Confiabilidade no Gerenciador de Tráfego do Azure
Este artigo contém recomendações de confiabilidade específicas para do Gerenciador de Tráfego do Azure, bem como suporte à recuperação de desastres entre regiões e à continuidade dos negócios suporte para o Gerenciador de Tráfego do Azure.
Para obter uma visão geral mais detalhada dos princípios de confiabilidade no Azure, confira Confiabilidade do Azure.
Recomendações de confiabilidade
Essa seção contém recomendações para obter resiliência e disponibilidade. Cada recomendação se enquadra em uma das duas categorias:
Os itens de integridade abrangem áreas como itens de configuração e a função adequada dos principais componentes que compõem a carga de trabalho do Azure, como configurações de recursos do Azure, dependências de outros serviços e assim por diante.
Os itens de risco abrangem áreas como requisitos de disponibilidade e recuperação, teste, monitoramento, implantação e outros itens que, se deixados não resolvidos, aumentam as chances de problemas no ambiente.
Matriz de prioridade de recomendações de confiabilidade
Cada recomendação é marcada de acordo com a seguinte matriz de prioridade:
| Imagem | Prioridade | Descrição |
|---|---|---|
|
Alto | Correção imediata necessária. |
|
Médio | Correção dentro de 3 a 6 meses. |
|
Baixo | Precisa de revisão. |
Resumo das recomendações de confiabilidade
Disponibilidade
O Status do Monitor do Gerenciador de Tráfego deve ser Online
O status do monitor deve estar online para fornecer failover para a carga de trabalho do aplicativo. Se a integridade do seu Gerenciador de Tráfego exibe um status Degradado, o status de um ou mais pontos de extremidade também pode ser Degradado.
Para obter mais informações sobre monitoramento de ponto de extremidade do Gerenciador de Tráfego, confira Monitoramento do ponto de extremidade do Gerenciador de Tráfego.
Para solucionar problemas de um estado degradado no Gerenciador de Tráfego do Azure, consulte Solução de problemas de estado degradado no Gerenciador de Tráfego do Azure.
Perfis do Gerenciador de Tráfego devem ter mais de um ponto de extremidade
Ao configurar o gerenciador de tráfego do Azure, você deve provisionar no mínimo dois pontos de extremidade para fazer failover da carga de trabalho para outra instância.
Para saber mais sobre os tipos de ponto de extremidade do Gerenciador de Tráfego, consulte Pontos de extremidade do Gerenciador de Tráfego.
Eficiência do sistema
O valor TTL dos perfis de usuário deve estar em 60 segundos
A Vida Útil (TTL) afeta a data da resposta que o cliente receberá quando fizer uma solicitação ao Gerenciador de Tráfego do Microsoft Azure. A redução do valor da TTL significa que o cliente será direcionado para um ponto de extremidade em funcionamento mais rápido em caso de failover. Configurar a TTL para 60 segundos para direcionar o tráfego para um ponto de extremidade íntegro o mais rápido possível.
Para obter mais informações sobre como configurar a TTL do DNS, consulte Configurar a Vida Útil do DNS.
Recuperação de desastre
Configurar pelo menos um ponto de extremidade em outra região
Os perfis devem ter mais de um ponto de extremidade para garantir a disponibilidade se um deles falhar. Também é recomendável que os pontos de extremidade estejam em regiões diferentes.
Para saber mais sobre os tipos de ponto de extremidade do Gerenciador de Tráfego, consulte Pontos de extremidade do Gerenciador de Tráfego.
Garantir o ponto de extremidade configurado para “(Todos os Mundos)” de perfis geográficos
No roteamento geográfico, o tráfego é roteado para pontos finais de acordo com regiões definidas. Se uma região falhar, não haverá failover predefinido. Ter um ponto de extremidade no qual o Agrupamento Regional esteja configurado como “Todos (Mundo)” em perfis geográficos evitará buracos negros de tráfego e garantirá que o serviço permaneça disponível.
Para saber como adicionar e configurar um ponto de extremidade, consulte Adicionar, desabilitar, habilitar, excluir ou mover pontos de extremidade.
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 desastre 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.