© Nelson Hale, 123RF

Flashspeicher ist schnell, dummerweise aber auch teuer, jedenfalls noch. Ein Ausweg ist das Caching mit Flash: So kann eine kleinere und billigere SSD mehrere große Platten zum Fliegen bringen. Das Linux-Magazin hat zwei Lösungen dafür getestet.

Festplatten sind relativ billig und kapazitätsreich, aber langsam – SSDs sind schnell, aber kleiner und teurer. Wer beider Vorteile durch einen SSD-Cache für Festplatten kombiniert, entfaltet eine Art Hebelwirkung: Mit überschaubarem finanziellen Aufwand lässt sich ein großer Performancegewinn erzielen.

Dem kommt entgegen, dass eine Applikation meist nicht alle Daten auf einmal begehrt, der größere Teil ist ihr oft lange Zeit mehr oder weniger egal. Caches nutzen genau das aus: Sie verlagern die gefragtesten Daten auf ein exklusives, schnelles Medium und lassen das Gros der Daten, das nur selten verlangt wird, auf dem billigeren, aber langsamen Hintergrundmedium.

Ein wenig Cache-Theorie

Soll ein Cache wichtige Daten bevorzugt bereitstellen, muss er entscheiden können, was wichtig ist. Dazu dient die so genannte Entscheidungsstrategie des Cache, für die es diverse Modelle gibt. Alle regeln, welche Daten der Cache zugunsten neuer Einträge wieder vergessen soll. Den Rest behält er und liefert ihn automatisch und völlig transparent aus, sobald das Hintergrundmedium danach gefragt wird. Die wichtigsten Entscheidungsstrategien sind:

Fifo (First in, first out): Der Eintrag, der als Erster in den Cache geschrieben wurde, fällt auch zuerst wieder heraus. Nachteilig ist diese Herangehensweise dann, wenn der Cache klein ist. Dann müssen permanent Daten gelöscht werden, um neuen Platz zu machen.

LFU (Least Frequently Used): Was am seltensten nachgefragt ist, wird wieder vergessen. Diese Strategie ist dann effizienter als Fifo, wenn Applikationen bestimmte Einträge tatsächlich deutlich öfter benötigen als andere.

LRU (Least Recently Used): Diese Strategie versucht jene Einträge im Cache zu behalten, die erst vor Kurzem gebraucht wurden, und die ältesten zu entfernen. Bei diesem Verfahren geht es also nicht wie bei LFU um die Zugriffsfrequenz, sondern um den Zugriffszeitpunkt. Diese Technik benutzt in der Regel einige Bits, um sich zu merken, wie alt der jeweilige Eintrag ist. Jeder Treffer im Cache aktualisiert das Alter aller anderen Einträge. Von LRU gibt es etliche Abwandlungen wie Pseudo-LRU (PLRU, braucht nur ein Alters-Bit) oder Segmented LRU (SLRU, arbeitet zusätzlich mit einem geschützten Segment, aus dem der Cache keine Einträge entfernen darf).

MRU (Most Recently Used): Auch das Gegenteil von LRU kann sinnvoll sein, nämlich dann, wenn die Wahrscheinlichkeit, dass auf ein Datum zugegriffen wird, mit seinem Alter steigt. Das passiert zum Beispiel beim sequenziellen Durchmustern eines Datenbestands. Auf ein eben gelesenes Datum kommt der Prozess dabei in nächster Zeit garantiert nicht so schnell zurück. In diesem Fall ist es sinnvoll, die jüngsten Einträge im Cache als erste wieder zu vergessen.

MQ (Multiqueue): Diese Technik verwaltet verschiedene Warteschlangen mit der LRU-Strategie, wobei jede Warteschlange einer bestimmten Zugriffsfrequenz zugeordnet ist. Zusätzlich gibt es einen History-Buffer, der sich die Zugriffshäufigkeiten der zuletzt entfernten Einträge eine gewisse Zeit lang merkt. Eine Abart von MQ ist Stochastic Multiqueue (SMQ).

RR: Random Replacement, das einen zufälligen Eintrag verdrängt.

