Confiabilidade no DNS do Azure

Este artigo contém informações detalhadas sobre suporte à recuperação de desastre entre regiões e continuidade dos negócios para o DNS do Azure.

Recuperação de desastre entre regiões e continuidade dos negócios

A DR (recuperação de desastre) trata da recuperação após eventos de alto impacto, como desastres naturais ou implantações com falha, que resultam em tempo de inatividade e perda de dados. Seja qual for a causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que dê suporte ativo à DR. Antes de começar a pensar em criar seu plano de recuperação de desastre, confira Recomendações para criar uma estratégia de recuperação de desastre.

Quando o assunto é DR, a Microsoft usa o modelo de responsabilidade compartilhada. Em um modelo de responsabilidade compartilhada, a Microsoft garante que a infraestrutura de linha de base e os serviços de plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente nem retornam de uma região com falha para a replicação cruzada em outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastres que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de PaaS (plataforma como serviço) do Azure fornece recursos e diretrizes para dar suporte à DR. Além disso, você pode usar recursos específicos do serviço para dar suporte a uma recuperação rápida, a fim de ajudar a desenvolver seu plano de DR.

A solução de failover de DNS do Azure para recuperação de desastre usa o mecanismo DNS padrão para fazer failover no site de backup. A opção manual por meio do DNS do Azure funciona melhor quando usada em conjunto com a espera passiva ou a abordagem de luz piloto.

Como o servidor DNS está fora da zona de failover ou desastre, ele é isolado contra qualquer tempo de inatividade. Você pode arquitetar um cenário de failover simples, desde que o operador tenha conectividade de rede durante o desastre e possa fazer a inversão. Se a solução estiver com script, você deverá garantir que o servidor ou o serviço que executa o script também esteja isolado contra o problema que afeta o ambiente de produção. Além disso, um TTL baixo para a zona impede o cache resolvedor por longos períodos de tempo, permitindo que o cliente acesse o site dentro do RTO. Para uma espera passiva e luz piloto, já que algumas atividades preparativas e de preparação podem ser necessárias, você também deve permitir tempo suficiente antes de se fazer a inversão.

Observação

A zona DNS privada do Azure dá suporte à resolução DNS entre redes virtuais em regiões do Azure, mesmo sem emparelhar explicitamente as redes virtuais. No entanto, todas as redes virtuais devem estar vinculadas à zona DNS privada.

Para saber como criar uma zona DNS privada do Azure usando o portal do Azure, confira Início rápido: criar uma zona DNS privada do Azure usando o portal do Azure.

Para criar um Resolvedor Privado de DNS do Azure usando o portal do Azure, confira Início rápido: criar um Resolvedor Privado de DNS do Azure usando o portal do Azure.

Recuperação de desastre na geografia de várias regiões

Há dois aspectos técnicos para a configuração de sua arquitetura de recuperação de desastre:

• Usar um mecanismo de implantação para replicar instâncias, dados e configurações entre ambientes primários e de espera. Esse tipo de recuperação de desastre pode ser feito nativamente por meio do Azure Site Recovery; confira a Documentação do Azure Site Recovery por meio de dispositivos/serviços de parceiros do Microsoft Azure, como a Veritas ou a NetApp.

• Desenvolver uma solução para desviar o tráfego de rede/da Web do site primário para o site em espera. Esse tipo de recuperação de desastre pode ser obtido por meio do DNS do Azure, do Gerenciador de Tráfego do Azure (DNS) ou de balanceadores de carga globais de terceiros.

Este artigo se concentra especificamente no planejamento de recuperação de desastre do DNS do Azure.

Configurar a recuperação de desastre e a detecção de interrupções

A solução de failover manual do DNS do Azure para recuperação de desastre usa o mecanismo DNS padrão para fazer o failover no site de backup. A opção manual por meio do DNS do Azure funciona melhor quando usada em conjunto com as abordagens de espera passiva ou de luz piloto.

Figura - Failover Manual usando o DNS do Azure

As suposições feitas para a solução são:

• Os pontos de extremidade primários e secundários têm IPs estáticos que não são alterados com frequência. Digamos que para o site primário, o IP é 100.168.124.44 e o IP para o site secundário é 100.168.124.43.
• Existe uma zona DNS do Azure para o site primário e secundário. Digamos que, para o site primário o ponto de extremidade é prod.contoso.com e para o site de backup é dr.contoso.com. Também existe um registro DNS para o aplicativo principal, conhecido como www.contoso.com.
• O TTL está no limite ou abaixo do SLA de RTO definido na organização. Por exemplo, se uma empresa define o RTO da resposta de desastre do aplicativo para ser de 60 minutos, então o valor TTL deve ser menor que 60 minutos, preferencialmente quanto menor, melhor. Você pode configurar o DNS do Azure para failover manual da seguinte maneira:
  • Criar uma zona DNS
  • Criar registros de zona DNS
  • Atualizar um registro CNAME

1. Crie uma zona DNS (por exemplo, www.contoso.com), conforme mostrado abaixo:

   

   Figura - Criar uma zona DNS no Azure

2. Nesta zona, crie três registros (por exemplo, www.contoso.com, prod.contoso.com e dr.contoso.com) conforme mostrado abaixo.

   

   Figura - Criar registros de zona DNS no Azure

   Nesse cenário, o site www.contoso.com tem um TTL de 30 minutos, que é bem abaixo do RTO indicado e está apontando para o site de produção prod.contoso.com. Essa configuração é aplicável durante operações normais de negócios. O TTL de prod.contoso.com e dr.contoso.com foi definido para 300 segundos ou 5 minutos. Você pode usar um serviço de monitoramento do Azure, como o Azure Monitor ou Azure App Insights ou qualquer solução de monitoramento de parceiro, como Dynatrace. Você pode até mesmo usar soluções de internas que possam monitorar ou detectar falhas de nível de infraestrutura virtual ou de aplicativo.

3. Depois da falha ser detectada, altere o valor de registro para apontar para dr.contoso.com, conforme mostrado abaixo:

   

   Figura - Atualizar o registro CNAME no Azure

   Em até 30 minutos, durante os quais a maioria dos resolvedores atualizará o arquivo de zonas armazenadas em cache, qualquer consulta em www.contoso.com será redirecionada para dr.contoso.com. Você também pode executar o seguinte comando na CLI do Azure para alterar o valor CNAME:

     az network dns record-set cname set-record \
     --resource-group 123 \
     --zone-name contoso.com \
     --record-set-name www \
     --cname dr.contoso.com
   

   Essa etapa pode ser executada manualmente ou por meio de automação. Ela pode ser feito manualmente por meio do console ou pela CLI do Azure. O SDK do Azure e a API podem ser usados para automatizar a atualização CNAME para que nenhuma intervenção manual seja necessária. A automação pode ser criada por meio de funções do Azure ou em um aplicativo de monitoramento de terceiros, ou até mesmo no local.

Próximas etapas

• Confiabilidade no Azure
• Saiba mais sobre o Gerenciador de Tráfego do Azure.
• Saiba mais sobre DNS do Azure.