Migra Microsoft SQL Server de AWS a Google Cloud

Last reviewed 2023-05-05 UTC

En este documento, se muestra cómo migrar una instancia de Microsoft SQL Server instalada en Amazon Elastic Compute Cloud (Amazon EC2) a una instancia de Microsoft SQL Server sobre Compute Engine, en Google Cloud. Esta migración se basa solo en la tecnología de base de datos integrada que proporciona Microsoft SQL Server. En efecto, este método es un método sin tiempo de inactividad que usa un grupo de disponibilidad Siempre activado. El grupo de disponibilidad Siempre activado abarca AWS y Google Cloud a través de una VPN, y permite la replicación de la base de datos de Microsoft SQL Server. En este documento, se supone que estás familiarizado con la configuración de la red, Google Cloud, Compute Engine, AWS y Microsoft SQL Server.

Si deseas realizar solo la replicación, puedes seguir los pasos de este instructivo, pero puedes detenerte después de agregar datos de prueba y omitir los pasos de migración de sistemas.

Objetivos

  • Implementa un grupo de disponibilidad Siempre activado de Microsoft SQL Server en múltiples nubes que abarque un Microsoft SQL Server en Amazon EC2 y un Microsoft SQL Server en Google Cloud sobre Compute Engine.
  • Configura una instancia principal de Microsoft SQL en Amazon EC2.
  • Configura la instancia de Microsoft SQL Server en Google Cloud como secundaria del Microsoft SQL Server principal en AWS (destino de la replicación de datos).
  • Para completar la migración de datos, establece el Microsoft SQL Server secundario en Google Cloud como Microsoft SQL Server principal en Google Cloud.

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. Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

Este instructivo también requiere de recursos en AWS que podrían generar costos.

Antes de comenzar

  1. En la página del selector de proyectos de la consola de Google Cloud, selecciona o crea un proyecto de Google Cloud.

    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 migración de bases de datos

La migración de la base de datos transfiere los datos de una base de datos de origen a una de destino. En general, puedes migrar un subconjunto de datos o tener un esquema diferente en la base de datos de origen y de destino. Sin embargo, en este instructivo se aborda la migración de bases de datos homogénea que requiere la migración de la base de datos completa sin cambios. La base de datos de destino es una copia de la base de datos de origen.

Migración de base de datos con tiempo de inactividad cero

El término tiempo de inactividad cero se refiere al hecho de que, durante la migración, los clientes que acceden a la base de datos de origen permanecen completamente operativos y no se interrumpen. El único tiempo de inactividad se produce cuando los clientes tienen que volver a conectarse a la base de datos de destino después de que se completa la migración. Aunque este método no es realmente con tiempo de inactividad cero, el término se refiere a este caso de tiempo de inactividad mínimo.

Para obtener un análisis general de la migración de bases de datos, consulta Migración de bases de datos: Conceptos y principios (parte 1) y Migración de bases de datos: Conceptos y principios (parte 2). En estos artículos, se proporciona una descripción general de la posible complejidad de la migración de bases de datos en diferentes situaciones.

Migración de bases de datos mediante la tecnología de Microsoft SQL Server

Algunas tecnologías de migración de bases de datos proporcionan componentes y servicios independientes. Cuando la migración de una base de datos requiere una copia de la base de datos de origen, puedes usar la tecnología integrada de Microsoft SQL Server.

En este instructivo, se usa la tecnología de grupo de disponibilidad Always On de Microsoft SQL Server para conectar la base de datos de origen (principal) a una de destino (secundaria). Esta tecnología proporciona replicación asíncrona desde la base de datos principal hasta la secundaria. Debido a que la base de datos principal se encuentra en Amazon EC2 y la secundaria se encuentra en Google Cloud en Compute Engine, la replicación realiza la migración de la base de datos. Después de que todos los datos se migren a través de la replicación asíncrona, la base de datos secundaria asciende a principal y los clientes pueden volver a conectarse a la nueva principal para el procesamiento continuo.

Este enfoque admite pruebas explícitas mediante una replicación de prueba en una base de datos de destino de prueba: puedes iniciar la replicación, mantenerla en ejecución durante un tiempo y, luego, detenerla. La base de datos de destino de prueba se encuentra en un estado coherente, y puedes usarla para probar la aplicación. Una vez que se complete la prueba, podrás borrar la base de datos de destino de prueba y, luego, iniciar la replicación de una base de datos activa.

Arquitectura de migración de base de datos en múltiples nubes

En el siguiente diagrama, se muestra la arquitectura general de implementación para la migración de una base de datos de múltiples nubes:

Un grupo de disponibilidad Siempre activado conecta una base de datos de AWS a una base de datos de Google Cloud.

En el diagrama anterior, se muestra la base de datos de SQL Server de origen (principal) en AWS como una instancia de Amazon EC2. En el diagrama, también se muestra la base de datos de destino (secundaria) en Google Cloud. Las bases de datos están conectadas por un grupo de disponibilidad Siempre activado. Se supone que la conexión de red entre AWS y Google Cloud es una conexión de VPN con alta disponibilidad segura.

Configura un grupo de disponibilidad de Microsoft SQL Server de múltiples nubes

