Como configurar o gerenciamento de tráfego para balanceadores de carga HTTP(S) internos

Neste guia, você verá exemplos de como configurar o gerenciamento de tráfego para balanceamento de carga HTTP(S) interno. Você aprenderá a usar o gerenciamento de tráfego em alguns casos específicos. Muitos outros casos de uso são possíveis.

Antes de começar

• Entenda como o gerenciamento de tráfego funciona. Para mais informações, leia Conceitos do gerenciamento de tráfego.

• Siga as instruções em Como configurar o balanceamento de carga HTTP(S) interno e configure todos os hosts de VM ou clusters do GKE que sejam necessários.

• Crie a verificação de integridade necessária ou reutilize uma que já exista, como descrito em Como configurar o balanceador de carga.

Como configurar o gerenciamento de tráfego

Use o Console do Cloud, o gcloud ou a API Cloud Load Balancing para configurar o gerenciamento de tráfego. No ambiente de configuração escolhido, defina o gerenciamento de tráfego por meio de configurações YAML. Um mapa de URL e um serviço de back-end têm seus próprios arquivos YAML. Dependendo da funcionalidade pretendida, você precisa gravar um YAML de mapa de URL, de serviço de back-end ou ambos.

Se precisar de ajuda para gravar esses arquivos YAML, use os recursos a seguir:

• Documentação da API de mapas de URL regionais e da API do serviço de back-end regional

  fornece uma lista completa de campos, incluindo a semântica sobre relações, restrições e cardinalidade.

• Exemplos nesta página

• Exemplos no Console do Cloud

Como acessar os exemplos YAML no Console do Cloud

Para acessar os exemplos YAML no Console do Cloud:

1. Acesse a página "Balanceamento de carga" no Console do Google Cloud.
   Acessar a página "Balanceamento de carga"
2. Em Balanceamento de carga HTTP(S), clique em Iniciar configuração.
3. Selecione Apenas entre minhas VMs. Essa configuração implica que o balanceador de carga é interno.
4. Clique em Continuar.
5. Na configuração Regras de roteamento, selecione Regra avançada de host, caminho e rota.
6. Clique em Adicionar hosts e correspondência de caminho.
7. Clique no link Orientação de código.

A página Exemplos YAML de correspondência de caminho será exibida.

Exemplos de YAML do mapa de URLs

Uma permissão em um mapa de URLs

Único serviço

Envie todo o tráfego para um serviço. Certifique-se de substituir as variáveis marcadas por []:

defaultService: regions/[region]/backendServices/[backend-service1]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: [url-map-name]
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100

Dividir tráfego

Divida o tráfego entre vários serviços. Certifique-se de substituir as variáveis marcadas por []:

defaultService: regions/[region]/backendServices/[backend-service1]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: [url-map-name]
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: /prefix
    priority: 2
    routeAction:
      weightedBackendServices:
      - backendService: regions/[region]/backendServices/[backend-service1]
        weight: 95
      - backendService: regions/[region]/backendServices/[backend-service2]
        weight: 5

Redirecionamento de URL

Retorna um código de resposta 3xx configurável. Também define o cabeçalho de resposta de local com o URI apropriado, substituindo o host e o caminho, conforme especificado na ação de redirecionamento. Certifique-se de substituir as variáveis marcadas por []:

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      urlRedirect:
        hostRedirect: [REDIRECT_HOST]
        pathRedirect: [REDIRECT_PATH]
        redirectResponseCode: FOUND
        stripQuery: True

Vários permitidos em um mapa de URLs

Espelhamento de tráfego

Além de encaminhar a solicitação ao serviço de back-end selecionado, envie uma solicitação idêntica ao serviço de back-end do espelhamento configurado em uma base autônoma. O balanceador de carga não espera por uma resposta do back-end a que envia a solicitação espelhada. O espelhamento é útil para testar uma nova versão de um serviço de back-end. Ele pode ser usado também para depurar erros de produção em uma versão de depuração do serviço de back-end, mas não na versão de produção. Certifique-se de substituir as variáveis marcadas por []:

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        requestMirrorPolicy:
          backendService: regions/[region]/backendServices/[backend-service2]

Regravação de URL

Regrave a parte do nome do host do URL, a parte do caminho do URL ou ambos antes de enviar uma solicitação para o serviço de back-end selecionado. Certifique-se de substituir as variáveis marcadas por []:

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        urlRewrite:
          hostRewrite: [REWRITE_HOST]
          pathPrefixRewrite: [REWRITE_PATH]

Repetição de solicitação

