Descripción general de la migración

En esta página, se proporciona una descripción general de las diferencias entre el balanceador de cargas de aplicaciones externo global y el balanceador de cargas de aplicaciones clásico, y una descripción general detallada de cómo puedes migrar tus recursos existentes del balanceador de cargas de aplicaciones clásico al balanceador de cargas de aplicaciones externo global.

Para aprovechar las funciones de administración avanzada del tráfico del balanceador de cargas de aplicaciones externo global, te recomendamos que migres tus recursos del balanceador de cargas de aplicaciones clásico a la infraestructura del balanceador de cargas de aplicaciones externo global.

Comparación entre los balanceadores de cargas de aplicaciones clásicos y los balanceadores de cargas de aplicaciones externos globales

Antes de migrar recursos, comprende las diferencias entre los balanceadores de cargas de aplicaciones clásicos y los balanceadores de cargas de aplicaciones externos globales.

Diferencias entre las funciones

Las siguientes funciones no son compatibles con el balanceador de cargas de aplicaciones externo global. Solo están disponibles con el balanceador de cargas de aplicaciones clásico:

Diferencias entre planos de datos

En la siguiente tabla, se destacan las diferencias en el plano de datos entre el balanceador de cargas de aplicaciones clásico y el balanceador de cargas de aplicaciones externo global. Estas diferencias afectan la forma en que los balanceadores de cargas responden a algunos eventos comunes.

Evento Respuesta del balanceador de cargas de aplicaciones clásico Respuesta del balanceador de cargas de aplicaciones externo global
Códigos de error o estado
Todos los backends están en mal estado Muestra HTTP 502 Muestra HTTP 503
La solicitud usa un algoritmo de cifrado SSL prohibido Muestra HTTP 502 Muestra HTTP 503
Conexión ascendente anterior que el backend restablece Muestra HTTP 502 Muestra HTTP 503
Actualización de conexión con errores (por ejemplo, mientras se actualiza a Websockets) Muestra HTTP 400 Muestra HTTP 403
El encabezado es demasiado grande Muestra HTTP 413 Muestra HTTP 431
Cuotas y límites
Configuración del mapa de URL Existen diferencias significativas en los límites de configuración del mapa de URL entre los dos balanceadores de cargas. Para obtener más información, consulta la documentación Cuotas: mapas de URL.
Manejo de encabezados
La solicitud usa un método HTTP personalizado sin cuerpo Agrega el encabezado Transfer Encoding: Chunked a la solicitud enviada al backend Agrega el encabezado Content-Length: 0 a la solicitud enviada al backend
Formato del encabezado X-Forwarded-For que se agregó a las solicitudes enviadas al backend Usa el delimitador “, ” entre las IP Usa el delimitador “,” entre las IP (sin espacio después de la coma).
Conservación de casos de encabezado Se conserva el caso de encabezado Todas las claves de encabezado se transforman en minúsculas
Encabezados repetidos con el mismo nombre Permitido Los encabezados repetidos se pueden combinar en un solo encabezado, con los valores anexados en orden y separados por comas, como se permite en RFC 7230.
(Solo HTTP/1.1) Nombre de encabezado no válido (por ejemplo, caracteres no compatibles en el encabezado) Permitido (para HTTP/1.1) Muestra HTTP 502 (para HTTP/1.1)
(Solo HTTP/1.1) Encabezado Content-Length repetido (pero igual) en la solicitud Permitido (para HTTP/1.1) Muestra HTTP 502 (para HTTP/1.1)
(Solo HTTP/1.1) Varios hosts en el encabezado Cuando se agregan 2 o más hosts y el primero es válido, se acepta el encabezado Cuando se agregan 2 o más hosts y ninguno de ellos es válido, el balanceador de cargas muestra HTTP 502
(Solo HTTP/1.1) encabezado Connection: Keep-Alive Agrega Keep-Alive header en las solicitudes enviadas al backend de forma predeterminada. No agrega este encabezado de forma predeterminada
Administra solicitudes
Barras inversas en la solicitud URL sin cambios Convierte a la barra diagonal
Combina barras duplicadas en la solicitud Deja las barras separadas Combina las barras
"#" en la ruta de acceso de la solicitud Permitido Muestra HTTP 400
(Solo HTTP/1.1) Caracteres no permitidos en la ruta de acceso de la solicitud (por ejemplo, “\\x7f\\x7f”) Permitido (para HTTP/1.1) Muestra HTTP 502 (para HTTP/1.1)
Distribución de tráfico (configuración de mapa de URL)
La solicitud del cliente incluye un número de puerto El número de puerto se ignora incluso si configuraste hosts con puertos en el mapa de URL. Solo se considera el nombre de host. Por ejemplo, las solicitudes de example.com:5000 coinciden con el servicio de backend de example.com. Se tienen en cuenta el nombre de host y el número de puerto. Por ejemplo, las solicitudes de example.com:5000 coinciden con el servicio de backend de example.com:5000. Si no hay coincidencia, se usa el servicio de backend predeterminado.