En las siguientes secciones, configurarás un grupo de disponibilidad Siempre activado de dos nodos en el que reside el nodo principal. El nodo secundario reside en Google Cloud. Esta configuración se describió antes en este documento en Arquitectura de migración de bases de datos de múltiples nubes.

En las siguientes tablas, se proporciona un resumen de los nodos y las direcciones IP que configuraste en este instructivo. Para cada VM de base de datos, se asignan dos direcciones IP además de la dirección IP principal: una para el clúster de conmutación por error de Windows Server (WSFC) y otra para el objeto de escucha del grupo de disponibilidad.

Proveedor Instancia IP principal IP de WSFC y del objeto de escucha del grupo de disponibilidad WSFC Grupo de disponibilidad
AWS cluster-sql1 192.168.1.4 192.168.1.5
192.168.1.6 		Name: cluster-dbclus Name: cluster-ag
Listener: ag-listener
Google Cloud cluster-sql2 10.1.1.4 10.1.1.5
10.1.1.6
Proveedor Instancia IP principal —
AWS dc-windows 192.168.1.100 Domain controller

En las instrucciones, se usan estos nombres y direcciones IP como ejemplos. Si deseas usar tus propios nombres y direcciones IP, reemplaza los valores de ejemplo de las instrucciones.

Requisitos previos para AWS

En AWS, deberías tener dos máquinas virtuales: una que ejecute el controlador de dominio y otra que ejecute un SQL Server. El controlador de dominio que se usa como ejemplo en este instructivo tiene la siguiente configuración:

Domain                    : dbeng.com
Domain controller         : Name: dc-windows
                            Private IP: 192.168.1.100
VPC Subnet                : 192.168.1.0/24
SQL Server service account: dbeng\sql_service

La VM de SQL Server que se usa como ejemplo en este instructivo es parte de un dominio de Windows Active Directory en Amazon EC2. El servidor tiene dos direcciones IP secundarias para que las usen el WSFC y el objeto de escucha del grupo de disponibilidad. La VM de SQL Server tiene la siguiente configuración:

VM Instance : Name: cluster-sql1
              Private IP: 192.168.1.4
              Secondary Private IPs: 192.168.1.5, 192.168.1.6
VPC Subnet  : 192.168.1.0/24

Puedes usar la cuenta de servicio NT SERVICE\MSSQLSERVER como la cuenta de servicio de SQL Server. Durante la configuración del grupo de disponibilidad Always On, debes otorgar acceso a las cuentas de máquina (dbeng\cluster-sql1$, dbeng\cluster-sql2$) en lugar de la cuenta de dominio. En la siguiente sección, se proporcionan los comandos para configurar el grupo de disponibilidad.

Requisitos previos para la conectividad entre AWS y Google Cloud

Para conectar tu proyecto de AWS con tu proyecto de Google Cloud, configura la siguiente conectividad de red:

  1. Configura una nube privada virtual de Google y una VPC de AWS en los proyectos respectivos, y configura una VPN entre las VPC. Para obtener información sobre cómo configurar una VPN entre Google Cloud y AWS, consulta VPN de múltiples nubes y subredes de varias zonas: configuración de red para implementaciones de bases de datos de múltiples nubes.

  2. En Cloud Shell, crea una subred en el proyecto de Google Cloud en el que crearás la instancia de SQL Server. Si ya tienes una subred, puedes usarla, pero asegúrate de configurar las reglas de firewall en el siguiente paso.

    gcloud compute networks create demo-vpc --subnet-mode custom

gcloud compute networks subnets create demo-subnet1 \
  --network demo-vpc --region us-east4 --range 10.1.1.0/24

    En este instructivo, se usan los siguientes valores:

    • VPC: demo-vpc
    • Subred: demo-subnet1; 10.1.1.0/24

    La subred aparece en la página Redes de VPC de la consola de Google Cloud.

  3. En el proyecto de Google Cloud, crea una regla de firewall para abrir todo el tráfico entre la subred de Google Cloud y la subred de AWS:

    gcloud compute firewall-rules create allow-vpn-ports \
  --network demo-vpc --allow tcp:1-65535,udp:1-65535,icmp \
  --source-ranges 10.1.1.0/24,192.168.1.0/24

    La regla de firewall aparece en la página de políticas Firewall de la consola de Google Cloud.

  4. En tu proyecto de AWS, crea una regla de firewall en el grupo de seguridad para abrir todo el tráfico entre tu subred de Google Cloud y tu subred de AWS, como se muestra en la siguiente captura de pantalla:

    Las reglas de entrada de AWS se configuran para permitir todo el tráfico, todos los protocolos y todos los rangos de puertos.

    En un entorno de producción, recomendamos que abras solo los puertos TCP/UDP necesarios. Abrir solo los puertos requeridos limita el tráfico potencialmente dañino y sigue el principio menos necesario.

Crea una instancia en Google Cloud para el grupo de disponibilidad Siempre activado

Este instructivo funciona con las siguientes ediciones y funciones de Microsoft SQL Server:

  • Edición:
    • Microsoft SQL Server 2016 Enterprise Edition
    • Microsoft SQL Server 2017 Enterprise Edition
    • Microsoft SQL Server 2019 Enterprise Edition
    • Microsoft SQL Server 2022 Enterprise Edition, o
    • Microsoft SQL Server 2016 Standard Edition
    • Microsoft SQL Server 2017 Standard Edition
    • Microsoft SQL Server 2019 Standard Edition, o
    • Microsoft SQL Server 2022 Standard Edition
  • Función: Grupos de disponibilidad Siempre activado

