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

Artigo
03/10/2024

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

Antes de começar, certifique-se de entender os recursos de recuperação de desastres do SQL Server. Estas capacidades incluem:

Clustering de ativação pós-falha
Grupos de Disponibilidade AlwaysOn
Espelhamento da base de dados
Envio de registos
Georreplicação ativa
Grupos de ativação pós-falha automática

Combinando tecnologias BCDR com recuperação de local

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

Tipo de implementação	Tecnologia BCDR	RTO esperado para SQL Server	RPO esperado para SQL Server
SQL Server em uma infraestrutura do Azure como um serviço (IaaS), máquina virtual (VM) ou no local.	Grupo de disponibilidade Always On	O tempo necessário para tornar a réplica secundária como primária.	Como a replicação para a réplica secundária é assíncrona, há alguma perda de dados.
SQL Server em uma VM IaaS do Azure ou no local.	Clustering de failover (FCI Always On)	O tempo necessário para fazer failover entre os nós.	Como a FCI Always On usa armazenamento compartilhado, a mesma exibição da instância de armazenamento está disponível no failover.
SQL Server em uma VM 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 de espera quente.	A replicação é assíncrona. A base de dados espelhada pode ficar um pouco atrasada relativamente à base de dados principal. O atraso é tipicamente pequeno. Mas ele pode se tornar grande se o sistema do servidor principal ou espelho estiver sob uma carga pesada. O envio de logs pode ser um complemento ao espelhamento do banco de dados. É uma alternativa favorável ao espelhamento assíncrono de banco de dados.
SQL como plataforma como serviço (PaaS) no Azure. Esse tipo de implantação inclui bancos de dados únicos e pools elásticos.	Georreplicação ativa	30 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 automaticamente vinculados 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 forma assíncrona transações confirmadas no banco de dados primário para um banco de dados secundário usando o isolamento de instantâneo. Os dados secundários são garantidos para nunca ter 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 únicos.	Grupos de ativação pós-falha automática	RTO de uma hora.	RPO de cinco segundos. Os grupos de failover automático fornecem a semântica do grupo sobre a replicação geográfica ativa. Mas o mesmo mecanismo de replicação assíncrona é usado.
SQL Server em uma VM IaaS do Azure ou no local.	Replicação com o Azure Site Recovery	O RTO é normalmente inferior a 15 minutos. Para saber mais, leia o SLA RTO fornecido pelo Site Recovery.	Uma hora para consistência de aplicativos e cinco minutos para consistência de falhas. Se você estiver procurando por RPO mais baixo, use outras tecnologias BCDR.

Nota

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

O Site Recovery é independente do aplicativo. A Recuperação de Site pode ajudar a proteger qualquer versão do SQL Server implantada em um sistema operacional com suporte. Para saber mais, consulte a matriz de suporte para recuperação de máquinas replicadas.
Você pode optar por usar a Recuperação de Site para qualquer implantação no Azure, Hyper-V, VMware ou infraestrutura física. Siga as orientações no final deste artigo sobre como ajudar a proteger um cluster do SQL Server com o Site Recovery.
Certifique-se de que a taxa de alteração de dados observada na máquina esteja dentro dos limites da Recuperação de Site. A taxa de alteração é medida em bytes de gravação por segundo. Para máquinas que executam o Windows, você pode exibir essa taxa de alteração selecionando a guia Desempenho no Gerenciador de Tarefas. Observe a velocidade de gravação de cada disco.
A Recuperação de Site oferece suporte à replicação de Instâncias de Cluster de Failover em Espaços de Armazenamento Diretos. Para saber mais, veja como habilitar a replicação direta de Espaços de Armazenamento.

Ao migrar sua carga de trabalho SQL para o Azure, é recomendável aplicar as diretrizes de desempenho para o SQL Server em máquinas virtuais do Azure.

Recuperação de desastres de um aplicativo

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

Existem alguns pré-requisitos para garantir que o seu plano de recuperação seja totalmente personalizado de acordo com a sua necessidade. Qualquer implantação do SQL Server normalmente precisa de uma implantação do Ative Directory. Ele também precisa de conectividade para sua camada de aplicativo.

