Confiabilidade no Gerenciador de Tráfego do Azure
Esse artigo contém suporte para recuperação de desastres entre regiões e continuidade de negócios para o Azure Traffic Manager.
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.
O Gerenciador de Tráfego do Azure é um balanceador de carga de tráfego baseado em DNS que permite distribuir o tráfego para seus aplicativos voltados para o público em regiões globais do Azure. O Gerenciador de Tráfego também fornece alta disponibilidade e rápida capacidade de resposta aos seus pontos de extremidade públicos.
O Gerenciador de Tráfego usa o DNS para direcionar as solicitações do cliente para o ponto de extremidade de serviço apropriado com base em um método de roteamento de tráfego. O Gerenciador de Tráfego também fornece monitoramento de integridade para cada ponto de extremidade. O ponto de extremidade pode ser qualquer serviço para a Internet hospedado dentro ou fora do Azure. O Gerenciador de Tráfego oferece uma variedade de métodos de roteamento de tráfego e opções de monitoramento de ponto de extremidade para atender às diferentes necessidades dos aplicativos e modelos de failover automático. O Gerenciador de Tráfego é resistente a falhas, incluindo a falha de toda a região do Azure.
Recuperação de desastre na geografia de várias regiões
O DNS é um dos mecanismos mais eficientes para desviar o tráfego de rede. O DNS é eficiente porque geralmente é global e externo ao data center. O DNS também é isolado de falhas de nível de zona regional ou de disponibilidade (AZ).
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 Gerenciador de Tráfego do Azure.
Detecção, notificação e gerenciamento de interrupção
Durante um desastre, o ponto de extremidade primário é analisado e o status é alterado para degradado e o site recuperação de desastre permanece Online. Por padrão, o Gerenciador de Tráfego envia todo o tráfego para o ponto de extremidade primário (prioridade mais alta). Se o ponto de extremidade primário aparece como degradado, o Gerenciador de Tráfego roteia o tráfego para o segundo ponto de extremidade desde que ele permaneça íntegro. É possível configurar mais pontos de extremidade no Gerenciador de Tráfego, que podem servir como pontos de extremidade de failover adicionais ou como balanceadores de carga que compartilham a carga entre os pontos de extremidade.
Configurar a recuperação de desastre e a detecção de interrupções
Quando você tiver arquiteturas complexas e vários conjuntos de recursos capazes de executar a mesma função, você pode configurar o Gerenciador de Tráfego do Azure (com base no DNS) para verificar a integridade de seus recursos e rotear o tráfego do recurso não íntegro para o recurso íntegro.
No exemplo a seguir, a região primária e a região secundária têm uma implantação completa. Essa implantação inclui os serviços de nuvem e um banco de dados sincronizado.
Figura - Failover automático usando o Gerenciador de Tráfego do Azure
No entanto, somente a região primária processa ativamente solicitações de rede dos usuários. A região secundária se torna ativa apenas quando a região primária apresentar uma interrupção do serviço. Nesse caso, todas as novas solicitações de rede são encaminhadas para a região secundária. Como o backup do banco de dados é quase instantâneo, ambos os balanceadores de carga possuem IPs que podem ter a integridade verificada, e as instâncias estão sempre em execução, essa topologia oferece uma opção para um RTO baixo e failover sem nenhuma intervenção manual. A região de failover secundária deve estar pronta para entrar em atividade imediatamente após a falha da região primária.
Este cenário é ideal para o uso do Gerenciador de Tráfego do Azure que tenha investigações incorporadas para vários tipos de verificações de integridade, incluindo http / https e TCP. O Gerenciador de Tráfego do Azure também tem um mecanismo de regras que pode ser configurado para failover quando ocorre uma falha, conforme descrito abaixo. Vamos considerar a seguinte solução usando o Gerenciador de Tráfego:
- O cliente tem o ponto de extremidade da Região nº1 conhecido como prod.contoso.com com um endereço IP estático de 100.168.124.44 e um ponto de extremidade da Região nº2 conhecido como dr.contoso.com com um endereço IP estático de 100.168.124.43.
- Cada um desses ambientes é apoiado por meio de uma propriedade pública como um balanceador de carga. O balanceador de carga pode ser configurado para ter um ponto de extremidade com base em DNS ou um nome de domínio totalmente qualificado (FQDN), como mostrado acima.
- Todas as instâncias na Região 2 possuem replicação quase em tempo real em relação à Região 1. Além disso, as imagens de computadores estão atualizadas e todos os dados de configuração/software tem os patches aplicados e estão de acordo com a Região 1.
- O dimensionamento automático é pré-configurado antes.
Para configurar o failover com o Gerenciador de Tráfego do Azure:
Criar um novo perfil do Gerenciador de Tráfego do Azure Criar um novo perfil do Gerenciador de Tráfego do Azure com o nome contoso123 e selecione o Método de roteamento como Prioritário. Se você tiver um grupo de recursos já existente que você deseja associar, então você pode selecionar um grupo de recursos existente, caso contrário, crie um novo grupo de recursos.
Figura – Criar um perfil do Gerenciador de Tráfego
Criar pontos de extremidade no perfil do Gerenciador de Tráfego
Nesta etapa, você cria pontos de extremidade que apontam para os sites de produção e de recuperação de desastre. Aqui, escolha o Tipo como um ponto de extremidade externo, mas se o recurso for hospedado no Azure, então você pode escolher o Ponto de extremidade do Azure também. Se você escolher Ponto de extremidade do Azure, então selecione um Recurso de destino que seja um Serviço de Aplicativo ou um IP público que está alocado por Azure. A prioridade é definida como 1 já que é o principal serviço para a Região 1. Da mesma forma, crie o ponto de extremidade de recuperação de desastre no Gerenciador de Tráfego.
Figura - Criar pontos de extremidade de recuperação de desastre
Definir a configuração de failover e verificação de integridade
Nesta etapa, você define o TTL do DNS para 10 segundos, que é cumprido por resolvedores recursivos voltados para a Internet. Essa configuração significa que o resolvedor de DNS não armazenará as informações em cache por mais de 10 segundos.
Para as configurações do monitor de ponto de extremidade, o caminho é atualmente definido para / ou raiz, mas você pode personalizar as configurações de ponto de extremidade para avaliar um caminho, por exemplo, prod.contoso.com/index.
O exemplo a seguir mostra o https como o protocolo de investigação. No entanto, você também pode escolher http ou tcp. A opção de protocolo depende do aplicativo final. O intervalo de investigação é definido como 10 segundos, que permite uma rápida investigação e a repetição é definida como 3. Como resultado, o Gerenciador de Tráfego fará o failover no segundo ponto de extremidade se três intervalos consecutivos registrarem uma falha.
A fórmula a seguir define o tempo total de um failover automatizado:
Time for failover = TTL + Retry * Probing intervalNesse caso, o valor é 10 + 3 * 10 = 40 segundos (Máximo).
Se Repetição estiver definida como 1 e o TTL estiver definido como 10 segundos, então o tempo para failover é de 10 + 1 * 10 = 20 segundos.
Defina a Repetição para um valor maior que 1 para eliminar a possibilidade de failovers devido a falsos positivos ou quaisquer perturbarções de rede secundária.
Figura - Definir a configuração de failover e verificação de integridade
Próximas etapas
Saiba mais sobre o Gerenciador de Tráfego do Azure.
Saiba mais sobre DNS do Azure.