Hybrid- und Multi-Cloud-Architekturmuster

Last reviewed 2024-11-27 UTC

Diese Seite enthält eine einseitige Ansicht aller Seiten in Hybrid- und Multi-Cloud-Architekturen mit Google Clouderstellen. Sie können diese Seite drucken oder im PDF-Format speichern. Dazu nutzen Sie die Druckfunktion Ihres Browsers und wählen die Option Als PDF speichern aus. Auf dieser Seite finden Sie rechts keinen Inhaltsverzeichnisbereich.

Dieses Dokument ist das zweite von drei Dokumenten in einer Reihe. Es werden gängige Hybrid- und Multi-Cloud-Architekturmuster erläutert. Außerdem werden die Szenarien beschrieben, für die diese Muster am besten geeignet sind. Außerdem werden Best Practices für die Bereitstellung solcher Architekturen in Google Cloudbeschrieben.

Der Dokumentensatz für Hybrid- und Multi-Cloud-Architekturmuster besteht aus den folgenden Teilen:

• Hybrid- und Multi-Cloud-Architekturen erstellen: Hier erfahren Sie, wie Sie eine Strategie für die Entwicklung einer Hybrid- und Multi-Cloud-Einrichtung mit Google Cloudplanen.
• Hybrid- und Multi-Cloud-Architekturmuster: Hier werden gängige Architekturmuster beschrieben, die im Rahmen einer Hybrid- und Multi-Cloud-Strategie übernommen werden können (dieses Dokument).
• Architekturmuster für Hybrid- und Multi-Cloud-Netzwerke: Hier werden Architekturmuster für Hybrid- und Multi-Cloud-Netzwerke aus Netzwerkperspektive besprochen.

Da das Spektrum an Anwendungsarbeitslasten in jedem Unternehmen anders ist, gelten auch für die Architektur einer Hybrid- oder Multi-Cloud-Konfiguration spezielle Anforderungen und Einschränkungen. Sie müssen Ihr Architekturdesign zwar auf diese Einschränkungen und Anforderungen zuschneiden, können aber auf verschiedenen gängigen Mustern aufbauen, um die grundlegende Architektur zu definieren.

Ein Architekturmuster ist eine wiederholbare Methode, um mehrere funktionale Komponenten einer Technologielösung, Anwendung oder eines Dienstes zu strukturieren, um eine wiederverwendbare Lösung zu erstellen, die bestimmte Anforderungen oder Anwendungsfälle erfüllt. Eine cloudbasierte Technologielösung besteht oft aus mehreren verschiedenen und verteilten Cloud-Diensten. Diese Dienste arbeiten zusammen, um die erforderlichen Funktionen bereitzustellen. In diesem Zusammenhang gilt jeder Dienst als funktionale Komponente der Technologielösung. Ebenso kann eine Anwendung aus mehreren funktionalen Ebenen, Modulen oder Diensten bestehen, von denen jede eine funktionale Komponente der Anwendungsarchitektur darstellen kann. Eine solche Architektur kann standardisiert werden, um bestimmte Geschäftsanwendungsfälle zu erfüllen, und als grundlegendes, wiederverwendbares Muster dienen.

Um ein Architekturmuster für eine Anwendung oder Lösung allgemein zu definieren, müssen Sie Folgendes ermitteln und definieren:

• Die Komponenten der Lösung oder Anwendung.
• Die erwarteten Funktionen für jede Komponente, z. B. Frontend-Funktionen für eine grafische Benutzeroberfläche oder Backend-Funktionen für den Datenzugriff.
• Wie die Komponenten miteinander und mit externen Systemen oder Nutzern kommunizieren. In modernen Anwendungen interagieren diese Komponenten über klar definierte Schnittstellen oder APIs. Es gibt eine Vielzahl von Kommunikationsmodellen, z. B. asynchrone und synchrone, Anfrage-Antwort- oder warteschlangenbasierte Modelle.

Die folgenden beiden Hauptkategorien von Hybrid- und Multi-Cloud-Architekturmustern:

• Muster für verteilte Architekturen: Diese Muster beruhen auf einer verteilten Bereitstellung von Arbeitslasten oder Anwendungskomponenten. Das bedeutet, dass sie eine Anwendung (oder bestimmte Komponenten dieser Anwendung) in der Rechenumgebung ausführen, die dem Muster am besten entspricht. So können die verschiedenen Eigenschaften und Merkmale verteilter und vernetzter Computing-Umgebungen optimal genutzt werden.
• Redundante Architekturmuster: Diese Muster basieren auf redundanten Bereitstellungen von Arbeitslasten. Bei diesen Mustern werden dieselben Anwendungen und ihre Komponenten in mehreren Rechenumgebungen bereitgestellt. Ziel ist es, entweder die Leistungskapazität oder die Ausfallsicherheit einer Anwendung zu erhöhen oder eine vorhandene Umgebung für Entwicklung und Tests zu replizieren.

Wenn Sie das ausgewählte Architekturmuster implementieren, müssen Sie einen geeigneten Deployment-Archetyp verwenden. Bereitstellungsarchetypen sind zonal, regional, multiregional oder global. Diese Auswahl bildet die Grundlage für die Erstellung anwendungsspezifischer Bereitstellungsarchitekturen. Jeder Bereitstellungs-Archetyp definiert eine Kombination aus Fehlerbereichen, in denen eine Anwendung ausgeführt werden kann. Diese fehlerhaften Domains können eine oder mehrere Google Cloud -Zonen oder ‑Regionen umfassen und sogar Ihre lokalen Rechenzentren oder fehlerhaften Domains bei anderen Cloud-Anbietern umfassen.

Diese Reihe enthält die folgenden Seiten:

• Muster für verteilte Architekturen

  • Gestaffeltes Hybridmuster

  • Partitioniertes Multi-Cloud-Muster

  • Hybrid- und Multi-Cloud-Muster für Analysen

  • Edge-Hybridmuster

• Muster für redundante Architekturen

  • Umgebungshybridmuster
  • Hybrid- und Multi-Cloud-Muster für Geschäftskontinuität
  • Cloud-Bursting-Muster

Beitragende

Autor: Marwan Al Shawi | Partner Customer Engineer

Weitere Beitragende:

• Saud Albazei | Customer Engineer, Application Modernization
• Anna Berenberg | Engineering Fellow
• Marco Ferrari | Cloud Solutions Architect
• Victor Moreno | Product Manager, Cloud Networking
• Johannes Passing | Cloud Solutions Architect
• Mark Schlagenhauf | Technical Writer, Netzwerk
• Daniel Strebel | EMEA Solution Lead, Application Modernization
• Ammett Williams | Developer Relations Engineer

Muster für verteilte Architekturen

Wenn Sie von einer nicht hybriden oder nicht Multi-Cloud-Rechenumgebung zu einer Hybrid- oder Multi-Cloud-Architektur migrieren, sollten Sie zuerst die Einschränkungen Ihrer vorhandenen Anwendungen berücksichtigen und wie diese Einschränkungen zu Anwendungsausfällen führen können. Dieser Aspekt wird noch wichtiger, wenn Ihre Anwendungen oder Anwendungskomponenten verteilt in verschiedenen Umgebungen ausgeführt werden. Nachdem Sie Ihre Einschränkungen berücksichtigt haben, entwickeln Sie einen Plan, um sie zu vermeiden oder zu überwinden. Berücksichtigen Sie die einzigartigen Funktionen der einzelnen Computing-Umgebungen in einer verteilten Architektur.

Hinweis: Je nach Anwendungsfall und Anforderungen können Sie unterschiedliche Architekturmuster auf verschiedene Anwendungen anwenden. Das bedeutet, dass möglicherweise mehrere Anwendungen mit unterschiedlichen Hybrid- und Multi-Cloud-Architekturmustern gleichzeitig ausgeführt werden.

Designaspekte

Die folgenden Designüberlegungen gelten für verteilte Bereitstellungsmuster. Je nach Ziellösung und Geschäftszielen können die Priorität und die Wirkung der einzelnen Aspekte variieren.

Latenz

Bei jedem Architekturmuster, bei dem Anwendungskomponenten (Frontends, Backends oder Mikrodienste) auf verschiedene Rechenumgebungen verteilt werden, kann es zu Kommunikationslatenzen kommen. Diese Latenz wird von der Hybridnetzwerkkonnektivität (Cloud VPN und Cloud Interconnect) und der geografischen Entfernung zwischen dem lokalen Standort und den Cloud-Regionen oder zwischen den Cloud-Regionen in einer Multi-Cloud-Umgebung beeinflusst. Daher ist es wichtig, die Latenzanforderungen Ihrer Anwendungen und ihre Empfindlichkeit gegenüber Netzwerkverzögerungen zu bewerten. Anwendungen, die Latenz tolerieren können, sind für die anfängliche verteilte Bereitstellung in einer Hybrid- oder Multi-Cloud-Umgebung besser geeignet.

Architektur für den temporären und den Endzustand

Um die Erwartungen und mögliche Auswirkungen auf Kosten, Umfang und Leistung zu spezifizieren, ist es wichtig, in der Planungsphase zu analysieren, welche Art von Architektur Sie benötigen und wie lange sie voraussichtlich dauern wird. Wenn Sie beispielsweise eine Hybrid- oder Multi-Cloud-Architektur für einen langen Zeitraum oder dauerhaft verwenden möchten, sollten Sie Cloud Interconnect in Betracht ziehen. Um die Kosten für die ausgehende Datenübertragung zu senken und die Netzwerkleistung der hybriden Verbindung zu optimieren, werden mit Cloud Interconnect die Kosten für die ausgehende Datenübertragung ermäßigt, die die Bedingungen für die ermäßigte Datenübertragungsrate erfüllen.

Zuverlässigkeit

Zuverlässigkeit ist ein wichtiger Aspekt bei der Architektur von IT-Systemen. Die Betriebsdauer ist ein wesentlicher Aspekt der Systemzuverlässigkeit. In Google Cloudkönnen Sie die Ausfallsicherheit einer Anwendung erhöhen, indem Sie redundante Komponenten dieser Anwendung über mehrere Zonen in einer einzelnen Region¹ oder über mehrere Regionen mit Umschaltfunktionen bereitstellen. Redundanz ist eines der wichtigsten Elemente zur Verbesserung der Gesamtverfügbarkeit einer Anwendung. Bei Anwendungen mit einer verteilten Einrichtung in Hybrid- und Multi-Cloud-Umgebungen ist es wichtig, eine gleichbleibende Verfügbarkeit aufrechtzuerhalten.

Um die Verfügbarkeit eines Systems in einer lokalen Umgebung oder in anderen Cloud-Umgebungen zu verbessern, sollten Sie überlegen, welche Hardware- oder Softwareredundanz – mit Failover-Mechanismen – Sie für Ihre Anwendungen und ihre Komponenten benötigen. Idealerweise sollten Sie die Verfügbarkeit eines Dienstes oder einer Anwendung in allen Umgebungen über die verschiedenen Komponenten und die unterstützende Infrastruktur hinweg berücksichtigen, einschließlich der Verfügbarkeit der Hybridverbindung. Dieses Konzept wird auch als die zusammengesetzte Verfügbarkeit einer Anwendung oder eines Dienstes bezeichnet.

Je nach Abhängigkeiten zwischen den Komponenten oder Diensten kann die kombinierte Verfügbarkeit für eine Anwendung höher oder niedriger sein als für einen einzelnen Dienst oder eine einzelne Komponente. Weitere Informationen finden Sie unter Kompositverfügbarkeit: Gesamtverfügbarkeit der Cloud-Infrastruktur berechnen.

Um die gewünschte Systemzuverlässigkeit zu erreichen, müssen Sie klare Zuverlässigkeitsmesswerte definieren und Anwendungen so entwerfen, dass sie sich selbst heilen und Störungen in den verschiedenen Umgebungen effektiv überstehen können. Informationen dazu, wie Sie geeignete Methoden zur Messung der Nutzerfreundlichkeit Ihrer Dienste definieren, finden Sie unter Zuverlässigkeit anhand von Zielvorhaben für die Nutzerfreundlichkeit definieren.

Hybrid- und Multi-Cloud-Konnektivität

Die Anforderungen an die Kommunikation zwischen den verteilten Anwendungskomponenten sollten bei der Auswahl einer Option für die Hybridnetzwerkverbindung berücksichtigt werden. Jede Konnektivitätsoption hat Vor- und Nachteile sowie spezifische Faktoren, die berücksichtigt werden müssen, z. B. Kosten, Traffic-Volumen, Sicherheit usw. Weitere Informationen finden Sie im Abschnitt Überlegungen zum Design der Konnektivität.

Verwaltung

Einheitliche Verwaltungs- und Überwachungstools sind für erfolgreiche Hybrid- und Multi-Cloud-Umgebungen (mit oder ohne Portabilität von Arbeitslasten) unerlässlich. Kurzfristig können diese Tools Entwicklungs-, Test- und Betriebskosten verursachen. Je mehr Cloud-Anbieter Sie nutzen, desto komplexer wird die Verwaltung Ihrer Umgebungen. Die meisten Anbieter öffentlicher Clouds haben nicht nur unterschiedliche Features, sondern auch unterschiedliche Tools, SLAs und APIs zur Verwaltung von Cloud-Diensten. Wägen Sie daher die strategischen Vorteile der ausgewählten Architektur gegen die potenzielle kurzfristige Komplexität und die langfristigen Vorteile ab.

Kosten

Jeder Cloud-Dienstanbieter in einer Multi-Cloud-Umgebung hat seine eigenen Abrechnungsmesswerte und -tools. Für mehr Transparenz und einheitliche Dashboards können Sie Tools zur Multi-Cloud-Kostenverwaltung und -Optimierung verwenden. Wenn Sie beispielsweise Cloud-first-Lösungen für mehrere Cloud-Umgebungen entwickeln, können die Produkte, Preise, Rabatte und Verwaltungstools der einzelnen Anbieter zu Kosteninkonsistenzen zwischen diesen Umgebungen führen.

Wir empfehlen, eine einzige, klar definierte Methode zur Berechnung der vollständigen Kosten von Cloud-Ressourcen zu verwenden und Transparenz bei den Kosten zu schaffen. Kostentransparenz ist für die Kostenoptimierung unerlässlich. Wenn Sie beispielsweise Abrechnungsdaten der von Ihnen verwendeten Cloud-Anbieter kombinieren und den Looker-Block zur Cloud-Kostenverwaltung in Google Cloudverwenden, können Sie eine zentrale Übersicht Ihrer Multi-Cloud-Kosten erstellen. Diese Ansicht kann Ihnen dabei helfen, eine konsolidierte Berichtsübersicht Ihrer Ausgaben in mehreren Clouds zu erhalten. Weitere Informationen finden Sie unter Die Strategie zur effektiven Optimierung der Kostenverwaltung für die Cloud-Abrechnung.

Wir empfehlen außerdem, FinOps-Praktiken zu verwenden, um Kosten sichtbar zu machen. Im Rahmen einer soliden FinOps-Praxis kann ein zentrales Team die Entscheidungsfindung für die Ressourcenoptimierung an alle anderen an einem Projekt beteiligten Teams delegieren, um die individuelle Verantwortlichkeit zu fördern. Bei diesem Modell sollte das zentrale Team den Prozess, die Berichterstellung und die Tools für die Kostenoptimierung standardisieren. Weitere Informationen zu den verschiedenen Aspekten der Kostenoptimierung und Empfehlungen finden Sie im Google Cloud -Architektur-Framework: Kostenoptimierung.

