Compartir a través de

Procedimientos recomendados para la configuración de HADR (SQL Server en Azure Virtual Machines)

  • Artículo

Se aplica a: SQL Server en máquina virtual de Azure

Un clúster de conmutación por error de Windows Server se usa para la alta disponibilidad y la recuperación ante desastres (HADR) con SQL Server en Azure Virtual Machines.

En este artículo se proporcionan procedimientos recomendados de configuración de clústeres tanto para instancias de clúster de conmutación por error (FCI) como para grupos de disponibilidad cuando se usan con SQL Server en máquinas virtuales de Azure.

Para obtener más información, consulte otros artículos de esta serie: Lista de comprobación, Tamaño de VM, Almacenamiento, Seguridad, Configuración de HADR y Recopilación de la línea de base.

Lista de comprobación

Revise la siguiente lista de comprobación para obtener una breve introducción sobre los procedimientos recomendados de HADR que se cubren en el resto del artículo con mayor detalle.

Las características de alta disponibilidad y recuperación ante desastres (HADR) como, por ejemplo, el grupo de disponibilidad Always On y la instancia de clúster de conmutación por error, se basan en la tecnología subyacente de clúster de conmutación por error de Windows Server. Revise los procedimientos recomendados para modificar la configuración de HADR para admitir mejor el entorno en la nube.

Para el clúster de Windows, tenga en cuenta estos procedimientos recomendados:

  • Implemente las máquinas virtuales con SQL Server en varias subredes siempre que sea posible para evitar la dependencia de un nombre de red distribuida (DNN) o una instancia de Azure Load Balancer para enrutar el tráfico a la solución de alta disponibilidad y recuperación ante desastres.
  • Cambie el clúster a parámetros menos agresivos para evitar interrupciones inesperadas de errores de red transitorios o mantenimiento de la plataforma de Azure. Para más información, consulte la configuración de latidos y umbrales. Para Windows Server 2012 y versiones posteriores, utilice los siguientes valores recomendados:
    • SameSubnetDelay: 1 segundo
    • SameSubnetThreshold: 40 latidos
    • CrossSubnetDelay: 1 segundo
    • CrossSubnetThreshold: 40 latidos
  • Coloque las máquinas virtuales en un conjunto de disponibilidad o en distintas zonas de disponibilidad. Para más información, consulte Configuración de disponibilidad de máquinas virtuales.
  • Use una sola NIC por nodo de clúster.
  • Configure la votación de cuórum de clúster para usar 3 o más números de votos impares. No asigne votos a las regiones de recuperación ante desastres.
  • Supervise detenidamente los límites de recursos para evitar reinicios inesperados o conmutaciones por error debido a restricciones de recursos.
    • Asegúrese de que el sistema operativo, controladores y SQL Server disponen de las versiones más recientes.
    • Optimice el rendimiento de SQL Server en las máquinas virtuales de Azure. Revise las demás secciones de este artículo para obtener más información.
    • Reduzca o extienda la carga de trabajo para evitar límites de recursos.
    • Cambie a una máquina virtual o disco cuyos límites sean más altos para evitar restricciones.

