Cisco and HP Square Off In Server Land

We all enjoy it when vendors face off on key technologies -- like next-generation server architectures. 

Not only is it fun to watch, but intense competitive pressures are good for customers and good for the industry.  And we've only seen the first few salvos in what should prove to be a sustained battle for data center supremacy

Now, my biases should be clear (rooting for Cisco!) -- but, with the latest round of HP announcements, you can begin to see some very distinct differences in architectural thinking between the two companies.

Two Views Of Management

Now, keep in mind that I'm reading the same public materials that you are, but one thing that jumped out at me was separate views regarding management at scale.  HP seems to have one view, Cisco another.

Cisco is promoting the view that the fundamental paradigm of resource management needs to change.  Rather than thinking about discrete resource management disciplines (server, network, storage, etc.), we'll all be far better off if we start thinking of every resource as a network service.

Now, if you've built your career on a different management paradigm, you may have an adverse reaction to this line of thinking, but it has a certain persuasiveness to it.  The NOC is turning into a busy place indeed -- it's the first call when there's a service delivery problem, or there's a security problem, etc.

Why not extend this model to provisioning of resources?  While you're provisioning connectivity between user and application, application and application, application and storage -- why not provision some compute, some storage and an applicationt template as well?

Another way of approaching this argument is to acknowledge that converged IT operations is inevitable -- but what discipline should be the core?  Hard to dispute that the network people are best positioned to extend what they do into new areas.

And, finally, as we start thinking about private clouds, dynamically shifting workloads, federation, etc. -- it's hard to describe resources as anything other than a network service, if you think about it.

By comparison, HP is not attempting to debate the underlying resource management model.  Servers are servers, storage is storage, network is network, etc.  Their argument is that by creating an even-higher-level abstraction (templates), speed and scale of management can be achieved.

My counter to this is simple -- templated workflows are table stakes in any next-gen management model -- no new thinking here.  The underlying model hasn't changed to allow better integration of core workflows. 

I keep thinking of attempting to put nice wallpaper over something considerably less pretty.

Two Views Of Storage

Cisco has elected to partner with best-of-breed storage providers for UCS (think EMC!).  I think they realized that storage and related information management disciplines are core to next-gen data center environments, and that it made sense to partner with industry leaders.

Smart strategic move, IMHO.

HP hasn't really figured out storage for these environments, IMHO.  As an example, I'd point to HP's stated approach of 'blading everything' -- including storage.  This is what happens when server guys get involved with storage -- everything has to be a server, even things that are better not being a server -- like storage.

If I followed the announcement material correctly, HP is now offering modest-capacity "storage blades", and repurposing LeftHand's software to cluster multiple images to create a "internal server SAN" or somesuch.

Definitely clever.  But is it useful?

I would argue that -- not only is this a sub-optimal approach to storage design -- it will severely limit how and where the HP blade farm can be used to support real-world workloads. 

Bad strategic move, IMHO.

I was quite intrigued with LH's approach a while back, but -- the more I thought about it -- I realized it had some pretty severe limitations.  The larger your environment got, the more apparent these limitations became.

First, you might as well forget demanding OLTP.  There's no support for non-volatile cache (either DRAM or flash) using this approach, so every write has to go safely to disk (actually, two disks).  Right away, an entire chunk of the workload spectrum isn't up for consideration.

Second, this approach is very wasteful in storage capacity.  Unless you don't care about losing access to your data due to server failure, each byte has to be written on two separate blades.  That's a 100% penalty on top of any RAID processing that's local to the blade.  Yuch.

Third, while it's true you can share storage within a blade rack, there's no sharing of storage across blade racks.  That is, unless you decide to turn your HP blade rack into an NFS server, but that's another can of worms.

Fourth, there's a long list of advanced storage functionality found in most enterprise arrays that just isn't available with this approach.  Hope you didn't want or need any of that.

Two Views Of Networking

A key proposition of Cisco's vision is unified data center networking -- the converged fabric.  Regardless how you might feel about things like FCoE, there is no arguing that fewer, converged network pipes are better than many differentiated ones in terms of economics, operations, power and cooling, rack space, etc. etc. etc.

