Investigações de integridade do Azure Load Balancer
Uma investigação de integridade do Azure Load Balancer é um recurso que detecta o status da integridade das instâncias do aplicativo. Ela envia uma solicitação às instâncias para verificar se elas estão disponíveis e respondem às solicitações. A investigação de integridade pode ser configurada para usar diferentes protocolos, como TCP, HTTP ou HTTPS. É um recurso importante porque ajuda você a detectar falhas do aplicativo, gerenciar a carga e planejar o tempo de inatividade.
As regras do Azure Load Balancer exigem uma investigação de integridade para detectar o status do ponto de extremidade. A configuração da investigação de integridade e das respostas de integridade determina quais instâncias do pool de back-end recebem novas conexões. Use investigações de integridade para detectar a falha de um aplicativo. Gere uma resposta personalizada para uma investigação de integridade. Use a investigação de integridade para o controle de fluxo para gerenciar a carga ou o tempo de inatividade planejado. Quando uma investigação de integridade falha, o balanceador de carga para de enviar novas conexões à respectiva instância não íntegra. A conectividade de saída não é afetada, apenas a de entrada.
Protocolos de investigação
As investigações de integridade dão suporte a vários protocolos. A disponibilidade de um protocolo de investigação de integridade específico varia de acordo com o SKU do Load Balancer. Além disso, o comportamento do serviço varia de acordo com o SKU do Load Balancer, conforme mostrado na tabela:
| SKU Standard | SKU Básico | |
|---|---|---|
| Protocolo de investigação | TCP, HTTP, HTTPS | TCP, HTTP |
| Comportamento de investigação inoperante | Todas as investigações inoperantes, todos os fluxos TCP continuam. | Todas as investigações inoperantes, todos os fluxos TCP expiram. |
Propriedades da investigação
As investigações de integridade têm as seguintes propriedades:
| Nome da propriedade da Investigação de Integridade | Detalhes |
|---|---|
| Nome | Nome da investigação de integridade. Esse é um nome que você pode definir para sua investigação de integridade |
| Protocolo | Protocolo de investigação de integridade. Esse é o tipo de protocolo que você deseja que seja usado pela investigação de integridade. As opções são: TCP, HTTP, HTTPS |
| Porta | Porta da investigação de integridade. A porta de destino que você deseja que seja usada pela investigação de integridade quando ela se conectar à máquina virtual para verificar a integridade |
| Intervalo (segundos) | Intervalo de investigação de integridade. O tempo (em segundos) entre diferentes investigações em duas tentativas consecutivas de verificação de integridade da máquina virtual |
| Usado por | A lista de regras do balanceador de carga usando essa investigação de integridade específica. Você deve ter pelo menos uma regra usando a investigação de integridade para que ela seja eficaz |
Configuração da investigação
A configuração de investigação de integridade consiste nos seguintes elementos:
| Configuração da investigação de integridade | Detalhes |
|---|---|
| Protocolo | Protocolo de investigação de integridade. Esse é o tipo de protocolo que você deseja que seja usado pela investigação de integridade. As opções disponíveis são: TCP, HTTP, HTTPS |
| Porta | Porta da investigação de integridade. A porta de destino que você deseja que a investigação de integridade use quando ela se conectar à máquina virtual para marcar o status de integridade da máquina virtual. Você deve garantir que a máquina virtual também esteja escutando nessa porta (ou seja, que a porta esteja aberta). |
| Intervalo | Intervalo de investigação de integridade. A quantidade de tempo (em segundos) entre as tentativas consecutivas de verificação de integridade até a máquina virtual |
Protocolo de investigação
O protocolo usado pela investigação de integridade pode ser configurado para uma das seguintes opções: TCP, HTTP, HTTPS.
| Cenário | Investigação TCP | Investigação HTTP/HTTPS |
|---|---|---|
| Visão geral | As investigações TCP iniciam uma conexão executando um handshake TCP aberto de três vias com a porta definida. As investigações TCP encerram uma conexão com um handshake TCP fechado de quatro vias. | HTTP e HTTPS emitem um HTTP GET com o caminho especificado. Ambas essas investigações dão suporte a caminhos relativos para o HTTP GET. Investigações HTTPS são iguais às investigações HTTP com a adição de um wrapper de TLS (Transport Layer Security). investigações HTTP/HTTPS podem ser úteis para implementar sua própria lógica para remover instâncias do balanceador de carga se a porta de investigação também é o ouvinte para o serviço. |
| Comportamento de falha da investigação | Uma investigação TCP falha quando: 1. O ouvinte TCP na instância não responde durante o período de tempo limite. Uma investigação é marcada como inoperante dependendo do número de solicitações de investigação com tempo limite, as quais foram configuradas para passar sem resposta antes da marcação da investigação como inoperante. 2. A investigação recebe uma redefinição de TCP da instância. | Uma investigação HTTP/HTTPS falha quando: 1. O ponto de extremidade da investigação retorna um código de resposta HTTP diferente de 200 (por exemplo, 403, 404 ou 500). 2. O ponto de extremidade de investigação não responde durante o mínimo do intervalo de investigação e do período de tempo limite de 30 segundos. Várias solicitações de investigação podem ficar sem resposta antes que a investigação seja marcada como não estando em execução e até que a soma de todos os intervalos de tempo limite seja atingido. 3. O ponto de extremidade de investigação fecha a conexão por meio de uma redefinição de TCP. |
| Investigação de comportamento | As investigações de integridade TCP são consideradas íntegras e marcam o ponto de extremidade de back-end como íntegro quando: 1. A investigação de integridade é bem-sucedida uma vez após a inicialização da VM. 2. Todo ponto de extremidade de back-end que atingiu um estado íntegro é qualificado para receber novos fluxos. | A investigação de integridade é marcada como operante quando a instância responde com um status HTTP 200 dentro do período de tempo limite. As investigações de integridade HTTP/HTTPS são consideradas íntegras e marcam o ponto de extremidade de back-end como íntegro quando: 1. A investigação de integridade é bem-sucedida uma vez após a inicialização da VM. 2. Todo ponto de extremidade de back-end que atingiu um estado íntegro é qualificado para receber novos fluxos. |
Observação
A investigação HTTPS exige o uso de certificados com base que tenham um hash de assinatura mínimo de SHA256 em toda a cadeia.
Comportamento de investigação inoperante
| Cenário | Conexões TCP | Datagramas UDP |
|---|---|---|
| Um única investigações de instância inoperante | As novas conexões TCP têm êxito nos pontos de extremidade de back-end íntegros restantes. Conexões TCP estabelecidas para este ponto de extremidade de back-end continuam. | Os fluxos UDP existentes são movidos para outra instância íntegra no pool de back-ends. |
| Todas as instâncias investigação inoperantes | Nenhum novo fluxo foi enviado para o pool de back-ends. O Standard Load Balancer permite que os fluxos TCP estabelecidos continuem, uma vez que um pool de back-ends tem mais de uma instância de back-end. O Basic Load Balancer encerra todos os fluxos TCP existentes para o pool de back-end. | Todos os fluxos UDP existentes terminaram. |
Tempo limite do intervalo e de investigação
O valor do intervalo determina a frequência com que a investigação de integridade verifica se há uma resposta das instâncias do pool de back-end. Se a investigação de integridade falhar, suas instâncias de pool de back-end são imediatamente marcadas como não íntegras. Se a investigação de integridade for bem-sucedida na próxima investigação de integridade, o Azure Load Balancer marcará as instâncias do pool de back-end como íntegras. Por padrão, a investigação de integridade tenta verificar a porta da investigação de integridade configurada a cada 5 segundos no portal do Azure, mas pode ser definida explicitamente com outro valor.
Para garantir que uma resposta oportuna seja recebida, as investigações de integridade HTTP/S têm tempos limite internos. Veja a seguir as durações do tempo limite das investigações TCP e HTTP/S:
- Duração do tempo limite da investigação TCP: N/D (as investigações falharão depois que a duração do intervalo de investigação configurada tiver passado e a próxima investigação tiver sido enviada)
- Duração do tempo limite da investigação HTTP/S: 30 segundos
Nas investigações HTTP/S, se o intervalo configurado for maior que o período de tempo limite acima, a investigação de integridade terá tempo limite e falhará se nenhuma resposta for recebida durante o período de tempo limite. Por exemplo, se uma investigação de integridade HTTP estiver configurada com um intervalo de investigação de 120 segundos (a cada 2 minutos) e nenhuma resposta de investigação for recebida nos primeiros 30 segundos, a investigação terá atingido seu período de tempo limite e falhará. Quando o intervalo configurado for menor que o tempo limite acima, ocorrerá uma falha na investigação de integridade se nenhuma resposta for recebida antes que o intervalo configurado seja concluído e a próxima investigação será enviada imediatamente.
Diretrizes 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 o serviço de aplicativo. A porta do aplicativo e a porta de investigação não precisam ser as mesmas. Em alguns cenários, o ideal é que a porta de investigação seja diferente da porta usada pelo aplicativo, mas, em geral, recomendamos que elas sejam a mesma porta.
Pode ser útil para seu aplicativo gerar uma resposta de investigação de integridade e sinalizar o balanceador de carga se sua instância deve receber novas conexões. É possível manipular a resposta de investigação para limitar a entrega de novas conexões a uma instância, falhando na investigação de integridade. Você pode se preparar para a manutenção do seu aplicativo e iniciar o descarregamento de conexões com seu aplicativo. Um sinal de investigação inoperante sempre permite a continuidade dos fluxos TCP até o tempo limite ocioso ou o fechamento da conexão em um Standard Load Balancer.
Para um aplicativo UDP com balanceamento de carga, gere um sinal de investigação de integridade personalizado do ponto de extremidade de back-end. Use TCP, HTTP ou HTTPS para a investigação de integridade que corresponda ao ouvinte correspondente.
Regra de balanceamento de carga de portas HA com Standard Load Balancer. Todas as portas têm balanceamento de carga, e uma única resposta de investigação de integridade deve refletir o status de toda a instância.
Não traduza ou proxy uma investigação de integridade por meio da instância que recebe a investigação 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 os proxies de dispositivo de terceiros ou convertem em outras máquinas virtuais por trás do dispositivo. Se você investigar a mesma porta usada para converter as solicitações ou usar um proxy para elas para as outras máquinas virtuais por trás do dispositivo, qualquer resposta de investigação de uma única máquina virtual marca o dispositivo em si como inoperante. Essa configuração pode levar a uma falha em cascata do aplicativo. O gatilho pode ser uma falha de investigação intermitente que faz com que o balanceador de carga marque a instância do dispositivo. Essa ação pode desabilitar seu aplicativo. Investigação de integridade do dispositivo em si. A seleção da investigação para determinar o sinal de integridade é uma consideração importante para cenários de NVA (soluções de virtualização de rede). 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, será necessário certificar-se de responder à investigação na interface em que a investigação foi recebida. Talvez seja necessário obter a conversão do endereço de rede de origem desse endereço na VM por interface.
Observe que uma definição de investigação não é obrigatória nem verificada ao usar o Azure PowerShell, a CLI do Azure, os modelos ou a API. Os testes de validação de investigação só são feitos quando o portal do Azure é usado.
Se a investigação de integridade for flutuante, o balanceador de carga aguardará um período maior até recolocar o ponto de extremidade de back-end em 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 investigação de integridade verifica a disponibilidade. Se uma instância for interrompida, ela não será investigada até que tenha sido reiniciada.
Não configure a 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 investigação de integridade e pode resultar na falha do cenário.
Para testar uma falha de investigação de integridade ou marcar uma instância individual, use um grupo de segurança de rede para bloquear explicitamente a investigação de integridade. Crie uma regra NSG para bloquear a porta de destino ou o IP de origem para simular a falha de uma investigação.
Ao contrário das regras de balanceamento de carga, as regras NAT de entrada não precisam de uma investigação de integridade anexada a elas.
Não é recomendável bloquear o IP ou a porta da investigação de integridade do Azure Load Balancer com regras NSG. Esse é um cenário sem suporte e pode fazer com que as regras NSG tenham efeito atrasado, fazendo com que as investigações de integridade representem de forma imprecisa a disponibilidade de suas instâncias de back-end.
Monitoramento
O Standard Load Balancer expõe o status da investigação de integridade por ponto de extremidade e ponto de extremidade de 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 compatíveis com o balanceador de carga Básico.
Endereço IP de origem da investigação
Para que a investigação de integridade do Azure Load Balancer marque a instância como operante, é necessário permitir o endereço IP 168.63.129.16 em todos os grupos de segurança de rede do Azure e nas políticas de firewall local. A marca de serviço AzureLoadBalancer identifica esse endereço IP de origem nos grupos de segurança de rede e permite o tráfego da investigação de integridade por padrão. Você pode aprender mais sobre esse IP aqui.
Se você não permitir o IP de origem da investigação nas políticas de firewall, a investigação de integridade falha, pois não poderá acessar a instância. Por sua vez, o Azure Load Balancer marca a instância como inoperante devido à falha da investigação de integridade. Essa configuração incorreta poderá causar uma falha no cenário de aplicativo com balanceamento de carga. Todas as investigações de integridade do Load Balancer IPv4 originam-se do endereço IP 168.63.129.16 como sua fonte. As investigações do IPv6 usam um endereço local de link (fe80::1234:5678:9abc) como sua origem. Para um Azure Load Balancer de pilha dupla, você deve configurar um Grupo de Segurança de Rede para que a investigação de integridade IPv6 funcione.
Limitações
As investigações de HTTPS não dão suporte à autenticação mútua com um certificado de cliente.
As investigações de HTTP não dão suporte ao uso de nomes de host para sondar back-ends
A habilitação de carimbos de data/hora TCP pode causar limitação ou outros problemas de desempenho, o que pode fazer com que o tempo limite das investigações de integridade seja atingido.
Não há suporte para uma investigação de integridade do balanceador de carga Básico do SKU com um conjunto de dimensionamento de máquinas virtuais.
As investigações de HTTP não dão suporte às seguintes portas devido a questões de segurança: 19, 21, 25, 70, 110, 119, 143, 220 e 993.