Freigeben über

Ausführen von Apache Cassandra auf Azure-VMs

Achtung

Dieser Artikel bezieht sich auf CentOS, eine Linux-Distribution mit dem End-of-Life-(EOL-)Status. Sie sollten Ihre Nutzung entsprechend planen. Weitere Informationen finden Sie in der Anleitung zum Ende des Lebenszyklus von CentOS.

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 können. Verwenden Sie diese Empfehlungen als Grundlage und testen Sie gegen Ihre eigene Arbeitslast.

Azure Managed Instance für Apache Cassandra

Wenn Sie nach einem automatisierteren Dienst für die Ausführung von Apache Cassandra auf virtuellen Azure-Computern suchen, sollten Sie die Verwendung von Azure Managed Instance für Apache Cassandra in Betracht ziehen. Dieser Dienst automatisiert die Bereitstellung, Verwaltung (Patchen und Knotenintegrität) und Skalierung von Knoten innerhalb eines Apache Cassandra-Clusters. Es bietet auch die Möglichkeit für Hybridcluster, sodass Apache Cassandra-Rechenzentren, die in Azure bereitgestellt werden, einem vorhandenen lokalen oder von Drittanbietern gehosteten Cassandra-Ring beitreten können. Der Dienst wird mithilfe von 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 häufig entweder Standard_DS14_v2, Standard_DS13_v2, Standard_D16s_v5 oder Standard_E16s_v5 virtuellen Computer. Cassandra-Workloads profitieren von mehr Arbeitsspeicher in der VM. Berücksichtigen Sie daher die speicheroptimierten Größe virtueller Computer, z. B. Standard_DS14_v2 oder Standard_E16s_v5, oder lokal optimierte Speichergrößen wie Standard_L16s_v3.

