Esta página foi traduzida pela API Cloud Translation.

Vista geral da migração

Esta página oferece uma vista geral das diferenças entre o balanceador de carga de aplicações externo global e o balanceador de carga de aplicações clássico, bem como uma vista geral detalhada de como pode migrar os seus recursos do balanceador de carga de aplicações clássico existentes para o balanceador de carga de aplicações externo global.

Para tirar partido das funcionalidades de gestão de tráfego avançada do Application Load Balancer externo global, recomendamos que migre os seus recursos do Application Load Balancer clássico para a infraestrutura do Application Load Balancer externo global.

Compare os balanceadores de carga de aplicações clássicos e os balanceadores de carga de aplicações externos globais

Antes de migrar recursos, compreenda as diferenças entre os Application Load Balancers clássicos e os Application Load Balancers externos globais.

Diferenças de funcionalidades

As seguintes funcionalidades não são suportadas com o Application Load Balancer externo global. Só estão disponíveis com o balanceador de carga de aplicações clássico:

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

Para implementar balanceadores de carga de aplicações externos globais para clusters do GKE, use o controlador GKE Gateway. Para obter instruções de configuração, consulte o artigo Implementar gateways.

Diferenças no plano de dados

A tabela seguinte realça as diferenças no plano de dados entre o Application Load Balancer clássico e o Application Load Balancer externo global. Estas diferenças afetam a forma como os balanceadores de carga respondem a alguns eventos comuns.

Evento	Resposta do balanceador de carga de aplicações clássico	Resposta do balanceador de carga de aplicações externo global
Códigos de estado/erro
Todos os back-ends estão em mau estado de funcionamento	Devolve HTTP 502	Devolve HTTP 503
O pedido usa uma cifra SSL proibida	Devolve HTTP 502	Devolve HTTP 503
Ligação a montante inicial reposta pelo back-end	Devolve HTTP 502	Devolve HTTP 503
Falha na atualização da ligação (por exemplo, durante a atualização para WebSockets)	Devolve HTTP 400	Devolve HTTP 403
O cabeçalho é demasiado grande	Devolve HTTP 413	Devolve HTTP 431
Quotas e limites
Configuração do mapa de URLs	Existem diferenças significativas nos limites de configuração do mapa de URLs entre os dois equilibradores de carga. Para ver detalhes, consulte a documentação Quotas: mapas de URLs.
Tratamento de cabeçalhos
O pedido usa um método HTTP personalizado sem corpo	Adiciona o cabeçalho `Transfer Encoding: Chunked` ao pedido enviado para o back-end	Adiciona o cabeçalho `Content-Length: 0` ao pedido enviado para o back-end
Formato do cabeçalho `X-Forwarded-For` adicionado aos pedidos enviados para o back-end	Usa o delimitador "`,` " entre IPs	Usa o delimitador "`,`" entre os IPs (sem espaço após a vírgula)
Preservação das letras maiúsculas nos cabeçalhos	As maiúsculas e minúsculas do cabeçalho são preservadas	Todas as chaves de cabeçalho são transformadas em minúsculas
Cabeçalhos repetidos com o mesmo nome	Permitido	Os cabeçalhos repetidos podem ser combinados num único cabeçalho, com os valores anexados por ordem e separados por vírgulas, conforme permitido pela RFC 7230.
(Apenas HTTP/1.1) Nome do cabeçalho inválido (por exemplo, carateres não suportados no cabeçalho)	Permitido (para HTTP/1.1)	Devolve HTTP 502 (para HTTP/1.1)
(Apenas HTTP/1.1) Cabeçalho repetido (mas igual) `Content-Length` no pedido	Permitido (para HTTP/1.1)	Devolve HTTP 502 (para HTTP/1.1)
(Apenas HTTP/1.1) Vários anfitriões no cabeçalho	Quando são adicionados 2 ou mais anfitriões e o primeiro é válido, o cabeçalho é aceite	Quando são adicionados 2 ou mais anfitriões e algum deles é inválido, o balanceador de carga devolve HTTP 502
(Apenas HTTP/1.1) `Connection: Keep-Alive` header	Adiciona o `Keep-Alive header` aos pedidos enviados ao back-end por predefinição	Não adiciona este cabeçalho por predefinição
Processamento de pedidos
Barras invertidas no pedido	O URL permanece inalterado	Converte em barra
Unir barras invertidas duplicadas no pedido	As barras invertidas das folhas não foram unidas	Une barras invertidas
`#` no caminho do pedido	Permitido	Devolve HTTP 400
(Apenas HTTP/1.1) Carateres ilegais no caminho do pedido (por exemplo, `\\x7f\\x7f`)	Permitido (para HTTP/1.1)	Devolve HTTP 502 (para HTTP/1.1)
Distribuição de tráfego (configuração do mapa de URLs)
O pedido do cliente inclui um número de porta	O número da porta é ignorado, mesmo que tenha configurado anfitriões com portas no mapa de URLs. Apenas é considerado o nome do anfitrião. Por exemplo, os pedidos de `example.com:5000` são associados ao serviço de back-end para `example.com`.	São considerados o nome de anfitrião e o número da porta. Por exemplo, os pedidos de `example.com:5000` são associados ao serviço de back-end para `example.com:5000`. Se não existir uma correspondência, é usado o serviço de back-end predefinido.