HP doesn't have much to say about this important development in data center networks.  And, for really demanding workloads, trying to run everything through IP-based protocols iSCSI or NFS just won't cut it.  And there's no amount of hand-waving that will convince large enterprises of this.

Re-packaging Vs. Re-engineering

If I had to share one important dynamic in all of this, it'd be my perception that HP is doing a lot of re-packaging to meet Cisco's onslaught.

By comparison, we're seeing Cisco do major re-engineering around how we think about data center architectures: unified computing, virtualization by default, unified networking, converged management models, etc.

From where I sit, the differences couldn't be clearer :-)

Comments

[John F.]

Well, I don't agree on every point you make, but I can agree on one thing; In the Cisco-HP Summo wrestling match, the competitors are clearly squaring off...

John

[nate]

Does Cisco prefer NetApp at the moment?

At least two local virtualization events in the Seattle area here recently have been Cisco+NetApp+Vmware+(local vmware consulting company). Though that was before the V-MAX was announced.

I've read that it's possibly because NetApp is the only big guy supporting/shipping(?) FCoE right now though I haven't tried to confirm it myself. Or could it be vmware just trying to show itself as being more open by not rigorously reminding people that it's a division of EMC.

One of the local vmware consulting shops have been pushing NetApp (VMware over NFS) for quite a while and their biggest sales point is that it's easier, and that you don't have SCSI reservation/locking issues, though they don't tell the whole story, that there can be locking issues on NFS as well as this pretty big issue showed:
http://blogs.storagemonkeys.com/index.php/2008/10/important-note-regarding-vmware-over-nfs/

There seems to be a pretty big following of vmware over NFS, wonder how long it will last?

I was expecting some sort of revamp in VMFS with the vSphere announcement, if it's there they didn't make a lot of noise about it.

[Peter C.]

Hmmm.... "blading everything" is what happens when 'server' guys get involved in storage - everything has to be a server.

So...

What happens when network guys get involved in Data Centers? Oh wait...that's a good idea.

- Peter

[Chuck Hollis]

Hi Nate -- you bring up some good questions.

I can categorically state that Cisco does not "prefer NetApp" at the moment. I bet the NetApp people really wish this was the case, but it ain't so.

Native FCoE into the array is nice marketing bling, but the reality is that most of FCoE's benefits accrue on the server side, not the storage side. And all the Cisco Nexus products support both FC and FCoE.

I also want to point out that the FCoE standard isn't entirely finalized yet -- a minor but important point to some.

The real issue is -- where does virtualization go from here?

Our view is that as it evolves from test+dev and smaller applications into big, hairy workloads running in large clusters, customers will prefer the same storage infrastructure for VMware that they do for their most demanding applications.

And, without being a technical bigot, the answer to that --- far and away - are block-oriented arrays with real FC SANs in front of them.

I'm not going to argue pros and cons, just the market reality of enterprise customers around the globe. Don't believe me, go check the data from IDC, Gartner, Forrestor, et. al. It's not even *close*.

Frankly, we're rather agnostic to the whole storage protocol discussion. We're pretty good at pointing out the pros and cons of each approach, and we don't have a religious bent one way or another.

Many customers in your category are hedging their bets by buying something like the Celerra unified storage that do iSCSI, NAS and real-deal FC SANs from the same storage array.

Different parts of your VMware environment might want different protocols. What you do for test+dev may not be what you do for your most demanding applications, hence the all-in-one approach.

The other thing you need to keep in mind is that this sounds like a partner-led event. The partner gets to choose who shows up at their event, and if they're in love with NetApp, you're gonna see a lot of NetApp love.

Conversely, go to another event sponsored by an EMC partner, and you're going to see a lot of EMC love.

That's the nature of the beast, isn't it?

[Chuck Hollis]

Hi Peter

Opinions vary on Cisco's UCS offering, but our perspective is that we see some really fresh thinking here, especially in next-gen data centers that are entirely virtualized, use converged fabrics, and managed in a network-centric fashion.

