Ausführen von Apache Cassandra auf Azure-VMs

  • Artikel

Achtung

Dieser Artikel bezieht sich auf CentOS, eine Linux-Distribution, die sich dem End-of-Life-Status (EOL) nähert. Sie sollten Ihre Nutzung entsprechend planen. Weitere Informationen finden Sie im CentOS-Leitfaden für das Lebensende.

Dieser Artikel enthält Überlegungen zur Leistung beim Ausführen von Apache Cassandra auf virtuellen Azure-Computern.

Diese Empfehlungen basieren auf den Ergebnissen von Leistungstests, die Sie auf GitHub finden. Nutzen Sie diese Empfehlungen als Baseline, und führen Sie Tests für ihre eigene Workload aus.

Azure Managed Instance for Apache Cassandra

Wenn Sie einen stärker automatisierten Dienst für die Ausführung von Apache Cassandra auf virtuellen Azure-Computern suchen, erwägen Sie die Verwendung von Azure Managed Instance for Apache Cassandra. Dieser Dienst automatisiert die Bereitstellung, Verwaltung (Patchen und Knotenintegrität) und Skalierung von Knoten innerhalb eines Apache Cassandra-Clusters. Er bietet außerdem die Möglichkeit von Hybridclustern, sodass in Azure bereitgestellte Apache Cassandra-Rechenzentren einem vorhandenen lokalen oder von Drittanbietern gehosteten Cassandra-Ring beitreten können. Der Dienst wird mithilfe von Microsoft Azure Virtual Machine Scale Sets bereitgestellt. Die folgenden Empfehlungen wurden während der Entwicklung dieses Diensts übernommen.

VM-Größen und Datenträgertypen in Azure

Cassandra-Workloads in Azure verwenden im Allgemeinen virtuelle Computer der Größen Standard_DS14_v2, Standard_DS13_v2, Standard_D16s_v5 oder Standard_E16s_v5. Cassandra-Workloads profitieren von einem größeren Arbeitsspeicher in der VM, erwägen Sie daher, virtuelle Computer mit arbeitsspeicheroptimierten Größen wie Standard_DS14_v2 oder Standard_E16s_v5 oder mit lokal datenspeicheroptimierter Größe wie Standard_L16s_v3 zu verwenden.

Aus Gründen der Robustheit werden Daten- und Commitprotokolle häufig auf einem Stripeset von zwei bis vier 1-TB-Managed Disks Premium (P30) gespeichert.

Cassandra-Knoten sollten keine zu große Datendichte aufweisen. Es wird empfohlen, höchstens 1 bis 2 TB Daten pro VM zu verwalten und ausreichend freien Speicherplatz für die Komprimierung bereitzustellen. Um den höchstmöglichen kombinierten Durchsatz und IOPS mit Managed Disks Premium zu erreichen, empfehlen wir, ein Stripeset mit verschiedenen 1-TB-Datenträgern zu erstellen und keinen einzigen Datenträger mit einer Größe von 2 TB oder 4 TB. Auf einer DS14_v2-VM haben beispielsweise vier 1-TB-Datenträger einen maximalen IOPS von 4 × 5000 = 20 K, im Gegensatz zu 7,5 K für einen einzigen 4-TB-Datenträger.

Ziehen Sie Azure Ultra Disks für Cassandra-Workloads in Betracht, bei denen eine geringere Datenträgerkapazität erforderlich ist. Sie können einen höheren IOPS/Durchsatz bei geringerer Latenz für VM-Größen wie Standard_E16s_v5 und Standard_D16s_v5 sicherstellen.

Für Cassandra-Workloads, die keinen permanenten Speicher benötigen, d. h., bei denen Daten auf einfache Weise von einem anderen Speichermedium rekonstruiert werden können, erwägen Sie die Verwendung der VM-Versionen Standard_L16s_v3 oder Standard_L16s_v2. Diese VMs-Größen weisen große und schnelle lokale temporäre NVMe-Datenträger auf.

Weitere Informationen finden Sie unter Comparing performance of Azure local/ephemeral vs attached/persistent disks (Vergleichen der Leistung auf lokalen/kurzlebigen mit angefügten/persistenten Datenträgern in Azure) auf GitHub.

Beschleunigter Netzwerkbetrieb

Cassandra-Knoten verwenden das Netzwerk intensiv, um Daten von der Client-VM zu senden und zu empfangen und um für Replikationszwecke zwischen Knoten zu kommunizieren. Zum Optimieren der Leistung profitieren Cassandra-VMs von hohem Durchsatz und einem Netzwerk mit niedriger Latenz.

Es wird empfohlen, den beschleunigten Netzwerkbetrieb auf der NIC des Cassandra-Knotens und auf VMs mit Clientanwendungen zu aktivieren, die auf Cassandra zugreifen.

