VMware saw an issue with the SMB customers in that some were not adopting the higher editions of their software because most of the features required shared storage and some SMBs might not have been ready to bite off the costs of that storage. So VMware decided to get creative and create a redundant shared storage solution using local storage.
Here are some of the features:
- Deploys as an appliance, very easy to install
- Must be deployed on a new ESXi 5.0 installation
- Deploys a VSA Cluster Service on the vCenter server
- The VSA Cluster Service can deploy the VSA “Agent VMs” to each of the ESXi 5.0 hosts
- The appliance will use the local space available and present the storage on the network as an NFS datastore
- Replicates the local storage to the local storage on another host in the cluster for redundancy.
- If a host fails, the appliance storing the replica will immediately take over the failed “Agent VM’s” IP address and share the storage from the replica
- v1.0 supports 2 or 3 ESXi hosts in a cluster (Typically for the essentials kits)
- Sold as a separate SKU with one price with no license capacity restrictions (no technical size limits that I could find)
- Supports 25 VMs (configured on 2 ESXi hosts) or 35 VMs (configured on 3 ESXi hosts)
- It is the only scenario where VMware recommends running vCenter on a physical or standalone ESXi hypervisor (To protect you from running into a Catch-22 as vCenter is managing the VSAs
- Recommended to use RAID10 on the hardware RAID controllers in the hosts (to protect from a single drive failure)
- Uses RAID 1 (Mirroring) between hosts for redundancy
- Supports Storage vMotion for when you are ready to migrate to hardware shared storage
- Can put the whole VSA cluster in maintenance mode or just a single node. Can also replace a node and have the VSA rebuild onto it for redundancy or for rolling upgrades.
Here’s how it works: Imagine I have 3 hosts numbered 1,2 and 3. Once the VSA gets installed, it creates two volumes on the available local storage on each host. So host 1 will have volumes 1A and 1B, host 2 has 2A and 2B, host 3 has 3A and 3B. Once the VSAs are configured, they will be redundant so that 1A (which stores VMs) mirrors to 2B, 2A mirrors to 3B and 3A mirrors to 1B. If any VSA get’s dropped, the VSA running the mirror copy takes the IP address of the failed VSA and keeps right on chugging.
My Take
The Pros: Great solution for SMBs without shared storage to take advantage of HA, vMotion, etc. I also think this is an outstanding solution for companies with remote offices who want to have redundancy in 2 or 3 ESXi hosts but don’t want to put shared storage in each site.
The Cons: Way too much overhead. VMware is recommending hardware RAID10 from the local drives if possible. If I have 4 x 1TB drives in a server (4TB RAW disk capacity). I use RAID10 as per VMware’s recommendation, this means 2TB gets presented to the ESXi host. Now the VSA uses half of that storage for VMs and half as a target to mirror the VSA from one of the other hosts. So out of 4TB of RAW disk, I get <1TB of capacity to store VMs on (don’t forget, I need room to store ESXi itself). Thats a 75% reduction from RAW capacity = too much overhead.
Overall I still think it’s worth it. It’s still going to be less expensive that a shared storage frame (even with the overhead loss). I think for remote sites, you can’t beat it. I can’t wait to see what they add to it in v2.0.