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

Last reviewed 2020-08-21 UTC

---

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
• VM de SQL Server

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. En la página del selector de proyectos de la consola de Google Cloud, selecciona o crea un proyecto de Google Cloud.

   Nota: Si no planeas conservar los recursos que creaste durante este procedimiento, crea un proyecto en lugar de seleccionar uno existente. Cuando termines, puedes borrar el proyecto y quitar todos los recursos asociados con él.

   Ir al selector de proyectos

2. Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

3. En la consola de Google Cloud, activa Cloud Shell.

   Activar 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

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

Las versiones 2016, 2017 y 2019 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 usa la imagen sql-ent-2016-win-2016 para Microsoft SQL Server 2016 Enterprise Edition. Si instalas Microsoft SQL Server 2017 Enterprise Edition, usa sql-ent-2017-win-2016. Para Microsoft SQL Server 2019 Enterprise Edition, usa sql-ent-2019-win-2019. 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.

Primero, si sigues los pasos en Configura grupos de disponibilidad AlwaysOn de SQL Server, crearás dos instancias de SQL Server en la misma zona (us-central1-f). Esta configuración no te protege contra un error de us-central1-f. Por lo tanto, para proporcionar compatibilidad con HA, debes implementar una instancia de SQL Server (cluster-sql1) en us-central1-c y una segunda instancia (cluster-sql2) en us-central1-f. En los pasos de la siguiente sección (sobre cómo agregar una instancia secundaria para la recuperación ante desastres), usa esta configuración de implementación.

En segundo lugar, los pasos en Configura grupos de disponibilidad AlwaysOn de SQL Server incluyen la ejecución de esta declaración:

BACKUP DATABASE TestDB to disk = '\\cluster-sql2\SQLBackup\TestDB.bak' WITH INIT

Esta declaración hace que la instancia en espera falle. En su lugar, ejecuta el siguiente comando (el nombre del archivo de copia de seguridad es diferente):

BACKUP DATABASE TestDB to disk = '\\cluster-sql2\SQLBackup\TestDB-backup.bak' WITH INIT

En tercer lugar, mediante los pasos en Configura grupos de disponibilidad AlwaysOn de SQL Server, se crean directorios de copias de seguridad. Usa estas copias de seguridad solo cuando sincronizas la instancia principal y la instancia en espera al inicio, y no después. Un enfoque alternativo para crear directorios de copias de seguridad es seleccionar Propagación automática en estos pasos. Este enfoque simplifica el proceso de configuración.

En cuarto lugar, si las bases de datos no se sincronizan, ejecuta el siguiente comando en cluster-sql2:

ALTER DATABASE [TestDB] SET HADR AVAILABILITY GROUP = [cluster-ag]

Quinto, a los fines de este instructivo, crearás un controlador de dominios en us-central1-f, como se muestra en el siguiente diagrama.

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

Aunque implementes la arquitectura anterior para este instructivo, se recomienda configurar un controlador de dominios 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ó.

Agrega una instancia secundaria para la recuperación ante desastres

A continuación, configura una tercera instancia de SQL Server (una instancia secundaria llamada cluster-sql3), junto con las herramientas de redes:

1. En Cloud Shell, en la misma nube privada virtual (VPC) que usaste para la región principal, crea una subred en la región secundaria (us-east1):

   gcloud compute networks subnets create wsfcsubnet4 --network wsfcnet \
       --region us-east1 --range 10.3.0.0/24
   

2. Modifica la regla de firewall llamada allow-internal-ports para permitir que la subred nueva reciba tráfico:

   gcloud compute firewall-rules update allow-internal-ports \
       --source-ranges 10.0.0.0/24,10.1.0.0/24,10.2.0.0/24,10.3.0.0/24
   

   La regla allow-internal-ports se incluye en los pasos de las instrucciones que seguiste antes.

3. Crea una instancia de SQL Server:

   gcloud compute instances create cluster-sql3 --machine-type n1-highmem-4 \
       --boot-disk-type pd-ssd --boot-disk-size 200GB \
       --image-project windows-sql-cloud --image-family sql-ent-2016-win-2016 \
       --zone us-east1-b \
       --network-interface "subnet=wsfcsubnet4,private-network-ip=10.3.0.4,aliases=10.3.0.5;10.3.0.6" \
       --can-ip-forward --metadata sysprep-specialize-script-ps1="Install-WindowsFeature Failover-Clustering -IncludeManagementTools;"
   

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 cluster-sql3, 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 cluster-sql3.

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

7. Abre una ventana de Windows PowerShell como administrador y, a continuación, configura el DNS y los puertos abiertos:

   netsh interface ip set dns Ethernet static 10.2.0.100
   
   netsh advfirewall firewall add rule name="Open Port 5022 for Availability Groups" dir=in action=allow protocol=TCP localport=5022
   
   netsh advfirewall firewall add rule name="Open Port 1433 for SQL Server" dir=in action=allow protocol=TCP localport=1433
   

