En este instructivo, se describe cómo habilitar la replicación asíncrona de Persistent Disk (replicación asíncrona de PD) en dos regiones de Google Cloud como una solución de recuperación ante desastres (DR) y cómo abrir las instancias de DR en caso de un desastre. Para los fines de este documento, un desastre es un evento en el que un clúster de alta disponibilidad (HA) de la base de datos principal falla o deja de estar disponible. Una base de datos principal puede fallar cuando la región en la que se encuentra falla o se vuelve inaccesible.
Este instructivo está dirigido a ingenieros, administradores y arquitectos de bases de datos.
Objetivos
- Habilitar la replicación asíncrona de Persistent Disks para todos los nodos del clúster del grupo de disponibilidad AlwaysOn de SQL Server que se ejecutan en Google Cloud.
- Simula un evento de desastre y realiza un proceso completo de recuperación ante desastres para validar la configuración de recuperación ante desastres.
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 proyecto de Cloud. 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.
Recuperación ante desastres en Google Cloud
En Google Cloud, la recuperación ante desastres (DR) se trata de proporcionar la continuidad del procesamiento, en especial 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 de máquina virtual (VM) se replican de la instancia principal a la región de DR.
Recuperación ante desastres para la replicación asíncrona de Persistent Disk
La replicación asíncrona de Persistent Disks (replicación asíncrona de PD) proporciona una replicación de almacenamiento en bloque de RPO y RTO baja para la DR activa-pasiva entre regiones.
PD Async Replication es una opción de almacenamiento que proporciona replicación asíncrona de datos entre dos regiones. En el improbable caso de una interrupción regional, PD Async Replication te permite conmutar por error los datos a una región secundaria y reiniciar las cargas de trabajo en esa región.
PD Async Replication 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 datos replicados se conoce como disco secundario.
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 PD, en el siguiente diagrama, se muestra una arquitectura mínima que admite la HA de la base de datos en una región principal y la replicación de discos de la región principal a la región de DR.
Figura 1. Arquitectura de recuperación ante desastres con Microsoft SQL Server y PD Async Replication
Esta arquitectura funciona de la siguiente manera:
- Dos instancias de Microsoft SQL Server, una principal y una en espera, forman parte de un grupo de disponibilidad y se encuentran en la misma región (R1), pero en diferentes zonas (zonas A y B). Las dos instancias en R1 coordinan sus estados mediante el modo de confirmación síncrona. El modo síncrono se usa porque admite alta disponibilidad y mantiene un estado de datos coherente.
- Los discos de ambos nodos de SQL se agregan a los grupos de coherencia y se replican en la región de DR R2. La infraestructura subyacente replica los datos de forma asíncrona.
- Solo los discos se replican en la región R2. 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 comienza cuando una región deja de estar disponible. El proceso de DR determina los pasos operativos que deben realizarse, ya sea de forma manual o automática, para mitigar la falla regional y establecer una instancia principal en ejecución en una región disponible.
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, se finalizará la replicación del disco de la instancia principal a la región de DR. Se crea una VM nueva a partir de las réplicas de disco y se pone en línea.
- La nueva base de datos principal en la región de DR (R2) se valida y se pone en línea, 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 en la que la instancia principal nueva tiene un nodo en espera.
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 Edition
- SQL Server 2017 Enterprise Edition
- SQL Server 2019 Enterprise Edition
- SQL Server 2022 Enterprise Edition
En el instructivo, se usa la función de grupos de disponibilidad AlwaysOn en SQL Server.
Si no necesitas una base de datos principal de Microsoft SQL Server con alta disponibilidad (HA), y una sola instancia de base de datos es suficiente para ser la principal, puedes usar las siguientes versiones de SQL Server:
- SQL Server 2016 Standard Edition
- SQL Server 2017 Standard Edition
- SQL Server 2019 Standard Edition
- SQL Server 2022 Standard Edition
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
A fin de configurar la replicación del disco en la región de DR para SQL Server, 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 grupos de disponibilidad AlwaysOn de SQL Server.
En este instructivo, se usa us-central1 para la región principal (denominada R1).
Si seguiste los pasos en Configura grupos de disponibilidad AlwaysOn de SQL Server, 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
Una vez que se hayan creado y configurado todas las VMs, habilita la copia de disco entre regiones mediante la creación de un grupo de coherencia para todos los discos conectados a las VMs. Los datos se copian de los discos de origen a los discos en blanco recién creados en la región designada.
Crea un grupo de coherencia para los nodos de SQL y el controlador de dominio. Una de las limitaciones de un disco zonal es que los grupos de coherencia no pueden abarcar más de una zona.
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
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-1-datadisk \ --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 node-2-datadisk \ --zone=$REGION-b \ --resource-policies=node-2-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 sincronizada
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-1-datadisk-replica \ --zone=$DR_REGION-a \ --size=$PD_SIZE \ --primary-disk=node-1-datadisk \ --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 node-2-datadisk-replica \ --zone=$DR_REGION-b \ --size=$PD_SIZE \ --primary-disk=node-2-datadisk \ --primary-disk-zone=$REGION-b 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-1-datadisk \ --zone=$REGION-a \ --secondary-disk=node-1-datadisk-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 node-2-datadisk \ --zone=$REGION-b \ --secondary-disk=node-2-datadisk-replica \ --secondary-disk-zone=$DR_REGION-b 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 de DR, 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 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/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
Crea VMs en la región de DR mediante réplicas de disco. Estas VMs tendrán la dirección IP de la VM de origen.
NODE1IP=$(gcloud compute instances describe node-1 --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\)) NODE2IP=$(gcloud compute instances describe node-2 --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\)) WITNESSIP=$(gcloud compute instances describe witness --zone $REGION-a --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=auto-delete=yes,boot=no,device-name=node-1-datadisk-replica,mode=rw,name=node-1-datadisk-replica 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
Simulamos una interrupción y conmutamos por error a la región de DR. Ahora podemos probar si la instancia secundaria funciona correctamente o no.
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, ejecutarás una consulta de selección 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;
Realiza una limpieza
Para evitar que se generen costos en tu cuenta de Google Cloud por los recursos que se usaron en este instructivo, sigue estos pasos:
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.