Présentation de la migration

Cette page présente les différences entre l'équilibreur de charge d'application externe mondial et l'équilibreur de charge d'application classique. Elle explique également en détail comment migrer vos ressources d'équilibreur de charge d'application classique existantes vers l'équilibreur de charge d'application externe mondial.

Pour profiter des fonctionnalités de gestion avancée du trafic de l'équilibreur de charge d'application externe global, nous vous recommandons de migrer vos ressources d'équilibreur de charge d'application classique vers l'infrastructure de l'équilibreur de charge d'application externe global.

Comparer les équilibreurs de charge d'application classiques et les équilibreurs de charge d'application externes globaux

Avant de migrer des ressources, comprenez les différences entre les équilibreurs de charge d'application classiques et les équilibreurs de charge d'application externes globaux.

Différences de fonctionnalités

Les fonctionnalités suivantes ne sont pas compatibles avec l'équilibreur de charge d'application externe mondial. Elles ne sont disponibles qu'avec l'équilibreur de charge d'application classique :

Différences au niveau du plan de données

Le tableau suivant met en évidence les différences dans le plan de données entre l'équilibreur de charge d'application classique et l'équilibreur de charge d'application externe mondial. Ces différences affectent la manière dont les équilibreurs de charge répondent à certains événements courants.

