Menu
SQL Server with WSFC on AWS
Quick Start Reference Deployment Guide

Step 4. Test the Cluster and Availability Group

Note

If you’re using a third Availability Zone as a full SQL Server cluster node (that is, if you set the Third AZ parameter to full), take that into consideration when following the steps in this section.

Before you put the availability group into production, you should test your deployment and familiarize yourself with the cluster’s behavior during a high availability automatic failover or a disaster recovery event.

  1. Open the Remote Desktop Connection application (mstsc.exe), connect to the Remote Desktop Gateway instance, and then connect to the WSFC node (e.g., WSFCNode1) in that zone.

  2. On the first cluster node instance, open the Failover Cluster Manager to view the cluster core resources. Make sure the cluster, one of the two listed IP addresses, and the file share witness are online.

    
       Viewing the Failover Cluster Manager

    Figure 14: Viewing the Failover Cluster Manager

  3. Open SQL Server Management Studio. In Object Explorer, open the context (right-click) menu for the AlwaysOn High Availability node, and launch the dashboard for the availability group you created earlier (e.g., SQLAG1).

  4. In the dashboard, view the availability replicas and make sure their synchronization state is Synchronized.

    
       Viewing the Always On High Availability dashboard with all nodes synchronized

    Figure 15: Viewing the Always On High Availability dashboard with all nodes synchronized

  5. Make sure that the primary instance and the IP address in the Cluster Core Resources pane of Failover Cluster Manager are coordinated. That is, if the primary instance is WSFCNode1, the IP address 10.0.0.101 should be online. If you need to move the cluster core resources to WSFCNode1, you can do so through PowerShell by using the command:

    Copy
    Get-ClusterGroup 'Cluster Group' | Move-ClusterGroup -Node WSFCNode1
  6. Sign in to the AWS Management Console, and open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.

  7. Stop the primary instance (e.g., WSFCNode1).

  8. Open the Remote Desktop Connection application (mstsc.exe), connect to the second cluster node (e.g., WSFCNode2) in Availability Zone 2.

  9. On the second cluster node instance, use the Failover Cluster Manager to view the cluster core resources. Note that the IP address that was previously offline (e.g., 10.0.32.101) is now online.

    
       Viewing the Failover Cluster Manager with WSFCNode1 offline

    Figure 16: Viewing the Failover Cluster Manager with WSFCNode1 offline

  10. Open SQL Server Management Studio. In Object Explorer, open the context (right-click) menu for the AlwaysOn High Availability node, and launch the dashboard for the availability group you created earlier (e.g., SQLAG1).

  11. In the dashboard, view the availability replicas. Note that now the primary instance has switched to WSFCNode2, and that the synchronization state of WSFCNode1 is Not Synchronizing.

    
       Always On High Availability dashboard with the first cluster node offline

    Figure 17: Always On High Availability dashboard with the first cluster node offline

  12. At this point, you can start the WSFCNode1 instance again in the Amazon EC2 console. When the instance is online, use the Failover wizard in the Availability Group dashboard and switch the primary instance back to WSFCNode1.

    Note

    We recommend that you use MultiSubnetFailover=true in your SQL client connection string. This property enables faster failover for all availability groups in SQL Server and will significantly reduce failover time for single and multi-subnet Always On topologies. If you have legacy clients that need to connect to an availability group listener and cannot use MultiSubnetFailover, we recommend that you change the RegisterAllProvidersIP setting to 0 by using the Set-ClusterParameter cmdlet.