Beispiele für Replikationskonfigurationen

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

Auf dieser Seite wird auch erläutert, wie Sie Einstellungen für andere Anwendungsfälle festlegen.

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 aktivieren Sie Autoscaling für die Cluster Ihrer Instanz. Mit Autoscaling kann Bigtable automatisch Knoten einem Cluster basierend auf der Arbeitslast hinzufügen und daraus entfernen.

Wenn Sie sich stattdessen für die manuelle Knotenzuweisung entscheiden, sollten Sie in jedem Cluster einer Instanz genügend Knoten bereitstellen, damit jeder Cluster die Replikation zusätzlich zur Last der Anwendungen bewältigen kann. Wenn ein Cluster nicht genügend Knoten hat, kann sich die Replikationsverzögerung erhöhen, der Cluster kann aufgrund von Arbeitsspeicheraufwand zu Leistungsproblemen führen und Schreibvorgänge in andere Cluster in der Instanz werden möglicherweise abgelehnt.

Die Beispiele in diesem Dokument beschreiben das Erstellen einer Instanz. 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, eines mit dem Namen live-traffic und eines mit dem Namen 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 Cluster hat, sind die Langlebigkeit und Verfügbarkeit Ihrer Daten auf die Zone beschränkt, in der sich der 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 Hochverfügbarkeit ist eine Instanz mit N+2-Clustern, die sich jeweils in einer anderen Region befinden. Wenn beispielsweise die Mindestanzahl von Clustern, die Sie für die Bereitstellung Ihrer Daten benötigen, zwei sind, benötigen Sie eine Instanz mit vier Clustern, um die Hochverfügbarkeit aufrechtzuerhalten. Diese Konfiguration sorgt für Betriebszeit auch in dem seltenen Fall, dass zwei Regionen nicht 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. Mit 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 Cluster in Region B haben. Wenn Sie in Region B schreiben, werden Ihnen doppelt berechnet, da Sie zwei Cluster in Region A 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.

Um die Instanz für diesen Anwendungsfall zu konfigurieren, erstellen Sie ein Anwendungsprofil mit Single-Cluster-Routing oder aktualisieren Sie das standardmäßige Anwendungsprofil zur Verwendung von Single-Cluster-Routing. 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. Verwenden Sie ein Anwendungsprofil mit Single-Cluster-Routing, um eine Arbeitslast auszuführen.

  2. Überwachen Sie die Cluster der Instanz mit der Google Cloud Console und prüfen Sie, ob 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 Read-Your-Writes-Konsistenz jetzt nicht mehr verfügbar ist, was auch bedeutet, dass Strong Consistency verloren geht.

    Wenn Sie Transaktionen für einzelne Zeilen aktiviert haben, erhalten Sie auch eine Warnung zu einem möglichen Datenverlust. 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