Session 5: Configuring AlwaysOn Availability Groups
Applies To: Windows Azure
This article is the fifth of six that explain how to deploy a SharePoint farm on Windows Azure Infrastructure Services. For general information about this series, see Installing SharePoint 2013 on Windows Azure Infrastructure Services. To go to the previous session, see Session 4: Configuring a SharePoint Machine. To go to the next session, see Session 6: Creating Availability Groups on Virtual Machines.
Configuring AlwaysOn Availability Groups
SharePoint relies on SQL Server to store data for user sites and applications. Because of this reliance on data, it is recommended that you implement the AlwaysOn feature. On Windows Azure Virtual Machines, the feature enables high availability.
|It is important to understand how the failover system works. Without an understanding, your system could fail without a backup. For an overview of the options, see High Availability and Disaster Recovery for SQL Server in Windows Azure Virtual Machines.|
The procedures here are based on Test Lab: Create an AlwaysOn Availability Group in Windows Azure End-to-End. A tutorial that uses PowerShell to accomplish the same tasks is found in Tutorial: AlwaysOn Availability Groups in Windows Azure
For troubleshooting the configuration, see Troubleshoot AlwaysOn Availability Groups Configuration (SQL Server)
Enabling Failover Clustering
AlwaysOn relies on the Windows Server feature Windows Server Failover Clustering (WSFC). The feature allows several machines to participate as a group in a cluster, also known as a a node. When one machine fails, a second machine is ready to take its place. (These high-level details are purposefully simple.) Therefore the first task is to enable the Failover Clustering feature on all of the participating machines. In this scenario, enable the feature on three VMs:
The failover cluster requires at least three VMs. Two machines host SQL Server. The second VM is a synchronous secondary replica, ensuring zero data loss if the primary machine fails. The third machine does not need to host SQL Server (although it could). In this scenario, the third machine functions as a quorum witness in the WSFC. Because the WSFC cluster relies on a quorum to monitor health, there must always be a majority to ensure that the WSFC cluster is online. If only two machines are in a cluster, and one fails, there can be no majority when only one out of two fails. For more information, see WSFC Quorum Modes and Voting Configuration (SQL Server).
To add the Failover Clustering feature to a Virtual Machine
Log on to the Virtual Machine as a member of the Domain Admins (for example, sp_install).
Open the Server Manager.
In the left pane, right-click the Features node and click Add Features.
Select Failover Clustering and click Next.
In the Confirm Installation Selections page, click Install.
When the Results page appears, click the Close button.
Creating a Windows Server Failover Cluster (WSFC)
Due to current non-RFC-compliant behavior by the DHCP in Windows Azure, creation of a WSFC cluster can fail. For details, search for "WSFC cluster behavior in Windows Azure networking" in High Availability and Disaster Recovery for SQL Server in Windows Azure Virtual Machines. However, there is a workaround. To create a cluster, execute the following high-level tasks, on one machine, in the specified order:
Create a single-node cluster on the primary SQL machine.
Change the IP address of the cluster to an unused IP address.
Bring the cluster name online.
Remove the resource that contains the changed IP address.
Add the other nodes (VMs with the WSFC feature enabled).
Create a single-node cluster on the principal SQL machine
Log on to the primary SQL Server host. Use the same identity used to enable clustering on the virtual machines: sp_install.
Open Server Manager and then expand the Features node. Right-click Failover Cluster Manager and click Create a cluster.
In the Create Cluster Wizard, click Next. Type the name of the principal SQL Server machine, and click Add.
In the Validation Warning page, click No, I do not require support from Microsoft for this cluster, and therefore do not want to run the validation tests. When I click Next, continue creating the cluster. Then, click Next.
In the Cluster Name text box, type Cluster1, then click Next.
In the Confirmation page, click Next to begin cluster creation. Once the cluster is created, click Finish.
In Server Manager, expand Failover Cluster Manager, then click Cluster1.< domainName>.com, then scroll down in the center pane, and expand Cluster Core Resources. The Name and IP Address resources appear in the Failed state. The IP address resource cannot be brought online because the cluster is assigned the same IP address as that of the machine itself. The result is a duplicate address. Right-click the failed IP Address resource and then click Properties.
In the IP Address Properties box, in the Adress box, type in 10.10.2.101. Then click OK,
In the Cluster Core Resources section, right-click Name: Cluster1 and click Bring this resource online. Wait until both resources are online. When the cluster name resource comes online, it updates the DC server with a new Active Directory (AD) computer account. This AD account is later used to run the availability group clustered service.
Now that the AD account is created, bring the cluster name offline. Right-click the Name: Cluster1 resource and click Take this resource offline. In the pop-up confirmation dialog, click Take Name: Cluster1 offline.
Remove the cluster IP address. Right-click IP Address: 10.10.2.101 and click Delete. The Name: Cluster1 resource can no long come online because it depends on the IP address resource. However, an availability group does not depend on the cluster name or IP address in order to work properly. So the cluster name can be left offline.
Add the remaining nodes to the cluster. In the browser tree, right-click Cluster1. <domainName>.com and click Add Node.
In the Add Node Wizard, click Next. In the Select Servers page, add all the machines that will participate in the cluster. For the current scenario, add:
Backup SQL Server Host
If a machine cannot be added, and the error message is "the Remote Registry is not running," do the following. Log on to the machine, open the Services snap-in (services.msc), and enable the Remote Registry. For more information, see Unable to connect to Remote Registry service.
After adding the two machines, click Next.
- Backup SQL Server Host
In the Validation Warning page, click No, I do not require support from Microsoft for this cluster, and therefore do not want to run the validation tests. When I click Next, continue creating the cluster. Then click Next twice to add the nodes. Once the nodes are added to the cluster, click Finish.
The Failover Cluster Manager should now show that your cluster has three nodes, and lists them in the Nodes container.
Create an Availability Group
The next step is to create an Availability Group using the SQL Server Configuration Manager, and SQL Server Management Studio.
|An availability group in SQL Server differs from a Windows Azure Availability Set. The Availability Group contains databases that are highly-available and recoverable. The Availability Set allocates Virtual Machines to different fault domains. For more information about fault domains, see Manage the Availability of Virtual Machines. For a list of availability sets to create, see Creating Availability Sets.|
To enable Availability Groups on SQL Server
Log on to the primary SQL Server host as sp_farm_db@<domainName>.com. The user must have sysadmin rights on the SQL Server instance.
On the Start menu, type SQL Server Configuration Manager. Open the application.
In the left pane, select SQL Server Services
In the list that appears, double-click SQL Server (MSSQLSERVER).
In the SQL Server (MSSQLSERVER) Properties dialog, click AlwaysOn HighAvailability.
Click the AlwaysOn High Availability tab, then select Enable AlwaysOn Availability Groups, and then click Apply. Click OK in the pop-up dialog, and do not close the properties window yet. You will restart the SQL Server service after you change the service account.
Next, change the SQL Server service account. Click the Log On tab, then type <DomainName>\sqlservice in Account Name. Fill in and confirm the password, and then click OK.
In the pop-up window, click Yes to restart the SQL Server service.
Log on to the second SQL Server host VM, and repeat the process.
To continue the deployment, see Session 6: Creating Availability Groups on Virtual Machines.