Partilhar via

Redundância de roteamento global para aplicativos Web de missão crítica

Importante

Projetar implementações de redundância que lidam com interrupções globais da plataforma para uma arquitetura de missão crítica pode ser complexo e caro. Devido aos potenciais problemas que podem surgir com este design, considere cuidadosamente as compensações.

Na maioria das situações, você não precisará da arquitetura descrita neste artigo.

Os sistemas de missão crítica se esforçam para minimizar pontos únicos de falha, criando recursos de redundância e autorrecuperação na solução, tanto quanto possível. Qualquer ponto de entrada unificado do sistema pode ser considerado um ponto de falha. Se esse componente sofrer uma interrupção, todo o sistema ficará offline para o usuário. Ao escolher um serviço de roteamento, é importante considerar a confiabilidade do próprio serviço.

Na arquitetura de uma aplicação crítica para a missão, o Azure Front Door é escolhido devido ao seu acordo de nível de serviço (SLA) de alta disponibilidade e ao seu conjunto de funcionalidades rico:

  • Encaminhar o tráfego para múltiplas regiões, num modelo ativo-ativo ou ativo-passivo
  • Failover transparente usando TCP anycast
  • Sirva conteúdo estático a partir de nós de borda utilizando redes de entrega de conteúdo integradas (CDNs)
  • Bloqueie o acesso não autorizado com o firewall integrado de aplicativos da Web

Para obter mais informações sobre os recursos do Azure Front Door, consulte Acelerar e proteger seu aplicativo Web com o Azure Front Door.

O Azure Front Door foi projetado para fornecer a máxima resiliência e disponibilidade não apenas para nossos clientes externos, mas também para várias propriedades na Microsoft. Embora a Microsoft ofereça um acordo de nível de serviço (SLA) líder na indústria para o Azure Front Door, se tiver uma aplicação crítica que exige um SLA ainda mais elevado, terá de implementar caminhos adicionais de tráfego de entrada.

Muitas grandes organizações e propriedades da Web de alto perfil usam essa abordagem para garantir a maior disponibilidade possível e otimizar o desempenho de entrega. No entanto, a procura de um SLO mais elevado acarreta custos significativos, custos operacionais e pode, inadvertidamente, reduzir a sua fiabilidade global. Considere cuidadosamente as compensações e os problemas potenciais que o caminho alternativo pode introduzir noutros componentes ao longo do caminho crítico. Mesmo quando o impacto da indisponibilidade é significativo, a complexidade pode superar o benefício.

Uma abordagem é definir um caminho secundário com serviços alternativos, que se torna o caminho principal quando o Azure Front Door não está disponível. Não trate a paridade de funcionalidades com o Azure Front Door como um requisito rigoroso. Priorize os recursos de que você absolutamente precisa para fins de continuidade de negócios, mesmo potencialmente executados em uma capacidade limitada.

Múltiplas estratégias podem alcançar alta disponibilidade em cargas de trabalho web. A abordagem seguinte fornece uma solução de emergência manual e direta que lhe permite fazer um failover rápido durante uma falha e restaurar o tráfego para o Azure Front Door depois de verificar se o serviço está saudável.

Este artigo descreve estratégias para o encaminhamento global. Estas estratégias usam o Azure Traffic Manager para direcionar o tráfego para um router alternativo quando o Azure Front Door não está disponível.

Abordagem

Este diagrama de arquitetura mostra uma abordagem geral que tem múltiplos caminhos de tráfego redundantes.

Diagrama que mostra o Traffic Manager a direcionar pedidos para o Azure Front Door ou para outro serviço, e depois para o servidor de origem.

