Métodos de roteamento 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 que você migre 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, confira Desativação do Azure Front Door (clássico).

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

Observação

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

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 em 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 de rede.

• Prioridade: uma prioridade pode ser definida para as origens quando você deseja configurar uma origem primária para a manutenção de todo o tráfego. A origem secundária pode servir de backup, caso a origem primária fique indisponível.

• Ponderado: um valor ponderado pode ser atribuído às origens quando você deseja distribuir o tráfego em um conjunto de origens de maneira uniforme ou de acordo com os coeficientes de ponderação. O tráfego será distribuído pelo valor de ponderação, se as latências das origens estão no 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 os domínios ou hosts front-end para garantir que as solicitações do mesmo usuário final sejam enviadas para o mesmo back-end.

Observação

O nome do ponto de extremidade nas camadas Standard e Premium do Azure Front Door Standard é chamado de host Front-end no Azure Front Door (clássico).

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

Observação

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-Azure 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 geral

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 consideradas íntegras (200 OK) na investigação de integridade.
   • Exemplo: suponha que existem seis origens: A, B, C, D, E e F. Dentre elas, C não está íntegra e E está desabilitada. A lista de origens disponíveis é A, B, D e F.
2. Prioridade: são selecionadas as origens de prioridade máxima entre as disponíveis.
   • Exemplo: suponha que as origens A, B e D têm prioridade 1 e a origem F tem prioridade 2. Em seguida, as origens selecionadas são A, B e D.
3. Sinal de latência (com base na investigação de integridade): selecione as origens dentro do intervalo de latência permitido no ambiente do Front Door em que a solicitação chegou. Esse sinal se baseia na configuração de sensibilidade de latência do grupo de origem e na latência das origens mais próximas.
   • Exemplo: suponha que o Front Door mediu a latência do ambiente em que a solicitação chegou à origem A em 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, pois D está a mais de 30 ms da origem mais próxima, que é A.
4. Pesos: por fim, o Azure Front Door fará uma distribuição equilibrada do tráfego entre o grupo de origens final selecionado na proporção de pesos especificada.
   • Exemplo: se a origem A tiver um peso igual a 3 e a origem B tiver um peso igual a 7, o tráfego será distribuído na proporção de 3/10 para as origens A e de 7/10 para as origens B.

Se a afinidade de sessão estiver habilitada, a primeira solicitação em uma sessão seguirá o fluxo listado anteriormente. As solicitações subsequentes serão enviadas para a origem selecionada na primeira solicitação.

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

A implantação de origens em dois ou mais locais no mundo pode melhorar a capacidade de resposta de seus aplicativos ao encaminhar o tráfego para o destino mais próximo do usuário final. A latência é o método de roteamento de tráfego padrão para a configuração do Front Door. Esse método de roteamento encaminha as solicitações dos usuários finais para a origem mais próxima do Azure Front Door. Esse mecanismo de roteamento combinado com a arquitetura anycast do Azure Front Door garante que cada um dos usuários finais obtenha o melhor desempenho de acordo com a respectiva localização.

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

Cada ambiente do Front Door mede a latência de origem separadamente. Isso significa que diferentes usuários em locais diferentes são encaminhados para a origem com o melhor desempenho para esse ambiente.

Observação

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 as ponderações na origem não entrarão em vigor, a menos que duas origens tenham a mesma latência de rede.

Roteamento de tráfego baseado em prioridade

Muitas vezes, uma organização deseja fornecer alta disponibilidade para seus serviços por meio da implantação de mais de um serviço de backup, caso o primário 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 de Prioridade permite que você implemente facilmente esse padrão de failover.

O Azure Front Door padrão contém uma lista de origens de igual prioridade. Por padrão, o Azure Front Door envia o tráfego apenas para as origens de prioridade máxima (o valor mais baixo de prioridade) como o conjunto primário de origens. Se as origens primárias não estiverem disponíveis, o Azure Front Door encaminhará o tráfego para o conjunto secundário de origens (o segundo valor mais baixo de prioridade). Se as origens primária e secundária não estiverem disponíveis, o tráfego passará para a terceira e assim por diante. A disponibilidade da origem depende do status configurado e do status contínuo de integridade da origem determinado pela investigações de integridade.