En las siguientes instrucciones, se usa la imagen de Microsoft SQL Server 2019 Enterprise Edition: sql-ent-2019-win-2019. Si deseas instalar Microsoft SQL Server 2017, 2016 o 2022 Enterprise Editions, usa sql-ent-2017-win-2019 ,sql-ent-2016-win-2019, respectivamente sql-ent-2022-win-2019, en su lugar. Para obtener una lista de todas las imágenes, consulta la página Detalles del sistema operativo de Compute Engine.

En los siguientes pasos, crearás una instancia de SQL Server en Google Cloud para el grupo de disponibilidad. La instancia usa la siguiente configuración de dirección IP con alias de direcciones IP:

VM Instance: Name: cluster-sql2
             Private IP: 10.1.1.4
             Secondary Private IPs: 10.1.1.5, 10.1.1.6

Creas una instancia llamada cluster-sql2 a partir de imágenes públicas de SQL Server, con un tamaño de disco de arranque de 200 GB y un tipo de máquina n1-highmem-4. Por lo general, las instancias de SQL Server requieren más recursos de procesamiento que la instancia del controlador de dominio. Si necesitas recursos de procesamiento adicionales más adelante, puedes cambiar el tipo de máquina para estas instancias. Si necesitas espacio de almacenamiento adicional, agrega un disco o cambia el tamaño del disco de arranque persistente. En grupos de disponibilidad más grandes, puedes crear varias instancias.

En los siguientes pasos, también se incluye la marca --metadata sysprep-specialize-script-ps1 que ejecuta un comando de Microsoft PowerShell durante la creación de la instancia para instalar la función de clúster de conmutación por error.

  1. En Cloud Shell, crea una instancia de SQL Server en Google Cloud que use la misma versión del sistema operativo que en AWS:

    gcloud compute instances create cluster-sql2 --machine-type n1-highmem-4 \
  --boot-disk-type pd-ssd --boot-disk-size 200GB \
  --image-project windows-sql-cloud --image-family sql-ent-2019-win-2019 \
  --zone us-east4-a \
  --network-interface "subnet=demo-subnet1,private-network-ip=10.1.1.4,aliases=10.1.1.5;10.1.1.6" \
  --can-ip-forward \
  --metadata sysprep-specialize-script-ps1="Install-WindowsFeature Failover-Clustering -IncludeManagementTools;"

  2. Configura un nombre de usuario y una contraseña de Windows antes de conectarte a la instancia.

  3. Cuando uses el protocolo de escritorio remoto (RDP) desde tu laptop, crea una regla de firewall que permita el acceso a la instancia.

  4. Conéctate a la instancia de Google Cloud mediante RDP y abre un PowerShell con privilegios elevados (se ejecuta como administrador).

  5. En este instructivo, configurarás un DNS local para usar el controlador de dominio en AWS (192.168.1.100) a fin de evitar crear otra VM en Google Cloud. En las cargas de trabajo de producción, recomendamos que uses un controlador de dominio (principal o secundario) en Google Cloud para evitar la autenticación a través del túnel VPN.

    En el PowerShell elevado, deberías poder hacer ping al controlador de dominio 192.168.1.100:

    ping 192.168.1.100

    Si el ping falla, asegúrate de que el firewall y el túnel VPN estén configurados correctamente entre AWS y Google Cloud, como se describió antes en los Requisitos previos para la conectividad.

  6. Debido a que el servidor se configuró originalmente con DHCP, cambia la instancia para usar direcciones IP estáticas:

    netsh interface ip set address name=Ethernet static 10.1.1.4 255.255.255.0 10.1.1.1 1

    Después de ejecutar el comando anterior, perderás la conexión. Vuelve a conectarte en RDP.

  7. Configura el DNS local para usar el controlador de dominio en AWS y abre los puertos de firewall locales para SQL Server. Cuando abres los puertos de firewall, permites que SQL Server se conecte a SQL Server remotos.

    netsh interface ip set dns Ethernet static 192.168.1.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

    El comando te solicitará las credenciales de administrador de dominio. Cuando el comando termina de ejecutarse, la instancia se reinicia.

    Si el comando no se ejecuta, asegúrate de que lo estás ejecutando como administrador.

  9. Usa la cuenta dbeng\Administrator para volver a conectarte a tu instancia mediante RDP.

  10. Configura la cuenta de servicio de SQL Server:

    1. Abre el Administrador de configuración de SQL Server 2019.
    2. En la pestaña SQL Server Services, haz clic derecho en SQL Server (MSSQLSERVER) y, luego, en Propiedades.
    3. Configura la cuenta y la contraseña para dbeng\sql_service.
    4. Reinicia SQL Server.

  11. Cambia el nombre de la instancia de SQL Server para que coincida con el nombre de la computadora y reinicia SQL Server:

    Invoke-Sqlcmd -Query "EXEC sp_dropserver @@SERVERNAME, @droplogins='droplogins'"

