Dotaz: HA linux storage

[Odpadlik]

Zdravím, řeším problém high availability úložiště pro Linuxové servery.

Požadavky:

• sdílený storage
• high available
• rychlý
• POSIX kompatibilní.

Má to být náhrada Netappu s jehož výkonem nejsem spokojen.

Pracuji s následujícími možnostmi:

1. Klasický NFS server s vlastním (lokálním) RAIDem a ext4/btrfs/xfs
2. NFS server v HA clusteru (active/passive) se sdíleným storage a filesystémem ext4/btrfs/xfs
3. NFS server v HA clusteru (active/passive) s lokálním storage typu ext4/btrfs/xfs který se replikuje na ostatní uzly pomocí DRBD
4. všechny servery v clusteru s GFS2 sdíleným filesystémem

Nemáte s tím někdo zkušenost?

Nejvíce mi dává smysl možnost 1 a 3.

1. Vím že mi dá co potřebuji. Trochu problém je s tím že to není úplně HA.

3. Je vlastně to samé co 1. s tím, že je doplněno o HA

Body 2 a 4 potřebují sdílené úložiště typu SAN což mi přijde zbytečně nákladné a je to další věc co by se mohla pokazit.

Odpovědi

[Petr]

Tak nejak nerozumim, resis HA uloziste a pak zaroven rikas, ze na tom Ha ani tak nezalezi. Ujasni si co chces. Od NetApp jsme postupne odesli k zfs storage na freebsd. Mame ale specificke pozadavky na provoz, tudiz to co vyhovuje nam nemusi tobe.

[Odpadlik]

Prosim precti si muj dotaz jeste jednou. Ok?

[Petr]

Ja jsem to cetl, ale ty zminujes ze HA reseni vyzdaduje dalsi veci ktere ti prijdou zbytecne. Pokud potrebujes 100% HA reseni, tak proste sdileny storage je zaklad.

[Odpadlik]

To neni pravda - viz DRBD. Navic sdileny storage je prave ten single point of failure

[lertimir]

Řeším něco podobného a nakonec se přikláníme ke "krabicovému" řešení na Synology.

A to dvě Synology napárované pomocí HA. a jako základní systémy v současnosti zvažujeme.

1. RS818+ 1U 4 disky (s 1U expanzí 8)
2. DS1817+ 8 disků + možná další expanze. Možností 10GbE rozhraní, SSD cache na zrychlení přístup
3. RS2416+12 disků ve 2U + možná další expanze.

Zatím analyzujeme potřebu jednak celkových kapacit a jednak potřebu síťových výkonů než se finálně rozhodneme. Ale pro mne toto řešení je již výkonově dostatečné pro klasické disky.

Pokud "rychlý" znamená storage na SSD a 10GeE ethernet v plné zátěži, tak je to na něco na Xeonu, ale i tak bych spíše použil NAS než něco stavěl.

[Odpadlik]

To neřeší logickou stránku věci (tj jak zajistit sdílený přístup), pouze hardware - ale jinak dík za link

[Odpadlik]

Tak se omlouvám. Tak krabice už umí NFS. Což není úplně ono, pač to určitě nebude umět tak aby nám to vyhovovalo.

[lertimir]

U vás je asi primárně otázky výkonu. jaké NFS umí krabice je tady a jinak krabice umí i iSCSI. Pro nás to, že na každém Synology bude RAID 1 a budou dvě spřažené do HA bude stačit, jak pro bezpečnost, tak pro výkon. Nicméně vysoké výkony jsou asi jiná otázka. Jaký výkon se od úložiště očekává. (IOPS, datová propustnost, kapacita, atd.?)

[Odpadlik]

No my potřebujeme aby krabice uměla NFS i CIFS, integraci do AD s podporou RFC2307bis a navíc asynchronní NFSv4, snapshoty a kvóty na uživatele a skupiny. Chci kapacitu cca 30Tb a latenci v řádu milisekund. Krátkodobou propustnost blížící se 10Gb Ethernetu. Málokdo něco takového nabízí out-of-the-box, takže jsem se smířil že si tyto "detaily" nějak dobastlím sám. Tady mi primárně jde o zajištění HA.

