Unité 4.3 : Élasticité et VM Auto Scaling

Introduction

L'élasticité sur IONOS CLOUD comporte deux axes distincts, déterminés à des moments différents. La mise à l'échelle verticale agrandit une seule VM en cours d'exécution et constitue principalement une opération en direct ; la mise à l'échelle horizontale ajoute et supprime des répliques entières selon une politique basée sur des métriques, et constitue le mécanisme d'élasticité géré par la plateforme. La décision qui lie ces deux axes est prise avant que l'un ou l'autre ne soit exécuté : VM Auto Scaling crée de nouvelles répliques à partir d'un modèle de réplique dont la configuration de calcul (architecture CPU, cœurs, RAM) et le stockage sont définis à l'avance, de sorte que le choix de la voie horizontale gérée engage la conception des répliques de la couche, comme vu dans l'Unité 4.1. Cette unité couvre les deux axes, les contrôles anti-flapping qui maintiennent un groupe de mise à l'échelle stable, et la précondition sans état qui rend la mise à l'échelle horizontale sûre, puis crée un groupe de mise à l'échelle automatique et effectue un redimensionnement en direct sur la couche FinCorp.

1. Élasticité verticale : mise à l'échelle verticale en direct et ses limites

La mise à l'échelle verticale en direct (LVS) modifie les ressources d'une VM après le provisionnement. Sur les serveurs Dedicated Core et vCPU, vous pouvez effectuer un hotplug vers le haut (ajout de CPU, de RAM, de NIC et de volumes de stockage) pendant que le serveur est en cours d'exécution. C'est ainsi que vous réagissez rapidement à un pic de charge sans fenêtre de maintenance. Les limites sont spécifiques et importantes pour la conception :

• La mise à l'échelle vers le haut est en direct ; la mise à l'échelle vers le bas est asymétrique. Vous pouvez effectuer la mise à l'échelle vers le haut en direct pour le CPU, la RAM, les NIC et les volumes de stockage. Vous ne pouvez effectuer la mise à l'échelle vers le bas en direct que pour les NIC et les volumes de stockage. Réduire le CPU ou la RAM nécessite un redémarrage, donc une mise à l'échelle vers le bas de la capacité de calcul est une opération planifiée, et non transparente.
• La limite de hotplug de la RAM est de 240 Go. Le hotplug de la RAM est automatiquement désactivé lorsque la taille de la RAM dépasse 240 Go. Au-delà de cette limite, toute augmentation de la RAM force la VM à redémarrer à chaque fois, ce qui signifie que la LVS ne s'applique plus à cette dimension.
• Windows est plus contraint. Windows permet la mise à l'échelle des cœurs de CPU en direct, mais pas de la RAM, et une mise à l'échelle au-delà de huit cœurs de CPU nécessite un redémarrage. Planifiez les niveaux Windows en conséquence.

