Esta página foi traduzida pela API Cloud Translation.

Visão geral da migração

Nesta página, você encontra uma visão geral das diferenças entre o balanceador de carga de aplicativo externo global e o balanceador de carga de aplicativo clássico, além de uma visão detalhada de como migrar seus recursos atuais do balanceador de carga de aplicativo clássico para o balanceador de carga de aplicativo externo global.

Para aproveitar os recursos de gerenciamento avançado de tráfego do balanceador de carga de aplicativo externo global, recomendamos migrar os recursos do balanceador de carga de aplicativo clássico para a infraestrutura do balanceador de carga de aplicativo externo global.

Comparar balanceadores de carga de aplicativo clássicos e balanceadores de carga de aplicativo externos globais

Antes de migrar recursos, entenda as diferenças entre os balanceadores de carga de aplicativo clássicos e os balanceadores de carga de aplicativo externos globais.

Diferenças de recursos

Os seguintes recursos não são compatíveis com o balanceador de carga de aplicativo externo global. Eles estão disponíveis apenas com o balanceador de carga de aplicativo clássico:

Nível de rede padrão
Controlador de entrada do GKE

Para implantar balanceadores de carga de aplicativo externos globais para clusters do GKE, use o controlador de gateway do GKE. Para instruções de configuração, consulte Como implantar gateways.

Diferenças do plano de dados

A tabela a seguir destaca as diferenças no plano de dados entre o balanceador de carga de aplicativo clássico e o balanceador de carga de aplicativo externo global. Essas diferenças afetam a forma como os balanceadores de carga respondem a alguns eventos comuns.

Evento	Resposta do balanceador de carga de aplicativo clássico	Resposta do balanceador de carga de aplicativo externo global
Status/códigos de erro
Nenhum back-end está íntegro	Retorna HTTP 502	Retorna HTTP 503
A solicitação usa uma criptografia SSL banida	Retorna HTTP 502	Retorna HTTP 503
Conexão de upstream inicial redefinida pelo back-end	Retorna HTTP 502	Retorna HTTP 503
Falha no upgrade da conexão (por exemplo, ao fazer upgrade para Websockets)	Retorna HTTP 400	Retorna HTTP 403
O cabeçalho é grande demais	Retorna HTTP 413	Retorna HTTP 431
Cotas e limites
Configuração do mapa de URL	Há diferenças significativas nos limites de configuração do mapa de URL entre os dois balanceadores de carga. Para mais detalhes, consulte a documentação Cotas: mapas de URL.
Processamento de cabeçalhos
A solicitação usa um método HTTP personalizado sem corpo	Adiciona o cabeçalho `Transfer Encoding: Chunked` à solicitação enviada ao back-end	Adiciona o cabeçalho `Content-Length: 0` à solicitação enviada ao back-end
Formato do cabeçalho `X-Forwarded-For` adicionado às solicitações enviadas ao back-end	Usa o delimitador "`,` " entre IPs	Usa o delimitador "`,`" entre IPs (sem espaço depois da vírgula)
Preservação de caixa do cabeçalho	A caixa do cabeçalho é preservada	Todas as chaves do cabeçalho são transformadas em minúsculas
Cabeçalhos repetidos com o mesmo nome	Permitido	Cabeçalhos repetidos podem ser combinados em um único cabeçalho, com os valores anexados em ordem e separados por vírgula, conforme permitido pela RFC 7230.
(Somente HTTP/1.1) Nome de cabeçalho inválido (por exemplo, caracteres incompatíveis no cabeçalho)	Permitido (para HTTP/1.1)	Retorna HTTP 502 (para HTTP/1.1)
(Somente HTTP/1.1) Cabeçalho `Content-Length` repetido (mas igual) na solicitação	Permitido (para HTTP/1.1)	Retorna HTTP 502 (para HTTP/1.1)
(Somente HTTP/1.1) Vários hosts no cabeçalho	Quando dois ou mais hosts são adicionados e o primeiro é válido, o cabeçalho é aceito	Quando dois ou mais hosts são adicionados e alguns são inválidos, o balanceador de carga retorna HTTP 502
(Somente HTTP/1.1) Cabeçalho `Connection: Keep-Alive`	Por padrão, adiciona `Keep-Alive header` às solicitações enviadas ao back-end	Por padrão, não adiciona esse cabeçalho
Processamento de solicitações
Barras invertidas na solicitação	O URL não foi alterado	Converte para barra
Mesclar barras duplicadas na solicitação	Deixa as barras sem mesclar	Mescla barras
"#" no caminho da solicitação	Permitido	Retorna HTTP 400
(Somente HTTP/1.1) Caracteres inválidos no caminho de solicitação (por exemplo, "\\x7f\\x7f")	Permitido (para HTTP/1.1)	Retorna HTTP 502 (para HTTP/1.1)
Distribuição de tráfego (configuração do mapa de URL)
A solicitação do cliente inclui um número de porta	O número da porta é ignorado mesmo que você tenha configurado hosts com portas no mapa de URL. Apenas o nome do host é considerado. Por exemplo, as solicitações para `example.com:5000` são correspondidas com o serviço de back-end para `example.com`.	O nome do host e o número da porta são considerados. Por exemplo, as solicitações para `example.com:5000` são correspondidas com o serviço de back-end para `example.com:5000`. Se não houver uma correspondência, o serviço de back-end padrão será usado.

