Multi-Cloud-Datenbankverwaltung: Architekturen, Anwendungsfälle und Best Practices

Last reviewed 2022-10-28 UTC

In diesem Dokument werden Bereitstellungsarchitekturen, Anwendungsfälle und Best Practices für die Multi-Cloud-Datenbankverwaltung beschrieben. Sie richtet sich an Architekten und Entwickler, die zustandsorientierte Anwendungen in mehreren Clouds und darüber hinweg entwerfen und implementieren.

Multi-Cloud-Anwendungsarchitekturen, die auf Datenbanken zugreifen, sind vom Anwendungsfall abhängig. Keine einzelne zustandsorientierte Anwendungsarchitektur kann alle Multi-Cloud-Anwendungsfälle unterstützen. Die beste Datenbanklösung für einen Cloud-Bursting-Anwendungsfall unterscheidet sich beispielsweise von der besten Datenbanklösung für eine Anwendung, die gleichzeitig in mehreren Cloud-Umgebungen ausgeführt wird.

Für öffentliche Clouds wie Google Cloud gibt es verschiedene Datenbanktechnologien, die sich für bestimmte Multi-Cloud-Anwendungsfälle eignen. Wenn Sie eine Anwendung in mehreren Regionen einer einzelnen öffentlichen Cloud bereitstellen möchten, können Sie eine vom Anbieter verwaltete, multiregionale Datenbank (in einer öffentlichen Cloud) wie Spanner verwenden. Zum Bereitstellen einer Anwendung, die in öffentlichen Clouds portabel ist, ist eine plattformunabhängige Datenbank möglicherweise die bessere Wahl, z. B. PostgreSQL.

In diesem Dokument wird eine Definition für eine zustandsorientierte Datenbankanwendung vorgestellt, worauf eine Anwendungsfallanalyse für mehrere Cloud-Datenbanken folgt. Anschließend wird eine detaillierte Datenbanksystemkategorisierung für Multi-Cloud-Bereitstellungsarchitekturen vorgestellt, die auf den Anwendungsfällen basiert.

Außerdem wird ein Entscheidungsbaum für die Auswahl von Datenbanken vorgestellt, in dem die wichtigsten Entscheidungspunkte für die Auswahl einer geeigneten Datenbanktechnologie beschrieben werden. Am Ende gibt es eine Erörterung der Best Practices für die Multi-Cloud-Datenbankverwaltung.

Wichtige Begriffe und Definitionen

Dieser Abschnitt erklärt die Terminologie und definiert die generische zustandsorientierte Datenbankanwendung, die in diesem Dokument verwendet wird.

Terminologie

• Öffentliche Cloud. Eine öffentliche Cloud bietet eine mehrmandantenfähige Infrastruktur (im Allgemeinen global) und Dienste, mit denen Kunden ihre Produktionsarbeitslasten ausführen können. Google Cloud ist eine öffentliche Cloud, die viele verwaltete Dienste bietet, darunter GKE, GKE Enterprise und Verwaltete Datenbanken.
• Hybrid-Cloud. Eine Hybrid-Cloud ist eine Kombination aus einer öffentlichen Cloud und einem oder mehreren lokalen Rechenzentren. Hybrid-Cloud-Kunden können ihre lokalen Dienste mit zusätzlichen Diensten einer öffentlichen Cloud kombinieren.
• Multi-Cloud. Eine Multi-Cloud ist eine Kombination aus mehreren öffentlichen Clouds und lokalen Rechenzentren. Hybrid-Clouds sind eine Teilmenge der Multi-Clouds.
• Bereitstellungsstandort. Ein Infrastrukturstandort ist ein physischer Standort, der Arbeitslasten bereitstellen und ausführen kann, einschließlich Anwendungen und Datenbanken. In Google Cloud sind Bereitstellungsstandorte z. B. Zonen und Regionen. Auf abstrakter Ebene sind eine Region oder Zone einer öffentlichen Cloud sowie ein lokales Rechenzentrum Bereitstellungsstandorte.

Zustandsorientierte Datenbankanwendungen

Zum Definieren von Multi-Cloud-Anwendungsfällen wird in diesem Dokument eine generische zustandsorientierte Datenbankanwendungsarchitektur verwendet, wie im folgenden Diagramm dargestellt.

Das Diagramm zeigt die folgenden Komponenten:

• Datenbank. Eine Datenbank kann eine Einzelinstanz-, Multi-Instanz- oder eine verteilte Datenbank sein, die auf Computing-Knoten bereitgestellt oder als cloudverwalteter Dienst verfügbar ist.
• Anwendungsdienste. Diese Dienste werden als eine Anwendung kombiniert, die die Geschäftslogik implementiert. Anwendungsdienste können Folgendes sein:
  • Mikrodienste in Kubernetes.
  • Grobe Prozesse, die auf einer oder mehreren virtuellen Maschinen ausgeführt werden.
  • Eine monolithische Anwendung auf einer großen virtuellen Maschine.
  • Serverloser Code in Cloud Functions oder Cloud Run. Einige Anwendungsdienste können auf die Datenbank zugreifen. Es ist möglich, jeden Anwendungsdienst mehrmals bereitzustellen. Jede Bereitstellung eines Anwendungsdienstes ist eine Instanz dieses Anwendungsdienstes.
• Anwendungsclients. Anwendungsclients greifen auf die Funktionalität zu, die von Anwendungsdiensten bereitgestellt wird. Anwendungsclients können Folgendes sein:
  • Bereitgestellte Clients, bei denen Code auf einem Computer, Laptop oder Smartphone ausgeführt wird.
  • Nicht bereitgestellte Clients, bei denen der Clientcode in einem Browser ausgeführt wird. Anwendungsclientinstanzen greifen immer auf eine oder mehrere Anwendungsdienstinstanzen zu.

Im Kontext einer Multi-Cloud-Datenbankdiskussion besteht die Architekturabstraktion einer zustandsorientierten Anwendung aus einer Datenbank, Anwendungsdiensten und Anwendungsclients. In einer Implementierung einer Anwendung können verschiedene Faktoren variieren, z. B. die Verwendung von Betriebssystemen oder Programmiersprachen. Diese Details wirken sich jedoch nicht auf die Multi-Cloud-Datenbankverwaltung aus.

Warteschlangen und Dateien als Datenspeicherdienste

Es gibt viele Persistenzressourcen, die es Anwendungsdiensten ermöglichen, Daten aufzubewahren. Dazu gehören Datenbanken, Warteschlangen und Dateien. Jede Persistenzressource bietet Speicherdatenmodelle und Zugriffsmuster, die für diese Modelle spezialisiert sind. Obwohl Warteschlangen, Nachrichtensysteme und Dateisysteme von Anwendungen verwendet werden, liegt der Schwerpunkt des folgenden Abschnitts auf Datenbanken.

Obwohl die gleichen Überlegungen für Faktoren wie Bereitstellungsstandort, Freigabe von Status, synchrone und asynchrone Replikation für Multi-Cloud-Datenbanken auch auf Warteschlangen und Dateien anwendbar sind, wird in diesem Dokument nicht auf dieses Diskussion eingegangen.

Netzwerk

In der Architektur einer generischen zustandsorientierten Anwendung (wird wieder im folgenden Diagramm dargestellt) stellt jeder Pfeil zwischen den Komponenten eine Kommunikationsbeziehung über eine Netzwerkverbindung dar, z. B. einen Anwendungsclient, der auf einen Anwendungsdienst zugreift.

Eine Verbindung kann innerhalb einer Zone oder über Zonen, Regionen oder Clouds hinweg bestehen. Verbindungen können zwischen einer beliebigen Kombination von Bereitstellungsstandorten vorhanden sein. In Multi-Cloud-Umgebungen ist das cloudübergreifende Netzwerk ein wichtiger Aspekt und Sie können verschiedene Optionen nutzen. Weitere Informationen zum cloudübergreifenden Netzwerk in mehreren Clouds finden Sie unter Verbindung zu Google Cloud herstellen: Informationen zu den Netzwerkoptionen.

In den Anwendungsfällen in diesem Dokument wird Folgendes angenommen:

• Eine sichere Netzwerkverbindung zwischen den Clouds besteht.
• Die Datenbanken und ihre Komponenten können miteinander kommunizieren.

Aus nicht funktionaler Sicht kann sich die Größe des Netzwerks, also der Durchsatz und die Latenz, auf die Latenz und den Durchsatz der Datenbank auswirken. Aus funktionaler Sicht hat das Netzwerk im Allgemeinen keine Auswirkungen.

Multi-Cloud-Datenbank – Anwendungsfälle

In diesem Abschnitt finden Sie eine Auswahl der gängigsten Anwendungsfälle für die Multi-Cloud-Datenbankverwaltung. Bei diesen Anwendungsfällen wird davon ausgegangen, dass eine sichere Netzwerkverbindung zwischen den Clouds und den Datenbankknoten besteht.

Anwendungsmigration

Im Kontext der Multi-Cloud-Datenbankverwaltung bezieht sich die Anwendungsmigration auf die Migration einer Anwendung, aller Anwendungsdienste und der Datenbank von der aktuellen Cloud in eine Ziel-Cloud. Es gibt viele Gründe, warum ein Unternehmen eine Anwendung migriert, beispielsweise um eine Wettbewerbssituation mit dem Cloud-Anbieter zu vermeiden, eine Technologie zu modernisieren oder die Gesamtbetriebskosten (TCO) zu senken.

Bei der Anwendungsmigration besteht die Absicht darin, die Produktion in der aktuellen Cloud zu beenden und in der Ziel-Cloud nach Abschluss der Migration fortzusetzen. Die Anwendungsdienste müssen in der Ziel-Cloud ausgeführt werden. Zur Implementierung der Dienste kann ein Lift-and-Shift-Ansatz verwendet werden. Bei diesem Ansatz wird derselbe Code in der Ziel-Cloud bereitgestellt. Für die erneute Implementierung des Dienstes können die modernen Cloud-Technologien verwendet werden, die in der Ziel-Cloud verfügbar sind.

