Métodos de encaminhamento de tráfego para a origem

Importante

O Azure Front Door (clássico) será desativado em 31 de março de 2027. Para evitar qualquer interrupção do serviço, é importante migrar seus perfis do Azure Front Door (clássico) para a camada Azure Front Door Standard ou Premium até março de 2027. Para obter mais informações, consulte Aposentadoria (clássica) do Azure Front Door.

O Azure Front Door dá suporte a quatro métodos diferentes de roteamento de tráfego para determinar como seu tráfego HTTP/HTTPS é distribuído entre diferentes origens. Quando as solicitações do usuário chegam aos pontos de presença da Front Door, o método de roteamento configurado é aplicado para garantir que as solicitações sejam encaminhadas para o melhor recurso de back-end.

Nota

Uma Origem e um grupo de origem neste artigo referem-se ao pool de back-end e back-end da configuração (clássica) do Azure Front Door.

Os quatro métodos de roteamento de tráfego são:

• Latência: o roteamento baseado em latência garante que as solicitações sejam enviadas para as origens de latência mais baixas aceitáveis dentro de um intervalo de sensibilidade. Em outras palavras, as solicitações são enviadas para o conjunto de origens mais próximo em relação à latência da rede.

• Prioridade: uma prioridade pode ser definida para suas origens quando você deseja configurar uma origem primária para atender a todo o tráfego. A origem secundária pode ser um backup caso a origem primária fique indisponível.

• Ponderado: um valor ponderado pode ser atribuído às suas origens quando você deseja distribuir o tráfego por um conjunto de origens uniformemente ou de acordo com os coeficientes de peso. O tráfego é distribuído pelo valor de peso se as latências das origens estiverem dentro do intervalo de sensibilidade de latência aceitável no grupo de origem.

• Afinidade de sessão: Você pode configurar a afinidade de sessão para seus hosts ou domínios de front-end para garantir que as solicitações do mesmo usuário final sejam enviadas para a mesma origem.

Nota

O nome do ponto de extremidade na camada Standard e Premium do Azure Front Door é chamado de host Frontend no Azure Front Door (clássico).

Todas as configurações de porta frontal têm monitoramento de integridade de back-end e failover global instantâneo automatizado. Para obter mais informações, consulte Monitoramento de back-end de porta frontal. O Azure Front Door pode ser usado com um único método de roteamento. Dependendo das necessidades do seu aplicativo, você pode combinar vários métodos de roteamento para criar uma topologia de roteamento ideal.

Nota

Ao usar o mecanismo de regras do Front Door, você pode configurar uma regra para substituir as configurações de rota nas camadas Standard e Premium do Azure Front Door ou substituir o pool de back-end no Azure Front Door (clássico) para uma solicitação. O grupo de origem ou pool de back-end definido pelo mecanismo de regras substitui o processo de roteamento descrito neste artigo.

Fluxo de decisão global

O diagrama a seguir mostra o fluxo de decisão geral:

As etapas de decisão são:

1. Origens disponíveis: selecione todas as origens habilitadas e retornadas íntegras (200 OK) para a sonda de integridade.
   • Exemplo: Suponha que existem seis origens A, B, C, D, E e F, e entre elas C é insalubre e E é deficiente. A lista de origens disponíveis é A, B, D e F.
2. Prioridade: As origens prioritárias entre as disponíveis são selecionadas.
   • Exemplo: Suponha que a origem A, B e D têm prioridade 1 e a origem F tem prioridade 2. Então, as origens selecionadas são A, B e D.
3. Sinal de latência (com base na sonda de integridade): Selecione as origens dentro do intervalo de latência permitido no ambiente da porta da frente onde a solicitação chegou. Este sinal é baseado na configuração de sensibilidade de latência no grupo de origem e na latência das origens mais próximas.
   • Exemplo: Suponha que o Front Door tenha medido a latência do ambiente onde a solicitação chegou à origem A a 15 ms, enquanto a latência para B é de 30 ms e D está a 60 ms de distância. Se a sensibilidade de latência do grupo de origem for definida como 30 ms, o pool de latência mais baixo consistirá nas origens A e B, porque D está além de 30 ms de distância da origem mais próxima que é A.
