Přečtěte si, jak využít nástroj bcache a pokročilé vlastnosti souborového systému XFS k efektivnímu zkombinování SSD a HDD (nejen) při práci s virtuálními stroji.

Úvod

Jako vývojář instalátoru Anaconda potřebuji pro svou práci hodně virtuálních strojů, abych mohl testovat změny, na kterých pracuji, případně reprodukovat bugy, pokud se zrovna nějaké objeví. Abych nemusel jen sedět a čekat, než se dokončí některé dlouhotrvající operace, pracuji většinou na více věcech zároveň. Mnoho virtuální strojů rovná se velké nároky na procesor, paměť a disk.

Proto, když disk v mém pracovním Lenovu W510 dosáhl už poměrně slušného stáří se vší tou zátěží, rozhodl jsem se neriskovat a pořídit disk nový. A tak přišlo dilema -- SSD, nebo HDD? Na jedné straně instalace na tři virtuální stroje vylučuje sekvenční zápis a potřebuji výkon, aby zůstal systém i při takovém procesu použitelný, na druhou stranu osm virtuálních strojů vyžaduje hodně místa, zvlášť když alespoň některé z nich musí posloužit i pro testování konfigurací s několika disky. Nakonec jsem se rozhodl pořídit SSD spolu s externím rámečkem USB 3.0, do kterého jsem dal původní HDD s tím, že na něm budou „disky“ virtuálních strojů. Konfigurace, která přináší kombinaci kapacity a rychlosti (tři paralelní instalace vytěžují externí disk na maximum, ale interní SSD umožňuje systému normální fungování), což jsou pro mé využití dva důležité parametry.

Technologie Fedory 20

XFS

Když se nedávno objevil RHEL 7 Beta a bylo zřejmé, že RHEL 7 používá jako výchozí systém souborů XFS, řekl jsem si, že bych se na tento file system měl zase trochu podívat. Roky ho mám doma na datovém disku a externím disku, protože jsem se kdysi dočetl, že je velmi robustní, není na tom špatně s výkonem a líbilo se mi, že z mého 100GB oddílu na externím disku si při vytvoření pro sebe ukrojil jen kousek z volného místa. Až teď po letech jsem však byl schopný pochopit články a příručky, jež XFS a jeho vlastnosti popisují. 12

„Óda na XFS“ by bylo téma na samostatný článek a přiznávám, že bych se na pro mě tenký led porovnávání souborových systémů nerad pouštěl. Věřím, že i mezi čtenáři tohoto článku se najde mnoho lidí, kteří by o této tématice věděli více než já. Chci ale zmínit alespoň tolik, kolik bylo důležité pro mé rozhodování, a co mě nejvíce oslovilo a rozhoupalo k tomu, abych XFS ve své konfiguraci použil.

  1. XFS je od začátku navrhováno tak, aby pokud možno co nejvíce operací mohlo běžet v několika vláknech, a tak dokáže velmi dobře využít multijádrové a multivláknové konfigurace současných počítačů.
  2. XFS provádí kontrolu a opravu systému souborů při připojování, není třeba při startu počítače spouštět fsck.xfs (ve skutečnosti je fsck.xfs jen shell skript informující uživatele o tom, že má spustit xfs_repair apod.). Vyhovuje mi, že se souborový systém zkontroluje, až když připojím oddíl na externím disku.
  3. XFS umožňuje mít log (žurnál) na jiném zařízení než data. Žurnálování znamená velké množství operací s malými daty, u kterých je potřeba, aby byly velmi rychlé, jinak brzdí vlastní práci s opravdovými daty. Proto je možnost mít žurnál na SSD, zatímco data jsou na HDD, velmi přínosná.
  4. XFS podporuje discard/TRIM, a umí tedy předejít degradaci výkonu zápisu SSD tím, že disk informuje o nepoužívaných částech disku, a nechává tak na interních mechanismech SSD, aby se postaralo o znovupoužití těchto částí při následných zápisech. To zároveň předchází zbytečnému opotřebení flash buněk a prodlužuje tak životnost SSD.
  5. XFS má nástroj xfs_fsr (file system reorganizer for XFS), jenž umí provést údržbu systému souborů, snížit fragmentaci souborů, předejít další apod.

