[SQL in Azure] Tutorial: AlwaysOn Availability Groups in Azure (GUI)

http://msdn.microsoft.com/en-us/library/azure/dn249504.aspx

Tutorial: AlwaysOn Availability Groups in Azure (GUI)

28 out of 55 rated this helpful - Rate this topic

Updated: October 23, 2013

Note

For the PowerShell-based tutorial of the same scenario, see Tutorial: AlwaysOn Availability Groups in Azure (PowerShell).

Azure virtual machines (VMs) can help database administrators to implement lower the cost of a high availability SQL Server system. This tutorial shows you how to implement an availability group using SQL Server AlwaysOn end-to-end inside an Azure environment. At the end of the tutorial, your SQL Server AlwaysOn solution in Azure will consist of the following elements:

• Four VMs are deployed in the same affinity group, virtual network, subnet, and cloud service and use the same storage account
  
  
• One VM is the domain controller (DC) server
  
  
• The remaining three VMs form a three-node Windows Server Failover Clustering (WSFC) cluster and are deployed in the same subnet and availability set
  
  
• Two of the WSFC nodes contain SQL Server instances and host an availability group with an availability database
  
  

The figure below is a graphical representation of the solution.

This scenario is chosen for its simplicity, not for its cost effectiveness or other factors on Azure. For example, you can minimize the number of VMs for a two-replica availability group in order to save on compute hours in Azure by using the domain controller as the quorum file share witness in a 2-node WSFC cluster. This method reduces the VM count by one from the above configuration.

This tutorial assumes the following:

• You already have an Azure account with the virtual machine subscription.
  
  
• You already know how to provision a SQL Server VM from the virtual machine gallery using the GUI. For more information, see Provisioning a SQL Server Virtual Machine on Azure
  
  
• You already have a solid understanding of AlwaysOn Availability Groups for on-premise solutions. For more information, see AlwaysOn Availability Groups (SQL Server).
  
  

Below is the outline of the steps:

1. Create the Virtual Network and Domain Controller Server
   
   
2. Configure the Domain Controller
   
   
3. Create the SQL Server VMs
   
   
4. Create the WSFC Cluster
   
   
5. Prepare the SQL Server Instances for Availability Group
   
   
6. Create the Availability Group
   
   

Create the Virtual Network and Domain Controller Server

You begin with a new Azure trial account. Once you have finished your account setup, you should be in the home screen of the Azure portal.

1. Click the New button at the lower-left corner of the page, as shown below.

   

2. Click Network, then click Virtual Network, and then click Custom Create, as shown below.

   

3. In the CREATE A VIRTUAL NETWORK dialog, create a new virtual network by stepping through the pages with the settings below.

    

   Page	Settings
   Virtual Network Details	NAME = ContosoNET REGION = West US AFFINITY GROUP NAME = ContosoAG
   DNS Servers and VPN Connectivity	None
   Virtual Network Address Spaces	Settings are shown in the screenshot below:

4. Next, you create a new storage account you will use to store the VHD files of the VMs. Click New again, then Data Services, then Storage, and then Quick Create, as shown below.

   

   Specify URL and Location/Affinity Group and click Create Storage Account as shown below. It may take some time for the storage account to be created.

   • URL = A unique URL
     
     
   • LOCATION/AFFINITY GROUP = ContosoAG
     
     

5. Next, you create the VM you will use as the domain controller (DC). Click New again, then Compute, then Virtual Machine, and then From Gallery, as shown below.

   

6. In the CREATE A VIRTUAL MACHINE dialog, configure a new VM by stepping through the pages with the settings below.

    

   Page	Settings
   Select the virtual machine operating system	Windows Server 2008 R2 SP1
   Virtual machine configuration	VERSION RELEASE DATE = (latest) VIRTUAL MACHINE NAME = ContosoDC SIZE = Medium NEW USER NAME = AzureAdmin NEW PASSWORD = Contoso!000 CONFIRM = Contoso!000
   Virtual machine mode	DNS NAME = A unique name STAND-ALONE VIRTUAL MACHINE = Selected STORAGE ACCOUNT = REGION/AFFINITY GROUP/VIRTUAL NETWORK = ContosoNET VIRTUAL NETWORK SUBNETS = Back(10.10.2.0/24)
   Virtual machine options	Use defaults

   Once you finish configuring the new VM, wait for the VM to be provisioned. This process takes some time to complete, and if you click to the Virtual Machine tab in the Azure portal, you can see ContosoDC cycling states from Starting (Provisioning) to Stopped, Starting, Running (Provisioning), and finally Running.

