Dotaz: Jaký FS použít na home storage - Btrfs / ZFS / ?

[VSi]

Zvažuji, jaký FS použít na serveru, který poskytuje přes Sambu home adresáře pro cca 300 PC s Windows (vč. cestovních profilů) + maildiry pro cca 100 uživatelů.

Aktuální stav: storage server - XFS na HW RAID50 z 8 ks 146GB SAS 10k disků; cca 600GB dat a 3M souborů; zálohy pomocí rsync na server s MDRAID 6 z 6 ks 2TB SATA disků. Pro zálohování se v noci vytvoří LVM snapshot na storage serveru, historie záloh se drží pomocí rsync --link-dest.

Celé to funguje poměrně dobře, i když zálohování trvá už dost dlouho, a mazání starých záloh vytvořených přes --link-dest trvá taky hodně dlouho. Na tom XFS se pro Windows atributy souborů používají xattr, ale pokud při rsync povolím jejich přenos, trvá to celé třikrát tak dlouho, což už není akceptovatelné.

Výkon aktuálního storage je na hraně. Stává se, že se na Windows workstationy loguje třeba 200 uživatelů v rozmezí pár minut, a pak načítání cestovních profilů už dost zadrhává.

Mám teď k dispozici nový HW, kterým bych to chtěl nahradit, a udělat celkově lépe:

- Storage: 6 x 600G SAS 10k, controller Dell H710; šasi na 24 disků, pro zlepšení výkonu je možné přidat nějaké HDD nebo SSD

- Backup: 6 x 4TB SAS 7k2, controller Dell H730+

Ideálně bych chtěl dojít k zálohování přes send/receive mechanismus jak nabízí ZFS a Btrfs. Podmínka jsou funkční kvóty a POSIX ACL. Export snapshotů přes Sambu je určitě plus.

Storage je poměrně kritický systém, výpadky z důvodu nestability FS, nebo dokonce zbořený FS, bych viděl hodně nerad. Asynchronní replikace přes send/receive např. každou půlhodinu by řešila i dostupnost při havárii HW. V aktuálním setupu můžu v nejhorším přijít o celý den. Distro Ubuntu nebo Debian.

Jak byste to řešili?

Btrfs bych nasadil na HW RAID6. Pro ZFS asi přepnout řadiče do JBOD režimu a vypnout writeback cache, do storage serveru přidat nějaká SSD pro ZIL a L2ARC.

U Btrfs si nejsem jistý stabilitou. Sice bych se vyhnul asi nejproblematičtější části - Brtfs RAID, ale lze už se na to spolehnout? Říkám si, že když to používá SLES jako default, tak asi ano. Jaký se dá očekávat výkon, ve srovnání s XFS? Plánuju si to zkusit naměřit, ten HW je k dispozici pro testy, ale zajímají mě zkušenosti z provozu.

Jak u Btrfs řešit rozšiřování prostoru? Dát pod něj ještě LVM, nebo si vystačím s integrovaným multidisk mechanismem, pokud bych pod něj přidával další logical volume z HW RAIDu?

Nebo použít radši ZFS? Zatím s ním nemám žádné zkušenosti.

Odpovědi

[Max]

To je stejné jako se ptát na to, jakou distribuci nainstalovat.
Před rokem vyšlo celkem pěkné srovnání obou FS tady na abc : Btrfs vs ZFS – srovnání pro a proti
Jinak samba u obou FS podporuje export snapshotu jako shadow copy pro win klienty.
Výkon bude při zápisu horší, než u XFS, protože COW. U ZFS můžeš zvednou ssd pro zlog apod., u btrfs takové možnosti tuningu nejsou na takové úrovni.
JBOD je sloučení disků do jedné velké kapacity. Asi možná můžeš vytvořit co disk, to jeden jbod, nebo co disk, to RAID0, ale to pořád pro ZFS není tak pěkné, jako použití hloupého HBA řadiče, u kterého nebývá ani problém se SMARTem, což u RAID řadičů bývá.
Zdar Max