Etapa 1: configurar o Ative Directory

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

Pequena empresa: você tem alguns aplicativos e um único controlador de domínio para o site local. Se quiser fazer failover de todo o site, use a replicação do Site Recovery. Este serviço replica o controlador de domínio para o datacenter secundário ou para o Azure.
Empresa de médio a grande porte: talvez seja necessário configurar controladores de domínio adicionais.
- Se você tiver um grande número de aplicativos, tiver uma floresta do Ative Directory e quiser fazer failover por aplicativo ou carga de trabalho, configure outro controlador de domínio no datacenter secundário ou no Azure.
- Se você estiver 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. Este controlador de domínio é usado para a instância recuperada do SQL Server.

As instruções neste artigo pressupõem que um controlador de domínio está disponível no local secundário. Para saber mais, consulte os procedimentos para ajudar a proteger o Ative Directory com a Recuperação de Site.

Etapa 2: Garantir a conectividade com outras camadas

Depois que a camada de banco de dados estiver sendo executada na região do Azure de destino, verifique se você tem conectividade com as camadas do aplicativo e da Web. Execute as etapas necessárias com antecedência para validar a conectividade com failover de teste.

Para entender como você pode projetar aplicativos para considerações de conectividade, consulte estes exemplos:

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

As tecnologias 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 principal. Esta etapa pressupõe que você já tenha um controlador de domínio no secundário. A etapa pode não ser necessária se você optar por fazer um failover automático. Faça failover das camadas da Web e do aplicativo somente depois que o failover do banco de dados for concluído.

Nota

Se você ajudou a proteger as máquinas SQL com o Site Recovery, basta criar um grupo de recuperação dessas máquinas e adicionar seu failover no plano de recuperação.

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

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

Etapa 4: Realizar um failover de teste

Algumas tecnologias BCDR, como o SQL Always On, não suportam nativamente failover de teste. Recomendamos a seguinte abordagem 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 acionar o failover de teste do plano de recuperação, recupere a VM do backup feito na etapa anterior.
Forçar um quórum na VM que foi restaurada a partir do backup.
Atualize o endereço IP do ouvinte para ser um endereço disponível na rede de failover de teste.
Coloque o ouvinte online.
Verifique se o balanceador de carga na rede de failover tem um endereço IP, do pool de endereços IP front-end correspondente 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 failover da camada de aplicativo seguida da 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 seu aplicativo.

Etapas para fazer um failover

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

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

Como ajudar a proteger um cluster do SQL Server

Para um cluster que executa o SQL Server Standard Edition ou o SQL Server 2008 R2, recomendamos que você use a replicação do Site Recovery para ajudar a proteger o SQL Server.

Azure para Azure e local para Azure

O Site Recovery não fornece suporte a cluster convidado ao replicar para uma região do Azure. O SQL Server Standard edition também não fornece uma solução de recuperação de desastres de baixo custo. Nesse cenário, recomendamos que você proteja o cluster do SQL Server para uma instância autônoma do SQL Server no local primário e recupere-o no secundário.

Configure outra instância autônoma do SQL Server na região primária do Azure ou no site local.
Configure a instância para servir como um espelho para os bancos de dados que você deseja ajudar a proteger. Configure o espelhamento no modo de alta segurança.
Configure a Recuperação de Site no site primário para VMs e servidores físicos do Azure, Hyper-V ou VMware.
Use a replicação do Site Recovery para replicar a nova instância do SQL Server para o site secundário. Como é uma cópia espelhada de alta segurança, ela é 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 do espelho para o cluster original com o restabelecimento do espelho.

Perguntas mais frequentes

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

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

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

O Site Recovery é independente do aplicativo. A Recuperação de Site pode ajudar a proteger qualquer versão do SQL Server implantada em um sistema operacional com suporte. Para obter mais, consulte a matriz de suporte para recuperação de máquinas replicadas.

O ASR funciona com replicação transacional SQL?

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

Próximos passos

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 máquinas SQL Server locais, saiba mais sobre as opções de alta disponibilidade para recuperação em Máquinas Virtuais do Azure.