Vlákno názorů k článku Konverze Debianu ze souborového systému EXT4 na moderní ZFS od Petr Soukup - Moje zkušenost je takové, že pokud má databáze...

Moje zkušenost je takové, že pokud má databáze hodně práce, může být lepší to ZFS nedávat, mnohonásobně to urychlí chod a ušetří to též životnost SSD disků, kterým to v případě databáze kde se často mění jen pár bytů, moc nesvědčí. Databázi clonuji na další stroj a udělat si zálohu nějakého clonu, které je možné dočasně pozdržet (i clonovanou databázi vypnout) není problém..

moje zkušenost je zase takové, že rád obětuji trochu výkonu za cenu daleko vyšší spolehlivosti.

Enterprise SSD nám umírají strašně málo, i ty pod databázemi.

ZFS ale není jednoduchý systém, i výkon pro databáze lze dobře vyladit a je potřeba se rozhodnout, jestli chceš ten čas do toho investovat nebo nikoliv.

Máme také několik velký společností, které provozují rozsáhlé databáze nad ZFS. Máme tady ale o dost více společností, kteří si na tom vylámaly zuby.

ZFS má velkou výhodu v tom, že i na storage, který má pomalé IO můžu dělat poměrně levně zálohy pomocí snapshotů aniž bych musel všechno procházet a podívat se, co se změnilo, což je výkonnostně mnohem náročnější než případných konstantních pár procent, které mi evtl. ZFS přidá. Pro nás je to v podstatě čistá a zcela zřejmá výhra. I mentálním modelem je to mnohem blíž Clojure s perzistentními datovými strukturami, než klasické souborové systémy.

Jak to vidíte? Já myslím, že nastíněný tuning PostgreSQL + ZFS bude drtivé většině firem na provoz stačit. Tam, kde to nestačí budou asi mít i na klasickém setupu dost starostí, takže je to o tom, které starosti chtějí mít radši/ co je bolí víc. Storage obecně je hodně těžká kategorie a žádné řešení nebude vyhovovat všem, ale myslím si, že kompromisy, které dělá ZFS může řadě adminům v dlouhodobém horizontu vyhovovat víc. Ano, vyžaduje to určité znalosti.

Neumi snapshoty i nektere databaze na aplikacni urovni? Neumi snapshoty i storage? Neumi snapshoty i jine filesystemy / volume managery. Jako byvaly Sunak jsem sice ZFS postizeny od jeho neverejnych pocatku, nicmene k objektivite je nutno dodat ze ne vzdy se vyplaci mit snapshoty az na urovni filesystemu a upinat se na jedno reseni.

Zrovna optimalizace ZFS na databaze byl diky komplexite ruznych db vrstev docela orisek. Zde jsme zrovna razili filozofii ze cim mensi overhead tim lepe. Takze bud uplne hloupy FS nebo idealne databaze dostane blokove zarizeni a resi mi tam svuj pisecek plne ve vlastni rezii. Stejne ma DB sve interni schema ulozeni informaci - cili vlastne specializovany filesystem.

Naprostý souhlas. Jestli ZFS použít i na databázi s hodně zápisy a updaty je otázka. Pro mnoho použíti může být jednodušší se ZFS vyhnout. Stejně je totiž nutné řešit zálohování i na úrovni databáze a ZFS k tomu nutně nepotřebujeme. Snapshot jde vytvořit i jinak než díky ZFS a overhead může být výrazně nižší.

Snapshot umí ledacos, problém ale bývá to dělat za běhu databáze, na to si často vylámeš zuby.

Databáze to často umí (Pg, ORA atd.), ale není to zrovna zero cost. Mohu použít transakční logy, jejich obnova je ale časově poměrně náročná znamená zpracovat transakci po transakci (což trvá klidně i hodiny na hodně silném HW), u ZFS to máme zadarmo a můžeme hned vedle spustit na readonly snapshotem databáze a koukat na data.

Enterprise diskové pole umí snapshoty, většinou, ale opět ne vždy jsou zero cost, ne vždy je možné je dělat na zaběhu a cenově to je občas dost vysoko.

Poměrně dlouho jsme používali u rýzných klientů takovou tu architekturu, že máme replikovaný SAN přes FC, nad tím Oracle RAC. Vše dost těžkopádné, obnovy znamenaly zalarmovat půlku firmy a čekat hodiny. Roční náklady 5M. Pokud něco běželo na single serveru, tak mirror raid přes řadič a hot swap disky, výkon pro random iops je ale žalostný, při degradace máme data na jediném disku, nic moc.

