FÖRSÄLJNING: 1-800-867-1389
EN
Det här innehållet finns inte tillgängligt på ditt språk men här finns den engelska versionen,

Tutorial: Listener Configuration for AlwaysOn Availability Groups

Updated: December 14, 2014

This topic shows you how to configure a listener for an AlwaysOn Availability Group. Your Availability Group can contain replicas that are on-premises only, Azure only, or span both on-premises and Azure for hybrid configurations. Azure replicas can reside within the same region or across multiple regions using multiple virtual networks (VNets).

The steps below assume you have already configured an availability group but have not configured a listener. Note the following limitations on the availability group listener in Azure:

  • The availability group listener is supported on Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.

  • The client application must reside on a different cloud service than the one that contains your availability group VMs. Azure does not support direct server return with client and server in the same cloud service.

  • Only one availability group listener is supported per cloud service because the listener is configured to either use the cloud service IP address or the Virtual IP (VIP) address of the Internal Load Balancer (ILB).

  • If you are creating a listener for a hybrid environment, the on-premises network must have connectivity to the public Internet in addition to the site-to-site VPN with the Azure virtual network. When in the Azure subnet, the availability group listener is reachable only by the public IP address of the respective cloud service.

ImportantImportant
This tutorial focuses on using PowerShell to create a listener for an Availability Group that includes Azure replicas. For more information on how to configure listeners using SSMS or Transact-SQL, see Create or Configure an Availability Group Listener.

First, you must decide whether to use an external (public) or internal (private) load balancing for the listener. If the database server must be accessible outside the Virtual Network (VNet) that contains the Availability Group, then you should use public load balancing with a public IP address accessible from the internet. However, if you will only access the listener within the VNet (including site-to-site VPN in hybrid scenarios), then you should use Internal Load Balancing (ILB) with a private IP address for the listener. Because the ILB is not accessible from outside the Azure VNet, this offers another layer of security. Throughout the remainder of this tutorial, some sections will have different steps for public load balancing versus Internal Load Balancing configurations. Please follow the instructions for your selected approach.

noteNote
ILB can only be configured on virtual networks with a regional scope. Existing virtual networks that have been configured for an affinity group cannot use ILB. For more information, see Internal Load Balancer.