Invoke-Sqlcmd -Query "EXEC sp_addserver '$env:COMPUTERNAME', local"

Stop-Service -Name "MSSQLServer" -Force

Start-Service -Name "MSSQLServer"

A continuación, configura la instancia en AWS.

Configura la instancia en AWS

En este instructivo, se supone que ya configuraste lo siguiente en AWS:

  • La instancia de SQL Server forma parte del dominio de Active Directory.
  • El DNS local funciona de forma correcta y el nombre del servidor remoto en Google Cloud (cluster-sql2.dbeng.com) se puede traducir a una dirección IP)
  • Las reglas de firewall se abren entre las subredes en AWS y Google Cloud.

Para configurar cluster-sql1 en AWS, haz lo siguiente:

  1. Conéctate a la instancia mediante RDP. (cluster-sql1)
  2. Abre un PowerShell con privilegios elevados (se ejecuta como administrador).

  3. Instala el clúster de conmutación por error de Windows si aún no está instalado.

    Install-WindowsFeature Failover-Clustering -IncludeManagementTools

    Este comando requiere realizar un reinicio si la función no estaba instalada. Después del reinicio, continúa con el siguiente paso.

  4. Abre los puertos de firewall locales para la instancia de SQL Server en AWS:

    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

netsh advfirewall firewall add rule name="ICMP Allow incoming V4 echo request" protocol="icmpv4:8,any" dir=in action=allow

  5. Cambia el nombre de la instancia de SQL Server para que coincida con el nombre de la computadora y reinicia SQL Server:

    Invoke-Sqlcmd -Query "EXEC sp_dropserver @@SERVERNAME, @droplogins='droplogins'"

Invoke-Sqlcmd -Query "EXEC sp_addserver '$env:COMPUTERNAME', local"

Stop-Service -Name "MSSQLServer" -Force

Start-Service -Name "MSSQLServer"

  6. Valida que la instancia en AWS se pueda conectar a la instancia en Google Cloud cuando se usa el nombre de la instancia remota. Para probar la conexión, ejecuta los siguientes comandos desde una cuenta de dominio que tenga acceso de conexión a SQL Server.

    1. Prueba la conexión de red:

      ping -4 cluster-sql2.dbeng.com

      El resultado luce de la siguiente manera:

      RESULTS:
Pinging cluster-sql2.dbeng.com [10.1.1.4] with 32 bytes of data:
Reply from 10.1.1.4: bytes=32 time=3ms TTL=127
Reply from 10.1.1.4: bytes=32 time=2ms TTL=127
Reply from 10.1.1.4: bytes=32 time=2ms TTL=127
Reply from 10.1.1.4: bytes=32 time=2ms TTL=127

    2. Prueba la autenticación de Windows en el servidor remoto:

      sqlcmd -E -S cluster-sql2.dbeng.com -Q "SELECT 'CONNECTED'"

      El resultado luce de la siguiente manera:

      RESULTS:
--------------------------------------------------------------------------
CONNECTED

(1 rows affected)

    Si no puedes conectarte, asegúrate de que el DNS funcione de forma correcta y que las reglas de firewall estén abiertas entre las subredes de AWS y Google Cloud.

Verifica que la instancia de Google Cloud esté lista para unirse al grupo de disponibilidad

  1. Usa la cuenta dbeng\Administrator para conectarte a la instancia de Google Cloud mediante RDP (cluster-sql2).
  2. Abre un PowerShell con privilegios elevados (se ejecuta como administrador).

  3. Valida que la instancia en Google Cloud pueda conectarse a la instancia en AWS cuando se usa el nombre de la instancia. Para probar la conexión, ejecuta los siguientes comandos desde una cuenta de dominio que tenga acceso de conexión a SQL Server.

    1. Prueba la conexión de red:

      ping -4 cluster-sql1.dbeng.com

      El resultado luce de la siguiente manera:

      RESULTS:
Pinging CLUSTER-SQL1.dbeng.com [192.168.1.4] with 32 bytes of data:
Reply from 192.168.1.4: bytes=32 time=3ms TTL=127
Reply from 192.168.1.4: bytes=32 time=2ms TTL=127
Reply from 192.168.1.4: bytes=32 time=3ms TTL=127
Reply from 192.168.1.4: bytes=32 time=2ms TTL=127

    2. Prueba la autenticación de Windows en el servidor remoto:

      sqlcmd -E -S cluster-sql1 -Q "SELECT 'CONNECTED'"

      El resultado luce de la siguiente manera:

      RESULTS:
------------------------------------------------------------
CONNECTED

(1 rows affected)

      Si no puedes conectarte, asegúrate de que el DNS funcione de forma correcta y que las reglas de firewall estén abiertas entre las subredes de AWS y Google Cloud.

  4. Crea carpetas en C:\SQLData y C:\SQLLog. Los datos y los archivos de registro de la base de datos usan estas carpetas.

    New-Item "C:\SQLData" –type directory
New-Item "C:\SQLLog" –type directory

  5. Crea una carpeta en C:\SQLBackup y un recurso compartido de Windows en \\cluster-sql2\SQLBackup para transferir la copia de seguridad desde la instancia de AWS. Puedes utilizar cualquier otro recurso compartido de red que esté disponible para ambos servidores.

    New-Item "C:\SQLBackup" –type directory
