Configuración de un agente de escucha ILB para grupos de disponibilidad en máquinas virtuales con SQL Server de Azure

Artículo
05/02/2017

Información general

Importante

Azure tiene dos modelos de implementación diferentes para crear y trabajar con recursos: Azure Resource Manager y el modelo clásico. Este artículo trata sobre el uso del modelo de implementación clásico. Se recomienda que las implementaciones más recientes usen el modelo Resource Manager.

Para configurar un agente de escucha para un grupo de disponibilidad AlwaysOn en el modelo de Resource Manager, consulte Configuración de un equilibrador de carga interno para un grupo de disponibilidad AlwaysOn de Azure.

El grupo de disponibilidad puede contener réplicas que son solo locales, solo de Azure o abarcan ambas, locales y de Azure, para configuraciones híbridas. Las réplicas de Azure pueden residir en la misma región o en varias regiones que usen varias redes virtuales. En los procedimientos descritos en este artículo se supone que ya tiene configurado un grupo de disponibilidad pero no un agente de escucha.

Instrucciones y limitaciones de los agentes de escucha internos

El uso de un equilibrador de carga interno (ILB) con un agente de escucha del grupo de disponibilidad de Azure está sujeto a las siguientes directrices:

El agente de escucha del grupo de disponibilidad es compatible con Windows Server 2008 R2, Windows Server 2012 y Windows Server 2012 R2.
Solo se admite un agente de escucha de grupo de disponibilidad interno para cada servicio en la nube, ya que el agente de escucha se configura según el ILB y solo hay un ILB por cada servicio en la nube. Sin embargo, es posible crear varios agentes de escucha externos. Para más información, consulte Configuración de un agente de escucha externo para grupos de disponibilidad AlwaysOn en Azure.

Determinar la accesibilidad del agente de escucha

Es importante saber que hay dos formas de configurar un agente de escucha del grupo de disponibilidad en Azure. Estos métodos se diferencian en el tipo de equilibrador de carga de Azure que se usa al crear el agente de escucha. La siguiente tabla muestra las diferencias:

Tipo de equilibrador de carga	Implementación	Úsala en estos casos:
Externo	Usa la dirección IP virtual pública del servicio en la nube que hospeda las máquinas virtuales.	Es necesario tener acceso al agente de escucha desde el exterior de la red virtual, incluso desde Internet.
Interno	Usa un equilibrador de carga interno con una dirección privada para el agente de escucha.	Solo se puede acceder al agente de escucha desde la misma red virtual. Este acceso incluye una VPN de sitio a sitio en escenarios híbridos.

Importante

No incurrirá en cargos de salida por utilizar un agente de escucha que use la dirección VIP pública del servicio en la nube (equilibrador de carga externo), siempre y cuando el cliente, el agente de escucha y las bases de datos se encuentren en la misma región de Azure. En caso contrario, los datos que devuelve el agente de escucha se consideran de salida y se cobran según las tarifas de transferencia de datos normales.

Un ILB solo se puede configurar en redes virtuales con un ámbito regional. Las redes virtuales existentes que se han configurado para un grupo de afinidad no pueden usar un ILB. Para más información, consulte Información general sobre el equilibrador de carga interno.

Este artículo se centra en la creación de un agente de escucha que usa un ILB. Si necesita un agente de escucha público o externo, consulte la versión de este artículo que analiza la configuración de un agente de escucha externo.

Creación de extremos de máquina virtual de carga equilibrada con Direct Server Return

Primero cree un ILB ejecutando el script que aparece más adelante en esta sección.

Cree un punto de conexión de carga equilibrada para cada máquina virtual que hospeda una réplica de Azure. Si tiene réplicas en varias regiones, cada réplica de esa región tiene que estar en el mismo servicio en la nube de la misma red virtual de Azure. La creación de réplicas de grupo de disponibilidad que abarcan varias regiones de Azure requiere configurar varias redes virtuales. Para más información acerca de la configuración de la conectividad cruzada entre redes virtuales, consulte Configuración de una conexión de red virtual a red virtual para el modelo de implementación clásico.

