Como criar verificações de integridade

O Google Cloud Platform (GCP) fornece mecanismos de verificação de integridade que determinam se as instâncias de VM respondem adequadamente ao tráfego. Neste documento, você verá como criar e usar verificações de integridade para balanceadores de carga.

Nesta página, presume-se que você está familiarizado com os Conceitos de verificação de integridade e que conhece as regras de firewall do GCP.

Categorias, protocolos e portas da verificação de integridade

O GCP organiza as verificações de integridade por categoria e protocolo.

Há duas categorias de verificação de integridade: verificações de integridade e verificações de integridade legadas. Cada categoria é compatível com um conjunto diferente de protocolos e um meio para especificar a porta usada para a verificação de integridade.

A maioria dos balanceadores de carga usa verificações de integridade não legadas, mas o balanceamento de carga de rede exige o uso de verificações de integridade legadas. Consulte Como selecionar uma verificação de integridade na página Conceitos de verificação de integridade para determinar a categoria, o protocolo e o método de especificação de porta apropriados.

O protocolo selecionado para a verificação de integridade não precisa corresponder ao protocolo usado pelo balanceador de carga e, em alguns casos, nem pode. Para mais informações, consulte Protocolos e balanceadores de carga.

O termo "verificação de integridade" não se refere a verificações de integridade legadas. As verificações de integridade legadas são explicitamente chamadas dessa forma neste documento.

Como criar verificações de integridade

O GCP permite que você crie ou selecione uma verificação de integridade ao concluir a configuração de back-end do balanceador de carga no Console do GCP.

Também é possível criar uma verificação de integridade independentemente da configuração do balanceador de carga no Console do GCP. Isso será útil caso precise criar sua verificação de integridade primeiro ou se precisar usar uma verificação de integridade para vários balanceadores de carga. É possível criar uma verificação de integridade usando o Console do GCP, a ferramenta de linha de comando gcloud ou as APIs REST. Depois de analisar as informações contextuais nesta seção, acesse Como criar e modificar verificações de integridade para instruções.

Os balanceadores de carga de rede precisam usar verificações de integridade legadas, que podem ser criadas ou selecionadas ao concluir a configuração de back-end do balanceador de carga da rede no Console do GCP. Para criar uma verificação de integridade legada de forma independente, é necessário usar a ferramenta de linha de comando gcloud ou as APIs REST. Para mais informações, consulte as verificações de integridade legadas.

Sinalizações usadas por todas as verificações de integridade

Estas sinalizações são comuns a todas as verificações de integridade, independentemente do protocolo:

gcloud compute health-checks create PROTOCOL HEALTH_CHECK_NAME \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    ...additional flags

em que:

  • PROTOCOL define o protocolo usado para a verificação de integridade. As opções válidas são http, https, http2, ssl e tcp;
  • HEALTH_CHECK_NAME é o nome da verificação de integridade. Dentro de um determinado projeto, cada verificação de integridade precisa ter um nome exclusivo;
  • DESCRIPTION é uma descrição opcional;
  • CHECK_INTERVAL refere-se ao período entre o início da conexão de um sistema de sondagem de verificação de integridade e o início da próxima. As unidades são informadas em segundos. Em caso de omissão, o GCP usará o valor 5s (5 segundos);
  • TIMEOUT define o período que o GCP aguardará pela resposta de uma sondagem. O valor de TIMEOUT precisa ser menor ou igual ao valor de CHECK_INTERVAL. As unidades são informadas em segundos. Em caso de omissão, o GCP usará o valor 5s (5 segundos);
  • HEALTHY_THRESHOLD e UNHEALTHY_THRESHOLD especificam o número sequencial de sondagens que precisam ser bem-sucedidas ou não para que a instância VM seja considerada íntegra ou não. Em caso de omissão, o GCP usará o limite padrão de 2;
  • ...sinalizações extras são outras sinalizações usadas para especificar portas e opções próprias do PROTOCOL. Essas sinalizações serão abordadas nas próximas seções.

Sinalizações de especificação de porta

Além do protocolo, é necessário especificar uma porta para a verificação de integridade. A maneira como você especifica a porta depende do tipo de balanceador de carga e do tipo de back-ends usado pelo serviço de back-end. Veja na tabela a seguir as opções de especificação de porta para combinações válidas do balanceador de carga e do back-end. Conforme usado na tabela, o termo grupo de instâncias refere-se a grupos de instâncias não gerenciados, grupos de instâncias zonais gerenciados ou grupos de instâncias regionais gerenciados.

