Grupos de disponibilidad Always On para SQL Server en Azure Virtual Machines

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

En este artículo se describen los grupos de disponibilidad AlwaysOn de SQL Server en Azure Virtual Machines (VM).

Para comenzar, consulte el tutorial del grupo de disponibilidad.

Información general

Los grupos de disponibilidad AlwaysOn en Azure Virtual Machines son similares a los grupos de disponibilidad AlwaysOn en el entorno local, y se basan en el clúster de conmutación por error de Windows Server subyacente. Sin embargo, dado que las máquinas virtuales se hospedan en Azure, existen algunas consideraciones adicionales, como la redundancia de máquinas virtuales y el enrutamiento del tráfico en la red de Azure.

En el diagrama siguiente se muestra un grupo de disponibilidad para SQL Server en Azure Virtual Machines:

Redundancia de máquina virtual

Para aumentar la redundancia y la alta disponibilidad, las máquinas virtuales de SQL Server deben estar en el mismo conjunto de disponibilidad o en distintas zonas de disponibilidad.

La colocación de un conjunto de máquinas virtuales en el mismo conjunto de disponibilidad protege frente a interrupciones en un centro de datos provocadas por un error del equipo (las máquinas virtuales dentro de un conjunto de disponibilidad no comparten recursos) o actualizaciones (las máquinas virtuales de un conjunto de disponibilidad no se actualizan al mismo tiempo).

Las zonas de disponibilidad protegen contra el error de un centro de datos completo, y cada zona representa un conjunto de centros de datos dentro de una región. Al asegurarse de que los recursos se colocan en diferentes zonas de disponibilidad, ninguna interrupción a nivel de centro de datos podrá desconectar todas las VM.

Al crear máquinas virtuales de Azure, debe elegir entre configurar conjuntos de disponibilidad y zonas de disponibilidad. Una máquina virtual de Azure no puede participar en ambos.

Aunque las zonas de disponibilidad pueden brindar una mejor disponibilidad que los conjuntos de disponibilidad (un 99,99 % frente al 99,95 %), el rendimiento también se debe tener en cuenta. Las máquinas virtuales dentro de un conjunto de disponibilidad se pueden colocar en un grupo de ubicación por proximidad que garantice que están próximas unas de otras, lo que minimiza la latencia de red entre ellas. Las máquinas virtuales ubicadas en distintas zonas de disponibilidad tienen una mayor latencia de red entre ellas, lo que puede aumentar el tiempo que se tarda en sincronizar los datos entre la réplica principal y las secundarias. Esto puede provocar retrasos en la réplica principal, así como aumentar la probabilidad de pérdida de datos en caso de una conmutación por error no planeada. Es importante probar la solución propuesta con carga y asegurarse de que cumpla con los Acuerdos de Nivel de Servicio tanto en lo relativo al rendimiento como a la disponibilidad.

Conectividad

Para que coincida con la experiencia local para conectarse al cliente de escucha del grupo de disponibilidad, implemente las máquinas virtuales de SQL Server en varias subredes dentro de la misma red virtual. Tener varias subredes elimina la necesidad de la dependencia adicional de una instancia de Azure Load Balancer o un nombre de red distribuida (DNN) para enrutar el tráfico al cliente de escucha.

Si implementa las máquinas virtuales de SQL Server en una sola subred, puede configurar un nombre de red virtual (VNN) y una instancia de Azure Load Balancer, o un nombre de red distribuida (DNN) para enrutar el tráfico al cliente de escucha del grupo de disponibilidad. Revise las diferencias entre los dos y, a continuación, implemente un nombre de red distribuida (DNN) o un nombre de red virtual (VNN) para el grupo de disponibilidad.

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

Además, hay algunas diferencias de comportamiento entre la funcionalidad del agente de escucha de VNN y el agente de escucha de DNN que son importantes tener en cuenta:

