IBM Cloud Docs
Patrón de despliegue de doble región multizona

Patrón de despliegue de doble región multizona

Los servidores virtuales de IBM Cloud Windows Server 2019 Standard configurados como nodos de Windows Server Failover Cluster (WSFC) y SQL Server Enterprise edition con grupos de disponibilidad SQL Server Always On configurados en cada nodo forman la base del patrón de despliegue de región multizona (MZR) dual. Esta arquitectura junto con MS ADDNS proporciona un despliegue de SQL Server para la recuperación de desastres.

Patrón de despliegue de doble MZR
Patrón de despliegue de doble MZR

El patrón de despliegue MZR dual que se muestra aprovecha el patrón de zona de disponibilidad (AZ) dual y lo amplía para que haya una copia de las bases de datos en una región remota; por lo tanto, este patrón es adecuado para bases de datos de producción que requieren recuperación ante desastres y aprovecha las siguientes tecnologías básicas:

  • Una IBM Cloud VPC con subredes en dos MZR.
  • Los grupos de seguridad se utilizan para controlar los flujos de tráfico entre los componentes.
  • Uno o varios hosts bastión utilizados para el acceso administrativo a los servidores.
  • IP flotante (FIP) conectada a los hosts bastión para permitir el acceso a Internet.
  • Tres servidores virtuales Windows Server 2019 Standard, uno en cada AZ en el MZR primario y un tercero en el MZR de recuperación, que son controladores de dominio Active Directory en el mismo forest\domain.
  • Tres servidores virtuales Windows Server 2019 Standard, uno en cada AZ del MZR primario y un tercero en el MZR de recuperación, que se convertirán en nodos de Windows Server Failover Cluster (WSFC).
  • Los grupos de disponibilidad Always On ofrecen la posibilidad de mantener un conjunto discreto de bases de datos en alta disponibilidad en uno o varios nodos de clúster y funcionan a nivel de base de datos. Los grupos de disponibilidad constan de una réplica primaria y hasta un máximo de ocho réplicas secundarias, y utilizan la replicación de datos síncrona o asíncrona. En este despliegue:
    • ios de replicación síncrona utilizados entre las dos AZ en la MZR primaria.
    • se utiliza la replicación asíncrona entre las MZR.
  • Distributed Network Names es un recurso de nombres en los grupos de disponibilidad WSFC y Always On, utilizado para la resolución de nombres de los recursos del clúster.

En esta implantación no es necesario un testigo de compartición de archivos porque hay un número impar de nodos y se utilizará el modo de quórum de Mayoría de Node

Clúster de conmutación por error de Windows Server

La implementación de grupos de disponibilidad Always On para HA en Windows requiere un clúster de conmutación por error de Windows Server (WSFC). Cada réplica de disponibilidad de un grupo de disponibilidad debe residir en un nodo diferente del WSFC. Para simplificar la configuración de seguridad de las bases de datos de disponibilidad, se recomienda que las instancias de SQL Server (las cuentas de servicio) se ejecuten bajo una cuenta de servicio de dominio.

Windows Server Failover Cluster (WSFC) es una característica de Windows Server y cada servidor que actúa como nodo de cluster debe tener esta característica habilitada. El CMCA se basa en el quórum de votos para evitar el síndrome del "cerebro dividido", y existen varios modos de quórum:

  • Mayoría de Node- Los nodos activos del clúster determinan el quórum. Al menos la mitad de los votos posibles deben ser afirmativos para que la agrupación mantenga un estado saludable.
  • Mayoría de Node y archivos compartidos: un archivo compartido remoto actúa como testigo de votación para los nodos activos que participan en una votación de quórum. Al igual que con la Mayoría de Node, al menos la mitad de los votos posibles deben ser afirmativos para que el clúster mantenga un estado saludable.
  • Mayoría de Node y discos - Un disco compartido actúa como testigo de votación, junto con los nodos activos implicados en una votación de quórum.
  • Sólo disco - Un disco compartido actúa como testigo y el quórum se determina por los nodos que pueden acceder al disco. No se requiere un número mínimo de votos posibles.

Las recomendaciones de Microsoft para SQL Server son las siguientes:

  • Utilice el modo de quórum Mayoría de Node cuando haya un número impar de nodos votantes.
  • Utilice el modo de quórum Mayoría de Node y archivos compartidos cuando tenga un número par de nodos con derecho a voto.

Grupos de disponibilidad Always On

