Como migrar o Microsoft SQL Server da AWS para o Google Cloud

Last reviewed 2023-05-05 UTC

Neste documento, mostramos como migrar uma instância do Microsoft SQL Server instalada no Amazon Elastic Compute Cloud (Amazon EC2) para uma instância do Microsoft SQL Server no Compute Engine no Google Cloud. Essa migração é baseada exclusivamente na tecnologia de banco de dados integrada fornecida pelo Microsoft SQL Server. Esse é um método efetivo de zero inatividade que usa um grupo de disponibilidade sempre ativado. O grupo de disponibilidade sempre ativado abrange a AWS e o Google Cloud por VPN e permite a replicação do banco de dados do Microsoft SQL Server. Para usar este documento, é necessário ter familiaridade com a configuração de rede, o Google Cloud, o Compute Engine, a AWS e o Microsoft SQL Server.

Se você quiser executar apenas a replicação, siga as etapas deste tutorial, mas pare depois de adicionar os dados de teste e omita as etapas de transição.

Objetivos

  • Implante um grupo de disponibilidade sempre ativado do Microsoft SQL Server em várias nuvens que abra um Microsoft SQL Server no Amazon EC2 e um Microsoft SQL Server no Google Cloud no Compute Engine.
  • Configure uma instância principal do Microsoft SQL no Amazon EC2.
  • Configure a instância do Microsoft SQL Server no Google Cloud como secundária para o Microsoft SQL Server primário na AWS (destino da replicação de dados).
  • Para concluir a migração de dados, torne o Microsoft SQL Server secundário no Google Cloud, o Microsoft SQL Server principal no Google Cloud.

Custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Este tutorial também requer recursos da AWS que podem gerar custos.

Antes de começar

  1. No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

    Acessar o seletor de projetos

  2. Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

  3. No Console do Google Cloud, ative o Cloud Shell.

    Ativar o Cloud Shell

Noções básicas sobre a migração do banco de dados

A migração de banco de dados move os dados de um banco de dados de origem para um banco de dados de destino. Em geral, é possível migrar um subconjunto dos dados ou ter um esquema diferente no banco de dados de origem e destino. No entanto, este tutorial aborda a migração homogênea do banco de dados que requer a migração do banco de dados completo sem alterações. O banco de dados de destino é uma cópia do banco de dados de origem.

Zerar a inatividade da migração do banco de dados

O termo inatividade zero refere-se ao fato de que, durante a migração, os clientes que acessam o banco de dados de origem permanecem totalmente operacionais e não são interrompidos. O único tempo de inatividade ocorre quando os clientes precisam se reconectar ao banco de dados de destino após a conclusão da migração. Embora esse método não seja nenhum tempo de inatividade zero, o termo se refere a esse cenário de tempo de inatividade mínimo.

Para uma discussão geral sobre a migração do banco de dados, consulte Migração de banco de dados: conceitos e princípios (parte 1) e Migração de banco de dados: conceitos e princípios (parte 2). Nestes artigos, fornecemos uma visão geral da possível complexidade da migração do banco de dados em diferentes cenários.

Migração de bancos de dados usando a tecnologia do Microsoft SQL Server

Algumas tecnologias de migração de banco de dados fornecem componentes e serviços separados. Quando a migração do banco de dados requer uma cópia do banco de dados de origem, você pode usar a tecnologia integrada do Microsoft SQL Server.

Neste tutorial, usamos a tecnologia do Grupo de Disponibilidade sempre ativado do Microsoft SQL Server para conectar o banco de dados de origem (principal) a um banco de dados de destino (secundário). Essa tecnologia fornece replicação assíncrona do banco de dados primário para o secundário. Como o banco de dados primário está no Amazon EC2 e o secundário está no Google Cloud no Compute Engine, a replicação realiza a migração do banco de dados. Depois que todos os dados forem migrados por meio da replicação assíncrona, o secundário será promovido ao principal e os clientes poderão se reconectar ao novo primário para processamento contínuo.

