Habilitar la recuperación tras fallos para Microsoft SQL Server en Hyperdisk

En este tutorial se describe cómo habilitar la replicación asíncrona de Hyperdisk Balanced en dos Google Cloud regiones como solución de recuperación tras desastres y cómo activar las instancias de recuperación tras desastres en caso de que se produzca un desastre.

.

Las instancias de clúster de conmutación por error (FCI) de Microsoft SQL Server son una única instancia de SQL Server de alta disponibilidad que se implementa en varios nodos de clúster de conmutación por error de Windows Server (WSFC). En cualquier momento, uno de los nodos del clúster aloja activamente la instancia de SQL. En caso de interrupción zonal o problema con la VM, WSFC transfiere automáticamente la propiedad de los recursos de la instancia a otro nodo del clúster, lo que permite que los clientes se vuelvan a conectar. SQL Server FCI requiere que los datos se ubiquen en discos compartidos para que se pueda acceder a ellos en todos los nodos de WSFC.

Para asegurarte de que la implementación de SQL Server pueda resistir una interrupción regional, replica los datos del disco de la región principal en una región secundaria habilitando la replicación asíncrona. En este tutorial se usan discos de escritura múltiple de alta disponibilidad equilibrados de Hyperdisk para habilitar la replicación asíncrona en dos Google Cloud regiones como solución de recuperación ante desastres para instancias de clústeres de conmutación por error de SQL Server. También se explica cómo activar las instancias de recuperación ante desastres en caso de desastre. En este documento, un desastre es un evento en el que un clúster de base de datos principal falla o deja de estar disponible porque la región del clúster deja de estar disponible, quizás debido a un desastre natural.

Este tutorial está dirigido a arquitectos, administradores e ingenieros de bases de datos.

Objetivos

  • Habilita la replicación asíncrona de Hyperdisk en todos los nodos del clúster de FCI de SQL Server que se ejecuten en Google Cloud.
  • Simula un desastre y lleva a cabo un proceso de recuperación ante desastres completo para validar la configuración.

Costes

En este documento, se utilizan los siguientes componentes facturables de Google Cloud:

Para generar una estimación de costes basada en el uso previsto, utiliza la calculadora de precios.

Los usuarios nuevos Google Cloud pueden disfrutar de una prueba gratuita.

Cuando termines las tareas que se describen en este documento, puedes evitar que se te siga facturando eliminando los recursos que has creado. Para obtener más información, consulta la sección Limpiar.