Un grupo de disponibilidad admite un conjunto de bases de datos primarias y hasta ocho conjuntos de bases de datos secundarias. Las bases de datos secundarias no son copias de seguridad, por lo que es esencial realizar copias de seguridad de las bases de datos y sus registros de transacciones de forma regular. Los grupos de disponibilidad Always On requieren una de las siguientes tres opciones de tipo de clúster: WSFC, EXTERNO, NINGUNO.

  • WSFC - Utiliza Windows Server Failover Cluster (WSFC) para gestionar la conmutación por error del clúster. Se trata de un requisito previo para los grupos de alta disponibilidad en servidores Windows.
  • Externo - Utiliza un gestor de clúster externo. Por ejemplo, SQL Server en Linux es compatible con Pacemaker. Los grupos de disponibilidad en clústeres Linux requieren al menos dos réplicas síncronas para garantizar la HA, pero al menos tres réplicas para la recuperación automática, por lo que se recomienda configurar un grupo de disponibilidad en al menos tres nodos.
  • Ninguno - Se conocen como grupos de disponibilidad sin clúster o inicialmente se denominaban grupos de disponibilidad de escala de lectura. Sin embargo, esta opción sólo ofrece un subconjunto de funciones de los grupos de disponibilidad y no incluye la conmutación por error automática. Entre sus características se incluyen la conmutación por error manual planificada y forzada y los modos de replicación síncrono y asíncrono, los nodos secundarios legibles y las copias de seguridad de réplicas secundarias. Los grupos de disponibilidad sin un clúster WSFC aún pueden proporcionar nodos secundarios legibles, enrutamiento de sólo lectura y equilibrio de carga. La conmutación por error puede automatizarse con herramientas externas. Una nueva característica de SQL Server 2019 ayuda a mitigar esto con la redirección automática del tráfico, que proporciona el enrutamiento del tráfico de lectura/escritura de vuelta al nodo primario y no requiere un Listener.

La siguiente terminología se utiliza para describir los conceptos de grupo de disponibilidad:

  • Grupo de disponibilidad: admite un entorno replicado para un conjunto discreto de bases de datos de usuarios.
  • Grupo de disponibilidad HA - un grupo de bases de datos que fallan juntas.
  • Grupo de disponibilidad a escala de lectura: grupo de bases de datos que se copian a otras instancias de SQL Server Server para la carga de trabajo de sólo lectura.
  • Réplica primaria: hace que las bases de datos primarias estén disponibles para conexiones de lectura-escritura de clientes y envía registros de transacciones de cada base de datos primaria a cada base de datos secundaria.
  • Réplica secundaria: hasta ocho réplicas secundarias, cada una de las cuales aloja un conjunto de bases de datos secundarias y sirve como posible objetivo de conmutación por error para el grupo de disponibilidad de HA.

Modos de sincronización

Las réplicas secundarias del grupo de disponibilidad pueden configurarse con uno de los siguientes modos de sincronización:

  • Sincrónico - El registro se endurece (las transacciones se consignan en el registro de transacciones) en cada réplica secundaria antes de que la transacción se consigne en la réplica primaria. Esto garantiza una pérdida de datos cero, con un impacto potencial en el rendimiento de una carga de trabajo altamente transaccional si la latencia de la red es alta. Puede tener dos réplicas sincrónicas por AG. Este modo es el más adecuado para instancias en la misma AZ o MZR.
  • Asíncrono - La transacción se considera comprometida tan pronto como se endurece en el registro de transacciones en la réplica primaria. Si se produce un problema antes de que los registros se hayan reforzado en todas las réplicas secundarias, es posible que se produzca una pérdida de datos, y el punto de recuperación sería la última transacción realizada con éxito en todas las réplicas secundarias. Este modo es más adecuado para instancias en diferentes MZR o entre una AZ y on-premise.

Modos de conmutación por error