Applikationsspezifisch: Caching ist nicht nur auf der Ebene von Blockdevices möglich, sondern auch auf dem Applikationslevel. Der Cache erfährt hier zum Beispiel vom Betriebssystem, von einem Hypervisor oder von einer Datenbank, was bereitzuhalten sich lohnt, und kann sich so auf Muster des Anwenderverhaltens einstellen.

Schreibmodi

Neben der Entscheidungsstrategie wählt jeder Cache außerdem noch eine Schreibstrategie. Hier unterscheidet man:

Writethrough: Den zu schreibenden Block legt das System sofort sowohl im Cache wie auch auf dem Hintergrundmedium ab. So bleibt in jedem Fall die Konsistenz gewahrt. Allerdings muss der Prozess beim Schreiben unter Umständen auf das langsamere Medium warten.

Writeback: Der zu schreibende Block gelangt zunächst nicht auf das Hintergrundmedium, sondern nur in den Cache. Auf die langsame Festplatte wandert der Block erst, wenn der Eintrag aus dem Cache verdrängt wird. Diese Strategie vermeidet Wartezeiten, allerdings um den Preis einer temporären Inkonsistenz. Das Medium hinter dem Cache enthält zeitweilig veraltete Daten. Der Cache sollte für diese Strategie unbedingt batteriegepuffert sein, andernfalls führt ein Stromausfall fast zwangsläufig zu Datenverlust und Inkonsistenz.

Abbildung 1: Schematischer Aufbau eines Floating-Gate-Transistors.

Ein weiteres Unterscheidungsmerkmal für Caches besteht darin, wie der Cache seine Einträge adressiert. Man unterscheidet Direct-mapped Caches, bei denen sich die Adresse im Cache direkt aus der Adresse auf dem Hauptspeichermedium ableitet, etwa indem dessen niederwertigste Bits verwendet werden, sowie assoziative Caches, bei denen ein Algorithmus den Speicherort im Cache bestimmt, zum Beispiel über eine Hashfunktion. Das direkte Mapping ist schneller, allerdings können sich zwei Blöcke selbst dann gegenseitig verdrängen, wenn der restliche Cache komplett leer ist. Das assoziative Verfahren ist flexibler, der Rechenaufwand dafür aber höher.

Caching-Lösungen unter Linux

Für Festplattencaches gibt es unter Linux verschiedene Lösungen. Dieser Artikel betrachtet nur Caches für Blockdevices, für die also das verwendete Filesystem gleichgültig ist und die auch nichts über die Eigenheiten von Applikationen wissen. Unberücksichtigt bleibt, dass dieselben Blöcke unter Umständen auch an anderen Stellen des I/O-Stack gecacht werden, etwa von der Festplatte selber oder im RAM bei Verwendung des so genannten Buffer Cache.

Die erste der möglichen Softwarelösungen unter Linux ist Flashcache [1]. Sie baut auf dem Linux Device Mapper auf, einem Teil des I/O-Stack, den beispielsweise auch das Software-Raid-Feature oder LVM nutzen. Flashcache realisiert einen assoziativen Cache mit Writeback-Policy, als Ersetzungsstrategie kommt entweder Fifo (Default) oder LRU zum Einsatz.

Direkter mit dem Device Mapper verbunden ist Dmcache [2], es ist eine Komponente dieses Kernel-Framework. Dmcache ist eines der in diesem Beitrag getesteten Verfahren. Es bildet aus drei Devices – dem eigentlichen Cache, einem kleinen Device für Metadaten (beide auf SSD) und der Festplatte – ein LVM-Hybrid-Volume. Die Caching-Strategie ist hier Stochastic Multiqueue oder MQ, als Schreibstrategie lässt sich Writeback, Writethrough oder Passthrough wählen.

Außerdem gibt es Bcache [3], eine auf SSDs spezialisierte Software, die keine sequenziellen Zugriffe cacht, denn die könnten via SSD langsamer sein als mit einer schnellen Platte. Bcache verwendet Writeback, hat aber nach eigenen Angaben auch viel Mühe investiert, um das Verfahren selbst für den Fall abzusichern, dass jemand plötzlich den Netzstecker zieht. Es meldet eine Schreiboperation erst dann als vollendet an die höheren Schichten zurück, wenn alles sicher auf einem Speichermedium angekommen ist. Damit vermeidet es halbfertige Schreiboperationen.

Zur Verringerung der Latenz kann Bcache auch ein Journal benutzen, dann wird die Vollzugsmeldung der Schreiboperation bereits nach dem Eintrag ins Journal ausgelöst. Für das Mapping der Einträge im Cache verwendet Bcache einen B+-Baum (daher der Name).

Schließlich gibt es noch das von der Firma STEC Inc. entwickelte Enhance IO [4], das der Autor in diesem Beitrag ebenfalls getestet hat. Enhance IO setzt auf Flashcache auf, verwendet aber im Unterschied dazu und zum Testkandidaten Dmcache nicht den Device Mapper. So kann es völlig transparent etwa auch Caches für bereits gemountete Blockdevices einrichten. Flashcache erkennt keine sequenziellen Schreiboperationen und behandelt sie dementsprechend auch nicht besonders. Es lassen sich drei Schreibstrategien einrichten: Read-only, Writethrough und Writeback.

Im Read-only-Modus werden alle Write-Operationen direkt zur Festplatte geleitet. Leseoperationen übertragen die Daten zuerst von der Platte zur SSD, bei einem erneuten Zugriff auf den gleichen Block wird dieser dann von der SSD gelesen.

Im Writethrough-Modus werden Read-Operationen ähnlich behandelt wie bei Read-only, geschrieben wird aber parallel auf HDD und SSD. Nachfolgende Reads greifen nur noch auf die SSD zu. Der Writeback-Modus führt wie üblich alle Read- und Write-Operationen zuerst auf der SSD aus. Auf die Platte gelangen sie asynchron.

Die Installation

Die Installation der beiden hier getesteten Caches – Dmcache und Enhance IO – ist kein Hexenwerk. Für Enhance IO folgt der Admin dem Beispiel in Listing 1. Zunächst klont er das Git-Repository und kopiert daraus die Kommandodatei für das CLI nach »/sbin« und die Manpage an den richtigen Ort (Zeilen 1 bis 5). Danach kopiert er das Verzeichnis mit den Treiberquellen und benennt es um. (Zeilen 7 bis 10). Nun ist das Framework Dynamic Kernel Module Support (DKMS) zu installieren. Vorher muss in einer Konfigurationsdatei für DKMS die folgende Zeile ergänzt werden (Zeile 14):

PACKAGE_VERSION="0.1"

Nun kann der Installateur mit Hilfe von DKMS das Treibermodul kompilieren und installieren (Zeilen 16). Der letzte Schritt richtet dann den Cache ein (Zeile 20). Im Beispiel ist »/dev/mapper/testvol-data1« das zu beschleunigende LVM-Volume und »/dev/nvme0n1p2« die SSD. Intel hatte für die Tests freundlicherweise eine schnelle PCI-Express-SSD mit NVMe der 750 Series bereitgestellt (mit einer Kapazität von 1,2 TByte).

01 jcb@localhost:~ git clone https://github.com/STEC-inc/EnhanceIO
02 jcb@localhost:~ cd EnhanceIO/
03 jcb@localhost:~/EnhanceIO$ sudo cp CLI/eio_cli /sbin/
04 jcb@localhost:~/EnhanceIO$ chmod 700 CLI/eio_cli
05 jcb@localhost:~/EnhanceIO$ sudo cp ./CLI/eio_cli.8 /usr/share/man/man8/
06
07 jcb@localhost:~/EnhanceIO$ cd Driver
08 jcb@localhost:~/EnhanceIO/Driver$ sudo cp -r enhanceio /usr/src
09 jcb@localhost:~/EnhanceIO/Driver$ sudo mv /usr/src/enhanceio/usr/src/enhanceio-0.1
10 jcb@localhost:~/EnhanceIO/Driver$ cd /usr/src/enhanceio-0.1
11
12 jcb@localhost:/usr/src/enhanceio-0.1$ sudo vi dkms.conf
13
14 jcb@localhost:/usr/src/enhanceio-0.1$ dnf install dkms
15
16 jcb@localhost:/usr/src/enhanceio-0.1$ sudo dkms add -m enhanceio -v 0.1
17 jcb@localhost:/usr/src/enhanceio-0.1$ sudo dkms build -m enhanceio -v 0.1
18 jcb@localhost:/usr/src/enhanceio-0.1$ sudo dkms install -m enhanceio -v 0.1
19
20 [root@graphite enhanceio-0.1]# sudo eio_cli create -d /dev/mapper/testvol-data1 -s /dev/nvme0n1p2 -m wb -c enhanceio_cache