Dnes ale výkon jednotlivých serverů tak extrémně pokročil, že moderní nvme disky ani pod řadič nedáme a musíme to řešit přes SW. ZFS je zajímavá volba, můžeme mít asychronně replikovanou Pg databázi s vysokým iops výkonem nad jediným server s 3 mirror disky a k tomu ještě zero cost snapshoty a schopnost se kdykoliv koukat do historie jako do knihy. Líbí se mi to jako alternative k drahým enterprise řešením, ale náklady na počáteční vývoj jsou relativně vysoké, není to pro každého.

Tak třeba PostgreSQL s blokovým zařízením pracovat neumí a i u Oracle se pokud vím doporučuje použít XFS.

Mě přijde, že do určité velikosti ta režie ZFS lze značně snížit základním nastavením, které je zmíněné v článku. Jsou i další nastavení, ale ta asi budou potřeba až na hodně velká či jinak vybočující nasazení databáze.

Každopádně se zdá, že O_DIRECT je na dohled: https://github.com/openzfs/zfs/pull/10018

Úplně hloupý FS (EXT4) s hloupým RAID (mdadm) neřeší konzistenci dat. Při velkých nasazeních tohle reálně potřeba řešit je. Takže se to bude flikovat na nějaké vyšší úrovni s možná ještě větší režií.
XFS snad umí metadata checksums, takže aspoň něco. Taky existuje dm-integrity. https://www.redhat.com/en/blog/what-bit-rot-and-how-can-i-detect-it-rhel
Ale ZFS má integritu dat řešenou od začátku by default a má k tomu zabudované nástroje a automatiky, které usnadňují správu toho všeho. Jestli si dobře vzpomínám na nějakou přednášku, tak pro LLNL je lepší udržovat ZFS on Linux, než používat původní řešení - náklady na údržbu a hledání chyb byly výrazně větší. Zdá se, že jim ZFS přijde pro jejich účely jako jedno z nejlepších řešení. I jiným, zdá se, nasazení ZFS vyhovuje: https://klarasystems.com/articles/openzfs-openzfs-for-hpc-clusters/

Nebavím se o velikosti databáze, ale zatížení a hlavně množství zápisů, které je se ZFS problémovější. Pokud je v databázi např. účetnictví, tak je ZFS jistě OK. Ale pokud to sbírá a vyhodnocuje nějaká velká data, kterých když se pár poztrácí, nic se nestane, tak je lepší se ZFS vyhnout. Bude to několikanásobně rychlejší a SSD disk se několikanásobně méně bude opotřebovávat. A to i při všech známých optimalizacích.

Nebavím se o "trochu výkonu" ale násobcích.

V našem případě to ZFS vyladit nešlo, všechny běžné poučky měly jen relativně malý vliv, zapsaných dat bylo nesmyslně mnoho. Jednoznačně pomohlo se ZFS zbavit. Používáme ZFS ale na vše ostatní.

19. 9. 2023, 12:39 editováno autorem komentáře

Zde je možné, že některé z posledních úprav přímo v kódu ZFS můžou pomoct. Musel bych vědět mnohem víc (hardware, zátěž, nastavení), abych se k tomu byl schopen vyjádřit, takhle je to bohužel jen informace, kterou si přečtu, ale žádné velké poučení nebo vhled z toho neplyne. ---\__o__/---

Podrobnosti jsou zde https://forum.root.cz/index.php?topic=26555.0

Netradiční je používání myisam. Ale zkoušeli jsme inodb a také to byla mizérie.
Jedno použití je sbírat všechny signalizace pakety VoIP provozu pro případné řešení problémů. Pokud by se měl ztratit jeden zápis z milionu v podstatě to vůbec nevadí.

"běžné poučky", to bude asi ten problém. Těch zdrojů na internetu a v poučkáš moc není. My si zkušenosti předáváme mezi sebou a drží se u projektů.

Asi nejlépe to popsali na blogu lets encrypt před pár lety (mimochodem mariadb pod lets encrypt běží nad zfs).

K ladění ZFS je často potřeba se podívat do kódu, pročíst si podrobně man pages, udělat si nějaké flame grafy a lépe problém analyzovat. To je i důvod proč ZFS nelze obecně doporučit, je to těžká technologie.

U nás nad ZFS má jeden z operátorů OLTP databázi v Pg, což jsou desítky tisíc zápisů každou vteřinu ve špičce.

19. 9. 2023, 16:35 editováno autorem komentáře

Bylo to pouziti jako ssd write cache nebo primarni ssd? Nezkouseli jste vyhradit na write cache SSD s vetsim poctem zapisu/levne SSD?

Asi jsem v tomhle "brutus", ale pokud potrebuji nasobne vyssi vykon na zapisy/cteni tak to nechavam na "all-in-memory" s tim ze obsah je nekde nareplikovany na konkurencni nod(y). No a z nich se delaji semtam snapshoty. Objemove mezi desitkami TB az stovkou.

No koneckoncu nevim nic o profilu loadu tak muzu byt taky mimo pisoar... Specificke potreby maji treba strizny, zpracovani videi ci odbavovaci pracoviste.

Fatalny problem z FS som zazil len zo ZFS.

Povodny admin nasluboval zo ZFS zazraky ale zabodol sa zmienit o nutnosti mat minimalne 10% kapacity ako vatu.

A je velmy tazke presvedcovat ze potrebujes novu policu a disky ked mas este 20% volnej kapacity. (Cas kedy zacinaju problemy).

Toto je obecná vlastnost asi všech COW filesystémů. Když se podíváte do dokumentace Netappu a jejich WAFL, tak narazíte na nápadně podobné informace.

Otázkou je, zda je chyba minulého admina, že Vám o tom neřekl. Nebo Vaše, že jste pak dál provozoval technologii o které nic nevíte.

To je moc hezká teorie, dokonce s malou a hlavně zbytečnou urážkou na konci, ale hádám, že tohle nebude pole o dvou discích a na takových nemusí úplně snadné ani ekonomické měnit filesystém, zvlášť když jsou z 80 % obsazené.

Ale nie vsetky maju tak katastroficky dopad ked im kapacita dochadza. (IBM storwize/IBM SVC) Ale to sa bavime o triedu lepsej lige ako je Netapp.

Ad posledny odstavec.
Som zvedavy ako presvedcite nadriadenich ze riesenie naraza na svoje limity ked predchadzajuceho admina mali za poloboha.

Skor typujem ze su to len silne reci maleho chlapa. Ktory nikdy nic podobne riesit nemusel.

Ke konci článku nastiňuji triky, jak se možná dostat na úplně jiný řád výkonu, který si prostě s klasickým mutabilním souborovým systémem nikdo netroufne nastavit, protože by to bylo naprosto šílené.
Paradoxně může být ZFS k SSD např. díky kompresi šetrnější. Protože jestli data přepisuji in-situ nebo kopíruji bokem by mělo být z hlediska wear levelingu celkem jedno resp. případně i lepší, protože přirozeně rozkládám zátěž do plochy.

ZFS má ze své podstaty jinak hodně slušné možnosti za běhu SSD vyměnit, pokud používám např. mirroring. Díky snaphostům a inkrementální replikaci můžu lépe a rychleji zálohovat na druhý stroj a zkrátit dobu obnovy v případě havárie.

Mohu rici z praxe ze komprese se hodila v momente kdy bylo zfs provozovano na konfiguraci kde bylo uzke hrdlo storage sit. Tim ze prenasena data byla pomerne dobre komprimovatelna, doslo ke zvyseni vykonu temer o rad. Bylo levnejsi mit vykonnejsi zelezo nez momentalne(v kratkodobem horizontu) upgradovat slozite storage cesty pred dve patra DC za devatero FC switchi a devatero racky...
Ne vzdy se to ale hodi. Zalezi od aplikace Jednak clovek taha nejaky overhead na noze dalsi vec je ze se zvysi latence takze na near-realtime ulohy to neni moc vhodne.

20. 9. 2023, 14:02 editováno autorem komentáře

Trošku to tu latenci může zvýšit, ale u menších bloků a LZ4 to asi nebude nějaká tragédie. Případně lze kompresi i vypnout a nebo komprimovat jen souvislé nuly.

Jinak ohledně sítí a jejich upgradů je to občas složité. Někdy si lze poměrně dobře pomoct např. pár kanály CWDM, což je častokrát levnější než tahat v provozu více vláken.

Jinak, napište mi prosím, ať si vyměníme kontakt (viz můj profil).

Zde hodně záleží na tom, co to je za datábázi a s čím má "hodně práce". Jsem stará škola a ZFS jsem se dlouho bál. Zkušenosti ale ukazují, že se správným nastavením lze u databází obecně docílit stavu, kdy je výkon minimálně stejný jako s konvenčním filesystémem, ale často o mnoho lepší.

Pro takový scénář ale musíte mít i dostatek systémových zdrojů a znamená to jak věnovat čas nastavení ZFS, tak upravit vhodně nastavení databáze. Pokud vezmete běžící databázi a zcela bez úprav ji přesunete na ZFS v defaultu, tak nejpravděpodobnější scénář bude horší performance.

S životností SSD lze v principu souhlasit ... double write má prostě režii a disky opotřebovává víc. Pokud nad takovým filesystémem pustím databázi co také dělá double write, tak tím životnost disku snižuji. Někdy to lze řešit konfiguračně a někdy nikoliv ... nicméně za sebe jsem názoru, že pro daný usecase použiju vhodný HW místo abych upravoval pro HW co mam vše okolo. Takže pokud chci používat na ZFS obecně cokoliv co dělá hodně zápisových operací, tak si na to pořídím disky co to dlouhodobě umožní.