Názory k článku
OpenZFS přidává podporu pro Direct I/O

na tohle čekáme jak na smilování. Těším se, až se to bude moci vyzkoušet, hlavně pro distribuované databáze (či databáze obecně) to je velký přínos.

A to ked teda mate a spravujete DB ktora naozaj vyzaduje vysoky vykon nema to taku prioritu ze by ste presli na nieco ine ako ZFS? U nas su napriklad pre DB vyhradene specialne stroje ktora maju celu konfiguraciu prisposobenu danej DB.

Kéž by, dnes se čím dál častěji DB cpe do openstacku/ku­bernetu a z celého se dělá služba. S ZFS to funguje relativně dobře, dají se snadno generovat datasety pro pody/kontejnery, s xfs to je složitější a konfigurace kvót přes projekty a generování snapshotů nad složkami není pohodlné.

Bohužel doba, kdy na DB máme vyhrazený, specializovaný, vyladěný server pomalu odchází, dnes vše musíme provozovat na univerzálních serverech a složitě hledat společná nastavení HW a hledat cesty, jak co ohnout, aby to fungovalo. Už i státní zakázky pomalu přechází to, že infrastruktura se popisuje přes helm chart.

Na druhou stranu každý další FS zvyšuje komplexnost automatizace, záloh, obnov, provozu a v týmu musíme ty znalosti udržovat. Nedostatek znalostí na stabilitu má asi vyšší dopad než data strkat do ARCu.

> dnes vše musíme provozovat na univerzálních serverech
nemusite

chápej to tak, že tohle poptávají klienti, samozřejmě nemusíme...

:) Vy znáte jeho konkrétní projekty? Jasně že nemusí, může dělat projekty jiné, nebo třeba pěstovat kedlubny.

Já chápu jak to myslíte, nedávno se zrovna tenhle aspekt výběru vhodného FS pro db řešil na fóru. A víceméně s vámi souhlasím, pokud řešíte dedikovaný db server, chcete nejlepší výkon, nejmíň problémů a máte to pod kontrolou.
Asi teď budu zmiňovat úplně očividnou věc - v praxi se můžete setkat s mnoha dalšími parametry pro rozhodování, kdy některé z nich půjdou proti sobě (jedno zjednodušení vám zkomplikuje život jinde). Stejně jako že třeba nemusíte mít pod kontrolou budget, výběr nějaké technologie, anebo poskytovatele infrastruktury, SaaS. Jestli vyhodnotíte, že je jakýkoliv aspekt kritický a bude v daném projektu problém, nebo byste sice byl radši, aby to bylo jinak, ale parametry to splní a bude to funkční, je už další věc. Stejně jako to, jestli o případném problému dokážete přesvědčit toho, kdo to pod kontrolou má, aby rozhodl jinak.

Jaky ma vyznam mit db na takto slozitem fs? A to pisi jako clovek pracovne ZFS zaujaty, stranny a zamestnabatelem podplaceny.
Neni to spis otazkou spravnych db ops? Jako presun db za ziva na jiny fs, repliky snapshoty na bazi db aj?
Nektere DB zvladaji svoji praci I bez fs na blokovem zarizeni.

25. 9. 2024, 11:52 editováno autorem komentáře

zpravidla to jsou důvody externí, třeba někoho napadlo provozovat kubernetes nad zfs a ty pro služby nemáš moc jiných možností.

Nebo z pohledu dev ops, kdy chceš mít agnostické procesy typu, vypnu/zmrazím službu, udělám snapshot, přenese/zazálohuji, obnovím, spustím službu. Řešit rozdílové zálohy na jiných FS není zase tak triviální, zejména pokud máš udržet atributy souborů.

V posledních letech na truhu vidím velkou snahu ty technologie sjednotit, odstranit různé jednoúčelové blackboxy a snažit se mít vše pod kontrolou. Není to tak dávno, kdy bylo běžné, že jsme dodali projekt vč. HW a nainstalovanýho OS, po dobu životnosti se pak na ten server nesáhlo, to ani aktualizace, dnes najednou se musí aktualizovat skoro na týdenní bázi a najednou admini potřebují znalost jak službu zastavit, zázálohovat, obnovit a mít na to procesy a není nic jednoduššího, když se snažíš na to udělat nějakou šablonu a mít vše stejně a případné výjimky dávat jen ojediněle.

Stejně tak dříve jsme měli několik fyzických serverů a na tom core databáze pro všechny systémy, jak ale rostou požadavky, roste množství systémů i dat, rostou potřeby různých verzí a nastavení, vznikají spousty samostatných databází a tady už finančně nedává smysl to provozovat na dedikovaném HW.