Configure as condições em que o balanceador de carga tenta repetir as solicitações com falha, quanto tempo o balanceador de carga aguarda antes de tentar novamente e o número máximo de novas tentativas permitidas. Certifique-se de substituir as variáveis marcadas por []:

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        retryPolicy:
          retryConditions: 502, 504
          numRetries: 3
          perTryTimeout:
            seconds: 1
            nanos: 50

Timeout

Especifique o tempo limite da rota selecionada. O tempo limite é calculado a partir do momento em que a solicitação é completa até que a resposta seja totalmente processada. O tempo limite inclui todas as novas tentativas. Certifique-se de substituir as variáveis marcadas por []:

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        timeout:
          seconds: 30
          nanos: 100

Falhas

Apresente erros ao atender às solicitações de serviço para simular falhas, incluindo alta latência, sobrecarga de serviço, falhas de serviço e particionamento de rede. Esse recurso é útil para testar a resiliência de um serviço a falhas simuladas. Certifique-se de substituir as variáveis marcadas por []`:

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        faultInjectionPolicy:
          delay:
            fixedDelay:
              seconds: 10
              nanos: 20
            percentage: 25
          abort:
            httpStatus: 503
            percentage: 50

CORS

Configure as políticas de compartilhamento de recursos entre origens (CORS, na sigla em inglês) para processar as configurações do balanceamento de carga HTTP(S) interno para aplicar solicitações CORS. Certifique-se de substituir as variáveis marcadas por []:

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        corsPolicy:
            allowOrigins: my-domain.com
            allowMethods: GET, POST
            allowHeaders: Authorization, Content-Type
            maxAge: 1200
            allowCredentials: True

Cabeçalhos

Adicione e remova cabeçalhos da solicitação antes de enviar uma solicitação ao serviço de back-end. Além disso, adicione e remova cabeçalhos de resposta depois de receber uma resposta do serviço de back-end. Certifique-se de substituir as variáveis marcadas por []:

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      headerAction:
        requestHeadersToAdd:
          - headerName: header-1-name
            headerValue: header-1-value
            replace: True
        requestHeadersToRemove:
          - header-2-name
          - header-3-name
        responseHeadersToAdd:
          - headerName: header-4-name
            headerValue: header-4-value
            replace: True
        responseHeadersToRemove:
          - header-5-name
          - header-6-name

Exemplos de YAML do serviço de back-end

Detecção de outlier

Especifique os critérios para remoção de VMs ou endpoints de back-end não íntegros em NEGs, com critérios que definem quando um back-end ou endpoint é considerado íntegro o suficiente para receber tráfego novamente. Certifique-se de substituir as variáveis marcadas por []:

kind: compute#backendService
loadBalancingScheme: INTERNAL_MANAGED
localityLbPolicy: RANDOM
name: regions/[region]/backendServices/[backend-service1]
outlierDetection:
  baseEjectionTime:
    nanos: 0
    seconds: '30'
  consecutiveErrors: 5
  consecutiveGatewayFailure: 3
  enforcingConsecutiveErrors: 2
  enforcingConsecutiveGatewayFailure: 100
  enforcingSuccessRate: 100
  interval:
    nanos: 0
    seconds: '1'
  maxEjectionPercent: 50
  successRateMinimumHosts: 5
  successRateRequestVolume: 100
  successRateStdevFactor: 1900
region: region/[region]

Disjuntores

A quebra de circuito permite definir limites de falha para impedir que as solicitações do cliente sobrecarreguem os back-ends. Depois que as solicitações atingirem um limite definido, o balanceador de carga deixará de permitir novas conexões ou de enviar solicitações adicionais, permitindo que os back-ends se recuperem. Assim, a quebra de circuito evita falhas em cascata retornando um erro ao cliente em vez de sobrecarregar um back-end. Isso permite que pouco tráfego seja vinculado enquanto fornece tempo para gerenciar a situação de sobrecarga, como lidar com um pico de tráfego aumentando a capacidade com escalonamento automático.

Defina limites superiores em solicitações por conexão, bem como o volume de conexões com um serviço de back-end. Além disso, limite o número de solicitações pendentes e novas tentativas. Certifique-se de substituir as variáveis marcadas por []:

kind: compute#backendService
loadBalancingScheme: INTERNAL_MANAGED
localityLbPolicy: RANDOM
affinityCookieTtlSec: 0
backends:
- balancingMode: UTILIZATION
  capacityScaler: 1.0
  group: region/[region]/instanceGroups/[instance-group]
  maxUtilization: 0.8
circuitBreakers:
  maxConnections: 1000
  maxPendingRequests: 200
  maxRequests: 1000
  maxRequestsPerConnection: 100
  maxRetries: 3
connectionDraining:
  drainingTimeoutSec: 0
healthChecks:
- region/[region]/healthChecks/[health-check]

Como configurar a divisão de tráfego

Neste exemplo, demonstramos as seguintes etapas:

1. Criar modelos distintos para diferentes serviços.

2. Criar grupos de instâncias para esses modelos.

3. Criar regras de roteamento que configurem a divisão de tráfego em 95% e 5%.

4. Enviar comandos curl, mostrando que as porcentagens de divisão de tráfego correspondem aproximadamente à configuração.

Os pressupostos destas instruções são os seguintes:

• A região é us-west1.
• Um proxy de destino e uma regra de encaminhamento foram criados, junto com um mapa de URLs chamado l7-ilb-map.

• O endereço da regra de encaminhamento é 10.1.2.99.

  Consulte as instruções em Como configurar o balanceamento de carga HTTP(S) interno para VMs do Compute Engine.

• O mapa de URLs envia todo o tráfego para um serviço de back-end, chamado red-service, que é o serviço padrão.

• Você configura um caminho alternativo que envia 5% do tráfego para blue-service e 95% do tráfego para green-service.

• É usada uma correspondência de caminho.

• Você está usando o Cloud Shell ou outro ambiente com o bash instalado.

Como definir os serviços

A função bash a seguir cria um serviço de back-end, incluindo o modelo da instância e o grupo de instâncias gerenciadas.

Estas instruções pressupõem que uma verificação de integridade de HTTP (l7-ilb-basic-check) foi criada. Consulte as instruções em Como configurar o balanceamento de carga HTTP(S) interno para VMs do Compute Engine.

function make_service() {
  local name="$1"
  local region="$2"
  local zone="$3"
  local network="$4"
  local subnet="$5"
  local subdir="$6"

  www_dir="/var/www/html/$subdir"

  (set -x; \
  gcloud compute instance-templates create "${name}-template" \
    --region="$region" \
    --network="$network" \
    --subnet="$subnet" \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --metadata=startup-script="#! /bin/bash
  apt-get update
  apt-get install apache2 -y
  a2ensite default-ssl
  a2enmod ssl
  sudo mkdir -p $www_dir
  /bin/hostname | sudo tee ${www_dir}index.html
  systemctl restart apache2"; \
  gcloud compute instance-groups managed create \
    "${name}-instance-group" \
    --zone="$zone" \
    --size=2 \
    --template="${name}-template"; \
  gcloud compute backend-services create "${name}-service" \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=l7-ilb-basic-check \
    --health-checks-region="$region" \
    --region="$region"; \
  gcloud compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --region="$region")
}

Como criar os serviços

Agora chame a função para criar três serviços: red, green e blue. O serviço red funciona como o serviço padrão das solicitações para /. Os serviços green e blue estão configurados em /prefix para lidar com 95% e 5% do tráfego, respectivamente.

make_service red us-west1 us-west1-a lb-network backend-subnet ""
make_service green us-west1 us-west1-a lb-network backend-subnet /prefix
make_service blue us-west1 us-west1-a lb-network backend-subnet /prefix

Como criar o mapa de URLs

Console

1. Acesse a página "Balanceamento de carga" no Console do Google Cloud.
   Acessar a página "Balanceamento de carga"
2. Clique no link l7-ilb-map.
3. Clique em Editar .

Configurar as novas regras de roteamento

1. Em Regras de roteamento, selecione Regra avançada para host, caminho e rota.
2. Abaixo de Novos hosts e correspondência de caminho, crie a ação padrão configurando o Serviço para red-service.
3. Clique em Done.
4. Clique em Adicionar hosts e correspondência de caminho.
5. No campo Hosts, insira 10.1.2.99. Esse é o endereço IP da regra de encaminhamento do seu balanceador de carga.

6. Cole o conteúdo YAML na caixa Correspondência de caminho, certificando-se de substituir [PROJECT_ID] pelo ID do projeto:

   defaultService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/red-service
   name: matcher1
   routeRules:
   - priority: 2
     matchRules:
       - prefixMatch: /prefix
     routeAction:
       weightedBackendServices:
         - backendService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/green-service
           weight: 95
         - backendService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/blue-service
           weight: 5
   

7. Clique em Done.

8. Clique em Atualizar.

gcloud

1. Exporte o mapa de URLs atual usando o comando gcloud compute url-maps export:

   gcloud compute url-maps export l7-ilb-map \
     --destination=l7-ilb-map-config.yaml \
     --region=us-west1
   

2. Atualize o arquivo do mapa de URL l7-ilb-map-config.yaml adicionando-o ao final do arquivo, substituindo [PROJECT_ID] pelo ID do projeto:

   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/red-service
     name: matcher1
     routeRules:
     - priority: 2
       matchRules:
         - prefixMatch: /prefix
       routeAction:
         weightedBackendServices:
           - backendService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/green-service
             weight: 95
           - backendService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/blue-service
             weight: 5
   

3. Atualize o mapa de URLs usando o comando gcloud compute url-maps import:

   gcloud compute url-maps import l7-ilb-map \
      --region=us-west1 \
      --source=l7-ilb-map-config.yaml
   

Como testar a configuração

Para testar a configuração, primeiro verifique se as solicitações de 10.1.2.99/, o endereço IP do balanceador de carga configurado anteriormente, são operadas pela configuração red padrão.

Verifique se as solicitações enviadas para 10.1.2.99/prefix são divididas como esperado.

Como criar uma VM cliente

Consulte Como criar uma instância de VM na zona para testar a conectividade.

Como enviar solicitações para 10.1.2.99

Acesse o cliente por SSH.

gcloud compute ssh l7-ilb-client-us-west1-a \
    --zone=us-west1-a

Execute este comando:

for LB_IP in 10.1.2.99; do
    RESULTS=
    for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}`"; done >/dev/null 2>&1
    IFS=':'
    echo "***"
    echo "*** Results of load balancing to $LB_IP: "
    echo "***"
    for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c
    echo
