Virtual storage appliance: How it works and what it doesDate: Oct 02, 2012
A virtual storage appliance is used to create shared storage without the cost of a storage array by pooling direct-attached capacity so that it can be accessed from multiple virtual server hosts. Shared storage is the key to VMware's highest-end features, such as high availability and improved data protection. In this video from a Storage Decisions seminar, storage expert Howard Marks explains the importance of virtual storage appliances, with details on one type of VSA that addresses the I/O blender problem of virtual server environments. Read the transcript below or watch the video.
This morning I said that it was important to have shared storage
for virtualization, but that doesn't necessarily mean a dedicated array from a storage vendor.
In smaller organizations and branch offices, I am a huge fan of a virtual storage appliance [VSA].
… [With a VSA,] a virtual
machine in the host connects to the onboard RAID controller and makes that
storage available via either iSCSI or NFS, so that now we can take that iSCSI IP address [and] make
it available to other hosts. In addition, most of these products will synchronously replicate. [I
can] take two DL380[servers] … put six 300 GB SAS drives in each one [for] 1.5 TB of usable RAID 5
across both systems, but all the data is written to both systems. It's a higher degree of
reliability than a low-end disk array, which may only have one controller and one set of disk
will charge you $2,500 for the software for both of those systems. Your performance is limited to
the onboard RAID controller, but there are ways around that too. For example, LSI's latest RAID
controllers support SSD [solid-state drive] caching, so for about $3,000, I can buy the RAID
controller, the disk drives and 100 GB SSD that it is going to use as cache and get performance
substantially better than I would get from a $10,000 single-controller disk array that doesn't have
[a] substantial amount of cache. So [as an] example, [OCZ's] virtual
storage appliance has SSD caching logic built in, and because it looks to VMware as the shared
disk, it doesn't cause the vMotion problems
that other host-side caching systems will.
Now, if you remember, one of the first slides that we looked at this morning was the I/O blender. And [I stole] the concept of the I/O blender … from the guys at Virsto. Virsto makes what they call a "storage hypervisor," which I think is a little bit hyperbolic, but I'll let them get away with it for now. They have a virtual storage appliance. Its function isn't to make the local disk look like a disk array; its function is to accelerate performance and provide better snapshots. So … they sit between the virtual machines and the hypervisor and they create a log-based file system. Log-based file systems take random I/O, consolidate it into a log and then write the data to disks somewhat later, so that by the time the data gets to the disk, it looks much more sequential. Basically, it demultiplexes the randomization the I/O blender creates. And so, by using an SSD for this log, we can now asynchronously destage to the actual disks, reads still happen from the disks, reads and writes come from different places, [and] you get better performance all around. And it's a much better snapshot mechanism on a per-VM snapshot than either VMware's or Microsoft's, so you could create snapshots and leave them around for a day or two to use them as an immediate backup mechanism, which I certainly wouldn't recommend for either Microsoft or VMware snapshots.