Déploiement rapide par clonage d'instances - Server Load Balancer

Pour déployer rapidement un environnement, assurer la reprise après sinistre ou migrer une configuration, utilisez la fonctionnalité de clonage d'instances Application Load Balancer (ALB). Elle permet de créer rapidement une instance identique ou similaire à une instance source, ce qui améliore l'efficacité du déploiement et réduit la complexité opérationnelle.

Clonage d'instance ALB

La fonctionnalité de clonage d'instance réplique la configuration d'une instance ALB existante, y compris les composants clés tels que les écouteurs, les groupes de serveurs, les règles de transfert et les vérifications d'état. Cette approche évite une reconfiguration manuelle fastidieuse et garantit que la nouvelle instance dispose d'une configuration identique ou similaire à celle de l'instance source. Cette fonctionnalité s'avère particulièrement utile pour la reprise après sinistre et la migration de configurations.

Fonctionnalités clés

Réplication rapide : clonez une instance ALB existante en un seul clic grâce à un processus automatisé alimenté par Resource Orchestration Service (ROS). Ce processus rapide améliore l'efficacité du déploiement et réduit la complexité opérationnelle.
Cohérence de la configuration : garantit que la nouvelle instance possède une configuration identique ou similaire à celle de l'instance source, ce qui prévient les erreurs de configuration.
Déploiement flexible : déployez une instance clonée dans une région ou une zone différente pour répondre à des exigences complexes telles que l'expansion commerciale multirégionale et le basculement de reprise après sinistre.

Cas d'utilisation

Migration d'environnement : clonez la configuration d'un environnement de test vers un environnement de préproduction ou de production afin d'assurer la cohérence entre les environnements et d'accélérer le déploiement des nouvelles fonctionnalités.
Reprise après sinistre : en cas de panne de service, utilisez le clonage d'instance pour déployer rapidement des ressources d'équilibrage de charge de secours, améliorant ainsi la continuité des activités et la haute disponibilité.
Migration de configuration : migrez la configuration d'une instance existante vers une nouvelle instance, par exemple lors d'une mise à niveau de version ou d'un ajustement architectural, afin d'éviter les configurations manuelles répétitives.

Limites

L'instance ALB de destination et l'instance ALB source doivent être de la même édition.
Les instances Ingress ALB ne peuvent pas être clonées.
Les instances ALB avec la protection contre les modifications activée ne peuvent pas être clonées.
Si l'instance ALB source est associée à une instance de bande passante Internet partagée, l'instance ALB clonée n'est pas automatiquement ajoutée à cette instance de bande passante Internet partagée. Vous pouvez ajouter manuellement l'instance depuis sa page de détails.
Si vous clonez une instance ALB non mise à niveau, une instance ALB mise à niveau est créée par défaut. Pour plus d'informations, consultez la rubrique Différences entre les instances ALB non mises à niveau et mises à niveau.

Exemple

Une entreprise déploie une nouvelle fonctionnalité dans un environnement de test et utilise une instance ALB pour l'équilibrage de charge. L'instance ALB est configurée avec une règle de transfert pour rediriger les requêtes HTTP vers HTTPS et utilise un nom de domaine personnalisé pour fournir des services de test. Lorsqu'un client de test accède au nom de domaine www.example.com, le DNS résout le nom de domaine vers l'instance ALB sur la base d'un enregistrement CNAME. L'instance ALB transfère ensuite le trafic vers ECS01 et ECS02 pour traitement, conformément à la règle de transfert.

Une fois la fonctionnalité validée lors des tests d'acceptation, vous devez migrer la configuration de l'instance ALB vers l'environnement de production. La configuration manuelle d'une instance ALB prend du temps et peut entraîner des incohérences de configuration susceptibles d'affecter les opérations commerciales, en particulier dans un environnement de production à fort trafic.

Pour résoudre ce problème, l'entreprise décide d'utiliser la fonctionnalité de clonage d'instance pour répliquer rapidement la configuration ALB de l'environnement de test vers l'environnement de production. Grâce à cette fonctionnalité, l'entreprise déploie rapidement l'instance ALB dans l'environnement de production, garantissant ainsi un lancement rapide et un fonctionnement stable de la nouvelle fonctionnalité.

Prérequis

Une instance ALB source doit être configurée avec des écouteurs, des serveurs backend et un enregistrement CNAME. Elle doit également être accessible pour les tests via le nom de domaine personnalisé www.example.com. Pour plus d'informations, consultez la rubrique Utilisation d'ALB pour équilibrer la charge des services IPv4.
- L'instance ALB source dispose d'un écouteur HTTP et d'un écouteur HTTPS. L'écouteur HTTP est configuré avec une règle de transfert de redirection pour rediriger les requêtes HTTP vers HTTPS.
- Déployez des services sur les serveurs backend ECS01 et ECS02 de l'instance ALB source.
  
  Cette rubrique utilise Alibaba Cloud Linux 3 comme système d'exploitation et Nginx pour configurer un service HTTP sur le port 80.
  Exemple : Déploiement d'un service de test sur ECS01
  yum install -y nginx systemctl start nginx.service cd /usr/share/nginx/html/ echo "Hello World ! This is ECS01." > index.html
