Dotaz: high availability storage

[disposable]

Potrebujem pre moje vservery nastaviť nejaký lacný (cca 0,-) SAN. Všetko ale musí byť duplikované a schopné fungovať aj keď sa aspoň 50% infraštruktúry pokazí.

Ideálne by som chcel export dát cez NFS, ale neviem či NFS podporuje clustering a takisto netuším aký súborový systém mať pod tým, aby podporoval viacero mirror data serverov.

Nezaujímajú ma odpovede typu: "Pozri sa na CLVM, OCFS/GFS2, pNFS, DRBD, atď.." To všetko som si už pozrel. Zaujímajú ma ucelené názory ľudí, ktorí už niečo podobné majú vyskúšané v praxi. Čo ste nastavili, ako ste to nastavili a prečo práve toto a prečo práve tak.

Odpovědi

[-]

Zdravim, pouzivam DRBD+RH cluster, funguje to 100% uz par rokov vratane disatser ked chcipol jeden zo serverov. VM sa premigrovali na druhy a vysledok bol cca 1min. vypadok. Po oprave sa novy server syncol k staremu a zas to vsetko slape. Mam 5 takychto clusterov, potencialny problem je rychlost synchronizacie serverov (a teda IO operacii), kedze DRBD pouziva len jednu sietovku.

[disposable]

Ďakujem, ale to je presne odpoveď typu: "Pozri si DRBD + RHCS." Ako to máte spojené, aký lokálny FS vám ten DRBD synchronizuje, prečo je práve toto lepšie než GFS2, ide v tom NFS,...? Mimochodom minútový výpadok a high availability by nemali byť ani len v jednej vete. Za minútový výpadok by som mal okamžitú výpoveď.

[dik]

"Za minútový výpadok by som mal okamžitú výpoveď. " a storage za 0kc , to moc nejde dohromady nebo se pletu?

Mimochodem se o neco podobne snazim ,resp. active/active (drbd + gfs2 + iscsi z image souboru + multipath) akoram mam obavu o konzistenci dat ,kdyz stejny image soubor bude mit otvereno vic iscsi targetu. dik

[a1bert]

"Za minútový výpadok by som mal okamžitú výpoveď ... storage za 0kc"

jestli mas opravdu podminky nastavene takto, tak bych zvazil jestli tu vypoved nedat sam uz ted ;) (nebo pokud te plati velmi dobre, tak to zaplat ze sveho)

[disposable]

Tá dilema je tam "môj čas" vs "peňažná investícia". Peňažnú investíciu sme už skúsili

• kúpili sme 2x Hitachi SMS 100 (£4000 za kus). Výsledok - pomalé jak šľak, čisto black box riešenie, kde sa skoro nič nedá poriadne nastaviť. Teda momentálne používam 1 na zálohy a druhý išiel na ebay.
• teraz mám na testovanie 1x Nexsan SATABeast za £24000. Výsledok - je to nádherný stroj, ale to je tak všetko. Problémy som už popísal v inom príspevku.

na rade je teraz "môj čas". Mám dosť black box riešení. Na hardvér mám rozpočet v zmysluplných hraniciach, ale nad softvérom chcem máť tentokrát úplnú kontrolu.

[VSi]

No tak by bylo dobre napsat, ceho presneji chcete dosahnout, resp. jake jsou pozadavky. Tech moznosti jak to udelat je docela hodne, vse ma nejake vyhody a nevyhody ve vztahu ke slozitosti - cas na konfiguraci, spravu; potencial, ze se to rozbije. Plus HW naroky - treba o DRBD nema moc smysl se pokouset bez HW RAIDu s write cache a baterii. A na linuxu momentalne jina technologie nez DRBD neni, chcete-li se vyhnout drahe SAN na fibre channel.

Pisete, ze 1 min. vypadek rozhodne ne, pritom jde o "vservery" (jaka technologie?). Kdyz odejde ten virtualizacni stroj, stejne musi vsechny na nem drive bezici virtualy nabootovat jinde. Pokud mate tech fyzickych serveru hodne, je na miste chtit skutecne bezvypadkovy storage - zde zalezi na virt. technologii, ale standard je multipath + FC (kvuli cene to zde neni reseni) nebo iSCSI. Ale podle me tohle uz na sw reseni stylu DRBD nikdo nestavi. Je treba taky rict, jaky vykon od toho cekate, jinak budeme rozebirat nesmyslna reseni.

Takhle to vypada, ze chcete, aby vam to tu nekdo cele navrhnul, a pritom nejsou ani jasne pozadavky.

[disposable]

