Implementar o Microsoft SQL Server para recuperação de desastres multirregional

Este tutorial descreve como implementar e gerir um sistema de base de dados do Microsoft SQL Server em duas regiões como solução de recuperação de desastres (RD) e como fazer failover de uma instância de base de dados com falhas para uma instância a funcionar normalmente. Trusted Cloud by S3NS Para efeitos deste documento, um desastre é um evento em que uma base de dados principal falha ou fica indisponível.

Uma base de dados principal pode falhar quando a região em que se encontra falha ou se torna inacessível. Mesmo que uma região esteja disponível e a funcionar normalmente, uma base de dados principal pode falhar devido a um erro do sistema. Nestes casos, a recuperação de desastres é o processo de disponibilização de uma base de dados secundária aos clientes para processamento contínuo.

Este tutorial destina-se a arquitetos, administradores e engenheiros de bases de dados.

Objetivos

• Implemente um ambiente de recuperação de desastres multirregional no Trusted Cloud usando os grupos de disponibilidade AlwaysOn do Microsoft SQL Server.
• Simule um evento de desastre e execute um processo completo de recuperação de desastres para validar a configuração de recuperação de desastres.

Custos

Neste documento, usa os seguintes componentes faturáveis do Trusted Cloud by S3NS:

• Compute Engine
• SQL Server VMs

Quando terminar as tarefas descritas neste documento, pode evitar a faturação contínua eliminando os recursos que criou. Para mais informações, consulte o artigo Limpe.

Antes de começar

Para este tutorial, precisa de um Trusted Cloud projeto. Pode criar um novo ou selecionar um projeto que já criou:

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

   Roles required to select or create a project

   • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
   • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

   Go to project selector

