Thu 14 Feb 2008
The Question: Server Virtualization’s Impact on Storage
Posted by John under Storage and Data Management , VirtualizationTaylor Allis asked this question on his most recent blog post: “What is server virtualization’s impact on Storage?” Here’s my opinion. But I’m interested in yours, too.
First, I think storage comes out of the server and into a shared pool. Some might say that’s a book-of-duh comment, but given the enormous storage capacity you can put inside a server today, why would anyone need to go external? Here’s the reasoning. Server workload, virtual or not, is relatively independent of the storage workload. By that I mean, running out of server resources to support an application has no implicit or explicit relationship to running out of storage resources (capacity or performance) to support that application. If you need to move a virtual server from one physical server to another, because the physical server is running out of head room, there’s no explicit reason I should also have to move the data. There are some impediments, like unwanted down time, to moving data out of a server and into a shared pool, but one of our clients, StorMagic, has pretty much solved that problem with their non-disruptive data migration capabilities.
Second, I think server virtualization drives the need for end-to-end server and storage reporting and monitoring tools. When you’ve got virtualized servers and shared, networked storage supporting production applications, how can you tell if the degraded performance that application owners are experiencing is the result of CPU resources, I/O issues, or storage capacity and performance issues? How can you avoid performance issues altogether? How can you decide which applications you can safely put on virtual servers and shared storage and still meet service level agreements? Another client of ours, Tek-Tools, has pretty much figured that one out with their Profiler for VMware module.
Other implications for storage include a need for higher reliability, availability, and more scalable performance from the storage system. That’s in response to the more-eggs-in-one-basket concern when multiple applications share a single storage pool.
OK, time for a dialogue - or blogalogue. What are your thoughts?
February 14th, 2008 at 12:04 pm
A couple of thoughts come to mind.
First, in my opinion, virtualization or abstraction, like entropy, grows. I don’t recall any instance in my career of a layer of abstraction being removed from a solution, whether that be in storage, processing, communication protocol or software design.
Second, virtualization exists for two reasons, being 1) to simplify aspects of system usage, at least from the perspective of a subset of the system users, and 2) because “integration” happens. The first is perhaps obvious, but the second deserves a little elaboration. I have this file folder on my titled “What to do with all that annoying excess storage capacity” for example. I don’t open it much these days, but it does serve to remind me of the disc industry’s continued fascination with areal density, and how the mismatch in the pace of different technology trajectories creates problems that are often addressed by, you guessed it, additional layers of virtualization or abstraction. I’m about to pen another folder with “What to do with all that annoying excess CPU capacity”.
Of course virtualization comes at a price, being system complexity. The distance grows between your fingertips on the keyboard, and the flux reversal on magnetic media where your data is persisted. Distance here is measured in the number of layers of abstraction, virtualization, APIs, nested protocol, encryption, encoding, replication, migration, …, etc. It will continue to grow, and it continues to provide rich opportunity for system and storage management utilities.
February 14th, 2008 at 1:18 pm
Bob, You nailed it. Doing root-cause analysis on performance problems gets tougher when we go through all those abstraction layers. This story on TechTarget shows how one customer used Tek-Tools to identify and kill a run away process. He would have had a tough time finding it without their monitoring utility.
February 15th, 2008 at 9:30 am
John, I agree - separating physical servers from physical storage is definitely removing limitations. I posted just this week on Dell’s newest Equallogic prodcut targeted squarely at supporting growing storage needs for virtualized servers.
I don’t agree with Bob. From where I sit, storage companies are scrambling to meet insatiable demand with better aerial density and higher capacity drives.
February 15th, 2008 at 10:52 am
Hey Pete,
I should let Bob respond, but I think the point that Bob was making is in part the same as yours. He’s saying that we used to have excess capacity, but now we do have challenges meeting capacity requirements. But he’s also saying that other dimensions of storage requirements are not keeping pace with capacity growth rates, at least at the drive level. Things like throughput, seek times, availability, reliability, and the second order effects, like RAID-rebuild time. That’s where “another layer of abstraction” comes in.
OK, let me stop talking for Bob…
Bob, are you reading? What are your thoughts? Or anyone else, for that matter.
John
February 15th, 2008 at 5:41 pm
John (and Bob!) - excellent point. As we virtualize more and more - management, monitoring and reporting tools become critical.
To your list of examples I’ll add Sun xVM Ops Center (http://www.sun.com/xvm). I admit, when Sun announced xVM I focused more on the server - the ability to run Windows, Linux, Solaris and import/export VMware and Microsoft VMs on a single system is pretty cool. Sun billed its xVM Ops Center just as much as its xVM Server - this line of questioning shows me now why. It can manage and report on physical and virtual domains.
So, great insight and I also got to throw in a plug for my company to boot!
- Taylor
February 15th, 2008 at 6:08 pm
Taylor - Tell me if I’m wrong, but I think Sun xVM Ops Center is more like Onaro with its focus on configuration and change management, asset reporting, right?
I was thinking more along the lines of event, performance, and capacity monitoring and reporting, threshholding, forecasting, and alerting.
While they are different, you are correct. These kinds of tools provide huge value.
- John
February 15th, 2008 at 6:20 pm
Taylor - One more comment, I view Sun xVM Ops Center as complementary to, and not competitive with things like Tek-Tools. Do you agree?
February 19th, 2008 at 7:46 pm
John - you are correct, I wanted to sync with our xVM Ops folks first so I don’t put out any mis-information.
I won’t share future plans, but Sun xVM Ops Center 1.0 provides functionality for patch management and bare-metal provisioning of servers only. Per the xVM folks at Sun, it’s like VMWare VirtualCenter + provisioning in opsware + patch management from shavlink.
So yes, although I don’t know Tek-Tools too well, looking at their site they are not competitive - looks like a good tool that spans servers and storage. I’ll have to take a closer look at them…
I’ve been at Sun just a couple years after the STK acquisition and I am already mixing up server and storage management
February 19th, 2008 at 8:45 pm
Taylor,
Thanks for the feedback. That’s what I thought, but it’s nice to get field validation.
And given products like Sun’s Thumper, it’s easy to see why you might mix up server and storage management, since you’ve already begun to converge some of your servers with your storage. Or should I say some of your storage with your servers? I’m so confused. Regardless of servers or storage, it’s still a lot of terabytes to manage.
- John