Edge for Private Cloud v4.18.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, 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 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. 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 den folgenden Befehl aus:
> /opt/apigee/apigee-cassandra/bin/cassandra-cli -h $(hostname -i) <<< "show schema;"
Dabei wird
$(hostname -i)der IP-Adresse des Cassandra-Knotens zugeordnet. 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 weitere Cassandra-Knoten hinzufügen, ist der Standardreplikationsfaktor nicht betroffen.
Wenn Sie beispielsweise die Anzahl der Cassandra-Knoten auf sechs erhöhen, aber den Replikationsfaktor bei 3 belassen, stellen Sie nicht sicher, 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 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.
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 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" *
- 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.