Datenverschiebung

Die Datenübertragung ist ein wichtiger Aspekt für die Hybrid- und Multi-Cloud-Strategie und -Architekturplanung, insbesondere für verteilte Systeme. Unternehmen müssen ihre verschiedenen geschäftlichen Anwendungsfälle, die zugrunde liegenden Daten und die Klassifizierung der Daten (für regulierte Branchen) identifizieren. Sie sollten auch berücksichtigen, wie sich die Datenspeicherung, ‑freigabe und ‑zugriff für verteilte Systeme in verschiedenen Umgebungen auf die Anwendungsleistung und Datenkonsistenz auswirken können. Diese Faktoren können die Anwendung und die Architektur der Datenpipeline beeinflussen. Mit den umfassenden Datenübertragungsoptionen vonGoogle Cloudkönnen Unternehmen ihre spezifischen Anforderungen erfüllen und hybride und Multi-Cloud-Architekturen nutzen, ohne Kompromisse bei Einfachheit, Effizienz oder Leistung einzugehen.

Sicherheit

Bei der Migration von Anwendungen in die Cloud sollten Sie Cloud-first-Sicherheitsfunktionen wie Konsistenz, Beobachtbarkeit und einheitliche Sicherheitstransparenz berücksichtigen. Jeder Anbieter öffentlicher Clouds hat seinen eigenen Ansatz, seine eigenen Best Practices und seine eigenen Sicherheitsfunktionen. Es ist wichtig, diese Funktionen zu analysieren und anzupassen, um eine standardmäßige, funktionale Sicherheitsarchitektur zu erstellen. Starke IAM-Kontrollen, Datenverschlüsselung, Sicherheitslücken-Scans und die Einhaltung von Branchenvorschriften sind ebenfalls wichtige Aspekte der Cloud-Sicherheit.

Bei der Planung einer Migrationsstrategie empfehlen wir, die oben genannten Aspekte zu analysieren. Sie können dazu beitragen, die Wahrscheinlichkeit zu minimieren, dass die Architektur komplexer wird, wenn die Anzahl Ihrer Anwendungen oder das Trafficvolumen zunimmt. Außerdem ist das Entwerfen und Erstellen einer Landing Zone fast immer eine Voraussetzung für die Bereitstellung von Unternehmens-Arbeitslasten in einer Cloud-Umgebung. Eine Landing Zone hilft Ihrem Unternehmen, Cloud-Dienste sicherer bereitzustellen, zu verwenden und zu skalieren. Sie umfasst mehrere Bereiche und enthält verschiedene Elemente, wie Identitäten, Ressourcenverwaltung, Sicherheit und Netzwerke. Weitere Informationen finden Sie unter Design der Landing-Zone in Google Cloud.

Die folgenden Dokumente in dieser Reihe beschreiben andere Muster für verteilte Architekturen:

• Gestaffeltes Hybridmuster
• Partitioniertes Multi-Cloud-Muster
• Hybrid- und Multi-Cloud-Muster für Analysen
• Edge-Hybridmuster

Gestaffeltes Hybridmuster

Die Architekturkomponenten einer Anwendung können entweder als Frontend oder Backend kategorisiert werden. In einigen Szenarien können diese Komponenten für die Verwendung in verschiedenen Rechenumgebungen gehostet werden. Als Teil des gestaffelten Hybridarchitekturmusters befinden sich die Rechenumgebungen in einer lokalen privaten Rechenumgebung und in Google Cloud.

Frontend-Anwendungskomponenten werden Endnutzern oder Geräten direkt bereitgestellt. Als Ergebnis sind diese Anwendungen oft leistungsempfindlich. Um neue Funktionen und Verbesserungen zu entwickeln, können Softwareupdates häufig sein. Da Frontend-Anwendungen in der Regel Backend-Anwendungen zum Speichern und Verwalten von Daten nutzen – und möglicherweise Geschäftslogik und Nutzereingaben –, sind sie oft zustandslos oder verwalten nur begrenzte Datenmengen.

Erstellen Sie Ihre Front-End-Anwendungen mit verschiedenen Frameworks und Technologien, damit sie zugänglich und brauchbar sind. Einige Schlüsselfaktoren für eine erfolgreiche Frontend-Anwendung sind Anwendungsleistung, Reaktionsgeschwindigkeit und Browserkompatibilität.

Die Komponenten der Back-End-Anwendung sind gewöhnlich auf das Speichern und Verwalten von Daten ausgelegt. Bei einigen Architekturen ist die Geschäftslogik in die Back-End-Komponente eingebunden. Neue Releases von Backend-Anwendungen müssen meist weniger oft vorgenommen werden als für Frontend-Anwendungen. Backend-Anwendungen haben folgende Herausforderungen zu bewältigen:

• Eine große Anzahl von Anfragen verarbeiten
• Große Datenmengen verarbeiten
• Daten sichern
• Aktuelle und aktualisierte Daten in allen Systemreplikaten beibehalten

Die dreistufige Anwendungsarchitektur ist eine der beliebtesten Implementierungen zum Erstellen von geschäftlichen Webanwendungen, wie E-Commerce-Websites mit verschiedenen Anwendungskomponenten. Diese Architektur umfasst die folgenden Ebenen: Jede Ebene arbeitet unabhängig, ist jedoch eng miteinander verknüpft und funktionieren alle zusammen.

• Web-Front-End und Präsentationsstufe
• Anwendungsstufe
• Datenzugriff oder Back-End-Stufe

Durch das Einfügen dieser Schichten in Container werden ihre technischen Anforderungen getrennt, wie z. B. Skalierungsanforderungen und hilft, diese in einem schrittweisen Ansatz zu migrieren. Außerdem können Sie sie auf plattformunabhängigen Cloud-Diensten bereitstellen, die über Umgebungen hinweg portierbar sind, automatisierte Verwaltungsfunktionen nutzen und mit Cloud-verwalteten Plattformen wie Cloud Run oder Google Kubernetes Engine (GKE) Enterprise Edition skalieren. Außerdem helfen Google Cloud-verwaltete Datenbanken wie Cloud SQL dabei, das Backend als Datenbankebene bereitzustellen.

Hinweis: Die Implementierung dieser Architektur und die Definition ihrer Komponenten kann variieren, je nachdem, ob Sie die Ebenen in einzelne Systeme und Schichten aufteilen oder sie kombinieren.

Beim gestaffelten Hybridarchitekturmuster liegt der Schwerpunkt auf der Bereitstellung vorhandener Frontend-Anwendungskomponenten in der öffentlichen Cloud. Bei diesem Muster behalten Sie vorhandene Back-End-Anwendungskomponenten in ihrer privaten Rechenumgebung. Je nach Umfang und spezifischem Design der Anwendung können Sie Frontend-Anwendungskomponenten von Fall zu Fall migrieren. Weitere Informationen finden Sie unter Zu Google Cloud.

Wenn Sie eine vorhandene Anwendung mit Backend- und Frontend-Komponenten haben, die in Ihrer lokalen Umgebung gehostet werden, berücksichtigen Sie die Einschränkungen Ihrer aktuellen Architektur. Wenn Ihre Anwendung beispielsweise skaliert wird und die Anforderungen an ihre Leistung und Zuverlässigkeit steigen, sollten Sie prüfen, ob Teile Ihrer Anwendung refaktoriert oder auf eine andere, optimalere Architektur umgestellt werden sollten. Mit dem gestaffelten hybriden Architekturmuster können Sie einige Anwendungslasten und Komponenten in die Cloud verlagern, bevor Sie komplett wechseln. Sie müssen auch die Kosten, Zeit und das Risiko berücksichtigen, die mit einer solchen Migration einhergehen.

Das folgende Diagramm zeigt ein typisches gestaffeltes Hybrid-Architekturmuster.

Im obigen Diagramm werden Clientanfragen an das Frontend der Anwendung gesendet, das in Google Cloudgehostet wird. Das Frontend der Anwendung sendet dann Daten zurück in die lokale Umgebung, in der das Anwendungs-Back-End gehostet wird (idealerweise über ein API-Gateway).

Mit dem gestaffelten Hybridarchitekturmuster können Sie dieGoogle Cloud -Infrastruktur und globale Dienste nutzen, wie in der Beispielarchitektur im folgenden Diagramm dargestellt. Das Frontend der Anwendung ist erreichbar über Google Cloud. Es kann auch die Flexibilität des Frontends erhöhen, indem es Autoscaling verwendet, um dynamisch und effizient auf die Skalierungsanforderung zu reagieren, ohne die Infrastruktur überzudimensionieren. Es gibt verschiedene Architekturen, mit denen Sie skalierbare Webanwendungen in Google Clouderstellen und ausführen können. Jede Architektur hat Vor- und Nachteile je nach Anforderungen.

Weitere Informationen findest du im Video Drei Möglichkeiten zum Ausführen skalierbarer Webanwendungen in Google Cloud auf YouTube. Weitere Informationen zu den verschiedenen Möglichkeiten zur Modernisierung Ihrer E-Commerce-Plattform inGoogle Cloudfinden Sie unter So erstellen Sie eine digitale Handelsplattform in Google Cloud.

Im obigen Diagramm wird das Frontend der Anwendung aufGoogle Cloud gehostet, um eine multiregionale und global optimierte User Experience bereitzustellen, die globales Load Balancing, Autoscaling und DDoS-Schutz durch Google Cloud Armor nutzt.

Im Laufe der Zeit kann die Anzahl der Anwendungen, die Sie in der öffentlichen Cloud bereitstellen, so weit ansteigen, dass Sie eine Verlagerung von Backend-Anwendungskomponenten in die öffentliche Cloud in Betracht ziehen. Wenn Sie hohe Zugriffszahlen erwarten, empfiehlt es sich, mit Cloud-verwalteten Diensten den technischen Aufwand für die Verwaltung Ihrer eigenen Infrastruktur zu verringern. Nutzen Sie diese Option, sofern Sie nicht aufgrund von Einschränkungen oder Anforderungen Backend-Anwendungskomponenten vor Ort hosten müssen. Wenn Ihre Back-End-Daten beispielsweise gesetzlichen Vorschriften unterliegen, müssen Sie diese Daten wahrscheinlich lokal aufbewahren. Sofern anwendbar und konform, können Sie jedoch mit Sensitive Data Protection, wie z. B. Techniken zur De-Identifizierung, diese Daten bei Bedarf verschieben.

Beim gestaffelten Hybridarchitekturmuster können Sie in einigen Szenarien auch Google Distributed Cloud verwenden. Mit Distributed Cloud können Sie Google Kubernetes Engine-Cluster auf dedizierter Hardware ausführen, die von Google bereitgestellt und gewartet wird und vom Rechenzentrum von Google Cloud getrennt ist. Um sicherzustellen, dass Distributed Cloud Ihre aktuellen und zukünftigen Anforderungen erfüllt, sollten Sie die Einschränkungen von Distributed Cloud im Vergleich zu einer herkömmlichen cloudbasierten GKE-Zone kennen.

Vorteile

Der primäre Fokus auf Frontend-Anwendungen bietet unter anderem folgende Vorteile:

• Front-End-Komponenten sind von Back-End-Ressourcen und gelegentlich von anderen Frontend-Komponenten abhängig.
• Backend-Komponenten hängen nicht von Frontend-Komponenten ab. Daher ist das Isolieren und Migrieren von Frontend-Anwendungen in der Regel weniger kompliziert als das Migrieren von Backend-Anwendungen.
• Da Frontend-Anwendungen häufig zustandslos sind oder selbst keine Daten verwalten, ist deren Migration tendenziell einfacher als Back-Ends.
  • Frontend-Komponenten können im Rahmen der Migration auf eine zustandslose Architektur optimiert werden. Weitere Informationen findest du unter Zustandsorientierte Webanwendungen zu Cloud Run portieren auf YouTube.

Die Bereitstellung vorhandener oder neu entwickelter Frontend-Anwendungen in der öffentlichen Cloud bietet einige Vorteile:

• Viele Frontend-Anwendungen müssen oft geändert werden. Die Ausführung dieser Anwendungen in der öffentlichen Cloud vereinfacht das Einrichten eines Prozesses für die kontinuierliche Integration und Bereitstellung (Continuous Integration/Continuous Delivery, CI/CD). Mit CI/CD können Sie effiziente und automatisierte Aktualisierungen senden. Weitere Informationen finden Sie unter CI/CD in Google Cloud.
• Leistungsempfindliche Frontends mit wechselndem Traffic können erheblich vom Load Balancing, multiregionalen Bereitstellungen, Cloud CDN Caching, Serverless und automatischen Skalierungsfunktionen profitieren, die eine cloudbasierte Bereitstellung (idealerweise mit zustandsloser Architektur) ermöglicht.

• Bei der Einführung von Mikrodiensten mit Containern über eine cloudverwaltete Plattform wie GKE können Sie moderne Architekturen wie microfrontend verwenden, die Mikrodienste auf die Frontend-Komponenten ausweiten.

  Das Erweitern von Mikrodiensten wird häufig mit Front-Ends verwendet, bei denen mehrere Teams an derselben Anwendung zusammenarbeiten. Diese Art von Teamstruktur erfordert einen iterativen Ansatz und kontinuierliche Wartung. Das Verwenden von Mikro-Front-Ends bietet unter anderem folgende Vorteile:

  • Sie können unabhängige Mikrodienstmodule für Entwicklung, Tests und Bereitstellung sein.
  • Es bietet eine Trennung, in der die einzelnen Entwicklungsteams Technologien und Code auswählen können.
  • Es kann schnelle Entwicklungs- und Bereitstellungszyklen ermöglichen, ohne die übrigen Frontend-Komponenten zu beeinträchtigen, die möglicherweise von anderen Teams verwaltet werden.

• Ob es um die Implementierung von Benutzeroberflächen oder APIs geht oder um die Erfassung von Daten aus dem Internet der Dinge (IoT), Frontend-Anwendungen können von den Möglichkeiten von Cloud-Diensten wie Firebase Pub/Sub Apigee Cloud CDN App Engine oder Cloud Run profitiern.

• In der Cloud verwaltete API-Proxyshelfen bei:

  • Entkoppeln Sie die App-seitige API von Ihren Back-End-Diensten, z. B. Mikrodienste.
  • Apps vor Änderungen am Backend-Code schützen.
  • Sie unterstützen Ihre vorhandenen API-gestützten Frontend-Architekturen wie Backend für Frontend (BFF), Mikro-Frontend und andere.
  • Sie können Ihre APIs in Google Cloud oder in anderen Umgebungen verfügbar machen, indem Sie API-Proxys in Apigee implementieren.

Sie können das gestaffelte Hybridmuster auch umgekehrt anwenden. Dazu stellen Sie Backends in der Cloud, während Frontends in privaten Rechenumgebungen bleiben. Obwohl dieser Ansatz weniger gebräuchlich ist, eignet sich dieser Ansatz am besten für ein komplexes und monolithisches Frontend. In solchen Fällen kann es einfacher sein, die Back-End-Funktionalität iterativ zu extrahieren und diese neuen Back-Ends in der Cloud bereitzustellen.

Im dritten Teil dieser Serie werden mögliche Netzwerkmuster für diese Architektur erörtert. Apigee Hybrid kann als Plattform zum Erstellen und Verwalten von API-Proxys in einem hybriden Bereitstellungsmodell verwendet werden. Weitere Informationen finden Sie unter Lose gekoppelte Architektur: einschließlich mehrstufiger monolithischer Architektur und Mikrodienstarchitekturen.

Best Practices

Verwenden Sie die Informationen in diesem Abschnitt, wenn Sie Ihre mehrstufige Hybridarchitektur planen.

Best Practices zur Vereinfachung der Abläufe

Berücksichtigen Sie beim Anwenden des Architekturmusters gestaffelter Hybrid die folgenden Best Practices, um die allgemeine Bereitstellung und operative Komplexität zu reduzieren:

• Basierend auf der Bewertung der Kommunikationsmodelle der identifizierten Anwendungen, wählen Sie die effizienteste und effektivste Kommunikationslösung für diese Anwendungen.

Da für die meisten Nutzerinteraktionen Systeme verwendet werden, die über mehrere Rechenumgebungen verbunden sind, ist eine schnelle Verbindung mit niedriger Latenz zwischen diesen Systemen sehr wichtig. Um die Erwartungen an Verfügbarkeit und Leistung zu erfüllen, sollten eine hohe Verfügbarkeit, geringe Latenzzeiten und ein angemessener Durchsatz gewährleistet sein. Aus Sicherheitsgründen muss die Kommunikation detailliert und kontrolliert werden. Idealerweise sollten Sie Anwendungskomponenten mit sicheren APIs bereitstellen. Weitere Informationen finden Sie unter Gated ausgehender Traffic.

• Um die Kommunikationslatenz zwischen den Umgebungen zu minimieren, wählen Sie eine Google Cloud -Region aus, die geografisch in der Nähe der privaten Rechenumgebung liegt, in der Ihre Anwendungs-Backend-Komponenten gehostet werden. Weitere Informationen finden Sie unter Best Practices für die Auswahl der Region in Compute Engine.
• Minimieren Sie großen Abhängigkeiten zwischen Systemen, die in verschiedenen Umgebungen ausgeführt werden, insbesondere wenn die Kommunikation synchron erfolgt. Diese Abhängigkeiten können die Leistung verlangsamen, die Gesamtverfügbarkeit verringern und zusätzliche Gebühren für die ausgehende Datenübertragung anfallen.
• Beim gestaffelten hybriden Architekturmuster haben Sie möglicherweise ein größeres Volumen an eingehendem Traffic aus lokalen Umgebungen, der in dieGoogle Cloud gelangt, als an ausgehendem Traffic, der die Google Cloudverlässt. Trotzdem sollten Sie das erwartete Volumen der ausgehenden Datenübertragung kennen, das Google Cloudverlässt. Wenn Sie diese Architektur langfristig mit hohem ausgehenden Datenübertragungsvolumen verwenden möchten, sollten Sie Cloud Interconnect in Betracht ziehen. Mit Cloud Interconnect können Sie die Verbindungsleistung optimieren und die Kosten für die ausgehende Datenübertragung senken, die bestimmte Bedingungen erfüllen. Weitere Informationen finden Sie unter Cloud Interconnect-Preise.
• Zum Schutz vertraulicher Daten empfehlen wir, alle öffentliche Kommunikation verschlüsseln. Wenn die Verschlüsselung auf der Verbindungsebene erforderlich ist, können Sie VPN-Tunnel, HA VPN over Cloud Interconnect und MACsec für Cloud Interconnect verwenden.

• Um Inkonsistenzen bei Protokollen, APIs und Authentifizierungsmechanismen über verschiedene Back-Ends hinweg zu überwinden, empfehlen wir, sofern zutreffend, ein API-Gateway oder einen Proxy als einheitliche Fassade zu implementieren. Dieses Gateway oder dieser Proxy fungiert als zentraler Kontrollpunkt und führt die folgende Maßnahmen aus:

  • Implementiert zusätzliche Sicherheitsmaßnahmen.
  • Schützt Client-Apps und andere Dienste vor Änderungen am Back-End-Code.
  • Erleichtert Audit-Trails für die Kommunikation zwischen allen umgebungsübergreifenden Anwendungen und deren entkoppelten Komponenten.
  • Fungiert als Zwischenkommunikationsschicht zwischen Legacy- und modernisierten Diensten.
    • Mit Apigee und Apigee Hybrid können Sie Gateways für Unternehmen und Hybridgateways in lokalen Umgebungen, Edge-Umgebungen, anderen Clouds undGoogle Cloud -Umgebungen hosten und verwalten.

• Verwenden Sie für die Einrichtung hybrider Konfigurationen Cloud Load Balancing mit Hybridkonnektivität Das bedeutet, dass Sie die Vorteile von Cloud Load Balancing auf Dienste ausweiten können, die in Ihrer lokalen Rechenumgebung gehostet werden. Dieser Ansatz ermöglicht eine stufenweise Migration von Arbeitslasten zu Google Cloud mit minimaler oder gar keiner Dienstunterbrechung und sorgt für einen reibungslosen Übergang für die verteilten Dienste. Weitere Informationen finden Sie unter Übersicht über Netzwerk-Endpunktgruppen mit Hybridkonnektivität.

• Manchmal ist die gemeinsame Verwendung eines API-Gateways oder eines Proxys und eines Application Load Balancer eine robustere Lösung für die Verwaltung, den Schutz und das Verteilen von API-Traffic in großem Maßstab. Mit Cloud Load Balancing mit API-Gateways können Sie Folgendes erreichen:

  • Stellen Sie mit Apigee und Cloud CDN leistungsstarke APIs bereit, um die Latenz zu verringern, APIs weltweit zu hosten und die Verfügbarkeit zu Spitzenzeiten zu erhöhen. Weitere Informationen findest du unter Leistungsstarke APIs mit Apigee und Cloud CDN auf YouTube.
  • Implementieren Sie die erweiterte Traffic-Verwaltung.
  • Verwenden Sie Google Cloud Armor als DDoS-Schutz und Netzwerksicherheitsdienst zum Schutz Ihrer APIs.
  • Effizientes Load-Balancing über mehrere Gateways hinweg auf mehreren Regionen. Weitere Informationen findest du unter APIs sichern und multiregionalen Failover implementieren mit Private Service Connect und Apigee auf YouTube.

• Verwenden Sie API-Verwaltung und Service Mesh zur Sicherung und Kontrolle von Dienstkommunikation und -sichtbarkeit mit Mikrodienstarchitektur.

  • Verwenden Sie Cloud Service Mesh, um die Dienst zu Dienst-Kommunikation zu ermöglichen, die die Qualität der Dienste in einem System aus verteilten Diensten aufrechterhält, in dem Sie die Authentifizierung, Autorisierung und Verschlüsselung zwischen den Diensten verwalten können.
  • Verwenden Sie eine API-Verwaltungsplattform wie Apigee, mit der Ihre Organisation und externe Entitäten diese Dienste nutzen können, indem Sie sie als APIs bereitstellen.

• Richten Sie eine gemeinsame Identität zwischen Umgebungen ein, damit sich Systeme über Umgebungsgrenzen hinweg sicher authentifizieren können.

• CI/CD- und Konfigurationsverwaltungssysteme in der öffentlichen Cloud bereitstellen Weitere Informationen finden Sie unter Gespiegeltes Netzwerkarchitekturmuster.

• Um die betriebliche Effizienz zu steigern, verwenden Sie einheitliche Tools und CI/CD-Pipelines umgebungsübergreifend

Best Practices für individuelle Arbeitslast- und Anwendungsarchitekturen

• Auch wenn der Fokus bei diesem Muster auf Frontend-Anwendungen liegt, sollten Sie die nötige Modernisierung von Ihren Backend-Anwendungen im Auge behalten. Wenn die Entwicklungsgeschwindigkeit von Back-End-Anwendungen wesentlich langsamer ist als bei Front-End-Anwendungen kann dieser Unterschied zusätzliche Komplexität verursachen.
• Die Behandlung von APIs als Backend-Schnittstellen optimiert Integrationen, Frontend-Entwicklung, Dienstinteraktionen und verbirgt die Komplexität von Backend-Systemen. Um diese Herausforderungen zu meistern, vereinfacht Apigee die Entwicklung und Verwaltung von API-Gateways/Proxys für hybride und Multi-Cloud-Bereitstellungen.
• Wählen Sie den Rendering-Ansatz für Ihre Frontend-Webanwendung basierend auf dem Inhalt (statisch oder Dynamik), die Leistung bei der Suchmaschinenoptimierung und die Erwartungen über die Seitenladegeschwindigkeiten.
• Wenn Sie eine Architektur für inhaltsbasierte Webanwendungen auswählen, stehen verschiedene Optionen zur Verfügung, darunter monolithische, serverlose, ereignisbasierte und Mikrodienstarchitekturen. Um die am besten geeignete Architektur auszuwählen, prüfen Sie diese Optionen gründlich anhand Ihrer aktuellen und zukünftigen Anwendungsanforderungen. Informationen dazu, wie Sie eine Architekturentscheidung treffen, die Ihren geschäftlichen und technischen Zielen entspricht, finden Sie unter Vergleich verschiedener Architekturen für inhaltsorientierte Webanwendungs-Back-Ends und Überlegungen für Web-Backends.

• Mit einer Mikrodienstarchitektur können Sie Containeranwendungen nutzen, mit Kubernetes als gemeinsame Laufzeitebene. Mit dem gestaffelten Hybridarchitekturmuster können Sie es in einem der folgenden Szenarien ausführen:

  • In beiden Umgebungen (Google Cloud und Ihre lokalen Umgebungen)

    • Wenn Sie Container und Kubernetes in verschiedenen Umgebungen verwenden, haben Sie die Flexibilität, Arbeitslasten zu modernisieren und dann zu unterschiedlichen Zeiten zu Google Cloud zu migrieren. Das ist hilfreich, wenn eine Arbeitslast stark von einer anderen abhängt und nicht einzeln migriert werden kann, oder um hybride Arbeitslast-Übertragbarkeit zu nutzen, um die besten in jeder Umgebung verfügbaren Ressourcen zu verwenden. In allen Fällen kann GKE Enterprise eine Schlüsseltechnologie sein. Weitere Informationen finden Sie unter Hybride GKE Enterprise-Umgebung.

  • In einer Google Cloud -Umgebung für die migrierten und modernisierten Anwendungskomponenten.

    • Verwenden Sie diesen Ansatz, wenn Sie lokale Legacy-Back-Ends haben, die keine Containerisierungsunterstützung bieten oder viel Zeit und Ressourcen für die kurzfristige Modernisierung benötigen.

    Weitere Informationen zum Entwerfen und Refaktorieren einer monolithischen Anwendung zu einer Mikrodienstarchitektur zur Modernisierung der Architektur Ihrer Webanwendung finden Sie unter Einführung in Mikrodienste.

• Sie können Datenspeichertechnologien je nach den Anforderungen für Ihre Webanwendungen erstellen. Cloud SQL für strukturierte Daten und Cloud Storage für Mediendateien ist ein gängiger Ansatz für die Erfüllung unterschiedlichen Datenspeicherbedarfs. Die Wahl hängt jedoch stark von Ihrem Anwendungsfall ab. Weitere Informationen zu Datenspeicheroptionen für inhaltsorientierte Anwendungs-Backends und effektive Modalitäten finden Sie unter Datenspeicheroptionen für inhaltsorientierte Webanwendungen Weitere Informationen finden Sie unter Erläuterung der Google Cloud -Datenbankoptionen.

Partitioniertes Multi-Cloud-Muster

Beim Architekturmuster partitionierte Multi-Cloud werden mehrere öffentliche Cloud-Umgebungen kombiniert, die von verschiedenen Cloud-Dienstanbietern betrieben werden. Diese Architektur bietet die Flexibilität, eine Anwendung in einer optimalen Rechenumgebung bereitzustellen, die die im ersten Teil dieser Reihe beschriebenen Multi-Cloud-Antriebskräfte und -Überlegungen berücksichtigt.

Das folgende Diagramm zeigt ein partitioniertes Multi-Cloud-Architekturmuster.

Dieses Architekturmuster kann auf zwei verschiedene Arten aufgebaut werden. Der erste Ansatz basiert auf der Bereitstellung der Anwendungskomponenten in verschiedenen Public-Cloud-Umgebungen. Dieser Ansatz wird auch als zusammengesetzte Architektur bezeichnet und entspricht dem Ansatz des Architekturmusters gestaffeltes Hybrid. Anstatt eine On-Premises-Umgebung mit einer öffentlichen Cloud zu verwenden, werden jedoch mindestens zwei Cloud-Umgebungen verwendet. In einer zusammengesetzten Architektur werden für eine einzelne Arbeitslast oder Anwendung Komponenten aus mehr als einer Cloud verwendet. Beim zweiten Ansatz werden verschiedene Anwendungen in verschiedenen Public-Cloud-Umgebungen bereitgestellt. In der folgenden unvollständigen Liste werden einige der Geschäftstreiber für den zweiten Ansatz beschrieben:

• Vollständige Integration von Anwendungen, die in unterschiedlichen Cloud-Umgebungen gehostet werden, bei einer Fusion oder Übernahme zwischen zwei Unternehmen.
• Sie möchten Flexibilität fördern und den unterschiedlichen Cloud-Präferenzen in Ihrer Organisation gerecht werden. Mit diesem Ansatz können Sie die Organisationseinheiten dazu anregen, den Cloud-Anbieter auszuwählen, der ihren spezifischen Anforderungen und Präferenzen am besten entspricht.
• Für die Nutzung in einer multiregionalen oder globalen Cloud-Bereitstellung. Wenn ein Unternehmen die Bestimmungen zum Datenstandort in bestimmten Regionen oder Ländern einhalten muss, muss es einen der verfügbaren Cloud-Anbieter an diesem Standort auswählen, wenn sein primärer Cloud-Anbieter dort keine Cloud-Region hat.

Mit dem partitionierten Multi-Cloud-Architekturmuster können Sie optional die Möglichkeit beibehalten, Arbeitslasten nach Bedarf von einer öffentlichen Cloud-Umgebung in eine andere zu verschieben. In diesem Fall ist die Portabilität Ihrer Arbeitslasten eine wichtige Anforderung. Wenn Sie Arbeitslasten in mehreren Rechenumgebungen bereitstellen und möchten, dass diese umgebungsübergreifend verschoben werden können, müssen Sie die Unterschiede zwischen den Umgebungen abstrahieren. Mit GKE Enterprise können Sie eine Lösung entwerfen und erstellen, um die Komplexität von Multi-Cloud-Umgebungen mit einheitlichen Governance-, Betriebs- und Sicherheitsstandards zu bewältigen. Weitere Informationen finden Sie unter GKE Multi-Cloud.

Wie bereits erwähnt, kann es sowohl geschäftliche als auch technische Gründe geben, Google Cloud mit einem anderen Cloud-Anbieter zu kombinieren und Arbeitslasten auf diese Cloud-Umgebungen aufzuteilen. Multi-Cloud-Lösungen bieten Ihnen die Flexibilität, Anwendungen in Multi-Cloud-Umgebungen zu migrieren, zu erstellen und zu optimieren, ohne dabei den Anbieter zu minimieren. Außerdem können Sie damit behördliche Anforderungen erfüllen. Sie können beispielsweise Google Cloud mit Oracle Cloud Infrastructure (OCI) verbinden, um eine Multi-Cloud-Lösung zu erstellen, die die Funktionen der einzelnen Plattformen nutzt. Dabei werden Komponenten, die in OCI ausgeführt werden, mit Ressourcen kombiniert, die in Google Cloudausgeführt werden. Weitere Informationen finden Sie unter Google Cloud und Oracle Cloud Infrastructure – Multi-Cloud optimal nutzen. Darüber hinaus ermöglicht Cross-Cloud Interconnect eine dedizierte Verbindung mit hoher Bandbreite zwischen Google Cloud und anderen unterstützten Cloud-Dienstanbietern. So können Sie Multi-Cloud-Lösungen entwerfen und erstellen, um ein hohes Inter-Cloud-Traffic-Volumen zu verarbeiten.

Vorteile

Die Verwendung einer Multi-Cloud-Architektur bietet zwar mehrere geschäftliche und technische Vorteile, wie im Abschnitt Erfolgsfaktoren, Überlegungen, Strategie und Ansätze erläutert, ist es jedoch wichtig, eine detaillierte Machbarkeitsbewertung für jeden potenziellen Vorteil durchzuführen. Bei Ihrer Bewertung sollten Sie alle damit verbundenen direkten oder indirekten Herausforderungen oder potenziellen Hindernisse und Ihre Fähigkeit, diese effektiv zu bewältigen, sorgfältig berücksichtigen. Berücksichtigen Sie auch, dass das langfristige Wachstum Ihrer Anwendungen oder Dienste zu Komplexitäten führen kann, die die anfänglichen Vorteile überwiegen.

Hier einige entscheidende Vorteile des partitionierten Multi-Cloud-Architekturmusters:

• In Szenarien, in denen Sie die Bindung an einen einzelnen Cloud-Anbieter minimieren möchten, können Sie Anwendungen auf mehrere Cloud-Anbieter verteilen. So können Sie die Anbieterbindung relativ reduzieren, da Sie die Möglichkeit haben, die Tarife (bis zu einem gewissen Grad) bei Ihren Cloud-Anbietern zu ändern. Open Cloud trägt dazu bei, Google Cloud -Funktionen wie GKE Enterprise an verschiedenen physischen Standorten bereitzustellen. Durch die Erweiterung der Funktionen von Google Cloud lokal, in mehreren öffentlichen Clouds und an der Edge wird Flexibilität und Agilität geschaffen und die Transformation vorangetrieben.

• Aus regulatorischen Gründen können Sie Anwendungen für einen bestimmten Teil Ihrer Nutzerbasis und Daten aus einem Land zur Verfügung stellen, in dem die Google Cloud keine Cloud-Region hat.

• Das Architekturmuster partitionierte Multi-Cloud kann dazu beitragen, die Latenz zu verringern und die Gesamtqualität der Nutzererfahrung an Standorten zu verbessern, an denen der primäre Cloud-Anbieter keine Cloud-Region oder keinen Point of Presence hat. Dieses Muster ist besonders nützlich, wenn eine Multi-Cloud-Verbindung mit hoher Kapazität und niedriger Latenz verwendet wird, z. B. Cross-Cloud Interconnect und CDN Interconnect mit einem verteilten CDN.

• Sie können Anwendungen über mehrere Cloud-Anbieter bereitstellen, sodass Sie aus den besten Diensten der einzelnen Anbieter auswählen können.

• Das Architekturmuster der partitionierten Multi-Cloud kann Fusions- und Akquisitionsszenarien erleichtern und beschleunigen, bei denen die Anwendungen und Dienste der beiden Unternehmen in verschiedenen Public-Cloud-Umgebungen gehostet werden.

Best Practices

• Beginnen Sie mit der Bereitstellung einer nicht geschäftskritischen Arbeitslast. Diese erste Bereitstellung in der sekundären Cloud kann dann als Muster für zukünftige Bereitstellungen oder Migrationen dienen. Dieser Ansatz ist jedoch wahrscheinlich nicht geeignet, wenn die spezifische Arbeitslast aus rechtlichen oder regulatorischen Gründen in einer bestimmten Cloud-Region gehostet werden muss und der primäre Cloud-Anbieter keine Region im erforderlichen Gebiet hat.
• Minimieren Sie Abhängigkeiten zwischen Systemen, die in verschiedenen öffentlichen Cloudumgebungen ausgeführt werden, insbesondere wenn die Kommunikation synchron erfolgt. Diese Abhängigkeiten können die Leistung verlangsamen, die Gesamtverfügbarkeit verringern und möglicherweise zusätzliche Gebühren für die ausgehende Datenübertragung anfallen.
• Prüfen Sie die Verwendung von Containern und Kubernetes, um die Unterschiede zwischen Umgebungen durch Abstraktion zu überbrücken, sofern dies von den Anwendungen unterstützt und möglich ist.
• Achten Sie darauf, dass CI/CD-Pipelines und Tools für die Bereitstellung und das Monitoring in allen Cloud-Umgebungen konsistent sind.
• Wählen Sie das optimale Netzwerkarchitekturmuster aus, das die effizienteste und effektivste Kommunikationslösung für die von Ihnen verwendeten Anwendungen bietet.
  • Die Kommunikation muss detailliert und kontrolliert werden. Verwenden Sie sichere APIs, um Anwendungskomponenten bereitzustellen.
  • Je nach Ihren spezifischen geschäftlichen und technischen Anforderungen können Sie entweder das geschachtelte Architekturmuster oder eines der gegateten Netzwerkmuster verwenden.
• Um die Erwartungen an Verfügbarkeit und Leistung zu erfüllen, sollten eine hohe End-to-End-Verfügbarkeit (HA), geringe Latenzzeiten und ein angemessener Durchsatz gewährleistet sein.

• Zum Schutz vertraulicher Daten empfehlen wir, alle öffentliche Kommunikation verschlüsseln.

  • Wenn eine Verschlüsselung am Konnektivitätslayer erforderlich ist, stehen je nach ausgewählter Hybridkonnektivitätslösung verschiedene Optionen zur Verfügung. Zu diesen Optionen gehören VPN-Tunnel, HA VPN über Cloud Interconnect und MACsec für Cross-Cloud Interconnect.

• Wenn Sie mehrere CDNs als Teil Ihres Multi-Cloud-Partitionierungsarchitekturmusters verwenden und Ihr anderes CDN mit großen Datendateien aus Google Cloudfüllen, sollten Sie CDN Interconnect-Verbindungen zwischen Google Cloud und unterstützten Anbietern verwenden, um diesen Traffic und möglicherweise die Kosten zu optimieren.

• Erweitern Sie Ihre Lösung zur Identitätsverwaltung zwischen Umgebungen, damit sich Systeme über Umgebungsgrenzen hinweg sicher authentifizieren können.

• Mit Cloud Load Balancing können Sie Anfragen effektiv zwischen Google Cloud und einer anderen Cloud-Plattform ausbalancieren. Weitere Informationen finden Sie unter Traffic an einen lokalen Speicherort oder eine andere Cloud weiterleiten.

  • Wenn das ausgehende Datenübertragungsvolumen von Google Cloudzu anderen Umgebungen hoch ist, sollten Sie Cross-Cloud Interconnect verwenden.

• Um Inkonsistenzen bei Protokollen, APIs und Authentifizierungsmechanismen über verschiedene Back-Ends hinweg zu überwinden, empfehlen wir, sofern zutreffend, ein API-Gateway oder einen Proxy als einheitliche Fassade zu implementieren. Dieses Gateway oder dieser Proxy fungiert als zentraler Kontrollpunkt und führt die folgende Maßnahmen aus:

  • Implementiert zusätzliche Sicherheitsmaßnahmen.
  • Schützt Client-Apps und andere Dienste vor Änderungen am Back-End-Code.
  • Erleichtert Audit-Trails für die Kommunikation zwischen allen umgebungsübergreifenden Anwendungen und deren entkoppelten Komponenten.
  • Fungiert als Zwischenkommunikationsschicht zwischen Legacy- und modernisierten Diensten.
    • Mit Apigee und Apigee Hybrid können Sie Gateways für Unternehmen und Hybridgateways in lokalen Umgebungen, Edge-Umgebungen, anderen Clouds undGoogle Cloud -Umgebungen hosten und verwalten.

• In einigen der folgenden Fälle kann die Verwendung von Cloud Load Balancing mit einem API-Gateway eine robuste und sichere Lösung für die Verwaltung, Sicherheit und Verteilung von API-Traffic in großem Maßstab über mehrere Regionen hinweg bieten:

  • Bereitstellung eines mehrregionalen Failover für Apigee API-Laufzeiten in verschiedenen Regionen.

  • Leistung mit Cloud CDN steigern

  • WAF- und DDoS-Schutz über Google Cloud Armor

• Verwenden Sie nach Möglichkeit einheitliche Tools für das Logging und Monitoring in Cloud-Umgebungen. Sie können Open-Source-Monitoringsysteme verwenden. Weitere Informationen finden Sie unter Hybrid- und Multi-Cloud-Monitoring- und -Logging-Muster.

• Wenn Sie Anwendungskomponenten dezentral bereitstellen, d. h. die Komponenten einer einzelnen Anwendung in mehr als einer Cloud-Umgebung, lesen Sie die Best Practices für das Architekturmuster gestaffelter Hybrid.

Hybrid- und Multi-Cloud-Muster für Analysen

In diesem Dokument wird erläutert, dass das Ziel des Hybrid- und Multi-Cloud-Musters für Analysen darin besteht, die Aufteilung zwischen Transaktions- und Analysearbeitslasten zu nutzen.

In Unternehmenssystemen fallen die meisten Arbeitslasten in folgende Kategorien:

• Transaktionsarbeitslasten umfassen interaktive Anwendungen für den Vertrieb, die Finanzabwicklung, das Enterprise-Resource-Planning (ERP), die Kommunikation usw.
• Zu Analysearbeitslasten gehören Anwendungen, die Daten transformieren, analysieren, optimieren oder visualisieren, um Entscheidungsprozesse zu verbessern.

Analysesysteme erhalten ihre Daten von Transaktionssystemen über API-Abfragen oder Datenbankzugriffe. In den meisten Unternehmen sind Analyse- und Transaktionssysteme in der Regel getrennt und nur lose gekoppelt. Das Ziel des Hybrid- und Multi-Cloud-Musters für Analysen besteht darin, diese vorhandene Trennung auszunutzen und Transaktions- und Analysearbeitslasten in zwei verschiedenen Computing-Umgebungen auszuführen. Dabei werden Rohdaten zuerst aus Arbeitslasten extrahiert, die in der privaten Rechenumgebung ausgeführt werden, und dann zur analytischen Verarbeitung inGoogle Cloudgeladen. Unter Umständen werden einige Ergebnisse dann wieder in Transaktionssysteme eingespeist.

Das folgende Diagramm zeigt konzeptionell mögliche Architekturen anhand potenzieller Datenpipelines. Jeder Pfad/Pfeil steht für eine mögliche Datenübertragungs- und Transformationspipeline, die je nach verfügbarer Datenqualität und dem gewünschten Anwendungsfall auf ETL oder ELT basieren kann.

Wenn Sie Ihre Daten in Google Cloud verschieben und aus ihnen Mehrwert schaffen möchten, verwenden Sie Datenmigrationsdienste – eine umfassende Suite mit Diensten zur Datenaufnahme, ‑integration und ‑replikation.

Wie im vorherigen Diagramm dargestellt, können Sie durch die Verbindung von Google Cloud mit lokalen Umgebungen und anderen Cloud-Umgebungen verschiedene Anwendungsfälle für die Datenanalyse nutzen, z. B. Datenstreaming und Datenbanksicherungen. Für den grundlegenden Transport eines Hybrid- und Multi-Cloud-Analysemusters, das ein hohes Datenübertragungsvolumen erfordert, bieten Cloud Interconnect und Cross-Cloud Interconnect eine dedizierte Konnektivität zu lokalen und anderen Cloud-Anbietern.

Vorteile

Das Ausführen von Analysearbeitslasten in der Cloud bietet mehrere zentrale Vorteile:

• Eingehender Traffic, also die Datenübertragung aus Ihrer privaten Rechenumgebung oder anderen Clouds inGoogle Cloud, ist möglicherweise kostenlos.
• Analysearbeitslasten müssen häufig beträchtliche Datenmengen verarbeiten und können stoßweise auftreten. Daher eignen sie sich besonders für die Bereitstellung in einer öffentlichen Cloud-Umgebung. Durch dynamische Skalierung von Rechenressourcen können Sie große Datasets schnell verarbeiten und gleichzeitig Vorabinvestitionen sowie eine Überdimensionierung von Rechenressourcen vermeiden.
• Google Cloud bietet eine Vielzahl von Diensten zur Verwaltung von Daten über ihren gesamten Lebenszyklus hinweg – von der ersten Erfassung über die Verarbeitung und Analyse bis hin zur endgültigen Visualisierung.
  • Die Datenmigrationsdienste in Google Cloud bieten eine umfassende Suite von Produkten, mit denen sich Daten auf unterschiedliche Weise nahtlos verschieben, integrieren und transformieren lassen.
  • Cloud Storage eignet sich hervorragend zum Erstellen eines Data Lakes.

• MitGoogle Cloud können Sie Ihre Datenplattform modernisieren und optimieren, um Datensilos aufzulösen. Mit einem Data Lakehouse können Sie verschiedene Speicherformate standardisieren. Außerdem bietet es die Flexibilität, Skalierbarkeit und Agilität, die erforderlich sind, damit Ihre Daten einen Mehrwert für Ihr Unternehmen schaffen und nicht zu Ineffizienzen führen. Weitere Informationen finden Sie unter BigLake.

• BigQuery Omni bietet Rechenleistung, die lokal auf dem Speicher in AWS oder Azure ausgeführt wird. Außerdem können Sie damit eigene Daten abfragen, die in Amazon Simple Storage Service (Amazon S3) oder Azure Blob Storage gespeichert sind. Mit dieser Multi-Cloud-Analysefunktion können Datenteams Datensilos aufbrechen. Weitere Informationen zum Abfragen von Daten, die außerhalb von BigQuery gespeichert sind, finden Sie unter Einführung in externe Datenquellen.

Best Practices

Berücksichtigen Sie bei der Implementierung des Hybrid- und Multi-Cloud-Architekturmusters für Analysen die folgenden allgemeinen Best Practices:

• Verwenden Sie das Handover-Netzwerkmuster, um die Datenaufnahme zu ermöglichen. Wenn Analyseergebnisse wieder in Transaktionssysteme übernommen werden müssen, können Sie das Handover-Muster mit dem Muster für gatewaygesteuerten ausgehenden Traffic kombinieren.
• Verwenden Sie Pub/Sub-Warteschlangen oder Cloud Storage-Buckets, um Daten von in Ihrer privaten Rechenumgebung ausgeführten Transaktionssystemen an Google Cloud zu übergeben. Diese Warteschlangen oder Buckets können dann als Quellen für Datenverarbeitungspipelines und Arbeitslasten dienen.
• Je nach Anforderungen Ihres Anwendungsfalls können Sie Cloud Data Fusion oder Dataflow verwenden, um ETL- und ELT-Datenpipelines bereitzustellen. Beide sind vollständig verwaltete Cloud-First-Datenverarbeitungsdienste zum Erstellen und Verwalten von Datenpipelines.
• Wenn Sie Ihre wertvollen Daten-Assets ermitteln, klassifizieren und schützen möchten, sollten Sie die Funktionen zum Schutz sensibler Daten in Google Cloudverwenden, z. B. De-Identifikationstechniken. Mit diesen Verfahren können Sie sensible Daten wie personenidentifizierbare Informationen (PII) mit einem zufällig generierten oder vordefinierten Schlüssel maskieren, verschlüsseln und ersetzen, sofern dies zulässig und konform ist.
• Erwägen Sie, wenn Sie bereits Hadoop- oder Spark-Arbeitslasten haben, die Migration von Jobs zu Dataproc und die Migration vorhandener HDFS-Daten zu Cloud Storage.

• Wählen Sie bei der ersten Datenübertragung von Ihrer privaten Rechenumgebung zu Google Clouddie für Ihre Dataset-Größe und verfügbare Bandbreite am besten geeignete Übertragungsmethode. Weitere Informationen finden Sie unter Migration zu Google Cloud: Große Datasets übertragen.

• Wenn eine langfristige Datenübertragung oder ein Datenaustausch zwischen Google Cloud und anderen Clouds mit hohem Traffic erforderlich ist, sollten Sie die Verwendung von Google Cloud Cross-Cloud Interconnect prüfen. So können Sie eine dedizierte Verbindung mit hoher Bandbreite zwischenGoogle Cloud und anderen Cloud-Dienstanbietern herstellen (verfügbar in bestimmten Standorten).

• Wenn eine Verschlüsselung am Konnektivitätslayer erforderlich ist, stehen je nach ausgewählter Hybridkonnektivitätslösung verschiedene Optionen zur Verfügung. Zu diesen Optionen gehören VPN-Tunnel, HA VPN über Cloud Interconnect und MACsec für Cross-Cloud Interconnect.

• Verwenden Sie konsistente Tools und Prozesse in allen Umgebungen. In einem Hybridszenario für Analysen können Sie damit die operative Effizienz steigern. Dies ist aber nicht zwingend dafür erforderlich.

Edge-Hybridmuster

Für das Ausführen von Arbeitslasten in der Cloud muss Clients in einigen Szenarien eine schnelle und zuverlässige Internetverbindung zur Verfügung stehen. Mit den heutigen Netzwerken stellt diese Anforderung selten ein Problem für die Cloudeinführung dar. Es gibt jedoch Szenarien, in denen eine kontinuierliche Verbindung nicht selbstverständlich ist:

• Seeschiffe und andere Fahrzeuge sind möglicherweise nur zeitweise verbunden oder haben nur Zugang zu Satellitenverbindungen mit hoher Latenz.
• Fabriken oder Kraftwerke könnten zwar mit dem Internet verbunden sein, aber unter Umständen eine Betriebssicherheit erfordern, die die Verfügbarkeitsversprechen ihres Internetanbieters übersteigen.
• Einzelhandelsgeschäfte und Supermärkte sind möglicherweise nur gelegentlich verbunden oder nutzen Verbindungen, die nicht die erforderliche Zuverlässigkeit oder Durchsatzraten für geschäftskritische Transaktionen bieten.

Die Edge-Hybrid-Architektur versucht diese Herausforderungen durch Differenzierung zu bewältigen: Zeit- und geschäftskritische Arbeitslasten werden lokal an den Edge-Punkten des Netzwerks und alle anderen Arten von Arbeitslasten in der Cloud ausgeführt. In einer Edge-Hybrid-Architektur stellt die Internetverbindung keine kritische Komponente dar. Sie wird für Verwaltungszwecke und zum Synchronisieren oder Hochladen von Daten (oft asynchron) verwendet, ist jedoch weder an zeit- noch geschäftskritischen Transaktionen beteiligt. “

Vorteile

Wenn bestimmte Arbeitslasten an den Edge-Punkten und andere in der Cloud ausgeführt werden, ergeben sich mehrere Vorteile:

• Eingehender Traffic, also die Datenübertragung von den Edge-Punkten zuGoogle Cloud, ist möglicherweise kostenlos.
• Das Ausführen von geschäfts- und zeitkritischen Arbeitslasten sorgt für niedrige Latenz und Unabhängigkeit. Wenn die Internetverbindung fehlschlägt oder vorübergehend nicht verfügbar ist, können Sie trotzdem alle wichtigen Transaktionen ausführen. Gleichzeitig profitieren Sie für einen erheblichen Teil Ihrer gesamten Arbeitslast von der Nutzung der Cloud.
• Rechen- und Speichergeräte, in die bereits investiert wurde, können weiterverwendet werden.
• Der Anteil der Arbeitslasten, der an den Edge-Punkten ausgeführt wird, kann mit der Zeit schrittweise reduziert und in die Cloud verschoben werden, entweder durch Überarbeitung bestimmter Anwendungen oder Ausstattung einiger Edge-Standorte mit Internetverbindungen, die zuverlässiger sind.
• IoT-Projekte (Internet of Things) können kosteneffizienter werden, wenn Datenberechnungen lokal ausgeführt werden. Dadurch können Unternehmen einige Dienste lokal am Edge ausführen und verarbeiten, das näher an den Datenquellen liegt. Außerdem können Unternehmen damit selektiv Daten an die Cloud senden und so Kapazität, Datenübertragung, Verarbeitung und Gesamtkosten der IoT-Lösung reduzieren.
• Edge-Computing kann als Zwischenkommunikationsschicht zwischen Legacy- und modernisierten Diensten fungieren. Beispielsweise Dienste, auf denen ein containerisiertes API-Gateway wie Apigee Hybrid ausgeführt wird. So können Legacy-Anwendungen und ‑Systeme in modernisierte Dienste wie IoT-Lösungen eingebunden werden.

Best Practices

Beachten Sie beim Implementieren des Edge-Hybridmusters folgende Architekturempfehlungen:

• Wenn die Kommunikation unidirektional ist, verwenden Sie das Muster für gatewaygesteuerten eingehenden Traffic.
• Wenn die Kommunikation bidirektional ist, sollten Sie das Muster für gatewaygesteuerten ausgehenden und eingehenden Traffic in Betracht ziehen.
• Wenn die Lösung aus vielen Edge-Remote-Standorten besteht, die über das öffentliche Internet mitGoogle Cloud verbunden sind, können Sie eine softwaredefinierte WAN-Lösung (SD-WAN) verwenden. Sie können auch Network Connectivity Center mit einem SD-WAN-Router eines Drittanbieters verwenden, der von einem Google Cloud -Partner unterstützt wird, um die Bereitstellung und Verwaltung sicherer Verbindungen im großen Maßstab zu vereinfachen.
• Minimieren Sie Abhängigkeiten zwischen Systemen, die an Edge-Punkten ausgeführt werden, und Systemen, die in der Cloudumgebung laufen. Abhängigkeiten können die Zuverlässigkeits- und Latenzvorteile einer Edge-Hybrideinrichtung wieder zunichtemachen.
• Um mehrere Edge-Standorte effizient zu verwalten und zu betreiben, sollten Sie eine zentrale Verwaltungsebene und eine Monitoringlösung in der Cloud haben.
• Achten Sie darauf, dass die CI/CD-Pipelines und Tools für das Deployment und Monitoring in allen Cloud- und Edge-Umgebungen einheitlich sind.
• Prüfen Sie die Verwendung von Containern und Kubernetes, sofern möglich, um Unterschiede zwischen verschiedenen Edge-Punkten und auch zwischen Edge-Punkten und der Cloud durch Abstraktion zu überbrücken. Da Kubernetes eine gemeinsame Laufzeitebene bietet, können Sie Arbeitslasten für alle Rechenumgebungen einheitlich entwickeln, ausführen und betreiben. Sie können Arbeitslasten auch zwischen dem Edge und der Cloud verschieben.
  • Zur Vereinfachung der hybriden Einrichtung und des Hybridbetriebs können Sie für diese Architektur GKE Enterprise verwenden, wenn Container in den allen Umgebungen verwendet werden. Berücksichtigen Sie die möglichen Konnektivitätsoptionen, die Sie haben, um einen GKE Enterprise-Cluster, der in Ihrer lokalen oder Edge-Umgebung ausgeführt wird, mit Google Cloudzu verbinden.
• Obwohl einige GKE Enterprise-Komponenten während einer vorübergehenden Verbindungsunterbrechung zuGoogle Cloudmöglicherweise beibehalten werden, verwenden Sie bei diesem Muster GKE Enterprise nicht als Nominalarbeitsmodus, wenn es von Google Cloud getrennt ist. Weitere Informationen finden Sie unter Auswirkungen einer vorübergehenden Trennung von Google Cloud.
• Um Inkonsistenzen in Protokollen, APIs, und Authentifizierungsmechanismen über verschiedene Backend- und Edge-Dienste hinweg zu überwinden, es empfiehlt sich, ggf. ein API-Gateway oder einen Proxy als vereinigende Fassade bereitzustellen. Dieses Gateway oder dieser Proxy fungierr als zentraler Kontrollpunkt und führt die folgende Maßnahmen durch:
  • Implementiert zusätzliche Sicherheitsmaßnahmen.
  • Schützt Client-Apps und andere Dienste vor Änderungen am Back-End-Code.
  • Erleichtert Audit-Trails für die Kommunikation zwischen allen umgebungsübergreifenden Anwendungen und deren entkoppelten Komponenten.
  • Fungiert als Zwischenkommunikationsschicht zwischen Legacy- und modernisierten Diensten.
    • Mit Apigee und Apigee Hybrid können Sie Gateways für Unternehmen und Hybridgateways in lokalen Umgebungen, Edge-Umgebungen, anderen Clouds undGoogle Cloud -Umgebungen hosten und verwalten.
• Richten Sie eine gemeinsame Identität zwischen Umgebungen ein, damit sich Systeme über Umgebungsgrenzen hinweg sicher authentifizieren können.
• Da die zwischen Umgebungen ausgetauschten Daten möglicherweise vertraulich sind, müssen Sie dafür sorgen, dass die gesamte Kommunikation über VPN-Tunnel, TLS oder beides verschlüsselt wird.

Umgebungshybridmuster

Mit dem Umgebungshybrid-Architekturmuster behalten Sie die Produktionsumgebung einer Arbeitslast im vorhandenen Rechenzentrum. Sie verwenden die öffentliche Cloud dann für Ihre Entwicklungs- und Testumgebungen oder andere Umgebungen. Dieses Muster basiert auf der redundanten Bereitstellung derselben Anwendungen in mehreren Rechenumgebungen. Ziel der Bereitstellung ist es, die Kapazität, Agilität und Ausfallsicherheit zu erhöhen.

Wenn Sie die Arbeitslasten festlegen, die migriert werden sollen, stoßen Sie eventuell auf bestimmte Anwendungen, deren Ausführung in der öffentlichen Cloud Probleme mit sich bringt.

• Rechtliche oder behördliche Auflagen können dafür verantwortlich sein, dass Daten in einem bestimmten Land verbleiben müssen.
• Lizenzbestimmungen von Drittanbietern untersagen möglicherweise die Ausführung bestimmter Software in einer Cloudumgebung.
• Eine Anwendung benötigt möglicherweise Zugriff auf Hardwaregeräte, die nur lokal verfügbar sind.

Berücksichtigen Sie in solchen Fällen nicht nur die Produktionsumgebung, sondern alle Umgebungen, die zum Lebenszyklus einer Anwendung gehören, einschließlich Entwicklungs-, Test- und Staging-Systeme. Diese Einschränkungen gelten häufig für Produktionsumgebung und ihre Daten. Sie gelten möglicherweise nicht für andere Umgebungen, in denen die eigentlichen Daten nicht verwendet werden. Wenden Sie sich an die Compliance-Abteilung Ihrer Organisation oder an das entsprechende Team.

Das folgende Diagramm zeigt ein typisches Umgebungshybrid-Architekturmuster.

Das Ausführen von Entwicklungs- und Testsystemen in anderen Umgebungen als die der Produktionssysteme kann riskant erscheinen und von Ihren bestehenden Best Practices oder Ihren Bemühungen abweichen, Unterschiede zwischen Ihren Umgebungen zu minimieren. Solche Bedenken sind zwar berechtigt, können aber ausgeräumt werden, wenn Sie zwischen den Phasen der Entwicklungs- und Testprozesse unterscheiden:

Die Entwicklungs-, Test- und Bereitstellungsprozesse variieren zwar von Anwendung zu Anwendung, setzen sich jedoch mehr oder weniger aus folgenden Phasen zusammen:

• Entwicklung: Releasekandidaten erstellen
• Funktions- oder Nutzerakzeptanztests: Prüfen, ob der Releasekandidat die funktionalen Anforderungen erfüllt.
• Leistungs- und Zuverlässigkeitstests: Prüfen, ob der Releasekandidat die nicht funktionalen Anforderungen erfüllt Dieser Test wird auch als Lasttest bezeichnet.
• Staging- oder Bereitstellungstests: Prüfen, ob das Bereitstellungsverfahren funktioniert.
• Produktion: Freigabe neuer oder aktualisierter Anwendungen.

Da die Ausführung mehrerer dieser Phasen in einer einzigen Umgebung selten praktikabel ist, erfordert jede Phase normalerweise eine oder mehrere dedizierte Umgebungen.

Hinweis: Der Begriff Staging-Umgebung wird oft mit Testumgebung verwechselt.

Der Hauptzweck einer Testumgebung besteht jedoch in der Ausführung von Funktionstests, Der Hauptzweck einer Staging-Umgebung besteht darin, zu testen, ob die Bereitstellungsverfahren Ihrer Anwendung wie vorgesehen funktionieren. Wenn ein Release eine Staging-Umgebung erreicht, sollten die Funktionstests abgeschlossen sein. Staging ist der letzte Schritt, bevor Sie Software in Ihrer Produktionsbereitstellung bereitstellen.

Damit Testergebnisse aussagekräftig und für die Produktionsbereitstellung gelten, müssen alle Umgebungen, die Sie während des gesamten Lebenszyklus einer Anwendung verwenden, folgenden Regeln so weit wie möglich entsprechen:

• Alle Umgebungen sind funktional äquivalent. Das bedeutet, dass Architektur, APIs und Versionen von Betriebssystemen sowie Bibliotheken äquivalent sind und die Systeme sich in allen Umgebungen gleich verhalten. Durch diese Äquivalenz lässt sich vermeiden, dass Anwendungen in einer Umgebung funktionieren, in einer anderen jedoch nicht, oder dass Fehler nicht reproduzierbar sind.
• Umgebungen, die für Leistungs- und Zuverlässigkeitstests, Staging und Produktion verwendet werden, sind funktionsunabhängig äquivalent. Das heißt, diese Umgebungen unterscheiden sich in puncto Leistung, Umfang, Konfiguration, Betrieb und Wartung nicht oder nur unwesentlich. Ansonsten sind Leistungs- und Staging-Tests bedeutungslos.

Im Allgemeinen ist es in Ordnung, wenn sich die für die Entwicklung und Funktionstests verwendeten Umgebungen auf funktionsunabhängiger Ebene von den anderen Umgebungen unterscheiden.

Wie im folgenden Diagramm dargestellt, basieren die Test- und Entwicklungsumgebungen auf Google Cloud. Eine verwaltete Datenbank wie Cloud SQL kann als Option für Entwicklung und Tests in Google Cloudverwendet werden. Entwicklung und Tests können dasselbe Datenbankmodul und dieselbe Version in der lokalen Umgebung verwenden, eine funktional äquivalente Version oder eine neue Version, die nach der Testphase in die Produktionsumgebung eingeführt wird. Da die zugrunde liegende Infrastruktur der beiden Umgebungen nicht identisch ist, ist dieser Ansatz für Leistungslasttests nicht gültig.

Die folgenden Szenarien passen gut zum Umgebungshybridmuster:

• Mit Kubernetes als gemeinsame Laufzeitebene, sofern möglich und sinnvoll, erreichen Sie eine funktionale Äquivalenz in allen Umgebungen. Die Google Kubernetes Engine (GKE) Enterprise-Version kann eine wichtige Technologie für diesen Ansatz sein.
  • Sorgen Sie für die Portabilität von Arbeitslasten und abstrahieren Sie Unterschiede zwischen Rechenumgebungen. Mit einem Zero-Trust-Service Mesh können Sie die erforderliche Kommunikationstrennung zwischen den verschiedenen Umgebungen kontrollieren und aufrechterhalten.
• Sie führen Umgebungen für die Entwicklung und Funktionstests in der öffentlichen Cloud aus. Diese Umgebungen können funktional äquivalent zu den übrigen Umgebungen sein, die sich jedoch in funktionsunabhängigen Aspekten wie der Leistung unterscheiden können. Dieses Konzept wird im vorherigen Diagramm veranschaulicht.
• Sie führen Umgebungen für die Produktion, das Staging sowie Leistungs- (Lasttests) und Zuverlässigkeitstests in der privaten Rechenumgebung aus und sorgen so für eine funktionale und funktionsunabhängige Äquivalenz.

Designaspekte

• Geschäftsanforderungen: Jede Bereitstellungs- und Releasestrategie für Anwendungen hat Vor- und Nachteile. Um sicherzustellen, dass der von Ihnen gewählte Ansatz Ihren spezifischen Anforderungen entspricht, basieren Sie Ihre Auswahl auf eine gründliche Bewertung Ihrer Geschäftsanforderungen und -einschränkungen.
• Umgebungsunterschiede: Als Teil dieses Musters ist das Hauptziel der Verwendung dieser Cloud-Umgebung die Entwicklung und Tests. Der endgültige Status ist das Hosten der getesteten Anwendung in der privaten Umgebung vor Ort (Produktion). Das technische Team muss die Architekturen und Funktionen beider Funktionen kennen und verstehen, um das Entwickeln und Testen einer Funktion zu vermeiden, die in der Cloudumgebung wie erwartet funktionieren kann und in der Produktionsumgebung (lokal) fehlschlägt. Dies umfasst Abhängigkeiten von anderen Anwendungen und der Hardwareinfrastruktur, z. B. Sicherheitssysteme, die Traffic-Prüfungen durchführen.
• Governance: Verwenden Sie ein Genehmigungs- und Governance-Verfahren, um zu steuern, was Ihr Unternehmen in der Cloud entwickeln und welche Daten es für Tests verwenden darf. Dieser Prozess kann Ihrem Unternehmen auch helfen, sicherzustellen, dass in Ihren Entwicklungs- und Testumgebung keine Cloud-Funktionen verwendet werden, die in Ihrer lokalen Produktionsumgebung nicht vorhanden sind.
• Erfolgskriterien: Es muss klare, vordefinierte und messbare Erfolgskriterien für das Testen geben, die mit den Standards für die Qualitätssicherung von Software in Ihrem Unternehmen übereinstimmen. Wenden Sie diese Standards auf jede Anwendung an, die Sie entwickeln und testen.
• Redundanz: Auch wenn Entwicklungs- und Testumgebungen nicht ganz so zuverlässig sein müssen wie die Produktionsumgebung, benötigen sie dennoch redundante Funktionen und die Möglichkeit, verschiedene Fehlerszenarien zu testen. Ihre Anforderungen an ein Fehlerszenario könnten dazu führen, dass Sie Redundanz in Ihre Entwicklungs- und Testumgebung einbauen.

Vorteile

Das Ausführen von Arbeitslasten für die Entwicklung und für Funktionstests in der öffentlichen Cloud bietet mehrere Vorteile:

• Umgebungen lassen sich nach Bedarf automatisch starten und herunterfahren. Sie können beispielsweise eine komplette Umgebung für jede Commit- oder Pull-Anfrage bereitstellen, Tests ausführen und dann die Umgebung wieder abschalten. Dieser Ansatz bietet außerdem folgende Vorteile:
  • Sie können die Kosten senken, indem Sie VM-Instanzen beenden, wenn sie inaktiv sind, oder Umgebungen nur bei Bedarf bereitstellen.
  • Sie können Entwicklung und Tests beschleunigen, indem Sie sitzungsspezifischen Umgebungen für jede Pull-Anfrage starten. Außerdem wird dadurch der Wartungsaufwand reduziert und Inkonsistenzen in der Build-Umgebung werden verringert.
• Wenn Sie diese Umgebungen in der öffentlichen Cloud ausführen, können Sie sich mit der Cloud und den zugehörigen Tools vertraut machen und Erfahrungen damit sammeln. Dies kann für die Migration anderer Arbeitslasten hilfreich sein. Dieser Ansatz ist besonders hilfreich, wenn Sie sich dafür entscheiden, Arbeitslastportabilität mithilfe von Containern und Kubernetes, z. B. mit GKE Enterprise in verschiedenen Umgebungen zu erkunden.

Best Practices

Beachten Sie für die erfolgreiche Implementierung des Hybridarchitekturmusters für die Umgebung die folgenden Empfehlungen:

• Definieren Sie die Kommunikationsanforderungen für Ihre Anwendung, einschließlich das optimale Netzwerk- und Sicherheitsdesign. Verwenden Sie dann das Muster für gespiegeltes Netzwerk, um Ihre Netzwerkarchitektur so zu entwerfen, dass eine direkte Kommunikation zwischen Systemen aus verschiedenen Umgebungen verhindert wird. Wenn eine Kommunikation umgebungsübergreifend erforderlich ist, muss es in einer kontrollierten Art und Weise erfolgen.

• Die von Ihnen gewählte Strategie für die Bereitstellung und das Testen von Anwendungen sollte sich an Ihren Geschäftszielen und -anforderungen orientieren. Das kann das Implementieren von Änderungen ohne Ausfallzeit oder die schrittweise Implementierung von Funktionen in einer bestimmten Umgebung oder Nutzergruppe vor der allgemeinen Veröffentlichung umfassen.

• Sie können Container mit Kubernetes verwenden, um Arbeitslasten portabel zu machen und Unterschiede zwischen Umgebungen zu abstrahieren. Weitere Informationen finden Sie unter Referenzarchitektur der hybriden GKE Enterprise-Umgebung.

• Etablierung einer gemeinsamen Toolchain, die in allen Rechenumgebungen funktioniert, zum Bereitstellen, Konfigurieren und Betreiben von Arbeitslasten. Kubernetes bietet diese Beständigkeit.

• Achten Sie darauf, dass CI/CD-Pipelines in der gesamten Rechenumgebung konsistent sind und dass in diesen Umgebungen genau dieselben Binärdateien, Pakete oder Container bereitgestellt werden.

• Nutzen Sie bei Verwendung von Kubernetes ein CI-System wie Jenkins, um eine Bereitstellungspipeline zu implementieren, die Bereitstellungen auf Clustern ausführt und in allen Umgebungen funktioniert. Weitere Informationen finden Sie unter DevOps-Lösungen in Google Cloud.

• Um die kontinuierliche Bereitstellung sicherer und zuverlässiger Anwendungen zu unterstützen, sollten Sie die Sicherheit als integralen Bestandteil des DevOps-Prozesses (DevSecOps) einbinden. Weitere Informationen finden Sie unter: Mit dem Dev(Sec)Ops Toolkit können Sie Ihre mit dem Internet verbundenen Anwendungen in weniger als einer Stunde bereitstellen und schützen.

• Verwenden Sie für das Logging und Monitoring in Google Cloudund in vorhandenen Cloud-Umgebungen die gleichen Tools. Prüfen Sie den Einsatz von Open-Source-Monitoring und -Systemen. Weitere Informationen finden Sie unter Hybrid- und Multi-Cloud-Monitoring- und -Logging-Muster.

• Wenn Test- und Produktionsarbeitslasten von verschiedenen Teams verwaltet werden, ist die Verwendung verschiedener Tools möglicherweise kein Problem. Wenn Sie jedoch dieselben Tools mit unterschiedlichen Berechtigungen für die Datenansicht verwenden, können Sie den Schulungsaufwand und die Komplexität reduzieren.

• Wählen Sie als Datenbank-, Speicher- und Nachrichtendienste für Funktionstests Produkte aus, für die es in Google Cloudein verwaltetes Äquivalent gibt. Durch die Nutzung verwalteter Dienste verringert sich der administrative Aufwand für die Pflege von Entwicklungs- und Testumgebungen.

• Zum Schutz vertraulicher Daten empfehlen wir, alle Kommunikation während der Übertragung zu verschlüsseln. Wenn eine Verschlüsselung am Konnektivitätslayer erforderlich ist, stehen je nach ausgewählter Hybridkonnektivitätslösung verschiedene Optionen zur Verfügung. Zu diesen Optionen gehören VPN-Tunnel, HA VPN über Cloud Interconnect und MACsec für Cloud Interconnect.

In der folgenden Tabelle sehen Sie, welche Google Cloud -Produkte mit gängigen OSS-Produkten kompatibel sind.

OSS-Produkt	Kompatibel mit dem Produkt Google Cloud
Apache HBase	Bigtable
apache beam	Dataflow
CDAP	Cloud Data Fusion
Apache Hadoop	Dataproc
MySQL, PostgreSQL	Cloud SQL
Redis-Cluster, Redis, Memcached	Memorystore
Network File System (NFS)	Filestore
JMS, Kafka	Pub/Sub
Kubernetes	GKE Enterprise

Hybrid- und Multi-Cloud-Muster für Geschäftskontinuität

Der Hauptgrund für die Berücksichtigung der Geschäftskontinuität für geschäftskritische Systeme besteht darin, Unternehmen dabei zu helfen, widerstandsfähig zu sein und ihren Geschäftsbetrieb während und nach Ausfallereignissen fortzusetzen. Wenn Sie Systeme und Daten über mehrere geografische Regionen hinweg replizieren und Single Points of Failure vermeiden, können Sie das Risiko einer Naturkatastrophe und deren Auswirkung auf die lokale Infrastruktur minimieren. Andere Fehlerszenarien sind schwere Systemausfälle, Cyberangriffe oder sogar Systemkonfigurationsfehler.

Die Optimierung eines Systems, damit es Ausfälle übersteht, ist für die Gewährleistung einer effektiven Geschäftskontinuität unerlässlich. Die Zuverlässigkeit eines Systems kann von mehreren Faktoren beeinflusst werden, darunter Leistung, Ausfallsicherheit, Verfügbarkeit, Sicherheit und Nutzerfreundlichkeit. Weitere Informationen zum Entwerfen und Betreiben zuverlässiger Dienste inGoogle Cloudfinden Sie unter Zuverlässigkeit im Architektur-Framework für Google Cloud und unter Bausteine für die Zuverlässigkeit in Google Cloud.

Dieses Architekturmuster basiert auf einer redundanten Bereitstellung von Anwendungen in mehreren Rechenumgebungen. Bei diesem Muster werden dieselben Anwendungen in mehreren Rechenumgebungen bereitgestellt, um die Zuverlässigkeit zu erhöhen. Die Geschäftskontinuität kann als die Fähigkeit eines Unternehmens definiert werden, seine wichtigsten Geschäftsfunktionen oder ‑dienste nach einem Unterbrechungsereignis auf einem vordefinierten akzeptablen Niveau fortzusetzen.

Die Notfallwiederherstellung (Disaster Recovery, DR) ist ein Teil der Geschäftskontinuität und hat zum Ziel, dass die IT-Systeme, die wichtige Geschäftsfunktionen unterstützen, nach einer Störung so schnell wie möglich wieder betriebsbereit sind. Im Allgemeinen tragen DR-Strategien und -Pläne oft zur Entwicklung einer umfassenderen Strategie zur Aufrechterhaltung der Geschäftskontinuität bei. Aus technologischer Sicht sollten Sie bei der Erstellung von Strategien zur Notfallwiederherstellung in Ihrer Geschäftsauswirkungsanalyse zwei wichtige Messwerte definieren: das Recovery Point Objective (RPO) und das Recovery Time Objective (RTO). Weitere Informationen zur Verwendung von Google Cloud für die Notfallwiederherstellung finden Sie im Leitfaden zur Planung der Notfallwiederherstellung.

Je kleiner die Zielwerte für RPO und RTO sind, desto schneller können Dienste nach einer Unterbrechung mit minimalen Datenverlusten wiederhergestellt werden. Dies ist jedoch mit höheren Kosten verbunden, da redundante Systeme aufgebaut werden müssen. Redundante Systeme, die eine nahezu Echtzeit-Datenreplikation ermöglichen und nach einem Ausfallereignis in der gleichen Skalierung arbeiten, erhöhen Komplexität, Verwaltungsaufwand und Kosten.

Die Entscheidung für eine DR-Strategie oder ein DR-Muster sollte auf einer Analyse der Geschäftsauswirkungen basieren. Beispielsweise können die finanziellen Verluste, die durch eine Ausfallzeit von nur wenigen Minuten für ein Finanzdienstleistungsunternehmen entstehen, die Kosten für die Implementierung eines Notfallwiederherstellungssystems bei weitem übersteigen. Unternehmen in anderen Branchen können jedoch stundenlange Ausfallzeiten verkraften, ohne dass dies erhebliche Auswirkungen auf das Geschäft hat.

Wenn Sie geschäftskritische Systeme in einem Rechenzentrum vor Ort ausführen, können Sie zur Notfallwiederherstellung beispielsweise Standby-Systeme in einem zweiten Rechenzentrum in einer anderen Region unterhalten. Ein kostengünstigerer Ansatz besteht jedoch darin, eine Rechenumgebung in der öffentlichen Cloud für Failover-Zwecke zu verwenden. Dieser Ansatz ist der Haupttreiber des Hybridmusters für Geschäftskontinuität. Die Cloud kann vor allem aus Kostengründen attraktiv sein, da Sie einen Teil Ihrer Notfallwiederherstellungsinfrastruktur deaktivieren können, wenn sie nicht verwendet wird. Um eine kostengünstigere Notfallwiederherstellungslösung zu erhalten, kann ein Unternehmen mit einer Cloud-Lösung die potenzielle Erhöhung der RPO- und RTO-Werte in Kauf nehmen.

Das obige Diagramm veranschaulicht die Verwendung der Cloud als Failover- oder Notfallwiederherstellungsumgebung für eine lokale Umgebung.

Eine weniger gebräuchliche (und selten erforderliche) Variante dieses Musters ist das Multi-Cloud-Muster für Geschäftskontinuität. Bei diesem Muster wird für die Produktionsumgebung ein Cloudanbieter und für die Notfallwiederherstellungs-Umgebung ein anderer Cloudanbieter verwendet. Wenn Sie Arbeitslastkopien über mehrere Cloudanbieter bereitstellen, können Sie die Verfügbarkeit in einem Maß erhöhen, das eine Bereitstellung in mehreren Regionen nicht bieten kann.

Die Bewertung einer Notfallwiederherstellung in mehreren Clouds im Vergleich zur Nutzung eines Cloud-Anbieters mit verschiedenen Regionen erfordert eine gründliche Analyse verschiedener Aspekte, darunter:

• Verwaltung
• Sicherheit
• Gesamte Machbarkeit
• Kosten
  • Die potenziellen Kosten für die ausgehende Datenübertragung von mehr als einem Cloud-Anbieter können bei einer kontinuierlichen Cloud-zu-Cloud-Kommunikation hoch sein.
  • Beim Replizieren von Datenbanken kann es zu einem hohen Traffic kommen.
  • Gesamtbetriebskosten und Kosten für die Verwaltung der cloudübergreifenden Netzwerkinfrastruktur.

Hinweis :Weitere Informationen dazu, wie Sie mit Cross-Cloud Interconnect die Gesamtbetriebskosten senken und die Komplexität reduzieren können, finden Sie unter Cross-Cloud Interconnect: Nahtlose Konnektivität zu allen Ihren Clouds.

Wenn Ihre Daten zur Erfüllung von behördlichen Anforderungen in Ihrem Land bleiben müssen, kann die Verwendung eines zweiten Cloud-Anbieters, der sich ebenfalls in Ihrem Land befindet, als Notfallwiederherstellungslösung eine Option sein. Die Verwendung eines zweiten Cloud-Anbieters setzt voraus, dass es keine Möglichkeit gibt, eine Hybridumgebung mit einer lokalen Umgebung zu erstellen. Damit Sie Ihre Cloud-Lösung nicht neu strukturieren müssen, sollte Ihr zweiter Cloud-Anbieter idealerweise alle erforderlichen Funktionen und Dienste in der Region anbieten.

Designaspekte

• Anforderungen an die Notfallwiederherstellung: Die RPO- und RTO-Ziele, die Ihr Unternehmen erreichen möchte, sollten die Architektur und Planung der Notfallwiederherstellung steuern.
• Lösungsarchitektur: Bei diesem Muster müssen Sie die vorhandenen Funktionen und Fähigkeiten Ihrer lokalen Umgebung replizieren, um Ihre Anforderungen an die Notfallwiederherstellung zu erfüllen. Daher müssen Sie die Machbarkeit und Rentabilität des Rehostings, der Refaktorierung oder der Neuarchitektur Ihrer Anwendungen bewerten, um in der Cloud-Umgebung dieselben (oder optimierteren) Funktionen und Leistungen zu bieten.
• Entwerfen und erstellen: Das Erstellen einer Landing-Zone ist fast immer eine Voraussetzung für die Bereitstellung von Unternehmensarbeitslasten in einer Cloud-Umgebung. Weitere Informationen finden Sie unter Design der Landing-Zone in Google Cloud.

• Wie wird die Notfallwiederherstellung ausgelöst?: Bei der Planung und Durchführung der Notfallwiederherstellung sollten Sie die folgenden Fragen berücksichtigen:

  • Was löst ein Notfallwiederherstellungsszenario aus? Eine Notfallwiederherstellung kann beispielsweise durch den Ausfall bestimmter Funktionen oder Systeme am primären Standort ausgelöst werden.
  • Wie wird das Failover auf die DR-Umgebung ausgelöst? Geht es um einen manuellen Genehmigungsprozess oder kann er automatisiert werden, um ein niedriges RTO-Ziel zu erreichen?
  • Wie sollten die Mechanismen zur Erkennung und Benachrichtigung von Systemausfällen gestaltet sein, damit der Failover gemäß der erwarteten RTO ausgelöst wird?
  • Wie wird der Traffic nach Erkennen des Fehlers an die DR-Umgebung weitergeleitet?

  Prüfen Sie Ihre Antworten auf diese Fragen durch Tests.

• Testen: Testen und bewerten Sie das Failover zur Notfallwiederherstellung gründlich. Achten Sie darauf, dass es Ihre RPO- und RTO-Anforderungen erfüllt. So können Sie bei Bedarf mit mehr Zuversicht die Notfallwiederherstellung auslösen. Führen Sie die Tests jedes Mal wieder durch, wenn eine neue Änderung oder Aktualisierung am Prozess oder an der Technologielösung vorgenommen wird.

• Teamfähigkeiten: Mindestens ein technisches Team muss die Fähigkeiten und das Fachwissen haben, um die Produktionsarbeitslast in der Cloud-Umgebung zu erstellen, zu betreiben und Fehler zu beheben, es sei denn, Ihre Umgebung wird von einem Drittanbieter verwaltet.

Vorteile

Die Nutzung von Google Cloud für die Geschäftskontinuität bietet mehrere Vorteile:

• Da in Google Cloud viele Regionen auf der ganzen Welt zur Auswahl stehen, können Sie damit Daten an einem anderen Standort auf demselben Kontinent sichern oder replizieren. Sie können Daten auch an einem anderen Standort auf einem anderen Kontinent sichern oder replizieren.
• MitGoogle Cloud können Sie Daten in Cloud Storage in einem biregionalen oder multiregionalen Bucket speichern. Die Daten werden redundant in mindestens zwei geografisch getrennten Regionen gespeichert. Daten, die in bi- oder multiregionalen Buckets gespeichert sind, werden über die Standardreplikation an geografischen Orten repliziert.
  • Dual-Region-Buckets bieten Georedundanz, um die Geschäftskontinuität und Notfallwiederherstellungspläne zu unterstützen. Außerdem kann für eine schnellere Replikation mit einem niedrigeren RPO die Turboreplikation für Objekte verwendet werden, die in Dual-Regionen gespeichert sind.
  • Ähnlich wie bei der Replikation in mehreren Regionen wird durch die Speicherung Ihrer Daten innerhalb der geografischen Grenzen der Region eine Redundanz in mehreren Regionen erreicht.
• Bietet eine oder mehrere der folgenden Optionen zur Senkung der Kapital- und Betriebskosten für die Notfallwiederherstellung:
  • Beendete VM-Instanzen verursachen lediglich Speicherkosten und sind wesentlich günstiger als laufende VM-Instanzen. So können Sie die Kosten für die Wartung von Cold-Standby-Systemen minimieren.
  • Mit dem nutzungsbasierten Abrechnungsmodell von Google Cloud zahlen Sie nur für die tatsächlich verwendete Speicher- und Rechenkapazität.
  • Mit Elastizitätsfunktionen wie Autoscaling können Sie Ihre Notfallwiederherstellungsumgebung bei Bedarf automatisch skalieren oder verkleinern.

Das folgende Diagramm zeigt beispielsweise eine Anwendung, die in einer lokalen Umgebung (Produktion) ausgeführt wird und Wiederherstellungskomponenten inGoogle Cloud mit Compute Engine, Cloud SQL und Cloud Load Balancing verwendet. In diesem Szenario wird die Datenbank vorab mit einer VM-basierten Datenbank oder einer von Google Cloud verwalteten Datenbank wie Cloud SQL bereitgestellt, um eine schnellere Wiederherstellung durch kontinuierliche Datenreplizierung zu ermöglichen. Sie können Compute Engine-VMs von vorab erstellten Snapshots starten, um die Kosten bei normalem Betrieb zu senken. Bei dieser Konfiguration muss das DNS nach einem Fehlerereignis auf die externe IP-Adresse von Cloud Load Balancing verweisen.

Damit die Anwendung in der Cloud funktioniert, müssen Sie die Webanwendungs- und Anwendungs-VMs bereitstellen. Je nach angestrebtem RTO-Niveau und den Unternehmensrichtlinien kann der gesamte Prozess zum Aufrufen einer Notfallwiederherstellung, zum Bereitstellen der Arbeitslast in der Cloud und zum Umleiten des Traffics manuell oder automatisch ausgeführt werden.

Um die Bereitstellung der Infrastruktur zu beschleunigen und zu automatisieren, sollten Sie die Infrastruktur als Code verwalten. Mit Cloud Build, einem Dienst für die kontinuierliche Einbindung, können Sie Terraform-Manifeste automatisch auf Ihre Umgebung anwenden. Weitere Informationen finden Sie unter Infrastruktur als Code mit Terraform, Cloud Build und GitOps verwalten.

Best Practices

Beachten Sie bei Verwendung des Musters für die Geschäftskontinuität folgende Best Practices:

• Erstellen Sie einen Notfallwiederherstellungsplan, in dem Ihre Infrastruktur sowie Failover- und Wiederherstellungsverfahren dokumentiert werden.
• Berücksichtigen Sie die folgenden Maßnahmen, die auf Ihrer Analyse der Geschäftsauswirkungen und den ermittelten erforderlichen RPO- und RTO-Zielen basieren:
  • Entscheiden Sie, ob die Sicherung von Daten in Google Cloud ausreichend ist oder ob Sie eine andere Notfallwiederherstellungsstrategie (Cold-, Warm- oder Hot-Standby-Systeme) in Betracht ziehen müssen.
  • Definieren Sie die Dienste und Produkte, die Sie als Bausteine für Ihren Notfallwiederherstellungsplan verwenden können.
  • Definieren Sie die entsprechenden Notfallwiederherstellungsszenarien für Ihre Anwendungen und Daten im Rahmen Ihrer ausgewählten Notfallwiederherstellungsstrategie.
• Verwenden Sie das Handover-Muster, wenn Sie nur Daten sichern. Andernfalls ist das vermaschte Muster eine gute Option, um die Netzwerkarchitektur der vorhandenen Umgebung zu replizieren.
• Minimieren Sie Abhängigkeiten zwischen Systemen, die in verschiedenen Umgebungen ausgeführt werden, insbesondere wenn die Kommunikation synchron erfolgt. Diese Abhängigkeiten können die Leistung beeinträchtigen und die Gesamtverfügbarkeit verringern.

• Vermeiden Sie das Split-Brain-Problem. Wenn Sie Daten bidirektional über Umgebungen hinweg replizieren, werden Sie unter Umständen mit dem sogenannten Split-Brain-Problem konfrontiert. Das Split-Brain-Problem tritt auf, wenn die Kommunikation zwischen zwei Umgebungen, die Daten bidirektional replizieren, unterbrochen wird. Diese Aufteilung kann dazu führen, dass Systeme in beiden Umgebungen annehmen, dass die jeweils andere Umgebung nicht verfügbar ist und dass sie exklusiven Zugriff auf die Daten haben. Das kann zu in Konflikt stehenden Änderungen der Daten führen. Es gibt zwei gängige Möglichkeiten, das Split-Brain-Problem zu vermeiden:

  • Eine dritte Computing-Umgebung verwenden In dieser Umgebung können Systeme vor der Änderung von Daten ein Quorum prüfen.

  • Zulassen, dass in Konflikt stehende Datenänderungen abgeglichen werden, wenn die Verbindung wiederhergestellt ist.

    Bei SQL-Datenbanken können Sie das Split-Brain-Problem vermeiden, indem Sie die ursprüngliche primäre Instanz nicht mehr zugänglich machen, bevor Clients die neue primäre Instanz verwenden. Weitere Informationen finden Sie unter Notfallwiederherstellung von Cloud SQL-Datenbanken.

• Achten Sie darauf, dass CI-/CD-Systeme und Artefakt-Repositories nicht zu einem Single Point of Failure werden. Wenn eine Umgebung nicht verfügbar ist, müssen Sie weiterhin in der Lage sein, neue Releases zur Verfügung zu stellen oder Konfigurationsänderungen zu übernehmen.

• Sorgen Sie bei Verwendung von Standby-Systemen dafür, dass alle Arbeitslasten portierbar sind. Alle Arbeitslasten sollten portabel sein (sofern von den Anwendungen unterstützt und möglich), damit die Systeme in allen Umgebungen einheitlich bleiben. Sie können diesen Ansatz mithilfe von Containern und Kubernetes erreichen. Mit der Google Kubernetes Engine (GKE) Enterprise-Version können Sie die Erstellung und den Betrieb vereinfachen.

• Binden Sie die Bereitstellung von Standby-Systemen in Ihre CI/CD-Pipeline ein. Dies gewährleistet, dass Anwendungsversionen und -konfigurationen in allen Umgebungen konsistent sind.

• Damit DNS-Änderungen schnell weitergegeben werden, konfigurieren Sie Ihr DNS mit einer relativ kurzen Gültigkeitsdauer, damit Sie Nutzer bei einem Notfall auf Standby-Systeme umleiten können.

• Wählen Sie die DNS- und Routingrichtlinie aus, die zu Ihrer Architektur und Ihrem Lösungsverhalten passt. Außerdem können Sie mehrere regionale Load Balancer mit DNS-Routingrichtlinien kombinieren, um globale Load Balancing-Architekturen für verschiedene Anwendungsfälle zu erstellen, einschließlich Hybridkonfigurationen.

• Verwenden Sie mehrere DNS-Anbieter. Wenn Sie mehrere DNS-Anbieter verwenden, haben Sie folgende Möglichkeiten:

  • Verfügbarkeit und Ausfallsicherheit Ihrer Anwendungen und Dienste verbessern

  • Mit einer DNS-Konfiguration mit mehreren Anbietern können Sie die Bereitstellung oder Migration von Hybridanwendungen mit Abhängigkeiten in lokalen und Cloud-Umgebungen vereinfachen.

    Google Cloud bietet eine Open-Source-Lösung auf Basis von octoDNS, mit der Sie eine Umgebung mit mehreren DNS-Anbietern einrichten und betreiben können. Weitere Informationen finden Sie unter Öffentliches DNS mit mehreren Anbietern mit Cloud DNS verwenden.

• Verwenden Sie bei der Verwendung von Standby-Systemen Load Balancer, um ein automatisches Failover einzurichten. Beachten Sie, dass die Hardware des Load Balancers ausfallen kann.

• Verwenden Sie Cloud Load Balancing anstelle von Hardware-Load Balancern, um einige Szenarien zu unterstützen, die bei der Verwendung dieses Architekturmusters auftreten. Interne Clientanfragen oder externe Clientanfragen können basierend auf verschiedenen Messwerten wie der gewichteten Trafficaufteilung an die primäre Umgebung oder die Notfallwiederherstellungsumgebung weitergeleitet werden. Weitere Informationen finden Sie unter Trafficverwaltung für globale externe Application Load Balancer.

• Verwenden Sie Cloud Interconnect oder Cross-Cloud Interconnect, wenn das Volumen der ausgehenden Datenübertragung von Google Cloud in die andere Umgebung hoch ist. Mit Cloud Interconnect können Sie die Verbindungsleistung optimieren und die Kosten für die ausgehende Datenübertragung von Traffic senken, der bestimmte Bedingungen erfüllt. Weitere Informationen finden Sie unter Cloud Interconnect-Preise.

• Sie können die bevorzugte Partnerlösung im Google Cloud Marketplace verwenden, um die Datensicherung, ‑replizierung und andere Aufgaben zu erleichtern, die Ihren Anforderungen entsprechen, einschließlich Ihrer RPO- und RTO-Ziele.

• Testen und bewerten Sie Szenarien für die Notfallwiederherstellung, um zu erfahren, wie schnell die Anwendung im Vergleich zum Zielwert für die RTO nach einem Notfall wiederhergestellt werden kann.

• Verschlüsseln Sie die Kommunikation während der Übertragung. Zum Schutz vertraulicher Daten empfehlen wir, die gesamte Kommunikation während der Übertragung zu verschlüsseln. Wenn eine Verschlüsselung am Konnektivitätslayer erforderlich ist, stehen je nach ausgewählter Hybridkonnektivitätslösung verschiedene Optionen zur Verfügung. Zu diesen Optionen gehören VPN-Tunnel, HA VPN über Cloud Interconnect und MACsec für Cloud Interconnect.

Cloud-Bursting-Muster

Internetanwendungen können extremen Nutzungsschwankungen unterliegen. Obwohl dies auf die meisten Unternehmensanwendungen nicht zutrifft, müssen viele Unternehmen mit einer anderen Art von stoßweiser Arbeitslast zurechtkommen: Batch- oder CI-/CD-Jobs.

Dieses Architekturmuster basiert auf einer redundanten Bereitstellung von Anwendungen in mehreren Rechenumgebungen. Das Ziel besteht darin, die Kapazität, Ausfallsicherheit oder beides zu erhöhen.

