Kéž by, dnes se čím dál častěji DB cpe do openstacku/kubernetu 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.
v cem je ta situace jina? Kdyz mi jako odbornikovi na danou oblast plati pytel penez tak bych jim mel byt schopen vysvetlit proc je me reseni to spravne reseni... Pokud nejsem schopen jim vysvetlit proc je to moje reseni to spravne reseni pak asi nejsem dostatecny odbornik na danou oblast. Ja chapu ruzna omezeni projektu ale taky se nepodepisu pod nejaky bastl ktery nebude odpovidat pozadavkum a standardum, klidne at si najdou nekoho jineho kdo jim odkyve cokoliv.
samozřejmě, když někdo bude chtít zálohovat na diskety, tak takovou zakázku asi nevezmu, když ale někdo chce infrastrukturu v Azure/AWS vč. databáze, tak řeknu, ok, ok, jdeme na to.
Dnes spousty společností si už neprovozují vlastní HW, dokonce i velké banky přechází na cloud (některé budují i interní) a přesouvají se tam i databáze, protože výhoda deklarativní konfigurace, zálohování, okamžité obnovy stojí za nějaký propad výkonu.
:) 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
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).