Edge for Private Cloud Version 4.17.09
Cassandra-Replikationsfaktor
Cassandra speichert Datenreplikate auf mehreren Knoten, um Zuverlässigkeit und Fehlertoleranz zu gewährleisten. Die Replikationsstrategie für jeden Edge-Schlüsselbereich bestimmt die Knoten, auf denen Replikate platziert werden.
Die Gesamtzahl der Replikate für einen Schlüsselbereich in einem Cassandra-Cluster wird als Replikationsfaktor des Schlüsselbereichs bezeichnet. Ein Replikationsfaktor von 1 bedeutet, dass es nur eine Kopie jeder Zeile im Cassandra-Cluster gibt. Ein Replikationsfaktor von 2 bedeutet, dass es zwei Kopien jeder Zeile gibt, die sich jeweils auf einem anderen Knoten befinden. Alle Replikate sind gleich wichtig. Es gibt kein primäres oder Master-Replikat.
In einem Produktionssystem mit drei oder mehr Cassandra-Knoten in jedem Rechenzentrum beträgt der Standardreplizierungsfaktor für einen Edge-Schlüsselbereich 3. Als allgemeine Regel gilt, dass der Replikationsfaktor die Anzahl der Cassandra-Knoten im Cluster nicht überschreiten darf.
So rufen Sie das Cassandra-Schema auf, in dem der Replikationsfaktor für jeden Edge-Schlüsselbereich angezeigt wird:
- Melden Sie sich in einem Cassandra-Knoten an.
- Führen Sie den folgenden Befehl aus:
> /opt/apigee/apigee-cassandra/bin/cassandra-cli -h $(hostname -i) <<< "schema;"
Dabei wird $(hostname -i) in die IP-Adresse des Cassandra-Knotens aufgelöst. Sie können $(hostname -i) auch durch die IP-Adresse des Knotens ersetzen.
Für jeden Schlüsselbereich wird die folgende Ausgabe angezeigt:
create keyspace kms
with placement_strategy = 'NetworkTopologyStrategy'
and strategy_options = {dc-1 : 3}
and durable_writes = true;
Sie sehen, dass für das Rechenzentrum 1, dc-1, der Standardreplizierungsfaktor für den kms-Schlüsselbereich drei ist, bei einer Installation mit drei Cassandra-Knoten.
Wenn Sie dem Cluster zusätzliche Cassandra-Knoten hinzufügen, hat das keine Auswirkungen auf den Standardreplizierungsfaktor.
Wenn Sie beispielsweise die Anzahl der Cassandra-Knoten auf sechs erhöhen, den Replikationsfaktor aber bei drei belassen, ist nicht gewährleistet, dass alle Cassandra-Knoten eine Kopie aller Daten haben. Wenn ein Knoten ausfällt, bedeutet ein höherer Replikationsfaktor eine höhere Wahrscheinlichkeit, dass die Daten auf dem Knoten auf einem der verbleibenden Knoten vorhanden sind. Der Nachteil eines höheren Replikationsfaktors ist eine erhöhte Latenz bei Datenschreiben.
Informationen zum Cassandra-Konsistenzniveau
Die Cassandra-Konsistenzebene wird als Mindestanzahl von Cassandra-Knoten definiert, die einen Lese- oder Schreibvorgang bestätigen müssen, bevor der Vorgang als erfolgreich betrachtet werden kann. Unterschiedlichen Edge-Schlüsselbereichen können unterschiedliche Konsistenzebenen zugewiesen werden.
Wenn Sie für Lese- und Schreibvorgänge eine Verbindung zu Cassandra herstellen, verwenden die Knoten des Message Processor und des Management Servers normalerweise den Cassandra-Wert LOCAL_QUORUM, um die Konsistenzebene für einen Schlüsselbereich anzugeben. Einige Schlüsselräume sind jedoch so definiert, dass für sie ein Konsistenzgrad von 1 verwendet wird.
Der Wert von LOCAL_QUORUM für ein Rechenzentrum wird so berechnet:
LOCAL_QUORUM = (replication_factor/2) + 1
Wie oben beschrieben, beträgt der Standardreplikationsfaktor für eine Edge-Produktionsumgebung mit drei Cassandra-Knoten drei. Daher ist der Standardwert von LOCAL_QUORUM = (3/2) + 1 = 2 (der Wert wird auf eine Ganzzahl abgerundet).
Bei LOCAL_QUORUM = 2 müssen mindestens zwei der drei Cassandra-Knoten im Rechenzentrum auf einen Lese-/Schreibvorgang antworten, damit der Vorgang erfolgreich ist. Bei einem Cassandra-Cluster mit drei Knoten könnte der Cluster daher tolerieren, dass ein Knoten pro Rechenzentrum ausgefallen ist.
Wenn Sie die Konsistenzebene als LOCAL_QUORUM angeben, vermeidet Edge die Latenz, die durch die Validierung von Vorgängen in mehreren Rechenzentren erforderlich ist. Wenn für einen Schlüsselbereich der Cassandra-Wert QUORUM als Konsistenzebene verwendet wird, müssen Lese-/Schreibvorgänge in allen Rechenzentren validiert werden.
So rufen Sie die Konsistenzebene auf, die vom Edge Message Processor oder den Management Server-Knoten verwendet wird:
- Melden Sie sich bei einem Message Processor-Knoten an.
- Wechseln Sie zum Verzeichnis /opt/apigee/edge-message-processor/conf:
> cd /opt/apigee/edge-message-processor/conf - Für Schreibkonsistenz:
> grep -ri "write.Consistencylevel" * - Lesekonsistenz:
> grep -ri "read.consistencylevel" * - Melden Sie sich beim Knoten des Verwaltungsservers an.
- Wechseln Sie zum Verzeichnis /opt/apigee/edge-management-server/conf:
> cd /opt/apigee/edge-management-server/conf - Wiederholen Sie die Schritte 3 und 4.
Wenn Sie dem Cluster weitere Cassandra-Knoten hinzufügen, hat dies keine Auswirkungen auf die Konsistenzebene.