Hybrid- und Multi-Cloud-Architekturmuster

Dieser Artikel ist der zweite Teil einer mehrteiligen Reihe, die Hybrid- und Multi-Cloud-Bereitstellungen, -Architekturmuster und -Netzwerktopologien zum Thema hat. Im vorliegenden Teil stehen gängige Hybrid- und Multi-Cloud-Architekturmuster im Mittelpunkt. Wir beschreiben, für welche Szenarien diese Muster am besten geeignet sind, und stellen Best Practices für die Implementierung mit Google Cloud vor.

Die Reihe besteht aus folgenden Teilen:

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.

Die Muster fallen in zwei Kategorien:

  • Muster, die auf einer verteilten Bereitstellung von Anwendungen basieren. Damit soll eine Anwendung in der für sie am besten geeigneten Rechenumgebung ausgeführt werden, um die verschiedenen Attribute und Merkmale von Rechenumgebungen optimal nutzen zu können.

  • Muster, die auf redundanten Bereitstellungen von Anwendungen basieren. Bei diesen Mustern wird eine Anwendung in mehreren Rechenumgebungen erstellt, um die Kapazität oder Ausfallsicherheit zu erhöhen.

Muster für verteilte Bereitstellungen

Berücksichtigen Sie bei der Umstellung einer herkömmlichen Rechenumgebung auf eine Hybrid- oder Multi-Cloud-Konfiguration die Einschränkungen, die sich aus vorhandenen Anwendungen ergeben. Überlegen Sie sich außerdem, wie Sie von den besonderen Funktionen der einzelnen Rechenumgebungen profitieren können. Die Muster für verteilte Bereitstellungen sind darauf ausgelegt, ein ausgewogenes Verhältnis zwischen diesen beiden Zielen herzustellen.

Gestaffeltes Hybridmuster

Die meisten Anwendungen fallen entweder in die Kategorie Front-End oder Back-End.

  • Front-End-Anwendungen werden Endnutzern oder Geräten direkt bereitgestellt. Diese Anwendungen sind häufig leistungsabhängig. Auch müssen dafür oft regelmäßige Releases mit neuen Funktionen und Verbesserungen übernommen werden. Da Front-End-Anwendungen zum Speichern und Verwalten von Daten normalerweise auf Back-End-Anwendungen zurückgreifen, sind sie häufig zustandslos oder werden nur für die Verwaltung kleiner Datenmengen genutzt.

  • Back-End-Anwendungen sind in der Regel auf die Datenverwaltung ausgelegt. Zu den zentralen Herausforderungen solcher Anwendungen zählen die Bewältigung großer Datenmengen und die angemessene Sicherung dieser Daten. Neue Releases müssen für Back-End-Anwendungen meist weniger oft vorgenommen werden als für Front-End-Anwendungen.

Beim gestaffelten Hybridmuster liegt der Fokus auf der Bereitstellung vorhandener Front-End-Anwendungen in der öffentlichen Cloud. Bei diesem Muster werden vorhandene Back-End-Anwendungen weiterverwendet, die in ihrer privaten Rechenumgebung verbleiben. Front-End-Anwendungen werden dagegen von Fall zu Fall migriert.

Das folgende Diagramm zeigt ein typisches gestaffeltes Hybridmuster.

Gestaffeltes Hybridmuster.

Mit der Zeit wird der Anteil der Anwendungen, die Sie in der Cloud bereitstellen, so groß sein, dass Sie wahrscheinlich auch das Verschieben von Back-End-Anwendungen in die öffentliche Cloud in Betracht ziehen.

Vorteile