Préparez les serveurs backend pour l'instance ALB de destination clonée si nécessaire :
- Si l'instance ALB de destination se trouve dans le même Virtual Private Cloud (VPC) que l'instance ALB source, les serveurs backend ECS01 et ECS02 de l'instance source peuvent également servir de serveurs backend pour l'instance de destination.
- Si l'instance ALB de destination ne se trouve pas dans le même Virtual Private Cloud (VPC) que l'instance ALB source, préparez les serveurs backend ECS03 et ECS04 dans le VPC de destination et déployez-y des services.
Préparez des serveurs pour simuler des clients : ECS-A est utilisé pour tester le trafic avant la migration, et ECS-B sert à vérifier le trafic d'accès pendant la migration. Les deux serveurs doivent disposer d'un accès au réseau public. Cette rubrique utilise Alibaba Cloud Linux 3 comme système d'exploitation.

Si vous disposez déjà de serveurs de test, il n'est pas nécessaire de créer ECS-A et ECS-B.

Procédure

Étape 1 : Cloner l'instance ALB source

Dans la barre de navigation supérieure de la console ALB, sélectionnez la région de l'instance ALB source.
Sur la page Instances, repérez l'instance à cloner. Dans la colonne Actions, choisissez > Clone Instance.
Dans la boîte de dialogue Clone Instance, configurez les paramètres de l'instance ALB de destination et cliquez sur Next.

Par défaut, les paramètres de l'instance ALB de destination sont identiques à ceux de l'instance ALB source. Dans cet exemple, modifiez la valeur de Region for the Clone en passant de Germany (Frankfurt) à US (Silicon Valley), changez le VPC du VPC1 par défaut vers le VPC2 de destination, et sélectionnez la zone et le vSwitch de destination correspondants. Vous pouvez conserver les valeurs par défaut pour les autres paramètres ou les modifier selon vos besoins.

Si l'instance clonée est de type réseau public et que la région de destination est une région où ALB prend en charge les Anycast EIP , vous devez également sélectionner un IP Type ( EIP ou Anycast EIP ) et allouer une adresse IP publique du type correspondant dans la zone sélectionnée.
À l'étape Preview and Confirm, confirmez les informations et les frais relatifs à l'instance ALB de destination, puis cliquez sur Clone.
Confirmez le résultat du clonage.

Une fois le clonage terminé, vous pouvez comparer les données métier de l'instance ALB de destination clonée avec celles de l'instance ALB source.

Le clonage d'instance est fourni par Resource Orchestration Service (ROS). Pendant le processus de clonage, vous pouvez vous connecter à la console ROS pour consulter la progression.
Ajoutez les serveurs backend ECS03 et ECS04 au groupe de serveurs de l'instance ALB de destination.

Étape 2 : Tester le trafic

Pour garantir que l'instance ALB de destination peut se connecter aux services backend, si vos services backend disposent de politiques d'accès telles qu'iptables ou d'autres logiciels de sécurité tiers, ajoutez le bloc CIDR du vSwitch de l'instance ALB à la liste d'autorisation.

Connectez-vous à distance au serveur de test ECS-A.
Exécutez la commande suivante pour modifier le fichier hosts.
```
sudo vi /etc/hosts
```
Dans le fichier hosts, ajoutez l'Elastic IP Address (EIP) et le nom de domaine de l'instance ALB de destination. Après avoir modifié le fichier, enregistrez les changements et quittez.
```
47.251.XX.XX www.example.com
```
Exécutez la commande suivante pour tester le transfert de trafic pour l'instance ALB de destination.
```
curl -v -L www.example.com
```
La sortie suivante est renvoyée, indiquant que les requêtes HTTP sont redirigées avec succès vers HTTPS et que le serveur répondant est ECS03.

Exécutez à nouveau la commande. Le serveur répondant devient ECS04.

Étape 3 : Migrer le trafic vers l'instance de destination

Avertissement

Avant de migrer le trafic, comparez les configurations des règles de transfert de vos instances ALB source et de destination pour vous assurer qu'elles offrent des capacités identiques. Vérifiez que toutes les configurations ont passé les tests d'acceptation afin d'éviter tout impact imprévu sur votre activité lors de la migration.
Effectuez la migration du trafic ALB pendant les heures creuses.

Un enregistrement CNAME est configuré pour l'instance ALB source. Après avoir vérifié la configuration de l'instance ALB de destination, vous pouvez migrer le trafic de l'instance ALB source vers l'instance ALB de destination selon vos besoins.

