Implementa Microsoft SQL Server para la recuperación ante desastres multirregional

---

En este instructivo, se describe cómo implementar y administrar un sistema de base de datos de Microsoft SQL Server en dos regiones de Google Cloud como una solución de recuperación ante desastres (DR) y cómo realizar una conmutación por error de una instancia de base de datos con errores a una que funciona con normalidad. Para los fines de este documento, un desastre es un evento en el que una 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. Incluso si una región está disponible y funciona con normalidad, una base de datos principal puede fallar debido a un error del sistema. En estos casos, la recuperación ante desastres es el proceso de hacer que una base de datos secundaria esté disponible para los clientes con un procesamiento continuo.

Este instructivo está dirigido a ingenieros, administradores y arquitectos de bases de datos.

Objetivos

• Implementa un entorno de recuperación ante desastres multirregional en Google Cloud mediante los grupos de disponibilidad AlwaysOn de Microsoft SQL Server.
• 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:

• Compute Engine
• SQL Server VMs

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios. Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

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:

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

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

2. Make sure that billing is enabled for your Google Cloud project.

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

   Activate Cloud Shell

Información sobre la recuperación ante desastres

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. Para sistemas como un sistema de administración de bases de datos, debes realizar la DR mediante la implementación del sistema en al menos dos regiones. Con esta configuración, el sistema continúa en funcionamiento si una región deja de estar disponible.

Recuperación ante desastres del sistema de base de datos

El proceso de hacer que una base de datos secundaria esté disponible cuando la instancia principal de la base de datos falla se denomina recuperación ante desastres de la base de datos (o DR de la base de datos). Si deseas obtener un análisis detallado de este concepto, consulta Recuperación ante desastres para Microsoft SQL Server. Lo ideal es que el estado de la base de datos secundaria sea coherente con la base de datos principal en el momento en que la principal deje de estar disponible, o que a la base de datos secundaria solo le falte un pequeño conjunto de transacciones recientes de la base de datos principal.

Arquitectura de recuperación ante desastres

Para Microsoft SQL Server, en el siguiente diagrama, se muestra una arquitectura mínima que admite la DR de la base de datos.

Figura 1. Arquitectura de recuperación ante desastres estándar con Microsoft SQL Server.

Esta arquitectura funciona de la siguiente manera:

• Dos instancias de Microsoft SQL Server (una instancia principal y una en espera) 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.
• Una instancia de Microsoft SQL Server (la instancia de recuperación ante desastres o secundaria) se encuentra en una segunda región (R2). Para la DR, la instancia secundaria en R2 se sincroniza con la instancia principal en R1 mediante el modo de confirmación asíncrona. El modo asíncrono se usa debido a su rendimiento (no ralentiza el procesamiento de confirmación en la instancia principal).

En el diagrama anterior, la arquitectura muestra un grupo de disponibilidad. El grupo de disponibilidad, si se usa con un objeto de escucha, proporciona la misma string de conexión a los clientes si estos se entregan con lo siguiente:

• La instancia principal
• La instancia en espera (después de una falla de la zona)
• La instancia secundaria (después de una falla de la región y después de que la instancia secundaria se convierte en la instancia principal nueva)

En una variante de la arquitectura anterior, debes implementar las dos instancias que se encuentran en la primera región (R1) en la misma zona. Este enfoque puede mejorar el rendimiento, pero no tiene alta disponibilidad. Para iniciar el proceso de DR, se podría requerir una interrupción de una sola zona.

Proceso básico de recuperación ante desastres

El proceso de DR comienza cuando una región deja de estar disponible y la base de datos principal conmuta por error para reanudar el procesamiento en otra región operativa. 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:

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 y confirma de manera formal el desastre y decide si se requiere una conmutación por error.
3. Si se requiere una conmutación por error, la instancia de base de datos secundaria en la segunda región (R2) se convertirá en la instancia principal nueva.
4. 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 DR completa en la que la instancia principal nueva tiene una instancia de base de datos secundaria y una en espera.

Proceso completo de recuperación ante desastres

Un proceso completo de DR extiende el proceso básico de DR mediante la adición de pasos para establecer una arquitectura de DR completa luego de una conmutación por error. En el siguiente diagrama, se muestra una arquitectura completa de DR de base de datos.

Figura 2. Recuperación ante desastres con una región principal no disponible (R1).

