Configurar o gerenciamento de tráfego para balanceadores de carga globais de aplicativos externos

Você aprenderá a usar o gerenciamento de tráfego em alguns casos específicos. Muitos outros casos de uso são possíveis.

O documento contém exemplos para balanceadores de carga de aplicativos externos globais. Os balanceadores de carga de aplicativo externos globais usam o esquema de balanceamento de carga EXTERNAL_MANAGED e componentes de balanceamento de carga globais, como regra de encaminhamento, mapa de URL e serviço de back-end.

Para informações sobre o gerenciamento de tráfego com um balanceador de carga de aplicativo clássico, consulte Visão geral do gerenciamento de tráfego para um balanceador de carga de aplicativo clássico.

Para informações sobre gerenciamento de tráfego com balanceadores de carga de aplicativo externos regionais, consulte Visão geral do gerenciamento de tráfego para balanceadores de carga de aplicativo externos regionais.

Além dos recursos avançados de roteamento descritos nesta página, os balanceadores de carga de aplicativo compatíveis se integram às extensões de serviço para permitir que você insira lógica personalizada no caminho de dados de balanceamento de carga.

Antes de começar

Entenda como o gerenciamento de tráfego funciona. Para mais informações, leia Visão geral do gerenciamento de tráfego para balanceadores de carga de aplicativos externos globais.

Configurar e testar 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 do recurso escolhido, você precisa gravar um arquivo YAML de mapa de URL, de serviço de back-end ou ambos.

Se precisar de ajuda para gravar esses arquivos YAML, use os exemplos nesta página e a documentação da API Cloud Load Balancing.

O console do Google Cloud não é compatível.

A documentação da API de mapa de URLs global e da API de serviço de back-end global inclui uma lista completa de campos, semânticas relacionadas a relacionamentos, restrições e cardinalidade.

Você pode adicionar testes de configuração a um mapa de URL para garantir que ele direcione as solicitações da maneira pretendida. Você pode fazer experimentos com diferentes regras de mapa de URL e executar quantos testes forem necessários para confirmar que o mapa encaminha o tráfego para o serviço ou o bucket de back-end apropriado. Para ver mais detalhes, consulte Adicionar testes a um mapa de URL. Se você quiser testar novas alterações em um mapa de URL sem implantar o mapa, consulte Como validar a configuração do mapa de URL.

Mapear o tráfego para um único serviço

Envie todo o tráfego para um serviço. Lembre-se de substituir os marcadores de posição.

    defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    name: URL_MAP_NAME
    pathMatchers:
    - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: /PREFIX
        priority: PRIORITY  # 0 is highest
        routeAction:
          weightedBackendServices:
          - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
            weight: 100

Dividir o tráfego entre dois serviços

Divida o tráfego entre dois ou entre vários serviços. Lembre-se de substituir os marcadores de posição:

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   name: URL_MAP_NAME
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
     - matchRules:
       - prefixMatch: /PREFIX
       priority: 2
       routeAction:
         weightedBackendServices:
         - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
           weight: 95
         - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
           weight: 5

Configurar um redirecionamento de URL

O exemplo a seguir retorna um código de resposta MOVED_PERMANENTLY_DEFAULT 301 configurável. O exemplo também define o cabeçalho de resposta Location com o URI apropriado, substituindo o host e o caminho conforme especificado na ação de redirecionamento.

Para criar um redirecionamento para um bucket de back-end, use projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET no campo defaultService.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: <var>URL_MAP_NAME</var>
   hostRules:
   - hosts:
     - "HOST TO REDIRECT FROM" # Use * for all hosts
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     defaultUrlRedirect:
       hostRedirect: "HOST TO REDIRECT TO" # Omit to keep the requested host
       pathRedirect: "PATH TO REDIRECT TO" # Omit to keep the requested path
       redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
       stripQuery: True

Espelhar 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 atire e esqueça. Isso significa que o balanceador de carga não espera por uma resposta do back-end a que envia a solicitação espelhada. O espelhamento de solicitações é útil para testar uma nova versão de um serviço de back-end. Ele também pode ser usado 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.

Por padrão, o serviço de back-end espelhado recebe todas as solicitações, mesmo que o tráfego original esteja sendo dividido entre vários serviços de back-end ponderados. É possível configurar o serviço de back-end espelhado para receber apenas uma porcentagem das solicitações usando a flag mirrorPercent opcional para especificar a porcentagem de solicitações a serem espelhadas, expressa como um valor entre 0 e 100,0. O espelhamento de solicitações com base em porcentagem está em Pré-lançamento.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           requestMirrorPolicy:
             backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
             mirrorPercent: 50.0

Se você tiver vários serviços de back-end ponderados e quiser registrar qual serviço de back-end foi usado para atender à solicitação original, adicione um cabeçalho personalizado que inclua essas informações em todas as solicitações. O exemplo a seguir adiciona um cabeçalho personalizado chamado x-weighted-picked-backend a todas as solicitações de cliente. Para o valor do cabeçalho, use o nome do serviço de back-end que atendeu à solicitação original.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
            - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
              weight: 95
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_1
                  replace: True
            - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
              weight: 5
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_2
                  replace: True
           requestMirrorPolicy:
             backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_3