[Aleš Kapica]

Záleží na tom jaký HW a v jakém počtu máš k dispozici. Jakou máš konektivitu & etc. Z hoven sice nějaký ten bič upleteš, ale moc s ním nezapráskáš.

[Odpadlik]

Prosím pouze smysluplné komentáře. Samozřejmě nepředpokládám, že řešení bude zadarmo a že si i nějakou investici vyžádá. Pouze očekávám že to bule levnější než 100k Eur (což je cena za Netapp All-flash storage)

[Max]

Máme 2x NetApp FAS2552 a v každém 2x SAS Agregáty (30TB) + 1x Agregát 2TB SSD, bez akcelerace pomocí ssd a výkon to má hodně pěkný. Připojeno do sítě přes 2x10Gbit ethernet a NFS4.1 + async do záložní lokality.

Pokud bych měl řešit vlastní storage v rámci OSS, což už jsem řešil, tak bych to udělal jako teď, co mám, tj. :
FreeBSD + ZFS + hodně ram a 2xSSD pro mirror SLOG + LSI HBA
ZFS = snapshoty, možnost dělat send/receive na/z jiného ZFS storage, pěkné statistiky zatížení, je to vyladěný FS

Ano, je to dražší, jak obyčejný storage s HW řadičem + ext4 a k tomu DRBD, ale výkonově je to hodně slušný.
A případně lze použít FreeNAS, což mi přijde jako dobré klikací řešení, žádný bastl.

Buď bych tedy osobně přemýšlel nad ZFS výše, nebo nad lokálním storage s DRBD na druhý node.
Obě řešení samozřejmě může rozdělit a mít půl produkce na jednom nodu a půl produkce na druhým. V případě pádu pak řešíš nahození půlky služeb na druhé straně.
Zdar Max

[Max]

Teď koukám, že zmiňuješ "100k Eur (což je cena za Netapp All-flash storage)", možná by se tedy hodilo říci, o jakém zatížení se bavíme a jaké jsou požadavky např. na latence apod.
Zdar Max

[Odpadlik]

Máme něco podobného. Blbé je, že Netapp neumí asynchronní NFS, což způsobuje latence v řádu desítek milisekund. To je pro nás nepřijatelné - z toho důvodu jsme nasadili něco podobného co zmiňuješ (Linux, lokální fs, hodně paměti, trocha kernel tuningu, a NFS). Akorát mě tedy mrzí že to není HA řešení. Proto ostatně tento dotaz.

O ZFS jsem slyšel, ale raději bych něco "komerčnějšího" s možnou podporou z venčí. Taky potřebujem snapshoty, tak váhám mezi BTRFS nebo EXT4+LVM. Tady by asi zvítězilo ZFS to uznávám.

To je ale jiný příběh. Primárně řeším problém HA, proto mě napadlo DRBD s HA clusterem.

[lertimir]

Rozumím. To je jiná liga, než kterou potřebujeme. 10ms by nás nepálilo.

[Odpadlik]

A přitom řešení je jednoduché. Asynchronní NFS a hodně paměti. 10ms by asi bylo OK, blbé je, že Netapp dává tak průměrně 40-50ms. To už se na kupříkladu subversion operacích (spousta malých souborků) dost projeví.

[lertimir]

Pokud je rozpočet kolem 100k Euro, tak možná más smysl i nějaký testovací pokus s tím Synology, protože se dvojice dá pořídit pod 100k Kč a třeba na omezených datech se ukáže jaké to má vlastnosti.

[aliquis]

40-50ms je vela aj v tcpdumpe, tam bude skor iny problem. Packet trace si robil na kontroleri ci na NFS klientovi? Ktore operacie trvaju dlho(read, write, other)? Netapp async NFS nepodporuje lebo nema zmysel. Kazdy zapis ide do pamate a aj NVRAM(lokalnehe nodu a partnera). Hned potom sa potvrdi NFS klientovi. Na disk to ide v ramci consistency pointu. Mas to monitorovane grafanou? Ake mas NFS latencie v grafane? Pri citani sa pouziva readahead...

