Über LVMCache

LVMCache (siehe auch manpage lvmcache(7)) ist das Caching-System von LVM, welches ermöglicht den Zugriff auf Logical Volumes (LVs) durch andere LVs zu cachen.

Der entschiedene Vorteil ist dabei, dass das Cache-LV auch nur mit einem Bruchteil der Kapazität des gecachten LVs groß sein muss. LVM führt dabei Statistik und entscheidet durch das Cachen welcher Blöcke die Performance am besten gesteigert werden kann.

Es gibt dabei grundsätzlich zwei Cache-Modi:

Zum einen bietet der Modus writethrough die Möglichkeit häufig gelesene Daten auf der schnelleren SSD zwischenzuspeichern, während Schreibvorgänge grundsätzlich „durch“ den Cache durch (gecachte Blöcke werden auch dort mit den neuen Daten überschrieben) auf das das unterliegende LV geschrieben. Hierdurch ist sichergestellt, dass die Daten auf der Ziel-LV immer konsistent und aktuell sind. Dieser Modus bringt keine Vorteile bei der Schreibgeschwindigkeit.
Zum anderen bietet der Modus writeback zusätzlich die Möglichkeit Daten zunächst im Cache zu speichern und „bei Zeiten“ auf das eigentliche LV zu flushen.

Für die PING-Server dürfte dabei vor allem der writeback interessant sein, der es ermöglicht Daten schnell schreiben und lesen zu können, sie aber mit einer zeitlichen Verzögerung dann doch auf einen anderen PING-Server zu synchronisieren. Hierbei entfällt dann z.B. die manuelle Aufgabe die Datenbank des Spam-Filters zu dumpen und bei einem Ausfall kann der Spamfilter dann mit einem noch relativ aktuellen Stand der Datenbank wieder in Betrieb genommen werden.

Voraussetzungen für LVMCache

Um ein LV cachen zu können müssen zwei LVs in der selben Volume Group (VG) angelegt werden, in der sich auch die zu cachende LV befindet. Auf den PING-Servern gibt es drei VGs:

pingXX: Lokale, nicht gespiegelte VG auf Magnetplatten
pingXX-data: Über DRBD gespiegelte VG mit Magnetplatten hinter dem DRBD
pingXX-ssd: Lokale, nicht gespiegelte VG auf SSDs

Den größten Nutzen für LVMCache entsteht dabei natürlich bei LVs in der pingXX-data VG, da dort ein Schreibzugriff sowohl auf das Schreiben auf die lokale Magnetplatte (langsam), als auch auf die entfernten Platten des DRBD-Mirrors (noch langsamer) wartet. Hier ist ein großer Zugewinn an Geschwindigkeit zu erwarten, wenn Daten als geschrieben gelten, sollten sie auf der lokalen SSD (pingXX-ssd) geschrieben sein. Im Hintergrund kann die XEN-Host-Domain (Dom0) die Daten später auf die Magnetplatten und den spiegelnden PING-Server im DRBD-Verbund fushen.

Die übliche Vorgehensweise wäre eine VG zu erstellen, die sowohl Magnetplatten als auch SSDs als Physical Volums (PVs) zusammenfasst. Dies hat nur den praktischen Nachteil, dass LVM den Speicher der SSDs und des DRBD-Verbunds, sofern nicht explizit angegeben, gemischt verwendet. Dabei könnte es also leicht passieren, dass nur ein Teil der Daten eines LVs auf dem DRBD-Verbund gespeichert werden, währen andere Teile auf den SSDs des ausgefallen Systems (z.B. die Metadaten des Dateisystems) liegen und es damit nicht möglich ist, die VMs auf einem anderen Server zu starten.

Eine sicherere aber auch aufwändigere Möglichkeit besteht darin, auf der SSD VG (pingXX-ssd) ein LV zu erstellen, dass die zwei von LVMCache benötigten LVs aufnehmen kann, und diese als PV der pingXX-data-VG hinzuzufügen und direkt alle Physical Extents (PEs) für die zwei zu erstellenden LVs zu benutzen.

Bei den zwei zu erstellenden LVs handelt es dabei in LVMSprech um die cache data LV, die als Speicherort für die eigentlichen Daten genutzt wird, und die cache metadata LV, welche die Metadaten des Caches speichert. Dabei ist die Metadata-LV ein 1000stel der Größe der Cache-Data-LV, aber mindestens 8 MiB groß.

