An upcoming project I’ll be involved in centres around High Availability and Disaster Recovery, and whilst Failover Clustering ticks a number of boxes on the high availability front, that does come with some additional caveats. I wrote recently about areas of weakness I’d found in a traditional Windows Server Failover Cluster, the main thing being shared storage introducing a new single point of failure.
To counter this, there were a number of possible options, at a variety of price points, from dedicated Hardware SAN devices in Cluster Configuration themselves, to software based Virtual SAN Solutions which claim to achieve the same.
This is a brief update on my experiences of Virtual SAN, based on two products, HP StoreVirtual VSA and Starwind Virtual SAN. I should note these are not performance reviews, just some notes on my experiences setting them up and using them in a lab environment.
Starwind Virtual SAN.
In it’s basic form, this is a Free piece of software, support is provided by a community forum, and there are naturally commercial licenses available. This edition can allow you quickly provision iSCSI based storage to be served over the network, but has no resiliency built in. I implemented this recently to provide additional storage to an ageing server running Exchange where physical storage was maxed out, and so network based was the only option, but Exchange needed to see this more as a physical disk than use a network share.
There is a two node license available for this, providing replicated storage across two servers running the software. This is where it provides real use, as you’ve now introduced storage resiliency given it’s available in two places. From experience, once the initial replication has taken place, provided you’ve set up your iSCSI connections and MPIO to use the multiple routes to the storage, powering down one of the servers running Starwind Virtual SAN had no impact on the access to data provided by the Virtual SAN. Once the server was powered back up, it took a little time to re-establish it’s replication relationship, but I’m going to write this off to my environment.
The software can be used in one of two ways, you can install it directly to your server (Bare Metal) or you can install it to a Virtual Machine, with Hyper-V and VMWare VSphere both possible. There are benefits to installing directly to your server, mainly being RAM usage and not having the overhead of hosting a full OS install running on a VM on top of your hypervisor. Two network connections are required, one as a synchronisation channel, ideally using a direct connection between the two servers, the other connection is required for management and health monitoring of the synchronisation relationship.
For extra resilience, if the license permits, a further node can be added to the configuration that is off-site, for Asynchronous replication.
HP StoreVirtual VSA
StoreVirtual is a virtualised storage applicance provided by HP, originally a product known as LeftHand. It is only available as a Virtual Machine and so adds some overhead to it’s implementation, using at least 4GB of RAM, which increases dependent on the capacity hosted. Supported on both VMWare and Hyper-V platforms, there is a wide market for the product.
The StoreVirtual VSA can function as a single node, and equally works in a multi-node configuration with scale-out functionality. Because it cannot be installed ‘Bare Metal’ other than on a dedicated hardware appliance, performance therefore has a potential to be slightly impacted given the overhead in the Hypervisor providing access to underlying physical storage.
In terms of management, there is a dedicated management interface, provided by installing the management tools on another computer (or VM) on the network. Here, it’s simple to provision storage, set up access control in terms of who can access this storage, and see health and performance information.
High availability is achieved not through MPIO, but through presenting a group of servers as a single cluster, this however needs to be managed by a further Virtual Machine running a role called Failover Manager (FOM), which again adds to the overall overhead of the implementation. In an ideal scenario, this would be hosted on hardware independent of the other two nodes to avoid a loss of Quorum. StoreVirtual also supports Asynchronous replication for off-site replication.
Update: for clarity, FOM is required when an even number of nodes are active, to ensure a majority vote is possible for failover purposes.
Limitations of Testing
My lab consists of 2 x HP Microserver Generation 8, both with Intel Xeon E3 series processors and 16GB RAM, both are connected to a HP Procurve 1800 managed gigabit switch. With only 16GB of RAM on each Hypervisor, it’s difficult to simulate a real-world workload on the I/O front, particularly when at bare minimum, 6GB needs to be allocated to StoreVirtual and a FOM on one of the machines, and 4GB for the redundant node on the other.
Pros and Cons
Pro – Installs directly to Windows Server 2012 R2 or to a VM
Pro – Relatively low memory footprint
Pro – Lots of options to tweak performance, can leverage SSD cache etc.
Pro – Generous licenses for evaluation purposes – 2 nodes (provided they are VM based) licenses are available free of charge
Con – I’d heard of Starwind before, having used a few of their useful tools, but would you trust their solution with your enterprise data?
Con – Caught up with a full resync when one node was shutdown and restarted, and it took some time to re-establish the synchronisation
Pro – A brand name you know, and might find easier to trust
Pro – Up to it’s 13th Version, the underlying OS is proven and stable
Pro – Intuitive management tools
Con – Must be ran as a VM, minimum RAM required is 4GB for a StoreVirtual node. A Failover Manager is required to maintain Quorum in a 2 node configuration
Con – 1TB license expires after 3 years, so for lab use, prepare for the time to come
I can vouch for solid performance in Starwind Virtual SAN, as the shared storage for my lab’s Hyper-V highly available VMs is running on a 2 node Starwind Virtual SAN. Ultimately, lack of Hardware available to perform a comparable test has meant I have not been able to use StoreVirtual to host the same workload. The licensing of StoreVirtual put me off a little, Starwind’s license is non expiring, but the 1TB license for StoreVirtual on offer is restricted to 3 years.
Once I’ve found some suitable hardware to give StoreVirtual a fuller evaluation, I’ll add more detail here.