[MP]

http://ixsystems.com/ - HA zfs, pozadavky nutno overit. Ale pokud je duraz na latenci, asi bych do vlastniho reseni nesel.

[Petr]

Zfs ma komercni podporu pokud potrebujes, teba ixsystems, snapshoty atd to umi a je to vyladene ve srovnani s btrfs. Zkus si u btrfs nechat stovky snapshotu, nebo raid5/6 to nema produkcni atd. Nasadit to do produkce bych nechtel, ale kazdy to mame jinak.

[Odpadlik]

Mám podobné výhrady k btrfs a nikde neříkám že bych ho určitě použil....

[Aleš Kapica]

Měl jsem na Btrfs kolem deseti tisíc snapshotů a jelo to ok. Problémy mohou nastat až při jejich odstraňování, obzvláště u pomalého blokového zařízení. Pokud se nestihnout všechny odstranit před případným restartem stroje, projde mount po restartu teprve až se všechny operace dokončí - čekal jsem takto téměř to půl dne a během té doby se modlil, aby všechno dojelo v pořádku. Od té doby jsem chytřejší a raději je odstraňuji postupně.

[Max]

Přílohy:

• nappm-prehled-01.png (66930 bytů)
• nappm-prehled-02.png (51293 bytů)
• nappm-prehled-03.png (142392 bytů)
• nappm-prehled-04.png (178456 bytů)

Nemáme problémy s latencema, resp. jen tu a tam. NetApp je připojen ke switchi HP5700 přes 2x10Gbit a to samé každý server DL380G9/nod.
Používáme ESXi 6.0 a připojení přes NFS4.1
Ve špičkách jdeme s těma pár SAS diskama k 5k IOPS (nepočítám ssd agregátor) a občas latence vyskočí na 25, někdy i k 50ms, ale běžnějších jsou latence v průměru kolem 3ms.
Statistiky z toho jednoho NetAppu viz příloha.
Běží nám tam :
- 2x Exchange 2013 (celkem 550 mailboxů, cca 2TB)
- KerioConnect 400 uživatelů (1TB)
- svn (30GB)
- Filserver (pro 250 uživatelů, 600GiB)
- helpdesk (redmine), nagios, ftp/ftps/sftp
- Oracle 11XE db pro Apex
- Apex + Glassfish
- 3x IIS Server
- citrix pro 25 desktopů
- sharepoint 2013
- x2go pro 20 uživatelů
- wsus pro 500 stanic (cca 600GiB)
- wiki
- print servery
- telefonní ústředna mx-one
- ESET ERA
- doménové a dns servery
- nějaký apache a malé VM.

Na tom 2TB SSD nám pak běží SAP + Oracle + - MSSQL 2012 (500GiB) + nějaké další věci
Zdar Max
PS: cena těch dvou NetAppů byla celkem směšná, resp. byly levnější, jak např. hloupé pole od HP

[Odpadlik]

Hmm, dík. Tak u vás je to primárně asi úložiště pro ten ESXi jestli tomu dobře rozumím. U nás je to primárně fileserver. A latenci jsem neměřil z Netappu ale pomocí timestamp z tcpdumpu. Jako všechno funguje, ale pátrat jsem začal potom, co si jeden uživatel začal stěžovat, že SVN checkout je na lokálním filesystému 20krát rychlejší než na NFS s Netappem. Zjistil jsem, že asynchronní NFS dokáže věci poměrně brutálně zrychlit. Nejdřív jsem se hádal s Netapp supportem, proč pro cache diskových operací nevyužijí NVRAM a pak z nich vypadlo, že NVRAM se k tomu využít nedá - tj umí to pouze synchronní NFS.

Faktem ale je, že my tam nemáme SSD disky, pouze SAS a SATA shelfy. Ten SSD agregátor by tomu mohl dost pomoci.

