Configurar a recuperação de desastres para o SQL Server

Artigo
04/03/2023

Este artigo descreve como ajudar a proteger o back-end do SQL Server de um aplicativo. Faça isso usando uma combinação de tecnologias de BCDR (continuidade dos negócios e recuperação de desastres) do SQL Server e o Azure Site Recovery.

Antes de começar, você precisa entender as funcionalidades de recuperação de desastre do SQL Server. Esses recursos incluem:

Clustering de failover
Grupos de disponibilidade AlwaysOn
Espelhamento de banco de dados
Envio de logs
Replicação geográfica ativa
Grupos de failover automático

Combinando tecnologias de BCDR com o Site Recovery

Sua escolha de uma tecnologia de BCDR para recuperar instâncias do SQL Server deve ser baseada em suas necessidades de RTO (objetivo de tempo de recuperação) e RPO (objetivo de ponto de recuperação), conforme descrito na tabela a seguir. Combine o Site Recovery com a operação de failover da tecnologia de sua escolha para orquestrar a recuperação de todo o aplicativo.

Tipo de implantação	Tecnologia de BCDR	RTO esperado para o SQL Server	RPO esperado para o SQL Server
SQL Server em uma VM (máquina virtual) de IaaS (infraestrutura como serviço) do Azure ou no local.	Grupo de disponibilidade Sempre Ativo	O tempo necessário para transformar a réplica secundária em primária.	Como a replicação para a réplica secundária é assíncrona, há alguma perda de dados.
SQL Server em uma VM de IaaS do Azure ou no local.	Clustering de failover (FCI AlwaysOn)	O tempo necessário para fazer failover entre os nós.	Como a FCI do Always On usa armazenamento compartilhado, a mesma exibição da instância de armazenamento está disponível no failover.
SQL Server em uma VM de IaaS do Azure ou no local.	Espelhamento de banco de dados (modo de alto desempenho)	O tempo necessário para forçar o serviço, que usa o servidor espelho como um servidor em espera passiva.	A replicação é assíncrona. O banco de dados espelho pode ficar um pouco defasado em relação ao banco de dados principal. Normalmente, o retardo é pequeno. Mas ele poderá ficar grande se o sistema do servidor espelho ou a entidade de segurança estiver sob uma carga pesada. O envio de logs pode ser um suplemento ao espelhamento de banco de dados. Trata-se de uma alternativa favorável ao espelhamento de banco de dados assíncrono.
SQL como PaaS (plataforma como serviço) no Azure. Esse tipo de implantação inclui bancos de dados individuais e pools elásticos.	Replicação geográfica ativa	Trinta segundos após o failover ser acionado. Quando o failover é ativado para um dos bancos de dados secundários, todos os outros secundários são vinculados automaticamente ao novo primário.	RPO de cinco segundos. A replicação geográfica ativa usa a tecnologia Always On do SQL Server. Ele replica de maneira assíncrona as transações confirmadas no banco de dados primário para um banco de dados secundário usando o isolamento de instantâneo. Há a garantia de que os dados secundários nunca terão transações parciais.
SQL como PaaS configurado com replicação geográfica ativa no Azure. Esse tipo de implantação inclui instâncias gerenciadas, pools elásticos e bancos de dados individuais.	Grupos de failover automático	RTO de uma hora.	RPO de cinco segundos. Os grupos de failover automático fornecem semântica de grupo sobre a replicação geográfica ativa. No entanto, o mesmo mecanismo de replicação assíncrona é usado.
SQL Server em uma VM de IaaS do Azure ou no local.	Replicação com o Azure Site Recovery	Normalmente, o RTO é de menos de 15 minutos. Para saber mais, leia o SLA de RTO fornecido pelo Site Recovery.	Uma hora para consistência do aplicativo e cinco minutos para consistência de falhas. Se estiver procurando um RPO mais baixo, use outras tecnologias de BCDR.

Observação

Algumas considerações importantes quando você está ajudando a proteger cargas de trabalho SQL com o Site Recovery:

O Site Recovery é independente do aplicativo. O Site Recovery pode ajudar a proteger qualquer versão do SQL Server implantada em um sistema operacional com suporte. Para saber mais, confira a matriz de suporte para recuperação de computadores replicados.
Você pode optar por usar o Site Recovery para qualquer implantação no Azure, no Hyper-V, no VMware ou em uma infraestrutura física. Siga as diretrizes no final deste artigo sobre como ajudar a proteger um cluster do SQL Server com o Site Recovery.
Verifique se a taxa de alteração de dados observada no computador está dentro dos limites do Site Recovery. A taxa de alteração é medida em bytes de gravação por segundo. Para computadores que executam o Windows, veja a taxa de alteração selecionando a guia Desempenho no Gerenciador de Tarefas. Observe a velocidade de gravação de cada disco.
O Site Recovery dá suporte à replicação de instâncias de cluster de failover nos Espaços de Armazenamento Diretos. Para saber mais, confira como habilitar a replicação dos Espaços de Armazenamento Diretos.

Ao migrar a carga de trabalho SQL para o Azure, é recomendável aplicar as Diretrizes de desempenho do SQL Server nas Máquinas Virtuais do Azure.

Recuperação de desastre de um aplicativo

O Site Recovery orquestra o failover de teste e o failover de todo o aplicativo com ajuda dos planos de recuperação.

Há alguns pré-requisitos para garantir que o plano de recuperação seja totalmente personalizado de acordo com suas necessidades. Qualquer implantação do SQL Server normalmente precisa de uma implantação do Active Directory. Ela também precisa de conectividade para a camada de aplicativo.

Etapa 1: configurar o Active Directory

Configure o Active Directory no site de recuperação secundário para que o SQL Server seja executado corretamente.

Pequena empresa: você tem alguns aplicativos e apenas um controlador de domínio para o site local. Se quiser fazer failover do site inteiro, use a replicação do Site Recovery. Esse serviço replica o controlador de domínio para o datacenter secundário ou para o Azure.
Empresa média a grande: talvez seja necessário configurar controladores de domínio adicionais.
- Se você tem uma grande quantidade de aplicativos, uma floresta do Active Directory e quer fazer failover por aplicativo ou carga de trabalho, recomendamos configurar outro controlador de domínio no datacenter secundário ou no Azure.
- Se você está usando grupos de disponibilidade Always On para recuperar para um site remoto, configure outro controlador de domínio no site secundário ou no Azure. Esse controlador de domínio é usado para a instância do SQL Server recuperada.

As instruções neste artigo supõem que um controlador de domínio esteja disponível no local secundário. Para saber mais, confira os procedimentos para ajudar a proteger o Active Directory com o Site Recovery.

Etapa 2: garantir a conectividade com outras camadas

Quando a camada de banco de dados estiver em execução na região do Azure de destino, verifique se você tem conectividade com o aplicativo e com as camadas da Web. Realize com antecedência as etapas necessárias para validar a conectividade com o failover de teste.

Para saber como projetar aplicativos tendo em mente a conectividade, confira estes exemplos:

Etapa 3: interoperar com o Always On, a replicação geográfica ativa e grupos de failover automático

As tecnologias de BCDR Always On, replicação geográfica ativa e grupos de failover automático têm réplicas secundárias do SQL Server em execução na região do Azure de destino. A primeira etapa para o failover do aplicativo é especificar essa réplica como primária. Essa etapa pressupõe que você já tem um controlador de domínio no secundário. Ela pode não ser necessária quando você opta por fazer um failover automático. Faça failover de suas camadas da Web e do aplicativo somente após a conclusão do failover do banco de dados.

Observação

Se você ajudou a proteger os computadores SQL com o Site Recovery, basta criar um grupo de recuperação desses computadores e adicionar seu failover no plano de recuperação.

Crie um plano de recuperação com máquinas virtuais da camada da Web e do aplicativo. As seguintes etapas mostram como adicionar o failover da camada de banco de dados:

Importe os scripts para fazer failover do grupo de disponibilidade do SQL em uma máquina virtual do Resource Manager e uma máquina virtual clássica. Importe os scripts para sua conta da Automação do Azure.
Adicione o script ASR-SQL-FailoverAG como uma ação prévia do primeiro grupo do plano de recuperação.
Siga as instruções disponíveis no script para criar uma variável de automação. Essa variável fornece o nome dos grupos de disponibilidade.

Etapa 4: conduzir um failover de teste

Algumas tecnologias de BCDR, como o SQL Always On, não dão suporte nativo ao failover de teste. Recomendamos a abordagem a seguir somente ao usar essas tecnologias.

