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).

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.

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).

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.

Windows Server 2016 as an Azure VM

Running Windows Server 2016 as a VM in Azure is also possible. Selecting New | Virtual Machines gives you several options. You can create either a conventional Windows server based on Windows Server 2016 Datacenter or a server with already activated container technology. Windows Server 2016 is also available in Azure as a nano installation. By selecting the VMs, Windows Server 2016 servers can be provided very quickly and can also be connected to local networks through virtual networks. Remote Desktop Protocol (RDP) access to the servers is fast and easy. After creating the VM, the associated RDP file can be downloaded directly from the Azure portal.

A wizard guides you through the setup process, where you can also select the virtual networks to which the server should belong. VMs can be combined to form networks. Azure also offers a way to create virtual networks with different subnets. The networks are routed automatically. In Azure, virtual networks form the link between servers in the cloud and local networks. In this way, you can run networks in the cloud and connect the server services to the corporate network. This also applies to containers and nano servers based on Windows Server 2016. To create virtual networks, choose New | Networking | Virtual network. Use the new Azure web portal for the configuration. When creating a virtual network, it is important to assign the network's storage location correctly (i.e., the resource group).

When setting up a virtual network, also determine the DNS servers that are available on the VM for name resolution. Several DNS servers can also be stored here; they are created later as virtual servers and can be a predefined Windows image based on Windows Server 2016, a self-installed server, or a Linux server. You can also connect to corporate networks.

Managing Virtual Networks

Subnetworks play an important role in the management of virtual networks and can be used to isolate virtual servers from other services, which is particularly interesting when using the containers in Windows Server 2016. The IP addresses on the subnet can be freely defined because they are only used within the virtual network and the servers connected to this network.

Azure automatically sets up routing between the different subnets you configure without having to adjust any settings. Subnets can be added to virtual networks at any time. It is also possible to specify for each virtual network whether it should communicate with other networks or be connected to company networks. You can customize virtual network settings at any time and create additional subnets, connect gateways and local networks, and much more. The DNS servers can also be adapted and expanded at any time. The VM settings show the associated virtual networks.

When you create VMs in Azure, you can assign them directly to specific networks and subnets. You have the option of installing a server yourself or using a predefined image (e.g., Windows Server 2016). As mentioned above, the servers can be directly assigned to virtual networks in the wizard. You can also add the VMs to a resource group. This is a group of resources in Microsoft Azure (e.g., multiple VMs).

Assignments to virtual networks are also defined by using the wizard to create new servers. If you have created several subnets for a virtual network, you can select the desired subnet after selecting the virtual network. The IP address of the server is assigned by DHCP within the subnet. No configuration is necessary. If you have created several servers in a virtual network, they can talk to, or ping, one other. However, the servers are managed through their external IP addresses and the configured endpoints, as can be seen in the VM settings.

Exchange 2016 and Office 365

Exchange Server 2016 and Office 365 also play an important role when it comes to cloud operation of Windows Server 2016. Office 365 uses Azure Active Directory (AD) for authentication. Windows 10 Enterprise can also use Azure AD. The new programs and operating systems in Windows Server 2016 close the circle of pervasive use of Azure.

As of Cumulative Update 3 [3], Exchange Server 2016 supports installations on servers running Windows Server 2016. Therefore, the Hybrid Configuration Wizard can also be used together with Windows Server 2016, Exchange Server 2016, Office 365, and Microsoft Azure. Unlike previous versions, this is a standalone product, and the wizard is no longer integrated with Exchange. The Office 365 Hybrid Configuration Wizard [4] adapts its functionality to the capabilities of the Exchange version used.

SQL Server 2016 in the Cloud

Companies migrating to Windows Server 2016 will upgrade their SQL servers sooner or later to the new version to run on the new server. It goes without saying that SQL Server 2016 also offers opportunities for collaboration with Azure that complement the functions of Windows Server 2016.

In addition to comprehensive encryption, SQL Server 2016 offers further security features. You can use filters in the databases to specify that users are not shown certain data, even if they are authorized to see the data. The filters also can be stored on the basis of user names in Active Directory or Azure AD. This means that users cannot read certain data at all if they are not authorized to do so. Reporting services can also access local data from SQL servers or data in Azure.

As with its predecessors, Microsoft has expanded its integration with Azure. The focus is primarily on companies that rely on hybrid cloud solutions; that is, they want to operate local database servers, but also databases or database servers in the cloud. The wizards for collaboration between local servers and the cloud have been extended and simplified accordingly. Fewer steps are required to migrate SQL databases to the cloud.

SQL Server 2016 also lets you run tables locally and in the cloud. You can thus extend local tables on servers with SQL Server 2016 into the cloud. The table is stored locally and in the cloud and is accessible from local applications, which is particularly useful for data that is not constantly needed and for which high-performance access is not required (e.g., past sales figures).

The advantage is that you can share data storage in the data center and offload outdated data into the cloud, saving money on expensive, high-performance storage space. Additionally, you can make large amounts of data available at a relatively low cost, access SQL server resources, and continue to use your applications. For applications that rely on this technology, the use of tables in Azure is transparent; no adjustments are necessary.

Conclusions

Windows Server 2012 R2 was already closely integrated with Azure. Microsoft goes even further with Windows Server 2016 and allows the integration of clusters and RDS. High-availability services such as Azure Site Recovery or Azure Backup are not yet fully functional with Windows Server 2016. However, Microsoft is expected to update these services.

When operating a cluster, Azure is a valuable tool, regardless of whether you want to connect a geocluster that spans multiple data centers or a small cluster that requires a witness server. The connection is made through easy-to-use wizards. The possibilities of Azure with Windows Server 2016 are worth a closer look.