New-SmbShare -Name "SQLBackup" -Path "C:\SQLBackup" -FullAccess
"dbeng.com\cluster-sql1$","dbeng.com\cluster-sql2$","NT
SERVICE\MSSQLSERVER","authenticated users","dbeng.com\sql_service"

Las instancias ahora están listas para el grupo de disponibilidad. Debido a que solo tienes dos instancias, en la siguiente sección, configurarás un testigo de archivos compartidos para proporcionar un voto de desempate y lograr un quórum.

Crea un testigo de archivos compartidos

A fin de proporcionar un voto de desempate y lograr un quórum para la situación de conmutación por error, crea un recurso de archivos compartidos que actuará como testigo. Para los fines de este instructivo, creas el testigo de archivos compartidos en la VM del controlador de dominio. En un entorno de producción, deberías crear el testigo de archivos compartidos en cualquier servidor dentro de tu dominio de Active Directory.

  1. Usa la cuenta dbeng\Administrator para conectarte a la VM del controlador de dominio, dc-windows, mediante RDP.
  2. Abre un PowerShell con privilegios elevados (se ejecuta como administrador).

  3. Crea la carpeta del testigo.

    New-Item "C:\QWitness" –type directory

  4. Comparte la carpeta.

    New-SmbShare -Name "QWitness" -Path "C:\QWitness" -Description "SQL File Share Witness" -FullAccess "dbeng.com\Administrator", "dbeng.com\cluster-sql1$", "dbeng.com\cluster-sql2$"

  5. Usa dbeng.com\Administrator para conectarte a cluster-sql1 y cluster-sql2 mediante RDP.

  6. Verifica que puedas acceder al directorio compartido desde ambos servidores:

    dir \\dc-windows\QWitness

    Si no puedes acceder al directorio compartido, intenta cambiar la conexión de red en el nodo para establecer que el servidor WINS coincida con el servidor de dominio. El cambio de conexión de red puede tardar unos segundos. En la siguiente captura de pantalla, se muestra la configuración de WINS actualizada:

    Se actualizó la configuración de la dirección WINS en la configuración avanzada de TCP/IP.

Todo está listo para el grupo de disponibilidad. A continuación, configura el clústerde conmutación por error.

Configura clústeres de conmutación por error

En esta sección, configurarás el WSFC y habilitarás la alta disponibilidad de Always On para ambas instancias. Ejecuta todos los siguientes comandos de configuración desde la instancia en AWS.

  1. Conéctate a la instancia de AWS (cluster-sql1) mediante RDP.
  2. Abre un PowerShell con privilegios elevados (se ejecuta como administrador).

  3. Configura las variables que reflejen el entorno del clúster. En este ejemplo, configura las siguientes variables:

    $node1 = "cluster-sql1.dbeng.com"
$node2 = "cluster-sql2.dbeng.com"
$nameWSFC = "cluster-dbclus" #Name of cluster
$ipWSFC1 = "192.168.1.5" #IP address of cluster in subnet 1 (AWS)
$ipWSFC2 = "10.1.1.5"    #IP address of cluster in subnet 2 (Google Cloud)

  4. Crea el clúster de conmutación por error (este comando puede tardar un tiempo en ejecutarse):

    New-Cluster -Name $nameWSFC -Node $node1, $node2 -NoStorage -StaticAddress $ipWSFC1, $ipWSFC2

Set-ClusterQuorum -FileShareWitness \\dc-windows\QWitness

  5. Habilita la opción de alta disponibilidad Siempre activado en el nodo 1. Si no habilitaste Siempre activado anteriormente, estos comandos forzarán el reinicio de SQL Server.

    Enable-SqlAlwaysOn -ServerInstance $node1 -Force

  6. Habilita la opción de alta disponibilidad Siempre activado en el nodo 2. Estos comandos detienen el servicio de SQL Server antes de habilitar SQL Siempre activado, por lo que puedes ignorar el error que dice: Enable-SqlAlwaysOn : StopService failed for Service 'MSSQLSERVER'.

    Get-Service -ComputerName $node2 -Name "MSSQLServer" | Stop-Service -Force

Enable-SqlAlwaysOn -ServerInstance $node2 -Force

Get-Service -ComputerName $node2 -Name "MSSQLServer" | Start-Service

  7. Crea carpetas en C:\SQLData y C:\SQLLog. Usa estas carpetas para los datos y los archivos de registro de la base de datos TestDB. Si el servidor ya tiene una base de datos con esta estructura de carpetas, puedes omitir este paso. Si no estás seguro, ejecuta los comandos y, también, ignora los mensajes de error sobre carpetas preexistentes.

    New-Item "C:\SQLData" –type directory
New-Item "C:\SQLLog" –type directory

El Administrador de clúster de conmutación por error está listo. A continuación, crea el grupo de disponibilidad.

Crea el grupo de disponibilidad