Der primäre Fokus auf Front-End-Anwendungen bietet mehrere Vorteile:

  • Front-End-Anwendungen hängen von Back-Ends und gelegentlich von anderen Front-Ends ab, Back-Ends jedoch nicht von Front-Ends. Daher ist das Isolieren und Migrieren von Front-End-Anwendungen in der Regel weniger kompliziert als das Migrieren von Back-End-Anwendungen, deren Abhängigkeiten komplexer Natur sein können.

  • Da Front-End-Anwendungen häufig zustandslos sind oder selbst keine Daten verwalten, ist deren Migration tendenziell einfacher.

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

  • Viele Front-End-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 dem Sie Updates effizient und automatisiert bereitstellen können.

  • Leistungsabhängige Front-Ends sowie Front-Ends, die häufig geändert werden müssen, können erheblich vom Load-Balancing, von multiregionalen Bereitstellungen und von den Autoscaling-Funktionen einer Cloud-Bereitstellung profitieren.

  • Unabhängig davon, ob Front-End-Anwendungen UIs oder APIs implementieren oder für die IdD-Datenaufnahme (Internet der Dinge) zuständig sind, profitieren sie potenziell von den Funktionen der Clouddienste, wie Firebase, Cloud CDN oder Cloud IoT.

Wenn Ihre Back-Ends Daten verwalten, die behördlichen oder gerichtlichen Einschränkungen unterliegen, ist es eventuell sinnvoll, sie dauerhaft oder zumindest so lange in der privaten Rechenumgebung zu belassen, wie die Arbeit im Rahmen der Einschränkungen möglich ist.

Sie können das gestaffelte Hybridmuster auch umgekehrt anwenden, obwohl dies weniger üblich ist. Dabei stellen Sie Back-Ends in der Cloud bereit und belassen Front-Ends in privaten Rechenumgebungen. Dieser Ansatz eignet sich am besten für ein komplexes und monolithisches Front-End. 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.

Best Practices

Berücksichtigen Sie beim Anwenden des gestaffelten Hybridmusters folgende Best Practices:

  • Verwenden Sie entweder eine Topologie für gatewaygesteuerten ausgehenden Traffic oder eine Mesh-Topologie. 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. Beim Design spielen daher Hochverfügbarkeit, niedrige Latenz und entsprechende Durchsatzraten eine zentrale Rolle.

  • Wählen Sie zum Minimieren der Kommunikationslatenz zwischen Umgebungen GCP-Regionen und Interconnect-Standorte aus, die geografisch in der Nähe Ihrer privaten Rechenumgebung liegen.

  • Bei einer gestaffelten Hybrideinrichtung kommen in der Regel größere Datenmengen bei Google Cloud an (eingehender Traffic), als von Google Cloud an die private Rechenumgebung übertragen werden (ausgehender Traffic). Beachten Sie, dass für den von Google Cloud kommenden Traffic die Preise für ausgehenden Traffic gelten. Durch Verwendung von Dedicated Interconnect oder Direct Peering können diese Kosten gesenkt werden.

  • Sorgen Sie dafür, dass die Kommunikation zwischen Umgebungen unidirektional verläuft. In der öffentlichen Cloud ausgeführte Front-End-Anwendungen dürfen mit Back-Ends kommunizieren, die in privaten Rechenumgebungen ausgeführt werden, jedoch nicht umgekehrt.

  • Da die zwischen Umgebungen ausgetauschten Daten möglicherweise vertraulich sind, müssen Sie gewährleisten, dass die gesamte Kommunikation über VPN-Tunnel (virtuelles privates Netzwerk), TLS (Transport Layer Security) oder beides verschlüsselt wird.

  • Es wird empfohlen, ein API-Gateway als Fassade für vorhandene Back-End-Dienste zu erstellen, insbesondere wenn die Protokolle, APIs und Authentifizierungsverfahren von Back-End zu Back-End verschieden sind. Ein API-Gateway bietet nicht nur die Möglichkeit der Vereinheitlichung, es kann auch als eine Art "Nadelöhr" dienen. Mit diesem Gateway können Sie zusätzliche Sicherheits- und Prüfmaßnahmen implementieren, die für die gesamte umgebungsübergreifende Kommunikation gelten.

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