As verificações de integridade somente podem usar um tipo de especificação de porta.

Balanceador de carga Tipo de back-end Especificação da porta
Balanceamento de carga TCP/UDP interno Grupos de instâncias Use uma destas opções1:
--port: especifica uma porta por número, de 1 a 65535.
--port-name: especifica qualquer porta nomeada exportada por um grupo de instâncias.
Não é possível usar a sinalização --use-serving-port para verificação de integridade associada a um balanceador de carga interno porque os serviços de back-end para balanceadores de carga internos não têm uma especificação de porta de qualquer tipo.
Balanceamento de carga HTTP(S) interno
Balanceamento de carga de proxy TCP
Balanceamento de carga de proxy SSL
Balanceamento de carga HTTP(S)
Grupos de endpoint da rede Use uma destas opções1:
--port: especifica uma porta por número, de 1 a 65535.
--use-serving-port2: use a porta especificada por cada endpoint no grupo de endpoints da rede.
Grupos de instâncias Use uma destas opções1:
--port: especifica uma porta por número, de 1 a 65535.
--port-name: especifica qualquer porta nomeada exportada por um grupo de instâncias.
--use-serving-port2: use a mesma porta nomeada do grupo de instâncias com a configuração para uso do serviço de back-end.

1As combinações de especificação de porta são resolvidas da seguinte forma:

  • Se --use-serving-port for especificado, --port nem --port-name poderão ser especificados.
  • Se --port e --port-name forem especificados, --port prevalecerá.
  • Se nenhum dos três for especificado, o padrão será: --port=80.

2Beta: use os seguintes comandos Beta gcloud se precisar de --use-serving-port:

Sinalizadores opcionais para verificações de integridade HTTP, HTTPS e HTTP/2

Além das sinalizações comuns e da especificação de porta, é possível usar estas sinalizações opcionais para verificações de integridade HTTP, HTTPS e HTTP/2. Neste exemplo, veja a criação de uma verificação de integridade HTTP chamada hc-http-port-80 usando a porta 80 com os critérios de intervalo padrão, tempo limite e limites de integridade.

gcloud compute health-checks create http hc-http-port-80 \
    --description="Simple HTTP port 80 health check" \
    --check-interval=5s \
    --timeout=5s \
    --healthy-threshold=2 \
    --unhealthy-threshold=2 \
    --port=80 \
    --host=HOST \
    --proxy-header=PROXY_HEADER \
    --request-path=REQUEST_PATH \
    --response=RESPONSE
  • O protocolo pode ser http (neste exemplo), https ou http2.
  • HOST permite fornecer um cabeçalho HTTP do host. Em caso de omissão, o endereço IP da regra de encaminhamento do balanceador de carga será usado.
  • PROXY_HEADER precisa ser NONE ou PROXY_V1. Em caso de omissão, o GCP usará NONE. O valor de PROXY_V1 adiciona o cabeçalho PROXY UNKNOWN\r\n.
  • REQUEST_PATH especifica o caminho do URL que o GCP usa ao enviar solicitações de verificação de integridade. Se omitido, a solicitação de verificação de integridade será enviada para /.
  • RESPONSE define uma resposta opcional esperada. As strings de resposta seguirão estas regras:
    • A string de resposta contém letras, números e espaços ASCII.
    • A string de resposta pode ter até 1.024 caracteres.
    • Não há compatibilidade com correspondência de caracteres curinga.
    • A verificação baseada em conteúdo não é compatível com inversão, por exemplo, não compatibilidade com os operadores ! no HAProxy.

Se o GCP encontrar as strings de resposta esperadas em qualquer lugar dos primeiros 1.024 bytes do corpo da resposta recebida, e se o status HTTP for 200 (OK), a sondagem será considerada bem-sucedida.

As sinalizações --request-path e --response modificam os critérios de sucesso da sondagem de verificação de integridade.

Sinalizações opcionais para verificações de integridade de SSL e TCP

Além das sinalizações comuns e da especificação de porta, é possível usar estas sinalizações opcionais para verificações de integridade de SSL e TCP. Neste exemplo, veja a criação de uma verificação de integridade TCP chamada hc-tcp-3268 usando a porta 3268 com os critérios de intervalo padrão, tempo limite e limites de integridade.

