First, let me explain exactly what the I/O Blender Effect is, and why it causes a problem in virtualized environments such as those from VMware or Microsoft’s Hyper-V.
This is typically what storage I/O traffic would look like when everything is working well. You have the least number of storage I/O packets, each carrying a large payload of data down to the storage. Because the data is arriving in large chunks at a time, the storage controller has the opportunity to create large stripes across its media, using the least number of storage-level operations before being able to acknowledge that the write has been successful.
Unfortunately, all too often the Windows Write Driver is forced to split data that it’s writing into many more, much smaller I/O packets. These split I/O situations cause data to be transferred far less efficiently, and this adds overhead to each write and subsequent read. Now that the storage controller is only receiving data in much smaller chunks at a time, it can only create much smaller stripes across its media, meaning many more storage operations are required to process each gigabyte of storage I/O traffic.
This is not only true when writing data, but also if you need to read that data back at some later time.
But what does this really mean in real-world terms?
It means that an average gigabyte of storage I/O traffic that should take perhaps 2,000 or 3,000 storage I/O packets to complete, is now taking 30,000, or 40,000 storage I/O packets instead. The data transfer has been split into many more, much smaller, fractured I/O packets. Each storage I/O operation that has to be generated takes a measurable amount of time and system resource to process, and so this is bad for performance! It will cause your workloads to run slower than they should, and this will worsen over time unless you perform some time and resource-costly maintenance.
So, what about the I/O Blender Effect?
Well, the I/O Blender Effect can amplify the performance penalty (or Windows I/O Performance Tax) in a virtualized environment. Here’s how it works…
As the small, fractured I/O traffic from several virtual machines passes through the physical host hypervisor (Hyper-V server or VMware ESX server), the hypervisor acts like a blender. It mixes these I/O streams, which causes a randomization of the storage I/O packets, before sending out what is now a chaotic mess of small, fractured and now very random I/O streams out to the storage controller.
It doesn’t matter what type of storage you have on the back-end. It could be direct attached disks in the physical host machine, or a Storage Area Network (SAN), this type of storage I/O profile couldn’t be less storage-friendly.
The storage is now only receiving data in small chunks at a time, and won’t understand the relationship between the packets, so it now only has the opportunity to create very small stripes across its media, and that unfortunately means many more storage operations are required before it can send an acknowledgement of the data transfer back up to the Windows operating system that originated it.
How can RAM caching alleviate the problem?
Firstly, to be truly effective the RAM caching needs to be done at the Windows operating system layer. This provides the shortest I/O path for read I/O requests that can be satisfied from server-side RAM, provisioned to each virtual machine. By satisfying as many “Hot Reads” from RAM as possible, you now have a situation where not only are those read requests being satisfied faster, but those requests are now not having to go out to storage. That means less storage I/O packets for the hypervisor to blend.
Furthermore, the DymaxIO™ fast data performance software from Condusiv Technologies also employs a patented technology called IntelliWrite®. This intelligently helps the Windows Write Driver make better choices when writing data out to disk, which avoids many of the split I/O situations that would then be made worse by the I/O Blender Effect. You now get back to that ideal situation of healthy I/O; large, sequential writes and reads.
Is RAM caching a disruptive solution?
No! Not at all, if done properly.
Condusiv’s DymaxIO software for virtualized environments is completely non-disruptive to live, running workloads such as SQL Servers, Microsoft Dynamics, Business Information (BI) solutions such as IBM Cognos, or other important workloads such as SAP, Oracle and the such.
In fact, all you need to do to test this for yourself is download a free 30-day trialware copy. For best results, install DymaxIO on ALL VMs on a single host. For evaluation on 10+ systems/VMs, we recommend you contact sales to speak with a Solution Specialist to get set up with the management console for faster deployment.
Just install it! There are no reboots required, and it will start working in just a couple of minutes.