Die Installation von Dmcache ist nicht schwieriger. Da das verwendete Device-Mapper-Framework zum Kernel gehört, braucht es nicht einmal extra Software. Zur Vorbereitung partitioniert der Admin die SSD so, dass ein größerer Cache und eine kleinere Partition für das Metadatendevice entstehen. Die Größe der Metadatenpartition berechnet die Formel:

Metadaten = 4194304 + (16 * Cachegröße /  Blockgröße)

Im vorliegenden Fall ergeben sich rund 70 MByte. Danach lässt sich das spezielle LVM-Kombi-Device mit Hilfe des Kommandos »dmsetup« einrichten:

dmsetup create dmcache --table '0 1366552543 cache /dev/nvme0n1p2 /dev/nvme0n1p1 /dev/sdb2 512 1 writeback default 0'

Diese relativ kryptischen Kommandozeile führt zuerst den ersten und letzten Sektor des Cache auf, danach die Devicenamen für das Metadatendevice, das Cachedevice und das Datendevice, dann die Blockgröße in Sektoren, dann die Anzahl der Feature-Argumente und das Feature-Argument Schreibstrategie (hier: Writeback), danach die Caching Policy und dann die Anzahl der Policy-Argumente (hier: null).

Sollte dieses Kommando mit der nicht leicht verständlichen Fehlermeldung »Ungültiges oder unvollständiges Multi-Byte- oder Wide-Zeichen« fehlschlagen, dann liegt das wahrscheinlich daran, dass die Cache- oder die Metadatenpartition noch alte Daten enthält. Das mag »dmsetup« nicht. Abhilfe schafft im Beispiel:

dd if=/dev/zero of=/dev/nvme0n1p2
dd if=/dev/zero of=/dev/nvme0n1p1

Danach sollte es funktionieren. Ob das so ist, darüber kann sich der Admin vergewissern, wenn er bei beiden Lösungen jeweils nach einer Anzahl von Schreib- und Leseversuchen die Cache-Statistiken aufruft. Bei Dmcache ist das wieder eine Zumutung: Die Zahlen werden unformatiert ausgegeben und die Bedeutung der einzelnen Werte ist nur im Sourcecode dokumentiert. Es ergibt sich eine Ausgabe wie in Listing 2.

01 root@graphite jcb]# dmsetup status
02
03 dmcache: 0 1366552543 cache 8 12468/17920 512 4653/4194304 1488021 200791
04 2189199 41931 0 4650 0 1 writeback 2
   migration_threshold 2048 mq 10
05 random_threshold 4 sequential_threshold 512
   discard_promote_adjustment 1
06 read_promote_adjustment 4 write_promote_adjustment 8
07 fedora-home: 0 199393280 linear

Im Beispiel dieses Listings steht das erste mit einem Slash getrennte Zahlenpaar für »Used Metadata Blocks/Total Metadata Blocks« , darauf folgt die Blockgröße im Cache, darauf »Used Cache Blocks/Total Cache Blocks« . Es schließen sich an das zweite durch einen Slash getrennte Zahlenpaar die Werte für Read Hits, Read Misses, Write Hits und Write Misses an. Einfacher ist es bei Enhance IO. Hier finden sich die Statistiken in einem File im Proc-Dateisystem, tabellarisch formatiert (Listing 3).

01 [root@graphite jcb]# cat /proc/enhanceio/enhanceio_cache/stats
03 reads                              1962
04 writes                          6268272
05 read_hits                           346
06 read_hit_pct                         17
07 write_hits                      1870824
08 write_hit_pct                        29
09 dirty_write_hits                 167399
10 dirty_write_hit_pct                   2
11 cached_blocks                     17664
12 rd_replace                           65
13 wr_replace                       394196
14 [...]

Benchmarks

Was ist nun der Lohn der Mühe? Das hat das Linux-Magazin mit verschiedenen Benchmarks überprüft. Zuerst verlegten die Tester die Festplattendatei einer virtuellen Maschine nacheinander auf eine gewöhnliche Festplatte, auf ein Raid-Device, auf Devices mit Dmcache oder Enhance IO und auf die pure SSD. Danach booteten sie die VM und maßen jeweils die benötigte Zeit.