Esta abordagem introduz vários componentes e fornece orientações que fazem alterações significativas associadas à entrega das suas aplicações web:

  • O Traffic Manager direciona o tráfego para o Azure Front Door ou para o serviço alternativo escolhido.

    O Traffic Manager é um balanceador de carga global baseado em Sistema de Nomes de Domínio (DNS). O registro CNAME do seu domínio aponta para o Gerenciador de Tráfego, que determina o destino com base em como você configura seu método de roteamento. Para uma arquitetura crítica, recomendamos o método de roteamento ponderado . Pode configurar este método para enviar parte ou todo o tráfego para diferentes endpoints. Em operações normais, todo o seu tráfego normalmente passa pela Azure Front Door.

    Recomendamos que desligue a monitorização de endpoints no Gestor de Tráfego. Crie procedimentos para detetar quando o seu caminho principal de tráfego se torna indisponível e mude o tráfego para o caminho secundário.

    Também pode usar um sistema de encaminhamento global de tráfego diferente. Mas o Gestor de Tráfego funciona bem em muitas situações.

  • Você tem dois caminhos de entrada:

    • Azure Front Door fornece a rota principal. Em operações normais, processa e encaminha todo ou a maior parte do tráfego da sua aplicação.

    • Outro router serve como backup para o Azure Front Door. O tráfego passa por este caminho secundário se a Azure Front Door ficar indisponível.

    O serviço específico que você seleciona para o roteador secundário depende de muitos fatores. Pode optar por usar serviços nativos Azure ou serviços externos. Estes artigos fornecem opções nativas Azure, sempre que possível, para evitar adicionar complexidade operacional adicional à solução. Se usar serviços externos, deve utilizar múltiplos planos de controlo para gerir a sua solução.

  • Seus servidores de aplicativos de origem precisam estar prontos para aceitar tráfego de qualquer serviço. Considere como você protege o tráfego para sua origem e quais responsabilidades o Azure Front Door e outros serviços upstream fornecem. Certifique-se de que seu aplicativo possa lidar com o tráfego de qualquer caminho pelo qual o tráfego flua.

Vantagens e desvantagens

Embora essa estratégia de mitigação possa tornar o aplicativo disponível durante interrupções da plataforma, há algumas compensações significativas. Deve ponderar os benefícios potenciais em relação aos custos conhecidos e tomar uma decisão informada sobre se os benefícios valem a pena.

  • Custo financeiro: ao implantar vários caminhos redundantes em seu aplicativo, você precisa considerar o custo de implantação e execução dos recursos. Fornecemos dois cenários de exemplo para diferentes casos de uso, cada um com um perfil de custo diferente.

  • Complexidade operacional: Toda vez que você adiciona componentes adicionais à sua solução, aumenta a sobrecarga de gerenciamento. Qualquer alteração em um componente pode afetar outros componentes.

    Por exemplo, se usar novas funcionalidades do Azure Front Door, deve verificar se o seu caminho alternativo de tráfego também oferece uma funcionalidade equivalente. Se não for o caso, decida como lidar com a diferença de comportamento entre as duas rotas de tráfego. Em aplicações do mundo real, estas complexidades podem ter um custo elevado e representar um grande risco para a estabilidade do seu sistema.

  • Desempenho: Este design requer pesquisas CNAME adicionais durante a resolução de nomes. Na maioria dos aplicativos, essa não é uma preocupação significativa, mas você deve avaliar se o desempenho do aplicativo é afetado pela introdução de camadas adicionais no caminho de entrada.

  • Custo de oportunidade: Projetar e implementar caminhos de entrada redundantes requer um investimento significativo em engenharia, o que, em última análise, tem um custo de oportunidade para o desenvolvimento de funcionalidades e outras melhorias na plataforma.

Advertência

Se você não for cuidadoso na forma como projeta e implementa uma solução complexa de alta disponibilidade, pode realmente piorar sua disponibilidade. Aumentar o número de componentes em sua arquitetura aumenta o número de pontos de falha. Isso também significa que você tem um nível mais alto de complexidade operacional. Quando você adiciona componentes extras, cada alteração feita precisa ser cuidadosamente revisada para entender como isso afeta sua solução geral.

Disponibilidade do Gestor de Tráfego

