Este tutorial descreve como ativar a replicação assíncrona equilibrada do Hyperdisk em duas Google Cloud regiões como solução de recuperação de desastres (RD) e como ativar as instâncias de RD em caso de desastre.
As instâncias de cluster de comutação por falha do Microsoft SQL Server (FCI) são uma única instância do SQL Server de elevada disponibilidade implementada em vários nós do cluster de comutação por falha do Windows Server (WSFC). Em qualquer altura, um dos nós do cluster aloja ativamente a instância SQL. Em caso de indisponibilidade zonal ou problema de VM, o WSFC transfere automaticamente a propriedade dos recursos da instância para outro nó no cluster, permitindo que os clientes se voltem a ligar. O FCI do SQL Server requer que os dados estejam localizados em discos partilhados para que possam ser acedidos em todos os nós do WSFC.
Para garantir que a implementação do SQL Server consegue resistir a uma interrupção regional, replique os dados do disco da região principal para uma região secundária ativando a replicação assíncrona. Este tutorial usa discos de gravação múltipla de alta disponibilidade equilibrados do Hyperdisk para ativar a replicação assíncrona em duas Google Cloud regiões como solução de recuperação de desastres (RD) para o FCI do SQL Server e como ativar as instâncias de RD em caso de desastre. Neste documento, um desastre é um evento em que um cluster de base de dados principal falha ou fica indisponível porque a região do cluster fica indisponível, talvez devido a um desastre natural.
Este tutorial destina-se a arquitetos, administradores e engenheiros de bases de dados.
Objetivos
- Ativar a replicação assíncrona do Hyperdisk para todos os nós do cluster FCI do SQL Server em execução no Google Cloud.
- Simule um evento de desastre e execute um processo de DR completo para validar a configuração de DR.
Custos
Neste documento, usa os seguintes componentes faturáveis do Google Cloud:
Para gerar uma estimativa de custos com base na sua utilização projetada,
use a calculadora de preços.
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 Google Cloud projeto. Pode criar um novo ou selecionar um projeto que já criou:
-
In the Google Cloud console, on the project selector page, select or create a Google 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 theresourcemanager.projects.createpermission. Learn how to grant roles.
-
Verify that billing is enabled for your Google Cloud project.
-
In the Google Cloud console, activate Cloud Shell.
Configure o cluster do SQL Server na região principal seguindo os passos neste guia de configuração de um cluster FCI do SQL Server com o modo de gravação múltipla de alta disponibilidade equilibrada do Hyperdisk. Depois de configurar o cluster, regresse a este tutorial para ativar a DR na região secundária.
Autorizações adequadas no seu projeto do Google Cloud e no SQL Server para fazer cópias de segurança e restaurar.
- Duas instâncias do Microsoft SQL Server, uma instância principal e uma instância de reserva, fazem parte de um cluster de FCI e estão localizadas na região principal (R1), mas em zonas diferentes (zonas A e B). Ambas as instâncias partilham um disco de alta disponibilidade equilibrado do Hyperdisk, o que permite o acesso aos dados a partir de ambas as VMs. Para obter instruções, consulte o artigo Configurar um cluster FCI do SQL Server com o modo de gravação múltipla de alta disponibilidade equilibrada do Hyperdisk
- Os discos de ambos os nós SQL são adicionados a grupos de consistência e replicados para a região de recuperação de desastres, R2. O Compute Engine replica os dados de forma assíncrona de R1 para R2.
- A replicação assíncrona apenas replica os dados nos discos para o R2 e não replica os metadados da VM. Durante a recuperação de desastres, são criadas novas VMs e os discos replicados existentes são anexados às VMs para colocar os nós online.
- A primeira região (R1), que está a executar a instância da base de dados principal, fica indisponível.
- A equipa de operações reconhece e confirma formalmente o desastre e decide se é necessária uma comutação por falha.
- Se for necessária uma comutação por falha, tem de terminar a replicação entre os discos primário e secundário. É criada uma nova VM a partir das réplicas do disco e é colocada online.
- A base de dados na região de DR, R2, é validada e colocada online. A base de dados em R2 torna-se a nova base de dados principal que permite a conetividade.
- Os utilizadores retomam o processamento na nova base de dados principal e acedem à instância principal no R2.
- SQL Server 2016 Enterprise e Standard Edition
- SQL Server 2017 Enterprise e Standard Edition
- SQL Server 2019 Enterprise e Standard Edition
- SQL Server 2022 Enterprise e Standard Edition
Crie um grupo de consistência para os nós do SQL Server e o nó que aloja as funções de testemunha e controlador de domínio. Uma das limitações dos grupos de consistência é que não podem abranger várias zonas, pelo que tem de adicionar cada nó a um grupo de consistência separado.
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 gcloud compute resource-policies create disk-consistency-group multiwriter-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-2 \ --zone=$REGION-b \ --resource-policies=node-2-disk-const-grp gcloud compute disks add-resource-policies mw-datadisk-1 \ --region=$REGION \ --resource-policies=multiwriter-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 secundária.
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-2-replica \ --zone=$DR_REGION-b \ --size=50 \ --primary-disk=node-2 \ --primary-disk-zone=$REGION-b gcloud compute disks create multiwriter-datadisk-1-replica \ --replica-zones=$DR_REGION-a,$DR_REGION-b \ --size=$PD_SIZE \ --type=hyperdisk-balanced-high-availability \ --access-mode READ_WRITE_MANY \ --primary-disk=multiwriter-datadisk-1 \ --primary-disk-region=$REGION 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 criado recentemente na região de recuperação de desastres.
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-2 \ --zone=$REGION-b \ --secondary-disk=node-2-replica \ --secondary-disk-zone=$DR_REGION-b gcloud compute disks start-async-replication multiwriter-datadisk-1 \ --region=$REGION \ --secondary-disk=multiwriter-datadisk-1-replica \ --secondary-disk-region=$DR_REGION gcloud compute disks start-async-replication witness \ --zone=$REGION-c \ --secondary-disk=witness-replica \ --secondary-disk-zone=$DR_REGION-c
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
Terminar ou parar 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/multiwriter-disk-const-grp \ --zone=$REGION-c 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
Mude o nome das VMs existentes para evitar nomes duplicados no projeto.
gcloud compute instances set-name witness \ --new-name=witness-old \ --zone=$REGION-c gcloud compute instances set-name node-1 \ --new-name=node-1-old \ --zone=$REGION-a gcloud compute instances set-name node-2 \ --new-name=node-2-old \ --zone=$REGION-b
Crie VMs na região de RD com os discos secundários. Estas VMs têm o endereço IP da VM de origem.
NODE1IP=$(gcloud compute instances describe node-1-old --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\)) NODE2IP=$(gcloud compute instances describe node-2-old --zone $REGION-b --format=value\(networkInterfaces[0].networkIP\)) WITNESSIP=$(gcloud compute instances describe witness-old --zone $REGION-c --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=boot=no,device-name=mw-datadisk-1-replica,mode=rw,name=mw-datadisk-1-replica,scope=regional 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 gcloud compute instances create node-2 \ --zone=$DR_REGION-b \ --machine-type $MACHINE_TYPE \ --network=$DRVPC_NAME \ --subnet=$DRSUBNET_NAME \ --private-network-ip $NODE2IP\ --disk=boot=yes,device-name=node-2-replica,mode=rw,name=node-2-replica \ --disk=boot=no,device-name=mw-datadisk-1-replica,mode=rw,name=mw-datadisk-1-replica,scope=regional
- Estabeleça ligação à VM do SQL Server através do Ambiente de Trabalho Remoto.
- Abra o SQL Server Management Studio.
- Na caixa de diálogo Ligar ao servidor, verifique se o nome do servidor está definido como
node-1e selecione Ligar. No menu Ficheiro, selecione Ficheiro > Novo > Consulta com a ligação atual.
USE [bookshelf]; SELECT * FROM Books;
- 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.
- Explore arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.
Recuperação de desastres em Google Cloud
A DR envolve a manutenção do acesso contínuo aos dados quando uma região falha ou se torna inacessível. Google Cloud Existem várias opções de implementação para o site de recuperação de desastres, que são ditadas pelos requisitos do objetivo de ponto de recuperação (RPO) e do objetivo de tempo de recuperação (RTO). Este tutorial aborda uma das opções em que os discos associados à máquina virtual são replicados da região principal para a região de recuperação de desastres.
Recuperação de desastres com a replicação assíncrona do Hyperdisk
A replicação assíncrona do Hyperdisk é uma opção de armazenamento que oferece uma cópia de armazenamento assíncrona para a replicação de discos entre duas regiões. No caso improvável de uma interrupção regional, a replicação assíncrona do Hyperdisk permite-lhe fazer failover dos seus dados para uma região secundária e reiniciar as suas cargas de trabalho nessa região.
A replicação assíncrona do Hyperdisk replica dados de um disco anexado a uma carga de trabalho em execução, denominado disco principal, para um disco separado localizado noutra região. O disco que recebe a replicação é denominado disco secundário. A região onde o disco principal está em execução é denominada região principal, e a região onde o disco secundário está em execução é a região secundária. Para garantir que as réplicas de todos os discos anexados a cada nó do SQL Server contêm dados do mesmo ponto no tempo, os discos são adicionados a um grupo de consistência. Os grupos de consistência permitem-lhe realizar testes de DR e DR em vários discos.
Arquitetura de recuperação de desastres
Para a replicação assíncrona do Hyperdisk, o diagrama seguinte mostra uma arquitetura mínima que suporta a HA da base de dados numa região principal, R1, e a replicação de discos da região principal para a região secundária, R2.
Figura 1. Arquitetura de recuperação de desastres com o Microsoft SQL Server e a replicação assíncrona do Hyperdisk
Esta arquitetura funciona da seguinte forma:
Processo de recuperação de desastres
O processo de recuperação de desastres prescreve os passos operacionais que tem de realizar depois de uma região ficar indisponível para retomar a carga de trabalho noutra região.
Um processo de recuperação de desastres (RD) de base de dados básico consiste nos seguintes passos:
Embora este processo básico estabeleça novamente uma base de dados principal funcional, não estabelece uma arquitetura de HA completa, porque a nova base de dados principal não está a ser replicada.
Figura 2. Implementação do SQL Server após a recuperação de desastres com replicação assíncrona do disco persistente
Recorra a uma região recuperada
Quando a região principal (R1) estiver novamente online, pode planear e executar o processo de reversão. O processo de reversão consiste em todos os passos descritos 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 suporta as seguintes versões do Microsoft SQL Server:
O tutorial usa a instância de cluster de failover do SQL Server com o disco de alta disponibilidade equilibrado do Hyperdisk.
Se não precisar das funcionalidades do SQL Server Enterprise, pode usar a edição Standard do SQL Server:
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.
Configure a recuperação de desastres para o Microsoft SQL Server
Este tutorial usa a imagem
sql-ent-2022-win-2022para o Microsoft SQL Server Enterprise.Para ver uma lista completa de imagens, consulte o artigo Imagens do SO.
Configure um cluster de alta disponibilidade de duas instâncias
Para configurar a replicação de discos para o SQL Server entre duas regiões, primeiro crie um cluster de alta disponibilidade de duas instâncias numa região. Uma instância funciona como principal e a outra como suplente. Para concluir este passo, siga as instruções em Configurar um cluster de FCI do SQL Server com o modo de gravação múltipla de alta disponibilidade equilibrado do Hyperdisk. Este tutorial usa
us-central1para a região principal R1. Se seguiu os passos em Configurar um cluster de FCI do SQL Server com o modo de gravação múltipla de alta disponibilidade equilibrada do Hyperdisk, criou duas instâncias do SQL Server na mesma região (us-central1). Implementou uma instância principal do SQL Server (node-1) emus-central1-ae uma instância de reserva (node-2) emus-central1-b.Ative a replicação assíncrona de disco
Depois de criar e configurar todas as VMs, ative a replicação de discos entre as duas regiões através dos seguintes passos:
Neste momento, os dados devem estar a ser replicados entre regiões. O estado da replicação de cada disco deve indicar
Active.Simule uma recuperação de desastres
Nesta secção, testa a arquitetura de recuperação de desastres configurada neste tutorial.
Simule uma indisponibilidade e execute uma comutação por falha de recuperação de desastres
Durante uma comutação por falha, cria novas VMs na região de recuperação de desastres e anexa os discos replicados às mesmas. Para simplificar a comutação por falha, pode usar uma nuvem virtual privada (VPC) diferente na região de recuperação de desastres para a recuperação, de modo a poder usar o mesmo endereço IP.
Antes de iniciar a comutação por falha, certifique-se de que
node-1é o nó principal do grupo de disponibilidade AlwaysOn que criou. Apresente o controlador de domínio e o nó do SQL Server principal para evitar problemas de sincronização de dados, uma vez que os dois nós estão protegidos por dois grupos de consistência separados. Para simular uma indisponibilidade, siga estes passos:Simulou uma indisponibilidade e fez failover para a região de recuperação de desastres. Agora, pode testar se a instância secundária está a funcionar corretamente.
Valide a conetividade do SQL Server
Depois de criar as VMs, verifique se as bases de dados foram recuperadas com êxito e se o servidor está a funcionar conforme esperado. Para testar a base de dados, execute uma consulta a partir da base de dados recuperada.
Limpar
Para evitar incorrer em custos na sua Google Cloud conta pelos recursos usados neste tutorial, siga os passos nesta secção para eliminar os recursos que criou.
Elimine o projeto
O que se segue?
-