Para el grupo de disponibilidad SQL Server o la instancia de clúster de conmutación por error, tenga en cuenta estos procedimientos recomendados:

  • Si experimenta errores inesperados con frecuencia, siga los procedimientos recomendados de rendimiento descritos en este artículo.
  • Si la optimización del rendimiento de las máquinas virtuales SQL Server no resuelve las conmutaciones por error inesperadas, considere la posibilidad de relajar la supervisión para el grupo de disponibilidad o la instancia de clúster de conmutación por error. Sin embargo, es posible que no se pueda solucionar el origen subyacente de la incidencia y podría enmascarar los síntomas al reducir la probabilidad de error. Es posible que tenga que investigar y abordar la causa principal subyacente. Para Windows Server 2012 y versiones posteriores, utilice los siguientes valores recomendados:
    • Tiempo de espera de concesión: use esta ecuación para calcular el valor máximo de tiempo de espera de concesión:
      Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
      Comience con 40 segundos. Si usa los valores SameSubnetThreshold y SameSubnetDelay flexibles recomendados anteriormente, no supere los 80 segundos para el valor de tiempo de espera de concesión.
    • Número máximo de errores en un período especificado: establezca este valor en 6.
  • Cuando use el nombre de red virtual (VNN) y Azure Load Balancer para conectarse a una solución de alta disponibilidad y recuperación ante desastres, especifique MultiSubnetFailover = true en la cadena de conexión, incluso si el clúster solo abarca una subred.
    • Si el cliente no admite MultiSubnetFailover = True, es posible que deba establecer RegisterAllProvidersIP = 0 y HostRecordTTL = 300 para copiar en caché las credenciales de cliente durante períodos más cortos. Sin embargo, esto puede provocar consultas adicionales en el servidor DNS.
  • Para conectarse a la solución HADR mediante el nombre de red distribuida (DNN), tenga en cuenta lo siguiente:
    • Debe usar un controlador cliente que admita MultiSubnetFailover = True y este parámetro debe estar en la cadena de conexión.
    • Use un puerto DNN único en la cadena de conexión al conectarse al cliente de escucha de DNN para un grupo de disponibilidad.
  • Use una cadena de conexión de creación de reflejo de la base de datos para que un grupo de disponibilidad básico omita la necesidad de un equilibrador de carga o DNN.
  • Valide el tamaño del sector de los discos duros virtuales antes de implementar la solución de alta disponibilidad para evitar tener E/S mal alineadas. Consulte KB3009974 para más información.
  • Si el motor de base de datos de SQL Server, la escucha del grupo de disponibilidad Always On o el sondeo de estado de la instancia de clúster de conmutación por error están configurados para usar un puerto entre 49152 y 65536 (el intervalo de puertos dinámicos predeterminado para TCP/IP), agregue una exclusión para cada puerto. Si lo hace, impedirá que a otros sistemas se les asigne dinámicamente el mismo puerto. En el ejemplo siguiente se crea una exclusión para el puerto 59999:
    netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

Para comparar la lista de comprobación de alta disponibilidad y recuperación ante desastres con otros procedimientos recomendados, consulte la lista de comprobación de procedimientos recomendados de rendimiento.

Configuración de disponibilidad de VM

Para reducir el impacto del tiempo de inactividad, tenga en cuenta la siguiente configuración de disponibilidad recomendada para máquinas virtuales:

  • Use grupos con ubicación por proximidad junto con redes aceleradas para la latencia más baja.
  • Coloque nodos de clúster de máquinas virtuales en zonas de disponibilidad independientes para protegerse frente a errores de nivel de centro de datos o en un único conjunto de disponibilidad para obtener redundancia de baja latencia dentro del mismo centro de datos.
  • Use discos de datos y del sistema operativo administrados de forma premium para máquinas virtuales en un conjunto de disponibilidad.
  • Configure cada capa de aplicación en conjuntos de disponibilidad independientes.

Quorum

Aunque un clúster de dos nodos funciona sin un recurso de cuórum, los clientes deben usar un recurso de quórum para tener soporte técnico de producción. La validación del clúster no aprueba ningún clúster sin un recurso de quórum.

Técnicamente, un clúster de tres nodos puede sobrevivir a una pérdida de un solo nodo (hasta dos) sin un recurso de cuórum, pero una vez que el clúster se reduce a dos nodos, si se produce la pérdida de otro nodo o un error de comunicación, existe el riesgo de que los recursos de clúster se desconecten para evitar un escenario de cerebro dividido. La configuración de un recurso de cuórum permite que el clúster continúe en línea con un solo nodo en línea.

El testigo de disco es la opción de cuórum más resistente, pero para usar un testigo de disco en un SQL Server en una máquina virtual de Azure, debe usar un disco compartido de Azure que imponga algunas limitaciones a la solución de alta disponibilidad. Por lo tanto, use un testigo de disco al configurar la instancia de clúster de conmutación por error con discos compartidos de Azure; de lo contrario, use un testigo en la nube siempre que sea posible.

En la tabla siguiente se enumeran las opciones de cuórum disponibles para SQL Server en máquinas virtuales de Azure:

Testigo en la nube Testigo de disco Testigo de recurso compartido de archivos
Sistema operativo admitido Windows Server 2016+ All All
  • El testigo en la nube resulta ideal para implementaciones en varios sitios, en varias zonas y en varias regiones. Use un testigo en la nube siempre que sea posible, a menos que use una solución de clúster de almacenamiento compartido.
  • El testigo de disco es la opción de cuórum más resistente y la preferida para cualquier clúster que use discos compartidos de Azure (o cualquier solución de disco compartido como SCSI compartido, iSCSI o SAN de canal de fibra). Un volumen compartido de clúster no se puede usar como testigo de disco.
  • El testigo de recursos compartidos de archivos es adecuado para cuando el testigo de disco y el testigo en la nube no están disponibles.