La mise à l'échelle verticale est le bon levier lorsqu'une seule charge de travail doit simplement être plus grande et ne peut pas être fractionnée, mais elle a une limite stricte (une VM ne peut pas dépasser l'hôte) et la mise à l'échelle vers le bas asymétrique en fait un mauvais choix pour un trafic qui fluctue. Pour cela, vous effectuez une mise à l'échelle horizontale.

2. Élasticité horizontale : VM Auto Scaling

VM Auto Scaling est le service managé qui lance et met fin à des répliques de VM entières afin de s'adapter à la charge. Il prend actuellement en charge uniquement la mise à l'échelle horizontale : il crée des VM supplémentaires en fonction de la configuration des répliques d'un groupe, plutôt que de redimensionner les instances existantes. Deux faits fondamentaux façonnent toute conception qui l'utilise.

La configuration des répliques est définie à l'avance. Un groupe VM Auto Scaling crée de nouvelles répliques de VM à partir d'un modèle de réplique. Par conséquent, la forme de calcul de la réplique (architecture CPU, cœurs, RAM) et le stockage sont des décisions prises au moment de la conception, et ce dès l'Unité 4.1. Les types de stockage de réplique pris en charge sont HDD, SSD Premium et SSD Standard. VM Auto Scaling est une fonctionnalité en accès anticipé, et les journaux de flux ne sont pas encore pris en charge sur les répliques en mise à l'échelle automatique, ce qui constitue un petit mais réel déficit d'observabilité à prendre en compte.

La configuration des répliques ne s'applique qu'aux nouvelles répliques. Le groupe dispose d'un modèle de réplique (la définition de la VM à partir de laquelle les nouvelles répliques sont créées). La modification du modèle, ou la modification manuelle des ressources d'une réplique, n'affecte que les répliques créées après la modification ; elle ne redimensionne pas la flotte existante. C'est le sens précis dans lequel le service n'effectue pas de mise à l'échelle verticale : il n'ajoute pas de cœurs, de RAM ou de stockage aux VM en cours d'exécution. Les noms de réplique générés automatiquement sont des noms, et non des identifiants de serveur, et ne peuvent pas être utilisés pour récupérer des informations via l'API. Il convient donc de concevoir les outils opérationnels autour du groupe, et non autour des identités individuelles des répliques.

2.1 Une seule politique de métrique, et les contrôles anti-flapping

Un groupe dispose d'exactement une politique de métrique : vous définissez une seule métrique dont l'utilisation déclenche la mise à l'échelle. Les métriques prises en charge sont la moyenne d'utilisation du CPU des instances (en pourcentage), ainsi que les octets et paquets réseau entrants et sortants. Au sein de cette politique unique, vous définissez une action de mise à l'échelle vers l'extérieur (scale-out) et une action de mise à l'échelle vers l'intérieur (scale-in), chacune avec un type de quantité (Absolu ou Pourcentage) et une valeur.

Les contrôles qui empêchent le groupe d'osciller (flapping entre scale-out et scale-in) ne sont pas de simples options ; ils constituent la conception d'un groupe stable :

• L'écart de seuil obligatoire. Les seuils de scale-in et de scale-out doivent être séparés d'au moins 40 points de pourcentage. Cette bande morte empêche une lecture de métrique bruitée de déclencher un scale-out suivi immédiatement d'un scale-in.
• Le délai d'attente (cooldown). Après une action de mise à l'échelle, le groupe attend une période de cooldown avant d'agir à nouveau. La valeur par défaut est de 5 minutes ; le minimum est de 120 secondes (2 minutes) et le maximum est de 24 heures. Un délai d'attente plus court que le temps nécessaire à une nouvelle réplique pour se réchauffer et commencer à absorber la charge est la cause classique d'une sur-mise à l'échelle.
• La taille de lot par action. Effectuez la mise à l'échelle par lots : le maximum recommandé est de 5 VM par action de mise à l'échelle, avec un plafond recommandé d'environ 100 répliques par groupe et un plancher d'une réplique. Le plancher d'une réplique signifie qu'il n'y a pas de scale-to-zero ; le groupe conserve toujours au moins une réplique active.

La configuration d'un groupe crée automatiquement deux alarmes de surveillance (une pour le scale-in, une pour le scale-out) conformément à la politique. Facultativement, la configuration de la réplique peut référencer une Unité de sauvegarde afin que les sauvegardes des VM de réplique soient stockées régulièrement, et elle peut associer un groupe de cibles Managed Application Load Balancer (plage de poids des cibles de 1 à 256) afin que les nouvelles répliques soient automatiquement ajoutées derrière l'équilibreur de charge à mesure qu'elles apparaissent. Cette association ALB est ce qui rend une couche de mise à l'échelle utilisable : sans elle, les nouvelles répliques ne recevraient aucun trafic.

2.2 La précondition d'absence d'état

La mise à l'échelle horizontale n'est sûre que si une réplique peut être créée ou détruite sans perte d'état utilisateur, car le groupe ajoute et supprime des VM entières selon son propre calendrier. Cela fait de l'absence d'état une précondition, et non une simple option. Tout état de session ou d'état en processus doit être externalisé hors de la réplique, ce qui est exactement le rôle de la couche de cache In-Memory DB (Module 5) : l'état de session et partagé réside dans le cache, les répliques restent sans état, et le groupe de mise à l'échelle automatique peut les faire tourner librement. Il s'agit de la même couche In-Memory que l'Unité 1.3 a désignée comme substitution pour la mise à l'échelle en lecture, qui remplit désormais un double rôle en tant que couche d'externalisation de l'état qui rend la mise à l'échelle automatique propre. Une couche avec état (une base de données, par exemple) n'est jamais la couche de mise à l'échelle automatique ; elle est atteinte via un équilibreur de charge privé de couche 4 et mise à l'échelle selon les modèles de couche de données du Module 5.

Considérations de conception

• Évolutivité. Déterminez l'axe de mise à l'échelle pour chaque niveau : vertical pour une charge de travail qui doit être plus importante et ne peut pas être fractionnée (dans la limite de 240 Go pour le hotplug et la réduction de la capacité CPU/RAM entraînant un redémarrage), horizontal pour un trafic qui varie. Seul le chemin horizontal est géré, et il crée de nouveaux répliques à partir d'un modèle de réplique défini à la conception.
• Fiabilité. L'écart de seuil, le temps de refroidissement et la taille du lot sont les contrôles de stabilité. Un temps de refroidissement trop court par rapport au temps de mise en température des répliques est la cause la plus courante de défaillance en production, entraînant une mise à l'échelle horizontale incontrôlée.
• Exploitation. Les modifications de configuration des répliques ne s'appliquent qu'aux nouvelles répliques, et les noms des répliques ne sont pas des identifiants de serveur, il faut donc opérer sur l'abstraction de groupe. La limite minimale d'une réplique signifie qu'il faut prévoir au moins une réplique toujours active par niveau de mise à l'échelle.

Déroulement de la mise en œuvre de DCD

Ce déroulement consiste à créer un groupe VM Auto Scaling pour la couche applicative destinée aux clients de FinCorp (la couche Dedicated Core de l'Unité 4.1), puis à effectuer un redimensionnement vertical en direct afin de présenter les deux axes d'élasticité côte à côte. Les prérequis sont le modèle de réplique Dedicated Core (une définition de serveur à partir de laquelle le groupe crée des répliques) et, pour la distribution du trafic, le Load Balancer applicatif public de couche 7 de l'Unité 3.3.

Objectif de construction : Configurer un groupe de mise à l'échelle automatique avec une politique basée sur une métrique et un redimensionnement en direct.

Étapes (dans Data Center Designer) :

1. Dans le VDC de FinCorp, lancez Create VM Auto Scaling Group. La fenêtre de création affiche un onglet Autoscaling Setup et un onglet Replica Configuration. Assurez-vous que le centre de données hébergeant le groupe dispose des ressources nécessaires.
2. Dans Autoscaling Setup, définissez le nombre minimum et maximum de répliques du groupe (minimum de 1 ; maximum recommandé d'environ 100).
3. Définissez la politique de métrique unique. Sélectionnez la métrique (pour l'application FinCorp, la moyenne d'utilisation du CPU). Définissez le Scale Out Threshold et le Scale In Threshold, en les maintenant à au moins 40 points de pourcentage d'écart.
4. Définissez l'action Scale Out : le type de quantité (Absolu ou Pourcentage) et la quantité (le nombre de répliques à ajouter), en maintenant le lot à un niveau inférieur ou égal au nombre recommandé de 5 par action.
5. Définissez l'action Scale In de la même manière (quantité minimale de 1).
6. Réglez le cooldown (5 minutes par défaut ; minimum 2 minutes, maximum 24 heures) à au moins la durée de mise en service des répliques, afin que les nouvelles répliques puissent absorber la charge avant l'action suivante.
7. Dans Replica Configuration, définissez le modèle de réplique Dedicated Core (cœurs, RAM, stockage parmi les types pris en charge, et l'image de démarrage). Associez le groupe de cibles ALB de l'Unité 3.3 afin que les nouvelles répliques reçoivent du trafic (poids de cible de 1 à 256 ; l'ALB transfère vers un port de cible configurable n'importe où dans la plage TCP de 1 à 65535, et non vers un port 80 fixe). Facultativement, référencez une Unité de sauvegarde. Cliquez sur Create.
8. Pour illustrer l'élasticité verticale, sélectionnez le serveur Dedicated Core sous-jacent (ou une VM gérée manuellement) dans l'espace de travail et, dans l'Inspecteur, augmentez le CPU et la RAM. Appliquez la modification : l'augmentation du CPU et de la RAM est effectuée en direct (en dessous de la limite de 240 Go de RAM pour le hotplug), alors qu'une diminution ultérieure du CPU ou de la RAM nécessiterait un redémarrage.

Erreurs courantes :

• Définir les seuils de réduction et d'expansion à moins de 40 points de pourcentage d'écart. L'écart obligatoire est rejeté s'il est violé et existe précisément pour éviter les oscillations.
• Un cooldown plus court que la durée de mise en service des répliques, ce qui provoque une expansion continue du groupe avant que les répliques précédentes ne prennent en charge la charge.
• Oublier d'associer le groupe de cibles ALB, si bien que les nouvelles répliques apparaissent mais ne reçoivent aucun trafic.
• S'attendre à ce qu'une modification du modèle de réplique redimensionne la flotte en cours d'exécution. Elle ne s'applique qu'aux nouvelles répliques ; la flotte existante reste inchangée.
• Mettre à l'échelle une couche avec état. Externalisez d'abord la session ou l'état vers le cache In-Memory ; seules les couches sans état peuvent être mises à l'échelle automatiquement en toute sécurité.

Modèle d'architecture

Le niveau web élastique standard combine trois des axes de ce cours. L'équilibreur de charge public de couche 7 (Unité 3.3) fait face à un groupe de mise à l'échelle automatique Dedicated Core dont les répliques sont sans état, l'état de session et l'état partagé étant conservés dans un cache In-Memory DB sur le réseau privé (Module 5). Sous charge, l'utilisation du CPU dépasse le seuil de mise à l'échelle horizontale, le groupe ajoute des répliques par lots de cinq au maximum, le groupe de cibles ALB les prend en charge automatiquement, et le délai de refroidissement empêche toute surcorrection ; lorsque la charge diminue et passe sous le seuil de mise à l'échelle verticale (au moins 40 points de moins), les répliques sont supprimées jusqu'au plancher d'une réplique. Pour l'application destinée aux clients de FinCorp, c'est ce niveau qui absorbe les variations de trafic quotidiennes : la taille de base est réduite sur Dedicated Core (Unité 4.1), les pics sont gérés en ajoutant des répliques plutôt qu'en utilisant une VM de grande taille en permanence, et comme les répliques ne conservent aucun état, le groupe peut les remplacer sans affecter les utilisateurs connectés.

Résumé

L'élasticité d'IONOS CLOUD repose sur deux axes déterminés à des moments différents. La mise à l'échelle verticale augmente les ressources d'une seule VM en cours d'exécution, avec une augmentation en direct du CPU, de la RAM, des NIC et du stockage, ainsi qu'une diminution en direct des NIC et du stockage. La diminution du CPU et de la RAM nécessite un redémarrage, et le hotplug de la RAM est désactivé au-delà de 240 Go. La mise à l'échelle horizontale via VM Auto Scaling est la voie gérée, une fonctionnalité en accès anticipé qui crée de nouvelles répliques à partir d'un modèle de réplique défini à la conception. Elle comporte une politique de métrique par groupe, un écart de seuil obligatoire de 40 points, un temps d'attente allant de deux minutes à 24 heures, une recommandation de lot d'environ cinq VM par action, et un minimum d'une réplique (pas de mise à l'échelle à zéro). La configuration des répliques ne s'applique qu'aux nouvelles répliques, et la couche mise à l'échelle doit être sans état, avec l'état externalisé vers le cache In-Memory. Le déploiement configure un groupe piloté par métrique derrière l'ALB et montre un redimensionnement en direct à ses côtés.

Points clés :

• Vertical : augmentation en direct du CPU, de la RAM, des NIC et du stockage ; diminution en direct uniquement des NIC et du stockage ; la diminution du CPU et de la RAM nécessite un redémarrage ; le hotplug de la RAM est désactivé au-delà de 240 Go.
• La mise à l'échelle horizontale automatique crée de nouvelles répliques à partir d'un modèle de réplique défini à la conception (forme de calcul et stockage), validé dans l'Unité 4.1.
• Une politique de métrique par groupe ; les seuils de réduction et d'augmentation doivent différer d'au moins 40 points de pourcentage ; temps d'attente par défaut de 5 minutes (de 2 minutes à 24 heures) ; lot recommandé d'au plus 5 VM ; minimum d'une réplique, pas de mise à l'échelle à zéro.
• La configuration des répliques ne s'applique qu'aux nouvelles répliques ; le service ne redimensionne pas la flotte en cours d'exécution, et les noms des répliques ne sont pas des identifiants de serveur.
• La couche de mise à l'échelle automatique doit être sans état, avec les sessions et l'état externalisés vers le cache In-Memory ; associez un groupe de cibles ALB afin que les nouvelles répliques reçoivent du trafic.

Terminologie importante :

• Mise à l'échelle verticale en direct (LVS) : modification des ressources d'une VM en cours d'exécution, en direct pour l'augmentation et pour la diminution des NIC et du stockage ; la diminution du CPU et de la RAM, ainsi que la RAM au-delà de 240 Go, nécessitent un redémarrage.
• Politique de métrique : la règle unique par groupe de mise à l'échelle automatique (une métrique, une action d'augmentation et une action de réduction) qui déclenche la mise à l'échelle.
• Temps d'attente : l'attente après une action de mise à l'échelle avant la suivante, le principal contrôle contre la sur-mise à l'échelle.
• Écart de seuil : la séparation minimale obligatoire de 40 points de pourcentage entre les seuils de réduction et d'augmentation, qui empêche les oscillations.

Lectures complémentaires

• Unité 4.1 : Sélection de la classe de calcul (pourquoi le niveau est Dedicated Core).
• Unité 3.3 : Équilibrage de charge - Niveau 7 (l'ALB auquel le groupe est rattaché).
• Unité 5.5 : Base de données en mémoire (le niveau d'externalisation de l'état qui rend la mise à l'échelle automatique sûre).