Para obtener más información sobre las diferencias y las funciones compatibles, consulta Comparación de funciones del balanceador de cargas y Descripción general del balanceador de cargas de aplicaciones.

Cómo migrar de un balanceador de cargas de aplicaciones clásico a uno externo global

Para migrar al balanceador de cargas de aplicaciones externo global, cambia el esquema de balanceo de cargas de tus recursos de balanceo de cargas, específicamente, los servicios de backend y las reglas de reenvío, de EXTERNAL a EXTERNAL_MANAGED. Para ello, debes realizar una serie de pasos de migración en los que puedes probar partes de tu tráfico de red con el nuevo esquema de balanceo de cargas antes de finalizar la migración. Durante la migración de recursos, controlas el porcentaje de solicitudes que se envía a la infraestructura del balanceador de cargas de aplicaciones clásico o a la infraestructura del balanceador de cargas de aplicaciones externo global.

En el siguiente diagrama, se muestran los esquemas de balanceo de cargas de tus recursos de balanceo de cargas antes y después de la migración.

Proceso de migración para recursos del balanceador de cargas de aplicaciones clásico
Proceso de migración para recursos del balanceador de cargas de aplicaciones clásico (haz clic para ampliar).

En el diagrama anterior, ten en cuenta lo siguiente:

  • Antes de migrar los recursos, todas las solicitudes usan la infraestructura del balanceador de cargas de aplicaciones clásico.
  • Mientras se migran los recursos, algunas solicitudes se envían a la infraestructura del balanceador de cargas de aplicaciones externo global y las restantes se envían a la infraestructura del balanceador de cargas de aplicaciones clásico.
  • Después de migrar los recursos, todas las solicitudes usan la infraestructura del balanceador de cargas de aplicaciones externo global.

Para garantizar una transición fluida, migra los siguientes recursos del balanceador de cargas de aplicaciones clásico en el orden especificado:

  1. Migra todos los servicios de backend conectados a las reglas de reenvío del balanceador de cargas.

  2. Migra todos los buckets de backend conectados a las reglas de reenvío del balanceador de cargas. Esto se hace a nivel de la regla de reenvío porque los buckets de backend no tienen esquemas de balanceo de cargas.

  3. Migra las reglas de reenvío del balanceador de cargas.

    Solo puedes migrar una regla de reenvío después de que se hayan migrado todos los servicios y buckets de backend adjuntos a la regla de reenvío.

Estados de migración

Para migrar recursos, configúralos en diferentes estados antes de cambiar su esquema de balanceo de cargas a EXTERNAL_MANAGED.

  1. PREPARE: Establece un recurso en este estado para prepararlo para la migración.
  2. TEST_BY_PERCENTAGE: Para probar un recurso preparado, configúralo en este estado para enviar un porcentaje del tráfico de red. Esta etapa es opcional.
  3. TEST_ALL_TRAFFIC: Establece un recurso en este estado para enviar todo el tráfico de red al recurso a través de la infraestructura del balanceador de cargas de aplicaciones externo global en lugar de la infraestructura del balanceador de cargas de aplicaciones clásico.

Proceso de migración