Zusätzliche Pakete

Für das Aktivieren einer LV mit über LVMCache verbundenen Cache ist zwingend das Paket thin-provisioning-tools erforderlich. In diesem Paket befinden sich die benötigten Programme zum Prüfen der Metadaten, ohne dies ein Versuch eine gecachte LV zu verwenden fehlschlägt.

apt-get install thin-provisioning-tools

$/!\$ Kein LVMCache für das Root-Dateisystem

Da die Thin-Provisioning-Tools nur mit großem Aufwand in die Init-RD zu bekommen sind, sollten darauf geachtet werden, dass kein LVMCache für das Root-Dateisystem der Dom0 genutzt wird, da diese sonst nicht mehr bootet.

Einrichten eines LVMCaches

Dieses Beispiel richtet auf dem Server ping08.ping.de ein LVMCache für das LV ping08-data/stats.ping.de-disk ein. Da hier sehr häufig die RRDs von Munin aktualisiert werden und somit sehr viel IO-Last entsteht, aber im Falle des Ablebens von ping08 und dem fehlende Rückschreiben der RRDs auf das DRBD-Device maximal wenige Minuten an statistischen Daten verloren gehen, ist diese LV ein guter Kandidat für ein Cache.

Stand vor dem Einrichten des Caches:

root@ping08:~# lvs ping08-data/stats.ping.de-disk
  LV                 VG          Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  stats.ping.de-disk ping08-data -wi-ao---- 9,00g

Wie zusehen ist das zu cachende LV 9 GB groß. Dabei belegen sämtliche Munin-Daten ca. 1,1 GB. Ein Cache der Größe von 20%, also 2 GB erscheint hier also mehr als ausreichend.

Da neben dem eigentlichen Datencache auch noch ein Bereich für Metadaten (siehe oben) angelegt werden muss, ergibt sich hier ein benötigter Speicherplatz von ca. 2,2 GB.

Anlegen des Cache-Bereichs auf der SSD-VG

Der Speicherbereich von 2,2 GB wird auf der SSD-VG (hier ping08-ssd) als LV angelegt:

root@ping08:~# lvcreate -n stats.ping.de-disk-cache -L2.2G ping08-ssd
  Rounding up size to full physical extent 2,20 GiB
  Logical volume "stats.ping.de-disk-cache" created.

Diese neu erstellte LV muss, um als Speicher für den Cache der eigentliche LV (hier ping08-data/stats.ping.de-disk) der VG der LV (hier ping08-data) hinzugefügt werden. Da aufgrund der DRBD-Installation die Filter von LVM in der Konfigurationsdatei /etc/lvm/lvm.conf sehr restriktiv eingestellt sind, müssen diese ergänzt werden:

filter = [ "a|^/dev/md0$|", "a|^/dev/md3$|", "a|^/dev/drbd.*|", "a|/dev/ping08-ssd/stats.ping.de-disk-cache|", "r/.*/" ]
global_filter = [ "a|^/dev/md0$|", "a|^/dev/md3$|", "a|^/dev/drbd.*|", "a|/dev/ping08-ssd/stats.ping.de-disk-cache|", "r/.*/" ]

Mit den neuen Filtern kann dann mit pvcreate das neue LV zur Nutzung als PV vorbereitet werden:

root@ping08:/etc/lvm# pvcreate /dev/ping08-ssd/stats.ping.de-disk-cache
  Physical volume "/dev/ping08-ssd/stats.ping.de-disk-cache" successfully created.

Über den Befehl vgextend wird dann das neue PV der Ziel-VG (hier ping08-data) hinzugefügt:

root@ping08:/etc/lvm# vgextend ping08-data /dev/ping08-ssd/stats.ping.de-disk-cache
  Volume group "ping08-data" successfully extended

Anlegen der CachePoolLV

Bevor eine LV mit einem Cache versehen werden kann, ist das Anlegen einer sogeganten CachePoolLV notwendig. Hierbei handelt es sich um den Verbund einer CacheDataLV (für die eigentlichen Daten) und einer CacheMetaLV (für die Meta-Daten). Wichtig ist dabei, dass beim Anlegen der beiden Komponenten darauf geachtet wird, dass diese sich auf der im letzten Schritt hinzugefügten SSD-PV befindet. Um diese vollständig auszunutzen, empfiehlt es sich eine LV mit vorgegebener Größe anzulegen und die zweite LV den restlichen Speicherplatz ausnutzen zu lassen.

Daher wird hier zunächst die CacheMetaLV (hier stats.ping.de-disk-cache0meta) angelegt, wobei wichtig ist, dass als letzter Parameter die zu nutzende PV anzugeben ist:

root@ping08:/etc/lvm# lvcreate -n stats.ping.de-disk-cache0meta -L 200M ping08-data /dev/ping08-ssd/stats.ping.de-disk-cache
  Logical volume "stats.ping.de-disk-cache0meta" created.

Über pvdisplay können dann die noch freien PEs angezeigt werden:

root@ping08:/etc/lvm# pvdisplay /dev/ping08-ssd/stats.ping.de-disk-cache
  --- Physical volume ---
  PV Name               /dev/ping08-ssd/stats.ping.de-disk-cache
  VG Name               ping08-data
  PV Size               2,20 GiB / not usable 4,00 MiB
  Allocatable           yes 
  PE Size               4,00 MiB
  Total PE              563
  Free PE               513
  Allocated PE          50
  PV UUID               nWPKjg-1qFl-dWJi-8VVg-2D0m-Bq37-1fnhEc

Nun werden die restlichen 513 freien PE für die CacheDataLV verwendet:

root@ping08:/etc/lvm# lvcreate -n stats.ping.de-disk-cache0 -l 513 ping08-data /dev/ping08-ssd/stats.ping.de-disk-cache
  Logical volume "stats.ping.de-disk-cache0" created.

Eine Kontrolle mit pvdisplay zeugt vom Erfolg der Operation:

root@ping08:/etc/lvm# pvdisplay /dev/ping08-ssd/stats.ping.de-disk-cache
  --- Physical volume ---
  PV Name               /dev/ping08-ssd/stats.ping.de-disk-cache
  VG Name               ping08-data
  PV Size               2,20 GiB / not usable 4,00 MiB
  Allocatable           yes (but full)
  PE Size               4,00 MiB
  Total PE              563
  Free PE               0
  Allocated PE          563
  PV UUID               nWPKjg-1qFl-dWJi-8VVg-2D0m-Bq37-1fnhEc

Als letzter Schritt der Vorbereitung wird nun ping08-data/stats.ping.de-disk-cache0 und ping08-data/stats.ping.de-disk-cache0meta zur CachePoolLV zusammengefügt:

root@ping08:/etc/lvm# lvconvert --type cache-pool --poolmetadata ping08-data/stats.ping.de-disk-cache0meta ping08-data/stats.ping.de-disk-cache0
  WARNING: Converting logical volume ping08-data/stats.ping.de-disk-cache0 and ping08-data/stats.ping.de-disk-cache0meta to cache pool's data and metadata volumes with metadata wiping.
  THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert ping08-data/stats.ping.de-disk-cache0 and ping08-data/stats.ping.de-disk-cache0meta? [y/n]: y
  Converted ping08-data/stats.ping.de-disk-cache0 to cache pool.

CachePoolLV und ursprüngliche LV zusammenführen

Die zuvor erstellte CachePoolLV muss nun noch mit der ursprünglichen LV zusammengeführt werden. Hierbei wird auch der Modus ausgewählt. Wie am Anfang dieser Seite beschrieben gibt es dabei writethrough und writeback zur Auswahl. Für dieses Beispiel wird writeback gewählt. Folgender Befehl führt die Aufgabe durch:

root@ping08:/etc/lvm# lvconvert --type cache --cachepool ping08-data/stats.ping.de-disk-cache0 --cachemode writeback ping08-data/stats.ping.de-disk
Do you want wipe existing metadata of cache pool volume ping08-data/stats.ping.de-disk-cache0? [y/n]: y
  Logical volume ping08-data/stats.ping.de-disk is now cached.

Finales

Über den Befehl lvs kann die Auslastung des Cachs kontrolliert werden:

root@ping08:/etc/lvm# lvs ping08-data/stats.ping.de-disk
  LV                 VG          Attr       LSize Pool                        Origin                     Data%  Meta%  Move Log Cpy%Sync Convert
  stats.ping.de-disk ping08-data Cwi-aoC--- 9,00g [stats.ping.de-disk-cache0] [stats.ping.de-disk_corig] 2,62   0,14            25,49

Systeme/Knipp-Server-Neu/lvmcache (zuletzt geändert am 2019-03-03 21:45:58 durch DanielHess)