En esta sección, crearás una base de datos de prueba en AWS (cluster-sql1) y la configurarás para que funcione con un grupo de disponibilidad nuevo. Como alternativa, puedes especificar una base de datos existente para el grupo de disponibilidad.

  1. Conéctate a la instancia de AWS (cluster-sql1) mediante RDP.
  2. Abre un PowerShell con privilegios elevados (se ejecuta como administrador).

  3. Crea una carpeta en C:\SQLBackup para almacenar una copia de seguridad de la base de datos. La copia de seguridad se requiere antes de que puedas configurar el grupo de disponibilidad en una base de datos nueva.

    New-Item "C:\SQLBackup" –type directory

  4. Si aún no tienes una base de datos configurada, ejecuta SQL Server Management Studio y crea una base de datos de prueba en la instancia de AWS (cluster-sql1):

    CREATE DATABASE TestDB
ON PRIMARY (NAME = 'TestDB_Data', FILENAME='C:\SQLData\TestDB_Data.mdf', SIZE = 256MB, MAXSIZE = UNLIMITED, FILEGROWTH = 256MB )
LOG ON (NAME = 'TestDB_Log', FILENAME='C:\SQLLog\TestDB_Log.ldf', SIZE = 256MB, MAXSIZE = UNLIMITED, FILEGROWTH = 256MB )
GO

USE [TestDB]
Exec dbo.sp_changedbowner @loginame = 'sa', @map = false;
ALTER DATABASE [TestDB] SET RECOVERY FULL;
GO

BACKUP DATABASE TestDB to disk = 'C:\SQLBackup\TestDB-backup.bak' WITH INIT
GO

  5. En Microsoft SQL Server Management Studio, selecciona Consulta > Modo de SQLCMD.

    SQL Server Management Studio proporciona un asistente para crear los grupos de disponibilidad. En este instructivo, usarás comandos de SQL en su lugar para que sea más fácil depurar problemas que puedas encontrar cuando te conectes entre diferentes proveedores de servicios en la nube. Si lo prefieres, puedes ejecutar el asistente de grupos de disponibilidad y pasar al paso posterior para verificar que el grupo de disponibilidad se esté sincronizando.

  6. Ejecuta las siguientes consultas en el modo SQLCMD. Si usas una base de datos preexistente, reemplaza TestDB por el nombre de tu base de datos.

    1. Crea un extremo en el primer nodo y otórgale permisos:

      :Connect CLUSTER-SQL1
IF NOT EXISTS (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint')
BEGIN
  CREATE ENDPOINT [Hadr_endpoint]
  AS TCP (LISTENER_PORT = 5022)
  FOR DATA_MIRRORING (ROLE = WITNESS, ENCRYPTION = REQUIRED ALGORITHM AES)
END
GO

IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') <> 0
BEGIN
  ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED
END
GO

use [master]
GO

IF SUSER_ID('DBENG\sql_service') IS NULL
  CREATE LOGIN [DBENG\sql_service] FROM WINDOWS
GO

GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DBENG\sql_service]
GO

    2. Habilita la sesión de evento extendida AlwaysOn_health en el primer nodo. Los grupos de disponibilidad requieren la sesión de evento extendida.

      :Connect CLUSTER-SQL1
IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AlwaysOn_health')
BEGIN
  ALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON);
END
IF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name='AlwaysOn_health')
BEGIN
  ALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START;
END
GO

    3. Crea un extremo en el segundo nodo y otórgale permisos:

      :Connect CLUSTER-SQL2
IF NOT EXISTS (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint')
BEGIN
  CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_PORT = 5022)
    FOR DATA_MIRRORING (ROLE = WITNESS, ENCRYPTION = REQUIRED ALGORITHM AES)
END
GO

IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') <> 0
BEGIN
  ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED
END
GO

use [master]
GO

IF SUSER_ID('DBENG\sql_service') IS NULL
  CREATE LOGIN [DBENG\sql_service] FROM WINDOWS
GO

GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DBENG\sql_service]
GO

    4. Habilita la sesión de evento extendida AlwaysOn_health en el segundo nodo. Los grupos de disponibilidad requieren la sesión de evento extendida.

      :Connect CLUSTER-SQL2
IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AlwaysOn_health')
BEGIN
  ALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON);
END
IF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name='AlwaysOn_health')
BEGIN
  ALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START;
END
GO

    5. Crea el grupo de disponibilidad en el primer nodo:

      :Connect CLUSTER-SQL1
USE [master]
GO

--DROP AVAILABILITY GROUP [cluster-ag];
GO

CREATE AVAILABILITY GROUP [cluster-ag]
WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY,
DB_FAILOVER = OFF,
DTC_SUPPORT = NONE)
FOR DATABASE [TestDB]
REPLICA ON N'CLUSTER-SQL1' WITH (ENDPOINT_URL = N'TCP://CLUSTER-SQL1.dbeng.com:5022', FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = MANUAL),
  N'CLUSTER-SQL2' WITH (ENDPOINT_URL = N'TCP://cluster-sql2.dbeng.com:5022', FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = MANUAL);
GO

    6. Une el segundo nodo al grupo de disponibilidad recién creado:

      :Connect CLUSTER-SQL2
ALTER AVAILABILITY GROUP [cluster-ag] JOIN;
GO

    7. Crea una copia de seguridad de la base de datos en el primer nodo:

      :Connect CLUSTER-SQL1