Para empezar, consulte Configuración del cuórum de clúster.

Votación de cuórum

Es posible cambiar el voto de cuórum de un nodo que participa en un clúster de conmutación por error de Windows Server.

Al modificar la configuración de voto de nodo, siga estas instrucciones:

Instrucciones de votación de cuórum
Comience con los nodos que no tengan ningún voto de manera predeterminada. Cada nodo solo debe tener un voto con justificación explícita.
Habilite los votos para los nodos de clúster que hospedan la réplica principal de un grupo de disponibilidad o los propietarios preferidos de una instancia de clúster de conmutación por error.
Habilite los votos para los propietarios de conmutación automática por error. Cada uno de los nodos que puede hospedar una réplica principal o FCI, como resultado de una conmutación automática por error, debe tener un voto.
Si un grupo de disponibilidad tiene más de una réplica secundaria, habilite votos solo para las réplicas que tienen conmutación automática por error.
Deshabilite los votos para los nodos que se encuentren en sitios secundarios de recuperación ante desastres. Los nodos de los sitios secundarios no deben contribuir a la decisión de desconectar un clúster si no hay ningún problema con el sitio primario.
Tenga un número impar de votos, con un mínimo de tres votos de quórum. Si es necesario, agregue un testigo de cuórum para un voto adicional cuando un clúster tenga dos nodos.
Vuelva a valorar las asignaciones de votos después de la conmutación por error. No es conveniente realizar la conmutación por error en una configuración de clúster que no admita un quórum correcto.

Conectividad

Para que no sienta que hay diferencia entre conectarse a la escucha de grupo de disponibilidad o a la instancia de clúster de conmutación por error y usar el entorno local, implemente las máquinas virtuales de SQL Server en varias subredes dentro de la misma red virtual. El hecho de tener varias subredes elimina la necesidad de la dependencia adicional de una instancia de Azure Load Balancer o un nombre de red distribuida para enrutar el tráfico al cliente de escucha.

Para simplificar la solución de alta disponibilidad y recuperación ante desastres, implemente las máquinas SQL Server virtuales en varias subredes siempre que sea posible. Para más información, consulte los apartado sobre grupos de disponibilidad en varias subredes e instancias de clúster de conmutación por error en varias subredes.

Si las máquinas virtuales de SQL Server están en una sola subred, es posible configurar un nombre de red virtual (VNN) y un instancia de Azure Load Balancer, o bien un nombre de red distribuida (DNN) tanto para las instancias de clúster de conmutación por error como para las escuchas de grupo de disponibilidad.

El nombre de red distribuida es la opción de conectividad recomendada, cuando esté disponible:

  • La solución de un extremo a otro es más sólida, dado que ya no tiene que mantener el recurso del equilibrador de carga.
  • La eliminación de los sondeos del equilibrador de carga reduce al mínimo la duración de la conmutación por error.
  • El nombre de red distribuida simplifica el aprovisionamiento y la administración de la instancia de clúster de conmutación por error o del cliente de escucha del grupo de disponibilidad con VM con SQL Server en Azure.

Tenga en cuenta las limitaciones siguientes:

Para más información, consulte la introducción al clúster de conmutación por error de Windows Server.

Para configurar la conectividad, consulte los artículos siguientes:

La mayoría de las características de SQL Server funcionan de manera transparente con FCI y grupos de disponibilidad cuando se usa el DNN, pero hay determinadas características que pueden exigir una consideración especial. Para obtener más información, consulte Interoperabilidad con FCI y DNN e Interoperabilidad con AG y DNN.

Sugerencia

Establezca el parámetro MultiSubnetFailover en true en la cadena de conexión, incluso para las soluciones HADR que abarquen una única subred, para admitir la expansión futura de las subredes sin necesidad de actualizar las cadenas de conexión.

Latido y umbral

Cambie la configuración del umbral y el latido del clúster a una configuración flexible. La configuración predeterminada del clúster de latidos y umbrales está diseñada para redes locales muy ajustadas y no tiene en cuenta la posibilidad de aumentar la latencia en un entorno de nube. La red de latidos se mantiene con UDP 3343, que tradicionalmente es mucho menos confiable que TCP y más propensa a conversaciones incompletas.

