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:
- Compute Engine
- VM de SQL Server
Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.
Este instructivo también requiere de recursos en AWS que podrían generar costos.
Antes de comenzar
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.
-
In the Google Cloud console, activate 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:
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
|
Name: cluster-dbclus
|
Name: cluster-ag
|
Google Cloud | cluster-sql2 |
10.1.1.4 |
10.1.1.5
|
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:
- 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.
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.
- VPC:
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.
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:
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.
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;"
Configura un nombre de usuario y una contraseña de Windows antes de conectarte a la instancia.
Cuando uses el protocolo de escritorio remoto (RDP) desde tu laptop, crea una regla de firewall que permita el acceso a la instancia.
Conéctate a la instancia de Google Cloud mediante RDP y abre un PowerShell con privilegios elevados (se ejecuta como administrador).
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.
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.
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
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.
Usa la cuenta
dbeng\Administrator
para volver a conectarte a tu instancia mediante RDP.Configura la cuenta de servicio de SQL Server:
- Abre el Administrador de configuración de SQL Server 2019.
- En la pestaña SQL Server Services, haz clic derecho en SQL Server (MSSQLSERVER) y, luego, en Propiedades.
- Configura la cuenta y la contraseña para
dbeng\sql_service
. - Reinicia SQL Server.
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:
- Conéctate a la instancia mediante RDP. (
cluster-sql1
) - Abre un PowerShell con privilegios elevados (se ejecuta como administrador).
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.
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
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"
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.
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
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
- Usa la cuenta
dbeng\Administrator
para conectarte a la instancia de Google Cloud mediante RDP (cluster-sql2
). - Abre un PowerShell con privilegios elevados (se ejecuta como administrador).
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.
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
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.
Crea carpetas en
C:\SQLData
yC:\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
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.
- Usa la cuenta
dbeng\Administrator
para conectarte a la VM del controlador de dominio,dc-windows
, mediante RDP. - Abre un PowerShell con privilegios elevados (se ejecuta como administrador).
Crea la carpeta del testigo.
New-Item "C:\QWitness" –type directory
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$"
Usa
dbeng.com\Administrator
para conectarte acluster-sql1
ycluster-sql2
mediante RDP.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:
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.
- Conéctate a la instancia de AWS (
cluster-sql1
) mediante RDP. - Abre un PowerShell con privilegios elevados (se ejecuta como administrador).
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)
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
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
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
Crea carpetas en
C:\SQLData
yC:\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.
- Conéctate a la instancia de AWS (
cluster-sql1
) mediante RDP. - Abre un PowerShell con privilegios elevados (se ejecuta como administrador).
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
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
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.
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.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
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
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
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
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
Une el segundo nodo al grupo de disponibilidad recién creado:
:Connect CLUSTER-SQL2 ALTER AVAILABILITY GROUP [cluster-ag] JOIN; GO
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
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
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
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
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 valorCONNECTED
::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 errorAn 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).
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
Verifica que el grupo de disponibilidad se esté sincronizando:
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.
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:
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 escuchaEn 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
- Nombre de DNS del objeto de escucha:
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:
- Para el primer par, ingresa los siguientes valores:
- Subred:
192.168.1.0/24
- Dirección IPv4:
192.168.1.6
- Subred:
- Para el segundo par, ingresa los siguientes valores:
- Subred:
10.1.1.0/24
- Dirección IPv4:
10.1.1.6
- Subred:
- Para el primer par, ingresa los siguientes valores:
Cuando termines de agregar pares de dirección IP y subred, haz clic en Aceptar.
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.- En el explorador de objetos, haz clic en Conectar y, luego, selecciona Motor de base de datos.
- 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
. 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:
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.
Crea una tabla con el nombre
Persons
encluster-sql1
::Connect CLUSTER-SQL1 USE TestDB; CREATE TABLE Persons ( PersonID int, LastName varchar(255), FirstName varchar(255), PRIMARY KEY (PersonID) );
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');
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
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
.
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
Ahora
Cluster-sql2
está listo para convertirse en el nodo principal. Conéctate acluster-sql2
y conviértelo el nodo principal::Connect CLUSTER-SQL2 ALTER AVAILABILITY GROUP [cluster-ag] FAILOVER; GO
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 encluster-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.Ahora que
cluster-sql2
es el nodo principal, consulta la tabla encluster-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
- En la consola de Google Cloud, ve a la página Administrar recursos.
- En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
- 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?
- Explora más documentación y soluciones para SQL Server.
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.