O Traffic Manager é um serviço fiável com um SLA líder no setor, mas a gestão do tráfego necessita de medidas adicionais para garantir disponibilidade ininterrupta em todas as situações. Se o Traffic Manager não estiver disponível, os seus utilizadores podem não ter acesso à sua aplicação, mesmo que o Azure Front Door e o seu serviço alternativo estejam ambos disponíveis. Planeie como a sua solução pode continuar a funcionar nestas circunstâncias.

O Gerenciador de Tráfego retorna respostas DNS armazenáveis em cache. Se o tempo de vida (TTL) em seus registros DNS permitir o armazenamento em cache, interrupções curtas do Gerenciador de Tráfego podem não ser uma preocupação. Isso ocorre porque os resolvedores de DNS downstream podem ter armazenado em cache uma resposta anterior. Você deverá planear interrupções prolongadas. Você pode optar por reconfigurar manualmente seus servidores DNS para direcionar os usuários para o Azure Front Door se o Gerenciador de Tráfego não estiver disponível.

Consistência de roteamento de tráfego

É importante entender as capacidades e funcionalidades do Azure Front Door que o utilizador utiliza e nas quais confia, se também for utilizar outro serviço. Ao escolher o serviço alternativo, decida os recursos mínimos necessários e omita outros recursos quando sua solução estiver em um modo degradado.

Ao planejar um caminho de tráfego alternativo, aqui estão algumas perguntas-chave que você deve considerar:

  • Você usa os recursos de cache do Azure Front Door? Se o cache não estiver disponível, seus servidores de origem podem acompanhar seu tráfego?
  • Você usa o mecanismo de regras do Azure Front Door para executar lógica de roteamento personalizada ou para reescrever solicitações?
  • Você usa o firewall de aplicativo Web (WAF) do Azure Front Door para proteger seus aplicativos?
  • Você restringe o tráfego com base no endereço IP ou na geografia?
  • Quem emite e gerencia seus certificados TLS?
  • Como você restringe o acesso aos seus servidores de aplicativos de origem para garantir que ele chegue através da Porta da Frente do Azure? Você usa o Private Link ou confia em endereços IP públicos com tags de serviço e cabeçalhos de identificador?
  • Seus servidores de aplicativos aceitam tráfego de qualquer lugar que não seja o Azure Front Door? Em caso afirmativo, que protocolos aceitam?
  • Os seus clientes utilizam o suporte HTTP/2 do Azure Front Door?

Firewall de aplicações Web (WAF)

Se você usar o WAF do Azure Front Door para proteger seu aplicativo, considere o que acontece se o tráfego não passar pelo Azure Front Door.

Se o seu caminho alternativo também fornece um WAF, considere as seguintes perguntas:

  • Pode ser configurado da mesma forma que o seu Azure Front Door WAF?
  • Precisa de ser ajustado e testado de forma independente, para reduzir a probabilidade de deteções de falsos positivos?

Advertência

Você pode optar por não usar um WAF para seu caminho de entrada alternativo. Esta abordagem pode apoiar o objetivo de fiabilidade da aplicação. Mas não segue boas práticas de segurança, e não o recomendamos.

Considere a contrapartida em aceitar tráfego da internet sem qualquer verificação. Se um invasor descobrir um caminho de tráfego secundário desprotegido para seu aplicativo, ele poderá enviar tráfego mal-intencionado pelo caminho secundário, mesmo quando o caminho primário incluir um WAF.

É melhor proteger todos os caminhos para seus servidores de aplicativos.

Considerações adicionais para alta disponibilidade

Quando você está projetando uma arquitetura da Web de missão crítica, há muitos fatores que podem afetar a disponibilidade e o desempenho do seu aplicativo. Muitos desses fatores vão além da configuração e dos recursos do Azure Front Door e, em vez disso, estão relacionados ao ecossistema geral e ao design da solução.

Nomes de domínio e DNS