Por lo tanto, al ejecutar nodos de clúster para SQL Server en soluciones de alta disponibilidad de máquinas virtuales de Azure, cambie la configuración del clúster a un estado de supervisión más flexible para evitar errores transitorios debido a la mayor posibilidad de latencia o error de red, mantenimiento de Azure o cuellos de botella de recursos.

La configuración de retraso y umbral tiene un efecto acumulativo en la detección de estado total. Por ejemplo, si se establece CrossSubnetDelay para enviar un latido cada 2 segundos y se establece CrossSubnetThreshold en 10 latidos perdidos antes de realizar la recuperación, el clúster puede tener una tolerancia de red total de 20 segundos antes de que se inicie la acción de recuperación. En general, se prefiere continuar con el envío de latidos con frecuencia pero tener umbrales mayores.

Para garantizar la recuperación durante interrupciones legítimas a la vez que proporciona mayor tolerancia a problemas transitorios, atenúe la configuración de retraso y umbral a los valores recomendados que se detallan en la tabla siguiente:

Configuración Windows Server 2012 o superior Windows Server 2008 R2
SameSubnetDelay 1 segundo 2 segundos
SameSubnetThreshold 40 latidos 10 latidos (máximo)
CrossSubnetDelay 1 segundo 2 segundos
CrossSubnetThreshold 40 latidos 20 latidos (máximo)

Use PowerShell para cambiar los parámetros del clúster:

(get-cluster).SameSubnetThreshold = 40
(get-cluster).CrossSubnetThreshold = 40

Use PowerShell para comprobar los cambios:

get-cluster | fl *subnet*

Tenga en cuenta lo siguiente.

  • Este cambio es inmediato, no es necesario reiniciar el clúster ni ningún recurso.
  • Los mismos valores de subred no deben ser mayores que los valores entre subredes.
  • SameSubnetThreshold <= CrossSubnetThreshold
  • SameSubnetDelay <= CrossSubnetDelay

Elija valores atenuados en función de cuánto tiempo de inactividad se tolera y de cuánto tiempo se dispone antes de que se pueda producir una acción correctiva en función de la aplicación, las necesidades empresariales y el entorno. Si no puede superar los valores predeterminados de Windows Server 2019, intente al menos igualarlos, si es posible:

Como referencia, en la tabla siguiente se detallan los valores predeterminados:

Configuración Windows Server 2019 Windows Server 2016 Windows Server 2008 - 2012 R2
SameSubnetDelay 1 segundo 1 segundo 1 segundo
SameSubnetThreshold 20 latidos 10 latidos 5 latidos
CrossSubnetDelay 1 segundo 1 segundo 1 segundo
CrossSubnetThreshold 20 latidos 10 latidos 5 latidos

Para más información, consulte Ajuste de los umbrales de red de clúster de conmutación por error.

Supervisión atenuada

Si el ajuste de la configuración de umbral y latido del clúster como se recomienda es una tolerancia insuficiente y sigue viendo conmutaciones por error debidos a problemas transitorios en lugar de a interrupciones reales, puede atenuar la supervisión de AG o FCI. En algunos escenarios, podría ser beneficioso atenuar temporalmente la supervisión durante un período de tiempo dado el nivel de actividad. Por ejemplo, puede que quiera atenuar la supervisión cuando realiza cargas de trabajo intensivas de E/S, como copias de seguridad de bases de datos, mantenimiento de índices, DBCC CHECKDB, etc. Una vez completada la actividad, establezca la supervisión en valores menos flexibles.

Advertencia

Cambiar esta configuración puede enmascarar un problema subyacente y debe usarse como una solución temporal para reducir, en lugar de eliminar, la probabilidad de error. Los problemas subyacentes deben investigarse y solucionarse.

Comience por aumentar los valores predeterminados de los siguientes parámetros para aligerar la supervisión y ajústelos según sea necesario:

Parámetro Valor predeterminado Valor relajado Descripción
Tiempo de espera de HealthCheck 30000 60000 Determina el estado de la réplica o nodo principal. La DLL de recursos de clúster de sp_server_diagnostics devuelve resultados en un intervalo que iguala 1/3 del umbral de tiempo de espera de comprobación de estado. Si sp_server_diagnostics es lento o no devuelve información, la DLL de recursos espera al intervalo completo del umbral de tiempo de espera de comprobación de estado antes de determinar que el recurso no responde e iniciar una conmutación automática por error, si está configurada para ello.
Nivel de condición de error 3 2 Condiciones que desencadenan una conmutación automática por error. Hay cinco niveles de condición de error que abarcan desde el nivel menos restrictivo (nivel uno) al más restrictivo (nivel cinco)

