Beispiele für Replikationseinstellungen

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

Auf dieser Seite wird auch erläutert, wie Sie die richtigen Einstellungen auswählen, falls Ihr Anwendungsfall hier nicht enthalten ist.

Bevor Sie diese Seite lesen, sollten Sie sich mit den Informationen unter 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.

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 neue Instanz mit zwei Clustern oder fügen Sie einer vorhandenen Instanz einen zweiten Cluster hinzu.

    Folgen Sie den Empfohlenen Standardwerten für die CPU-Auslastung für diese Konfiguration.

  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.

  5. Prüfen Sie die CPU-Auslastung für die Cluster der Instanz und fügen Sie den Clustern gegebenenfalls Knoten hinzu.

  6. Prüfen Sie die clientseitige Latenz mit einem Tool Ihrer Wahl. Wenn Sie den HBase-Client für Java verwenden, können Sie die Latenz mit dessen clientseitigen Messwerten überwachen.

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

  1. Erstellen Sie eine neue Instanz mit drei Clustern oder fügen Sie einer vorhandenen Instanz Cluster hinzu, bis diese über drei Cluster verfügt.

    Folgen Sie den Empfohlenen Standardwerten für die CPU-Auslastung für diese Konfiguration.

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

    Verwenden Sie dieselbe Anzahl von Knoten in cluster-a und cluster-b, wenn beide Cluster den Traffic für dieselbe Anwendung verarbeiten. Verwenden Sie für die größere Arbeitslast eine höhere Anzahl von Knoten in cluster-c.

  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.

  5. Prüfen Sie die CPU-Auslastung für die Cluster der Instanz und fügen Sie den Clustern gegebenenfalls Knoten hinzu.

  6. Prüfen Sie die clientseitige Latenz mit einem Tool Ihrer Wahl. Wenn Sie den HBase-Client für Java verwenden, können Sie die Latenz mit dessen clientseitigen Messwerten prüfen.

Hochverfügbarkeit einrichten

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.

Für diesen Anwendungsfall müssen Sie ein neues Anwendungsprofil erstellen, das Multi-Cluster-Routing verwendet, oder das standardmäßige Anwendungsprofil für die Verwendung von Multi-Cluster-Routing aktualisieren. 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 mit mehreren Clustern verwenden.

Mit den folgenden Konfigurationen verbessern Sie die Verfügbarkeit:

  • Zwei Cluster in derselben Region, aber in unterschiedlichen Zonen. Diese Option bietet Hochverfügbarkeit und die Möglichkeit eines Failovers, ohne regionsübergreifende Replikationskosten zu verursachen. Daten in einer replizierten Cloud 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

    Folgen Sie den Empfohlenen Standardwerten für die CPU-Auslastung für diese Konfiguration.

  • Zwei Cluster in unterschiedlichen Regionen. Diese Konfiguration mit mehreren Regionen bietet Hochverfügbarkeit, wie auch die oben beschriebene Konfiguration mit mehreren 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

    Folgen Sie den Empfohlenen Standardwerten für die CPU-Auslastung für diese Konfiguration.

  • 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

    Beginnen Sie mit einer CPU-Auslastung von 35 % in der Region mit zwei Clustern und 70 % in der anderen Region. Überwachen Sie die Cluster der Instanz und passen Sie die Anzahl der Knoten nach Bedarf an, damit jeder Cluster über ausreichend Ressourcen für ein Failover verfügt.

Sie können ein Failover für diesen Anwendungsfall simulieren, um Ihre Anwendung zu testen:

  1. Führen Sie unter Verwendung des Anwendungsprofils mit Multi-Cluster-Routing eine Testarbeitslast aus.

  2. Prüfen Sie die Cluster der Instanz mit der Google Cloud Console und achten Sie darauf, dass die Cluster eingehende Anfragen verarbeiten.

  3. Löschen Sie einen der Cluster, um einen Ausfall zu simulieren.

    Mit dieser Änderung wird auch die Kopie Ihrer Daten gelöscht, die mit dem Cluster gespeichert wurde.

  4. Fahren Sie mit der Überwachung von Latenz und Fehlerraten fort. Wenn die verbleibenden Cluster ausreichend CPU-Ressourcen zur Verfügung haben, können sie eingehende Anfragen in der Regel bewältigen.

  5. Fügen Sie der Instanz einen Cluster hinzu und überwachen Sie sie weiter. Die Daten müssten jetzt auf den neuen Cluster repliziert werden.

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 Back-up-Cluster 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 im 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.

Folgen Sie den Empfohlenen Standardwerten für die CPU-Auslastung für diese Konfiguration.

So implementieren Sie diese Konfiguration:

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

  2. Prüfen 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 Anwendungsprofil, damit es auf den zweiten Cluster in der Instanz verweist.

    In einer Warnung wird Ihnen mitgeteilt, dass Read-Your-Writes-Konsistenz jetzt nicht mehr verfügbar ist, was auch bedeutet, dass strikte Konsistenz verlorengeht.

    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 jede Kundengruppe mit Cloud Bigtable-Clustern möglichst nahe am Kunden bedienen. 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 Cloud Bigtable-Instanz mit vier Clustern: zwei in Region A und zwei in Region B. Cluster in derselben Region müssen sich in unterschiedlichen 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 Cloud Bigtable Failovers automatisch aus. Wenn Sie Single-Cluster-Routing verwenden, entscheiden Sie nach eigenem Ermessen, wann ein Failover zu einem anderen Cluster erfolgen soll.

Multi-Cluster-Routing

Verwenden Sie für diesen Anwendungsfall Multi-Cluster-Routing, damit Cloud Bigtable automatisch ein Failover auf eine bestimmte Region ausführt, wenn Ihre Anwendung die andere Region nicht erreichen kann.

Zum Implementieren dieser Konfiguration erstellen Sie ein neues Anwendungsprofil, das Multi-Cluster-Routing verwendet, oder aktualisieren Sie das standardmäßige Anwendungsprofil zur Verwendung von Multi-Cluster-Routing.

Diese Konfiguration bietet Eventual Consistency. Wenn eine Region nicht verfügbar ist, werden Cloud 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.

Sie können nur ein einziges Anwendungsprofil mit Multi-Cluster-Routing pro Instanz verwenden. Sie können keine Kombination aus Multi-Cluster- und Single-Cluster-Routing-Profilen verwenden. Eine Instanz muss eines von beiden verwenden.

Bei der erstmaligen Konfiguration Ihrer Instanz sollten Sie versuchen, eine CPU-Auslastung von 35 % für jeden Cluster nicht zu überschreiten. Mit diesem Ziel sorgen Sie dafür, dass bei einem Failover jeder Cluster den Traffic verarbeiten kann, der normalerweise vom anderen Cluster in dessen Region verarbeitet wird. Möglicherweise müssen Sie dieses Ziel je nach Traffic und Nutzungsverhalten anpassen.

Sie können ein Failover für diesen Anwendungsfall simulieren, um Ihre Anwendung zu testen:

  1. Führen Sie eine Testarbeitslast aus.

  2. Beobachten Sie die Cluster der Instanz mit der Cloud Console und achten Sie darauf, dass alle vier Cluster eingehende Anfragen verarbeiten.

  3. Löschen Sie einen der Cluster in Region A, um ein Problem mit dem Herstellen einer Verbindung zu einer Zone zu simulieren.

    Mit dieser Änderung wird auch die Kopie Ihrer Daten gelöscht, die mit dem Cluster gespeichert wurde.

  4. Fahren Sie mit dem Monitoring von Latenz und Fehlerraten der verbliebenen Cluster fort.

    Wenn den Clustern ausreichend CPU-Ressourcen zur Verfügung stehen, können sie eingehende Anfragen in der Regel bewältigen.

  5. Fügen Sie der Instanz in Region A einen Cluster hinzu und überwachen Sie die Instanz weiter.

    Die Daten werden jetzt auf den neuen Cluster repliziert.

  6. Löschen Sie beide Cluster in Region A, um ein Problem mit dem Herstellen einer Verbindung zu einer Zone zu simulieren.

    Mit dieser Änderung werden die Kopien Ihrer Daten gelöscht, die sich in diesen Clustern befanden.

  7. Fahren Sie mit dem Monitoring von Latenz und Fehlerraten der verbliebenen Cluster fort.

    Wenn den Clustern ausreichend CPU-Ressourcen zur Verfügung stehen, können sie eingehende Anfragen, die vorher von der anderen Region verarbeitet wurden, in der Regel bewältigen. Wenn die Cluster nicht über ausreichend Ressourcen verfügen, müssen Sie möglicherweise die Anzahl der Knoten anpassen.

Single-Cluster-Routing

Sie können Single-Cluster-Routing für diesen Anwendungsfall verwenden, wenn für den Cloud Bigtable-Cluster bei Ausfall einer Zone oder Region nicht automatisch ein Failover ausgeführt werden soll. Diese Option eignet sich für den Fall, dass Sie die Kosten und Latenzen verwalten möchten, die entstehen können, wenn Cloud Bigtable den Traffic von und an eine(r) weit entfernte(n) Region weiterleitet, oder wenn Sie Failover-Entscheidungen auf der Grundlage Ihrer eigenen Beurteilung oder Geschäftsregeln treffen möchten.

Zum Implementieren dieser Konfiguration erstellen Sie vier Anwendungsprofile, die Single-Cluster-Routing verwenden. Jedes Anwendungsprofil wird an einen anderen Cluster in der Cloud Bigtable-Instanz weitergeleitet.

Folgen Sie den Empfohlenen Standardwerten für die CPU-Auslastung für diese Konfiguration.

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.

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 Cloud Bigtable können Sie eine Instanz erstellen, die Cluster in mehreren Google Cloud-Regionen enthält. Ihre Daten werden dann in jeder Region automatisch repliziert.

Verwenden Sie für diesen Anwendungsfall Anwendungsprofile 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.

    Folgen Sie den Empfohlenen Standardwerten für die CPU-Auslastung für diese Konfiguration.

  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:

Weitere Informationen