This week was one of those “in spite of the best laid plans of mice and men” weeks.
One of the engineers I’ve been working with to help me get a better understanding for what the performance and scalability of a scale-up environment when being used to run Red Hat Virtualization (Xen) as well as the Kernel Virtual Machine (KVM) is changing roles within the company. Good for him!
Unfortunately, this means that I’ll have to do some of the data-collection work on my own. On top of my daily responsibilities. So, we met this week to try and figure out how we could compress what’s been, thus far, a multi-month effort into something a bit more schedule friendly for the both of us. And I think we’ve got a reasonable plan, all things considered.
One of the achilles heels of almost any of the virtualization solutions, thus far, has been the IO throughput (and latency) for disk related IO operations. If you look at testing done by various vendors and the Open Source community at large, the throughput has been either “not great” or inconsistent. The “not great” element of this hasn’t, historically, really been that huge of a deal for customers, since they seem to have planned around it by not including disk IO intensive workloads into their consolidation/virtualization plans.
However, more and more customers are looking to virtualize everything running on their server platforms in an effort to save power, cooling and management costs. As a result, the “not great” performance behavior has become enough of an issue that all of the virtualization vendors now support (or will in the near future), minimally, para-virtualized IO drivers and/or other performance optimizations.
Consequently, they also appear to be pushing Linux (and Windows) further “back” into their data centers and looking to use the two for more and more critical tasks, even in a virtualized/consolidated context. An on-going problem for myself and our customers has been the amount of fact-based information available in terms of how to best configure these environments to optimize IO performance or to help customers understand the actual limitations and benefits of the various IO options in a virtualized environment.
Also, there’s very little in terms of stated best practices for using things like raw devices, volume manager backed devices, file systems or file containers for the various types of workloads. So, I was hoping we’d be able to provide some of that in a presentation at a large conference this summer. And my original plan was that I’d only be the consumer of the data, not the creator of it. Thus the “best laid plans of mice and men” statement early on.
So, for the next couple of weeks, I’ll be trying to collect whatever the engineer is unable to collect. Then I’ll have to graph it, ‘gussy it up’ (with pretty colors), add some configuration recommendations and bring it all with me to the sessions I have planned for the conference.