Para saber mais sobre as diferenças e as funcionalidades suportadas, consulte os artigos Comparação de funcionalidades do equilibrador de carga e Vista geral do equilibrador de carga de aplicações.

Migre do balanceador de carga de aplicações externo clássico para o balanceador de carga de aplicações externo global

Para migrar para o Application Load Balancer externo global, altere o esquema de balanceamento de carga dos seus recursos de balanceamento de carga, especificamente, os serviços de back-end e as regras de encaminhamento, de EXTERNAL para EXTERNAL_MANAGED. Para tal, executa uma série de passos de migração em que pode testar partes do tráfego de rede com o novo esquema de equilíbrio de carga antes de finalizar a migração. Durante a migração de recursos, controla a percentagem de pedidos enviados para a infraestrutura do balanceador de carga de aplicações clássico ou para a infraestrutura do balanceador de carga de aplicações externo global.

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

Processo de migração para recursos do balanceador de carga de aplicações clássico. — Processo de migração para recursos do Application Load Balancer clássico (clique para aumentar).

No diagrama anterior, tenha em atenção o seguinte:

Antes da migração dos recursos, todos os pedidos usam a infraestrutura do Application Load Balancer clássico.
Enquanto os recursos são migrados, alguns pedidos são enviados para a infraestrutura do Application Load Balancer externo global e os restantes pedidos são enviados para a infraestrutura do Application Load Balancer clássico.
Após a migração dos recursos, todos os pedidos usam a infraestrutura do Application Load Balancer externo global.

Para ajudar a garantir uma transição sem problemas, migre os seguintes recursos do Application Load Balancer 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 contentores de back-end anexados às regras de encaminhamento do balanceador de carga. Faz isto ao nível da regra de encaminhamento porque os contentores de back-end não têm esquemas de balanceamento de carga.
Migre as regras de encaminhamento do balanceador de carga.

Só pode migrar uma regra de encaminhamento depois de todos os serviços de back-end e os contentores de back-end anexados à regra de encaminhamento já terem sido migrados.

Estados de migração

Migre os recursos definindo-os para estados diferentes antes de alterar o respetivo esquema de balanceamento de carga para EXTERNAL_MANAGED.

PREPARE: defina um recurso para este estado para o preparar para a migração.
TEST_BY_PERCENTAGE: para testar um recurso preparado, defina o recurso para este estado para enviar uma percentagem do tráfego de rede. Esta fase é opcional.
TEST_ALL_TRAFFIC: defina um recurso para este estado para enviar todo o tráfego de rede para o recurso através da infraestrutura do balanceador de carga de aplicações externo global, em vez da infraestrutura do balanceador de carga de aplicações clássico.

Processo de migração

Para ajudar a garantir que não há tempo de inatividade, migre os recursos numa ordem específica da infraestrutura do Application Load Balancer clássico para a infraestrutura do Application Load Balancer externo global e, em seguida, altere o esquema de balanceamento de carga de EXTERNAL para EXTERNAL_MANAGED para finalizar a migração.

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

Repita os passos seguintes para cada serviço de back-end.
1. Prepare o serviço de back-end para a migração.
  
  Antes de poder enviar tráfego através da infraestrutura do Application Load Balancer externo global, defina o estado do serviço de back-end como PREPARE. Isto prepara o serviço de back-end para processar o tráfego de rede da infraestrutura do balanceador de carga de aplicações externo global. Um serviço de back-end demora algum tempo (aproximadamente seis minutos) a ficar pronto para enviar tráfego através da infraestrutura do Application Load Balancer externo global.
