A Guest Blog by Cisco’s Frank Cicalese: Frank is a Technical Solutions Architect with Cisco, assisting customers with their design of SQL Server solutions on Cisco Unified Compute System. Before joining Cisco, Frank worked at Microsoft Corporation for 10 years, excelling in several positions, including as Database TSP. Frank has in-depth technical knowledge and proficiency with database design, optimization, replication, and clustering and has extensive virtualization, identity and access management and application development skills. He has established himself as an architect who can tie core infrastructure, collaboration, and application development platform solutions together in a way that drives understanding and business value for the companies he services.
Ah yes, it’s that time of year again. It’s time for PASS Summit! I hope all of you are having a great event thus far. During my conversations with customers and peers, I am inevitably asked “Why should we implement SQL on UCS?” In this blog I cover this very common question. First off, for those of you not familiar with Cisco UCS, please visit here when you have a moment to learn more about this great server architecture. So, why would anyone want to consider running their SQL workloads on Cisco UCS? Read on to learn about what I consider to be the top reasons to do so…
High availability is one of the most important factors for companies when it comes to considering an architecture for their database implementations. UCS provides companies with the confidence that their database implementations will be able to recover quickly from any catastrophic datacenter event in minutes as opposed to the hours if not days that it would take to recover on a competing architecture. UCS Manager achieves this through its implementation of Service Profiles. Service Profiles contain the identity of a server. The UCS servers themselves are stateless and do not acquire their personality (state) until they are associated with a Service Profile. This stateless type of architecture allows for the re-purposing of server hardware dynamically and can be utilized for re-introducing failed hardware back in to production within five to seven minutes.
Service Profiles can provide considerable relief for SQL Server administrators when re-introducing failed servers back in to production. Service Profiles make this a snap! Just un-associate the Service Profile from the downed server, associate it with a spare server and the workload will be back up and running in five to seven minutes. This is true for both virtualized and bare-metal workloads! Yes! You read that last statement correctly!! Regardless of the workload being virtual or bare-metal, Cisco UCS can move the workload from one server to another in five to seven minutes (providing they are truly stateless i.e., booting from SAN).
Since every server in UCS that is serving a workload requires that a Service Profile be associated with it, Cisco UCS Manager provides the ability to create Service Profile Templates which ease the administrative effort involved with the creation of Service Profiles. Server administrators can configure Service Profile Templates specifically for their SQL Servers and foster consistent standardization of their SQL Server implementations throughout the enterprise via these templates. Once the templates are created, Service Profiles can be created from these templates and associated to a server in seconds. Furthermore, these operations can be scripted via Cisco’s Open XML API and/or PowerShell integration (discussed next) simplifying the deployment process even more.
To learn more about Service Profile Templates and Service Profiles, please visit here.
Manage Workloads Efficiently:
Cisco UCS has very tight integration with Microsoft System Center. Via Cisco’s Operations Manager Pack, Orchestrator Integration Pack, PowerShell PowerTool and Cisco’s extensions to Microsoft’s Hyper-V switch, administrators are able to monitor, manage and maintain their SQL Server implementations proactively and efficiently on Cisco UCS. Additionally, Cisco’s PowerTool for PowerShell, with its many cmdlets, can help to automate any phase of management with System Center thus optimizing the overall management/administration of Cisco UCS even more so. All of this integration comes as a value-add from Cisco at no extra cost!
Please visit http://communities.cisco.com/ucs to learn more about, download and evaluate Cisco’s Operations Manager Pack, Orchestrator Integration Pack and PowerShell PowerTool.
Read More »
Tags: business intelligence, Cisco, database, Microsoft, Microsoft SQL Server, Microsoft SQL Server2014, Microsoft Windows Server 2012, Nexus 1000v, OLTP, UCS
The second revolution in server virtualization is here. Virtual Machines were the first revolution that allowed users the ability to run multiple workloads on a single server through a hypervisor. Now the next wave is here. Linux Containers have recently started to gain momentum with many enterprise customers asking me if they should consider it and if Cisco offered Docker support in the enterprise-grade virtual networking products.
I approached my engineers to see whether our recently introduced Nexus 1000v for the Linux KVM hypervisor, which already has 10000+ customers across various hypervisors, is able to support linux containers or more specifically the popular linux container technology, Dockers.
One of the key advantages of Nexus 1000V today is that it allows easy management of policies for all of the virtual machines. For example, with a single command or REST API call, a security policy can be deployed or altered across all virtual interfaces connected to a Virtual Extensible LAN (VXLAN). My reasoning was that we should able to extend that to support to linux containers/dockers.
So I approached Tim Kuik (@tjkuik) and Dave Thompson (@davetho610) and much to my delight, they not only said Nexus 1000V can do it but also showed how to do it so that customers can take advantage of this today in their deployments.
I have included Tim and Dave’s how to attach Docker containers to the Nexus 1000v and to assign policies write-up below so that you can try this in your setup. Happy reading.
How to use Dockers with Nexus 1000V for KVM Hypervisor:
Begin by installing the Nexus 1000v to manage one or more Ubuntu servers: The Nexus 1000v is managed by a Virtual Supervisor Module (VSM). Once the package is installed on your servers, the servers will appear on the VSM as Virtual Ethernet Modules (VEM). Below we can see our VSM is managing a server named Bilbo:
We’ve also pre-configured our server to have a port-channel that is capable of carrying vlan traffic 100-109. We’ve used an Ethernet Port-profile to conveniently manage the uplinks for all of our servers:
A key concept of the Nexus 1000v is that of a Port-profile. The Port-profile allows for a shared set of port attributes to be cohesively managed in a single policy definition. This policy can include an ACL definition, Netflow specification, VLAN or VXLAN designation, and/or other common port configuration attributes. We can, of course, create multiple Port-profiles. Perhaps we would have one per level of service or tenant. The Port-profile provides the mechanism to collect and manage the set of containers that share the same policy definition.
Below we create a Port-profile that could be used by any number of containers on any number of servers.
Install docker on your server. [https://docs.docker.com/installation/ubuntulinux/]
The purpose of the container is to run our application. Let’s create one for this example which can handle ssh sessions. Here is an example Dockerfile which does that:
At this point, via Docker, you can build an image specified by this Dockerfile.
All the pieces are now in place. The Nexus 1000v is running. We have a policy definition that will assign the interfaces to vlan 100 (port-profile vlan100). Docker is installed on our server. We have created a useful container image. Let’s create an actual container from this image:
The container instance started at this point is running with just a loopback interface since we used the argument “–networking=false”. We can now add an eth0 interface to this container and set it up to be handled by the Nexus 1000v on the host.
Setup a few env variables we will use as part of the procedure. Find the PID of the running container and generate UUIDs to be used as identifiers for the port and container on the Nexus 1000v:
In this example the following PID and UUIDs were set:
Create a linux veth pair and assign one end to the Nexus 1000v. We will use the port-profile defined on the VSM named “vlan100’ which will configure the port to be an access port on VLAN 100:
When an interface is added to the Nexus 1000v, parameters are specified for that interface by adding keys to the external_ids column of the Interface table. In the example above the following keys are defined:
- iface-id: Specifies the UUID for the interface being added. The Nexus 1000v requires a UUID for each interface added to the switch so we generate one for this.
- attached-mac: Provides the MAC of the connected interface. We get this from the ‘ip link show’ command for the interface to be added to the container.
- profile: Provides the name of the port-profile which the Nexus 1000v should use to configure policies on the interface.
- vm-uuid: Specifies the UUID for the entity which owns the interface being added. So in this case that’s the container instance. Since Docker doesn’t create a linux type UUID for the container instance, we generate one for this as well.
- vm-name: Specifies the name of the entity which owns the interface. In this case it’s the container name.
Move the other end of the linux veth pair to the container’s namespace, rename it as eth0, and give it a static IP address of 172.22.64.201 (of course DHCP could be used instead to assign the address):
On the Nexus 1000v’s VSM you will see logs like this indicating the interface has been added as switch port vethernet1 on our virtual switch:
The following VSM commands show that switch port veth1 is up on VLAN 100 and is connected to host interface veth18924_eth0 on host bilbo:
On the host bilbo we can use vemcmd to get information on the port status:
That’s it. We now have a useful Docker container with an interface on the Nexus 1000v using our selected policy. Using another server (and/or container) that is on the same vlan, we can ssh into this container using the IP address we assigned:
When shutting down the Docker container, remove the port before removing the container:
Tags: docker, Nexus 1000v
There has been some seismic activity happening in Bay Area and the epicenter for all Virtual Networking shifts is right here at Cisco HQ in San Jose. (Our sympathies go to all those affected by the real earthquake further to the north.) At Cisco, it’s all about the applications and the shift to dynamic network virtualization. Cisco pioneered virtual networking with Nexus 1000V virtual switch and recently incorporated it in the application aware Application Virtual Switch (AVS), for Cisco ACI-enabled networks. Cisco is excited to announce the availability of Nexus 1000 Release 3.1 of Nexus1000V for vSphere (available for download here). We are showing the upcoming generation of the virtual switch at VMworld in San Francisco this week.
Nexus1000V is the edge switch for virtual environments, bringing the network edge right up to the virtual machine, and connecting virtual ports to the physical network and beyond. The Nexus 1000V is the foundation for our virtual network overlay portfolio, including all of our virtual L4-7 application and security services, our cloud orchestration software, VXLANs and more. It is also at the heart of AVS, a purpose-built, hypervisor-resident virtual network edge switch designed for the Application Centric Infrastructure.
Release 3.1 is a new major release enabling enterprise and cloud provider customers running the vSphere hypervisor to leverage the distributed virtual firewall VSG, expand VXLAN footprint in the datacenter, improve secure isolation thru Cisco TrustSec and dramatically simplify updates through Cisco VSUM (Virtual Switch Update Manager). Most of the new features are value add to the Advanced Edition. New customers will need a Ver 3 specific license to use the full functionality of Ver 3. Existing customers with support contract are automatically entitled to free upgrade to Ver 3. AVS incorporates Nexus 1000V capabilities with consistent application policy enforcement for virtual workloads and unprecedented end-to-end visibility for applications in your data center.
Features of the new Nexus 1000V Release 3.1:
- Increased Scalability (Advanced Edition) – More than doubles the scale from the previous release. The virtual switch now supports 250 hosts/servers per switch with 10,000 ports per switch. In addition it supports 4094 active VLANs and 16 million VXLAN (6144 active VXLANs) per switch across 6144 port profiles.
- VXLAN control plane: BGP based control plane across multiple virtual switches provide expanded Layer 2 domain footprint that can potentially support nearly 40,000 VMs in a single domain
- Increased Resiliency – Supports headless Port bring up where Virtual Machines can be bought up on the host even if VEM is offline i.e. the VSM is not reachable by VEM. Both VSM headful and headless VM vMotion is supported.
- Cisco TrustSec 2.0 (Advanced Edition) – Continues to extended Cisco TrustSec solutions for network based segmentation of users and physical workloads, leveraging Security Group Tags (SGT) for defining security segments and SGACL support (Enforcement) and Native(in-line) SGT tagging.
- BPDU Guard – Keeps virtual network safe from misconfigured VLANs and strictly enforces VLAN boundries. It prevents Misconfigured VLAN Rogue devices from flooding the network
- Storm Control – Prevent network disruptions from a broadcast, multicast, or unknown-unicast traffic storm.
- Simplified Deployment, upgrade and visibility with Cisco VSUM – Cisco VSUM is a FREE virtual appliance that enables Server and Network administrators to Deploy, Upgrade and Monitor Nexus1000V and to Deploy and Upgrade Cisco AVS from within their vCenter web interface.
- Customer Experience – Here’s what one of our Beta customers, Josh Coen says about Cisco VSUM. Josh is a Principal Cloud Architect with Varrow and has been working in the IT industry since 1999, with a heavy focus on virtualization and storage since 2008.
Nexus 1000V has already reached the 10,000 customer milestone with some customers purchasing 1000+ CPU licenses. Nexus 1000V continues to provide the foundation for the most advanced virtual networks by supporting, 1) multiple hypervisor environments, such as VMware vSphere, Microsoft Hyper-V and Openstack KVM 2) the most extensive set of virtual network services, including ASA 1000V Cloud Firewall, distributed zone-based virtual firewall, vWAAS WAN optimization, the Cloud Services Router (CSR) 1000V, Cisco Prime Network Analysis Module (NAM) and advanced service insertion and chaining technology, vPath and 3) a true management control plane that provides greater policy and control features for richer networking functionality.
We’ll be showing a lot of these features this week. Come by our booth and check it out. If you are around #VMworld this week, give us a shout out on twitter using Cisco hash tag #ciscovmw. For those of you that can’t make it out to VMworld, listen to the review of these new features in Ver 3.1 in this webcast.
Tags: ASA 1000V, Cisco ONE, CSR 1000V, Hyper-V, NAM, Nexus 1000v, OpenStack, TrustSec, Virtual Network Management Center, Virtual Security Gateway, virtual switch, VMware, vmworld, VNMC, vPath, vsg, VSUM, VXLAN
In this week’s episode of Engineers Unplugged, David Hartman and Tim Cerling discuss Fast Track 4.0 Solutions, which promote fast and efficient deployment of private clouds with Cisco, EMC, and Microsoft solutions.
How many engineers does it take to straighten a whiteboard? (Answer: 5) Behind the scenes on #EngineersUnplugged
If you would like to become Internet Famous, and strut your unicorn talents, join us for our next filming session at VMworld 2014. Tweet me for details!
This is Engineers Unplugged, where technologists talk to each other the way they know best, with a whiteboard. The rules are simple:
- Episodes will publish weekly (or as close to it as we can manage)
- Subscribe to the podcast here: engineersunplugged.com
- Follow the #engineersunplugged conversation on Twitter
- Submit ideas for episodes or volunteer to appear by Tweeting to @CommsNinja
- Practice drawing unicorns
Join the behind the scenes by liking Engineers Unplugged on Facebook.
Tags: EMC, fast track, Microsoft, Nexus 1000v, private cloud
If it’s mid-July then it is time once again for Microsoft’s annual worldwide partner conference – WPC. For 2014, we find Cisco’s Microsoft team in Washington D.C. joining around ~16,000 other Microsoft partners. The partners come from all around the world and are of all partner types be they VARs, local System Integrators, Global System Integrators, or OEMs. They have come to D.C. to learn what Microsoft has up their sleeves for the upcoming year as well as to hear Microsoft CEO Satya Nadella give his first major WPC keynote. This is Cisco’s fourth consecutive year of WPC sponsorship – from L.A. to Toronto to Houston and now to Washington D.C. – we have amped up our investment year over year to showcase our leading datacenter technologies for the Microsoft ecosystem. Read More »
Tags: @ciscoDC, Cisc UCS, FlexPod, Hyper-V, Microsoft, Microsoft SQL Server, Microsoft Windows Server 2012, Nexus 1000v