Zur Sicherstellung von Haltbarkeit werden Daten und Commit-Logs häufig auf einem Stripeset von zwei bis vier 1-TB Premium-SSDs (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 größtmöglichen kombinierten Durchsatz und IOPS mit Premium-SSDs zu erzielen, empfehlen wir, einen Stripesatz von einigen 1-TB-Datenträgern zu erstellen, anstatt einen einzelnen 2-TB- oder 4-TB-Datenträger zu verwenden. 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.

Bewerten Sie Azure Ultra Disks für Cassandra-Workloads, die eine kleinere Festplattenkapazität benötigen. Sie können höhere IOPS/Durchsatz und niedrigere Latenz für VM-Größen wie Standard_E16s_v5 und Standard_D16s_v5 bereitstellen.

Für Cassandra-Workloads, die keinen dauerhaften Speicher benötigen – d. h., wo Daten leicht aus einem anderen Speichermedium wiederhergestellt werden können – erwägen Sie die Verwendung von Standard_L16s_v3 oder Standard_L16s_v2 VMs. Diese VMs-Größen weisen große und schnelle lokale temporäre NVM Express -Datenträger (NVMe) auf.

Weitere Informationen finden Sie unter Vergleich der Leistung von lokalen/temporären vs angefügten/permanenten Datenträgern (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 , die beschleunigte Vernetzung auf der NIC des Cassandra-Knotens und auf VMs zu aktivieren, auf denen Clientanwendungen 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 finden Sie unter Erstellen eines virtuellen Linux-Computers mit beschleunigtem Netzwerk.

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. Es wird empfohlen, azure Managed Disks 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. (Beispielsweise haben DS14_v2 virtuelle Maschinen einen maximalen zwischengespeicherten Durchsatz von 512 MBps im Vergleich zu einem nicht zwischengespeicherten Durchsatz von 768 MBps.)

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. Beispielsweise stellt DS14_v2 eine Cachegröße von 512 GB bereit, die bis zu 50% der Daten aus einem Cassandra-Knoten mit einer Datendichte von 1-2 TB speichern kann.

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 Vergleichen von Konfigurationen für die Zwischenspeicherung von Azure-VM-Datenträgern (GitHub).

Linux-Read-Ahead

In den meisten Linux-Distributionen, die für Azure im Microsoft Marketplace verfügbar sind, beträgt die Standardeinstellung für blockbasierte Gerätelesevorgänge 4096 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 Vergleich der Auswirkungen von Einstellungen für das Vorauslesen von Datenträgern (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 empfehlen wir die folgenden Ansätze:

  • 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 Messen der Auswirkungen von Mdadm-Blockgrößen auf die Cassandra-Leistung (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 schreibt Cassandra 3.x etwa alle 10 Sekunden Daten aus dem Arbeitsspeicher in die Commit-Log-Datei, und der Datenträger wird dabei nicht bei jedem Schreibvorgang berührt. 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.

Commit-Logs müssen beständig sein, damit ein neu gestarteter Node Daten, die noch nicht in den Datendateien enthalten sind, aus den gespülten Commit-Logs rekonstruieren kann. Um eine bessere Haltbarkeit zu erreichen, speichern Sie Commit-Protokolle auf Premium-SSDs und nicht auf lokalem Speicher, was verloren gehen kann, wenn die VM zu einem anderen Host migriert wird.

Basierend auf unseren Tests hat Cassandra auf CentOS 7.x möglicherweise eine geringere Schreibleistung, wenn Commit-Protokolle im xfs im Vergleich zum Ext4-Dateisystem vorhanden sind. Durch das Aktivieren der Komprimierung von Commit-Protokollen wird die Leistung von XFS 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 in Beobachtungen zu ext4- und xfs-Dateisystemen und komprimierten Commit-Protokollen (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. Verwenden Sie diese Tests, um zu bestätigen, dass die Leistung den Erwartungen entspricht, basierend auf der VM-Größe.

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

Weitere Informationen zum Ausführen von Leistungstests finden Sie unter Validating baseline Azure VM Performance (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 Vergleichen der relativen Leistung verschiedener Cassandra-Dokumentgrößen (GitHub).

Replikationsfaktor

Die meisten Cassandra-Workloads verwenden einen Replikationsfaktor (RF) von 3, wenn sie angefügte Premium-Datenträger und sogar 5 verwenden, wenn sie temporäre/kurzlebige lokale Datenträger verwenden. 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. Wenn Sie RF größer als 1 und eine Konsistenzstufe von LOCAL_QUORUM verwenden, ist es normal, dass die Lese- und Schreibleistung niedriger als die gleiche Workload ist, die mit RF 1 ausgeführt wird.

Weitere Informationen finden Sie unter Vergleich der relativen Leistung verschiedener Replikationsfaktoren (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.

Aus diesem Grund scheinen die zweite und nachfolgende Lesevorgänge bei der Ausführung von Leseleistungstests mit denselben Daten viel schneller zu sein als der ursprüngliche Lesevorgang, der für den Zugriff auf Daten auf dem Remotedatenträger oder aus dem Hostcache erforderlich ist, wenn ReadOnly aktiviert ist. 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. Wenn die ReadOnly-Zwischenspeicherung aktiviert ist, befinden sich die Daten möglicherweise im Hostcache, und nachfolgende Lesevorgänge sind auch nach dem Löschen des Betriebssystemseitencaches schneller und starten den Cassandra-Dienst neu.

Weitere Informationen finden Sie in Beobachtungen zur Cassandra-Verwendung von Linux-Seitenzwischenspeicherung (GitHub).

Replikation in mehreren Rechenzentren

Cassandra unterstützt nativ das Konzept mehrerer Rechenzentren, wodurch es einfach ist, einen Cassandra-Ring über mehrere Azure-Regionen oder verfügbarkeitsübergreifende Zonen innerhalb einer Region zu konfigurieren.

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.

Es ist wichtig, die Baseline-Roundtrip-Latenz zwischen Regionen zu messen. Die Netzwerklatenz zwischen Regionen kann 10- bis 100-mal höher als die Latenz innerhalb einer Region sein. Erwarten Sie eine Verzögerung bei der Anzeige von Daten in der zweiten Region, wenn Sie LOCAL_QUORUM-Schreibkonsistenz verwenden, oder eine signifikant verringerte Leistung der Schreibvorgänge, wenn Sie EACH_QUORUM verwenden.

Wenn Sie Apache Cassandra im Großen und speziell in einer Multi-DC-Umgebung ausführen, wird die Knotenreparatur schwierig. Tools wie Reaper können dabei helfen, Reparaturen im großen Umfang zu koordinieren (z. B. über alle Knoten in einem Rechenzentrum, nacheinander pro Rechenzentrum, um die Last für den gesamten Cluster zu begrenzen). Die Knotenreparatur für große Cluster bleibt jedoch eine ungelöste Herausforderung und gilt für alle Umgebungen, unabhängig davon, ob lokal oder in der Cloud.

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 Messen der Auswirkung der regionsüberschreitenden Replikation in einer Umgebung mit mehreren Domänencontrollern auf GitHub.

Hinted Handoff-Konfiguration

In einem multiregionalen Cassandra-Ring können Schreiblasten mit der Konsistenzstufe LOCAL_QUORUM in der sekundären Region Daten verlieren. 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 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:

Um nicht öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte

Weitere Informationen zu diesen Leistungsergebnissen finden Sie unter Cassandra auf Azure VMs Performance Experiments.

Weitere Informationen zu allgemeinen Cassandra-Einstellungen, nicht spezifisch für Azure, finden Sie unter:

  • Last updated on