Essa abordagem aceita testes explícitos com uma replicação de avaliação em um banco de dados de destino de teste. Você pode iniciar a replicação, mantê-la em execução por um tempo e, em seguida, parar a replicação. O banco de dados de destino de teste está em um estado consistente, e você pode usá-lo para testar o aplicativo. Após a conclusão dos testes, exclua o banco de dados de destino do teste e inicie a replicação para um banco de dados ativo.

Arquitetura de migração de banco de dados de várias nuvens

O diagrama a seguir mostra a arquitetura geral de implantação para uma migração de banco de dados de várias nuvens:

Um grupo de disponibilidade sempre ativado conecta um banco de dados da AWS a um banco de dados do Google Cloud.

O diagrama anterior mostra o banco de dados SQL de origem (principal) na AWS como uma instância do Amazon EC2. O diagrama também mostra o banco de dados de destino (secundário) no Google Cloud. Os bancos de dados estão conectados por um grupo de disponibilidade sempre ativado. A conexão de rede entre a AWS e o Google Cloud é considerada uma conexão VPN de alta disponibilidade.

Como configurar um grupo de disponibilidade do Microsoft SQL Server com várias nuvens

Nas seções a seguir, você configura um grupo de disponibilidade sempre ativado de dois nós em que o nó primário reside na AWS e o nó secundário reside no Google Cloud. Essa configuração é descrita anteriormente neste documento em Arquitetura de migração do banco de dados de várias nuvens.

As tabelas a seguir fornecem um resumo dos nós e endereços IP que você configurou neste tutorial. Para cada VM de banco de dados, você aloca dois endereços IP além do endereço IP primário: um endereço IP para o Windows Server Failover Cluster (WSFC) e um endereço IP para o listener do grupo de disponibilidade.

Provedor Instância IP primário WSFC e IPs Listener do grupo de disponibilidade WSFC Grupo de disponibilidade
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
Provedor Instância IP primário —
AWS dc-windows 192.168.1.100 Domain controller

As instruções usam esses nomes e endereços IP como exemplos. Para usar seus próprios nomes e endereços IP, substitua os valores de exemplo nas instruções.

Pré-requisitos para AWS

Na AWS, você precisa ter duas máquinas virtuais: uma que executa o controlador de domínio e outra que executa um SQL Server. O controlador de domínio usado como exemplo neste tutorial tem a seguinte configuração:

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

A VM do SQL Server usada como exemplo neste tutorial faz parte de um domínio do Windows Active Directory no Amazon EC2. O servidor tem dois endereços IP secundários a serem usados pelo WSFC e pelo Listener do grupo de disponibilidade. A VM do SQL Server tem a seguinte configuração:

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

Use a conta de serviço NT SERVICE\MSSQLSERVER como a conta de serviço do SQL Server. Durante a configuração do grupo de disponibilidade sempre ativado, você concede acesso às contas de máquina (dbeng\cluster-sql1$, dbeng\cluster-sql2$) em vez da conta de domínio. Veja na seção a seguir os comandos para configurar o grupo de disponibilidade.

Pré-requisitos para conectividade entre a AWS e o Google Cloud

Para conectar seu projeto da AWS ao projeto do Google Cloud, configure a seguinte conectividade de rede:

  1. Configure uma nuvem privada virtual do Google, uma VPC da AWS nos respectivos projetos e configure uma VPN entre as VPCs. Para informações sobre como configurar uma VPN entre o Google Cloud e a AWS, consulte VPN de várias nuvens e sub-redes: configuração de rede para implantações de banco de dados de várias nuvens.

  2. No Cloud Shell, crie uma sub-rede no projeto do Google Cloud em que você está criando a instância do SQL Server. Se você já tiver uma sub-rede, poderá usá-la, mas configure as regras de firewall na próxima etapa.

    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

    Neste tutorial, os seguintes valores são usados:

    • VPC: demo-vpc
    • Sub-rede demo-subnet1; 10.1.1.0/24

    A sub-rede é exibida na página Redes VPC do Console do Google Cloud.

  3. No projeto do Google Cloud, crie uma regra de firewall para abrir todo o tráfego entre a sub-rede do Google Cloud e a sub-rede da 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

    A regra de firewall é exibida na página Políticas de Firewall do Console do Google Cloud.

  4. No projeto da AWS, crie uma regra de firewall no grupo de segurança para abrir todo o tráfego entre a sub-rede do Google Cloud e a sub-rede da AWS, como mostrado na captura de tela a seguir:

    As regras de entrada da AWS estão definidas para permitir todo o tráfego, todos os protocolos e todos os intervalos de portas.

    Em um ambiente de produção, considere abrir apenas as portas TCP/UDP necessárias. Abrir somente as portas necessárias limita o tráfego potencialmente nocivo e segue um princípio menos necessário.

