Virtualization Technology News and Information
Article
RSS
Ensuring unstoppable IT infrastructure operation and availability with Hybrid Cloud on Microsoft Azure

Introduction

Lately, there has been a significant move of businesses to the clouds when it comes to server infrastructure and maintenance. For obvious reasons, cloud is a good solution to consider, as cloud providers ensure stability of hardware operation and power supply, which top the chart of the main causes for failures in case physical servers are used. If we're talking about a cloud infrastructure, it can be eliminated, either completely or to a considerable extent. That way, IT staff together with their chief management will no longer be worried about the company IT infrastructure operation and availability.

Configuring Hybrid Cloud

Yet, in certain scenarios, businesses are reluctant to support the tendency and make this move to the clouds a part of their story, mostly due to some internal reasons or apprehensions. Namely for such cases, the StarWind Hybrid Cloud solution has been developed. It allows running the replication of a company's whole virtualized server infrastructure between the local physical server(s) and a remote server in the cloud (Azure for now, with other popular providers like Google Cloud and Amazon AWS to join soon) securely connected to the company's domain network through VPN. Here are some details on how this can be realized.

Before deploying the scenario, make sure your case meets the technical requirements of StarWind Hybrid Cloud (refer to this technical paper):

  • Active Azure subscription;
  • Access to Azure location offering nested virtualization. The location having the minimal network latency is the correct choice;
  • 1Gbps Internet connection is recommended, though technically the minimum could be 100Mbps
  • Public IPv4 address for your VPN connection;
  • Active Directory and DNS deployed on premises;
  • Windows Server 2016 installed on the physical server that is going to become a part of the failover cluster between the company's site and the Azure instance.

As stated in the prerequisites, communication security is ensured by using VPN as a part of the setup. In fact, IPSec IKEv2 is the way to go when configuring VPN. On the physical server located at the company's premises, the Routing and Remote Access Service role should be installed with the "site-to-site" connection type. For the Azure counterpart, we need to configure VPN as well, and for this purpose a network gateway needs to be implemented, with the VPN configuration attached to it. For communication between the sites, ExpressRoute can be added that will offer you better reliability and faster communication as a result of avoiding using public networks.

When the configuration of the nodes in Azure and on premises is done and the secure VPN communication between them is established, we get closer to deploying StarWind Virtual SAN (available as BYOL or SaaS on Azure) and all prerequisites required for using this particular software. The main requirements are:

  • Hyper-V role
  • Multipath I/O (including multipathing for iSCSI devices, deployment of which would require an additional reboot)
  • Failover Cluster feature

Depending on your usage scenario, the above list may not be 100% exhaustive, yet it reflects the basic minimum, without which it would be impossible to get the whole thing working. After these prerequisites are met, it is time to deploy StarWind devices to be further used as cluster shared volumes for the cluster we are going to create using the on-premises server and the remote Azure VM server. Based on the requirements of your environment, certain number of storage devices should be configured, including the Witness device to be further used as Quorum for the failover cluster. We need to end up with StarWind disks replicated between the remote cloud server and the local one. After the StarWind disks are created, it is high time to proceed with iSCSI setup on both nodes. Be sure to select the Failover Only load balance policy for the targets that you connect and provide only local (loopback) connection for the witness target, no matter whether configuring this on the Azure side or the on-premises server. This policy will back better productivity when I/O operations are processed. After the targets are connected, we need to go to the Disk Management snap-in and bring the offline disks online, along with initializing them as GPT devices. Be sure to perform the above operations on both servers.

When done with the targets and disks, we need to deploy a Microsoft Failover Cluster. For this, we will use two nodes, i.e. the on-premises server and the Azure VM that are members of our StarWind setup and the same domain. The disks based on StarWind targets can be added to the cluster at the stage of its creation or at a later stage, when the cluster is already configured. In the first scenario, all available storage will be added with the smallest disk becoming the Quorum. If the latter is chosen, the Quorum should be assigned manually.

Conclusion

After the Failover Cluster is fully functional, we are ready to deploy VMs on top of the CSVs inside the cluster. As a result, we will be able to live migrate them between the nodes, i.e. moving the VMs between the physical server at the company's site and the Azure virtualized server.

Due to the flexibility in terms of the compute and storage resources this solution offers, it can be considered as a great option to recover your production and bring it back to the functional state almost immediately after a force majeure has been encountered. Here, I should note that to some extent StarWind Hybrid Cloud could enter the internal competition with another product of StarWind, i.e. the StarWind Cloud VTL solution. The latter offers making backups to the virtual tape and uploading those to a cloud provider, which can still be a regulatory requirement that many companies need to meet. Unlike in case of Cloud VTL where some amount of time is required to retrieve the tapes from the cloud and restore the production environment using them, StarWind Hybrid Cloud offers almost instant start of the VMs in the cloud in case the local node fails as a result of power outage or a much more disastrous event. This allows for making the company's crucial services available again after a very short service disruption.

Published Monday, January 01, 2018 1:44 PM by David Marshall
Filed under: ,
Comments
There are no comments for this post.
To post a comment, you must be a registered user. Registration is free and easy! Sign up now!
Calendar
<January 2018>
SuMoTuWeThFrSa
31123456
78910111213
14151617181920
21222324252627
28293031123
45678910