Dieses Dokument ist das zweite von drei Dokumenten in einem Set. Darin 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.

Die Dokumentation zu Hybrid- und Multi-Cloud-Architekturmustern besteht aus den folgenden Teilen:

• Hybrid- und Multi-Cloud-Architekturen erstellen: Hier wird die Planung einer Strategie für die Entwicklung einer Hybrid- und Multi-Cloud-Einrichtung mit Google Clouderläutert.
• Hybrid- und Multi-Cloud-Architekturmuster: Hier werden gängige Architekturmuster beschrieben, die im Rahmen einer Hybrid- und Multi-Cloud-Strategie verwendet 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 behandelt.

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 zum Strukturieren mehrerer funktionaler Komponenten einer Technologielösung, Anwendung oder eines Dienstes, um eine wiederverwendbare Lösung zu erstellen, die bestimmte Anforderungen oder Anwendungsfälle erfüllt. Eine cloudbasierte Technologielösung besteht oft aus mehreren unterschiedlichen und verteilten Cloud-Diensten. Diese Dienste arbeiten zusammen, um die erforderliche Funktionalität bereitzustellen. In diesem Zusammenhang wird jeder Dienst als funktionale Komponente der Technologielösung betrachtet. Ebenso kann eine Anwendung aus mehreren funktionalen Ebenen, Modulen oder Diensten bestehen, die jeweils eine funktionale Komponente der Anwendungsarchitektur darstellen können. Eine solche Architektur kann standardisiert werden, um bestimmte geschäftliche Anwendungsfälle zu berücksichtigen und als grundlegendes, wiederverwendbares Muster zu dienen.

Um ein Architekturmuster für eine Anwendung oder Lösung 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 genau definierte Schnittstellen oder APIs. Es gibt eine Vielzahl von Kommunikationsmodellen, z. B. asynchron und synchron, Anfrage/Antwort oder warteschlangenbasiert.

Es gibt zwei Hauptkategorien von Hybrid- und Multi-Cloud-Architekturmustern:

• Muster für verteilte Architekturen: Diese Muster basieren 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 am besten zum Muster passt. So können die verschiedenen Eigenschaften und Merkmale von verteilten und miteinander verbundenen Rechenumgebungen optimal genutzt werden.
• Redundante Architekturmuster: Diese Muster basieren auf redundanten Bereitstellungen von Arbeitslasten. Bei diesen Mustern stellen Sie dieselben Anwendungen und ihre Komponenten in mehreren Rechenumgebungen bereit. Das Ziel besteht darin, die Leistungskapazität oder 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 Bereitstellungsarchetyp 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 Fehlerdomains, in denen eine Anwendung ausgeführt werden kann. Diese Fehlerdomains können eine oder mehrere Google Cloud Zonen oder ‑Regionen umfassen und auf Ihre lokalen Rechenzentren oder Fehlerdomains bei anderen Cloud-Anbietern ausgeweitet werden.

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-Hybrid- 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 überlegen, wie diese Einschränkungen zu Anwendungsfehlern führen könnten. Diese Überlegung wird 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 besonderen Funktionen der einzelnen Computing-Umgebungen in einer verteilten Architektur.

Designaspekte

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

Latenz

Bei jedem Architekturmuster, bei dem Anwendungskomponenten (Frontends, Backends oder Mikrodienste) auf verschiedene Rechenumgebungen verteilt werden, kann es zu Kommunikationslatenz kommen. Diese Latenz wird durch die Hybridnetzwerkverbindung (Cloud VPN und Cloud Interconnect) und die geografische Entfernung zwischen dem lokalen Standort und den Cloud-Regionen oder zwischen Cloud-Regionen in einer Multicloud-Konfiguration beeinflusst. Daher ist es wichtig, die Latenzanforderungen Ihrer Anwendungen und ihre Empfindlichkeit gegenüber Netzwerkverzögerungen zu bewerten. Anwendungen, die Latenz tolerieren können, eignen sich besser für die erste verteilte Bereitstellung in einer Hybrid- oder Multi-Cloud-Umgebung.

Architektur für temporären und endgültigen Status

Um die Erwartungen und alle potenziellen Auswirkungen auf Kosten, Skalierung und Leistung festzulegen, ist es wichtig, in der Planungsphase zu analysieren, welche Art von Architektur Sie benötigen und wie lange sie voraussichtlich genutzt werden soll. Wenn Sie beispielsweise eine Hybrid- oder Multi-Cloud-Architektur über einen längeren 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 Hybridverbindung zu optimieren, bietet Cloud Interconnect Rabatte auf die Kosten für die ausgehende Datenübertragung, die die Bedingungen für die Datenübertragungsrate mit Rabatt erfüllen.

