UCS doesn’t scale???

Sounds more like the HP F.U.D. machine is in full swing vs. the Cisco marketing machine.

And no, I’m not affiliated with Cisco in any way. I just follow Data Center designs including such as John Manvilles (Cisco) and James Hamilton (Amazon).

Yes, Cisco’s main data center in Texas (DC1) is HP free, with a rapid migration of other sites from HP to Cisco.

John Manville, VP of Cisco’s DC’s has also demonstrated (in detail) how the TCO of HP ($3,600/server/quarter) has gone down to ($1,600/server/quarter) with UCS.

Looks like a lot of people on this thread need to do some homework and verify facts before they speak.

Robin, have you used Cisco UCS? Have you spoken to customers who have chosen it over competitive offerings? Do you really understand the power of shared storage, especially in VMWare environments? Sure, in massively scaled out environments like Amazon and Google, sure, DAS makes sense. But there are only a handful of those environments. The overwhelming majority of real businesses have more modest requirements, and the performance of NetApp and EMC as companies proves that people like shared storage, and the size of the blade market confirms people want to use these systems.

I actually install these systems and teach people how to use them. The fact that people are blogging about UCS and sign up as references show the power of the system. I’ve been here over 12 years and this is not just a marketing thing.

In response to your comment about “Cisco marketing hounds”, I work for a solutions integrator and Cisco partner, but never heard a thing from Cisco about this article. In fact, I was alerted to it when it was included as a link on an email sent out by an HP rep titled, “IT Critics Declare HP Dominance Over Cisco”. The StorageMojo piece, despite all of the critques by me an others, is still the best of the 5 links included in the email.

Robin, you say you have more coming. I hope you will specifically address the comments to your post.

Robin

While I quite like most of what you write, this article is a notable exception. At a meta level, the challenge is that you fail to consider UCS in the context of its intended purpose which is an optimized hosting platform for virtual infrastructure. Under this type of architecture, discussions about DAS and $1,000 pizza box servers become, for example irrelevant.

Before tackling the theme of the article which is that the UCS doesn’t scale, I wanted to address the undertone which is that the UCS 61000 “switch” is expensive. Cisco doesn’t, of course, make a 6100 switch. The UCS 6100 is a Fabric Interconnect that manages the UCS blades and aggregates uplink traffic. Quibbling over its cost is pointless. What is important is how well the UCS enables the overall vast savings and other benefits of a virtualized data center in respect to alternative solutions. The unified fabric, unified management, extended memory technology, stateless computing and VN Link capabilities put UCS in a class by itself for enabling optimal performance, provisioning and management of a virtual infrastructure. Additionally, the reduced switches, adapters and management module requirements along with superior power usage efficiencies typically make the UCS the least expensive option as well.

You say that, “You can buy a low-end server for that $1K/10G port”. That $1K port supports up to 4 blades, so the cost isn’t nearly as high as portrayed. While it is true that you can fill up your data center with 1RU pizza box servers, how will you manage them? How will you power and cool them? How are you going to justify the periodic upgrade costs, cabling, SFPs, maintenance contracts, rack space, network switch ports, SAN switch ports, and PDU, UPS and generator slices required? How will you back up all of the DAS disks?

In terms of the Cisco’s enterprise architecture not scaling, compared to what? 1 RU pizza box servers running GigE? Stating that a converged network uses more ports than separate LAN and SAN networks due to interconnects is a bit laughable. Any data center network of a significant size requires switch interconnects. These may use a relatively small number of uplink ports or, as intimated by Mr. Skorupa, they may require entire switches. The point is that this requirement exists regardless of whether the environment is traditional or converged. It is simply a matter of best practices in reducing single points of failure. What is also overlooked is that there will be an equally complex set of SAN switching which also may require a large number of switch interconnects. This will, of course, result in a fairly significant amount of cable bloat, not to mention potential cooling issues, rack space issues and management overhead. Generally speaking, full mesh LANs are a bad idea. The only reason to do this is because your core switch can’t handle the traffic load. This may be the primary driver behind the Nexus 7000 with its high backplane capacity.

Maintaining that DAS offers better scale out than SAN is irrelevant in a virtual infrastructure since we are always going to utilize shared storage for capabilities such as HA, FT, vMotion, etc. Even in an increasingly anachronistic physical data center, however, I would argue that more frequent disk failure, recovering from disk failure, reboot requirements for upgrades and lack of I/O performance in addition to the mentioned management challenges make SAN storage a superior option. Furthermore, new servers often utilize either a SCSI (320 Mbit/s) or SAS (3 Gbit/s or increasingly 6 Gbit/s at higher cost). The cost for this storage is not much less than the typical Fibre Channel back-end component of enterprise storage arrays.

Attempting to build a case for distributed architecture by referencing Amazon and Google is misleading. Large Web portals like this are the exception, not the rule, and utilize purpose-build systems designed from the ground up to function in a distributed farm – more comparable to high-performance computing clusters. Most business applications do not work this way, and probably won’t for a very long time, if ever.