mám v práci asi 10 fyzických serverov, na každom z nich beží 10-50 vserverov (http://linux-vserver.org). každý vserver je umiestnený vo vlastnom adresári na 3 miestach:

• na serveri v ktorom beží,
• na serveri ktorý robí zálohy
• a na serveri ktorý je hot-spare (náhradník)

problém je, že keď sa fyzický server pokazí, musím dotknuté vservery naštartovať na hot-spare, kde ale prídem o dáta vytvorené medzi zálohou a daným časom. keby som mal spoľahlivé centrálne úložisko všetkých vserverov, mountnuté cez NFS, mohol by som jednoducho naštartovať spadnuté vservery z hociktorého servera, prípadne ich rovnomerne rozložiť na všetky fyzické servery.

Už asi mesiac mám na testovanie zapožičaný Nexsan SATABeast, ktorý sa ale napriek všetkým oceneniam, certifikátom, atď. 2x pokazil (najprv PDU, potom kvôli vibráciám ničil disky), takže som zase kde som začal. nemám nič proti mountovaniu nejakého cluster filesystému cez iscsi, ale NFS mi pripadá jednoduchší a elegantnejší. každý môj server má 4 Gigabitové sieťovky, z toho 2 chcem bond-núť a použiť len na storage.

[VSi]

Teď už se dá něco napsat.

Řešením typu "Nexsan SATABeast" nebo nějakému entry-level diskovému poli s iSCSI bych se asi vyhnul. Protože nevěřím té redundanci v jednom boxu. Ať už na úrovni dual-controller, napájení, nebo firmware.

Takže jsme u toho, že jsou potřeba 2 nezávislé storage boxy, ideálně se synchronní replikací. A nad tím můžeme stavět něco dalšího.

Jak už vám tu napsali jiní, klasické řešení s FC diskovými poli vč. replikace je asi mimo finanční možnosti. Takže je tu cesta Linux + DRBD.

Teď co na druhé straně, pro přístup k datům. NFS bude skutečně nejelegantnější, pokud se nenarazí na nějaké problémy se zamykáním souborů, kvótami apod. ve spojení s těmi vserver kontejnery. Hodně záleží, jestli využijete/potřebujete sdílený volný prostor mezi těmi servery, nebo jestli nevadí např. svazky pevné velikosti pro každý fyzický server.

Asi jste to četl, ale inspiroval bych se tady: http://www.abclinuxu.cz/blog/zdenduv_blog/2010/2/stripky-ze-stavby-centralniho-uloziste

Sám bych to řešil, pokud by šlo o NFS, asi tak: 2 stejné storage servery s HW RAIDem a BBWC, propojené přímo replikační linkou pro DRBD (2×GbE nebo možná 1×10GbE), redundantní síť k virt. serverům (2 switche). Na tom replikace celého svazku pole přes DRBD. Na tom XFS nebo EXT4, exportované přes NFS. Filesystem bude připojen vždy jen na jednom storage serveru a tam bude exportován přes NFS. Při výpadku se vše nastartuje na druhém storage serveru (připojení ext3, start nfsd), na stejné IP adrese (pomocí nějakého cluster manageru).

Výpadek NFS by se měl vejít do 5-10s. Podle mě nejméně komplikované řešení. Další možnosti jsou GFS2 připojený na multipath device nad iSCSI na každém serveru. Nebo pro každý virt. server exportovat přes iSCSI samostatný svazek a nad tím ext4/xfs. Nedá se jasně říct, co je nejlepší. Záleží na prioritách - komplexnost celého řešení, složitost konfigurace a údržby, doba výpadku při pádu jednoho storage serveru, výkon.

Možná je tohle všechno jasné. Možná je 5-10s moc. To musíte říct, a dá se vymyslet něco jiného. Možná chcete konkrétní zkušenost a konfiguraci. To z podobného nasazení nemám. Jen co se týče DRBD+Xen, a to funguje dobře.

[-]

opat zdravim, obavam sa, ze bez aspon zakladneho precitania dokumentacie k danym technologiam sa z miesta nepohnete. Asi ste ocakavali konkretny setup a konfiguraky, to sa ale lisi pripad od pripadu, preto dokumentacia. Ako spomenul p. Setka, s opensource na linuxe je DRBD + GFS2 + RHC jedina pouzitelna a dlhodobo udrziavana technologia. Pokial chcete nieco zadarmo, nemozete cakat 100% funkcionalitu zariadeni za radovo tisice EUR. Vo vasom pripade je potrebne iSCSI alebo FC storage s dualnymi adaptermi, s dvojicou switchov, zalohovanymi routrami, zdrojmi, dvojicou UPS ... . Tu sa ale blizime k 30000EUR(hruby odhad) a to odporuje Vasej poziadavke mat to zadarmo. Takze asi nemate inu moznost, iba pouzit uvedene technologie. Ak je pre Vas 1min. vypadok neakceptovatelny, musite investovat do technologii, ktore priamo riesia redundanciu a HA zdrojov.

[l0gik]

To bych se hádal, HA řešení se dá krásně postavit i např na Glusteru. Když se dobře rozvhrne architektura a rozložení sítě, tak to nebude vyset na jednom routeru/switchi a ostatní zajístí Gluster.Akorát to možná nebude mít takovej výkon jako FC (i když Gluster jde postavit io na infibandu), ale tragickej nebude, na běžný věci rozhodně dostatečnej (a dobře škálovatelnej).

[dik]

...a je to stabilní i s malými soubory a pod zátěží? Lidi na foru si dost stěžovali ,tak by mě zajímala praktická zkušenost. Dik

[disposable]

Glusterfs vyzerá veľmi zaujímavo. Nechápem ako mi toto mohlo ujsť. Máte aj nejaké tipy?

[l0gik]

No vím o projektu, kde to nasadili jako backend pro úložiště velkých datových souborů s poměrně masivním konkurenčním přístupem a jsou stopro spokojeni. Ale to jsou velé soubory. Nicméně na stránkách glusteru je poměrně dost usecasu.

Co vím, tak co řešili za problém, že se ten fs nemá moc rád se zámkama (pochopitelně - zamknout se musej všechny instance a to přes síť už není úplně nejrychlejší).

[dik]

...no já jsem kdysy zkoušel řadu 2.0.x a stabilita pod zátěží byla opravdu žalostná, teď je aktuál 3.1.x která by měla být ok. dik

[Ivan]

Na nic se nekoukej a jdi shanet penize. Kdyby existovalo nejaky HA reseni zadarmo, tak by to pouzivali vsichni a vsude. Za spolehlivost se plati a pokud nemas dopredu dany rozpocet, tak si clusterema muzes maximalne hrat.

PS: proti 50% vypadku neni stavenej ani Temelin, obycejne se branis proti jedny (max. dvoum vypadkum).