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.]
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
I have heard this a lot over the years, in one way or another – “The only price that really counts is what I actually pay for my server.”
Alright, so why bother with a TCO analysis? The truth is that server acquisition costs only contribute 20% (or less) to a 3 year server TCO. Management and other OpEx costs contribute the remaining 80%. If you go to 5 years, the acquisition cost starts to fade into obscurity.
There are a number of studies you can find online that call out server acquisition cost at 15% to 17% of TCO, or even less. One is an Information Week report that quotes a 2007 IDC study. The Information Week article is very good, with multiple sources and definitely worth a read. Since 2007 there have been myriad improvements in processor performance, as well as, server and architectural innovations (Cisco UCS). All of these supply ample rationale for a low CapEx component for Server / Data Center Total Cost of Ownership, see the figures below.
[The WW Server Related Spend… chart is from IDC, “New Econmoinc Model of the Datacenter”; IDC 2011] [Only the graph is from the cited source, the table is my analysis of the numbers presented by the graph.]
Summary of the figures above:
Server purchase spend and associated power & cooling spending is flat (red and green bands above)
Physical server management cost is the down (blue aband bove)
Virtual server management cost are way up and increasing (orange band above)
Cisco UCS Servers and Blade Server Evolution, part 1, as the title suggests, discussed blade server evolution and why Cisco UCS is a game changer. Now let’s talk about what the implications are for blade server TCO (Total Cost of Ownership) and how Cisco Unified Computing System scales vs. legacy blade architectures.
Blade Server TCO and Scale
Scale is the crux of the problem that has historically been the barrier for blade servers to deliver on their initial promise. Scale for I/O. Scale for Servers. Scale for Management. Cisco identified these shortfalls in the traditional legacy blade architecture and came to the marketplace with an innovative, game changing redefined architecture – Cisco UCS.
As discussed in “part 1”, to move the bar for blade chassis, we to better consolidate I/O, management and scale. Enter Cisco UCS. Deliver everything at scale: servers and I/O and blade chassis and management etc. Deliver a new design, rather than retreading an old dead end chassis ‘building block’ design.
Efficiency and Scale by Design
The requisite new design is what Cisco delivered. Cisco UCS is a variable chassis count, variable server count, variable I/O capacity, smart scaling architecture.
Figure 1 is the Cisco design, a converged I/O (FCoE – lossless FC and Enet combined) that scales. It provides easy, efficient infrastructure scaling across: multiple chassis, multiple servers, racks, rows and yes, it even includes the integration of rack servers into the solution.
Figure 1: Cisco UCS architecture – 10 x 8 blade chassis = 80 blade servers, 20 cables (add more I/O by simply adding cables – easy scaling)
Figure 2 is a Non-Converged legacy blade chassis I/O architecture. More = more… of everything. More chassis to hold more blades is OK, that makes sense. But more Switches? More cables? More points of Management? More complexity? Not too good.
Arguably the place to begin a Cisco UCS blade server journey would be with “Why Blade Servers”. ‘Blades’ are cool. There was “Blade Runner” (a cult classic) and the Wesley Snipes “Blade” movies, several TV series with ‘blade’ in the name, on and on; but for data centers and servers? Why blades? Where is the Blade Server TCO & ROI benefit that drives business decisions and therefore innovation and how do blade servers / chassis get there?
Blade servers have been around since about year 2000 and arguably came about as a way to make data center footprints smaller and reduce power consumption (reduced TCO). Nothing new here for blade enthusiasts. Rack servers were taking up more and more space and power in data centers. The concept of blades was brilliant, insightful and simple. Take as many common rack delivered functionalities (services) as possible, and package them together for delivery to a fixed group of servers. The easy targets for this were server power, cooling, and I/O (well, some I/O functions). To look at it another way, a blade chassis takes a data center rack with servers, I/O cables and switches, then shrinks them into a ‘building block unit’. Once you have the ‘unit’, put a single sheet metal wrapper around everything and voila, a blade chassis. Overly simplistic I know, but a close enough visual. If you want a step-by-step evolution, Sean McGee (a colleague of mine here at Cisco) did a darn good overview The “Mini-Rack” Approach To Blade Server Design.