Observe as seguintes limitações ao usar o espelhamento de tráfego:

  • O espelhamento de tráfego é aceito quando ambos os serviços de back-end têm grupos gerenciados de instâncias, NEGs zonais ou back-ends de NEGs híbridos. Ele não é compatível com NEGs da Internet, sem servidor e back-ends do Private Service Connect.
  • As solicitações para o serviço de back-end espelhado não geram registros nem métricas para o Cloud Logging e o Cloud Monitoring.

Reescrever o URL solicitado

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. Lembre-se de substituir os marcadores de posição.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           urlRewrite:
             hostRewrite: "new-host-name.com" # Omit to keep the requested host
             pathPrefixRewrite: "/new-path/" # Omit to keep the requested path

Repetir uma 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.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           retryPolicy:
             retryConditions: 502, 504
             numRetries: 3
             perTryTimeout:
               seconds: 1
               nanos: 500000000

Especificar o tempo limite da rota

Especifique o tempo limite da rota selecionada. O tempo limite é calculado a partir do momento do processamento total da solicitação e da resposta. O tempo limite inclui todas as novas tentativas. Lembre-se de substituir os marcadores de posição.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           timeout:
             seconds: 30
             nanos: 0

Configurar injeção de 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.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           faultInjectionPolicy:
             delay:
               fixedDelay:
                 seconds: 10
                 nanos: 0
               percentage: 25
             abort:
               httpStatus: 503
               percentage: 50

Configurar o CORS

Configure políticas de Compartilhamento de recursos entre origens (CORS) para gerenciar as configurações de aplicação de solicitações CORS.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           corsPolicy:
               allowOrigins: [ "http://my-domain.com" ]
               allowMethods: [ "GET", "POST" ]
               allowHeaders: [ "Authorization", "Content-Type" ]
               maxAge: 1200
               allowCredentials: true

Adicionar e remover cabeçalhos de solicitação e resposta

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.

Há restrições de valores válidos para headerName e headerValue. Para mais detalhes, consulte Como os cabeçalhos personalizados funcionam.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               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

Configurar 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. Lembre-se de substituir os marcadores de posição.

    loadBalancingScheme: EXTERNAL_MANAGED
    localityLbPolicy: RANDOM
    name: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
    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

Configurar a divisão de tráfego: etapas detalhadas

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:

  • Um proxy de destino e uma regra de encaminhamento foram criados, junto com um mapa de URLs chamado global-lb-map.

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

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 (global-lb-basic-check) foi criada. Para ver instruções, consulte uma destas páginas:

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-12 \
    --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=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=global-lb-basic-check \
    --global \
  gcloud compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --global)
}

Criar os serviços

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

Criar o mapa de URL

Console

  1. Acesse a página Balanceamento de carga no Console do Google Cloud.
    Acessar balanceamento de carga
  2. Clique no link global-lb-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 Concluído.
  4. Clique em Adicionar hosts e correspondência de caminho.
  5. No campo Hosts, insira o endereço IP da regra de encaminhamento do balanceador de carga.

  6. Cole o conteúdo YAML a seguir na caixa Correspondência de caminhos:

    defaultService: projects/PROJECT_ID/global/backendServices/red-service
name: matcher1
routeRules:
- priority: 2
  matchRules:
    - prefixMatch: /PREFIX
  routeAction:
    weightedBackendServices:
      - backendService: projects/PROJECT_ID/global/backendServices/green-service
        weight: 95
      - backendService: projects/PROJECT_ID/global/backendServices/blue-service
        weight: 5

  7. Clique em Concluído.

  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 global-lb-map \
  --destination=global-lb-map-config.yaml \
  --global

  2. Atualize o arquivo do mapa de URLs global-lb-map-config.yaml adicionando-o ao fim do arquivo:

    hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/global/backendServices/red-service
  name: matcher1
  routeRules:
  - priority: 2
    matchRules:
      - prefixMatch: /PREFIX
    routeAction:
      weightedBackendServices:
        - backendService: projects/PROJECT_ID/global/backendServices/green-service
          weight: 95
        - backendService: projects/PROJECT_ID/global/backendServices/blue-service
          weight: 5

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

    gcloud compute url-maps import global-lb-map \
   --global \
   --source=global-lb-map-config.yaml

Testar a configuração

Para testar a configuração, primeiro verifique se as solicitações para 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 FORWARDING_RULE_IP_ADDRESS/prefix são divididas conforme o esperado.

O controle de tráfego permite configurar afinidade da sessão com base em um cookie fornecido. 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.

  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 \
    --global

  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: 0
 minimumRingSize: 10000

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

    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 \
    --global

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 ver informações sobre geração de registros e monitoramento, consulte Geração de registros e monitoramento de HTTP(S) externo.

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. O balanceador de carga de aplicativo externo global seleciona apenas uma regra de caminho. No entanto, quando você usa regras de rota, mais de uma pode ser aplicada.

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.

A seguir