Podla tohoto https://www.salvagedata.com/btrfs-zfs-xfs-ext4-how-are-they-different/
sa zda ze ZFS je dobry na cluster.
ZFS v sobě žádné vestavěné clusterování nemá. Pokud tohle nutně potřebujete, tak musíte mít buď vyloženě clusterovací FS, např. GPFS od IBM, StorNext, OCFS od Oracle, který má nějakou sdílených (distribuovaných) zámků. Nebo pak musíte kombinovat víc věcí dohromady. Tzn. např. ZFS a nad tím glusterfs, CEPH.
Nicméně tady je dobré zároveň zmínit, že jste se ptal na FS pro databázi. Což je jeden konkrétní specifický use case. Většina databázových serverů s určitou formou vnitřního clusterování přímo počítá. Pokud bychom pominuli např. Oracle RAC Cluster, tak se to typicky neřeší na úrovni FS.
Je to vždy specifické pro konkrétní projekt a vybranou databázi, a bývá tam víc způsobů realizace. Nicméně pokud chcete clusterovanou db pro zvýšení dostupnosti, rozhodně nepotřebujete ZFS, ale spíš musíte prozkoumat možnosti vybraného serveru (db engine).
XFS je dobry na, akurat ze nema ziadnu detekciu zlyhani disku alebo "bit rotu"(zlyhanie pametovych buniek v pcb), takze pre DB alebo kriticke datove ulozisko to nie je vhodne lebo moze odfajcit celu db.
Ta online verifikace checksumů, je jeden s těch argumentů pro ZFS. Bit-rot, poškození dat samozřejmě určitou roli hrát může (zvlášť když si děláte nějakou dlouhodobou statistiku v obrovských datacentrech), ale přijde mi, že ve většině případů je to strašně vyhypované.
Řekl bych, že valná většina běžících systému za poslední dekády vůbec žádný on-line checksuming na úrovni FS neměla a nemá, normálně to běhá a není tam žádný excesivní výskyt chyb. Když máte slušný serverový HW a odladěný systém, tyhle problémy typicky nemáte.
Samozřejmě, určité formy ověřování jsou navíc implementováno i na mnoha dalších místech. Od sběrnic, přes ECC paměti, u enterprise storage systémů může být pak navíc použité T10 (DIF, DIX).
Navíc i některé databáze mají možnost konfigurovat ověřování checksumů u stránek.
Ano není to self-healing, ale dokáže to indikovat problém. A stejně když máte něco důležitého, musíte stejně mít dobře vyřešenou strategii pro zálohování (kontrolu záloh, restoru) atp.
Takže za mě, tohle není určitě ta hlavní věc, proč bych šel na databázi do CoW systému.
EXT4 sa zda byt po vsetkych strankach optimalne, az na to ze nevie pracovat s raidom dobre lebo je to len "blby" FS.
V konecmom dosledku je to teda o tom, ci chce clovek viac vykonu(XFS, EXT4), pripadne riesi velky cluster(ZFS), alebo bezpecnosti(BTRFS), povedzme atomicity.
Kedze som sa pytal na databazovy server, tak mi tu vychadza najlepsie EXT4 kvoli vykonu a ked neriesim viac diskov. Inak BTRFS.
PS: o snapshoty na urovni disku mi vobec nejde. To som len tak spomenul ako vyhodu BTRFS ale nie je to nieco co riesim/chcem.. Ide mi primarne o to aby FS vedel zabranit poskodeniu dat a neodfajcil rychlo disky(privela zapisov a citani). Proste nieco na com ma bezat kriticka db a nie obycajna db pre webstranku kde problem s diskom nie je koniec sveta.
Upřímně s tímhle vyhodnocením taky úplně nesouzním. Nemyslím, že by automaticky vše převážila výhoda mít FS s vestavěným RAIDováním (multi device). Třeba konkrétně u BTRFS je tam zrovna tohle docela nedodělané/nedomyšlené, nemyslím tím jen RAID5/6 (který je už léta v neprodukčním stavu), ale např. i u jednoduchého mirrorování.
Například tam není spolehlivý mechanismus jak zajistit, že se po vykopnutí jednoho (vadného) disku z mirroru FS automaticky správě připojí po rebootu tak, aby se spolehlivě detekoval a použil ten druhý (zdravý), který má poslední zápis.
Musíte to jen manuálně připojit s explicitním použitím optionu degraded a správným zařízením. Což je třeba super, když máte BTRFS mirror jako rootfs, vzdálený server a ten se vám po nějakém násilném rebootu zastaví v initrd. Ale i u datového disku je to podle mě docela problém.
Na mailing listech BTRFS a fórech se o tom debatovalo už před deseti lety a pořád se to chová stejně (pravděpodobně jiné priority).
To je třeba jeden z důvodů, proč se to pořád používá dohromady s MDRAIDem, který udělá jedno blokové zařízení, je spolehlivý, akorát pak samozřejmě můžete zapomenout na veškerý self-healing.
ZFS je na tom v tomhle ohledu mnohem líp, ale také má svá specifika a vyžaduje značné ladění.
Jinak jedna ze základních charakteristik CoW filesystémů (jak BTRFS, tak ZFS) je že z principu zvyšují write amplification factor,
tzn. jestli vám jde o to, abyste "neodfajcil rychlo disky(privela zapisov...", tak to také není nutně ten nejlepší nápad.
Za těchhle okolností budu mít na databázi daleko radši MDRAID (nebo HW RAID kartu) a slušná serverová U.2 / U.3 SSD s dobrou výdrží. Navíc nebudu muset nutně řešit jak spolu "bojuje" chytrý FS a vestavěné mechanismy v databázovém serveru..
Ušetřený čas pak můžu věnovat optimalizaci databáze, a vychytávání mechanismu pro zálohování. Připadaně pokud je to opravdu důležité, a je potřeba vysoká dostupnost, tak udělat DB cluster.
Jinak aby to nevyznělo tak, že en-bloc odsuzuji CoW FS. Vůbec ne a jsou spousty oblastí, kde to může přinést reálné benefity, rychlé snapshoty jsou super pro obecné file servery, kontejnery atp. Relativně cenově dostupná ZFS úložiště s JBOD a hromadou disků atp.
BTRFS zase rád používám jako systémový FS na rolling distribucích, protože se můžu snadno vracet a nabootovat ze staršího snapshotu, když se něco pokazí atp.
Ale u těch databází mi přijde, že pokud se vyloženě člověk nemusí přizpůsobit nějakému cízímu serveru, nebo systému, kde už je tohle dané (např. ZFS na FreeBSD), tak si akorát může přidělat starosti.
40 Odpovědí
22956 Zhlédnutí