Beachten Sie für die einzelnen Arbeitslasten folgende zusätzliche Best Practices:

  • Auch wenn der Fokus bei diesem Muster auf Front-End-Anwendungen liegt, sollten Sie die nötige Modernisierung von Back-End-Anwendungen im Auge behalten. Wenn Back-Ends wesentlich seltener gepflegt, gewartet und aktualisiert werden als Front-Ends, kann ein Gefälle entstehen, das die Projektkomplexität erhöht.

  • Damit Migrationen per Transformation und Verschiebung möglich sind, sollten Sie Kubernetes als gemeinsame Laufzeitebene zwischen Google Cloud und privaten Rechenumgebungen verwenden. Mit Kubernetes können Sie Arbeitslasten modernisieren und zu unterschiedlichen Zeiten zu Google Cloud migrieren. Dies kann von entscheidender Bedeutung sein, wenn eine Arbeitslast sehr von einer anderen abhängt und nicht separat migriert werden kann.

  • Vermeiden Sie die bidirektionale Kommunikation zwischen Umgebungen. Dafür sollten Sie auch CI-/CD-Systeme in der öffentlichen Cloud erstellen.

  • Verwenden Sie in einem gestaffelten Hybridszenario einheitliche Tools und CI-/CD-Prozesse in allen Umgebungen, um die operative Effizienz zu steigern. Diese Best Practice ist optional.

  • Wenn Sie Front-End-Arbeitslasten mithilfe von Kubernetes ausführen, sollten Sie Dienste ohne Selektoren verwenden. Dies gewährleistet, dass alle Dienste oder API-Gateways erkennbar sind, die in der privaten Rechenumgebung ausgeführt werden. Die Verwendung von Kubernetes-Stub-Domains ermöglicht die Einbindung in externe DNS-basierte Diensterkennungssysteme wie Consul.

Partitioniertes Multi-Cloud-Muster

Beim partitionierten Multi-Cloud-Muster werden mehrere öffentliche Cloudumgebungen von verschiedenen Anbietern derart kombiniert, dass Sie die Möglichkeit haben, eine Anwendung in der optimalen Rechenumgebung bereitzustellen. Das folgende Diagramm zeigt ein typisches partitioniertes Multi-Cloud-Muster.

Partitioniertes Multi-Cloud-Muster.

Sie können auch hier ermöglichen, dass Arbeitslasten nach Bedarf von einer öffentlichen Cloudumgebung in eine andere verschoben werden. Allerdings stellt die Portabilität von Arbeitslasten dann eine wesentliche Anforderung dar. 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.

Google Cloud bietet eine Vielzahl von Diensten, mit denen Sie Ihre Arbeitslasten auf verschiedene Arten bereitstellen können. In einigen Situationen ist es dennoch sinnvoll, Google Cloud mit einem anderen Cloud-Anbieter zu kombinieren und die Arbeitslasten auf mehrere Cloud-Umgebungen aufzuteilen. Hier einige Beispiele:

  • Wenn Sie nicht an einen einzigen Anbieter gebunden sein wollen, können Sie Anwendungen auf mehrere Cloud-Anbieter verteilen.

  • Aus regulatorischen Gründen bedienen Sie einen bestimmten Teil Ihrer Nutzerbasis mit Daten aus einem Land, in dem Google Cloud noch keine Marktpräsenz erlangt hat.

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

Vorteile

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

  • Sie können damit Anbieterabhängigkeit vermeiden. Dieses Muster reduziert das strategische Risiko und gibt Ihnen die Flexibilität, Pläne oder Partnerschaften später zu ändern.

  • Wenn Sie Arbeitslasten portabel halten, können Sie durch das Verschieben von Arbeitslasten zwischen Rechenumgebungen Ihre Arbeitsabläufe optimieren.