Como criar uma instância no Google Cloud para o grupo de disponibilidade sempre ativado

Este tutorial funciona com as seguintes edições e recursos do Microsoft SQL Server:

  • Edição:
    • Microsoft SQL Server 2016 Enterprise Edition ou
    • Microsoft SQL Server 2017 Enterprise Edition ou
    • Microsoft SQL Server 2019 Enterprise Edition ou
    • Microsoft SQL Server 2022 Enterprise Edition ou
    • Microsoft SQL Server 2016 Standard Edition ou
    • Microsoft SQL Server 2017 Standard Edition ou
    • Microsoft SQL Server 2019 Standard Edition ou
    • Microsoft SQL Server 2022 Standard Edition
  • Recurso: grupos de disponibilidade sempre ativados

As instruções a seguir usam a imagem do Microsoft SQL Server 2019 Enterprise Edition: sql-ent-2019-win-2019. Se você quiser instalar o Microsoft SQL Server 2017, 2016 ou 2022 Enterprise Editions, use sql-ent-2017-win-2019, sql-ent-2016-win-2019, respectivamente sql-ent-2022-win-2019. Para ver uma lista de todas as imagens, consulte a página Detalhes do sistema operacional do Compute Engine.

Nas etapas a seguir, você cria uma instância do SQL Server no Google Cloud para o grupo de disponibilidade. A instância usa a seguinte configuração de endereço IP com endereços IP de alias:

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

Você cria uma instância chamada cluster-sql2 a partir de imagens públicas do SQL Server, com um tamanho de disco de inicialização de 200 GB e um tipo de máquina n1-highmem-4. As instâncias do SQL Server normalmente exigem mais recursos de computação do que a instância do controlador de domínio. Se for preciso mais recursos de computação posteriormente, é possível alterar o tipo de máquina dessas instâncias. Se for preciso espaço de armazenamento adicional, adicione um disco ou redimensione o disco de inicialização permanente. Em grupos de disponibilidade maiores, é possível criar várias instâncias.

As etapas a seguir também incluem a sinalização --metadata sysprep-specialize-script-ps1 que executa um comando do Microsoft PowerShell durante a criação da instância para instalar o recurso Clustering-Clustering.

  1. No Cloud Shell, crie uma instância do SQL Server no Google Cloud que use a mesma versão do sistema operacional da 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. Defina um nome de usuário e uma senha do Windows antes de se conectar à instância.

  3. Ao usar o Remote Desktop Protocol (RDP) no seu laptop, crie uma regra de firewall que permita acesso à instância.

  4. Conecte-se à instância do Google Cloud usando o RDP e abra um PowerShell elevado (executado como administrador).

  5. Neste tutorial, você configura um DNS local para usar o controlador de domínio na AWS (192.168.1.100) para evitar a criação de outra VM no Google Cloud. Para as cargas de trabalho de produção, recomendamos que você use um controlador de domínio (principal ou secundário) no Google Cloud para evitar a autenticação no túnel da VPN.

    No PowerShell elevado, você poderá dar um ping no controlador de domínio 192.168.1.100:

    ping 192.168.1.100

    Se o ping falhar, verifique se o firewall e o túnel da VPN estão configurados corretamente entre a AWS e o Google Cloud, conforme descrito em Pré-requisitos para conectividade anteriormente neste documento.

  6. Como o servidor foi configurado originalmente com DHCP, altere a instância para usar endereços IP estáticos:

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

    Após a execução do comando anterior, você perderá sua conexão. Reconecte-se no RDP.

  7. Configurar o DNS local para usar o controlador de domínio na AWS e abrir as portas de firewall locais do SQL Server. Abrir as portas do firewall permite que o SQL Server se conecte aos servidores SQL 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. Adicione a instância ao domínio do Windows:

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

    O comando solicita as credenciais de administrador de domínio. Quando o comando terminar de executar, a instância reiniciará.

    Se o comando não for executado, verifique se você está executando-o como administrador.

  9. Use a conta dbeng\Administrator para se reconectar à instância usando RDP.

  10. Defina a conta de serviço do SQL Server:

    1. Abra o SQL Server 2019 Configuration Manager.
    2. Na guia Serviços do SQL Server, clique com o botão direito do mouse em SQL Server (MSSQLSERVER) e clique em Propriedades.
    3. Defina a conta e a senha de dbeng\sql_service.
    4. Reinicie o SQL Server.

  11. Renomeie a instância do SQL Server para corresponder ao nome do computador e reinicie o 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"