Cette rubrique utilise la fonctionnalité de politique de routage pondéré d'Alibaba Cloud DNS à titre d'exemple. En ajustant dynamiquement le ratio de pondération entre les instances ALB source et de destination, le trafic DNS est progressivement migré de l'instance source vers la nouvelle instance.

Partie 1 : Ajouter un enregistrement CNAME

Dans le volet de navigation de gauche, choisissez ALB > Instances. Sur la page Instances, copiez le nom DNS de l'instance ALB créée.
Suivez ces étapes pour ajouter un enregistrement CNAME.
1. Sur la console Alibaba Cloud DNS, repérez le nom de domaine de destination et cliquez sur Settings dans la colonne Actions.
  
  Pour les domaines non enregistrés auprès d'Alibaba Cloud, vous devez d'abord ajouter le domaine à la console Alibaba Cloud DNS avant de pouvoir configurer les paramètres DNS.
2. Sur la page Settings, cliquez sur Add Record, configurez l'enregistrement CNAME, puis cliquez sur OK.
  
  Dans cet exemple, le Record Type est défini sur CNAME, et la Record Value est définie sur le nom DNS de l'instance ALB de destination. Vous pouvez conserver les valeurs par défaut pour les autres paramètres d'enregistrement DNS ou les modifier selon vos besoins.
3. Dans la boîte de dialogue Change Resource Record Confirmation, confirmez les informations DNS et cliquez sur OK.

Partie 2 : Définir les pondérations et démarrer le déploiement canari

Sur la page Settings, repérez l'enregistrement CNAME ajouté dans la Partie 1. Cliquez sur la flèche déroulante à côté de Modify, puis cliquez sur Edit Record Set.
Dans le panneau Edit Record, sous Record Values, définissez les pondérations pour les enregistrements DNS des instances ALB source et de destination. Définissez la pondération de l'enregistrement DNS pour l'instance ALB source à 100 et celle de l'instance ALB de destination à 0.

Vous ne pouvez activer la politique de routage pondéré que si plusieurs enregistrements A, CNAME ou AAAA existent pour le même nom d'hôte et la même ligne DNS sous le nom de domaine.
Si vous n'observez aucun impact sur votre activité, diminuez progressivement la pondération de l'enregistrement DNS pour l'instance ALB source et augmentez celle de l'instance ALB de destination.
Connectez-vous à distance au serveur de test ECS-B et exécutez la commande dig plusieurs fois pour vérifier l'effet de la migration du trafic.
```
dig www.example.com
```
La figure suivante montre la sortie. En exécutant la commande plusieurs fois, vous pouvez observer que les requêtes sont distribuées soit vers l'instance ALB source, soit vers l'instance ALB de destination, en fonction de leurs pondérations.

(Facultatif) Partie 3 : Finaliser la migration du trafic

Sur la base des résultats de vérification de la migration du trafic, réduisez progressivement la pondération de l'enregistrement DNS pour l'instance ALB source à 0 et augmentez celle de l'instance ALB de destination à 100. Cela permet de finaliser la migration du trafic de l'instance ALB source vers l'instance ALB de destination.

Une fois que toutes les connexions persistantes vers l'instance ALB source sont fermées et qu'aucun nouveau trafic ne lui est acheminé, vous pouvez surveiller l'instance pendant une période donnée, puis la libérer en fonction de votre scénario métier.

Documents connexes

Après avoir cloné une instance ALB, vous pouvez utiliser les journaux d'accès ALB pour surveiller la charge sur l'instance de destination et résoudre les problèmes connexes.
Si vous devez migrer un écouteur CLB de couche 7 vers ALB :
- Migration en un clic d'un écouteur CLB de couche 7 vers ALB
- Migration manuelle d'un écouteur CLB de couche 7 vers ALB
Vous pouvez sélectionner une politique de gestion du trafic DNS en fonction de vos besoins :
- politique de routage pondéré : distribue le trafic DNS selon un algorithme tournant pondéré basé sur les pondérations configurées, en renvoyant les valeurs d'enregistrement correspondantes lors des requêtes.
- Résolution DNS intelligente : renvoie les résultats DNS en fonction de la localisation géographique de l'utilisateur et de son FAI afin de réduire la latence de résolution et d'améliorer la vitesse d'accès au site web. Les lignes prises en charge incluent le FAI, le FAI/province, l'extérieur de la Chine continentale, le continent et les lignes personnalisées.
- Global Traffic Manager (GTM) : met en œuvre l'accès de proximité, l'équilibrage de charge pour le trafic à forte concurrence et le basculement de trafic basé sur les résultats des vérifications d'état. Cela vous permet de construire de manière flexible des services actifs-actifs et de reprise après sinistre dans différentes régions.