gcloud compute health-checks create tcp hc-tcp-3268 \
    --description="Health check: TCP 3268" \
    --check-interval=5s \
    --timeout=5s \
    --healthy-threshold=2 \
    --unhealthy-threshold=2 \
    --port=3268 \
    --proxy-header=PROXY_HEADER \
    --request=REQUEST_STRING \
    --response=RESPONSE_STRING
  • O protocolo pode ser tcp (neste exemplo) ou ssl.
  • PROXY_HEADER precisa ser NONE ou PROXY_V1. Em caso de omissão, o GCP usará NONE. O valor de PROXY_V1 adiciona o cabeçalho PROXY UNKNOWN\r\n.
  • REQUEST_STRING: será possível fornecer uma string de até 1.024 caracteres ASCII para enviar depois que a sessão TCP ou SSL tiver sido estabelecida.
  • RESPONSE_STRING: é possível fornecer uma string com até 1.024 caracteres ASCII para a resposta esperada.

As sinalizações --request e --response modificam os critérios de sucesso para a sondagem de verificação de integridade. Se usar a sinalização --response, individualmente ou em conjunto com a sinalização --request, a resposta apresentada corresponderá exatamente à string de resposta esperada.

Como criar e modificar verificações de integridade

Não é possível modificar uma verificação de integridade para convertê-la em uma verificação de integridade legada ou vice-versa.

Console

O Console do GCP lista ambas as verificações, de integridade e de integridade legadas. É possível editar as verificações de integridade atuais e as legadas. No entanto, não é possível criar uma verificação de integridade legada na página de verificações no Console do GCP.

Para criar uma verificação de integridade:

  1. Acesse a página "Verificações de integridade" no Console do Google Cloud Platform.
    Acessar a página "Verificações de integridade"
  2. Clique em Criar verificação de integridade.
  3. Na página Criar verificação de integridade, forneça estas informações:
    • Nome: informe um nome para a verificação de integridade.
    • Descrição: opcionalmente, informe uma descrição.
    • Protocolo: escolha um protocolo de verificação de integridade.
    • Porta: informe um número de porta.
    • Protocolo de proxy: opcionalmente, é possível acrescentar um cabeçalho de proxy às solicitações feitas pelos sistemas de sondagem de verificação de integridade.
    • Solicitar caminho e resposta: para protocolos HTTP, HTTPS e HTTP2, há a opção de informar um caminho de URL para que os sistemas de sondagem de verificação de integridade façam contato. Para mais informações, consulte as sinalizações opcionais para verificações de integridade HTTP, HTTPS e HTTP/2.
    • Solicitação e resposta: para protocolos TCP e SSL, é possível especificar uma string de texto ASCII para enviar e uma string de resposta de texto esperada. Para mais informações, consulte as sinalizações opcionais para verificações de integridade de SSL e TCP.
    • Intervalo de verificação: define o período entre o início de uma sondagem e o início da próxima.
    • Tempo limite: define o tempo que o GCP aguardará pela resposta de uma sondagem. O valor precisa ser menor ou igual ao intervalo de verificação.
    • Limite íntegro: define o número sequencial de sondagens que precisam ser bem-sucedidas para que a instância da VM seja considerada íntegra.
    • Limite não íntegro: define o número de falhas seguidas em sondagens para que a instância da VM seja considerada não íntegra.
  4. Clique em Criar.

Para editar uma verificação de integridade:

  1. Acesse a página "Verificações de integridade" no Console do Google Cloud Platform.
    Acessar a página "Verificações de integridade"
  2. Clique em uma verificação de integridade para ver os detalhes.
  3. Se precisar modificar a verificação de integridade, clique em Editar e:
    • faça alterações nos parâmetros conforme a necessidade;
    • clique em Salvar.