Antes de empezar

  1. Para seguir este tutorial, necesitas un Google Cloud proyecto. Puedes crear uno o seleccionar un proyecto que ya hayas creado:

    1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

      Roles required to select or create a project

      • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
      • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

      Go to project selector

    2. Verify that billing is enabled for your Google Cloud project.

    3. In the Google Cloud console, activate Cloud Shell.

      Activate Cloud Shell

    4. Configura el clúster de SQL Server en la región principal siguiendo los pasos de esta guía para configurar un clúster de FCI de SQL Server con el modo de escritura múltiple de alta disponibilidad equilibrado de Hyperdisk. Una vez que hayas configurado el clúster, vuelve a este tutorial para habilitar la recuperación ante desastres en la región secundaria.

    5. Permisos adecuados en tu proyecto de Google Cloud y en SQL Server para realizar copias de seguridad y restauraciones.

      6. Recuperación tras fallos en Google Cloud

      La recuperación ante desastres Google Cloud implica mantener el acceso continuo a los datos cuando una región falla o se vuelve inaccesible. Hay varias opciones de implementación para el sitio de recuperación tras desastres, que se determinarán en función de los requisitos de objetivo de punto de recuperación (RPO) y objetivo de tiempo de recuperación (RTO). En este tutorial se explica una de las opciones en las que los discos conectados a la máquina virtual se replican de la región principal a la de recuperación ante desastres.

      Recuperación tras fallos con la replicación asíncrona de Hyperdisk

      La replicación asíncrona de Hyperdisk es una opción de almacenamiento que proporciona una copia de almacenamiento asíncrona para replicar discos entre dos regiones. En el improbable caso de una interrupción regional, la replicación asíncrona de Hyperdisk te permite realizar una conmutación por error de tus datos en una región secundaria y reiniciar tus cargas de trabajo en esa región.

      La replicación asíncrona de Hyperdisk replica los datos de un disco conectado a una carga de trabajo en ejecución (denominado "disco principal") en un disco independiente ubicado en otra región. El disco que recibe la réplica se denomina disco secundario. La región en la que se ejecuta el disco principal se denomina región principal, y la región en la que se ejecuta el disco secundario es la región secundaria. Para asegurarse de que las réplicas de todos los discos conectados a cada nodo de SQL Server contengan datos del mismo momento, los discos se añaden a un grupo de coherencia. Los grupos de coherencia te permiten realizar pruebas de recuperación ante desastres en varios discos.

      Arquitectura de recuperación tras fallos

      En el caso de la replicación asíncrona de Hyperdisk, el siguiente diagrama muestra una arquitectura mínima que admite la alta disponibilidad de la base de datos en una región primaria, R1, y la replicación de discos de la región primaria a la secundaria, R2.

      Las instancias principales y de espera se encuentran en dos zonas de la región R1. Los discos subyacentes se replican mediante la replicación asíncrona en la región R2.

      Imagen 1. Arquitectura de recuperación tras fallos con Microsoft SQL Server y replicación asíncrona de Hyperdisk

      Esta arquitectura funciona de la siguiente manera:

      • Dos instancias de Microsoft SQL Server, una instancia principal y una instancia de espera, forman parte de un clúster de FCI y se encuentran en la región principal (R1), pero en zonas diferentes (zonas A y B). Ambas instancias comparten un disco Hyperdisk Balanced High Availability, lo que permite acceder a los datos desde ambas máquinas virtuales. Para obtener instrucciones, consulta Configurar un clúster de FCI de SQL Server con el modo de escritura múltiple de alta disponibilidad equilibrado de HyperDisk.
      • Los discos de ambos nodos de SQL se añaden a grupos de coherencia y se replican en la región de recuperación ante desastres, R2. Compute Engine replica los datos de forma asíncrona de R1 a R2.
      • La replicación asíncrona solo replica los datos de los discos en R2 y no replica los metadatos de la VM. Durante la recuperación ante desastres, se crean nuevas VMs y los discos replicados se asocian a las VMs para poner los nodos online.

      Proceso de recuperación tras fallos

      El proceso de recuperación ante desastres describe los pasos operativos que debes seguir después de que una región deje de estar disponible para reanudar la carga de trabajo en otra región.

      Un proceso básico de recuperación ante desastres de una base de datos consta de los siguientes pasos:

      1. La primera región (R1), que ejecuta la instancia de base de datos principal, deja de estar disponible.
      2. El equipo de Operaciones reconoce formalmente el desastre y decide si es necesario realizar una conmutación por error.
      3. Si es necesario realizar una conmutación por error, debe finalizar la replicación entre los discos principal y secundario. Se crea una VM a partir de las réplicas del disco y se pone online.
      4. La base de datos de la región de recuperación ante desastres, R2, se valida y se pone online. La base de datos de R2 se convierte en la nueva base de datos principal, lo que permite la conectividad.
      5. Los usuarios reanudan el procesamiento en la nueva base de datos principal y acceden a la instancia principal de R2.

      Aunque este proceso básico vuelve a establecer una base de datos principal operativa, no establece una arquitectura de alta disponibilidad completa, ya que la nueva base de datos principal no se replica.

      Las instancias principales y de espera se encuentran en dos zonas de la región R1, y los discos subyacentes se replican mediante la replicación asíncrona en la región R2.

      Imagen 2. Implementación de SQL Server tras la recuperación tras fallos con la réplica asíncrona de Persistent Disk

      Volver a una región recuperada

      Cuando la región principal (R1) vuelva a estar online, puedes planificar y ejecutar el proceso de recuperación. El proceso de conmutación por recuperación consta de todos los pasos descritos en este tutorial, pero, en este caso, R2 es el origen y R1 es la región de recuperación.

      Elegir una edición de SQL Server

      Este tutorial es compatible con las siguientes versiones de Microsoft SQL Server:

      • SQL Server 2016 Enterprise y Standard Edition
      • SQL Server 2017 Enterprise y Standard Edition
      • SQL Server 2019 Enterprise y Standard Edition
      • SQL Server 2022 Enterprise y Standard Edition

      En el tutorial se usa la instancia de clúster de conmutación por error de SQL Server con el disco Hyperdisk Balanced High Availability.

      Si no necesitas las funciones de SQL Server Enterprise, puedes usar la edición Standard de SQL Server:

      Las versiones 2016, 2017, 2019 y 2022 de SQL Server tienen Microsoft SQL Server Management Studio instalado en la imagen, por lo que no es necesario instalarlo por separado. Sin embargo, en un entorno de producción, te recomendamos que instales una instancia de Microsoft SQL Server Management Studio en una VM independiente de cada región. Si configura un entorno de alta disponibilidad, debe instalar Microsoft SQL Server Management Studio una vez por cada zona para asegurarse de que siga estando disponible si otra zona deja de estarlo.

      Configurar la recuperación tras fallos para Microsoft SQL Server

      En este tutorial se usa la imagen de sql-ent-2022-win-2022 para Microsoft SQL Server Enterprise.

      Para ver una lista completa de las imágenes, consulta Imágenes de SO.

      Configurar un clúster de alta disponibilidad de dos instancias

      Para configurar la replicación de discos de SQL Server entre dos regiones, primero crea un clúster de alta disponibilidad de dos instancias en una región. Una instancia actúa como principal y la otra como de reserva. Para completar este paso, sigue las instrucciones que se indican en el artículo sobre cómo configurar un clúster de FCI de SQL Server con el modo de escritura múltiple de alta disponibilidad equilibrado de Hyperdisk. En este tutorial se usa us-central1 para la región principal R1. Si has seguido los pasos descritos en Configurar un clúster de FCI de SQL Server con el modo de escritura múltiple de alta disponibilidad de Hyperdisk Balanced, habrás creado dos instancias de SQL Server en la misma región (us-central1). Habrás implementado una instancia de SQL Server principal (node-1) en us-central1-a y una instancia de espera (node-2) en us-central1-b.

      Habilitar la réplica asíncrona de discos

      Una vez que haya creado y configurado todas las VMs, habilite la replicación de discos entre las dos regiones siguiendo estos pasos:

      1. Crea un grupo de coherencia para ambos nodos de SQL Server y el nodo que aloja los roles de testigo y controlador de dominio. Una de las limitaciones de los grupos de coherencia es que no pueden abarcar varias zonas, por lo que debes añadir cada nodo a un grupo de coherencia independiente.

        gcloud compute resource-policies create disk-consistency-group node-1-disk-const-grp \
