Vérification des connaissances - Calcul et élasticité
Évaluez votre compréhension des concepts clés du Module 4. Sélectionnez la meilleure réponse pour chaque question, puis soumettez pour voir vos résultats. Vous devez obtenir au moins 60 % pour réussir.
Un architecte s'attend à ce que VM Auto Scaling gère une charge de travail en croissance sur une seule VM en ajoutant de la CPU et de la RAM aux répliques en cours d'exécution à mesure que la charge augmente. Pourquoi ce modèle mental est-il incorrect quant au fonctionnement du service ?
VM Auto Scaling est horizontal : il démarre et termine des répliques entières pour se conformer à une politique de métrique unique, et les modifications de configuration des répliques n'affectent que les nouvelles répliques, jamais le parc de répliques en cours d'exécution. L'augmentation de la CPU et de la RAM d'une seule VM relève de la Live Vertical Scaling, un mécanisme distinct doté de ses propres limites (la limite de 240 Go de RAM pour l'ajout à chaud, et la réduction de la CPU/RAM qui nécessite un redémarrage). Les options incorrectes inventent des comportements de redimensionnement partiel que le service ne possède pas.
Un architecte choisit une classe de calcul pour une charge de travail qui s'inscrit parfaitement dans un bundle fixe de vCPU, de RAM et de NVMe, mais dont les données métier persistantes doivent survivre aux reconstructions d'instances. Un collègue affirme qu'un Cube n'est pas adapté car « les Cubes ne peuvent pas utiliser Block Storage ». Comment l'architecte doit-il répondre ?
Un Cube est livré avec un modèle NVMe obligatoire et immuable, mais il peut également attacher des périphériques Block Storage HDD/SSD en option. Les données persistantes doivent donc être placées sur ces volumes plutôt que sur le disque NVMe, qui est supprimé avec l'instance. La contrainte réelle est que le modèle (vCPU, RAM, NVMe) est fixe après le provisionnement, et non que le Cube ne peut pas utiliser Block Storage. La conception correcte utilise donc des volumes en option pour les données qui doivent survivre.
FinCorp doit placer un disque de démarrage et de données pour une base de données mono-VM sur Block Storage et souhaite que le volume délivre ses performances SSD nominales. Quelle décision de conception détermine le plus directement si le SSD fonctionnera comme prévu ?
Les performances des SSD sur IONOS CLOUD Block Storage évoluent avec la taille du volume, et IONOS CLOUD recommande au moins 100 Go pour atteindre les performances complètes, ce qui explique précisément pourquoi les SSD de moins de 100 Go sont déconseillés pour les charges de travail de bases de données. Les distracteurs inversent la relation taille/performance entre HDD et SSD (le HDD est indépendant de la taille), font un mauvais usage des zones de disponibilité et invoquent une réplication inter-régions gérée qui n'existe pas pour Block Storage.
Un architecte ajuste un groupe VM Auto Scaling dont les répliques mettent plusieurs minutes à démarrer et à se mettre en service. Lors des tests, le groupe passe à l'échelle supérieure de manière répétée, puis repasse immédiatement à l'échelle inférieure, oscillant sous une charge stable. Quel choix de configuration stabilise le mieux le groupe ?
L'oscillation est prévenue par les deux contrôles anti-flapping : un délai de refroidissement suffisamment long pour que les nouvelles répliques se mettent en service et prennent en charge la charge, et une séparation obligatoire entre les seuils de mise à l'échelle inférieure et supérieure qui crée une bande morte. Un délai de refroidissement plus court aggrave la surdimensionnement, un groupe ne peut avoir qu'une seule politique de métrique, et il n'y a pas de mise à l'échelle à zéro car le plancher est d'une réplique.
FinCorp doit faire fonctionner son important parc VMware existant sous une stricte souveraineté européenne tout en confiant le cycle de vie de la plateforme à des équipes externes, et il souhaite également déployer de nouvelles charges de travail élastiques sur le bord. Quelle approche correspond le mieux à ces contraintes ?
Un Private Cloud VMware dédié permet à FinCorp de conserver son modèle opérationnel VMware tout en confiant le cycle de vie de la plateforme à IONOS CLOUD. De plus, comme le plan de contrôle est exploité dans l'UE, la souveraineté est préservée, alors qu'un service VMware exploité aux États-Unis dans une région européenne présenterait toujours une exposition à la loi CLOUD, indépendamment de l'emplacement des données. Le schéma hybride place le parc réglementé sur un VMware dédié et les nouvelles charges de travail élastiques sur le calcul standard, au lieu d'imposer une réplatformisation complète coûteuse ou de rester entièrement en local.