Vérification des connaissances - Opérations, résilience et performances
Testez votre compréhension des concepts clés du Module 7. 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 doit donner au service de paiement de FinCorp une bascule automatique entre deux zones de disponibilité. L'équipe demande quel produit géré IONOS orchestre la bascule en surveillant le principal, en le déclarant mort, et en promouvant le secondaire dans tout le stack. Quelle est la bonne réponse, et quel est le mécanisme réel de bascule automatique de la plateforme ?
IONOS ne vend pas de produit de bascule géré qui orchestre la promotion dans tout le stack. Le mécanisme automatisé natif compose le plan d'équilibrage de charge des vérifications de santé, qui décident de la santé des points de terminaison dans une zone, avec un enregistrement Cloud DNS à faible TTL qui est réorienté pour déplacer le trafic en manipulant la résolution de nom. Le Cloud DNS lui-même n'est pas conscient de la santé. Il n'y a pas de « wizard » d'enregistrement de bascule de vérification de santé empaqueté dans la console Cloud DNS ; là où la coupure doit être automatique au niveau DNS, elle est pilotée par le Cloud DNS API. Le Load Balancer ne transmet qu'aux cibles saines, mais ne promeut pas de stack de secours, et le scaling automatique remplace des instances dans un niveau plutôt que d'orchestrer la bascule entre zones.
Une équipe place une base de données principale Node et son système de secours dans le même centre de données virtuel et laisse la plateforme assigner les zones de disponibilité automatiquement, en supposant qu'une zone assignée automatiquement leur donne une redondance multi-zone. L'architecte signale cela comme le piège de la zone auto. Pourquoi l'hypothèse est-elle erronée, et quelle est la discipline correcte ?
L'assignation automatique de zone n'est pas une garantie multi-AZ. Elle peut placer les deux membres d'une paire redondante dans la même zone, ce qui signifie qu'une défaillance de zone unique peut éliminer les deux et que la redondance est illusoire. La discipline consiste à assigner des zones explicites et distinctes à chaque membre d'une paire redondante : la base de données de secours Node est située dans une zone nommée différente de la principale, et le calcul pilot-light est provisionné dans une zone nommée distincte du niveau de production. Cela est peu coûteux au moment de la conception et ne peut pas être rétrofit de manière propre après une panne qui prouve que la paire était co-localisée.
FinCorp divise la production, la non-production et une charge de travail isolée pour la conformité à travers des contrats séparés, et exécute également des grappes Managed Kubernetes. L'équipe d'exploitation s'attend à un seul panneau géré qui réunit toutes les télémétries et s'attend à ce que les événements de plan de contrôle Kubernetes arrivent dans le Logging Service aux côtés des journaux d'application. Quel énoncé décrit correctement les limites d'observabilité qu'ils doivent concevoir ?
Les pipelines de surveillance et de journalisation sont par contrat et par région, et le journal d'activité est par contrat sans point de terminaison d'agrégation, il n'y a donc pas de panneau natif qui réunit les télémétries à travers des contrats séparés ; l'agrégation est construite en éventail de chaque signal de contrat dans un collecteur externe. Séparément, la source « Kubernetes » dans le Logging Service signifie dans le workload Cluster et les journaux Node que vous expédiez vous-même, et non le plan de contrôle géré ; les événements de plan de contrôle ne sont jamais émis dans le pipeline Logging Service. L'option « Journalisation vers S3 » du Cluster écrit les données de journal Cluster dans un bac et n'est pas la visibilité du plan de contrôle dans votre panneau de surveillance.
La base de données de transactions réglementées de FinCorp contient seulement quelques dizaines de gigaoctets de données en direct, et un ingénieur propose de la configurer sur un SSD Volume de 40 GB pour correspondre à la petite empreinte de données. L'architecte annule cette proposition. Quel raisonnement est correct pour dimensionner le Volume ?
Les performances de SSD sont mises à l'échelle avec la taille de Volume jusqu'à une limite, s'accumulant par gigaoctet, donc un petit SSD Volume affame une charge de travail exigeante. La plateforme recommande de réserver des volumes de SSD d'au moins 100 GB pour obtenir le plein bénéfice, et pour les charges de travail de base de données, ce plancher d'environ 100 GB est porteur de charge : un SSD Volume en dessous de celui-ci dégrade un niveau de base de données même lorsque l'ensemble de données est petit. Le Volume est donc dimensionné en fonction des performances en premier et de la capacité en second. C'est HDD, et non SSD, dont les performances sont plates et indépendantes de la taille de Volume, et le Data Center Designer dérive des performances prévues de la taille de Volume plutôt que de garantir le plafond à toute taille.
FinCorp doit migrer un vaste estate VMware vers IONOS. Le plan de projet suppose un assistant d'importation natif OVF/OVA pour les machines virtuelles et une coupure basée sur la réplication pour les bases de données qui seront déplacées vers IONOS Managed PostgreSQL. L'architecte rejette ces deux hypothèses. Quelle description de l'approche ingénieriée correcte est exacte ?
IONOS n'a pas d'assistant d'importation natif OVF/OVA, la migration est donc ingénieriée et non importée, et l'architecte choisit l'une des trois voies honnêtes par charge de travail : conversion d'image et téléchargement sur la surface KVM Public Cloud, réplication et basculement natif VMware vers des Private Cloud dédiés, ou sauvegarde/restauration. Sur la voie Private Cloud, un VPN de couche 2 étend un segment sur les sites afin que les vagues progressives conservent leurs adresses IP, tandis que la mobilité live entre les hôtes est intra-Cluster uniquement et n'est jamais un déplacement en direct d'un site à l'autre. La vague de base de données est une coupure dure dump-and-restore avec un véritable temps d'arrêt, car il n'y a pas de coupure basée sur la réplication native vers les bases de données gérées ; la source reste autoritaire jusqu'à ce que la cible restaurée soit validée.