Google ACE: Compute Engine und Betrieb virtueller Maschinen — Lernleitfaden

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Teil des Google Associate Cloud Engineer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Compute Engine bietet flexible, hochleistungsfähige virtuelle Maschinen und Orchestrierungsprimitive zur Ausführung von allgemeinen und spezialisierten Workloads. Operative Exzellenz auf Compute Engine bedeutet, die richtige Maschinenfamilie und Festplatte auszuwählen, den Lebenszyklus von Instanzen mit Vorlagen und Instanzgruppen zu gestalten, eine robuste Autoreparatur und Autoskalierung zu etablieren, Zugriffspfade zu härten und sich mit wiederholbaren Wiederherstellungsverfahren auf Ausfallszenarien vorzubereiten. Dieser Abschnitt erläutert Designentscheidungen, Kompromisse und Betriebsmuster, die den manuellen Aufwand minimieren und die Zuverlässigkeit sowie Kosteneffizienz maximieren.

Maschinentypen, Dimensionierung und Instanzlebenszyklus

Maschinenfamilien

• Allzweck: E2 (kostenoptimiert), N2 (ausgewogen), N2D (AMD-basiert), Tau T2D/T2A (hohes Preis-Leistungs-Verhältnis für Scale-Out), geeignet für die meisten Workloads.
• Rechenoptimiert: C3 für CPU-gebundene Aufgaben; wählen Sie diese, wenn Sie eine hohe Leistung pro Kern benötigen.
• Speicheroptimiert: M-Serie für In-Memory-Datenbanken und -Analysen.
• GPUs und Beschleuniger: Fügen Sie diese zu unterstützten Familien hinzu, wenn Sie CUDA- oder ML-Beschleunigung benötigen; stellen Sie sicher, dass die Treiberinitialisierung in den Startprozessen erfasst wird.

Benutzerdefinierte Maschinentypen

• Verwenden Sie benutzerdefinierte vCPU- und Speichergrößen, um Workloads richtig zu dimensionieren und Verschwendung zu reduzieren, insbesondere bei asymmetrischen Anforderungen (z. B. hoher Speicherbedarf bei moderater CPU-Nutzung).
• Bevorzugen Sie bei CPU-gebundenen Diensten eine höhere Anzahl an vCPUs; bei speichergebundenen Diensten erhöhen Sie den RAM und stellen Sie sicher, dass Garbage Collectors und Caches optimiert sind.
• Achten Sie auf Lizenzmodelle, die an die Anzahl der Kerne gebunden sind; benutzerdefinierte Typen helfen, unnötige lizenzierte Kerne zu vermeiden.

Dimensionierung von Workloads

• Beginnen Sie mit Ressourcenprofilen, die in Entwicklungs- oder früheren Umgebungen gemessen wurden: CPU-Auslastung bei P95, maximaler Speicherverbrauch (High-Water-Mark), Festplattendurchsatz/IOPS, Netzwerkbandbreite.
• Planen Sie bei stoßweisem Datenverkehr einen Puffer ein oder verwenden Sie Autoskalierung; streben Sie bei stabilen Zuständen eine Auslastung von 60–70 % zur Spitzenzeit an, um Kosten und Ausfallsicherheit in Einklang zu bringen.
• Evaluieren Sie Spot VMs (Preemptible VMs) für Batch- und fehlertolerante Jobs; sie können jederzeit beendet werden, also konzipieren Sie sie mit Checkpointing und Wiederholungsversuchen.

Ressourcen für den Instanzlebenszyklus

• VM-Instanzen: Die atomare Rechenressource. Verwenden Sie Labels und eine konsistente Namensgebung, um die Automatisierung voranzutreiben.
• Instanzvorlagen: Unveränderliche Blueprints, die Maschinentyp, Festplatten, Dienstkonten, Metadaten und Startskripte erfassen; sie sind die Grundlage für verwaltete Instanzgruppen und gewährleisten wiederholbare Deployments.
• Verwaltete Instanzgruppen (MIGs): Bieten eine deklarative Größe, Autoskalierung, Autoreparatur, Rolling Updates, regionale (Multi-Zonen) Platzierung und Konfiguration pro Instanz. Bevorzugen Sie MIGs für zustandslose und zustandsbehaftete Muster (zustandsbehaftete MIGs behalten ausgewählte Festplatten/IPs bei).
• Nicht verwaltete Instanzgruppen: Einfache Sammlungen für das Load Balancing von Legacy-Systemen; ohne Autoskalierung/Autoreparatur. Nur verwenden, wenn Sie unabhängig verwaltete VMs registrieren müssen.

Verfügbarkeit, Autoskalierung und Wartung

Autoskalierung

• Signale: CPU-Auslastung, Anfragen pro Sekunde pro Instanz eines HTTP-Load-Balancers, Cloud Monitoring-Messwerte und Warteschlangentiefe. Wählen Sie ein Signal, das eng mit der Sättigung korreliert; die CPU ist eine gute Basis für homogene, CPU-gebundene Workloads.
• Abkühlphasen und Stabilisierung: Konfigurieren Sie diese, um ein „Thrashing“ (ständiges Skalieren) zu verhindern. Wenn Ihre Anwendung Minuten zum Aufwärmen benötigt, erhöhen Sie die anfängliche Verzögerung der MIG und legen Sie eine angemessene Abkühlphase für die Autoskalierung fest.
• „Genau-eine“-Muster: Um genau eine VM zu erzwingen, setzen Sie bei einer MIG min=1 und max=1 für die Autoskalierung. Dies erhält die Integrität und ermöglicht gleichzeitig die Autoreparatur.

Autoreparatur und Systemdiagnosen

• Systemdiagnosen: Verwenden Sie HTTP(S)-Prüfungen für die Lebendigkeit der Anwendung; TCP validiert nur die Annahme von Sockets. Implementieren Sie einen Systemdiagnose-Endpunkt, der kritische Abhängigkeiten prüft.
• Schwellenwerte und Intervalle: Passen Sie das Prüfintervall und die Schwellenwerte an, um Ausfälle schnell und ohne Fehlalarme zu erkennen.
• Anfängliche Verzögerung: Stellen Sie die anfängliche Verzögerung für die Autoreparatur der MIG lang genug für den Start und das Aufwärmen ein, um einen vorzeitigen Austausch von fehlerfreien Instanzen zu vermeiden, die gerade online gehen.
• Fehlermodi: Falsch konfigurierte Systemdiagnose-Endpunkte und zu kurze anfängliche Verzögerungen verursachen „Flapping“ (Instabilitäten) und Überprovisionierung.

Regionale MIGs und Platzierung

• Regionale MIGs verteilen Instanzen über mehrere Zonen in einer Region und bieten so eine Toleranz gegenüber Zonenausfällen. Wählen Sie die Anzahl der Ziel-Replikate pro Zone basierend auf der Kapazitätsplanung.
• Verwenden Sie Konfigurationen pro Instanz und zustandsbehaftete Richtlinien, wenn die Beibehaltung von Festplatten oder IPs erforderlich ist; beachten Sie, dass der Austausch von VMs aufgrund der Zustandsabstimmung langsamer sein kann.

Wartung, Live-Migration und Reservierungen

• Live-Migration: Standard für die meisten VMs; Instanzen werden während der Host-Wartung ohne Neustart verschoben. Für Workloads, die keine Migration tolerieren (z. B. latenzempfindliches HFT), setzen Sie die Wartungsrichtlinie auf „Beenden“ und verlassen Sie sich auf die Autoreparatur.
• Host-Wartungsfenster sind mit Live-Migration transparent, erzeugen aber dennoch Ereignisse; überwachen und testen Sie dies.
• Reservierungen: Erstellen Sie zonale Reservierungen, um Kapazität für kritische Starts oder strenge SLOs zu garantieren. Wenden Sie den Reservierungsverbrauch „spezifisch“ oder „beliebig“ basierend auf Ihrer Governance an. Reservierungen sind Kapazitätsgarantien; kombinieren Sie sie mit Rabatten für zugesicherte Nutzung (Committed Use Discounts) für die Kostenplanung.

Speicher, Images und Leistung

Persistente Festplatten

• Typen: Standard (HDD) für sequenziellen Durchsatz bei niedrigen Kosten; Balanced (pd-balanced) für allgemeine Zwecke; SSD (pd-ssd) für hohe IOPS/niedrige Latenz; Extreme (pd-extreme) für bereitgestellte IOPS und Durchsatz in Hochleistungsstufen. Regionale PDs bieten synchrone Replikation über Zonen hinweg für erhöhte Verfügbarkeit.
• Die Leistung skaliert bei Standard, Balanced und SSD mit der Festplattengröße; dimensionieren Sie die Festplatte vorab, um Spitzen-IOPS/Durchsatz zu erreichen, oder verwenden Sie Extreme, um explizit bereitzustellen.
• Multi-Attach im schreibgeschützten Modus ermöglicht die gemeinsame Nutzung von Datensätzen über viele VMs hinweg; koordinieren Sie den Zugriff und die Caching-Ebenen entsprechend.

Lokale SSD

• Flüchtig, direkt an den Host angeschlossen, sehr hohe IOPS/niedrige Latenz. Daten gehen bei Anhalten/Beenden/Migrieren verloren. Verwendung für Scratch-Speicher, Caches und replizierte Datenebenen. Stellen Sie Replikation auf Anwendungsebene oder Checkpoints sicher.

Snapshots und Images

• Snapshots sind inkrementelle Point-in-Time-Backups von persistenten Festplatten; planen Sie sie mit dem Resource Manager oder gcloud, um das RPO zu erfüllen. Regionsübergreifender Speicher unterstützt DR.
• Images erfassen Boot-Festplatten plus Konfiguration. Pflegen Sie eine gehärtete, patch-verwaltete Image-Pipeline. Validieren Sie Gast-Agenten (für Logging/Monitoring) in Ihren Golden Images.
• Wiederherstellungsmuster: Halten Sie für eine schnelle Wiederherstellung die Basis-Images klein und konfigurieren Sie den Rest über Startskripte oder cloud-init; dies reduziert Abweichungen (Drift) und beschleunigt Updates.

Festplattenauswahl: Kompromisse und Ausfallmodi

• Unterprovisionierte Festplatten drosseln den Anwendungsdurchsatz; Überprovisionierung verursacht unnötige Kosten. Messen Sie die tatsächlichen I/O-Eigenschaften und wählen Sie die kleinste Festplatte, die den Spitzenbedarf mit einem Puffer erfüllt.
• Für Datenbanken ziehen Sie regionale PDs und pd-ssd/pd-extreme in Betracht; validieren Sie das fsync-Verhalten und die Warteschlangentiefen (Queue Depths). Vermeiden Sie lokale SSDs für dauerhafte Zustände (durable state), es sei denn, sie werden repliziert.

Zugriff, Sicherheit, Netzwerk und spezialisierte Workloads

Linux- und Windows-Administration

• Linux SSH: Bevorzugen Sie OS Login, um die SSH-Autorisierung zu zentralisieren und den Zugriff Identitäten zuzuordnen. Vergeben Sie compute.osLogin oder compute.osAdminLogin an Gruppen, nicht an Einzelpersonen.
• Windows RDP: Legen Sie Windows-Anmeldeinformationen in der Konsole oder über gcloud fest; stellen Sie sicher, dass Firewall-Regeln TCP 3389 nur von vertrauenswürdigen IPs zulassen. Verwenden Sie IAP TCP-Forwarding, um eine öffentliche Freigabe zu vermeiden.
• Serielle Konsole: Aktivieren Sie sie als Notfallzugang (Break-Glass-Pfad); verwenden Sie

undefined

für das Boot-Debugging. Beschränken Sie den Zugriff mit IAM und überwachen Sie ihn.

SSH, OS Login und Schlüsselverwaltung

• Aktivieren Sie OS Login auf Projekt- oder Instanzebene mit den Metadaten

undefined

. Benutzer fügen ihren öffentlichen SSH-Schlüssel zu ihrem Google-Konto hinzu; IAM steuert den rollenbasierten Zugriff.

• Für sudo/root verwenden Sie compute.osAdminLogin. Deaktivieren Sie projektweite SSH-Schlüssel, wenn Sie OS Login verwenden, um Abweichungen (Drift) zu vermeiden.

Metadaten, Startskripte und cloud-init

• Der Metadatenserver stellt Instanz-/Projektdaten und Service-Account-Token bereit. Verwenden Sie nur Token mit eng gefasstem Geltungsbereich (well-scoped); kodieren Sie niemals Secrets fest.
• Startskripte und cloud-init: Bootstrappen Sie Agenten, rufen Sie Konfigurationen ab und registrieren Sie Dienste. Gestalten Sie Skripte idempotent und schreiben Sie Protokolle zur Diagnose in die serielle Konsole.
• Metadaten pro Instanz können Vorlageneinstellungen überschreiben; verwenden Sie sie sorgfältig, um Konfigurationsabweichungen (Configuration Skew) zu vermeiden.

Service-Accounts und Geltungsbereiche (Scopes)

• Weisen Sie pro Workload einen dedizierten Service-Account mit IAM-Rollen nach dem Prinzip der geringsten Rechte (Least Privilege) für die erforderlichen Ressourcen zu (z. B.

undefined

für einen bestimmten Bucket).

• Bevorzugen Sie breite Cloud-API-Geltungsbereiche (Scopes) nur dann, wenn IAM den Zugriff streng kontrolliert; andernfalls beschränken Sie die Geltungsbereiche auf die minimal erforderlichen APIs.

Netzwerk und Adressen

• NICs können nur interne oder auch externe IPs haben. Bevorzugen Sie private VMs mit Cloud NAT oder IAP für ausgehenden Datenverkehr und administrativen Zugriff.
• Reservieren Sie statische interne IPs für stabile Endpunkte wie Lizenzserver; vermeiden Sie die Abhängigkeit von flüchtigen Adressen.
• Externes HTTP(S) Load Balancing terminiert TLS am Edge; verwenden Sie verwaltete Zertifikate und Health Checks für die Backend-MIGs. Halten Sie die Bereitschaft des Backends auf den Health Check und die anfängliche Verzögerung der MIG abgestimmt.

Spezialisierte Workloads und Isolation

• Shielded VMs: Secure Boot, vTPM und Integritätsüberwachung schützen vor Rootkits; aktivieren Sie diese standardmäßig, es sei denn, inkompatible Treiber erfordern etwas anderes.
• Confidential VMs: Speicherverschlüsselung mit AMD SEV schützt Daten während der Nutzung (Data-in-Use); im Allgemeinen minimaler Performance-Overhead, aber validieren Sie dies für latenzempfindliche Anwendungen.
• Sole-Tenant-Knoten: Dedizierte physische Hosts für Compliance, Isolation von „lauten Nachbarn“ (Noisy-Neighbor-Isolation) und Lizenz-Affinität. Planen Sie Kapazitätsfragmentierung und höhere Kosten ein.

Fehlerbehebung und Wiederherstellungsmaßnahmen

Allgemeine Diagnosen

• Konnektivität: Überprüfen Sie Firewall-Regeln, Berechtigungen von Dienstkonten und Routen. Verwenden Sie die Konnektivitätstests des Network Intelligence Center.
• Startprobleme: Überprüfen Sie die Logs der seriellen Konsole, erstellen Sie einen Screenshot und prüfen Sie die Ausgabe des Startskripts. Deaktivieren Sie Secure Boot vorübergehend, wenn unsignierte Treiber den Start blockieren, und beheben Sie anschließend das Problem.
• Zugriffssperre: Bei SSH-Problemen mit OS Login, bestätigen Sie die IAM-Rollen und dass Schlüssel in den Benutzerkonten vorhanden sind; verwenden Sie die serielle Konsole, um einen Benutzer für den Notfallzugriff hinzuzufügen.
• Festplattenbeschädigung: Trennen Sie das Boot-Laufwerk, hängen Sie es an eine Rettungs-VM an, reparieren Sie die Dateisysteme, rotieren Sie die Anmeldeinformationen und erstellen Sie nach der Behebung ein Image.

Verhalten von MIGs und Load Balancern

• Überprovisionierung: Wenn Instanzen eine lange Aufwärmphase benötigen, erhöhen Sie die anfängliche Verzögerung der MIG und den Cooldown des Autoscalers; andernfalls skalieren Sie möglicherweise aufgrund von 4xx/5xx-Fehlern hoch, während die Anwendung noch initialisiert wird.
• Autohealing-Schleifen: Bestätigen Sie die Semantik des Zustands-Endpunkts und die Bereitschaft von Abhängigkeiten; staffeln Sie den Start von Abhängigkeiten oder fügen Sie Wiederholungsversuche hinzu.

Wiederherstellungsmuster

• Instanz aus Vorlage oder Image neu erstellen; unveränderliche (immutable) Muster reduzieren die MTTR.
• Daten aus dem letzten erfolgreichen Snapshot wiederherstellen; validieren Sie RPO/RTO anhand der Geschäftsanforderungen.
• Bei regionalen Ausfällen führen Sie ein Failover in eine andere Zone oder Region durch, indem Sie regionale MIGs und regionenübergreifende Snapshot-Replikation verwenden.

Betriebliche Schutzmaßnahmen

• Reservierungen für kritische Kapazitäten; verwenden Sie monitoring-basierte Benachrichtigungen zum Verbrauch von Reservierungen und Kontingenten.
• Audit und Logging: Aktivieren Sie Logs für Administratoraktivitäten und Datenzugriffe für kritische Dienste. Ordnen Sie den Zugriff über OS Login und Dienstkonten zu.

Kurze Beispiele

• Eine statische interne IP-Adresse reservieren:

undefined

• OS Login auf Projektebene aktivieren:

undefined

• Einen HTTP-Health-Check erstellen und an eine MIG mit Autohealing anhängen:

undefined

undefined

Praktisches Problemszenario

Northwind Analytics betreibt eine latenzempfindliche API auf Compute Engine. Vorfälle zeigen eine häufige Überprovisionierung während der Deployments, gelegentliche Unklarheiten beim SSH-Zugriff unter den Administratoren und einen lizenzierten Telemetrie-Server, der unter 10.0.3.21 erreichbar bleiben muss. Das Ziel ist es, die Skalierung zu stabilisieren, den Zugriff abzusichern und die Stabilität des Lizenz-Endpunkts zu gewährleisten.

Vorgehensweise

1. Eine Instanzvorlage mit einem passenden benutzerdefinierten Maschinentyp und Start-Bootstrapping erstellen

• Begründung: Die Vorlage erzwingt Unveränderlichkeit (Immutability). Ein benutzerdefinierter Typ mit 6 vCPUs/20 GB RAM entspricht den gemessenen P95-Werten für CPU und Arbeitsspeicher und vermeidet gleichzeitig überschüssige Kerne, die die Lizenzkosten erhöhen würden. Ein Startskript registriert die API erst dann beim Load Balancer, wenn die Health Checks erfolgreich sind, was die Auswirkungen der Aufwärmphase reduziert.

2. Eine regionale verwaltete Instanzgruppe (MIG) hinter einem externen HTTP(S) Load Balancer bereitstellen

• Begründung: Eine regionale MIG verteilt Instanzen auf mehrere Zonen, um eine Toleranz gegenüber Zonenausfällen zu gewährleisten. Der HTTP(S) Load Balancer terminiert TLS am Edge und führt Health Checks pro Instanz durch, sodass der Traffic nur an bereite Backends geleitet wird.

3. Autoscaling auf Basis der CPU mit Cooldown und Autohealing mit einer realistischen anfänglichen Verzögerung konfigurieren

• Begründung: Die CPU-Auslastung korreliert stark mit der Sättigung dieser API. Ein Cooldown von 90 Sekunden verhindert ein “Thrashing” (schnelles Hoch- und Herunterskalieren) bei vorübergehenden Lastspitzen. Eine anfängliche Verzögerung von 200 Sekunden passt zur Aufwärmphase von Containern und JIT und verhindert, dass der Autoscaler Kaltstarts als Kapazitätsengpass interpretiert.

4. Den Health Check optimieren und einen /healthz-Endpunkt auf Anwendungsebene hinzufügen

• Begründung: Ein HTTP-Health-Check, der Abhängigkeiten (Cache, DB-Konnektivität) validiert, erkennt “Gray Failures” (schwer erkennbare Teil-Ausfälle). Die Verwendung von 10-Sekunden-Intervallen und 3 Schwellenwerten für den fehlerhaften Zustand schafft eine Balance zwischen Erkennungsgeschwindigkeit und dem Risiko von Fehlalarmen.

5. OS Login aktivieren und einer IAM-Gruppe Administratorzugriff gewähren

• Begründung: OS Login zentralisiert die SSH-Autorisierung und -Zuordnung. Administratoren fügen ihre öffentlichen SSH-Schlüssel zu ihren Google-Konten hinzu; die Zuweisung von compute.osAdminLogin an die Bereitschaftsgruppe (On-Call-Gruppe) gewährt sudo-Rechte und erhält gleichzeitig die Audit-Protokolle. Dies beseitigt die Abweichung von Schlüsseln pro VM.

6. Die statische interne IP-Adresse des Lizenzservers reservieren und an eine kleine, dedizierte VM anhängen

• Begründung: Die Reservierung von 10.0.3.21 garantiert die Verfügbarkeit der Adresse und verhindert eine versehentliche Wiederverwendung. Weisen Sie sie der NIC der Lizenz-VM zu, damit abhängige Anwendungen keine Konfigurationsänderungen benötigen. Beschränken Sie Firewall-Regeln auf nur erlaubte Quell-Subnetze.

7. Der API-Vorlage ein dediziertes Dienstkonto mit den geringsten IAM-Rechten (Least Privilege) zuweisen

• Begründung: Das Prinzip der geringsten Rechte (Principle of Least Privilege) reduziert den potenziellen Schaden bei einer Kompromittierung (“Blast Radius”). Dem Dienstkonto werden nur die benötigten Rollen gewährt (z. B. Lesezugriff auf bestimmte Secrets und Pub/Sub-Themen). Die Verwendung einer Vorlage stellt sicher, dass alle Instanzen die korrekte Identität erben.

8. Instanzen mit Shielded VM absichern und den Notfallzugriff über die serielle Konsole durchsetzen

• Begründung: Secure Boot und Integritätsüberwachung mindern das Risiko von Manipulationen am Kernel/Bootloader. Beschränken Sie den Zugriff auf die serielle Konsole mit IAM und protokollieren Sie den Zugriff für Audits; behalten Sie ihn für die Wiederherstellung bei, falls SSH fehlschlägt.

9. Snapshot-Zeitpläne für zustandsbehaftete (stateful) Festplatten implementieren und die Wiederherstellung testen

• Begründung: Obwohl die API zustandslos (stateless) ist, erstellen Sie einen Snapshot-Zeitplan für den Lizenzserver und alle Konfigurationsfestplatten, um die RPO-Anforderungen zu erfüllen. Regelmäßige Wiederherstellungstests validieren die Tools und Runbooks.

10. Validieren und bereitstellen

• Begründung: Blue/Green- oder Canary-Updates mit den Rolling-Update-Einstellungen der MIG reduzieren das Risiko. Monitoring-Dashboards bestätigen die Stabilisierung der Instanzanzahl während der Deployments, eine verbesserte Zuordnung des Administratorzugriffs und die ununterbrochene Erreichbarkeit von 10.0.3.21.

← Ressourcenhierarchie · Alle Domänen · Container →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Google durchsuchen →