Aus Sicht der Datenbank sollten Sie folgende alternative Möglichkeiten für die Anwendungsmigration in Betracht ziehen:

• Datenbank-Lift-and-Shift: Wenn dieselbe Datenbank-Modul in der Ziel-Cloud verfügbar ist, ist es möglich, die Datenbank per Lift-and-Shift zu verschieben, um eine identische Bereitstellung in der Ziel-Cloud zu erstellen.
• Datenbank verschieben zu verwaltetem Äquivalent: Eine selbstverwaltete Datenbank kann zu einer verwalteten Version desselben Datenbank-Moduls migriert werden, wenn die Ziel-Cloud diese bereitstellt.
• Datenbankmodernisierung: Verschiedene Clouds bieten unterschiedliche Datenbanktechnologien. Von einem Cloud-Anbieter verwaltete Datenbanken können Vorteile wie striktere Service Level Agreements (SLAs), Skalierbarkeit und automatische Notfallwiederherstellung bieten.

Unabhängig von der Bereitstellungsstrategie ist die Datenbankmigration ein Prozess, der etwas Zeit in Anspruch nimmt, da Daten aus der aktuellen Cloud in die Ziel-Cloud verschoben werden müssen. Es ist zwar möglich, einem Export- und Importansatz zu folgen, der Ausfallzeiten mit sich bringt, aber die Migration mit minimalen oder keinen Ausfallzeiten wird empfohlen. Dieser Ansatz minimiert die Ausfallzeiten der Anwendung und hat die geringsten Auswirkungen auf ein Unternehmen und seine Kunden.

Notfallwiederherstellung

Als Notfallwiederherstellung wird die Fähigkeit einer Anwendung bezeichnet, Dienste während eines Regionsausfalls weiterhin für Anwendungsclients bereitzustellen. Um eine Notfallwiederherstellung zu gewährleisten, muss eine Anwendung in mindestens zwei Regionen bereitgestellt werden und jederzeit ausgeführt werden können. In der Produktion wird die Anwendung in der primären Region ausgeführt. Wenn jedoch ein Ausfall auftritt, wird eine sekundäre Region zur primären Region. Im Folgenden sind verschiedene Modelle für die Bereitschaft bei der Notfallwiederherstellung aufgeführt:

• Hot-Standby. Die Anwendung wird in zwei oder mehr Regionen (primär und sekundär) bereitgestellt und in jeder Region funktioniert sie vollständig. Wenn die primäre Region ausfällt, kann die Anwendung in der sekundären Region den Anwendungsclient-Traffic sofort übernehmen.
• Cold-Standby. Die Anwendung wird in der primären Region ausgeführt, ist jedoch für den Start in einer sekundären Region bereit, wird aber nicht ausgeführt. Wenn die primäre Region ausfällt, wird die Anwendung in der sekundären Region gestartet. Ein Anwendungsausfall tritt auf, bis die Anwendung ausgeführt wird und alle Anwendungsdienste für Anwendungsclients bereitstellen kann.
• Kein Standby. In diesem Modell ist der Anwendungscode bereit für die Bereitstellung, ist aber noch nicht in der sekundären Region bereitgestellt (und verwendet daher keine bereitgestellten Ressourcen). Wenn eine primäre Region ausfällt, muss sich die erste Bereitstellung der Anwendung in der sekundären Region befinden. Bei dieser Bereitstellung befindet sich die Anwendung im selben Zustand wie beim Cold-Standby, was bedeutet, dass sie gestartet werden muss. Bei diesem Ansatz ist der Anwendungsausfall im Vergleich zum Cold-Standby-Fall länger, da die Anwendungsbereitstellung zuerst erfolgen muss, einschließlich der Erstellung von Cloud-Ressourcen.

Aus Sicht der Datenbank entsprechen die in der obigen Liste beschriebenen Bereitschaftsmodelle den folgenden Datenbankansätzen:

• Datenbank mit transaktionaler Synchronisierung. Diese Datenbank entspricht dem Hot-Standby-Modell. Für jede Transaktion in der primären Region wird in synchroner Koordination ein Commit in einer sekundären Region durchgeführt. Wenn die sekundäre Region während eines Ausfalls zur primären Region wird, ist die Datenbank konsistent und sofort verfügbar. In diesem Modell sind das Recovery Point Objective (RPO) und das Recovery Time Objective (RTO) beide null.
• Asynchron replizierte Datenbank. Diese Datenbank entspricht ebenfalls dem Hot-Standby-Modell. Da die Datenbankreplikation von der primären Region in die sekundäre Region asynchron ist, besteht die Möglichkeit, dass einige Transaktionen in die sekundäre Region repliziert werden, wenn die primäre Region ausfällt. Während die Datenbank in der sekundären Region für die Produktionslast bereit ist, enthält sie möglicherweise nicht die neuesten Daten. Aus diesem Grund kann in der Anwendung ein Verlust von Transaktionen auftreten, die nicht wiederhergestellt werden können. Darum hat dieser Ansatz ein RTO von null, aber das RPO ist größer als null.
• Inaktive Datenbank. Diese Datenbank entspricht dem Cold-Standby-Modell. Die Datenbank wird ohne Daten erstellt. Wenn die primäre Region ausfällt, müssen Daten in die inaktive Datenbank geladen werden. Um diese Aktion zu aktivieren, muss eine regelmäßige Sicherung in der primären Region erstellt und in die sekundäre Region übertragen werden. Die Sicherung kann vollständig oder inkrementell sein, je nachdem, was das Datenbankmodul unterstützt. In beiden Fällen wird die Datenbank auf die letzte Sicherung zurückgesetzt und aus Sicht der Anwendung können viele Transaktionen im Vergleich zur primären Region verloren gehen. Dieser Ansatz kann zwar kostengünstig sein, wobei jedoch durch das Risiko besteht, dass alle Transaktionen seit der letzten verfügbaren Sicherung verloren gehen, wenn der Datenbankstatus nicht aktuell ist.
• Keine Datenbank. Dieses Modell entspricht dem Fall Kein Standby. In der sekundären Region ist keine Datenbank installiert. Wenn die primäre Region ausfällt, muss eine Datenbank erstellt werden. Nachdem die Datenbank erstellt wurde, wie im Fall der inaktiven Datenbank, muss sie mit Daten geladen werden, bevor sie für die Anwendung verfügbar ist.

Die in diesem Dokument erläuterten Ansätze zur Notfallwiederherstellung gelten auch, wenn eine primäre und eine sekundäre Cloud anstelle einer primären und sekundären Region verwendet werden. Der Hauptunterschied besteht darin, dass aufgrund der Netzwerkheterogenität zwischen Clouds die Latenz zwischen den Clouds im Vergleich zur Netzwerkentfernung zwischen den Regionen einer Cloud zunehmen kann.

Die Wahrscheinlichkeit, dass eine ganze Cloud ausfällt, ist geringer als die Wahrscheinlichkeit, dass eine Region ausfällt. Für Unternehmen kann es jedoch nützlich sein, eine Anwendung in zwei Clouds bereitzustellen. Dieser Ansatz kann dabei helfen, ein Unternehmen vor Ausfällen zu schützen oder Geschäfts- oder Branchenvorschriften zu erfüllen.

Ein weiterer Ansatz für die Notfallwiederherstellung besteht darin, eine primäre und eine sekundäre Region sowie eine primäre und eine sekundäre Cloud zu haben. Dieser Ansatz ermöglicht Unternehmen, den besten Prozess zur Notfallwiederherstellung zu finden, um auf einen Ausfall reagieren zu können. Damit eine Anwendung ausgeführt werden kann, kann je nach Schweregrad des Ausfalls entweder eine sekundäre Region oder eine sekundäre Cloud verwendet werden.

Cloud-Bursting-Muster

Cloud Bursting bezieht sich auf eine Konfiguration, die das Hochskalieren des Anwendungsclient-Traffics über verschiedene Bereitstellungsstandorte hinweg ermöglicht. Ein Anwendungs-Bursting tritt auf, wenn der Bedarf für die Kapazität zunimmt und ein Standby-Standort zusätzliche Kapazität bietet. Ein primärer Standort unterstützt den regulären Traffic, während ein Standby-Standort zusätzliche Kapazität bietet, falls der Anwendungsclient-Traffic über die Kapazitäten des primären Standorts hinausgeht. Sowohl am primären Standort als auch am Standby-Standort sind Anwendungsdienstinstanzen bereitgestellt.

Cloud Bursting ist über mehrere Clouds hinweg implementiert, wobei eine Cloud die primäre Cloud und eine zweite die Standby-Cloud ist. Es wird in einem Hybrid-Cloud-Kontext verwendet, um eine begrenzte Anzahl von Computing-Ressourcen in lokalen Rechenzentren mit elastischen Cloud-Computing-Ressourcen in einer öffentlichen Cloud zu erweitern.

Für die Datenbankunterstützung sind folgende Optionen verfügbar:

• Bereitstellung am primären Standort. In dieser Bereitstellung wird die Datenbank nur am primären Standort und nicht am Standby-Standort bereitgestellt. Wenn ein Anwendungs-Bursting auftritt, greift die Anwendung am Standby-Standort auf die Datenbank am primären Standort zu.
• Bereitstellung am primären und am Standby-Standort. Diese Bereitstellung unterstützt sowohl den primären Standort als auch den Standby-Standort. Eine Datenbankinstanz wird an beiden Standorten bereitgestellt und von den Anwendungsdienstinstanzen dieses Standorts aufgerufen, insbesondere beim Bursting. Wie in Notfallwiederherstellung in Clouds und über Clouds hinweg können die beiden Datenbanken transaktional oder asynchron synchronisiert werden. Bei der asynchronen Synchronisierung kann es zu einer Verzögerung kommen. Wenn Aktualisierungen am Standby-Standort durchgeführt werden, müssen diese Aktualisierungen an den primären Standort zurückübertragen werden. Wenn an beiden Standorten gleichzeitige Aktualisierungen möglich sind, muss eine Konfliktlösung implementiert werden.