• Tiempo de conmutación por error: el tiempo de conmutación por error es más rápido cuando se usa un cliente de escucha de DNN, ya que no es necesario esperar a que el equilibrador de carga de red detecte el evento de error y cambie su enrutamiento.
• Conexiones existentes: Las conexiones establecidas con una base de datos específica dentro de un grupo de disponibilidad de conmutación por error se cerrarán, pero otras conexiones a la réplica principal permanecerán abiertas, ya que el DNN permanece en línea durante el proceso de conmutación por error. Esto es diferente de un entorno VNN tradicional en el que todas las conexiones a la réplica principal normalmente se cierran cuando se conmuta por error el grupo de disponibilidad, el agente de escucha se queda sin conexión y la réplica principal cambia al rol secundario. Al usar un agente de escucha de DNN, es posible que tenga que ajustar las cadenas de conexión de la aplicación para asegurarse de que las conexiones se redirijan a la nueva réplica principal tras la conmutación por error.
• Transacciones abiertas: Las transacciones abiertas en una base de datos de un grupo de disponibilidad con conmutación por error se cerrarán y revertirán, y tendrá que volver a conectarse manualmente. Por ejemplo, en SQL Server Management Studio, cierre la ventana de consulta y abra otra nueva.

La configuración de un agente de escucha de VNN en Azure requiere un equilibrador de carga. Hay dos opciones principales para los equilibradores de carga en Azure: externa (pública) o interna. El equilibrador de carga externo (público) es un equilibrador de carga accesible desde Internet y está asociado a una IP virtual pública que es accesible a través de Internet. Un equilibrador de carga interno solo admite clientes dentro de la misma red virtual. Para cualquiera de los tipos de equilibrador de carga, tiene que habilitar Direct Server Return.

Puede seguir conectándose a cada réplica de disponibilidad por separado conectándose directamente a la instancia del servicio. Además, como los grupos de disponibilidad son compatibles con las versiones anteriores de los clientes de creación de reflejo de la base de datos, puede conectarse a las réplicas de disponibilidad como asociados de creación de reflejo de la base de datos siempre y cuando las réplicas estén configuradas de forma similar a la creación de reflejo de la base de datos:

• Hay una réplica principal y una réplica secundaria.
• La réplica secundaria está configurada como no legible (la opción Secundaria legible está establecida en No).

A continuación, se muestra una cadena de conexión de cliente de ejemplo correspondiente a esta configuración similar a la creación de reflejo de la base de datos que usa ADO.NET o SQL Server Native Client:

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

Para obtener más información sobre la conectividad del cliente, consulte:

• Usar palabras clave de cadena de conexión con SQL Server Native Client
• Conectar clientes a una sesión de creación de reflejo de la base de datos (SQL Server)
• Conexión con el agente de escucha del grupo de disponibilidad en TI híbrida
• Agentes de escucha del grupo de disponibilidad, conectividad de cliente y conmutación por error de una aplicación (SQL Server)
• Uso de cadenas de conexión de creación de reflejo de la base de datos con grupos de disponibilidad

Una sola subred requiere un equilibrador de carga

Al crear un cliente de escucha de grupo de disponibilidad en un clúster de conmutación por error de Windows Server (WSFC) tradicional local, se crea un registro DNS para el cliente de escucha con la dirección IP que se proporcione y esta dirección IP se asigna a la dirección MAC de la réplica principal actual en las tablas de ARP de conmutadores y enrutadores de la red local. Para ello, el clúster usa Gratuitous ARP (GARP), que difunde a la red la última asignación de direcciones IP a MAC cada vez que se selecciona una nueva réplica principal tras la conmutación por error. En este caso, la dirección IP es del cliente de escucha y la dirección MAC es de la réplica principal actual. GARP fuerza una actualización a las entradas de la tabla de ARP de los conmutadores y enrutadores, y los usuarios que se conectan a la dirección IP del cliente de escucha se enrutan sin problemas a la réplica principal actual.

Por motivos de seguridad, no se permite la difusión en ninguna nube pública (Azure, Google, AWS), por lo que no se admiten los usos de ARP y GARP en Azure. Para superar esta diferencia en los entornos de red, las máquinas virtuales con SQL Server de un único grupo de disponibilidad de subred dependen de equilibradores de carga para enrutar el tráfico a las direcciones IP adecuadas. Los equilibradores de carga se configuran con una dirección IP de front-end que corresponde al cliente de escucha y se asigna un puerto de sondeo para que Azure Load Balancer sondee periódicamente el estado de las réplicas del grupo de disponibilidad. Puesto que solo la réplica principal de VM con SQL Server responde al sondeo TCP, el tráfico entrante se enruta a la máquina virtual que responde correctamente al sondeo. Además, el puerto de sondeo correspondiente se configura como la dirección IP del clúster de WSFC, lo que garantiza que la réplica principal responda al sondeo TCP.

