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, así como una descripción 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 de los mapas 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 del 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.

Debido a las diferencias de arquitectura, cuando migres al balanceador de cargas de aplicaciones externo global, es posible que observes un aumento en la cantidad de conexiones a tus backends, en especial cuando uses el protocolo HTTP/1.1. Esto puede generar un mayor consumo de memoria en las instancias de backend. Supervisa el uso de recursos de backend durante la migración y después de ella.

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.

Migra del balanceador de cargas de aplicaciones externo clásico al 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 qué porcentaje de solicitudes 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 los recursos del balanceador de cargas de aplicaciones clásico.
Proceso de migración para los recursos del balanceador de cargas de aplicaciones clásico (haz clic para ampliar).

En el diagrama anterior, ten en cuenta lo siguiente:

  • Antes de que se migren 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 solicitudes restantes se envían a la infraestructura del balanceador de cargas de aplicaciones clásico.
  • Después de migrar los recursos, todas las solicitudes usarán 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 adjuntos a las reglas de reenvío del balanceador de cargas.

  2. Migra todos los buckets de backend adjuntos 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 de backend y los buckets de backend conectados a la regla de reenvío.

Estados de migración

Para migrar recursos, debes establecerlos 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, migra los recursos en un orden específico desde la infraestructura del balanceador de cargas de aplicaciones clásico a la infraestructura del balanceador de cargas de aplicaciones externo global y, luego, cambia 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, establece el estado del servicio de backend en 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 según lo esperado, aumenta gradualmente el porcentaje hasta el 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 complete 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 (aproximadamente 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 (aproximadamente seis minutos) en migrarse 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. Esto se hace a nivel de la regla de reenvío porque 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, establece el estado del bucket de backend en 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íale todo el tráfico de red del balanceador de cargas de aplicaciones clásico. Un bucket de backend tarda un tiempo (aproximadamente 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 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 Migra 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 a partir de la migración. No puedes revertir un recurso después de que transcurran los 90 días.

Usa la afinidad de sesión

Ten en cuenta las siguientes advertencias cuando migres servicios de backend de balanceadores de cargas de aplicaciones clásicos con afinidad de sesión:

  • Establecer un valor para TEST_BY_PERCENTAGE redirecciona parte del tráfico que se dirige al balanceador de cargas de aplicaciones clásico hacia el balanceador de cargas de aplicaciones externo global. Esto interrumpe la afinidad de IP del cliente. Si cambias el porcentaje de migración (por ejemplo, si lo aumentas en un 10%), se interrumpirá la afinidad de sesión para el mismo porcentaje de direcciones IP de cliente (un 10% en este ejemplo) hasta que se restablezca la afinidad en la próxima solicitud.

  • Si se establece un valor para TEST_BY_PERCENTAGE, se redirecciona 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 de balanceador de cargas que generó la cookie.

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

  • Si cambias el esquema de balanceo de cargas del servicio de backend a EXTERNAL_MANAGED, se invalidarán todas las cookies generadas por 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 del servicio de backend es EXTERNAL_MANAGED, no se respetará la cookie del cliente. El balanceador de cargas de aplicaciones externo global ignora la cookie y crea una nueva.

Cómo revertir los 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, también se debe revertir la regla de reenvío. Para revertir una regla de reenvío al esquema EXTERNAL, no es necesario revertir los servicios de backend.

Para revertir los recursos, sigue estos pasos:

  1. Quita las funciones nuevas de administración avanzada del tráfico 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 configura 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 previos 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 previos 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 verificar sus esquemas de balanceo de cargas de la siguiente manera:

  • Los paneles de supervisión y registro 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 dirige 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, la solicitud se enruta 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 usó para enrutar la solicitud. El encabezado se devuelve 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?