Este tutorial descreve como ativar a replicação assíncrona do disco permanente (PD Async Replication) em duas regiões do Google Cloud como uma solução de recuperação de desastres (DR) e como criar instâncias de DR no caso de um desastre. Para os fins deste documento, um desastre é um evento em que um cluster de alta disponibilidade (HA, na sigla em inglês) do banco de dados primário falha ou se torna indisponível. Um banco de dados primário pode falhar quando a região onde ele está localizado falha ou fica inacessível.
Este tutorial se destina a arquitetos de bancos de dados, administradores e engenheiros.
Objetivos
- Ativar a replicação assíncrona de disco permanente para todos os nós do cluster do grupo de disponibilidade AlwaysOn do SQL Server em execução no Google Cloud.
- Simular um evento de desastre e executar um processo de recuperação de desastre completo para validar a configuração de recuperação de desastres.
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.
Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.
Antes de começar
Para este tutorial, você precisa de um projeto do Google Cloud. É possível criar um novo projeto ou selecionar um projeto que já foi criado:
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
In the Google Cloud console, activate Cloud Shell.
Recuperação de desastres no Google Cloud
No Google Cloud, DR significa fornecer continuidade de processamento, especialmente quando uma região falha ou se torna inacessível. Há várias opções de implantação para o site de DR e elas serão determinadas pelos requisitos do objetivo do ponto de recuperação (RPO) e do objetivo do tempo de recuperação (RTO). Este tutorial aborda uma das opções em que os discos de máquina virtual (VM) são replicados da região principal para a região de DR.
Recuperação de desastres para replicação assíncrona do disco permanente
A replicação assíncrona do disco permanente (PD Async Replication) fornece replicação de armazenamento em blocos com RPO e RTO baixos para DR ativa-passiva entre regiões.
A replicação assíncrona de DPs é uma opção de armazenamento que oferece replicação assíncrona de dados entre duas regiões. No caso improvável de uma interrupção de serviço regional, a replicação assíncrona de DPs permite realizar failover dos dados para uma região secundária e reiniciar as cargas de trabalho nessa região.
A replicação assíncrona de DP replica dados de um disco que está conectado a uma carga de trabalho em execução conhecida como disco principal, até um disco separado localizado em outra região. O disco que recebe os dados replicados é chamado de disco secundário.
Para garantir que as réplicas de todos os discos conectados a cada nó do SQL Server tenham dados do mesmo ponto no tempo, os discos são adicionados a um grupo de consistência. Os grupos de consistência permitem realizar DR e testes de DR em vários discos.
Arquitetura de recuperação de desastres
Para replicação assíncrona de DP, o diagrama a seguir mostra uma arquitetura mínima que suporta alta disponibilidade do banco de dados em uma região primária e replicação de disco a partir da região primária até a região de DR.
Figura 1. Arquitetura de recuperação de desastres com o Microsoft SQL Server e a Replicação assíncrona de DPs
Essa arquitetura funciona da seguinte forma:
- Duas instâncias do Microsoft SQL Server, uma primária e uma de espera, fazem parte de um grupo de disponibilidade e estão na mesma região (R1), mas em zonas diferentes (zonas A e B). As duas instâncias na R1 coordenam os estados usando o modo de confirmação síncrona. O modo síncrono é usado porque aceita alta disponibilidade e mantém um estado de dados consistente.
- Os discos dos dois nós SQL são adicionados aos grupos de consistência e replicados para a região R2 da DR. Os dados são replicados de forma assíncrona pela infraestrutura subjacente.
- Somente os discos são replicados para a região R2. Durante a DR, novas VMs são criadas e os discos replicados existentes são conectados às VMs para colocar os nós on-line.
Processo de recuperação de desastres
O processo de DR começa quando uma região fica indisponível. O processo de DR determina as etapas operacionais que precisam ser executadas, manual ou automaticamente, para reduzir a falha da região e estabelecer uma instância primária em execução em uma região disponível.
Um processo básico de DR do banco de dados consiste nas seguintes etapas:
- A primeira região (R1), que está executando a instância primária do banco de dados, fica indisponível.
- A equipe de operações reconhece e confirma formalmente o desastre e decide se um failover é necessário.
- Se for necessário um failover, a replicação do disco da região primária para a de DR será encerrada. Uma nova VM é criada a partir das réplicas do disco e colocada on-line.
- O novo banco de dados principal na região de DR (R2) é validado e colocado on-line, permitindo a conectividade.
- Os usuários retomam o processamento no novo banco de dados primário e acessam a instância primária na R2.
Embora esse processo básico estabeleça um banco de dados principal de trabalho novamente, ele não estabelece uma arquitetura de alta disponibilidade completa, em que o novo primário tem um nó de espera.
Figura 2. Implantação do SQL Server após a recuperação de desastres com a replicação assíncrona de disco permanente
Substituto para uma região recuperada
Quando a região primária (R1) voltar a ficar on-line, você poderá planejar e executar o processo de fail-back. O processo de failback consiste em todas as etapas descritas neste tutorial; mas, neste caso, R2 é a origem e R1 é a região de recuperação.
Escolha uma edição do SQL Server
Este tutorial considera 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 o recurso de grupos de disponibilidade AlwaysOn no SQL Server.
Se você não precisar de um banco de dados primário do Microsoft SQL Server com alta disponibilidade e uma única instância de banco de dados primária for suficiente, use 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 2016, 2017, 2019 e 2022 do SQL Server têm o Microsoft SQL Server Management Studio instalado na imagem. Você não precisa instalá-lo separadamente. No entanto, em um ambiente de produção, recomendamos instalar uma instância do Microsoft SQL Server Management Studio em uma VM separada em cada região. Se você configurar um ambiente de alta disponibilidade, convém instalar o Microsoft SQL Server Management Studio uma vez em cada zona para garantir que ele continue disponível se outra zona ficar indisponível.
Configurar a recuperação de desastres no Microsoft SQL Server
Este tutorial usa a imagem sql-ent-2022-win-2022 para o Microsoft SQL Server
Enterprise.
Para obter uma lista completa de imagens, consulte Imagens do SO.
Configurar um cluster de alta disponibilidade de duas instâncias
Para configurar a replicação de disco para a região de DR do SQL Server, primeiro
crie um cluster de alta disponibilidade de duas instâncias em uma região.
Uma instância serve como primária e a outra como de espera. Para realizar esta etapa, siga as instruções em
Como configurar os grupos de disponibilidade SQL Server AlwaysOn.
Neste tutorial, usamos us-central1 para a região primária (chamada de R1).
Se seguiu as etapas em
Como configurar os grupos de disponibilidade SQL Server AlwaysOn,
você terá criado duas instâncias SQL Server na mesma região (us-central1). Você implantou uma instância primária do SQL Server (node-1) in
us-central1-a e uma instâncias de espera (node-2) in us-central1-b.
Ativar a replicação assíncrona de disco
Depois de criar e configurar todas as VMs, ative a cópia de disco entre as regiões criando grupos de consistência para todos os discos conectados às VMs. Os dados foram copiados de discos de origem para discos em branco recém-criados na região designada.
Crie um grupo de consistência para nós de SQL e o controlador de domínio. Uma das limitações para um disco zonal é que os grupos de consistência não podem ultrapassar zonas.
gcloud compute resource-policies create disk-consistency-group node-1-disk-const-grp \ --region=$REGION gcloud compute resource-policies create disk-consistency-group node-2-disk-const-grp \ --region=$REGION gcloud compute resource-policies create disk-consistency-group witness-disk-const-grp \ --region=$REGION
Adicione os discos das VMs primárias e de espera aos grupos de consistência correspondentes.
gcloud compute disks add-resource-policies node-1 \ --zone=$REGION-a \ --resource-policies=node-1-disk-const-grp gcloud compute disks add-resource-policies node-1-datadisk \ --zone=$REGION-a \ --resource-policies=node-1-disk-const-grp gcloud compute disks add-resource-policies node-2 \ --zone=$REGION-b \ --resource-policies=node-2-disk-const-grp gcloud compute disks add-resource-policies node-2-datadisk \ --zone=$REGION-b \ --resource-policies=node-2-disk-const-grp gcloud compute disks add-resource-policies witness \ --zone=$REGION-c \ --resource-policies=witness-disk-const-grp
Crie discos secundários em branco na região pareada.
DR_REGION="us-west1" gcloud compute disks create node-1-replica \ --zone=$DR_REGION-a \ --size=50 \ --primary-disk=node-1 \ --primary-disk-zone=$REGION-a gcloud compute disks create node-1-datadisk-replica \ --zone=$DR_REGION-a \ --size=$PD_SIZE \ --primary-disk=node-1-datadisk \ --primary-disk-zone=$REGION-a gcloud compute disks create node-2-replica \ --zone=$DR_REGION-b \ --size=50 \ --primary-disk=node-2 \ --primary-disk-zone=$REGION-b gcloud compute disks create node-2-datadisk-replica \ --zone=$DR_REGION-b \ --size=$PD_SIZE \ --primary-disk=node-2-datadisk \ --primary-disk-zone=$REGION-b gcloud compute disks create witness-replica \ --zone=$DR_REGION-c \ --size=50 \ --primary-disk=witness \ --primary-disk-zone=$REGION-c
Inicie a replicação do disco. Os dados são replicados do disco principal para o disco em branco recém-criado na região de DR.
gcloud compute disks start-async-replication node-1 \ --zone=$REGION-a \ --secondary-disk=node-1-replica \ --secondary-disk-zone=$DR_REGION-a gcloud compute disks start-async-replication node-1-datadisk \ --zone=$REGION-a \ --secondary-disk=node-1-datadisk-replica \ --secondary-disk-zone=$DR_REGION-a gcloud compute disks start-async-replication node-2 \ --zone=$REGION-b \ --secondary-disk=node-2-replica \ --secondary-disk-zone=$DR_REGION-b gcloud compute disks start-async-replication node-2-datadisk \ --zone=$REGION-b \ --secondary-disk=node-2-datadisk-replica \ --secondary-disk-zone=$DR_REGION-b gcloud compute disks start-async-replication witness \ --zone=$REGION-c \ --secondary-disk=witness-replica \ --secondary-disk-zone=$DR_REGION-c
Os dados devem estar sendo replicados entre regiões neste ponto.
O status de replicação de cada disco precisa indicar Active.
Simular uma recuperação de desastres
Nesta seção, você vai testar a arquitetura de recuperação de desastres configurada neste tutorial.
Simular uma interrupção de serviço e executar um failover de recuperação de desastres
Durante um failover de DR, você cria novas VMs na região de DR e conecta os discos replicados a eles. Para simplificar o failover, você pode usar uma nuvem privada virtual (VPC) diferente na região de DR para a recuperação a fim de que o mesmo endereço IP seja usado.
Antes de iniciar o failover, verifique se node-1 é o nó principal do
grupo de disponibilidade AlwaysOn que você criou. Ative o controlador de domínio e o
nó principal do SQL Server para evitar problemas de sincronização de dados, uma vez que os dois nós são protegidos por dois grupos de consistência separados.
Para simular uma interrupção do serviço, siga estas etapas:
Crie uma VPC de recuperação.
DRVPC_NAME="default-dr" DRSUBNET_NAME="default-recovery" gcloud compute networks create $DRVPC_NAME \ --subnet-mode=custom CIDR = $(gcloud compute networks subnets describe default \ --region=$REGION --format=value\(ipCidrRange\)) gcloud compute networks subnets create $DRSUBNET_NAME \ --network=$DRVPC_NAME --range=$CIDR --region=$DR_REGION
Encerre a replicação de dados.
PROJECT=$(gcloud config get-value project) gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/node-1-disk-const-grp \ --zone=$REGION-a gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/node-2-disk-const-grp \ --zone=$REGION-b gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/witness-disk-const-grp \ --zone=$REGION-c
Pare as VMs de origem na região principal.
gcloud compute instances stop node-1 \ --zone=$REGION-a gcloud compute instances stop node-2 \ --zone=$REGION-b gcloud compute instances stop witness \ --zone=$REGION-c
Crie VMs na região de DR usando réplicas de disco. Essas VMs terão o endereço IP da VM de origem.
NODE1IP=$(gcloud compute instances describe node-1 --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\)) NODE2IP=$(gcloud compute instances describe node-2 --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\)) WITNESSIP=$(gcloud compute instances describe witness --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\)) gcloud compute instances create node-1 \ --zone=$DR_REGION-a \ --machine-type $MACHINE_TYPE \ --network=$DRVPC_NAME \ --subnet=$DRSUBNET_NAME \ --private-network-ip $NODE1IP\ --disk=boot=yes,device-name=node-1-replica,mode=rw,name=node-1-replica \ --disk=auto-delete=yes,boot=no,device-name=node-1-datadisk-replica,mode=rw,name=node-1-datadisk-replica gcloud compute instances create witness \ --zone=$DR_REGION-c \ --machine-type=n2-standard-2 \ --network=$DRVPC_NAME \ --subnet=$DRSUBNET_NAME \ --private-network-ip $WITNESSIP \ --disk=boot=yes,device-name=witness-replica,mode=rw,name=witness-replica
Simulamos uma interrupção de serviço e realizamos failover para a região de DR. Agora podemos testar se a instância secundária está funcionando corretamente ou não.
Verifique a conectividade do SQL Server
Depois que as VMs forem criadas, verifique se os bancos de dados foram recuperados com sucesso e se o servidor está funcionando conforme o esperado. Para testar o banco de dados, você executará uma consulta de seleção do banco de dados recuperado.
- Conecte-se à VM do SQL Server usando a Área de trabalho remota.
- Abra o SQL Server Management Studio.
- Na caixa de diálogo Conectar-se ao servidor, verifique se o nome do servidor está definido para
NODE-1e selecione Conectar. No menu de arquivos, selecione Arquivo > Novo > Consulta com a conexão atual.
USE [bookshelf]; SELECT * FROM Books;
Limpar
Para evitar cobranças dos recursos usados neste tutorial na conta do Google Cloud, siga estas etapas:
Excluir o projeto
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
A seguir
- Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.