2. Verify that billing is enabled for your Trusted Cloud project.

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

   Activate Cloud Shell

   Compreender a recuperação de desastres

   Na Trusted Cloud, a recuperação de desastres (RD) consiste em garantir a continuidade do processamento, especialmente quando uma região falha ou se torna inacessível. Para sistemas, como um sistema de gestão de bases de dados, implementa a DR implementando o sistema em, pelo menos, duas regiões. Com esta configuração, o sistema continua a funcionar se uma região ficar indisponível.

   Recuperação de desastres do sistema de base de dados

   O processo de disponibilização de uma base de dados secundária quando a instância da base de dados principal falha denomina-se recuperação de desastres da base de dados (ou DR da base de dados). Para uma discussão detalhada sobre este conceito, consulte o artigo Recuperação de desastres para o Microsoft SQL Server. Idealmente, o estado da base de dados secundária é consistente com a base de dados principal no momento em que a principal fica indisponível, ou a base de dados secundária tem em falta apenas um pequeno conjunto de transações recentes da base de dados principal.

   Arquitetura de recuperação de desastres

   Para o Microsoft SQL Server, o diagrama seguinte mostra uma arquitetura mínima que suporta a DR da base de dados.

   

   Figura 1. Arquitetura de recuperação de desastres padrão com o Microsoft SQL Server.

   Esta arquitetura funciona da seguinte forma:

   • Duas instâncias do Microsoft SQL Server (uma instância principal e uma instância de reserva) estão localizadas na mesma região (R1), mas em zonas diferentes (zonas A e B). As duas instâncias em R1 coordenam os respetivos estados através do modo de confirmação síncrono. O modo síncrono é usado porque suporta a elevada disponibilidade e mantém um estado de dados consistente.
   • Uma instância do Microsoft SQL Server (a instância secundária ou de recuperação de desastres) está localizada numa segunda região (R2). Para a recuperação de desastres, a instância secundária em R2 sincroniza-se com a instância principal em R1 através do modo de confirmação assíncrona. O modo assíncrono é usado devido ao seu desempenho (não abranda o processamento de confirmações na instância principal).

   No diagrama anterior, a arquitetura mostra um grupo de disponibilidade. O grupo de disponibilidade, se usado com um ouvinte, fornece a mesma string de ligação aos clientes se os clientes forem publicados pelo seguinte:

   • A instância principal
   • A instância em modo de espera (após uma falha de zona)
   • A instância secundária (após uma falha da região e depois de a instância secundária se tornar a nova instância principal)

   Numa variante da arquitetura acima, implementa as duas instâncias que estão na primeira região (R1) na mesma zona. Esta abordagem pode melhorar o desempenho, mas não está altamente disponível. Pode ser necessária uma falha de zona única para iniciar o processo de DR.

   Processo básico de recuperação de desastres

   O processo de DR é iniciado quando uma região fica indisponível e a base de dados principal passa a processar noutra região operacional. O processo de DR prescreve os passos operacionais que têm de ser tomados, manual ou automaticamente, para mitigar a falha da região e estabelecer uma instância primária em execução numa região disponível.

   Um processo de recuperação de desastres (RD) de base de dados básico consiste nos seguintes passos:

   1. A primeira região (R1), que está a executar a instância da base de dados principal, fica indisponível.
   2. A equipa de operações reconhece e confirma formalmente o desastre e decide se é necessária uma comutação por falha.
   3. Se for necessária uma comutação por falha, a instância da base de dados secundária na segunda região (R2) torna-se a nova instância principal.
   4. Os clientes retomam o processamento na nova base de dados principal e acedem à instância principal no R2.

   Embora este processo básico volte a estabelecer uma base de dados principal funcional, não estabelece uma arquitetura de recuperação de desastres completa, em que a nova base de dados principal tem uma instância de base de dados secundária e de espera.

   Conclua o processo de recuperação de desastres

   Um processo de DR completo expande o processo de DR básico adicionando passos para estabelecer uma arquitetura de DR completa após uma comutação por falha. O diagrama seguinte mostra uma arquitetura de DR de base de dados completa.

   

   Figura 2. Recuperação de desastres com uma região principal indisponível (R1).

   Esta arquitetura de RD de base de dados completa funciona da seguinte forma:

   1. A primeira região (R1), que está a executar a instância da base de dados principal, fica indisponível.
   2. A equipa de operações reconhece e confirma formalmente a ocorrência de um desastre e decide se é necessária uma comutação por falha.
   3. Se for necessária uma comutação por falha, a instância da base de dados secundária na segunda região (R2) torna-se a instância principal.
   4. É criada outra instância secundária, a nova instância de reserva, e iniciada em R2 e adicionada à instância principal. A instância de espera está numa zona diferente da instância principal. A base de dados principal consiste agora em duas instâncias (principal e de reserva) de elevada disponibilidade.
   5. Numa terceira região (R3), é criada e iniciada uma nova instância de base de dados secundária (em espera). Esta instância secundária está ligada de forma assíncrona à nova instância principal no R2. Neste ponto, a arquitetura original de recuperação de desastres é recriada e fica operacional.

   Recorra a uma região recuperada

   Depois de a primeira região (R1) voltar a ficar online, pode alojar a nova base de dados secundária. Se a R1 ficar disponível em breve, pode implementar o passo 5 no processo de recuperação completo na R1 em vez da R3 (a terceira região). Neste caso, não é necessária uma terceira região.

   O diagrama seguinte mostra a arquitetura se o R1 ficar disponível a tempo.

   

   Figura 3. Recuperação de desastres após a região R1 com falhas ficar novamente disponível.

   Nesta arquitetura, os passos de recuperação são os mesmos que os descritos anteriormente no Processo de recuperação de desastres completo, com a diferença de que R1 passa a ser a localização das instâncias secundárias em vez de R3.

   Escolher uma edição do SQL Server

   Este tutorial suporta as seguintes versões do Microsoft SQL Server:

   • SQL Server 2016 Enterprise Edition
   • SQL Server 2017 Enterprise Edition
   • SQL Server 2019 Enterprise Edition
   • SQL Server 2022 Enterprise Edition

   O tutorial usa a funcionalidade AlwaysOn Availability Groups no SQL Server.

   Se não precisar de uma base de dados principal do Microsoft SQL Server de alta disponibilidade (HA) e uma única instância de base de dados for suficiente como principal, pode usar as seguintes versões do SQL Server:

   • SQL Server 2016 Standard Edition
   • SQL Server 2017 Standard Edition
   • SQL Server 2019 Standard Edition
   • SQL Server 2022 Standard Edition

   As versões de 2016, 2017, 2019 e 2022 do SQL Server têm o Microsoft SQL Server Management Studio instalado na imagem. Não precisa de o instalar separadamente. No entanto, num ambiente de produção, recomendamos que instale uma instância do Microsoft SQL Server Management Studio numa VM separada em cada região. Se configurar um ambiente de HA, deve instalar o Microsoft SQL Server Management Studio uma vez para cada zona para garantir que permanece disponível se outra zona ficar indisponível.

   Configurar o Microsoft SQL Server para DR multirregional

   Esta secção usa as seguintes imagens para o Microsoft SQL Server:

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

   Para ver uma lista completa de imagens, consulte a secção Imagens.

   Configure um cluster de alta disponibilidade de duas instâncias

   Para configurar uma arquitetura de DR de base de dados multirregional para o SQL Server, primeiro crie um cluster de alta disponibilidade (HA) de duas instâncias numa região. Uma instância serve como principal e a outra como secundária. Para concluir este passo, siga as instruções em Configurar grupos de disponibilidade AlwaysOn do SQL Server. Este tutorial usa us-central1 para a região principal (denominada R1). Antes de começar, reveja as seguintes considerações:

   • Se seguiu os passos em Configurar grupos de disponibilidade AlwaysOn do SQL Server, criou duas instâncias do SQL Server na mesma região (us-central1). Implementou a instância principal do SQL Server (node-1) em us-central1-a e uma instância de reserva (node-2) em us-central1-b.

   • Embora implemente a arquitetura na Figura 4 para este tutorial, é uma prática recomendada configurar um controlador de domínio em mais do que uma zona. Esta abordagem garante que estabelece uma arquitetura de base de dados com AD e RD. Por exemplo, se ocorrer uma indisponibilidade numa zona, essa zona não se torna um único ponto de falha para a sua arquitetura implementada.

   

   Figura 4. Arquitetura de recuperação de desastres padrão implementada neste tutorial.

   Adicione uma instância secundária para recuperação de desastres

   Em seguida, configura uma terceira instância do SQL Server (uma instância secundária com o nome node-3) e configura a rede da seguinte forma:

   1. Crie um script de especialização para os nós do cluster de tolerância a falhas do Windows Server. O script instala a funcionalidade do Windows necessária e cria regras de firewall para o WSFC e o SQL Server. Também formata o disco de dados e cria pastas de dados e registos para o SQL Server:

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

   2. Inicialize as seguintes variáveis:

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

      Onde:

      • VPC_NAME: nome da sua VPC
      • SUBNET_NAME: nome da sua sub-rede para a região us-east1

   3. Crie uma instância do SQL Server:

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

   4. Defina uma palavra-passe do Windows para a nova instância do SQL Server:

      1. Na Trusted Cloud consola, aceda à página do Compute Engine.

         Aceder ao Compute Engine

      2. Na coluna Ligar do cluster do Compute Engine node-3, selecione a lista pendente Definir palavra-passe do Windows.

      3. Defina o nome de utilizador e a palavra-passe. Anote-as para utilização posterior.

   5. Clique em RDP para estabelecer ligação à instância node-3.

   6. Introduza o nome de utilizador e a palavra-passe do passo anterior e, de seguida, clique em OK.

   7. Adicione a instância ao domínio do Windows:

      1. Clique com o botão direito do rato no botão Iniciar (ou prima Win+X) e clique em Windows PowerShell (administrador).

      2. Clique em Sim para confirmar o pedido de elevação.

      3. Associe o computador ao seu domínio do Active Directory e reinicie:

         Add-Computer -Domain DOMAIN -Restart
         

         Substitua DOMAIN pelo nome DNS do seu domínio do Active Directory.

         Aguarde aproximadamente 1 minuto para que o reinício seja concluído.

   Adicione a instância secundária ao cluster de comutação por falha

   Em seguida, adicione a instância secundária (node-3) ao cluster de comutação por falha do Windows:

   1. Ligue-se às instâncias do node-1 ou node-2 através do RDP e inicie sessão como utilizador administrador.

   2. Abra uma janela do PowerShell como utilizador administrador e defina as variáveis para o ambiente de cluster neste tutorial:

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

      Substitua SQLSRV_CLUSTER pelo nome do cluster do SQL Server.

   3. Adicione a instância secundária ao cluster:

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

      Este comando pode demorar algum tempo a ser executado. Uma vez que o processo pode deixar de responder e não regressar automaticamente, prima ocasionalmente Enter.

   4. No nó, ative a funcionalidade de alta disponibilidade AlwaysOn:

      Enable-SqlAlwaysOn -ServerInstance $node3 -Force
      

   O nó faz agora parte do cluster de comutação por falha.

   Adicione a instância secundária ao grupo de disponibilidade existente

   Em seguida, adicione a instância do SQL Server (a instância secundária) e a base de dados ao grupo de disponibilidade:

   1. Ligue-se a node-3 através do Ambiente de Trabalho Remoto. Inicie sessão com a sua conta de utilizador do domínio.

   2. Abra o Gestor de configuração do SQL Server.

   3. No painel de navegação, selecione SQL Server Services

   4. Na lista de serviços, clique com o botão direito do rato em SQL Server (MSSQLSERVER) e selecione Propriedades.

   5. Em Iniciar sessão como, altere a conta:

      • Nome da conta: DOMAIN\sql_server onde DOMAIN é o nome NetBIOS do seu domínio do Active Directory.
      • Palavra-passe: introduza a palavra-passe que escolheu anteriormente para a conta do domínio sql_server.

   6. Clique em OK.

   7. Quando lhe for pedido para reiniciar o SQL Server, selecione Sim.

   8. Em qualquer um dos três nós de instância node-1, node-2 ou node-3, abra o Microsoft SQL Server Management Studio e ligue-se à instância principal: node-1.

      1. Aceda ao Explorador de objetos.
      2. Selecione a lista pendente Associar.
      3. Selecione Motor de base de dados.
      4. Na lista pendente Nome do servidor, selecione node-1. Se o cluster não estiver listado, introduza-o no campo.

   9. Clique em Nova consulta.

   10. Cole o seguinte comando para adicionar um endereço IP ao ouvinte que é usado para o nó e, de seguida, clique em Executar:

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

       Substitua LOAD_BALANCER_IP_ADDRESS pelo endereço IP do balanceador de carga na região us-east1.

   11. No Object Explorer, expanda o nó AlwaysOn High Availability e, de seguida, expanda o nó Availability Groups.

   12. Clique com o botão direito do rato no grupo de disponibilidade denominado bookshelf-ag e, de seguida, selecione Adicionar réplica.

   13. Na página Introdução, clique no nó AlwaysOn High Availability e, de seguida, clique no nó Grupos de disponibilidade.

   14. Na página Associar a réplicas, clique em Associar para associar à réplica secundária existente node-2.

   15. Na página Specify Replicas (Especificar réplicas), clique em Add Replica (Adicionar réplica) e, de seguida, adicione o novo nó node-3. Não selecione Comutação por falha automática, porque a comutação por falha automática provoca uma confirmação síncrona. Esta configuração ultrapassa os limites regionais, o que não recomendamos.

   16. Na página Selecionar sincronização de dados, selecione Preenchimento automático.

       Como não existe nenhum ouvinte, a página Validação gera um aviso que pode ignorar.

   17. Conclua os passos do assistente.

   O modo de comutação por falha para node-1 e node-2 é automático, enquanto é manual para node-3. Esta diferença é uma forma de distinguir a alta disponibilidade da recuperação de desastres.

   O grupo de disponibilidade está agora pronto. Configurou dois nós para alta disponibilidade e um terceiro nó para recuperação de desastres.

   Simular uma recuperação de desastres

   Nesta secção, testa a arquitetura de recuperação de desastres deste tutorial e considera implementações de RD opcionais.

   Simule uma indisponibilidade e execute uma comutação por falha de recuperação de desastres

   1. Simule uma falha ou uma indisponibilidade na região principal:

      1. No Microsoft SQL Server Management Studio em node-1, estabeleça ligação a node-1.

      2. Crie uma tabela. Depois de adicionar réplicas nos passos posteriores, verifique se a réplica funciona, verificando se esta tabela está presente.

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

      3. No Cloud Shell, encerre ambos os servidores na região principal us-central1:

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

   2. No Microsoft SQL Server Management Studio no node-3, estabeleça ligação a node-3.

   3. Execute uma comutação por falha e defina o modo de disponibilidade como synchronous-commit. A imposição de uma comutação por falha é necessária porque o nó está no modo de confirmação assíncrona.

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

      Pode retomar o processamento. node-3 é agora a instância principal.

   4. (Opcional) Crie uma nova tabela em node-3. Depois de sincronizar as réplicas com a nova principal, verifique se esta tabela é replicada para as réplicas.

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

   Embora node-3 seja a região principal neste momento, é recomendável reverter para a região original ou configurar uma nova instância secundária e uma instância de espera para recriar novamente uma arquitetura de DR completa. A secção seguinte aborda estas opções.

   (Opcional) Recrie uma arquitetura de DR que replique completamente as transações

   Este exemplo de utilização aborda uma falha em que todas as transações são replicadas da base de dados principal para a secundária antes de a principal falhar. Neste cenário ideal, não são perdidos dados. O estado do secundário é consistente com o primário no ponto de falha.

   Neste cenário, pode recriar uma arquitetura de recuperação de desastres completa de duas formas:

   • Recorrer ao servidor principal original e ao servidor de reserva original (se estes estiverem disponíveis).
   • Crie um novo dispositivo em espera e secundário para o node-3 caso o dispositivo principal e em espera originais estejam indisponíveis.

   Abordagem 1: recorrer ao primário e secundário originais

   1. No Cloud Shell, inicie o servidor principal (antigo) e o servidor de reserva originais:

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

   2. No Microsoft SQL Server Management Studio, adicione novamente node-1 e node-2 como réplicas secundárias:

      1. No node-3, adicione os dois servidores no modo de confirmação assíncrona:

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

      2. No node-1, inicie novamente a sincronização das bases de dados:

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

      3. No node-2, inicie novamente a sincronização das bases de dados:

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

   3. Definir node-1 novamente como principal:

      1. Em node-3, altere o modo de disponibilidade de node-1 para synchronous-commit. A instância node-1 volta a ser a principal.

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

      2. No node-1, altere node-1 para ser o principal e os outros dois nós para serem os secundários:

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

   Depois de todos os comandos serem bem-sucedidos, node-1 é o principal e os outros nós são secundários, conforme mostrado no diagrama seguinte.

   

   Abordagem 2: configure um servidor principal e um servidor de reserva novos

   É possível que não consiga recuperar as instâncias principal e de standby originais da falha, que demore demasiado tempo a recuperá-las ou que a região esteja inacessível. Uma abordagem consiste em manter node-3 como principal e, em seguida, criar uma nova instância de espera e uma nova instância secundária, conforme mostrado no diagrama seguinte.

   

   Figura 5. Recuperação de desastres com a região principal original R1 indisponível.

   Esta implementação requer que faça o seguinte:

   • Manter node-3 como principal em us-east1.

   • Adicione uma nova instância em espera (node-4) numa zona diferente em us-east1. Este passo estabelece a nova implementação como de elevada disponibilidade.

   • Crie uma nova instância secundária (node-5) numa região separada, por exemplo, us-west2. Este passo configura a nova implementação para recuperação de desastres. A implementação geral está agora concluída. A arquitetura da base de dados suporta totalmente a AD e a RD.

   (Opcional) Execute uma alternativa quando faltarem transações

   Uma falha menos ideal ocorre quando uma ou mais transações confirmadas no servidor principal não são replicadas para o servidor secundário no ponto de falha (também conhecido como falha grave). Numa comutação por falha, todas as transações confirmadas que não foram replicadas são perdidas.

   Para testar os passos de comutação por falha para este cenário, tem de gerar uma falha grave. A melhor abordagem para gerar uma falha grave é a seguinte:

   • Altere a rede para que não haja conectividade entre as instâncias principal e secundária.
   • Altere o elemento principal de alguma forma, por exemplo, adicionando uma tabela ou inserindo alguns dados.
   • Siga o processo de comutação por falha descrito anteriormente para que o servidor secundário se torne o novo servidor principal.

   Os passos do processo de alternativa são idênticos aos do cenário ideal, exceto que a tabela adicionada ao principal após a interrupção da conetividade de rede não é visível no secundário.

   A única opção para lidar com uma falha grave é remover as réplicas (node-1 e node-2) do grupo de disponibilidade e sincronizar as réplicas novamente. A sincronização altera o estado para corresponder ao dispositivo secundário. Qualquer transação que não tenha sido replicada antes da falha é perdida.

   Para adicionar node-1 como uma instância secundária, pode seguir os mesmos passos para adicionar node-3 anteriormente (consulte Adicione a instância secundária ao cluster de comutação por falha anteriormente) com a seguinte diferença: node-3 é agora a instância principal e não node-1. Tem de substituir qualquer instância de node-3 pelo nome do servidor que adiciona ao grupo de disponibilidade. Se reutilizar a mesma VM (node-1 e node-2), não precisa de adicionar o servidor ao cluster de failover do Windows Server. Basta adicionar novamente a instância do SQL Server ao grupo de disponibilidade.

   Neste ponto, node-3 é o principal e node-1 e node-2 são secundários. Agora, é possível voltar a usar o node-1, tornar o node-2 o dispositivo em espera e tornar o node-3 o dispositivo secundário. O sistema tem agora o mesmo estado que tinha antes da falha.

   Failover automático

   A comutação automática para uma instância secundária como principal pode criar problemas. Depois de o servidor principal original voltar a ficar disponível, pode ocorrer uma situação de divisão de cérebros se alguns clientes acederem ao servidor secundário enquanto outros escrevem no servidor principal restaurado. Neste caso, é possível que o primário e o secundário sejam atualizados em paralelo e os respetivos estados divergem. Para evitar esta situação, este tutorial fornece instruções para uma comutação por falha manual em que decide se (ou quando) fazer a comutação por falha.

   Se implementar uma comutação por falha automática, tem de garantir que apenas uma das instâncias configuradas é a principal e pode ser modificada. Qualquer instância em espera ou secundária não pode fornecer acesso de escrita a nenhum cliente (exceto à primária para replicação de estado). Além disso, tem de evitar uma cadeia rápida de alternâncias subsequentes num curto período de tempo. Por exemplo, uma comutação por falha a cada cinco minutos não seria uma estratégia de recuperação de desastres fiável. Para processos de comutação por falha automáticos, pode criar salvaguardas contra cenários problemáticos, como os seguintes, e até envolver um administrador da base de dados para decisões complexas, se necessário.

   Arquitetura de implementação alternativa

   Este tutorial configura uma arquitetura de recuperação de desastres com uma instância secundária que se torna a instância principal numa comutação por falha, conforme mostrado no diagrama seguinte.

   

   Figura 6. Arquitetura de recuperação de desastres padrão com o Microsoft SQL Server.

   Isto significa que, em caso de comutação por falha, a implementação resultante tem uma única instância até ser possível uma alternativa ou até configurar uma instância em espera (para HA) e uma instância secundária (para DR).

   Uma arquitetura de implementação alternativa consiste em configurar duas instâncias secundárias. Ambas as instâncias são réplicas da principal. Se ocorrer uma comutação por falha, pode reconfigurar um dos servidores secundários como um servidor em espera. Os diagramas seguintes mostram a arquitetura de implementação antes e depois de uma comutação por falha.

   

   Figura 7. Arquitetura de recuperação de desastres padrão com duas instâncias secundárias.

   

   Figura 8. Arquitetura de recuperação de desastres padrão com duas instâncias secundárias após a comutação por falha.

   Embora ainda tenha de tornar um dos secundários um standby (Figura 8), este processo é muito mais rápido do que criar e configurar um novo standby de raiz.

   Também pode resolver a DR com uma configuração análoga a esta arquitetura de utilização de duas instâncias secundárias. Além de ter duas bases de dados secundárias numa segunda região (Figura 7), pode implementar mais duas bases de dados secundárias numa terceira região. Esta configuração permite-lhe criar de forma eficiente uma arquitetura de implementação com HA e DR após uma falha da região principal.

   Limpar

   Para evitar incorrer em custos na sua conta do Trusted Cloud pelos recursos usados neste tutorial:

   Elimine o projeto

   1. In the Trusted Cloud console, go to the Manage resources page.

      Go to Manage resources

   2. In the project list, select the project that you want to delete, and then click Delete.
   3. In the dialog, type the project ID, and then click Shut down to delete the project.

   O que se segue?

   • Explore arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.