Dotaz: RAID5 - mdadm vs btrfs

[Orange]

Stavm si takový malý domácí server, a úložný prostor bych chtěl řešit jako RAID5 ze čtyř disků. Nepište mi, že RAID není záloha, to vím. Budu tam mít multimédia a podobné věci, které je možné v nouzi oželet a která se nezálohují, ale přesto jsem ochotný dát čtvrtinu kapacity na to, když se podělá hardware tak abych o to hned nepřišel. Nevím ale jestli zvolit klasický mdadm nebo použít btrfs. Každé má z mého pohledu výhody i nevýhody. Mdadm je otestovaný a stabilní, ale na rozdíl od btrfs neochrání před silent corruption. Btrfs je ale pořád ještě ve vývoji, navíc nedávno se objevila závažná chyba právě u RAID5/6, nicméně už by měla být opravena. Takže co poradíte?

Odpovědi

[Heron]

btrfs raid5 zatím není v produkční kvalitě, takže i toto je potřeba vzít v potas. mdadm raid5 funguje.

Tohle spíš záleží na tom, zda využijete výhody, které btrfs nabízí (cow a z toho plynoucí snapshoty), pokud ano, můžete jej nasadit přímo na disky nebo i na mdadm pole, pokud ne, tak bych zvolil konvenční fs.

[pavlix]

Není RAID5 trochu hardcore? Pokud chci systém udržet v provozu a nechci aby mi data odešla „jen“ kvůli výpadku disku, tak přeci potřebuju mít v systému pořád jednu kopii navíc. Tedy i v situaci, kdy se jeden disk odporoučel, nahrazuju ho jiným a čekám na rebuild.

[Peter Golis]

Pravda. Raid 6 je lepší.

[Jendа]

Hraje se na pravděpodobnost, že za jeden den (pokud vyrazíš pro nový disk hned) to nezhebne. To je u všech RAIDů, jenom tady je ta pravděpodobnost odejití o něco vyšší (odhadem tak 1/365 pro MTBF tři roky a za předpokladu, že pravidelně děláš scrub pole, takže se ti nestane, že tam byl jeden disk už nějakou dobu nalomený a nezvládne rebuild).

Tak mě napadá, že btrfs nečte při rebuildu data lineárně (takže větší zátěž na disky kvůli seekování).

U RAID 6 se straší, že je pomalý při zápisu, a přijde mi, že je to pravda. Takže radši RAID 10.

V btrfs bohužel pořád narážím na podivné bugy, takže bych si na ještě méně odladěný RAID netroufl.

[pavlix]

Takže radši RAID 10.

Ten zase nezajišťuje stejnou úroveň redundance, takže asi záleží na tom, co chceš.

[Heron]

To si musí určit tazatel. Dobré (ale to je dobré vždy), mít další disk buď jako hotspare nebo alespoň na poličce vedle serveru. Ale raid5 se běžně používá a počítá se s tím, že během recovery nevypadne další disk. No a když náhodou vypadne, tak je tady záloha. Mohou vypadnou i dva disky v r6, nebo 1/2+1 disky v r10. Jen to jen o pravděpodobnosti.

[k3dAR]

prave ze je to o pravdepodobnosti, to ze pri vypadku disku v raid6 vypadnou dalsi 2 je mnohem mene pravdepodobne, nez ze pri vypadku 1 disku v raid5 vypadne pri rebuildu dalsi 1 ;)

[j]

RAID5 je naprosto vpohode, pokud ti vadi rebuild, tak se samozrejme pouzije spare, kterej na inteligentim radici nabehne (v 90% pripadu) driv, nez fyzicky vadnej disk klekne => dochazi jen k prosty kopii z disku na disk.

R6 se ti bude rebuildovat uplne stejne, jen mas posychrovanej vypadek dvou disku.

Kazdej normalmni system umi delat rebuild na pozadi, takze realne mas rekneme o +- 30% horsi vykon toho pole, ale to na provozu nepoznas skoro vubec.

... Samo, nad btrfs funguje raidovani trochu jinak nez na radici/sw raidu. Z hlediska pouzivani to ale vliv bude mit +- stejnej.

[k3dAR]

[...] R6 se ti bude rebuildovat uplne stejne, jen mas posychrovanej vypadek dvou disku. [...]

jenze o to "jen..dvou" prave ze jde ;)

[pavlix]

+1

[cronin]

Tak ja teda neviem: Pád koľko diskov v N-diskovom poli by podľa Teba malo pole prežiť?

[pavlix]

GOTO 2

[cronin]

Nestíham sledovať Tvoje uvažovanie. Najskôr namietaš, že redundancia jedného disku - raid5 - je málo. Bolo Ti odpovedané, "že raid 6". Potom namietaš, že aj redundancia dvoch diskov je málo. Chcem preto vedieť, aká redundancia je podľa Teba dostatočná. Podľa možnosti tak, aby to bolo technicky aj finančne zvládnuteľné.

[pavlix]

Potom namietaš, že aj redundancia dvoch diskov je málo.

Nikoliv.

[cronin]

Aha, už mi došlo. Chyba bola v mojom príjímači. Teda skôr interpreteri.

[pavlix]

:)

[pavlix]

Až na to, že jsem nepsal, že mi vadí rebuild, ale že mi vadí situace, kdy nemám žádnou redundanci. Ta situace je u RAID5 stav při běžné údržbě (výměně disku), zatímco u RAID6 při běžné údržbě redundance zůstává.

[j]