Cloud Bursting ist ein häufiger Anwendungsfall in Hybrid-Clouds, um die Kapazität in lokalen Rechenzentren zu erhöhen. Es ist auch ein Ansatz, der in öffentlichen Clouds verwendet werden kann, wenn Daten innerhalb eines Landes bleiben müssen. In Situationen, in denen eine öffentliche Cloud nur eine Region in einem Land hat, ist es möglich, ein Bursting in eine Region einer anderen öffentlichen Cloud im selben Land durchzuführen. Dadurch wird gewährleistet, dass die Daten innerhalb des Landes bleiben und gleichzeitig Ressourceneinschränkungen in der Region der öffentlichen Cloud-Regionen behandelt werden.

Nutzung branchenführender Cloud-Dienste

Einige Anwendungen erfordern spezialisierte Cloud-Dienste und -Produkte, die nicht in einer einzelnen Cloud verfügbar sind. Beispielsweise kann eine Anwendung die Geschäftslogikverarbeitung von Geschäftsdaten in der einen Cloud und Analysen der Geschäftsdaten in einer anderen Cloud ausführen. In diesem Anwendungsfall werden die Teile der Geschäftslogikverarbeitung und die Analyseteile der Anwendung in verschiedenen Clouds bereitgestellt.

Aus Sicht der Datenverwaltung gelten folgende Anwendungsfälle:

• Partitionierte Daten. Jeder Teil der Anwendung hat eine eigene Datenbank (separate Partition) und keine der Datenbanken sind direkt miteinander verbunden. Die Anwendung, die die Daten verwaltet, schreibt alle Daten, die in beiden Datenbanken (Partitionen) verfügbar sein müssen, zweimal.
• Asynchron replizierte Datenbank. Wenn Daten aus einer Cloud in der anderen Cloud verfügbar sein müssen, ist möglicherweise eine asynchrone Replikationsbeziehung geeignet. Wenn beispielsweise eine Analyseanwendung dasselbe Dataset oder einen Teil des Datasets für eine Geschäftsanwendung erfordert, kann letztere zwischen den Clouds repliziert werden.
• Datenbank mit transaktionaler Synchronisierung. Mit diesen Arten von Datenbanken können Sie Daten für beide Teile der Anwendung verfügbar machen. Jede Aktualisierung jeder Anwendung ist transaktional konsistent und steht sofort für beide Datenbanken (Partitionen) zur Verfügung. Transaktional synchronisierte Datenbanken dienen praktisch als eine einzelne verteilte Datenbank.

Verteilte Dienste

Ein verteilter Dienst wird an zwei oder mehr Bereitstellungsstandorten bereitgestellt und ausgeführt. Es ist möglich, alle Dienstinstanzen an allen Bereitstellungsstandorten bereitzustellen. Alternativ ist es möglich, einige Dienste an allen Standorten und einige nur an einem der Standorte bereitzustellen, abhängig von Faktoren wie der Hardwareverfügbarkeit oder der erwarteten begrenzten Last.

Daten in einer transaktional synchronisierten Datenbank sind an allen Standorten konsistent. Daher ist eine solche Datenbank die beste Option, um Dienstinstanzen an allen Bereitstellungsstandorten bereitzustellen.

Wenn Sie eine asynchrone replizierte Datenbank verwenden, besteht das Risiko, dass dasselbe Datenelement an zwei Bereitstellungsstandorten gleichzeitig geändert wird. Eine Strategie zur Konfliktlösung muss implementiert werden, um zu bestimmen, welche der beiden in Konflikt stehenden Änderungen der endgültige konsistente Zustand ist. Es ist zwar möglich, eine Konfliktlösung zu implementieren, dies ist jedoch nicht immer einfach und manchmal ist ein manuelles Eingreifen erforderlich, um die Daten wieder in einen konsistenten Zustand zu versetzen.

Verlagerung verteilter Dienste und Failover

Wenn eine ganze Cloud-Region ausfällt, wird eine Notfallwiederherstellung eingeleitet. Wenn ein einzelner Dienst in einer zustandsorientierten Datenbankanwendung ausfällt (nicht die Region oder die gesamte Anwendung), muss der Dienst wiederhergestellt und neu gestartet werden.

Ein erster Ansatz für die Notfallwiederherstellung besteht darin, den fehlgeschlagenen Dienst an seinem ursprünglichen Bereitstellungsort neu zu starten (ein Neustart vor Ort-Ansatz). Technologien wie Kubernetes starten Dienste automatisch basierend auf ihrer Konfiguration neu.

Wenn dieser Ansatz jedoch nicht erfolgreich ist, können Sie alternativ den Dienst an einem sekundären Standort neu starten. Für den Dienst wird ein Failover von seinem primären Standort zu einem sekundären Standort ausgeführt. Wenn die Anwendung als eine Reihe von verteilten Diensten bereitgestellt wird, kann der Failover eines einzelnen Dienstes dynamisch erfolgen.

Aus der Sicht der Datenbank erfordert der Neustart des Dienstes am ursprünglichen Bereitstellungsstandort keine bestimmte Datenbankbereitstellung. Wenn ein Dienst an einen alternativen Bereitstellungsstandort verschoben wird und der Dienst auf die Datenbank zugreift, gelten die gleichen Bereitschaftsmodelle, die zuvor unter Verteilte Dienste in diesem Dokument erläutert wurden.

Wenn ein Dienst vorübergehend verschoben wird und für ein Unternehmen während der Verschiebung höhere Latenzen akzeptabel sind, könnte der Dienst über Bereitstellungsstandorte hinweg auf die Datenbank zugreifen. Obwohl der Dienst verschoben wurde, greift er weiterhin auf die Datenbank zu, wie er es vom ursprünglichen Bereitstellungsstandort aus tun würde.

Kontextabhängige Bereitstellung

Grundsätzlich enthält eine einzelne Anwendungsbereitstellung für alle Anwendungsclients alle Anwendungsdienste und Datenbanken. Es gibt jedoch einige außergewöhnliche Anwendungsfälle. Eine Bereitstellung einer einzelnen Anwendung kann nur einen Teil der Clients bereitstellen (basierend auf spezifischen Kriterien). Dies bedeutet, dass mehrere Anwendungsbereitstellungen erforderlich sind. Jede Bereitstellung stellt einen anderen Teil der Clients bereit, während alle Bereitstellungen zusammen alle Clients bereitstellen.

Beispielanwendungsfälle für eine kontextabhängige Bereitstellung:

• Bei der Bereitstellung einer mehrmandantenfähigen Anwendung, für die eine Anwendung für alle kleinen Mandanten bereitgestellt wird, wird jeweils für 10 mittlere Mandanten eine weitere Anwendung und für jeden Premiummandanten eine Anwendung bereitgestellt.
• Wenn Kunden separiert werden müssen, z. B. Geschäftskunden und Behörden.
• Wenn Entwicklungs-, Staging- und Produktionsumgebungen getrennt werden müssen

Aus Sicht der Datenbank ist es möglich, eine Datenbank für jede Anwendungsbereitstellung in einer 1:1-Bereitstellungsstrategie bereitzustellen. Wie im folgenden Diagramm dargestellt, ist diese Strategie ein einfacher Ansatz, bei dem partitionierte Daten erstellt werden, da jede Bereitstellung ein eigenes Dataset hat.

Das obige Diagramm zeigt Folgendes:

• Eine Einrichtung mit drei Bereitstellungen einer Anwendung.
• Jedes Dataset hat eine eigene Datenbank.
• Zwischen den Bereitstellungen werden keine Daten geteilt.

In vielen Fällen ist eine 1:1-Bereitstellung die geeignetste Strategie, es gibt jedoch Alternativen.

Bei Mehrmandantenfähigkeit können Mandanten verschoben werden. Ein kleiner Mandant kann sich in einen mittleren Mandanten umwandeln und muss in eine andere Anwendung verschoben werden. In diesem Fall ist für separate Datenbankbereitstellungen eine Datenbankmigration erforderlich. Wenn eine verteilte Datenbank bereitgestellt und von allen Bereitstellungen gleichzeitig verwendet wird, befinden sich alle Mandantendaten in einem einzigen Datenbanksystem. Aus diesem Grund erfordert das Verschieben eines Mandanten zwischen Datenbanken keine Datenbankmigration. Das folgende Diagramm zeigt ein Beispiel für diese Art von Datenbank:

Das obige Diagramm zeigt Folgendes:

• Drei Bereitstellungen einer Anwendung.
• Alle Bereitstellungen nutzen eine einzige verteilte Datenbank.
• Anwendungen können auf alle Daten in jeder Bereitstellung zugreifen.
• Es ist keine Datenpartitionierung implementiert.

Wenn Mandanten im Rahmen von Lebenszyklusvorgängen häufig Mandanten verschieben, kann die Datenbankreplikation eine nützliche Alternative sein. Bei diesem Ansatz werden Mandantendaten vor der Mandantenmigration zwischen Datenbanken repliziert. In diesem Fall werden unabhängige Datenbanken für verschiedene Anwendungsbereitstellungen verwendet und nur für die Replikation unmittelbar vor und während der Mandantenmigration eingerichtet. Das folgende Diagramm zeigt eine temporäre Replikation zwischen zwei Anwendungsbereitstellungen während einer Mandantenmigration:

Das obige Diagramm zeigt drei Bereitstellungen einer Anwendung mit drei separaten Datenbanken. Diese enthalten die Daten, die mit den einzelnen Bereitstellungen verknüpft sind. Für die Migration von Daten von einer Datenbank in eine andere kann eine temporäre Datenbankmigration eingerichtet werden.

