Sondas do estado de funcionamento
Nota
Um grupo Origem e origem neste artigo referem-se ao conjunto de back-end e back-end da configuração do Azure Front Door (clássico).
Para determinar o estado de funcionamento e a proximidade de cada back-end para um determinado ambiente do Azure Front Door, cada ambiente do Front Door envia periodicamente um pedido HTTP/HTTPS sintético para cada uma das origens configuradas. Em seguida, o Azure Front Door utiliza estas respostas da sonda para determinar a origem "melhor" para encaminhar os seus pedidos de cliente.
Aviso
Uma vez que cada POP do Azure Front Door emite sondas de estado de funcionamento para as suas origens, o volume da sonda de estado de funcionamento para as suas origens pode ser bastante elevado. O número de pesquisas depende da localização de tráfego do cliente e da frequência da sonda de estado de funcionamento. Se o POP de extremidade do Azure Front Door não receber tráfego real dos seus utilizadores finais, a frequência da pesquisa de estado de funcionamento do EDGE POP é diminuída da frequência configurada. Se existir tráfego do cliente para todo o POP de extremidade do Azure Front Door, o volume da sonda de estado de funcionamento pode ser elevado consoante a frequência das pesquisas de estado de funcionamento.
Um exemplo para estimar aproximadamente o volume da sonda de estado de funcionamento por minuto para a sua origem ao utilizar a frequência de pesquisa predefinida de 30 segundos. O volume da pesquisa em cada uma das origens é igual ao número de POPs edge vezes dois pedidos por minuto. Os pedidos de pesquisa serão menores se não houver tráfego enviado para todos os POPs edge. Para obter uma lista de localizações de limites, veja Localizações de limite por região para o Azure Front Door. Pode haver mais do que um POP em cada localização de limite.
Nota
As sondas HTTP/HTTPS do Azure Front Door são enviadas com User-Agent o cabeçalho definido com o valor: Edge Health Probe.
Protocolos suportados
O Azure Front Door suporta o envio de sondas através de protocolos HTTP ou HTTPS. Estas sondas são enviadas através das mesmas portas TCP configuradas para encaminhar pedidos do cliente e não podem ser anuladas.
Métodos HTTP suportados para sondas de estado de funcionamento
O Azure Front Door suporta os seguintes métodos HTTP para enviar as sondas de estado de funcionamento:
- GET: O método GET significa obter todas as informações (na forma de uma entidade) identificadas pelo Request-URI.
- CABEÇALHO: O método HEAD é idêntico a GET, exceto que o servidor NÃO DEVE devolver um corpo da mensagem na resposta. Por predefinição, para novos perfis do Front Door, o método de pesquisa é definido como HEAD.
Nota
Para uma carga e um custo mais baixos nos back-ends, o Front Door recomenda a utilização de pedidos HEAD para sondas de estado de funcionamento.
Respostas da sonda de estado de funcionamento
| Respostas | Description |
|---|---|
| Determinar o Estado de Funcionamento | Um código de estado 200 OK indica que o back-end está em bom estado de funcionamento. Tudo o resto é considerado um fracasso. Se, por algum motivo (incluindo a falha de rede), não for recebida uma resposta HTTP válida para uma sonda, a pesquisa será contabilizada como uma falha. |
| Medir Latência | A latência é o tempo do relógio de parede medido a partir do momento imediatamente antes de enviarmos o pedido da sonda para o momento em que recebemos o último byte da resposta. Utilizamos uma nova ligação TCP para cada pedido, pelo que esta medida não é tendenciosa para back-ends com ligações quentes existentes. |
Como o Front Door determina o estado de funcionamento do back-end
O Azure Front Door utiliza o mesmo processo de três passos abaixo em todos os algoritmos para determinar o estado de funcionamento.
Excluir back-ends desativados.
Exclua back-ends que tenham erros de sondas de estado de funcionamento:
Esta seleção é efetuada ao analisar as últimas respostas da sonda de estado de funcionamento. Se, pelo menos, x estiver em bom estado de funcionamento, o back-end é considerado em bom estado de funcionamento.
n é configurado ao alterar a propriedade SampleSize nas definições de balanceamento de carga.
x é configurado ao alterar a propriedade SuccessfulSamplesRequired nas definições de balanceamento de carga.
Para os conjuntos de back-end em bom estado de funcionamento no conjunto de back-end, o Front Door mede e mantém a latência (tempo de ida e volta) para cada back-end.
Nota
Se um único ponto final for membro de vários conjuntos de back-end, o Azure Front Door otimiza o número de sondas de estado de funcionamento enviadas para o back-end para reduzir a carga no back-end. Os pedidos de pesquisa de estado de funcionamento serão enviados com base no intervalo de exemplo configurado mais baixo. O estado de funcionamento do ponto final em todos os conjuntos será determinado pelas respostas das mesmas sondas de estado de funcionamento.
Falha completa da sonda de estado de funcionamento
Se as sondas de estado de funcionamento falharem para cada back-end num conjunto de back-end, o Front Door considera todos os back-end em mau estado de funcionamento e encaminha o tráfego numa distribuição round robin em todos eles.
Assim que qualquer back-end regressar a um estado de bom estado de funcionamento, o Front Door retomará o algoritmo normal de balanceamento de carga.
Desativar sondas de estado de funcionamento
Se tiver um único back-end no conjunto de back-end, pode optar por desativar as pesquisas de estado de funcionamento, reduzindo a carga no back-end da aplicação. Mesmo que tenha vários back-ends no conjunto de back-end, mas apenas um deles estiver no estado ativado, pode desativar as pesquisas de estado de funcionamento.
Passos seguintes
- Saiba como criar um perfil do Front Door.
- Saiba mais sobre a arquitetura de encaminhamento do Azure Front Door.