BACKUP DATABASE [TestDB] TO DISK = N'\\CLUSTER-SQL2\SQLBackup\TestDB.bak' WITH COPY_ONLY, FORMAT, INIT, SKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 5
GO

    8. Restablece la copia de seguridad de la base de datos en el segundo nodo:

      :Connect CLUSTER-SQL2
RESTORE DATABASE [TestDB] FROM DISK = N'\\CLUSTER-SQL2\SQLBackup\TestDB.bak' WITH NORECOVERY, NOUNLOAD, STATS = 5
GO

    9. Crea una copia de seguridad del registro de transacciones en el primer nodo:

      :Connect CLUSTER-SQL1
BACKUP LOG [TestDB] TO DISK = N'\\CLUSTER-SQL2\SQLBackup\TestDB.trn' WITH NOFORMAT, INIT, NOSKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 5
GO

    10. Restablece la copia de seguridad del registro de transacciones en el segundo nodo:

      :Connect CLUSTER-SQL2
RESTORE LOG [TestDB] FROM  DISK = N'\\CLUSTER-SQL2\SQLBackup\TestDB.trn' WITH NORECOVERY, NOUNLOAD, STATS = 5
GO

  7. Para asegurarte de que no haya errores en la sincronización, ejecuta la siguiente consulta y asegúrate de que la columna connected_state_desc tenga el valor CONNECTED:

    :Connect CLUSTER-SQL2
select r.replica_server_name, r.endpoint_url,
       rs.connected_state_desc, rs.last_connect_error_description,
       rs.last_connect_error_number, rs.last_connect_error_timestamp
 from sys.dm_hadr_availability_replica_states rs
  join sys.availability_replicas r
   on rs.replica_id=r.replica_id
 where rs.is_local=1

    • Si la columna connected_state_desc tiene el mensaje de error An error occurred while receiving data: '24(The program issued a command but the command length is incorrect)', ejecuta el siguiente comando para intentar borrar el error:

      :Connect CLUSTER-SQL1
IF SUSER_ID('DBENG\CLUSTER-SQL2$') IS NULL
   CREATE LOGIN [DBENG\CLUSTER-SQL2$] FROM WINDOWS
GO

GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DBENG\CLUSTER-SQL2$]
GO

:Connect CLUSTER-SQL2
IF SUSER_ID('DBENG\CLUSTER-SQL1$') IS NULL
  CREATE LOGIN [DBENG\CLUSTER-SQL1$] FROM WINDOWS
GO

GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DBENG\CLUSTER-SQL1$]
GO

      Vuelve a ejecutar la consulta anterior para asegurarte de que el error de sincronización ya no ocurra. Es posible que debas esperar unos minutos para que se borre el error. Si el error persiste, consulta Soluciona problemas de configuración de grupos de disponibilidad Always On (SQL Server).

  8. Finaliza la configuración del grupo de disponibilidad:

    :Connect CLUSTER-SQL2
ALTER DATABASE [TestDB] SET HADR AVAILABILITY GROUP = [cluster-ag]
GO

ALTER DATABASE [TestDB] SET HADR RESUME;
GO

  9. Verifica que el grupo de disponibilidad se esté sincronizando:

    1. En SQL Server Management Studio, en Alta disponibilidad Siempre activa > Grupos de disponibilidad, haz clic derecho en el grupo de disponibilidad y, luego, selecciona Mostrar panel.

    2. Verifica que el estado de sincronización principal sea Sincronizado, y el estado de sincronización secundario sea Sincronizar, como se muestra en la siguiente captura de pantalla:

      SQL Server Management Studio muestra el estado de sincronización del grupo de disponibilidad.

  10. Para agregar un objeto de escucha, en Alta disponibilidad Siempre activado > Grupos de disponibilidad > cluster-ag (Primary) > Objetos de grupo de disponibilidad, haz clic con el botón derecho en el nombre del grupo de disponibilidad y selecciona Agregar objeto de escucha

  11. En el cuadro de diálogo Nuevo objeto de escucha del grupo de disponibilidad, especifica los siguientes parámetros para el objeto de escucha:

    • Nombre de DNS del objeto de escucha: ag-listener
    • Puerto: 1433
    • Modo de red: Static IP

  12. Agrega dos campos de subred y dirección IP. En este ejemplo, usa los siguientes pares de subred y dirección IP. Estos pares son las direcciones IP que creaste además de la dirección IP principal en las VM de la instancia de SQL Service:

    1. Para el primer par, ingresa los siguientes valores:
      • Subred: 192.168.1.0/24
      • Dirección IPv4: 192.168.1.6
    2. Para el segundo par, ingresa los siguientes valores:
      • Subred: 10.1.1.0/24
      • Dirección IPv4: 10.1.1.6

  13. Cuando termines de agregar pares de dirección IP y subred, haz clic en Aceptar.

  14. Conéctate a SQL Server con ag-listener.dbeng.com como el nombre de la base de datos de SQL Server en lugar del nombre de las instancias. Esta conexión apunta a la instancia que está activa en este momento.

    1. En el explorador de objetos, haz clic en Conectar y, luego, selecciona Motor de base de datos.
    2. En el cuadro de diálogo Conectar al servidor, en el campo Nombre del servidor, ingresa el nombre del objeto de escucha ag-listener.dbeng.com.

    3. Después de agregar el nombre del servidor, haz clic en Conectar. En el explorador de objetos, se muestra la conexión nueva, como se ve en la siguiente captura de pantalla:

      El explorador de objetos muestra una conexión.

    Si te conectas a cluster-sql2 mediante RDP, puedes repetir este paso para establecer la conexión.