Anwendungsportabilität

Mit der Portabilität von Anwendungen wird sichergestellt, dass eine Anwendung an verschiedenen Bereitstellungsstandorten bereitgestellt werden kann, insbesondere in verschiedenen Clouds. Diese Portabilität gewährleistet, dass eine Anwendung jederzeit migriert werden kann, ohne dass eine migrationsspezifische Überarbeitung oder zusätzliche Anwendungsentwicklung erforderlich ist, um sich auf eine Anwendungsmigration vorzubereiten.

Für die Sicherstellen der Portabilität von Anwendungen können Sie einen der folgenden Ansätze verwenden, die weiter unten in diesem Abschnitt beschrieben werden:

• Systembasierte Portabilität
• API-Kompatibilität
• Funktionsbasierte Portabilität

Die systembasierte Portabilität verwendet die gleichen technischen Komponenten, die in allen möglichen Bereitstellungen verwendet werden. Damit systembasierte Portabilität gewährleistet ist, muss jede Technologie an allen potenziellen Bereitstellungsstandorten verfügbar sein. Wenn eine Datenbank wie PostgreSQL beispielsweise ein Kandidat ist, muss ihre Verfügbarkeit an allen potenziellen Bereitstellungsstandorten für den erwarteten Zeitraum überprüft werden. Dasselbe gilt für alle anderen Technologien, z. B. Programmiersprachen und Infrastrukturtechnologien. Wie im folgenden Diagramm dargestellt, werden bei diesem Ansatz eine Reihe von gemeinsamen Funktionen für alle Bereitstellungsstandorte basierend auf Technologie eingerichtet.

Das obige Diagramm zeigt eine portable Anwendungsbereitstellung, bei der die Anwendung an jedem Bereitstellungsstandort genau dasselbe Datenbanksystem erwartet. Da an jedem Standort dasselbe Datenbanksystem verwendet wird, ist die Anwendung portabel. Die Anwendung kann davon ausgehen, dass genau dasselbe Datenbanksystem in der gesamten Bereitstellung verwendet wird. Daher kann von genau derselben Datenbanksystemschnittstelle und demselben Verhalten ausgegangen werden.

Im Kontext von Datenbanken verwendet der Client im API-Kompatibilitätssystem eine bestimmte Datenbankzugriffsbibliothek (z. B. eine MySQL-Clientbibliothek), um eine Verbindung zu einer beliebigen verfügbaren konformen Implementierung in einer Cloud-Umgebung herzustellen. Das folgende Diagramm veranschaulicht die API-Kompatibilität.

Das obige Diagramm zeigt die Portabilität von Anwendungen, die auf der Datenbanksystem-API anstelle des Datenbanksystems basiert. Die Datenbanksysteme können zwar an jedem Standort unterschiedlich sein, die API ist jedoch identisch und bietet die gleiche Funktionalität. Die Anwendung ist portabel, da sie an jedem Standort dieselbe API annehmen kann, auch wenn das zugrunde liegende Datenbanksystem eine andere Datenbanktechnologie ist.

Bei der funktionsbasierten Portabilität können verschiedene Technologien in verschiedenen Clouds verwendet werden, die dieselbe Funktionalität bieten. Sie können beispielsweise die Verwendung von Datenbanken auf das relationale Modell beschränken. Da jedes relationale Datenbanksystem die Anwendung unterstützen kann, können verschiedene Datenbanksysteme in verschiedenen Versionen in verschiedenen Clouds verwendet werden, ohne die Portabilität der Anwendung zu beeinträchtigen. Ein Nachteil bei der funktionsbasierten Portabilität ist, dass nur die Teile des Datenbankmodells verwendet werden können, die von allen relationalen Datenbanksystemen unterstützt werden. Anstatt eines Datenbanksystems, das mit allen Clouds kompatibel ist, muss ein Datenbankmodell verwendet werden. Das folgende Diagramm zeigt eine Beispielarchitektur für die funktionsbasierte Portabilität.

Wie das vorherige Diagramm zeigt, können die Datenbanksystem-API und das Datenbanksystem an jedem Standort unterschiedlich sein. Für Portabilität sollte die Anwendung nur jene Teile der einzelnen Datenbanksysteme und der APIs verwenden, die an den einzelnen Standorten verfügbar sind. Da an jedem Standort nur ein Teil jedes Datenbanksystems allgemein verfügbar ist, muss die Anwendung seine Nutzung auf diesen Teil beschränken.

Damit alle Optionen in diesem Abschnitt portabel sind, muss die vollständige Architektur kontinuierlich an allen Zielstandorten bereitgestellt werden. Für diese Bereitstellungen müssen alle Einheiten- und Systemtestfälle ausgeführt werden. Dies sind grundlegende Anforderungen für Änderungen an Infrastrukturen und Technologien, die frühzeitig erkannt und berücksichtigt werden müssen.

Verhinderung von Anbieterabhängigkeit

Durch die Verhinderung von Anbieterabhängigkeit können Sie das Risiko einer Abhängigkeit von einer bestimmten Technologie und einem bestimmten Anbieter minimieren. Das ist teilweise vergleichbar mit der Portabilität von Anwendungen. Die Verhinderung der Anbieterabhängigkeit gilt für alle verwendeten Technologien und nicht nur für Cloud-Dienste. Wenn MySQL beispielsweise als Datenbanksystem verwendet und auf virtuellen Maschinen in Clouds installiert wird, besteht aus Cloud-Sicht keine Abhängigkeit, aber es besteht eine Abhängigkeit von MySQL. Bei einer Anwendung, die über mehrere Clouds hinweg portabel ist, sind möglicherweise weiterhin Technologien erforderlich, die von anderen Anbietern als der Cloud bereitgestellt werden.

Um Anbieterabhängigkeit zu verhindern, müssen alle Technologien ersetzbar sein. Aus diesem Grund ist eine vollständige, strukturierte Abstraktion aller Anwendungsfunktionen erforderlich, damit jeder Anwendungsdienst auf einer anderen Technologiebasis neu implementiert werden kann, ohne dass sich dies auf die Implementierung der Anwendung auswirkt. Aus Sicht der Datenbank kann diese Abstraktion durch die Trennung der Verwendung eines Datenbankmodells von einem bestimmten Datenbankverwaltungssystem erfolgen.

Vorhandenes Datenbankverwaltungssystem für die Produktion

Viele Multi-Cloud-Anwendungen werden mit integrierten Datenbanksystemen entwickelt. Viele Unternehmen entwickeln diese im Rahmen der Anwendungsmodernisierungsstrategie. Bei der Entwicklung dieser Anwendungen wird davon ausgegangen, dass die neu entwickelte und implementierte Anwendung auf die vorhandenen Datenbanken zugreift.

Es gibt viele Gründe, warum vorhandene Datenbanken nicht unbedingt Teil einer Modernisierung sind. Möglicherweise werden bestimmte Features verwendet, die in anderen Datenbanksystemen nicht verfügbar sind. Ein Unternehmen hat möglicherweise Datenbanken mit komplexen und etablierten Verwaltungsprozessen, was einen Wechsel zu einem anderen System unpraktisch oder zu teuer macht. Oder ein Unternehmen möchte eine Anwendung in der ersten Phase und die Datenbank in der zweiten Phase modernisieren.

Wenn ein Unternehmen ein vorhandenes Datenbanksystem verwendet, muss der Entwickler der Multi-Cloud-Anwendung entscheiden, ob es die einzige verwendete Datenbank ist oder ob ein anderes Datenbanksystem für eine andere Bereitstellungsstandorte hinzugefügt werden muss. Wenn beispielsweise eine Datenbank lokal verwendet wird und die Anwendung auch in Google Cloud ausgeführt werden muss, müssen sie überprüfen, ob die in Google Cloud bereitgestellten Anwendungsdienste auf die lokale Datenbank zugreifen. Oder wenn Sie eine zweite Datenbank sowohl in Google Cloud als auch für die lokal ausgeführten Anwendungsdienste bereitstellen möchten.

Wenn eine zweite Datenbank in Google Cloud bereitgestellt wird, können die Anwendungsfälle den Anwendungsfällen entsprechen, die unter Cloud Bursting oder Verteilte Dienste beschrieben werden. In beiden Fällen gilt die gleiche Datenbankdiskussion wie in diesen Abschnitten. Sie ist jedoch auf die regionenübergreifende Funktionalität beschränkt, die die vorhandene lokale Datenbank unterstützen kann, z. B. Synchronisierung und Replikation.

Bereitstellungsmuster

Die in diesem Dokument beschriebenen Anwendungsfälle werfen eine häufig gestellte Frage aus Sicht der Datenbank auf: Wenn sich Datenbanken an mehreren Bereitstellungsorten befinden, in welcher Beziehung stehen sie?

Die wichtigsten Arten von Beziehungen (Bereitstellungsmuster), die im nächsten Abschnitt behandelt werden, sind:

• Partitionierung ohne datenbankübergreifende Abhängigkeit
• Asynchrone unidirektionale Replikation
• Bidirektionale Replikation mit Konfliktlösung
• Vollständig aktiv/aktiv-synchronisiertes verteiltes System

Es ist möglich, jeden Anwendungsfall in diesem Dokument einem oder mehreren der vier Bereitstellungsmuster zuzuordnen.

In der folgenden Erläuterung wird davon ausgegangen, dass Clients direkt auf Anwendungsdienste zugreifen. Je nach Anwendungsfall ist möglicherweise ein Load-Balancer erforderlich, um den Clientzugriff dynamisch zu Anwendungen zu leiten, wie im folgenden Diagramm dargestellt.

Im obigen Diagramm leitet ein Cloud-Load-Balancer Clientaufrufe an einen der verfügbaren Standorte weiter. Der Load-Balancer sorgt dafür, dass Load-Balancing-Richtlinien erzwungen werden und dass Clients an den richtigen Standort der Anwendung und ihrer Datenbank weitergeleitet werden.