Esta arquitectura completa de DR de base de datos funciona de la siguiente manera:

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 y confirma de manera formal el desastre y decide si se requiere una conmutación por error.
3. Si se requiere una conmutación por error, la instancia de base de datos secundaria en la segunda región (R2) se convertirá en la instancia principal.
4. Otra instancia secundaria, la instancia en espera nueva, se crea y se inicia en R2 y se agrega a la instancia principal. La instancia en espera está en una zona diferente que la principal. La base de datos principal ahora consta de dos instancias (principal y en espera) con alta disponibilidad.
5. En una tercera región (R3), se crea y se inicia una instancia de base de datos secundaria nueva (en espera). Esta instancia secundaria se conecta de forma asíncrona a la instancia principal nueva en R2. En este punto, la arquitectura de recuperación ante desastres original ya se volvió a crear y está en funcionamiento.

Usa como resguardo una región recuperada

Después de que la primera región (R1) esté de nuevo en línea, puede alojar la base de datos secundaria nueva. Si R1 está disponible a tiempo, puedes implementar el paso 5 en el proceso de recuperación completo en R1 en lugar de R3 (la tercera región). En este caso, no se necesita una tercera región.

En el siguiente diagrama, se muestra la arquitectura si R1 está disponible a tiempo.

Figura 3. Recuperación ante desastres luego de que la región con errores R1 vuelve a estar disponible.

En esta arquitectura, los pasos de recuperación son los mismos que se describieron antes en Completa el proceso de recuperación ante desastres, con la diferencia de que R1 se convierte en la ubicación de las instancias secundarias, en lugar de R3.

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 Microsoft SQL Server para la DR multirregional

En esta sección, se usan las siguientes imágenes para Microsoft SQL Server:

• sql-ent-2016-win-2016 para Microsoft SQL Server 2016 Enterprise Edition
• sql-ent-2017-win-2016 para Microsoft SQL Server 2017 Enterprise Edition
• sql-ent-2019-win-2019 para Microsoft SQL Server 2019 Enterprise Edition
• sql-ent-2022-win-2022 para Microsoft SQL Server 2022 Enterprise Edition

Para obtener una lista completa de imágenes, consulta Imágenes.

Configura un clúster con alta disponibilidad de dos instancias

A fin de configurar una arquitectura de DR de base de datos multirregional para SQL Server, primero debes crear un clúster con alta disponibilidad (HA) de dos instancias en una región. Una instancia actúa como la principal, y la otra actúa como secundaria. 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). Antes de comenzar, revisa las siguientes consideraciones:

• 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.

• Aunque implementes la arquitectura de la Figura 4 para este instructivo, se recomienda configurar un controlador de dominio en más de una zona. Este enfoque garantiza que establezcas una arquitectura de base de datos con alta disponibilidad y habilitada para DR. Por ejemplo, si se produce una interrupción en una zona, esta no se convierte en un punto único de fallo para la arquitectura que se implementó.

Figura 4. Arquitectura de recuperación ante desastres estándar implementada en este instructivo.

Agrega una instancia secundaria para la recuperación ante desastres

A continuación, configura una tercera instancia de SQL Server (una instancia secundaria llamada node-3) y configura la red de la siguiente manera:

1. Crea una secuencia de comandos de specialize para los nodos de clústeres de conmutación por error de Windows Server. La secuencia de comandos instala la función necesaria de Windows y crea reglas de firewall para WSFC y SQL Server. También da formato al disco de datos y crea carpetas de datos y registros para SQL Server:

   cat << "EOF" > specialize-node.ps1
   
   $ErrorActionPreference = "stop"
   
   # Install required Windows features
   Install-WindowsFeature Failover-Clustering -IncludeManagementTools
   Install-WindowsFeature RSAT-AD-PowerShell
   
   # Open firewall for WSFC
   netsh advfirewall firewall add rule name="Allow SQL Server health check" dir=in action=allow protocol=TCP localport=59997
   
   # Open firewall for SQL Server
   netsh advfirewall firewall add rule name="Allow SQL Server" dir=in action=allow protocol=TCP localport=1433
   
   # Open firewall for SQL Server replication
   netsh advfirewall firewall add rule name="Allow SQL Server replication" dir=in action=allow protocol=TCP localport=5022
   
   # Format data disk
   Get-Disk |
    Where partitionstyle -eq 'RAW' |
    Initialize-Disk -PartitionStyle MBR -PassThru |
    New-Partition -AssignDriveLetter -UseMaximumSize |
    Format-Volume -FileSystem NTFS -NewFileSystemLabel 'Data' -Confirm:$false
   
   # Create data and log folders for SQL Server
   md d:\Data
   md d:\Logs
   EOF
   

