Edge for Private Cloud v4.18.05
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, an 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 von jeder Zeile im Cassandra-Cluster nur eine Kopie 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. Im Allgemeinen sollte der Replikationsfaktor die Anzahl der Cassandra-Knoten im Cluster nicht überschreiten.
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 dazu diesen Befehl aus:
/opt/apigee/apigee-cassandra/bin/cassandra-cli -h $(hostname -i) <<< "show 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 Schlüsselbereich kms 3 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.
Cassandra-Konsistenzgrad
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 Message Processor- und Management Server-Knoten eine Verbindung zu Cassandra für Lese- und Schreibvorgänge herstellen, verwenden sie in der Regel den Cassandra-Wert LOCAL_QUORUM, um die Konsistenzebene für einen Schlüsselbereich anzugeben. Einige Schlüsselräume sind jedoch so definiert, dass sie ein Konsistenzniveau von 1 verwenden.
So wird der Wert von LOCAL_QUORUM für ein Rechenzentrum berechnet:
LOCAL_QUORUM = (replication_factor/2) + 1
Wie oben beschrieben, beträgt der Standard-Replikationsfaktor für eine Edge-Produktionsumgebung mit drei Cassandra-Knoten drei. Der Standardwert von LOCAL_QUORUM ist daher (3/2) + 1 = 2 (der Wert wird auf eine ganze Zahl 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 kann der Cluster also einen Ausfall eines Knotens pro Rechenzentrum tolerieren.
Durch Angabe der Konsistenzebene als LOCAL_QUORUM 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" *
- Für die 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 zusätzliche Cassandra-Knoten hinzufügen, hat das keine Auswirkungen auf die Konsistenzebene.