Abych byl úplně detailní, tak je víc věcí, co mne na Netappu štve. Tristní synchronizace s AD a implementace NFSv4 s Kerberosem je prakticky nepoužitelná. Support je taktéž tragický - pokud chce člověk detailní technické informace typu "já opravdu nejsem lama, dejte mi kontakt na vývojáře", tak má smůlu.

Ale to je na další diskusi někde jinde. Nechci moc odbíhat od tématu

[Soptadv]

Ahoj,

koukni se na HPE 3PAR File Persona specifikace, myslím že by to splnilo...

Ale obávám se že by jsi musel přitlačit na ceně, tohle jsou pole do HI a MID levelu, ne Entry jako NetApp...

Petr

[Max]

Já ten SSD Agregátor na urychlení SAS pole nepoužívám. On je totiž v tomhle Netapp pěkně na pytel. Pokud bych přidal nějaké SSD do SAS Agregátoru, tak je to nevratný proces, není to jako u ZFS, kde si řekneš ok, teď bych chtěl urychlit tohle pole, tak odkloním SLOG na rychlý SSD a když to nebudu potřebovat, tak ho zase odeberu.
Prostě není tam taková variabilita. Na druhou stranu, FreeBSD nepodporuje NFS4.1 a ani žádný OSS Solaris like systém, jen ty šíleně placené varianty :-/.
V tom má zase NetApp navrch a řešením v OSS je jedině ZFSonLinux a použít Linux na NFS služby.
Zdar Max

[romanch]

Možná trochu podobné požadavky - shared HA storage pro KVM (proxmox) používáme : 2x HW server, disky v JBOD modu, nad tím ZFS raidz1 nebo 2 + nvme SSD cache. A tyhle 2 servery jsou propojené 10gbe (teď i testovacím 40gbe mellanox) a nad tím je GlusterFS, který to exportuje na každém serveru ven jiným 10gbe pro KVM Hosty SW je distribuční Debian bez úprav + ZFS, konfigurace jednoduchá za odpoledne. eliminuji tím HW raidy a řešení typu SAN (FC) Náklady 00 nic, používám nové LFF SAS disky, repas 2x Xeon HPE servery za 500E + 64GB RAM.

[pavele]

Dva servery - to jako dva nody s GlusterFS?

[scott]

Tohle reseni se mi libi,ale neni lepsi pro GlusterFS mit vice nodu? A NFS by melo byt vestavene i v GlusterFS, aby se nemusel pouzivat FUSE konektor, mas s tim take zkusenosti?

[pavele]

Já jen, že jsem si chvíli hrál s GlusterFS se dvěma nódy a v případě výpadku jednoho nódu došlo po krátkém čase k odpojení druhého, funkčního nódu.

A co jsem se potom díval na informace k tomuto chování, prý to není bug.

Takže pro moje použití byl GlusterFS nevhodný - jsou potřeba nejméně 3 nódy.

Možná mě někdo opraví, že u nové verze už s tím problém není, přece jen je vývoj a změny v GlusterFS jsou poměrně rychlé, přirovnal bych to k vývoji Btrfs.

[hermelin]

Ahoj, pouzivam proxmox s drbd ale taky se poohlizim po necem jinem. Hlavnim duvodem je ze uz drbd neni standartne v Proxmoxu (musi se doinstalovavat z jineho repozitare), a uz sem diky tomu na mailing listu zaznamenal i nejake problemy. GlusterFS se mi na image virtualu zatim jevi jako rozumna nahrada - az bude cas mrknu na to a otestuju. Jinak problem s dvouuzlovym glusterfs je uz podle dokumentace vyreseno prostrednictvim tretiho uzlu ktery funguje pouze jako arbitr pro quorum (neuklada zadna data, pouze metadata a strukturu adresaru) - http://docs.gluster.org/en/latest/Administrator%20Guide/arbiter-volumes-and-quorum/

[pavele]

A ten třetí uzel musí být na samostatném serveru nebu může být na jednom ze dvou uzlů?

Co se stane, když třetí uzel vypadne současně s druhým - oba budou nainstalované na stejném serveru?