7. Once ContosoDC is provisioned, click the Connect button to download the remote desktop (RDP) file to your local directory.

The DC server is now successfully provisioned. Next, you will configure the Active Directory domain on this DC server. Leave the PowerShell window open on your local computer. You will use it again later to create the two SQL Server VMs.

Configure the Domain Controller

1. Next, you configure ContosoDC as a DC server for corp.contoso.com. Launch the RDP file for ContosoDC and log in using your configured administrator account (AzureAdmin) and password (Contoso!000).

2. After you log in, run dcpromo from the Start menu, as shown below.

   

3. In the Active Directory Domain Services Installation Wizard dialog, configure a new domain controller by stepping through the pages with the settings below.

    

   Page	Settings
   Welcome	Use defaults
   Operating System Compatibility	Use defaults
   Choose a Deployment Configuration	Create a new domain in a new forest = Selected
   New of the Forest Root Domain	FQDN of the forest root domain = corp.contoso.com
   Domain NetBIOS Name	Use defaults
   Set Forest Functional Level	Forest functional level = Windows Server 2008 R2
   Additional Domain Controller Options	DNS server = Selected
   (Pop-Up Window: Static IP Assignment)	Yes, the computer will use an IP address automatically assigned by a DHCP server (not recommended). = Selected
   (Pop-up window)	Do you want to continue? = Yes
   Location for Database, Log Files, and SYSVOL	Use defaults
   Directory Services Restore Mode Administrator Password	Password = Contoso!000 Confirm Password = Contoso!000

   After the DC server is provisioned, the VM restarts automatically.

4. Next, you configure Active Directory (AD) with the accounts you will use later. Launch the RDP file for ContosoDC again using the default domain administrator (CORPAzureAdmin) and password (Contoso!000).

5. Once you log in, open Active Directory Users and Computers from the Start menu, as shown below.

   

6. Expand corp.contoso.com, then right-click Users, then point to New, then click User.

7. Specify a user named Install as shown below and click Next.

8. Specify and confirm the account password (for example, Contoso!000), then select the check boxes as shown below, and then click Next.

   • User must change password at next logon = Cleared
     
     
   • Password never expires = Selected
     
     

9. Click Finish. You have now created CORPInstall in AD. You will use this account to configure the failover cluster and the availability group.

10. Following the same steps, create two additional accounts: CORPSQLSvc1 and CORPSQLSvc2. You will use them as service accounts for the SQL Server instances.

    Next, you need to give CORPInstall the necessary permissions for configuring Windows Service Failover Clustering (WSFC).

11. In the View menu, click Advanced Features, as shown below. This action lets you see all the hidden containers, as well as hidden tabs in the properties windows for AD objects.

    

12. Right-click corp.contoso.com and click Properties.

13. In corp.contos.com Properties, select the Security tab, then click the Advanced button.

14. In Advanced Security Settings for corp, click Add.

15. Type CORPInstall in the text box and click OK.

16. Select Allow for Read all properties and Create Computer objects as shown below, then click OK three times to exit corp.contoso.com Properties.

    

Now that you have finished configuring Active Directory and the user objects, you will create three SQL Server VMs and join them to this domain.

Create the SQL Server VMs

