Linuxový správce logických svazků LVM (Logical Volume Management) zná každý linuxový admin. Tato abstrakce nad diskovými úložišti dokáže udělat softwarový RAID, snapshoty, změnu velikosti logických oddílů a další magii. V tomto krátkém zápisku zkusím shrnout moje poslední zkušenosti týkající se dvou pokročilých a velice zajímavých témat: klonování LV a caching LV na SSD disku.
Ti, kteří neví co PV, VG a LV doporučím nejprve například seriál na abclinuxu.cz. Stručně řečeno:
- VG (volume group) sdružuje fyzická zařízení (PV, physical volume) do skupiny.
- V rámci VG existuje logický oddíl (LV, logical volume).
- Dále vytvářet různé konfigurace, např. mirror, striping, vytvářet a rušit další LV, snapshoty, měnit velikost LV apod.
V tomto zápisku se vrátím ke dvěma velice zajímavým činnostem s LVM, ke kterým jsem se v poslední době dostal.
Činnost 1: klonování LV
Popis problému je jednoduchý. Měl jsem v notebooku 500G SSD disk a notebook jsem chtěl přeinstalovat. Nicméně jsem chtěl kompletní zálohu tohoto SSD uložit na 500G pevný disk. Nabízelo se několik variant:
První z nich, ta nejvíce low-level je provést čistou bitovou kopii SSD na HDD. Možnost jsem zamítnul, protože mi přijde příliš low-level.
Druhá varianta, ta nejvíce high-level je vytvoření filesystému (v libovolné konfiguraci) na HDD a překopírování souborů (zde jsou pomocníci jako tar nebe lépe cpio). Opět zamítnuto, příliš high-level.
Obě varianty navíc nedokáží vytvořit konzistentní kopii, pokud se se systémem intenzivně pracuje. Toto by se dalo řešit použitím snapshotů, nicméně tím už si zbytečně přiděláváme práci.
Řešení je velice jednoduché a nalezl jsem ho v diskuzi pod tímto zápiskem:
- Přidání HDD do stejné VG jako SSD.
- Mirror všech LV, které je nutné zkopírovat z SSD na HDD. Mirror se usadí na novém PV (pokud ve VG původně bylo pouze jediné)
- Rozdělení zrcadleného LV na dvě nezávislé LV.
- Rozdělení VG tak aby HDD byl samostatná VG.
Jednoduché a elegantní, nutné příkazy jsou:
vgextend vg /dev/sdX lvconvert -m 1vg/lv1 lvconvert -m 1vg/lv2 # volitelne ... lvconvert --splitmirrors 1 -n lv1_clone vg/lv1 lvconvert --splitmirrors 1 -n lv2_clone vg/lv2 ... vgsplit vg vg_clone /dev/sdX
Činnost 2: Caching HDD na SSD
Popis problému je opět jednoduchý — máme stroj, kde je pevný disk, popř. disky v nějakém pěkném RAIDu a k nim SSD (jedno nebo více) a chceme použít SSD k urychlení operací s točivým úložištěm (disk/disky).
Řešení je možné opět více, například bcache nebo dm-cache. Proč ale nepoužít LVM, které v posledních verzích podporuje použití jaderného modulu dm_cache pro caching? Opět inspirací mi byl blogový zápisek, kde najdete detailnější popis.
Veškeré kroky zahrnují následující operace:
- Přidání SSD do stejné VG jako jsou HDD.
- Vytvoření dvou LV pro cache — jedna pro metadata, druhá pro data (metadatová stačí 1000x menší než datová)
- Zkonvertování těchto dvou LV do cache poolu.
- Připojení cache poolu k LV.
Výhody řešení spočívají v možnosti cache za běhu vytvořit a připojit stejně jako odebrat. Nevýhoda pak je, že každé LV má svůj cache pool; pokud tedy máte oddělený /home a / pak každý musíte cachovat zvlášť.
Opět posloupnost příkazů bez nároku na úplnost/bezchybnost — v příkladu použijeme /dev/sdX pro cachování LV s názvem vg/home:
vgextend vg /dev/sdX # SSD cache # vytvoreni metadata cache LV na sdX lvcreate -L 1G -n meta vg /dev/sdX # vytvoreni data cache LV na sdX lvcreate -L 229G -n data vg /dev/sdX # konverze do cache poolu lvconvert --type cache-pool --poolmetadata vg/meta vg/data # pripojeni cache poolu k LV vg/home lvconvert --type cache --cachepool vg/data vg/home
Odstranění SSD cache
Zde je nápomocná již manuálová stránka lvmcache, kde je odstranění cache bez odstranění LV již přímo zmíněno — stačí odstranit LV vg/data:
lvremove vg/data
Statistiky SSD cache
A když už cache máme, ukáži, jak vytáhnout jednoduché statistiky cachingu. V Linuxu na to máme příkaz dmsetup status, který když aplikujeme na cachované LV, získáme následující výstup:
dmsetup status /dev/mapper/vg-home # vypise: 0 1677721600 cache 8 4160/17408 128 1306202/2097152 87122544 9943501 25634508 20958276 0 1306202 0 1 writeback 2 migration_threshold 2048 mq 10 random_threshold 4 sequential_threshold 512 discard_promote_adjustment 1 read_promote_adjustment 4 write_promote_adjustment 8
Význam jednotlivých kolonek je možné vygooglovat, ale lépe se podívat přímo do dokumentace:
<metadata block size> <#used metadata blocks>/<#total metadata blocks> <cache block size> <#used cache blocks>/<#total cache blocks> <#read hits> <#read misses> <#write hits> <#write misses> <#demotions> <#promotions> <#dirty> <#features> <features>* <#core args> <core args>* <policy name> <#policy args> <policy args>*
Z výpisu je vidět, že moje cache je zaplnění z 62% a při čtení zabrala v 89% případů: read_hits / (read_hits+read_misses) a pro zápis v 55% případů.
Poznámky
Další drobnosti, které někoho mohou napadnout — dle dokumentace lvmcache lze vytvořit cache pool jedním příkazem. Stejně tak je možné vytvořit zrcadlený cache pool pro vyšší robustnost — zde pozor — LV, ke které je připojena cache, nelze připojit samostatně.
Závěr
Máte-li tip na podobné pokročilé techniky nad LVM, neváhejte se s nimi podělit v diskuzi pod článkem, stejně tak budu rád za jakékoli upřesnění nepřesností a doplnění textu.