Zuverlässigkeit

Zuverlässigkeit ist ein wichtiger Aspekt bei der Entwicklung von IT-Systemen. Die Verfügbarkeit der Betriebszeit ist ein wichtiger Aspekt der Systemzuverlässigkeit. In Google Cloudkönnen Sie die Ausfallsicherheit einer Anwendung erhöhen, indem Sie redundante Komponenten dieser Anwendung in mehreren Zonen in einer einzelnen Region¹ oder in mehreren Regionen mit Failover-Funktionen 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, ein einheitliches Verfügbarkeitsniveau aufrechtzuerhalten.

Um die Verfügbarkeit eines Systems in einer lokalen Umgebung oder in anderen Cloud-Umgebungen zu verbessern, sollten Sie überlegen, welche Hardware- oder Software-Redundanz mit Failover-Mechanismen Sie für Ihre Anwendungen und deren Komponenten benötigen. Im Idealfall sollten Sie die Verfügbarkeit eines Dienstes oder einer Anwendung für die verschiedenen Komponenten und die unterstützende Infrastruktur (einschließlich der Verfügbarkeit von Hybridverbindungen) in allen Umgebungen berücksichtigen. Dieses Konzept wird auch als zusammengesetzte Verfügbarkeit einer Anwendung oder eines Dienstes bezeichnet.

Abhängig von den Abhängigkeiten zwischen den Komponenten oder Diensten kann die zusammengesetzte Verfügbarkeit einer Anwendung höher oder niedriger sein als die eines einzelnen Dienstes oder einer einzelnen Komponente. Weitere Informationen finden Sie unter Zusammengesetzte Verfügbarkeit: Berechnung der Gesamtverfügbarkeit der Cloud-Infrastruktur.

Um die gewünschte Systemzuverlässigkeit zu erreichen, müssen Sie klare Zuverlässigkeitsmesswerte definieren und Anwendungen so konzipieren, dass sie sich selbst reparieren und Störungen in den verschiedenen Umgebungen effektiv überstehen. Informationen dazu, wie Sie geeignete Methoden zur Messung der Kundenzufriedenheit mit Ihren Diensten definieren, finden Sie unter Zuverlässigkeit anhand von Nutzerfreundlichkeitszielen definieren.

Hybrid- und Multi-Cloud-Konnektivität

Die Anforderungen an die Kommunikation zwischen den Komponenten der verteilten Anwendungen sollten Ihre Auswahl einer Option für die Hybridnetzwerkverbindung beeinflussen. Jede Verbindungsoption hat ihre Vor- und Nachteile sowie spezifische Faktoren, die berücksichtigt werden müssen, z. B. Kosten, Trafficvolumen und Sicherheit. Weitere Informationen finden Sie im Abschnitt Überlegungen zum Konnektivitätsdesign.

Verwaltung

Einheitliche Tools für Verwaltung und Monitoring sind für erfolgreiche Hybrid- und Multi-Cloud-Setups (mit oder ohne Workload-Portabilität) unerlässlich. Kurzfristig können diese Tools zu zusätzlichen Kosten für Entwicklung, Tests und Betrieb führen. Je mehr Cloud-Anbieter Sie nutzen, desto komplexer wird die Verwaltung Ihrer Umgebungen. Die meisten Anbieter öffentlicher Clouds haben nicht nur unterschiedliche Funktionen, 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 Multicloud-Umgebung hat eigene Abrechnungs-Messwerte und ‑Tools. Um eine bessere Übersicht und einheitliche Dashboards zu erhalten, sollten Sie Tools zur Kostenverwaltung und ‑optimierung für mehrere Clouds verwenden. Wenn Sie beispielsweise Cloud-First-Lösungen in mehreren Cloud-Umgebungen entwickeln, können die Produkte, Preise, Rabatte und Verwaltungstools der einzelnen Anbieter zu Kostenabweichungen zwischen diesen Umgebungen führen.

Wir empfehlen, eine einzige, klar definierte Methode zur Berechnung der vollen Kosten von Cloud-Ressourcen zu verwenden und die Kosten transparent zu machen. Kostentransparenz ist für die Kostenoptimierung unerlässlich. Wenn Sie beispielsweise Abrechnungsdaten der von Ihnen verwendeten Cloud-Anbieter kombinieren und den Google Cloud Looker Cloud Cost Management Block verwenden, können Sie eine zentrale Ansicht Ihrer Multicloud-Kosten erstellen. Diese Ansicht kann Ihnen helfen, einen konsolidierten Überblick über Ihre Ausgaben in mehreren Clouds zu erhalten. Weitere Informationen finden Sie unter Strategie zur effektiven Optimierung der Kostenverwaltung für die Cloud-Abrechnung.

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