2. Inicializa las siguientes variables:

   VPC_NAME=VPC_NAME
   SUBNET_NAME=SUBNET_NAME
   REGION=us-east1
   PD_SIZE=200
   MACHINE_TYPE=n2-standard-8
   

   Donde

   • VPC_NAME: Es el nombre de tu VPC.
   • SUBNET_NAME: el nombre de tu subred para la región us-east1.

3. Crea una instancia de SQL Server:

   gcloud compute instances create node-3 \
   --zone $REGION-b \
   --machine-type $MACHINE_TYPE \
   --subnet $SUBNET_NAME \
   --image-family sql-ent-2022-win-2022 \
   --image-project windows-sql-cloud \
   --tags wsfc,wsfc-node \
   --boot-disk-size 50 \
   --boot-disk-type pd-ssd \
   --boot-disk-device-name "node-3" \
   --create-disk=name=node-3-datadisk,size=$PD_SIZE,type=pd-ssd,auto-delete=no \
   --metadata enable-wsfc=true \
   --metadata-from-file=sysprep-specialize-script-ps1=specialize-node.ps1
   

4. Establece una contraseña de Windows para la instancia de SQL Server nueva:

   1. En la consola de Google Cloud, ve a la página de Compute Engine.

      Ir a Compute Engine

   2. En la columna Conectar del clúster de Compute Engine node-3, selecciona la lista desplegable Configurar contraseña de Windows.

   3. Configura el nombre de usuario y la contraseña. Toma nota para usarlos más adelante.

5. Haz clic en RDP para conectarte a la instancia node-3.

6. Ingresa el nombre de usuario y la contraseña del paso anterior y, luego, haz clic en Aceptar.

7. Agrega la instancia al dominio de Windows:

   1. Haz clic derecho en el botón Iniciar (o presiona Windows+X) y, luego, haz clic en Windows PowerShell (Admin).

   2. Para confirmar el símbolo de elevación, haz clic en Sí.

   3. Une la computadora a tu dominio de Active Directory y reiníciala:

      Add-Computer -Domain DOMAIN -Restart
      

      Reemplaza DOMAIN por el nombre de DNS de tu dominio de Active Directory.

      Espera aproximadamente 1 minuto para que se complete el reinicio.

Agrega la instancia secundaria al clúster de conmutación por error

A continuación, agrega la instancia secundaria (node-3) al clúster de conmutación por error de Windows:

1. Conéctate a las instancias node-1 o node-2 a través de RDP y accede como usuario administrador.

2. Abre una ventana de PowerShell como usuario administrador y configura las variables para el entorno del clúster en este instructivo:

   $node3 = "node-3"
   $nameWSFC = "SQLSRV_CLUSTER" # Name of cluster 
   

   Reemplaza SQLSRV_CLUSTER por el nombre del clúster de SQL Server.

3. Agrega la instancia secundaria al clúster:

   Get-Cluster | WHERE Name -EQ $nameWSFC | Add-ClusterNode -NoStorage -Name $node3
   

   A este comando le puede llevar un tiempo ejecutarse. Debido a que el proceso puede dejar de responder y no mostrar una salida automáticamente, presiona Enter con frecuencia.

4. En el nodo, habilita la función de alta disponibilidad de AlwaysOn:

   Enable-SqlAlwaysOn -ServerInstance $node3 -Force
   

El nodo ahora forma parte del clúster de conmutación por error.

Agrega la instancia secundaria al grupo de disponibilidad existente

A continuación, agrega la instancia de SQL Server (la instancia secundaria) y la base de datos al grupo de disponibilidad:

1. Conéctate a node-3 mediante el escritorio remoto. Accede con tu cuenta de usuario de dominio.

2. Abre el Administrador de configuración de SQL Server.

3. En el panel de navegación, selecciona SQL Server Services.

4. En la lista de servicios, haz clic con el botón derecho en SQL Server (MSSQLSERVER) y selecciona Propiedades.

5. En Acceder como, cambia la cuenta:

   • Nombre de la cuenta: DOMAIN\sql_server, en el que DOMAIN es el nombre de NetBIOS de tu dominio de Active Directory.
   • Contraseña: ingresa la contraseña que elegiste antes para la cuenta de dominio sql_server.

