Google PCA: Migration, Modernisierung und Hybrid-Cloud-Strategie — Lernleitfaden

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Überblick

Eine erfolgreiche Migrations-, Modernisierungs- und Hybrid-Cloud-Strategie stimmt die Plattformauswahl auf die Geschäftsergebnisse ab und managt gleichzeitig Risiken in Bezug auf Verfügbarkeit, Datenintegrität, Latenz, Sicherheit und Kosten. Der Weg dorthin balanciert ein schnelles Rehosting zur Reduzierung des Rechenzentrumsrisikos mit gezieltem Refactoring, um die Vorteile der Cloud zu nutzen. Das Betriebsmodell muss sich parallel zur Technologie weiterentwickeln, um Verbesserungen aufrechtzuerhalten. Dieser Abschnitt bietet einen pragmatischen Leitfaden für die Bewertung und Wellenplanung, Entscheidungs-Frameworks, Migrationsmechanismen, hybride Integration, Modernisierungsmuster, Richtlinien- und Multi-Cloud-Überlegungen sowie die Optimierung nach der Migration, mit Schwerpunkt auf Fehlermodi und Kompromissen.

Bewertung, Bereitschaft und Wellenplanung

• Erkennung und Abhängigkeitsanalyse

  • Inventarisieren Sie Workloads, Versionen, OS-Kernel, Speicher, IAM und Datenklassifizierungen. Bilden Sie Abhängigkeiten über Web→API→DB-Flows, gemeinsam genutzte Dienste (LDAP/AD, DNS, NTP), Batch-Pipelines und externe APIs ab.
  • Nutzen Sie Application Profiling und Distributed Tracing in Umgebungen vor der Migration, um versteckte Abhängigkeiten und Long-Tail-Latenzen aufzudecken. Aktivieren Sie VPC Flow Logs und Instrumentierung auf Anwendungsebene (Cloud Logging, Cloud Monitoring, Cloud Trace).
  • Identifizieren Sie Zustandsgrenzen und Datengravitation: Größe, Zugriffsmuster (R/W-Mix), Konsistenzerwartungen und Replikationstopologie.

• Bereitschaft und Fähigkeiten

  • Bewerten Sie die Kenntnisse in den Bereichen Cloud-Grundlagen, IaC, CI/CD, SRE, Sicherheit, Netzwerk und Datenbanken. Definieren Sie eine rollenbasierte Schulungs- und Zertifizierungs-Roadmap und budgetieren Sie Zeit für Weiterbildung und begleitende Bereitschaftsdienste (Shadow On-Calls).
  • Richten Sie eine Landing Zone (Projekte, Ordner, Shared VPC, Organisationsrichtlinien, Audit-Sinks, CMEK-Strategie) vor der ersten Welle ein.

• Planung der Migrationswellen

  • Gruppieren Sie Anwendungen nach Affinität und Auswirkungsradius (Blast Radius) in Wellen: gemeinsame Daten, synchrone Abhängigkeiten und Änderungsfenster. Ziehen Sie risikoreiche Abhängigkeiten in dieselbe Welle oder ersetzen Sie sie durch klar definierte API-Verträge (Stubs).
  • Definieren Sie pro Welle SLOs, RTO/RPO, Rollback-Kriterien und Validierungs-Gates (Schemaprüfungen, synthetische User Journeys, Leistungsschwellenwerte).
  • Bereiten Sie Runbooks und das Change Management vor: Umstellungsschritte, Checkpoints, Rollback und Sammlung von Nachweisen für die Abnahme.

• Kompatibilität, Lizenzierung und Performance-Baselining

  • Validieren Sie die Unterstützung von Betriebssystemen und Middleware in Compute Engine und Managed Services. Überprüfen Sie kommerzielle Lizenzbedingungen, BYOL-Einschränkungen, Anforderungen an Kernel-Module und Hardware-Affinitäten.
  • Erfassen Sie Baselines für CPU, Speicher, IOPS, Durchsatz und Latenz mit Spitzen- und 95-Perzentil-Werten, um Zielressourcen zu dimensionieren und die Vorteile zu validieren.

• Data Governance

  • Klassifizieren Sie PII/PCI-Daten. Planen Sie die De-Identifizierung oder Tokenisierung bei der Erfassung (Ingest) mit Cloud DLP. Definieren Sie Audit-, Aufbewahrungs- und Exportrichtlinien, bevor das erste Produktionsprotokoll gespeichert wird.

Häufige Fehlermodi: unbekannte synchrone Abhängigkeiten, die nach der Umstellung kaskadierende Timeouts verursachen; überlappende IP-Bereiche, die die Konnektivität blockieren; Lücken in der Lizenzkonformität; fehlende Rollback-Parität, bei der Datenänderungen nicht rückgängig gemacht werden können.

Migrationsmuster, Datenverschiebung und Umstellung (Cutover)

• Entscheidungsrahmen (die 6 Rs)

  • Rehost (Rehosting): Verschiebung „as-is“ nach Compute Engine. Schnellste Zeit bis zur Cloud-Bereitstellung, minimale Änderungen. Risiko: Übernahme von technischen Schulden und ineffizienter Dimensionierung.
  • Replatform (Replatforming): Kleine Änderungen zur Übernahme von Managed Services (z. B. Cloud SQL, Cloud Load Balancing). Schnellere betriebliche Vorteile bei geringen Code-Änderungen.
  • Refactor (Refactoring): Dekomposition oder Containerisierung für GKE/Cloud Run; Übernahme von ereignisgesteuerten Mustern. Höchster langfristiger Nutzen bei gleichzeitigem Umsetzungsrisiko.
  • Retire (Stilllegen): Entfernen ungenutzter Systeme, nachdem deren Nichtverwendung und das Fehlen von Abhängigkeiten nachgewiesen wurden.
  • Retain (Beibehalten): Beibehaltung on-prem aus regulatorischen oder Latenzgründen; Integration über eine hybride Lösung.
  • Relocate (Verlagern): Verschiebung von vSphere-Workloads zur Google Cloud VMware Engine; bewahrt Tooling und minimiert Änderungen.

• Tools für die Compute- und Datenbankmigration

  • Migrate to Virtual Machines beschleunigt das Rehosting in Compute Engine unter Beibehaltung von Datenträgern und Netzwerkkonfiguration. Überprüfen Sie die Unterstützung für Gastbetriebssysteme und Kernel-Treiber.
  • Database Migration Service bietet homogene Online-Replikation (z. B. MySQL, PostgreSQL) zu Cloud SQL mit geringer Ausfallzeit. Stellen Sie sicher, dass die Binlog-/Replikationseinstellungen korrekt sind und die Latenz eine Aufholjagd in nahezu Echtzeit unterstützt.
  • Datenbanken passend zum Workload auswählen:
    • Cloud SQL für verwaltete relationale Anforderungen; aktivieren Sie die automatische Speichervergrößerung und überwachen Sie die CPU bei ca. 75 % pro Kern; verfolgen Sie den Replikations-Lag und sharden oder skalieren Sie hoch, wenn Schwellenwerte erreicht werden.
    • Bigtable für die Erfassung von Zeitreihendaten mit geringer Latenz und hohem Durchsatz (z. B. Sensordaten).
    • Spanner für globale Skalierung und starke Konsistenz; verstehen Sie den Kompromiss zwischen Lock-in und Portabilität.
  • Datenverschiebung
    • Storage Transfer Service für laufende oder geplante Übertragungen; parallelisiert und fehlertolerant bei Wiederholungsversuchen.
    • Transfer Appliance für einmalige Massen-Uploads (zehn bis hunderte TB), um Netzwerkzeit und -risiko zu reduzieren.
    • gsutil und parallele Composite-Uploads für kleine bis mittlere Datensätze.

• Online- vs. Offline-Migration

  • Online: Kontinuierliche Replikation mit einer kurzen Umstellungsphase (Cutover). Vorteile: minimale Ausfallzeit; Nachteile: erfordert stabile Latenz und Bandbreite; sorgfältige Vermeidung von „Dual-Writes“.
  • Offline: Snapshot und Massenimport. Vorteile: einfach und vorhersagbar; Nachteile: Ausfallzeit entspricht der Kopierdauer.

• Cutover-Planung, Rollback und Kontrolle der Ausfallzeit

  • DNS-TTLs Tage vor der Umstellung senken, nicht wesentliche Änderungen einfrieren und ein Wartungsfenster planen.
  • Validierungs-Gates ausführen: Schema-Parität, Prüfsummen oder Zeilenzählungen, Anwendungs-Smoke-Tests, Canary-Traffic und Performance-Sonden.
  • Rollback: Rückwärtskompatible Schemaänderungen, Feature-Flags und die Beibehaltung der „Source-of-Truth“-Daten sicherstellen. Irreversible Schreibvorgänge vermeiden, bis die Stabilität nachgewiesen ist.
  • Beispiel für die Erweiterung eines VM-Datenträgers mit minimaler Ausfallzeit:
    • Datenträgergröße in der Konsole oder CLI ändern:

undefined

- Unter Linux ext4:

undefined

• Rolling-Updates für Apps mit minimalen Auswirkungen auf GKE:

undefined

Häufige Fehlerquellen: Paketverlust über Cloud VPN, der die Datenbankreplikation stört (Dedicated Interconnect oder Partner Interconnect verwenden), Divergenz durch „Dual-Writes“ während der Umstellung, fehlende Health Checks, die Rolling-Updates anhalten.

Hybride Identität, Konnektivität und On-Premises-Integration

• Identität

  • Active Directory als „Source of Truth“ beibehalten. Google Cloud Directory Sync für die Synchronisierung von Konten und Gruppen verwenden und SAML SSO für den Benutzerzugriff auf Google Cloud konfigurieren.
  • IAM-Berechtigungen nach dem Prinzip der geringsten Rechte (Least Privilege) über Rollen vergeben, Service Accounts für Workloads verwenden und Workload Identity Federation gegenüber langlebigen Schlüsseln bevorzugen.

• Hybride Konnektivität und Routing

  • Cloud VPN für anfängliche Anforderungen mit geringem Durchsatz und für Tests verwenden; für dauerhafte Bandbreite, geringere Latenz und vorhersagbare Replikationsleistung auf Dedicated Interconnect umsteigen. Redundante VLAN-Anhänge und HA VPN oder duale Interconnects für Ausfallsicherheit bereitstellen.
  • Sicherstellen, dass sich die IP-Bereiche von Google Cloud nicht mit den On-Premises-CIDRs überschneiden, um die End-to-End-Erreichbarkeit zu gewährleisten.

  • Mehrstufigen Zugriff mit Firewall-Regeln und Tags erzwingen. Beispiel, um nur Web→API zu erlauben:

undefined

• Private Service Connect und privaten Google-Zugriff für die Service-zu-Service-Kommunikation ohne öffentlichen Egress verwenden; bei Bedarf mit VPC Service Controls segmentieren.

• Hybrides DNS: Cloud DNS mit Weiterleitung (Forwarding) und eingehenden/ausgehenden Richtlinien verwenden, um sowohl On-Prem- als auch Cloud-Namen aufzulösen.

• On-Premises-Integration und Latenz

  • Zustandsdaten (State) nahe an den Rechenressourcen (Compute) halten oder umgekehrt; wenn die On-Prem-DB die autoritative Quelle bleiben muss, ziehen Sie App Engine flexible oder Compute Engine mit Cloud VPN/Interconnect für den privaten Zugriff in Betracht.
  • Caches und Queues einführen, um synchrone Pfade zu entkoppeln und Latenzschwankungen abzufedern; p95/p99-Latenz messen, nicht nur Durchschnittswerte.

Häufige Fehlerquellen: überlappende CIDRs, die Routen blockieren, unzureichende Redundanz der BGP-Sitzung, Lecks durch öffentliches DNS oder Egress, die private Dienste offenlegen, und unerwartet „geschwätzige“ Protokolle, die unter Verbindungen mit hoher Latenz leiden.

Modernisierung, Betriebsmodell und Optimierung

• Muster zur Modernisierung von Altsystemen

  • Strangler-Fig-Muster: Platzieren Sie eine API-Fassade vor dem Monolithen und leiten Sie Domänen schrittweise an neue Services weiter.
  • Containerisierung: Standardisieren Sie Basis-Images (bevorzugen Sie schlanke Images wie Alpine, falls kompatibel), ordnen Sie Dockerfile-Layer so an, dass die Installation von Abhängigkeiten vor dem Kopieren des Quellcodes zwischengespeichert wird, um die Build-Zeit zu verkürzen, und führen Sie eine CI/CD-Pipeline mit automatisierten Tests in der Staging-Umgebung ein.
  • Verwaltete Daten: Verschieben Sie operative Speicher in verwaltete Datenbanken; wählen Sie pro Domäne: Cloud SQL für transaktionale, Bigtable für Zeitreihen- und Spanner für global konsistente Workloads.

• Validierung von Anwendungskompatibilität, Konsistenz und Leistung

  • Bestätigen Sie die Unterstützung von Betriebssystem und Middleware, Thread- und Verbindungslimits sowie die Semantik des Dateisystems. Validieren Sie die Portabilität von Lizenzen und die Nutzungsmessung.
  • Definieren Sie Anforderungen an die Datenkonsistenz (Read-Your-Write, Monotonic Reads, Eventual vs. Strong). Gleichen Sie diese mit den Zieldatenbanken und Zugriffsmustern ab.
  • Validieren Sie die Leistung mit Lasttests und synthetischen User Journeys; stellen Sie sicher, dass die SLO-Budgets nach der Migration erreichbar sind.

• Observability und Compliance

  • Instrumentieren Sie Anwendungen mit Cloud Logging, Monitoring und Trace, um Latenzzeiten über Microservices hinweg zu lokalisieren.
  • Exportieren Sie Audit-Logs und Änderungen an IAM-Richtlinien nach BigQuery und teilen Sie diese mit Auditoren über Views und IAM für Datasets. Exportieren Sie Langzeitmetriken nach Cloud Storage, um mehrjährige Aufbewahrungsanforderungen zu erfüllen.

• Betriebsmodell und Zuständigkeit (Ownership)

  • Übernehmen Sie SRE-Praktiken: SLOs, Fehlerbudgets, Incident Response und schuldfreie Postmortems. Definieren Sie Service-Ownership, Runbooks und Bereitschaftsdienste (On-Call Rotations).
  • Verwenden Sie IaC (z. B. Terraform), um die Infrastruktur konsistent bereitzustellen. Beachten Sie, dass der Deployment Manager Google-spezifisch ist, die Automatisierung von Multi-Cloud-Ressourcen einschränken kann und vielen Engineers nicht vertraut ist.
  • Automatisieren Sie die Konsistenz von Richtlinien mit Organization Policy, IAM Conditions, Config Sync und Policy Controller (OPA Gatekeeper) über Projekte und Umgebungen hinweg.

• Multi-Cloud-Strategie und Kompromisse beim Lock-in

  • Erhöhen Sie die Portabilität mit Kubernetes, 12-Factor-App-Praktiken, durch OpenAPI definierten Verträgen und Abstraktionen für den Daten-Egress. Wägen Sie Portabilität gegen Betriebsaufwand und Leistung ab; Managed Services reduzieren den Aufwand (Toil), können aber die Wechselkosten erhöhen.

• Kosten- und Leistungsoptimierung; Stilllegung

  • Skalieren Sie zustandslose Compute Engine-Instanzen mit Managed Instance Groups und Autoscaling; wählen Sie Serverless (Cloud Functions oder Cloud Run) für Workloads mit Lastspitzen (bursty) oder MVP-Workloads, die von der Skalierung auf Null profitieren.
  • Passen Sie die Größe von VMs an (Right-Sizing), aktivieren Sie Autoscaling auf GKE, wenden Sie Rabatte für zugesicherte Nutzung an und legen Sie nicht genutzte Artefakte still. Verfolgen Sie die realisierten Vorteile über KPIs (Verfügbarkeit, Latenz, Cost-to-Serve).
  • Legen Sie On-Premises-Systeme nach einer Abkühlphase (Cooling Period) und der Bestätigung von Abhängigkeiten still. Archivieren oder löschen Sie Daten gemäß der Aufbewahrungsrichtlinie und aktualisieren Sie die CMDB.

Praktisches Problemszenario

Acme Weather Networks muss seine Echtzeit-Sensorplattform und eine veraltete J2EE-Admin-Benutzeroberfläche von einem On-Premises-Rechenzentrum zu Google Cloud migrieren. Das System erfasst Daten von 50.000 Sensoren, die 10 Messwerte pro Sekunde senden, und speichert historische Daten von fünf Jahren (75 TB). Es muss während der Umstellung den privaten Zugriff auf das On-Premises-ERP und Active Directory aufrechterhalten, die Ausfallzeit für eine On-Premises-MySQL-Datenbank minimieren und intermittierende Replikationsfehler, die über VPN beobachtet wurden, beseitigen.

1. Eine sichere Landing Zone einrichten

   • Erstellen Sie eine Organisation, Ordner und Prod/Non-Prod-Projekte. Richten Sie eine Shared VPC mit nicht überlappenden IP-Bereichen ein, um die Erreichbarkeit von On-Premises über hybride Konnektivität sicherzustellen. Wenden Sie Organisationsrichtlinien an und richten Sie zentralisierte Exporte von Audit-Logs nach BigQuery mit Least-Privilege-Zugriff ein.
   • Begründung: Routing-Konflikte verhindern und eine grundlegende Governance durchsetzen, bevor Workloads bereitgestellt werden.

2. Hybride Identität implementieren

   • Konfigurieren Sie Google Cloud Directory Sync, um AD-Identitäten und -Gruppen zu spiegeln, und richten Sie SAML SSO ein. Verwenden Sie Service Accounts und benutzerdefinierte IAM-Rollen für die Plattform und die Workloads.
   • Begründung: Behält die Unternehmensidentität als “Source of Truth” bei und ermöglicht eine Zugriffskontrolle nach dem Least-Privilege-Prinzip.

3. Konnektivität bereitstellen und Leistung planen

   • Beginnen Sie mit HA Cloud VPN für Dev/Test. Für die Replikation der Produktionsdatenbank und die stabile Sensor-Datenerfassung stellen Sie Dedicated Interconnect mit dualen VLAN-Anhängen und BGP-Sitzungen bereit.
   • Begründung: Interconnect bietet eine geringere Latenz und weniger Paketverluste als VPN, was die MySQL-Replikation und die Streaming-Datenerfassung stabilisiert.

4. Historische Daten effizient verschieben

   • Bestellen Sie Transfer Appliances, laden Sie das 75-TB-Dataset on-prem, versenden Sie es und rehydrieren Sie es in Cloud Storage. Verwenden Sie den Storage Transfer Service für laufende inkrementelle Updates bei Bedarf. Führen Sie Cloud DLP auf Support-Logs aus, um PII vor der Speicherung in Bigtable oder BigQuery zu de-identifizieren.
   • Begründung: Der Offline-Massentransfer reduziert das Risiko des Cutover-Fensters und vermeidet die Sättigung der Leitungen.

5. Rehosting der J2EE-Admin-Benutzeroberfläche

   • Verwenden Sie Migrate to Virtual Machines, um die J2EE-VM per Lift-and-Shift auf die Compute Engine zu verschieben. Platzieren Sie die Instanzen in einer Managed Instance Group hinter einem HTTP(S) Load Balancer. Wenden Sie Firewall-Regeln nach Tags an, um ausschließlich Web→API→DB-Datenflüsse zu erzwingen. Beispiel:

undefined

• Begründung: Schnelle Risikominderung mit einer vertrauten Laufzeitumgebung bei gleichzeitiger Durchsetzung von Netzwerkpfaden nach dem Least-Privilege-Prinzip.

6. Migration von MySQL zu Cloud SQL mit minimaler Ausfallzeit

   • Erfassen Sie eine Leistungs-Baseline und aktivieren Sie das Binary Logging auf der Quelle. Verwenden Sie den Database Migration Service, um eine kontinuierliche Replikation nach Cloud SQL einzurichten. Aktivieren Sie die automatische Speichervergrößerung und erstellen Sie Benachrichtigungen für eine CPU-Auslastung nahe 75 % und einen Replikations-Lag von unter 60 Sekunden.
   • Begründung: Die Online-Migration erreicht eine geringe Ausfallzeit; verwaltetes SQL reduziert den Aufwand (Toil) und setzt operative SLOs durch.