Datenverschiebung

Die Datenverschiebung 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 dafür erforderlichen Daten und die Klassifizierung der Daten (für regulierte Branchen) identifizieren. Sie sollten auch berücksichtigen, wie sich Datenspeicherung, ‑freigabe und ‑zugriff für verteilte Systeme in verschiedenen Umgebungen auf die Anwendungsleistung und Datenkonsistenz auswirken können. Diese Faktoren können sich auf die Anwendung und die Architektur der Datenpipeline auswirken. Die umfassenden Optionen für die Datenübertragung vonGoogle Cloudermöglichen es Unternehmen, ihre spezifischen Anforderungen zu erfüllen und Hybrid- und Multi-Cloud-Architekturen zu nutzen, ohne Kompromisse bei Einfachheit, Effizienz oder Leistung eingehen zu müssen.

Sicherheit

Beim Migrieren von Anwendungen in die Cloud ist es wichtig, Cloud-First-Sicherheitsfunktionen wie Konsistenz, Beobachtbarkeit und einheitliche Sicherheitsübersicht zu berücksichtigen. Jeder Anbieter öffentlicher Clouds hat seinen eigenen Sicherheitsansatz, seine eigenen Best Practices und Funktionen. Es ist wichtig, diese Funktionen zu analysieren und aufeinander abzustimmen, um eine standardmäßige, funktionale Sicherheitsarchitektur zu erstellen. Starke IAM-Kontrollen, Datenverschlüsselung, Scannen auf Sicherheitslücken und die Einhaltung von Branchenvorschriften sind ebenfalls wichtige Aspekte der Cloud-Sicherheit.

Bei der Planung einer Migrationsstrategie empfehlen wir, die oben genannten Aspekte zu berücksichtigen. Sie können Ihnen helfen, die Wahrscheinlichkeit zu minimieren, dass die Architektur mit dem Wachstum Ihrer Anwendungen oder des Datenverkehrs komplexer wird. 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 Landing Zone-Design 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 Webanwendungslösung 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 vonGoogle Cloudverwaltete Datenbanken wie Cloud SQL dabei, das Backend als Datenbankebene bereitzustellen.

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 Cloudmigrieren.

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 über Google Clouderreichbar. 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 über die verschiedenen Möglichkeiten zur Modernisierung Ihrer E-Commerce-Plattform aufGoogle Cloudfinden Sie unter Aufbau einer digitalen 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 Google Cloud -Rechenzentrum 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 die 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 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 Ihren lokalen Umgebungen)

    • Wenn Sie Container und Kubernetes in verschiedenen Umgebungen verwenden, haben Sie die Flexibilität, Arbeitslasten zu modernisieren und zu unterschiedlichen Zeiten zu Google Cloud 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 von verschiedenen Cloud-Dienstanbietern kombiniert. Diese Architektur bietet die Flexibilität, eine Anwendung in einer optimalen Rechenumgebung bereitzustellen, die die im ersten Teil dieser Reihe besprochenen Multicloud-Faktoren und ‑Überlegungen berücksichtigt.

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

Dieses Architekturmuster kann auf zwei verschiedene Arten erstellt 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 gestaffelten Hybrid-Architekturmuster. Anstelle einer lokalen Umgebung mit einer öffentlichen Cloud werden jedoch mindestens zwei Cloud-Umgebungen verwendet. In einer zusammengesetzten Architektur verwendet eine einzelne Arbeitslast oder Anwendung Komponenten aus mehr als einer Cloud. Beim zweiten Ansatz werden verschiedene Anwendungen in verschiedenen Public Cloud-Umgebungen bereitgestellt. In der folgenden unvollständigen Liste werden einige der geschäftlichen Gründe für den zweiten Ansatz beschrieben:

