Install DataKeeper

After the cluster is created, DataKeeper is installed. It is important to install DataKeeper after the initial cluster is created so the custom cluster resource type can be registered with the cluster. If you installed DataKeeper before the cluster was created you will need to run the install again and perform a repair installation.

1. Install DataKeeper after the cluster is created. During the installation choose all the default options.

2. The service account used for the login on the VMs must be a domain account created earlier and be in the local administrators group on each node in the cluster.

Once DataKeeper is installed and licensed on each node, reboot the servers.

Create the DataKeeper Volume Resource

1. To create the DataKeeper Volume Resource, start the DataKeeper UI and connect to both of the servers.

2. Connect to VM-1.

3. Connect to VM-2.

4. Once connection to each server is established, create a DataKeeper volume. Right click on Jobs and choose Create Job.

5. Add the Job name and Job description.

6. Choose the Source Server, IP address and Volume. The IP address is whether the replication traffic will travel.

7. Choose the Target Server.

8. Choose your options. Synchronous replication should be chosen for two VMs in the same geographic region. For cross-region replication, the asynchronous option should be used. Compression can also be enabled for large distances, or when high latency is observed between the VMs.

By clicking yes on the last dialog, a new DataKeeper Volume Resource will be registered in Failover Cluster. By default new DataKeeper Volume resources are placed in the Available Storage group.

9. A DataKeeper Volume Resource can be seen in Available Storage.

Create the File Server Cluster Resource

Use PowerShell to create the Failover Server Cluster Resource instead of the Failover Cluster interface. The virtual machines are configured to use DHCP, and the GUI based wizard will not prompt the user to enter the cluster IP address. Instead, it will issue a duplicate IP address. Using a powershell command to create the File Server Cluster Resource and specify the IP address will avoid a duplicate IP address being issued.

*Make a note of the IP address specified here. It must be a unique IP address on the network. The same IP address will be assigned for the Load Balancer.

Create the Internal Load Balancer

The Azure network stack does not support gratuitous ARPS so clients cannot connect directly to the cluster IP address. Instead, clients connect to an internal load balancer and are redirected to the active cluster node. An internal load balancer can be created through the Azure Portal as shown below.

A Public Load Balancer can be used if your client connects over the public internet but assuming the clients reside in the same Virtual Network, an Internal Load Balancer can be used.

*The Virtual Network is the same as the network where the cluster nodes reside. The Private IP address specified will be EXACTLY the same as the address used to create the File Server Cluster Resource. Since multiple Availability Zones are being used, a zone redundant load balancer will be created as shown below.

*An Azure Internal Load Balancer is only required for older versions of SQL Server running on Windows 2016 or older. Starting with SQL Server 2019 CU2, SQL Server FCIs running on Windows 2016 and newer do not need to use an Azure ILB. Instead, the Distributed Network Name (DNN) Azure feature should be configured for SQL Server FCIs. This guide does not cover configuration of a DNN in Azure, but instead relies on an Azure ILB for proper routing.

To edit the load balancer after it is created:

1. Frontend IP configuration.

2. Add Backend pools. Here we will add two cluster nodes, VM-1 and VM-2 to our backend pool.

3. Add Health probes. The probe we add will be Port 59999. This probe determines which machine is currently active in our cluster and where the Virtual IP is enabled. Using this
   ILB will route the traffic to the corresponding node.

4. Add Load balancing rules to redirect the SMB traffic, TCP port 445. Note: Notice that the Floating IP (direct server return) setting is changed. Make sure this option is set to Enabled.

Fix the File Server IP Resource

The final step in the configuration is to run the PowerShell script on one of the cluster nodes. This will allow the Cluster IP Address to respond to the ILB probes and ensure that there is no IP address conflict between the Cluster IP Address and the ILB.

*Edit the script to fit the deployed environment. The subnet mask set to 255.255.255.255 is not a mistake and must be kept as is. This creates a host-specific route to avoid IP address conflicts with the ILB.

Create File Shares

Create the file shares in Windows Explorer on the active node. Failover Clustering automatically picks up the shares and puts them in the cluster.

*The Continuous Availability option of a file share is not supported in this configuration.

A functioning WSFC File Server that spans Availability Zones in Azure is now ready for use.

For additional assistance, pre-sales customers please contact sales@us.sios.com or evalsupport@us.sios.com. If you are a post-sales customer please contact the SIOS Support team at support@us.sios.com. If you need additional assistance with this feature, please contact our Professional Services team at professional-services@us.sios.com.