Edge for Private Cloud Version 4.17.01
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üsselraum in einem Cassandra-Cluster wird als Replikationsfaktor des Schlüsselraums bezeichnet. Ein Replikationsfaktor von 1 bedeutet, dass nur eine Kopie jeder Zeile im Cassandra-Cluster vorhanden ist. Ein Replikationsfaktor von zwei bedeutet, dass es zwei Kopien jeder Zeile gibt, wobei sich jede Kopie auf einem anderen Knoten befindet. 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) <<< "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 Rechenzentrum 1, dc-1, der Standardreplikationsfaktor für den Schlüsselraum kms bei einer Installation mit drei Cassandra-Knoten drei beträgt.
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 höhere Latenz bei Datenschreibvorgängen.
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 eine Verbindung zu Cassandra für Lese- und Schreibvorgänge hergestellt wird, verwenden Message Processor- und Management Server-Knoten 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 die Konsistenzebene 1 verwendet wird.
So wird der Wert von LOCAL_QUORUM für ein Rechenzentrum 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 kann der Cluster also einen Ausfall eines Knotens pro Rechenzentrum tolerieren.
Durch Angabe der Konsistenzebene als LOCAL_QUORUM vermeidet Edge die Latenz, die bei der Validierung von Vorgängen in mehreren Rechenzentren erforderlich ist. Wenn ein Schlüsselraum den Cassandra-Wert QUORUM als Konsistenzebene verwendet, müssen Lese-/Schreibvorgänge in allen Rechenzentren validiert werden.
So zeigen Sie die Konsistenzebene an, die von den Edge Message Processor- oder 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 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.