Gestor de Tráfego do Azure com o Azure Site Recovery

O Gestor de Tráfego do Azure permite-lhe controlar a distribuição do tráfego nos pontos finais da aplicação. Os pontos finais são serviços com acesso à Internet alojados dentro ou fora do Azure.

O Gestor de Tráfego utiliza o Sistema de Nomes de Domínio (DNS) para direcionar os pedidos de cliente para o ponto final mais adequado, com base num método de encaminhamento de tráfego e no estado de funcionamento dos pontos finais. O Gestor de Tráfego proporciona vários métodos de encaminhamento de tráfego e opções de monitorização de pontos finais para satisfazer diferentes necessidades das aplicações e modelos de ativação pós-falha automática. Os clientes ligam diretamente ao ponto final selecionado. O Gestor de Tráfego não é um proxy ou um gateway e não vê o tráfego a passar entre o cliente e o serviço.

Este artigo descreve como pode combinar o encaminhamento inteligente do Monitor de Tráfego do Azure com as poderosas capacidades de recuperação após desastre e migração do Azure Site Recovery.

Ativação pós-falha no local para o Azure

Para o primeiro cenário, considere a Empresa A que tem toda a infraestrutura de aplicações em execução no seu ambiente no local. Por motivos de continuidade e conformidade empresarial, a Empresa A decide utilizar o Azure Site Recovery para proteger as suas aplicações.

A empresa A está a executar aplicações com pontos finais públicos e quer a capacidade de redirecionar totalmente o tráfego para o Azure num evento de desastre. O método de encaminhamento de tráfego Prioritário no Gestor de Tráfego do Azure permite à Empresa A implementar facilmente este padrão de ativação pós-falha.

A configuração é a seguinte:

• A Empresa A cria um perfil do Gestor de Tráfego.
• Ao utilizar o método de encaminhamento Prioridade , a Empresa A cria dois pontos finais – Principal para o local e Ativação Pós-falha para o Azure. A Prioridade Primária é atribuída Prioridade 1 e a Ativação Pós-falha é atribuída Prioridade 2.
• Uma vez que o ponto final primário está alojado fora do Azure, o ponto final é criado como um ponto final externo .
• Com o Azure Site Recovery, o site do Azure não tem máquinas virtuais ou aplicações em execução antes da ativação pós-falha. Assim, o ponto final de Ativação Pós-falha também é criado como um ponto final externo .
• Por predefinição, o tráfego do utilizador é direcionado para a aplicação no local porque esse ponto final tem a prioridade mais alta associada. Nenhum tráfego é direcionado para o Azure se o ponto final primário estiver em bom estado de funcionamento.

Num evento de desastre, a Empresa A pode acionar uma ativação pós-falha para o Azure e recuperar as respetivas aplicações no Azure. Quando o Gestor de Tráfego do Azure deteta que o ponto final primário já não está em bom estado de funcionamento, utiliza automaticamente o ponto final de Ativação Pós-falha na resposta DNS e os utilizadores ligam-se à aplicação recuperada no Azure.

Dependendo dos requisitos empresariais, a Empresa A pode escolher uma frequência de pesquisa superior ou inferior para alternar entre o local e o Azure num evento de desastre e garantir um período de inatividade mínimo para os utilizadores.

Quando o desastre está contido, a Empresa A pode efetuar a reativação pós-falha do Azure para o respetivo ambiente no local (VMware ou Hyper-V) com o Azure Site Recovery. Agora, quando o Gestor de Tráfego deteta que o ponto final primário está novamente em bom estado de funcionamento, utiliza automaticamente o ponto final Primário nas respetivas respostas DNS.

Migração no local para o Azure

Além da recuperação após desastre, o Azure Site Recovery também permite migrações para o Azure. Com as poderosas capacidades de ativação pós-falha de teste do Azure Site Recovery, os clientes podem avaliar o desempenho da aplicação no Azure sem afetar o ambiente no local. Quando os clientes estiverem prontos para migrar, podem optar por migrar cargas de trabalho inteiras em conjunto ou optar por migrar e dimensionar gradualmente.

O método de encaminhamento Ponderado do Gestor de Tráfego do Azure pode ser utilizado para direcionar parte do tráfego de entrada para o Azure, ao mesmo tempo que direciona a maioria para o ambiente no local. Esta abordagem pode ajudar a avaliar o desempenho de dimensionamento, uma vez que pode continuar a aumentar o peso atribuído ao Azure à medida que migra cada vez mais cargas de trabalho para o Azure.

