Visão geral das investigações de integridade do Gateway de Aplicativo
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. As investigações 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 as investigações o detectam como íntegro.
A investigação padrão usa o número da porta da Configuração de Back-end associada e outras configurações predefinidas. Você pode usar investigações personalizadas para configurá-los do seu jeito.
Comportamento de investigações
Endereço IP de origem
O endereço IP de origem das investigações 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 investigação
Um gateway começa a disparar investigações imediatamente após você configurar uma Regra, associando-a a uma Configuração de Back-end e a um 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 investigação bem-sucedida seja recebida.
As investigações necessários são determinados com base na combinação exclusiva da Configuração de Servidor de Back-end e 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 de back-end distintas são associadas ao mesmo pool de back-end usando suas respectivas regras, o gateway cria investigações para cada servidor e a combinação da configuração de back-end. Você pode exibir isso na página de integridade do back-end.
Além disso, todas as instâncias do gateway de aplicativo examinam os servidores back-end independentemente umas das outras.
Intervalos de investigação
A mesma configuração de investigação se aplica a cada instância do Gateway de Aplicativo. Por exemplo, se um gateway de aplicativo tiver duas instâncias e o intervalo de investigação for definido como 20 segundos, ambas as instâncias enviarão a investigação de integridade a cada 20 segundos.
Depois que a investigação detecta 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, a investigação subsequente detectará primeiro essa falha. O gateway de aplicativo marcará o servidor como não íntegro após 2 investigações com falha consecutivos [Primeira detecção 20 segundos + (2 investigações com falha consecutivos * 20 segundos)].
Observação
O relatório de integridade do back-end é atualizado com base no intervalo de atualização da respectiva investigação e não depende da solicitação do usuário.
Investigação de integridade padrão
Um Application Gateway configura automaticamente uma investigação de integridade padrão quando você não define nenhuma configuração de investigação personalizada. O comportamento de monitoramento funciona com uma solicitação HTTP GET para os endereços IP ou o FQDN configurados no pool de back-end. Para investigações padrão, se as configurações de HTTP de back-end estão configuradas para HTTPS, a investigação usa HTTPS para testar a integridade dos servidores back-end.
Por exemplo: você configura o gateway de aplicativo para usar os servidores back-end A, B e C para receber o 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 de HTTP íntegra tem um código de status entre 200 e 399. Nesse caso, a solicitação HTTP GET para a investigação de integridade se parece com http://127.0.0.1/. Consulte também códigos de resposta HTTP no Gateway de Aplicativo.
Se a investigação de verificação padrão falhar para o servidor A, o gateway de aplicativo para de encaminhar solicitações a esse servidor. A investigação 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 da investigação de integridade padrão
| Propriedades da investigação | Valor | Descrição |
|---|---|---|
| URL de investigação | <protocol>://127.0.0.1:<port>/ | O protocolo e a porta são herdados das configurações HTTP de back-end às quais a investigação está associada |
| Intervalo | 30 | A quantidade de tempo em segundos a esperar antes da próxima investigação de integridade é enviada. |
| Tempo limite | 30 | A quantidade de tempo em segundos o gateway de aplicativo aguarda uma resposta de investigação antes da marcação da investigação como não íntegro. Se uma investigação é retornada como íntegra, o back-end correspondente será imediatamente marcado como íntegro. |
| Limite não íntegro | 3 | Controla quantas investigações enviar caso ocorra uma falha da investigação de integridade regular. Na SKU v1, essas investigações de integridade adicionais são enviadas em sucessão rápida para determinar a integridade do back-end rapidamente e não é preciso esperar o intervalo de investigação. No caso do SKU v2, as investigações de integridade esperam o intervalo. O servidor back-end é marcado após a contagem de falhas de investigação consecutivas atingir o limite de não íntegro. |
A investigação padrão examina apenas <protocol>://127.0.0.1:<port> para determinar o status de integridade. Se precisar configurar a investigação de integridade para ir para uma URL personalizada ou modificar outras configurações, você deverá usar investigações personalizadas. Para obter mais informações sobre investigações HTTPS, veja Visão geral da terminação de TLS e TLS de ponta a ponta com o Gateway de Aplicativo.
Investigação de integridade personalizada
Investigações personalizadas permitem que você tenha um controle mais granular sobre o monitoramento de integridade. Ao usar investigações personalizadas, você pode configurar um nome do host personalizado, um caminho de URL, um intervalo de investigação, o número de respostas com falha que serão aceitas antes de marcar a instância do pool de back-end como não íntegra etc.
Configurações da investigação de integridade personalizada
A tabela a seguir fornece definições para as propriedades de uma investigação de integridade personalizada.
| Propriedades da investigação | Descrição |
|---|---|
| Nome | O nome da investigação. Esse nome é usado para identificar a investigação nas configurações de HTTP de back-end e se referir a ela. |
| Protocolo | O protocolo usado para enviar a investigação. Isso deve corresponder ao protocolo definido nas configurações HTTP de back-end ao qual está associado |
| Host | O nome do host para enviar a investigação. Na SKU v1, esse valor é usado somente para o cabeçalho de host da solicitação de investigação. No SKU v2, ele é usado como cabeçalho de host e SNI |
| Caminho | O caminho relativo da investigação. Um caminho válido começa com "/" |
| Porta | Se definida, ela será usada como a porta de destino. Caso contrário, ele usará a mesma porta que as configurações HTTP às quais está associado. Essa propriedade só está disponível na SKU v2 |
| Intervalo | Intervalo de investigação em segundos. Este valor é o intervalo de tempo entre duas investigações consecutivas |
| Tempo limite | Tempo limite da investigação em segundos. Se uma resposta válida não for recebida nesse período limite, a investigação será marcada como com falha |
| Limite não íntegro | Contagem de repetições da investigação. O servidor back-end é marcado como inativo após a contagem de falhas de investigação consecutivas atingir o limite de não íntegro |
Correspondência de investigação
Por padrão, uma resposta HTTP(S) com código de status entre 200 e 399 é considerada íntegra. As investigações de integridade personalizadas também fornecem suporte a dois critérios correspondentes. Critérios de correspondência podem ser utilizados para, opcionalmente, mudar a interpretação padrão do que constitui uma resposta íntegra.
A seguir estão os critérios de correspondência:
- Correspondência de código de status de resposta HTTP - Critério de correspondência de teste para aceitar o código de resposta HTTP ou intervalos de códigos de resposta especificados pelo usuário. Códigos de status de resposta separados por vírgulas individuais ou um intervalo de código de status têm suporte.
- Correspondência do corpo da resposta HTTP - Critério de correspondência da análise 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 de uma 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 cmdlet New-AzApplicationGatewayProbeHealthResponseMatch.
Por exemplo:
$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399
$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"
Os critérios de correspondência podem ser anexados à configuração de investigação usando um operador -Match no PowerShell.
Alguns casos de uso para investigação personalizados
- Se um servidor back-end permitir acesso apenas a usuários autenticados, as investigações 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 em tempo real, você pode configurar o tráfego de investigação para aceitar 403 como uma resposta esperada.
- Quando um servidor back-end tem um certificado curinga (*.contoso.com) instalado para atender a diferentes subdomínios, você pode usar uma investigação personalizada com um nome de host específico (necessário para SNI) que é aceito para estabelecer uma investigação TLS bem-sucedida e relatar esse servidor como íntegro. Com "substituir nome de host" na Configuração de back-end definida como NÃO, os diferentes nomes de host de entrada (subdomínios) serão passados como estão para o back-end.
Considerações NSG
O controle de granularidade sobre a sub-rede do Gateway de Aplicativo por meio de regras NSG é possível na visualização pública. Encontre mais detalhes aqui.
Com a funcionalidade atual, existem algumas restrições:
Você precisa permitir o tráfego de entrada na Internet nas portas TCP 65503-65534 para a SKU do Gateway de Aplicativo v1 e as portas TCP 65200-65535 para a SKU V2 com a sub-rede de destino como Qualquer e a origem como a marca de serviço GatewayManager. Esse intervalo de porta é necessário para a comunicação da infraestrutura do Azure.
Além disso, a conectividade de Internet de saída não pode ser bloqueada, e o tráfego de entrada proveniente da marca AzureLoadBalancer deve ser permitido.
Para obter mais informações, confira Visão geral da configuração do Gateway de Aplicativo.
Próximas etapas
Depois de aprender sobre o monitoramento de integridade do Gateway de Aplicativo, você poderá 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.