Seu aplicativo de missão crítica deve usar nomes de domínio personalizados para controlar como o tráfego flui para seu aplicativo e reduzir as dependências de um único provedor. Considere os seguintes pontos ao planear a sua abordagem DNS:

  • Serviço DNS: Use um serviço DNS de alta qualidade e resiliente para o seu nome de domínio, como Azure DNS. Se os servidores DNS do seu nome de domínio não estiverem disponíveis, os utilizadores não poderão aceder ao seu serviço.

  • Resolvedores DNS: Recomendamos que utilize múltiplos resolvers DNS para aumentar a resiliência global.

  • Domínios de ápice: Quando usa o Traffic Manager, utiliza um CNAME para apontar o seu nome de domínio para o perfil do Traffic Manager. Os padrões DNS não permitem criar um CNAME no ápice (ou raiz) de um domínio. Aloja o teu domínio DNS no Azure DNS e usa registos de alias para apontar para o teu perfil no Traffic Manager.

  • Encadeamento CNAME: Soluções que combinam o Traffic Manager, Azure Front Door e outros serviços utilizam um processo de resolução de DNS CNAME em várias camadas, também conhecido como encadeamento CNAME. Por exemplo, quando você resolve seu próprio domínio personalizado, pode ver cinco ou mais registros CNAME antes que um endereço IP seja retornado.

    Adicionar mais ligações a uma cadeia CNAME pode afetar o desempenho da resolução de nomes DNS. Mas as respostas DNS são geralmente armazenadas em cache, o que reduz o impacto no desempenho.

Certificados TLS

Para um aplicativo de missão crítica, é recomendável provisionar e usar seus próprios certificados TLS em vez dos certificados gerenciados fornecidos pelo Azure Front Door. Você reduz o número de problemas potenciais com essa arquitetura complexa.

Aqui estão alguns benefícios:

  • Para emitir e renovar certificados TLS gerenciados, o Azure Front Door verifica sua propriedade do domínio. O processo de verificação de domínio pressupõe que os registos CNAME do seu domínio apontam diretamente para a Porta da Frente do Azure. Mas, essa suposição muitas vezes não está correta. Emitir e renovar certificados TLS gerenciados no Azure Front Door pode não funcionar sem problemas e você aumenta o risco de interrupções devido a problemas de certificado TLS.

  • Mesmo que seus outros serviços forneçam certificados TLS gerenciados, talvez não consigam verificar a propriedade do domínio.

  • Se cada serviço obtiver os seus próprios certificados TLS geridos de forma independente, podem surgir problemas. Por exemplo, os utilizadores podem não esperar ver certificados TLS emitidos por diferentes autoridades ou certificados com datas de validade ou impressões digitais diferentes.

No entanto, há operações adicionais relacionadas à renovação e atualização de seus certificados antes que eles expirem.

Segurança de origem

Ao configurar sua origem para aceitar apenas tráfego por meio da Porta da Frente do Azure, você ganha proteção contra ataques DDoS de camada 3 e camada 4. O Azure Front Door responde apenas ao tráfego HTTP válido, o que também ajuda a reduzir a sua exposição a muitas ameaças baseadas em protocolo. Se você alterar sua arquitetura para permitir caminhos de entrada alternativos, precisará avaliar se aumentou acidentalmente a exposição de sua origem a ameaças.

Se você usar o Private Link para se conectar do Azure Front Door ao seu servidor de origem, como o tráfego flui pelo seu caminho alternativo? Você pode usar endereços IP privados para acessar suas origens ou deve usar endereços IP públicos?

Se sua origem usa a marca de serviço do Azure Front Door e o cabeçalho X-Azure-FDID para validar que o tráfego fluiu pelo Azure Front Door, considere como suas origens podem ser reconfiguradas para validar que o tráfego fluiu por qualquer um dos seus caminhos válidos. Você deve testar se não abriu acidentalmente sua origem para o tráfego por outros caminhos, inclusive dos perfis do Azure Front Door de outros clientes.

Ao planejar sua segurança de origem, verifique se o caminho de tráfego alternativo depende do provisionamento de endereços IP públicos dedicados. Isso pode precisar de um processo acionado manualmente para colocar o caminho de backup online.

