Políticas de Verificação de Integridade para Balanceadores de Carga de Rede

No nível mais alto, a integridade do balanceador de carga de rede reflete a integridade de seus respectivos componentes. Os indicadores de status de integridade fornecem informações que podem ser necessárias para detalhar e investigar um problema existente. Alguns problemas comuns que os indicadores de status de integridade podem ajudá-lo a detectar e corrigir incluem:

Uma verificação de integridade está configurada incorretamente.

Nesse caso, todos os servidores de backend de um ou mais listeners afetados são considerados não íntegros. Se a sua investigação constatar que os servidores de backend não têm problemas, é provável que um conjunto de backend inclua uma verificação de integridade configurada incorretamente.

Um listener está configurado incorretamente.

Todos os indicadores de status de integridade do servidor de back-end reportam OK, mas o balanceador de carga de rede não transmite tráfego em um listener.

O listener pode ser configurado para:

• Fazer listening na porta incorreta.
• Utilizar o protocolo incorreto.
• Utilizar a política incorreta.

Se sua investigação mostrar que não há falha do listener, verifique a configuração da lista de segurança.

Uma regra de segurança está configurada incorretamente.

Os indicadores de status de integridade ajudam a diagnosticar dois casos de regras de segurança configuradas incorretamente:

• Todos os indicadores de status de integridade da entidade mostram OK, mas o tráfego não flui (como acontece com listeners mal configurados). Se o listener não apresentar falha, verifique a configuração da regra de segurança.
• Todos os status de integridade da entidade são reportados como não íntegros. Você verificou a configuração da verificação de integridade e os serviços são executados corretamente nos servidores de backend.

  Nesse caso, as regras de segurança podem não incluir o intervalo de IPs da origem das solicitações de verificação de integridade. Você pode obter o IP de origem da verificação de integridade na página Detalhes de cada servidor de backend. Você também pode usar a API para obter o IP no campo sourceIpAddress do objeto HealthCheckResult.

  Observação
  
  O IP de origem das solicitações de verificação de integridade são provenientes de uma instância de computação gerenciada pelo serviço Network Load Balancer.

Um ou mais servidores de backend são considerados não íntegros.

Um servidor de back-end pode estar não íntegro ou a verificação de integridade pode estar configurada incorretamente. Para ver o código de erro correspondente, marque o campo de status na página Detalhes do servidor de backend. Você também pode usar a API para obter o código do erro no campo healthCheckStatus do objeto HealthCheckResult.

Outros casos em que o status da integridade pode se mostrar útil incluem:

• Grupos de segurança de rede da VCN ou listas de segurança de rede estão bloqueando o tráfego.
• As instâncias do serviço Compute têm tabelas de roteamento configuradas de forma incorreta.

O status da integridade é atualizado a cada três minutos. Não há uma granularidade mais detalhada disponível.

O status da integridade não fornece dados históricos.

Configure o protocolo de verificação de integridade para corresponder ao aplicativo ou serviço. Ao executar um serviço HTTP, certifique-se de configurar uma verificação de integridade em nível de HTTP. Se você executar uma verificação de integridade em nível de TCP com um serviço HTTP, talvez não obtenha uma resposta correta. O handshake TCP pode ser bem-sucedido e indicar que o serviço está ativo mesmo quando o serviço HTTP está configurado incorretamente ou está tendo outros problemas. Embora a verificação de integridade pareça bem, os clientes podem vivenciar falhas na transação.

Por exemplo:

• O serviço HTTP de backend tem problemas ao se comunicar com o URL de verificação de integridade e o URL de verificação de integridade retorna mensagens 5XX. Uma verificação de integridade HTTP captura a mensagem do URL de verificação de integridade e marca o serviço como inativo. Nesse caso, um handshake de verificação de integridade TCP é bem-sucedido e marca o serviço como íntegro, mesmo que o serviço HTTP possa não ser útil.
• O serviço HTTP de backend responde com mensagens 4XX por causa de problemas de autorização ou porque não há conteúdo configurado. Uma verificação de integridade de TCP não detecta esses erros.

