Visão geral da migração

Visualização

Este produto ou recurso está sujeito aos "Termos das ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos do serviço. Os produtos e recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Esta página mostra as 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 geral detalhada de como migrar seus recursos do balanceador de carga de aplicativo clássico para o balanceador de carga de aplicativo externo global.

Para aproveitar os recursos de gerenciamento de tráfego avançado do balanceador de carga de aplicativo externo global, recomendamos que você migre seus 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. Somente 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.

Para saber mais sobre as diferenças e os recursos com suporte, 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 balanceador de carga de aplicativo 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, você executa uma série de etapas de migração em que pode testar partes do tráfego de rede com o novo esquema de balanceamento de carga antes de finalizar 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 para a infraestrutura do balanceador de carga de aplicativo externo global.

O diagrama a seguir 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 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 clássica do Application Load Balancer.
• 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 demais são enviadas para a infraestrutura do balanceador de carga de aplicativo clássico.
• Depois que os recursos forem migrados, todas as solicitações vão usar a infraestrutura do balanceador de carga de aplicativo externo global.

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

1. Migrar todos os serviços de back-end anexados às regras de encaminhamento do balanceador de carga.

2. Migrar 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.

3. Migrar 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 à regra de encaminhamento já foram migrados.

Estados de migração

Você migra recursos definindo-os em estados diferentes antes de mudar o esquema de balanceamento de carga para EXTERNAL_MANAGED.

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

Observação: depois de mudar o estado de um recurso de PREPARE para TEST_BY_PERCENTAGE ou TEST_ALL_TRAFFIC, aguarde um tempo (aproximadamente seis minutos) para que o recurso esteja pronto para aceitar tráfego. O recurso precisa estar no estado TEST_ALL_TRAFFIC antes de mudar o esquema de balanceamento de carga.

Processo de migração

Para garantir que não haja 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 finalizar a migração.

1. 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 estar 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 testar o tráfego antes de migrar um serviço de back-end. Comece com um pequeno valor percentual e monitore os registros dos recursos. Se o serviço de back-end se comportar como esperado, aumente gradualmente a porcentagem para 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 dele como TEST_ALL_TRAFFIC e envie todo o tráfego de rede do Application Load Balancer 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.

2. 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 tempo (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.

3. Migrar as regras de encaminhamento.

   Para cada regra de encaminhamento, mude o esquema de balanceamento de carga da regra para EXTERNAL_MANAGED e aguarde um tempo (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 global externa do balanceador de carga de aplicativo.

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 de recursos do balanceador de carga de aplicativo clássico (clique para ampliar).

Depois de migrar um recurso, se você quiser reverter para o Application Load Balancer clássico, mude o esquema de balanceamento de carga dele 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:

• A definição de um valor para TEST_BY_PERCENTAGE redireciona parte do tráfego direcionado ao balanceador de carga de aplicativo clássico para o balanceador de carga de aplicativo externo global. Isso quebra a afinidade do 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.

• A definição de 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 do balanceador de carga que gerou o cookie.

• Definir um valor para TEST_BY_PERCENTAGE como 0%, não definir ou definir o serviço de back-end para o estado PREPARE invalida todos os cookies direcionados ao balanceador de carga de aplicativo externo global.

• A mudança 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 aplicativo clássico. Isso permite que você reverter o tráfego se houver um problema com seu 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 de 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 a migração 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 alteração 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. O 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 os recursos, siga estas etapas:

1. Remova todos os novos recursos avançados de gerenciamento de tráfego do balanceador de carga de aplicativo externo global configurado no recurso.

2. Desfaça as regras de encaminhamento.

   Mude o esquema de balanceamento de carga das regras de encaminhamento de EXTERNAL_MANAGED para EXTERNAL.

3. Reverta os buckets de back-end.

   1. Defina o estado de migração dos buckets de back-end como TEST_ALL_TRAFFIC e aguarde um tempo (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 de migração dos buckets de back-end como PREPARE.
   4. Reverter os buckets de back-end para os estados anteriores à migração.

4. 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 um 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 de migração dos serviços de back-end como PREPARE.
   4. Reverter os serviços de back-end para os estados anteriores à migração.

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

Acompanhar o processo de migração

Durante a migração dos recursos, você pode conferir os esquemas de balanceamento de carga deles:

• 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 encaminha a solicitação com base no valor dela. Se o valor do cabeçalho for EXTERNAL, ele direcionará a solicitação para a infraestrutura do balanceador de carga de aplicativo clássico. Se o valor for EXTERNAL_MANAGED, ele encaminhará a solicitação pela infraestrutura do balanceador de carga de aplicativo externo global.

    Use este cabeçalho para direcionar uma solicitação a uma frota específica do balanceador de carga.

  • X-External-Managed-Migration-Selected-Scheme: esse cabeçalho de solicitação e resposta informa o back-end e o 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 roteada pela infraestrutura global externa do balanceador de carga de aplicativo, o valor será EXTERNAL_MANAGED.

A seguir

• Migrar recursos do balanceador de carga de aplicativo clássico
• Reverter recursos migrados para o balanceador de carga de aplicativo clássico