Use Transact-SQL (T-SQL) para modificar las condiciones de comprobación de estado y error de los AG y las FCI.

Para grupos de disponibilidad:

ALTER AVAILABILITY GROUP AG1 SET (HEALTH_CHECK_TIMEOUT =60000);
ALTER AVAILABILITY GROUP AG1 SET (FAILURE_CONDITION_LEVEL = 2);

Para instancias de clúster de conmutación por error:

ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY HealthCheckTimeout = 60000;
ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY FailureConditionLevel = 2;

Específico para grupos de disponibilidad, comience con los siguientes parámetros recomendados y ajústelos según sea necesario:

Parámetro Valor predeterminado Valor relajado Descripción
Tiempo de espera de concesión 20000 40000 Evita la división de cerebro.
Tiempo de espera de sesión 10000 20000 Comprueba las incidencias de comunicación entre réplicas. El período de tiempo de espera de la sesión es una propiedad de réplica que controla el número de segundos que una réplica de disponibilidad espera una respuesta de ping de una réplica conectada antes de determinar que la conexión ha sufrido un error. De forma predeterminada, una réplica espera 10 segundos la respuesta de un ping. Esta propiedad de réplica solamente se aplica a la conexión entre una réplica secundaria dada y la réplica principal del grupo de disponibilidad.
Número máximo de errores en el período especificado 2 6 Se usa para evitar el movimiento indefinido de un recurso en clúster dentro de varios errores de nodo. Un valor demasiado bajo puede dar lugar a que el grupo de disponibilidad esté en un estado de error. Aumente el valor para evitar interrupciones cortas por problemas de rendimiento, ya que un valor demasiado bajo puede provocar que el grupo de disponibilidad esté en un estado de error.

Antes de realizar cambios, tenga en cuenta lo siguiente:

  • No reduzca los valores de tiempo de espera por debajo de sus valores predeterminados.
  • Use esta ecuación para calcular el valor máximo de tiempo de espera de concesión: Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
    Comience con 40 segundos. Si usa los valores SameSubnetThreshold y SameSubnetDelay flexibles recomendados anteriormente, no supere los 80 segundos para el valor de tiempo de espera de concesión.
  • En el caso de las réplicas de confirmación sincrónica, cambiar el tiempo de espera de sesión a un valor alto puede aumentar las esperas HADR_sync_commit.

Tiempo de espera de concesión

Use el Administrador de clústeres de conmutación por error para modificar la configuración de tiempo de espera de concesión para el grupo de disponibilidad. Consulte la documentación de comprobación de estado de concesión del grupo de disponibilidad de SQL Server para obtener pasos detallados.

Tiempo de espera de sesión

Use Transact-SQL (T-SQL) para modificar el tiempo de espera de sesión de un grupo de disponibilidad:

ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON 'INSTANCE01' WITH (SESSION_TIMEOUT = 20);

Número máximo de errores en el período especificado

Use el Administrador de clústeres de conmutación por error para modificar el valor máximo de errores en el período especificado:

  1. Seleccione Roles en el panel de navegación.
  2. En Roles, haga clic con el botón derecho en el recurso en clúster y elija Propiedades.
  3. Seleccione la pestaña Conmutación por error y aumente el valor Máximo de errores en el período especificado según sea necesario.

Límites de recursos

Los límites de máquina virtual o disco podrían dar lugar a un cuello de botella de recursos que afecta al estado del clúster e impide la comprobación de estado. Si tiene incidencias con los límites de recursos, tenga en cuenta lo siguiente:

  • Use Análisis de E/S (versión preliminar) en Azure Portal para identificar problemas de rendimiento de disco que pueden provocar una migración tras error.
  • Asegúrese de que el sistema operativo, controladores y SQL Server disponen de las versiones más recientes.
  • Optimice SQL Server en el entorno de máquina virtual de Azure como se describe en las directrices de rendimiento para SQL Server en Azure Virtual Machines
  • Usar
  • Reduzca o propague la carga de trabajo para reducir el uso sin superar los límites de recursos
  • Ajuste la carga de trabajo de SQL Server si tiene alguna oportunidad, como por ejemplo
    • Agregue u optimice índices
    • Actualice las estadísticas si es necesario y, si es posible, con un examen completo
    • Use características como el regulador de recursos (a partir de SQL Server 2014, solo para empresas) para limitar el uso de recursos durante cargas de trabajo específicas, como copias de seguridad o mantenimiento de índices.
  • Cambie a una máquina virtual o disco que tenga límites más altos para satisfacer o superar las demandas de la carga de trabajo.

