Información general sobre la migración

En esta página se ofrece una descripción general de las diferencias entre el balanceador de carga de aplicación externo global y el balanceador de carga de aplicación clásico, así como una descripción detallada de cómo puedes migrar tus recursos del balanceador de carga de aplicación clásico al balanceador de carga de aplicación externo global.

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

Comparar balanceadores de carga de aplicación clásicos y balanceadores de carga de aplicación externos globales

Antes de migrar recursos, debes conocer las diferencias entre los balanceadores de carga de aplicación clásicos y los balanceadores de carga de aplicación externos globales.

Diferencias entre funciones

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

Diferencias en el plano de datos

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

Evento Respuesta del balanceador de carga de aplicación clásico Respuesta del balanceador de carga de aplicaciones externo global
Códigos de estado o de error
Todos los backends están en mal estado Devuelve el código HTTP 502 Devuelve HTTP 503
La solicitud usa un cifrado SSL prohibido Devuelve el código HTTP 502 Devuelve HTTP 503
Conexión upstream anticipada restablecida por el backend Devuelve el código HTTP 502 Devuelve HTTP 503
No se ha podido actualizar la conexión (por ejemplo, al actualizar a Websockets) Devuelve HTTP 400 Devuelve HTTP 403
El encabezado es demasiado grande Devuelve el código HTTP 413 Devuelve el error HTTP 431
Cuotas y límites
Configuración de mapas de URLs Hay diferencias significativas en los límites de configuración de los mapas de URLs entre los dos balanceadores de carga. Para obtener más información, consulta la documentación sobre cuotas de mapas de URLs.
Gestión de encabezados
La solicitud usa un método HTTP personalizado sin cuerpo Añade el encabezado Transfer Encoding: Chunked a la solicitud enviada al backend. Añade el encabezado Content-Length: 0 a la solicitud enviada al backend.
Formato del encabezado X-Forwarded-For añadido a las solicitudes enviadas al backend. Usa el delimitador ", " entre IPs Usa el delimitador "," entre las IPs (sin espacio después de la coma).
Conservación de las mayúsculas y minúsculas de los encabezados Se conservan las mayúsculas y minúsculas del 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 añadidos en orden y separados por comas, tal como se permite en RFC 7230.
(Solo HTTP/1.1) Nombre de encabezado no válido (por ejemplo, caracteres no admitidos en el encabezado) Permitido (en HTTP/1.1) Devuelve el código HTTP 502 (en HTTP/1.1)
(Solo HTTP/1.1) Encabezado Content-Length repetido (pero igual) en la solicitud Permitido (en HTTP/1.1) Devuelve el código HTTP 502 (en HTTP/1.1)
(Solo HTTP/1.1) Varios hosts en el encabezado Cuando se añaden dos o más hosts y el primero es válido, se acepta el encabezado. Si se añaden dos o más hosts y alguno de ellos no es válido, el balanceador de carga devuelve el error HTTP 502.
(Solo HTTP/1.1) Connection: Keep-Alive header Añade el Keep-Alive header en las solicitudes enviadas al backend de forma predeterminada. No añade este encabezado de forma predeterminada.
Gestión de solicitudes
Barras invertidas en la solicitud La URL no ha cambiado Se convierte en una barra inclinada
Combinar barras duplicadas en la solicitud Deja barras sin combinar Combina barras
`#` en la ruta de la solicitud Permitido Devuelve HTTP 400
(Solo HTTP/1.1) Caracteres no válidos en la ruta de la solicitud (por ejemplo, `\\x7f\\x7f`) Permitido (en HTTP/1.1) Devuelve el código HTTP 502 (en HTTP/1.1)
Distribución del tráfico (configuración del mapa de URLs)
La solicitud del cliente incluye un número de puerto El número de puerto se ignora aunque hayas configurado hosts con puertos en el mapa de URLs. Solo se tiene en cuenta el nombre de host. Por ejemplo, las solicitudes de example.com:5000 se emparejan con el servicio de backend de example.com. Se tienen en cuenta tanto el nombre de host como el número de puerto. Por ejemplo, las solicitudes de example.com:5000 se emparejan con el servicio de backend de example.com:5000. Si no hay ninguna coincidencia, se utiliza el servicio backend predeterminado.