Agrega datos de prueba

En esta sección, agregarás una tabla de prueba y algunos datos de prueba a la base de datos TestDB en cluster-sql1 y, luego, verificarás la replicación de datos.

  1. Crea una tabla con el nombre Persons en cluster-sql1:

    :Connect CLUSTER-SQL1
USE TestDB;
CREATE TABLE Persons (
    PersonID int,
    LastName varchar(255),
    FirstName varchar(255),
    PRIMARY KEY (PersonID)
);

  2. Inserta algunas filas:

    :Connect CLUSTER-SQL1
USE TestDB;
INSERT INTO Persons (PersonId, LastName, FirstName)
  VALUES (1, 'Velasquez', 'Ava');
INSERT INTO Persons (PersonId, LastName, FirstName)
  VALUES (2, 'Delaxcrux', 'Paige');

  3. Si usas la edición Enterprise, habilita el acceso de lectura de la réplica de lectura (cluster-sql2) para que puedas verificar que se realice la replicación. La edición Estándar no es compatible con el acceso de solo lectura a la réplica de lectura. Si usas la edición Estándar, pasa a la siguiente sección para ejecutar la migración de sistemas a Google Cloud.

    :Connect CLUSTER-SQL1
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON N'CLUSTER-SQL2' WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL))
GO

  4. En la edición Enterprise, consulta la tabla en cluster-sql2 para verificar que el contenido de la tabla se haya replicado:

    :Connect CLUSTER-SQL2
SELECT * FROM TestDB.dbo.Persons;

Ahora que los datos se replicaron desde cluster-sql1 a cluster-sql2, ejecuta la migración de sistemas. Si solo deseas realizar la replicación, puedes omitir las siguientes secciones y no ejecutar la migración de sistemas o el resguardo. Si no quieres conservar los recursos que usaste para realizar la replicación, puedes seguir los pasos de limpieza al final de este instructivo a fin de evitar que se apliquen cargos.

Ejecuta la migración de sistemas a Google Cloud

A fin de garantizar un conjunto de datos coherente, se debe detener a cualquier cliente que escriba en cluster-sql1 para que todos los datos se puedan replicar en cluster-sql2 antes de ejecutar la migración de sistemas.

Para garantizar la coherencia, todos los datos se deben replicar por completo. En esta sección, se realizará la replicación de datos completa cambiando el modo de disponibilidad a SYNCHRONOUS_COMMIT. Este cambio garantiza una replicación completa de cluster-sql1 a cluster-sql2.

  1. Para cambiar el modo de disponibilidad de ambos nodos a la confirmación síncrona, ejecuta el siguiente comando de SQL en cluster-sql1. Configurar ambos nodos a la confirmación síncrona es la única forma de garantizar que no se pierda ningún dato.

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

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

  2. Ahora Cluster-sql2 está listo para convertirse en el nodo principal. Conéctate a cluster-sql2 y conviértelo el nodo principal:

    :Connect CLUSTER-SQL2
ALTER AVAILABILITY GROUP [cluster-ag] FAILOVER;
GO

  3. Cambia el modo de disponibilidad a confirmación asíncrona en ambos nodos. Debido a que cluster-sql2 es el nodo principal, ejecuta los siguientes comandos de SQL en cluster-sql2:

    :Connect CLUSTER-SQL2
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON N'CLUSTER-SQL1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
GO

ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON N'CLUSTER-SQL2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
GO

    Ahora estás listo para usar cluster-sql2 como el nodo principal de las aplicaciones. cluster-sql1 es el secundario que se replica de forma asíncrona.

  4. Ahora que cluster-sql2 es el nodo principal, consulta la tabla en cluster-sql2 para verificar que el contenido de la tabla se haya replicado:

    :Connect CLUSTER-SQL2
SELECT * FROM TestDB.dbo.Persons;

    El resultado coincide con los datos de prueba que insertaste en la tabla antes en este instructivo.

Para realizar una verificación de replicación adicional, puedes crear una tabla nueva e insertar una sola fila en el principal nuevo. Cuando la tabla y su fila aparezcan en el secundario, sabrás que la replicación funciona.

Resguardo

En ocasiones, es posible que debas volver del nuevo principal al principal original. Cuando completaste la migración de sistemas a Google Cloud anteriormente en este instructivo, hiciste la versión principal anterior (cluster-sql1) la secundaria en el nuevo primario (cluster-sql2).

A fin de completar una reversión, sigue el proceso para ejecutar la migración de sistemas a Google Cloud y reemplaza los siguientes valores:

  • Reemplaza el principal (cluster-sql1) por el principal nuevo (cluster-sql2).
  • Reemplaza el secundario original (cluster-sql2) por el secundario nuevo (cluster-sql1).

Limpia

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

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 en Google Cloud

  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.

Borra el proyecto en AWS

Debido a que creaste y usaste recursos en AWS, continúan generando costos. Para garantizar que no se acumulen más costos, borra esos recursos en AWS.

¿Qué sigue?