gcloud

  1. Use os seguintes comandos gcloud para listar as verificações de integridade:

    gcloud compute health-checks list
    
  2. Identifique uma verificação de integridade e, em seguida, descreva-a usando o comando gcloud apropriado, substituindo HEALTH_CHECK_NAME pelo nome.

    gcloud compute health-checks describe HEALTH_CHECK_NAME
    
  3. Para modificar a verificação de integridade, use o comando gcloud apropriado, substituindo HEALTH_CHECK_NAME pelo nome. Exceto pelo nome e protocolo da verificação de integridade, é possível modificar qualquer uma das sinalizações comuns, as sinalizações de especificação de porta e as sinalizações opcionais. Ao modificar uma verificação de integridade atual com o comando gcloud compute health-checks update, as definições pré-configuradas são preservadas para sinalizações que você omitir. O comando a seguir modifica uma verificação de integridade de exemplo alterando o intervalo de verificação, o tempo limite e o caminho da solicitação:

    gcloud compute health-checks update http hc-http-port-80 \
        --check-interval=20s \
        --timeout=15s \
        --request-path="/health"
    

API

  1. É possível listar as verificações de integridade com a chamada de API healthChecks.list.

  2. Se souber o nome de uma verificação de integridade, será possível ter os detalhes de configuração com a chamada de API healthChecks.get.

  3. Se precisar modificar uma verificação de integridade, use estas chamadas de API:

Verificações de integridade legadas

Como criar verificações de integridade legadas

Nesta seção, você verá como criar verificações de integridade legadas que são exigidas pelos balanceadores de carga da rede.

Console

Embora a página de verificações de integridade do Console do GCP liste ambas as verificações, de integridade e de integridade legadas, não é possível criar uma verificação de integridade legada no Console do GCP. Somente é possível criá-la usando a página do balanceador de carga de rede do Console do GCP.

gcloud

Use o seguinte comando gcloud para criar uma verificação de integridade legada para um balanceador de carga de rede:

gcloud compute LEGACY_CHECK_TYPE create LEGACY_HEALTH_CHECK_NAME \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    --host=HOST \
    --port=PORT \
    --request-path=REQUEST_PATH

Em que:

  • LEGACY_CHECK_TYPE é http-health-checks para uma verificação de integridade HTTP legada ou https-health-checks para uma verificação de integridade HTTPS legada. Se estiver criando a verificação de integridade legada para um balanceador de carga de rede, será necessário usar http-health-checks;
  • LEGACY_HEALTH_CHECK_NAME é o nome da verificação de integridade legada. Dentro de um determinado projeto, cada verificação de integridade legada precisa ter um nome exclusivo;
  • DESCRIPTION é uma descrição opcional;
  • CHECK_INTERVAL define o período entre o início de uma sondagem e o início da próxima. As unidades são informadas em segundos. Em caso de omissão, o GCP usará o valor 5s (5 segundos);
  • TIMEOUT define o tempo que o GCP aguardará pela resposta de uma sondagem. O valor de TIMEOUT precisa ser menor ou igual ao valor de CHECK_INTERVAL. As unidades são informadas em segundos. Em caso de omissão, o GCP usará o valor 5s (5 segundos);
  • HEALTHY_THRESHOLD e UNHEALTHY_THRESHOLD especificam o número sequencial de sondagens que precisam ser bem-sucedidas ou não para que a instância VM seja considerada íntegra ou não. Em caso de omissão, o GCP usará o limite padrão de 2;
  • HOST permite fornecer um cabeçalho HTTP do host. Em caso de omissão, o endereço IP da regra de encaminhamento do balanceador de carga será usado.
  • PORT permite-lhe fornecer um número de porta. Em caso de omissão, o GCP usará 80.
  • REQUEST_PATH especifica o caminho do URL que o GCP usa ao enviar solicitações de verificação de integridade. Se omitido, a solicitação de verificação de integridade será enviada para /.

API

É possível criar uma verificação de integridade legada usando esta chamada de API para um balanceador de carga de rede:

Como visualizar e modificar verificações de integridade legadas

Console

O Console do GCP lista ambas as verificações, de integridade e de integridade legadas na página das verificações. Para editar uma verificação de integridade legada atual:

  1. Acesse a página "Verificações de integridade" no Console do Google Cloud Platform.
    Acessar a página "Verificações de integridade"
  2. Clique em uma verificação de integridade para ver os detalhes.
  3. Se precisar modificar a verificação de integridade, clique em Editar e:
    • faça alterações nos parâmetros conforme a necessidade;
    • clique em Salvar.

