Ü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ß.