Vlákno názorů k článku
OpenZFS přidává podporu pro Direct I/O od Uncaught ReferenceError: - na tohle čekáme jak na smilování. Těším se,...

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).