Best Practices

  • Wägen Sie die strategischen Vorteile einer partitionierten Multi-Cloud-Einrichtung gegen die zusätzliche Komplexität ab, die diese Einrichtung mit sich bringt. Die Gewährleistung der Portabilität von Arbeitslasten und der Einheitlichkeit von Tools in verschiedenen Cloudumgebungen erhöht den Entwicklungs-, Test- und Betriebsaufwand.

  • Verwenden Sie eine Multi-Cloud-Umgebung nur für geschäftskritische Arbeitslasten oder wenn die Arbeitslasten aus rechtlichen oder regulatorischen Gründen nicht in einer einzigen öffentlichen Cloudumgebung untergebracht werden können.

  • 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 beeinträchtigen und die Gesamtverfügbarkeit verringern.

  • Prüfen Sie die Verwendung von Containern und Kubernetes, um die Unterschiede zwischen Umgebungen durch Abstraktion zu überbrücken.

  • Achten Sie darauf, dass CI-/CD-Prozesse und Tools für die Bereitstellung und das Monitoring in allen Cloudumgebungen konsistent sind.

  • Verwenden Sie entweder die Mesh-Topologie oder die gatewaygesteuerte Topologie.

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

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

  • Prüfen Sie bei Verwendung von Kubernetes den Einsatz von ExternalDNS, um Dienste in allen Rechenumgebungen anhand des DNS-Namens erkennbar zu machen.

  • Sie können mit Anycast-IP-basierten Load-Balancern von Google Cloud Anfragen über mehrere Google Cloud-Regionen ausgleichen. Allerdings lassen sich damit keine Nutzeranfragen auf mehrere Clouds verteilen. Für diese Verteilung müssen Sie entweder Round-Robin oder Geo DNS verwenden. Sie können beispielsweise NS1, Oracle® oder Akamai verwenden.

Hybrid- und Multi-Cloud in Analytics

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.

Obwohl Analysesysteme ihre Daten von Transaktionssystemen über API-Abfragen oder Datenbankzugriffe beziehen, sind Analyse- und Transaktionssysteme in den meisten Unternehmen normalerweise getrennt und lose gekoppelt. Der Gedanke hinter dem Hybrid- und Multi-Cloud-Muster für Analysen besteht darin, diese vorhandene Trennung auszunutzen und beide Arten von Arbeitslasten in zwei verschiedenen Rechenumgebungen auszuführen. Dabei werden Rohdaten zuerst aus Arbeitslasten extrahiert, die in der privaten Rechenumgebung ausgeführt werden, und dann zur analytischen Verarbeitung in Google Cloud geladen. Unter Umständen werden einige Ergebnisse dann wieder in Transaktionssysteme eingespeist.

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

Vorteile

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

  • 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 Cloudumgebung. 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.

  • Cloud Storage eignet sich hervorragend zum Erstellen eines Data Lakes.

  • Eingehender Traffic, also die Datenübertragung aus der privaten Rechenumgebung in Google Cloud, ist kostenlos.

Best Practices

Berücksichtigen Sie beim Implementieren des Hybrid-/Multi-Cloud-Musters für Analysen folgende Best Practices:

Edge-Hybridmuster

Für das Ausführen von Arbeitslasten in der Cloud muss Clients 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ügbarkeitsgarantien der Verbindung nicht gewährleisten können.

  • Geschäfte oder 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.

Das Edge-Hybridmuster 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-Hybrideinrichtung stellt die Internetverbindung keine kritische Komponente dar. Sie wird für Verwaltungszwecke und zum Synchronisieren oder Hochladen von Daten (oft asynchron) verwendet, ist jedoch an zeit- oder geschäftskritischen Transaktionen nicht beteiligt.

Edge-Hybridmuster.

Vorteile

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

  • 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 werden, entweder durch Überarbeitung bestimmter Anwendungen oder Ausstattung einiger Edge-Punkte mit zuverlässigeren Internetverbindungen.

  • Eingehender Traffic, also die Datenübertragung von den Edge-Punkten zu Google Cloud, ist kostenlos.

Best Practices

Beachten Sie beim Implementieren des Edge-Hybridmusters folgende Empfehlungen:

  • Wenn die Kommunikation unidirektional ist, verwenden Sie die Topologie für gatewaygesteuerten eingehenden Traffic. Prüfen Sie für die bidirektionale Kommunikation die Topologie für gatewaygesteuerten eingehenden und ausgehenden Traffic.

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

  • Verwenden Sie zur effizienten Verwaltung und Ausführung mehrerer Edge-Punkte eine zentrale Steuerungsebene in der Cloud.

  • Achten Sie darauf, dass die CI-/CD-Prozesse 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, 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 sowie Arbeitslasten zwischen Edge- und Cloudumgebungen verschieben.

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