7. Kontrollierten Cutover durchführen

   • Senken Sie die DNS-TTLs 48 Stunden im Voraus, frieren Sie Schemaänderungen ein und planen Sie ein Wartungsfenster. Stoppen Sie Schreibvorgänge on-prem, stellen Sie sicher, dass der DMS-Lag null ist, führen Sie Prüfsummen und Anwendungs-Smoke-Tests durch und leiten Sie dann die Clients auf Cloud SQL um. Halten Sie einen Rollback-Plan bereit, bei dem Schreibvorgänge bei fehlgeschlagener Validierung wieder auf die On-Premises-Umgebung umgeleitet werden können.
   • Begründung: Deterministische Schritte begrenzen die RTO und erhalten die Datenkonsistenz.

8. Datenerfassung für Echtzeit-Telemetrie aufbauen

   • Erfassen Sie Daten über Pub/Sub, verarbeiten Sie sie mit Dataflow und speichern Sie Zeitreihen in Bigtable für Schreib- und Lesevorgänge mit geringer Latenz. Halten Sie die ERP-Integration über Interconnect privat.
   • Begründung: Bigtable passt zum Zeitreihenprofil mit hohem Durchsatz, und Pub/Sub entkoppelt Produzenten mit Lastspitzen von den Konsumenten.

9. Services containerisieren und CI/CD einführen

   • Containerisieren Sie zustandslose Services für GKE. Optimieren Sie Dockerfiles durch die Verwendung schlanker Basis-Images und die Anordnung der Layer, sodass die Installation von Abhängigkeiten vor dem Kopieren des Quellcodes erfolgt. Implementieren Sie eine CI/CD-Pipeline mit automatisierten Tests in der Staging-Umgebung und Canary-Rollouts. Aktualisieren Sie mit minimaler Ausfallzeit:

undefined

• Begründung: Verbessert die Geschwindigkeit, Zuverlässigkeit und Skalierbarkeit von Deployments ohne eine komplette Neuentwicklung (Big-Bang Rewrite).

10. Observability und Audit verbessern

    • Instrumentieren Sie Cloud Logging, Monitoring und Trace, um Latenzzeiten über Microservices hinweg genau zu lokalisieren. Exportieren Sie Audit-Logs nach BigQuery und teilen Sie auf Auditoren zugeschnittene Ansichten. Exportieren Sie Langzeitmetriken nach Cloud Storage, um die fünfjährige Aufbewahrungsfrist zu erfüllen.
    • Begründung: Vollständige Telemetrie unterstützt SLOs und Compliance.

11. Optimieren und stilllegen

    • Aktivieren Sie Autoscaling auf MIGs und GKE, passen Sie die Instanzgrößen an (Right-Sizing), wenden Sie Rabatte für zugesicherte Nutzung an und planen Sie Nicht-24x7-Workloads auf Serverless (z. B. Cloud Functions für Hilfsaufgaben), um auf null zu skalieren. Nach Erreichen der Stabilität und einer Abkühlphase (Cooling Period) legen Sie die On-Premises-Systeme still, aktualisieren die CMDB und veröffentlichen die realisierten Vorteile.
    • Begründung: Kosten- und Betriebseffizienzen realisieren und gleichzeitig die Kosten für den Parallelbetrieb eliminieren.

12. In den Betrieb überführen und schulen

    • Finalisieren Sie Runbooks, RACI, Bereitschaftsdienste (On-Call Rotations) und SLO/Fehlerbudgets. Stellen Sie gezielte Schulungs- und Zertifizierungspläne bereit, um Qualifikationslücken zu schließen. Bevorzugen Sie Terraform für IaC; beachten Sie, dass der Deployment Manager Google-spezifisch ist und möglicherweise keine Nicht-Google-Ressourcen adressieren kann.
    • Begründung: Ein ausgereiftes Betriebsmodell sichert Zuverlässigkeit und Geschwindigkeit über das Migrationsereignis hinaus.

← Zuverlässigkeit · Alle Domänen · Betrieb →

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

Google durchsuchen →