[VSi]

Díky. Co se týká JBOD, tak jsem se ne úplně přesně vyjádřil - alespoň ten Dell H730 podporuje "non-RAID mode (pass-through)", ale ten mám teď úplně nový a ještě jsem ho nezapnul, tak nevím, jak se to přesně chová. U staršího Dell H710 myslím, že nic takového není. Dělat RAID0 pro každý disk se mi taky moc nelíbí, ale to by člověk musel kupovat už rozhodnutý, že tam dá ZFS. Jinak jsem s HW RAIDy na Dell a HP serverech nikdy problém neměl, zkušenost z posledních cca 10 let a 20 strojů.

Na ZFS (resp. ZoL) i Btrfs jsem četl i z posledních roků poměrně odrazující zkušenosti. O bezproblémových nasazeních se toho člověk tolik nedočte. S volbou distribuce bych to úplně nesrovnával

Z výkonnostního pohledu mě zajímá asi víc čtení, než zápis. Stejně ale nezbyde, než to otestovat na vlastními daty.

[/dev/win]

ZFS jedine nad FreeBSD alebo Solarisom

[cronin]

Vyzerá to, že to máš zabehnuté, funkčné, použiteľné a stabilné; si si istý, že to chceš radikálne meniť? Je isté, kde je vlastne úzke miesto? CPU? Sieť? Čo tak použiť SSD disky? Diskusie na tému ZFS vs. BTRFS vs. zvyšok sveta so záujmom už určitý čas sledujem a popravde som veľmi rád, že zatiaľ nemusím riešiť multi-terabyte storage inak ako cez Amazon EFS/S3.

[VSi]

Aktuálně je menší problém provozní výkon, v situaci kdy se přihlašují uživatelé se ze serveru kopírují cestovní profily (pár desítek MB per user, hodně malých souborů) třeba pro 100-200 lidí téměř paralelně. Síť a CPU v tu chvíli nejsou problém, spíš IOPS. To se dá zlepšit přidáním více disků do pole nebo přechodem na SSD.

Větší problém je zálohování, objem dat roste a teď trvá přes rsync třeba 6 hodin, pokud zapnu i přenos xattr, tak přes 15 hodin.

Varianta zachování aktuální konfigurace je taky možná, provozní problém s tím nikdy nebyl, tak při konzervativním přístupu - proč to měnit... ale ty snapshoty a send/receive by se fakt hodily.

[Max]

Tak rozhodně tím člověk získá hodně. Snapshoty berou minimum místa a ta historie dat je k nezaplacení. Zachrání to třeba situace, kdy uživatel si během dne omylem přepíše soubor a potřebuje nejaktuálnější verzi. Nebo si naopak uživatel na něco vzpomene po době, kdy už nejsou zálohy. Já už bych bez snapshotů nedal ani ránu. Buď používáme Windows Server s VSS, nebo v lokalitách s málo uživateli a bez nutnosti serveru Synology, aktuálně ty verze, kde je podporováno btrfs.
QNAPy jedou ZFS, takže tam jsou taktéž snapshoty.
Zdar Max

[Ladislav]

Zaujimalo by ma napr. ak by som nasadil btrfs na moj 3TB disk na domacom servery ako funguju snapshoty ? Robia sa automaticky ? Ak by som chcel robit snapshoty nad cryptsetupom celeho disku (/boot + root particia velka) dalo by sa ? Dakujem

[Sten]

Snapshoty se nedělají automaticky, ale jsou aplikace, které to zařídí (třeba Snapper nebo apt-btrfs-snapshot).

Snapshoty fungují jen nad jedním Btrfs. U cryptsetupu, kde je oddělený nešifrovaný /boot, tak nemůže být jeden snapshot pro /boot i /, ale automatické aplikace mohou dělat snapshoty na obojím ve stejnou chvíli (pokud je obojí Btrfs). /boot ale není potřeba snapshotovat, v nejhorším se udělá rollback / z LiveCD a /boot z něj přegeneruje.

[lertimir]