• Anwendungen, die in unterschiedlichen Cloud-Umgebungen gehostet werden, vollständig in ein Szenario für Fusionen und Übernahmen zwischen zwei Unternehmen zu integrieren.
• Um Flexibilität zu fördern und den unterschiedlichen Cloud-Präferenzen in Ihrer Organisation gerecht zu werden. Mit diesem Ansatz können Sie Organisationseinheiten dazu anregen, den Cloud-Anbieter auszuwählen, der ihren spezifischen Anforderungen und Präferenzen am besten entspricht.
• Für den Betrieb in einer multiregionalen oder globalen Cloud-Bereitstellung. Wenn ein Unternehmen in bestimmten Regionen oder Ländern die Vorschriften zum Datenstandort 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 wird die Portabilität Ihrer Arbeitslasten zu einer wichtigen 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 Multi-Cloud-Komplexität mit konsistenten Governance-, Betriebs- und Sicherheitsstatus 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 und gleichzeitig die Anbieterabhängigkeit zu reduzieren und behördliche Anforderungen zu erfüllen. Sie können beispielsweise eine Verbindung Google Cloud mit Oracle Cloud Infrastructure (OCI) herstellen, um eine Multi-Cloud-Lösung zu erstellen, die die Funktionen jeder Plattform nutzt. Dazu kombinieren Sie Komponenten, die in OCI ausgeführt werden, mit Ressourcen, die auf Google Cloudausgeführt werden, über eine private Cloud Interconnect-Verbindung. Weitere Informationen finden Sie unter Google Cloud and Oracle Cloud Infrastructure – making the most of multicloud. Außerdem 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 entwickeln und erstellen, die ein hohes Inter-Cloud-Trafficvolumen bewältigen.

Vorteile

Die Verwendung einer Multi-Cloud-Architektur bietet mehrere geschäftliche und technische Vorteile, wie im Abschnitt Erfolgsfaktoren, Überlegungen, Strategie und Ansätze beschrieben. Es ist jedoch wichtig, eine detaillierte Machbarkeitsbewertung für jeden potenziellen Vorteil durchzuführen. Bei der Bewertung sollten Sie alle damit verbundenen direkten oder indirekten Herausforderungen oder potenziellen Hindernisse sowie Ihre Fähigkeit, diese effektiv zu bewältigen, sorgfältig berücksichtigen. Außerdem kann das langfristige Wachstum Ihrer Anwendungen oder Dienste zu Komplexitäten führen, 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 Abhängigkeit von einem bestimmten Anbieter relativ verringern, da Sie die Tarife (bis zu einem gewissen Grad) bei Ihren Cloud-Anbietern ändern können. Die Open Cloud trägt dazu bei, Google Cloud Funktionen wie GKE Enterprise an verschiedenen physischen Standorten bereitzustellen. Durch die Erweiterung der Google Cloud Funktionen lokal, in mehreren öffentlichen Clouds und am Edge bietet sie Flexibilität, Agilität und treibt die Transformation voran.

• Aus regulatorischen Gründen können Sie einen bestimmten Teil Ihrer Nutzerbasis und Daten aus einem Land bedienen, in dem Google Cloud keine Cloud-Region hat.

• Das Architekturmuster partitionierte Multi-Cloud kann dazu beitragen, die Latenz zu verringern und die allgemeine Qualität der Nutzerfreundlichkeit 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 Sie Multicloud-Verbindungen mit hoher Kapazität und niedriger Latenz verwenden, z. B. Cross-Cloud Interconnect und CDN Interconnect mit einem verteilten CDN.

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

• Das Architekturmuster partitionierte Multicloud kann Fusionen und Übernahmen erleichtern und beschleunigen, bei denen die Anwendungen und Dienste der beiden Unternehmen möglicherweise in verschiedenen öffentlichen 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 anwendbar, wenn die spezifische Arbeitslast aus rechtlichen oder behördlichen 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 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 wird 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 sollten Sie entweder das vermaschte Architekturmuster oder eines der Gated-Netzwerkmuster verwenden.
• Um die Erwartungen an Verfügbarkeit und Leistung zu erfüllen, sollten Sie eine End-to-End-Hochverfügbarkeit (HA), geringe Latenzzeiten und ein angemessener Durchsatz gewährleisten.

• 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-Architekturmusters mit Partitionierung verwenden und Ihr anderes CDN mit großen Dateien aus Google Cloudeinpflegen, sollten Sie die CDN Interconnect-Verbindungen zwischen Google Cloud und unterstützten Anbietern verwenden, um diesen Traffic und möglicherweise seine 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 verteilen. Weitere Informationen finden Sie unter Traffic an einen lokalen Standort oder eine andere Cloud weiterleiten.

  • Wenn das ausgehende Datenübertragungsvolumen von Google Cloudin Richtung anderer Umgebungen hoch ist, sollten Sie Cross-Cloud Interconnect in Betracht ziehen.

