NAS im Eigenbau: SSD-Caching – Teil 1
Ort des Caches
Im SAN/NAS-Umfeld kann, sowohl der Storage Client als auch der Storage Server, Cachetechnologien nutzen, je nachdem, welche Anwendungen zum Einsatz kommen.
• Client Cache: Ein System, das auf der Initiator-Seite eine Block-LUN (iSCSI, FC) cached, erreicht höhere Performance-Zuwächse, da der Cache sowohl die LUN als auch die Speichernetzwerk-Latenzen ausblendet. Selbiges gilt für Netzwerk-Dateisysteme (z.B. NFS), bei welchen der Client einen SSD-Cache nutzt. Allerdings kann diese Form des Cachings nur bei exklusiven LUN-Verbindungen eines Clients vorkommen, nicht jedoch bei gemeinsam genutzten (shared) LUNs. Da ein Netzwerk-Dateisystem per Definition geshared arbeitet, beschränkt sich der NFS-Client-Cache in der Regel auf Lesezugriffe.
• Auf der anderen Seite kann der Storage-Server selbst seine Disks mit SSD-Cache aufwerten. Das sorgt für Konsistenz auf den Disks, weil die Zugriffe mehrerer Speicher-Clients den selben Cache passieren. Im Gegenzug bleibt aus Sicht des Clients jedoch die Latenz des Speichernetzwerks selbst bestehen.
Block-Caching
Seit der Kernel Version 3.9 (Red Hat Enterprise Linux 7, CentOS 7, Suse Enterprise Linux 12) enthält der Upstream Linux Kernel gleich zwei Block-Caching Module: Bcache und DM-Cache. In diesem Workshop setzt speicherguide.de das populärere und stabilere Modul DM-Cache ein und lässt Bchace außen vor. Zudem unterstützt der Logical Volume Manager (LVM) dieses Caching-Modul und vereinfacht damit die Verwaltung hybrider Volumen.
DM-Cache setzt über den Device-Mapper ein virtuelles Block-Volume aus insgesamt drei logischen Volumes zusammen. Neben dem Daten- und dem Cachespeicher verlangt DM-Cache auch nach einem gesondertem Blockspeicher für die Metadaten. Dieser sichert die Informationen darüber, welche Dateisystem-Blöcke im Cache und welche auf dem Originaldatenträger liegen. Bei aktiviertem Schreib-Cache landen neue Blöcke im Cache und die zugehörigen Metatdaten werden als »Cached only« markiert. Ein im Hintergrund arbeitender Migrationsprozess kopiert die Änderungen asynchron auf dem dahinter gelagerten Datenträger. DM-Cache kennt drei Betriebsmodi: Read/Write-Cache, Read-Cache und Passthrough, also Cache deakiviert.
Die Größe des Metadaten Volumen beträgt 16 Bytes pro cached Block auf dem Datenträger. Die Blockgröße beträgt dabei in der Regel 512 Byte (ein Sektor), kann aber auch größer ausfallen, sofern die Platte und das Dateisystem dies unterstützen. DM-Cache lässt sich auch nachträglich zu Datenträgern hinzufügen, die bereits über ein Dateisystem und Daten verfügen. Selbstverständlich bedarf es vorher eines vollständigen Backups des Datenträgers. Wer sich bei den Parametern des Caches vertippt, kann durchaus die bestehende Formatierung zerstören.
DM-Cache einrichten
Für einen ersten Test mit DM-Cache setzt speicherguide.de zunächst eine virtuelle Maschine (KVM) mit CentOS7 als Betriebssystem ein. Der Maschine stehen zwei virtuelle QCOW2-Disks zur Verfügung. Eine davon lagert auf einer SSD, die andere auf einer herkömmlichen Disk. Im weiteren Verlauf der Tests wird speicherguide.de den Testaufbau in einen physischen Server mit Samsung EVO SSD-Laufwerken umziehen und dann auch Benchmark-Daten nachliefern, was in einer virtualisierten Umgebung nur wenig Sinn macht.
Prinzipiell ist das LVM-Setup für DM-Cache recht einfach, wenn man weiß, an welche Regeln man sich zu halten hat. Zunächst gilt: Alle Volumes des Cache-Aufbaus müssen in einer einzigen Volume Group liegen. Prinzipiell würde es mehr Sinn machen, SSDs und normale Disks in verschiedenen VGs zu separieren, das wird so aber nicht unterstützt.
Im Test-Setup von speicherguide.de besteht bereits eine VG namens »centos« auf der klassischen Festplatte. Sie beherbergt die üblich verdächtigen Volumes für das Root- und das Swap-Laufwerk.
Nun weisen wir allen verbleibenden Speicher der VG dem zu cachenden Volume zu:
#lvcreate -n cached_lv -l100%VG centos
Im ersten Testaufbau hat diese LUN rund 10 GByte.
Die SSD findet sich innerhalb der VM als /dev/vdb und wird nun der VG hinzugefügt.
#vgextend centos /dev/vdb
Um das Metadaten-Volume zu berechnen brauchen wir zunächst die Zahl der Blöcke.
#blockdev --getsz /dev/centos/cached_lv
22470656
Die Zahl der Blöcke geteilt durch 64k (65536) ergibt die Größe der Metadatenpartition in MB. In diesem Fall also rund 343 MB
#lvcreate -n cached_meta -L 343m centos
Der Rest der VG kann nun als Daten-Cache verwendet werden, jedoch mit einer Ausnahme: Auf der VG muss so viel Platz frei bleiben, wie die Metadatenpartition belegt. Der Grund hierfür ist simpel: Der LVM erzeugt später beim Anlegen des Cache-Pools ein verstecktes logical Volume mit der Größe des Metadaten-LV. Die ist für den Notfall gedacht. Sollte es zu einem Crash kommen, wird der fsck-Service diese versteckte Partition nutzen, um den Metadatenblock neu aufzubauen. Um sich das Rechnen zu ersparen, erzeugen wir eine LV in der passenden Größe als Blocker, weist den Rest der VG dann der Cache-Datenpartition zu und entfernt die Blocker_LV wieder.
#lvcreate -n cache_meta2 -L344m centos
Logical volume "cache_meta2" created
#lvcreate -n cache_data -l100%FREE centos
Logical volume "cache_data" created
#lvremove centos/cache_meta2
Do you really want to remove active logical volume cache_meta2?
[y/n]: y
Logical volume "cache_meta2" successfully removed
Im nächsten Schritt konvertiert speicherguide.de die zwei Cache-LVs zu einem Cache Pool. Dabei erzeugt der LVM automatisch das versteckte Laufwerk für Notfälle.
#lvconvert --type cache-pool --poolmetadata centos/cache_meta --cachemode writethrough
centos/cache_data
Logical volume "lvol0" created
Converted centos/cache_data to cache pool
Und zum Abschluss wird dieser Cache Pool dem regulären Laufwerk hinzugefügt:
#lvconvert --type cache --cachepool centos/cache_data centos/cached_lv
centos/cached_lv is now cached
Der LVM sieht nun so aus:
#lvs -a
LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync Convert
cache_data
centos Cwi-a-C--- 1,32g
[cache_data_cdata] centos Cwi-aoC--- 1,32g
[cache_data_cmeta] centos ewi-aoC--- 344,00m
cached_lv
centos Cwi-a-C--- 10,71g cache_data [cached_lv_corig]
[cached_lv_corig]
centos -wi-ao---- 10,71g
[lvol0_pmspare]
centos ewi------- 344,00m
root
centos -wi-ao---- 7,81g
swap
centos -wi-ao---- 1000,00m
Alle Zugriffe von und auf das Laufwerk cached_lv passieren nun den SSD-Cache und das Laufwerk wird besonders bei Random I/Os schnellere Zugriffsraten erzielen. Laut Dokumentation erkennt DM-Cache sequentielle Zugriffe, für die das Caching wenig Sinn macht und reicht diese direkt zur Platte durch.
Die LVM-Unterstützung für DM-Cache ist relativ frisch. Nicht alle Linux-Distributionen setzen die jeweils aktuellste Version der »lvm-tools« ein, wodurch besonders auf älteren PC die Cache-Features nicht oder nur eingeschränkt zur Verfügung stehen. Im Internet finden sich zudem eine Reihe von Tutorials, wie der Anwender DM-Cache über den Device-Mapper konfigurieren und nutzen kann.
Das funktioniert prinzipiell auch, jedoch sichert der Device-Mapper diese Caching Konfiguration nicht dauerhaft ab. Nach einem Neustart lassen sich die so erstellten Cache-Volumes erst mal nicht einbinden. Der Verwalter muss die DM-Cache-Kommandos wiederholen, oder ein passendes init-Skript schreiben, welches die Vorbereitung des Cache-Volumes beim Systemstart automatisiert. Die Konfiguration via LVM ist daher deutlich komfortabler. In neueren Versionen der LVM-Tools (z.B. in Opensuse und Fedora) sind bereits erweiterte Hilfsmittel implementiert. Dort lassen sich dann die Cache-Modi (writeback, writethrough) im laufenden Betrieb über lvchange ändern.
Im nächsten Teil von »NAS im Eigenbau« beschäftigt sich speicherguide.de mit dem Thema fs-cache. Dieses Client-basierte Caching-Modul reduziert die Netzwerklast auf NFS-Freigaben und beschleunigt die Lesezugriffe.