For ILB, you must first create the internal load balancer. This is done in the script below. In both ILB and public load balancing, you must create a load-balanced endpoint for each VM hosting an Azure replica. If you have replicas in multiple regions, each replica for that region must be in the same cloud service in the same VNet. Creating Availability Group replicas that span multiple Azure regions requires configuring multiple VNets. For more information on configuring cross VNet connectivity, see Configure VNet to VNet Connectivity.

  1. In the Azure portal, navigate to each VM hosting a replica and view the details.

  2. Click the Endpoints tab for each of the VMs.

  3. Verify that the Name and Public Port of the listener endpoint you want to use is not already in use. In the example below, the name is “MyEndpoint” and the port is “1433”.

  4. On your local client, download and install the latest PowerShell module.

  5. Launch Azure PowerShell. A new PowerShell session is opened with the Azure administrative modules loaded.

  6. Run Get-AzurePublishSettingsFile. This cmdlet directs you to a browser to download a publish settings file to a local directory. You may be prompted for your log-in credentials for your Azure subscription.

  7. Run the Import-AzurePublishSettingsFile command with the path of the publish settings file that you downloaded:

    Import-AzurePublishSettingsFile -PublishSettingsFile <PublishSettingsFilePath>
    

    Once the publish settings file is imported, you can manage your Azure subscription in the PowerShell session.

  8. If you are using public load balancing, continue with this step. If you are using Internal Load Balancing (ILB), skip to the next step. Copy the PowerShell script below into a text editor and set the variable values to suit your environment. Note that if your availability group spans Azure regions, you must run the script once in each datacenter for the cloud service and nodes that reside in that datacenter.

    # Define variables
    $ServiceName = "<MyCloudService>" # the name of the cloud service that contains the availability group nodes
    $AGNodes = "<VM1>","<VM2>","<VM3>" # all availability group nodes containing replicas in the same cloud service, separated by commas
    $EndpointName = "MyEndpoint" # name of the endpoint
    $EndpointPort = "1433" # public port to use for the endpoint
    
    # Configure a load balanced endpoint for each node in $AGNodes, with direct server return enabled
    ForEach ($node in $AGNodes)
    {
        Get-AzureVM -ServiceName $ServiceName -Name $node | Add-AzureEndpoint -Name $EndpointName -Protocol "TCP" -PublicPort $EndpointPort -LocalPort $EndpointPort -LBSetName "$EndpointName-LB" -ProbePort 59999 -ProbeProtocol "TCP" -DirectServerReturn $true | Update-AzureVM
    }
    
  9. If you are using Internal Load Balancing (ILB), continue with this step. If you are using public load balancing, skip to the next step. For ILB, you should assign a static IP address. First, examine the current VNet configuration by running the following command:

    (Get-AzureVNetConfig).XMLConfiguration
    

    First note the Subnet name for the subnet that contains the VMs that host the replicas. This will be used in the $SubnetName parameter in the script. Then note the VirtualNetworkSite name and the starting AddressPrefix for the subnet that contains the VMs that host the replicas. Then look for an available IP Address by passing both values to the Test-AzureStaticVNetIP command and examining the AvailableAddresses. For example, if the VNet was named MyVNet and had a subnet address range that started at 172.16.0.128, the following command would list available addresses:

    (Test-AzureStaticVNetIP -VNetName "MyVNet" -IPAddress 172.16.0.128).AvailableAddresses
    

    Choose one of the available addresses and use it in the $ILBStaticIP parameter of the following script.

    Copy the PowerShell script below into a text editor and set the variable values to suit your environment. Note that existing deployments that use affinity groups cannot add ILB. For more information on ILB requirements, see Internal Load Balancer. Note that if your availability group spans Azure regions, you must run the script once in each datacenter for the cloud service and nodes that reside in that datacenter.

    # Define variables
    $ServiceName = "<MyCloudService>" # the name of the cloud service that contains the availability group nodes
    $AGNodes = "<VM1>","<VM2>","<VM3>" # all availability group nodes containing replicas in the same cloud service, separated by commas
    $EndpointName = "<MyEndpoint>" # name of the endpoint
    $EndpointPort = "1433" # public port to use for the endpoint
    $ILBName = "<MyInternalLoadBalancer>" # chosen name for the new ILB
    $SubnetName = "<MySubnetName>" # subnet name that the replicas use in the VNet
    $ILBStaticIP = "<MyILBStaticIPAddress>" # static IP address for the ILB in the subnet
    
    Add-AzureInternalLoadBalancer -InternalLoadBalancerName $ILBName -SubnetName $SubnetName -ServiceName $ServiceName -StaticVNetIPAddress $ILBStaticIP
    
    # Configure a load balanced endpoint for each node in $AGNodes using ILB
    ForEach ($node in $AGNodes)
    {
    Get-AzureVM -ServiceName $ServiceName -Name $node | Add-AzureEndpoint -Name $EndpointName -LBSetName "$EndpointName-LB" -Protocol tcp -LocalPort $EndpointPort -PublicPort $EndpointPort -ProbePort 59999 -ProbeProtocol tcp -ProbeIntervalInSeconds 10 -InternalLoadBalancerName $ILBName -DirectServerReturn $true | Update-AzureVM 
    }
    
  10. Once you have set the variables, copy the script from the text editor into your Azure PowerShell session to run it. If the prompt still shows >>, type ENTER again to make sure the script starts running.

    noteNote
    The Azure Management Portal does not support the Internal Load Balancer at this time, so you will not see either the ILB or the endpoints in the portal. However, Get-AzureEndpoint returns an internal IP address if the Load Balancer is running on it. Otherwise, it returns null.

Next, if any servers on the cluster are running Windows Server 2008 R2 or Windows Server 20012, you must install the hotfix KB2854082 is installed on each of the on-premises server or Azure VM that is part of the cluster. Any server or VM that is in the cluster, but not in the availability group, should also have this hotfix installed.

In the remote desktop session for each of the cluster nodes, download KB2854082 to a local directory. Then, install the hotfix on each of the cluster nodes sequentially. If the cluster service is currently running on the cluster node, the server is restarted at the end of the hotfix installation.

WarningWarning
Stopping the cluster service or restarting the server affects the quorum health of your cluster and the availability group, and may cause your cluster to go offline. To maintain the high availability of your cluster during installation, make sure that:

  • The cluster is in optimal quorum health,

  • All cluster nodes are online before installing the hotfix on any node, and

  • Allow the hotfix installation to run to completion on one node, including fully restarting the server, before installing the hotfix on any other node in the cluster.

