It’s finally here- the new Data Center and Cloud community framework has launched! We created new content spaces for Compute and Storage, Software Defined Networks, Data Center and Networking, and OpenStack and OpenSource Software.
Over the last 12 months I’ve been doing a lot of work that has involved the Cisco Nexus 1000v, and during this time I came to realise that there wasn’t a huge amount of recent information available online about it.
Because of this I’m going to put together a short post covering what the 1000v is, and a few points around it’s deployment.
What is the Nexus 1000v?
The blurb on the VMware website defines the 1000v as “..a software switch implementation that provides an extensible architectural platform for virtual machines and cloud networking.”, and the Cisco website says, “This switch: Extends the network edge to the hypervisor and virtual machines, is built to scale for cloud networks, forms the foundation of virtual network overlays for the Cisco Open Network Environment and Software Defined Networking (SDN)”
So that’s all fine and good, but what does this mean for us? Well, the 1000v is a software only switch that sits inside the ESXi (and KVM or Hyper-V, if they’re your poison) Hypervisor that leverages VMware’s built-in Distributed vSwitch functionality.
In the past, we have pointed out that configuring network services and security policies into an application network has traditionally been the most complex, tedious and time-consuming aspect of deploying new applications. For a data center or cloud provider to stand up applications in minutes and not days, easily configuring the right service nodes (e.g. a load balancer or firewall), with the right application and security policies, to support the specific workload requirements, independent of location in the network is a clear obstacle that has to be overcome.
Let’s say, for example, you have a world-beating best-in-class firewall positioned in some rack of your data center. You also have two workloads that need to be separated according to security policies implemented on this firewall on other servers a few hops away. The network and security teams have traditionally had a few challenges to address:
- If traffic from workload1 to workload2 needs to go through a firewall, how do you route traffic properly, considering the workloads don’t themselves have visibility to the specifics of the firewalls they need to work with. Traffic routing of this nature can be implemented in the network through the use of VLAN’s and policy-based routing techniques, but this is not scalable to hundreds or thousands of applications, is tedious to manage, limits workload mobility, and makes the whole infrastructure more error-prone and brittle.
- The physical location of the firewall or network service largely determines the topology of the network, and have historically restricted where workloads could be placed. But modern data center and cloud networks need to be able to provide required services and policies independent of where the workloads are placed, on this rack or that, on-premises or in the cloud.
Whereas physical firewalls might have been incorporated into an application network through VLAN stitching, there are a number of other protocols and techniques that generally have to be used with other network services to include them in an application deployment, such as Source NAT for application delivery controllers, or WCCP for WAN optimization. The complexity of configuring services for a single application deployment thus increases measurably.
A Guest Blog by Partner Rick Heiges of Scalability Experts: Rick is a SQL Server Microsoft MVP and Senior Solutions Architect. He primarily works with Enterprise customers on their Data Platform strategies. Rick is also very involved in the SQL Server Community primarily through PASS and events such as the PASS Summit, SQL Saturdays, and 24 Hours of PASS. His tenure on the PASS Board of Directors saw the annual Summit triple in size from 2003 to 2011. You can find his blog at www.sqlblog.com.
So far, it has been another great week here at the PASS Summit 2014, SQL Server’s largest annual user and partner conference. With yesterday’s keynote address, there is still very much a focus on getting to the cloud and new investments in cloud technology in general. Microsoft seems to be extending its data collection and storage technologies in the cloud and also on-prem. One of the coolest features talked about was the concept of a “stretch tables” where a table that lives on your on-prem SQL Server can be “stretched” on to tables in SQL Azure Databases. The data may be shared so that the “hot” data can stay local and the “cold” data would live in the cloud. There were some other great demos around using the Kinect device to create a heat map of customer activity in a physical store (similar to what people linger and search for when shopping online). You can watch the PASS Summit 2014 Keynote here on PASStv.
As a Senior Solutions Architect with Scalability Experts, I work with large enterprise customers (Fortune 500 type) on a regular basis. There is more and more interest about leveraging the Public Cloud for some workloads and taking advantage of “on-prem” resources in a cloud-like way. This means deploying your internal resources in a similar way – for example via Cisco’s Microsoft Fast Track certified FlexPod or VSPEX integrated infrastructure solutions – that public cloud resources are deployed with a similar chargeback (or ‘show back’) model and automating the self-service deployment of infrastructure, and the monitoring of the entire stack.
One of the things that I really like about Microsoft’s products is a focus on ease of use, tight integration, and low TCO. This is important to a lot of the customers that I interact with. This is why I have seen a surge in Cisco UCS products in my customer base of the past few years. Cisco has a similar goal to keep things simple and TCO low – read this Total Economic Impact report from Forrester on UCS ROI/TCO. Cisco also provides Management Pack plug-ins to Microsoft’s System Center suite for tight integration so that you can manage the entire stack (Hardware, Hypervisor, Application, and even Public Cloud) with a single tool. It is great to see how this partnership between Microsoft and Cisco can be beneficial to the customers that I work with.
Microsoft’s SQL Server 2014 also brings “In-Memory” Technology to OLTP in a cost-effective manner by not forcing a complete rewrite of the application. In a recent Cisco UCS on Microsoft SQL Server 2014 case study, Progressive Insurance was able to take advantage of this technology to further its strategy of its competitive advantage – ease of use.
Eventually, I see the Public Cloud taking on a more “primary” role in the future. Similar to the “Everything on a VM unless there is a reason not to” mantra, I see an “Everything on a Public Cloud VM unless there is a reason not to” mantra on the long-term horizon. Until then, the Hybrid Cloud will be the default stance for many large enterprises.
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.