[hermelin]

Tak samozrejme pokud vypadnou dva jakykoliv uzly tak quorum ze neni schopny zajistit konzistenci takze svazek bude minimalne read-only nebo se ztrati uplne. Arbitr je asi dobre mit na jinem serveru nez jsou ty dva nody. Vse je ale jenom teorie - s glusterfs nikdy nic nedelal. Treba sem nekdo napise sve prakticke zkusenosti s glusterfs na dvou uzlech.

[marbu]

Arbitr je asi dobre mit na jinem serveru nez jsou ty dva nody.

+1

[Odpadlik]

Trochu blbé je, že GlusterFS používá afaik FUSE, tzn nikdy to nebude tak rychlé jako nativní filesystém.

[ZS-Man]

To není úplně přesné, Proxmox (QEMU) používá pro přístup k virtuálním diskům libgfapi.

[hermelin]

presne tak - vice o tom tady - http://staged-gluster-docs.readthedocs.io/en/release3.7.0beta1/Features/libgfapi/

podporuje jak qemu, nfs i sambu

to by mohlo vykonove dost pomoci

[Odpadlik]

lib(cokoli) = FUSE = nikdy to nebude tak rychle jako nativni filesystem v kernelu.

[Aleš Kapica]

GlusterFS i s obrázky. Stránka sice dva roky stará, protože už jsem dávno o kus jinde (proto i nedoplněná), ale pro seznámení může stačit.

[Odpadlik]

Vím jak GlusterFS funguje. Je to fajn systém, ale nic to nemění na faktu že je to založené na FUSE, tj nebude to nejrychlejší (ve srovnání s NFS například).

Co mi přijde slibné je GlusterFS ve spojení s pNFS - tomu bych opravdu rozuměl. Nezkoušel někdo?

[Aleš Kapica]

Jo. Zkoušel. Na pytel.

[Odpadlik]

No je otázka jesti jsi zkoušel opravdu pNFS a ne jen NFS. Gluster umí oba.

[Aleš Kapica]

Pokud nevěříš, zkus si to taky Tomáši.

[Odpadlik]

Jj, vyzkouším

[Aleš Kapica]

GlusterFS je dobrý na sdílení souborů mezi virtály a hostiteli. Pro bloková zařízení virtuálů samotných je lepší použít distribuované blokové zařízení. Ovšem to vyžaduje minimálně tři nody (sheepdog). V případě dvounodového clusteru je lepší používat DRBD oddíly zpropagované rovnou do virtuálů. Osvědčilo se jako nejspolehlivější. Když se něco podělá, tak to nesejme všechno najednou.

[Odpadlik]

Virtuály neřeším, to je příliš pomalé. Když už izolace, tak nasadit kontejnery - běžet Linux VM na Linuxovém hypervizoru mi fakt přijde dnes trochu nešťastné a překonané.

Řeším fileserver resp distribuovaný filesystém. DRBD je fajn a rychlé (pač se implementace dostala do jádra), GlusterFS má ale také BD translator který toho umí víc (DRBD v je v podstatě jen síťový RAID-1). V podstatě mi z toho vychází asi nejlépe Gluster/pNFS - to má potenciál. GFS je také OK, ale chce to SAN....

[marbu]

Tahle poučka obecně platí pro lokální souborové systémy (jako je např. xfs, ext4, zfs), protože se použitím fuse zněkolikanásobí počet přepnutí kontextu a žádné další externí vlivy to už nepřebijou. Ale v případě distribuovaných systémů, kdy jsou ve hře třeba desítky strojů komunikujících po síti, jejich konfigurace a způsob, jak k těm strojům přistupují klienti, bych to úplně netvrdil.

Např. v případě toho GlusterFS můžeš jako místo tzv. nativního fuse klienta zvolit nfs klienta. To že je ten nfs klient v kernelu ale automaticky neznamená, že bude tento přístup vždy bez ohledu na další okolnosti rychlejší nebo lepší. Naopak se spíš doporučuje ten fuse klient:

The Gluster Native Client is a FUSE-based client running in user space. Gluster Native Client is the recommended method for accessing volumes when high concurrency and high write performance is required.

Na druhou stranu je ten nfs klient zase lepší v případě čtení mnoha malých souborů z jediného klienta. Ale se z pouhého posuzování kernel vs user space bez ohledu na architekturu nedá jen tak odhadnout.

[Aleš Kapica]

Z vlastní zkušenosti doporučuji používat raději toho klienta přes FUSE, než NFS. Odpadne tím řada problémů. Ale má to háček a tím je zabezpečení. Možná je dnes už situace jiná, ale když jsem si s tím hrál, tak jsem raději GlusterFS provozoval tak, aby byl zcela oddělen od veřejné sítě, na samostatné VLAN. Ovšem to platí i pro jiná distribuovaná řešení.

Kupř. pokud někdo získá kompletní URL na připojení kontejneru cephu, nebo sheepdogu, tak může hravě nabourat FS virtuálu. Sheepdog sice měl podporu pro zamykání, ale to dělalo někdy binec při migraci. Nevím jak to má aktuálně Ceph. Na GlusterFS se mi líbila právě ta možnost sdílení souborů mezi více stroji. Jako úložiště virtuálních disků přístupných přes libgfapi to taky nebylo špatné, ale IO výkon hostitelských strojů byl velmi limitující (byly to staré šunky s velkými a pomalými SATA disky). Tak kde jedou hostitelské stroje na raidech s rychlými SAS disky to může být výkonově úplně jinde.

[Odpadlik]

Tak pokud se někdo může zmocnit přístupu na filesystém jednoduše přes URL, tak to svědčí o zásadní chybě v návrhu sítě. Jinak co se týče zabezpečení, tak GlusterFS to vůbec neřeší, což možná přijde později - zase to ale svědčí ve prospěch NFS, která se dá snadno a elegantně zabezpečit Kerberem - pak můžete mít bezpečný přístup i přes to Vaše URL :D

[Odpadlik]

Jj, myslím si to samé. Native Gluster client je asi 10x pomalejší než NFS - a lepší už to nebude. Myslel jsem si taky, že GlusterFS ve spojení s NFS by mohlo být rychlejší, zvláště pokud to pojede přes ParalelNFS (pNFS). Problémem je, že:

- GlusterFS nepodporuje kernel NFS server

- Ganesha NFS nepodporuje asynchronní NFS.

Což nám dává pouze synchronní user space NFS server.Nic moc.

Docházím k závěru, že člověk by se měl vyvarovat distribuovaných filesystémů, pokud je nutně nepotřebuje - protože prostě nejsou tak rychlé (a ani být nemohou) jako lokální fs. Prostě zůstat u starého dobrého NFS, a pokud člověk potřebuje redundanci, tak pod něj hodit ještě DRBD

[Max]

Jsem téhož názoru (DRBD, nebo ZFS/Btrfs send/receive), resp. cluster fs se vyplatí až od mnohem většího nasazení, nic s pár nodama nebude mít nikdy uspokojivý výkon :-/.
Zdar Max

[Aleš Kapica]

Záleží co od toho chceš.

[Aleš Kapica]

Docházím k závěru, že člověk by se měl vyvarovat distribuovaných filesystémů, pokud je nutně nepotřebuje - protože prostě nejsou tak rychlé (a ani být nemohou) jako lokální fs.

Plantáte nesmysly. NFS dává smysl pouze v případě, že nemáte sdílená data křížem krážem. Tj. když klienti komunikují přes jeden společný storage. Ano, můžete také provozovat NFS porno, kdy každý šuká s každým, ovšem za nedostupnosti některého z namountovaných nodů vám může NFS nepěkně zablokovat síť.

Pokud chcete data skutečně sdílet, tak abyste mohl kterýkoliv z nodů podle libosti a potřeby odstavit, tak dává smysl jedině distribuované řešení. A pokud se týče rychlosti - ta je limitována především tím, jak rychle jsou schopny nody ukládat a poskytovat data.