done

Como verificar os resultados

***
***Results of load balancing to 10.1.2.99:
***
502 red-instance-group-9jvq
498 red-instance-group-sww8

Como enviar solicitações para 10.1.2.99/prefix

Envie solicitações para 10.1.2.99/prefix e observe a divisão de tráfego.

for LB_IP in 10.1.2.99; do
    RESULTS=
    for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}/prefix/index.html`"; done >/dev/null 2>&1
    IFS=':'
    echo "***"
    echo "*** Results of load balancing to $LB_IP/prefix: "
    echo "***"
    for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c
    echo
done

Como verificar os resultados

***
***Results of load balancing to 10.1.2.99/prefix:
***
21 blue-instance-group-8n49
27 blue-instance-group-vlqc
476 green-instance-group-c0wv
476 green-instance-group-rmf4

A configuração canário envia 95% de solicitações /prefix para o serviço green e 5% para o serviço blue.

Como configurar a afinidade da sessão com base em HTTP_COOKIE

É possível usar o controle de tráfego para configurar a afinidade de sessão com base em um cookie. Para configurar a afinidade da sessão com base em HTTP_COOKIE para um serviço de back-end denominado red-service, siga estas instruções.

Para configurar a afinidade de sessão usando HTTP_COOKIE:

1. Use o comando gcloud compute backend_services export para acessar a configuração do serviço de back-end.

   gcloud compute backend-services export red-service \
       --destination=red-service-config.yaml \
       --region=us-west1
   

2. Atualize o arquivo red-service-config.yaml da seguinte forma:

   sessionAffinity: 'HTTP_COOKIE'
   localityLbPolicy: 'RING_HASH'
   consistentHash:
    httpCookie:
     name: 'http_cookie'
     path: '/cookie_path'
     ttl:
       seconds: 100
       nanos: 30
    minimumRingSize: 10000
   

3. No arquivo red-service-config.yaml, exclua a linha que diz:

   sessionAffinity: NONE
   

4. Atualize o arquivo de configuração do serviço de back-end:

   gcloud compute backend-services import red-service \
       --source=red-service-config.yaml \
       --region=us-west1
   

Como solucionar problemas

Use estas informações para solucionar problemas quando o tráfego não estiver sendo encaminhado de acordo com as regras de roteamento e as políticas de tráfego que você tiver configurado.

Para saber informações sobre geração de registros e monitoramento, consulte Geração de registro e monitoramento de HTTP(S) interno.

Sintomas:

• Aumento do tráfego para serviços em regras acima da regra em questão.
• Aumento inesperado nas respostas HTTP 4xx e 5xx para uma determinada regra de rota.

Solução: verifique a ordem das suas regras de rota. As regras de rota são interpretadas na ordem em que são especificadas.

As regras de rota em um mapa de URLs são interpretadas na ordem em que são especificadas. Isso é diferente de como as regras de caminho são interpretadas pela correspondência de prefixo mais longa. Para uma regra de caminho, o balanceamento de carga de HTTP(S) interno selecionará somente uma regra de caminho. No entanto, mais de uma opção pode ser aplicada quando você usa regras de rota.

Ao definir regras de rota, verifique se as regras na parte superior da lista não encaminham inadvertidamente o tráfego que, de outra forma, seria roteado por outra regra de rota. O serviço que recebe tráfego direcionado incorretamente provavelmente rejeitará as solicitações, e o serviço nas regras de rota receberá tráfego reduzido ou nenhum tráfego.