Redes

Implemente las máquinas virtuales con SQL Server en varias subredes siempre que sea posible para evitar la dependencia de un nombre de red distribuida (DNN) o una instancia de Azure Load Balancer para enrutar el tráfico a la solución de alta disponibilidad y recuperación ante desastres.

Use una sola NIC por servidor (nodo de clúster). La red de Azure tiene redundancia física, lo que hace que las NIC adicionales sean innecesarias en un clúster invitado de máquina virtual de Azure. El informe de validación de clúster le avisa de que solo se puede tener acceso a los nodos en una sola red. Puede omitir esta advertencia en los clústeres de conmutación por error invitados de máquinas virtuales de Azure.

Los límites de ancho de banda de una máquina virtual determinada se comparten entre las NIC y la adición de una NIC adicional no mejora el rendimiento del grupo de disponibilidad para SQL Server en máquinas virtuales de Azure. Por lo tanto, no es necesario agregar una segunda NIC.

El servicio DHCP no compatible con RFC en Azure puede hacer que se produzcan errores en la creación de determinadas configuraciones de clúster de conmutación por error. Este error se produce porque se asigna una dirección IP duplicada al nombre de red del clúster, como la misma dirección IP que uno de los nodos del clúster. Se trata de un problema al usar los grupos de disponibilidad, lo que depende de la característica de clúster de conmutación por error de Windows.

Considere un escenario en el que se crea un clúster de dos nodos y se pone en conexión:

  1. El clúster se conecta y NODE1 solicita una dirección IP asignada de manera dinámica para el nombre de red del clúster.
  2. El servicio DHCP no otorga ninguna dirección IP a excepción de la propia de NODE1, ya que el servicio DHCP reconoce que la solicitud proviene del NODE1 mismo.
  3. Windows detecta que se asigna una dirección duplicada tanto a NODE1 como al nombre de red del clúster de conmutación por error y que el grupo de clústeres predeterminado no puede ponerse en línea.
  4. El grupo de clústeres predeterminado se mueve a NODE2. NODO2 trata la dirección IP de NODE1 como la dirección IP del clúster y pone en línea el grupo de clústeres predeterminado.
  5. Cuando NODE2 intenta establecer conectividad con NODE1, los paquetes dirigidos a NODE1 nunca abandonan NODE2, porque resuelve la dirección IP de NODE1 en sí mismo. NODE2 no puede establecer conectividad con NODE1, pierde el cuórum y cierra el clúster.
  6. NODE1 puede enviar paquetes a NODE2, pero NODE2 no puede responder. Node1 pierde el cuórum y cierra el clúster.

Puede evitar este escenario asignando una dirección IP estática no utilizada al nombre de red del clúster para poner en línea el nombre de red del clúster y agregar la dirección IP a Azure Load Balancer.

Si el motor de base de datos de SQL Server, la escucha del grupo de disponibilidad Always On, el sondeo de estado de la instancia de clúster de conmutación por error, el punto de conexión de la creación de reflejo de la base de datos, el recurso IPD principal del clúster o cualquier otro recurso de SQL están configurados para usar un puerto entre 49 152 y 65 536 (el intervalo de puertos dinámicos predeterminado para TCP/IP), agregue una exclusión para cada puerto. Si lo hace, impide que otros procesos de sistemas se asignen dinámicamente al mismo puerto. En el ejemplo siguiente se crea una exclusión para el puerto 59999:

netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

Es importante configurar la exclusión de puertos cuando el puerto no está en uso; de lo contrario, se produce un error en el comando con un mensaje similar a "El proceso no puede acceder al archivo porque está en uso en otro proceso".

Para confirmar que las exclusiones se han configurado correctamente, use el siguiente comando: netsh int ipv4 show excludedportrange tcp.

El establecimiento de esta exclusión para el puerto de sondeo IP del rol de grupo de disponibilidad debe impedir eventos como los del identificador 1069 con el estado 10048. Este evento se puede ver en los eventos del clúster de conmutación por error de Windows con el siguiente mensaje:

Cluster resource '<IP name in AG role>' of type 'IP Address' in cluster role '<AG Name>' failed.
An Event ID: 1069 with status 10048 can be identified from cluster logs with events like:
Resource IP Address 10.0.1.0 called SetResourceStatusEx: checkpoint 5. Old state OnlinePending, new state OnlinePending, AppSpErrorCode 0, Flags 0, nores=false
IP Address <IP Address 10.0.1.0>: IpaOnlineThread: **Listening on probe port 59999** failed with status **10048**
Status [**10048**](/windows/win32/winsock/windows-sockets-error-codes-2) refers to: **This error occurs** if an application attempts to bind a socket to an **IP address/port that has already been used** for an existing socket.

Esto puede deberse a que un proceso interno toma el mismo puerto definido como puerto de sondeo. Recuerde que el puerto de sondeo se usa para comprobar el estado de una instancia del grupo de back-end desde Azure Load Balancer.
Si en el sondeo de estado no se obtiene una respuesta de una instancia de back-end, no se enviará ninguna nueva conexión a esa instancia de back-end hasta que el sondeo de estado se realice correctamente de nuevo.

Problemas conocidos

Revise las resoluciones para detectar las incidencias y errores más comunes.

La contención de recursos (E/S en particular) provoca conmutación por error

Agotar la capacidad de E/S o CPU de la máquina virtual puede hacer que el grupo de disponibilidad conmute por error. Identificar la contención que se produce justo antes de la conmutación por error es la manera más confiable de identificar lo que provoca la conmutación automática por error.

Uso de análisis de E/S

Use Análisis de E/S (versión preliminar) en Azure Portal para identificar problemas de rendimiento de disco que pueden provocar una migración tras error.

Supervisión con métricas de E/S de almacenamiento de máquinas virtuales

Supervise Azure Virtual Machines para ver las métricas de uso de E/S de almacenamiento para comprender la latencia de nivel de disco o máquina virtual.

Siga estos pasos para revisar el evento de agotamiento general de E/S de máquina virtual de Azure:

  1. Vaya a la máquina virtual en el portal de Azure, no a las máquinas virtuales SQL.

  2. Seleccione Métricas en Supervisión para abrir la página Métricas.

  3. Seleccione Hora local para especificar el intervalo de tiempo que le interesa y la zona horaria, ya sea local de la máquina virtual o UTC/GMT.

    Captura de pantalla de la página Métricas de Azure Portal en la que se selecciona cambiar el período de tiempo del gráfico.

  4. Seleccione Agregar métrica para agregar las dos métricas siguientes para ver el gráfico:

    • Porcentaje de consumo de ancho de banda en caché de máquinas virtuales
    • Porcentaje de consumo de ancho de banda que no está almacenado en caché de máquinas virtuales

Captura de pantalla de la página Métricas en Azure Portal.

Los objetos HostEvent de máquina virtual de Azure provocan la conmutación por error

Es posible que un objeto HostEvent de máquina virtual de Azure haga que el grupo de disponibilidad conmute por error. Si cree que un objeto HostEvent de máquina virtual de Azure produjo una conmutación por error, puede comprobar el registro de actividad de Azure Monitor y la información general sobre el estado de los recursos de máquina virtual de Azure.

El registro de actividad de Azure Monitor es un registro de plataforma de Azure que proporciona información sobre los eventos del nivel de suscripción. El registro de actividad incluye información como, por ejemplo, cuándo se modificó un recurso o cuándo se inició una máquina virtual. Puede ver el registro de actividad en el portal de Azure o recuperar entradas con PowerShell y la CLI de Azure.

Para comprobar el registro de actividad de Azure Monitor, siga estos pasos:

  1. En Azure Portal, vaya a la máquina virtual.

  2. Seleccione Registro de actividad en el panel Máquina virtual

  3. Seleccione Intervalo de tiempo y, luego, elija el período de tiempo en que el grupo de disponibilidad conmutó por error. Seleccione Aplicar.

    Captura de pantalla de Azure Portal que muestra el registro de actividad.

Si Azure tiene más información sobre la causa principal de una falta de disponibilidad iniciada por la plataforma, esa información puede publicarse en la página Máquina virtual de Azure: información general de Resource Health hasta 72 horas después de la falta de disponibilidad inicial. Esta información solo está disponible para las máquinas virtuales en este momento.

  1. En Azure Portal, vaya a la máquina virtual.
  2. Seleccione Estado del recurso en el panel Estado.

Captura de pantalla de la página Resource Health en Azure Portal.

Desde esta página, también puede configurar alertas basadas en eventos de estado.

Nodo de clúster eliminado de la pertenencia

