Administrace komentářů

Už několikrát jsem tu psal, že RAID{1,5,6} dává smysl pouze tehdy, je-li vestavěný přímo ve filesystému. Jinak z jeho výhod zbude jen směšný zlomek.

RAID používám kvůli tomu, aby mi to fungovalo, když zhebne jeden (případně dva) disky. Případně ještě pro získání většího výkonu při sekvenčním čtení. To skvěle funguje i bez filesystému. Máš na mysli ještě nějaké jiné výhody?

Samozřejmě mám na mysli další výhody a ne jen tak ledajaké. Disk nemusí zhebnout. Může pouze obsahovat špatná data (po problému s napájením, vlivem závady nebo vlivem lidského faktoru (začínající administrátor a dd, začínající administrátor a fdisk)). Striktní dodržení vrstev abstrakce způsobí, že RAID vrací špatná data, leckdy jiná při každém čtení. (Stačí si představit, jak se data čtou prokládaně.) RAID na úrovni filesystému tento problém snadno ustojí. Checksum mu řekne, který z disků má pravdu (ať už je to RAID1, RAID5, RAID6 nebo jiný typ redundance), a blok se pak opraví podle replik (RAID1) nebo podle parity (RAID5,6).

Další výhoda pokročilých filesystémů (ne nutně související s RAIDem, ale přece výhoda) je možnost mít jiný RAID level pro data a metadata nebo dokonce pro různé části filesystému. Kromě elegantního řešení dilemat typu využití místa versus spolehlivost to nabízí ještě jednu pěknou vlastnost — pokud budou například metadata typu RAID1 a data typu RAID0 a jeden z disků v poli odejde, neztratím všechna data. Filesystém bude mountovatelný a některé soubory (ty, které se šťastnou náhodou trefily celé do dostupných bloků) budou dostupné. Právě v malých souborech má člověk leckdy nejdůležitější data… Tohle žádný klasický RAID neumí.

Poslední zajímavou výhodou filesystémů podporujících atomické checksumy a RAID je možnost replikace dat a/nebo metadat v rámci jednoho disku (resp. v rámci každého z disků pole). U dat to (kromě hodně důležitých subvolumes) až tak velký smysl nedává, ale u metadat to může výrazně pomoct, když se (a) objeví vadné bloky nebo (b) filesystém poškodí nějakým neopatrným zásahem — někdy se člověk nestačí divit, co všechno lidský faktor umí způsobit.

Uvnitř virtuálního stroje pak samozřejmě poběží operační systém s Btrfs nebo ZFS, který si dovede konzistenci dat na svém virtuálním disku ohlídat.

Nedovede, protože nemá přístup k původním diskům. Když tedy RAID nebo on zjistí nekonzistenci, nemá jak zkusit, které disky dávají správná data a které špatná.

Buď k nim přístup bude mít (což se zatím v tolsetech všeho druhu příliš nepodporuje a už vůbec ne v souvislosti s migrací, jak správně podotýkáš níže), nebo zkrátka nevyužije všech výhod RAIDu na úrovni filesystému (zejména co se výkonu týká). Virtualizace má výhody i nevýhody a tohle je (zatím) jeden z kompromisů.

Dlužno ale zdůraznit, že pomocí „zvol“ na ZFS můžeš vytvářet a exportovat disková média, která jsou nejen redundantní, ale taky automaticky checksummovaná a tedy odolná proti skrytým chybám disků. ZFS tedy umí zabít dvě mouchy jednou ranou — spolehlivý filesystém na serveru a spolehlivá virtuální média pro virtuální stroje. Kdyby tu diskutoval Jirka Paroubek, zeptal by se ostatních filesystémů: Kdo z vás to má?!

Ideálním řešením je přidělit virtuálním stroji několik logical volumes (vhodně alokovaných podle topologie fyzického úložiště) a nechat ho, aby se o RAID (na úrovni filesystému, samozřejmě) postaral sám.

To je noční můra. Virtuální stroj mám proto, abych ho mohl bez zásahů zvenku přelejvat mezi různými stroji ve virtualizačním clusteru. Ne, že když ho dám na stroj, který má náhodou jiný počet disků, budu muset spustit komplikovaný rebalance/reshape.

V tom máš naprostou pravdu. Počet disků fyzického stroje by ale nemusel hrát až takovou roli, pokud by nějaký budoucí virtualizační stack dokázal alokaci disků rozumně zautomatizovat a pokud by počet fyzických disků převyšoval počet virtuálních, což lze očekávat. Do té doby by asi byl schůdným řešením zvol nad ZFS, který se dá (při dodržení správné velikosti) naalokovat na každém stroji jiným způsobem a pokaždé může být distribuovaný, checksummovaný i redundantní, bez ohledu na to, co s ním dělá virtuální stroj.

Faktem ale zůstává, že pokud filesystém ve virtuálním stroji nemá ponětí o topologii úložiště, bude to mít velmi negativní dopad na výkon. Tohle je jeden z nedořešených problémů (současné) virtualizace.