4. Pesos: Por fim, o Azure Front Door roda o tráfego entre o grupo final selecionado de origens na proporção de pesos especificados.
   • Exemplo: Se a origem A tem um peso de 3 e a origem B tem um peso de 7, então o tráfego é distribuído 3/10 para as origens A e 7/10 para a origem B.

Se a afinidade de sessão estiver habilitada, a primeira solicitação em uma sessão seguirá o fluxo listado anteriormente. Os pedidos subsequentes são enviados para a origem selecionada no primeiro pedido.

Roteamento de tráfego baseado em latências mais baixas

A implantação de origens em dois ou mais locais em todo o mundo pode melhorar a capacidade de resposta de seus aplicativos, roteando o tráfego para o destino "mais próximo" de seus usuários finais. A latência é o método de encaminhamento de tráfego predefinido para a configuração do Front Door. Este método de encaminhamento reencaminha os pedidos dos utilizadores finais para a origem mais próxima atrás do Azure Front Door. Esse mecanismo de roteamento combinado com a arquitetura anycast do Azure Front Door garante que cada um dos seus usuários finais obtenha o melhor desempenho com base em sua localização.

A origem "mais próxima" não é necessariamente mais próxima, medida pela distância geográfica. Em vez disso, o Azure Front Door determina a origem mais próxima medindo a latência da rede. Leia mais sobre a arquitetura de roteamento do Azure Front Door.

Cada ambiente de porta da frente mede a latência de origem separadamente. Isso significa que diferentes usuários em locais diferentes são roteados para a origem com o melhor desempenho para esse ambiente.

Nota

Por padrão, a propriedade de sensibilidade de latência é definida como 0 ms. Com essa configuração, a solicitação é sempre encaminhada para as origens mais rápidas disponíveis e os pesos na origem não entram em vigor, a menos que duas origens tenham a mesma latência de rede.

Roteamento de tráfego baseado em prioridades

Muitas vezes, uma organização deseja fornecer alta disponibilidade para seus serviços implantando mais de um serviço de backup caso o principal fique inativo. Em todo o setor, esse tipo de topologia também é conhecido como implantação Ativa/Em Espera ou Ativa/Passiva. O método de roteamento de tráfego prioritário permite que você implemente facilmente esse padrão de failover.

O Azure Front Door padrão contém uma lista de prioridade igual de origens. Por padrão, o Azure Front Door envia tráfego apenas para as origens de prioridade superior (menor valor em prioridade) como o conjunto primário de origens. Se as origens primárias não estiverem disponíveis, o Azure Front Door encaminha o tráfego para o conjunto secundário de origens (segundo menor valor de prioridade). Se as origens primária e secundária não estiverem disponíveis, o tráfego vai para a terceira, e assim por diante. A disponibilidade da origem baseia-se no status configurado e no status de integridade de origem contínuo determinado pelas sondas de integridade.

Configurando a prioridade para origens

Cada origem no seu grupo de origem da configuração do Azure Front Door tem uma propriedade chamada Priority, que pode ser um número entre 1 e 5. Com o Azure Front Door, você pode configurar a prioridade de origem explicitamente usando essa propriedade para cada origem. Esta propriedade é um valor entre 1 e 5. Quanto menor o valor, maior a prioridade. As origens podem partilhar os mesmos valores de prioridade.

Método ponderado de encaminhamento de tráfego

O método de roteamento de tráfego ponderado permite distribuir o tráfego uniformemente ou usar uma ponderação predefinida.

No método de roteamento de tráfego ponderado, você atribui um peso a cada origem na configuração da Porta da Frente do Azure do seu grupo de origem. O peso é um número inteiro que varia de 1 a 1000. Este parâmetro usa um peso padrão de 50.