8. Agrega la instancia al dominio de Windows:

   Add-Computer -DomainName "dbeng.com" -Credential "dbeng.com\Administrator" -Restart -Force
   

   Mediante este comando, se finaliza la conexión RDP.

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

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

1. Conéctate a las instancias cluster-sql1 o cluster-sql2 mediante RDP y accede como administrador.

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

   $node3 = "cluster-sql3"
   $nameWSFC = "cluster-dbclus" # Name of cluster
   

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
   

5. Crea dos carpetas en C:\SQLData y C:\SQLLog para almacenar los datos de la base de datos y los archivos de registro:

   New-item -ItemType Directory "C:\SQLData"
   
   New-item -ItemType Directory "C:\SQLLog"
   

El nodo ahora está unido al 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. En cualquiera de los tres nodos de instancia (cluster-sql1, cluster-sql2 o cluster-sql3), abre Microsoft SQL Server Management Studio y conéctate a la instancia principal (cluster-sql1):

   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 cluster-sql1. Si el clúster no aparece en la lista, ingrésalo en el campo.

2. Haz clic en Nueva consulta.

3. 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 [cluster-ag] MODIFY LISTENER 'cluster-listene' (ADD IP ('10.3.0.6', '255.255.255.0'))
   

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

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

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

7. En la página Conectar con las réplicas, haz clic en Conectar para conectarte a la réplica secundaria existente cluster-sql2.

8. En la página Especificar réplicas, haz clic en Agregar réplica y, luego, agrega el nodo nuevo cluster-sql3. 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.

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

10. Completa los pasos del asistente.

El modo de conmutación por error para cluster-sql1 y cluster-sql2 es automático, y manual para cluster-sql3. 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 (interrupción) en la región principal:

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

   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 TestDB
      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 cluster-sql2 --zone us-central1-f --quiet
      gcloud compute instances stop cluster-sql1 --zone us-central1-c --quiet
      

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

2. En Microsoft SQL Server Management Studio, en cluster-sql3, conéctate a cluster-sql3.

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 [cluster-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS
   GO
   ALTER AVAILABILITY GROUP [cluster-ag]
   MODIFY REPLICA ON 'CLUSTER-SQL3' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
   GO
   

   Puedes reanudar el procesamiento. cluster-sql3 ahora es la instancia principal.

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

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

Aunque en este punto cluster-sql3 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 cluster-sql3 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 cluster-sql1 --zone us-central1-c --quiet
   gcloud compute instances start cluster-sql2 --zone us-central1-f --quiet
   

2. En Microsoft SQL Server Management Studio, agrega cluster-sql1 y cluster-sql2 como réplicas secundarias:

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

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [cluster-ag]
      MODIFY REPLICA ON 'CLUSTER-SQL1' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [cluster-ag]
      MODIFY REPLICA ON 'CLUSTER-SQL1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      ALTER AVAILABILITY GROUP [cluster-ag]
      MODIFY REPLICA ON 'CLUSTER-SQL2' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [cluster-ag]
      MODIFY REPLICA ON 'CLUSTER-SQL2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      

   2. En cluster-sql1, comienza a sincronizar las bases de datos otra vez:

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

   3. En cluster-sql2, comienza a sincronizar las bases de datos otra vez:

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

3. Vuelve a establecer cluster-sql1 como la principal:

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

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [cluster-ag]
      MODIFY REPLICA ON 'CLUSTER-SQL1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
      GO
      

   2. En cluster-sql1, cambia cluster-sql1 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 [cluster-ag] FAILOVER;
      GO
      
      -- Node 2 has synchronous commit
      ALTER AVAILABILITY GROUP [cluster-ag]
      MODIFY REPLICA ON 'CLUSTER-SQL2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
      GO
      
      -- Node 3 has asynchronous commit
      ALTER AVAILABILITY GROUP [cluster-ag]
      MODIFY REPLICA ON 'CLUSTER-SQL3' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      

Después de que todos los comandos se ejecutaron de forma correcta, cluster-sql1 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 cluster-sql3 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 cluster-sql3 como la instancia principal en us-east1.

• Agrega una instancia en espera nueva (cluster-sql4) 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 (cluster-sql5) 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 (cluster-sql1 y cluster-sql2) 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 cluster-sql1 como una instancia secundaria, puedes seguir los mismos pasos de antes que se usaron para agregar cluster-sql3 (consulta Agrega la instancia secundaria al clúster de conmutación por error) con la siguiente diferencia: cluster-sql3 ahora es la primaria, no cluster-sql1. Debes reemplazar cualquier instancia de cluster-sql3 por el nombre del servidor que agregues al grupo de disponibilidad. Si vuelves a usar la misma VM (cluster-sql1 y cluster-sql2), 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, cluster-sql3 es la principal, y cluster-sql1 y cluster-sql2 son las secundarias. Ahora es posible volver a cluster-sql1 para hacer que cluster-sql2 sea la instancia en espera y cluster-sql3 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. A fin de 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 estas 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. En la consola de Google Cloud, ve a la página Administrar recursos.

   Ir a Administrar recursos

2. En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
3. En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

¿Qué sigue?

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