Tuesday, December 15, 2015

How to setup a highly available cluster with Hyper-V and Starwind Virtual SAN - part 1

For a long time I have wanted to build a new lab for doing my tests around all the new stuff that regularly come out in IT. One month ago, when I got back from the Microsoft MVP Summit, which by the way was an incredible human experience, I bought a good bunch of new hardware to extend the capabilities of my pre-existing infrastructure.

Once I set everything up, using of course the last preview of my favorite operating system, Windows 2016 Technical Preview 4 on the server side, and Windows 10 on the client side, I moved to think how I could build a virtual environment that could be highly available both on the hypervisor tier and on the storage tier.

What we all know is that building a virtual infrastructure on top of a failover cluster is the way of preventing a host server from becoming a single point of failure in case of hardware fault.

The problem is that, when building HA clusters, your hosted application availability is only as good as its weakest link.

Without some sort of HA mechanism, storage becomes the weakest link in the cluster setup because if the shared storage fails the whole cluster becomes unavailable, no matter how many iSCSI target servers you have.


So, while I kept telling myself that I wanted a SAN, I also wanted to be able to configure a highly available ISCSI storage without investing in any kind of expensive hardware, like JBOD trays or Dual Controller SAS arrays.

Then, in the era of Software Defined Everything, I started to look at a Software Defined SAN. And found out that Virtual SAN by StarWind Software, is the best option here, since it integrates perfectly with Windows Server in providing redundancy for storage backend for my iSCSI target servers without the need to buy new hardware.

The basic concept of StarWind Virtual SAN is really interesting: you re-use your exceeding local Windows storage in a synchronously mirrored way and expose it through iSCSI to the Hyper-V servers.


There are two possible scenarios: Hyper-converged or Compute and Storage.

The Hyper-Converged scenario is the only rational option when you want to build a fully redundant Hyper-V cluster and only have two physical nodes: the local storage on both servers is managed by StarWind Virtual SAN, which mirrors it between the two nodes over the network and provides it to the Hyper-V cluster as a Cluster Shared Volume (CSV). The software reads and writes data locally so there is no storage IO going through the network links, apart for synchronous replication between the two nodes.

In order to provide HA and resiliency you need both a heartbeat (for cluster monitoring) and a synchronization (for data replication) networks.

In my case I had four physical nodes at hand, and I intended to use them all. So I opted for the Compute and Storage scenario, with:
  • two backend servers mirroring their cheap internal storage through StarWind Virtual SAN and acting as iSCSI targets (Storage layer)
  • two front-end hypervisors in a cluster acting as iSCSI initiators and mounting the backend storage as a CSV (Compute layer)
This allows me to keep CPU cycles separated from IO ops, spreading the different workload across two scalable layers:

Let’s start playing with it.


Just download the installer (which is just a small exe file), which contains both the Management Console and the actual Virtual SAN services. The installation is pretty straightforward. Let's fire it up on each backend node:

Accept the licensing :

Once you get on the information screen you have a good bunch of information of all the feature of the latest release (V8):
  • New Log-structured File System (LSFS) container, with thin-provisioning, snapshots, optional deduplication, synchronous and asynchronous replication.
  • Flash cache to accelerate LSFS
  • New management console
  • Snapshots for High-availability devices
  • VAAI commands support
  • NUMA - aware resource management.
  • Single-node and multi-node devices SMI-S support.

Choose installation folder:

Choose the component to install. A quick but important note here. The list of components is different between Core and Desktop Experience versions of Windows: the Management Console only appears on Windows versions with GUI. Since you need console to build mirroring, you have to install at least one Windows with Desktop Experience on one of your two Virtual SAN nodes.

In my case I have installed the console on a separate workstation where all my RSAT tools are. That's a fifth node I have, but you can very well keep with the four nodes so configured:
  1. Virtual SAN and StarWind Console
  2. Virtual SAN
  3. Hyper-V
  4. Hyper-V
For a Virtual SAN node acting only as storage provider, select StarWind Virtual SAN Service:

If you choose to install the console, which is required to build the mirror, select the appropriate component:

Go through the rest of the installer:

Now you should have installed the StarWind service on both the backend storage nodes:

You can leverage Get-NetTCPConnection (which actually replaces Netstat), to check the different channels between the two mirrored storages:

Get-NetTCPConnection -OwningProcess (Get-Process StarWindService).ID

Open the management console. The interface is nice and simple and the process is self-explanatory:
  1. connect to both your StarWind Virtual SAN servers
  2. add a device on the first node
  3. use Replication Manager to enable synchronous mirroring toward the second node
  4. wait for first replica to end
I will go through the whole procedure in the next post. Stay tuned.

No comments:

Post a Comment

Related Posts Plugin for WordPress, Blogger...