Por exemplo, a Empresa B opta por migrar por fases, movendo alguns dos respetivos ambientes de aplicação, mantendo os restantes no local. Durante as fases iniciais em que a maior parte do ambiente está no local, é atribuído um peso maior ao ambiente no local. O gestor de tráfego devolve um ponto final com base nos pesos atribuídos aos pontos finais disponíveis.

Durante a migração, ambos os pontos finais estão ativos e a maior parte do tráfego é direcionado para o ambiente no local. À medida que a migração prossegue, pode ser atribuído um peso maior ao ponto final no Azure e, por fim, o ponto final no local pode ser desativado após a migração.

Ativação pós-falha do Azure para o Azure

Para este exemplo, considere a Empresa C que tem toda a infraestrutura de aplicações a executar o Azure. Por motivos de continuidade e conformidade empresarial, a Empresa C decide utilizar o Azure Site Recovery para proteger as suas aplicações.

A empresa C está a executar aplicações com pontos finais públicos e quer a capacidade de redirecionar totalmente o tráfego para uma região do Azure diferente num evento de desastre. O método de encaminhamento de tráfego Prioritário permite à Empresa C implementar facilmente este padrão de ativação pós-falha.

A configuração é a seguinte:

• A Empresa C cria um perfil do Gestor de Tráfego.
• Ao utilizar o método de encaminhamento Prioridade , a Empresa C cria dois pontos finais : Principal para a região de origem (Azure Ásia Oriental) e Ativação Pós-falha para a região de recuperação (Azure Sudeste Asiático). A Prioridade Primária é atribuída Prioridade 1 e a Ativação Pós-falha é atribuída Prioridade 2.
• Uma vez que o ponto final primário está alojado no Azure, o ponto final pode ser como um ponto final do Azure .
• Com o Azure Site Recovery, o site do Azure de recuperação não tem máquinas virtuais ou aplicações em execução antes da ativação pós-falha. Assim, o ponto final de Ativação Pós-falha pode ser criado como um ponto final externo .
• Por predefinição, o tráfego de utilizador é direcionado para a aplicação região de origem (Ásia Oriental), uma vez que esse ponto final tem a prioridade mais alta associada. Nenhum tráfego é direcionado para a região de recuperação se o ponto final primário estiver em bom estado de funcionamento.

Num evento de desastre, a Empresa C pode acionar uma ativação pós-falha e recuperar as aplicações na região do Azure de recuperação. Quando o Gestor de Tráfego do Azure deteta que o ponto final primário já não está em bom estado de funcionamento, utiliza automaticamente o ponto final de Ativação Pós-falha na resposta DNS e os utilizadores ligam-se à aplicação recuperada na região do Azure de recuperação (Sudeste Asiático).

Consoante os requisitos comerciais, a Empresa C pode escolher uma frequência de pesquisa superior ou inferior para alternar entre regiões de origem e recuperação e garantir um período de inatividade mínimo para os utilizadores.

Quando o desastre estiver contido, a Empresa C pode efetuar a reativação pós-falha da região do Azure de recuperação para a região do Azure de origem com o Azure Site Recovery. Agora, quando o Gestor de Tráfego deteta que o ponto final primário está novamente em bom estado de funcionamento, utiliza automaticamente o ponto final Primário nas respetivas respostas DNS.

Proteger aplicações empresariais de várias regiões

Muitas vezes, as empresas globais melhoram a experiência dos clientes ao adaptarem as suas aplicações para atender às necessidades regionais. A localização e a redução da latência podem levar à divisão da infraestrutura da aplicação entre regiões. As empresas também estão vinculadas a leis de dados regionais em determinadas áreas e optam por isolar uma parte da infraestrutura de aplicações dentro dos limites regionais.

Vamos considerar um exemplo em que a Empresa D dividiu os respetivos pontos finais de aplicação para servir separadamente a Alemanha e o resto do mundo. A Empresa D utiliza o método de encaminhamento Geográfico do Gestor de Tráfego do Azure para configurar esta configuração. Qualquer tráfego proveniente da Alemanha é direcionado para o Ponto Final 1 e qualquer tráfego com origem fora da Alemanha é direcionado para o Ponto Final 2.