Muster für redundante Bereitstellungen

In den folgenden Abschnitten werden allgemeine Muster erläutert, die auf einer redundanten Bereitstellung von Anwendungen in mehreren Rechenumgebungen basieren. Bei diesen Mustern stellen Sie dieselben Anwendungen in mehreren Rechenumgebungen bereit, um die Kapazität oder Ausfallsicherheit zu erhöhen.

Umgebungshybridmuster

Beim Umgebungshybridmuster verbleibt die Produktionsumgebung einer Arbeitslast im vorhandenen Rechenzentrum, während andere Nicht-Produktionsumgebungen in die öffentliche Cloud verlagert werden.

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.
  • Für eine Anwendung kann der Zugriff auf Hardwaregeräte erforderlich sein, die nur lokal verfügbar sind. Das kann auch für das Verschieben von Arbeitslasten der Fall sein.

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. Die Einschränkungen, die eine Cloudmigration schwierig machen können, gelten häufig für die Produktionsumgebung und ihre Daten, nicht jedoch für andere Umgebungen.

Das folgende Diagramm zeigt ein typisches Umgebungshybridmuster.

Umgebungshybridmuster.

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
    • Staging- oder Bereitstellungstests: Prüfen, ob das Bereitstellungsverfahren funktioniert.
    • Einsatz in der Produktion

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

Damit Testergebnisse aussagekräftig und auf die Produktionsbereitstellung anwendbar sind, 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.

Entscheidend ist, dass sich die für die Entwicklung und Funktionstests verwendeten Umgebungen auf funktionsunabhängiger Ebene von den anderen Umgebungen durchaus unterscheiden können. Dies fügt sich gut in das Umgebungshybridmuster ein:

  • Mit Kubernetes als gemeinsame Laufzeitebene schaffen Sie eine funktionale Äquivalenz in allen Umgebungen. Damit ist die Portabilität von Arbeitslasten gewährleistet und Unterschiede zwischen Rechenumgebungen werden durch Abstraktion überbrückt.

  • Sie führen Umgebungen für die Produktion, das Staging sowie Leistungs- und Zuverlässigkeitstests in der privaten Rechenumgebung aus und sorgen so für eine funktionale und funktionsunabhängige Äquivalenz.

  • Sie führen Umgebungen für die Entwicklung und Funktionstests in der öffentlichen Cloud aus. Diese Umgebungen entsprechen funktional den übrigen Umgebungen, können sich aber in funktionsunabhängigen Aspekten wie der Leistung unterscheiden.

Vorteile

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

  • Die Umgebungen lassen sich je nach Bedarf automatisch hoch- und herunterfahren. Sie können beispielsweise eine komplette Umgebung für jede Commit- oder Pull-Anfrage bereitstellen, Tests ausführen und dann die Umgebung wieder herunterfahren.

  • Entwicklungs- und Testumgebungen werden häufig abwechselnd verwendet. Wenn Sie VM-Instanzen bei Inaktivität beenden oder Umgebungen nur bei Bedarf bereitstellen, können Sie die Kosten senken.

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

Best Practices