Para obtener más información sobre las diferencias y las funciones admitidas, consulta la comparativa de funciones de los balanceadores de carga y la descripción general de Application Load Balancer.

Migrar del balanceador de carga de aplicación clásico al externo global

Para migrar al balanceador de carga de aplicación externo global, debes cambiar el esquema de balanceo de carga de tus recursos de balanceo de carga (en concreto, los servicios de backend y las reglas de reenvío) de EXTERNAL a EXTERNAL_MANAGED. Para ello, debes seguir una serie de pasos de migración en los que puedes probar partes del tráfico de tu red con el nuevo esquema de balanceo de carga antes de finalizar la migración. Durante la migración de recursos, puedes controlar el porcentaje de solicitudes que se envían a la infraestructura del balanceador de carga de aplicación clásico o a la del balanceador de carga de aplicación externo global.

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

Proceso de migración de recursos de balanceador de carga de aplicación clásico.
Proceso de migración de recursos de balanceador de carga de aplicación clásico (haz clic para ampliar).

En el diagrama anterior, ten en cuenta lo siguiente:

  • Antes de migrar los recursos, todas las solicitudes utilizan la infraestructura del balanceador de carga de aplicaciones clásico.
  • Mientras se migran los recursos, algunas solicitudes se envían a la infraestructura del balanceador de carga de aplicación externo global y el resto se envía a la infraestructura del balanceador de carga de aplicación clásico.
  • Una vez que se han migrado los recursos, todas las solicitudes utilizan la infraestructura del balanceador de carga de aplicación externo global.

Para que la transición se produzca sin problemas, migre los siguientes recursos del balanceador de carga de aplicación clásico en el orden especificado:

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

  2. Migra todos los segmentos de backend asociados a las reglas de reenvío del balanceador de carga. Esto se hace a nivel de la regla de reenvío porque los contenedores de backend no tienen esquemas de balanceo de carga.

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

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

Estados de migración

Para migrar recursos, debes cambiar su estado antes de cambiar su esquema de balanceo de carga a EXTERNAL_MANAGED.

  1. PREPARE: asigna este estado a un recurso para prepararlo para la migración.
  2. TEST_BY_PERCENTAGE: para probar un recurso preparado, asigna este estado al recurso para enviar un porcentaje del tráfico de red. Esta fase es opcional.
  3. TEST_ALL_TRAFFIC: asigna este estado a un recurso para enviar todo el tráfico de red al recurso a través de la infraestructura del balanceador de carga de aplicación externo global en lugar de la infraestructura del balanceador de carga de aplicación clásico.
antes de cambiar el esquema de balanceo de carga.

Proceso de migración