Configuração de prioridade para origens

Cada origem no grupo de origem da configuração do Azure Front Door tem uma propriedade chamada Prioridade, 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. Essa propriedade é um valor entre 1 e 5. Quanto menor o número, mais alta será a prioridade. As origens podem compartilhar os mesmos valores de prioridade.

Método de roteamento de tráfego ponderado

O método de roteamento de tráfego Ponderado permite que você distribua o tráfego de maneira uniforme ou use uma ponderação predefinida.

No método de roteamento de tráfego ponderado, você atribui uma ponderação a cada origem na configuração do Azure Front Door do grupo de origem. A ponderação é um inteiro que varia de 1 a 1.000. Esse parâmetro usa uma ponderação padrão de 50.

Com base na lista de origens disponíveis que possuem uma sensibilidade de latência aceitável, o tráfego é distribuído com um mecanismo de distribuição equilibrada, que usa a proporção entre as ponderações especificadas. Se a sensibilidade de latência for definida como 0 milissegundo, essa propriedade não entrará em vigor, a menos que haja duas origens com a mesma latência de rede.

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

• Atualização gradativa de aplicativo: fornece uma porcentagem do tráfego que deve ser encaminhado para uma nova origem e aumenta gradativamente o tráfego ao longo do tempo, até que esteja no mesmo nível das outras origens.
• Migração de aplicativo para o Azure: crie um pool de origens com as origens externas e do Azure. Ajuste a ponderação das origens para dar preferência às novas origens. Você pode configurar isso gradativamente, começando por desabilitar as novas origens e, em seguida, atribuir a elas as ponderações mais baixas, aumentando lentamente para os níveis em que elas recebem mais tráfego. Por fim, basta desabilitar as origens menos preferenciais e removê-las do grupo.
• Estouro de nuvem para capacidade adicional: expanda rapidamente uma implantação local na nuvem colocando-a atrás do Front Door. Quando você precisar de capacidade extra na nuvem, poderá 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 as solicitações provenientes do mesmo cliente para origens diferentes. Para determinados aplicativos com estado ou em determinados cenários, é preferível que as solicitações subsequentes do mesmo usuário sejam levadas para a mesma origem que processou a solicitação inicial. O recurso de afinidade de sessão baseada em cookies é útil quando você deseja manter uma sessão de usuário na mesma origem, como cenários em que os clientes se autenticam na origem. Quando você usa cookies gerenciados com SHA256 da URL de origem como o identificador no cookie, o Azure Front Door pode direcionar o tráfego 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 nas camadas Standard e Premium do Azure Front Door e no nível do host front-end no Azure Front Door (clássico) para cada um dos 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 de ASLBSA e ASLBSACORS. A afinidade de sessão baseada em cookie permite que o Front Door identifique os diferentes usuários, mesmo se estiverem por trás do mesmo endereço IP que, por sua vez, possibilita uma distribuição mais uniforme do tráfego entre as diferentes origens.

O tempo de vida do cookie é o mesmo que a sessão do usuário, visto que o Front Door é compatível apenas com cookies de sessão no momento.

Observação

Independentemente de onde esteja configurada, a afinidade de sessão é lembrada por meio do cookie de sessão do navegador no nível de domínio. Os subdomínios no mesmo domínio curinga podem compartilhar a afinidade de sessão, contanto que o mesmo navegador do usuário envie solicitações para o mesmo recurso de origem.

Proxies públicos podem interferir nas afinidade de sessão. Isso ocorre porque estabelecer uma sessão requer que o Front Door adicione um cookie de afinidade de sessão à resposta, o que não poderá ser realizado se a resposta for armazenável em cache, pois ela poderia atrapalhar os cookies de outros clientes que solicitam o mesmo recurso. Para evitar isso, a afinidade de sessão não será estabelecida, se a origem enviar uma resposta armazenável em cache ao tentar fazer isso. Se a sessão já tiver sido estabelecida, não importará se a resposta da origem for armazenável em cache ou não.

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

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

Próximas etapas

• Saiba como criar um Azure Front Door.
• Saiba como o Azure Front Door funciona.