Si la configuración de latido y umbral del clúster de Windows es demasiado agresiva para su entorno, es posible que vea el siguiente mensaje con frecuencia en el registro de eventos del sistema.

Error 1135
Cluster node 'Node1' was removed from the active failover cluster membership.
The Cluster service on this node may have stopped. This could also be due to the node having
lost communication with other active nodes in the failover cluster. Run the Validate a
Configuration Wizard to check your network configuration. If the condition persists, check
for hardware or software errors related to the network adapters on this node. Also check for
failures in any other network components to which the node is connected such as hubs, switches, or bridges.

Para más información, revise Solución de problemas de clúster con el id. de evento 1135.

La concesión ha caducado o ya no es válida

Si la supervisión es demasiado agresiva para su entorno, es posible que observe con frecuencia reinicios, errores o conmutaciones por error del grupo de disponibilidad o de la instancia de clúster de conmutación por error. Además, para los grupos de disponibilidad, puede ver los siguientes mensajes en el registro de errores de SQL Server:

Error 19407: The lease between availability group 'PRODAG' and the Windows Server Failover Cluster has expired.
A connectivity issue occurred between the instance of SQL Server and the Windows Server Failover Cluster.
To determine whether the availability group is failing over correctly, check the corresponding availability group
resource in the Windows Server Failover Cluster

Error 19419: The renewal of the lease between availability group '%.*ls' and the Windows Server Failover Cluster
failed because the existing lease is no longer valid.

Connection timeout

Si el tiempo de espera de la sesión es demasiado agresivo para el entorno del grupo de disponibilidad, es posible que vea los siguientes mensajes con frecuencia:

Error 35201: A connection timeout has occurred while attempting to establish a connection to availability
replica 'replicaname' with ID [availability_group_id]. Either a networking or firewall issue exists,
or the endpoint address provided for the replica is not the database mirroring endpoint of the host server instance.

Error 35206
A connection timeout has occurred on a previously established connection to availability
replica 'replicaname' with ID [availability_group_id]. Either a networking or a firewall issue
exists, or the availability replica has transitioned to the resolving role.

El grupo no se ha conmutado por error

Si el valor Máximo de errores en el período especificado es demasiado bajo y experimenta errores intermitentes debido a incidencias transitorias, el grupo de disponibilidad podría terminar en un estado de error. Aumente este valor para tolerar más errores transitorios.

Not failing over group <Resource name>, failoverCount 3, failoverThresholdSetting <Number>, computedFailoverThreshold 2.

Evento 1196: El recurso de nombre de red no pudo registrar el nombre DNS asociado

  • Compruebe la configuración de la NIC de cada uno de los nodos del clúster para asegurarse de que no hay ningún registro DNS externo presente.
  • Asegúrese de que existe el registro A en el clúster en los servidores DNS internos. Si no es así, cree un nuevo registro A en el servidor DNS para el objeto de control de acceso de clúster y active Permitir para que los usuarios autenticados actualicen los registros DNS con el mismo nombre de propietario.
  • Seleccione el recurso "Nombre del clúster" con el recurso IP sin conexión y corríjalo.

Evento 157 : El disco se ha quitado de manera inesperada.

Esto puede ocurrir si la propiedad de espacios de almacenamiento AutomaticClusteringEnabled está establecida en True para un entorno de AG. Cámbielo a False. Además, la ejecución de un informe de validación con la opción de almacenamiento puede desencadenar el restablecimiento del disco o el evento de eliminación imprevista. La limitación del sistema de almacenamiento también puede desencadenar el evento de eliminación del disco imprevista.

Evento 1206: El recurso de nombre de red de clústeres no se puede poner en conexión.

No se pudo actualizar el objeto de equipo asociado al recurso en el dominio. Asegúrese de tener los permisos adecuados en el dominio.

Errores de agrupación en clústeres de Windows

Puede encontrar problemas al configurar un clúster de conmutación por error de Windows o su conectividad si no tiene abiertos los puertos del servicio de clúster para la comunicación.

Si está en Windows Server 2019 y no ve una dirección IP del clúster de Windows, ha configurado el nombre de red distribuida, que solo se admite en SQL Server 2019. Si tiene versiones anteriores de SQL Server, puede quitar y volver a crear el clúster con el nombre de red.

Revise otros errores de eventos de clústeres de conmutación por error de Windows y sus soluciones aquí.

Pasos siguientes

Para obtener más información, consulte: