Unité 4.3 : Élasticité et VM Auto Scaling

Introduction

L'élasticité sur IONOS a deux axes distincts qui sont décidés à des moments différents. La mise à l'échelle verticale augmente une seule instance VM en cours d'exécution et constitue en grande partie une opération en direct ; la mise à l'échelle horizontale ajoute et supprime des répliques entières sous une politique de métrique et constitue le mécanisme d'élasticité géré de la plateforme. La décision qui relie les deux est prise avant que l'une ou l'autre ne soit exécutée : 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 configurés à l'avance, de sorte que le choix du chemin géré horizontalement engage la conception de réplique du niveau depuis 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 condition préalable sans état qui rend la mise à l'échelle horizontale sûre, puis crée un groupe de mise à l'échelle automatique et effectue une redimensionnement en direct sur le niveau FinCorp.

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

La mise à l'échelle verticale en temps réel (LVS) modifie les ressources d'un VM après la mise en service. Sur les serveurs Dedicated Core et vCPU, vous pouvez ajouter des ressources (CPU, RAM, cartes réseau et volumes de stockage) pendant l'exécution du serveur, ce qui vous permet de réagir rapidement à un pic sans fenêtre de maintenance. Les limites sont spécifiques et importantes pour la conception :

• La mise à l'échelle vers le haut est en temps réel ; la mise à l'échelle vers le bas est asymétrique. Vous pouvez mettre à l'échelle vers le haut en temps réel les CPU, RAM, cartes réseau et volumes de stockage. Vous pouvez mettre à l'échelle vers le bas en temps réel uniquement les cartes réseau et les volumes de stockage. La réduction des CPU ou 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 mise à l'échelle en temps réel des RAM est de 240 Go. La mise à l'échelle en temps réel des RAM est automatiquement désactivée lorsque la taille des RAM dépasse 240 Go. Au-delà de cette limite, l'augmentation des RAM oblige le VM à redémarrer à chaque fois, ce qui signifie que la LVS n'est plus applicable à cette dimension.
• Le Windows est plus contraint. Le Windows permet de mettre à l'échelle les CPU en temps réel, mais pas les RAM, et la mise à l'échelle au-delà de huit CPU nécessite un redémarrage. Planifiez les niveaux de Windows en conséquence.

La mise à l'échelle verticale est la bonne option lorsque une seule charge de travail doit simplement être plus grande et ne peut pas être divisée, mais elle a un plafond dur (un VM ne peut pas dépasser l'hôte) et la mise à l'échelle vers le bas asymétrique la rend moins adaptée au trafic qui fluctue. Pour cela, vous mettez à l'échelle horizontalement.

2. Élasticité Horizontale : VM Auto Scaling

VM Auto Scaling est le service géré qui lance et termine des répliques complètes de VM pour correspondre à la charge. Il prend actuellement en charge la mise à l'échelle horizontale uniquement : il crée plus de machines virtuelles en fonction d'une configuration de réplique d'un groupe plutôt que de redimensionner les existantes. Deux faits déterminants façonnent chaque conception qui l'utilise.

La configuration de la réplique est décidée à l'avance. Un groupe VM Auto Scaling crée de nouvelles répliques de VM à partir d'un modèle de réplique, donc la forme de calcul de la réplique (architecture CPU, cœurs, RAM) et le stockage sont des décisions de conception prises à l'avance, lors de 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é d'accès anticipé, et les Flow Logs ne sont pas encore pris en charge sur les répliques d'auto-mise à l'échelle, ce qui constitue un petit mais réel écart d'observabilité à noter.

La configuration de la réplique s'applique uniquement aux nouvelles répliques. Le groupe a un modèle de réplique (la définition de 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 ne réalise pas de mise à l'échelle verticale : il n'ajoute pas de cœurs, de RAM ou de stockage aux machines virtuelles en cours d'exécution. Les noms de réplique auto-générés sont des noms, et non des identifiants de serveur, et ne peuvent pas être utilisés pour récupérer des informations sur le API, vous devez donc concevoir vos outils opérationnels autour du groupe, et non autour des identités de réplique individuelles.

2.1 Une Politique de Métrique, et les Contrôles Anti-Flapping

Un groupe a 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 l'utilisation moyenne de l'architecture CPU (pourcentage), et les octets et les paquets de réseau entrants et sortants. Dans cette politique, vous définissez une action de mise à l'échelle et une action de réduction, chacune avec un type de quantité (Absolu ou Pourcentage) et une quantité.

Les contrôles qui empêchent le groupe d'osciller (en faisant des allers-retours entre la mise à l'échelle et la réduction) ne sont pas des commodités optionnelles ; ils constituent la conception d'un groupe stable :

• L'écart de seuil obligatoire. Les seuils de réduction et de mise à l'échelle doivent être séparés d'au moins 40 points de pourcentage. Cette bande morte empêche une seule lecture de métrique bruyante de déclencher une mise à l'échelle et une réduction immédiate.
• La période de refroidissement. Après une action de mise à l'échelle, le groupe attend une période de refroidissement avant d'agir à nouveau. La valeur par défaut est de 5 minutes ; la valeur minimale est de 120 secondes (2 minutes) et la valeur maximale est de 24 heures. Une période de refroidissement plus courte que le temps dont a besoin une nouvelle réplique pour se mettre en ligne et commencer à absorber la charge est la cause classique d'une sur-mise à l'échelle.
• La taille de lot par action. Mettez à l'échelle par lots : la taille de lot maximale recommandée est de 5 machines virtuelles par action de mise à l'échelle, avec un plafond de groupe recommandé d'environ 100 répliques et un plancher d'une réplique. Le plancher d'une réplique signifie qu'il n'y a pas de mise à l'échelle à zéro ; le groupe conserve toujours au moins une réplique active.

La configuration d'un groupe crée deux alarmes de surveillance automatiquement (une pour la réduction et une pour la mise à l'échelle) selon la politique. De manière facultative, la configuration de la réplique peut référencer une unité de sauvegarde afin que les sauvegardes de réplique VM soient stockées régulièrement, et elle peut associer un groupe cible Managed Application Load Balancer (plage de poids cible de 1 à 256) afin que les nouvelles répliques soient ajoutées automatiquement derrière le balancier de charge lorsqu'elles apparaissent. Cette association ALB est ce qui rend un niveau de mise à l'échelle utilisable : sans elle, les nouvelles répliques ne recevraient aucun trafic.

2.2 La Condition Préalable de l'État Sans É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 machines virtuelles entières selon son propre calendrier. Cela rend l'état sans état une condition préalable, et non un élément souhaitable. Tout état de session ou en cours de processus doit être externalisé à partir 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é vit dans le cache, les répliques restent sans état, et le groupe d'auto-mise à l'échelle peut les renouveler librement. Il s'agit de la même couche In-Memory qui a été nommée dans l'Unité 1.3 comme substitution de mise à l'échelle de lecture, qui remplit maintenant une double fonction en tant que couche d'externalisation d'état qui rend la mise à l'échelle automatique propre. Un niveau d'état (une base de données, par exemple) n'est jamais le niveau de mise à l'échelle automatique ; il est atteint via un équilibrage de charge privé de couche 4 et mis à l'échelle par les modèles de niveau de données du Module 5.

Considérations de conception

• Évolutivité. Déterminez l'axe de mise à l'échelle par niveau : vertical pour une charge de travail qui doit être plus grande et ne peut pas être divisée (dans la limite de 240 Go de hotplug et la descente CPU/RAM qui supporte le redémarrage), horizontal pour un trafic qui fluctue. Seul le chemin horizontal est géré, et il crée de nouvelles répliques à partir d'un modèle de réplique de 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 démarrage de la réplique est la défaillance de production la plus courante, provoquant une mise à l'échelle incontrôlée.
• Opérations. Les modifications de configuration des répliques ne s'appliquent qu'aux nouvelles répliques, et les noms de répliques ne sont pas des ID de serveur, donc opérez sur l'abstraction de groupe. Le plancher d'au moins un signifie que vous devez budgétiser pour au moins une réplique toujours active par niveau de mise à l'échelle.

DCD Déploiement étape par étape

Ce déploiement étape par étape crée un groupe VM Auto Scaling pour le niveau d'application orienté client de FinCorp (le niveau Dedicated Core de l'Unité 4.1) et effectue ensuite une mise à l'échelle verticale en direct pour montrer les deux axes d'élasticité côte à côte. Les prérequis sont le modèle de réplica Dedicated Core (une définition de serveur à partir de laquelle le groupe crée des réplicas) et, pour la distribution du trafic, le Load Balancer d'application de couche 7 public de l'Unité 3.3.

Objectif de construction : Configurer un groupe à mise à l'échelle automatique avec une stratégie de métrique et une mise à l'échelle en direct.

Étapes (dans le Data Center Designer) :

1. Dans le VDC FinCorp, commencez Créer un groupe VM Auto Scaling. La fenêtre de création affiche une onglet de configuration d'auto-mise à l'échelle et une onglet de configuration de réplica. Assurez-vous que le centre de données qui héberge le groupe dispose des ressources nécessaires.
2. Dans Configuration d'auto-mise à l'échelle, définissez les comptes de réplica minimum et maximum du groupe (plancher de un ; plafond recommandé d'environ 100).
3. Définissez la stratégie de métrique unique. Sélectionnez la métrique (pour l'application FinCorp, utilisation moyenne de CPU). Définissez les seuils de mise à l'échelle et de réduction, en les gardant à au moins 40 points de pourcentage les uns des autres.
4. Définissez l'action de mise à l'échelle : type de quantité (absolu ou pourcentage) et quantité (le nombre de réplicas à ajouter), en gardant le lot à ou en dessous du recommandé de 5 par action.
5. Définissez l'action de réduction de la même manière (quantité minimale de un).
6. Définissez le délai de refroidissement (par défaut 5 minutes ; minimum 2 minutes, maximum 24 heures) à au moins le temps de démarrage du réplica, afin que les nouveaux réplicas puissent absorber la charge avant la prochaine action.
7. Dans Configuration de réplica, définissez le modèle de réplica Dedicated Core (cœurs, RAM, stockage à partir des types pris en charge, et l'image de démarrage). Associez le groupe cible ALB de l'Unité 3.3 afin que les nouveaux réplicas reçoivent du trafic (poids cible de 1 à 256 ; l'ALB transmet à un port cible configurable dans la plage TCP 1 à 65535, et non à un port fixe 80). Faites référence facultativement à une unité de sauvegarde. Cliquez sur Créer.
8. Pour montrer l'élasticité verticale, sélectionnez le Dedicated Core Server sous-jacent (ou un VM géré manuellement) dans l'espace de travail et, dans l'Inspecteur, augmentez CPU et RAM. Mettez en œuvre le changement : la mise à l'échelle de CPU et RAM est en direct (en dessous du plafond de 240 Go RAM hotplug), alors qu'une mise à l'échelle descendante ultérieure de CPU/RAM nécessiterait un redémarrage.

Erreurs courantes :

• Définir les seuils de réduction et de mise à l'échelle à moins de 40 points de pourcentage les uns des autres. L'écart obligatoire est rejeté s'il est violé et existe précisément pour empêcher les oscillations.
• Un délai de refroidissement plus court que le temps de démarrage du réplica, ce qui cause le groupe à continuer à mettre à l'échelle avant que les réplicas précédents ne prennent en charge la charge.
• Oublier d'associer le groupe cible ALB, de sorte que les nouveaux réplicas apparaissent mais ne reçoivent pas de trafic.
• S'attendre à ce qu'un changement de modèle de réplica redimensionne la flotte en cours d'exécution. Il s'applique uniquement aux nouveaux réplicas ; la flotte existante reste inchangée.
• Mettre à l'échelle un niveau d'état. Externalisez la session/état vers le cache In-Memory en premier ; seuls les niveaux sans état mettent à l'échelle en toute sécurité.

Modèle d'architecture

Le niveau web élastique standard est composé de trois fils de ce cours. Le pare-feu de couche 7 public (Unité 3.3) fait face à un groupe d'auto-mise à l'échelle de Dedicated Core dont les répliques sont sans état, avec une session et un état partagé conservés dans un In-Memory DB cache sur le réseau privé (Module 5). Sous charge, l'utilisation de CPU franchit le seuil de mise à l'échelle, le groupe ajoute des répliques par lots de cinq au maximum, le groupe cible ALB les prend en charge automatiquement, et le refroidissement empêche la sur-correction ; à mesure que la charge diminue et franchit le seuil de mise à l'échelle (d'au moins 40 points inférieurs), les répliques sont supprimées jusqu'au plancher d'une réplique. Pour l'application orientée client de FinCorp, c'est le niveau qui absorbe les fluctuations de trafic quotidiennes : la ligne de base est de petite taille sur Dedicated Core (Unité 4.1), les pics sont gérés en ajoutant des répliques plutôt qu'en utilisant un VM permanently large, et comme les répliques ne conservent aucun état, le groupe peut les remplacer sans affecter les utilisateurs connectés.

Résumé

L'élasticité IONOS a deux axes décidés à des moments différents. La mise à l'échelle verticale augmente une seule instance de VM en cours d'exécution, avec une mise à l'échelle live pour CPU/RAM/NIC/stockage et une mise à l'échelle descendante pour NIC/stockage, la mise à l'échelle descendante de CPU/RAM nécessitant un redémarrage et le hotplug de RAM étant désactivé au-dessus de 240 Go. La mise à l'échelle horizontale via VM Auto Scaling est le chemin géré, une fonctionnalité d'accès anticipé qui crée de nouvelles répliques à partir d'un modèle de réplique de conception, avec une politique de métrique par groupe, un écart de seuil obligatoire de 40 points, un refroidissement allant de deux minutes à 24 heures, des conseils de traitement par lots autour de cinq VM par action, et un plancher d'une réplique (pas de mise à l'échelle à zéro). La configuration de la réplique n'est applicable qu'aux nouvelles répliques, et le niveau mis à l'échelle doit être sans état, avec l'état externalisé vers le cache In-Memory. La construction relie un groupe piloté par les métriques derrière l'ALB et affiche une redimensionnement live à côté.

Points clés :

• Vertical : mise à l'échelle live de CPU/RAM/NIC/stockage ; mise à l'échelle descendante uniquement NIC/stockage live ; CPU/RAM mise à l'échelle descendante nécessite un redémarrage ; RAM hotplug désactivé au-dessus de 240 Go.
• La mise à l'échelle automatique horizontale crée de nouvelles répliques à partir d'un modèle de réplique de conception (forme de calcul et stockage), validé dans l'unité 4.1.
• Une politique de métrique par groupe ; les seuils de mise à l'échelle et de réduction doivent différer d'au moins 40 points de pourcentage ; refroidissement par défaut de 5 minutes (2 minutes à 24 heures) ; lot recommandé jusqu'à 5 VM ; plancher d'une réplique, pas de mise à l'échelle à zéro.
• La configuration de la réplique n'est applicable qu'aux nouvelles répliques ; le service ne redimensionne pas la flotte en cours d'exécution, et les noms de réplique ne sont pas des ID de serveur.
• Le niveau de mise à l'échelle automatique doit être sans état, avec la session/état externalisée vers le cache In-Memory ; associez un groupe cible ALB afin que les nouvelles répliques reçoivent le trafic.

Terminologie importante :

• Mise à l'échelle verticale live (LVS) : modification des ressources d'une instance de VM en cours d'exécution, live pour la mise à l'échelle et pour la mise à l'échelle descendante de NIC/stockage ; CPU/RAM mise à l'échelle descendante et RAM au-dessus 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 de mise à l'échelle et une action de réduction) qui déclenche la mise à l'échelle.
• Refroidissement : l'attente après une action de mise à l'échelle avant la suivante, le contrôle principal anti-sur-mise à l'échelle.
• Écart de seuil : l'écart de seuil obligatoire de 40 points de pourcentage minimum entre les seuils de réduction et de mise à l'échelle qui empêche les oscillations.

Lecture supplémentaire

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