By Michael Letschin, Field CTO
This is the fifth of six posts (the last one was Hyperconverged “SDS”) where we’re going to cover some practical details that help raise your SDS IQ and enable you to select the SDS solution that will deliver Storage on Your Terms. The fifth SDS flavor in our series is Virtual Storage Appliances.
One of the lesser known flavors of SDS is the Virtual Storage Appliance (VSA); it’s less common because it requires a virtual machine environment (think Microsoft’s Hyper-V or VMware), and because there are only a few, software-only options for it (like FreeNAS, LeftHand VSA, or Nexenta’s NexentaStor). There also tend to be feature limitations as a result of the virtual machine environment, such as lack of replication across hosts. That said, for the right use case – such as remote offices, branch offices, small and medium-sized businesses, and multitenant apps – a virtual storage appliance (VSA) can offer a cost-effective storage solution. To use the VMware example, multiple head nodes each connect with vSphere and a VSA to present storage as one or more pools, with data from one or more VSAs.
Virtual storage appliances offer excellent flexibility through the hypervisor, because you can choose which one you’d like. The hypervisor host does confine scalability to VM size, that’s an important limitation. While managing individual VSAs across different hosts can bring some challenges, it also supports flexibility. You can spin up VSAs per group or per application to create multitenancy using VSAs. IT maintains control, even though individual teams might think they’re managing their storage pools. This approach offers good performance: even a loaded hypervisor only has minimal impact. And finally, this model doesn’t require any additional hardware, so there’s a nice cost benefit.
Overall grade: C
See below for a typical build and the report card:
