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

Configure e use verificações de integridade para decidir a disponibilidade dos servidores de backend para um balanceador de carga de rede.

Uma verificação de integridade é um teste para confirmar a disponibilidade dos servidores de backend. Uma verificação de integridade pode ser uma solicitação ou uma tentativa de conexão. Com base em um intervalo especificado, o balanceador de carga da rede aplica a política de verificação de integridade para monitorar continuamente os servidores de backend. Se um servidor falhar na verificação de integridade, o balanceador de carga da rede colocará o servidor temporariamente fora de rotação. Se posteriormente o servidor for aprovado na verificação de integridade, o balanceador de carga da rede vai retorná-lo à rotação.

Você configura a política de verificação de integridade ao criar um balanceador de carga de rede. Você também pode configurar a política de verificação de integridade ao criar ou editar um conjunto de backend para um balanceador de carga existente. Aqui está um resumo dos protocolos que você pode usar com sua política de verificação de integridade:

  • As verificações de integridade em nível de TCP tentam fazer uma conexão TCP com os servidores de backend e validam a resposta com base no status da conexão.

    Se não for prático criar uma solicitação para o protocolo com o qual está trabalhando, você poderá omitir os dados da solicitação. Nesse caso, o backend será considerado íntegro, se a conexão TCP for bem-sucedida.

  • As verificações de integridade em nível de HTTP enviam solicitações aos servidores de back-end em um URI específico e validam a resposta com base no código de status ou dados da entidade (corpo) retornados.
  • As verificações de integridade no nível do HTTPS enviam solicitações aos servidores de backend em um URI específico e validam a resposta com base no código de status ou dados da entidade (corpo) retornados por um protocolo HTTPS seguro e criptografado.
  • As verificações de integridade no nível do UDP enviam uma única solicitação ao servidor de backend e correspondem à resposta (se recebida) com os dados de resposta especificados.
  • As verificações de integridade no nível do DNS enviam solicitações aos servidores de backend usando UDP ou TCP. A verificação de integridade também usa o nome da consulta e as informações relacionadas que você deseja fornecer a resposta de DNS do servidor de backend.

O serviço fornece recursos de verificação de integridade específicos para o aplicativo, a fim de aumentar a disponibilidade e reduzir a janela de manutenção do aplicativo.

Você pode executar as seguintes tarefas de gerenciamento da política de verificação de integridade:

Configurar 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.

Indicadores de Status de Integridade

O serviço Balanceador de Carga de Rede fornece indicadores de status de integridade que usam as políticas de verificação de integridade para reportar a integridade geral dos balanceadores de carga de rede e de seus respectivos componentes. Você pode ver indicadores de status de integridade nas páginas Lista e Detalhes da Console para balanceadores de carga, conjuntos de backend e servidores de backend. Você também pode usar a API para recuperar essas informações.

Os indicadores de status de integridade têm quatro níveis. A tabela a seguir fornece o significado geral de cada nível:

Nível Cor Descrição
OK Verde Nenhuma atenção necessária.

O recurso está funcionando conforme esperado.

Advertência Amarelo Algumas entidades de geração de relatórios requerem atenção.

O recurso não está funcionando com eficiência máxima ou está incompleto e requer mais atenção.

Crítico Vermelho Algumas ou todas as entidades de geração de relatórios requerem atenção imediata.

O recurso não está funcionando ou uma falha inesperada é iminente.

Desconhecido Desativado Não é possível determinar o status de integridade.

O recurso não está respondendo ou está em transição e pode passar para outro status com o tempo.

O significado preciso de cada nível difere entre os seguintes componentes:

Usando o Status de Integridade

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:

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.

Melhores Práticas da Verificação de Integridade

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.

Efeitos Colaterais Comuns da Configuração Incorreta da Verificação de Integridade

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

Configurando seu Protocolo de Verificação de Integridade para Corresponder ao seu Aplicativo ou Serviço

O serviço fornece recursos de verificação de integridade específicos para o aplicativo, a fim de aumentar a disponibilidade e reduzir a janela de manutenção do aplicativo.

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.

Verificação de Integridade de DNS

O serviço Network Load Balancer suporta verificação de integridade de DNS por meio de transporte TCP e UDP, para servidores de backend IPv4 e IPv6. A verificação de integridade do DNS para servidores de backend do resolvedor de DNS é uma melhoria em relação às verificações baseadas em TCP ou UDP, porque verifica se o protocolo DNS é funcional para os servidores de backend do resolvedor de DNS. Esses protocolos usam o formato base64 para especificar as mensagens de solicitação e resposta, e isso pode ser difícil ao formar solicitações e respostas de DNS. Além disso, pode haver várias respostas válidas e RCODE na mensagem de resposta, por exemplo, NOERROR(0) e NXDOMAIN(3). Não é possível lidar com todos esses cenários usando a verificação de integridade TCP ou UDP padrão.

Ao criar um conjunto de backend, durante a criação do balanceador de carga de rede inicial ou ao adicionar um conjunto de backend a um balanceador de carga de rede existente, especifique as seguintes configurações específicas de protocolo se estiver usando a verificação de integridade do DNS:

  • Nome da consulta: Forneça um nome de domínio DNS para a consulta.
  • Classe de consulta: Selecione uma das seguintes opções:
    • IN: Internet (padrão)
    • CH: Caos
  • Tipo de consulta: Selecione uma das seguintes opções:
    • A: Indica um endereço IPv4 correspondente ao nome de host. (padrão)
    • AAAA: Indica um endereço IPv6 correspondente ao nome de host.
    • TXT: Indica um campo de texto.
  • Códigos de resposta aceitáveis: Selecione uma ou mais das seguintes opções:
    • RCODE:0 NOERROR Consulta de DNS concluída com sucesso.
    • Falha do servidor RCODE:2 SERVFAIL ao concluir a solicitação de DNS.
    • O nome de domínio RCODE:3 NXDOMAIN não existe.
    • RCODE:5 REFUSED O servidor se recusou a responder para a consulta.