En Azure Portal, vaya a cada máquina virtual que hospeda una réplica para ver los detalles.
Haz clic en la pestaña Puntos de conexión para cada una de las máquinas virtuales.
Compruebe que el nombre y el puerto público del punto de conexión del agente de escucha que desea utilizar no están ya en uso. En el ejemplo de esta sección, el nombre es MyEndpoint y el puerto es 1433.
En el cliente local, descargue e instale el último módulo de PowerShell.
Inicie Azure PowerShell.
Se abre una nueva sesión de PowerShell con los módulos de administración de Azure cargados.
Ejecute Get-AzurePublishSettingsFile. Este cmdlet te dirige a un explorador para descargar un archivo de configuración de publicación en un directorio local. Puede que tenga que escribir las credenciales de inicio de sesión de la suscripción a Azure.
Ejecute el siguiente comando Import-AzurePublishSettingsFile con la ruta de acceso del archivo de configuración de publicación que descargó:
```
Import-AzurePublishSettingsFile -PublishSettingsFile <PublishSettingsFilePath>
```
Una vez que el archivo de configuración de publicación se haya importado, puede administrar su suscripción a Azure en la sesión de PowerShell.
En el ILB, asigne una dirección IP estática. Examine la configuración actual de la red virtual ejecutando el comando siguiente:
```
(Get-AzureVNetConfig).XMLConfiguration
```
Tome nota del nombre de la Subred que contenga las máquinas virtuales que hospeden las réplicas. Este nombre se usa en el parámetro $SubnetName en el script.
En la subred que contiene las máquinas virtuales que hospedan las réplicas, tome nota del nombre del elemento VirtualNetworkSite y del elemento AddressPrefix inicial. Busque una dirección IP disponible pasando ambos valores al comando Test-AzureStaticVNetIP y examinando el parámetro AvailableAddresses. Por ejemplo, si el nombre de la red virtual fuera MyVNet y tuviera un intervalo de direcciones de subred que empezase por 172.16.0.128, el siguiente comando mostraría las direcciones disponibles:
```
(Test-AzureStaticVNetIP -VNetName "MyVNet"-IPAddress 172.16.0.128).AvailableAddresses
```
Seleccione una de las direcciones disponibles y úsela en el parámetro $ILBStaticIP del script del paso siguiente.

Copie el siguiente script de PowerShell en un editor de texto y configure los valores de las variables para que se adapten a su entorno. Se han proporcionado los valores predeterminados de algunos parámetros.

Las implementaciones existentes que usan grupos de afinidad no pueden agregar un ILB. Para más información sobre requisitos de ILB, consulte Información general sobre el equilibrador de carga interno.

Además, si el grupo de disponibilidad abarca regiones de Azure, debe ejecutar el script una vez en cada centro de datos del servicio en la nube y los nodos que residen en ese centro de datos.

# 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
$SubnetName = "<MySubnetName>" # subnet name that the replicas use in the virtual network
$ILBStaticIP = "<MyILBStaticIPAddress>" # static IP address for the ILB in the subnet
$ILBName = "AGListenerLB" # customize the ILB name or use this default value

# Create the ILB
Add-AzureInternalLoadBalancer -InternalLoadBalancerName $ILBName -SubnetName $SubnetName -ServiceName $ServiceName -StaticVNetIPAddress $ILBStaticIP

# Configure a load-balanced endpoint for each node in $AGNodes by using ILB
ForEach ($node in $AGNodes)
{
    Get-AzureVM -ServiceName $ServiceName -Name $node | Add-AzureEndpoint -Name "ListenerEndpoint" -LBSetName "ListenerEndpointLB" -Protocol tcp -LocalPort 1433 -PublicPort 1433 -ProbePort 59999 -ProbeProtocol tcp -ProbeIntervalInSeconds 10 -InternalLoadBalancerName $ILBName -DirectServerReturn $true | Update-AzureVM
}

Una vez configuradas las variables, copie el script del editor de texto en la sesión de PowerShell para ejecutarlo. Si el mensaje todavía muestra >>, pulse ENTER de nuevo para asegurarse de que el script comienza a ejecutarse.

Comprobación de que KB2854082 está instalado si es necesario.

Después, si algún servidor del clúster está ejecutando Windows Server 2008 R2 o Windows Server 2012, debe comprobar que la revisión KB2854082 está instalada en todos los servidores locales o máquinas virtuales de Azure que forman parte del clúster. Cualquier servidor o VM que esté en el clúster, pero no en el grupo de disponibilidad, también debería tener instalada esta revisión.

En la sesión de escritorio remoto para todos los nodos del clúster, descarga la KB2854082 en un directorio local. A continuación, instale la revisión en todos los nodos del clúster secuencialmente. Si en ese momento el servicio de clúster se está ejecutando en el nodo de clúster, el servidor se reiniciará al final de la instalación de la revisión.

Advertencia

Detener el servicio de clúster o reiniciar el servidor afectará al estado del cuórum del clúster y al grupo de disponibilidad y puede provocar que el clúster se quede sin conexión. Para mantener la alta disponibilidad del clúster durante la instalación, asegúrate de que:

El clúster se encuentra en un estado de cuórum óptimo.
Todos los nodos del clúster están conectados antes de instalar la revisión en cualquier nodo.
Antes de instalar la revisión en cualquier otro nodo del clúster, permita que se ejecute la instalación de la revisión hasta su finalización en un nodo, incluido el reinicio completo del servidor.

Apertura de los puertos de firewall en los nodos de grupo de disponibilidad