1. Next, you create the three VMs you will use which includes a WSFC cluster node and two SQL Server VMs. To create each of the VMs, go back to the Azure portal, then click New, then Compute, then Virtual Machine, and then From Gallery. Then, use the templates in the following table to help you create the VMs.

    

   Page	VM1	VM2	VM3
   Select the virtual machine operating system	Windows Server 2008 R2 SP1	SQL Server 2012 SP1 Enterprise on Windows Server 2008 R2 SP1	SQL Server 2012 SP1 Enterprise on Windows Server 2008 R2 SP1
   Virtual machine configuration	VERSION RELEASE DATE = (latest) VIRTUAL MACHINE NAME = ContosoWSFCNode SIZE = Medium NEW USER NAME = AzureAdmin NEW PASSWORD = Contoso!000 CONFIRM = Contoso!000	VIRTUAL MACHINE NAME = ContosoSQL1 SIZE = Large NEW USER NAME = AzureAdmin NEW PASSWORD = Contoso!000 CONFIRM = Contoso!000	VIRTUAL MACHINE NAME = ContosoSQL2 SIZE = Large NEW USER NAME = AzureAdmin NEW PASSWORD = Contoso!000 CONFIRM = Contoso!000
   Virtual machine mode	CONNECT TO AN EXISTING VIRTUAL MACHINE = Selected (ContosoDC) STORAGE ACCOUNT = the storage account you created REGION/AFFINITY GROUP/VIRTUAL NETWORK = ContosoNET VIRTUAL NETWORK SUBNETS = Back(10.10.2.0/24)	CONNECT TO AN EXISTING VIRTUAL MACHINE = Selected (ContosoDC) STORAGE ACCOUNT = the storage account you created REGION/AFFINITY GROUP/VIRTUAL NETWORK = ContosoNET VIRTUAL NETWORK SUBNETS = Back(10.10.2.0/24)	CONNECT TO AN EXISTING VIRTUAL MACHINE = Selected (ContosoDC) STORAGE ACCOUNT = the storage account you created REGION/AFFINITY GROUP/VIRTUAL NETWORK = ContosoNET VIRTUAL NETWORK SUBNETS = Back(10.10.2.0/24)
   Virtual machine options	AVAILABILITY SET = Create an availability set AVAILABILITY SET NAME = SQLHADR	AVAILABILITY SET = SQLHADR	AVAILABILITY SET = SQLHADR

   When you select CONNECT TO AN EXISTING VIRTUAL MACHINE and select ContosoDC (the only choice), it is the same as telling Azure to place the VM in the same cloud service as ContosoDC. Again, this cloud service name is unique on the internet.

   Once the three VMs are fully provisioned, you need to join them to the corp.contoso.com domain and grant CORPInstall administrative rights to the machines. To do this, follow the steps below for each of the three VMs.

2. Download each VM's remote desktop (RDP) file to your local directory by selecting the VM in the list and clicking the Connect button. To select a VM, click anywhere but the first cell in the row, as shown below.

   

3. Launch the RDP file you downloaded and log into the VM using your configured administrator account (BUILTINAzureAdmin).

4. Once you are logged in, the Initial Configuration Tasks window is automatically launched. Click the Configure networking link.

5. The Network Connections window is opened. Right-click Local Area Connection 2 and click Properties.

6. Select Internet Protocol Version 4 (TCP/IPv4) and click Properties.

7. Select Use the following DNS server addresses and specify 10.10.2.4 in Preferred DNS server.

8. The address 10.10.2.4 is the address assigned to a VM in the 10.10.2.0/24 subnet in an Azure virtual network, and that VM is ContosoDC. To verify ContosoDC's IP address, use the nslookup contosodc in the command prompt, as shown below.

   

9. Click OK twice to commit the changes. You are now able to join the VM to corp.contoso.com.

10. Back in the Initial Configuration Tasks, click the Provide computer name and domain link.

11. In the System Properties dialog, click Change.

12. Select the Domain check box and type corp.contoso.com in the text box, then click OK.

13. In the Windows Security popup dialog, specify the credentials for the default domain administrator account (CORPAzureAdmin) and the password Contoso!000.

14. When you see the "Welcome to the corp.contoso.com domain" message, click OK.

15. In Computer Name/Domain Changes, click OK, then click OK in the popup dialog.

16. Wait until the VM is restarted, then launch the RDP file again to log into the VM using the BUILTINAzureAdmin account.

