EMC can't help themselves. Given what appears to be a new corporate mandate to deny competitive threats in their massive propaganda machine, they look pretty stupid when one of those threats involves their new BFF Cisco and their trophy-acquisition raison d'etre,VMware.
Yesterday, Netapp, Cisco and VMware made a planned, well-orchestrated announcement of their secure, multi-tenancy architecture. Trust me - everyone in the industry knew it was coming and it was the main reason we chose to time our vSPhere and vCenter Server announcement for Monday this week. Chuck Hollis, EMC's StorageMonkeys poll winner, responded with an incredibly ignorant post that does not even mention the companies involved, nor does it link to any of the numerous online postings discussing it. For as many words as La Bombast put into this blog entry, you would think he would have at least mentioned Cisco in his discussion on network security. Granted, this announcement puts EMC in a compromised position, seeing as how their most strategic partners have chosen to develop an advancement in data center technology with one of their most dangerous competitors, Netapp. Nonetheless, EMC's inability to deal with the reality of it underscores the difficulties they have holding an objective, honest and open public discussion.
I like what Netapp, VMware and Cisco have done with their Secure Multi-Tenancy architecture. The ability to segregate and align applications, data and IT resources for management purposes is a very big deal. It is also one of the key concepts in virtualization technology. Sharing resources among multiple applications and users provides powerful economic leverage (doh!) and aligning security and access controls on virtual boundaries is not only desirable - it is essential. Role-based administration is certainly nothing new, and bringing that into the virtual data center is a necessary evolution in the technology's development.
So what about 3PAR? Been there, done that and continue to lead in utility storage infrastructure technologies. 3PAR developed our Virtual Domain technology more than two years ago that brought role-based administration and firewalls to utility storage. It's also why we developed our Cloud-Agile program for utility computing service providers and designed ourCloud-Agile SECURED solution into it. We have done many things over the years that have been ahead of their time and Virtual Domains was one of them. We're happy to see Netapp, Cisco and VMware shine a light on this important technology area. Too bad for EMC that they missed on this one. Guess they have some 'splainin and fudding to do!
Check out our capacity guarantee -
the program EMC doesn't want you to know about.
the register article you point to is somewhat obsolete, though it does point out an important shift(or clarification) in their strategy
from "The actual server hardware is any X86-based server, meaning NetApp is not about to piss off any server hardware vendors by showing a preference for any particular brand."
to
http://www.theregister.co.uk/2010/01/26/cisc0_netapp_vmware/
"The CVN architecture is focussed on implementing heavily virtualised IT systems for private and public cloud deployments, and includes Cisco USC servers - we initially thought it wouldn't"
Their setup involves the new Cisco FCoE switches and FCoE servers but they seem to be relying on iSCSI and NFS rather than FC or FCoE. Which makes me think their customers will be wasting a ton of $$ for this extra hardware(and complexity) that they won't need.
Also it appears that NetApp datamotion only supports NFS and iSCSI, so that would explain why this solution doesn't advertise fiberchannel.
Not that I have an issue with NFS or iSCSI but just think they could go with a lower cost networking setup based on regular 10GbE ethernet then trying to hype the FCoE stuff even further. I would think that HP c Class blades with virtualconnect would be a much better fit given they are pure ethernet.
Posted by: nate | January 27, 2010 at 10:06 AM
Yes, the age of the link was intentional - it shouldn't have been a surprise to anybody and it was publicly known. I haven't looked at the networking details, but I wouldn't be surprised that it uses standard virtual LAN technology, which means Ethernet as opposed to FC and FCoE. Why FCoE would be necessary is interesting - is it a matter of will or is there a real need for it?
Posted by: marc farley | January 27, 2010 at 10:24 AM
Yeah it's using the ethernet-only part of FCoE I'm sure but the hardware they are using of course there's extra cost for a FCoE adapter vs normal ethernet same for switches, whether or not you actually use the technology.
Posted by: nate | January 27, 2010 at 10:45 AM
Hi Marc -- thanks for your thoughtful and insightful commentary on my post. You always bring a certain "something" to the discussion, especially when it's as important as security.
All kidding aside, security is not a joking matter for some. Bad things tend to happen when you think something is secure, and it's not.
At a different level, I think the work that NetApp did -- while not unique -- shows how you can separate multiple tenants in a virtualized environment. That's good.
It does nothing to show how tenants are protected from the service provider.
A nice start, but -- to anyone who has more than a casual background in security -- this can hardly be marketed as "secure multitenancy" with a straight face.
I chose three simple questions to illustrate the point. No one -- including you -- has responded.
But there's a lot of hooting and hollering from the monkey cages in the meantime!
-- Chuck
Posted by: Chuck Hollis | January 27, 2010 at 01:19 PM
@nate & @mark - The CVD process requires products to be both validated and shipping for customers. That requirement limits end-to-end FCoE use in the SMT solution due to no northbound FCoE support on UCS. However, the architecture was designed for a simple and easy migration to unified fabric / FCoE once support from all vendors is in place.
Stay tuned...
Posted by: David Klem | January 27, 2010 at 02:17 PM