Cuando un grupo de disponibilidad falla, una réplica secundaria se convierte en la nueva primaria, y la réplica primaria, si está disponible, se convierte en una réplica secundaria.

  • Conmutación automática por error - Las conmutaciones automáticas por error proporcionan HA y se basan en objetos listener y WSFC correctamente configurados para su éxito. Sólo una réplica en modo de disponibilidad de compromiso síncrono puede ser el destino de una conmutación por error automática. Puede configurar las condiciones que provocan una conmutación por error automática en una escala de 1 a 5, donde 1 indica que sólo una interrupción total del servicio SQL Server en la réplica primaria iniciaría una conmutación por error, y 5 indica cualquiera de una serie de errores críticos a menos graves SQL Server. El valor predeterminado es 3, que provoca un fallo automático en caso de interrupción o de que la réplica primaria no responda, pero también para algunas condiciones críticas del servidor. Estas condiciones de "política de conmutación por error flexible" se detallan en Configurar una política de conmutación por error automática flexible para un grupo de disponibilidad Always On.
  • Conmutación por error planificada - Una conmutación por error planificada sólo puede producirse si no hay posibilidad de pérdida de datos. Concretamente, esto significa que la conmutación por error se produce sin utilizar el parámetro FORCE para reconocer las advertencias en el código o en los cuadros de diálogo de SSMS. Sólo es posible tener un failover planificado a una réplica secundaria en modo de disponibilidad synchronouscommit. Puede mover una réplica de modo de disponibilidad asíncrono-comprometido a síncrono, esperar al estado SINCRONIZADO y, a continuación, emitir una conmutación por error planificada sin pérdida de datos. Las conmutaciones por error planificadas deben iniciarse siempre a través de SSMS, T-SQL o PowerShell.
  • Failover forzado - Un failover forzado iniciado manualmente sólo debe iniciarse en respuesta a condiciones adversas del cluster, como la pérdida del nodo primario. Inicie desde asistentes SSMS, comandos T-SQL o PowerShell y sólo desde Windows Server Failover Cluster Manager como último recurso.
  • Forzar conmutación por error si el quórum de WSFC no funciona - No podrá forzar una conmutación por error para grupos de disponibilidad basados en un WSFC si el WSFC no tiene quórum. Primero tendrás que forzar el quórum en el Gestor de Configuración "amañando" la votación y modificando los pesos de los nodos. Debería considerar este paso sólo en casos de emergencia, como cuando un desastre ha interrumpido la mayoría de los nodos del clúster. Esto se puede lograr con un script PowerShell, para forzar a un nodo en línea a asumir el rol principal sin una mayoría de votos.

Las conmutaciones por error no están causadas por problemas en la base de datos, como que ésta se vuelva sospechosa debido a la pérdida de un archivo de datos o a la corrupción de un registro de transacciones.

Otros tipos de grupos de disponibilidad

Los siguientes grupos de disponibilidad no se utilizan en este patrón de despliegue, pero pueden ser de interés para los solucionadores que deseen adaptar o ampliar este patrón de despliegue:

  • Grupos de disponibilidad básicos: son una versión limitada de los grupos de disponibilidad y sólo se admiten en la edición SQL Server Standard. La única réplica secundaria no puede ser leída o respaldada y cada grupo de disponibilidad básico puede soportar sólo dos réplicas, pero múltiples grupos de disponibilidad básicos pueden ser configurados por servidor. Los grupos de disponibilidad básicos permiten muchas de las mismas características de los grupos de disponibilidad, incluida la replicación síncrona o asíncrona y las conmutaciones por error manuales o automáticas.
  • Grupos de disponibilidad distribuidos: permite que un grupo de disponibilidad trate a otro grupo de disponibilidad para que actúe como réplica secundaria. Las réplicas secundarias de sólo lectura pueden dispersarse globalmente, descargando cargas de trabajo a réplicas secundarias regionales de sólo lectura. Los dos grupos de disponibilidad, cada uno con su propio listener, no necesitan estar en la misma red o WSFC. Esto permite la HA y la DR geográficamente remotas a través de despliegues multisitio. Con los grupos de disponibilidad distribuidos, no es necesario que un WSFC abarque varias regiones. No hay conmutación por error automática entre el grupo de disponibilidad primario y el secundario. El grupo de disponibilidad que no es primario sólo puede servir consultas de sólo lectura, pero tiene una réplica primaria. La réplica primaria del grupo de disponibilidad secundario se encarga de replicar las transacciones a las demás réplicas secundarias del grupo de disponibilidad secundario. Esta arquitectura es útil para las actualizaciones de versiones de SO y SQL Server, ya que puede tener diferentes versiones de Windows Server en cada grupo de disponibilidad. Aunque cada grupo de disponibilidad en un escenario distribuido tiene su propio listener, el grupo de disponibilidad distribuido en su conjunto no lo tiene. Las aplicaciones, quizás con la ayuda de alias DNS, se conectarán a cada grupo de disponibilidad directamente después de una conmutación por error para aprovechar las réplicas secundarias legibles.

Nombres de redes distribuidas

Este despliegue utiliza Nombres de red distribuidos (DNN), que es un recurso de nombres en WSFC y grupos de disponibilidad Always On, utilizado para la resolución de nombres de los recursos del clúster. Se diferencia de un recurso de nombre de red estándar porque no requiere una dirección IP separada de las direcciones IP de los nodos y no requiere el uso del Protocolo Gratuito de Resolución de Direcciones (GARP) en la red cuando se produce una conmutación por error. En Windows Server 2019, el nombre del WSFC, que también es el Objeto de nombre de clúster (CNO) en los Servicios de dominio Active Directory y el oyente de la base de datos pueden crearse ambos con DNN.