Introduction
For all our customers running HyperConverged Appliances, it’s a common thing to consider the implementation of stretched scenario having numerous locations and offices. Within this scenario, VSAN from StarWind distributes Highly Available storage for a Failover Cluster that spans two geographic locations.
Stretched cluster allows extending Virtual SAN shared storage between two sites using it as a stretched storage. It is designed to manage planned maintenance and avoid disaster scenarios. As both sites are active, maintenance or loss of any of them does not affect the overall workload of a cluster. Even when the site fails, the cluster starts utilizing the StarWind storage on another location.
Furthermore, stretched cluster enables swift virtual machines migration from one geographic location to another, maintaining network connections with other servers within the cluster. This scenario is useful if, for example, a hurricane or other natural disasters are expected to hit one location. In this case, critical virtual machines could be migrated to servers that are physically located in a different facility but connected within the stretched cluster.
How to
To start with, get Windows Server 2016 installed on both servers. As usual, before StarWind configuration, let’s install all Windows Updates, Failover Cluster, MPIO features, and the Hyper-V role.
Design Networking
The stretched cluster requires at least one single network channel between nodes. It could be implemented using the direct connection, hardware or software VPN solutions. In our case, I use Tinc VPN to setup secure private networking between two locations. To emphasize other software solutions, SoftEther VPN, Windows Server Routing, and Remote Access (RRAS) can be used to implement L2TP/IKEv2 and PPTP VPN as well.
In terms of performance, the network latency should be minimized. StarWind HA devices continue synchronization process under 100Mbps throughput and latency of 50ms, which allows protecting several mission-critical VMs. However, StarWind is not able to ensure solution stability In case of higher network latency and slower network throughput. In fact, it is highly recommended to contact StarWind support team so that our Engineer could help you with the configuration and confirm the setup.
VPN setup
Using Tinc VPN, it is quite easy to configure L2 network between sites. Let’s start the configuration. Tinc VPN requires a creation of a configuration file that contains a name of the host, the name of the host to connect to, the mode, and the name of the interface. Here is an example:
Install Tap-device by executing addtap.bat file located in tinc folder.
Open network settings and assign the interface name, set in tinc’s configuration file beforehand, for a Tap-device. Once it is done, finish Tinc configuration on this site, generating certificates for each location.
Add private IPv4 Addresses of the second node and witness host to the configuration file.
Note, Tinc requires a copy of each site configuration in tinc\VPN\hosts folder. The execution of the following command creates the VPN service and starts Tinc.
Afterwards, I have assigned a private network IPv4 addresses to Tap interfaces. Now we can ping the second host and witness, and check the latency.
Tinc VPN configuration is finished.
StarWind Configuration
Since we have a 2-node scenario built over a single channel, we need to decide which one will serve as the main site, in order to setup Node Majority Failover Strategy. With the Node Majority Failover Strategy, failure of only one node can be tolerated. In case of two nodes go down, the third node will also become unavailable for clients’ requests.
In my case, AWS Windows Server VM on free tier will serve the StarWind witness role.
According to the recommendations, I’ve created 3 devices:
- Witness – serves to Failover Cluster purposes;
- CSV1 – shared storage for clustered VMs;
- CSV2 – shared storage for clustered VMs.
Storage is set up and we are ready to create a failover cluster. Validate the cluster as usual and then add StarWind HA devices as cluster shared storage.
Now, a Stretched cluster is ready and this means you can create VMs on top of CSVs. Test Live Migration and Failover processes.
Conclusion
As you can see, VSAN from StarWind features the stretched cluster scenario. Having the low network latency and the high network throughput, it allows benefitting from utilizing active-active replicated shared storage between geographical locations. Thus, business simply tolerates any disaster that hits one if its sites or easily conducts planned maintenance.
Here you can find the complete guidance on how to configure a Stretched Hyper-V Cluster powered by VSAN from StarWind as the shared storage provider.
