Not Your Father’s Cisco

Some might think this is a no-brainer after Cisco’s March introduction of their “Project California” UCS line. But much of the discussion and coverage at that time centered on the question of whether the UCS hardware was really a play for dominance or merely an extension of Cisco’s network leadership. Specifically, the initial UCS hardware was only available in a blade form factor and was introduced with much focus on running virtualization software from VMware and Microsoft. Many concluded that, although UCS was debatably innovative in the server space, it would remain a niche product.

But Cisco wiped away any doubt at their June 2009 Partner summit: They’re not just producing a blade server for large virtualization environments. UCS is a full line of servers in a variety of form factors aimed at all data center server workloads. On Tuesday, two shots were fired. First, Cisco’s Omar Sultan came right out and staked the claim: UCS is not just for virtualization. Then Cisco announced a new line of UCS servers, the rack-mount C-Series.

Cisco: Full-Line Server Vendor

Cisco's new C-Series of rackmount servers

The C-Series servers are important more for what they represent than for the specifics of the three models announced. While the B-Series blade servers were huge, expensive, and especially appropriate in the largest enterprise virtualization environments, the new C-Series makes sense anywhere in the data center. They start very small, with the entry-level C 200 M1 sporting just two CPUs, four 3.5″ hard drives, and 2 PCIe adapters in a one RU format. Pricing has not yet been announced, but expect these to compete with the higher-end enterprise server lines from IBM, HP, and Dell.

Step up to the 2 RU C 210 or C 250 and you get greater scalability in terms of drives or memory, respectively. These new systems nicely bridge the gap below the market for more expensive and scalable blade servers like the B-Series UCS systems previously announced. All of the UCS server models feature similar features and can be integrated into the new unified computing environment envisioned by Cisco, centered around 10 Gb datacenter-class Ethernet.

Will it work?

That’s the multi-billion dollar question. There must have been some interesting discussions within Cisco on whether or not to take on the server-space titans, alienating these potential partners and risking sales. Undoubtedly, the revenue potential from entering the $85 billion data center server market proved too tempting. Plus, those vendors, especially HP, have been making waves in Cisco’s core market of enterprise networking.

Cisco is expected to bring in $36 billion in revenue in 2009, down from $38 billion in 2008, and must make bold moves to move that number higher. Taking $20 billion in data center server sales over the next two or three years is a very good way to accomplish this!

© Stephen Foskett for Gestalt IT, 2009. | Cisco Launching Full Assault On Data Center Server Market
Read more posts categorized as Exclusive, Featured, Networking, Server Virtualization, Storage, Top Story

We at Gestalt IT applaud Cisco, and especially Wendy Mars, for their straightforward responses to our concerns. Cisco responds particularly to some of the question we and others (see the list below) have raised:

• Is it really more than a blade server?
• Who’s going to deliver the solution?
• Is this a data center in a box?
• Do enterprises want to unify networks, storage, and servers? (This is where she calls us out by name)
• The challenge of outages and downtime
• Is UCS only suitable for green-field sites?
• Will this lock customers into a proprietary system?

Our Response

Cisco responds to our question about the reluctance of existing IT infrastructure organizations to want to “unify” the various parts of their environment (server, networks, storage), which would seem to be the result of adopting the UCS vision. Wendy flatly says “they do” want to do this, that “they’ve been demanding this for some time”, and that Forrester and Gartner support this. Perhaps it is true that “C-level” management would love to unify these organizations, but do the “foot soldiers” want to do it? Certainly not! 

There is massive resistance to unifying storage, servers, and networking among IT professionals:

• Storage folks claim that server and networking groups don’t understand just how hard it is to meet the massive I/O demands placed on them. They also feel like critical elements like latency and storage resource management are overlooked by the rest of the infrastructure community. Storage is just a bunch of disk drives, right?
• Networking folks typically de-value storage and servers as mere end points and feel that the rest of the infrastructure community doesn’t understand how hard it is to keep everything talking. Networking is just some cabling, right?
• Server people feel like their domain is where all the real work happens, and storage and networks are just enablers. They’re closest to the end users, so they feel like network and storage groups don’t see the business pressures they face. But servers are just big PCs, right?

Whenever these three organizations meet, they disagree about priorities and root cause. They don’t speak each other’s languages. They don’t understand the best practices that have evolved. And when a company tries to merge them into a single organization, balls start dropping. The network is neglected. Or the storage is left to rot. Or the servers are virtualized just to get “that PC hardware” out of the way.

Now take a networking company like Cisco and watch it try to enter the world of storage and servers. Is it any surprise that there is resistance and even backlash against these “uninformed newcomers”? Cisco did everything right with their Fibre Channel storage product line, yet they failed to dominate the market. They probably hastened the marriage of Brocade and McData, but the fabric boys are probably stronger now then they have ever been. Cisco’s storage products were not a mistake, but they were not the runaway hit that many (including me) thought they would be. Once the dust settled, the most common question I heard from enterprise storage and networking folks was a simple one: “Is there any benefit to consolidating storage and networking with one vendor?”

