In this blog, I have covered steps to create a Failover Cluster In Windows Server Failover groups that give high accessibility and adaptability to numerous server workloads. The server applications can run on actual workers or virtual machines. In a failover cluster, on the off chance that at least one of the clustered servers (nodes) fizzles, different nodes start to offer support. This process is known as failover. We cover this in detail in our Azure Data Database Administrator [DP-300] Training program.
To understand more about the certification read our blog Microsoft Azure Database Administrator Associate.
In this blog we’ll cover:
- Windows Server Failover Cluster In Azure
- Failover Clustering Feature
- Cluster Validation
- Create A Windows Server Failover Cluster
- Test Windows Server Failover Cluster
- Deploy An Active Directory-Detached Cluster
Windows Server Failover Cluster In Azure
Deploying a Windows Server Failover Cluster (WSFC) in Azure is like arranging one on-premises. For this, we need to follow some specific considerations in azure.
Quite possibly the main angle is choosing what to use for a witness asset. The witness is a core part of the quorum mechanism. Quoram is the thing that guarantees that everything in the WSFC keeps awake and running. On the off chance that you lose quorum, the WSFC will go down taking an AG or FCI with it. The witness asset can be a disk, file share (SMB 2.0 or later), or cloud observer. It is suggested that you utilize a cloud witness as it is completely Azure-based, particularly for arrangements that will traverse numerous Azure regions or are hybrid. The cloud witness feature is available in Windows Server 2016 and later. The next consideration is the Microsoft Distributed Transaction Coordinator (DTC or MSDTC). A few applications use it, however, most of not.
Most WSFC deployments require the utilization of both AD DS and DNS; FCIs consistently do. AGs can be designed without requiring AD DS but still needing DNS. In Windows Server 2016, there is a variation of a WSFC called a Workgroup Cluster, which can be utilized with AGs as it were. A typical Azure-based WSFC will only require a single virtual network card (vNIC) unlike the setup for an on-premises physical or virtual server, the IP addresses for the vNIC has to be configured in Azure, not in the virtual machine that means inside the virtual machine it will show up as a dynamic host configuration protocol address.
Failover Clustering Feature
Before the Windows Server Failover Cluster can be configured, the underlying Windows feature must be enabled on every node that will participate in the WSFC. This can be done in one of two ways: using the Powershell or Server manager.
In Server Manager, Failover Clustering must be enabled in the Add Roles and Features Wizard.
To enable the feature using PowerShell use this code below
Install-WindowsFeature Failover-Clustering -IncludeManagementTools
Once the feature is installed on the servers targeted as windows server failover cluster nodes, you must then validate the configuration.
Cluster Validation
For a Windows Server Failover Cluster to be considered supported, it must pass cluster validation. Cluster validation is a built-in process that checks the nodes via a series of tests to ensure that the entire configuration is suitable for clustering. After running validation, each of the tests will come back with a warning, an error, a pass, or a message that the test is not applicable. Warnings are acceptable if that condition is expected in your environment. If not, it should be addressed. All errors must be resolved.
Validation can be run via Failover Cluster Manager or by using the Test-Cluster PowerShell cmdlet.
Create A Windows Server Failover Cluster
To create a Windows Server Failover Cluster in Azure, you cannot use the Wizard in Failover Cluster Manager for FCIs or AGs deployed using Windows Server 2016 and earlier. Due to the Dynamic Host Configuration Protocol (DHCP) issue mentioned earlier, currently, the only way to create the WSFC is to use PowerShell and specify the IP address. This could change in future versions of Windows Server.
1.)For A Configuration That Has Shared Storage:
New-Cluster -Name MyWSFC -Node Node1,Node2,…,NodeN -StaticAddress w.x.y.z
where MyWSFC is the name of the WSFC you want, Node1, Node2,…, NodeN are the names of the nodes that will participate in the WSFC, and w.x.y.z is the IP address of the WSFC (for example 10.252.1.100.)
If you are creating a WSFC that spans multiple subnets, you can specify more than one IP address for -StaticAddress separated by commas(,).
2.)For A Configuration That Does Not Have Shared Storage
New-Cluster -Name MyWSFC -Node Node1,Node2,…,NodeN -StaticAddress w.x.y.z -NoStorage
3.)For A Workgroup Cluster That Will Only Use DNS
New-Cluster -Name MyWSFC -Node Node1,Node2,…,NodeN -StaticAddress w.x.y.z -NoStorage -AdministrativeAccessPoint DNS
For a Workgroup Cluster, you will need to ensure the name and IP address(es) are in DNS for any name or IP address created in the context of the WSFC such as the WSFC itself, an FCI name and IP address, and an AG listener name and IP address.
Test Windows Server Failover Cluster
After the WSFC is made yet prior to arranging FCIs or AGs, test that the WSFC is turning out appropriately For clusters that require shared storage, for example, for those supporting a SQL Server Failover Cluster Instance, it is important that your test the ability for all of the nodes in the cluster to access any shared storage and to take ownership of the storage as they would in a failover. You can do this by tapping on Storage, then, at that point Disks in Failover Cluster Manager, as displayed in the picture underneath. In the event that you right-click on each grouped circle gadget, you will see the alternative Move Available Storage. On the off chance that you pick the Select Node choice, you can force the storage to failover to the other nodes in the cluster to confirm this functionality.
Deploy An Active Directory-Detached Cluster
In Windows Server 2012 R2, you can deploy a failover cluster without dependencies in Active Directory Domain Services (AD DS) for network names. This is referred to as an Active Directory-detached cluster. Using this deployment method enables you to create a failover cluster without the previously required permissions for creating computer objects in AD DS or the need to request that computer objects are pre-staged in AD DS.
When you create an Active Directory-detached cluster, the cluster network name (also known as the administrative access point) and network names for any clustered roles with client access points are registered in Domain Name System (DNS). However, no computer objects are created for the cluster in AD DS. This includes the computer object for the cluster (also known as the cluster name object or CNO) and computer objects for any clustered roles that would typically have client access points in AD DS (also known as virtual computer objects or VCOs).
Deployment Considerations
An Active Directory-detached cluster uses Kerberos authentication for intracluster communication. However, when authentication against the cluster network name is required, the cluster uses NTLM (NT LAN Manager) authentication. Therefore, we do not recommend this deployment method for any scenario that requires Kerberos authentication.
DEPLOYMENT CONSIDERATIONS | ||
Cluster Workload | Supported/Not Supported | More Information |
SQL Server | Supported | We recommend that you use SQL Server Authentication for Active Directory-detached cluster deployment. |
File server | Supported, but not recommended | Kerberos authentication is the preferred authentication protocol for Server Message Block (SMB) traffic. |
Hyper-V | Supported, but not recommended | Live migration is not supported because it has a dependency on Kerberos authentication.
Quick migration is supported. |
Message Queuing (also known as MSMQ) | Not supported | Message Queuing stores properties in AD DS. |
Deploy An Active Directory-Detached Cluster
- All servers must be joined in the same azure active directory domain.
- All servers must have a failover clustering feature installed.
- All servers must have passed the cluster validation rules.
- All servers must have supported the hardware and collection of servers.
To deploy an Active Directory-detached cluster, you must use Windows PowerShell. You cannot use Failover Cluster Manager. To create the failover cluster, start Windows PowerShell as an administrator, and then use the New-Cluster cmdlet with the –AdministrativeAccessPoint parameter set to a value of DNS.
The following example creates a failover cluster (Cluster1) from two nodes (Node1 and Node2), with an administrative access point of type DNS.
New-Cluster Cluster1 –Node Node1,Node2 –StaticAddress 192.168.1.16 -NoStorage –AdministrativeAccessPoint Dns
By using the following PowerShell command to verify the type of administrative access point for a failover cluster:
(Get-Cluster).AdministrativeAccessPoint
Related/References
- Exam DP-300: Microsoft Azure Database Administrator Associate
- Microsoft Certified Azure Database Administrator Associate(Hands-On Labs)
- Azure SQL Deployment Options | SQL Managed Instance | SQL Database| SQL On VM
- Migrate SQL Server To Azure SQL Database
- Implement A High Availability And Disaster Recovery Environment
- Use External Table On Azure SQL Managed Instance To Read Data From Azure SQL Database
- Optimize Query Performance In SQL Server
Next Task For You
We will cover all the exam objectives related to how to perform migrations, Hands-On Labs, and practice tests in our Azure Database Administrator training program. If you want to begin your journey towards becoming a Microsoft Certified: Azure Database Administrator Associate by checking our FREE CLASS.
Leave a Reply