Ještě bych dodal situace, kdy tam nemusí jít přímo o umístění databáze na ZFS datasety.
Ale např. i menší instalace s virtualizační platformou jako Proxmox, která je pak nakonfigurovaná tak, že má lokální ZFS úložiště sestavené z přímo připojených SSD a VM používají ZVOLy jako virt. disky.
Takže sice ve VM může mít libovolný jiný fs, nebo i raw blok. zařízení uvniř, ale pořád to sdílí obecné charakteristiky ZFS.

25. 9. 2024, 14:04 editováno autorem komentáře

VM můžou být klidně i nad datasety. To má řadu výhod, třeba to, že datasety jsou obecně víc testované. Různé disky k jedné VM lze potom např. zanořit pod nadřazený dataset pro snadnější správu.

Ano to samozřejmě můžou, otevře to navíc i některé možnosti, co s ZVOLy nejdou.
Nicméně uváděl jsem to spíš jako typický příklad toho, kdy vám v serveru s hypervizorem už jednoduše ZFS běží pod těmi virtuály, aniž byste si ho nutně musel vybrat přímo pro provoz DB (v kontextu otázky, jaký význam má řešit případné složitosti v ZFS pro databázi).

Len 25 rokov po SGI XFS.?!

ASi se to v souborovém systému, který umí snapshoty, šifrování, kompresi, deduplikaci, má multilayer cache, slog, supluje za "volume manager" včetně "RAID", má checksumy nad daty, ... implementuje hůře než v systému, který tyhle věci nemá :-)

XFS toho umi taky dost, treba deduplikace, ale ve sve dobe byl revolucni, jako HPFS ma B-Tree, umi vice formaty v FS, treba linearni, nejake RAW formy pro konkretni soubor a nejake optimalizace v podadresarich dle atributu ;-) dale onen Direct I/O, ale tez ACL a ve sve dobe odporoval velke FS, takze casto ani nebyla jina moznost, nez mit vse na XFS --- XFS byl velky prirustek do Linuxu a ne nadarmo si jej RHEL nakonec vybral jako vychozi FS - napr. reflink to podporuje taky.

Ano XFS toho neumi tolik jako ZFS nebo BRTFS, ale na svoji dobu toho umel fakt dost a i dnes patri mezi spickove FS, je tedy potreba to porovnavat v kontextu doby a ve sve dobe to byl FS plny do te doby nevydanych vlastnosti ;-)

Jo ale ZFS dodnes nema nastroj na opravu, takze pokud se zhrouti, coz uz jsme videl, tak nemas data a obnovujes se zalohy, zatimco jine se snadno opravi a voala jede se dale.

A jak dlouho trvalo ZFS, ze je treba umet expandovat zRAID - tvrdili, ze to nikdo z enterprise nema - treba NetApp ? ... spise neznam nikoho, kdo by neumel expandovat ;-)

K cemu je to dobre, reknme ze mame zpool s 4x zraid dual parity a 8x disku a 2TB ... a chcme pridat 8 TB ... novy zRAID by bylo treba 8x2TB ... nebot mensi by ovlivnil vykon a tratili by jsme dalsi 2 disky na paritu ... no tak pridame disk do kazdeho zRAID ... nebo 2 disky ... a razem rozsirujeme o skutecnou kapacitu bez ztraty kapacity diky parity ... nekdy se to hodi pri provozu, jindy pri migraci, kdy treba mame kupu spare disku, ale ne dost na novou zraid- raid group a vime, ze budou vetsi snapshoty diky blokove migraci na novy storage ... a do stareho nechceme investovat ... v 99% to vzdy pomohlo, jen jednou jsme potrebopvali zapujcit starsi schelf - duvodem byl ale narust dat, pak nutnost rozdelit volumu - pokud firma koupi novy storage, ma zajem migrovat a ne dokupovat disky do stareho ;-) - a nekdy behem migrace prisly nove data ;-)

Dlouhé technické příspěvky bez diakritiky... to fakt ne! lidi mějte rozum to se nedá číst!

Snad pod každým článkem se do ZFS opíráte, ale žádný kloudný incident či bug report jste neuvedl a to dokonce ani verzi ZFS, se kterou jste to prý viděl. To se potom dá jen pokrčit rameny. Když Vám vyhovuje NetApp, tak přece používejte NetApp.

Kde tvrdili vývojáři ZFS, že expanzi nikdo nemá? To se ten odkaz nedal přiložit?

Poslední odstavec je pro mne těžko čitelný a nejsem si jistý, jestli jsem ho správně pochopil. Pokud má firma nový storage, tak jí přece nic nebrání na něj zmigrovat aniž by rozšiřovala původní storage.

Implementujeme i DB bez filesystemu na blokovem zarizeni.

To jste dobrý! :) Bloková zařízení uměla O_DIRECT ještě dřív než XFS.

pre virtualky (proxmox) zatial nie:
"ZVOLs and dedup is not currently supported with Direct I/O."