Every server manufacturer has a Server TCO tool, of sorts. Why do I say “of sorts”? Because rather than a straightforward approach to TCO, some tools color the input parameters with fixed pre-sets, conditions and assumptions. Certainly every tool has some assumptions and pre-sets; they just need to be applied equitably across all scenarios and all vendors. If not, you get results that “…would strain credulity…” in the immortal words of Captain Barbossa [Pirates of the Caribbean – At World’s End; my daughters love these movies. OK, me too.]
Simplifying Cloud Infrastructure Deployments with Cisco Common Cloud Architecture built on Cisco UCS and OpenStack
In three short years OpenStack has become cloud management platform that is “Too Big to Fail” (according to Citi Research). Whether it is true or not, OpenStack is definitely gaining traction and is making a profound impact not only as a viable Cloud management option, but also on the software economics for Cloud solutions.
Cloud computing is rapidly transforming businesses and organizations by providing access to flexible, agile, and cost-effective IT infrastructure. These elastic capabilities help accelerate the delivery of infrastructure, applications, and services with the right quality of service (QoS) to increase revenue. Cisco’s approach—innovative and unified data center infrastructure that provides the underlying foundation for OpenStack technology—enables the creation of massively scalable infrastructure that delivers on the promise of the cloud.
Cisco Common Cloud Architecture built on Cisco Unified Computing System (UCS) with OpenStack provides the foundation for flexible, elastic cloud solutions enabling speed and agility. As the saying goes “Every Skyscraper is built on a strong foundation of pillars”, the OpenStack platform requires the core requirements from the underlying infrastructure – simplification, rapid provisioning, self-service consumption model, and elastic resource allocation. Cisco UCS uniquely provides a policy based resource management model, which simplifies by integrating compute, networking and storage with the ability to scale and automate deployment.
This foundation addresses every stage of cloud deployment be it private or public cloud offerings. Some of primary workloads targeted for OpenStack based deployments are:
- Self-service development and test environments
- Massively scalable software-as-a-service (SaaS) solutions
- High-performance, scale-out storage
- Web server, multimedia, big data, and cluster-aware applications
- Applications with extensive computing power requirements and mixed I/O workloads
To accelerate these cloud infrastructure deployments, Cisco has developed starter configurations focused on compute-intensive, mixed or heterogeneous and storage-intensive workloads. The various server nodes are typically sized to include the OpenStack controller, compute, Ceph storage, Swift proxy and Swift storage.
Cisco UCS Solution Accelerator Paks for Cloud Infrastructure Deployments
Scaling beyond 160 servers can be implemented by interconnecting multiple UCS domains using Nexus 3000/5000/6000/7000 Series switches, scalable to thousands of servers and to hundreds of petabytes storage, and managed from a single pane using UCS Central in a datacenter or distributed globally as shown in figure.
I recently wrote a blog titled Blade Server TCO and Architecture – You Cannot Separate Them and thought a little more on the architecture side would be a good thing.
With so much misinformation (dis-information?) about UCS running around in the ether, I thought the straight forward comparison offered here would be valuable. It is important to dispel myths and analyze reality before making the important decisions around server and networking refreshes / upgrades, which by necessity affect long term data center architecture. I hope you will find this presentation – Cisco UCS, HP and IBM – A Blade Architecture Comparison, useful in your decision making process.
For me, there are three primary drivers that differentiate the Cisco UCS architecture from everyone else’s designs and they can be divided into the buckets below:
You could, and probably should, ask what is left out? That’s pretty easy. I did not specifically call out Performance and TCO, for a good reason. If you can execute on the three bullets above like Cisco UCS does, Performance and TCO are the natural derivatives. You shouldn’t have to target them separately. It’s kind of a “If you build it, they will come” scenario. That’s why I made the statements in the TCO and Architecture blog that “…Server cost is irrelevant (to OpEx) because: changing its contribution to total TCO has a vanishingly small impact….” and “…It [architecture] is the single most important component of OpEx…” For more on this and how server cost and TCO intersect, please check out this blog – Blade Server TCO and Architecture – You Cannot Separate Them. It takes a look at the OpEx and CapEx components of TCO, and how altering either of them effects the actual total 3-year TCO. You may be surprised.
Cisco is providing trade-in credits for customers’ old generation servers and blade chassis, helping ease the transition and upgrade to a new UCS blade architecture. The UCS Advantage presentation below has more details on this fantastic program that can further enhance the already compelling TCO benefit of upgrading to Cisco UCS.
Special note: For more on the benefit that Cisco UCS delivers for I/O and throughput, I suggest a great blog by Amit Jain – How to get more SAN mileage out of UCS FI. Amit does an excellent compare / contrast of FC and FCoE technologies (“…8 Gb FC yields 6.8 Gb throughput while 10 Gb FCoE yields close to 10 Gb throughput…”).
Tags: blade architecture, blade architecture comparison, blade server, blade server architecture, blade server TCO, capex, Cisco, Cisco UCS, data center, data center TCO, HP blades, HP BladeSystem, IBM blades, IBM Flex Fabric, opex, server, server TCO, tco, technology, UCS
Guest post by Dennis Clark, Senior Solutions Marketing Manager – Microsoft Applications, NetApp
We are here in Charlotte this week with our Cisco friends, with the opportunity to talk with all sorts of like-minded Microsoft SQL Server individuals at the 2013 SQL PASS Summit. The conversations vary in range from things like database performance, developer issues, to private cloud and data management concerns. We’ve also had some good chats with a few data warehouse folks, which prompted me to share some thoughts on this topic.
We know that the data warehouse (DW) is central to a comprehensive business intelligence (BI) solution. So clearly, if our DW isn’t up to snuff, as they say, then we can forget about delivering critical analytics to a growing number of LOB managers and execs. This, in turn, negatively affects the bottom line of the business, which isn’t good for anyone. And it isn’t getting any easier. Data is growing exponentially and the problem of integrating data from multiple sources isn’t going away any time soon. These issues, along with the complex interaction of the different components of a BI solution, continue to make the design, deployment and management of data warehouses a challenge. Now you can continue to throw money at it by over-provisioning and burning up valuable data center space and power to try to keep up, or you can strive to achieve a higher level of DW nirvana with Cisco and NetApp.
Data Warehouse Nirvana
Intel estimates1 that one-third of the servers in production are more than four years old. At first, one might think that it is great to get this much service out of a capital investment, but the operational costs to run these outdated servers would pay for a complete technology refresh increasing performance and reliability while reducing total costs. How is this possible? With the Intel® Xeon® Processor E5-2600 v2 product family and Cisco’s Unified Computing System. Read More »
Tags: B200 M3, BL460c, blade server, Cisco, Cisco UCS, data center, datacenter, Hewlett Packard, HP, HP BL460c Gen8, Intel E5-2600, Intel Xeon, Intel Xeon E5, Ivy Bridge v2, rack server, refresh, ROI, savings, sever, tco, UCS, x86