17. In the Start menu, type "user", then click Give administrative rights to a domain user, as shown below.

    

18. In the User Accounts dialog, click Add.

19. In Add New User, specify Install in User name and CORP in Domain, then click Next.

20. Select Administrator to add the CORPInstall to the local Administrators group, then click Finish, and then click OK to close the User Accounts dialog.

21. Next, you add the Failover Clustering feature to the VM. In the Initial Configuration Tasks window, click Add features.

22. In the Add Features Wizard, select Failover Clustering as shown below and click Next.

    

23. In Confirm Installation Selections, click Install.

24. When the Failover Clustering feature installation is completed, click Close.

25. Log out of the VM.

The SQL Server VMs are now provisioned and running, but they are installed with SQL Server with default options.

Create the WSFC Cluster

In this section, you create the WSFC cluster that will host the availability group you will create later. By now, you should have done the following to each of the three VMs you will use in the WSFC cluster:

• Fully provisioned in Azure
  
  
• Joined VM to the domain
  
  
• Added CORPInstall to the local Administrators group
  
  
• Added the Failover Clustering feature
  
  

All these are prerequisites on each VM before you can join it to the WSFC cluster.

Also, note that the Azure virtual network does not behave in the same way as an on-premise network, you need to create the cluster in the following order:

1. Create a single-node cluster on one of the nodes (ContosoSQL1)
   
   
2. Modify the cluster IP address to an unused IP address (10.10.2.101)
   
   
3. Bring the cluster name online
   
   
4. Add the other nodes (ContosoSQL2 and ContosoWSFCNode)
   
   

Finally, you are ready to move on. Follow the steps below to fully configure the cluster.

1. Launch the RDP file for ContosoSQL1 and log in using the credentials for CORPInstall.

2. Open Server Manager, then expand the Features node, then right-click Failover Cluster Manager, and then click Create a Cluster, as shown below.

   

3. In the Create Cluster Wizard, create a one-node cluster by stepping through the pages with the settings below:

    

   Page	Settings
   Before You Begin	Use defaults
   Select Servers	Type ContosoSQL1 in Enter server name and click Add
   Validation Warning	Select 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.
   Access Point for Administering the Cluster	Type Cluster1 in Cluster Name
   Confirmation	Use defaults

4. In Server Manager, expand Failover Cluster Manager, then click Cluster1.corp.contoso.com, then scroll down in the center pane, and then expand Cluster Core Resources. You should see both the Name and the IP Address resources 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, which is a duplicate address. Right-click the failed IP Address resource, and then click Properties, as shown below.

   

5. Select Static IP Address and specify 10.10.2.101 in the Address text box, as shown below. Then, click OK.

6. In the Cluster Core Resources section, right-click Name: Cluster1 and click Bring this resource online. Then, wait until both resources are online. When the cluster name resource comes online, it updates the DC server with a new AD computer account. This AD account will be used to run the availability group clustered service later.

7. Finally, you add the remaining nodes to the cluster. In the browser tree, right-click Cluster1.corp.contoso.com and click Add Node, as shown below.

   

8. In the Add Node Wizard, click Next. Then, in the Select Servers page, add ContosoSQL2 and ContosoWSFCNode to the list by typing the server name in Enter server name and then clicking Add. When you are done, click Next.

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

   Failover Cluster Manager should now show that your cluster has three nodes and list them in the Nodes container, as shown below.

   

10. Log out of the remote desktop session.

Prepare the SQL Server Instances for Availability Group

In this section, you will do the following on both ContosoSQL1 and contosoSQL2:

1. Add a login for NT AUTHORITYSystem with a necessary permissions set to the default SQL Server instance
   
   
2. Add CORPInstall as a sysadmin role to the default SQL Server instance
   
   
3. Open the firewall for remote access of SQL Server
   
   
4. Enable the AlwaysOn Availability Groups feature
   
   
5. Change the SQL Server service account to CORPSQLSvc1 and CORPSQLSvc2, respectively
   
   

The actions above can be performed in any order. Nevertheless, the steps below will walk through them in order. Follow the steps for both ContosoSQL1 and ContosoSQL2:

1. If you have not logged out of the remote desktop session for the VM, do so now.

2. Launch the RDP file for the VM and log in as BUILTINAdministrator.

3. First, you add NT AUTHORITYSystem to the SQL Server logins and with necessary permissions. From the Start menu, launch SQL Server Management Studio.

4. Click Connect to connect to the default SQL Server instance.

5. In Object Explorer, expand Security, right-click Logins, and click New Login.

6. Type NT AUTHORITYSystem in Login name and click OK.

7. In Object Explorer, right-click NT AUTHORITYSystem and click Properties.

8. In the Securables page, for the local server, select Grant for the following permissions and click OK.

   • Alter any availability group
     
     
   • Connect SQL
     
     
   • View server state
     
     

9. Next, you add CORPInstall as a sysadmin role to the default SQL Server instance. In Object Explorer, right-click Logins again and click New Login.

10. Type CORPInstall in Login name.

11. In the Server Roles page, select sysadmin. Then, click OK. Once the login is created, you can see it by expanding Logins in Object Explorer.

12. Next, you create a firewall rule for SQL Server. From the Start menu, launch Windows Firewall with Advanced Security, as shown below.

    

13. Right-click Inbound Rules and click New Rule.

14. In the Rule Type page, select Program, then click Next.

15. In the Program page, select This program path and type %ProgramFiles%Microsoft SQL ServerMSSQL11.MSSQLSERVERMSSQLBinnsqlservr.exe in the text box. Then, click Next.

16. In the Action page, keep Allow the connection selected and click Next.

17. In the Profile page, accept the default settings and click Next.

18. In the Name page, specify a rule name, such as SQL Server (Program Rule) in the Name text box, then click Finish.

19. Next, you enable the AlwaysOn Availability Groups feature. From the Start menu, launch SQL Server Configuration Manager.

20. In the browser tree, click SQL Server Services, then right-click the SQL Server (MSSQLSERVER) service and click Properties.

21. Click the AlwaysOn High Availability tab, then select Enable AlwaysOn Availability Groups, as shown below, 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.

    

22. Next, you change the SQL Server service account. Click the Log On tab, then type CORPSQLSvc1 (for ContosoSQL1) or CORPSQLSvc2 (for ContosoSQL2) in Account Name, then fill in and confirm the password, and then click OK.

23. In the pop-up window, click Yes to restart the SQL Server service. After the SQL Server service is restarted, the changes you made in the properties window are effective.

24. Log out of the VM.

Create the Availability Group

You are now ready to configure an availability group. Below is an outline of what you will do:

1. Create a new database (MyDB1) on ContosoSQL1
   
   
2. Take both a full backup and a transaction log backup of the database
   
   
3. Restore the full and log backups to ContosoSQL2 with the NORECOVERY option
   
   
4. Create the availability group (AG1) with synchronous commit, automatic failover, and readable secondary replicas
   
   

Follow the instructions below:

1. If you have not already logged out of the remote desktop sessions for ContosoSQL1 and ContosoSQL2, do so now.

2. Launch the RDP file for ContosoSQL1 and log in as CORPInstall.

3. In File Explorer, under C:, create a directory called backup. You will use this directory use to back up and restore your database.

4. Right-click the new directory, point to Share with, and then click Specific people, as shown below.

   

5. Add CORPSQLSvc1 and give it the Read/Write permission, then add CORPSQLSvc2 and give it the Read permission, as shown below, and then click Share. Once the file sharing process is complete, click Done.

   

6. Next, you create the database. From the Start menu, launch SQL Server Management Studio, then click Connect to connect to the default SQL Server instance.

7. In the Object Explorer, right-click Databases and click New Database.

8. In Database name, type MyDB1, then click OK.

9. Next, you take a full backup of the database. In the Object Explorer, expand Databases, then right-click MyDB1, then point to Tasks, and then click Back Up.

10. In the Source section, keep Backup type set to Full. In the Destination section, click Remove to remove the default file path for the backup file.

11. In the Destination section, click Add.