Événement Réponse de l'équilibreur de charge d'application classique Réponse de l'équilibreur de charge d'application externe mondial
Codes d'état/d'erreur
Tous les backends ne sont pas opérationnels Renvoie HTTP 502 Renvoie HTTP 503
La requête utilise un algorithme de chiffrement SSL interdit Renvoie HTTP 502 Renvoie HTTP 503
Réinitialisation précoce de la connexion en amont par le backend Renvoie HTTP 502 Renvoie HTTP 503
Échec de la mise à niveau de la connexion (par exemple, lors de la mise à niveau vers Websockets) Renvoie HTTP 400 Renvoie HTTP 403
L'en-tête est trop volumineux Renvoie HTTP 413 Renvoie HTTP 431
Quotas et limites
Configuration du mappage d'URL Les limites de configuration des mappages d'URL sont très différentes entre les deux équilibreurs de charge. Pour en savoir plus, consultez la documentation Quotas : mappages d'URL.
Gestion des en-têtes
La requête utilise une méthode HTTP personnalisée sans corps Ajoute l'en-tête Transfer Encoding: Chunked à la requête envoyée au backend Ajoute l'en-tête Content-Length: 0 à la requête envoyée au backend
Format de l'en-tête X-Forwarded-For ajouté aux requêtes envoyées au backend Utilise le délimiteur ", " entre les adresses IP Utilise le délimiteur "," entre les adresses IP (sans espace après la virgule)
Conservation de la casse dans l'en-tête La casse de l'en-tête est conservée à l'identique Toutes les clés d'en-tête sont converties en caractères minuscules
En-têtes répétés portant le même nom Autorisé Les en-têtes répétés peuvent être combinés en un seul en-tête, avec les valeurs ajoutées dans l'ordre et séparées par des virgules, comme autorisé par la norme RFC 7230.
(HTTP/1.1 uniquement) Nom d'en-tête non valide (par exemple, caractères non compatibles dans l'en-tête) Autorisé (pour HTTP/1.1) Renvoie HTTP 502 (pour HTTP/1.1)
(HTTP/1.1 uniquement) En-tête Content-Length répété (mais identique) dans la requête Autorisé (pour HTTP/1.1) Renvoie HTTP 502 (pour HTTP/1.1)
(HTTP/1.1 uniquement) Plusieurs hôtes dans l'en-tête Lorsque deux hôtes ou plus sont ajoutés et que le premier est valide, l'en-tête est accepté Lorsque deux hôtes ou plus sont ajoutés et que l'un d'entre eux n'est pas valide, l'équilibreur de charge renvoie le code HTTP 502
(HTTP/1.1 uniquement) En-tête Connection: Keep-Alive Ajoute l'en-tête Keep-Alive header dans les requêtes envoyées au backend par défaut N'ajoute pas cet en-tête par défaut
Gérer les requêtes
Conversion des barres obliques en barres obliques inverses dans la requête URL inchangée Conversion en barre oblique
Fusion des barres obliques en double dans la requête Barres obliques non fusionnées Fusion des barres obliques
"#" dans le chemin de la requête Autorisés Renvoie HTTP 400
(HTTP/1.1 uniquement) Caractères non valides dans le chemin de la requête (par exemple, "\\x7f\\x7f") Autorisé (pour HTTP/1.1) Renvoie HTTP 502 (pour HTTP/1.1)
Distribution du trafic (configuration de mappage d'URL)
La requête du client inclut un numéro de port Le numéro de port est ignoré, même si vous avez configuré des hôtes avec des ports dans le mappage d'URL. Seul le nom d'hôte est pris en compte. Par exemple, le mappage des requêtes ciblant example.com:5000 sur le service de backend va porter sur example.com. Le nom d'hôte et le numéro de port sont tous deux pris en compte. Par exemple, le mappage des requêtes ciblant example.com:5000 sur le service de backend va porter sur example.com:5000. En l'absence de correspondance, le service de backend par défaut est utilisé.

En raison de différences architecturales, lorsque vous migrez vers l'équilibreur de charge d'application externe global, vous pouvez constater une augmentation du nombre de connexions à vos backends, en particulier lorsque vous utilisez le protocole HTTP/1.1. Cela peut entraîner une augmentation de la consommation de mémoire sur les instances de backend. Surveillez l'utilisation de vos ressources de backend pendant et après la migration.

Pour en savoir plus sur les différences et les fonctionnalités compatibles, consultez Comparaison des fonctionnalités de l'équilibreur de charge et Présentation de l'équilibreur de charge d'application.

Migrer des équilibreurs de charge d'application externes classiques vers des équilibreurs de charge d'application externes globaux

Pour migrer vers l'équilibreur de charge d'application externe global, vous devez modifier le schéma d'équilibrage de charge de vos ressources d'équilibrage de charge, en particulier les services de backend et les règles de transfert, en passant de EXTERNAL à EXTERNAL_MANAGED. Pour ce faire, vous devez suivre une série d'étapes de migration qui vous permettent de tester des parties de votre trafic réseau avec le nouveau schéma d'équilibrage de charge avant de finaliser la migration. Lors de la migration des ressources, vous contrôlez le pourcentage de requêtes envoyées à l'infrastructure de l'équilibreur de charge d'application classique ou à celle de l'équilibreur de charge d'application externe global.

Le schéma suivant illustre les schémas d'équilibrage de charge de vos ressources d'équilibrage de charge avant et après la migration.

Processus de migration pour les ressources d'équilibreur de charge d'application classique.
Processus de migration des ressources de l'équilibreur de charge d'application classique (cliquez pour agrandir).

Dans le schéma précédent, notez les points suivants :

  • Avant la migration des ressources, toutes les requêtes utilisent l'infrastructure de l'équilibreur de charge d'application classique.
  • Pendant la migration des ressources, certaines requêtes sont envoyées à l'infrastructure de l'équilibreur de charge d'application externe global, et les autres sont envoyées à l'infrastructure de l'équilibreur de charge d'application classique.
  • Une fois les ressources migrées, toutes les requêtes utilisent l'infrastructure de l'équilibreur de charge d'application externe mondial.

Pour faciliter la transition, migrez les ressources d'équilibreur de charge d'application classiques suivantes dans l'ordre indiqué :

  1. Migrez tous les services de backend associés aux règles de transfert de l'équilibreur de charge.

  2. Migrez tous les buckets backend associés aux règles de transfert de l'équilibreur de charge. Vous devez le faire au niveau de la règle de transfert, car les buckets backend ne disposent pas de schémas d'équilibrage de charge.

  3. Migrez les règles de transfert de l'équilibreur de charge.

    Vous ne pouvez migrer une règle de transfert qu'une fois que tous les services de backend et les buckets de backend associés à la règle de transfert ont déjà été migrés.

États de la migration

Pour migrer des ressources, vous devez les définir sur différents états avant de modifier leur schéma d'équilibrage de charge sur EXTERNAL_MANAGED.

  1. PREPARE : définissez une ressource sur cet état pour la préparer à la migration.
  2. TEST_BY_PERCENTAGE : pour tester une ressource préparée, définissez-la sur cet état afin d'envoyer un pourcentage du trafic réseau. Cette étape est facultative.
  3. TEST_ALL_TRAFFIC : définissez une ressource sur cet état pour envoyer tout le trafic réseau à la ressource via l'infrastructure de l'équilibreur de charge d'application externe global au lieu de l'infrastructure de l'équilibreur de charge d'application classique.

Processus de migration

Pour éviter tout temps d'arrêt, vous devez migrer les ressources dans un ordre spécifique de l'infrastructure de l'équilibreur de charge d'application classique vers l'infrastructure de l'équilibreur de charge d'application externe mondial, puis modifier le schéma d'équilibrage de charge de EXTERNAL à EXTERNAL_MANAGED pour finaliser la migration.

  1. Migrez les services de backend de l'équilibreur de charge.

    Répétez les étapes suivantes pour chaque service de backend.

    1. Préparez le service de backend pour la migration.

      Avant de pouvoir envoyer du trafic via l'infrastructure de l'équilibreur de charge d'application externe global, définissez l'état du service de backend sur PREPARE. Cela prépare le service de backend à gérer le trafic réseau de l'infrastructure de l'équilibreur de charge d'application externe global. Un service de backend met un certain temps (environ six minutes) à être prêt à envoyer du trafic via l'infrastructure de l'équilibreur de charge d'application externe global.

    2. Facultatif : Testez le service de backend préparé.

      Une fois que le service de backend est à l'état PREPARE, définissez son état sur TEST_BY_PERCENTAGE et définissez un pourcentage du trafic réseau de l'équilibreur de charge d'application classique sur l'infrastructure de l'équilibreur de charge d'application externe global.

      Bien que cette étape soit facultative, nous vous recommandons de tester le trafic avant de migrer un service de backend. Commencez par une petite valeur de pourcentage et surveillez les journaux des ressources. Si le service de backend se comporte comme prévu, augmentez progressivement le pourcentage jusqu'à 100 %.

      Dans l'état TEST_BY_PERCENTAGE, vous ne pouvez pas utiliser les fonctionnalités supplémentaires de l'infrastructure de l'équilibreur de charge d'application externe global.

    3. Envoyez tout le trafic réseau de l'équilibreur de charge d'application classique vers le service de backend préparé.

      Une fois le test du service de backend réussi, définissez son état sur TEST_ALL_TRAFFIC et envoyez tout le trafic réseau de l'équilibreur de charge d'application classique vers le service de backend préparé. Un service de backend prend un certain temps (environ six minutes) pour être prêt à gérer le trafic réseau.

      Dans l'état TEST_ALL_TRAFFIC, vous ne pouvez pas utiliser les fonctionnalités supplémentaires de l'infrastructure de l'équilibreur de charge d'application externe global.

    4. Modifiez le schéma d'équilibrage de charge du service de backend migré sur EXTERNAL_MANAGED.

      Après avoir testé votre service de backend préparé sur l'infrastructure de l'équilibreur de charge d'application externe global, définissez son schéma d'équilibrage de charge sur EXTERNAL_MANAGED. La migration complète d'un service de backend prend un certain temps (environ six minutes). Une fois que le schéma d'équilibrage de charge du service de backend est défini sur EXTERNAL_MANAGED, vous pouvez utiliser les fonctionnalités avancées de l'infrastructure de l'équilibreur de charge d'application externe global.

  2. Migrez les buckets de backend de l'équilibreur de charge. Vous devez le faire au niveau de la règle de transfert, car les buckets backend ne disposent pas de schémas d'équilibrage de charge.

    Répétez les étapes suivantes pour chaque bucket.

    1. Préparez le bucket backend pour la migration.

      Avant de pouvoir envoyer du trafic via l'infrastructure de l'équilibreur de charge d'application externe global, définissez l'état du bucket backend sur PREPARE et patientez pendant un certain temps (environ six minutes).

    2. Facultatif : Testez le service de backend préparé.

      Une fois que l'état du bucket backend est PREPARE, définissez-le sur TEST_BY_PERCENTAGE et définissez un pourcentage du trafic réseau de l'équilibreur de charge d'application classique vers l'infrastructure de l'équilibreur de charge d'application externe global.

    3. Envoyez tout le trafic réseau de l'équilibreur de charge d'application classique vers le bucket de backend préparé.

      Définissez l'état du bucket backend sur TEST_ALL_TRAFFIC et envoyez-y tout le trafic réseau de l'équilibreur de charge d'application classique. Un bucket backend prend un certain temps (environ six minutes) pour être prêt à gérer le trafic réseau.

      Dans l'état TEST_ALL_TRAFFIC, vous ne pouvez pas utiliser les fonctionnalités supplémentaires de l'infrastructure de l'équilibreur de charge d'application externe global.

  3. Migrez les règles de transfert.

    Pour chaque règle de transfert, définissez le schéma d'équilibrage de charge sur EXTERNAL_MANAGED, puis patientez quelques minutes (environ six). Une fois que le schéma d'équilibrage de charge de la règle de transfert est défini sur EXTERNAL_MANAGED, vous pouvez utiliser les fonctionnalités avancées de l'infrastructure de l'équilibreur de charge d'application externe global.

Pour obtenir une procédure détaillée, consultez Migrer des ressources depuis un équilibreur de charge d'application classique.

Le schéma suivant montre les ressources de l'équilibreur de charge d'application classique dans les différents états de migration.

États de migration des ressources d'équilibreur de charge d'application classique.
États de migration des ressources de l'équilibreur de charge d'application classique (cliquez pour agrandir).

Après avoir migré une ressource, si vous souhaitez la rétablir dans l'équilibreur de charge d'application classique, modifiez son schéma d'équilibrage de charge dans les 90 jours suivant sa migration. Vous ne pouvez pas effectuer de rollback sur une ressource une fois le délai de 90 jours écoulé.

Utiliser l'affinité de session

Tenez compte des mises en garde suivantes lorsque vous migrez des services de backend d'équilibreur de charge d'application classique avec affinité de session :

  • Définir une valeur pour TEST_BY_PERCENTAGE redirige une partie du trafic ciblant l'équilibreur de charge d'application classique vers l'équilibreur de charge d'application externe global. Cela rompt l'affinité de session basée sur les adresses IP client. Si vous modifiez le pourcentage de migration (par exemple, en l'augmentant de 10 %), l'affinité de session est interrompue pour le même pourcentage d'adresses IP client (10 % dans cet exemple), jusqu'à ce que l'affinité soit rétablie lors de la prochaine requête.

  • Définir une valeur pour TEST_BY_PERCENTAGE redirige ce pourcentage de trafic sans cookie de session vers l'équilibreur de charge d'application externe global. Il redirige également tout le trafic avec un cookie de session vers le parc d'équilibreurs de charge qui a généré le cookie.

  • Si vous définissez la valeur de TEST_BY_PERCENTAGE sur 0 %, si vous ne la définissez pas ou si vous définissez le service de backend sur l'état PREPARE, tous les cookies existants qui sont dirigés vers l'équilibreur de charge d'application externe global sont invalidés.

  • Si vous modifiez le schéma d'équilibrage de charge du service de backend en EXTERNAL_MANAGED, tous les cookies générés par le parc d'équilibreurs de charge d'application classiques seront invalidés. Cela vous permet de rétablir le trafic en cas de problème avec votre application à l'aide de l'équilibreur de charge d'application externe global. Par exemple, si un client présente un cookie provenant du parc d'équilibreurs de charge d'application classiques, mais que le schéma du service de backend est EXTERNAL_MANAGED, le cookie du client n'est pas pris en compte. L'équilibreur de charge d'application externe global ignore le cookie et en crée un.

