This is FrankDenneman's Typepad Profile.
Join Typepad and start following FrankDenneman's activity
Join Now!
Already a member? Sign In
FrankDenneman
Recent Activity
Disclaimer: Frank Denneman– PernixData Employee That’s a lengthy article Chad, luckily you are enjoying your holiday and are able to get some rest after writing this one. All kidding aside, Kernel modules is the way to go. And regardless if you are VMware itself or a third party vendor, you can write software code that fits nicely in the kernel and scale together with the kernel. PernixData has done this. Granted we have a collection of extreme gifted engineers that understand the kernel code like no other, but we proved it could be done. VMware reviewed and tested our code and VMware certified the FVP software. To quote you: This is the very basic reason why ScaleIO has a kernel-loadable module for Linux kernels (used with KVM, Xen) and Windows (used with Hyper-V), but not vSphere (where it requires a virtual appliance model – with the corresponding “convoluted” IO path). I’m curious if writing kernel extension modules is not the primary reason for performance, why is the Scale IO team investing time and energy in writing kernel code for Linux and Windows, but not for VMware. Why not use a common, transportable code for all platform? Open formats such as virtual machines can run on many different platforms and would reduce development greatly. Why, because many people and I other believes that kernel code is the only way to provide scaleable performance, reduction of resource management and operational simplicity. Storage kernels are purposely build to provide storage functionality to a variety and multiplicity of virtual machines. When extending the kernel modules, your code scales inherently with the hypervisor. Sitting at a lower layer allows you to play well with others. This is not the case with VM centric storage solutions. Are Hypervisors build from the ground up to “offload” their functionality to a guest world? Talk about a convoluted path! Introducing guest worlds that are responsible for major part natively handled by the kernel. These storage vms become depended on other schedulers sitting lower in the kernel, interacting with each other. And vice versa, if the storage command cannot be executed or completed, the CPU scheduler waits for the commands to complete before it can schedule the storage VM. See the problem? With a couple of VMs and a storage VM it might not be as problematic as I describe, but what if your environment is running massive amounts of VMs? Context switching is one, allowing a guest world to take responsibility for the majority of performance is something completely different. In my opinion, hypervisors where never designed to have a virtual machine assume the role of a storage scheduler. With introducing service VM, virtual appliance (give it any other fancy name) you are bubbling up the responsibility where it has no place. Exposing it to other schedulers who do not understand the importance of that particular virtual machine to the rest of the virtual infrastructure. You can create a lot of catch-22 situations if not designed correctly. Remember, VMware is continuously improving their kernel code to have improve their internal structures. This is complex stuff. Which alludes to the following problem, management overhead. There is a virtual machine, fully exposed between the rest of the virtual machines. You need to manage it from a resource management perspective, remember you can set a CPU reservation but that does not mean it can kick off resident and active threads on the CPUs. That’s the responsibility of the kernel and then you have the problem of security. In my days as an architect I’ve seen some “non-standard” environments where junior admins had full control. You don’t want to have the risk of accidental shutdowns on that layer. And if we talk about setting reservations, which other clustering service are you impacting? Think HA, think DRS, think convoluted design here. Harden, ensure, encapsulate your basic compute and storage services, don’t leave them exposed and that’s what you are doing with a virtual machine running storage code. And we can talk about scalability from east to west, horizontal throughout the cluster, but if I start, my comment might be as long as your article.
FrankDenneman is now following The Typepad Team
Mar 11, 2014