Edge for Private Cloud v4.19.01
Informationen zum Cassandra-Replikationsfaktor
Cassandra speichert Datenreplikate auf mehreren Knoten, um Zuverlässigkeit und Fehlertoleranz zu gewährleisten. Die Replikationsstrategie für jeden Edge-Schlüsselraum bestimmt die Knoten, auf denen sich Replikate befinden platziert.
Die Gesamtzahl der Replikate für einen Schlüsselraum in einem Cassandra-Cluster wird als den Replikationsfaktor von keyspace. Ein Replikationsfaktor von 1 bedeutet, dass es nur einen Kopie jeder Zeile im Cassandra-Cluster. Ein Replikationsfaktor von zwei bedeutet, dass es zwei Kopien jeder Zeile, wobei sich jede Kopie auf einem anderen Knoten befindet. Alle Replikate sind gleich wichtig: gibt es keine primäre oder Master-Replikation.
In einem Produktionssystem mit drei oder mehr Cassandra-Knoten in jedem Rechenzentrum wird die Standardeinstellung Replikationsfaktor für einen Edge-Schlüsselraum ist 3. In der Regel ist der Replikationsfaktor sollte die Anzahl der Cassandra-Knoten im Cluster nicht überschreiten.
Mit dem folgenden Verfahren können Sie das Cassandra-Schema aufrufen, das den Replikationsfaktor zeigt für jeden Edge-Schlüsselraum:
- Melden Sie sich bei 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)der IP-Adresse des Cassandra-Knotens zugeordnet. Oder Sie kann$(hostname -i)durch die IP-Adresse des Knotens ersetzen.
Für jeden Schlüsselraum wird die Ausgabe in folgender Form 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 Standard-Replikationsfaktor für die
kms-Schlüsselraum entspricht drei für ein
mit drei Cassandra-Knoten installieren.
Wenn Sie dem Cluster zusätzliche Cassandra-Knoten hinzufügen, ist der Standard-Replikationsfaktor nicht betroffen sind.
Wenn Sie beispielsweise die Anzahl der Cassandra-Knoten auf sechs erhöhen, aber die Replikation 3 setzen, stellen Sie nicht sicher, dass alle Cassandra-Knoten über eine Kopie aller Daten verfügen. Wenn ein ausfällt, bedeutet ein höherer Replikationsfaktor eine höhere Wahrscheinlichkeit, dass die Daten auf dem Knoten noch auf einem der verbleibenden Knoten vorhanden ist. Der Nachteil eines höheren Replikationsfaktors Latenz bei Datenschreibvorgängen.
Cassandra-Konsistenzebene
Das Cassandra-Konsistenzniveau ist definiert als die Mindestanzahl von Cassandra-Knoten, die einen Lese- oder Schreibvorgang bestätigen, bevor der Vorgang als erfolgreich betrachtet werden kann. Verschiedenen Konsistenzebenen können verschiedenen Edge-Schlüsselbereichen zugewiesen werden.
Beim Herstellen einer Verbindung zu Cassandra für Lese- und Schreibvorgänge, Message Processor und Management
Serverknoten verwenden in der Regel den Cassandra-Wert LOCAL_QUORUM, um
gibt die Konsistenzebene für einen Schlüsselraum an. Einige Schlüsselbereiche sind jedoch so definiert, dass ein
Konsistenzstufe 1.
Der Wert von LOCAL_QUORUM für ein Rechenzentrum wird so berechnet:
LOCAL_QUORUM = (replication_factor/2) + 1
Wie oben beschrieben, kann der Standard-Replikationsfaktor für eine Edge-Produktionsumgebung mit
drei Cassandra-Knoten sind drei. Dementsprechend ist der Standardwert LOCAL_QUORUM =
(3/2) +1 = 2 (der Wert wird auf eine Ganzzahl abgerundet).
Wenn LOCAL_QUORUM = 2, sind mindestens zwei der drei Cassandra-Knoten in den Daten
um erfolgreich zu sein, muss das Center auf einen Lese-/Schreibvorgang reagieren. Für drei Knoten
Cassandra-Cluster konnte der Cluster daher tolerieren, dass ein Knoten pro Rechenzentrum ausgefallen ist.
Durch Angabe der Konsistenzebene als LOCAL_QUORUM vermeidet Edge die Latenz
die für die Validierung von Abläufen in mehreren Rechenzentren erforderlich sind. Wenn ein Schlüsselraum die Cassandra-
QUORUM als Konsistenzebene haben, müssen Lese-/Schreibvorgänge
in allen Rechenzentren validiert.
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 Konsistenz bei Schreibvorgängen:
grep -ri "write.consistencylevel" *
- Für Konsistenz bei Lesevorgängen:
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.