Vérification des connaissances - Calcul et élasticité
Testez 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 un score d'au moins 60 % pour réussir.
Un architecte s'attend à ce que VM Auto Scaling gère une charge de travail VM unique en augmentation en ajoutant CPU et RAM aux répliques en cours d'exécution à mesure que la charge augmente. Pourquoi est-ce le mauvais modèle mental du service ?
VM Auto Scaling est horizontal : il lance et termine des répliques complètes pour correspondre à une seule politique de métrique, et les changements de configuration de réplique n'affectent que les nouvelles répliques, jamais la flotte en cours d'exécution. La croissance d'un VM unique avec CPU et RAM est une mise à l'échelle verticale en direct, un mécanisme séparé avec ses propres plafonds (la limite de 240 Go RAM pour la connexion chaud, la réduction CPU/RAM qui nécessite un redémarrage). Les distracteurs 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 correspond parfaitement à un forfait fixe de vCPU, RAM et NVMe, mais dont les données commerciales persistantes doivent survivre aux reconstructions d'instances. Un membre de l'équipe argue qu'un Cube est inapproprié parce que "Cubes ne peut pas utiliser Block Storage". Comment l'architecte doit-il répondre ?
Un Cube est livré avec un modèle NVMe obligatoire et immuable, mais peut également attacher des périphériques HDD/SSD Block Storage supplémentaires, donc les données persistantes appartiennent à ces volumes plutôt qu'au disque NVMe qui est supprimé avec l'instance. La véritable contrainte est que le modèle (vCPU, RAM, NVMe) est fixé après la mise en service, et non que le Cube ne peut pas utiliser Block Storage, donc la conception correcte utilise des volumes supplémentaires pour les données qui doivent survivre.
FinCorp a besoin de placer un disque de démarrage et de données unique pour la base de données VM sur Block Storage et souhaite que le Volume livre sa pleine performance notée SSD. Quelle décision de conception régit le plus directement si la performance SSD sera telle que prévue ?
La performance SSD sur IONOS Block Storage est mise à l'échelle avec la taille du Volume, et IONOS recommande au moins 100 Go pour atteindre une performance complète, ce qui est exactement pourquoi les SSD de moins de 100 Go sont déconseillés pour les charges de travail de base de données. Les options incorrectes inversent la relation de taille entre HDD et SSD (HDD est indépendant de la taille), utilisent abusivement les zones de disponibilité et invoquent une réplication inter-régions gérée qui n'existe pas pour Block Storage.
Un architecte régle un groupe VM Auto Scaling dont les répliques mettent plusieurs minutes à démarrer et à se mettre en route. Lors des tests, le groupe se met à l'échelle en temps réel, puis se réduit immédiatement, en oscillant sous une charge constante. Quel est le choix de configuration qui stabilise le mieux le groupe ?
L'oscillation est prévenue par les deux mécanismes anti-flapping : un temps de refroidissement suffisamment long pour que les nouvelles répliques se mettent en route et prennent en charge la charge, et une séparation obligatoire entre les seuils de réduction et de mise à l'échelle qui crée une bande morte. Un temps de refroidissement plus court aggrave la sur-mise à l'échelle, 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 une réplique.
FinCorp doit exécuter son vaste patrimoine existant de VMware sous une souveraineté de l'UE stricte, tout en déplaçant le cycle de vie de la plateforme hors de ses propres équipes, et il souhaite également de nouvelles charges de travail élastiques au niveau du bord. Quelle approche convient le mieux à ces contraintes ?
Un VMware dédié Private Cloud permet à FinCorp de conserver son modèle d'exploitation de VMware, tandis qu'IONOS possède le cycle de vie de la plateforme, et parce que le plan de contrôle est exploité par l'UE, il préserve la souveraineté, alors qu'un service de VMware exploité par les États-Unis dans une région de l'UE comporterait toujours un risque d'exposition à la loi CLOUD, indépendamment de l'emplacement des données. Le modèle hybride place le patrimoine réglementé sur un VMware dédié et les nouvelles charges de travail élastiques sur un calcul standard, plutôt que de forcer une rétablisation complète coûteuse ou de rester entièrement sur site.