Assuming adding (320) new servers (as blades) to an existing datacenter…

With Cisco UCS, you only add 1 additional management points.
With any other vendor, you ALWAYS add more, unless it is the very brand you already have. Even in that case, you usually add more server islands, server switches, SAN switches, etc. And all these need to be managed, usually independently.

So, do you suggest customers SHOULD stick to the brand, just because they already have some legacy investment in their products? This really sounds like running away from competition.

Disclaimer: I work for an integrator company as a Pre-Sales SE, which does mainly Cisco, but also Brocade, Juniper, McAfee, Tandberg (at least we “did” ), Tellabs, Teldat etc. with respect to customer’s expectations and needs.

In a UCS chassis with two IOMs and 4 links each, you have 80Gb/s (shared by 8 blades) resulting in 1:1 over subscription.

In an HP c7000 with two Flex-10′s, you have 80Gb/s (shared by 16 blades) resulting in 2:1 over subscription.

Both of those examples are cheesy at best. They quote raw numbers without considering operation in a failure.

To use a bare metal OS example on the UCS chassis, you could set half the blades to be fabric A active, fabric B failover. The other 4 blades could be configured fabric B active, fabric A failover. In this scenario, you _could_ run full-tilt 80gb/s. I suspect HP has some similar capability.

It kind of misses the point in a production data center though. If in the split-fabric scenario above, you exceeded an average throughput of greater than 20Gb/s on both fabrics, the loss of a fabric interconnect (or Flex-10) would mean a demand greater than 40Gb/s on the active remaining fabric and packets being dropped on the ground. Neither Cisco, HP, IBM or Dell can defy physics. Any sane designer takes this into consideration.

Cisco built a better mousetrap. Even if you haven’t drank the UCS kool-aid yet, I suspect you grudgingly will in the coming 2-5 years. I can’t wait to see HP or IBM validate the UCS concept by introducing similar functionality.

All truth passes through three stages:
First, it is ridiculed; Second, it is violently opposed; and Third, it is accepted as self-evident.

– Arthur Schopenhauer, 1788-1860

Time to deploy doesn’t compare … your complexity argument is just complete ignorance

Recently setup 2 new systems: Time To Complete 4 hours (UCS System, Core Network Connectivity, Core SAN Connectivity)

Have added 6 chassis to each system: Time To Complete each chassis, 15 min and 95% of that time is unpacking the chassis and taking it out to the data center floor. 3% racking and 2% logging into UCSM and then clicking to make server port.

Just the other day I had to add another network switch and san switch to an HP c7000 (install configure and cable), this took longer than adding the all 12 chassis (minus unpack time) and then installing ESXi on 6 servers….

You can keep your horse and buggy …. I like my new Under-carriage Combustion System

Disclaimer … I am an Enterprise customer that likes to get work done and not make life more difficult that it needs to be.

OK, if you did actually have such a niche application requirement like that you CAN infact do that in Cisco UCS, by simply populating each chassis with (4) compute blades. All blades in the chassis could send/receive 20 Gbps all at the same time. From there, you can scale that kind of bandwidth beyond a single chassis into a larger pod of (10) chassis holding (40) servers — all (40) servers capable of sending/receiving 20G of bandwidth at the same time to any other server in any other chassis, with no over-subscription.

How would you do that with HP/IBM/Dell chassis without skyrocketing the networking costs? Lets take HP … You would need to populate each c7000 chassis with no more than (8) servers, and each chassis would need (2) Flex-10 switch modules with all (8) 10GE uplinks connected. Each c7000 chassis with fans and power supplies is ~$8,700 list price. Each Flex-10 switch module is ~$12,000 list price. To manage all those Flex-10 modules you’ll also need the Virtual Connect Enterprise Manager license at $5,000 per chassis.

With Cisco UCS, on the other hand, you dont need per-chassis management licensce costs, you don’t need the expense 10GE switch modules in each chassis.

HP Solution (MSRP):
(5) c7000 chassis = $43,500
(5) VCEM licenses = $25,000
(10) Flex-10 modules = $120,000
(2) 48-port non-blocking 10GE switches (Arista 7148) = $50,000
HP Total = $238,500

Cisco UCS Solution (MSRP):
(10) chassis = $37,000
(20) fabric extenders = $40,000
(2) 40-port fully licensed fabric interconnects = $128,000
Cisco UCS Total = $205,000

Result: Cisco UCS is actually over $30,000 less and provides a whole lot more functionality (stateless computing):
http://www.mseanmcgee.com/2010/04/the-state-of-statelessness-cisco-ucs-vs-hp-virtual-connect/

Help me understand what you see as Cisco UCS “huge costs” — because I must be missing something here.
The reality is, in your Frankenstein bandwidth scenario, the costs only work favorably for HP/IBM/Dell if you would actually implement a single chassis with no upstream networking, and no customer is going to realisticly implement that.

Cheers,
Brad

While the Tolly review clearly has some flaws in it, the review does cast light on the fact that the UCS platform’s I/O capabilities, even if ‘properly’ configured are severly limited. If the Chassis is only capable of 80gb of I/O, then your blades, best case, under full load, cannot truly leverage over 10gb per blade.

And I won’t even get started on the huge costs and extremely proprietary nature of the UCS platform.

Cheers,
Brad