= Ü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           
}}}