6. Haz clic en Aceptar.

7. Cuando se te solicite reiniciar SQL Server, selecciona Sí.

8. En cualquiera de los tres nodos de instancia node-1, node-2 o node-3, abre Microsoft SQL Server Management Studio y conéctate a la instancia principal: node-1.

   1. Ve al Explorador de objetos.
   2. Selecciona la lista desplegable Conectar.
   3. Selecciona Motor de base de datos.
   4. En la lista desplegable Nombre de servidor, selecciona node-1. Si el clúster no aparece en la lista, ingrésalo en el campo.

9. Haz clic en Nueva consulta.

   Nota: Los pasos 9 y 10 no son necesarios si se usó un nombre de red distribuida para configurar el grupo de disponibilidad AlwaysOn.

10. Pega el siguiente comando a fin de agregar una dirección IP al objeto de escucha que se usa para el nodo y, luego, haz clic en Ejecutar:

    ALTER AVAILABILITY GROUP [bookshelf-ag] MODIFY LISTENER 'bookshelf' (ADD IP ('LOAD_BALANCER_IP_ADDRESS', '255.255.255.0'))
    

    Reemplaza LOAD_BALANCER_IP_ADDRESS por la dirección IP del balanceador de cargas en la región us-east1.

11. En el Explorador de objetos, expande el nodo Alta disponibilidad de AlwaysOn y, luego, expande el nodo Grupos de disponibilidad.

12. Haz clic con el botón derecho en el grupo de disponibilidad llamado bookshelf-ag y, luego, selecciona Agregar réplica.

13. En la página Introducción, haz clic en el nodo Alta disponibilidad de AlwaysOn y, luego, en el nodo Grupos de disponibilidad.

14. En la página Conectar con las réplicas, haz clic en Conectar para conectarte a la réplica secundaria existente node-2.

15. En la página Especificar réplicas, haz clic en Agregar réplica y, luego, agrega el nodo nuevo node-3. No selecciones Conmutación por error automática porque esta genera una confirmación síncrona. Esta configuración cruza los límites regionales, por lo que no recomendamos hacerlo.

16. En la página Seleccionar sincronización de datos, selecciona Propagación automática.

    Debido a que no hay un objeto de escucha, la página Validación genera una advertencia que puedes ignorar.

17. Completa los pasos del asistente.

El modo de conmutación por error para node-1 y node-2 es automático, y manual para node-3. Esta diferencia es una forma de distinguir la alta disponibilidad de la recuperación ante desastres.

El grupo de disponibilidad ya está listo. Configuraste dos nodos para alta disponibilidad y un tercer nodo para la recuperación ante desastres.

Simula una recuperación ante desastres

En esta sección, probarás la arquitectura de recuperación ante desastres de este instructivo y considerarás implementaciones opcionales de DR.

Simula una interrupción y ejecuta una conmutación por error de DR

1. Simula una falla o interrupción en la región principal:

   1. En Microsoft SQL Server Management Studio, en node-1, conéctate a node-1.

   2. Crea una tabla. Después de agregar réplicas en pasos posteriores, verifica si la réplica funciona y si esta tabla está presente.

      USE bookshelf
      GO
      CREATE TABLE dbo.TestTable_Before_DR (ID INT NOT NULL)
      GO
      

   3. En Cloud Shell, cierra ambos servidores en la región principal us-central1:

      gcloud compute instances stop node-2 --zone us-central1-b --quiet
      gcloud compute instances stop node-1 --zone us-central1-a --quiet
      

   Nota: Una forma alternativa de crear una falla es detener las VM que ejecutan node-1 y node-2. Este enfoque simula una falla grave en lugar de un cierre común de la instancia.

2. En Microsoft SQL Server Management Studio, en node-3, conéctate a node-3.

