In the past I build a lot of how to build stuff on a cluster or troubleshooting can’t think of any thing or I did add this on a cluster, but with Azure this whole workload went to the past.
A bit feels it that Windows server FCI is a legacy feature but is it ? well lots of items are still using this and not everyone is in the cloud.
But what if you still want to build a cluster in Azure. yes SQL – AlwaysOn is still a good and valid option. But talking a failover file server ? or some other easy workload. Well in this blog I show you how to build this cluster and the workload is up to you. For a long time it was not possible to create a FCI in Azure as there where no shared disk available and If you want to build a FCI you need some extra software from SIOS. https://us.sios.com/
In this post I create a Two node Failover Cluster FCI. with a file server role
So what do we need to build a cluster in Azure
- Two Windows server 2019 Vm’s
- atleast one Shared premium disk
- Azure Internal loadbalancer
- Some time
Building the 2 Vm’s and domain joined need no explanation, If you need help just post a comment and I will help.
Two Azure VM’s mine are deallocated for now for a reason, as we need to adjust the disk and this can only be done when the vm is deallocated.
This is just a basic VM one network card. but make sure you choose a SKU that support a Premium SSD ! with out that it won’t run and Size does matter.
In my created VM I use a 256 GB disk I may not need this size but it is the minimum supported disk for creating a cluster
Enabling shared disks is only available to a subset of disk types. Currently only ultra disks and premium SSDs can enable shared disks. Each managed disk that have shared disks enabled are subject to the following limitations https://docs.microsoft.com/en-us/azure/virtual-machines/linux/disks-shared?WT.mc_id=AZ-MVP-4025011
as you can see there is a MaxShares list For each disk, you can define a maxShares value that represents the maximum number of nodes that can simultaneously share the disk. For example, if you plan to set up a 2-node failover cluster, you would set maxShares=2. The maximum value is an upper bound. Nodes can join or leave the cluster (mount or unmount the disk) as long as the number of nodes is lower than the specified maxShares value
The maxShares value can only be set or edited when the disk is detached from all nodes that is why my VM’w are deallocated for now.
How to create such a Shared disk There are multiple ways create a disk in the disk blade. or run a powershell script it’s all up to you
creating the disk in the portal is quick and easy but it can also be done in a ARM or posh or CLI script. Personally I use often PowerShell instead of ARM.
In the Advanced options there you can enable this shared disk setting
There is no other GUI method that can set this
Or if you have already created and added this disk to a node you can create another disk on that node. But remember that does not enable the Maxshared option.
A resize does not help you.
There is no option to set this afterwards in the Portal keep that in mind. you can only set this with powershell
Sample Idea. in my case
$vmDisks1 = get-azdisk -ResourceGroupName rg-cluster01 -DiskName demo01
$vmDisks1.MaxShares=2
$vmDisks1 | Update-AzDisk
as the error show the disk need to be detached. of all machines!
Ok now that the Disk has changed or recreated and has the setting maxshared=2
We first go to node001 and add the disk to that node
Make sure you attach the same disk to both nodes as this disk was configured as a shared disk
Keep in mind creating the disk here does not enable the MaxShares
now on the second node we add the same disk as it is a shared disk you can see this now 1 used and one share is open. And remember the VM’s need to be deallocated !!
now that the disk is been added to both nodes we can start to build our cluster
After the VM’s are started we install the failover and the file server feature see also my other cluster blogs https://robertsmit.wordpress.com/2018/11/29/step-by-step-windows-server-2019-file-server-clustering-with-powershell-or-gui-cluster-ha-azure-windowsadmincenter-windowsserver2019/
Install-WindowsFeature –Name Failover-Clustering,file-services –IncludeManagementTools
or do this in the GUI. or run this from the domain member server in my case the Dc
$nodes = ("node001","node002")
Invoke-Command $nodes {Install-WindowsFeature Failover-Clustering -IncludeAllSubFeature -IncludeManagementTools}
Now building the Cluster with the wizard is not the best method. As in this case we want to set some different options than default.
The distributed network name (DNN) replaces the virtual network name (VNN) as the connection point when used with an Always On failover cluster instance on SQL Server VMs. This negates the need for an Azure Load Balancer routing traffic to the VNN, simplifying deployment, maintenance, and improving failover.
With an FCI deployment, the VNN still exists, but the client connects to the DNN DNS name instead of the VNN name.
Limitations
- Currently, a DNN with FCI is supported only for SQL Server 2019 CU2 and later on Windows Server 2016 and later.
- There might be more considerations when you’re working with other SQL Server features and an FCI with a DNN. For more information, see FCI with DNN interoperability.
Distributed server name as CNO this is perfect for SQL workloads
The big difference is that now the CNO is not an DNN
New-Cluster -Name AzCluster001 -Node ("node001","node002") –StaticAddress 10.80.0.100 -NoStorage -ManagementPointNetworkType Singleton |Set-ClusterQuorum -NodeAndFileShareMajority \\RDSDC01\cluster
The Static IP Address that you appoint to the CNO is not for network communication. The only purpose is to bring the CNO online due to the dependency request. Therefore, you cannot ping that IP, cannot resolve DNS name, and cannot use the CNO for management since its IP is an unusable IP.
Now that we have created the cluster and set the Fileshare Witness we can make the preparations for the file server
Adding the Disks
Before we move on we first add a Azure internal load ballancer. this is needed for the access in the azure subscription.
For creating a loadbalancer we need a loadbalancer and configure the backend pools with a health probe configured to a load balancing rule.
Creating a new loadbalancer is just a quick process but make sure you choose a Internal and a standard one
And place this LB also on the network where the Cluster nodes are.
In the backend pool we added both VM’s that are the cluster noded.
Press save and the cluster nodes are added to the loadbalancer.
In the loadbalancer we need to create a probe that is checking the port and as we are using a file server that is SMB traffic we use the SMB 445 port
Set the interval to 10- seconds and you can keep the rest default – I changed the threshold to 31
last we make a loadballancer rule give this a name and add the backend pool to this.
and the health probe that we just created is also attached.
keep the floating IP on disabled
Now that the Load Balancer is in place we can create the File server role in the Cluster, You can do all this in random order but the powershell script at the end of this blog must run after you configure all of this.
Doing this in the wizard or PowerShell makes the different here, as we need the file server based on a DNS record that’s why we made the Azure LB. We do this with PowerShell
Add-ClusterFileServerRole -Storage "Cluster Disk 1" -Name FS01 -StaticAddress 10.80.0.211
Remember here the IP that is the same IP that is been used in the Azure Load balancer!
But remember, that IP Address is the same unusable IP address as the CNO’s IP. (Cluster IP) You can use it to bring the resource online but that is not a real IP for network communication. If this is a File Server, none of the VMs except the owner node of this VCO can access the File Share. The way Azure networking works is that it will loop the traffic back to the node it was originated from. So it works only on the node where the resource is running.
The Continuous availability is not supported in Azure.
Our next step is creating the File shares. and test the file server. Using the create file share in the Cluster is not working create the file share on the node that holds the Cluster disk. as it may work for you now but as soon as we configured the rest it will not work any more !!
Testing the file share on node 2 and it worked.
as you can see it works BUT you can see I’m logged in into node 2 and test also from node 2. moving the role to node 1 it breaks the file server.
as Azure can’t handle this we need to implement a little fix in PowerShell.
keep in mind that Pinging the CNO or the VCO will not work, as the cluster needs an IP to start but has no function further.
get the cluster properties
So the cluster is running and the fileserver is running but you can only connect on the node where the file share is hosted, That is not how it should work.
We need to utilize the Load Balancer in Azure so this IP Address is able to communicate with other machines in order to achieving the client-server traffic. This can only be don with PowerShell
Load Balancer is an Azure IP resource that can route network traffic to different Azure VMs. The IP can be a public facing VIP, or internal only. Each VM needs have the endpoint(s) so the Load Balancer knows where the traffic should go. In the endpoint, there are two kinds of ports. The first is a Regular port and is used for normal client-server communications.
We used port 445 is for SMB file sharing Another kind of port is a Probe port. The default port number for this is 59999. Probe port’s job is to find out which is the active node that hosts the VCO (Fileserver) in the Cluster. Load Balancer sends the probe pings over TCP port 59999 to every node in the cluster, by default, every 10 seconds. When you configure a role in Cluster on an Azure VM, you need to know out what port(s) the application uses because you will need to add the port(s) to the endpoint. Then, you add the probe port to the same endpoint. After that, you need update the parameter of VCO’s IP address to have that probe port. Finally, Load Balancer will do the similar port forward task and route the traffic to the VM who owns the VCO.
Setting this for our File Cluster and here comes the complicated part, If you have only one nic it is easy the default is cluster network 1
getting the IP resource Name can be found get-clusterresourcename
***here is a different IP 150 as took later the screenshot and rebuild this a couple of times for the blog*
$ClusterNetworkName = “Cluster Network 1”
$IPResourceName = “IP Address 10.80.0.0”
# The IP address that is used in the Load balancer that should be the same than on the Fileserver cluster role.
$ILBIP = “10.80.0.150”
$params = @{"Address"="$ILBIP";
"ProbePort"="59999";
"SubnetMask"="255.255.255.255";
"Network"="$ClusterNetworkName";
"OverrideAddressMatch"=1;
"EnableDhcp"=0}
Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple $params
Running this should set everything to work.
WARNING: The properties were stored, but not all changes will take effect until IP Address 10.80.0.211 is taken offline
and then online again. So I Stopped the Cluster and Started it again
A quick test on my domain controller and test server and it all worked.
As you can see it is rather complicated to run a file cluster in Azure and the question is why ? there are better options for this as netapp files.
Or using Azure files with Azure AD Support
Step By Step Azure Files share SMB with native AD support
Sometimes you need just the cloud mind and step away from what you have. live can get easier and less management.
Thanks for your Support and If you use this let ne know why just a quick post in the comments Thanks!
Follow Me on Twitter @ClusterMVP
Follow My blog https://robertsmit.wordpress.com
Linkedin Profile Robert Smit MVP Linkedin profile
Google : Robert Smit MVP profile
Robert Smit MVP Blog 