gcloud

  1. Use os seguintes comandos gcloud para listar as verificações de integridade legadas para balanceadores de carga de rede.

    gcloud compute http-health-checks list
    
  2. Identifique uma verificação de integridade e, em seguida, descreva-a usando o comando gcloud apropriado, substituindo LEGACY_HEALTH_CHECK_NAME pelo nome.

    gcloud compute http-health-checks describe LEGACY_HEALTH_CHECK_NAME
    
  3. Caso precise modificar a verificação de integridade legada, use o comando gcloud apropriado, substituindo LEGACY_HEALTH_CHECK_NAME pelo nome. Ao modificar uma verificação de integridade com a gcloud, as configurações existentes para as sinalizações omitidas serão preservadas.

    gcloud compute http-health-checks update LEGACY_HEALTH_CHECK_NAME \
        ...other options
    

    Em que ...outras opções são as opções para criar uma verificação de integridade legada.

API

  1. Use a chamada de API a seguir para listar verificações de integridade legadas para balanceadores de carga de rede.

  2. Se souber o nome de uma verificação de integridade legada, é possível receber os detalhes de configuração com esta chamada de API:

  3. Se precisar modificar uma verificação de integridade legada, use estas chamadas de API:

Regras de firewall

É preciso criar regras de firewall de entrada aplicáveis a todas as VMs com balanceamento de carga para permitir o tráfego de intervalos de IP de sondagem de verificação de integridade. Os exemplos a seguir criam regras de firewall que são aplicáveis às instâncias de VM por tag de destino. Para mais informações sobre como especificar segmentações para regras de firewall, consulte a explicação de destinos na Visão geral de regras de firewall e Como configurar tags de rede.

Cada um desses exemplos habilita todo o tráfego TCP dos sistemas de verificação de integridade do GCP para suas instâncias de VM. O tráfego TCP inclui tráfego SSL, HTTP, HTTPS e HTTP/2. Se preferir, é possível especificar portas juntamente com o protocolo TCP. No entanto, se especificar portas, suas regras de firewall poderão se tornar específicas para uma determinada verificação de integridade. Se usar tcp:80 para o protocolo e a porta, isso habilitará o tráfego TCP na porta 80, para que o GCP entre em contato com suas VMs usando HTTP na porta 80, mas não será possível entrar em contato usando HTTPS na porta 443.

Regras para verificações de integridade

O próximo exemplo cria uma regra de firewall de entrada para os seguintes balanceadores de carga:

  • Balanceamento de carga TCP/UDP interno (verificações de integridade)
  • Balanceamento de carga HTTP(S) interno (verificações de integridade)
  • Balanceamento de carga de proxy TCP (verificações de integridade)
  • Balanceamento de carga de proxy SSL (verificações de integridade)
  • Balanceamento de carga HTTP(S) (verificações de integridade e verificações de integridade legadas)

Para esses balanceadores de carga, os intervalos de IP de origem das verificações de integridade, incluindo as verificações legadas, se usadas para balanceamento de carga HTTP(S), são:

  • 35.191.0.0/16
  • 130.211.0.0/22

Somente para balanceamento de carga HTTP(S) interno, o intervalo de IP de origem será todos os endereços IP na sub-rede somente proxy.

Se precisar criar regras para o balanceamento, consulte a próxima seção.

Console

  1. Acesse a página "Regras de firewall" no Console do Google Cloud Platform.
    Acessar a página "Regras de firewall"
  2. Clique em Criar regra de firewall.
  3. Na página Criar regra de firewall, forneça estas informações:
    • Nome: informe um nome para a regra. Para este exemplo, use fw-allow-health-checks.
    • Rede: escolha uma rede VPC.
    • Prioridade: informe um número para a prioridade. Números mais baixos têm prioridades mais altas. Certifique-se de que a regra de firewall tenha uma prioridade mais alta que outras regras que podem negar o tráfego de entrada.
    • Direção do tráfego: escolha entrada.
    • Ação na correspondência: escolha permitir.
    • Destinos: escolha Tags de destino especificadas e insira tags na caixa de texto Tags de destino. Para este exemplo, use allow-health-checks.
    • Filtro de origem: escolha intervalos de IP.
    • Intervalos de IP de origem: 35.191.0.0/16,130.211.0.0/22.
    • Portas e protocolos permitidos: use tcp. O TCP é o protocolo subjacente a todos os protocolos de verificação de integridade.
    • Clique em Criar.
  4. Em cada instância com balanceamento de carga, adicione a tag de rede para que essa nova regra de firewall de entrada aplique-se a ela. Neste exemplo, usamos allow-health-checks para a tag de rede.