--region=$REGION

gcloud compute resource-policies create disk-consistency-group node-2-disk-const-grp \
--region=$REGION

gcloud compute resource-policies create disk-consistency-group witness-disk-const-grp \
--region=$REGION

gcloud compute resource-policies create disk-consistency-group multiwriter-disk-const-grp \
--region=$REGION

      2. Añade los discos de las máquinas virtuales principal y de espera a los grupos de coherencia correspondientes.

        gcloud compute disks add-resource-policies node-1 \
--zone=$REGION-a \
--resource-policies=node-1-disk-const-grp

gcloud compute disks add-resource-policies node-2 \
--zone=$REGION-b \
--resource-policies=node-2-disk-const-grp

gcloud compute disks add-resource-policies mw-datadisk-1 \
--region=$REGION \
--resource-policies=multiwriter-disk-const-grp

gcloud compute disks add-resource-policies witness \
--zone=$REGION-c \
--resource-policies=witness-disk-const-grp

      3. Crea discos secundarios en blanco en la región secundaria.

        DR_REGION="us-west1"
gcloud compute disks create node-1-replica \
  --zone=$DR_REGION-a \
  --size=50 \
  --primary-disk=node-1 \
  --primary-disk-zone=$REGION-a

gcloud compute disks create node-2-replica \
  --zone=$DR_REGION-b \
  --size=50 \
  --primary-disk=node-2 \
  --primary-disk-zone=$REGION-b

gcloud compute disks create multiwriter-datadisk-1-replica \
  --replica-zones=$DR_REGION-a,$DR_REGION-b \
  --size=$PD_SIZE \
  --type=hyperdisk-balanced-high-availability \
  --access-mode READ_WRITE_MANY \
  --primary-disk=multiwriter-datadisk-1 \
  --primary-disk-region=$REGION

gcloud compute disks create witness-replica \
  --zone=$DR_REGION-c \
  --size=50 \
  --primary-disk=witness \
  --primary-disk-zone=$REGION-c

      4. Inicia la replicación del disco. Los datos se replican del disco principal al disco en blanco recién creado en la región de recuperación ante desastres.

        gcloud compute disks start-async-replication node-1 \
  --zone=$REGION-a \
  --secondary-disk=node-1-replica \
  --secondary-disk-zone=$DR_REGION-a

gcloud compute disks start-async-replication node-2 \
  --zone=$REGION-b \
  --secondary-disk=node-2-replica \
  --secondary-disk-zone=$DR_REGION-b

gcloud compute disks start-async-replication multiwriter-datadisk-1 \
  --region=$REGION \
  --secondary-disk=multiwriter-datadisk-1-replica \
  --secondary-disk-region=$DR_REGION

gcloud compute disks start-async-replication witness \
  --zone=$REGION-c \
  --secondary-disk=witness-replica \
  --secondary-disk-zone=$DR_REGION-c

      En este punto, los datos deberían replicarse entre las regiones. El estado de replicación de cada disco debe ser Active.

      Simular una recuperación tras fallos

      En esta sección, probarás la arquitectura de recuperación tras fallos configurada en este tutorial.

      Simular una interrupción del servicio y ejecutar una conmutación por error de recuperación tras desastres

      Durante una conmutación por error, creas VMs en la región de recuperación ante desastres y les adjuntas los discos replicados. Para simplificar la conmutación por error, puedes usar otra nube privada virtual (VPC) en la región de recuperación ante desastres para la recuperación, de forma que puedas usar la misma dirección IP.

      Antes de iniciar la conmutación por error, asegúrese de que node-1 sea el nodo principal del grupo de disponibilidad Always On que ha creado. Inicia el controlador de dominio y el nodo principal de SQL Server para evitar problemas de sincronización de datos, ya que los dos nodos están protegidos por dos grupos de coherencia independientes. Para simular una interrupción, sigue estos pasos:

      1. Crea una VPC de recuperación.

        DRVPC_NAME="default-dr"
DRSUBNET_NAME="default-recovery"

gcloud compute networks create $DRVPC_NAME \
--subnet-mode=custom

CIDR=$(gcloud compute networks subnets describe default \
--region=$REGION --format=value\(ipCidrRange\))

gcloud compute networks subnets create $DRSUBNET_NAME \
--network=$DRVPC_NAME --range=$CIDR --region=$DR_REGION

      2. Finalizar o detener la replicación de datos.

        PROJECT=$(gcloud config get-value project)

gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/node-1-disk-const-grp \
--zone=$REGION-a

gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/node-2-disk-const-grp \
--zone=$REGION-b

gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/multiwriter-disk-const-grp \
--zone=$REGION-c

gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/witness-disk-const-grp \
--zone=$REGION-c

      3. Detén las VMs de origen en la región principal.

        gcloud compute instances stop node-1 \
  --zone=$REGION-a

gcloud compute instances stop node-2 \
  --zone=$REGION-b

gcloud compute instances stop witness \
  --zone=$REGION-c

      4. Cambia el nombre de las VMs para evitar que haya nombres duplicados en el proyecto.

        gcloud compute instances set-name witness \
--new-name=witness-old \
--zone=$REGION-c

gcloud compute instances set-name node-1 \
--new-name=node-1-old \
--zone=$REGION-a

gcloud compute instances set-name node-2 \
--new-name=node-2-old \
--zone=$REGION-b

      5. Crea VMs en la región de recuperación ante desastres con los discos secundarios. Estas máquinas virtuales tendrán la dirección IP de la máquina virtual de origen.

        NODE1IP=$(gcloud compute instances describe node-1-old --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\))
NODE2IP=$(gcloud compute instances describe node-2-old --zone $REGION-b --format=value\(networkInterfaces[0].networkIP\))
WITNESSIP=$(gcloud compute instances describe witness-old --zone $REGION-c --format=value\(networkInterfaces[0].networkIP\))

gcloud compute instances create node-1 \
  --zone=$DR_REGION-a \
  --machine-type $MACHINE_TYPE \
  --network=$DRVPC_NAME \
  --subnet=$DRSUBNET_NAME \
  --private-network-ip $NODE1IP\
  --disk=boot=yes,device-name=node-1-replica,mode=rw,name=node-1-replica \
  --disk=boot=no,device-name=mw-datadisk-1-replica,mode=rw,name=mw-datadisk-1-replica,scope=regional

gcloud compute instances create witness \
  --zone=$DR_REGION-c \
  --machine-type=n2-standard-2 \
  --network=$DRVPC_NAME \
  --subnet=$DRSUBNET_NAME \
  --private-network-ip $WITNESSIP \
  --disk=boot=yes,device-name=witness-replica,mode=rw,name=witness-replica

gcloud compute instances create node-2 \
  --zone=$DR_REGION-b \
  --machine-type $MACHINE_TYPE \
  --network=$DRVPC_NAME \
  --subnet=$DRSUBNET_NAME \
  --private-network-ip $NODE2IP\
  --disk=boot=yes,device-name=node-2-replica,mode=rw,name=node-2-replica \
  --disk=boot=no,device-name=mw-datadisk-1-replica,mode=rw,name=mw-datadisk-1-replica,scope=regional

      Has simulado una interrupción del servicio y has conmutado por error a la región de recuperación ante desastres. Ahora puedes probar si la instancia secundaria funciona correctamente.

      Verificar la conectividad de SQL Server

      Después de crear las máquinas virtuales, comprueba que las bases de datos se han recuperado correctamente y que el servidor funciona como se espera. Para probar la base de datos, ejecuta una consulta desde la base de datos recuperada.

      1. Conéctate a la máquina virtual de SQL Server mediante Escritorio remoto.
      2. Abre SQL Server Management Studio.
      3. En el cuadro de diálogo Conectar con el servidor, comprueba que el nombre del servidor sea node-1 y selecciona Conectar.

      4. En el menú Archivo, selecciona Archivo > Nuevo > Consulta con la conexión actual.

        USE [bookshelf];
SELECT * FROM Books;

      Limpieza

      Para evitar que se apliquen cargos en tu Google Cloud cuenta por los recursos utilizados en este tutorial, sigue los pasos de esta sección para eliminar los recursos que has creado.

      Eliminar el proyecto

      1. In the Google Cloud console, go to the Manage resources page.

        Go to Manage resources

      2. In the project list, select the project that you want to delete, and then click Delete.
      3. In the dialog, type the project ID, and then click Shut down to delete the project.

      Siguientes pasos