Présentation de la migration

Preview

Ce produit ou cette fonctionnalité est soumis aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent bénéficier d'une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Cette page présente les différences entre l'équilibreur de charge d'application externe mondial et l'équilibreur de charge d'application classique, ainsi qu'une présentation détaillée de la façon dont vous pouvez migrer vos ressources d'équilibreur de charge d'application classique 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 d'é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, vous devez comprendre 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:

• Niveau de réseau Standard

• Contrôleur d'entrée GKE

  Pour déployer des équilibreurs de charge d'application externes mondiaux pour les clusters GKE, utilisez plutôt le contrôleur GKE Gateway. Pour obtenir des instructions de configuration, consultez Déployer des passerelles.

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 du mappage 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 ne va porter que 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 ne va porter que sur example.com:5000. En l'absence de correspondance, le service de backend par défaut est utilisé.

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

Migrer d'un équilibreur de charge d'application externe classique vers un équilibreur de charge d'application externe global

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) de EXTERNAL à EXTERNAL_MANAGED. Pour ce faire, vous effectuez une série d'étapes de migration au cours desquelles vous pouvez 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 à l'infrastructure de l'équilibreur de charge d'application externe global.

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

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 classique de l'équilibreur de charge d'application.
• 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 global.

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

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 comportent 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'après avoir migré tous les services de backend et les buckets de backend associés à la règle de transfert.

États de migration

Vous migrez les ressources en les définissant sur différents états avant de définir 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 pour 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 vers 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.

Remarque :Une fois que vous avez modifié l'état d'une ressource de PREPARE à TEST_BY_PERCENTAGE ou TEST_ALL_TRAFFIC, attendez un certain temps (environ six minutes) pour que la ressource soit prête à accepter le trafic. La ressource doit être à l'état TEST_ALL_TRAFFIC avant de modifier le schéma d'équilibrage de charge.

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 remplacer le schéma d'équilibrage de charge EXTERNAL par 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 qu'un trafic puisse être envoyé 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 d'équilibreur de charge d'application externe global. Un service de backend prend un certain temps (environ six minutes) pour ê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 dans 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 valeur de pourcentage faible 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 au service 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 au 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. Définissez 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 d'é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 backend de l'équilibreur de charge. Vous devez le faire au niveau de la règle de transfert, car les buckets backend ne comportent 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 qu'un trafic puisse être envoyé via l'infrastructure de l'équilibreur de charge d'application externe global, définissez l'état du bucket backend sur PREPARE, puis patientez un certain temps (environ six minutes).

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

      Une fois que le bucket backend est dans 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.

   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 y envoyez tout le trafic réseau de l'équilibreur de charge d'application classique. Un bucket backend met un certain temps (environ six minutes) à ê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 un certain temps (environ six minutes). 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 connaître la procédure détaillée, consultez la page 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 de l'équilibreur de charge d'application classique (cliquez pour agrandir).

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

Utiliser l'affinité de session

Tenez compte des mises en garde suivantes lorsque vous migrez des services de backend Application Load Balancer classiques 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é d'adresse IP client. Modifier le pourcentage de migration (par exemple, l'augmenter de 10%) interrompt l'affinité de session 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%, ou si vous ne la définissez pas, ou si vous définissez le service de backend sur l'état PREPARE, tous les cookies existants dirigés vers l'équilibreur de charge d'application externe global sont invalidés.

• Si vous définissez le schéma d'équilibrage de charge du service de backend sur EXTERNAL_MANAGED, tous les cookies générés par la flotte d'équilibreurs de charge d'application classiques sont invalidés. Vous pouvez ainsi annuler le trafic en cas de problème avec votre application qui utilise l'équilibreur de charge d'application externe global. Par exemple, si un client présente un cookie de la flotte d'équilibreurs de charge d'application classiques, mais que le schéma de service de backend est EXTERNAL_MANAGED, le cookie du client n'est pas accepté. L'équilibreur de charge d'application externe global ignore le cookie et en crée un.

Annuler la migration de ressources

Après avoir migré une ressource, si vous souhaitez la faire revenir de l'infrastructure d'équilibreur de charge d'application externe global vers l'infrastructure d'é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 au schéma EXTERNAL, vous devez rétablir la règle de transfert. La restauration d'une règle de transfert vers le schéma EXTERNAL ne nécessite pas de restaurer les services de backend.

Pour effectuer un rollback de ressources, procédez comme suit:

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

2. Annulez les règles de transfert.

   Modifiez le schéma d'équilibrage de charge des règles de transfert de EXTERNAL_MANAGED à EXTERNAL.

3. Effectuez un rollback des buckets de backend.

   1. Définissez l'état de migration des buckets de backend sur TEST_ALL_TRAFFIC, puis attendez un certain temps (environ six minutes).
   2. Facultatif: Pour réduire le trafic, définissez l'état de migration des buckets 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établir les buckets backend à leur état d'avant la migration.

4. Annulez les services de backend.

   1. Définissez l'état de migration des services de backend sur TEST_ALL_TRAFFIC, puis 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établir les services de backend à leur état d'avant la migration.

Pour obtenir un processus détaillé par étapes, consultez Rétrograder des ressources migrées vers l'équilibreur de charge d'application classique.

Suivre votre processus de migration

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

• Les tableaux de bord de journalisation et de surveillance de l'équilibreur de charge d'application externe global. Pour en savoir plus, consultez la section 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 dirigé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 particulier.

  • X-External-Managed-Migration-Selected-Scheme: cet en-tête de requête et de réponse informe le backend et le client du 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 mondial, sa valeur est EXTERNAL_MANAGED.

Étape suivante

• Migrer des ressources depuis l'équilibreur de charge d'application classique
• Rétrograder les ressources migrées vers l'équilibreur de charge d'application classique