Obwohl Sie stoßweise Arbeitslasten in einer rechenzentrumsbasierten Computingumgebung durch Überdimensionierung von Ressourcen verarbeiten können, ist dieser Ansatz nicht unbedingt kosteneffektiv. Wenn Sie Batchjobs über einen längeren Zeitraum ausführen, lässt sich zwar die Auslastung optimieren, allerdings ist das Verzögern von Jobs nicht zielführend, wenn diese zeitkritisch sind.

Die Idee des Cloud-Bursting-Musters besteht darin, die Basislast in einer privaten Rechenumgebung zu belassen und die Cloud bedarfsweise zu nutzen, wenn zusätzliche Kapazität für Bursts benötigt wird.

Wenn die Datenkapazität im vorherigen Diagramm in einer lokalen privaten Umgebung am Limit ist, kann das System zusätzliche Kapazitäten aus einerGoogle Cloud -Umgebung erhalten, wenn nötig.

Die Hauptfaktoren dieses Musters sind Geldeinsparungen und die Reduktion des Zeit- und Arbeitsaufwands, um auf Änderungen der Skalierungsanforderungen zu reagieren. Bei diesem Ansatz zahlen Sie nur für die Ressourcen, die bei der Verarbeitung zusätzlicher Lasten verwendet werden. Dies bedeutet, dass Sie Ihre Infrastruktur nicht überdimensionieren müssen. Stattdessen können Sie die Vorteile von On-Demand-Cloud-Ressourcen nutzen und sie je nach Bedarf skalieren und vordefinierte Kennzahlen nutzen. So kann Ihr Unternehmen Dienstunterbrechungen während der Hauptnachfragezeiten vermeiden.

Eine wichtige Voraussetzung für Cloud Bursting-Szenarien ist die Portabilität von Arbeitslasten. Wenn Sie die Bereitstellung von Arbeitslasten in mehreren Umgebungen zulassen, müssen Sie die Unterschiede zwischen den Umgebungen durch Abstraktion überbrücken. Zum Beispiel können Sie mit Kubernetes Konsistenz auf Arbeitslastebene über unterschiedliche Umgebungen mit unterschiedlichen Infrastrukturen erzielen. Weitere Informationen finden Sie unter Referenzarchitektur der GKE Enterprise-Hybridumgebung.

Designaspekte

Das Cloud-Bursting-Muster kann sowohl auf interaktive Arbeitslasten als auch auf Batcharbeitslasten angewendet werden. Wenn Sie mit interaktiven Arbeitslasten arbeiten, müssen Sie allerdings festlegen, wie Anfragen auf die Umgebungen verteilt werden sollen:

• Sie können eingehende Nutzeranfragen an einen Load Balancer weiterleiten, der im vorhandenen Rechenzentrum ausgeführt wird, und die Anfragen dann vom Load Balancer auf die lokalen Ressourcen und die Cloudressourcen verteilen lassen.

  Bei diesem Ansatz muss der Load Balancer oder ein anderes System, das im vorhandenen Rechenzentrum ausgeführt wird, auch die in der Cloud zugeteilten Ressourcen kontinuierlich verfolgen. Der Load Balancer oder ein anderes System muss auch das automatische Hoch- oder Herunterskalieren von Ressourcen initiieren. Mit diesem Ansatz können Sie alle Cloudressourcen in Zeiten geringer Aktivität außer Betrieb nehmen. Die Implementierung von Mechanismen zur Ressourcenverfolgung kann jedoch die Möglichkeiten Ihrer Load Balancer-Lösungen übersteigen und damit die Gesamtkomplexität erhöhen.

• Anstatt Mechanismen zum Verfolgen von Ressourcen zu implementieren, können Sie Cloud Load Balancing mit einem NEG-Backend (Netzwerk-Endpunktgruppe) mit Hybridkonnektivität verwenden. Sie verwenden diesen Load Balancer, um interne Clientanfragen oder externe Clientanfragen an Backends weiterzuleiten, die sich sowohl lokal als auch inGoogle Cloud befinden und die auf verschiedenen Messwerten wie der gewichteten Trafficaufteilung basieren. Sie können auch Backends basierend auf der Load Balancing-Bereitstellungskapazität für Arbeitslasten in Google Cloudskalieren. Weitere Informationen finden Sie unter Trafficverwaltung für globale externe Application Load Balancer.

  Dieser Ansatz bietet viele zusätzliche Vorteile, z. B. die Nutzung der Vorteile von DDoS-Schutzfunktionen von Google Cloud Armor, WAF und Caching von Inhalten am Cloud-Edge mit Cloud CDN. Allerdings müssen Sie die Größe der Hybrid-Netzwerkkonnektivität an den zusätzlichen Traffic anpassen.

• Wie in Portabilität von Arbeitslasten hervorgehoben könnte eine Anwendung mit nur minimalen Änderungen in eine andere Umgebung portierbar sein, um Arbeitslastkonsistenz zu erreichen. Dies bedeutet jedoch nicht, dass die Anwendung in beiden Umgebungen die gleiche Leistung erreicht. Unterschiede beim zugrunde liegenden Computing, Infrastruktursicherheitsfunktionen oder Netzwerkinfrastruktur samt der Nähe zu abhängigen Diensten bestimmen in der Regel die Leistung. Durch Tests erhalten Sie genauere Einblicke in die Leistung und können die Leistungserwartungen besser nachvollziehen.

• Mit Cloud-Infrastrukturdiensten können Sie eine Umgebung zum Hosten Ihrer Anwendungen ohne Portabilität erstellen. Verwenden Sie die folgenden Ansätze, um Clientanfragen zu verarbeiten, wenn der Traffic zu Spitzennachfragezeiten weitergeleitet wird:

  • Verwenden Sie konsistente Tools, um diese beiden Umgebungen zu überwachen und zu verwalten.
  • Achten Sie darauf, dass die Arbeitslastversionsverwaltung konsistent ist und Ihre Datenquellen auf dem neuesten Stand sind.
  • Möglicherweise müssen Sie eine Automatisierung hinzufügen, um die Cloudumgebung bereitzustellen, und den Traffic umleiten, wenn der Bedarf steigt und die Cloud-Arbeitslast Clientanfragen für die Anwendung akzeptieren soll.

• Wenn Sie in Zeiten geringer Nachfrage alle Google Cloud -Ressourcen herunterfahren möchten, ist die Verwendung von DNS-Routingrichtlinien, die hauptsächlich für das Load Balancing von Traffic dienen, möglicherweise nicht immer optimal. Dies hat hauptsächlich folgende Gründe:

  • Die Initialisierung von Ressourcen kann einige Zeit in Anspruch nehmen, bevor Nutzer sie verwenden können.
  • DNS-Aktualisierungen werden tendenziell langsam über das Internet übertragen.

  Deshalb gilt Folgendes:

  • Nutzer werden möglicherweise an die Cloud-Umgebung weitergeleitet, auch wenn keine Ressourcen zur Verarbeitung ihrer Anfragen verfügbar sind.
  • Nutzer werden möglicherweise weiterhin vorübergehend zur lokalen Umgebung weitergeleitet, während DNS-Updates im Internet übertragen werden.

Mit Cloud DNS können Sie die DNS-Richtlinie und Routingrichtlinie auswählen, die zu Ihrer Lösungsarchitektur und Ihrem Verhalten passen, z. B. DNS-Routingrichtlinien für die Standortbestimmung. Cloud DNS unterstützt auch Systemdiagnosen für den internen Passthrough-Network Load Balancer und den internen Application Load Balancer. In diesem Fall können Sie sie in Ihre Hybrid-DNS-Gesamteinrichtung integrieren, die auf diesem Muster basiert.

In einigen Szenarien können Sie Cloud DNS verwenden, um Clientanfragen mit Systemdiagnosen in Google Cloudzu verteilen, z. B. bei der Verwendung von internen Application Load Balancers oder regionenübergreifenden internen Application Load Balancers. In diesem Szenario prüft Cloud DNS den Gesamtzustand des internen Application Load Balancer, der wiederum den Status der Backend-Instanzen prüft. Weitere Informationen finden Sie unter DNS-Routingrichtlinien und Systemdiagnosen verwalten.

Sie können auch den Cloud DNS-Split-Horizon verwenden. Cloud DNS-Split-Horizon ist ein Ansatz zum Einrichten von DNS-Antworten oder -Einträgen für den spezifischen Standort oder das Netzwerk des DNS-Abfrageursprungs für denselben Domainnamen. Dieser Ansatz wird häufig verwendet, um Anforderungen zu erfüllen, bei denen eine Anwendung so konzipiert ist, dass sie sowohl eine private als auch eine öffentliche Umgebung mit jeweils eigenen Features bietet. Mit diesem Ansatz wird auch die Trafficlast auf die Umgebungen verteilt.

Angesichts dieser Überlegungen eignet sich Cloud Bursting generell besser für Batcharbeitslasten als für interaktive Arbeitslasten.

Vorteile

Das Cloud Bursting-Architekturmuster bietet folgende wichtige Vorteile:

• Cloud Bursting ermöglicht die weitere Nutzung vorgenommener Investitionen in Rechenzentren und private Rechenumgebungen. Diese Nutzung kann unbegrenzt sein oder so lang dauern, bis die vorhandenen Geräte ersetzt werden müssen. An diesem Punkt können Sie dann eine vollständige Verlagerung prüfen.
• Da Sie keine überschüssige Kapazität für Nachfragespitzen bereitstellen müssen, können Sie die Nutzung und Kosteneffizienz Ihrer privaten Rechenumgebungen möglicherweise erhöhen.
• Mit Cloud Bursting können Sie Batchjobs innerhalb eines angemessenen Zeitraums ausführen, ohne dass Rechenressourcen überdimensioniert werden müssen.

Best Practices

Beachten Sie beim Implementieren von Cloud-Bursting folgende Best Practices:

• Damit in der Cloud ausgeführte Arbeitslasten genauso auf Ressourcen zugreifen können wie Arbeitslasten, die in einer lokalen Umgebung ausgeführt werden, nutzen Sie dieMesh-Topologie mit dem Sicherheitszugriffsprinzip der geringsten Berechtigung. Wenn die Gestaltung der Arbeitslast dies zulässt, können Sie nur den Zugriff von der Cloud auf die lokale Rechenumgebung zulassen und nicht umgekehrt.
• Wählen Sie zum Minimieren der Kommunikationslatenz zwischen Umgebungen eine Google Cloud -Region aus, die sich geografisch in der Nähe Ihrer privaten Rechenumgebung befindet. Weitere Informationen finden Sie unter Best Practices für die Auswahl der Region in Compute Engine.
• Verringern Sie die Angriffsfläche für Sicherheitsattacken, wenn Sie Cloud Bursting nur für Batcharbeitslasten verwenden. Halten Sie dafür alle Google Cloud -Ressourcen privat. Lassen Sie keinen direkten Zugriff aus dem Internet auf diese Ressourcen zu, auch wenn Sie externes Load Balancing von Google Cloud verwenden, um den Einstiegspunkt für die Arbeitslast bereitzustellen.

• Wählen Sie die DNS- und Routingrichtlinie aus, die Ihrem Architekturmuster und dem gewünschten Lösungsverhalten entspricht.

  • Im Rahmen dieses Musters können Sie das Design Ihrer DNS-Richtlinien dauerhaft anwenden oder, wenn Sie zu Spitzenbedarfszeiten zusätzliche Kapazität benötigen, mit einer anderen Umgebung.
  • Sie können DNS-Routingrichtlinien für die Standortbestimmung verwenden, um einen globalen DNS-Endpunkt für Ihre regionalen Load Balancer einzurichten. Diese Taktik hat viele Anwendungsfälle für DNS-Routingrichtlinien zur Standortbestimmung, einschließlich bei Hybridanwendungen, die Google Cloud zusammen mit einer lokalen Bereitstellung verwenden, in der sich die Google Cloud -Region befindet.

  • Wenn Sie für dieselben DNS-Abfragen verschiedene Einträge bereitstellen müssen, können Sie das Split-Horizon-DNS verwenden, z. B. bei Abfragen von internen und externen Clients.

    Weitere Informationen finden Sie unter Referenzarchitekturen für Hybrid-DNS

• Damit DNS-Änderungen schnell weitergegeben werden, konfigurieren Sie Ihr DNS mit einer relativ kurzen Gültigkeitsdauer, damit Sie Nutzer auf Standby-Systeme umleiten können, wenn Sie zusätzliche Kapazität mithilfe von Cloud-Umgebungen benötigen.

• Bei Jobs, die nicht sehr zeitkritisch sind und bei denen Daten nicht lokal gespeichert werden, empfiehlt sich die Verwendung von Spot-VM-Instanzen, die wesentlich günstiger sind als normale VM-Instanzen. Bei einem vorzeitigen Beenden des VM-Jobs muss das System den Job jedoch automatisch neu starten können.

• Verwenden Sie gegebenenfalls Container für die Portabilität von Arbeitslasten. Außerdem kann GKE Enterprise eine wichtige Technologie für dieses Design sein. Weitere Informationen finden Sie unter Referenzarchitektur der GKE Enterprise-Hybridumgebung

• Beobachten Sie den Traffic, der von Google Cloud an eine andere Rechenumgebung gesendet wird. Für diesen Traffic gelten die Gebühren für ausgehende Datenübertragung.

• Wenn Sie diese Architektur langfristig mit hohem ausgehenden Datenübertragungsvolumen verwenden möchten, sollten Sie Cloud Interconnect in Betracht ziehen. Mit Cloud Interconnect können Sie die Verbindungsleistung optimieren und die Kosten für die ausgehende Datenübertragung von Traffic senken, der bestimmte Bedingungen erfüllt. Weitere Informationen finden Sie unter Cloud Interconnect-Preise.

• Wenn Cloud Load Balancing verwendet wird, sollten Sie gegebenenfalls die Funktionen zur Optimierung der Anwendungskapazität nutzen. Auf diese Weise können Sie einige der Kapazitätsprobleme bewältigen, die bei global verteilten Anwendungen auftreten können.

• Authentifizieren Sie die Personen, die Ihre Systeme nutzen, indem Sie eine gemeinsame Identität zwischen Umgebungen etablieren, damit sich Systeme über Umgebungsgrenzen hinaus authentifizieren können.

• Zum Schutz vertraulicher Informationen wird dringend empfohlen, die gesamte Kommunikation während der Übertragung zu verschlüsseln. Wenn eine Verschlüsselung am Konnektivitätslayer erforderlich ist, stehen je nach ausgewählter Hybridkonnektivitätslösung verschiedene Optionen zur Verfügung. Zu diesen Optionen gehören VPN-Tunnel, HA VPN über Cloud Interconnect und MACsec für Cloud Interconnect.

Hybrid- und Multi-Cloud-Architekturmuster: Nächste Schritte

• Informationen zum Umgang mit Hybrid- und Multi-Cloud-Architekturen und zur Auswahl geeigneter Arbeitslasten
• Weitere Informationen zu den Netzwerkarchitekturmustern, die für die ausgewählten Hybrid- und Multi-Cloud-Architekturmuster geeignet sind
• Bereitstellungsarchetypen für Cloud-Anwendungen
• Informationen zum Entwerfen und Bereitstellen einer E-Commerce-Webanwendung mit verschiedenen Architekturen, einschließlich einer auf Mikrodiensten basierenden E-Commerce-Webanwendung mit GKE und einer dynamischen Webanwendung, die auf einer serverlosen API basiert.

---

1. Weitere Informationen zu regionsspezifischen Aspekten finden Sie unter Geografie und Regionen.  ↩