O problema com esta configuração é que, se o Ponto Final 1 deixar de funcionar por qualquer motivo, não existe nenhum redirecionamento do tráfego para o Ponto Final 2. O tráfego proveniente da Alemanha continua a ser direcionado para o Ponto Final 1 , independentemente do estado de funcionamento do ponto final, deixando os utilizadores alemães sem acesso à aplicação da Empresa D. Da mesma forma, se o Ponto Final 2 ficar offline, não haverá redirecionamento do tráfego para o Ponto Final 1.

Para evitar encontrar este problema e garantir a resiliência da aplicação, a Empresa D utiliza perfis aninhados do Gestor de Tráfego com o Azure Site Recovery. Numa configuração de perfil aninhada, o tráfego não é direcionado para pontos finais individuais, mas sim para outros perfis do Gestor de Tráfego. Eis como funciona esta configuração:

• Em vez de utilizar o encaminhamento Geográfico com pontos finais individuais, a Empresa D utiliza o encaminhamento Geográfico com perfis do Gestor de Tráfego.
• Cada perfil subordinado do Gestor de Tráfego utiliza o Encaminhamento prioritário com um ponto final primário e de recuperação, o que aninha o encaminhamento Prioridade no encaminhamento geográfico .
• Para ativar a resiliência da aplicação, cada distribuição de cargas de trabalho utiliza o Azure Site Recovery para efetuar a ativação pós-falha para uma região de recuperação baseada em caso de desastre.
• Quando o Gestor de Tráfego principal recebe uma consulta DNS, é direcionado para o Gestor de Tráfego subordinado relevante que responde à consulta com um ponto final disponível.

Por exemplo, se o ponto final na Germany Central falhar, a aplicação pode ser rapidamente recuperada para o Nordeste da Alemanha. O novo ponto final processa o tráfego proveniente da Alemanha com um período de inatividade mínimo para os utilizadores. Da mesma forma, uma falha de ponto final na Europa Ocidental pode ser processada ao recuperar a carga de trabalho da aplicação para a Europa do Norte, com o Gestor de Tráfego do Azure a processar redirecionamentos de DNS para o ponto final disponível.

A configuração acima pode ser expandida para incluir o número de combinações de região e ponto final necessárias. O Gestor de Tráfego permite até 10 níveis de perfis aninhados e não permite ciclos na configuração aninhada.

Considerações sobre o Objetivo de Tempo de Recuperação (RTO)

Na maioria das organizações, adicionar ou modificar registos DNS é processado por uma equipa separada ou por alguém fora da organização. Isto torna a tarefa de alterar os registos DNS muito desafiante. O tempo necessário para atualizar os registos DNS por outras equipas ou organizações que gerem a infraestrutura DNS varia de organização para organização e afeta o RTO da aplicação.

Ao utilizar o Gestor de Tráfego, pode fazer o frontload do trabalho necessário para as atualizações de DNS. Não é necessária nenhuma ação manual ou script no momento da ativação pós-falha real. Esta abordagem ajuda na mudança rápida (e, portanto, na redução do RTO), bem como na prevenção de erros de alteração de DNS morosos dispendiosos num evento de desastre. Com o Gestor de Tráfego, até o passo de reativação pós-falha é automatizado, o que teria de ser gerido separadamente.

Definir o intervalo de pesquisa correto através de verificações de estado de funcionamento de intervalos básicos ou rápidos pode reduzir consideravelmente o RTO durante a ativação pós-falha e reduzir o tempo de inatividade para os utilizadores.

Além disso, pode otimizar o valor DNS Time to Live (TTL) para o perfil do Gestor de Tráfego. TTL é o valor para o qual uma entrada DNS seria colocada em cache por um cliente. Para um registo, o DNS não seria consultado duas vezes dentro do intervalo de TTL. Cada registo DNS tem um TTL associado. A redução deste valor resulta em mais consultas DNS para o Gestor de Tráfego, mas pode reduzir o RTO ao detetar falhas mais rapidamente.

O TTL experimentado pelo cliente também não aumenta se o número de resoluções de DNS entre o cliente e o servidor DNS autoritativo aumentar. O DNS resolve a "contagem decrescente" do TTL e só transmite um valor TTL que reflita o tempo decorrido desde que o registo foi colocado em cache. Isto garante que o registo DNS é atualizado no cliente após o TTL, independentemente do número de Resoluções DNS na cadeia.

Passos seguintes

• Saiba mais sobre os métodos de encaminhamento do Gestor de Tráfego.
• Saiba mais sobre perfis aninhados do Gestor de Tráfego.
• Saiba mais sobre a monitorização de pontos finais.
• Saiba mais sobre os planos de recuperação para automatizar a ativação pós-falha da aplicação.