Explorar uma solução de alta disponibilidade e recuperação de desastre de IaaS
Há muitas combinações de recursos que podem ser implantadas no Azure para IaaS. Esta seção abordará cinco exemplos comuns de arquiteturas de HADR (alta disponibilidade e recuperação de desastres) do SQL Server no Azure.
Exemplo 1 de alta disponibilidade de região única – grupos de disponibilidade Always On
Se você precisar de alta disponibilidade e não de recuperação de desastres, configurar um AG (grupo de disponibilidade) é um dos métodos mais abrangentes, não importa em que local você está usando o SQL Server. A imagem abaixo é um exemplo de como poderia ser um possível AG em uma só região.
Por que vale a pena considerar essa arquitetura?
Essa arquitetura protege os dados com mais de uma cópia em VMs (máquinas virtuais) diferentes.
Essa arquitetura permite que você cumpra o RTO (objetivo de tempo de recuperação) e o RPO (objetivo de ponto de recuperação) com uma perda de dados mínima ou nenhuma, se implementada corretamente.
Essa arquitetura oferecerá um método fácil e padronizado para que os aplicativos acessem réplicas primárias e secundárias (se forem usados itens como réplicas somente leitura).
Essa arquitetura fornece disponibilidade aprimorada durante cenários de aplicação de patch.
Essa arquitetura não precisa de armazenamento compartilhado, portanto, há menos complicação do que ao usar uma FCI (instância de cluster de failover).
Exemplo 2 de alta disponibilidade de região única – instância de cluster de failover Always On
Até que os AGs tenham sido introduzidos, as FCIs eram a maneira mais popular de implementar alta disponibilidade do SQL Server. Porém, as FCIs foram criadas quando implantações físicas eram dominantes. Em um mundo virtualizado, as FCIs não fornecem muitas das mesmas proteções que forneceriam em um hardware físico, pois é raro que uma VM tenha um problema. As FCIs foram projetadas para oferecer proteção contra problemas como falha de placa de rede ou falha de disco, o que provavelmente não aconteceria no Azure.
Dito isso, as FCIs têm um lugar no Azure. Elas funcionam e, desde que você tenha as expectativas corretas sobre o que é e o que não é oferecido, uma FCI é uma solução perfeitamente aceitável. A imagem abaixo, na documentação da Microsoft, mostra uma exibição de alto nível da aparência de uma implantação da FCI ao usar Espaços de Armazenamento Diretos.
Por que vale a pena considerar essa arquitetura?
FCIs ainda são uma solução de disponibilidade popular.
A história do armazenamento compartilhado está sendo aprimorada com recursos como Disco Compartilhado do Azure.
Essa arquitetura cumpre à maioria dos RTOs e RPOs para HA (embora não haja suporte para DR).
Essa arquitetura fornece um método fácil e padronizado para que os aplicativos acessem a instância clusterizada do SQL Server.
Essa arquitetura fornece disponibilidade aprimorada durante cenários de aplicação de patch.
Exemplo 1 de recuperação de desastre – grupo de disponibilidade Always On de várias regiões ou híbrido
Se você estiver usando AGs, uma opção é configurar o AG em várias regiões do Azure ou potencialmente como uma arquitetura híbrida. Isso significa que todos os nós que contêm as réplicas participam do mesmo WSFC. Isso pressupõe uma boa conectividade de rede, especialmente se for uma configuração híbrida. Uma das principais considerações seria o recurso de testemunha para o WSFC. Essa arquitetura exigiria que AD DS e o DNS estivessem disponíveis em todas as regiões e potencialmente no local também, caso essa seja uma solução híbrida. A imagem abaixo mostra como é o AG único configurado em dois locais usando o Windows Server.
Por que vale a pena considerar essa arquitetura?
Essa arquitetura é uma solução comprovada. Não é diferente de ter dois data centers hoje em uma topologia de AG.
Essa arquitetura funciona com as edições Standard e Enterprise do SQL Server.
O AGs naturalmente fornecem redundância com cópias adicionais de dados.
Essa arquitetura usa um recurso que fornece tanto HA quanto D/R
Exemplo 2 de recuperação de desastre – grupo de disponibilidade distribuído
Um AG distribuído é um recurso somente da Edição Enterprise introduzido no SQL Server 2016. Ele é diferente de um AG tradicional. Em vez de ter um WSFC subjacente em que todos os nós contêm réplicas que participam de um AG, conforme descrito no exemplo anterior, um AG distribuído é composto por vários AGs. A réplica primária que contém o banco de dados de leitura/gravação é conhecida como a primária global. O primário do segundo AG é conhecido como encaminhador e mantém as réplicas secundárias desse AG em sincronia. Em essência, isso é um AG de AGs.
Essa arquitetura torna mais fácil lidar com coisas como o quorum, pois cada cluster manteria o próprio quorum, o que significa que ele também tem a própria testemunha. Um AG distribuído funcionaria se você usasse o Azure para todos os recursos ou se usasse uma arquitetura híbrida.
A imagem abaixo mostra um exemplo de configuração do AG distribuído. Há dois WSFCs. Imagine que cada um esteja em uma região do Azure diferente ou que um seja local e outro esteja no Azure. Cada WSFC tem um AG com duas réplicas. A primária global no AG 1 está mantendo a secundária da réplica do AG 1 sincronizada, bem como o encaminhador, que também é a primária do AG 2. Essa réplica mantém a réplica secundária do AG 2 sincronizada.
Por que vale a pena considerar essa arquitetura?
Essa arquitetura separa o WSFC como um ponto único de falha se todos os nós perderem a comunicação
Nessa arquitetura, uma primária não está sincronizando todas as réplicas secundárias.
Essa arquitetura pode fornecer failback de uma localização para outra.
Exemplo 3 de recuperação de desastre – envio de logs
O envio de logs é um dos métodos mais antigos do HADR para configurar a recuperação de desastres para SQL Server. Conforme descrito acima, a unidade de medida é o backup do log de transações. A menos que a alternância para uma espera passiva esteja planejada para garantir que não haja perda de dados, provavelmente ocorrerá perda de dados. Quando se trata de recuperação de desastres, é sempre melhor pressupor alguma perda de dados, mesmo que seja mínima. A imagem abaixo, da documentação da Microsoft, mostra um exemplo de topologia de envio de logs.
Por que vale a pena considerar essa arquitetura?
O envio de logs é um recurso testado e comprovado que existe há mais de 20 anos
É fácil implantar e administrar o envio de logs, uma vez que ele se baseia em backup e restauração.
O envio de logs é tolerante a redes que não são robustas.
O envio de logs cumpre os objetivos de RTO e RPO para DR.
O envio de logs é uma boa maneira de proteger as FCIs.
Exemplo 4 de recuperação de desastre – Azure Site Recovery
Para aqueles que não desejam implementar uma solução de desastre baseada em SQL Server, o Azure Site Recovery é uma opção potencial. No entanto, a maioria dos profissionais de dados prefere uma abordagem centrada no banco de dados, que geralmente tem um RPO menor.
A imagem abaixo, da documentação da Microsoft, mostra em que lugar no portal do Azure você configuraria a replicação para o Azure Site Recovery.
Por que vale a pena considerar essa arquitetura?
O Azure Site Recovery funcionará com mais do que apenas o SQL Server.
O Azure Site Recovery pode cumprir ao RTO e, possivelmente, o RPO.
O Azure Site Recovery é fornecido como parte da plataforma do Azure.