Beispiele für Replikationskonfigurationen

Auf dieser Seite werden einige gängige Anwendungsfälle für die Bigtable-Replikation sowie die Einstellungen beschrieben, die Sie jeweils verwenden können.

Auf dieser Seite wird auch erläutert, wie Sie die richtigen Einstellungen für andere Anwendungsfälle auswählen.

Bevor Sie diese Seite lesen, sollten Sie sich mit den Informationen unter Bigtable-Replikation – Übersicht vertraut gemacht haben.

Bevor Sie Cluster zu einer Instanz hinzufügen, sollten Sie sich mit den Einschränkungen vertraut machen, die beim Ändern von Richtlinien zur Speicherbereinigung für replizierte Tabellen gelten.

In den meisten Fällen sollten Sie das Autoscaling für die Cluster Ihrer Instanz aktivieren. Mit Autoscaling können Sie in Bigtable einem Cluster je nach Arbeitslast automatisch Knoten hinzufügen und entfernen.

Wenn Sie stattdessen die manuelle Knotenzuweisung auswählen, müssen Sie in jedem Cluster in einer Instanz genügend Knoten bereitstellen, damit jeder Cluster zusätzlich zu der Last, die von Anwendungen empfangen wird, die Replikation verarbeiten kann. Wenn ein Cluster nicht über ausreichend Knoten verfügt, kann die Replikationsverzögerung erhöht werden, beim Cluster können aufgrund erhöhter Arbeitsspeichernutzung Leistungsprobleme auftreten und Schreibvorgänge in anderen Clustern in der Instanz können abgelehnt werden.

In den Beispielen in diesem Dokument wird das Erstellen einer Instanz beschrieben. Sie können aber auch einer vorhandenen Instanz Cluster hinzufügen.

Batchanalysejobs von anderen Anwendungen isolieren

Wenn Sie einen einzelnen Cluster zum Ausführen eines Batchanalysejobs mit zahlreichen großen Lesevorgängen sowie zum Ausführen einer Anwendung verwenden, die sowohl Lese- als auch Schreibvorgänge verarbeitet, ist mit einer Verlangsamung der Vorgänge für den Nutzer zu rechnen. Wenn Sie hingegen die Replikation aktivieren, können Sie Anwendungsprofile mit Single-Cluster-Routing verwenden, um Batchanalysejobs und Anwendungstraffic an unterschiedliche Cluster weiterzuleiten. Die Nutzer Ihrer Anwendung sind somit nicht von den Batchjobs betroffen.

So isolieren Sie Arbeitslasten:

  1. Erstellen Sie eine Instanz mit zwei Clustern.

  2. Erstellen Sie zwei Anwendungsprofile und bezeichnen Sie eines als live-traffic und das andere als batch-analytics.

    Wenn Ihre Cluster-IDs cluster-a und cluster-b lauten, werden Anfragen vom Anwendungsprofil live-traffic an cluster-a und vom Anwendungsprofil batch-analytics an cluster-b weiterleiten. Diese Konfiguration bietet Read-Your-Writes-Konsistenz für Anwendungen, die dasselbe Anwendungsprofil verwenden, jedoch nicht für Anwendungen mit unterschiedlichen Anwendungsprofilen.

    Bei Bedarf können Sie Transaktionen für einzelne Zeilen im Anwendungsprofil live-traffic aktivieren. Im Anwendungsprofil batch-analytics müssen Transaktionen für einzelne Zeilen nicht aktiviert werden, sofern Sie dieses Profil nur für Lesevorgänge verwenden.

  3. Führen Sie mit dem Anwendungsprofil live-traffic eine Arbeitslast mit Live-Traffic aus.

  4. Verwenden Sie während der Ausführung der Arbeitslast mit Live-Traffic das Anwendungsprofil batch-analytics, um eine Batcharbeitslast mit Lesevorgängen auszuführen.

So isolieren Sie zwei kleinere Arbeitslasten von einer größeren Arbeitslast:

  1. Erstellen Sie eine Instanz mit drei Clustern.

    Bei diesen Schritten wird davon ausgegangen, dass Ihre Cluster die IDs cluster-a, cluster-b und cluster-c verwenden.

  2. Erstellen Sie die folgenden Anwendungsprofile:

    • live-traffic-app-a: Single-Cluster-Routing von Ihrer Anwendung zu cluster-a
    • live-traffic-app-b: Single-Cluster-Routing von Ihrer Anwendung zu cluster-b
    • batch-analytics: Single-Cluster-Routing vom Batchanalysejob zu cluster-c

  3. Verwenden Sie die Live-Traffic-Anwendungsprofile, um Arbeitslasten mit Live-Traffic auszuführen.

  4. Verwenden Sie während der Ausführung der Arbeitslasten mit Live-Traffic das Anwendungsprofil batch-analytics, um eine schreibgeschützte Batcharbeitslast auszuführen.

Hochverfügbarkeit erstellen

Wenn eine Instanz nur einen einzigen Cluster hat, sind die Langlebigkeit und Verfügbarkeit Ihrer Daten auf die Zone beschränkt, in der sich dieser Cluster befindet. Mit der Replikation kann sowohl die Langlebigkeit als auch die Verfügbarkeit verbessert werden, da separate Kopien Ihrer Daten in mehreren Zonen oder Regionen gespeichert und bei Bedarf automatisch per Failover zwischen Clustern übertragen werden.

Wenn Sie Ihre Instanz für einen Anwendungsfall mit Hochverfügbarkeit konfigurieren möchten, erstellen Sie ein neues Anwendungsprofil, das Multi-Cluster-Routing verwendet oder aktualisieren Sie das standardmäßige Anwendungsprofil, um Multi-Cluster-Routing zu verwenden. Diese Konfiguration bietet Eventual Consistency. Sie können keine Transaktionen für einzelne Zeilen aktivieren, da Transaktionen für einzelne Zeilen Datenkonflikte auslösen können, wenn Sie Multi-Cluster-Routing verwenden.

Mit den folgenden Konfigurationen verbessern Sie die Verfügbarkeit:

  • Cluster in drei oder mehr verschiedenen Regionen (empfohlene Konfiguration). Die empfohlene Konfiguration für hohe Verfügbarkeit ist eine Instanz mit N+2-Clustern, die sich jeweils in einer anderen Region befinden. Wenn Sie zum Beispiel die Mindestanzahl an Clustern für die Bereitstellung von Daten 2 bereitstellen müssen, benötigen Sie eine 4-Cluster-Instanz, um HA beizubehalten. Diese Konfiguration bietet die Verfügbarkeit auch in dem seltenen Fall, dass zwei Regionen nicht mehr verfügbar sind. Wir empfehlen, die Cluster auf mehrere Kontinente zu verteilen.

    Konfigurationsbeispiel:

    • cluster-a in der Zone us-central1-a in Iowa
    • cluster-b in der Zone europe-west1-d in Belgien
    • cluster-c in der Zone asia-east1-b in Taiwan

  • Zwei Cluster in derselben Region, aber in unterschiedlichen Zonen. Diese Option bietet Hochverfügbarkeit in der Verfügbarkeit der Region, die Fähigkeit zum Failover, ohne dass regionsübergreifende Replikationskosten entstehen, und ohne erhöhte Latenz beim Failover. Daten in einer replizierten Bigtable-Instanz sind immer dann verfügbar, wenn eine der Zonen verfügbar ist, in die sie repliziert werden.

    Konfigurationsbeispiel:

    • cluster-a in der Zone australia-southeast1-a in Sydney
    • cluster-b in der Zone australia-southeast1-b in Sydney

  • Zwei Cluster in unterschiedlichen Regionen. Diese Konfiguration mit mehreren Regionen bietet Hochverfügbarkeit, ähnlich wie die vorherige Konfiguration für mehrere Zonen. Ihre Daten sind jedoch auch dann verfügbar, wenn Sie keine Verbindung zu einer der Regionen herstellen können.

    Das Replizieren von Schreibvorgängen zwischen Regionen wird Ihnen in Rechnung gestellt.

    Konfigurationsbeispiel:

    • cluster-a in der Zone asia-northeast1-c in Tokio
    • cluster-b in der Zone asia-east2-b in Hongkong

  • Zwei Cluster in Region A und ein dritter Cluster in Region B. Bei dieser Option sind Ihre Daten auch dann verfügbar, wenn Sie keine Verbindung zu einer der Regionen herstellen können. Sie bietet außerdem zusätzliche Kapazität in Region A.

    Das Replizieren von Schreibvorgängen zwischen Regionen wird Ihnen in Rechnung gestellt. Wenn Sie Schreibvorgänge in Region A ausführen, werden Ihnen einmalig Gebühren berechnet, da Sie nur einen einzigen Cluster in Region B haben. Wenn Sie Schreibvorgänge in Region B ausführen, werden Ihnen die Kosten doppelt berechnet, da Sie in Region A zwei Cluster haben.

    Konfigurationsbeispiel:

    • cluster-a in der Zone europe-west1-b in Belgien
    • cluster-b in der Zone europe-west1-d in Belgien
    • cluster-c in der Zone europe-north1-c in Finnland

Sicherungen praktisch in Echtzeit bereitstellen

