Fiabilidade no DNS do Azure

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

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

A recuperação de desastres (DR) consiste na recuperação de eventos de alto impacto, como desastres naturais ou implantações com falha que resultam em tempo de inatividade e perda de dados. Independentemente da causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que suporte ativamente a DR. Antes de começar a pensar em criar seu plano de recuperação de desastres, consulte Recomendações para projetar uma estratégia de recuperação de desastres.

Quando se trata de 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 da plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente ou recorrem de uma região com falha para replicação cruzada para 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 plataforma como serviço (PaaS) do Azure fornecem recursos e orientação para dar suporte à DR e você pode usar recursos específicos do serviço para dar suporte à recuperação rápida para ajudar a desenvolver seu plano de DR.

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

Como o servidor DNS está fora da zona de failover ou desastre, ele está 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 for baseada em script, você deverá garantir que o servidor ou 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 do resolvedor por longos períodos de tempo, permitindo que o cliente acesse o site dentro do RTO. Para uma espera fria e luz piloto, uma vez que algum pré-aquecimento e outras atividades administrativas podem ser necessárias, você também deve dar tempo suficiente antes de fazer o flip.

Nota

A zona DNS privada do Azure dá suporte à resolução de 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, consulte Guia de 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, consulte Guia de início rápido: Criar um Resolvedor Privado de DNS do Azure usando o portal do Azure.

Recuperação de desastres em geografia de várias regiões

Há dois aspetos técnicos para configurar sua arquitetura de recuperação de desastres:

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

• Desenvolvimento de uma solução para desviar o tráfego de rede/web do site principal para o site em espera. Esse tipo de recuperação de desastres 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 desastres do DNS do Azure.

Configurar a recuperação de desastres e a deteção de interrupções

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

Figura - Failover manual usando o DNS do Azure

Os pressupostos para a solução são:

• Os pontos de extremidade primários e secundários têm IPs estáticos que não mudam 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 registo DNS para a aplicação principal conhecida como www.contoso.com.
• O TTL está igual ou inferior ao SLA RTO definido na organização. Por exemplo, se uma empresa definir o RTO da resposta a desastres do aplicativo como 60 minutos, o TTL deve ser inferior a 60 minutos, de preferência quanto menor, melhor. Você pode configurar o DNS do Azure para failover manual da seguinte maneira:
  • Criar uma zona DNS
  • Criar registos de zona DNS
  • Atualizar registro CNAME

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

   

   Figura - Criar uma zona DNS no Azure

2. Dentro dessa 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

   Neste cenário, site, www.contoso.com tem um TTL de 30 minutos, que está bem abaixo do RTO indicado, e está apontando para o local de produção prod.contoso.com. Essa configuração ocorre durante as operações comerciais normais. 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 o Azure App Insights, ou qualquer solução de monitoramento de parceiro, como o Dynatrace. Você pode até mesmo usar soluções desenvolvidas internamente que podem monitorar ou detetar falhas no nível de aplicativo ou infraestrutura virtual.

3. Quando a falha for detetada, altere o valor do registro para apontar para dr.contoso.com conforme mostrado abaixo:

   

   Figura - Atualizar o registro CNAME no Azure

   Dentro de 30 minutos, durante os quais a maioria dos resolvedores atualizará o arquivo de zona em cache, qualquer consulta a www.contoso.com será redirecionada para dr.contoso.com. Você também pode executar o seguinte comando da 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
   

   Esta etapa pode ser executada manualmente ou via automação. Isso pode ser feito manualmente por meio do console ou pela CLI do Azure. O SDK e a API do Azure 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 dentro de um aplicativo de monitoramento de terceiros ou até mesmo localmente.

Próximos passos

• Fiabilidade no Azure
• Saiba mais sobre o Azure Traffic Manager.
• Saiba mais sobre o DNS do Azure.