Für den beschleunigten Netzwerkbetrieb wird eine moderne Linux-Distribution mit den aktuellen Treibern benötigt, z. B. Cent OS 7.5+ oder Ubuntu 16.x/18.x. Weitere Informationen hierzu finden Sie unter Erstellen eines virtuellen Linux-Computers mit beschleunigtem Netzwerkbetrieb.

Zwischenspeichern von Azure-VM-Datenträgern

Für Cassandra-Leseworkloads ist die beste Leistung zu beobachten, wenn die Latenz für Datenträger mit wahlfreiem Zugriff niedrig ist. Wir empfehlen, verwaltete Azure-Datenträger mit aktivierter ReadOnly-Zwischenspeicherung zu verwenden. Die ReadOnly-Zwischenspeicherung bietet eine niedrigere durchschnittliche Latenz, da die Daten aus dem Cache auf dem Host gelesen und nicht an den Back-End-Speicher gesendet werden.

Leseintensive Workloads mit zufälligen Lesevorgängen wie Cassandra profitieren von der niedrigeren Leselatenz, obgleich der zwischengespeicherte Modus niedrigere Durchsatzgrenzen als der nicht zwischengespeicherte Modus aufweist. (Virtuelle DS14_v2-Computer haben einen maximalen zwischengespeicherten Durchsatz von 512 MB/s, im Vergleich zu einem nicht zwischengespeicherten Durchsatz von 768 MB/s.)

Die schreibgeschützte Zwischenspeicherung ist besonders hilfreich für Cassandra-Zeitreihen und andere Workloads, bei denen das Arbeitsdataset in den Hostcache passt und die Daten nicht ständig überschrieben werden. DS14_v2 bietet z. B. eine Cachegröße von 512 GB; damit könnten bis zu 50 % der Daten von einem Cassandra-Knoten mit einer Datendichte von 1 bis 2 TB gespeichert werden.

Bei aktivierter schreibgeschützter Zwischenspeicherung gibt es keine wesentlichen Leistungseinbußen aufgrund von Cachefehlern. Daher empfiehlt sich der zwischengespeicherte Modus für sämtliche Workloads, außer für höchst schreibintensive Workloads.

Weitere Informationen finden Sie unter Comparing Azure VM data disk caching configurations (Vergleichen der Konfigurationen für das Zwischenspeichern von Azure-VM-Datenträgern) auf GitHub.

Linux-Read-Ahead

In den meisten Linux-Distributionen im Azure Marketplace ist die Read-Ahead-Standardeinstellung für Blockgeräte 4.096 KB. Die von Cassandra gelesenen E/As sind im Allgemeinen zufällig und relativ klein. Daher wird durch einen großen Read-Ahead Durchsatz vergeudet, da Teile von Dateien gelesen werden, die nicht benötigt werden.

Um den unnötigen Lookahead zu minimieren, legen Sie die Read-Ahead-Einstellung für Linux-Blockgeräte auf 8 KB fest. (Siehe Empfohlene Produktionseinstellungen in der DataStax-Dokumentation.)

Konfigurieren Sie einen Read-Ahead von 8 KB für alle Blockgeräte im Stripeset und auf dem Arraygerät selbst (z. B. /dev/md0).

Weitere Informationen finden Sie unter Comparing impact of disk read-ahead settings (Vergleichen der Auswirkungen von Read-Ahead-Einstellungen für Datenträger) auf GitHub.

mdadm-Blockgröße für Datenträgerarrays

Beim Ausführen von Cassandra in Azure wird häufig ein mdadm-Stripeset (d. h. RAID 0) von mehreren Datenträgern erstellt, um den Gesamtdurchsatz für Datenträger und IOPS in Richtung der VM-Grenzwerte zu steigern. Die optimale Datenträger-Stripegröße ist eine anwendungsspezifische Einstellung. Für SQL Server-OLTP-Workloads wird beispielsweise ein Wert von 64 KB empfohlen. Für Data Warehousing-Workloads beträgt die empfohlene Einstellung 256 KB.

Unsere Tests haben keinen signifikanten Unterschied zwischen Blockgrößen von 64 KB, 128 KB und 256 KB für Cassandra-Leseworkloads ergeben. Die Blockgröße 128 KB scheint einen kleinen, kaum feststellbaren Vorteil zu bieten. Daher wird Folgendes empfohlen:

  • Wenn Sie bereits eine Blockgröße von 64 KB oder 256 KB verwenden, ist es nicht sinnvoll, das Datenträgerarray neu zu erstellen und eine Größe von 128 KB zu verwenden.

  • Bei einer neuen Konfiguration ist es sinnvoll, 128 KB von Anfang an zu verwenden.