In manchen Fällen müssen Anfragen immer an einen einzigen Cluster weitergeleitet werden, beispielsweise wenn das Lesen veralteter Daten inakzeptabel ist. Allerdings können Sie auch dann die Replikation verwenden. Dabei ist ein Cluster für die Verarbeitung von Anfragen zuständig, während ein anderer Cluster als echtzeitnahe Sicherung dient. Wenn der verarbeitende Cluster nicht mehr verfügbar ist, können Sie die Ausfallzeit durch ein manuelles Failover auf den Sicherungscluster minimieren.

Zum Konfigurieren der Instanz für diesen Anwendungsfall müssen Sie ein Anwendungsprofil mit Single-Cluster-Routing erstellen oder das standardmäßige Anwendungsprofil zur Verwendung von Single-Cluster-Routing aktualisieren. Der Cluster, den Sie in Ihrem Anwendungsprofil angegeben haben, verarbeitet eingehende Anfragen. Der andere Cluster fungiert als Sicherung für den Fall, dass ein Failover erforderlich ist. Diese Einrichtung wird manchmal Aktiv-Passiv-Konfiguration genannt und bietet sowohl strikte Konsistenz als auch Read-Your-Writes-Konsistenz. Bei Bedarf können Sie Transaktionen für einzelne Zeilen im Anwendungsprofil aktivieren.

So implementieren Sie diese Konfiguration:

  1. Führen Sie unter Verwendung des App-Profils mit Single-Cluster-Routing eine Arbeitslast aus.

  2. Überwachen Sie die Cluster der Instanz mit der Google Cloud Console und achten Sie darauf, dass nur ein Cluster eingehende Anfragen verarbeitet.

    Der andere Cluster verwendet weiterhin CPU-Ressourcen für die Replikation und andere Wartungsaufgaben.

  3. Aktualisieren Sie das App-Profil, damit es auf den zweiten Cluster in der Instanz verweist.

    Sie erhalten eine Warnung, dass die Read-Your-Writes-Konsistenz verloren geht, was auch bedeutet, dass die strikte Konsistenz verloren geht.

    Falls Sie Transaktionen für einzelne Zeilen aktiviert haben, erhalten Sie auch eine Warnung bezüglich eines potenziellen Datenverlusts. Sie verlieren Daten, wenn Sie während des Failovers in Konflikt stehende Schreibvorgänge senden.

  4. Überwachen Sie Ihre Instanz weiter. Sie müssten sehen, dass der zweite Cluster jetzt eingehende Anfragen verarbeitet.

Hochverfügbarkeit und regionale Ausfallsicherheit beibehalten

Angenommen Sie haben Kunden in zwei verschiedenen Regionen eines Kontinents. Sie möchten, dass sich Bigtable-Cluster jeweils möglichst nah bei den Kunden befinden. Die Daten sollen in jeder Region hochverfügbar sein. Möglicherweise möchten Sie eine Failover-Option bereitstellen, wenn einer oder mehrere der Cluster nicht verfügbar sind.

Für diesen Anwendungsfall können Sie eine Instanz mit zwei Clustern in Region A und zwei Clustern in Region B erstellen. Diese Konfiguration bietet Hochverfügbarkeit, auch wenn Sie keine Verbindung zu einer Google Cloud-Region herstellen können. Sie bietet auch regionale Ausfallsicherheit, denn wenn eine Zone ausfällt, bleibt der andere Cluster in der Region dieser Zone weiterhin verfügbar.

Je nach Ihren Geschäftsanforderungen können Sie für diesen Anwendungsfall Multi-Cluster-Routing oder Single-Cluster-Routing verwenden.

So konfigurieren Sie Ihre Instanz für diesen Anwendungsfall:

  1. Erstellen Sie eine Bigtable-Instanz mit vier Clustern: zwei in Region A und zwei in Region B. Cluster in derselben Region müssen sich in verschiedenen Zonen befinden.

    Konfigurationsbeispiel:

    • cluster-a in der Zone asia-south1-a in Mumbai
    • cluster-b in der Zone asia-south1-c in Mumbai
    • cluster-c in der Zone asia-northeast1-a in Tokio
    • cluster-d in der Zone asia-northeast1-b in Tokio

  2. Platzieren Sie einen Anwendungsserver in der Nähe jeder Region.

Je nach Ihren Geschäftsanforderungen können Sie für diesen Anwendungsfall Multi-Cluster-Routing oder Single-Cluster-Routing verwenden. Wenn Sie Multi-Cluster-Routing verwenden, führt Bigtable Failovers automatisch aus. Wenn Sie Single-Cluster-Routing verwenden, entscheiden Sie nach eigenem Ermessen, wann ein Failover zu einem anderen Cluster erfolgen soll.

Single-Cluster-Routing

