Wissensüberprüfung - Betrieb, Resilienz und Leistung
Ein Architekt muss dem an Zahlungen angrenzenden Service von FinCorp einen automatischen Failover zwischen zwei Verfügbarkeitszonen ermöglichen. Das Team fragt, welches verwaltete IONOS CLOUD-Produkt den Failover orchestriert, indem es die Primärinstanz überwacht, sie als ausgefallen meldet und die Sekundärinstanz im gesamten Stack hochskaliert. Was ist die richtige Antwort, und wie funktioniert der tatsächliche automatisierte Failover-Mechanismus der Plattform?
IONOS CLOUD bietet kein verwaltetes Failover-Produkt an, das die Hochskalierung im gesamten Stack orchestriert. Der native automatisierte Mechanismus kombiniert die Health-Checks der Load-Balancer-Ebene, die den Zustand der Endpunkte innerhalb einer Zone bestimmen, mit einem Cloud DNS-Eintrag mit niedriger TTL, der neu zugewiesen wird, um den Verkehr durch Manipulation der Namensauflösung umzuleiten. Cloud DNS selbst ist nicht zustandsbewusst. Es gibt keinen paketierten „Health-Check-Failover-Eintrag“-Assistenten in der Cloud DNS-Konsole; wenn der Wechsel auf der DNS-Ebene automatisch erfolgen muss, wird er über die Cloud DNS API gesteuert. Der Load Balancer leitet nur an gesunde Ziele weiter, skaliert aber keinen Standby-Stack hoch, und Auto Scaling ersetzt Instanzen innerhalb einer Ebene, anstatt einen Failover zwischen Zonen zu orchestrieren.
Ein Team platziert einen primären Datenbankknoten und dessen Standby-Knoten im selben VDC und lässt die Plattform die Verfügbarkeitszonen automatisch zuweisen, in der Annahme, dass eine automatisch zugewiesene Zone ihnen Redundanz über mehrere Zonen hinweg bietet. Der Architekt markiert dies als die „Auto-Zone-Falle“. Warum ist die Annahme falsch, und welche korrekte Vorgehensweise ist erforderlich?
Die automatische Zonenzuweisung ist keine Garantie für Multi-AZ-Redundanz. Sie kann beide Mitglieder eines redundanten Paares in dieselbe Zone platzieren, was bedeutet, dass ein einzelner Zonenausfall beide Knoten außer Gefecht setzt und die Redundanz nur scheinbar vorhanden ist. Die korrekte Vorgehensweise besteht darin, jedem Mitglied eines redundanten Paares explizite, separate Zonen zuzuweisen: Der Standby-Datenbankknoten wird in eine benannte Zone platziert, die sich von der des primären Knotens unterscheidet, und Pilot-Light-Compute-Ressourcen werden in einer benannten Zone bereitgestellt, die sich von der Produktionsebene unterscheidet. Dies ist zum Designzeitpunkt kostengünstig und kann nach einem Ausfall, der belegt, dass das Paar in derselben Zone lag, nicht sauber nachgerüstet werden.
FinCorp verteilt Produktions-, Nichtproduktions- und compliance-isolierte Workloads auf separate Verträge und betreibt zusätzlich Managed Kubernetes-Cluster. Das Betriebsteam erwartet eine einzelne verwaltete Oberfläche, die alle Telemetriedaten zusammenführt, und erwartet, dass Kubernetes-Steuerungsebenen-Ereignisse neben den Anwendungstagebuchdaten im Logging Service ankommen. Welche Aussage beschreibt korrekt die Observability-Grenzen, die sie einplanen müssen?
Monitoring- und Logging-Pipelines sind pro Vertrag und pro Region organisiert, und das Activity Log ist pro Vertrag ohne Aggregationsschnittstelle. Es gibt daher keine native Oberfläche, die Telemetriedaten über separate Verträge hinweg zusammenführt. Die Aggregation wird erstellt, indem das Signal jedes Vertrags in einen externen Collector geleitet wird. Unabhängig davon bedeutet die Quelle "Kubernetes" im Logging Service die Workload- und Knotentagebuchdaten innerhalb des Clusters, die Sie selbst übermitteln, nicht die verwaltete Steuerungsebene. Steuerungsebenen-Ereignisse werden niemals in die Logging Service-Pipeline ausgegeben. Das separate "Logging to S3"-Schaltfeld des Clusters schreibt Cluster-Tagebuchdaten in einen Bucket und stellt keine Sichtbarkeit der Steuerungsebene in Ihrer Monitoring-Oberfläche dar.
Die regulierte Transaktionsdatenbank von FinCorp enthält nur wenige Dutzend Gigabyte an aktiven Daten, und ein Ingenieur schlägt vor, sie auf einem 40 GB SSD-Volumen bereitzustellen, um dem geringen Datenbedarf zu entsprechen. Der Architekt widerspricht diesem Vorschlag. Welche Begründung ist korrekt, um die Volumengröße festzulegen?
Die SSD-Leistung skaliert mit der Volumengröße bis zu einer Obergrenze und steigt pro Gigabyte an, sodass ein kleines SSD-Volumen eine anspruchsvolle Arbeitslast unterversorgt. Die Plattform empfiehlt, SSD-Volumen von mindestens 100 GB zu reservieren, um den vollen Nutzen zu erzielen, und für Datenbank-Workloads ist diese Untergrenze von etwa 100 GB entscheidend: Ein SSD-Volumen darunter beeinträchtigt eine Datenbank-Ebene, selbst wenn der Datensatz klein ist. Das Volumen wird daher zuerst nach Leistung und zweitens nach Kapazität dimensioniert. Es ist das HDD, nicht das SSD, dessen Leistung konstant und unabhängig von der Volumengröße ist, und der Data Center Designer leitet die erwartete Leistung aus der Größe des Volumes ab, anstatt die Obergrenze bei jeder Größe zu garantieren.
FinCorp muss eine große VMware-Umgebung in IONOS CLOUD migrieren. Der Projektplan geht von einem nativen OVF/OVA-Importassistenten für die VMs und einem replikationsbasierten Cutover für die Datenbanken aus, die auf IONOS CLOUD Managed PostgreSQL migriert werden. Der Architekt lehnt beide Annahmen ab. Welche Beschreibung des korrekten, technisch umgesetzten Vorgehens ist zutreffend?
IONOS CLOUD verfügt über keinen nativen OVF/OVA-Importassistenten, daher wird die Migration technisch umgesetzt und nicht importiert, und der Architekt wählt pro Arbeitslast einen von drei ehrlichen Wegen: Bildkonvertierung und Hochladen auf die KVM Public Cloud-Oberfläche, VMware-native Replikation und Live-Failover in eine dedizierte Private Cloud, oder Backup/Restore. Auf dem Private Cloud-Weg erstreckt ein Layer 2 VPN ein Segment über mehrere Standorte, sodass gestaffelte Wellen ihre IP-Adressen beibehalten, während die Live-Mobilität zwischen Hosts nur intra-cluster erfolgt und niemals ein Live-Wechsel über Standorte hinweg ist. Die Datenbankwelle ist ein dump-and-restore-Hard-Cutover mit einem echten Ausfallzeitfenster, da es kein natives replikationsbasiertes Cutover in die verwalteten Datenbanken gibt; die Quelle bleibt autoritativ, bis das wiederhergestellte Ziel validiert ist.