Para garantizar que no haya tiempo de inactividad, migras los recursos en un orden específico de la infraestructura del balanceador de cargas de aplicaciones clásico a la infraestructura del balanceador de cargas de aplicaciones externo global y, luego, cambias el esquema de balanceo de cargas de EXTERNAL a EXTERNAL_MANAGED para finalizar la migración.

  1. Migra los servicios de backend del balanceador de cargas.

    Repite los siguientes pasos para cada servicio de backend.

    1. Prepara el servicio de backend para la migración.

      Antes de que se pueda enviar tráfico a través de la infraestructura del balanceador de cargas de aplicaciones externo global, configura el estado del servicio de backend como PREPARE. Esto prepara el servicio de backend para controlar el tráfico de red de la infraestructura del balanceador de cargas de aplicaciones externo global. Un servicio de backend tarda un tiempo (aproximadamente seis minutos) en estar listo para enviar tráfico a través de la infraestructura del balanceador de cargas de aplicaciones externo global.

    2. Opcional: Prueba el servicio de backend preparado.

      Después de que el servicio de backend esté en el estado PREPARE, configúralo en TEST_BY_PERCENTAGE y establece un porcentaje del tráfico de red del balanceador de cargas de aplicaciones clásico en la infraestructura del balanceador de cargas de aplicaciones externo global.

      Si bien esta etapa es opcional, te recomendamos que pruebes el tráfico antes de migrar un servicio de backend. Comienza con un valor de porcentaje pequeño y supervisa los registros de los recursos. Si el servicio de backend se comporta como se espera, aumenta gradualmente el porcentaje al 100%.

      En el estado TEST_BY_PERCENTAGE, no puedes usar las capacidades adicionales de la infraestructura del balanceador de cargas de aplicaciones externo global.

    3. Envía todo el tráfico de red del balanceador de cargas de aplicaciones clásico al servicio de backend preparado.

      Después de que la prueba del servicio de backend se realice correctamente, establece su estado en TEST_ALL_TRAFFIC y envía todo el tráfico de red del balanceador de cargas de aplicaciones clásico al servicio de backend preparado. Un servicio de backend tarda un tiempo (alrededor de seis minutos) en estar listo para controlar el tráfico de red.

      En el estado TEST_ALL_TRAFFIC, no puedes usar las capacidades adicionales de la infraestructura del balanceador de cargas de aplicaciones externo global.

    4. Cambia el esquema de balanceo de cargas del servicio de backend migrado a EXTERNAL_MANAGED.

      Después de probar el servicio de backend preparado en la infraestructura del balanceador de cargas de aplicaciones externo global, cambia su esquema de balanceo de cargas a EXTERNAL_MANAGED. Un servicio de backend tarda un tiempo (alrededor de seis minutos) en migrar por completo. Después de que el esquema de balanceo de cargas del servicio de backend cambie a EXTERNAL_MANAGED, podrás usar las funciones avanzadas de la infraestructura del balanceador de cargas de aplicaciones externo global.

  2. Migra los buckets de backend del balanceador de cargas. Para ello, debes hacerlo a nivel de la regla de reenvío, ya que los buckets de backend no tienen esquemas de balanceo de cargas.

    Repite los siguientes pasos para cada bucket.

    1. Prepara el bucket de backend para la migración.

      Antes de que se pueda enviar tráfico a través de la infraestructura del balanceador de cargas de aplicaciones externo global, configura el estado del bucket de backend como PREPARE y espera un tiempo (aproximadamente seis minutos).

    2. Opcional: Prueba el servicio de backend preparado.

      Después de que el bucket de backend esté en el estado PREPARE, configúralo en TEST_BY_PERCENTAGE y establece un porcentaje del tráfico de red del balanceador de cargas de aplicaciones clásico en la infraestructura del balanceador de cargas de aplicaciones externo global.

    3. Envía todo el tráfico de red del balanceador de cargas de aplicaciones clásico al bucket de backend preparado.

      Establece el estado del bucket de backend en TEST_ALL_TRAFFIC y envía todo el tráfico de red del balanceador de cargas de aplicaciones clásico a él. Un bucket de backend tarda un tiempo (alrededor de seis minutos) en estar listo para controlar el tráfico de red.

      En el estado TEST_ALL_TRAFFIC, no puedes usar las capacidades adicionales de la infraestructura del balanceador de cargas de aplicaciones externo global.

  3. Migra las reglas de reenvío.

    Para cada regla de reenvío, cambia el esquema de balanceo de cargas de la regla de reenvío a EXTERNAL_MANAGED y espera un tiempo (aproximadamente seis minutos). Después de que el esquema de balanceo de cargas de la regla de reenvío cambie a EXTERNAL_MANAGED, podrás usar las funciones avanzadas de la infraestructura del balanceador de cargas de aplicaciones externo global.

Para obtener un proceso detallado paso a paso, consulta Cómo migrar recursos desde el balanceador de cargas de aplicaciones clásico.

En el siguiente diagrama, se muestran los recursos del balanceador de cargas de aplicaciones clásico en los diferentes estados de migración.

Estados de migración de los recursos del balanceador de cargas de aplicaciones clásico
Estados de migración de los recursos del balanceador de cargas de aplicaciones clásico (haz clic para ampliar).

Después de migrar un recurso, si deseas revertirlo al balanceador de cargas de aplicaciones clásico, cambia su esquema de balanceo de cargas en un plazo de 90 días después de la migración. No puedes revertir un recurso después de que haya transcurrido el plazo de 90 días.

Usa la afinidad de sesión