Com a lista de origens disponíveis que têm uma sensibilidade de latência aceitável, o tráfego é distribuído com um mecanismo round-robin usando a proporção de pesos especificada. Se a sensibilidade de latência for definida como 0 milissegundos, essa propriedade não terá efeito a menos que haja duas origens com a mesma latência de rede.

O método ponderado permite alguns cenários úteis:

• Atualização gradual do aplicativo: fornece uma porcentagem do tráfego para rotear para uma nova origem e aumentar gradualmente o tráfego ao longo do tempo para colocá-lo em pé de igualdade com outras origens.
• Migração de aplicativos para o Azure: crie um grupo de origem com origens do Azure e externas. Ajuste o peso das origens para preferir as novas origens. Você pode configurar isso gradualmente, começando com as novas origens desativadas, em seguida, atribuindo-lhes os pesos mais baixos, aumentando-o lentamente para os níveis onde eles recebem mais tráfego. Depois, finalmente, desativar as origens menos preferidas e removê-las do grupo.
• Explosão na nuvem para capacidade adicional: expanda rapidamente uma implantação local na nuvem colocando-a atrás da porta da frente. Quando precisar de capacidade extra na nuvem, você pode adicionar ou habilitar mais origens e especificar qual parte do tráfego vai para cada origem.

Afinidade de sessão

Por padrão, sem afinidade de sessão, o Azure Front Door encaminha solicitações originadas do mesmo cliente para origens diferentes. Certos aplicativos com monitoração de estado ou, em determinados cenários, quando surgem solicitações do mesmo usuário, preferem a mesma origem para processar a solicitação inicial. O recurso de afinidade de sessão baseado em cookies é útil quando você deseja manter uma sessão de usuário na mesma origem. Quando você usa cookies gerenciados com SHA256 da URL de origem como identificador no cookie, o Azure Front Door pode direcionar o tráfego subsequente de uma sessão de usuário para a mesma origem para processamento.

A afinidade de sessão pode ser habilitada no nível do grupo de origem na camada Standard e Premium do Azure Front Door e no nível de host front-end no Azure Front Door (clássico) para cada um dos seus domínios (ou subdomínios) configurados. Uma vez habilitado, o Azure Front Door adiciona um cookie à sessão do usuário. Os cookies são chamados ASLBSA e ASLBSACORS. A afinidade de sessão baseada em cookies permite que o Front Door identifique diferentes usuários, mesmo que atrás do mesmo endereço IP, o que, por sua vez, permite uma distribuição mais uniforme do tráfego entre suas diferentes origens.

A duração do cookie é igual à da sessão do utilizador, pois, atualmente, o Front Door só suportada cookies de sessão.

Nota

Independentemente de onde está configurado, a afinidade de sessão é lembrada através do cookie de sessão do navegador no nível do domínio. Subdomínios sob o mesmo domínio curinga podem compartilhar a afinidade de sessão, desde que o mesmo navegador do usuário envie solicitações para o mesmo recurso de origem.

Procurações públicas podem interferir com a afinidade de sessão. Isso ocorre porque o estabelecimento de uma sessão requer que o Front Door adicione um cookie de afinidade de sessão à resposta, o que não pode ser feito se a resposta for armazenável em cache, pois interromperia os cookies de outros clientes que solicitam o mesmo recurso. Para proteger contra isso, a afinidade de sessão não será estabelecida se a origem enviar uma resposta em cache quando isso for tentado. Se a sessão já tiver sido estabelecida, não importa se a resposta da origem é armazenável em cache.

A afinidade de sessão será estabelecida nas seguintes circunstâncias, além dos cenários padrão não armazenáveis em cache:

• A resposta deve incluir o Cache-Control cabeçalho de no-store.
• Se a resposta contiver um Authorization cabeçalho, ela não deve expirar.
• A resposta é um código de status HTTP 302.

Próximos passos

• Saiba como criar uma Porta da Frente do Azure.
• Saiba como funciona o Azure Front Door.