Estes são os efeitos colaterais comuns da configuração incorreta da verificação de integridade e podem ser usados para diagnosticar e solucionar problemas.

• Porta errada

  Neste cenário, todos os servidores de backend se reportam como não íntegros. Se os servidores de backend não tiverem problemas, talvez você tenha cometido um erro ao definir a porta. A porta deve estar fazendo listening e ter permitido tráfego no backend.

  Erro de Registro em Log do OCI: errno":"EHOSTUNREACH","syscall":"connect".

• Caminho incorreto

  Neste cenário, todos os servidores de backend se reportam como não íntegros. Se os servidores de backend não tiverem problemas, talvez você tenha cometido um erro ao definir o caminho da verificação de integridade HTTP necessário para corresponder a um aplicativo real no servidor de backend. Nesse caso, você pode usar um teste de curl em um sistema na mesma rede.

  Por exemplo:

  $ curl -i http://10.0.0.5/health

  Você recebe o código de status configurado na resposta Erro de Registro em Log do OCI:

  "msg":"invalid statusCode","statusCode":404,"expected":"200".

• Protocolo errado

  Neste cenário, todos os servidores de backend se reportam como não íntegros. Se os servidores de backend não tiverem problemas, talvez você tenha cometido um erro ao definir o protocolo necessário para corresponder ao protocolo que está fazendo listening no backend. Por exemplo: Só suportamos verificações de integridade TCP e HTTP. Se o servidor de backend estiver usando HTTPS, use TCP como protocolo.

  Erro de Registro em Log do OCI:

  "code":"EPROTO","errno":"EPROTO".

• Código de status incorreto

  Neste cenário, todos os servidores de backend se reportam como não íntegros. Se os servidores de backend não tiverem problemas, para uma verificação de integridade HTTP, talvez você tenha cometido um erro ao definir o código de status para corresponder ao código de status real que está sendo retornado do backend. Um cenário comum é quando um backend está retornando um 302 e você está esperando um 200. Esse resultado provavelmente é o backend que envia você para uma página de acesso ou outro local no servidor. Nesse cenário, você pode corrigir o backend para retornar o código esperado ou usar 302 na configuração de verificação de integridade.

  Erro de Registro em Log do OCI:

  "msg":"invalid statusCode","statusCode":XX,"expected":"200" 

  em que XX será o código de status retornado.

• Padrão regex errado

  Todos os servidores de backend se reportam como não íntegros. Se os servidores de backend não tiverem problemas, talvez você tenha cometido um erro ao definir um padrão regex incorreto consistente com o corpo ou o backend não está retornando o corpo esperado. Neste cenário, você pode alterar o backend para corresponder ao padrão ou corrigir o padrão para corresponder ao backend. A seguir estão alguns exemplos de padrões específicos.

  • Qualquer Conteúdo - ".*"
  • Uma página que retorna o valor "Status:OK:" - "Status:OK:.*"
  • Erro de Registro em Log do OCI: "resultado da correspondência de resposta: falha"
• Grupos de Segurança de Rede, listas de segurança ou firewall local mal Configurados

Todos ou alguns servidores de backend se reportam como não íntegros. Se os servidores de backend não tiverem problemas, você poderá ter cometido um erro ao configurar os NSGs, as Listas de Segurança ou os firewalls locais, como firewall, iptables ou SELiinux. Neste cenário, você pode usar um teste curl ou netcat de um sistema que pertence à mesma sub-rede e NSG que o HTTP da instância do balanceador:

Por exemplo:

$ curl -i http://10.0.0.5/health TCP: ex: nc -zvw3 10.0.05 443.

Você pode verificar o firewall local usando o seguinte comando:

firewall-cmd --list-all --zone=public.

Se o firewall não tiver as regras esperadas, você poderá usar um conjunto de comandos como este para adicionar o serviço: (este exemplo é para a porta HTTP 80):

• firewall-cmd --zone=public --add-service=http

• firewall-cmd --zone=public --permanent --add-service=http