bcache

bcache (block cache) je mechanismus v kernelech verze 3.10 a vyšších, který umožňuje použití jednoho blokového zařízení jako cache pro jiné blokové zařízení. Typickým příkladem (i když určitě ne jediným) je tedy kombinace SSD a HDD, a tím vytvoření de facto hybridního disku, avšak na softwarové úrovni, a tedy s mnohem větší flexibilitou, podobně jako je tomu u hardwarových a softwarových RAIDů. Základním rozdílem je to, že pomocí bcache můžeme vytvořit cache více na míru našim požadavkům, zejména si můžeme zvolit velikost cachovaného i cachujícího zařízení. Stačí na HDD vytvořit diskový oddíl kapacity, kterou potřebujeme, na SSD vytvořit diskový oddíl velikosti cache, kterou chceme HDD dopřát, a poté už jen říct bcache, že tohle je naše konfigurace (viz níže v části o nasazení). Lze tak např. využít SSD jako cache pro několik různých HDD, případně využít část SSD jako disk pro systém a část jako cache pro HDD apod. Dá se říci, že představivosti se meze nekladou.

Jediným omezením je to, že bcache funguje nad blokovými zařízeními, a proto nelze např. využít pro vytvoření lokální cache oddílu NFS (iSCSI už je samozřejmě věc jiná). Je však pravdou, že bcache je minimálně s výchozími hodnotami parametrů připravená zejména pro práci s SSD (např. velikost cachovaných jednotek bývá z důvodů menšího opotřebování SSD shodná s velikostí nejmenších smazatelných jednotek, viz man make-bcache).

Dále můžeme u bcache určit, jaký způsob zápisové cache se má používat --writethrough, writeback, writearound, none. Věřím, že první dva není třeba vysvětlovat, writearound cache funguje tak, že dlouhé sekvenční zápisy, které nečiní problémy ani HDD, cache obcházejí a data se zapisují rovnou. Výhodou je ponechání ostatních dat v cache připravených pro čtení (málokdy chceme přečíst zpět vše, co jsme právě zapsali) a menší opotřebení SSD, díky ušetření velkého množství zápisů. Použití zápisové cache je velmi vhodné, neboť data jsou při zápisu na HDD serializována a zapisována sekvenčně, jak jen to jde. Proto je rozdíl při použití bcache nejen vidět (na rychlosti práce s daty), ale i slyšet (R/W hlava HDD nelítá jako pominutá). Konfigurovatelných parametrů je mnoho, ale troufám si říci, že kromě způsobu práce zápisové cache jsou všechny určeny spíše pro pokročilejší uživatele.

Nasazení technologií

Už tedy víme, co nám technologie Fedory 20 můžou nabídnout. K jejich využití máme k dispozici externí 500GB HDD a 250GB SSD a chceme dosáhnout následujících parametrů:

  • rychlý a pohotový systém využívající rychlosti SSD
  • velká kapacita diskového prostoru pro virtuální stroje a jejich snapshoty
  • dostatečná rychlost instalací na virtuální stroje
  • malá degradace rychlosti instalací na virtuální stroje při paralelních instalacích
  • možnost používat systém i bez externího disku s virtuálními stroji
  • rychlá práce se snapshoty virtuálních strojů usnadňující testování změn v instalátoru

Mně se jako nejlepší řešení využití výše uvedených technologií a HW vybavení jeví umístění systému na SSD a virtuálních strojů na externí HDD cachovaný částí SSD, přičemž žurnál souborového systému oddílu pro virtuální stroje může být na rychlém a pohotovém SSD.

Vytvoření bcache