Ten en cuenta las siguientes advertencias cuando migres los servicios de backend del balanceador de cargas de aplicaciones clásico con afinidad de sesión:

  • Si configuras un valor para TEST_BY_PERCENTAGE, se redireccionará parte del tráfico segmentado para el balanceador de cargas de aplicaciones clásico al balanceador de cargas de aplicaciones externo global. Esto interrumpe la afinidad de la IP del cliente. Si cambias el porcentaje de migración (por ejemplo, lo aumentas en un 10%), se rompe la afinidad de la sesión para el mismo porcentaje de direcciones IP de cliente (10% en este ejemplo), hasta que se restablece la afinidad en la siguiente solicitud.

  • Si configuras un valor para TEST_BY_PERCENTAGE, se redireccionará ese porcentaje de tráfico sin una cookie de sesión al balanceador de cargas de aplicaciones externo global. También redirecciona todo el tráfico con una cookie de sesión a la flota del balanceador de cargas que generó la cookie.

  • Si estableces un valor de TEST_BY_PERCENTAGE en 0%, no lo estableces o configuras el servicio de backend en el estado PREPARE, se invalidan todas las cookies existentes que se dirigen al balanceador de cargas de aplicaciones externo global.

  • Si cambias el esquema de balanceo de cargas del servicio de backend a EXTERNAL_MANAGED, se invalidan todas las cookies que genera la flota del balanceador de cargas de aplicaciones clásico. Esto te permite revertir el tráfico si hay un problema con tu aplicación que usa el balanceador de cargas de aplicaciones externo global. Por ejemplo, si un cliente presenta una cookie de la flota del balanceador de cargas de aplicaciones clásico, pero el esquema de servicio de backend es EXTERNAL_MANAGED, no se respeta la cookie del cliente. El balanceador de cargas de aplicaciones externo global ignora la cookie y crea una nueva.

Cómo revertir recursos migrados

Después de migrar un recurso, si deseas revertirlo de la infraestructura del balanceador de cargas de aplicaciones externo global a la infraestructura del balanceador de cargas de aplicaciones clásico, puedes hacerlo en un plazo de 90 días después de cambiar su esquema de balanceo de cargas.

Para revertir un servicio de backend al esquema EXTERNAL, se requiere revertir la regla de reenvío. Revertir una regla de reenvío al esquema EXTERNAL no requiere revertir los servicios de backend.

Para revertir recursos, sigue estos pasos:

  1. Quita las funciones avanzadas de administración de tráfico nuevas del balanceador de cargas de aplicaciones externo global configuradas en el recurso.

  2. Revierte las reglas de reenvío.

    Cambia el esquema de balanceo de cargas de las reglas de reenvío de EXTERNAL_MANAGED a EXTERNAL.

  3. Revierte los buckets de backend.

    1. Establece el estado de migración de los buckets de backend en TEST_ALL_TRAFFIC y espera un tiempo (aproximadamente seis minutos).
    2. Opcional: Para disminuir el tráfico, establece el estado de migración de los buckets de backend en TEST_BY_PERCENTAGE y establece un porcentaje del tráfico.
    3. Establece el estado de migración de los buckets de backend en PREPARE.
    4. Revierte los buckets de backend a sus estados anteriores a la migración.

  4. Revierte los servicios de backend.

    1. Establece el estado de migración de los servicios de backend en TEST_ALL_TRAFFIC y espera un tiempo (aproximadamente seis minutos).
    2. Opcional: Para disminuir el tráfico, establece el estado de migración de los servicios de backend en TEST_BY_PERCENTAGE y establece un porcentaje del tráfico.
    3. Establece el estado de migración de los servicios de backend en PREPARE.
    4. Revierte los servicios de backend a sus estados anteriores a la migración.

Para obtener un proceso detallado paso a paso, consulta Cómo revertir los recursos migrados al balanceador de cargas de aplicaciones clásico.

Realiza un seguimiento del proceso de migración

Mientras migras tus recursos, puedes consultar los siguientes elementos para verificar sus esquemas de balanceo de cargas:

  • Los paneles de registro y supervisión del balanceador de cargas de aplicaciones externo global Para obtener más información, consulta Registro y supervisión del balanceador de cargas de aplicaciones externo global.

  • Los valores de los siguientes encabezados de solicitud y respuesta HTTP:

    • X-External-Managed-Migration-Scheme-Override: Este encabezado de solicitud enruta la solicitud según su valor. Si el valor del encabezado es EXTERNAL, dirige la solicitud a la infraestructura del balanceador de cargas de aplicaciones clásico. Si el valor es EXTERNAL_MANAGED, enruta la solicitud a través de la infraestructura del balanceador de cargas de aplicaciones externo global.

      Usa este encabezado para dirigir una solicitud a una flota de balanceador de cargas en particular.

    • X-External-Managed-Migration-Selected-Scheme: Este encabezado de solicitud y respuesta informa al backend y al cliente sobre el esquema de balanceo de cargas que se usa para enrutar la solicitud. El encabezado se muestra al cliente y se pasa al backend del cliente.

      Si la solicitud se enruta a través de la infraestructura del balanceador de cargas de aplicaciones clásico, su valor es EXTERNAL. Si la solicitud se enruta a través de la infraestructura del balanceador de cargas de aplicaciones externo global, su valor es EXTERNAL_MANAGED.

¿Qué sigue?