Sie können für diesen Anwendungsfall Single-Cluster-Routing verwenden, wenn für den Bigtable-Cluster nicht automatisch ein Failover erfolgen soll, wenn eine Zone oder Region nicht verfügbar ist. Diese Option ist eine gute Wahl, wenn Sie die Kosten und die Latenz verwalten möchten, die entstehen, wenn Bigtable den Traffic von und zu einer entfernten Region weiterleitet, oder wenn Sie Failover-Entscheidungen nach eigenem Ermessen oder gemäß Ihren Geschäftsregeln treffen möchten.

Zum Implementieren dieser Konfiguration erstellen Sie mindestens ein App-Profil, das für jede Anwendung, die Anfragen an die Instanz sendet, Single-Cluster-Routing verwendet. Sie können die Anwendungsprofile an jeden Cluster in der Bigtable-Instanz weiterleiten. Wenn Sie beispielsweise drei Anwendungen in Mumbai und sechs in Tokio haben, können Sie ein App-Profil für die Mumbai-Anwendung so konfigurieren, dass eine Weiterleitung an asia-south1-a erfolgt, und zwei App-Profile, die zu asia-south1-c weiterleiten. Konfigurieren Sie für die Tokio-Anwendung drei Anwendungsprofile, die zu asia-northeast1-a weiterleiten, und drei, die zu asia-northeast1-b weiterleiten.

Wenn bei dieser Konfiguration ein oder mehrere Cluster ausfallen, können Sie ein manuelles Failover ausführen oder festlegen, dass die Daten in dieser Zone vorübergehend nicht verfügbar sind, bis die Zone wieder verfügbar ist.

Multi-Cluster-Routing

Wenn Sie diesen Anwendungsfall implementieren und Bigtable automatisch einen Failover auf eine Region ausführen soll, wenn Ihre Anwendung die andere Region nicht erreichen kann, verwenden Sie das Multi-Cluster-Routing.

Zur Implementierung dieser Konfiguration erstellen Sie ein neues Anwendungsprofil, das Multi-Cluster-Routing für jede Anwendung verwendet oder aktualisieren Sie das Standard-Anwendungsprofil, sodass es Multi-Cluster-Routing verwenden kann.

Diese Konfiguration bietet Eventual Consistency. Wenn eine Region nicht verfügbar ist, werden Bigtable-Anfragen automatisch an die andere Region gesendet. In diesem Fall wird Ihnen der Netzwerktraffic in die andere Region in Rechnung gestellt und Ihre Anwendung kann aufgrund der größeren Entfernung eine höhere Latenz haben.

Daten in der Nähe Ihrer Nutzer speichern

Wenn Ihre Nutzer auf der ganzen Welt verteilt sind, können Sie die Latenz reduzieren, indem Sie Ihre Anwendung in der Nähe Ihrer Nutzer ausführen und Ihre Daten möglichst nahe an der Anwendung platzieren. Mit Bigtable können Sie eine Instanz erstellen, die Cluster in mehreren Google Cloud-Regionen enthält. Ihre Daten werden dann automatisch in jeder Region repliziert.

Verwenden Sie für diesen Anwendungsfall App-Profile mit Single-Cluster-Routing. Multi-Cluster-Routing ist für diesen Anwendungsfall aufgrund der Entfernung zwischen Clustern ungeeignet. Wenn ein Cluster ausgefallen ist und das zugehörige Anwendungsprofil für Multi-Cluster-Routing den Traffic automatisch über eine große Entfernung umleitet, kann dies zu einer inakzeptablen Latenz führen und unerwartete zusätzliche Netzwerkkosten verursachen.

So konfigurieren Sie Ihre Instanz für diesen Anwendungsfall:

  1. Erstellen Sie eine Instanz mit Clustern in drei verschiedenen geografischen Regionen, beispielsweise USA, Europa und Asien.

  2. Platzieren Sie einen Anwendungsserver in der Nähe jeder Region.

  3. Erstellen Sie in etwa die folgenden Anwendungsprofile:

    • clickstream-us: Single-Cluster-Routing zum Cluster in den USA
    • clickstream-eu: Single-Cluster-Routing zum Cluster in Europa
    • clickstream-asia: Single-Cluster-Routing zum Cluster in Asien

In dieser Einrichtung verwendet Ihre Anwendung das Anwendungsprofil für den nächstgelegenen Cluster. Alle auf einem Cluster eingehenden Schreibvorgänge werden automatisch auf die anderen beiden Cluster repliziert.

Andere Anwendungsfälle

Wenn Ihr spezieller Anwendungsfall auf dieser Seite nicht beschrieben wird, bieten Ihnen die folgenden Fragen eventuell eine Hilfestellung für die richtige Konfiguration Ihrer Anwendungsprofile:

Nächste Schritte