En este paso, se creará una regla de firewall para abrir el puerto de sondeo para el punto de conexión de carga equilibrada (59999, como se especificó anteriormente) y otra regla para abrir el puerto de escucha del grupo de disponibilidad. Como se creó el punto de conexión de carga equilibrada en las máquinas virtuales que contienen réplicas del grupo de disponibilidad, será necesario abrir el puerto de sondeo y el puerto de escucha en las respectivas máquinas virtuales.

Inicie el Firewall de Windows con seguridad avanzada en las máquinas virtuales que hospedan réplicas.
Haga clic con el botón secundario en Reglas de entrada y, a continuación, en Nueva regla.
En la página Tipo de regla, seleccione Puerto y después haga clic en Siguiente.
En la página Protocolo y puertos seleccione TCP, escriba 59999 en el cuadro de texto Puertos locales específicos y haga clic en Siguiente.
En la página Acción, mantenga seleccionado Permitir la conexión y luego haga clic en Siguiente.
En la página Perfiles, acepte la configuración predeterminada y luego haga clic en Siguiente.
En la página Nombre, especifique un nombre de regla, como Always On Listener Probe Port (Puerto de sondeo de escucha Always On), en el cuadro de texto Nombre y haga clic en Finalizar.
Repita los pasos anteriores para el puerto de escucha del grupo de disponibilidad (como se especificó anteriormente en el parámetro $EndpointPort del script) y especifique un nombre de regla adecuado, como Puerto de escucha Always On.

Creación del agente de escucha de grupo de disponibilidad

Cree el agente de escucha de grupo de disponibilidad en dos pasos. En primer lugar, cree el recurso de clúster del punto de acceso de cliente y configure las dependencias. En segundo lugar, configure los recursos de clúster en PowerShell.

Creación del punto de acceso cliente y configuración de las dependencias de clúster

En este paso, se crea manualmente el agente de escucha del grupo de disponibilidad en el Administrador de clústeres de conmutación por error y SQL Server Management Studio.

Abra el Administrador de clústeres de conmutación por error desde el nodo que hospeda la réplica principal.
Seleccione el nodo Redes y anote el nombre de red del clúster. Este nombre se utilizará en la variable $ClusterNetworkName en el script de PowerShell.
Amplía el nombre del clúster y haz clic en Funciones.
En el panel Roles, haga clic con el botón derecho en el nombre del grupo de disponibilidad y después seleccione Agregar recurso>Punto de acceso cliente.
En la casilla Nombre, cree un nombre para este nuevo agente de escucha, después haga clic en Siguiente dos veces y haga clic en Finalizar.
No pongas el agente de escucha o el recurso en línea en este momento.
Haga clic en la pestaña Recursos y después expanda el punto de acceso cliente que acaba de crear. Se muestra el recurso de dirección IP de cada red del clúster existente. Si se trata de una solución solo de Azure, se muestra un único recurso de dirección IP.
Realice cualquiera de las siguientes acciones:
- Para configurar una solución híbrida:
  
  a. Haga clic con el botón derecho en el recurso de dirección IP que corresponda a la subred local y, a continuación, seleccione Propiedades. Anote el nombre de dirección IP y el nombre de red.
  
  b. Seleccione Dirección IP estática, asigne una dirección IP no utilizada y, a continuación, haga clic en Aceptar.
- Para configurar una solución solo de Azure:
  
  a. Haga clic con el botón derecho en el recurso de dirección IP correspondiente a la subred de Azure y, a continuación, seleccione Propiedades.
  
  Nota
  
  Si el agente de escucha no se puede poner en línea debido a una dirección IP en conflicto seleccionada por DHCP, puede configurar una dirección IP estática válida en esta ventana de propiedades.
  
  b. En la misma ventana de propiedades de Dirección IP, cambie el Nombre de dirección IP.
  Este nombre se utilizará en la variable $IPResourceName del script de PowerShell. Si la solución abarca varias redes virtuales de Azure, repita este paso para cada recurso de dirección IP.

Configuración de los recursos de clúster en PowerShell

En ILB, debe usar la dirección IP del ILB creado anteriormente. Use el script siguiente para obtener esta dirección IP en PowerShell:

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

En una de las máquinas virtuales, copie el script de PowerShell correspondiente a su sistema operativo en un editor de texto y establezca las variables en los valores que anotó anteriormente.

Para Windows Server 2012 o posterior, use el siguiente script:

# 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 ILB

Import-Module FailoverClusters

Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$ILBIP";"ProbePort"="59999";"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"EnableDhcp"=0}

Para Windows Server 2008 R2, use el siguiente script:

# 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 ILB

Import-Module FailoverClusters

cluster res $IPResourceName /priv enabledhcp=0 address=$ILBIP probeport=59999  subnetmask=255.255.255.255