Em seguida, configure a instância na AWS.

Configurar a instância na AWS

Neste tutorial, presumimos que você já tenha configurado o seguinte na AWS:

  • A instância do SQL Server faz parte do domínio do Active Directory.
  • O DNS local está funcionando corretamente e o nome do servidor remoto no Google Cloud (cluster-sql2.dbeng.com) pode ser convertido em um endereço IP.
  • As regras de firewall são abertas entre as sub-redes na AWS e no Google Cloud.

Para configurar cluster-sql1 na AWS, faça o seguinte:

  1. Conecte-se à instância AWS usando RDP (cluster-sql1).
  2. Abra um PowerShell elevado (executado como administrador).

  3. Caso ainda não tenha feito isso, instale o cluster de failover do Windows.

    Install-WindowsFeature Failover-Clustering -IncludeManagementTools

    Este comando requer uma reinicialização se o recurso ainda não estiver instalado. Após a reinicialização, continue com a próxima etapa.

  4. Abra as portas de firewall locais para a instância do SQL Server na 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. Renomeie a instância do SQL Server para corresponder ao nome do computador e reinicie o 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. Valide se a instância no AWS pode se conectar à instância no Google Cloud ao usar o nome da instância remota. Para testar a conexão, execute os seguintes comandos em uma conta de domínio que concedeu acesso de conexão ao SQL Server.

    1. Testar conexão de rede:

      ping -4 cluster-sql2.dbeng.com

      A saída será assim:

      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. Teste a autenticação do Windows para o servidor remoto:

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

      A saída será assim:

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

(1 rows affected)

    Se não conseguir se conectar, verifique se o DNS está funcionando corretamente e se as regras de firewall estão abertas entre as sub-redes da AWS e do Google Cloud.

Verifique se a instância do Google Cloud está pronta para participar do grupo de disponibilidade

  1. Use a conta dbeng\Administrator para se conectar à instância do Google Cloud usando RDP (cluster-sql2).
  2. Abra um PowerShell elevado (executado como administrador).

  3. Valide se a instância no Google Cloud pode se conectar a ela no AWS ao usar o nome dela. Para testar a conexão, execute os seguintes comandos em uma conta de domínio que concedeu acesso ao SQL Server.

    1. Testar conexão de rede:

      ping -4 cluster-sql1.dbeng.com

      A saída será assim:

      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. Teste a autenticação do Windows para o servidor remoto:

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

      A saída será assim:

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

(1 rows affected)

      Se não conseguir se conectar, verifique se o DNS está funcionando corretamente e se as regras de firewall estão abertas entre as sub-redes da AWS e do Google Cloud.

  4. Crie pastas em C:\SQLData e C:\SQLLog. Os arquivos de dados e arquivos de registros do banco de dados usam essas pastas.

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

  5. Crie uma pasta em C:\SQLBackup e um compartilhamento do Windows em \\cluster-sql2\SQLBackup para transferir o backup da instância da AWS. Você pode usar qualquer outro compartilhamento de rede disponível para os dois 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"

