#memeconnect #fs
Virtualization workloads in general put pressure on the I/O system. Typically they are more "bursty" than non-virtualized systems because the hypervisor adds a variable overhead. For desktop virtualization in particular, I/O is even more intense, with I/O storms early in the morning, at lunchtime, and late in the afternoon. Should a patch need to be applied, it is likely targeted at a high percentage of the user population, leading to another I/O storm; similarly with any disruption, the I/O sub-system will be under substantial strain.
The traditional method of ameliorating I/O storms is to use an array with RAM (volatile) cache. This works well for reads, especially if there is good locality of reference. The array has to secure writes using a battery backup system, as the RAM is volatile. RAM is expensive, limited in size, and requires complex and expensive battery backup mechanisms.
Flash is persistent (non-volatile). It is much cheaper than RAM, and needs no battery. Because of the speed of writing to flash memory, the RAM buffers in the storage controller can be powered by simple capacitance for the time required to write the data out to flash.
The traditional method of implementing flash is to use it as a Solid State Drive (SSD). In early implementations, an entire volume needed to be put on SSD, causing angst amongst users due to the high cost of flash. Now most storage vendors have the ability to take part of the volume (sub volume) and place it on SSD. The SSD acts as a "Tier 0," and can reduce I/O times to between 1-3 milliseconds. Most vendors have software that runs in the background and helps storage administrators understand which volumes or parts of volumes are consistently highly accessed, and will automatically run batch jobs at non-critical times to move the data to the correct tier. This system works consistently for "well-mannered" workloads. However, SSDs do not help much with "ill-mannered" workloads such as virtualized environments: it is almost impossible to predict ahead of time where the I/O storm will come from, and which volumes will be affected.
Wikibon has discussed flash architectures in depth. There are two major architectures that can be used to assist I/O:
- FOS - Flash-on-Server,
- FOSC - Flash-on-Storage-Controller.
FOS is more useful for speeding up databases, filesystems and OS/Hypervisor operations. FOSC is more useful for a shared I/O environment and is the best architecture for a highly shared environment found in desktop virtualization.
FalconStor has just announced the FalconStor® Network Storage Server (NSS) SAN Accelerator for VMware View™, which uses a FOSC architecture to greatly accelerate VMware's desktop virtualization. The FlashCache comprises about 3% of the total storage in size, and is dynamically used to assist reads and writes. VWware View has improved its IO organization, and FalconStor is able to automate the optimization of the flash-cache setup. In addition to the flash-cache, the FalconStor product offers multi-tier data protection by performing backup and recovery for the entire virtual desktop environment and for each virtual desktop. It also enables self-service file recovery for individual virtual desktop users.
The overall cost of storage is reduced by putting the low-cost 2TB SATA drives behind the flash-cache. FalconStor claims that the average cost of providing storage and protection for a virtual desktop is about $35 in CAPEX.
Action Item: Virtual desktop infrastructure (VDI) implementations have struggled to gain wide commercial acceptance due to a number of factors, including I/O challenges. FalconStor's flash-on-storage-controller (FOSC) implementation directly solves the problem of I/O storms and should be on the storage shortlist for any desktop virtualization (VMware View or Citrix) environment.
Footnotes:
