En este instructivo, se describe cómo habilitar la replicación asíncrona balanceada de Hyperdisk en dos Google Cloud regiones como una solución de recuperación ante desastres (DR) y cómo abrir las instancias de DR en caso de un desastre.
Las instancias de clústeres de conmutación por error (FCI) de Microsoft SQL Server son una sola instancia de SQL Server de alta disponibilidad que se implementa en varios nodos del clúster de conmutación por error de Windows Server (WSFC). En cualquier momento, uno de los nodos del clúster aloja de forma activa la instancia de SQL. En caso de una interrupción zonal o un problema de VM, WSFC transfiere automáticamente la propiedad de los recursos de la instancia a otro nodo dentro del clúster, lo que permite que los clientes se vuelvan a conectar. Las FCI de SQL Server requieren que los datos se ubiquen en discos compartidos para que se pueda acceder a ellos en todos los nodos de WSFC.
Para garantizar que la implementación de SQL Server pueda soportar una interrupción regional, habilita la replicación asíncrona para replicar los datos del disco de la región principal en una región secundaria. En este instructivo, se usan discos de Hyperdisk Balanced High Availability de multiescritura para habilitar la replicación asíncrona en dos regiones de Google Cloud como una solución de recuperación ante desastres (DR) para FCI de SQL Server y cómo abrir las instancias de DR en caso de un 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 instructivo está dirigido a ingenieros, administradores y arquitectos de bases de datos.
Objetivos
- Habilita la replicación asíncrona de Hyperdisk para todos los nodos del clúster de FCI de SQL Server que se ejecutan en Google Cloud.
- Simula un evento de desastre y realiza un proceso completo de DR para validar la configuración de DR.
Costos
En este documento, usarás los siguientes componentes facturables de Google Cloud:
Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.
Cuando finalices las tareas que se describen en este documento, puedes borrar los recursos que creaste para evitar que continúe la facturación. Para obtener más información, consulta Cómo realizar una limpieza.
Antes de comenzar
Para este instructivo, necesitas un Google Cloud proyecto. Puedes crear uno nuevo o seleccionar un proyecto que ya hayas creado:
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
In the Google Cloud console, activate Cloud Shell.
-
Para configurar el clúster de SQL Server en la región principal, sigue los pasos que se indican en esta guía Configura un clúster de FCI de SQL Server con el modo de multiescritura de alta disponibilidad equilibrada de Hyperdisk. Después de configurar el clúster, vuelve a este instructivo para habilitar la DR en la región secundaria.
Permisos adecuados en tu proyecto de Google Cloud y SQL Server para realizar copias de seguridad y restauraciones
Recuperación ante desastres en Google Cloud
La DR en Google Cloud implica mantener el acceso continuo a los datos cuando una región falla o se vuelve inaccesible. Existen varias opciones de implementación para el sitio de DR y las dictarán los requisitos del objetivo de punto de recuperación (RPO) y del objetivo de tiempo de recuperación (RTO). En este instructivo, se analiza una de las opciones en las que los discos conectados a la máquina virtual se replican de la instancia principal a la región de DR.
Recuperación ante desastres 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 la replicación de discos entre dos regiones. En el improbable caso de una interrupción regional, la replicación asíncrona de Hyperdisk te permite conmutar por error tus datos a 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 que está conectado a una carga de trabajo en ejecución, conocida como el disco principal, a un disco independiente ubicado en otra región. El disco que recibe la replicación se conoce como disco secundario. La región donde se ejecuta el disco principal se conoce como región principal, y la región donde se ejecuta el disco secundario es la región secundaria. Para garantizar que las réplicas de todos los discos conectados a cada nodo de SQL Server contengan datos del mismo momento, los discos se agregan a un grupo de coherencia. Los grupos de coherencia te permiten realizar pruebas de DR y DR en varios discos.
Arquitectura de recuperación ante desastres
En el caso de la replicación asíncrona de Hyperdisk, en el siguiente diagrama, se muestra una arquitectura mínima que admite la HA de la base de datos en una región principal, R1, y la replicación de discos de la región principal a la región secundaria, R2.
Figura 1. Arquitectura de recuperación ante desastres con Microsoft SQL Server y Hyperdisk Asynchronous Replication
Esta arquitectura funciona de la siguiente manera:
- Dos instancias de Microsoft SQL Server, una principal y una en espera, forman parte de un clúster de FCI y se encuentran en la región principal (R1), pero en diferentes zonas (zonas A y B). Ambas instancias comparten un disco de alta disponibilidad balanceada de Hyperdisk, lo que permite el acceso a los datos desde ambas VMs. Para obtener instrucciones, consulta Configura un clúster de FCI de SQL Server con el modo de multiescritura de alta disponibilidad equilibrada de Hyperdisk.
- Los discos de ambos nodos de SQL se agregan a los grupos de coherencia y se replican en la región de DR, R2. Compute Engine replica de forma asíncrona los datos de la R1 a la 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 DR, se crean VMs nuevas y los discos replicados existentes se conectan a las VMs para poner los nodos en línea.
Proceso de recuperación ante desastres
El proceso de DR prescribe los pasos operativos que debes seguir después de que una región deja de estar disponible para reanudar la carga de trabajo en otra región.
Un proceso de DR de la base de datos básico consta de los siguientes pasos:
- La primera región (R1), que ejecuta la instancia de base de datos principal, deja de estar disponible.
- El equipo de operaciones reconoce y confirma de manera formal el desastre y decide si se requiere una conmutación por error.
- Si se requiere una conmutación por error, debes finalizar la replicación entre los discos primario y secundario. Se crea una VM nueva a partir de las réplicas de disco y se pone en línea.
- La base de datos de la región de DR, R2, se valida y se pone en línea. La base de datos en R2 se convierte en la nueva base de datos principal, lo que habilita la conectividad.
- Los clientes reanudan el procesamiento en la base de datos principal nueva y acceden a la instancia principal en R2.
Aunque este proceso básico vuelve a establecer una base de datos principal en funcionamiento, no establece una arquitectura de alta disponibilidad completa, ya que no se replica la nueva base de datos principal.
Figura 2. Implementación de SQL Server después de la recuperación ante desastres con replicación asíncrona de Persistent Disk.
Usa como resguardo una región recuperada
Cuando la región principal (R1) está de nuevo en línea, puedes planificar y ejecutar el proceso de conmutación por error. El proceso de resguardo consta de todos los pasos que se describen en este instructivo, pero, en este caso, R2 es la fuente y R1 es la región de recuperación.
Elige una edición de SQL Server
Este instructivo 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 instructivo, 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 estándar de SQL Server:
Las versiones 2016, 2017, 2019 y 2022 de SQL Server tiene instalado Microsoft SQL Server Management Studio en la imagen; no necesitas instalarlo por separado. Sin embargo, en un entorno de producción, recomendamos que instales una instancia de Microsoft SQL Server Management Studio en una VM independiente en cada región. Si configuraste un entorno con alta disponibilidad, debes instalar Microsoft SQL Server Management Studio una vez en cada zona, para asegurarte de que esté disponible si otra zona no lo está.
Configura la recuperación ante desastres para Microsoft SQL Server
En este instructivo, se usa la imagen sql-ent-2022-win-2022 para Microsoft SQL Server Enterprise.
Para obtener una lista completa de imágenes, consulta Imágenes de SO.
Configura un clúster con alta disponibilidad de dos instancias
Para configurar la replicación de discos para 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 la principal, y la otra queda en espera. Para realizar este paso, sigue las instrucciones de Configura un clúster de FCI de SQL Server con el modo de multiescritura de alta disponibilidad equilibrada de Hyperdisk.
En este instructivo, se usa us-central1 para la región principal R1.
Si seguiste los pasos en
Configura un clúster de FCI de SQL Server con el modo de varios escritores de alta disponibilidad equilibrada de Hyperdisk,
habrás creado dos instancias de SQL Server en la misma región (us-central1). Implementarás la instancia principal de SQL Server (node-1) en
us-central1-a y una instancia en espera (node-2) en us-central1-b.
Habilita la replicación asíncrona del disco
Después de crear y configurar todas las VMs, habilita la replicación de discos entre las dos regiones completando los siguientes pasos:
Crea un grupo de coherencia para los 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 más de una zona, por lo que debes agregar 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
Agrega los discos de las VMs principales y en 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
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
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 DR.
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 momento, los datos deberían replicarse entre regiones.
El estado de replicación de cada disco debe decir Active.
Simula una recuperación ante desastres
En esta sección, probarás la arquitectura de recuperación ante desastres configurada en este instructivo.
Simula una interrupción y ejecuta una conmutación por error de recuperación ante desastres
Durante una conmutación por error, creas VMs nuevas en la región de DR y les conectas los discos replicados. Para simplificar la conmutación por error, puedes usar una nube privada virtual (VPC) diferente en la región de DR para la recuperación y usar la misma dirección IP.
Antes de iniciar la conmutación por error, asegúrate de que node-1 sea el nodo principal del grupo de disponibilidad AlwaysOn que creaste. Abre 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 separados.
Para simular una interrupción, sigue estos pasos:
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
Finaliza o detén 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
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
Cambia el nombre de las VMs existentes para evitar 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
Crea VMs en la región de DR con los discos secundarios. Estas VMs tendrán la dirección IP de la VM 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
Simulaste una interrupción y conmutaste por error a la región de DR. Ahora puedes probar si la instancia secundaria funciona correctamente.
Verifica la conectividad de SQL Server
Después de crear las VMs, verifica que las bases de datos se hayan recuperado correctamente y que el servidor funcione según lo esperado. Para probar la base de datos, ejecuta una consulta desde la base de datos recuperada.
- Conéctate a la VM de SQL Server con el escritorio remoto.
- Abre SQL Server Management Studio.
- En el cuadro de diálogo Conectar al servidor, verifica que el nombre del servidor esté configurado como
node-1y selecciona Conectar En el menú de archivo, selecciona Archivo > Nuevo > Consulta con la conexión actual.
USE [bookshelf]; SELECT * FROM Books;
Limpia
Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos que usaste en este instructivo, sigue los pasos de esta sección para borrar los recursos que creaste.
Borra el proyecto
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
¿Qué sigue?
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.