Beachten Sie für die erfolgreiche Implementierung des Umgebungsmusters folgende Empfehlungen:

  • Verwenden Sie die gespiegelte Topologie, um die Kommunikation zwischen Systemen aus verschiedenen Umgebungen zu unterbinden. Da Systeme nicht umgebungsübergreifend kommunizieren müssen, müssen Sie keine gemeinsame Identität einrichten.

  • Verwenden Sie Container und Kubernetes, um Arbeitslasten portabel zu machen und Unterschiede zwischen Umgebungen durch Abstraktion zu überbrücken. Beachten Sie jedoch, dass der Portabilität von Arbeitslasten Grenzen gesetzt sind.

  • Achten Sie darauf, dass die CI-/CD-Prozesse in allen Rechenumgebungen einheitlich sind und dass in den verschiedenen Umgebungen der exakt gleiche Satz von Binärdateien, Paketen oder Containern zur Verfügung gestellt wird.

  • Richten Sie zum Erstellen, Konfigurieren und Ausführen von Arbeitslasten eine gemeinsame Toolchain ein, die in allen Rechenumgebungen funktioniert. Kubernetes bietet eine solche Einheitlichkeit, mit Ausnahme einiger geringfügiger Unterschiede beim Verbinden mit oder Authentifizieren bei Clustern, die in verschiedenen Rechenumgebungen ausgeführt 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. Sie können auch Jenkins selbst in Google Kubernetes Engine (GKE) ausführen.

  • Verwenden Sie für das Logging und Monitoring in Google Cloud und in vorhandenen Cloud-Umgebungen die gleichen Tools. Prüfen Sie den Einsatz von Open-Source-Monitoringsystemen wie Prometheus. Wenn Test- und Produktionsarbeitslasten von verschiedenen Teams verwaltet werden, ist die Verwendung verschiedener Tools möglicherweise kein Problem. Allerdings lassen sich der Schulungsaufwand und die Komplexität durch Nutzung der gleichen Tools reduzieren.

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

Die folgende Tabelle zeigt, welche Google Cloud-Produkte mit gängigen OSS-Produkten kompatibel sind.

OSS-Produkt Kompatibel mit Google Cloud-Produkt
Apache HBase Cloud Bigtable
Apache Beam Dataflow
Apache Hadoop Dataproc
MySQL, PostgreSQL Cloud SQL
Redis Memorystore
Network File System (NFS) Filestore
JMS, Kafka Pub/Sub

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

Idealerweise werden geschäftskritische Systeme so eingerichtet, dass sie einem Notfallszenario standhalten. 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. Dieser Ansatz deckt jedoch nicht das Risiko von Ausfällen ab, die durch menschliche Fehler oder Softwaremängel verursacht werden. Es ist daher von entscheidender Bedeutung, auch einen Notfallwiederherstellungsplan zu haben. Dieser muss gewährleisten, dass Sie Ihre Systeme innerhalb eines zumutbaren Zeitrahmens und mit minimalem Datenverlust wiederherstellen können, wenn diese Arten von Notfällen eintreten.

Ein wesentlicher Bestandteil der Notfallwiederherstellungsplanung besteht darin, Daten häufig an einem anderen Standort zu sichern, um den hinnehmbaren Datenverlust (Recovery Point Objective, RPO) zu minimieren. Wenn Sie außerdem Cold-, Warm- oder Hot-Standby-Systeme an einem zweiten Standort unterhalten, kann die Zeit bis zur Wiederherstellung (Recovery Time Objective, RTO) minimiert werden.

Wenn Sie geschäftskritische Systeme in einem zentralen Rechenzentrum ausführen, können Sie zur Notfallwiederherstellung beispielsweise Standby-Systeme in einem zweiten Rechenzentrum unterhalten, das sich in einer anderen Region befindet. Ein kostengünstigerer Ansatz stellt jedoch die Verwendung einer Rechenumgebung in der öffentlichen Cloud für Failover-Zwecke dar. Dies ist die Idee hinter dem Hybridmuster für Geschäftskontinuität.

Hybridmuster für Geschäftskontinuität.

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

Vorteile

Die Nutzung der öffentlichen Cloud für Geschäftskontinuität bietet eine Reihe von Vorteilen:

  • Da in Google Cloud über ein Dutzend Regionen zur Auswahl stehen, können Sie damit Daten an einem anderen Standort auf demselben Kontinent oder sogar auf einem anderen Kontinent sichern oder replizieren.

  • Beendete VM-Instanzen verursachen lediglich Speicherkosten und sind wesentlich günstiger als ausgeführte VM-Instanzen. Sie können so die Kosten für den Unterhalt von Cold-Standby-Systemen minimieren.

  • Mit dem nutzungsbasierten Abrechnungsmodell von Google Cloud ist gewährleistet, dass Sie nur für die tatsächlich verwendete Speicher- und Rechenkapazität zahlen und Ihre Umgebung für die Notfallwiederherstellung je nach Bedarf vergrößern oder verkleinern können.

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.

  • Entscheiden Sie auf der Grundlage Ihrer RPO- und RTO-Werte, ob die Sicherung von Daten in Google Cloud ausreichend ist oder ob Sie Cold-, Warm- oder Hot-Standby-Systeme unterhalten müssen. In der Anleitung zur Notfallwiederherstellungsplanung finden Sie allgemeine Szenarien und Hinweise zu deren Implementierung in Google Cloud.

  • Verwenden Sie die Handover-Topologie, wenn Sie lediglich Daten sichern. Ziehen Sie andernfalls die gespiegelte Topologie in Betracht.

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

  • Wenn Sie Daten bidirektional über Umgebungen hinweg replizieren, werden Sie unter Umständen mit dem sogenannten Split-Brain-Problem konfrontiert. "Split Brain" bezeichnet eine Situation, in der die Kommunikation zwischen zwei Umgebungen unterbrochen wird und Systeme auf beiden Seiten annehmen, dass die jeweils andere Umgebung nicht mehr verfügbar ist. Die Systeme gehen dann unter Umständen davon aus, dass sie einen exklusiven Zugriff auf Daten haben, was im Endeffekt zu Änderungskonflikten führt. Eine Möglichkeit zur Vermeidung dieser Trennung ist die Einbindung einer dritten Rechenumgebung. Dieser Ansatz ermöglicht einem auf Datenreplikation beruhenden System, ein Quorum abzufragen, bevor eine Datenänderung als sicher eingestuft wird. Alternativ können Sie es zulassen, dass in Konflikt stehende Datenänderungen abgeglichen werden, wenn die Verbindung wiederhergestellt ist.

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

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

  • Sorgen Sie bei Verwendung von Standby-Systemen dafür, dass Arbeitslasten portierbar sind, damit die Systeme in allen Umgebungen einheitlich bleiben. Prüfen Sie den Einsatz von Containern und Kubernetes.

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

  • Nutzen Sie bei Verwendung von Hot-Standby-Systemen Load-Balancer-Module, um ein automatisches Failover einzurichten. Beachten Sie jedoch, dass auch Load-Balancer-Module ausfallen können. Konfigurieren Sie daher DNS vorsichtshalber so, dass Sie Nutzer im Notfall auf Standby-Systeme umleiten können. Verwenden Sie eine relativ kurze Gültigkeitsdauer (Time to Live, TTL), damit DNS-Änderungen schnell weitergegeben werden. Nutzen Sie außerdem das SLA für 100 % Betriebszeit von Cloud DNS.

  • Erwägen Sie für die Notfallwiederherstellung Partnerlösungen wie Actifio oder Commvault.

Cloud Bursting

Internetanwendungen können extremen Nutzungsschwankungen unterliegen, insbesondere solche, die auf Nutzer ausgerichtet sind. 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.

Durch Überdimensionierung von Ressourcen können stoßweise Arbeitslasten zwar auch in einer klassischen, auf einem Rechenzentrum basierenden Rechenumgebung verarbeitet werden, jedoch nur mit erheblichen Kostenaufwand. 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.