12. In the File name text box, type \ContosoSQL1ackupMyDB1.bak. Then, click OK, and then click OK again to backup the database. When the backup operation completes, click OK again to close the dialog.

13. Next, you take a transaction log backup of the database. In the Object Explorer, expand Databases, then right-click MyDB1, then point to Tasks, and then click Back Up.

14. In Backup type, select Transaction Log. Keep the Destination file path set to the one you specified earlier and click OK. Once the backup operation completes, click OK again.

15. Next, you restore the full and transaction log backups on ContosoSQL2. Launch the RDP file for ContosoSQL2 and log in as CORPInstall. Leave the remote desktop session for ContosoSQL1 open.

16. From the Start menu, launch SQL Server Management Studio, then click Connect to connect to the default SQL Server instance.

17. In the Object Explorer, right-click Databases and click Restore Database.

18. In the Source section, select Device, and click the … button.

19. In Select backup devices, click Add.

20. In Backup file location, type \ContosoSQL1ackup, then click Refresh, then select MyDB1.bak, then click OK, and then click OK again. You should now see the full backup and the log backup in the Backup sets to restore pane.

21. Go to the Options page, then select RESTORE WITH NORECOVERY in Recovery state, and then click OK to restore the database. Once the restore operation completes, click OK.

22. Now, you create an availability group. Go back to the remote desktop session for ContosoSQL1. In the Object Explorer in SSMS, right-click AlwaysOn High Availability and click New Availability Group Wizard, as shown below.

    

23. In the Introduction page, click Next. In the Specify Availability Group Name page, type AG1 in Availability group name, then click Next again.

    

24. In the Select Databases page, select MyDB1 and click Next. The database meets the prerequisites for an availability group because you have taken at least one full backup on the intended primary replica.

    

25. In the Specify Replicas page, click Add Replica.

    

26. The Connect to Server dialog pops up. Type ContosoSQL2 in Server name, then click Connect.

    

27. Back in the Specify Replicas page, you should now see ContosoSQL2 listed in Available Replicas. Configure the replicas as shown below. When you are finished, click Next.

    

28. In the Select Initial Data Synchronization page, select Join only and click Next. You have already performed data synchronization manually when you took the full and transaction backups on ContosoSQL1 and restored them on ContosoSQL2. You can instead choose not to perform the backup and restore operations on your database and select Full to let the New Availability Group Wizard perform data synchronization for you. However, this is not recommended for very large databases that are found in some enterprises.

    

29. In the Validation page, click Next. This page should look similar to below. There is a warning for the listener configuration because you have not configured an availability group listener. I intentionally skipped that step because availability group listeners are not currently supported in Azure VMs.

    

30. In the Summary page, click Finish, then wait while the wizard configures the new availability group. In the Progress page, you can click More details to view the detailed progress. Once the wizard is finished, inspect the Results page to verify that the availability group is successfully created, as shown below, then click Close to exit the wizard.

    

31. In the Object Explorer, expand AlwaysOn High Availability, then expand Availability Groups. You should now see the new availability group in this container. Right-click AG1 (Primary) and click Show Dashboard.

    

    Your AlwaysOn Dashboard should look similar to the one shown below. You can see the replicas, the failover mode of each replica and the synchronization state.

    

32. From the Start menu, open Server Manager again, then expand Features, then expand Failover Cluster Manager, then expand Cluster1.corp.contoso.com, and then expand Services and applications. A new clustered service called AG1 has been created in Cluster1 to represent the availability group that you just configured. Note that AG1 does not have any IP address by which database clients can connect to the availability group, because you did not configure one and because that IP address would not work even if you configured it since the Azure virtual network does not support static IP addresses.

    

    Warning

    Do not try to fail over this clustered service. All failover operations should be performed from within AlwaysOn Dashboard in SSMS. For more information, see Restrictions on Using The WSFC Failover Cluster Manager with Availability Groups

You have now successfully implemented SQL Server AlwaysOn by creating an availability group in Azure. To configure a listener for this availability group, see Tutorial: Listener Configuration for AlwaysOn Availability Groups in Azure.