Beispiele für Replikationseinstellungen

Auf dieser Seite werden einige häufige Anwendungsfälle für die Aktivierung der Bigtable-Replikation sowie die Einstellungen beschrieben, die Sie für diese Anwendungsfälle unterstützen können.

Batchanalysejobs von anderen Anwendungen isolieren
Hochverfügbarkeit einrichten
Back-ups praktisch in Echtzeit bereitstellen
Hochverfügbarkeit und regionale Ausfallsicherheit beibehalten
Daten in der Nähe Ihrer Nutzer speichern

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

Unabhängig von Ihrem Anwendungsfall müssen Sie immer in allen Clustern 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.

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:

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.
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.
Führen Sie mit dem Anwendungsprofil live-traffic eine Arbeitslast mit Live-Traffic aus.
Verwenden Sie während der Ausführung der Arbeitslast mit Live-Traffic das Anwendungsprofil batch-analytics, um eine Batcharbeitslast mit Lesevorgängen auszuführen.
Prüfen Sie die CPU-Auslastung für die Cluster der Instanz und fügen Sie den Clustern gegebenenfalls Knoten hinzu.
Überwachen 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:

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.
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
Verwenden Sie die Live-Traffic-Anwendungsprofile, um Arbeitslasten mit Live-Traffic auszuführen.
Verwenden Sie während der Ausführung der Arbeitslasten mit Live-Traffic das Anwendungsprofil batch-analytics, um eine schreibgeschützte Batcharbeitslast auszuführen.
Prüfen Sie die CPU-Auslastung für die Cluster der Instanz und fügen Sie den Clustern gegebenenfalls Knoten hinzu.
Überwachen 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 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.

Weitere Informationen dazu, wie Bigtable Hochverfügbarkeit beiträgt, finden Sie unter Mit Bigtable eine globale Datenpräsenz aufbauen .

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. Es wird empfohlen, 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
Stellen Sie für diese Konfiguration genügend Knoten bereit, um ein Ziel von 23 % der CPU-Auslastung für eine Instanz mit drei Clustern, drei Regionen und einer CPU-Auslastung von 3 % für eine Instanz mit vier Clustern zu gewährleisten. Dadurch wird sichergestellt, dass der gesamte Cluster bzw. die verbleibenden Cluster den gesamten Traffic verarbeiten können, selbst wenn zwei Regionen nicht verfügbar sind.
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
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, ä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
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. Mit dieser Option sind Ihre Daten auch dann verfügbar, wenn Sie keine Verbindung zu einer der Regionen herstellen können. Außerdem bietet sie 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:

Führen Sie unter Verwendung des App-Profils mit Multi-Cluster-Routing eine Testarbeitslast aus.
Überwachen Sie die Cluster der Instanz mit der Google Cloud Console und prüfen Sie, ob die Cluster eingehende Anfragen verarbeiten.
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.
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.
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 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.

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

So implementieren Sie diese Konfiguration:

Führen Sie unter Verwendung des App-Profils mit Single-Cluster-Routing eine Arbeitslast aus.
Überwachen Sie die Cluster der Instanz mit der Google Cloud Console und prüfen Sie, ob eingehende Anfragen nur von einem Cluster verarbeitet werden.

Der andere Cluster verwendet weiterhin CPU-Ressourcen für die Replikation und andere Wartungsaufgaben.
Aktualisieren Sie das App-Profil, 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.
Ü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:

Erstellen Sie eine Bigtable-Instanz mit 4 Clustern: 2 in Region A und 2 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
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.

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.

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.

Wenn Sie die Instanz zum ersten Mal einrichten, sollten Sie die CPU-Auslastung von 35% für jeden Cluster nicht ü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:

Führen Sie eine Testarbeitslast aus.
Überwachen Sie die Cluster der Instanz mit der Google Cloud Console und achten Sie darauf, dass alle vier Cluster eingehende Anfragen verarbeiten.
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.
Fahren Sie mit der Überwachung 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.
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.
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.
Fahren Sie mit der Überwachung 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.

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.