Prvním krokem je rozdělení disků a příprava diskových oddílů. Rozdělení části SSD pro systém je asi věcí každého z nás, ale řekněme, že 230 GB pro systém a data uživatelů stačí. Zbývajících 20 GB SSD můžeme využít jako cache pro externí HDD, jen posledních 128 MB si necháme jako místo pro žurnál systému souborů pro virtuální stroje (viz níže), který pokryje celý externí HDD. Když máme 20GB diskový oddíl (řekněme /dev/sda6) připravený pro cache a 500GB oddíl (řekněme /dev/sdb1) pro virtuální stroje, následujícími příkazy z nich jako root odstraníme potenciální zbytky metadat předchozích formátů (systémů souborů, odkládacích prostorů atd.), které by mohly kolidovat s metadaty bcache:

# wipefs -a /dev/sda6
# wipefs -a /dev/sdb1

Tím máme připravený prostor pro bcache, a můžeme se tedy pustit do zapsání metadat. O to se postará nástroj make-bcache (na Fedoře dostupný v balíku bcache-tools), konkrétně následující dvojí spuštění:

# make-bcache -B /dev/sdb1
# make-bcache -C /dev/sda6

První příkaz vytvoří metadata na cachovaném zařízení („Backing device“), druhý na cachovacím zařízení („Caching device“). Dále tato dvě zařízení musíme propojit, a vytvořit tak samotnou bcache. Výpisem metadat (superbloku) cache zjistíme tzv. cset.uuid, které pak připojíme k zařízení bcache0:

# bcache-super-show /dev/sda6
# echo CSET.UUID_Z_VYSTUPU > /sys/block/bcache0/bcache/attach

A máme hotovo, naše bcache je na světě! V /dev by se mělo objevit zařízení /dev/bcache0 a pro další kontrolu můžeme spustit nástroj bcache-status, který vypisuje statistiky o bcache zařízeních v systému:

# bcache-status -s

Vytvoření systému souborů

Nyní máme bcache, na které můžeme vytvořit systém souborů XFS. Při rozdělování disků jsme si nechali 128 MB pro žurnál tohoto souborového systému. Dokumentace XFS 2 říká, že maximální velikost žurnálu je menší z hodnot 128 MB a 64 K bloků, což při v dnešní době standardně používané velikosti bloku 4 kB znamená, že 128 MB je omezující hodnota. Žurnál může být i menší, minimální velikosti je délka nejdelší transakce systému souborů, kterou budeme chtít vrátit nebo provést znovu. To jsou však detaily, do kterých se dle mého názoru obyčejný uživatel vůbec pouštět nemusí. 128 MB místa na disku máme v dnešní době všichni a případné delší zpracování zbytečně velkého logu při opravě systému souborů snad taky nebude činit problémy. O vytvoření systému souborů dle našich představ se postará následující příkaz:

# mkfs.xfs -l logdev=/dev/sda7 -L VIRTUALS /dev/bcache0

Nastavení štítku systému souborů (-L VIRTUALS) můžeme samozřejmě vynechat, ale ze zkušenosti vím, že používání štítků zvyšuje přehlednost při následovné práci s diskovými oddíly. Přece jen jsou štítky smysluplnější než UUID.

Máme tedy systém souborů na bcache, který můžeme připojit a začít s ním pracovat. Protože ho však budeme chtít připojovat často, je vhodné přidat řádek do souboru /etc/fstab, abychom si ušetřili psaní dlouhého příkazu pro připojení. Řádek může vypadat např. takto:

LABEL=VIRTUALS /mnt/virtuals xfs defaults,user,noauto,logdev=/dev/sda7 1 2

Pak již stačí, aby v systému existoval adresář /mnt/virtuals a můžeme i jako běžný uživatel příkazem

$ mount /mnt/virtuals

připojit náš nový, výkonný systém souborů na bcache, vytvořit na něm disky virtuálních strojů ve formátu qcow2, který umožňuje práci se snapshoty, a pak už můžeme spokojeně sledovat výstup nástroje bcache-status, abychom viděli, jak se cache zaplňuje, kolik má zásahů apod. Zároveň ve výpisu tohoto nástroje můžeme zjistit, jaký způsob zápisové cache se používá. V mém případě bylo výchozí hodnotou writethrough, což je pro pro výše popsanou konfiguraci nevhodné, protože virtuální stroje by musely čekat na dokončení zápisu na externí disk. Pro přepnutí na režim writeback nebo writearound stačí kernelu jako root říci, že se má bcache odteď chovat jinak:

# echo writearound > /sys/block/bcache0/bcache/cache_mode

Dál už si stačí užívat to krásné ticho, kdy zápisy na externí disk probíhají sekvenčně, a tudíž R/W hlavička nelítá jako pominutá sem a tam, a kdy se externí HDD jen jednou za čas „protáhne“ chvilkou zapisování data, která se v mezičase možná několikrát změnila.

Sledování a údržba

Jak už to v IT chodí, vytvoření nebo nasazení technologie je jen prvním a zpravidla tím jednodušším krokem. Následuje údržba a dolaďování, kdy teprve začíná ta pravá zábava. V našem případě se jedná v podstatě o dobrovolnou činnost, protože konfigurace dokáže dobře fungovat téměř neomezeně dlouho, i když ji necháme bez jakýchkoliv zásahů. Já jsem zvědavý a mám rád pořádek, takže trochu sledování a údržby přece jen dělám. Konkrétně mám v /etc/cron.daily/ jednořádkový skript, který spustí bcache-status, přičemž výstup je zaslán rootovi mailem (výchozí chování u úloh cron). Můžu se tak pravidelně nebo jednou za čas dívat, jak na tom bcache byla se zásahy, využitím apod. Kdo bude chtít, může si samozřejmě pohrát i s parametry bcache a zkoušet různé hodnoty pro parametry v /sys/block/bcache0/bcache/, které dokáží bcache dobře přizpůsobit.

Nesmíme však zapomínat ani na souborový systém XFS a jeho dovednosti, zvláště ve spojení s SSD. Můžeme např. využít podpory TRIM a do /etc/cron.daily/ přidat skript spouštějící nástroj fstrim, jenž se postará o sdělení disku, které části jsou souborovými systémy nevyužívány. A jednou za týden, tedy kandidát pro /etc/cron.weekly, může přijít vhod xfs_fsr, který na souborových systémech XFS pouklízí a odstraní (má-li dost volného místa) fragmentaci souborů. Říká se, že fragmentace na SSD nevadí, někdo dokonce říká, že je k užitku, protože SSD pak dělá lepší paralelní čtení jednoho souboru z různých banků buněk. Já si ale myslím, že defragmentovaný soubor naopak nechává na firmwaru a hardwaru SSD, aby si ho rozdělily a umístily nejlépe, jak je to možné, což je to nejlepší, co může systém nic netušící o fyzikálních principech a fyzickém rozdělení disku udělat.

Závěr

Výsledkem pár příkazů v terminálu využívajících technologií dostupných ve Fedoře 20 je konfigurace, jež naplno využívá možností kombinace SSD + HDD, a dosahuje tak výborných parametrů zrychlujících (nebo přesněji řečeno nezpomalujících) moji práci při vývoji instalátoru Anaconda. Systém má v této konfiguraci dostatečnou kapacitu pro disky virtuálních strojů i se snapshoty, čtení i zápis jsou díky cachování velmi rychlé a na externí HDD probíhá zápis téměř vždy sekvenčně, čímž je dosaženo vyšší rychlosti a nižší hlučnosti. Nezaznamenal jsem žádný nárůst využití CPU způsobený výpočty spojenými s cachovacími algoritmy, naopak, díky poklesu množství dat přenesených přes port USB a způsobu fungování protokolu pro USB využití CPU pokleslo. A stále mám systém, ke kterému nepotřebuji připojený externí disk, nechci-li pracovat s virtuálními stroji na něm uloženými. To vše bez navýšení rizika ztráty dat. Docela dobré, co říkáte?

  1. http://techpubs.sgi.com/library/tpl/cgi-bin/browse.cgi?coll=linux&db=bks&cmd=toc&pth=/SGI_Admin/LX_XFS_AG↩
  2. http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/index.html↩