Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Prerequisites
The tutorial assumes you have a basic understanding of SQL Server Always On Availability
Groups. If you need more information, see Overview of Always On Availability Groups (SQL
Server).
The following table lists the prerequisites that you need to complete before starting this tutorial:
Requirement Description
- In an Azure availability set
Two SQL Servers - In a single domain
- With Failover Clustering feature installed
Windows Server File share for cluster witness
SQL Server service account Domain account
SQL Server Agent service
Domain account
account
Firewall ports open - SQL Server: 1433 for default instance
- Database mirroring endpoint: 5022 or any available port
- Availability group load balancer IP address health probe: 59999
or any available port
Requirement Description
- Cluster core load balancer IP address health probe: 58888 or any
available port
Add Failover Clustering
Both SQL Servers require this feature
Feature
- Local administrator on each SQL Server
Installation domain account - Member of SQL Server sysadmin fixed server role for each
instance of SQL Server
Before you begin the tutorial, you need to Complete prerequisites for creating Always On
Availability Groups in Azure Virtual Machines. If these prerequisites are completed already, you
can jump to Create Cluster.
Note
Many of the steps provided in this tutorial can now be automated with Azure SQL VM CLI and
Azure Quickstart Templates.
4. In the Create Cluster Wizard, create a one-node cluster by stepping through the pages with
the settings in the following table:
Page Settings
Before You Begin Use defaults
Type the first SQL Server name in Enter server name and click
Select Servers
Add.
Select No. I do not require support from Microsoft for this
Validation Warning cluster, and therefore do not want to run the validation tests.
When I click Next, continue Creating the cluster.
Access Point for
Type a cluster name, for example SQLAGCluster1 in Cluster
Administering the
Name.
Cluster
Use defaults unless you are using Storage Spaces. See the note
Confirmation
following this table.
2. In the Add Node Wizard, click Next. In the Select Servers page, add the second SQL
Server. Type the server name in Enter server name and then click Add. When you are
done, click Next.
3. In the Validation Warning page, click No (in a production scenario you should perform the
validation tests). Then, click Next.
4. In the Confirmation page if you are using Storage Spaces, clear the checkbox labeled Add
all eligible storage to the cluster.
Warning
If you are using Storage Spaces and do not uncheck Add all eligible storage to the cluster,
Windows detaches the virtual disks during the clustering process. As a result, they do not
appear in Disk Manager or Explorer until the storage spaces are removed from the cluster
and reattached using PowerShell. Storage Spaces groups multiple disks in to storage pools.
For more information, see Storage Spaces.
5. Click Next.
6. Click Finish.
Failover Cluster Manager shows that your cluster has a new node and lists it in the Nodes
container.
7. Log out of the remote desktop session.
7. In the Select Initial Data Synchronization page, select Full and specify a shared network
location. For the location, use the backup share that you created. In the example it was, \\
<First SQL Server>\Backup\. Click Next.
Note
Full synchronization takes a full backup of the database on the first instance of SQL Server
and restores it to the second instance. For large databases, full synchronization is not
recommended because it may take a long time. You can reduce this time by manually taking
a backup of the database and restoring it with NO RECOVERY. If the database is already
restored with NO RECOVERY on the second SQL Server before configuring the Availability
Group, choose Join only. If you want to take the backup after configuring the Availability
Group, choose Skip initial data synchronization.
8. In the Validation page, click Next. This page should look similar to the following image:
Note
There is a warning for the listener configuration because you have not configured an
Availability Group listener. You can ignore this warning because on Azure virtual machines
you create the listener after creating the Azure load balancer.
9. 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.
10.Click Close to exit the wizard.
You can see the replicas, the failover mode of each replica and the synchronization state.
2. In Failover Cluster Manager, click your cluster. Select Roles. The Availability Group
name you used is a role on the cluster. That Availability Group does not have an IP address
for client connections, because you did not configure a listener. You will configure the
listener after you create an Azure load balancer.
Warning
Do not try to fail over the Availability Group from the Failover Cluster Manager. All failover
operations should be performed from within AlwaysOn Dashboard in SSMS. For more
information, see Restrictions on Using The Failover Cluster Manager with Availability
Groups.
At this point, you have an Availability Group with replicas on two instances of SQL Server. You can
move the Availability Group between instances. You cannot connect to the Availability Group yet
because you do not have a listener. In Azure virtual machines, the listener requires a load balancer.
The next step is to create the load balancer in Azure.
Setting Field
Name Use a text name for the load balancer, for example sqlLB.
Type Internal
Virtual network Use the name of the Azure virtual network.
Subnet Use the name of the subnet that the virtual machine is in.
IP address
Static
assignment
Use an available address from subnet. Use this address for your
IP address availability group listener. Note that this is different from your cluster IP
address.
Subscription Use the same subscription as the virtual machine.
Location Use the same location as the virtual machine.
The Azure portal blade should look like this:
5. Click Create, to create the load balancer.
To configure the load balancer, you need to create a backend pool, a probe, and set the load
balancing rules. Do these in the Azure portal.
Add backend pool for the availability group listener
1. In the Azure portal, go to your availability group. You might need to refresh the view to see
the newly created load balancer.
2. Click the load balancer, click Backend pools, and click +Add.
3. Type a name for the backend pool.
4. Associate the backend pool with the availability set that contains the VMs.
5. Under Target network IP configurations, check VIRTUAL MACHINE and choose both
of the virtual machines that will host availability group replicas. Do not include the file share
witness server.
Note
If both virtual machines are not specified, connections will only succeed to the primary
replica.
6. Click OK to create the backend pool.
Add the cluster core IP address for the Windows Server Failover Cluster
(WSFC)
The WSFC IP address also needs to be on the load balancer.
1. In the portal, on the same Azure load balancer, click Frontend IP configuration and click
+Add. Use the IP Address you configured for the WSFC in the cluster core resources. Set
the IP address as static.
2. On the load balancer, click Health probes, and click +Add.
3. Set the WSFC cluster core IP address health probe as follows:
c. Under IP Address, click Static IP Address. Set the IP address as the same address that
you used when you set the load balancer address on the Azure portal.
5. Make the SQL Server availability group resource dependent on the client access point.
a. In Failover Cluster Manager, click Roles, and then click your availability group.
b. On the Resources tab, under Other Resources, right-click the availability resource
group, and then click Properties.
c. On the dependencies tab, add the name of the client access point (the listener) resource.
d. Click OK.
6. Make the client access point resource dependent on the IP address.
a. In Failover Cluster Manager, click Roles, and then click your availability group.
b. On the Resources tab, right-click the client access point resource under Server Name,
and then click Properties.
c. Click the Dependencies tab. Verify that the IP address is a dependency. If it is not, set a
dependency on the IP address. If there are multiple resources listed, verify that the IP
addresses have OR, not AND, dependencies. Click OK.
Tip
You can validate that the dependencies are correctly configured. In Failover Cluster
Manager, go to Roles, right-click the availability group, click More Actions, and then click
Show Dependency Report. When the dependencies are correctly configured, the
availability group is dependent on the network name, and the network name is dependent on
the IP address.
7. Set the cluster parameters in PowerShell.
a. Copy the following PowerShell script to one of your SQL Server instances. Update the
variables for your environment.
• $ListenerILBIP is the IP address that you created on the Azure load balancer for
the availability group listener.
• $ListenerProbePort is the port you configured on the Azure load balancer for
the availability group listener.
PowerShell
7. $ClusterNetworkName = "<MyClusterNetworkName>" # the cluster network name
(Use Get-ClusterNetwork on Windows Server 2012 of higher to find the name)
$IPResourceName = "<IPResourceName>" # the IP Address resource name
$ListenerILBIP = "<n.n.n.n>" # the IP Address of the Internal Load
Balancer (ILB). This is the static IP address for the load balancer you
configured in the Azure portal.
[int]$ListenerProbePort = <nnnnn>
Import-Module FailoverClusters
b. Set the cluster parameters by running the PowerShell script on one of the cluster nodes.
Note
If your SQL Server instances are in separate regions, you need to run the PowerShell script
twice. The first time, use the $ListenerILBIP and $ListenerProbePort from the
first region. The second time, use the $ListenerILBIP and $ListenerProbePort
from the second region. The cluster network name and the cluster IP resource name are also
different for each region.
8. Bring the availability group cluster role online. In Failover Cluster Manager under Roles,
right click the role, and select Start Role.
If necessary, repeat the steps above to set the cluster parameters for the WSFC cluster IP address.
1. Get the IP address name of the WSFC Cluster IP address. In Failover Cluster Manager
under Cluster Core Resources, locate Server Name.
2. Right-click IP Address, and select Properties.
3. Copy the Name of the IP address. It may be Cluster IP Address.
Import-Module FailoverClusters
Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple
@{"Address"="$ClusterCoreIP";"ProbePort"=$ClusterProbePort;"SubnetMask"="2
55.255.255.255";"Network"="$ClusterNetworkName";"EnableDhcp"=0}
b. Set the cluster parameters by running the PowerShell script on one of the cluster nodes.
Warning
The availability group listener health probe port has to be different from the cluster core IP address
health probe port. In these examples, the listener port is 59999 and the cluster core IP address is
58888. Both ports require an allow inbound firewall rule.
If the listener is using a port other than the default port (1433), specify the port in the connection
string. For example, the following sqlcmd command connects to a listener at port 1435:
cmd
2. sqlcmd -S <listenerName>,1435 -E
The SQLCMD connection automatically connects to whichever instance of SQL Server hosts the
primary replica.
Tip
Make sure that the port you specify is open on the firewall of both SQL Servers. Both servers
require an inbound rule for the TCP port that you use. For more information, see Add or Edit
Firewall Rule.