Una vez establecidas las variables, abra una ventana de Windows PowerShell con privilegios elevados, pegue el script del editor de texto en la sesión de PowerShell para ejecutarlo. Si el mensaje todavía muestra >>, pulse ENTER de nuevo para asegurarse de que el script comienza a ejecutarse.
Repita los pasos anteriores para cada máquina virtual.
Este script configura el recurso de dirección IP con la dirección IP del servicio en la nube y establece otros parámetros como, por ejemplo, el puerto de sondeo. El recurso de dirección IP, una vez conectado, puede responder al sondeo en el puerto de sondeo del punto de conexión de carga equilibrada que creó anteriormente.

Conexión del agente de escucha

En el Administrador de clústeres de conmutación por error, expanda Roles y, a continuación, resalte el grupo de disponibilidad.
En la pestaña Recursos, haga clic con el botón derecho en el nombre del agente de escucha y, a continuación, haga clic en Propiedades.
Haz clic en la pestaña Dependencias . Si aparecen varios recursos, compruebe que las direcciones IP tienen dependencias OR y no AND.
Haga clic en OK.
Haga clic con el botón derecho en el nombre del agente de escucha y luego haga clic en Poner en línea.
Una vez que el agente de escucha está en línea, en la pestaña Recursos, haga clic con el botón derecho en el grupo de disponibilidad y haga clic en Propiedades.
Cree una dependencia en el recurso del nombre del agente de escucha (no en el nombre de los recursos de dirección IP) y, a continuación, haga clic en Aceptar.
Abra SQL Server Management Studio y conéctese a la réplica principal.
Vaya a Grupos de alta disponibilidad> AlwaysOn AvailabilityGroups><AvailabilityGroupNombre>>Agentes de escucha del grupo de disponibilidad.
Debe mostrarse el nombre del agente de escucha que creó en el Administrador de clústeres de conmutación por error.
Haga clic con el botón derecho en el nombre del agente de escucha y luego en Propiedades.
En el cuadro de texto Puerto, especifique el número del puerto del agente de escucha del grupo de disponibilidad mediante el parámetro $EndpointPort usado anteriormente (en este tutorial, el valor predeterminado era 1433) y, después, haga clic en Aceptar.

Elementos de seguimiento

Después de crear el agente de escucha del grupo de disponibilidad, puede que sea necesario ajustar los parámetros de clúster RegisterAllProvidersIP y HostRecordTTL para el recurso del agente de escucha. Estos parámetros pueden reducir el tiempo de reconexión tras una conmutación por error que puede evitar los tiempos de expiración de la conexión. Para más información sobre estos parámetros, así como código de ejemplo, consulte Crear o configurar un agente de escucha del grupo de disponibilidad.

Prueba del agente de escucha del grupo de disponibilidad (dentro de la misma red virtual)

En este paso, se probará el agente de escucha del grupo de disponibilidad mediante una aplicación de cliente que se ejecuta en la misma red.

La conectividad del cliente tiene los requisitos siguientes:

Las conexiones de cliente para el agente de escucha tienen que proceder de máquinas que residan en un servicio en la nube diferente al que hospeda las réplicas de disponibilidad Always On.
Si las réplicas AlwaysOn están en subredes diferentes, los clientes tendrán que especificar MultisubnetFailover=True en la cadena de conexión. Esta condición se produce en los intentos de conexión en paralelo con las réplicas de las diversas subredes. Este escenario incluye una implementación de grupo de disponibilidad Always On entre regiones.

Un ejemplo sería conectarse al agente de escucha desde una de las máquinas virtuales de la misma red virtual de Azure (pero no desde una que hospede una réplica). Una manera fácil de completar esta prueba consiste en intentar conectar SQL Server Management Studio al agente de escucha del grupo de disponibilidad. Otro método sencillo consiste en ejecutar SQLCMD.exe, como se indica a continuación:

sqlcmd -S "<ListenerName>,<EndpointPort>" -d "<DatabaseName>" -Q "select @@servername, db_name()" -l 15

Nota

Si el valor de EndpointPort es 1433, no es necesario especificarlo en la llamada. La llamada anterior también asume que el equipo cliente está unido al mismo dominio y que el llamador tiene concedidos los permisos en la base de datos mediante la autenticación de Windows.

Al probar el agente de escucha, asegúrese de conmutar por error el grupo de disponibilidad para asegurarte de que los clientes puedan conectarse al agente de escucha a través de las conmutaciones por error.

Pasos siguientes

Además de conectar automáticamente los clientes a la réplica principal, un agente de escucha se puede utilizar para redirigir las cargas de trabajo de solo lectura a las secundarias. Esto puede mejorar el rendimiento y la escalabilidad de la solución en general. Para más información, consulte Use ReadIntent Routing with Azure Always On availability group listener (Uso del enrutamiento ReadIntent con el agente de escucha del grupo de disponibilidad de Azure Always On).