2. Opcional: teste o serviço de back-end preparado.
  
  Depois de o serviço de back-end estar no estado PREPARE, defina o respetivo estado como TEST_BY_PERCENTAGE e defina uma percentagem do tráfego de rede do Application Load Balancer clássico para a infraestrutura do Application Load Balancer externo global.
  
  Embora esta fase seja opcional, recomendamos que teste o tráfego antes de migrar um serviço de back-end. Comece com um valor percentual pequeno e monitorize os registos dos recursos. Se o serviço de back-end se comportar como esperado, aumente gradualmente a percentagem para 100%.
  
  No estado TEST_BY_PERCENTAGE, não pode usar as capacidades adicionais da infraestrutura do Application Load Balancer externo global.
3. Envie todo o tráfego de rede do balanceador de carga de aplicações clássico para o serviço de back-end preparado.
  
  Depois de o teste do serviço de back-end ser bem-sucedido, defina o respetivo estado como TEST_ALL_TRAFFIC e envie todo o tráfego de rede do balanceador de carga de aplicações clássico para o serviço de back-end preparado. Um serviço de back-end demora algum tempo (aproximadamente seis minutos) a ficar pronto para processar o tráfego de rede.
  
  No estado TEST_ALL_TRAFFIC, não pode usar as capacidades adicionais da infraestrutura do Application Load Balancer externo global.
4. Altere 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 aplicações externo global, altere o respetivo esquema de balanceamento de carga para EXTERNAL_MANAGED. Um serviço de back-end demora algum tempo (aproximadamente seis minutos) a ser totalmente migrado. Depois de o esquema de balanceamento de carga do serviço de back-end mudar para EXTERNAL_MANAGED, pode usar as funcionalidades avançadas da infraestrutura do Application Load Balancer externo global.
Migre os contentores de back-end do balanceador de carga. Faz isto ao nível da regra de encaminhamento, porque os contentores de back-end não têm esquemas de balanceamento de carga.

Repita os seguintes passos para cada contentor.
1. Prepare o contentor de back-end para a migração.
  
  Antes de poder enviar tráfego através da infraestrutura do Application Load Balancer externo global, defina o estado do contentor de back-end como PREPARE e aguarde algum tempo (aproximadamente seis minutos).
2. Opcional: teste o serviço de back-end preparado.
  
  Depois de o contentor de back-end estar no estado PREPARE, defina o respetivo estado como TEST_BY_PERCENTAGE e defina uma percentagem do tráfego de rede do balanceador de carga da aplicação clássico para a infraestrutura do balanceador de carga da aplicação externo global.
3. Envie todo o tráfego de rede do balanceador de carga de aplicações clássico para o contentor de back-end preparado.
  
  Defina o estado do contentor de back-end como TEST_ALL_TRAFFIC e envie todo o tráfego de rede do balanceador de carga da aplicação clássico para o mesmo. Um bucket de back-end demora algum tempo (aproximadamente seis minutos) a ficar pronto para processar o tráfego de rede.
  
  No estado TEST_ALL_TRAFFIC, não pode usar as capacidades adicionais da infraestrutura do Application Load Balancer externo global.
Migre as regras de encaminhamento.

Para cada regra de encaminhamento, altere o esquema de balanceamento de carga da regra de encaminhamento para EXTERNAL_MANAGED e aguarde algum tempo (aproximadamente seis minutos). Depois de o esquema de equilíbrio de carga da regra de encaminhamento mudar para EXTERNAL_MANAGED, pode usar as funcionalidades avançadas da infraestrutura do Application Load Balancer externo global.

Para ver um processo detalhado passo a passo, consulte o artigo Migre recursos do Application Load Balancer clássico.

O diagrama seguinte mostra os recursos do balanceador de carga de aplicações clássico nos diferentes estados de migração.

Estados de migração dos recursos do balanceador de carga de aplicações clássico. — Estados de migração dos recursos do Application Load Balancer clássico (clique para aumentar).

Após a migração de um recurso, se quiser revertê-lo para o Application Load Balancer clássico, altere o respetivo esquema de balanceamento de carga no prazo de 90 dias após a migração. Não pode reverter um recurso após o período de 90 dias.

Usar afinidade de sessão

Tenha em atenção as seguintes ressalvas ao migrar serviços de back-end do balanceador de carga de aplicações clássico com afinidade de sessão:

A definição de um valor para TEST_BY_PERCENTAGE redireciona alguma segmentação de tráfego do balanceador de carga de aplicações clássico para o balanceador de carga de aplicações externo global. Isto quebra a afinidade do IP do cliente. A alteração da percentagem de migração (por exemplo, aumentá-la em 10%) interrompe a afinidade de sessão para a mesma percentagem de endereços IP do cliente (10% neste exemplo), até que a afinidade seja restabelecida no pedido seguinte.
A definição de um valor para TEST_BY_PERCENTAGE redireciona essa percentagem de tráfego sem um cookie de sessão para o balanceador de carga de aplicações externo global. Também redireciona todo o tráfego com um cookie de sessão para a frota do equilibrador de carga que gerou o cookie.
Se definir um valor de 0% para TEST_BY_PERCENTAGE, não o definir ou definir o serviço de back-end para o estado PREPARE, todos os cookies existentes direcionados para o Application Load Balancer externo global são invalidados.
A alteração do 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 aplicações clássico. Isto permite-lhe reverter o tráfego se houver um problema com a sua aplicação através do balanceador de carga de aplicações externo global. Por exemplo, se um cliente apresentar um cookie da frota do Application Load Balancer clássico, mas o esquema de serviço de back-end for EXTERNAL_MANAGED, o cookie do cliente não é respeitado. O balanceador de carga de aplicações externo global ignora o cookie e cria um novo.

Reverta os recursos migrados

Após a migração de um recurso, se quiser revertê-lo da infraestrutura do balanceador de carga de aplicações externo global para a infraestrutura do balanceador de carga de aplicações clássico, pode fazê-lo no prazo de 90 dias após a alteração do respetivo esquema de balanceamento de carga.

A reversão de um serviço de back-end para o esquema EXTERNAL requer a reversão da regra de encaminhamento. A reversão de uma regra de encaminhamento para o esquema EXTERNAL não requer a reversão dos serviços de back-end.

Para reverter recursos, siga estes passos:

Remova todas as novas funcionalidades de gestão de tráfego avançada do balanceador de carga de aplicações externo global configurado no recurso.
Reverta as regras de encaminhamento.

Altere o esquema de balanceamento de carga das regras de encaminhamento de EXTERNAL_MANAGED para EXTERNAL.
Reverta os contentores de back-end.
1. Defina o estado de migração dos contentores de back-end para TEST_ALL_TRAFFIC e aguarde algum tempo (aproximadamente seis minutos).
2. Opcional: para diminuir o tráfego, defina o estado de migração dos contentores de back-end como TEST_BY_PERCENTAGE e defina uma percentagem do tráfego.
3. Defina o estado de migração dos contentores de back-end como PREPARE.
4. Reverter os contentores de back-end para os respetivos estados pré-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 percentagem do tráfego.
3. Defina o estado de migração dos serviços de back-end como PREPARE.
4. Reverter os serviços de back-end para os respetivos estados pré-migração.

Para ver um processo passo a passo detalhado, consulte o artigo Reverter recursos migrados para o Application Load Balancer clássico.

Acompanhe o processo de migração

Durante a migração dos seus recursos, pode verificar os respetivos esquemas de equilíbrio de carga através da visualização do seguinte:

Os painéis de controlo de registo e monitorização do balanceador de carga de aplicações externo global. Para mais informações, consulte o artigo Registo e monitorização do Application Load Balancer externo global.
Os valores dos seguintes cabeçalhos de pedidos e respostas HTTP:
- X-External-Managed-Migration-Scheme-Override: este cabeçalho do pedido encaminha o pedido com base no respetivo valor. Se o valor do cabeçalho for EXTERNAL, direciona o pedido para a infraestrutura do Application Load Balancer clássico. Se o valor for EXTERNAL_MANAGED, encaminha o pedido através da infraestrutura do balanceador de carga da aplicação externo global.
  
  Use este cabeçalho para direcionar um pedido para um conjunto específico de balanceadores de carga.
- X-External-Managed-Migration-Selected-Scheme: este cabeçalho de pedido e resposta informa o back-end e o cliente sobre o esquema de equilíbrio de carga usado para encaminhar o pedido. O cabeçalho é devolvido ao cliente e transmitido ao back-end do cliente.
  
  Se o pedido for encaminhado através da infraestrutura do Application Load Balancer clássico, o valor é EXTERNAL. Se o pedido for encaminhado através da infraestrutura do Application Load Balancer externo global, o respetivo valor é EXTERNAL_MANAGED.