Se houver endereços IP públicos dedicados, considere se você deve implementar a Proteção contra DDoS do Azure para reduzir o risco de ataques de negação de serviço contra suas origens. Além disso, considere se precisa de implementar o Azure Firewall ou outro firewall capaz de o proteger contra várias ameaças de rede. Você também pode precisar de mais estratégias de deteção de intrusão. Esses controles podem ser elementos importantes em uma arquitetura de vários caminhos mais complexa.

Modelagem de saúde

A metodologia de projeto de missão crítica requer um modelo de integridade do sistema que ofereça observabilidade geral da solução e de seus componentes. Ao usar vários caminhos de entrada de tráfego, você precisa monitorar a integridade de cada caminho. Se o tráfego for redirecionado para o caminho de entrada secundário, o modelo de integridade deverá refletir o fato de que o sistema ainda está operacional, mas está sendo executado em um estado degradado.

Inclua estas perguntas no design do seu modelo de saúde:

  • Como é que os diferentes componentes da sua solução monitorizam o estado dos componentes a jusante?
  • Quando os monitores de saúde devem considerar que os componentes a jusante não estão íntegros?
  • Quanto tempo demora para uma interrupção ser detetada?
  • Depois que uma interrupção é detetada, quanto tempo leva para o tráfego ser roteado por um caminho alternativo?

Monitorização de saúde

As soluções globais de balanceamento de carga permitem mudar para uma plataforma secundária caso ocorra uma falha. O Traffic Manager funciona bem para a maioria dos cenários.

Quando usar o Traffic Manager com o Azure Front Door, utilize a sua própria solução externa ou personalizada de monitorização para detetar quando o Azure Front Door se torna indisponível e iniciar os seus processos de resposta. O Azure Front Door é um sistema distribuído globalmente que utiliza rede anycast, por isso deve realizar verificações de conectividade a partir das mesmas regiões geográficas que os seus clientes.

Importante

Para cargas de trabalho globais que requerem validação de saúde em múltiplas geografias, desative a monitorização de endpoints do Traffic Manager e utilize procedimentos manuais de failover.

Prepare-se também para ativar manualmente os seus procedimentos de resposta se os seus sistemas de monitorização não detetarem o problema.

Procedimentos de resposta

Se os seus sistemas de monitorização detetarem que o Azure Front Door não está disponível, reconfigure o Traffic Manager para direcionar todo o tráfego pelo seu caminho alternativo. Use uma das seguintes abordagens:

Importante

Redirecionar todo o tráfego pelo caminho secundário é uma solução de curto prazo que permite a continuidade do negócio durante uma interrupção contínua. Depois que a interrupção for resolvida, restaure as operações normais por meio do Azure Front Door assim que possível.

Múltiplos fatores influenciam o tempo que a interrupção afeta o seu tráfego, incluindo os seguintes fatores:

  • Valores TTL de registos DNS

  • Fonte de deteção de falhas (Gestor de Tráfego ou monitorização personalizada)

  • Frequência dos exames de saúde

  • Limiar de falha na verificação de saúde antes do sistema redirecionar o tráfego

  • Duração da cache DNS do cliente e a montante para respostas do Gestor de Tráfego

Você também precisa determinar quais desses fatores estão sob seu controle e se os serviços upstream além do seu controle podem afetar a experiência do usuário. Por exemplo, mesmo que você use TTL baixo em seus registros DNS, os caches DNS upstream ainda podem fornecer respostas obsoletas por mais tempo do que deveriam. Esse comportamento pode exacerbar os efeitos de uma interrupção ou fazer parecer que seu aplicativo está indisponível, mesmo quando o Gerenciador de Tráfego já mudou para enviar solicitações para o caminho de tráfego alternativo.

Sugestão

Soluções críticas para a operação requerem abordagens automáticas de recuperação sempre que possível. Os processos manuais de failover são demasiado lentos para manter a aplicação responsiva.