As instâncias agora estão prontas para o grupo de disponibilidade. Como você tem apenas duas instâncias, na próxima seção, você configura uma testemunha de compartilhamento de arquivos para fornecer um voto de desempate e conquistar um quórum.

Como criar uma testemunha de compartilhamento de arquivos

Para dar um voto de desempate e conquistar um quórum para o cenário de failover, crie um compartilhamento de arquivos que funciona como uma testemunha. Para este tutorial, você cria a testemunha de compartilhamento de arquivos na VM do controlador de domínio. Em um ambiente de produção, você criaria a testemunha de compartilhamento de arquivos em qualquer servidor no domínio do Active Directory.

  1. Use a conta dbeng\Administrator para se conectar à VM do controlador de domínio, dc-windows, usando RDP.
  2. Abra um PowerShell elevado (executado como administrador).

  3. Crie a pasta de testemunha:

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

  4. Compartilhe a pasta:

    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. Use dbeng.com\Administrator para se conectar a cluster-sql1 e cluster-sql2 usando RDP.

  6. Verifique se você pode acessar o diretório compartilhado nos dois servidores:

    dir \\dc-windows\QWitness

    Se você não conseguir acessar o diretório compartilhado, tente alterar a conexão de rede no nó para definir o servidor WINS para corresponder ao servidor de domínio. A alteração da conexão de rede pode levar alguns segundos. A captura de tela a seguir mostra as configurações atualizadas do WINS:

    Configurações de endereço WINS atualizadas nas configurações avançadas de TCP/IP.

Está tudo pronto para o grupo de disponibilidade. Em seguida, configure o cluster de failover.

Como configurar o cluster de failover

Nesta seção, você configura o WSFC e ativa a alta disponibilidade sempre ativa para as duas instâncias. Execute todos os comandos de configuração a seguir da instância na AWS.

  1. Conecte-se à instância AWS (cluster-sql1) usando o RDP.
  2. Abra um PowerShell elevado (executado como administrador).

  3. Defina variáveis que reflitam seu ambiente de cluster. Para este exemplo, configure as seguintes variáveis:

    $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. Crie o cluster de failover. A execução deste comando pode demorar um pouco:

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

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

  5. Ative a opção "Sempre ativa" na "Alta disponibilidade" no nó 1. Caso você não tenha ativado esse recurso antes, esses comandos forçam o reinício do SQL Server.

    Enable-SqlAlwaysOn -ServerInstance $node1 -Force

  6. Ativar alta disponibilidade sempre ativado no nó 2. Esses comandos interrompem o serviço do SQL Server antes de ativar o SQL sempre ativado, para que você possa ignorar o erro que diz: 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. Crie pastas em C:\SQLData e C:\SQLLog. Use essas pastas para os dados do banco de dados e os arquivos de registro do TestDB. Se o servidor já tiver um banco de dados com essa estrutura de pastas, pule esta etapa. Se você não tiver certeza, execute os comandos e ignore todas as mensagens de erro sobre pastas preexistentes.

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

O Failover Cluster Manager está pronto. Em seguida, crie o grupo de disponibilidade.

Criar o grupo de disponibilidade