Velmi kvalitně má snaphosty zpracované opensuse. Snapshoty provádí jednak pravidelně a jednak automaticky před jakoukoliv aktualizací. A tyto snapshoty má zpracované do menu grubu, Je pak velmi triviální přejít do zpětného snapshotu pouhým výběrem menu z grubu. Také jejich volba rozdělení btrfs volume na subvolume, které nepodléhají snapshotům, protože ubsahují data, která by nebylo záhodno ztratit při rollback, je zajímavá. Myslím, že má cenu, si opensuse nainstalovat třeba do virutálu a probrat se možnostmi.

Cryptsetup se snapshoty neinteraguje. Díky CoW vlastnostem btrfs, jsou snapshoty vlastně jen informace při dalším zapisování, že bloky s původním obsahem se nebudou uvolňovat po přepisu, protože CoW stejně napíše obash na jiné místo. A ani problém by být nemusel pro nějakou konzistentní recovery/rollback, protože rollback by se provedl čistě na úrovni FS a pro initramfs informace by na úrovni filesystému byla stále stejná, kde co má brát, to že by to fakticky byl rollbak ze snapshotu by už nebylo po jeho provedení poznat.

[Josef Kufner]

Na podzim jsem doma přešel od zálohování pomocí rsync --link-dest na zálohovaní pomocí prostého rsync --in-place a BTRFS snapshoty na cílovém disku. Send/receive snapshotu namísto rsync je asi rozumné vylepšení, ale nemám všude BTRFS. Zatím jsem také neřešil mazání starých snapshotů.

Je to tedy v úplně jiném měřítku, než máš ty, ale funguje to stejně dobře. Myslím, že přechod byl bezproblémový a funguje to dostatečně blbuvzdorně, aby se na to dalo spolehnout.

Jediné co, tak budeš muset pořešit snapshotování a sledování velikosti snapshotu. Drobná a naprosto logická nepříjemnost je, že když máš subvolume nad kterým právě doběhl rsync, tak je vidět velikost snapshotu, tedy kolik dat přibylo zálohou. Ale jakmile uděláš snapshot po dokončení zálohování, tak na stejný stav ukazují dva subvolume (subvolume a snapshot) a tudíž by se smazáním neuvolnilo žádné místo a informace o velikosti se tím ztratí. Já to řeším tak, že si tu velikost poznamenám do reportu o doběhnutém zálohování těsně před vytvořením snapshotu. Pokud použiješ send/receive, tak toto odpadá.

[Josef Kufner]

A nechceš dát cestovní profily na SSD? Případně celou provozní část dát na SSD a na rotačních nechat jen zálohy?

600GB není nijak moc dat. Nějaký obyčejný 1TB SSD disk stojí jen kolem 8 kKč a výkonem je úplně někde jinde než 10kRPM disky.

[R]

Nejake obycajne SSD vydrzi kolko v takejto prevadzke?

[dustin]

Máme několik Intel SC3500 v provozu několik let na dost zatížené databázi a všechny mají dle smartu stav (Media_Wearout_Indicator) stále > 90%. Uznávám není to základní SSD, ale 800GB DC S3510 stojí 11k s DPH, zatímco obyč. SSD 1TB vyjde na 7.5k. To mi už nepřijde takový rozdíl.

[VSi]

600 GB je tam teď, uživatelé už si začínají stěžovat, že nastavené kvóty jsou málo... plus rezerva na pár let růstu, tak to chce minimálně tak 1.5T čisté kapacity. Na takovouhle aplikaci nebudu dávat "obyčejný 1TB SSD", ale alespoň něco ekvivalentního Intel DC S3710 - takový 400GB od Dellu mě dneska stojí cca 10kKč, takže třeba 4ks do R5 nebo spíš 6 ks do R6, to je celkem OK. Výkon takhle umím vyřešit, ale na otázce jaký FS použít to nic nemění.

[lertimir]

Pokud by tam bylo SSD tak pro mne jediný FS, který má vědomí, že pod ním je SSD je btrfs. Tak bych volil ten.

[VSi]

To vědomí spočívá v čem? TRIM, nebo ještě něco navíc? V případě Btrfs bych použil HW RAID6, tak je otázka, nakolik by se to uplatnilo.

[Sten]

TRIM a COW. Většina SSD rotuje bloky ve skupinách, COW změnou pozice sektoru na disku vyrovnává zatížení všech bloků, i když se přepisuje pořád jeden blok.

(Tuhle vlastnost tedy nemá jen Btrfs, ale i ZFS a obecně všechny COW filesystémy.)

[Sten]

* vyrovnává zatížení všech skupin

[Josef Kufner]

To vyrovnávání zatížení bloků dělají SSD disky samy tím, že logické bloky předávané operačnímu systému neodpovídají 1:1 fyzickým blokům. Jestli se zapíše do téhož bloku, nebo jinam, je celkem jedno. COW pomůže spíš efektivnějším trimem a tím, že se nemusí čekat na kopírování ostatních bloků v rámci jedné skupiny.

[VSi]

A poznám nějak, jestli to funguje přes ten HW RAID, když si to zkusím nainstalovat?

[Sten]

Pokud tam má být šestidiskový RAID6 a ten server má alespoň 4 GiB RAM, tak bych šel do ZFS. Debian Stretch má v backportech ZoL 0.7, takže stabilní a výkonné je. ZFS navíc podporuje SSD/NVMe cache (čtecí L2ARC a zapisovací ZIL), kdyby byl problém se špičkovým výkonem (třeba to kopírování profilů), tak se to dá tímhle vyhlazovat.

[lertimir]

Já ti nevím, ale např. FreeNAS tvrdí 1GB operační paměti na 1TB disku. Takže ve 4GB to se moc neprovede.

[Sten]

1 GB na 1 TB je potřeba pro deduplikaci, a to nad rámec těch 2-4 GB, co to chce pro samotný běh. Deduplikace ale není standardně zapnutá a, pokud to místo opravdu nutně nepotřebujete, bych ji ani moc nedoporučoval.

[Max]

Ne, 1GiB/1TiB je doporučované minimum, v případě deduplikace je doporučované minimum 5GiB/1TiB
K tomu je pak potřeba ještě připočítat režie systému.
Zdar Max

[Sten]

ZoL oficiálně doporučuje 8+ GB bez ohledu na velikost pole s tím, že doporučované minimum je 2 GB.

S jedním GB RAM zvládne ZFS klidně exabajt dat. 1 GB na 1 TB se týká jen deduplikace, a i tam je to hrubý odhad než nějaké pravidlo. (Zdroj: vývojář ZFS Richard Yao)

[Max]

Kde tam máš v tom odkazu napsáno, že je to bez ohledu na velikost pole?
O FreeNASu se říká, že má jeden z nejvytuněnějších ZFS na BSD, a ti mají uvedeno minimum 1GiB/1TiB a v případě deduplikace 5GiB/1TiB.
Je to postarší info, ale i na aktuálním webu se toho stále drží.
Dále zde máme ofiko Oracle note pro výpočet alokace ram pro konkrétní použití na Solarisu.
Obecně se dá říci, že implemetace ZFS je od nejlepšího po nejhorší : Solaris, BSD, Linux
Tak, a teď k mé zkušenosti. Když jsem si zapl deduplikaci na 24TiB poolu s 64GiB ram a po měsíci šel systém do kolen a už jsem se k datům nedostal, protože při mountu vždy došla ram, tak to podle tebe nedostatkem ram nebylo? A FreeNAS správci a Oracle se plete, protože vývojář ZFSonLinux napsal na reddit, že 1GiB ram stačí pro exabajt storage?
Nebo vývojáři ZFSonLinux mají implementaci ZFS, která nežere ani smítko ram?
Každopádně já si přes noc pouštím jen tak ze srandy "zdb -S pool" na mém 24TiB poolu a uvidíme, co mi to vyplivne za hodnoty a kolik bych měl podle Oracle mít volné ram.
Zdar Max

[Sten]

Na velikosti pole to nezáleží, protože tam není napsáno, že by to záviselo na velikosti pole

FreeNAS tam nemá uvedeno, že by to bylo minimum, ale že je to doporučení. Hodně RAM se hodí i na cache (a to u jakéhokoliv souborového systému), to doporučení IMO nemá nic společného s požadavky ZFS.

Bez duplikace doporučuje Oracle alespoň 1 GB RAM. Opět bez zmínky, že by to záviselo na velikosti pole. Proč by to vůbec mělo záviset na velikosti pole? Všechna data má ZFS na disku, pokud se nevejdou do RAM, může je kdykoliv znovu načíst.

[Max]

Tak, už mám výsledek simulace deduplikace :

traversing objset 0, 964 objects, 0 blocks so far
traversing objset 21, 17 objects, 0 blocks so far
traversing objset 48, 12 objects, 0 blocks so far
traversing objset 55, 282 objects, 5 blocks so far
traversing objset 63, 2162 objects, 13886490 blocks so far
traversing objset 84, 425 objects, 175125037 blocks so far
traversing objset 96, 25491 objects, 178035147 blocks so far
traversing objset 108, 7 objects, 189724681 blocks so far
traversing objset 239, 27 objects, 189724681 blocks so far
traversing objset 790, 46 objects, 189725115 blocks so far
traversing objset 796, 11713 objects, 189919683 blocks so far
traversing objset 818, 1018960 objects, 190142211 blocks so far
Simulated DDT histogram:

bucket              allocated                       referenced
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     1     187M   23.4T   22.1T   22.2T     187M   23.4T   22.1T   22.2T
     2    2.49M    319G    262G    264G    5.48M    701G    564G    569G
     4     477K   59.6G   29.9G   30.7G    2.27M    290G    142G    146G
     8    43.0K   5.37G   3.59G   3.62G     362K   45.3G   29.8G   30.1G
    16    2.30K    294M    148M    151M    51.2K   6.38G   3.29G   3.37G
    32      459   57.3M   18.6M   19.0M    21.2K   2.64G    618M    639M
    64      137   17.1M    506K    648K    9.06K   1.13G   34.4M   43.9M
   128        9   1.00M      9K     36K    1.57K    180M   1.57M   6.27M
   256        3    384K      3K     12K    1.03K    132M   1.03M   4.12M
   512        3    384K      9K     12K    2.26K    290M   6.21M   9.05M
   32K        2    256K      2K      8K    91.1K   11.4G   91.1M    364M
 Total     190M   23.8T   22.4T   22.5T     196M   24.5T   22.8T   22.9T

dedup = 1.02, compress = 1.07, copies = 1.00, dedup * compress / copies = 1.09

Podle výpočtu na stránkách oracle bych pro svůj 24TiB pool potřeboval minimálně 61GiB ram + k tomu ještě standardní režie. Takže jen deduplikace podle Oracle sežere skoro 2,6GiB/1TiB. A to se bavíme jen o deduplikační tabulce. Další ram je např. potřeba na checksumy všech dat v poolu.
Pokud budeš mít míň, můžeš se dostat do stavu, že datasety nepřipojíš, dokud nedoplníš fyzickou ram, jak se stalo mně, když jsem to testoval.

Jinak ZFS používá/má v ram :
- read cache
- write cache
- checksumy všech bloků v poolu
- paritní data
- deduplikační tabulku (viz onen výpočet)
- jisté režie má i komprese

Každopádně ano, 1GiB/1TiB může být v nemálo situacích přestřelený požadavek, ale pokud chceš trochu rozumně cachovat a používat pár základních fičur, tak je to ideální poměr, a to prosím bez deduplikace.
Zdar Max

[VSi]

RAM je 128G, to by mělo stačit . Ale vzhledem k tomu, že nepotřebuju zas tak velkou kapacitu, bych výkon řešil použitím čistě SSD. Třeba 6 ks 400 nebo 480 GB v RAID-Z2/RAID6 mi na nějakou dobu vystačí, zas tolik to nestojí, a výkon je úplně jinde. Trochu problém pro ZFS budu mít v tom, že ten HW, do kterého bych to potřeboval, nepodporuje na diskovém řadiči HDD passthru, moc se mi nelíbí dělat tam N x RAID0.

[Sten]

ZFS to vadit nebude. Ten RAID0 by nakonec mohl být i výhoda, řadič bude cachovat ZIL, takže by to mohlo zrychlovat zápisy.

[Max]

Vadí to, a celkem dost. Důvod je prostý, řadiče standardně vypínají cache, která je na diskách, aby se používala jen ta cache na řadiči a on si to mohl celé řídit. Proto když chcípne baterie na řadiči, tak chcípne výkon celého pole třeba na trapných 20MiB/s a šíleně mizerný iops, protože nejen, že se vypne cache na řadiči, ale nezapne se na diskách.
Pokud není budget vyčerpán a mělo by se nasazovat ZFS, doporučil bych dodatečně koupit nějaký LSI HBA řadič, cena kolem 5-6kkč bez DPH.
A jako další bonus pak bude plnohodnotný přístup k SMARTu.
Zdar Max

[romanch]

Ano, taky takhle jsem nějak k HP serverům g6 a g7 (P410) dokupoval LSIčka (IBM M5110 tuším) kvůli tomu, že P410 neumějí HBA - PassThru mode a RAID0 jsem principiálně odmítl dělat. u G8 a G9 už P420 a P440 HBA mode dají - sice to nějak prudí ale funguje to.

Práci čest soudruzi IT :)

[VSi]

V konfiguraci PERC H710 lze nastavit, jestli se má drive write-cache vypnout nebo ne, a jak se má používat RAM na řadiči - jestli jen pro čtení, nebo i pro writeback. V tom by problém nebyl. Problém může být v nemožnosti přenosu disků na jiný typ controlleru, což mi nějak nevadí, a pak v nedostupnosti SMARTu, s čímž jsem schopen žít. Při RAID-Z2 když mi odejde disk, tak ho prostě vyměním, žádný stres, a ten HW RAID chyby u kompatibilních disků odhalí spolehlivě, a disk vyhodí z pole jako vadný => reklamace.

[lertimir]

vědomí spočívá v tom, že btrfs mount má volbu:

ssd ssd_spread nossd

(default: SSD autodetected)

Options to control SSD allocation schemes. By default, BTRFS will enable or disable SSD allocation heuristics depending on whether a rotational or non-rotational device is in use (contents of /sys/block/DEV/queue/rotational). If it is, the ssd option is turned on. The option nossd will disable the autodetection.

The ssd_spread mount option attempts to allocate into bigger and aligned chunks of unused space, and may perform better on low-end SSDs. ssd_spread implies ssd, enabling all other SSD heuristics as well. The option nossd will disable all SSD options.

[majales]

Další věc je dostupnost... Poptával jsem například Intel DC P3520 2TB, a bylo mi řečeno že nikde v Evropě nemají na skladě ani u Intelu.. Že prý kdybych chtěl víc kusů (snad 5 a víc) tak že rozjedou linku a vyrobí.. K smíchu..

[VSi]

Menší kapacity (400/800 GB) přímo přes Dell nejsou problém. Pokud to nemá být jen cache (L2ARC, ZIL pro ZFS), tak je stejně potřeba redundance, a není zas takový problém poskládat větší kapacitu z menších disků.

[romanch]

Používám na cca 10 serverech ZFS, SAS raid řadič do HBA modu, MVMe SSD Intel cache, Většinou cca 5-8 HDD do Raiz1 nebo Raidz2 (staré malé HDD) Vše distribuce Debian (proxmox) ZoL, při chybě disku, se zatím vždy podařila náprava - scrub. přendání HDD Poolu a import do jiného serveru též OK.

zůstanu u tohoto modelu i nadále. Právě vyrábím 5 serverový Cluster ... nad ZFS ještě poběží GlusterFS

Práci čest soudruzi IT :)

[dustin]

Pěkné, jak dlouho ti to takhle na debianu jede? Díky.

[romanch]

Debian používám odjakživa, Proxmox cca 5 let, ZFS asi 3 roky - postupně snaha eliminovat závislost na HW RAID řadiči serveru, možnost přendat HDD do náhradního nového serveru apod, navíc ZFS je podporovanej v Proxmoxu, takže vše dohromady. Ale neměl jsem dost nehod HDD, aby to mělo opravdovou vypovídací schopnost. 2x se záhadné chyby HDD podařilo opravit a 2x výměna vadného HDD bez ztráty kytičky. Ale Teď navíc nad to přidám GlusterFS a budu snad už úplně v klidu. Jinak používám do ZFS i obyč velké SATA HDD

Jedině nechápu proč v ZFS nejde přidávat HDD do RaidZx. Prej jde RaidZx zvětšovat postupnou výměnou všech HDD za větší - to hodlám vyzkoušet nanečisto.

BTW mě ještě překvapilo, jak odolně fungoval CEPH ... udělal jsem mini setup 3x server a 6x hdd a dělal jsem v tom psí kusy, vypínal a zapínal servery a vždy nakonec po hodině najednou STATUS OK - ale žilo si to vlastním životem :) Je to velkej BlackBox a když se to po.., tak to nikdo nespraví :)

Práci čest soudruzi IT :)

[Sten]

Přidávat disky do VDEVů nejde, protože by ZFS muselo implementovat rebalance, a do toho se autorům zatím moc nechce.

[pavele]

S tím GlusterFS jsem zvědavý, zatím si všichni stěžují, jak je to pomalé a já si na tom nabil ehm ústa. Vidím to tak, že GlusterFS je v podobném stavu jako btrfs. Byl bych rád, kdybys potom napsal, jak to jede, třeba zase sem.

Já ti dám soudruha.

[Aleš Kapica]

Kecy v kleci. Má se to s ním úplně stejně jako s Btrfs. Je třeba vědět jak to funguje, co to dělá, k čemu je to dobré a co to má za specifika.

GlusterFS je zajímavá clusterová alternativa za NFS. Neposkytuje distribuované blokové zařízení jako Ceph nebo Sheepdog, ale souborový systém. Nehodí se z principu na mraky malých souborů (ubijou to IO operace spojené s replikací), ani pro big soubory (tam bych použil právě zmíněný Sheepdog, nebo Ceph).

[cronin]

Nehodí se z principu na mraky malých souborů ..., ani pro big soubory ...

Tak to mi príde ako dosť obmedzené použitie, nie? Načo sa to teda vlastne hodí? Mám si dať na to zbierku MP3?

[kotel]

Taky x let používám proxmox s ZFS + ZFS na xigmanas. Zkoušel jsem glustefs pro web servery jako sdílené úložiště, ale to není vhodné kvůli rychlosti (web si pro zobrazení stránky načítá tisíce souborů). Jinak je to skvělá věc. Řešení by bylo nějaká cache ještě nad glustefs. Pokouším se rozjet ceph, který má podporu přímo v proxmoxu na části disku, ale nedaří se. Chce to na to mít disky úplně extra.

[kotel]

Jinak samozřejmě největší výhoda proxmoxu je, že to nainstaluje ZFS už při instalaci. Prostě vyberete typ raidu, disky a hotovo. Chtěl jsem teď udělat malej záložní server jen na rsync záloh a aby to vydrželo nějakej pátek bez údržby. Zkusil jsem po letech čistou instalaci debianu a tam je sice nějakej btrfs, ale jak to nainstalovat korektně? Jde to vůbec? Asi ne. Takže tam šel proxmox. Tzn. hned funkční webová konzole, funkční ssh a funkční raid. Ale mohli už udělat instalaci bez potřeby myši, protože většina serverů má jen 2x usb, případně jsou vpředu 2x a vzadu 2x a v instalaci se stejně hovno řeší, takže úplně zbytečná komplikace.