• 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, den Schutz und die Verteilung von API-Traffic in großem Maßstab über mehrere Regionen hinweg bieten:

  • Bereitstellung von Multi-Region-Failover für Apigee-API-Runtimes in verschiedenen Regionen.

  • Leistung mit Cloud CDN steigern

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

• Verwenden Sie nach Möglichkeit konsistente 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 verteilt bereitstellen, wobei die Komponenten einer einzelnen Anwendung in mehr als einer Cloud-Umgebung bereitgestellt werden, 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.

• 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 langfristig ein Datentransfer oder ‑austausch zwischen Google Cloud und anderen Clouds mit hohem Trafficvolumen erforderlich ist, sollten Sie die Verwendung von Google Cloud Cross-Cloud Interconnect in Betracht ziehen, um eine dedizierte Verbindung mit hoher Bandbreite zwischenGoogle Cloud und anderen Cloud-Dienstanbietern herzustellen (verfügbar an 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 können kostengünstiger 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, verwenden Sie das Muster für gatewaygesteuerten ausgehenden und eingehenden Traffic.
• Wenn die Lösung aus vielen Edge-Remotestandorten besteht, die über das öffentliche Internet eine Verbindung zuGoogle Cloud herstellen, können Sie eine SD-WAN-Lösung (Software-Defined 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. Sehen Sie sich die möglichen Verbindungsoptionen an, die Sie zum Verbinden eines GKE Enterprise-Clusters, der in Ihrer lokalen oder Edge-Umgebung ausgeführt wird, mit Google Cloudhaben.
• 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 und Google 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. Anschließend verwenden Sie die öffentliche Cloud 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, 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 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 vorhandenen Best Practices oder Bestrebungen zuwiderlaufen, die Unterschiede zwischen diesen Umgebungen minimieren sollen. 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 Dies wird auch als Lasttest bezeichnet.
• Staging- oder Bereitstellungstests: Prüfen, ob das Bereitstellungsverfahren funktioniert.
• Produktion: Neue oder aktualisierte Anwendungen veröffentlichen.

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

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äftliche Anforderungen: Jede Bereitstellungs- und Release-Strategie für Anwendungen hat ihre eigenen 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: Mit einem Genehmigungs- und Governance-Prozess können Sie steuern, was Ihr Unternehmen in der Cloud entwickeln darf und welche Daten für Tests verwendet werden können. 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 je nach Bedarf automatisch starten und stoppen. 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. Dadurch wird auch der Wartungsaufwand reduziert und es kommt zu weniger Inkonsistenzen in der Build-Umgebung.
• 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 Hybridmusters für Umgebungen folgende 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 bedeuten, dass Änderungen ohne Ausfallzeiten eingeführt oder Funktionen schrittweise in einer bestimmten Umgebung oder für eine bestimmte Nutzergruppe implementiert werden, bevor sie allgemein verfügbar gemacht werden.

• Um Arbeitslasten portabel zu machen und Unterschiede zwischen Umgebungen zu abstrahieren, können Sie Container mit Kubernetes verwenden. 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 auf Google Cloud.

• Um Ihnen bei der kontinuierlichen Veröffentlichung sicherer und zuverlässiger Anwendungen zu helfen, sollten Sie die Sicherheit als integralen Bestandteil des DevOps-Prozesses (DevSecOps) einbeziehen. 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 Cloudumgebungen 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, kann die Verwendung verschiedener Tools akzeptabel sein. Wenn Sie jedoch dieselben Tools mit unterschiedlichen Berechtigungen für die Ansicht 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 auf der 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 Informationen 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.

Die folgende Tabelle zeigt, 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, einer Organisation zu helfen, widerstandsfähig zu sein und ihren Geschäftsbetrieb während und nach Ausfällen 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 beispielsweise ein schwerer Systemausfall, ein Cyberangriff oder ein Fehler bei der Systemkonfiguration.

Die Optimierung eines Systems, um Ausfällen standzuhalten, ist für die Geschäftskontinuität unerlässlich. Die Systemzuverlässigkeit kann von mehreren Faktoren beeinflusst werden, darunter Leistung, Ausfallsicherheit, Verfügbarkeit, Sicherheit und Nutzerfreundlichkeit. Weitere Informationen zum Entwerfen und Betreiben zuverlässiger Dienste aufGoogle Cloudfinden Sie in der Zuverlässigkeitsspalte des Google Cloud Well-Architected Framework und unter Bausteine für Zuverlässigkeit in Google Cloud.

Dieses Architekturmuster basiert auf einer redundanten Bereitstellung von Anwendungen in mehreren Rechenumgebungen. Bei diesem Muster stellen Sie dieselben Anwendungen in mehreren Rechenumgebungen bereit, um die Zuverlässigkeit zu erhöhen. Geschäftskontinuität kann als die Fähigkeit einer Organisation definiert werden, ihre wichtigsten Geschäftsfunktionen oder ‑dienste nach einer Störung auf einem vordefinierten akzeptablen Niveau fortzusetzen.

Die Notfallwiederherstellung 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 sind DR-Strategien und ‑Pläne oft ein wichtiger Bestandteil für eine erweiterte Strategie zur Aufrechterhaltung der Geschäftskontinuität. Aus technologischer Sicht sollten in Ihrer Geschäftsauswirkungsanalyse zwei wichtige Messwerte definiert werden, wenn Sie mit der Entwicklung von Strategien zur Notfallwiederherstellung beginnen: 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 RPO- und RTO-Zielwerte sind, desto schneller können Dienste nach einer Unterbrechung mit minimalem Datenverlust wiederhergestellt werden. Dies ist jedoch mit höheren Kosten verbunden, da redundante Systeme erforderlich sind. Redundante Systeme, die in der Lage sind, Daten in nahezu Echtzeit zu replizieren und die nach einem Fehlerereignis im gleichen Umfang arbeiten, erhöhen die Komplexität, den Verwaltungsaufwand und die Kosten.

Die Entscheidung für eine DR-Strategie oder ein ‑Muster sollte auf einer Geschäftsauswirkungsanalyse basieren. Beispielsweise können die finanziellen Verluste, die durch einen Ausfall von nur wenigen Minuten für ein Finanzdienstleistungsunternehmen entstehen, die Kosten für die Implementierung eines DR-Systems bei Weitem übersteigen. Unternehmen in anderen Branchen können jedoch stundenlange Ausfallzeiten ohne nennenswerte Auswirkungen auf das Geschäft verkraften.

Wenn Sie geschäftskritische Systeme in einem lokalen Rechenzentrum ausführen, können Sie zur Notfallwiederherstellung beispielsweise Standby-Systeme in einem zweiten Rechenzentrum in einer anderen Region unterhalten. Ein kostengünstigerer Ansatz stellt jedoch die Verwendung einer Rechenumgebung in der öffentlichen Cloud für Failover-Zwecke dar. Dieser Ansatz ist der Hauptgrund für das Hybridmuster für Geschäftskontinuität. Die Cloud kann aus Kostensicht besonders attraktiv sein, da Sie einen Teil Ihrer DR-Infrastruktur deaktivieren können, wenn sie nicht verwendet wird. Um eine kostengünstigere DR-Lösung zu erhalten, kann ein Unternehmen mit einer Cloudlösung die potenziellen Erhöhungen der RPO- und RTO-Werte in Kauf nehmen.

Das obige Diagramm zeigt 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 DR-Umgebung ein anderer Cloudanbieter verwendet. Wenn Sie Kopien von Arbeitslasten über mehrere Cloud-Anbieter hinweg bereitstellen, können Sie die Verfügbarkeit möglicherweise über das hinaus erhöhen, was eine Bereitstellung in mehreren Regionen bietet.

Die Bewertung eines DR in mehreren Clouds im Vergleich zur Verwendung eines Cloud-Anbieters mit verschiedenen Regionen erfordert eine gründliche Analyse mehrerer 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 kontinuierlicher Inter-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.

Wenn Ihre Daten aufgrund von behördlichen Anforderungen in Ihrem Land verbleiben müssen, kann die Verwendung eines zweiten Cloud-Anbieters, der sich ebenfalls in Ihrem Land befindet, als DR-Option infrage kommen. Bei der Verwendung eines zweiten Cloud-Anbieters wird davon ausgegangen, dass es keine Möglichkeit gibt, eine lokale Umgebung für die Einrichtung einer Hybridkonfiguration zu verwenden. Um eine Neugestaltung Ihrer Cloud-Lösung zu vermeiden, sollte Ihr zweiter Cloud-Anbieter idealerweise alle erforderlichen Funktionen und Dienste in der Region anbieten.

Designaspekte

• DR-Erwartung: Die RPO- und RTO-Ziele, die Ihr Unternehmen erreichen möchte, sollten Ihre DR-Architektur und die Planungsphase bestimmen.
• Lösungsarchitektur: Bei diesem Muster müssen Sie die vorhandenen Funktionen Ihrer lokalen Umgebung replizieren, um Ihre DR-Erwartungen zu erfüllen. Daher müssen Sie die Machbarkeit und Rentabilität des Rehostings, Refaktorierens oder der Neugestaltung Ihrer Anwendungen bewerten, um in der Cloudumgebung dieselben (oder optimierte) Funktionen und Leistung 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 Landing Zone-Design in Google Cloud.

• DR-Aufruf: Bei der Gestaltung und dem Prozess für die Notfallwiederherstellung sollten Sie die folgenden Fragen berücksichtigen:

  • Was löst ein Notfallwiederherstellungsszenario aus? Ein DR kann beispielsweise durch den Ausfall bestimmter Funktionen oder Systeme am primären Standort ausgelöst werden.
  • Wie wird das Failover zur DR-Umgebung ausgelöst? Ist es ein manueller Genehmigungsprozess oder kann er automatisiert werden, um ein niedriges RTO-Ziel zu erreichen?
  • Wie sollten Mechanismen zur Erkennung und Benachrichtigung von Systemfehlern konzipiert sein, um Failover in Übereinstimmung mit dem erwarteten RTO auszulösen?
  • Wie wird der Traffic nach dem Erkennen des Fehlers zur DR-Umgebung umgeleitet?

  Überprü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 Ihren Erwartungen an RPO und RTO entspricht. So können Sie bei Bedarf leichter DR aufrufen. Führen Sie die Tests jedes Mal neu durch, wenn eine neue Änderung oder Aktualisierung am Prozess oder an der Technologielösung vorgenommen wird.

• Teamkompetenzen: Mindestens ein technisches Team muss über die erforderlichen Fähigkeiten und das Fachwissen verfügen, um die Produktionsarbeitslast in der Cloud-Umgebung zu erstellen, auszuführen und Fehler zu beheben, sofern Ihre Umgebung nicht von einem Drittanbieter verwaltet wird.

Vorteile

Die Nutzung von Google Cloud für die Aufrechterhaltung des Geschäftsbetriebs bietet mehrere Vorteile:

• Da Google Cloud viele Regionen auf der ganzen Welt zur Auswahl hat, können Sie damit Daten an einem anderen Standort auf demselben Kontinent sichern oder replizieren. Sie können Daten auch an einem Standort auf einem anderen Kontinent sichern oder replizieren.
• MitGoogle Cloud können Daten in Cloud Storage in einem biregionalen oder multiregionalen Bucket gespeichert werden. Daten werden redundant in mindestens zwei separaten geografischen Regionen gespeichert. Daten, die in Buckets mit zwei oder mehreren Regionen gespeichert sind, werden mithilfe der Standardreplikation über geografische Regionen hinweg repliziert.
  • Dual-Region-Buckets bieten Georedundanz zur Unterstützung von Geschäftskontinuitäts- und Notfallwiederherstellungsplänen. Um die Replikation zu beschleunigen und ein niedrigeres RPO zu erreichen, können in Dual-Regionen gespeicherte Objekte optional die Turboreplikation über diese Regionen hinweg verwenden.
  • Die multiregionale Replikation bietet Redundanz über mehrere Regionen hinweg, indem Ihre Daten innerhalb der geografischen Grenzen der multiregionalen Konfiguration gespeichert werden.
• Bietet eine oder mehrere der folgenden Optionen zur Reduzierung von Kapital- und Betriebsausgaben für die Erstellung einer DR:
  • Beendete VM-Instanzen verursachen lediglich Speicherkosten und sind wesentlich günstiger als ausgeführte VM-Instanzen. So können Sie die Kosten für den Unterhalt 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 Funktionen für die Elastizität wie Autoscaling können Sie Ihre DR-Umgebung nach Bedarf automatisch skalieren.

Das folgende Diagramm zeigt beispielsweise eine Anwendung, die in einer lokalen Umgebung (Produktion) ausgeführt wird und Wiederherstellungskomponenten aufGoogle Cloud mit Compute Engine, Cloud SQL und Cloud Load Balancing verwendet. In diesem Szenario wird die Datenbank mit einer VM-basierten Datenbank oder einer Google Cloud verwalteten Datenbank wie Cloud SQL vorab bereitgestellt, um eine schnellere Wiederherstellung mit kontinuierlicher Datenreplikation zu ermöglichen. Sie können Compute Engine-VMs aus vorab erstellten Snapshots starten, um die Kosten im Normalbetrieb zu senken. Bei dieser Einrichtung muss 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 Web- und Anwendungs-VMs bereitstellen. Je nach angestrebtem RTO-Level und Unternehmensrichtlinien kann der gesamte Prozess zum Auslösen eines DR, zum Bereitstellen der Arbeitslast in der Cloud und zum Umleiten des Traffics manuell oder automatisch abgeschlossen werden.

Um die Bereitstellung der Infrastruktur zu beschleunigen und zu automatisieren, sollten Sie die Infrastruktur als Code verwalten. Sie können Cloud Build, einen Dienst für die kontinuierliche Integration, verwenden, um Terraform-Manifeste automatisch auf Ihre Umgebung anzuwenden. 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 basierend auf Ihrer Analyse der geschäftlichen Auswirkungen und den ermittelten erforderlichen RPO- und RTO-Zielen:
  • Entscheiden Sie, ob das Sichern von Daten in Google Cloud ausreicht oder ob Sie eine andere DR-Strategie (Cold-, Warm- oder Hot-Standby-Systeme) in Betracht ziehen müssen.
  • Definieren Sie die Dienste und Produkte, die Sie als Bausteine für Ihren DR-Plan verwenden können.
  • Formulieren Sie die entsprechenden DR-Szenarien für Ihre Anwendungen und Daten im Rahmen Ihrer ausgewählten DR-Strategie.
• Verwenden Sie das Handover-Muster, wenn Sie nur Daten sichern. Andernfalls ist das Mesh-Muster möglicherweise 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 zwei Umgebungen, die Daten bidirektional replizieren, die Kommunikation miteinander verlieren. Diese Trennung kann dazu führen, dass Systeme in beiden Umgebungen annehmen, dass die jeweils andere Umgebung nicht mehr verfügbar ist und sie exklusiven Zugriff auf die Daten haben. Dies kann zu widersprüchlichen Änderungen der Daten führen. Es gibt zwei gängige Möglichkeiten, das Split-Brain-Problem zu vermeiden:

  • Verwenden Sie eine dritte Rechenumgebung. In dieser Umgebung können Systeme ein Quorum abfragen, bevor Daten geändert werden.

  • 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 für 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 portierbar sein (sofern von den Anwendungen unterstützt und machbar), damit die Systeme in allen Umgebungen konsistent bleiben. Dieser Ansatz lässt sich mit Containern und Kubernetes umsetzen. Mit der Google Kubernetes Engine (GKE) Enterprise-Version können Sie die Entwicklung und den Betrieb vereinfachen.

• Binden Sie die Bereitstellung von Standby-Systemen in Ihre CI/CD-Pipeline ein. Damit sorgen Sie dafür, dass Anwendungsversionen und -konfigurationen in allen Umgebungen einheitlich sind.

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

• Wählen Sie die DNS- und Routingrichtlinie aus, die Ihrer Architektur und Ihrem Lösungsverhalten entspricht. 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 der hybriden Einrichtung.

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

  • Verfügbarkeit und Stabilität Ihrer Anwendungen und Dienste verbessern

  • Die Bereitstellung oder Migration von Hybridanwendungen mit Abhängigkeiten zwischen lokalen und Cloud-Umgebungen mit einer DNS-Konfiguration für mehrere Anbieter 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 Public DNS von mehreren Anbietern mit Cloud DNS.

• Verwenden Sie Load-Balancer, wenn Sie Standby-Systeme verwenden, um ein automatisches Failover zu erstellen. Beachten Sie, dass die Hardware des Load-Balancers ausfallen kann.

• Verwenden Sie Cloud Load Balancing anstelle von Hardware-Load-Balancern, um einige Szenarien zu ermöglichen, die bei 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 DR-Umgebung weitergeleitet werden. Weitere Informationen finden Sie unter Trafficverwaltung für globale externe Application Load Balancer.

• Wenn das ausgehende Datenübertragungsvolumen von Google Cloud in Richtung der anderen Umgebung hoch ist, sollten Sie Cloud Interconnect oder Cross-Cloud Interconnect verwenden. 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.

• Erwägen Sie, Ihre bevorzugte Partnerlösung im Google Cloud Marketplace zu verwenden, um Datenback-ups, Replikationen und andere Aufgaben zu erleichtern, die Ihren Anforderungen entsprechen, einschließlich Ihrer RPO- und RTO-Ziele.

• Testen und bewerten Sie DR-Aufrufszenarien, um zu ermitteln, wie schnell die Anwendung nach einem Notfall wiederhergestellt werden kann, verglichen mit dem angestrebten RTO-Wert.

• Kommunikation während der Übertragung verschlüsseln Zum Schutz vertraulicher Informationen 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

• Überwachen Sie den Traffic, der von Google Cloud an eine andere Rechenumgebung gesendet wird. Für diesen 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.