Visão geral das sondas de integridade do Application Gateway
O Gateway de Aplicativo do Azure monitora a integridade de todos os servidores em seu pool de back-end e interrompe automaticamente o envio de tráfego para qualquer servidor que considere não íntegro. Os testes continuam a monitorar esse servidor não íntegro, e o gateway começa a rotear o tráfego para ele mais uma vez assim que os testes o detetam como íntegro.
O teste padrão usa o número da porta da Configuração de back-end associada e outras configurações predefinidas. Você pode usar sondas personalizadas para configurá-las do seu jeito.
Comportamento das sondas
Endereço IP de origem
O endereço IP de origem dos testes depende do tipo de servidor back-end:
- Se o servidor no pool de back-end for um ponto de extremidade público, o endereço de origem será o endereço IP público de front-end do gateway de aplicativo.
- Se o servidor no pool de back-end for um ponto de extremidade privado, o endereço IP de origem será do espaço de endereço da sub-rede do gateway de aplicativo.
Operações de sonda
Um gateway começa a disparar testes imediatamente após configurar uma Regra, associando-a a uma Configuração de Back-end e Pool de Back-end (e ao Ouvinte, é claro). A ilustração mostra que o gateway investiga independentemente todos os servidores do pool de back-end. As solicitações de entrada que começam a chegar são enviadas apenas para os servidores íntegros. Um servidor back-end é marcado como não íntegro por padrão até que uma resposta de teste bem-sucedida seja recebida.
Os testes necessários são determinados com base na combinação exclusiva do Servidor de Back-end e da Configuração de Back-end. Por exemplo, considere um gateway com um único pool de back-end com dois servidores e duas configurações de back-end, cada um com números de porta diferentes. Quando essas configurações distintas de back-end são associadas ao mesmo pool de back-end usando suas respetivas regras, o gateway cria testes para cada servidor e a combinação da configuração de back-end. Você pode visualizar isso na página Integridade do back-end.
Além disso, todas as instâncias do gateway de aplicativo investigam os servidores back-end independentemente uns dos outros.
Intervalos da sonda
A mesma configuração de teste se aplica a cada instância do seu Application Gateway. Por exemplo, se um gateway de aplicativo tiver duas instâncias e o intervalo de teste estiver definido como 20 segundos, ambas as instâncias enviarão a investigação de integridade a cada 20 segundos.
Quando o teste deteta uma resposta com falha, o contador de "Limite não íntegro" é acionado e marca o servidor como não íntegro se a contagem de falhas consecutivas corresponder ao limite configurado. Assim, se você definir esse Limite Não Íntegro como 2, o teste subsequente detetará primeiro essa falha. O gateway de aplicativo marcará o servidor como não íntegro após 2 testes com falha consecutivos [Primeira deteção 20 segundos + (2 testes com falha consecutivos * 20 segundos)].
Nota
O relatório de integridade do back-end é atualizado com base no intervalo de atualização do respetivo teste e não depende da solicitação do usuário.
Sonda de integridade padrão
Um gateway de aplicativo configura automaticamente uma sonda de integridade padrão quando você não configura nenhuma configuração de teste personalizada. O comportamento de monitoramento funciona fazendo uma solicitação HTTP GET para os endereços IP ou FQDN configurados no pool de back-end. Para testes padrão, se as configurações http de back-end estiverem definidas para HTTPS, o teste usará HTTPS para testar a integridade dos servidores de back-end.
Por exemplo: você configura seu gateway de aplicativo para usar os servidores back-end A, B e C para receber tráfego de rede HTTP na porta 80. O monitoramento de integridade padrão testa os três servidores a cada 30 segundos para obter uma resposta HTTP íntegra com um tempo limite de 30 segundos para cada solicitação. Uma resposta HTTP saudável tem um código de status entre 200 e 399. Nesse caso, a solicitação HTTP GET para o teste de integridade se parece com http://127.0.0.1/. Consulte também Códigos de resposta HTTP no Application Gateway.
Se a verificação de teste padrão falhar para o servidor A, o gateway de aplicativo interromperá o encaminhamento de solicitações para esse servidor. O teste padrão ainda continua a verificar o servidor A a cada 30 segundos. Quando o servidor A responde com êxito a uma solicitação de uma investigação de integridade padrão, o gateway de aplicativo começa a encaminhar as solicitações para o servidor novamente.
Configurações padrão da sonda de integridade
| Propriedade da sonda | Valor | Descrição |
|---|---|---|
| URL da sonda | <protocolo>://127.0.0.1:<port>/ | O protocolo e a porta são herdados das configurações HTTP de back-end às quais a sonda está associada |
| Intervalo | 30 | A quantidade de tempo, em segundos, para aguardar antes que a próxima sonda de integridade seja enviada. |
| Limite de Tempo Excedido | 30 | A quantidade de tempo, em segundos, que o gateway de aplicativo aguarda uma resposta de teste antes de marcar a sonda como não íntegra. Se um teste retornar como íntegro, o back-end correspondente será imediatamente marcado como íntegro. |
| Limiar com funcionamento incorreto | 3 | Governa quantas sondas enviar em caso de falha da sonda de integridade regular. No SKU v1, essas sondas de integridade adicionais são enviadas em rápida sucessão para determinar a integridade do back-end rapidamente e não esperar pelo intervalo da sonda. Para o SKU v2, as sondas de integridade aguardam o intervalo. O servidor back-end é marcado para baixo depois que a contagem de falhas de teste consecutivas atinge o limite não íntegro. |
O teste padrão examina apenas protocol<>://127.0.0.1:<port> para determinar o status de integridade. Se você precisar configurar o teste de integridade para ir para uma URL personalizada ou modificar quaisquer outras configurações, deverá usar testes personalizados. Para obter mais informações sobre testes HTTPS, consulte Visão geral da terminação TLS e TLS de ponta a ponta com o Application Gateway.
Sonda de integridade personalizada
As sondas personalizadas permitem que você tenha um controle mais granular sobre o monitoramento de integridade. Ao usar testes personalizados, você pode configurar um nome de host personalizado, caminho de URL, intervalo de teste e quantas respostas com falha aceitar antes de marcar a instância do pool de back-end como não íntegra, etc.
Configurações personalizadas da sonda de integridade
A tabela a seguir fornece definições para as propriedades de uma sonda de integridade personalizada.
| Propriedade da sonda | Descrição |
|---|---|
| Name | Nome da sonda. Esse nome é usado para identificar e fazer referência ao teste nas configurações HTTP de back-end. |
| Protocolo | Protocolo usado para enviar a sonda. Isso tem que corresponder ao protocolo definido nas configurações HTTP de back-end às quais está associado |
| Host | Nome do host para enviar a sonda. Na SKU v1, esse valor é usado apenas para o cabeçalho do host da solicitação de teste. No SKU v2, ele é usado como cabeçalho de host e SNI |
| Caminho | Caminho relativo da sonda. Um caminho válido começa com '/' |
| Porta | Se definido, ele é usado como a porta de destino. Caso contrário, ele usa a mesma porta que as configurações HTTP às quais está associado. Esta propriedade só está disponível na v2 SKU |
| Intervalo | Intervalo da sonda em segundos. Este valor é o intervalo de tempo entre duas sondas consecutivas |
| Limite de Tempo Excedido | Tempo limite da sonda em segundos. Se uma resposta válida não for recebida dentro desse período de tempo limite, a sonda será marcada como falha |
| Limiar com funcionamento incorreto | Contagem de novas tentativas da sonda. O servidor back-end é marcado para baixo depois que a contagem de falhas consecutivas de teste atinge o limite não íntegro |
Correspondência de sonda
Por padrão, uma resposta HTTP(S) com código de status entre 200 e 399 é considerada íntegra. Além disso, as sondas de integridade personalizadas oferecem suporte a dois critérios de correspondência. Os critérios de correspondência podem ser usados para, opcionalmente, modificar a interpretação padrão do que torna uma resposta saudável.
Os critérios de correspondência são os seguintes:
- Correspondência de código de status de resposta HTTP - Critério de correspondência de sonda para aceitar códigos de resposta http especificados pelo usuário ou intervalos de códigos de resposta. Códigos de status de resposta separados por vírgulas individuais ou um intervalo de códigos de status são suportados.
- Correspondência de corpo de resposta HTTP - Critério de correspondência de teste que examina o corpo da resposta HTTP e corresponde a uma cadeia de caracteres especificada pelo usuário. A correspondência procura apenas a presença da cadeia de caracteres especificada pelo usuário no corpo da resposta e não é uma correspondência de expressão regular completa. A correspondência especificada deve ter 4090 caracteres ou menos.
Os critérios de correspondência podem ser especificados usando o New-AzApplicationGatewayProbeHealthResponseMatch cmdlet.
Por exemplo:
$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399
$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"
Os critérios de correspondência podem ser anexados à configuração da sonda usando um -Match operador no PowerShell.
Alguns casos de uso para sondas personalizadas
- Se um servidor back-end permitir acesso apenas a usuários autenticados, as sondas do gateway de aplicativo receberão um código de resposta 403 em vez de 200. Como os clientes (usuários) são obrigados a autenticar-se para o tráfego ao vivo, você pode configurar o tráfego de teste para aceitar 403 como uma resposta esperada.
- Quando um servidor back-end tem um certificado curinga (*.contoso.com) instalado para servir subdomínios diferentes, você pode usar uma sonda personalizada com um nome de host específico (necessário para SNI) que é aceito para estabelecer uma sonda TLS bem-sucedida e relatar esse servidor como íntegro. Com "substituir nome de host" na Configuração de back-end definida como NO, os diferentes nomes de host de entrada (subdomínios) serão passados como estão para o back-end.
Considerações sobre o NSG
O controle de grão fino sobre a sub-rede do Application Gateway por meio de regras NSG é possível na visualização pública. Estão disponíveis mais detalhes aqui.
Com a funcionalidade atual existem algumas restrições:
Você deve permitir o tráfego de entrada da Internet nas portas TCP 65503-65534 para a SKU do Application Gateway v1 e nas portas TCP 65200-65535 para a SKU v2 com a sub-rede de destino como Qualquer e origem como marca de serviço GatewayManager. Este intervalo de portas é necessário para a comunicação da infraestrutura do Azure.
Além disso, a conectividade de saída com a Internet não pode ser bloqueada e o tráfego de entrada proveniente da marca AzureLoadBalancer deve ser permitido.
Para obter mais informações, consulte Visão geral da configuração do Application Gateway.
Próximos passos
Depois de aprender sobre o monitoramento de integridade do Gateway de Aplicativo, você pode configurar uma investigação de integridade personalizada no portal do Azure ou uma investigação de integridade personalizada usando o PowerShell e o modelo de implantação do Azure Resource Manager.