Partitionierung ohne datenbankübergreifende Abhängigkeit

Dieses Bereitstellungsmuster ist das einfachste der in diesem Dokument beschriebenen Muster. Jeder Standort oder jede Cloud hat eine Datenbank und die Datenbanken enthalten partitionierte Datasets, die nicht voneinander abhängig sind. Ein Datenelement wird nur in einer Datenbank gespeichert. Jede Datenpartition befindet sich in einer eigenen Datenbank. Ein Beispiel für dieses Muster ist eine mehrmandantenfähige Anwendung, bei der sich ein Dataset in der einen oder der anderen Datenbank befindet. Das folgende Diagramm zeigt zwei vollständig partitionierte Anwendungen.

Wie das obige Diagramm zeigt, wird eine Anwendung an zwei Standorten bereitgestellt, die jeweils für eine Partition des gesamten Datasets verantwortlich sind. Jedes Datenelement befindet sich nur an genau einem der Standorte, was ein partitioniertes Dataset ohne Replikation zwischen den beiden gewährleistet.

Ein alternatives Bereitstellungsmuster für partitionierte Datenbanken ist, dass das Dataset vollständig partitioniert ist, aber innerhalb derselben Datenbank gespeichert wird. Es gibt nur eine Datenbank mit allen Datasets. Obwohl die Datasets in derselben Datenbank gespeichert sind, sind die Datasets vollständig getrennt (partitioniert) und eine Änderung an einem Dataset führt nicht zu Änderungen in einem anderen. Das folgende Diagramm zeigt zwei Anwendungen, die eine einzige Datenbank gemeinsam nutzen.

Das obige Diagramm zeigt Folgendes:

• Zwei Anwendungsbereitstellungen, die beide eine gemeinsame Datenbank haben, die sich am ersten Standort befindet.
• Jede Anwendung kann auf alle Daten in der Bereitstellung zugreifen, da das Dataset nicht partitioniert ist.

Asynchrone unidirektionale Replikation

Dieses Bereitstellungsmuster hat eine primäre Datenbank, die in eine oder mehrere sekundäre Datenbanken repliziert wird. Die sekundäre Datenbank kann für den Lesezugriff verwendet werden. Ein Beispiel für dieses Muster ist, wenn die beste Datenbank für einen bestimmten Anwendungsfall als primäre Datenbank und die sekundäre Datenbank für Analysen verwendet wird. Das folgende Diagramm zeigt zwei Anwendungen, die auf unidirektional replizierte Datenbanken zugreifen.

Wie das obige Diagramm zeigt, ist eine der beiden Datenbanken ein Replikat der anderen. Der Pfeil im Diagramm zeigt die Replikationsrichtung: Die Daten aus dem Datenbanksystem an Standort 1 werden in das Datenbanksystem an Standort 2 repliziert.

Bidirektionale Replikation mit Konfliktlösung

Dieses Bereitstellungsmuster hat zwei primäre Datenbanken, die asynchron aufeinander repliziert werden. Wenn dieselben Daten gleichzeitig in jede Datenbank geschrieben werden (z. B. derselbe Primärschlüssel), kann dies zu einem Schreiben-Schreiben-Konflikt führen. Aufgrund dieses Risikos muss eine Konfliktlösung vorhanden sein, um zu bestimmen, welcher Zustand während der Replikation der letzte ist. Dieses Muster kann in Situationen verwendet werden, in denen die Wahrscheinlichkeit eines Schreiben-Schreiben-Konflikt gering ist. Das folgende Diagramm zeigt zwei Anwendungen, die auf bidirektional replizierte Datenbanken zugreifen.

Wie das vorherige Diagramm zeigt, wird jede Datenbank in die andere Datenbank repliziert. Die beiden Replikationen sind unabhängig voneinander, wie im Diagramm durch zwei separate blaue Pfeile angegeben. Da die beiden Replikationen unabhängig sind, kann es zu einem Konflikt kommen, wenn zufällig dasselbe Datenelement von jeder der Anwendungen geändert und gleichzeitig repliziert wird. In diesem Fall muss eine Konfliktlösung stattfinden.

Vollständig aktiv/aktiv-synchronisiertes verteiltes System

Dieses Bereitstellungsmuster verfügt über eine einzelne Datenbank mit einer Aktiv-Aktiv-Einrichtung (auch primär/primäres oder Mastermaster). In einer Aktiv/Aktiv-Einrichtung wird eine Aktualisierung von Daten in einer primären Datenbank transaktional konsistent und synchron repliziert. Ein Beispiel-Anwendungsfall für dieses Muster ist das verteilte Computing. Das folgende Diagramm zeigt zwei Anwendungen, die auf eine vollständig synchronisierte primäre-primäre Datenbank zugreifen.

Wie das vorhergehende Diagramm zeigt, sorgt diese Anordnung dafür, dass jede Anwendung immer ohne Verzögerung oder Risiko von Konflikten auf den letzten konsistenten Status zugreift. Eine Änderung der einen Datenbank ist sofort in der anderen Datenbank verfügbar. Jede Änderung wird in beiden Datenbanken angezeigt, wenn ein Änderungstransaktions-Commit stattfindet.

Datenbanksystemkategorisierung

Nicht alle Datenbankverwaltungssysteme können gleich gut für die Bereitstellungsmuster verwendet werden, die in diesem Dokument erläutert werden. Je nach Anwendungsfall kann möglicherweise nur ein Bereitstellungsmuster oder eine Kombination von Bereitstellungsmustern mit nur einem Teil der Datenbanksysteme implementiert werden.

Im folgenden Abschnitt werden die verschiedenen Datenbanksysteme kategorisiert und den vier Bereitstellungsmustern zugeordnet.

Es ist möglich, Datenbanken nach verschiedenen Dimensionen zu kategorisieren, z. B. Datenmodell, interne Architektur, Bereitstellungsmodell und Transaktionstypen. Im folgenden Abschnitt werden für die Multi-Cloud-Datenbankverwaltung zwei Dimensionen verwendet:

• Bereitstellungsarchitektur Architektur der Bereitstellung eines Datenbank-Verwaltungssystems auf Cloud-Ressourcen (z. B. Compute Engine-Instanzen oder in der Cloud verwaltet).
• Verteilungsmodell Das Verteilungsmodell das ein Datenbanksystem unterstützt (z. B. eine einzelne Instanz oder vollständig verteilt).

Diese beiden Dimensionen sind im Kontext von Multi-Cloud-Anwendungsfällen am relevantesten und unterstützen die vier Bereitstellungsmuster, die aus den Multi-Cloud-Datenbank-Anwendungsfällen abgeleitet werden. Eine beliebte Kategorisierung basiert auf den Datenmodellen, die von einem Datenbankverwaltungssystem unterstützt werden. Einige Systeme unterstützen nur ein Modell, z. B. ein Graphmodell. Andere Systeme unterstützen mehrere Datenmodelle gleichzeitig (z. B. relationale und Dokumentmodelle). Im Kontext der Multi-Cloud-Datenbankverwaltung ist diese Kategorisierung jedoch nicht relevant, da Multi-Cloud-Anwendungen für ihre Multi-Cloud-Bereitstellung ein beliebiges Datenmodell verwenden können.

Datenbanksystem nach Bereitstellungsarchitektur

Die Multi-Cloud-Datenbankverwaltung umfasst die folgenden vier Hauptklassen der Bereitstellungsarchitektur für Datenbankverwaltungssysteme:

• Integrierte Cloud-Datenbanken. Integrierte Cloud-Datenbanken sind für die Arbeit mit Cloud-Technologie entworfen und optimiert. Einige Datenbanksysteme verwenden z. B. Kubernetes als Implementierungsplattform und nutzen Kubernetes-Funktionen. Beispiele für diese Art von Datenbank sind CockroachDB und YugaByte. Sie können in jeder Cloud bereitgestellt werden, die Kubernetes unterstützt.
• Vom Cloud-Anbieter verwaltete Datenbanken. Von Cloud-Anbietern verwaltete Datenbanken basieren auf einer für den Cloud-Anbieter spezifischen Technologie und sind ein Datenbankdienst, der von einem bestimmten Cloud-Anbieter verwaltet wird. Spanner und Bigtable sind Beispiele für diese Art von Datenbank. Von Cloud-Anbieter verwaltete Datenbanken sind nur in der Cloud des Cloud-Anbieters verfügbar und können nicht an anderer Stelle installiert und ausgeführt werden.
• Vor-Cloud-Datenbanken. Vor-Cloud-Datenbanken gab es schon vor der Entwicklung der Cloud-Technologie (manchmal lange davor) und sie werden normalerweise auf Bare-Metal-Hardware und virtuellen Maschinen (VMs) ausgeführt. PostgreSQL und MySQL sind Beispiele für diese Art von Datenbank. Diese Systeme können in jeder Cloud ausgeführt werden, die die erforderlichen virtuellen Maschinen oder die nötige Bare-Metal-Hardware unterstützt.
• Von Cloud-Partnern verwaltete Datenbanken. Einige öffentliche Clouds haben Datenbankpartner, die Datenbanken von Kunden in der öffentlichen Cloud installieren und verwalten. Aus diesem Grund müssen Kunden diese Datenbanken nicht selbst verwalten. Beispiele für diese Art von Datenbank sind MongoDB Atlas und MariaDB.

Es gibt einige Varianten dieser Hauptkategorien. Beispielsweise kann ein Datenbankanbieter, der eine für die Cloud erstellte Datenbank implementiert, auch eine Installation auf Technologie anbieten, die für die Cloud entwickelt wurde, und ein verwaltetes Angebot für Kunden in der vom Anbieter bereitgestellten Cloud haben. Dieser Ansatz entspricht dem Anbieter, der eine öffentliche Cloud bereitstellt, die nur seine Datenbank als einzelnen Dienst unterstützt.

Vor-Cloud-Datenbanken können sich auch in Containern befinden und in einem Kubernetes-Cluster bereitstellbar sein. Diese Datenbanken verwenden jedoch keine Kubernetes-spezifischen Funktionen, wie Skalierung, Multi-Service- oder Multi-Pod-Bereitstellung.

Datenbankanbieter können gleichzeitig mit mehreren Anbietern öffentlicher Clouds zusammenarbeiten und ihre Datenbank als von Cloud-Partnern verwaltete Datenbank in mehr als einer öffentlichen Cloud anbieten.

Datenbanksystem nach Verteilungsmodell

Verschiedene Datenbankverwaltungssysteme werden gemäß den Verteilungsmodellen in der Architektur einer Datenbank implementiert. Für Datenbanken gibt es folgende Modelle:

• Einzelne Instanz. Eine einzelne Datenbankinstanz wird auf einer VM oder in einem Container ausgeführt und fungiert als zentrales System. Dieses System verwaltet den gesamten Datenbankzugriff. Da die einzelne Instanz mit keiner anderen Instanz verbunden werden kann, unterstützt das Datenbanksystem keine Replikation.
• Multi-Instanz, Aktiv-Passiv. In dieser allgemeinen Architektur sind mehrere Datenbankinstanzen miteinander verknüpft. Die gängigste Verknüpfung ist eine Aktiv-Passiv-Beziehung, wobei eine Instanz die aktive Datenbankinstanz ist, die sowohl Instanzen als auch Schreib- und Lesevorgänge unterstützt. Ein oder mehrere passive Systeme sind schreibgeschützt und erhalten alle Datenbankänderungen vom primären System entweder synchron oder asynchron. Passive Systeme können Lesezugriff gewähren. Aktiv-Passiv wird auch als Primär-Sekundär oder Master-Slave bezeichnet.
• Multi-Instanz, Aktiv-Aktiv. In dieser relativ seltenen Architektur ist jede Instanz eine aktive Instanz. In diesem Fall kann jede Instanz Lese- und Schreibtransaktionen ausführen und Datenkonsistenz bereitstellen. Aus diesem Grund werden alle Instanzen immer synchronisiert, um Dateninkonsistenzen zu vermeiden.
• Multi-Instanz, Aktiv-Aktiv mit Konfliktlösung. Auch dieses System ist relativ selten. Jede Instanz steht für Schreib- und Lesezugriff zur Verfügung. Die Datenbanken werden jedoch im asynchronen Modus synchronisiert. Gleichzeitige Aktualisierungen desselben Datenelements sind zulässig, was zu einem inkonsistenten Zustand führt. Eine Richtlinie zur Konfliktlösung muss entscheiden, welcher der Zustände der letzte konsistente Zustand ist.
• Multi-Instanz, Fragmentierung. Fragmentierung basiert auf der Verwaltung von (getrennten) Datenpartitionen. Eine separate Datenbankinstanz verwaltet jede Partition. Diese Verteilung ist skalierbar, da im Laufe der Zeit mehr Shards dynamisch hinzugefügt werden können. Shard-übergreifende Abfragen sind jedoch vielleicht nicht möglich, da diese Funktion nicht von allen Systemen unterstützt wird.

Alle in diesem Abschnitt beschriebenen Verteilungsmodelle können die Fragmentierung unterstützen und können ein fragmentiertes System sein. Nicht alle Systeme sind jedoch darauf ausgelegt, eine Fragmentierungsoption bereitzustellen. Fragmentierung ist ein Skalierbarkeitskonzept und ist für die Auswahl von Architekturdatenbanken in Multi-Cloud-Umgebungen nicht allgemein relevant.

Verteilungsmodelle unterscheiden sich für Cloud-Datenbanken und von Partnern verwaltete Datenbanken. Da diese Datenbanken an die Architektur eines Cloud-Anbieters gebunden sind, implementieren diese Systeme Architekturen, die auf den folgenden Bereitstellungsstandorten basieren:

• Zonales System. Ein zonal verwaltetes Datenbanksystem ist an eine Zone gebunden. Wenn die Zone verfügbar ist, steht auch das Datenbanksystem zur Verfügung. Wenn die Zone jedoch nicht mehr verfügbar ist, kann nicht auf die Datenbank zugegriffen werden.
• Regionales System. Eine regional verwaltete Datenbank ist an eine Region gebunden und zugänglich, wenn mindestens eine Zone zugänglich ist. Jede Kombination von Zonen kann unzugänglich werden.
• Regionenübergreifendes System. Ein regionenübergreifendes System ist an zwei oder mehr Regionen gebunden und funktioniert ordnungsgemäß, wenn mindestens eine Region verfügbar ist.

Ein regionenübergreifendes System kann auch ein cloudübergreifendes System unterstützen, wenn die Datenbank in allen Clouds installiert werden kann, die ein Unternehmen verwenden möchte.

Es gibt weitere mögliche Alternativen zu den Architekturen verwalteter Datenbanken, die in diesem Abschnitt erläutert werden. Ein regionales System kann ein Laufwerk von zwei Zonen gemeinsam nutzen lassen. Wenn eine der beiden Zonen nicht mehr zugänglich ist, kann das Datenbanksystem in der verbleibenden Zone fortfahren. Wenn ein Ausfall jedoch beide Zonen betrifft, ist das Datenbanksystem nicht verfügbar, obwohl andere Zonen möglicherweise noch vollständig online sind.

Datenbanksysteme Bereitstellungsmustern zuordnen

In der folgenden Tabelle wird beschrieben, wie die in diesem Dokument beschriebenen Bereitstellungsmuster und Bereitstellungsarchitekturen miteinander in Beziehung stehen. Die Felder geben an, welche Bedingungen für eine Kombination erforderlich sind, basierend auf dem Bereitstellungsmuster und der Bereitstellungsarchitektur.

Bereitstellungsarchitektur	Bereitstellungsmuster
	Partitionierung ohne datenbankübergreifende Abhängigkeit	Asynchrone unidirektionale Replikation	Bidirektionale Replikation mit Konfliktlösung	Vollständig aktiv/aktiv-synchronisiertes verteiltes System
Integrierte Cloud-Datenbanken	Verfügbar für alle Clouds, die integrierte Cloud-Technologien bieten, die von Datenbanksystemen verwendet werden. Wenn dieselbe Datenbank nicht verfügbar ist, können verschiedene Datenbanksysteme verwendet werden.	Cloud-Datenbank die Replikation bietet	Cloud-Datenbank, die bidirektionale Replikation bietet	Cloud-Datenbank die primäre-primäre Synchronisierung bietet
Vom Cloud-Anbieter verwaltete Datenbanken	Datenbanksysteme können in verschiedenen Clouds unterschiedlich sein.	Das Replikat muss nicht die vom Cloudanbieter verwaltete Datenbank sein (siehe Die Rolle der Datenbankmigrationstechnologie bei Bereitstellungsmustern).	Nur innerhalb einer Cloud, nicht über mehrere Clouds hinweg, wenn die Datenbank bidirektionale Replikation bietet	Nur innerhalb einer Cloud, nicht über mehrere Clouds hinweg, wenn die Datenbank eine Primär-Primär-Synchronisierung bietet.
Vor-Cloud-Datenbanken	Datenbanksysteme können in verschiedenen Clouds identisch oder unterschiedlich sein.	Die Replikation ist über mehrere Clouds hinweg möglich.	Das Datenbanksystem bietet bidirektionale Replikation und Konfliktlösung.	Das Datenbanksystem bietet die primäre Primärsynchronisierung.
Von Cloud-Partnern verwaltete Datenbanken	Datenbanksysteme können in verschiedenen Clouds unterschiedlich sein. Wenn der Partner ein verwaltetes Datenbanksystem in allen erforderlichen Clouds bereitstellt, kann dieselbe Datenbank verwendet werden.	Das Replikat muss nicht die vom Cloud-Anbieter verwaltete Datenbank sein. Wenn der Partner ein verwaltetes Datenbanksystem in allen erforderlichen Clouds bereitstellt, kann dieselbe Datenbank verwendet werden.	Das Datenbanksystem bietet bidirektionale Replikation und Konfliktlösung.	Das Datenbanksystem bietet die primäre Primärsynchronisierung.

Wenn ein Datenbanksystem keine integrierte Replikation bietet, kann stattdessen vielleicht die Datenbankreplikationstechnologie verwendet werden. Weitere Informationen finden Sie unter Die Rolle der Technologie zur Datenbankmigration in Bereitstellungsmustern.

Die folgende Tabelle enthält die Bereitstellungsmuster für Verteilungsmodelle. Die Felder geben die Bedingungen an, für die die Kombination anhand eines Bereitstellungsmusters und eines Verteilungsmodells möglich ist.

Verteilungsmodell	Bereitstellungsmuster
	Partitionierung ohne datenbankübergreifende Abhängigkeit	Asynchrone unidirektionale Replikation	Bidirektionale Replikation mit Konfliktlösung	Vollständig aktiv/aktiv-synchronisiertes verteiltes System
Einzelne Instanz	Dies ist mit dem gleichen oder einem anderen Datenbanksystem in den betroffenen Clouds möglich.	Nicht zutreffend	Nicht zutreffend	Nicht zutreffend
Multi-Instanz, Aktiv-Passiv	Dies ist mit dem gleichen oder einem anderen Datenbanksystem in den betroffenen Clouds möglich.	Replikation ist über Clouds hinweg möglich.	Replikation ist über Clouds hinweg möglich.	Nicht zutreffend
Multi-Instanz, Aktiv-Aktiv	Dies ist mit dem gleichen oder einem anderen Datenbanksystem in den betroffenen Clouds möglich.	Nicht zutreffend	Nicht zutreffend	Synchronisierung ist über Clouds hinweg möglich.
Multi-Instanz, Aktiv-Aktiv mit Konfliktlösung	Dies ist mit dem gleichen oder einem anderen Datenbanksystem in den betroffenen Clouds möglich.	Nicht zutreffend	Nicht zutreffend	Gilt, wenn eine bidirektionale Replikation über Clouds hinweg möglich ist.

In einige Implementierungen von Verteilungsmodellen, die eine zusätzliche Abstraktion basierend auf der zugrunde liegenden Datenbanktechnologie hinzufügen, ist kein solches Verteilungsmodell eingebunden. Beispiel: Postgres-BDR, ein Aktiv-Aktiv-System. Solche Systeme sind in der vorherigen Tabelle in der entsprechenden Kategorie enthalten. Aus der Multi-Cloud-Perspektive ist es irrelevant, wie ein Verteilungsmodell implementiert wird.

Datenbankmigration und -replikation

Je nach Anwendungsfall muss ein Unternehmen eine Datenbank möglicherweise von einem Bereitstellungsstandort zu einem anderen migrieren. Alternativ kann es bei der nachgelagerten Verarbeitung erforderlich sein, die Daten für eine Datenbank an einem anderen Standort zu replizieren. Im folgenden Abschnitt werden die Datenbankmigration und die Datenbankreplikation ausführlicher erläutert.

Datenbankmigration

Die Datenbankmigration wird verwendet, wenn eine Datenbank von einem Bereitstellungsort an einen anderen verschoben wird. Beispielsweise wird eine in einem lokalen Rechenzentrum ausgeführte Datenbank migriert, um stattdessen in der Cloud ausgeführt zu werden. Nach Abschluss der Migration wird die Datenbank im lokalen Rechenzentrum heruntergefahren.

Die wichtigsten Ansätze für die Datenbankmigration sind folgende:

• Lift-and-Shift. Die VM und die Laufwerke, auf denen die Datenbankinstanzen ausgeführt werden, werden unverändert in die Zielumgebung kopiert. Nachdem sie kopiert wurden, werden sie gestartet und die Migration ist abgeschlossen.
• Exportieren und Importieren sowie Sichern und Wiederherstellen. Bei beiden Ansätzen wird die Funktionalität des Datenbanksystems verwendet, um eine Datenbank zu externalisieren und am Zielstandort neu zu erstellen. Der Export/Import basiert normalerweise auf einem ASCII-Format, während die Sicherung und Wiederherstellung auf einem Binärformat basiert.
• Migration ohne Ausfallzeiten. Bei diesem Ansatz wird eine Datenbank migriert, während die Anwendungssysteme auf das Quellsystem zugreifen. Nach dem anfänglichen Ladevorgang werden Änderungen mithilfe von CDC-Technologien (Change Data Capture) von der Quell- zur Zieldatenbank übertragen. Bei der Anwendung kommt es zu einer Ausfallzeit zwischen dem Zeitpunkt, an dem sie auf dem Quelldatenbanksystem beendet wird, und dem Neustart auf dem Zieldatenbanksystem, nachdem die Migration abgeschlossen ist.

Die Datenbankmigration wird in Multi-Cloud-Anwendungsfällen relevant, wenn eine Datenbank zwischen den beiden Clouds verschoben wird oder von einer Art Datenbankmodul in ein anderes verschoben wird.

Die Datenbankmigration ist ein vielschichtiger Prozess. Weitere Informationen finden Sie unter Datenbankmigration: Konzepte und Prinzipien (Teil 1) und Datenbankmigration: Konzepte und Prinzipien (Teil 2).

Integrierte Datenbanktechnologien können für die Datenbankmigration verwendet werden, z. B. für den Export/Import, für das Sichern/Wiederherstellen oder für integrierte Replikationsprotokolle. Wenn das Quell- und Zielsystem unterschiedliche Datenbanksysteme sind, sind Migrationstechnologien die beste Option für die Datenbankmigration. Striim und Debezium sind Beispiele für Datenbankmigrationstechnologien.

Datenbankreplikation

Die Datenbankreplikation ist ähnlich wie die Datenbankmigration. Während der Datenbankreplikation ist das Quelldatenbanksystem jedoch weiterhin vorhanden, während jede Änderung an die Zieldatenbank übertragen wird.

Die Datenbankreplikation ist ein kontinuierlicher Prozess, der Änderungen von der Quelldatenbank an die Zieldatenbank sendet. Wenn dieser Prozess asynchron ist, gelangen die Änderungen nach einer kurzen Verzögerung zur Zieldatenbank. Wenn der Prozess synchron ist, werden die Änderungen am Quellsystem gleichzeitig am selben Zielsystem und an denselben Transaktionen vorgenommen.

Neben dem Replizieren einer Quelle in eine Zieldatenbank werden üblicherweise Daten aus einer Quelldatenbank in ein Zielanalysesystem repliziert.

Wie bei der Datenbankmigration können Sie bei der Einbindung von Replikationsprotokollen die integrierte Datenbanktechnologie für die Datenbankreplikation verwenden. Wenn keine integrierten Replikationsprotokolle vorhanden sind, kann Replikationstechnologie wie Striim oder Debezium verwendet werden.

Die Rolle der Technologie zur Datenbankmigration in Bereitstellungsmustern

Die integrierte Datenbanktechnologie zum Aktivieren der Replikation ist nicht allgemein verfügbar, wenn verschiedene Datenbanksysteme in Bereitstellungsmustern verwendet werden, z. B. die asynchrone (heterogene) Replikation. Stattdessen kann die Datenbankmigrationstechnologie bereitgestellt werden, um diese Art der Replikation zu ermöglichen. Einige dieser Migrationssysteme implementieren auch eine bidirektionale Replikation.

Wenn die Datenbankmigrations- oder -replikationstechnologie für die Datenbanksysteme verfügbar ist, die in Kombinationen verwendet werden, die unter Datenbanksysteme Bereitstellungsmustern zuordnen in Tabelle 1 oder Tabelle 2 mit "Nicht zutreffend" markiert sind, kann sie eventuell zur Datenbankreplikation verwendet werden. Das folgende Diagramm zeigt einen Ansatz für die Datenbankreplikation unter Verwendung einer Migrationstechnologie.

Im vorherigen Diagramm wird die Datenbank an Standort 1 in die Datenbank an Standort 2 repliziert. Anstelle einer direkten Replikation des Datenbanksystems wird ein Migrationsserver bereitgestellt, um die Replikation zu implementieren. Dieser Ansatz wird für Datenbanksysteme verwendet, in denen Datenbankreplikation nicht in die Implementierung integriert ist und die für die Implementierung der Replikation von einem System abhängen, das vom Datenbanksystem getrennt ist.

Auswahl einer Multi-Cloud-Datenbank

Anhand der Multi-Cloud-Datenbank-Anwendungsfälle in Verbindung mit der Datenbanksystem-Kategorisierung können Sie entscheiden, welche Datenbanken für einen bestimmten Anwendungsfall am besten geeignet sind. Zum Implementieren des Anwendungsfalls in Anwendungsportabilität gibt es zwei Optionen. Die erste Option besteht darin, dafür zu sorgen, dass dasselbe Datenbankmodul in allen Clouds verfügbar ist. Dieser Ansatz gewährleistet die Systemportabilität. Die zweite Option besteht darin sicherzustellen, dass dasselbe Datenmodell und dieselbe Abfrageschnittstelle für alle Clouds verfügbar sind. Auch wenn sich die Datenbanksysteme unterscheiden können, wird die Portabilität in einer funktionalen Oberfläche bereitgestellt.

Die Entscheidungsbäume in den folgenden Abschnitten veranschaulichen die Entscheidungskriterien für die Multi-Cloud-Datenbank-Anwendungsfälle in diesem Dokument. Die Entscheidungsbäume schlagen die beste Datenbank für jeden Anwendungsfall vor.

Best Practices für vorhandenes Datenbanksystem

Wenn ein Datenbanksystem in der Produktion ist, müssen Sie entscheiden, ob Sie es behalten oder ersetzen möchten. Das folgende Diagramm zeigt die Fragen, die Sie bei Ihrem Entscheidungsprozess stellen sollten:

Die Fragen und Antworten im Entscheidungsbaum lauten so:

• Befindet sich ein Datenbanksystem in der Produktion?
  • Wenn sich kein Datenbanksystem in der Produktion befindet, wählen Sie ein Datenbanksystem aus. Fahren Sie mit Entscheidung zu Multi-Cloud-Datenbankverwaltung fort.
  • Wenn sich ein Datenbanksystem in der Produktion befindet, entscheiden Sie, ob es beibehalten werden soll.
• Wenn sich ein Datenbanksystem in der Produktion befindet, entscheiden Sie, ob es beibehalten werden soll.
  • Wenn das Datenbanksystem beibehalten werden soll, ist die Entscheidung getroffen und der Entscheidungsprozess abgeschlossen.
  • Wenn das Datenbanksystem geändert werden soll oder die Entscheidung noch getroffen wird, wählen Sie ein Datenbanksystem aus (springen Sie zu Entscheidung zur Multi-Cloud-Datenbankverwaltung).

Entscheidung über Multi-Cloud-Datenbankverwaltung

Der folgende Entscheidungsbaum ist für einen Anwendungsfall mit einer Anforderung für eine Datenbank an mehreren Standorten (einschließlich einer Multi-Cloud-Datenbankbereitstellung). Dabei wird das Bereitstellungsmuster als Grundlage für die Entscheidungskriterien verwendet.

Die Fragen und Antworten im Entscheidungsbaum lauten so:

• Sind die Daten in verschiedenen Datenbanken ohne datenbankübergreifende Abhängigkeit partitioniert?
  • Wenn ja, können für jeden Standort dieselben oder unterschiedliche Datenbanksysteme ausgewählt werden.
  • Falls nicht, fahren Sie mit der nächsten Frage fort.
• Ist eine asynchrone unidirektionale Replikation erforderlich?
  • Wenn ja, prüfen Sie, ob ein Datenbankreplikationssystem akzeptabel ist.
    • Wenn ja, wählen Sie dieselben oder verschiedene Datenbanksysteme aus, die mit dem Replikationssystem kompatibel sind.
    • Falls nicht, wählen Sie ein Datenbanksystem aus, das ein Aktiv-Passiv-Verteilungsmodell implementieren kann.
    • Falls nicht, fahren Sie mit der nächsten Frage fort.
• Wählen Sie ein Datenbanksystem mit synchronisierten Instanzen aus.
  • Ist Konfliktlösung akzeptabel?
    • Wenn ja, wählen Sie ein bidirektionales replizierendes Datenbanksystem oder ein Aktiv-Aktiv-Datenbanksystem aus.
    • Falls nicht, wählen Sie ein Aktiv-Aktiv-System aus.

Wenn mehr als ein Multi-Cloud-Anwendungsfall implementiert ist, muss ein Unternehmen entscheiden, ob es ein Datenbanksystem verwenden will, um alle Anwendungsfälle zu unterstützen, oder mehrere Datenbanksysteme.

Wenn ein Unternehmen ein Datenbanksystem verwenden möchte, das alle Anwendungsfälle unterstützt, ist das System mit der besten Synchronisierung die beste Wahl. Wenn beispielsweise sowohl eine unidirektionale Replikation als auch synchronisierte Instanzen erforderlich sind, sind die synchronisierten Instanzen die beste Wahl.

Die Hierarchie der Synchronisierungsqualität ist von "Keine" bis "Am besten": Partitioniert, unidirektionale Replikation, bidirektionale Replikation und vollständig synchronisierte Replikation.

Best Practices bei der Bereitstellung

In diesem Abschnitt werden Best Practices erläutert, die Sie bei der Auswahl einer Datenbank für die Migration oder Entwicklung von Multi-Cloud-Anwendungen befolgen sollten.

Vorhandenes Datenbankverwaltungssystem

Es kann empfehlenswert sein, eine Datenbank beizubehalten und keine Änderungen am Datenbanksystem vorzunehmen, es sei denn, dies ist für einen bestimmten Anwendungsfall erforderlich. Unternehmen mit einem bestehenden Datenbankverwaltungssystem mit effektiven Entwicklungs-, Betriebs- und Wartungsprozessen sollten keine Änderungen vornehmen.

Bei einem Cloud-Bursting-Anwendungsfall, bei dem kein Datenbanksystem in der Cloud erforderlich ist, muss die Datenbank möglicherweise nicht geändert werden. Ein weiterer Anwendungsfall ist die asynchrone Replikation an einen anderen Bereitstellungsstandort innerhalb derselben oder in einer anderen Cloud. Bei diesen Anwendungsfällen empfiehlt es sich, eine Benchmark zu implementieren und zu überprüfen, ob die regionenübergreifende Kommunikation und die Latenz beim Zugriff auf die Datenbank den Anforderungen der Anwendung entsprechen.

Datenbanksystem als Kubernetes-Dienst

Wenn ein Unternehmen die Ausführung eines Datenbanksystems in Kubernetes als Dienst auf der Grundlage von StatefulSets in Betracht zieht, müssen die folgenden Faktoren berücksichtigt werden:

• Wenn die Datenbank das für die Anwendung erforderliche Datenbankmodell bereitstellt.
• Nicht funktionale Faktoren, die bestimmen, wie die Operationalisierung in einem Datenbanksystem als Kubernetes-Dienst implementiert wird, z. B. wie die Skalierung erfolgt (hoch und herunter), wie Sicherung und Wiederherstellung verwaltet werden und wie das System Monitoring verfügbar macht. Unternehmen sollten ihre Erfahrungen mit Datenbanken als Anhaltspunkt verwenden, um die Anforderungen eines Kubernetes-basierten Datenbanksystems besser zu verstehen.
• Hochverfügbarkeit und Notfallwiederherstellung. Damit Hochverfügbarkeit erzielt wird, muss das System weiter funktionieren, wenn eine Zone innerhalb einer Region ausfällt. Die Datenbank muss in der Lage sein, den Failover von einer Zone auf zu einer anderen schnell auszuführen. Im Best-Case-Szenario wird in jeder Zone eine Instanz der Datenbank ausgeführt, die vollständig für ein RTO und RPO von null synchronisiert ist.
• Notfallwiederherstellung zur Behebung des Ausfalls einer Region (oder einer Cloud). In einem idealen Szenario arbeitet die Datenbank weiterhin in einer zweiten Region mit einem RPO und RTO von null. In einem weniger idealen Szenario ist die Datenbank in der sekundären Region möglicherweise nicht vollständig aktuell bezüglich aller Transaktionen aus der primären Datenbank.

Um zu bestimmen, wie eine Datenbank in Kubernetes am besten ausgeführt wird, ist eine vollständige Datenbankauswertung ein guter Ansatz, insbesondere wenn das System mit einem System in der Produktion außerhalb von Kubernetes vergleichbar sein muss.

Von Kubernetes unabhängiges Datenbanksystem

Bei einer Anwendung, die in Form von Diensten in Kubernetes implementiert ist, muss nicht immer gleichzeitig die Datenbank in Kubernetes ausgeführt werden. Es gibt viele Gründe, warum ein Datenbanksystem außerhalb von Kubernetes ausgeführt werden muss, z. B. etablierte Prozesse, Produktkenntnisse innerhalb eines Unternehmens oder Nichtverfügbarkeit. Sowohl Cloud-Anbieter als auch von Cloud-Partnern verwaltete Datenbanken fallen in diese Kategorie.

Es ist ebenso möglich und machbar, eine Datenbank auf einer Compute Engine auszuführen. Bei der Auswahl eines Datenbanksystems empfiehlt es sich, eine vollständige Datenbankbewertung durchzuführen, um zu gewährleisten, dass alle Anforderungen für eine Anwendung erfüllt sind.

Aus Sicht des Anwendungsdesigns ist Verbindungs-Pooling ein wichtiger Aspekt. Ein Anwendungsdienst, der auf eine Datenbank zugreift, kann intern einen Verbindungspool verwenden. Die Verwendung eines Verbindungspools ist gut für Effizienz und reduzierte Latenz. Anfragen werden stattdessen aus dem Pool genommen, ohne dass sie initiiert werden müssen, und es muss nicht auf das Erstellen von Verbindungen gewartet werden. Wenn die Anwendung durch Hinzufügen von Anwendungsdienstinstanzen vertikal skaliert wird, erstellt jede Instanz einen Verbindungspool. Wenn Best Practices befolgt werden, erstellt jeder Pool vorab einen minimalen Satz von Verbindungen. Jedes Mal, wenn eine andere Anwendungsdienstinstanz für die Anwendungsskalierung erstellt wird, werden der Datenbank Verbindungen hinzugefügt. Aus der Entwurfsperspektive muss das Hinzufügen von Verbindungen verwaltet werden, um eine Überlastung zu vermeiden, da Datenbanken keine unbegrenzten Verbindungen unterstützen.

Bestes Datenbanksystem im Vergleich zur Portabilität von Datenbanksystemen

Bei der Auswahl von Datenbanksystemen wählen Unternehmen üblicherweise das beste Datenbanksystem aus, um den Anforderungen einer Anwendung gerecht zu werden. In einer Multi-Cloud-Umgebung kann die beste Datenbank in jeder Cloud ausgewählt werden und sie können je nach Anwendungsfall miteinander verbunden werden. Wenn sich diese Systeme unterscheiden, erfordert jede Replikation – uni- oder bidirektional – einen erheblichen Aufwand. Dieser Ansatz ist möglicherweise gerechtfertigt, wenn der Nutzen der Verwendung des besten Systems den Aufwand für seine Implementierung überwiegt.

Es empfiehlt sich jedoch, gleichzeitig einen Ansatz für ein Datenbanksystem zu berücksichtigen und zu bewerten, der in allen erforderlichen Clouds verfügbar ist. Obwohl eine solche Datenbank nicht so ideal wie die beste Option ist, ist sie unter Umständen viel einfacher zu implementieren, zu betreiben und zu warten.

Bei der gleichzeitigen Bewertung eines Datenbanksystems werden die Vor- und Nachteile beider Datenbanksysteme aufgezeigt, sodass eine solide Grundlage für die Auswahl besteht.

Integrierte im Vergleich zu externer Datenbanksystemreplikation

Für Anwendungsfälle, die ein Datenbanksystem an allen Bereitstellungsstandorten (Zonen, Regionen oder Clouds) erfordern, ist die Replikation ein wichtiges Feature. Die Replikation kann eine asynchrone, bidirektionale oder vollständig synchronisierte Aktiv-Aktiv-Replikation sein. Datenbanksysteme unterstützen nicht alle diese Replikationsformen.

Für die Systeme, die die Replikation nicht als Teil ihrer Systemimplementierungs-Replikation unterstützen, können Systeme wie Striim als Ergänzung zur Architektur verwendet werden. Wie diskutiert unter Datenbankmigration.

Es hat sich bewährt, alternative Datenbankverwaltungssysteme zu bewerten, um die Vor- und Nachteile eines Systems mit integrierter Replikation oder eines Systems, für das Replikationstechnologie erforderlich ist, zu ermitteln.

Eine dritte Klasse spielt auch in diesem Fall eine Rolle. Diese Klasse bietet Add-ons für vorhandene Datenbanksysteme zur Bereitstellung von Replikation. Ein Beispiel ist MariaDB Galera Cluster. Wenn der Bewertungsprozess es zulässt, ist die Berücksichtigung dieser Systeme zu empfehlen.

Nächste Schritte

• Hybrid- und Multi-Cloud-Muster und -Praktiken
• Muster für die Verbindung anderer Cloud-Dienstanbieter mit Google Cloud
• Monitoring- und Logging-Architekturen für Hybrid- und Multi-Cloud-Bereitstellungen in Google Cloud
• Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.