gcloud

  1. Use o seguinte comando gcloud para criar uma regra de firewall chamada fw-allow-health-checks, que permite conexões de entrada a instâncias na sua rede com a tag allow-health-checks. Substitua NETWORK_NAME pelo nome da sua rede.

    gcloud compute firewall-rules create fw-allow-health-checks \
        --network NETWORK_NAME \
        --action ALLOW \
        --direction INGRESS \
        --source-ranges 35.191.0.0/16,130.211.0.0/22 \
        --target-tags allow-health-checks \
        --rules tcp
  2. Em cada instância com balanceamento de carga, adicione a tag de rede para que essa nova regra de firewall de entrada aplique-se a ela. Neste exemplo, usamos allow-health-checks para a tag de rede.

Para mais informações, consulte a documentação das regras de firewall da gcloud e a documentação da API.

Regras para balanceamento de carga de rede

Neste exemplo, criamos uma regra de firewall de entrada para o balanceamento de carga de rede, que exige uma verificação de integridade legada. Os intervalos de IP de origem das verificações de integridade legadas para o balanceamento de carga de rede são:

  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22

Console

  1. Acesse a página "Regras de firewall" no Console do Google Cloud Platform.
    Acessar a página "Regras de firewall"
  2. Clique em Criar regra de firewall.
  3. Na página Criar regra de firewall, forneça estas informações:
    • Nome: informe um nome para a regra. Neste exemplo, use fw-allow-network-lb-health-checks.
    • Rede: escolha uma rede VPC.
    • Prioridade: informe um número para a prioridade. Números mais baixos têm prioridades mais altas. Certifique-se de que a regra de firewall tenha uma prioridade mais alta que outras regras que podem negar o tráfego de entrada.
    • Direção do tráfego: escolha entrada.
    • Ação na correspondência: escolha permitir.
    • Destinos: escolha Tags de destino especificadas e insira tags na caixa de texto Tags de destino. Neste exemplo, use allow-network-lb-health-checks.
    • Filtro de origem: escolha intervalos de IP.
    • Intervalos de IP de origem: 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22.
    • Portas e protocolos permitidos: use tcp. O TCP é o protocolo subjacente para HTTP e HTTPS.
    • Clique em Criar.
  4. Em cada instância com balanceamento de carga, adicione a tag de rede para que essa nova regra de firewall de entrada aplique-se a ela. Neste exemplo, usamos allow-network-lb-health-checks para a tag de rede.

gcloud

  1. Use o seguinte comando gcloud para criar uma regra de firewall chamada fw-allow-network-lb-health-checks, que permite conexões de entrada a instâncias na sua rede com a tag allow-network-lb-health-checks. Substitua NETWORK_NAME pelo nome da sua rede.

    gcloud compute firewall-rules create fw-allow-network-lb-health-checks \
        --network NETWORK_NAME \
        --action ALLOW \
        --direction INGRESS \
        --source-ranges 35.191.0.0/16,209.85.152.0/22,209.85.204.0/22 \
        --target-tags allow-network-lb-health-checks \
        --rules tcp
  2. Em cada instância com balanceamento de carga, adicione a tag de rede para que essa nova regra de firewall de entrada aplique-se a ela. Neste exemplo, usamos allow-network-lb-health-checks para a tag de rede.

Para mais informações, consulte a documentação das regras de firewall da gcloud e a documentação da API.

Como fazer associações com balanceadores de carga

Protocolos e balanceadores de carga

É melhor usar uma verificação de integridade (ou verificação de integridade legada) que tenha um protocolo que corresponda ao protocolo usado pelo serviço de back-end ou pelo pool de segmentação do balanceador de carga. No entanto, os protocolos de verificação de integridade e os do balanceador de carga não precisam ser os mesmos. Por exemplo:

  • Para o balanceamento de carga TCP/UDP interno, somente é possível usar TCP ou UDP para o protocolo do serviço de back-end. Se você veicula tráfego HTTP de VMs por trás de um balanceador de carga interno, convém empregar uma verificação de integridade usando o protocolo HTTP.

  • As verificações de integridade legada são limitadas ao protocolo HTTP. Se usar um balanceador de carga de rede para equilibrar o tráfego TCP, será necessário executar um serviço HTTP nas VMs que estão sendo balanceadas para que possam responder a sondagens de verificação de integridade.

Verificações de integridade para serviços de back-end

