A couple of weeks have passed since the announcement of Cisco’s Unified Computing System (UCS), and in that timeframe I’ve collected a number of links to articles and blog posts about UCS. I thought I’d collect them here and try to get a feel from all of the various viewpoints where the industry stands on UCS.
I’ll start with Robin Harris aka StorageMojo and his initial take on UCS. The one thing that jumped out at me about his article was this statement:
If IBM, HP and Sun aren’t meeting today to plot a radical, Cisco margin destroying open-source router & low-cost switch counterattack - like Seagate, HP and IBM performed on Quantum’s DLT - they’re idiots.
This seems to validate the strategy outlined by Sun and sheds new light—for me, at least—on the potential motivations for IBM to acquire Sun and, thus, Sun’s intellectual property. Is Big Blue’s move to acquire Sun a precursor to a strike against the heart of Cisco’s routing and switching business? And how would Cisco respond to just such a move?
Massimo Re Ferre’ of IT 2.0 approaches UCS from a different angle. According to Massimo, if you stop and really look at what you get from UCS, it’s not terribly different from what you can get from other vendors. In fact, if you separate out the unified fabric, there really isn’t a whole lot to distinguish UCS from other, similar solutions from HP, IBM, Dell, and Sun. And if you think about it, he’s right—it’s really only the unified fabric, along with the fabric extenders in the chassis and the single point of management, that differentiate the platform.
Therein lies the problem. Massimo points out a couple of potential problems with unified fabric (security and political/organizational challenges). If unified fabric doesn’t fly, then UCS is grounded too. And industry excitement over FCoE isn’t exactly the greatest in the world. Chris Evans aka The Storage Architect makes clear his feelings about FCoE in this post:
FCoE is a Cisco strategy to own the data centre, nothing else. As the recession bites, it would be a brave soul who could justify the disruption and additional spend, for very little gain.
FCoE is hardly a forgone conclusion, and given that so much of UCS’ value is tied up in the unified fabric and the results that come from it, that makes UCS awfully vulnerable.
Not everyone thinks that FCoE makes the UCS vulnerable, by the way; technology evangelist Christopher Kusek thinks the future will be a unified one:
The Data center has spoken and it’s answer is True unification.
Burton Group analyst Drue Reeves says that this was a move Cisco had to make:
In the end, UCS was a move Cisco had to make to ward off competition AND increase shareholder value. Cisco has a strong brand, enterprise credibility, the technical chops and finances to pull it off. Is UCS a business risk? Sure. But the greater risk for Cisco is to do nothing.
Perhaps, perhaps not. Given that UCS relies so heavily on FCoE, wouldn’t it have made sense for Cisco to push the FCoE train along by providing FCoE interconnects for blade servers from HP and IBM? Of course, this is supposing that CNAs would be available for HP and IBM blades, but I’m sure that this is something Cisco could have helped guarantee. This route would have broadened the market for FCoE and the unified fabric and simultaneously establishing Cisco as the FCoE leader (as if they weren’t already). Then, when really game-changing stuff like the SR-IOV-enabled adapters like “Palo” were available, Cisco could have taken the leap into the compute space and played the unified management card. That seems like a less risky approach to me. But hey, what do I know?
Tags: Cisco, FCoE, Hardware, HP, IBM, Networking, Sun, UCS, Virtualization
-
Scott,
All of this hand wringing about FCoE takes me back to 1999 when Cisco was talking about a laughable, unsecured, organizationally and politically challenged idea called “Voice over IP”.Cheers,
Brad -
I’m questioned Chris Evan’s contention that FCoE is more expensive than current iSCSI/FC implementations, but it’s really not that expensive when you factor in the reduction of traditional ethernet switches and server Nics. I suppose if you only look at the storage fabric, then he’s probably right.
Our data center team ran the numbers and CNAs and Nexus switches actually come in cheaper than comparable FC HBAs, quad port NICs, FC Switches and Ethernet switches. I’m looking forward to working with this gear and it’s new capabilities. Also looking forward to tackling the problems it creates as well - security issues definitely come to mind.
-
Just use iSCSI and voila! unified fabric on any blade center you choose. FCoE isn’t VoIP. VoIP uses the exsitng stack and gear, FCoE just uses the base medium. iSCSI is the far better comparison to VoIP. Cisco wants you to use FCoE so they can sell you new stuff that you don’t need.
-
Nate,
Cisco sell’s switches, not storage protocols. FCoE, iSCSI, and NAS all use Ethernet, and Cisco sells Ethernet switches. At the end of the day Cisco doesn’t really care which storage protocol you prefer. It just so happens most Enterprise mission critical applications use FC, so for these environments FCoE makes for a nice transition to a unified fabric.My larger point in comparing FCoE to VoIP was that back in 1999 the negativity and hand wringing was all the same. Now 10 years later VoIP is the de facto installation and Cisco is #1 in Enterprise Telephony. There is a track record of success here that should not be dismissed.
-
Brad, FCoE doesn’t just run on any switch, you need a switch that supports it since it isn’t running on the TCP/IP stack. While you can run iSCSI on any switch because it runs on TCP/IP. So no Cisco doesn’t sell protocols, but they do push the ones that will force you to buy new gear which accomplishes their goal of selling switches. It wasn’t like Cisco pushed VoIP for the beauty of that protocol either. VoIP installs meant more network was needed, new switches that would support PoE, QoS, etc. were needed, and they got to sell callmanagers too.
-
In my oppinon we have come upon the junction point of FCoE because of two critical paths..
1.) Network attached storage back in the day (circa 1994?) was not fast enough nor reliable enough FCP really began taking traction and replacing campus wide storage networks. This began the segmentation of storage networks and traditional ethernet networks.
2.) iSCSI has been discussed (don’t remember the timeline here) and then trusted for low cost consolidation of storage over existing ethernet infrastructure but because performance was not up to the speeds of FCP and a Fiber Channel switching infrastructure it was reserved for low priority enterprise application.
Now what do you think would of happened if iSCSI were to of been as fast or faster than FCP back when it became more mainstream? It would of obviously replaced FCP for that is why FCP replaced the old style network storage when it began.
But the reality is iSCSI is built on TCP/IP and this protocol stack in it’s current state can not compete with FCP over a Fiber Channel switching network..
But instead of reinventing the wheel I think those much smarter than many of us came up with taking what works (in storage FCP) and fixing the problems with iSCSI (retransmission and TCP/IP overhead) and FCoE was created.
If you look back in time to when FCP came out it was quite expensive.. this is because it was being sold as a performance product not a cost savings product.. and iSCSI was sold as a cost savings product not a performance product..
Now if those developing ethernet technologies that can handle FCoE (ahem Cisco) were smart they would combine pricing ideology to take into account cost savings AND performance.. if it is cheaper to deploy today than FCP was to deploy back in the past then eventually it will take off and we’ll all be on FCoE in the future..
(Security implications are put aside.. Converged network and whatever security problems they may create also need fixed but I think this needs to be apart of the overall design)
-
Andy, I disagree that FC holds some great performance mark over iSCSI. The blather of worry about TCP/IP overhead has been the battle cry of FC pushers from the very beginning, but in practice such overhead does not cause the claimed impact. iSCSI can perform just as well, and in some instances better. The reality is iSCSI ontop of the TCP/IP stack can absolutely compete with FC. iSCSI can use the same 10Gb pipe, and if you are really worried about overhead can use TOEs or HBAs just like FC to handle that. At a lower cost per port you can also feed more links into the storage network significantly overcoming any perceived loss to overhead. iSCSI become even betetr when you throw away the archaic practice of the monolithic SAN and look at clustered virtualized SAN solutions like the Equallogic solution.
-
Nate,
While, yes, a unified fabric requires a “new” switch, it isn’t “stuff you don’t need”, quite the contrary.What you “need” is connectivity to storage, and connectivity to IP.
How would you do that with FC? You would have that server connecting to 4 different switches, (2) FC, and (2) Eth.
How would you do that in iSCSI? You would have that server connecting to 4 different switches, (2) Eth, and (2) Eth.Now lets look at a unified fabric with Nexus.
Unified fabric with FC? You would have that server connecting to 2 different switches, (2) Nexus.
Unified fabric with iSCSI? You would have that server connecting to 2 different switches, (2) Nexus.Looks to me like a unified fabric requires less for what I “need”, not more?
-
So in essence Cisco is offering a “unified” fabric for commodity technology (ethernet/intel servers), as well as “new” non-commodity technology (FCoE), which accomplishes I/O consolidation and a single management infrastructe for storage and data center management. That’s neat but how long will it take for HP/IBM/SUN to come up with a similiar management platform? UCS manager is the compelling factor here. Convergence use to refer to V/V/D which is a reality, but FCoE only converges network pipes: loss-less ethernet is enough to scare anyone who has worked in Storage and FC for a long time. It will need to be proven, but I agree virtualized Data Centers across disperate geographies is a compelling software play. It’s the future no doubt, and all players will be diving head long, Cisco just knows how to execute a lot better at giving away the cow but keeping the milk under patent.
Site Sponsors
9 comments
Comments feed for this article
Trackback link: http://blog.scottlowe.org/2009/04/03/a-collection-of-viewpoints-on-cisco-ucs/trackback/