3. Ejecuta una conmutación por error y configura el modo de disponibilidad como confirmación síncrona. Es necesario forzar una conmutación por error porque el nodo está en modo de confirmación asíncrona.

   ALTER AVAILABILITY GROUP [bookshelf-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS
   GO
   ALTER AVAILABILITY GROUP [bookshelf-ag]
   MODIFY REPLICA ON 'node-3' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
   GO
   

   Puedes reanudar el procesamiento. node-3 ahora es la instancia principal.

4. Crea una tabla nueva en node-3, (opcional). Después de sincronizar las réplicas con la instancia principal nueva, verifica si esta tabla se replicó en las réplicas.

   USE bookshelf
   GO
   CREATE TABLE dbo.TestTable_After_DR (ID INT NOT NULL)
   GO
   

Aunque en este punto node-3 es la instancia principal, recomendamos usar la región original o configurar una instancia secundaria y una en espera nuevas para volver a crear una arquitectura de DR completa. En la siguiente sección, se analizan estas opciones.

Vuelve a crear una arquitectura de DR que replique por completo las transacciones (opcional)

En este caso de uso, se aborda una falla en la que todas las transacciones se replican de la base de datos principal a la secundaria antes de que la principal falle. En esta situación ideal, no se pierde ningún dato. El estado de la secundaria es coherente con el de la principal en el momento de la falla.

En esta situación, puedes volver a crear una arquitectura de DR completa de las siguientes dos maneras:

• Recurre a la instancia principal y la en espera originales (si están disponibles).
• Crea una instancia en espera y una secundaria nuevas para node-3 en caso de que la instancia principal y la en espera originales no estén disponibles.

Enfoque 1: Vuelve a usar la instancia principal y la en espera originales

1. En Cloud Shell, inicia la principal y la en espera originales (anteriores):

   gcloud compute instances start node-1 --zone us-central1-a --quiet
   gcloud compute instances start node-2 --zone us-central1-b --quiet
   

2. En Microsoft SQL Server Management Studio, agrega node-1 y node-2 como réplicas secundarias:

   1. En node-3, agrega los dos servidores en modo de confirmación asíncrona:

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      

   2. En node-1, comienza a sincronizar las bases de datos otra vez:

      USE [master]
      GO
      ALTER DATABASE [bookshelf] SET HADR RESUME;
      GO
      

   3. En node-2, comienza a sincronizar las bases de datos otra vez:

      USE [master]
      GO
      ALTER DATABASE [bookshelf] SET HADR RESUME;
      GO
      

3. Vuelve a establecer node-1 como la principal:

   1. En node-3, cambia el modo de disponibilidad de node-1 a confirmación síncrona. La instancia node-1 se vuelve a convertir en la instancia principal.

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
      GO
      

   2. En node-1, cambia node-1 para que sea la principal y los otros dos nodos a fin de que sean las secundarias:

      USE [master]
      GO
      -- Node 1 becomes primary
      ALTER AVAILABILITY GROUP [bookshelf-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS;
      GO
      
      -- Node 2 has synchronous commit
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
      GO
      
      -- Node 3 has asynchronous commit
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-3' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      

Después de que todos los comandos se ejecutaron de forma correcta, node-1 es la principal, y los otros nodos son la secundaria, como se muestra en el siguiente diagrama.

Enfoque 2: Configura una instancia principal y una en espera nuevas

Es posible que no puedas recuperar las instancias principal y en espera originales de la falla, que lleve demasiado tiempo, o que no se pueda acceder a la región. Un enfoque es conservar node-3 como la principal y, luego, crear una instancia en espera y una instancia secundaria nuevas, como se muestra en el siguiente diagrama.

Figura 5. Recuperación ante desastres con la región principal original R1 no disponible.

Para esta implementación, se requiere que hagas lo siguiente:

• Conserva node-3 como la instancia principal en us-east1.

• Agrega una instancia en espera nueva (node-4) en una zona diferente en us-east1. En este paso, se establece la implementación nueva como una con alta disponibilidad.

• Crea una instancia secundaria nueva (node-5) en una región independiente, por ejemplo, us-west2. En este paso, se configura la implementación nueva para la recuperación ante desastres. Ya se completó la implementación general. La arquitectura de la base de datos es compatible por completo con la HA y DR.

Ejecuta un resguardo cuando falten transacciones, (opcional)

Una falla no ideal es cuando una o más transacciones confirmadas en la instancia principal no se replican en la secundaria en el momento de la falla (también conocida como falla grave). En una conmutación por error, todas las transacciones confirmadas que no se replican se pierden.

A fin de probar los pasos de conmutación por error para esta situación, debes generar una falla grave. El mejor enfoque para generar una falla grave es el siguiente:

• Cambia la red para que no haya conectividad entre las instancias principales y las secundarias.
• Cambia la principal de alguna manera. Por ejemplo, agrega una tabla o inserta algunos datos.
• Sigue el proceso de conmutación por error como se describió antes para que la secundaria se convierta en la nueva principal.

Los pasos para el proceso de conmutación por error son idénticos a la situación ideal, excepto que la tabla que se agregó a la instancia principal después de que se interrumpió la conectividad de red no se verá en la secundaria.

La única opción para lidiar con una falla grave es quitar las réplicas (node-1 y node-2) del grupo de disponibilidad y volver a sincronizarlas. La sincronización cambia su estado para que coincida con la secundaria. Se perderán todas las transacciones que no se hayan replicado antes de que se produzca la falla.

Si quieres agregar node-1 como una instancia secundaria, puedes seguir los mismos pasos de antes que se usaron para agregar node-3 (consulta Agrega la instancia secundaria al clúster de conmutación por error) con la siguiente diferencia: node-3 ahora es la primaria, no node-1. Debes reemplazar cualquier instancia de node-3 por el nombre del servidor que agregues al grupo de disponibilidad. Si vuelves a usar la misma VM (node-1 y node-2), no es necesario que agregues el servidor al clúster de conmutación por error de Windows Server; solo vuelve a agregar la instancia de SQL Server al grupo de disponibilidad.

En este punto, node-3 es la principal, y node-1 y node-2 son las secundarias. Ahora es posible volver a node-1 para hacer que node-2 sea la instancia en espera y node-3 la secundaria. Ahora, el sistema tiene el mismo estado que tenía antes de la falla.

Conmutación por error automática

Conmuta por error de forma automática a una instancia secundaria, ya que la principal puede crear problemas. Después de que la instancia principal original vuelve a estar disponible, puede ocurrir una situación de cerebro dividido si algunos clientes acceden a la secundaria, mientras que otros escriben en la principal restablecida. En este caso, la principal y la secundaria pueden actualizarse en paralelo, y sus estados difieren. Para evitar esta situación, en este instructivo se proporcionan instrucciones para realizar una conmutación por error manual en la que decides si quieres realizar la conmutación por error (o cuándo hacerlo).

Si implementas una conmutación por error automática, debes asegurarte de que solo una de las instancias configuradas sea la principal y que se pueda modificar. Cualquier instancia en espera o secundaria no debe proporcionar acceso de escritura a ningún cliente (excepto la principal para la replicación de estado). Además, debes evitar que se produzca una cadena rápida de conmutaciones por error en poco tiempo. Por ejemplo, una conmutación por error cada cinco minutos no sería una estrategia de recuperación ante desastres confiable. En el caso de los procesos automatizados de conmutación por error, puedes compilar protecciones contra situaciones problemáticas como estas, y hasta involucrar a un administrador de base de datos para que tome decisiones complejas, si es necesario.

Arquitectura de implementación alternativa

En este instructivo, se configura una arquitectura de recuperación ante desastres con una instancia secundaria que se convierte en la instancia principal en una conmutación por error, como se muestra en el siguiente diagrama.

Figura 6. Arquitectura de recuperación ante desastres estándar con Microsoft SQL Server.

Esto significa que, en el caso de una conmutación por error, la implementación resultante tiene una sola instancia hasta que se pueda hacer un resguardo, o hasta que configures una instancia en espera (para HA) y una secundaria (para DR).

Una arquitectura de implementación alternativa implica configurar dos instancias secundarias. Ambas instancias son réplicas de la instancia principal. Si ocurre una conmutación por error, puedes volver a configurar una de las secundarias como instancia en espera. En los siguientes diagramas, se muestra la arquitectura de implementación antes y después de una conmutación por error.

Figura 7. Arquitectura de recuperación ante desastres estándar con dos instancias secundarias.

Figura 8. Arquitectura de recuperación ante desastres estándar con dos instancias secundarias después de la conmutación por error.

Si bien aún es necesario que una de las dos instancias secundarias sea una en espera (Figura 8), este proceso es mucho más rápido que crear y configurar una en espera nueva desde cero.

También puedes abordar la DR con una configuración análoga a esta arquitectura que usa dos instancias secundarias. Además de tener dos instancias secundarias en una segunda región (Figura 7), puedes implementar otras dos secundarias en una tercera región. Esta configuración te permite crear de manera eficiente una arquitectura de implementación habilitada para HA y DR después de una falla de la región principal.

Limpia

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

Precaución: Borrar un proyecto tiene las siguientes consecuencias:
• Se borra todo en el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
• Se pierden los ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo 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.

¿Qué sigue?

• Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.