Configure o Backup do Azure na VM que hospeda a réplica do grupo de disponibilidade no Azure.
Antes de disparar o failover de teste do plano de recuperação, recupere a VM no backup feito na etapa anterior.
Force um quorum na VM que foi restaurada do backup.
Atualize o endereço IP do ouvinte para um endereço disponível na rede do failover de teste.
Faça o ouvinte ficar online.
Verifique se o balanceador de carga na rede de failover tem um endereço IP do pool de endereços IP de front-end que corresponde a cada ouvinte do grupo de disponibilidade e com a VM do SQL Server no pool de back-end.
Em grupos de recuperação posteriores, adicione o failover da camada de aplicativo seguido de sua camada da Web para esse plano de recuperação.
Faça um failover de teste do plano de recuperação para testar o failover de ponta a ponta do aplicativo.

Etapas para fazer um failover

Depois de adicionar o script na Etapa 3 e validá-lo na Etapa 4, você poderá fazer failover do plano de recuperação criado na Etapa 3.

As etapas de failover das camadas do aplicativo e da Web devem ser as mesmas nos planos de failover de teste e de recuperação de failover.

Como ajudar a proteger um cluster do SQL Server

Para um cluster executando o SQL Server Standard ou o SQL Server 2008 R2, recomendamos o uso da replicação do Site Recovery para ajudar a proteger o SQL Server.

Do Azure para o Azure e do local para o Azure

O Site Recovery não dá suporte a clusters convidados ao replicar para uma região do Azure. O SQL Server Standard também não oferece uma solução de recuperação de desastre de baixo custo. Nesse cenário, recomendamos que você proteja o cluster do SQL Server para uma instância do SQL Server autônomo em seu local primário e o recupere no secundário.

Configure uma instância do SQL Server autônomo adicional na região do Azure primária ou no site local.
Configure a instância para servir como um espelho para os bancos de dados que deseja ajudar a proteger. Configure o espelhamento no modo de alta segurança.
Configure o Site Recovery no site primário para servidores físicos de VMs do VMware, do Hyper-V ou do Azure.
Use a replicação do Site Recovery para replicar a nova instância do SQL Server para o site secundário. Como se trata de uma cópia espelhada de alta segurança, ela será sincronizada com o cluster primário, mas replicada usando a replicação do Site Recovery.

Considerações sobre failback

Para clusters do SQL Server Standard, o failback após um failover não planejado requer um backup e uma restauração do SQL Server. Essa operação é feita da instância de espelho para o cluster original com restabelecimento do espelho.

Perguntas frequentes

Como o SQL Server é licenciado quando usado com o Site Recovery?

A replicação do Site Recovery para o SQL Server é coberta pelo benefício de recuperação de desastre do Software Assurance. Essa cobertura se aplica a todos os cenários do Site Recovery: recuperação de desastre do local para o Azure e recuperação de desastre entre regiões do Azure IaaS. Confira Preço do Azure Site Recovery para saber mais.

O Site Recovery dá suporte à minha versão do SQL Server?

O Site Recovery é independente do aplicativo. O Site Recovery pode ajudar a proteger qualquer versão do SQL Server implantada em um sistema operacional com suporte. Para saber mais, confira a matriz de suporte para recuperação de computadores replicados.

O ASR funciona com a Replicação transacional do SQL?

Devido ao ASR usar a cópia em nível de arquivo, o SQL não pode garantir que os servidores em uma topologia de replicação de SQL associada estejam sincronizados no momento do failover do ASR. Isso pode fazer com que os agentes de logreader e/ou de distribuição falhem devido à incompatibilidade de LSN, que pode interromper a replicação. Se você fizer failover do publicador, distribuidor ou assinante em uma topologia de replicação, precisará recompilar a replicação. É recomendável reinicializar a assinatura para SQL Server.

Próximas etapas

Saiba mais sobre a arquitetura do Site Recovery.
Para o SQL Server no Azure, saiba mais sobre soluções de alta disponibilidade para recuperação em uma região secundária do Azure.
Para o Banco de Dados SQL, saiba mais sobre as opções de continuidade de negócios e alta disponibilidade para recuperação em uma região secundária do Azure.
Para computadores do SQL Server no local, saiba mais sobre as opções de alta disponibilidade para recuperação em Máquinas Virtuais do Azure.