Weitere Informationen finden Sie unter Measuring impact of mdadm chunk sizes on Cassandra performance (Messen der Auswirkung von mdadm-Blockgrößen auf die Cassandra-Leistung) auf GitHub.

Commitprotokoll-Dateisystem

Für Cassandra-Schreibvorgänge wird die beste Leistung erzielt, wenn sich Commitprotokolle auf Datenträgern mit hohem Durchsatz und niedriger Latenz befinden. In der Standardkonfiguration leert Cassandra 3.x etwa alle 10 Sekunden Daten aus dem Arbeitsspeicher in die Commitprotokolldatei, und auf den Datenträger wird nicht bei jedem Schreibvorgang zugegriffen. In dieser Konfiguration ist kein Unterschied hinsichtlich der Schreibleistung zu beobachten, egal, ob sich das Commitprotokoll auf angefügten Premium-Datenträgern oder auf lokalen/kurzlebigen Datenträgern befindet.

Commitprotokolle müssen permanent sein, damit ein neu gestarteter Knoten noch nicht in den Datendateien enthaltene Daten aus den geleerten Commitprotokollen wiederherstellen kann. Um die Dauerhaftigkeit zu verbessern, speichern Sie Commitprotokolle auf Managed Disks Premium und nicht im lokalen Speicher, der verloren gehen kann, wenn die VM zu einem anderen Host migriert wird.

Laut unseren Tests kann Cassandra unter CentOS 7.x eine niedrigere Schreibleistung haben, wenn sich Commitprotokolle auf dem xfs-Dateisystem und nicht auf dem ext4-Dateisystem befinden. Durch Aktivieren der Komprimierung von Commitprotokollen wird die xfs-Leistung an die von ext4 angeglichen. Unsere Tests haben ergeben, dass die Leistung von xfs mit Komprimierung ebenso gut wie die Leistung von ext4 mit und ohne Komprimierung ist.

Weitere Informationen finden Sie unter Beobachtungen zu den Dateisystemen ext4 und xfs und komprimierten Commitprotokollen auf GitHub.

Messen der VM-Baselineleistung

Führen Sie nach dem Bereitstellen der VMs für den Cassandra-Ring einige synthetische Tests aus, um die Netzwerk- und Datenträger-Baselineleistung zu ermitteln. Vergewissern Sie sich anhand dieser Tests, dass die Leistung hinsichtlich der VM-Größe den Erwartungen entspricht.

Wenn Sie später die tatsächliche Workload ausführen, erleichtert Ihnen die ermittelte Baselineleistung das Untersuchen potenzieller Engpässe. Wenn Ihnen beispielsweise die Baselineleistung für den ausgehenden Netzwerkdatenverkehr auf der VM bekannt ist, können Sie das Netzwerk möglicherweise als Engpass ausschließen.

Weitere Informationen zum Ausführen von Leistungstests finden Sie unter Validating baseline Azure VM Performance (Validieren der Azure-VM-Baselineleistung) auf GitHub.

Dokumentgröße

Die Lese- und Schreibleistung von Cassandra hängt von der Dokumentgröße ab. Beim Lesen oder Schreiben größerer Dokumente ist davon auszugehen, dass eine höhere Latenz und weniger Vorgänge/Sekunde zu beobachten sind.

Weitere Informationen finden Sie unter Comparing relative performance of various Cassandra document sizes (Vergleichen der relativen Leistung für verschiedene Cassandra-Dokumentgrößen) auf GitHub.

Replikationsfaktor

Für die meisten Cassandra-Workloads gilt ein Replikationsfaktor (RF) von 3, wenn angefügte Premium-Datenträger verwendet werden; der Faktor beträgt sogar 5, wenn temporäre/kurzlebige lokale Datenträger verwendet werden. Die Anzahl der Knoten im Cassandra-Ring muss einem Vielfachen des Replikationsfaktors entsprechen. RF 3 impliziert beispielsweise einen Ring von 3, 6, 9 oder 12 Knoten, bei RF 5 hingegen sind 5, 10, 15 oder 20 Knoten vorhanden. Wird ein RF größer als 1 bei einer Konsistenzebene von LOCAL_QUORUM verwendet, ist die Lese- und Schreibleistung normalerweise geringer als die derselben Workload, die mit RF 1 ausgeführt wird.

Weitere Informationen finden Sie unter Comparing relative performance of various replication factors (Vergleichen der relativen Leistung verschiedener Replikationsfaktoren) auf GitHub.

Zwischenspeichern von Seiten unter Linux

Beim Lesen von Datendateien verwendet der Java-Code in Cassandra reguläre Datei-E/A-Vorgänge und profitiert vom Zwischenspeichern von Seiten unter Linux. Nachdem Teile der Datei einmalig gelesen wurden, wird der gelesene Inhalt im Betriebssystem-Seitencache gespeichert. Der nachfolgende Lesezugriff auf dieselben Daten ist viel schneller.

