Storage problems are ‘taking the fun’ out of virtualization. Legacy storage systems can’t keep up with the performance demands of highly random workloads that server virtualization environments generate. Because of this, companies are seeing these deployments make for much lower VM densities than expected – fewer virtual machines on each physical server host. This in turn leads to a lower return on investment (ROI) for the project.
Flash, with its orders of magnitude better IOPS performance than spinning disk has provided the raw material for a solution to this storage problem. But simply installing some SSDs into the environment doesn’t ensure success. How that flash capacity is implemented can greatly impact its effectiveness. PCIe-based solutions are a popular choice because they’re relatively simple to implement and allow this performance upgrade to be put directly where it’s needed, on the PCIe bus next to the host CPU.
PCIe based SSDs typically implement solid state storage on a high performance PCIe card. This allows for the CPU/Application/Hypervisor to have direct access to the high-speed memory-based storage, making it ideal for virtual memory swap pools or as a storage area for performance demanding VMs. They also represent one of the more affordable ways to implement flash since they leverage the existing power supply and chassis of the server they are being installed in. But this same server-side location of flash capacity can cause other issues.
First, the hypervisor has to support the PCIe flash device. Many PCIe flash cards use proprietary drivers which can lead to spotty hypervisor support and limited vetting of the driver for stability.
Second, when the flash capacity is installed in the host server and then allocated to each VM, users often see lower than expected utilization rates. Excess capacity that exists on one VM is ‘held captive’ and can’t be used by other VMs. This is problematic since the VMs that need SSD performance often have rapidly growing data sets or may need extra SSD capacity to cover a temporary spike in demand. The result is reduced VM densities and lower than expected ROI as previously mentioned. It also means that excess SSD capacity has to be bought which, given flash’s premium price, only makes the ROI situation worse.
Finally, since each virtual machine has its own dedicated flash, each VM is essentially assigning itself a local flash disk. This may lead to restrictions with functions like vMotion and storage vMotion that require access to a common storage area, or it can mean these functions are not supported at all.
Without a shared storage area, high availability and fault tolerance can be lost. This high-speed capacity on each host-based flash module becomes a single point of failure and issues of uptime and data availability become a concern. As a result, users are forced to live with this vulnerability or abandon server-side flash for more complex and expensive solutions.
While PCIe flash implementation is an extremely effective way to get flash performance exactly where it’s needed, installing what’s essentially direct attached storage defeats some of the primary benefits of server virtualization, such as simple VM migration and high availability (HA). For these functions, shared storage infrastructures (e.g. a SAN or NAS) have been the standard solution.
OCZ’s VXL Virtual Storage Accelerator, when implemented with the Z-Drive R4 PCIe flash module, can help ‘unleash’ virtualization from the storage problems that have bogged it down. And, it can do so while leveraging the advantages of server-side flash devices.
What is VXL?
VXL is caching, storage acceleration and virtualization software that enables flash capacity to be fully leveraged in the virtual server environment. It provides a server-based solution to the storage performance issues that often plague virtualization projects, without imposing the negative side effects that other PCIe products can bring. Running at the hypervisor level, VXL provides a high-performance cache across all VMs that are resident on that host, based on their needs, monitoring data requests to reduce traffic to and from existing networked storage by up to 90%.
VXL installs as a VM on the host so it doesn’t require any guest agents or drivers. This simplifies deployment since it works with any guest OS that the hypervisor supports, reducing management of multiple caching instances and the maintenance involved with upgrading drivers.
By virtualizing this server-based flash area, VXL enables features like vMotion without affecting its caching function. Other solutions require that caching be disabled before VMs are migrated, resulting in significant loss of application performance. With this shared flash capability, VXL supports data mirroring between PCIe flash devices on different hosts enabling high availability and VMware Fault Tolerance (FT).
Use Case: The SAN-less Data center
VXL treats flash as another virtual resource to be distributed dynamically to VMs internally and externally to the physical server that the flash device is running on. This allows flash capacity to be shared with other hosts in the virtualized cluster, via iSCSI, without the need for a dedicated SAN or NAS, eliminating the complexity and cost of maintaining a traditional networked storage infrastructure altogether.
Use Case: A Performance Boost for an Existing SAN
VXL can also enable PCIe-based SSDs to be used in conjunction with an existing SAN. Using its application optimized caching policies VXL can re-expose existing SAN volumes by caching hot data and redirecting read hits to the flash area. In this way, the IT manager can utilize the PCIe flash by creating new all-flash, highly available volumes or by using the host side flash as a cache to accelerate the performance of existing SAN disk capacity.
VXL also allows the user to dedicate part of the flash resource on the PCIe card for virtualized volumes while using the remaining flash capacity as a cache, thus optimizing the use of this valuable resource. For example, as described below, an IT manager could dedicate part of the flash as a volume to house a tempDB completely on flash while using the rest of the flash to cache only the hot tables from the much larger main DB files.
Use Case: Caching tempDB on Flash
With a dynamic pool of flash, VXL can respond to temporary requirements for high performance capacity. For example, SQL Server will store queries in a tempDB on other available storage, typically spinning disk, when it runs out of RAM capacity. Rather than taking this performance penalty, VXL can redirect tempDB writes to available flash capacity on the host. And it can perform migration of the VM running that SQL application to another server, providing continuous access to that tempDB wherever the VM may reside, on any host in the virtual server cluster.
Use Case: Retaining Log Files on Mirrored Flash Volumes
Log files are critical for recovering production databases and therefore need to be kept in a resilient, highly available storage infrastructure. Without virtualization capabilities server-side flash devices can be a single point of failure and inadequate for mission critical applications. VXL enables mirroring of these essential log files between flash devices on separate host servers, providing needed redundancy in the event of a server failure.
Storage Swiss Take
Server virtualization is creating performance problems that companies are turning to flash-based products to resolve. Server-side solutions, like PCIe flash devices with caching software are a popular choice for boosting performance but these dedicated flash areas can’t be shared between virtualization hosts and sometimes even between VMs on a the same host. This can severely reduce the ROI of a server virtualization project and impact VM availability as well.
OCZ’s VXL Accelerator software addresses this shortcoming of server-side flash, allowing the caching function to be shared among VMs and flash capacity shared between VMware hosts. When paired with the Z-Drive R4 PCIe flash module, it can provide the performance boost that’s needed while maintaining the VM migration and high availability features that have become a requirement for most environments.
OCZ is a client of Storage Switzerland