Into the Blue

Under Windows Server 2016, you can now set up witness servers (Cloud Witness) for Windows clusters in the Microsoft cloud, as well as the Connection Broker for Remote Desktop Services (RDS), which means you can link up multiple data centers for highly available and powerful servers and clusters. You don't have to rely on virtual machines (VMs) with Windows Server 2016 in the cloud; instead, you can lease their functionality as a service in Azure itself. Now it is also possible to install Windows Server 2016 in Azure. The cloud service allows you to install VMs based on Server 2016 and connect them to each other through virtual networks or to the local network to create a hybrid cloud that supports Windows Server 2016 features. Such a cloud could be managed with System Center Virtual Machine Manager, for example.

Connecting Server 2016 to Azure makes sense if a cluster extends across multiple data centers. In this case, Cloud Witness can stabilize and significantly influence the management of the quorum. Such clusters are used in Windows Server 2016, for example, with the new Storage Spaces Direct (see the article on S2D in this issue) and Storage Replica. In such a scenario, the local volumes of the cluster nodes are combined into a virtual storage location replicated between data centers by Storage Replica. In this way, Hyper-V could be operated in a geocluster with high availability. Cloud Witness is therefore predestined for high availability.

In addition to the active options available for connecting Windows Server 2016 to the Microsoft Azure cloud, a considerable amount of Azure lies behind the scenes of the operating system. The network stack and the functions relating software-defined storage (e.g., S2D and Storage Replica) are well known from Azure. Technologies such as Azure Site Recovery to replicate VMs in Microsoft Azure or Azure Backup to back up entire servers to the cloud are also included. Although they are currently not available for Windows Server 2016, these features are expected to be updated soon in Azure.

Cloud Witness is also ideal for failover clusters that do not use shared storage, such as database availability groups in Exchange or Always On Availability Groups in SQL Server 2014/2016. If you run clusters in the cloud, such as Azure or Amazon Web Services, use of this function also makes sense. Scale-out file servers (SOFS) in Windows Server 2016 can also be integrated optimally as clusters. Cloud Witness is also available, and you should consider the use of Cloud Witness in other than just large companies or networks. If you only use a small cluster with two nodes, it can be worth positioning the witness server in the cloud.

Multisite Cluster with Cloud Witness

If you run a cluster in the network that spans several data centers, the question becomes where the witness server should be located to ensure reliability. With Windows Server 2016, you can configure clusters to use as witness server services in Azure to ensure that no incorrect failover or fallbacks occur, because Azure keeps track of the cluster.

Cloud Witness is a new type of cluster quorum computation introduced with Windows Server 2016. For example, you can use Azure Blob Storage for Cloud Witness, which avoids the overhead caused by a VM in Azure. You can also use a storage account in Azure as a Cloud Witness for multiple clusters. A separate "blob file" in the storage account is used for each cluster. The file is updated whenever the status of a cluster node in the cluster changes.

When it comes to voting, Cloud Witness receives one vote in the cluster, just like each cluster node, to ensure that there is always a majority for the quorum. Cloud Witness is available as a resource in the cluster. Microsoft therefore recommends that you connect all cluster nodes to the Internet so that you can reach Cloud Witness in Microsoft Azure.

The basis for Cloud Witness in a cluster with Windows Server 2016 is the preparation of a suitable Azure Storage Account. This account contains the blob file containing the witness data for the cluster. Of course, you can also try this with an Azure test account. To do so, add a new storage account on the Azure portal with New | Storage | Storage Account . In the Replication area, select the Locally-redundant storage (LRS) option (Figure 1).

Figure 1: The basis for Cloud Witness in Windows Server 2016 is a storage account in Microsoft Azure.

Creating a storage account takes a little time. The account's access keys are important for connecting your cluster nodes. You need to retrieve them in the Azure portal so that you can use them on the cluster node. The two keys can be found under All settings | Access keys in the storage account management. If you create a storage account, Microsoft Azure also creates a URL, so you can access it externally; the format is https://<Storage Account Name>.<Storage Type>.<Endpoint> (e.g., https://cloudwitnessjoos.blob.core.windows.net ).

Connecting Clusters to Azure

Once you have created the storage account, you can customize the cluster quorum. The quickest way to do this is to right-click the cluster and select More Actions | Configure Cluster Quorum Settings in the Failover Cluster Manager (Figure 2). In the wizard that opens, choose Select Quorum Configuration Option | Advanced quorum configuration and click Next until you are on the Select Quorum Witness page. Select the Configure a Cloud Witness option.

Figure 2: The connection to Azure is made in the Failover Cluster Manager of Windows Server 2016.

In the next window, enter the name of the storage account to be used as a Cloud Witness and enter the access key. The wizard then completes the connection to Azure. You can also use PowerShell:

> Set-ClusterQuorum -CloudWitness -AccountName <StorageAccountName> -AccessKey <StorageAccountAccessKey>

If the endpoint does not comply with the https://<Name>.blob.core.windows.net standard, use:

> Set-ClusterQuorum -CloudWitness -AccountName <StorageAccountName> -AccessKey <StorageAccountAccessKey> -Endpoint <Servername>

If it is not possible to connect the cluster nodes directly, you can also carry out a test connection via a proxy. However, this is not always so easy and unfortunately not very stable. An article on the Microsoft Developer Network (MSDN) provides more instructions [1]. You can also check the successful connection in the Azure portal. If you click on the storage account and then Blobs , you will see the new msft-cloud-witness container (Figure 3). This is the container for the cluster's blob file. Click on the container and you will see the witness file. The file name corresponds to the cluster's GUID. In the Failover Cluster Manager, click on the cluster and check Cloud Witness in the Cluster Core Resources section. This must be displayed as Online . Double-click on the resources to call their properties. Here the Status must indicate Online . In PowerShell, you can check the configuration with the Get-ClusterQuorum | fl command (Figure 4).

Figure 3: The Cloud Witness blob file is stored in Azure.

Figure 4: The cluster quorum can also be queried in PowerShell.

Connecting Remote Desktop Services to Azure

The Connection Broker controls the connection of users in RDS environments. Since Windows Server 2012 R2, the creation of a Connection Broker is no longer optional, but mandatory. With Windows Server 2016, the data can be stored in Azure SQL, which enables highly available and powerful RDS environments and saves resources because you can rely directly on Azure SQL and do not have to run your own SQL servers. What you need is a new SQL database, which you can add in the Azure portal by clicking Databases | SQL Database . Once the database is created, display its connection strings for the OBDC driver, which you need for the Connection Broker on the network.

You need to install the native SQL client [2] to connect the Connection Broker to Microsoft Azure, which is also required if you install your own database server for RDS high availability. In the RD Connection Broker context menu in the Server Manager, configure the environment for high availability. A wizard will help you set up the system. Select Shared database server as the option; then, enter the DNS name of your database and the copied connection string from the previous step, including the custom credentials for login in Microsoft Azure.

If the connection has been successfully established, the Azure SQL database is used. If you connect further Connection Brokers, they can be linked in the same way, which enables you to achieve high availability without having to run your own database.