Nesta seção, você verá como associar uma verificação de integridade a um serviço de back-end para estes tipos de balanceadores de carga:

  • Balanceamento de carga TCP/UDP interno
  • Balanceamento de carga HTTP(S) interno
  • Balanceamento de carga de proxy TCP
  • Balanceamento de carga de proxy SSL
  • Balanceamento de carga HTTP(S)

Nesta seção, presume-se que você já:

Para associar uma verificação de integridade a um novo balanceador de carga interno, HTTP(S), de proxy TCP e de proxy SSL, consulte o guia de configuração do respectivo balanceador de carga.

Console

Para associar uma verificação de integridade a um balanceador de carga interno, de proxy TCP, de proxy SSL ou HTTP(S) existentes:

  1. Acesse a página "Balanceamento de carga" no Console do Google Cloud Platform.
    Acessar a página "Balanceamento de carga"
  2. Clique em um balanceador de carga para ver os detalhes.
  3. Clique em Editar e em Configuração de back-end.
  4. Escolha uma verificação de integridade no menu Verificação de integridade.
  5. Clique em Atualizar.

gcloud

Para associar uma verificação de integridade a um balanceador de carga interno, de proxy TCP, de proxy SSL ou HTTP(S) existentes:

  1. Identifique os serviços ou serviços de back-end usados pelo balanceador de carga. Aqueles que são internos, de proxy TCP e proxy SSL têm apenas um serviço de back-end para todo o balanceador de carga. Os HTTP(S) têm um ou mais serviços de back-end associados ao mapa de URLs.

    • Para listar serviços de back-end para balanceadores de carga TCP/UDP internos, execute este comando. Identifique o nome e a região do serviço de back-end.

      gcloud compute backend-services list \
          --filter="loadBalancingScheme=INTERNAL"
      
    • Para listar serviços de back-end para balanceadores de carga HTTP(S) internos, execute este comando. Identifique o nome e a região do serviço de back-end.

      gcloud compute backend-services list \
          --filter="loadBalancingScheme=INTERNAL_MANAGED"
      
    • Para listar serviços de back-end para balanceadores de carga de proxy TCP:

      gcloud compute backend-services list \
          --filter="loadBalancingScheme=EXTERNAL" \
          --filter="protocol=TCP"
      
    • Para listar serviços de back-end para balanceadores de carga de proxy SSL:

      gcloud compute backend-services list \
          --filter="loadBalancingScheme=EXTERNAL" \
          --filter="protocol=SSL"
      
    • Para identificar serviços de back-end para balanceamento de carga HTTP(S), identifique o mapa de URLs e, em seguida, descreva-o, substituindo URL_MAP_NAME pelo nome do mapa de URLs. Os serviços de back-end usados são listados na seção pathMatchers da resposta.

      gcloud compute url-maps list
      gcloud compute url-maps describe URL_MAP_NAME
      
  2. Identifique uma verificação de integridade. Se necessário, veja as verificações de integridade.

  3. Associe a verificação de integridade ao serviço de back-end. Nos seguintes comandos, substitua BACKEND_SERVICE_NAME pelo nome do serviço de back-end e HEALTH_CHECK_NAME pelo nome da verificação de integridade. Esses comandos substituem todas as verificações de integridade associadas ao serviço de back-end. Na maioria dos casos, haverá apenas uma verificação de integridade associada ao serviço de back-end.

    • Para alterar a verificação de integridade de um serviço de back-end para um balanceador de carga interno, use o seguinte comando. Os serviços de back-end para balanceadores de carga internos são regionais. Por isso, além do nome, especifique REGION.

      gcloud compute backend-services update BACKEND_SERVICE_NAME \
          --region REGION \
          --health-checks HEALTH_CHECK_NAME
      
    • Para alterar a verificação de integridade de um serviço de back-end para balanceadores de carga de proxy TCP, de proxy SSL e HTTP(S):

      gcloud compute backend-services update BACKEND_SERVICE_NAME \
          --global \
          --health-checks HEALTH_CHECK_NAME
      

API

  1. É possível listar serviços de back-end com a chamada de API backendServices.list.

  2. Veja verificações de integridade.

  3. Para associar uma verificação de integridade a um serviço de back-end, use uma das seguintes chamadas de API:

Verificações de integridade legadas para balanceamento de carga de rede