Para asegurarte de que no haya tiempo de inactividad, migra los recursos en un orden específico de la infraestructura del balanceador de carga de aplicación clásico a la del balanceador de carga de aplicación externo global y, a continuación, cambia el esquema de balanceo de carga de EXTERNAL a EXTERNAL_MANAGED para finalizar la migración.

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

    Repite los pasos siguientes con cada servicio 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 carga de aplicación externo global, define el estado del servicio de backend como PREPARE. De esta forma, el servicio de backend se prepara para gestionar el tráfico de red de la infraestructura del balanceador de carga de aplicación 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 carga de aplicación externo global.

    2. Opcional: Prueba el servicio de backend preparado.

      Cuando el servicio de backend esté en el estado PREPARE, cámbialo a TEST_BY_PERCENTAGE y asigna un porcentaje del tráfico de red del balanceador de carga de aplicación clásico a la infraestructura del balanceador de carga de aplicación externo global.

      Aunque esta fase es opcional, te recomendamos que pruebes el tráfico antes de migrar un servicio backend. Empieza con un valor de porcentaje pequeño y monitoriza los registros de los recursos. Si el servicio backend se comporta como se espera, aumenta gradualmente el porcentaje hasta el 100%.

      En el estado TEST_BY_PERCENTAGE, no puedes usar las funciones adicionales de la infraestructura del balanceador de carga de aplicación externo global.

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

      Una vez que se haya probado correctamente el servicio de backend, defina su estado como TEST_ALL_TRAFFIC y envíe todo el tráfico de red del balanceador de carga de aplicaciones clásico al servicio de backend preparado. Un servicio de backend tarda un tiempo (aproximadamente seis minutos) en estar listo para gestionar el tráfico de red.

      En el estado TEST_ALL_TRAFFIC, no puedes usar las funciones adicionales de la infraestructura del balanceador de carga de aplicación externo global.

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

      Después de probar el servicio de backend preparado en la infraestructura del balanceador de carga de aplicación externo global, cambia su esquema de balanceo de carga a EXTERNAL_MANAGED. Un servicio backend tarda un tiempo (aproximadamente seis minutos) en migrarse por completo. Una vez que el esquema de balanceo de carga del servicio de backend cambie a EXTERNAL_MANAGED, podrás usar las funciones avanzadas de la infraestructura del balanceador de carga de aplicación externo global.

  2. Migra los segmentos de backend del balanceador de carga. Esto se hace a nivel de regla de reenvío porque los contenedores de backend no tienen esquemas de balanceo de carga.

    Repite los pasos siguientes con cada uno de los contenedores.

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

      Antes de que se pueda enviar tráfico a través de la infraestructura del balanceador de carga de aplicación externo global, define el estado del segmento de backend como PREPARE y espera un tiempo (aproximadamente seis minutos).

    2. Opcional: Prueba el servicio de backend preparado.

      Una vez que el bucket de backend esté en el estado PREPARE, cámbialo a TEST_BY_PERCENTAGE y asigna un porcentaje del tráfico de red del balanceador de carga de aplicación clásico a la infraestructura del balanceador de carga de aplicación externo global.

    3. Envía todo el tráfico de red del balanceador de carga de aplicación clásico al backend preparado.

      Define el estado del bucket de backend como TEST_ALL_TRAFFIC y envía todo el tráfico de red del balanceador de carga de aplicaciones clásico a ese bucket. Un backend bucket tarda un tiempo (aproximadamente seis minutos) en estar listo para gestionar el tráfico de red.

      En el estado TEST_ALL_TRAFFIC, no puedes usar las funciones adicionales de la infraestructura del balanceador de carga de aplicación externo global.

  3. Migra las reglas de reenvío.

    En cada regla de reenvío, cambia el esquema de balanceo de carga de la regla de reenvío a EXTERNAL_MANAGED y espera un tiempo (aproximadamente seis minutos). Una vez que el esquema de balanceo de carga de la regla de reenvío cambie a EXTERNAL_MANAGED, podrás usar las funciones avanzadas de la infraestructura del balanceador de carga de aplicación externo global.

Para ver un proceso detallado paso a paso, consulta Migrar recursos del balanceador de carga de aplicación clásico.

En el siguiente diagrama se muestran los recursos del balanceador de carga de aplicaciones clásico en los distintos estados de la migración.

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

Después de migrar un recurso, si quieres volver al balanceador de carga de aplicaciones clásico, cambia su esquema de balanceo de carga en un plazo de 90 días desde la migración. No puedes restaurar un recurso una vez que hayan transcurrido los 90 días.

Usar la afinidad de sesión