Yet UCS, and the entire datacenter Ethernet vision, is something else entirely. It’s not consolidation on a single vendor with no urgent reason, as was the case with storage. UCS is real consolidation. Storage and networking and server hardware and virtualization all living under one roof and all managed together. All friends. Will this work? I don’t think the jury is in with a verdict. In fact, I think the jury has just started hearing evidence!

Watch the Video!

Cisco’s UCS Blogroll

If you’re interested, Cisco closes the video with a blogroll. Here it is in clickable form:

• Scott Lowe
• The Hot Aisle (note corrected URL)
• Rational Survivability
• Colin McNamara
• Storagebod (A Gestalt IT author)
• LANZen
• Brian Madden
• Christopher Crowhurst
• Gestalt IT (Hey, that’s us!)
• VMLover
• Open Source Juicer
• Storage Rap
• Solori
• Marc Hamilton
• SOA Real World
• Paul Fallon
• Ethereal Mind (A Gestalt IT author)
• Storage Mojo
• Cloud of Data
• Mark Wilson
• TechHead

© Stephen Foskett for Gestalt IT, 2009. | Cisco is Loud and Proud About UCS
Read more posts categorized as Exclusive, Featured, Networking, Storage

It does not cover SAN in any detail and the FC coverage is limited to this is how you present a LUN as a fibre channel device but this led on to some interesting conversations around the complexity of FC vs iSCSI.

I, for sometime, have been saying that the complexity of FC is over-stated and actually it is not really any harder than iSCSI. This often leads to looks of disbelief and complete disagreement, it is almost as if I am spouting heresy. The iSCSI camp think I am mad and the FC camp seem to think that I’m diminishing them.

But, if you take OnTap; there is really very little difference in how you present a iSCSI LUN compared to how you present an FC LUN. It is certainly no harder to do FC from an array management point of view.

And then we go to the host; lets take Windows for example. Now this is where I think a lot of the perception of the simplicity of iSCSI comes in; Microsoft have implemented a very nice software initiator, it’s there and it’s standard. A bit of pointing and clicking and you are there.

Unfortunately, traditional FC cannot be implemented completely in software and needs FC HBAs, hence we need to install additional drivers and software to make it work; these are not part of the standard Windows build and suddenly it all becomes ‘complex’.

If we go to Unix, we end up mucking about configuration files in general for both iSCSI and FC; so really it’s not any harder to do FC than iSCSI.

So if it’s not hard to do at the host level and if it’s not hard to do at the array; where is it hard? And this is where I think it becomes more interesting; it’s the network! Is a large Data Centre IP network harder to set-up than a large Data Centre FC network?

Arguably, the FC network is easier but it is different. In the FC network you have a lot less to worry about; you run less protocols, services, it’s non routeable, the security model is simpler, there is less potential for different workloads to clash, you do not have address space management to worry, you do not have name services to worry about and if I were a Network Admin, I would argue that it’s them who are being diminished by this constant claim that iSCSI is easier.

To do either iSCSI or FC properly is probably equally hard. If you just want to bung a block-level array in and do not care about segregation of traffic, quality of service, don’t care whether your IP back-up traffic and IP storage traffic contend and make your back-ups over-run. If you know you’ve got enough headroom on your existing IP network to carry your block traffic, go ahead with iSCSI; it’s easier because you’ve already got the infrastructure in place.

But if you want put in place a dedicated storage network; the choice is not as clear-cut as people would like to make out. Even when you start looking at cost; yes GbE is cheaper than FC but FC is generally running at 4 gig now and is faster. FC ports are in my experience are significantly cheaper than 10GbE ports. So if you need the throughput, then FC might well be cheaper than iSCSI.

There might be a small saving in the number of FTEs you require as you could have a single Network team but I believe that FC is actually so simple that if you get over the politics, you could have a single Network team which manages both FC and IP. This is purely politics and a turf-war!

If you are a small shop and you have just a few administrators who do everything, iSCSI might also make sense but don’t believe FC is hard; administering a small SAN with a couple of switches might not add a huge amount of additional overhead.

Neither iSCSI or FC are wrong answers but make sure that when you have got to the answer, you show your working. And when a vendor tells you what the answer is, ask them to show your their working and challenge it.

Of course, if I was building a green-field data-centre and could simply start again, I’d probably look at putting in Data Centre Ethernet which would give me the option of FCoE. I would have a single Network team from the get go.

It’ll be interesting to see if Microsoft bundle a software initiator for FCoE into Windows at some point; then I think we’ll see perceptions of complexity change again.

Yes, I’ve completely ignored NAS but actually many of the same arguments apply.

I’d welcome some thoughts; that’s if anyone is still reading and not exploded in apoplectic rage at the heretic!

© Martin for Gestalt IT, 2009. | Protocols, Religions and Heresy!
Read more posts categorized as All, Featured, Storage