Effectuer un rollback des ressources migrées

Après avoir migré une ressource, si vous souhaitez la rétablir depuis l'infrastructure de l'équilibreur de charge d'application externe global vers l'infrastructure de l'équilibreur de charge d'application classique, vous pouvez le faire dans les 90 jours suivant la modification de son schéma d'équilibrage de charge.

Pour rétablir un service de backend sur le schéma EXTERNAL, vous devez rétablir la règle de transfert. Pour rétablir une règle de transfert sur le schéma EXTERNAL, il n'est pas nécessaire de rétablir les services de backend.

Pour rétablir des ressources, procédez comme suit :

  1. Supprimez toutes les nouvelles fonctionnalités de gestion avancée du trafic de l'équilibreur de charge d'application externe global configurées sur la ressource.

  2. Effectuez un rollback des règles de transfert.

    Modifiez le schéma d'équilibrage de charge des règles de transfert en remplaçant EXTERNAL_MANAGED par EXTERNAL.

  3. Effectuez un rollback des buckets de backend.

    1. Définissez l'état de migration des buckets de backend sur TEST_ALL_TRAFFIC et attendez un certain temps (environ six minutes).
    2. Facultatif : Pour réduire le trafic, définissez l'état de migration des buckets de backend sur TEST_BY_PERCENTAGE et définissez un pourcentage du trafic.
    3. Définissez l'état de migration des buckets backend sur PREPARE.
    4. Rétablissez l'état des buckets de backend avant la migration.

  4. Restaurez les services de backend.

    1. Définissez l'état de migration des services de backend sur TEST_ALL_TRAFFIC et attendez un certain temps (environ six minutes).
    2. Facultatif : Pour réduire le trafic, définissez l'état de migration des services de backend sur TEST_BY_PERCENTAGE et définissez un pourcentage du trafic.
    3. Définissez l'état de migration des services de backend sur PREPARE.
    4. Rétablissez l'état des services de backend avant la migration.