In this step, you create a firewall rule to open the probe port for the load-balanced endpoint (59999 as specified earlier), and another rule to open the availability group listener port. Since you created the load-balanced endpoint on the Azure VMs that contain availability group replicas, you need to open the probe port and the listener port on the respective Azure VMs.

  1. On VMs hosting replicas, launch Windows Firewall with Advanced Security.

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

  3. In the Rule Type page, select Port, then click Next.

  4. In the Protocol and Ports page, select TCP and type 59999 in the Specific local ports box. Then, click Next.

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

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

  7. In the Name page, specify a rule name, such as AlwaysOn Listener Probe Port in the Name text box, and click Finish.

  8. Repeat the above steps for the availability group listener port (as specified earlier in the $EndpointPort parameter of the script) and specify an appropriate rule name, such as AlwaysOn Listener Port.

In this step, you manually create the availability group listener in Failover Cluster Manager and SQL Server Management Studio (SSMS).

  1. Open Failover Cluster Manager from the node hosting the primary replica.

  2. Select the Networks node, and note the cluster network name. This name will be used in the $ClusterNetworkName variable in the PowerShell script.

  3. Expand the cluster name, and then click Roles.

  4. In the Roles pane, right-click the availability group name and then select Add Resource > Client Access Point.

    Add Client Access Point for Availability Group

  5. In the Name box, create a name for this new listener, then click Next twice, and then click Finish. Do not bring the listener or resource online at this point.

  6. Click the Resources tab, then expand the Client Access Point you just created. You will see the IP Address resource for each of the cluster networks in your cluster. If this is an Azure-only solution, you will only see one IP address resource.

  7. If you are configuring a hybrid solution, continue with this step. If you are configuring an Azure only solution, skip to the next step.

    1. Right-click the IP Address resource that corresponds to your on-premises subnet, then select Properties. Note the IP Address Name and network name.

    2. Select Static IP Address, assign an unused IP address and then click OK.



  8. Right-click the IP Address resource that corresponds to your Azure subnet and then select Properties.

    TipTip
    If the listener later fails to come online due to a conflicting IP address selected by DHCP, you can configure a valid static IP Address in this properties window.

  9. In the same IP Address properties window, change the IP Address Name. This IP address name will be used in the $IPResourceName variable of the PowerShell script. Repeat this step for each IP resource if your solution spans multiple Azure VNets.

  10. If you are using public load balancing, continue with this step. If you are using Internal Load Balancing, skip to the next step. For public load balancing, you must obtain the public virtual IP address of the cloud service that contains your replicas. Log into the Azure portal. Navigate to the cloud service that contains your availability group VM. Open the Dashboard view. Note the address shown under Public Virtual IP (VIP) Address. If your solution spans VNets, repeat this step for each cloud service that contains a VM that hosts a replica.

    On one of the VMs, copy the PowerShell script below into a text editor and set the variables to the values you noted earlier.

    # Define variables
    $ClusterNetworkName = "<ClusterNetworkName>" # the cluster network name (Use Get-ClusterNetwork on Windows Server 2012 of higher to find the name)
    $IPResourceName = "<IPResourceName>" # the IP Address resource name 
    $CloudServiceIP = "<X.X.X.X>" # Public Virtual IP (VIP) address of your cloud service
    
    Import-Module FailoverClusters
    
    # If you are using Windows Server 2012 or higher, use the Get-Cluster Resource command. If you are using Windows Server 2008 R2, use the cluster res command. Both commands are commented out. Choose the one applicable to your environment and remove the # at the beginning of the line to convert the comment to an executable line of code. 
    
    # Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$CloudServiceIP";"ProbePort"="59999";"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"OverrideAddressMatch"=1;"EnableDhcp"=0}
    # cluster res $IPResourceName /priv enabledhcp=0 overrideaddressmatch=1 address=$CloudServiceIP probeport=59999  subnetmask=255.255.255.255
    
  11. If you are using Internal Load Balancing (ILB), continue with this step. If you are using public load balancing, skip to the next step. For ILB, you must use the IP address of the ILB created earlier. Use the following script to obtain this IP Address in PowerShell.

    # Define variables
    $ServiceName = "<MyServiceName>" # the name of the cloud service that contains the AG nodes
    (Get-AzureInternalLoadBalancer -ServiceName $ServiceName).IPAddress
    

    On one of the VMs, copy the PowerShell script below into a text editor and set the variables to the values you noted earlier.

    # Define variables
    $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 
    $ILBIP = “<X.X.X.X># the IP Address of the Internal Load Balancer (ILB)
    
    Import-Module FailoverClusters
    
    # If you are using Windows Server 2012 or higher, use the Get-Cluster Resource command. If you are using Windows Server 2008 R2, use the cluster res command. Both commands are commented out. Choose the one applicable to your environment and remove the # at the beginning of the line to convert the comment to an executable line of code. 
    
    # Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$ILBIP";"ProbePort"="59999";"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"OverrideAddressMatch"=1;"EnableDhcp"=0}
    # cluster res $IPResourceName /priv enabledhcp=0 overrideaddressmatch=1 address=$ILBIP probeport=59999  subnetmask=255.255.255.255
    
  12. Once you have set the variables, open an elevated Windows PowerShell window, then copy the script from the text editor and paste into your Azure PowerShell session to run it. If the prompt still shows >>, type ENTER again to make sure the script starts running. Repeat this on each VM.

    This script configures the IP Address resource with the IP address of the cloud service and sets other parameters like the probe port. When the IP Address resource is brought online, it can then respond to the polling on the probe port from the load-balanced endpoint created earlier in this tutorial.

  13. Navigate back to Failover Cluster Manager. Expand Roles and then highlight your Availability Group. On the Resources tab, right-click the listener name and click Properties.

  14. Click the Dependencies tab. If there are multiple resources listed, verify that the IP addresses have OR, not AND, dependencies. Click OK.

  15. Right-click the listener name and click Bring Online.

  16. Once the listener is online, from the Resources tab, right-click the availability group and click Properties.

    Configure the Availability Group Resource

  17. Create a dependency on the listener name resource (not the IP address resources name). Click OK.

    Add Dependency on the Listener Name

  18. Launch SQL Server Management Studio and connect to the primary replica.

  19. Navigate to AlwaysOn High Availability | Availability Groups | <AvailabilityGroupName> | Availability Group Listeners. You should now see the listener name that you created in Failover Cluster Manager. Right-click the listener name and click Properties.

  20. In the Port box, specify the port number for the availability group listener by using the $EndpointPort you used earlier (in this tutorial, 1433 was suggested), then click OK.