Tenga en cuenta las siguientes advertencias al migrar servicios de backend de balanceadores de carga de aplicaciones clásicos con afinidad de sesión:

  • Si asignas un valor a TEST_BY_PERCENTAGE, se redirige parte del tráfico dirigido al balanceador de carga de aplicación clásico al balanceador de carga de aplicación externo global. Esto rompe la afinidad de la IP del cliente. Si se cambia el porcentaje de migración (por ejemplo, si se aumenta en un 10%), se rompe 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 siguiente solicitud.

  • Si asignas un valor a TEST_BY_PERCENTAGE, se redirige ese porcentaje del tráfico al balanceador de carga de aplicación externo global sin una cookie de sesión. También redirige todo el tráfico con una cookie de sesión a la flota de balanceadores de carga que generó la cookie.

  • Si asignas el valor 0 % a TEST_BY_PERCENTAGE, no le asignas ningún valor o estableces el servicio de backend en el estado PREPARE, se invalidarán todas las cookies que se dirijan al balanceador de carga de aplicaciones externo global.

  • Si cambias el esquema de balanceo de carga del servicio de backend a EXTERNAL_MANAGED, se invalidarán todas las cookies generadas por la flota de balanceadores de carga de aplicaciones clásicos. Esto te permite revertir el tráfico si hay algún problema con tu aplicación mediante el balanceador de carga de aplicación externo global. Por ejemplo, si un cliente presenta una cookie de la flota de Application Load Balancer clásico, pero el esquema del servicio backend es EXTERNAL_MANAGED, la cookie del cliente no se tendrá en cuenta. El balanceador de carga de aplicaciones externo global ignora la cookie y crea una nueva.

Deshacer la migración de recursos

Después de migrar un recurso, si quieres volver a la infraestructura del balanceador de carga de aplicación clásico desde la infraestructura del balanceador de carga de aplicación externo global, puedes hacerlo en un plazo de 90 días a partir del cambio de su esquema de balanceo de carga.

Para revertir un servicio de backend al esquema EXTERNAL, debes revertir la regla de reenvío. Para restaurar una regla de reenvío al esquema EXTERNAL, no es necesario restaurar los servicios de backend.

Para restaurar recursos, sigue estos pasos:

  1. Elimina las nuevas funciones de gestión de tráfico avanzada del balanceador de carga de aplicación externo global configuradas en el recurso.

  2. Restaurar las reglas de reenvío.

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

  3. Restaurar los segmentos de backend.

    1. Define el estado de migración de los backend buckets como TEST_ALL_TRAFFIC y espera un tiempo (aproximadamente seis minutos).
    2. Opcional: Para reducir el tráfico, defina el estado de migración de los contenedores backend en TEST_BY_PERCENTAGE y establezca un porcentaje del tráfico.
    3. Define el estado de migración de los segmentos de backend como PREPARE.
    4. Vuelve a los estados de los backend buckets anteriores a la migración.

  4. Deshaz los cambios en los servicios de backend.

    1. Define el estado de migración de los servicios backend como TEST_ALL_TRAFFIC y espera un tiempo (aproximadamente seis minutos).
    2. Opcional: Para reducir el tráfico, defina el estado de migración de los servicios backend como TEST_BY_PERCENTAGE y establezca un porcentaje del tráfico.
    3. Define el estado de migración de los servicios backend como PREPARE.
    4. Restaurar los servicios backend a su estado anterior a la migración.

Para obtener un proceso detallado paso a paso, consulta Restaurar recursos migrados a balanceadores de carga de aplicación clásicos.

Hacer un seguimiento del proceso de migración

Mientras migras tus recursos, puedes consultar sus esquemas de balanceo de carga de las siguientes formas:

  • Los paneles de control de registro y monitorización del balanceador de carga de aplicación externo global. Para obtener más información, consulta Registro y monitorización del balanceador de carga de aplicación 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 en función de su valor. Si el valor del encabezado es EXTERNAL, dirige la solicitud a la infraestructura del balanceador de carga de aplicaciones clásico. Si el valor es EXTERNAL_MANAGED, la solicitud se enruta a través de la infraestructura del balanceador de carga de aplicación externo global.

      Usa este encabezado para dirigir una solicitud a una flota de balanceadores de carga concreta.

    • X-External-Managed-Migration-Selected-Scheme: este encabezado de solicitud y respuesta informa al backend y al cliente sobre el esquema de equilibrio de carga utilizado para enrutar la solicitud. El encabezado se devuelve al cliente y se envía al backend del cliente.

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

Siguientes pasos