Pour obtenir une procédure détaillée, consultez Rétablir les ressources migrées vers l'équilibreur de charge d'application classique.

Suivre votre processus de migration

Lorsque vous migrez vos ressources, vous pouvez vérifier leurs schémas d'équilibrage de charge en consultant les éléments suivants :

  • Tableaux de bord de journalisation et de surveillance de l'équilibreur de charge d'application externe global. Pour en savoir plus, consultez Journalisation et surveillance de l'équilibreur de charge d'application externe global.

  • Les valeurs des en-têtes de requête et de réponse HTTP suivants :

    • X-External-Managed-Migration-Scheme-Override : cet en-tête de requête achemine la requête en fonction de sa valeur. Si la valeur de l'en-tête est EXTERNAL, la requête est redirigée vers l'infrastructure de l'équilibreur de charge d'application classique. Si la valeur est EXTERNAL_MANAGED, la requête est acheminée via l'infrastructure de l'équilibreur de charge d'application externe global.

      Utilisez cet en-tête pour diriger une requête vers un parc d'équilibreurs de charge spécifique.

    • X-External-Managed-Migration-Selected-Scheme : cet en-tête de requête et de réponse informe le backend et le client sur le schéma d'équilibrage de charge utilisé pour acheminer la requête. L'en-tête est renvoyé au client et transmis au backend du client.

      Si la requête est acheminée via l'infrastructure de l'équilibreur de charge d'application classique, sa valeur est EXTERNAL. Si la requête est acheminée via l'infrastructure de l'équilibreur de charge d'application externe global, sa valeur est EXTERNAL_MANAGED.

Étapes suivantes