Nesta seção, você verá como associar uma verificação de integridade legada a um pool de segmentação para o balanceamento de carga de rede. Nesta seção, presume-se que você já:

Para associar uma verificação de integridade legada a um novo balanceador de carga de rede, consulte Como configurar o balanceamento de carga de rede. Associe uma verificação de integridade legada ao pool de segmentação ao criar um novo balanceador de carga de rede.

Console

Para associar uma verificação de integridade a um balanceador de carga de rede atual:

  1. Acesse a página "Balanceamento de carga" no Console do Google Cloud Platform.
    Acessar a página "Balanceamento de carga"
  2. Clique em um balanceador de carga de rede para ver os detalhes.
  3. Clique em Editar e em Configuração de back-end.
  4. Escolha uma verificação de integridade legada no menu Verificação de integridade. Somente serão exibidas as verificações legadas qualificadas.
  5. Clique em Atualizar.

gcloud

Para associar uma verificação de integridade a um balanceador de carga de rede atual:

  1. Identifique os pools de segmentação. Os balanceadores de carga de rede têm pelo menos um pool de segmentação e podem ter um pool de backup secundário.

    gcloud compute target-pools list
    
  2. Identifique uma verificação de integridade legada usando o protocolo HTTP. Se necessário, veja as verificações de integridade legadas.

  3. Associe a verificação de integridade legada ao pool de segmentação. Nos seguintes comandos, substitua TARGET_POOL_NAME pelo nome do pool de segmentação, REGION por sua região e LEGACY_HEALTH_CHECK_NAME pelo nome da verificação de integridade legada. A verificação de integridade legada usará o protocolo HTTP.

    • Para remover uma verificação de integridade de HTTP legada de um pool de segmentação:

      gcloud compute target-pools remove-health-checks TARGET_POOL_NAME \
          --region REGION \
          --http-health-check LEGACY_HEALTH_CHECK_NAME
      
    • Para adicionar uma verificação de integridade de HTTP legada a um pool de segmentação:

      gcloud compute target-pools add-health-checks TARGET_POOL_NAME \
          --region REGION \
          --http-health-check LEGACY_HEALTH_CHECK_NAME
      

API

  1. É possível listar pools de segmentação com a chamada de API targetPools.list.

  2. Veja as verificações de integridade legadas e identifique uma verificação de integridade de HTTP legada.

  3. Para associar uma verificação de integridade HTTP legada a um pool de segmentação, use a chamada de API targetPools.addHealthCheck.

Como solucionar problemas de verificações de integridade bloqueando intervalos de endereços IP

Em determinadas circunstâncias, é importante que haja falha proposital nas verificações de integridade. Talvez seja necessário forçar uma determinada VM a falhar nas verificações de integridade como parte de uma atividade de solução de problemas ou fazer com que ela falhe nas verificações de integridade como parte do procedimento de encerramento.

É possível forçar a falha em verificações de integridade ou verificações de integridade legada, bloqueando temporariamente o acesso aos intervalos de IP da verificação. Neste exemplo, mostramos como fazer a verificação de integridade usando o software de firewall iptables em execução em uma VM do Linux.

Para fazer com que uma VM falhe nas sondagens da verificação de integridade e da verificação de integridade legada, conecte-se a elas e execute um comando iptables como o seguinte exemplo, substituindo HEALTH_CHECK_PORT pelo número de porta TCP apropriada. Se precisar que uma VM falhe propositalmente nos testes enquanto está sendo encerrada, adicione comandos iptables como esses a um script de encerramento seguido por um atraso apropriado com base no intervalo de verificação e no limite não íntegro da verificação de integridade.

$ sudo iptables -I INPUT 1 -m state --state NEW \
-s 35.191.0.0/16 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -I INPUT 1 -m state --state NEW \
-s 130.211.0.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -I INPUT 1 -m state --state NEW \
-s 209.85.152.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -I INPUT 1 -m state --state NEW \
-s 209.85.204.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset

Para remover as regras iptables, execute os seguintes comandos, substituindo HEALTH_CHECK_PORT pela porta TCP da verificação de integridade.

$ sudo iptables -D INPUT -m state --state NEW \
-s 35.191.0.0/16 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -D INPUT -m state --state NEW \
-s 130.211.0.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -D INPUT -m state --state NEW \
-s 209.85.152.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -D INPUT -m state --state NEW \
-s 209.85.204.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…