Sondas de integridade do Balanceador de Carga do Azure
Uma investigação de integridade do Balanceador de Carga do Azure é um recurso que deteta o status de integridade de suas instâncias de aplicativo. Ele envia uma solicitação às instâncias para verificar se elas estão disponíveis e respondendo às solicitações. A sonda de integridade pode ser configurada para usar diferentes protocolos, como TCP, HTTP ou HTTPS. É um recurso importante porque ajuda você a detetar falhas de aplicativos, gerenciar a carga e planejar o tempo de inatividade.
As regras do Balanceador de Carga do Azure exigem uma investigação de integridade para detetar o status do ponto de extremidade. A configuração do teste de integridade e das respostas do teste determina quais instâncias do pool de back-end recebem novas conexões. Use testes de integridade para detetar a falha de um aplicativo. Gere uma resposta personalizada a uma sonda de integridade. Use a sonda de integridade para controle de fluxo para gerenciar a carga ou o tempo de inatividade planejado. Quando um teste de integridade falha, o balanceador de carga para de enviar novas conexões para a respetiva instância não íntegra. A conectividade de saída não é afetada, apenas a de entrada.
Protocolos de sonda
As sondas de saúde suportam vários protocolos. A disponibilidade de um protocolo de teste de integridade específico varia de acordo com o SKU do Balanceador de Carga. Além disso, o comportamento do serviço varia de acordo com o SKU do Balanceador de Carga, conforme mostrado nesta tabela:
| SKU | Protocolo da sonda | Comportamento de sonda para baixo |
|---|---|---|
| Standard | TCP, HTTP, HTTPS | Todas as sondas estão inativas, todos os fluxos TCP continuam. |
| Básica | TCP, HTTP | Todas as sondas inativas, todos os fluxos TCP expiram. |
Propriedades da sonda
As sondas de saúde têm as seguintes propriedades:
| Nome da propriedade da Sonda de Integridade | Detalhes |
|---|---|
| Nome | Nome da sonda de saúde. Este é um nome que você pode definir para sua sonda de saúde |
| Protocolo | Protocolo de sonda de saúde. Este é o tipo de protocolo que você gostaria que a sonda de integridade usasse. As opções são: TCP, HTTP, HTTPS |
| Porta | Porto da sonda de saúde. A porta de destino que você gostaria que a sonda de integridade usasse quando se conecta à máquina virtual para verificar sua integridade |
| Intervalo (segundos) | Intervalo da sonda de saúde. A quantidade de tempo (em segundos) entre testes diferentes em duas tentativas consecutivas de verificação de integridade para a máquina virtual |
| Utilizado por | A lista de regras do balanceador de carga que usam essa sonda de integridade específica. Você deve ter pelo menos uma regra usando a sonda de saúde para que ela seja eficaz |
Configuração da sonda
A configuração da sonda de integridade consiste nos seguintes elementos:
| Configuração da Sonda de Integridade | Detalhes |
|---|---|
| Protocolo | Protocolo de sonda de saúde. Este é o tipo de protocolo que você gostaria que a sonda de integridade usasse. As opções disponíveis são: TCP, HTTP, HTTPS |
| Porta | Porto da sonda de saúde. A porta de destino que você gostaria que a investigação de integridade usasse quando se conecta à máquina virtual para verificar o status de integridade da máquina virtual. Você deve garantir que a máquina virtual também esteja escutando nessa porta (ou seja, a porta está aberta). |
| Intervalo | Intervalo da sonda de saúde. A quantidade de tempo (em segundos) entre tentativas consecutivas de verificação de integridade para a máquina virtual |
Protocolo da sonda
O protocolo usado pela sonda de integridade pode ser configurado para uma das seguintes opções: TCP, HTTP, HTTPS.
| Cenário | Sonda TCP | Sonda HTTP/HTTPS |
|---|---|---|
| Descrição geral | As sondas TCP iniciam uma conexão ao executar um handshake TCP aberto de três vias com a porta definida. As sondas TCP encerram uma conexão com um handshake TCP de fechamento de quatro vias. | HTTP e HTTPS emitem um HTTP GET com o caminho especificado. Ambos os testes suportam caminhos relativos para o HTTP GET. As sondas HTTPS são as mesmas que as sondas HTTP com a adição de um Transport Layer Security (TLS). Os testes HTTP / HTTPS podem ser úteis para implementar sua própria lógica para remover instâncias do balanceador de carga se a porta do teste também for o ouvinte do serviço. |
| Comportamento de falha da sonda | Uma sonda TCP falha quando: 1. O ouvinte TCP na instância não responde durante o período de tempo limite. Uma sonda é marcada para baixo com base no número de solicitações de teste com tempo limite, que foram configuradas para ficarem sem resposta antes de marcar a sonda. 2. O teste recebe uma redefinição de TCP da instância. |
Uma sonda HTTP/HTTPS falha quando: 1. O ponto de extremidade de teste retorna um código de resposta HTTP diferente de 200 (por exemplo, 403, 404 ou 500). 2. O ponto de extremidade da sonda não responde de forma alguma durante o intervalo mínimo da sonda e o período de tempo limite de 30 segundos. Várias solicitações de teste podem ficar sem resposta antes que a sonda seja marcada como não em execução e até que a soma de todos os intervalos de tempo limite seja atingida. 3. O ponto de extremidade da sonda fecha a conexão por meio de uma redefinição de TCP. |
| Comportamento da sonda | Os testes de integridade TCP são considerados íntegros e marcam o ponto de extremidade de back-end como íntegro quando: 1. A sonda de integridade é bem-sucedida uma vez após a inicialização da VM. 2. Qualquer ponto de extremidade de back-end em um estado íntegro é elegível para receber novos fluxos. |
O teste de integridade é marcado quando a instância responde com um status HTTP 200 dentro do período de tempo limite. As sondas de integridade HTTP/HTTPS são consideradas saudáveis e marcam o ponto de extremidade de back-end como íntegro quando: 1. A sonda de integridade é bem-sucedida uma vez após a inicialização da VM. 2. Qualquer ponto de extremidade de back-end em um estado íntegro é elegível para receber novos fluxos. |
Nota
A sonda HTTPS requer o uso de certificados baseados que tenham um hash de assinatura mínimo de SHA256 em toda a cadeia.
Comportamento de sonda para baixo
| Cenário | Conexões TCP | Datagramas UDP |
|---|---|---|
| Testes de instância única inativos | Novas conexões TCP são bem-sucedidas para permanecer íntegro backend endpoint. As conexões TCP estabelecidas para esse ponto de extremidade de back-end continuam. | Os fluxos UDP existentes são movidos para outra instância íntegra no pool de back-end. |
| Todas as instâncias são investigadas | Nenhum novo fluxo é enviado para o pool de back-end. O Standard Load Balancer permite que os fluxos TCP estabelecidos continuem, dado que um pool de back-end tem mais de uma instância de back-end. O Balanceador de Carga Básico encerra todos os fluxos TCP existentes para o pool de back-end. | Todos os fluxos UDP existentes terminam. |
Intervalo de sonda e tempo limite
O valor de intervalo determina a frequência com que o teste de integridade verifica uma resposta de suas instâncias do pool de back-end. Se o teste de integridade falhar, suas instâncias do pool de back-end serão imediatamente marcadas como não íntegras. Se o teste de integridade for bem-sucedido no próximo teste íntegro, o Balanceador de Carga do Azure marcará suas instâncias do pool de back-end como íntegras. A sonda de integridade tenta verificar a porta da sonda de integridade configurada a cada 5 segundos por padrão no portal do Azure, mas pode ser definida explicitamente como outro valor.
Para garantir que uma resposta oportuna seja recebida, as sondas de integridade HTTP/S têm tempos limite integrados. A seguir estão as durações de tempo limite para testes TCP e HTTP/S:
- Duração do tempo limite da sonda TCP: N/D (as sondas falharão quando a duração do intervalo de teste configurado for passada e a próxima sonda for enviada)
- Duração do tempo limite da sonda HTTP/S: 30 segundos
Para testes HTTP/S, se o intervalo configurado for maior do que o período de tempo limite acima, o tempo limite do teste de integridade expirará e falhará se nenhuma resposta for recebida durante o período de tempo limite. Por exemplo, se uma sonda de integridade HTTP for configurada com um intervalo de teste de 120 segundos (a cada 2 minutos) e nenhuma resposta de teste for recebida nos primeiros 30 segundos, a sonda atingirá seu período de tempo limite e falhará. Quando o intervalo configurado for menor do que o período de tempo limite acima, o teste de integridade falhará se nenhuma resposta for recebida antes que o período de intervalo configurado seja concluído e o próximo teste será enviado imediatamente.
Orientação de design
Ao projetar o modelo de integridade para seu aplicativo, investigue uma porta em um ponto de extremidade de back-end que reflita a integridade da instância e do serviço do aplicativo. A porta do aplicativo e a porta do teste não precisam ser as mesmas. Em alguns cenários, pode ser desejável que a porta de teste seja diferente da porta usada pelo aplicativo, mas geralmente é recomendável que as sondas usem a mesma porta.
Pode ser útil para seu aplicativo gerar uma resposta de teste de integridade e sinalizar ao balanceador de carga se sua instância deve receber novas conexões. Você pode manipular a resposta do teste para limitar a entrega de novas conexões a uma instância falhando no teste de integridade. Você pode se preparar para a manutenção de seu aplicativo e iniciar a drenagem de conexões para seu aplicativo. Um sinal de inatividade da sonda sempre permite que os fluxos TCP continuem até o tempo limite ocioso ou o fechamento da conexão em um balanceador de carga padrão.
Para um aplicativo com balanceamento de carga UDP, gere um sinal de teste de integridade personalizado a partir do ponto de extremidade de back-end. Use TCP, HTTP ou HTTPS para a sonda de integridade que corresponde ao ouvinte correspondente.
Regra de balanceamento de carga de Portas HA com o Balanceador de Carga Padrão. Todas as portas têm balanceamento de carga e uma única resposta de teste de integridade deve refletir o status de toda a instância.
Não traduza ou faça proxy de um teste de integridade por meio da instância que recebe o teste de integridade para outra instância em sua rede virtual. Essa configuração pode levar a falhas em seu cenário. Por exemplo: um conjunto de dispositivos de terceiros é implantado no pool de back-end de um balanceador de carga para fornecer escala e redundância para os dispositivos. A investigação de integridade é configurada para investigar uma porta que o dispositivo de terceiros faz proxy ou traduz para outras máquinas virtuais por trás do dispositivo. Se você sondar a mesma porta usada para traduzir ou solicitações de proxy para as outras máquinas virtuais por trás do dispositivo, qualquer resposta de teste de uma única máquina virtual marcará o dispositivo. Essa configuração pode levar a uma falha em cascata do aplicativo. O gatilho pode ser uma falha de teste intermitente que faz com que o balanceador de carga marque a instância do dispositivo. Esta ação pode desativar seu aplicativo. Sonde a saúde do próprio aparelho. A seleção da sonda para determinar o sinal de integridade é uma consideração importante para cenários de dispositivos virtuais de rede (NVA). Consulte o fornecedor do aplicativo para obter o sinal de integridade apropriado para esses cenários.
Se você tiver várias interfaces configuradas em sua máquina virtual, certifique-se de responder à sonda na interface em que a recebeu. Talvez seja necessário traduzir esse endereço de rede na VM por interface.
Uma definição de teste não é obrigatória ou verificada ao usar o Azure PowerShell, a CLI do Azure, Modelos ou API. Os testes de validação de teste só são feitos ao usar o portal do Azure.
Se o teste de integridade flutuar, o balanceador de carga aguardará mais tempo antes de colocar o ponto de extremidade de back-end de volta no estado íntegro. Esse tempo de espera extra protege o usuário e a infraestrutura e é uma política intencional.
Verifique se as instâncias da máquina virtual estão em execução. Para cada instância em execução no pool de back-end, a sonda de integridade verifica a disponibilidade. Se uma instância for interrompida, ela não será investigada até que tenha sido iniciada novamente.
Não configure sua rede virtual com o intervalo de endereços IP de propriedade da Microsoft que contém 168.63.129.16. A configuração colide com o endereço IP da investigação de integridade e pode fazer com que o cenário falhe.
Para testar uma falha de teste de integridade ou marcar uma instância individual, use um grupo de segurança de rede para bloquear explicitamente a sonda de integridade. Crie uma regra NSG para bloquear a porta de destino ou o IP de origem para simular a falha de uma sonda.
Ao contrário das regras de balanceamento de carga, as regras NAT de entrada não precisam de um teste de integridade anexado a elas.
Não é recomendável bloquear o IP ou a porta da sonda de integridade do Balanceador de Carga do Azure com regras NSG. Esse é um cenário sem suporte e pode fazer com que as regras do NSG entrem em vigor com atraso, resultando em testes de integridade para representar incorretamente a disponibilidade de suas instâncias de back-end.
Monitorização
O Balanceador de Carga Padrão expõe o status da sonda de integridade do ponto de extremidade por ponto de extremidade e back-end por meio do Azure Monitor. Outros serviços do Azure ou aplicativos parceiros podem consumir essas métricas. Os logs do Azure Monitor não são suportados para o Balanceador de Carga Básico.
Endereço IP de origem da sonda
Para que a investigação de integridade do Balanceador de Carga do Azure marque sua instância, você deve permitir o endereço IP 168.63.129.16 em qualquer grupo de segurança de rede do Azure e políticas de firewall local. A AzureLoadBalancer etiqueta de serviço identifica esse endereço IP de origem em seus grupos de segurança de rede e permite o tráfego de investigação de integridade por padrão. Você pode aprender mais sobre este IP aqui.
Se você não permitir o IP de origem do teste em suas políticas de firewall, o teste de integridade falhará porque não consegue acessar sua instância. Por sua vez, o Azure Load Balancer marca sua instância como -down- devido à falha da sonda de integridade. Essa configuração incorreta pode fazer com que o cenário do aplicativo com balanceamento de carga falhe. Todas as sondas de integridade do Balanceador de Carga IPv4 são originadas do endereço IP 168.63.129.16 como origem. As sondas IPv6 usam um endereço link-local (fe80::1234:5678:9abc) como origem. Para um Balanceador de Carga do Azure de pilha dupla, você deve configurar um Grupo de Segurança de Rede para que a sonda de integridade IPv6 funcione.
Limitações
Os testes HTTPS não suportam autenticação mútua com um certificado de cliente.
Os testes HTTP não suportam o uso de nomes de host para back-ends de testes.
Habilitar carimbos de data/hora TCP pode causar limitação ou outros problemas de desempenho, o que pode fazer com que as sondas de integridade atinjam o tempo limite.
Uma sonda de integridade do balanceador de carga SKU básico não é suportada com um conjunto de dimensionamento de máquina virtual.
Os testes HTTP não suportam sondagem nas seguintes portas devido a questões de segurança: 19, 21, 25, 70, 110, 119, 143, 220, 993.