Technologien zur Leistungssteigerung, die auf der Nutzung von SSDs basieren und in Speicher- und Datenspeicherlösungen weit verbreitet sind, wurden bereits vor geraumer Zeit entwickelt. An erster Stelle steht die Verwendung von SSDs als Speichermedium, was zu 100 % effektiv, aber auch kostspielig ist. Deshalb kommen Techniken wie Tiering und Caching zum Einsatz, bei denen SSDs nur für die am häufigsten benötigten ('heißen') Daten verwendet werden. Tiering eignet sich gut für langfristige Szenarien (Tage-Wochen) mit 'heißen' Daten, während Caching hingegen für kurzfristige Anwendungen (Minuten-Stunden) ausgelegt ist. Beide Optionen sind in Speicherlösungen implementiert. . In diesem Artikel werden wir die Implementierung des zweiten Algorithmus betrachten – .
Das Konzept der SSD-Caching-Technologie besteht darin, SSDs als intermediären Cache zwischen Festplatten und dem Arbeitsspeicher des Controllers zu verwenden. Die Leistung von SSDs ist zwar geringer als die des eigenen Caches des Controllers, jedoch ist das Volumen um ein Vielfaches größer. Daher erhalten wir einen Kompromiss zwischen Geschwindigkeit und Volumen.
Anwendungen für das Lesen von SSD-Caches:
- Die Überlegenheit von Lesevorgängen gegenüber Schreibvorgängen (typisch für Datenbanken und Webanwendungen);
- Das Vorhandensein eines Engpasses durch die Leistung des Festplattenarrays;
- Das Volumen der nachgefragten Daten ist geringer als das Volumen des SSD-Caches.
Die Gründe für die Verwendung von SSD-Caches für Lese- und Schreibvorgänge sind dieselben, mit Ausnahme der Art der Operationen – gemischter Typ (z. B. Datei-Server).
Die meisten Anbieter von Speicherlösungen verwenden in ihren Produkten SSD-Caches nur für Lesevorgänge. Ein grundlegender Unterschied zu ihnen besteht darin, dass der Cache auch für Schreiboperationen genutzt werden kann. Um die Funktionalität des SSD-Cachings in den QSAN-Speichersystemen zu aktivieren, ist der Erwerb einer separaten Lizenz erforderlich (wird in elektronischer Form bereitgestellt).
Der SSD-Cache in XCubeSAN wird physisch als separate SSD-Cache-Pools realisiert. In einem System können bis zu vier Pools vorhanden sein. Jeder Pool verwendet selbstverständlich seinen eigenen Satz von SSDs. In den Eigenschaften der virtuellen Festplatte legen wir fest, ob dieser Pool verwendet wird und welcher genau. Die Aktivierung und Deaktivierung der Cache-Nutzung für Volumes kann online durchgeführt werden, ohne den I/O-Betrieb anzuhalten. Außerdem können SSDs „hot-swappable“ dem Pool hinzugefügt oder entfernt werden. Bei der Erstellung eines SSD-Cache-Pools muss gewählt werden, in welchem Modus er arbeiten wird: nur Lesen oder Lesen+Schreiben. Dies beeinflusst seine physische Organisation. Da es mehrere Cache-Pools geben kann, können sie unterschiedliche Funktionalitäten haben (d.h. im System können gleichzeitig Cache-Pools für Lesen und für Lesen+Schreiben existieren).
Wenn der Cache-Pool nur für Lesezwecke verwendet wird, kann er aus 1 bis 8 SSDs bestehen. Die Laufwerke müssen nicht die gleiche Kapazität oder vom gleichen Anbieter sein, da sie in der NRAID+-Struktur kombiniert werden. Alle SSDs im Pool arbeiten gemeinsam. Das System versucht eigenständig, eingehende Anfragen gleichmäßig auf alle SSDs zu verteilen, um die maximale Leistung zu erreichen. Falls eine der SSDs ausfällt, ist das nicht tragisch: Der Cache enthält nur eine Kopie der Daten, die auf dem RAID-System der Festplatten gespeichert sind. Es wird einfach der verfügbare SSD-Cache verringert (oder auf null gesetzt, wenn der ursprüngliche SSD-Cache aus einem einzelnen Laufwerk besteht).
Wenn der Cache für Lese- und Schreiboperationen genutzt wird, sollte die Anzahl der SSDs im Pool ein Vielfaches von zwei betragen, da der Inhalt auf Paaren von Speichermedien gespiegelt wird (es wird eine NRAID 1+-Struktur verwendet). Die Duplizierung des Caches ist notwendig, weil er Daten enthalten kann, die noch nicht auf die Festplatten geschrieben wurden. In einem solchen Fall würde der Ausfall einer SSD im Cache-Pool zum Verlust von Informationen führen. Bei NRAID 1+ hingegen würde der Ausfall einer SSD lediglich dazu führen, dass der Cache in den Zustand „nur Lesen“ übergeht, wobei nicht geschriebene Daten auf das Festplattensystem zurückgesetzt werden. Nach dem Austausch der defekten SSD kehrt der Cache in seinen ursprünglichen Betriebsmodus zurück. Übrigens kann zur Verbesserung der Sicherheit für Caches, die im Lese- und Schreibmodus arbeiten, ein dedizierter Hot-Spare zugeordnet werden.
Bei der Verwendung der SSD-Caching-Funktion in XCubeSAN gibt es eine Reihe von Anforderungen an den Speicher der Speichercontroller: Je mehr Systemspeicher vorhanden ist, desto größer ist der verfügbare Cache-Pool.
Im Gegensatz zu den meisten Herstellern von Speicherlösungen, die lediglich eine Ein-/Aus-Option für SSD-Caching anbieten, bietet QSAN deutlich mehr Möglichkeiten. Insbesondere kann der Cache-Modus je nach Art der Last gewählt werden. Es gibt drei voreingestellte Profile, die am ehesten mit den entsprechenden Diensten übereinstimmen: Datenbank, Dateisystem, Web-Service. Darüber hinaus kann der Administrator ein eigenes Profil erstellen und die erforderlichen Parameterwerte festlegen:
- Blockgröße (Cache Block Size) – 1/2/4 MB
- Anzahl der Leseanfragen, damit der Block in den Cache kopiert wird (Populate-on-Read Threshold) – 1..4
- Anzahl der Schreibanfragen, damit der Block in den Cache kopiert wird (Populate-on-Write Threshold) – 0..4
Profile können „on the fly“ geändert werden, jedoch selbstverständlich mit einer Rücksetzung des Cache-Inhalts und einem neuen ‚Aufwärmprozess‘.
Betrachtet man das Funktionsprinzip des SSD-Caches, lassen sich die Hauptoperationen im Umgang damit herausstellen:
Daten werden gelesen, wenn sie nicht im Cache sind
- Die Anfrage vom Host gelangt an den Controller;
- Da die angeforderten Daten nicht im SSD-Cache sind, werden sie von den Festplatten gelesen;
- Die gelesenen Daten werden an den Host gesendet. Gleichzeitig wird überprüft, ob diese Blöcke "heiß" sind;
- Wenn ja, werden sie für die spätere Verwendung in den SSD-Cache kopiert.
Daten werden gelesen, wenn sie im Cache vorhanden sind
- Die Anfrage vom Host gelangt an den Controller;
- Da die angeforderten Daten im SSD-Cache vorhanden sind, werden sie von dort gelesen;
- Die gelesenen Daten werden an den Host gesendet.
Daten werden beim Einsatz eines Lesecaches geschrieben
- Die Schreibanforderung vom Host gelangt an den Controller;
- Die Daten werden auf die Festplatten geschrieben;
- Der Host erhält eine Bestätigung über die erfolgreiche Schreiboperation;
- Gleichzeitig wird überprüft, ob der Block "heiß" ist (Vergleich mit dem Parameter Populate-on-Write Threshold). Wenn ja, wird er für die spätere Verwendung in den SSD-Cache kopiert.
Daten werden beim Einsatz eines Lese- und Schreibcaches geschrieben
- Die Schreibanforderung vom Host gelangt an den Controller;
- Daten werden im SSD-Cache geschrieben;
- Der Host erhält eine Bestätigung über die erfolgreiche Schreiboperation;
- Daten aus dem SSD-Cache werden im Hintergrund auf die Festplatten geschrieben;
Überprüfung im Einsatz
Teststand
2 Server (CPU: 2 x Xeon E5-2620v3 2,4GHz / RAM: 32GB) sind über zwei Ports direkt mit dem XCubeSAN XS5224D (16GB RAM / Controller) verbunden, über Fibre Channel 16G.
Es wurden 16 x Seagate Constellation ES, ST500NM0001, 500GB, SAS 6Gb/s, im RAID5 (15+1) für das Datenspeichervolumen und 8 x HGST Ultrastar SSD800MH.B, HUSMH8010BSS200, 100GB, SAS 12Gb/s als Cache verwendet.
Es wurden 2 Volumes erstellt: jeweils eines für jeden Server.
Test 1. SSD-Cache nur im Lese-Modus mit 1-8 SSDs
SSD-Cache
- I/O-Typ: Anpassung
- Cache-Blockgröße: 4MB
- Populate-on-read-Schwelle: 1
- Populate-on-write-Schwelle: 0
I/O-Muster
- Werkzeug: IOmeter V1.1.0
- Worker: 1
- Outstanding (Warteschafftiefe): 128
- Zugriffs-Spezifikationen: 4KB, 100% Lesen, 100% Zufällig
In der Theorie gilt: Je mehr SSDs im Cache-Pool, desto höher die Leistung. Dies wurde durch praktische Tests bestätigt. Das signifikante Wachstum der Anzahl an SSDs bei einer geringen Anzahl an Volumes führt jedoch nicht zu einer explosiven Wirkung.
Test 2. SSD-Cache im Lese- + Schreibmodus mit 2-8 SSDs
SSD-Cache
- I/O-Typ: Anpassung
- Cache-Blockgröße: 4MB
- Populate-on-read-Schwelle: 1
- Populate-on-write-Schwelle: 1
I/O-Muster
- Werkzeug: IOmeter V1.1.0
- Worker: 1
- Outstanding (Warteschafftiefe): 128
- Zugriffs-Spezifikationen: 4KB, 100% Schreiben, 100% Zufällig
Dasselbe Ergebnis: explosiver Anstieg der Leistung und Skalierung bei Erhöhung der Anzahl an SSDs.
In beiden Tests war das Volumen der Arbeitsdaten kleiner als das gesamte Cache-Volumen. Daher wurden im Laufe der Zeit alle Blöcke in den Cache übertragen. Die Arbeit erfolgte somit im Wesentlichen mit SSDs, ohne die Festplatten nennenswert zu beanspruchen. Ziel dieser Tests war es, die Effizienz des Cache-Warmups und die Skalierung seiner Leistung in Abhängigkeit von der Anzahl der SSDs anschaulich zu demonstrieren.
Kehren wir nun von den Höhen zurück zur Realität und prüfen eine realistischere Situation, in der das Datenvolumen größer ist als die Größe des Caches. Um den Test in einer akzeptablen Zeit durchzuführen (die „Aufwärmzeit“ des Caches steigt erheblich mit der Volumengröße), beschränken wir uns auf eine Volumengröße von 120 GB.
Test 3. Emulation der Datenbankarbeit
SSD-Cache
- I/O-Typ: Datenbank
- Cache-Blockgröße: 1 MB
- Populate-on-Read-Schwelle: 2
- Populate-on-write-Schwelle: 1
I/O-Muster
- Werkzeug: IOmeter V1.1.0
- Worker: 1
- Outstanding (Warteschafftiefe): 128
- Zugriffs-Spezifikationen: 8 KB, 67 % Lesen, 100 % Zufällig
Urteil
Als offensichtliche Schlussfolgerung bietet die Nutzung von SSD-Caches eine gute Effizienz zur Leistungssteigerung jeder Speichersystem-Architektur. Im Hinblick auf Diese Aussage trifft vollkommen zu: Die SSD-Caching-Funktion ist hervorragend umgesetzt. Dies gilt sowohl für die Unterstützung der Lese- als auch der Lese-+ Schreibmodi, die flexible Anpassung an verschiedene Nutzungszenarien als auch die Gesamtleistung des Systems. Daher kann man zu einem sehr vernünftigen Preis (die Lizenzkosten sind mit den Kosten von 1-2 SSDs vergleichbar) die Gesamtleistung erheblich steigern.
Quelle: habr.com