Devido a diferenças arquitetônicas, ao migrar para o balanceador de carga de aplicativo externo global, talvez haja um aumento no número de conexões com seus back-ends, especialmente ao usar o protocolo HTTP/1.1. Isso pode aumentar o consumo de memória nas instâncias de back-end. Monitore o uso de recursos de back-end durante e após a migração.

Para saber mais sobre as diferenças e os recursos compatíveis, consulte Comparação de recursos do balanceador de carga e Visão geral do balanceador de carga de aplicativo.

Migrar do balanceador de carga de aplicativo clássico para o externo global

Para migrar para o balanceador de carga de aplicativo externo global, mude o esquema de balanceamento de carga dos recursos de balanceamento de carga, especificamente os serviços de back-end e as regras de encaminhamento, de EXTERNAL para EXTERNAL_MANAGED. Para fazer isso, execute uma série de etapas de migração em que é possível testar partes do tráfego de rede com o novo esquema de balanceamento de carga antes de concluir a migração. Durante a migração de recursos, você controla qual porcentagem de solicitações é enviada para a infraestrutura do balanceador de carga de aplicativo clássico ou do balanceador de carga de aplicativo externo global.

O diagrama a seguir mostra os esquemas de balanceamento de carga dos seus recursos antes e depois da migração.

Processo de migração para recursos do balanceador de carga de aplicativo clássico. — Processo de migração para recursos do balanceador de carga de aplicativo clássico (clique para ampliar).

No diagrama anterior, observe o seguinte:

Antes da migração dos recursos, todas as solicitações usam a infraestrutura do balanceador de carga de aplicativo clássico.
Enquanto os recursos são migrados, algumas solicitações são enviadas para a infraestrutura do balanceador de carga de aplicativo externo global, e as solicitações restantes são enviadas para a infraestrutura do balanceador de carga de aplicativo clássico.
Depois que os recursos são migrados, todas as solicitações usam a infraestrutura do balanceador de carga de aplicativo externo global.

Para facilitar a transição, migre os seguintes recursos do balanceador de carga de aplicativo clássico na ordem especificada:

Migre todos os serviços de back-end anexados às regras de encaminhamento do balanceador de carga.
Migre todos os buckets de back-end anexados às regras de encaminhamento do balanceador de carga. Isso é feito no nível da regra de encaminhamento porque os buckets de back-end não têm esquemas de balanceamento de carga.
Migre as regras de encaminhamento do balanceador de carga.

Só é possível migrar uma regra de encaminhamento depois que todos os serviços de back-end e buckets de back-end anexados a ela já tiverem sido migrados.

Estados de migração

Para migrar recursos, defina estados diferentes antes de mudar o esquema de balanceamento de carga para EXTERNAL_MANAGED.

PREPARE: defina um recurso nesse estado para prepará-lo para a migração.
TEST_BY_PERCENTAGE: para testar um recurso preparado, defina o recurso como esse estado para enviar uma porcentagem do tráfego de rede. Esta etapa é opcional.
TEST_ALL_TRAFFIC: defina um recurso nesse estado para enviar todo o tráfego de rede a ele pela infraestrutura do balanceador de carga de aplicativo externo global em vez da infraestrutura do balanceador de carga de aplicativo clássico.

Processo de migração

Para evitar tempo de inatividade, migre os recursos em uma ordem específica da infraestrutura do balanceador de carga de aplicativo clássico para a infraestrutura do balanceador de carga de aplicativo externo global e mude o esquema de balanceamento de carga de EXTERNAL para EXTERNAL_MANAGED para concluir a migração.

Migre os serviços de back-end do balanceador de carga.

Repita as etapas a seguir para cada serviço de back-end.
1. Prepare o serviço de back-end para a migração.
  
  Antes que qualquer tráfego possa ser enviado pela infraestrutura do balanceador de carga de aplicativo externo global, defina o estado do serviço de back-end como PREPARE. Isso prepara o serviço de back-end para processar o tráfego de rede da infraestrutura do balanceador de carga de aplicativo externo global. Um serviço de back-end leva algum tempo (aproximadamente seis minutos) para ficar pronto para enviar tráfego pela infraestrutura do balanceador de carga de aplicativo externo global.
2. Opcional: teste o serviço de back-end preparado.
  
  Depois que o serviço de back-end estiver no estado PREPARE, defina o estado como TEST_BY_PERCENTAGE e defina uma porcentagem do tráfego de rede do balanceador de carga de aplicativo clássico para a infraestrutura do balanceador de carga de aplicativo externo global.
  
  Embora essa etapa seja opcional, recomendamos que você teste o tráfego antes de migrar um serviço de back-end. Comece com uma pequena porcentagem e monitore os registros dos recursos. Se o serviço de back-end se comportar como esperado, aumente gradualmente a porcentagem até 100%.
  
  No estado TEST_BY_PERCENTAGE, não é possível usar os recursos adicionais da infraestrutura do balanceador de carga de aplicativo externo global.
3. Envie todo o tráfego de rede do balanceador de carga de aplicativo clássico para o serviço de back-end preparado.
  
  Depois que o teste do serviço de back-end for concluído, defina o estado como TEST_ALL_TRAFFIC e envie todo o tráfego de rede do balanceador de carga de aplicativo clássico para o serviço de back-end preparado. Um serviço de back-end leva algum tempo (aproximadamente seis minutos) para ficar pronto para processar o tráfego de rede.
  
  No estado TEST_ALL_TRAFFIC, não é possível usar os recursos adicionais da infraestrutura do balanceador de carga de aplicativo externo global.
4. Mude o esquema de balanceamento de carga do serviço de back-end migrado para EXTERNAL_MANAGED.
  
  Depois de testar o serviço de back-end preparado na infraestrutura do balanceador de carga de aplicativo externo global, mude o esquema de balanceamento de carga para EXTERNAL_MANAGED. Um serviço de back-end leva algum tempo (aproximadamente seis minutos) para ser totalmente migrado. Depois que o esquema de balanceamento de carga do serviço de back-end mudar para EXTERNAL_MANAGED, você poderá usar os recursos avançados da infraestrutura do balanceador de carga de aplicativo externo global.
Migre os buckets de back-end do balanceador de carga. Isso é feito no nível da regra de encaminhamento porque os buckets de back-end não têm esquemas de balanceamento de carga.

Repita as etapas a seguir para cada bucket.
1. Prepare o bucket de back-end para a migração.
  
  Antes que qualquer tráfego possa ser enviado pela infraestrutura do balanceador de carga de aplicativo externo global, defina o estado do bucket de back-end como PREPARE e aguarde um pouco (aproximadamente seis minutos).
2. Opcional: teste o serviço de back-end preparado.
  
  Depois que o bucket de back-end estiver no estado PREPARE, defina o estado como TEST_BY_PERCENTAGE e defina uma porcentagem do tráfego de rede do balanceador de carga de aplicativo clássico para a infraestrutura do balanceador de carga de aplicativo externo global.
3. Envie todo o tráfego de rede do balanceador de carga de aplicativo clássico para o bucket de back-end preparado.
  
  Defina o estado do bucket de back-end como TEST_ALL_TRAFFIC e envie todo o tráfego de rede do balanceador de carga de aplicativo clássico para ele. Um bucket de back-end leva algum tempo (aproximadamente seis minutos) para ficar pronto para processar o tráfego de rede.
  
  No estado TEST_ALL_TRAFFIC, não é possível usar os recursos adicionais da infraestrutura do balanceador de carga de aplicativo externo global.
Migre as regras de encaminhamento.

Para cada regra de encaminhamento, mude o esquema de balanceamento de carga para EXTERNAL_MANAGED e aguarde um pouco (aproximadamente seis minutos). Depois que o esquema de balanceamento de carga da regra de encaminhamento mudar para EXTERNAL_MANAGED, será possível usar os recursos avançados da infraestrutura do balanceador de carga de aplicativo externo global.

Para um processo detalhado, consulte Migrar recursos do balanceador de carga de aplicativo clássico.

O diagrama a seguir mostra os recursos do balanceador de carga de aplicativo clássico nos diferentes estados de migração.

Estados de migração dos recursos do balanceador de carga de aplicativo clássico. — Estados de migração dos recursos do balanceador de carga de aplicativo clássico (clique para ampliar).

Depois de migrar um recurso, se você quiser reverter para o balanceador de carga de aplicativo clássico, mude o esquema de balanceamento de carga em até 90 dias após a migração. Não é possível reverter um recurso após o período de 90 dias.

Como usar a afinidade de sessão

Considere as seguintes ressalvas ao migrar serviços de back-end do balanceador de carga de aplicativo clássico com afinidade da sessão:

Definir um valor para TEST_BY_PERCENTAGE redireciona parte do tráfego destinado ao balanceador de carga de aplicativo clássico para o balanceador de carga de aplicativo externo global. Isso quebra a afinidade de IP do cliente. Mudar a porcentagem de migração (por exemplo, aumentar em 10%) interrompe a afinidade da sessão para a mesma porcentagem de endereços IP do cliente (10% neste exemplo) até que a afinidade seja restabelecida na próxima solicitação.
Definir um valor para TEST_BY_PERCENTAGE redireciona essa porcentagem de tráfego sem um cookie de sessão para o balanceador de carga de aplicativo externo global. Ele também redireciona todo o tráfego com um cookie de sessão para a frota de balanceadores de carga que gerou o cookie.
Definir um valor de 0% para TEST_BY_PERCENTAGE, deixar sem definição ou definir o serviço de back-end como o estado PREPARE invalida todos os cookies atuais direcionados ao balanceador de carga de aplicativo externo global.
Mudar o esquema de balanceamento de carga do serviço de back-end para EXTERNAL_MANAGED invalida todos os cookies gerados pela frota do balanceador de carga de aplicativo clássico. Isso permite reverter o tráfego se houver um problema com o aplicativo usando o balanceador de carga de aplicativo externo global. Por exemplo, se um cliente apresentar um cookie da frota do balanceador de carga de aplicativo clássico, mas o esquema do serviço de back-end for EXTERNAL_MANAGED, o cookie do cliente não será aceito. O balanceador de carga de aplicativo externo global ignora o cookie e cria um novo.

Reverter recursos migrados

Depois de migrar um recurso, se você quiser reverter da infraestrutura do balanceador de carga de aplicativo externo global para a infraestrutura do balanceador de carga de aplicativo clássico, faça isso em até 90 dias após a mudança do esquema de balanceamento de carga.

Para reverter um serviço de back-end para o esquema EXTERNAL, é necessário reverter a regra de encaminhamento. A reversão de uma regra de encaminhamento para o esquema EXTERNAL não exige a reversão dos serviços de back-end.

Para reverter de recursos, siga estas etapas:

Remova todos os novos recursos avançados de gerenciamento de tráfego do balanceador de carga de aplicativo externo global configurados no recurso.
Faça o rollback das regras de encaminhamento.

Mude o esquema de balanceamento de carga das regras de encaminhamento de EXTERNAL_MANAGED para EXTERNAL.
Reverta os buckets de back-end.
1. Defina o estado da migração dos buckets de back-end como TEST_ALL_TRAFFIC e aguarde um pouco (aproximadamente seis minutos).
2. Opcional: para diminuir o tráfego, defina o estado de migração dos buckets de back-end como TEST_BY_PERCENTAGE e defina uma porcentagem do tráfego.
3. Defina o estado da migração dos buckets de back-end como PREPARE.
4. Reverta os buckets de back-end para os estados anteriores à migração.
Reverta os serviços de back-end.
1. Defina o estado de migração dos serviços de back-end como TEST_ALL_TRAFFIC e aguarde algum tempo (aproximadamente seis minutos).
2. Opcional: para diminuir o tráfego, defina o estado de migração dos serviços de back-end como TEST_BY_PERCENTAGE e defina uma porcentagem do tráfego.
3. Defina o estado da migração dos serviços de back-end como PREPARE.
4. Reverta os serviços de back-end para os estados anteriores à migração.

Para um processo detalhado, consulte Reverter recursos migrados para o balanceador de carga de aplicativo clássico.

Acompanhar o processo de migração

Ao migrar seus recursos, você pode verificar os esquemas de balanceamento de carga deles consultando o seguinte:

Os painéis de geração de registros e monitoramento do balanceador de carga de aplicativo externo global. Para mais informações, consulte Geração de registros e monitoramento do balanceador de carga de aplicativo externo global.
Os valores dos seguintes cabeçalhos de solicitação e resposta HTTP:
- X-External-Managed-Migration-Scheme-Override: esse cabeçalho de solicitação direciona a solicitação com base no valor dela. Se o valor do cabeçalho for EXTERNAL, ele vai direcionar a solicitação para a infraestrutura do balanceador de carga de aplicativo clássico. Se o valor for EXTERNAL_MANAGED, ele vai rotear a solicitação pela infraestrutura do balanceador de carga de aplicativo externo global.
  
  Use esse cabeçalho para direcionar uma solicitação a uma frota específica de balanceadores de carga.
- X-External-Managed-Migration-Selected-Scheme: esse cabeçalho de solicitação e resposta informa ao back-end e ao cliente sobre o esquema de balanceamento de carga usado para rotear a solicitação. O cabeçalho é retornado ao cliente e transmitido ao back-end do cliente.
  
  Se a solicitação for roteada pela infraestrutura do balanceador de carga de aplicativo clássico, o valor será EXTERNAL. Se a solicitação for encaminhada pela infraestrutura do balanceador de carga de aplicativo externo global, o valor será EXTERNAL_MANAGED.