Cisco will have to prove themselves in front of customers (like all vendors do!), but -- based on what we've seen -- I'm not going to bet against them.

Thanks for writing ...

-- Chuck

[John F.]

Hi Chuck,

I'll take the opposing view and state that EMC wishes it were not so. We can agree to disagree for now, but in the end it's not our choice to make. As you well know, it's the customer that ultimately decides, and that decision is based on the preceived value each vendor or combination of vendors brings to each customer's unique situation.

John F.

[Chuck Hollis]

John, I'm merely stating a fact -- Cisco does not "prefer" NetApp.

If you have factual evidence to the contrary, please share it.

And fluffy marketing videos don't count !

You're right -- customers decide. We both agree on that.

-- Chuck

[John F.]

Oh come on Chuck,

Cisco has no preference, we both know that. May what the customer preceives as the best vendor win.

Best of Luck to you, and congratulations on your launch.

John

[Frank L.]

Hi Chuck,

I would agree with you. Anyone who seriously thinks objectively not just about the current state of the data center, but also the near future where provisioning and workloads will shift dynamically between not only servers, but between data centers, and even organizations, cannot deny that the network needs to be at the heart.

In an abstract way, I liken it to other provisioning infrastructures such as the phone company, cable company, power, water, etc. None of these infrastructures are managed in the home where they are consumed. They are managed centrally. Given enough time I can see where the data center will be forced to move to this model as well.

Further evidence can be found just by looking at Cisco's UCS and HP's Matrix solutions. With the exception of HP's storage (which to your point doesn't make much sense in a cloud environment, indeed even a dynamic data center environment), the two offer almost all of the same capabilities. Yet HP can only do this by adding layer upon layer upon layer of management, whereas Cisco can accomplish this from the network side simply with some fancy firmware. It is able to run much leaner, with far less overhead and complexity. When I see this, it seems clear that the natural place for the intelligence to live is the network.

This is not to say that Cisco doesn't have a lot of proving to do, or that this isn't going to be an extremely tough battle for them. Indeed, it might not even be Cisco that wins in the long run. I just think that over time it will be hard to keep the intelligence from migrating to the network.

Just MHO.

Frank

[Nigel]

Hi Chuck,

Sorry but I couldnt resist..... Apparently Dave Donatelli doesn't think the Cisco approach is best and voted with his feet :-D

Nigel

[Chuck Hollis]

Hi Nigel -- couldn't resist, could you?

-- Chuck

[John Spiers]

Chuck,

I would like to make a few corrections to your comments about LeftHand-HP solutions:

“First, you might as well forget demanding OLTP. There's no support for non-volatile cache (either DRAM or flash) using this approach, so every write has to go safely to disk (actually, two disks). Right away, an entire chunk of the workload spectrum isn't up for consideration.”

Not true. LeftHand’s software supports battery backed cache in its storage systems and with its Virtual SAN Appliance.

“Second, this approach is very wasteful in storage capacity. Unless you don't care about losing access to your data due to server failure, each byte has to be written on two separate blades. That's a 100% penalty on top of any RAID processing that's local to the blade. Yuch.”

Well Chuck, you have it wrong again. There are multiple ways to create redundancy so that you can sustain blade and blade storage failures with RAID 5 or RAID 6 storage efficiencies. And remember, our Thin Provisioning works with remote replication features (unlike EMC), and eliminates snapshot reserve space.

“Third, while it's true you can share storage within a blade rack, there's no sharing of storage across blade racks. That is, unless you decide to turn your HP blade rack into an NFS server, but that's another can of worms.”

Not true. Blade racks can be connected to each other and LeftHand storage can span multiple blade racks.

Conclusion:
EMC is feeling the pain being tied to hardware.

By the way, I’m pleased to announce that David Donatelli, the former president of the EMC Storage Division, responsible for the EMC storage platforms and related software businesses, has decided to join HP as the executive vice president of Enterprise Servers, Storage and Networking.

John Spiers