Die Resultate zeigt Abbildung 2. Die Daten stammen aus dem Protokoll des verwendeten Bootchart-Tools [5] und beziehen sich auf die Anzahl der Sekunden vom Beginn des Bootens bis zum Start von Xorg. Das schlechte Abschneiden von Dmcache erklärt sich dadurch, dass der Cache hier sehr lange zum Aufwärmen braucht. Ein paar Bootversuche reichen dafür nicht. Beim FIO-Benchmark mussten die Tester die Messung mehr als 70-mal wiederholen, bevor Dmcache stabile Resultate produzierte.

Abbildung 2: Booten einer VM als Benchmark. Gemessen wurde die Zeit bis zum Start von Xorg. Dmcache ist noch nicht aufgewärmt.

Abbildung 3: Die SSD – ob alleine oder als Cache – ist der reinen Festplatte beim wahlfreien Lesen turmhoch überlegen.

In einem zweiten Benchmark benutzten sie den Flexible I/O-Tester (FIO, [6]) und ließen ihn einen Nur-Lese-Workload mit wahlfreiem Zugriff abarbeiten. Er legte zunächst 15 Files mit einer Größe zwischen 10 und 100 GByte an (Gesamtgröße 96 GByte, das war das Achtfache des verfügbaren RAM) und las dann mit maximal 16 Threads für mehrere Minuten beliebige 4-KByte-Blöcke. Dieser Test zeigt die turmhohe Überlegenheit der SSD (und damit auch der gecachten Devices) gegenüber Festplatten in dieser Disziplin (Abbildung 3).

Dass hier ein Cache ein paar Prozent besser abschneidet als sogar die SSD, wäre nicht zu erwarten gewesen, resultiert aber sicher aus normalen Schwankungen der Resultate und aus der Tatsache, dass die Einflüsse auf den komplizierten I/O-Stack vielfältig sind. Unter anderem spielen hier andere Caches im noch schnelleren RAM auf der Ebene der Filesysteme mit. Das Ergebnis der einzelnen Platte fällt mit unter 1 MByte/s so schlecht aus, dass es mit der y-Achse verschmilzt. Ein Raid ist zwar deutlich schneller, aber immer noch um etliche Größenordnungen langsamer als die Devices, die sich in dieser Benchmarking-Spielart das zeitraubende ständige Neupositionieren eines Lesekopfes schenken können.

Für einen dritten Benchmark verwendeten die Tester Sysbench [7], der einen Read-Write-OLTP-Mix in einer MySQL-Datenbank abarbeitete. Das Datendirectory von MySQL lag nacheinander auf den bereits oben getesteten Devices. Jede Messung wurde mindestens dreimal wiederholt, dann ein Mittelwert gebildet. Im Zuge des Benchmark-Ablaufs wuchs die Anzahl parallel arbeitender Datenbankthreads.

Wie nicht anders zu erwarten, ist hier die reine SSD die teuerste, aber auch schnellste Lösung. Die beiden Caches kommen sich auf dem Gipfelpunkt ihrer Leistungskurve bei 64 Threads recht nahe. Das Raid schneidet noch passabel ab, ist aber schon deutlich langsamer. Die einzelne Festplatte wird schließlich gnadenlos deklassiert (Abbildung 4).

Abbildung 4: Sysbench mit verschiedenen Devices. Die pure SSD holt keiner ein und die einzelne Platte landet abgeschlagen auf dem letzten Platz.

Fazit

Eine All-Flash-Lösung wäre die schnellste, aber auch teuerste Lösung. Günstiger sind Caches, die mit Hilfe einer SSD ein größeres Festplattenvolumen merklich beschleunigen können. Das wird am besten dort gelingen, wo eine Anwendung stabile Zugriffsmuster produziert. Bei völlig regellosen, chaotischen Zugriffen, die sich nie wiederholen, wird der Cache wenig beitragen können. Oft benötigt er auch eine gewisse Zeit zum Einschwingen. Wer mit Writeback arbeitet, muss sich gegen das Risiko eines Datenverlustes wappnen, zum Beispiel mit batteriegepufferten Caches.