Tak u R10 ses na tom uplne stejne, kdyz ti umre druhej nespravnej disk, tak si prisel o pole. A presto se R6 nepouziva temer vubec nikde. Nejspis proto, ze se za normalnich okolnosti pouziva ten spare disk, kterej ho nahradi driv nez umre, takze se to chova velmi podobne jako R6. Zato je treba o rekneme 20% min disku(vetsi nez 6ti diskovy raidy se nedoporucuje delat v zadnym pripade). Coz je uz pri desitkach disku docela slusnej ranec $$$.

[k3dAR]

[...R5...] spare disk, kterej ho nahradi driv nez umre, takze se to chova velmi podobne jako R6 [...]

podobne neni stejne, kdyz spare mas i u raid6, pak uz to neni ani podobne...
stale platit ze raid6 vydrzi vypadek 2 disku, raid5 jen 1 disku... a rozdil mezi je "jen" to jestli pole vydrzi nebo zkolabuje ;)
demagog muze namitnout ze jestli 2 neni take malo, ale racionalne uvazujici chape ze 2 je 2x vice nez 1...

[Semo]

Mne pride, ze RAID5 + 1 spare pouziva rovnako vela diskov ako RAID6 bez spare. Ked uz ten disk mam, tak preco by som ho rovno uz nevyuzil, nez ho tam nechal len lezat. Tie 3W navyse uz prezijem, pokial mi ide o dostupnost dat.

[Max]

Provozuji mdadm RAID5 (3x2TB - shit disky, něco Green, něco Black, něco nevím co) a na tom btrfs. Teď budu rozšiřovat o další 2TB. Resp. jsem se pokusil několikrát rozšířit, ale vždy mi PC vytuhnul. Ale ničeho se neboj, mně vytuhnul kvůli tomu, že na desce mám jen 4xSATA, tak jsem sáhl pro SATA multiplikátoru z číny. Výsledek je takový, že po cca 2h reschapingu pole celý PC vytuhne, v logách jsou jen hlášky ohledně zamrzání a resetování toho SATA portu, kde mám multiplikátor.
Teď jsem si koupil řadič do PCIe, takže o víkendu snad úspěšně konečně provedu rozšíření pole.
Tím jsem jen chtěl říci, že to funguje a výpadky napájení / tvrdé zamrznutí apod. nejsou problém. Debian stretch.
Zdar Max
PS: jak bylo již řečeno, využívat RAID5 čistě v rámci btrfs není dobrý nápad, implementace není dokončená / odladěna

[j]

Mam btrfs R5 4x 6TB ... z hlediska pouziti (uloziste bordelu) me na tom vadi jedina vec - neumi to rict kolik je tam mista. Chapu sice ze se to dost blbe odhaduje se zapnutou kompresi a reflinkovanym obsahem, ale aspon minimalni hodnotu by to vracet mohlo.

[Max]

A nebo pokus jsi labužník a máš dost ram, tak nalaď ZFSonLinux.
Budeš pak moci využít Raid-Z(aka RAID5) / RAID-Z2(aka RAID6) / RAID-Z3 (aka RAID7) + snapshoty + checksummy dat a další věci.
Zdar Max

[Heron]

A nebo pokus jsi labužník a máš dost ram, tak nalaď ZFSonLinux.

Osobně bych raději doporučil rovnou FreeBSD. Prostě nemám nejlepší pocit nasazovat ZFS na Linux za situace, kdy:

• To není zcela licenčně kompatibilní a samotnému autorovi licence se to nelíbí.
• ZFS je na FreeBSD nativní.

[Max]

Tak samozřejmě, a ještě lepší to je na Solarisu (OpenIndiana), kde je to ještě nativnější a s více fcemi, jak na Freebsd.
Problém ovšem je v tom, že pokud to nechci čistě jen jako storage, ale chci tam mít i další věci, tak u FreeBSD si teď nejsem jistý, zda je pro něj dostupná taková sw výbava jako pro linux(což by stejně šlo vyřešit jailem) + nemá takový support hw jako linux. A pokud jde o Solaris/OpenIndiana, tak tam je podpora hw ještě užší.
VPSFree dokazuje, že to se ZFSonLinux jde i produkčně.

Každopádně už se těším, až bude u btrfs dostupné RAID5/6 (aka RAID-Z2 u ZFS, nebo RAID-DP u NetAppu), protože bez toho je použití na storage drahý (v RAIDu10 vždy může odejít 1+n disků, kde třeba i při 20 diskách v případě pádu nevhodných dvou je s polem ámen, což se u RAID6/RAID-DP/RAID-Z2 nestane + konkurence má write-penality docela dobře pořešeno).
Zdar Max

[dustin]

Jak je pořešená ta write penalty? Plánuju začít testovat ZFSonLinux pro přechod ze stávající spleti md raid10ů + XFS na jeden ZFS + inkrementální push na zálohy a zvažuju, jakou ochranu v ZFS zvolit. Co jsem koukal na benchmarky, tak to raidz bylo proti raid10 pořád dost pomalejší, hlavně recovery, které je u nových velkých disků stále zásadnější.

[Max]

Přesně jsem to nestudoval, ale bude to asi obdobné jako např. u NetAppu, nebo jako teď probublává také write cache do mdadm, ale zatím experimental. Pokud jde o skládání/recovery pole, tak je jasné, že to bude pomalejší než RAID10. Já jsem srab, já se u RAIDu 10 s větším počtem disků bojím toho, že mi můžou odejít oba disky v jednom mirroru a bude to v kelu. Proto na data, kterých si víc vážím, používám RAID-Z3, kapacitou jsem stále úplně jinde oproti RAID10 a výkonově mi to stačí a mohou mi odejít libovolné 3 disky a pořád to bude ok.
Zdar Max