Cloud-Bursting-Muster.

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.

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 und gegebenenfalls das automatische Hoch- und Herunterskalieren von Ressourcen in die Wege leiten.

    Leiten Sie eingehende Nutzeranfragen an einen Load-Balancer, der im vorhandenen Rechenzentrum läuft, und lassen Sie den Load-Balancer dann die Anfragen auf die lokalen und Cloud-Ressourcen verteilen.

    Einerseits können Sie mit diesem Ansatz alle Cloudressourcen in Zeiten geringer Aktivität außer Betrieb nehmen. Andererseits kann die Implementierung von Verfahren zur Ressourcenverfolgung die Möglichkeiten von Standardlösungen für Load-Balancer übersteigen und damit die Gesamtkomplexität erhöhen.

  • Alternativ können Sie die Anfragen zuerst an Google Cloud weiterleiten und dann auf Umgebungen verteilen lassen. Da die Load-Balancer von Google Cloud das Load-Balancing und Autoscaling nur für Google Cloud-Ressourcen unterstützen, müssen Sie einen Load-Balancer von Google Cloud mit zusätzlichen benutzerdefinierten Load-Balancing-Verfahren für die Verteilung von Anfragen kombinieren. Auch dieser Ansatz erhöht die Komplexität.

    Ein Load-Balancing mithilfe von Round-Robin-DNS ist nicht zweckmäßig, wenn Sie in Zeiten geringer Nachfrage alle Ressourcen in Google Cloud herunterfahren möchten. Da DNS-Aktualisierungen in der Regel langsam weitergegeben werden, besteht beim Load-Balancing über das DNS die Gefahr, dass Nutzer an Google Cloud weitergeleitet werden, obwohl dort keine Ressourcen zur Verarbeitung ihrer Anfragen verfügbar sind.

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

Vorteile

Dieses 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 in die Cloud prüfen.

  • Sie können die Auslastung und Kosteneffizienz Ihrer privaten Rechenumgebungen möglicherweise erhöhen, da Sie keine Überkapazitäten für Bedarfsspitzen mehr unterhalten müssen.

  • Durch das Cloud-Bursting können Batch-Jobs innerhalb eines angemessenen Zeitraums ausgeführt werden, ohne dass Rechenressourcen überdimensioniert werden müssen.

Best Practices

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

  • Sorgen Sie mithilfe der Mesh-Topologie dafür, dass in der Cloud ausgeführte Arbeitslasten genauso auf Ressourcen zugreifen können wie Arbeitslasten, die in anderen Rechenumgebungen ausgeführt werden. Wenn es Ihre Arbeitslasten erlauben, lassen Sie nur den Zugriff von der Cloud auf die andere Rechenumgebung zu, nicht umgekehrt.

  • Wählen Sie zum Minimieren der Kommunikationslatenz zwischen Umgebungen Google Cloud-Regionen und Interconnect-Standorte aus, die geografisch in der Nähe Ihrer privaten Rechenumgebung liegen.

  • 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 und lassen Sie keinen direkten Zugriff aus dem Internet auf diese Ressourcen zu.

  • Prüfen Sie für weniger zeitkritische Jobs, die nicht länger als 24 Stunden laufen, die Verwendung von VM-Instanzen auf Abruf. Diese sind wesentlich billiger als herkömmliche VM-Instanzen. Bei Ausführung eines Jobs auf einer VM auf Abruf muss jedoch das System den Job automatisch neu starten können.

  • Verwenden Sie Container für die Portabilität von Arbeitslasten. Bei ressourcenintensiven Batcharbeitslasten können Sie diese Container direkt auf Compute Engine-VMs bereitstellen und die Anzahl der VMs mithilfe einer verwalteten Instanzgruppe skalieren. Bei interaktiven Arbeitslasten oder verschiedenen, weniger ressourcenintensiven Arbeitslasten können Sie für das Bereitstellen dieser Container auch Google Kubernetes Engine (GKE) in Verbindung mit dem Cluster Autoscaling verwenden. Beachten Sie jedoch, dass für GKE immer mindestens ein Knoten pro Zone ausgeführt werden muss.

  • Beobachten Sie den Traffic, der von Google Cloud an eine andere Rechenumgebung gesendet wird. Für diesen gelten die Preise für ausgehenden Traffic.

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

  • Ziehen Sie für speicherintensive Arbeitslasten die Einbindung einer Hybrid-Speicherlösung wie Cloudian, Egnyte oder SwiftStack in Betracht.

  • Verwenden Sie das Cloud-Bursting-Muster, um ein CI-System dynamisch zu skalieren. Wenn Sie mit Jenkins arbeiten, können Sie mit dem Google Compute Engine-Plug-in Jenkins-Instanzen in Compute Engine verwalten und automatisch skalieren.

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

Weitere Informationen