After the availability group listener is created, it may be necessary to adjust the RegisterAllProvidersIP and HostRecordTTL cluster parameters for the listener resource. These parameters may reduce reconnection time after a failover which may prevent connection timeouts. For more information on these parameters, as well as sample code, see Create or Configure an Availability Group Listener.

In this step, you test the availability group listener using a client application running on the same network.

For client connectivity, please note the following requirements:

  • Client connections to the listener must come from machines that reside in a different cloud service than the one that hosts the AlwaysOn Availability replicas.

  • If the AlwaysOn replicas are in different subnets, clients must specify "MultisubnetFailover=True" in the connection string. This results in parallel connection attempts to replicas in the different subnets. Note that this scenario includes a cross-region AlwaysOn Availability Group deployment.

One example would be to connect to the listener from one of the VMs in the same Azure VNet (but not one that hosts a replica). An easy way to complete this test is to try to connect SSMS to the availability group listener. Another simple method is to run SQLCMD.exe as follows:

sqlcmd -S "<ListenerName>,<EndpointPort>" -d "<DatabaseName>" -Q "select @@servername, db_name()" -l 15
TipTip
Note that if the EndpointPort value is 1433, it is not required to specify it in the call. The previous call also assumes that the client machine is joined to the same domain and that the caller has been granted permissions on the database using windows authentication.

When testing the listener, be sure to fail over the availability group to make sure that clients can connect to the listener across failovers.

In the case of public load balancing, the previous test will not work outside the Azure VNet. In order to access the listener from outside the virtual network, you must specify the cloud service name. For a cloud service with the name mycloudservice, the sqlcmd statement would be as follows:

sqlcmd -S "mycloudservice.cloudapp.net,<EndpointPort>" -d "<DatabaseName>" -U "<LoginId>" -P "<Password>"  -Q "select @@servername, db_name()" -l 15

Unlike the previous example, SQL authentication must be used, because the caller cannot use windows authentication over the internet. For more information, see AlwaysOn Availability Group in Windows Azure VM: Client Connectivity Scenarios. When using SQL authentication, make sure that you create the same login on both replicas. For more information about troubleshooting logins with Availability Groups, see How to map logins or use contained SQL database user to connect to other replicas and map to availability databases.

If the AlwaysOn replicas are in different subnets, clients must specify "MultisubnetFailover=True" in the connection string. This results in parallel connection attempts to replicas in the different subnets. Note that this scenario includes a cross-region AlwaysOn Availability Group deployment.

noteNote
The test in this step does not work with ILB, because the internal load balancer is inaccessible from outside the Azure VNet.

See Also

Var detta till hjälp?
(1500 tecken kvar)
Tack för dina kommentarer
Visa:
© 2015 Microsoft