Nesta seção, você cria um banco de dados de teste na AWS (cluster-sql1) e o configura para trabalhar com um novo grupo de disponibilidade. Como alternativa, é possível especificar um banco de dados existente para o grupo de disponibilidade.

  1. Conecte-se à instância AWS (cluster-sql1) usando o RDP.
  2. Abra um PowerShell elevado (executado como administrador).

  3. Crie uma pasta em C:\SQLBackup para armazenar um backup do banco de dados. O backup é necessário para que você possa configurar o grupo de disponibilidade em um novo banco de dados.

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

  4. Se você ainda não tiver um banco de dados configurado, execute o SQL Server Management Studio e crie um banco de dados de teste na instância da 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. No Microsoft SQL Server Management Studio, selecione Consulta > Modo SQLCMD.

    O SQL Server Management Studio oferece um assistente para criar os grupos de disponibilidade. Neste tutorial, você usa comandos SQL para facilitar a depuração de problemas que podem ser encontrados ao se conectar a diferentes provedores de nuvem. Se preferir, execute o assistente do grupo de disponibilidade e pule para a etapa seguinte para verificar se o grupo de disponibilidade está sincronizando.

  6. Execute as consultas a seguir no modo SQLCMD. Se você estiver usando um banco de dados preexistente, substitua TestDB pelo nome do banco de dados.

    1. Crie um endpoint no primeiro nó e conceda permissão a ele:

      :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. Ative a sessão de evento estendida AlwaysOn_health no primeiro nó. Os grupos de disponibilidade exigem a sessão estendida do evento.

      :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. Crie um endpoint no segundo nó e conceda a permissão a ele:

      :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. Ative a sessão de evento estendida AlwaysOn_health no primeiro nó. Os grupos de disponibilidade exigem a sessão estendida do evento.

      :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. Crie o grupo de disponibilidade no primeiro nó:

      :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. Junte-se o segundo nó ao grupo de disponibilidade recém-criado:

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

    7. Crie um backup do banco de dados no primeiro nó:

      :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. Restaure o backup do banco de dados no segundo nó:

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

    9. Crie um backup do registro de transações no primeiro nó:

      :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. Restaure o backup do registro de transações no segundo nó:

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

  7. Para garantir que não haja erros na sincronização, execute a seguinte consulta e certifique-se de que a coluna connected_state_desc tenha um 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

    • Se a coluna connected_state_desc tiver a mensagem de erro An error occurred while receiving data: '24(The program issued a command but the command length is incorrect)', execute o seguinte comando para tentar limpar o erro:

      :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

      Execute novamente a consulta anterior para garantir que o erro de sincronização não ocorra mais. Talvez seja necessário aguardar alguns minutos para que o erro seja apagado. Se o erro persistir, consulte Solução de problemas de configuração de grupos de disponibilidade sempre ativados (SQL Server).

  8. Conclua a configuração do grupo de disponibilidade:

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

ALTER DATABASE [TestDB] SET HADR RESUME;
GO

  9. Verifique se o grupo de disponibilidade está sincronizando:

    1. No SQL Server Management Studio, em Always On High Availability > Availability Groups, clique com o botão direito do mouse no grupo de disponibilidade e selecione Show Dashboard.

    2. Verifique se o estado de sincronização principal é Synchronized e se o estado de sincronização secundário é Synchronization, conforme mostrado na captura de tela a seguir:

      O SQL Server Management Studio mostra o Estado de sincronização do grupo de disponibilidade.

  10. Para adicionar um listener, em Always On High Availability > Availability Groups > cluster-ag (Primary) > Availability Group Listeners, clique com o botão direito do mouse no nome do grupo de disponibilidade e selecione Add Listener.

  11. Na caixa de diálogo Novo listener do grupo de disponibilidade, especifique os seguintes parâmetros para o listener:

    • Nome DNS do listener: ag-listener
    • Porta: 1433
    • Modo de rede: Static IP

  12. Adicione dois campos de sub-rede e endereço IP. Para este exemplo, use os seguintes pares de sub-rede e endereço IP: Estes pares são os endereços IP que você criou além do endereço IP principal nas VMs da instância do SQL Service:

    1. Para o primeiro par, insira os seguintes valores:
      • Sub-rede: 192.168.1.0/24
      • Endereço IPv4: 192.168.1.6
    2. Para o segundo par, insira os seguintes valores:
      • Sub-rede: 10.1.1.0/24
      • Endereço IPv4: 10.1.1.6

  13. Quando terminar de adicionar pares de sub-redes e endereços IP, clique em OK.

  14. Conecte-se ao SQL Server usando ag-listener.dbeng.com como o nome do banco de dados do SQL Server em vez do nome das instâncias. Essa conexão aponta para a instância ativa no momento.

    1. Em Object Explorer, clique em Connect e selecione Database Engine.
    2. Na caixa de diálogo Connect to Server, no campo Server name, insira o nome do listener ag-listener.dbeng.com.

    3. Depois de adicionar o nome do servidor, clique em Conectar. O Object Explorer mostra a nova conexão, conforme mostrado na captura de tela a seguir:

      O Object Explorer mostra uma conexão.

    Se você estiver conectado a cluster-sql2 usando o RDP, poderá repetir essa etapa para estabelecer a conexão.

