Export (0) Print
Expand All

Phase 5: Enable AlwaysOn Availability Groups

Updated: November 10, 2014

[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]

This is the fifth phase of deploying SharePoint with SQL Server AlwaysOn in Azure, which includes enabling failover clustering and SQL Server AlwaysOn Availability Groups. You must complete this phase before moving on to Phase 6.

For the previous phase, see Phase 4: Configure SharePoint Servers.

For the final phase, see Phase 6: Create an Availability Group.

For all of the phases of this deployment, see Deploying SharePoint 2013 with SQL Server AlwaysOn Availability Groups in Azure.

This deployment of SharePoint with SQL Server AlwaysOn is designed to accompany the SharePoint with SQL Server AlwaysOn Infographic and incorporate the latest recommendations.

The following figure shows the configuration resulting from the successful completion of this phase.

SharePoint 2013 in Windows Azure

Enabling 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 Availability Group feature. On 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 Azure Virtual Machines.

The procedures here are based on Test Lab: Create an AlwaysOn Availability Group in Azure End-to-End. A tutorial that uses PowerShell to accomplish the same tasks is found in Tutorial: AlwaysOn Availability Groups in Azure

To troubleshoot the configuration, see Troubleshoot AlwaysOn Availability Groups Configuration (SQL Server)

Enabling Failover Clustering

SQL Server AlwaysOn Availability Groups relies on the Windows Server Failover Clustering (WSFC) feature of Windows Server. The feature allows several machines to participate as a group in a cluster. When one machine fails, another 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:

  • SQL1

  • SQL2

  • MN1

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 (example name MN1), functions as a quorum witness in the WSFC, also known as a majority node. 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

  1. Log on to the Virtual Machine as a member of the Domain Admins (for example, sp_install).

  2. Open the Server Manager.

  3. In the left pane, right-click the Features node and click Add Features.

    Add Features to Windows Server
  4. Select Failover Clustering and click Next.

    Select Failover Clustering
  5. In the Confirm Installation Selections page, click Install.

  6. 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 Azure, creation of a WSFC cluster can fail. For details, search for "WSFC cluster behavior in Azure networking" in High Availability and Disaster Recovery for SQL Server in 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:

  1. Create a single-node cluster on the primary SQL machine.

  2. Change the IP address of the cluster to an unused IP address.

  3. Bring the cluster name online.

  4. Remove the resource that contains the changed IP address.

  5. Add the other nodes (VMs with the WSFC feature enabled).

Create a single-node cluster on the primary SQL machine

  1. Log on to the primary SQL Server host. Use the same identity used to enable clustering on the virtual machines: sp_install.

  2. Open Server Manager and then expand the Features node. Right-click Failover Cluster Manager and click Create a cluster.

    In Server Manager, click Create a Cluster....
  3. In the Create Cluster Wizard, click Next. Type the name of the primary SQL Server machine, and click Add.

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

  5. In the Cluster Name text box, type Cluster1, then click Next.

  6. In the Confirmation page, click Next to begin cluster creation. Once the cluster is created, click Finish.

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

    Cluster Core Resources
  8. In the IP Address Properties box, in the Address box, type in Then click OK,

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

    Cluster Online
  10. 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.

  11. Remove the cluster IP address. Right-click IP Address: 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.

  12. Add the remaining nodes to the cluster. In the browser tree, right-click Cluster1. <domainName>.com and click Add Node.

  13. 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:

    • Secondary SQL server

    • Cluster majority node

    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.

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

Enable AlwaysOn Availability Groups

The next step is to enable AlwaysOn Availability Groups using the SQL Server Configuration Manager and SQL Server Management Studio.

An availability group in SQL Server differs from an Azure Availability Set. The Availability Group for SQL Server contains databases that are highly-available and recoverable. The Availability Set for Azure allocates virtual machines to different fault domains. For more information about fault domains, see Manage the Availability of Virtual Machines.

To enable AlwaysOn Availability Groups on SQL Server

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

  2. On the Start menu, type SQL Server Configuration Manager. Open the application.

  3. In the left pane, select SQL Server Services

  4. In the list that appears, double-click SQL Server (MSSQLSERVER).

  5. In the SQL Server (MSSQLSERVER) Properties dialog, click AlwaysOn High Availability.

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

    Enable SQL Server AlwaysOn
  7. 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.

  8. In the pop-up window, click Yes to restart the SQL Server service.

  9. Log on to the secondary SQL Server VM, and repeat the process.

Next Steps

For the final phase of the deployment, see Phase 6: Create an Availability Group.

For all of the phases of this deployment, see Deploying SharePoint 2013 with SQL Server AlwaysOn Availability Groups in Azure.

Community Additions

© 2014 Microsoft