Consulte a: Área de design de missão crítica: Modelagem de saúde

Processos de reconfiguração resilientes

Quando planeias como operar uma solução que usa um caminho de entrada redundante, planeia também como implementar ou configurar os teus serviços quando estes estiverem a correr num estado degradado. Para a maioria dos serviços Azure, os SLAs aplicam-se ao tempo de funcionamento do serviço em si, não a operações de gestão ou implementações. Considere se deve tornar os seus processos de implementação e configuração resilientes a falhas de serviço.

Ao planear a sua estratégia de failover, evite depender de uma única ferramenta como o portal Azure, caso a sua conectividade seja interrompida. Compreenda como usar ferramentas como o Azure CLI, Azure PowerShell ou APIs REST para realizar tarefas de reconfiguração como redirecionar o seu tráfego. Para mais informações sobre comandos de exemplo para scripts de failover, consulte Procedimentos de resposta.

Deve também considerar com quantos planos de controlo independentes precisa de interagir para gerir a sua solução. Quando você usa os serviços do Azure, o Azure Resource Manager fornece um plano de controle unificado e consistente. Mas se usar um serviço externo para encaminhar tráfego, pode ser necessário usar um plano de controlo separado para configurar o serviço, o que introduz maior complexidade operacional.

Advertência

O uso de vários planos de controle introduz complexidade e risco à sua solução. Cada ponto de diferença aumenta a probabilidade de alguém acidentalmente perder uma definição de configuração ou aplicar configurações diferentes a componentes redundantes. Certifique-se de que seus procedimentos operacionais reduzam esse risco.

Consulte: Área de projeto essencial para a missão: implantação sem interrupção

Validação contínua

Para uma solução de missão crítica, suas práticas de teste precisam verificar se a solução atende aos seus requisitos, independentemente do caminho pelo qual o tráfego do aplicativo flui. Considere cada parte da solução e como testá-la para cada tipo de interrupção.

Certifique-se de que seus processos de teste incluam estes elementos:

  • Você pode verificar se o tráfego é redirecionado corretamente pelo caminho alternativo quando o caminho principal não está disponível?
  • Ambos os caminhos conseguem suportar o nível de tráfego de produção que espera receber? O caminho secundário está pronto para receber tráfego de produção com aviso mínimo ou nenhum?
  • Ambos os caminhos estão adequadamente protegidos, para evitar abrir ou expor vulnerabilidades quando se está num estado degradado?

Consulte : Área de projeto de missão crítica: Validação contínua

Cenários comuns

Aqui estão os cenários comuns em que esse design pode ser usado:

  • A entrega de conteúdo global geralmente se aplica à entrega de conteúdo estático, mídia e aplicativos de comércio eletrônico de alta escala. Nesse cenário, o cache é uma parte crítica da arquitetura da solução, e falhas no cache podem resultar em desempenho ou confiabilidade significativamente degradados.

  • A entrada HTTP global geralmente se aplica a APIs e aplicativos dinâmicos de missão crítica. Nesse cenário, o requisito principal é rotear o tráfego para o servidor de origem de forma confiável e eficiente. Frequentemente, um WAF é um importante controle de segurança usado nessas soluções.

Advertência

Se não fores cuidadoso na forma como projetares e implementares uma solução complexa de multi-ingresso, pode realmente piorar a tua disponibilidade. Aumentar o número de componentes em sua arquitetura aumenta o número de pontos de falha. Isso também significa que você tem um nível mais alto de complexidade operacional. Quando você adiciona componentes extras, cada alteração feita precisa ser cuidadosamente revisada para entender como isso afeta sua solução geral.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

  • Dave Burkhardt | Gerente de Programa Principal, Azure Front Door
  • John Downs | Engenheiro de Software Principal, Azure Patterns & Practices
  • Akhil Karmalkar | Gestor Principal de Programas, Azure Front Door
  • Priyanka Wilkins | Desenvolvedora de Conteúdos Principal, Azure Patterns & Practices

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Próximos passos

  • Last updated on