Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Uma sonda de estado de funcionamento do Balanceador de Carga do Azure é uma funcionalidade que deteta o estado de funcionamento das suas instâncias da aplicação. 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 sonda de estado de funcionamento para detetar o estado da 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ásico | TCP, HTTP | Todas as sondas estão indisponíveis, 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 pretende que a sonda de estado utilize ao ligar-se à máquina virtual para verificar o respetivo estado. |
| Intervalo (segundos) | Intervalo da sonda de saúde. O intervalo de tempo (em segundos) entre sondagens diferentes em duas tentativas consecutivas de verificação do estado de funcionamento da máquina virtual |
| Limiar | Limite da sonda de integridade. O número de vezes que a sonda de estado de funcionamento tem de ser bem-sucedida ou falhar para permitir ou impedir a entrega de tráfego à máquina virtual |
| Utilizado por | Lista de regras do balanceador de carga usando esta sonda de integridade. 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. O intervalo de tempo (em segundos) entre tentativas consecutivas de verificação de integridade à 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. Ambas estas sondas suportam caminhos relativos nos pedidos HTTP GET. As sondas HTTPS são as mesmas que as sondas HTTP com a adição de um Transport Layer Security (TLS). As sondagens HTTP / HTTPS podem ser úteis para implementar a sua própria lógica para remover instâncias do equilibrador de carga, se a porta da sondagem também for a porta de escuta do serviço. |
| Comportamento de falha da sonda | Uma sonda TCP falha quando: 1. O listener TCP da instância não responde de todo durante o timeout. Uma sonda é marcada como indisponível com base no número de pedidos da sonda que expiraram, que foram configurados para ficar sem resposta antes de a sonda ser marcada como indisponível. 2. A sonda recebe um reset TCP da instância. |
Uma sonda HTTP/HTTPS falha quando: 1. O endpoint de verificação devolve um código de estado 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 | As sondas de estado de funcionamento TCP são consideradas saudáveis e marcam o endpoint de back-end como saudável quando: 1. A verificação de estado só é efetuada com êxito uma vez após o arranque da VM. 2. Qualquer servidor back-end em estado operacional pode 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 estado de funcionamento HTTP/HTTPS são consideradas em bom estado e marcam o ponto final de back-end como estando em bom estado quando: 1. A verificação de estado só é efetuada com êxito uma vez após o arranque da VM. 2. Qualquer servidor back-end em estado operacional pode 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 descida da sonda
| Cenário | Conexões TCP | Datagramas UDP |
|---|---|---|
| Testes de instância única inativos | As novas conexões TCP são estabelecidas com êxito com o endpoint de backend restante que permanece operacional. As ligações TCP estabelecidas a esta extremidade de back-end continuam. | Os fluxos UDP existentes são movidos para outra instância em bom estado no pool de back-end. |
| Todas as instâncias são investigadas | Nenhum novo fluxo é enviado para o pool de back-end. O Balanceador de Carga Standard permite que os fluxos TCP estabelecidos continuem, dado que um pool de back-end tem mais de uma instância de back-end. O Basic Balanceador de Carga (retirado) termina todos os fluxos TCP existentes para o pool de backend. | 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 a sonda de saúde falhar, o balanceador de carga marca imediatamente as instâncias do pool de backend como pouco saudáveis. Se a sonda de saúde tiver sucesso no próximo teste, o Balanceador de Carga do Azure marca as instâncias do teu pool de backend como saudáveis. A sonda de estado de funcionamento tenta verificar a porta da sonda de estado de funcionamento configurada a cada 5 segundos, por predefinição, no portal do Azure, mas pode defini-la para outro valor. Quando implementas através de templates ARM, da API REST, da CLI do Azure ou do PowerShell, o intervalo padrão é de 15 segundos (mínimo 5 segundos).
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.
Limiar da sonda
O valor limite do teste é o número de vezes que um teste de integridade precisará ter êxito ou falhar consecutivamente para que o teste marque uma instância de back-end como íntegra ou não íntegra, respectivamente.
Para testes TCP, se o limite de teste estiver configurado como 2, o teste precisará receber 2 respostas consecutivas antes que uma instância de back-end comece a receber tráfego. Da mesma forma, quando uma instância de backend é considerada saudável, são necessárias 2 falhas ou expirações consecutivas para que a instância passe a ser considerada não saudável e deixe de receber novo tráfego.
Para sondagens HTTP, as respostas explícitas marcarão imediatamente a sonda como ativa ou inativa, no caso de respostas 200 e não 200, e reinicializarão efetivamente o limiar. Isto significa que o valor de limiar só se aplica a sondagens HTTP se a sondagem expirar devido à ausência de resposta.
Orientação de design
Ao projetar o modelo de estado de funcionamento da sua aplicação, sonde uma porta num endpoint de back-end que reflita o estado de funcionamento da instância e do serviço da aplicação. A porta da aplicação e a porta de sondagem não têm de ser iguais. 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. Pode preparar a manutenção da sua aplicação e iniciar o encerramento das ligações à sua aplicação. Um sinal de falha da sonda permite sempre que os fluxos TCP continuem até ao tempo limite de inatividade ou ao fecho da ligação num Balanceador de Carga Standard.
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. Utilize TCP, HTTP ou HTTPS para a sonda de estado de funcionamento que corresponda ao escutador correspondente.
Regra de balanceamento de carga de portas HA com Balanceador de Carga Standard. 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 encaminhe nem faça passar através de um proxy uma sonda de estado de funcionamento da instância que a recebe para outra instância na sua rede virtual. Essa configuração pode levar a falhas em seu cenário. Por exemplo: um conjunto de dispositivos de terceiros é implementado no pool de back-end de um balanceador de carga para assegurar escalabilidade e redundância dos dispositivos. A sonda de estado de funcionamento está configurada para sondar uma porta que o equipamento de terceiros encaminha ou traduz para outras máquinas virtuais por trás do equipamento. Se sondar a mesma porta utilizada para traduzir ou servir de proxy aos pedidos para as outras máquinas virtuais atrás do dispositivo virtual, qualquer resposta da sonda proveniente de uma única máquina virtual fará com que o dispositivo virtual seja assinalado como indisponível. Essa configuração pode levar a uma falha em cascata do aplicativo. O fator desencadeador pode ser uma falha intermitente da sonda que faz com que o balanceador de carga assinale a instância do dispositivo como indisponível. Esta ação pode desativar seu aplicativo. Verifique o estado do próprio aparelho. A seleção da sonda para determinar o sinal de estado de funcionamento é um aspeto importante a ter em conta em 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. Poderá ser necessário traduzir o endereço de rede de origem na VM individualmente em cada interface.
Uma definição de sonda não é obrigatória nem é verificada quando se utiliza o Azure PowerShell, a CLI do Azure, modelos ou a API. Os testes de validação da sonda só são efetuados quando se utiliza o portal do Azure.
Se a sonda de estado de funcionamento oscilar, o balanceador de carga aguardará mais tempo antes de voltar a colocar o ponto final de back-end no estado saudável. 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 entra em conflito com o endereço IP da sonda de estado de funcionamento e pode fazer com que o seu 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 de 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
Balanceador de Carga Standard disponibiliza o estado da sonda de integridade para cada ponto final e cada ponto final de back-end através 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 Basic Balanceador de Carga (retirado).
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 Balanceador de Carga do Azure 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 endereço de 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.
As sondas HTTP não suportam a utilização de nomes de anfitrião para os backends das sondas.
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.
As sondas de saúde para o Basic Balanceador de Carga (aposentado) não são suportadas com um conjunto de escalas de máquinas virtuais.
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.