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.
Přijde mi, že tu spíš trolíte než přispíváte do diskuze. Jaké máte zkušenosti se ZFS a databázemi? Jaké databáze, jakých parametrů provozujete?
Zde je poměrně užitečný benchmark: https://www.enterprisedb.com/blog/postgres-vs-file-systems-performance-comparison
Dobrý vzhled poskytly i tyto články: https://www.percona.com/blog/mysql-zfs-in-the-cloud-leveraging-ephemeral-storage/
a
https://www.percona.com/blog/mysql-zfs-performance-update/
ZFS je hodně o tom, jak jej nastavíme a jak nastavíme server. Na XFS je to víc prostě naformátovat nějak disk a ono to poběží už poměrně rozumně i bez explicitního tuningu, dokud neděláte věci jako zálohy/ recovery, kde to je se samotnou databází a XFS úplně jiná písnička. Potom si do toho pozvete ještě LVM, aby se daly ty konzistentní snapshoty nějak dělat a už ta komplexita roste a celková kvalita/ výkon služby spíše klesá. No a nebo to nějak řešíte na úrovni databáze.
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/
Jinak samozřejmě, ext4 je na db špatná, xfs super, ale údržba také není nic moc. Když to člověk takhle projde, zjistí, že to zfs zase není tak špatné..
S tím O_DIRECT máš bližší informace, že ho vidíš na dohled? Já zatím nemám.
Tady je třeba důležitá věc, se zfs vypínám kernel page cache, ušetří to pár %, protože díky zfs ARC je zbytečné data ještě ukládat do další paměti.
Jinak, napište mi prosím, ať si vyměníme kontakt (viz můj profil).
O O_DIRECT nemám bližší informace než co je dostupné na GH a o čem jsou záznamy z developer summitu. Zdá se, že nějaká iniciální práce se stala už v ZFS 0.8: https://github.com/openzfs/zfs/releases/tag/zfs-0.8.0 a
https://github.com/openzfs/zfs/pull/7823
Zde jsou občasné zmínky v OpenZFS Leadership Team - Meeting Agenda and Notes Podle všeho v LLNL a LANL ještě kolem DirectIO něco vaří, protože jim to 1,5-3x zvyšuje rychlost na polích z NVMe: https://storageconference.us/2023/AtkinsonPresentation.pdf takže na to se určitě těším.
Zajímavé jsou různé drobnosti, jak per dataset rate-limit pro read např. nebo práce na rychlejší deduplikaci: https://youtu.be/sLX-bKEDpNE?si=10Iz-5FlNswJ2wvw&t=765
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
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.
Nechtěl jsem nikoho urazit. Jen konstatuji že pokud jsem za chod nějaké technologie odpovědný, tak si o tom mám minimálně elementární vlastnosti nastudovat. Jestli si můj názor vezmete k srdci a dovzděláte se, nebo to budete brát jako útok či urážku, je Vaše osobní právo na interpretaci této informace.
V článku se řeší ZFS na VPS. Ale samozřejmě úplně stejně můžete realizovat velké pole s kapacitou stovek TB nebo i více. Jinak ze zkušenosti ta degradace výkonu obvykle ( ne ve všech případech ) přichází až po překročení 90% ( prakticky je to o tom, jak moc se na pole zapisuje ). Prostě pokud nasazuji kamkoliv filesystém s Copy On Write, tak je toto obecná vlastnost a když na začátku počítám sizing a ekonomiku provozu, tak s tím musím počítat. A naprosto prakticky ... vzhledem ke kompresi a případně deduplikaci, tak reálně uložím více dat než na standardní filesystém. Takže to nakonec neni tak černé.
Toto je například můj backup server:
compressratio 1.97x
compression zstd
Takže reálně ušetřím skoro polovinu kapacity a i když bych jako hard lmit bral 80% kapacity pole, tak jsem pořád hodně v plusu. Zrovna u serveru se zálohami bych se ale nebál překročit ani těch 90%, protože dopad na výkon v tomto konkrétním případě žádný nebude.
Ale jsou situace, kdy komprese ani deduplikace nepomůže prakticky vůbec. Typickým příkladem jsou šifrovaná a/nebo již zkomprimovaná data.
Dopad na vykon samozrejme bude, v zavislosti na IOps ktery ten zalohovac je schopny fyzicky dodat. Videl sem situace, kdy zalohovac nezvladal v ramci zalohovaciho okna merge, jednoduse proto, ze velikost zaloh vs IOps HW.
Pricemz to cele bylo dodano tzv "na klic" a cena byla v 8mi mistna ...
To ze je to "jen" zaloha neznamena, ze to nepotrebuje adekvatni vykon.
Ostatne i samotne vytvareni zalohy neni bez dopadu na vykon provozniho stroje, a cim dele to trva, tim horsi ten dopad je.
Záloha samozřejmě výkon potřebuje, nemyslím že jsem někde napsal že tomu tak neni. Z pohledu filesystému je ten rozdíl v tom, že nedokází k přepisu existujících dat, ale data doplňujete o nová a pak stará odmazáváte - takže COW v tomto scénáři nemá takovou vlastní režii a díky tomu začně výkon degradovat až daleko za hranicí 90% obsazenosti. Oproti tomu scénář kdy data neustále přepisujete má tu režii COW velkou.
Z pohledu ZFS si v tomto scénáři můžete ale hodně pomoci .... například akcelerovat velkou kapacitu na HDD pomocí rychlých SSD disků.
Nemel by mit provozovatel nejakou provozni rezervu? Treba i cold spare? Nemel by se na kazdou operaci pripravit a overit ze mu budou stacit zdroje a jinak to odpiskat a predtim navysit kapacitu? Nemel by sledovat nejaky progress v monitoringu? Nemel by mit nastavene soft boundaries jako kvoty?
Ja bych tam ten osten i nechal. Tech vypatlanych firem ktere nadavaji na to ze jim <dopln_libovolnou_technologii> zaplnila pole mam plne zuby.
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.
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í.