[Max]

Ještě dodám, že na tomto :
12x 4TB WD RE4 SATA 7200ot. = RAID-Z3 mi trvá scrub 15h a 29min.
Jedná se o málo vytížené pole a v té době se tam snad ani na něj nijak moc nesahalo.
Vytížené pole 12x 4TB WD RE4 SATA 7200ot. = vdev mirror (RAID10)= scrub 50h 46min
Zdar Max

[dustin]

Díky za čísla. Je mi jasné, že čísla zatíženého a nezatíženého pole nelze porovnávat, ale ten scrub raid z3 na obyč SATA (používáme také) není špatný čas.

[Max]

Jinak server (copy-paste z dokumentace):

Supermicro
Board : X10DRW-iT (2x CPU, Intel® X540 Dual port 10GBase-T, 10x SATA3, IPMI, SUB3), Bios : 2.0 (17.12.2015)
Case : SuperChassis 847BE1C-R1K28WB, 36x (24 front + 12 rear) 3.5" hot-swap, Redundant 1280W Platinum Level (1+1)
2x Intel Xeon E5-2620 v3 @ 2.40GHz (6 core, 12 threads)
1x Areca 1883i (LSI3108), 2GiB (fw: 1.53 - 13.5.2016)
1x Areca SuperCap Flash Back Up Unity
4x 16GiB DDR4 2133MHz 2Rx4 (64GiB) - (Samsung M393A2G40DB0-CPB)
4x 32GiB DDR4 2133MHz 2Rx4 (64GiB) - (Samsung M393A4K40BB0-CPB)
13x 4TB WD RE4 (ZFS RAID 10)
12x 4TB WD RE4 (ZRAID3)

1x HP SC08e 6Gb 2-ports Ext PCIe SAS HBA = LSI SAS2008-IT (fw:20.00.07.00)
1x MSA P2000 G3 SAS SATA 3,5" (2x RAID6 - 2x 10TB = RAID60 20TB)

1x Intel X520-DA2 (Cabling Type - SFP+ Direct Attached Twin Axial Cabling up to 10m)

Left riser card : [RSC-R2UW-4E8]
Right riser card: [RSC-R1UW-E8R]
U této WIO desky fungují s jedním CPU jen sloty 3 a 4 na levé strany,
proto bylo nutné dokoupit další CPU a k němu další ram.

Teď ještě na budu přesouvat backup server pro Oracle databáze na tento storage do jailu, abych zrychlil kompresi dumpů a další věci a ty CPU se tak neflákaly.
Zdar Max

[Heron]

FreeBSD si teď nejsem jistý, zda je pro něj dostupná taková sw výbava jako pro linux

To neumím posoudit, zatím jsem v portech našel vše, co jsem potřeboval pro serverové nasazení.

VPSFree dokazuje, že to se ZFSonLinux jde i produkčně.

Jistě, to jsem nerozporoval, pro produkční nasazení je to ok, ale po stránce řekněme morální s tím mám trochu problém.

Každopádně už se těším, až bude u btrfs dostupné RAID5/6

No mě dost chybí podpora pro flash cache. Doporučení vývojářů btrfs používat prostě ssd na všechno (i na datovou storage) je jistě vtipné, ale cenově zatím trochu mimo. ZFS má SLOG (+ cache, ale tam je lepší mít dost ram) a to z těch obyč rotačních disků v našich testech udělalo úplně jinou kategorii (naschvál jsme testovali na starých green diskách + intel dc 36xx ssd a nestačili se divit, jakej to má výkon). Takže toto je pro mě důvod pro zfs, i z levných disků + ssd to udělá obstojný storage.

raid56 mi ani tak moc nechybí, stejně všechno stavím jako raid10 (v zfs potom jako mirror vdevy vkládané do zpoolu).

[Max]

Mno, já IOPS měřím akorát na produkčním Netappu, tam mám 24xSAS 10k v RAID-DP bez SSD cache a dostávám se až k 5000 IOPS. Odezvy storage skákají až k 4ms. Se serverama mám propojeno přes NFS4.1 (2x10Gbit LAG)
Ještě mám na NetAppu ssd pole, na tom teď běží pár db, to do toho nepočítám.
Původní záměr byl i použít část ssd pole jako cache pro SAS pole, ale když jsem zjistil, jak dementní to je (= nevratná operace), tak jsem do toho nešel.
ZFS mám nad FreeBSD (FreeNAS), tam jedu 4TB WD RE4 SATA, něco v RAID-Z2, něco v mirror vdevech (celkem asi 70TB storage). S výkonem jsem zatím spokojen.
Zdar Max

[Heron]

Tak my jsme stáli před volbou nového storage řešení. Single storage na ZFS a export NFS, nebo distribuované. Nakonec jsme zvolili CEPH, ten má vlastní SSD cache pro OSD. SSD má sloužit pro XFS journal cache. Parametry zatím zveřejňovat nebudu, ale bude tam několik desítek OSD. Do stovky, zatím nám to stačí v malém, později se budou přidávat další. Jedno SSD může sloužit pro několik OSD (dle dokumentace tak pro 5).

Měli jsme na stole několik komerčních řešení za ceny, za které si to hravě uděláme sami 3x, takže to jsme zamítli. Nehledě na praktiky komerčních firem v oboru, takže osobně bych byl proti libovolnému komerčnímu řešení.

[Max]

Ty máš tu výhodu, že jste "velký". My jsme relativně malý. Máme dvě lokality, jedno ostrou a jednu backup. Takže jsme potřebovali redundantní řešení. Kdybych měl volit nějaký distribuovaný storage systém, tak bych asi sáhl také po ceph, ale potřeboval bych v hlavní lokalitě aspoň 3 nody a to samé v záložní lokalitě. V lepším případě 4+4. To už je celkem dost železa. Teď mám akorát dva netappy. Oba mají všechno redundantní, až teda na to zkurvené napájení, to vymyslelo nějaký ucho. Co řadič, to jeden přívodní napájecí zdroj/kabel. Když tedy padne jedna napájecí větev, tak padne i jeden řadič a druhý online převezme jeho fci. A to se mi nelíbí.
Další důvod pro NetApp byla dobrá podpora NFS4.1 (to nemá FreeBSD ani OpenIndiana). Jako hypervisor mám ESXi 6 a tam je NFS4.1 také ok.
Zkoušel jsem poptávat Nexentu, ale když si jen za licence řekli přes milion, tak jsem je poslal do temných míst (prostě mnohem dražší, jak NetApp, nechápu co blbnou ...).
Zdar Max

[Heron]

aspoň 3 nody

No tohle je absolutní minimum, kde riskuješ, že při výpadku libovolného nodu ti nepojede nic. Za rozumné minimum se považuje 5 nodů.

To už je celkem dost železa.

Neříkej, že by to nebylo levnější, než ty netappy.

Když tedy padne jedna napájecí větev, tak padne i jeden řadič a druhý online převezme jeho fci.

Geniální řešení ... Přiznávám, že k posouzení stavu hw u nabízených komerčních řešení jsme se ani nedostali. Úplně mi stačilo jednání s HP, kde nebyli schopni dodat jedinou nabídku správně (tj. tak, aby to šlo z dodaných dílů vůbec poskládat).

Další důvod pro NetApp byla dobrá podpora NFS4.1 (to nemá FreeBSD ani OpenIndiana). Jako hypervisor mám ESXi 6 a tam je NFS4.1 také ok.

No my pravděpodobně (to ještě nevím), budeme do vmware strkat iscsi a nikoliv nfs. Protože ceph má takovou malou nepříjemnost a to pouze jeden metadata server (což nechápu, kdo to takto navrhoval), takže při jeho výpadku ti vypadne i ten exportovaný cephfs. Zatímco exportovaná bloková zařízení běží dál a můžeš si vypínat nody jak chceš (s přihlédnutím na redundanci).

Na NFS považuji za lepší variantu GlusterFS (který má ovšem tunu jiných nevýhod).

[Max]

No, přesnou cenu za ten NetApp sem nenapíšu, ale slušně podlezli konkurenci. A když jsem to počítal proti základním supermicro + diskama (že bych měl 1 + 1 a třeba drbd, nebo zfs send/receive), tak jsem se dostal sice na o něco menší částku, ale bez tak velké redundance, co NetApp nabízí + bych se musel spokojit s NFS3 a s né tak pěkným monitoringem/reportingem storage, který NetApp nabízí.
Dalším důvodem bylo pak zálohování, protože Veeam podporuje NetApp aj. storage řešení, takže lze snapshoty a mirroring na sekundární pole ovládat z Veeamu, ten si zase umí povídat s vmware, takže výsledkem jsou i konzistentní VM v snapshotech + zálohování pomocí snapshotů storage a né vmware, takže menší náchylnost na to, že se nějaký zprasená app při obnově posere (reálně se mi to ale nikdy nestalo, takže toto beru jen jako nice argument pro management, na druhou stranu, po výpadku v Naganu v tomto týdnu jsem zaslechl nadávat pár adminů na zbořený servery a obnovu ze zálohy).
Kdybych si měl poskládat něco podobného, co nabízí NetApp pro takto malé řešení, tak dám za hw víc, jak za NetApp + jeho licence.
Dokonce i s tím Veeamem jsem se dostali silně dolu. Celkově tedy máme NetApp+ESXi Standard + Veeam Ent Plus, vše komunikuje se vším, vše redundantní a výkon víc než slušný.
Pokud bychom byli velký, že by nebyl problém mít 5 nodů v jedné lokalitě a 5 v další, tak už bych asi s NetAppem nepočítal a provozoval něco jiného, hlavně distribuovaného přes více lokalit.
Osobně to vidím tak, že za 5 let, až toto bude out, tak možná už konečně přejdeme na KVM a nějaký distribuovaný storage.
Zdar Max

[Heron]

O Veeamu mi ani nemluv. Ta sračka ani neumí obnovit pořadí disků a když se ti to nelíbí, tak si to máš přeházet ručně.

Nechápu, jak takové věci vůbec mohou projít QA do produkce a ještě na to napíšou KB. Toto je další ze seznamu důvodů, proč prostě nechci mít serverovnu postavenou na komerčním softu. Jednak je to blackbox (takže když se něco pokazí, tak ani nevíš, jak se to pokazilo) a vůbec nemáš jistotu, co to dělá. Jako třeba nefunkční CBT, na což nám dodavatel doporučil koupit si licencni na novou verzi. (Tohle doporučení v tom KB naštěstí není.)

To už si mnohem raději napíšu vlastní skripty nad btrfs (nebo zfs) snapshoty a send / receive. Ano, nemá to nablýskané grafy a reporty pro blbečky (rozuměj: managery), ale na rozdíl od výše uvedených produktů to funguje a když se to rozbije, tak vím kde.

[j]

S tou srackou naprosto souhlasim, napr totalne rozmrdany M$ SQL (widle ve vmware). Ti kokoti si proste pres api zavolaj repliku databaze, a protoze jim nekde neco vytimeoutuje, tak to tak nechaj, takze se databaze neda pouzivat. Nebo to dostanou do stavu, kdy se neda indexovat, protoze sou dojebany tabulky. Neuveritelny.

O tom, ze velikost jejich "zaloh" je pri zmenach 20MB/den klidne 2GB/den ani nemluve.

Zkouseli sme lecos, ale vetsi srackomet se snad ani neda poridit.

[MP]

Jen otazka, proc jen NFS3 v pripade zakladniho SM+drbd/zfs?

[Max]

Protože ESXi podporuje jen NFS4.1, takže FreeBSD a Solaris jsou out. Pokud bych pro storage použil linux, tak údajně od RHEL7 je NFS 4.1 podporováno, ale zase nevím, jak moc je to stabilní.
Zdar Max

[citanus]

urcite umi i nfs3, jen je tam omezej feature set

[Max]

Tak jasně, že umí NFS3, narážel jsem spíš na to, že neumí NFS4, ale jen NFS4.1
A tím je spousta oss řešení vyoutovaná.
Zdar Max

[citanus]

promin, pozdej mi doslo ze si to myslel takhle.

OT kdyz uz jsme u vmware. doporucuji vyzkouset vsan. Nasazoval jsem to ted s nsx. Dokonce nam to vmware doporucil na management cluster. Uz to chrousta vic jak rok, vypadky disku i nodu probehli bez jakychkoliv potizi, vykon excelentni... jen ty licence, no ale to uz neni tak hrozny oproti nsx.

[Max]

Obojí znám, ty ceny licencí jsou ale strašný.
Zdar Max

[MP]

V cem je lepsi GlusterFS nez NFS krome vicenodoveho masteru? Resp. horsi? Ja ho zkousel (aneb, stavime tu storage) a pres libgfapi to jeste vykonove slo, ale mount pres fstab byl vykonostni propad jak do praveku. A databazi bych si na to zatim taky nedal...

[Heron]

NFS není lepší než GlusterFS, hovořil jsem o tom, že pokud někdo chce exportovat NFS, tak je (podle mě) lepší použít GlusterFS a exportovat NFS z něj (má interní nfs server) než používat ceph fs, který má single point of failure v podobě jednoho metadata serveru.

U Glusteru lze exportovat NFS na každém nodu (všechny nody jsou symetrické, na rozdíl od CEPHU) a mělo byt jít mezi nimi libovolně přepínat (NFS je nestavové). To jsem ale ještě netestoval.

CEPH začal jako S3 like storage, potom tam má ta bloková zařízení a ceph fs je nejmladší komponenta a vyžaduje metadata server, který aktuálně je doporučované mít pouze jednou. Takže CEPH je aktuálně skvělý pro export blokového zařízení, to žádný single point nemá, ale méně skvělý pro export toho interního ceph fs.

[MP]

Jo takhle. Po tech testech, co jsem tu mel, jsem chtel jit do Cephu jako blokove storage, ale s 2 nody jsem rekl sefovi, ze ne. Takze jsem testoval i samotny gluster a vykonove dobry, ale jak doslo na rw operace, tak dost zpomalil, stopku tomu dalo nepouzitelnost fuse. A pouzit nfs v glusteru jsem nejak zapomel ozkouset, ale stejne glusterfs neni moc idealni na databaze, takze... Takze nakonec jsem skoncil u nechtene varianty drbd+nfs ha, ale do budoucna urcite ceph v planu zustava, idealne, kdyby dokazali vyresit i cephfs problem s metadatovym spof. Sice bych mohl ceph nasadit na hypervizory, ale to bych zase ubral vyrazny vykon z tech VM a jeste k tomu bych mel maximalne sas 6g, takze dalsi zpomaleni. Takova blba prechodova doba s omezenymi financemi, klasika.

[kamen]

Neumim odpovedet na konkretni dotaz, ale mohu se podelit o zkusenosti s BTRFS.

Je to fantasticka vec svyma vlastnostma, ale..

- nekolikrat jsem prisel o cely FS bez priciny a bez moznosti zjistit co se vlastne stalo. Neexistuji zadne tooly, ktere by pripadny fragmenty dat z poskozenyho FS vyextrahovali

- kdyz jsem ho pouzil jako FS pro praci, tak v porovnani s ext4 to byla super bida. vse o 25% pomalejsi (mereno vlastnimi testy)

- kdyz se FS zaplnil, casto na dlouhe chvile zatuhnul a tim vsechny procesy co spolehali na ten FS.

- obecne s poctem snapshotu a probehnuvsich diskovych operacich cely FS zpomaluje.

=> za mne je dnes BTRFS vhodny _BOHUZEL_ snad jen na inkrementalni zalohovani s pravidelnou kontrolou stavu zaloh. protoze jinak je to fantazie co se deklarovanych vlastnosti tyce.

Sam mam na vase pozadavky RAID1 (ted dva 3TB disky + 64GB SSD pro system) a kdyz to chci mit rychly zapis, tak RAID0 slozeny ze dvou RAID1.

[kamen]

jo ten raid1 mam pres mdraid.

[MP]

A zapnul jste si u ext4 pro to porovnani plny zurnal, nebo naopak vypnul COW na btrfs? Jinak jste porovnaval neporovnatelne. Taktez zaplnenim FS odstrelite jakkykoliv system.

Takze dva body z tech 4 nejsou chya btrfs. Ale ten bod 1] je samozrejme uz problematictejsi, jenomze tahani fragmentu dat je casove narocnejsi operace nez obnova ze zalohy.

[Josef Kufner]

Taktez zaplnenim FS odstrelite jakkykoliv system.

Je obrovský rozdíl mezi tím, když plný FS okamžitě vrátí chybu, že je plný, a tím, když deset minut hledá volné místo a pak teprve řekne, že nenašel.

[pavlix]

Taktez zaplnenim FS odstrelite jakkykoliv system.

Nestalo se.

[kamen]

COW na btrfs je featura co se mi libi a chci ji.

Proto jsem si chtel nechat zapnutou. Kdyby ji nemel, tak prec nezustat u Ext4, ktery ji take nema?

Plny zurnal u Ext4 jsem snad ani nikdy nepotreboval. Nikdy jsem neprisel od data a to dokonce i kdyz se mi diky spatnemu kabelu 'sam' odpojoval USB disk.

Proto jsem na nejaky plny zurnal ani nepomyslel. Je mozne u BTRFS zapnout neco co mi zaruci, ze se mi FS neposkodi (i za cenu snizeni vykonu?).

[Heron]

Je mozne u BTRFS zapnout neco co mi zaruci, ze se mi FS neposkodi (i za cenu snizeni vykonu?).

Příčetný admin.

Těžko se reaguje bez konkrétních chybových hlášení a popisů stavů.

- kdyz jsem ho pouzil jako FS pro praci, tak v porovnani s ext4 to byla super bida. vse o 25% pomalejsi (mereno vlastnimi testy)

25% je super bída ve srovnání s tím, co ten FS nabízí za funkce? Já mohu posloužit testy, kdy jen ten FS ještě pomalejší (obecně to má pomalý fsync, což se ale ví), ale přes to jej používám, protože možnost snapshotů a reflink kopií je pro mě větším přínosem a uspoří mi víc času, než spálí ty pomalé operace.

- kdyz se FS zaplnil, casto na dlouhe chvile zatuhnul a tim vsechny procesy co spolehali na ten FS.

Nezaplňovat FS. Jako vážně, když jsem přicházel do světa linuxu, byla dobrá rada zaplňovat max. do 80%. A to tehdy (1998) bylo na scéně jen ext2 (plus nějaké obskurní pokusy). Stále to považuju za dobrou radu a žádný fs bych nenechal dojít do stavu 100% zaplnění.

- obecne s poctem snapshotu a probehnuvsich diskovych operacich cely FS zpomaluje.

Toho jsem si nevšiml, snapshotů mám obecně tisíce. Jediný "problém", který nastane je úklid (btrfs-cleaner) po odstranění několika desítek snapshotů současně - to je potom fs hůře dostupné, ale to se dá řešit tak, že se ty snapshoty budou mazat postupně v čase. (Nehledě na to, že na normálním FS bych tam ty adresáře ani mít tolikrát nemohl, protože by se to tam nevešlo, a nebo pokud by to byly skutečné kopie na nějakém celkově obrovském fs, tak by to trvalo nejšpíš stejně dlouho - ty záznamy se v těch strukturách fs stejně tak jako tak změnit musí).

[kamen]

Nezaplňovat FS. ?

S ext4 se mi bezne stava ze ho zaplnim az po strop a nestalo se mi ze by mi zatuhnul system.

Abych to upresnil: Pokud jsem rekl zaplnoval, mel jsem na mysli FS, ktery nebylpripojeny jako / nebo cast stromu kde jsou systemove programy/knihovny/zdroje (/usr*, /lib*, /etc* atp.). Data na ktere se ty procesy spolehali byli data se kterymi pracovali (obrazky, hudba, gitlab data, nextcloud data, atp.).

Muj prispevek nemel byt konfrontacni, jen jsem chte dat zkusenost. V naslednych postech by mne fakt zajimalo, jak spravne pouzivat BTRFS, aby mi dobre spolehlive a predvidatelne slouzil.

Rad bych poskytnul konkretni hlaseni, dokonce jsem si to nekam i ulozil, ale bohuzel to uz nemuzu najit.

[Heron]

S ext4 se mi bezne stava ze ho zaplnim az po strop a nestalo se mi ze by mi zatuhnul system.

Ok, rozumím, ale stejně bych to nedělal. Už jen proto, že nalézt volné bloky je pro ten fs čím dál větší problém a ty bloky už rozhodně nebudou v souvislých oblastech. Takže se značně zvyšuje fragmentace souborů. Což je věc, která se na ext4 blbě řeší (ne že by to vůbec nešlo, ale proč si přidávat starosti).

Muj prispevek nemel byt konfrontacni, jen jsem chte dat zkusenost. V naslednych postech by mne fakt zajimalo, jak spravne pouzivat BTRFS, aby mi dobre spolehlive a predvidatelne slouzil.

Já mám nejstarší BTRFS někdy z roku 2010, už přežilo výměnu několika disků (celkem postupně 9). Chvílemi tam bylo i desítky tisíc snapshotů, teď jsem se "uklidnil" na tisíce. Pravdou ale je, že zaplnění nikdy nepřerostlo 80% (po pravdě, aktuálně 83%, ale mám tam data, o kterých vím, že se brzo zbavím), normální zaplnění je tak 70%.

Aktuálně to používám (kromě home adresářů a adresářů s projekty) hlavně na běh kontejnerů (nspawn). Tam se hodí snapshoty (před update, jako záloha - v kombinaci se send na jiný server, před náročnější akcí apod.)

O data jsem s BTRFS nikdy nepřišel, rozpadl se mi jen jednou, když zahaproval řadič a polovina disků náhle zmizela. I potom šel ten fs namountovat, data šla překopírovat a btrfs do logu vesele psal corruption detected and repaired (nebo tak něco). I tak jsem ta data obnovil raději ze zálohy.

[MP]

Jak se divate na btrfs jako fs ve VM? Resim ted, ze na ext4 po ztrate sitoveho storage doslo k neopravitelnemu poskozeni FreeIPA databazi, tak zvazuji jiny fs. Takovy PSQL se obnovil bez problemu, ale Berkeley db ne.

[Heron]

Jak se divate na btrfs jako fs ve VM?

Komplikovaně. Záleží na konkrétním provozu. U nás jsem navrhoval použití BTRFS ve vm z důvodů snadného natahovaní a zmenšování (kdykoliv lze přidat další disk a kdykoliv lze disk zase odebrat), takže na rozdíl od ostatních fs by bylo možné vmko za běhu zbavit disků, které už nejsou potřeba. Tohle třeba s ext4 bez výpadku nelze udělat a třeba xfs nenabízí shrink vůbec.

Jenže postupně tento důvod nějak ustal, protože thin provisioning "prostě funguje", takže disk navíc ve vmku nehraje takovou roli.

Resim ted, ze na ext4 po ztrate sitoveho storage

Jakoze VMko přišlo (na chvíli) o disky? Tomu, obávám se, žádný fs odolný není.

Takovy PSQL se obnovil bez problemu, ale Berkeley db ne.

V tom případě udělat revizi zálohovacího řešení. FreeIPA neznám, možná nabízí nějakou formu replikace, ovšem v každém případě je nutné mít řádnou zálohu.

[MP]

No, tu replikaci jsem taky zkousel. Vtip byl v tom, ze replikovany server byl na stejnem ulozisti, takze to schytal taky. Nestastne...Tak resitelne to je, prinejhorsim to pojede i na lokalnich discich, nebo bude cast vm na btrfs, cast na ext4, atd., ale je docela blbe, kdyz domenova infrastruktura umre proto, ze nema ani dns. Ono obnovovat celou domenu je vetsi maso nez rucne synchronizovat usery mezi XX virtualy.

No, myslel jsem, ze btrfs pouzivas i ve virtualech, takhle vaham, zda ho tam dat. Zkusil jsem "utrhnout" sitovy backend z cerstve freeipa na btrfs a tentokrat to "prezilo". Moc moznosti, tezky vyber...

[Aleš Kapica]

Já už měl totálně zaplněný Btrfs několikrát - v zásadě se nic neděje, ovšem ten kdo neví jak tento FS funguje bývá v takové situaci vyděšený z toho, že pouhým smazáním dat místo uvolnit nelze – tedy pokud není k dispozici ani tolik místa, kolik zabírá ten odstraňovaný soubor. Přesto. I pro takovou situaci existuje řešení. Příkaz truncate --size=0 /cesta/k/souboru_na_btrfs smrskne jeho velikost na 0 bajtů, a pak už jde smazat bez problémů.

[kamen]

25% je super bída ve srovnání s tím, co ten FS nabízí za funkce? Já mohu posloužit testy, kdy jen ten FS ještě pomalejší (obecně to má pomalý fsync, což se ale ví), ale přes to jej používám, protože možnost snapshotů a reflink kopií je pro mě větším přínosem a uspoří mi víc času, než spálí ty pomalé operace.

No proto jsem psal kontext pouziti. Pokud s nim chci aktivne pracovat, musim se s tim smirit a nebo to nepouzivat. Ja si zvolil nepouzivat, ale na inkrementalni zalohy mi 25% horsi vykon nevadil. Jen pokud bych se na neho mohl opravdu spolehnout. Viz dalsi zkusenosti.

[Kate]

Nepřispívají snapshoty k fragmentaci dat a pomalejšímu seeku u plotnových disků? Osobně to v roce 2017 fakt neřeším, protože systém kde na tom záleží mám na SSD a u dat je mi rychlost celkem putna :)

[Heron]

Ano, ale btrfs by měl dělat autodefrag i s ohledem na snapshoty. Ale pochopitelně ne vždy (čistě z povahy věci), to lze čistě vyřešit.

Jinak u btrfs s tím problém nemám, ale u zfs je to už cítit :-/

NAME    SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
zroot  5.44T  4.66T   792G         -    29%    85%  1.00x  ONLINE  -

[Max]

Amatére :D, musíš víc plnit, jinak budeš mít u fragmentace moc malé hodnoty :).

NAME           SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
datastore-e1  18.1T  16.6T  1.56T         -    50%    91%  1.00x  ONLINE  /mnt
datastore1    21.8T  17.4T  4.38T         -    49%    79%  1.00x  ONLINE  /mnt
datastore2    43.5T  40.6T  2.86T         -    41%    93%  1.00x  ONLINE  /mnt

Zdar Max
PS: čekám na LOT7, pak budu mít rezervy dostatečné ...

[panCHrz]

NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
data  1.67T  1.61T  65.2G         -    57%    96%  1.00x  ONLINE  -
sys   9.75G  6.06G  3.69G         -    50%    62%  1.00x  ONLINE  -

[Heron]

Aha, no já dával příklad z domu. Tohle doufám nemáš doma, to už bych se fakt cítil méněcenný.

[panCHrz]

Jeden virtuálek ve firmě. Tečou na něj geografické zálohy od zákazníka. Volné místo vydrží cca 1-2 měsíce. Když dojde, přidám 50GB a jede se dál....

[Heron]

Reagoval jsem na Maxe, taky bych chtěl mít na hraní 15, 21 a 43TB datastory. Ale asi to má v jobu. Teda doufám.

[Max]

Doma mám kapacitně skoro to samé, co ty. mdadm raid5 4x2TB a nad tím btrfs
Zdar Max

[kamen]

Myslel jsem si ze snapshoty jsou jen nove pohledy na stav toho FS. Kdezto u mazani prave dojde k fragmentaci, kdy se smazany soubor stejne neprepise nez dojde misto resp. pocet volnych bloku. Snapshot jen zabrani smazani souboru, pokud na neho nekdo ukazuje.

Jinak mazani na BTRFS je sranda a clovek nikdy nevi kolik a kdy se mu posmazani uvolni mista , ale to chapu a s tim problem nemam.

[Aleš Kapica]

Aktivuj si počítání kvót a budeš to vědět přesně.

Mimochodem – u Btrfs lze dosáhnout uvolnění dalšího místa rekomprimací extentů. Viz.

[Heron]

Aktivuj si počítání kvót a budeš to vědět přesně.

Jo, a taky si počká. Měl jsem zapnuté kvóty (protože s tím umí spolupracovat machinectl a u kontejneru zobrazuje velikost), ale potom bylo mazání snapshotu o dost pomalejší (nemyslím v userspace, to vždy proběhne hned, ale potom cleaner běžel o poznání déle). Po vypnutí opět ok. Znát přesnou velikost subvolume zase tak nutně nepotřebuju.

[Aleš Kapica]

Co je mazání snapshotů proti věčnosti..

[Heron]

Myslel jsem si ze snapshoty jsou jen nove pohledy na stav toho FS

Ovšem je důležité vědět, jak takový pohled na stav fs vznikne.

FS ukládá data souborů do bloků na disku. Tradiční fs to dělaly tak, že při přepisu obsahu souborů prostě rovnou přepsal ty bloky. Toto řešení je jednoduché, přímočaré a velmi rychlé. Jenže v případě výpadku (třeba napájení) došlo k poškození dat toho naposledy zapisovaného souboru. Journal (typicky) řeší pouze metadata, takže po fsck je fs "v pořádku", ale data mohou být poškozená (zápis souboru prostě nedoběhl).

COW toto řeší trochu jinak. Soubor má data opět v blocích. Ale každý blok, pokud se má přepsat, tak se "zkopíruje" na nové umístění a teprve tam se zapíšou data. Až je tohle hotové, atomicky se přehodí ukazatel a soubor má náhle jiné bloky s novými daty.

Teoreticky tak nemůže dojít k poškození souboru, protože soubor je po výpadku buď ve stavu před výpadkem (prostě nedošlo k přehození ukazatelů), nebo po zápisu (vše proběhlo ok).

No a když už má FS tohle, tak je poměrně jednoduché udělat snapshot souboru (reflink). Prostě se udělá "kopie" seznamu bloků. Takže snapshot ukazuje na staré bloky a soubor ukazuje na nové bloky.

Těchto reflinků tam může být "neomezený počet", prostě každý z nich ukazuje na své bloky, přičemž většina z nich pravděpodobně bude sdílena. Tedy tato kopie šetří místo.

Problém je samozřejmě v tom, že ty nové bloky už čistě z principu nemohou být na stejném místě jako ty původní, tedy automaticky dochází ke fragmentaci - disk musí seekovat mezi různými bloky a není možné, aby každý reflink (což je prostě z hlediska user space normální samostatný soubor, není to ani hardlink ani softlink) byl uložen souvisle na disku. COW tedy automaticky vede k větší fragmentaci. Proto se také doporučuje používat SSD.

Jinak mazani na BTRFS je sranda a clovek nikdy nevi kolik a kdy se mu posmazani uvolni mista , ale to chapu a s tim problem nemam.

Ano, tohle je z důvodu viz výše. Pokud smažete soubor s reflinky (snapshoty), tak není jasné, kolik bloků bude skutečně možno uvolnit - což jsou pouze ty, na které už nikdo další neodkazuje.

[pletiplot]

Naprosto klíčové je mít dohled a vědět, že disk vypadl. Hodně uživatelů domácích serverů se spoléhá na to, že mají RAID, tak se jim nemůže nic stát, odejde disk, ale nijak se to neprojeví, pak odejde druhý a je to. Když vypadne disk, je potřeba hned měnit a resyncovat, jednak degradované pole má znatelně horší performance, jednak samozřejmě čekáním se zvyšuje pravděpodobnost, že selže další. Zpravidla je nějaký otestovaný disk už připravený v šuplíku, ale samozřejmě pokud máte 4 disky a máte disk navíc, tak už to stojí znatelně peněz, pokud jich máte 300, je to dobrá investice. Disk zřídka selže tak, že není čitelný. Pokud selže disk A, dáme místo něj disk B a pustíme resync. Pokud během resyncu selže disk C, dá se situace zachránit tak, že zrušíme resync A->B, stopneme pole, disk C zkopírujeme na B (dd s ignorováním IO chyb), sestavíme pole znovu s diskem B, C vyměníme za D a dokončíme resync A->D. Pár souborů se poškodí, ale to je prostě risk. Doporučuje se sledovat stav disků pomocí smartd a proaktivně vyměnovat disky, které mají špatné hodnoty.