Los grupos de disponibilidad configurados en una sola subred deben usar un equilibrador de carga o un nombre de red distribuido (DNN) para enrutar el tráfico a la réplica adecuada. Para evitar estas dependencias, configure el grupo de disponibilidad en varias subredes para que el cliente de escucha del grupo de disponibilidad esté configurado con una dirección IP de una réplica en cada subred y pueda enrutar el tráfico correctamente.

Si ya ha creado el grupo de disponibilidad en una sola subred, puede migrarlo a un entorno de varias subredes.

Mecanismo de concesión

Para SQL Server, la DLL de recursos del grupo de disponibilidad determina el estado del grupo de disponibilidad según el mecanismo de concesión del grupo de disponibilidad y la detección de estado de Always On. La DLL de recursos del grupo de disponibilidad expone el estado de los recursos a través de la operación IsAlive. El monitor de recursos sondea IsAlive en el intervalo de latidos del clúster, que se establece mediante los valores CrossSubnetDelay y SameSubnetDelay para todo el clúster. En un nodo principal, el servicio de clúster inicia la conmutación por error cada vez que la llamada de IsAlive a la DLL de recursos indica que el grupo de disponibilidad no tiene un estado correcto.

La DLL de recursos del grupo de disponibilidad supervisa el estado de los componentes internos de SQL Server. Sp_server_diagnostics notifica el estado de estos componentes a SQL Server en un intervalo controlado por HealthCheckTimeout.

A diferencia de otros mecanismos de conmutación por error, la instancia de SQL Server desempeña un rol activo en el mecanismo de concesión. El mecanismo de concesión se usa como validación Looks-Alive entre el host del recurso de clúster y el proceso de SQL Server. El mecanismo se usa para garantizar que los dos lados (el Servicio de clúster y el servicio de SQL Server) están en contacto con frecuencia, comprobando el estado del otro y evitando en última instancia un escenario de cerebro dividido.

Al configurar un grupo de disponibilidad en máquinas virtuales de Azure, a menudo es necesario configurar estos umbrales de manera diferente a como se configurarían en un entorno local. Para configurar los valores de umbral según los procedimientos recomendados para VM de Azure, consulte los procedimientos recomendados del clúster.

Configuración de red

Implemente las máquinas virtuales de 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 al cliente de escucha del grupo de disponibilidad.

En un clúster de conmutación por error de máquinas virtuales de Azure, se recomienda una sola NIC por servidor (nodo de clúster). Las redes de Azure tienen redundancia física, lo que hace que las NIC adicionales sean innecesarias en un clúster de conmutación por error de máquinas virtuales de Azure. Aunque el informe de validación del clúster emite una advertencia acerca de que los nodos solo son accesibles en una única red, esta advertencia puede omitirse de forma segura en los clústeres de conmutación por error de máquinas virtuales de Azure.

Grupo de disponibilidad básico

Como el grupo de disponibilidad básico no permite más de una réplica secundaria y no hay acceso de lectura a la réplica secundaria, puede usar las cadenas de conexión de creación de reflejo de la base de datos para los grupos de disponibilidad básicos. El uso de la cadena de conexión elimina la necesidad de tener agentes de escucha. La eliminación de la dependencia del agente de escucha es útil para los grupos de disponibilidad en VM de Azure, ya que elimina la necesidad de un equilibrador de carga o de tener que agregar direcciones IP adicionales al equilibrador de carga cuando se tienen varios agentes de escucha para bases de datos adicionales.

Por ejemplo, para conectarse explícitamente mediante TCP/IP a la base de datos AdventureWorks del grupo de disponibilidad en Replica_A o Replica_B de un grupo de disponibilidad básico (o cualquier grupo de disponibilidad que tenga solo una réplica secundaria y no se permita el acceso de lectura en la réplica secundaria), una aplicación cliente podría proporcionar la siguiente cadena de conexión de creación de reflejo de la base de datos para conectarse correctamente al grupo de disponibilidad.

Server=Replica_A; Failover_Partner=Replica_B; Database=AdventureWorks; Network=dbmssocn

Opciones de implementación

Hay varias opciones para implementar un grupo de disponibilidad en SQL Server en Azure Virtual Machines, algunas con más automatización que otras.

En la tabla siguiente se proporciona una comparación de las opciones disponibles:

Pasos siguientes

Para comenzar, revise los procedimientos recomendados de HADR y, luego, implemente el grupo de disponibilidad manualmente con el tutorial del grupo de disponibilidad.

Para obtener más información, consulte:

• Clúster de conmutación por error de Windows Server con SQL Server en máquinas virtuales de Azure
• Introducción a los grupos de disponibilidad Always On