Mastering Windows Server 2016 Hyper-V

(Romina) #1

Name>. It’s possible to have the file share witness for a cluster hosted on a different
cluster to provide additional resiliency to the file share. Note that the clustered file
share can be hosted on a traditional file server or a Scale-out File Server. Both will
work well.


A disk witness can be any cluster disk, which means that it’s accessible from all nodes
in a cluster that is NTFS or Resilient File System (ReFS) formatted and is at least
512MB in size. You may wonder why the cluster disk needs to be 512MB. The cluster
disk stores a copy of the cluster database, hence the size requirement. By default,
when you’re creating a cluster, the smallest cluster disk that is over 512MB is
automatically made the disk witness, although this can be changed. The disk witness
is exclusively used for witness purposes and does not require a drive letter.


Windows Server 2016 introduces a third type of witness resource, a cloud witness. A
cloud witness utilizes an Azure storage account, which can utilize any of the Azure
regions. A cloud witness has the following benefits:


It  uses    Azure   as  a   third   site,   which   solves  a   challenge   for many    multisite
deployments today that need the witness in a separate location that they don’t
actually have.
There is no maintenance for the witness, since it’s just using an Azure storage
account accessed over the Internet via HTTPS.
It is ideal when other types of witnesses are not available or not easily available
(for example, creating a guest cluster in Azure or other private cloud).
It’s cheap—very cheap—maybe even free, but more on this in a second.

The cloud witness works by creating a 0-byte block blob for each cluster in an
automatically created container named msft-cloud-witness in the specified Azure
storage account. Azure charges based on consumption. While not guaranteed, the
price for a 0-byte file will likely be 0 but may cost you a cent eventually. Multiple
clusters can use the same storage account; a new block blob is created using the GUID
of the cluster. Figure 7.3 shows an example storage account that is being used by two
separate clusters; hence the two separate block blobs, one per cluster. Note that the
file is not empty; it contains a sequence number, but it’s so small that Azure rounds it
down to 0. Note that when using a cloud witness, the access key for the storage
account is not stored in the cluster; instead, a shared access signature (SAS) token is
generated, stored, and used. Details on SAS can be found at
https://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-shared-
access-signature-part-1/.

Free download pdf