Como adicionar dados de teste

Nesta seção, você adicionará uma tabela de teste e alguns dados de teste ao banco de dados do TestDB em cluster-sql1 e, em seguida, verificará a replicação de dados.

  1. Crie uma tabela chamada Persons em cluster-sql1:

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

  2. Insira algumas linhas:

    :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. Se você estiver usando a edição Enterprise, ative o acesso de leitura da réplica de leitura (cluster-sql2) para que você possa verificar se a replicação ocorreu. A edição Standard não é compatível com acesso somente leitura à réplica de leitura. Se você estiver usando a edição padrão, pule para a próxima seção para executar a transição para o Google Cloud.

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

  4. Na edição Enterprise, consulte a tabela em cluster-sql2 para verificar se o conteúdo da tabela foi replicado:

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

Agora que os dados são replicados de cluster-sql1 para cluster-sql2, você executa a transferência. Se você quiser apenas executar a replicação, ignore as seções a seguir e não execute a transição ou o substituto. Se você não quiser manter os recursos usados para executar a replicação, evite cobranças seguindo as etapas de limpeza ao final deste tutorial.

Como executar a transição para o Google Cloud

Para garantir um conjunto de dados consistente, qualquer cliente que grave em cluster-sql1 precisa ser interrompido para que todos os dados possam ser replicados para cluster-sql2 antes de executar a transição.

Para garantir consistência, todos os dados precisam ser completamente replicados. Nesta seção, você alcança a replicação de dados completa alterando o modo de disponibilidade para SYNCHRONOUS_COMMIT. Essa mudança garante uma replicação completa de cluster-sql1 para cluster-sql2.

  1. Para alterar o modo de disponibilidade de ambos os nós para confirmação síncrona, execute o seguinte comando SQL em cluster-sql1. A configuração dos dois nós para a confirmação síncrona é a única maneira de garantir que nenhum dado seja perdido.

    :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. Cluster-sql2 está pronto para se tornar o nó principal. Conecte-se a cluster-sql2 e torne-o o nó principal:

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

  3. Altere o modo de disponibilidade para confirmação assíncrona nos dois nós. Como cluster-sql2 é o nó principal, execute os seguintes comandos SQL em 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

    Agora você está pronto para usar cluster-sql2 como o nó principal dos aplicativos. cluster-sql1 é a secundária que é replicada de maneira assíncrona.

  4. Agora que cluster-sql2 é o nó principal, consulte a tabela em cluster-sql2 para verificar se o conteúdo da tabela foi replicado:

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

    A saída corresponde aos dados de teste que você inseriu na tabela anteriormente neste tutorial.

Para realizar uma verificação de replicação posterior, crie uma nova tabela e insira uma única linha na nova linha principal. Quando a tabela e a linha dela aparecerem na secundária, você saberá que a replicação está funcionando.

Fallback

Às vezes, pode ser necessário retornar do novo primário para o primário original. Quando você concluiu a transição para o Google Cloud no início deste tutorial, você fez o primário anterior (cluster-sql1) o secundário para o novo primário (cluster-sql2).

Para concluir um fallback, siga o processo para executar a transição para o Google Cloud e substitua os seguintes valores:

  • Substitua o principal original (cluster-sql1) pelo novo primário (cluster-sql2).
  • Substitua o secundário original (cluster-sql2) pelo nova secundário (cluster-sql1).

Limpeza

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.

Para evitar cobranças dos recursos usados neste tutorial na conta do Google Cloud, siga estas etapas:

Excluir o projeto no Google Cloud

  1. No Console do Google Cloud, acesse a página Gerenciar recursos.

    Acessar "Gerenciar recursos"

  2. Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
  3. Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

Excluir o projeto na AWS

Como você criou e usou recursos no AWS, eles continuarão a gerar custos. Para garantir que não haja custo adicional, exclua esses recursos na AWS.

A seguir