Daher erscheinen beim Durchführen von Tests zur Leseleistung für dieselben Daten der zweite und nachfolgende Lesevorgänge viel schneller als der ursprüngliche Lesevorgang, bei dem auf Daten auf dem Remotedatenträger bzw. bei Aktivierung von ReadOnly im Hostcache zugegriffen werden musste. Um ähnliche Leistungsmesswerte in nachfolgenden Ausführungen zu erhalten, leeren Sie den Linux-Seitencache, und starten Sie den Cassandra-Dienst neu, um dessen internen Speicher zu leeren. Bei Aktivierung der ReadOnly-Zwischenspeicherung befinden sich die Daten möglicherweise im Hostcache, und nachfolgende Lesevorgänge sind selbst nach dem Leeren des Betriebssystem-Seitencaches und dem Neustarten des Cassandra-Diensts schneller.

Weitere Informationen finden Sie unter Observations on Cassandra usage of Linux page caching (Beobachtungen zur Cassandra-Verwendung des Zwischenspeicherns von Seiten in Linux) auf GitHub.

Replikation in mehreren Rechenzentren

Cassandra unterstützt nativ das Konzept mehrerer Rechenzentren. Dies erleichtert das Konfigurieren eines Cassandra-Rings über mehrere Azure-Regionen hinweg oder über Verfügbarkeitszonen in einer Region hinweg.

Verwenden Sie für eine Bereitstellung über mehrere Regionen das globale VNET-Peering von Azure, um die virtuellen Netzwerke in den verschiedenen Regionen miteinander zu verbinden. Wenn VMs in derselben Region, aber in separaten Verfügbarkeitszonen bereitgestellt werden, können sich die VMs im selben virtuellen Netzwerk befinden.

Die Baseline-Roundtrip-Latenz zwischen Regionen muss unbedingt gemessen werden. Die Netzwerklatenz zwischen Regionen kann 10- bis 100-mal höher als die Latenz innerhalb einer Region sein. Erwarten Sie eine Verzögerung der Anzeige von Daten in der zweiten Region, wenn die Schreibkonsistenz LOCAL_QUORUM verwendet wird, oder eine erheblich reduzierte Leistung von Schreibvorgängen, wenn EACH_QUORUM verwendet wird.

Beim Ausführen von Apache Cassandra im großen Stil und insbesondere in einer Umgebung mit mehreren Domänencontrollern ist das Reparieren von Knoten eine Herausforderung. Mithilfe von Tools wie Reaper können Sie Reparaturen im gewünschten Umfang koordinieren (z. B. für sämtliche Knoten in einem Rechenzentrum, jeweils ein Rechenzentrum, um die Last für den gesamten Cluster zu begrenzen). Das Reparieren von Knoten für große Cluster ist jedoch weiterhin problematisch, und dies gilt für alle Umgebungen, seien es lokale oder Cloudumgebungen.

Beim Hinzufügen von Knoten zu einer sekundären Region wird die Leistung nicht linear skaliert, da eine bestimmte Menge von Bandbreiten- und CPU/Datenträger-Ressourcen für das Senden und Empfangen von Replikationsdaten zwischen den Regionen genutzt wird.

Weitere Informationen finden Sie unter Measuring impact of multi-dc cross-region replication (Messen der Auswirkung der regionsüberschreitenden Replikation in einer Umgebung mit mehreren Domänencontrollern) auf GitHub.

Hinted Handoff-Konfiguration

In einem Cassandra-Ring über mehrere Regionen können bei Schreibworkloads mit der Konsistenzebene LOCAL_QUORUM Daten in der sekundären Region verloren gehen. Standardmäßig wird Cassandra-Hinted Handoff auf einen relativ niedrigen maximalen Durchsatz und eine Hint-Lebensdauer von drei Stunden gedrosselt. Für Workloads mit intensiven Schreibvorgängen empfiehlt es sich, die Hinted Handoff-Drosselung zu erhöhen und das Hint-Zeitfenster zu vergrößern, um zu verhindern, dass Hints vor ihrer Replikation gelöscht werden.

Weitere Informationen finden Sie unter Observations on hinted handoff in cross-region replication (Beobachtungen zu Hinted Handoffs bei der regionsüberschreitenden Replikation) auf GitHub.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Andere Mitwirkende:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Weitere Informationen zu diesen Leistungsergebnissen finden Sie unter Cassandra on Azure VMs Performance Experiments (Leistungsexperimente für Cassandra auf Azure-VMs).

Informationen zu allgemeinen Cassandra-Einstellungen, die nicht spezifisch für Azure sind, finden Sie hier: