Názory k článku Velká řešení otevřeně: souborový systém GlusterFS
-
Ahoj,
dovolil bych si opravit jednu nepřesnost - při roztržení komunikace by nemělo k zápisu do volume vůbec docházet; pokud není nadpoloviční kvórum, stává se volume pouze read-only.
Dále by stálo za to zmínit možnost provozovat tzv. arbiter volume, kdy se dá krásně obejít potřeba mít lichý počet bricků - dejme tomu, že mám replica volume ze tří bricků, ale pouze na dvou z nich jsou data, na třetím jsou metadata - worst case spotřeba dat na arbitru je 4kB * počet souborů ve volumu, v průměru tak polovic. -
Yenya (neregistrovaný)
Škoda že na začátku článku není aspoň nějaké srovnání s alternativami, zejména s tím Cephem.
Já jsem s GlusterFS přišel do styku jen krátce - zprovoznili jsme to, ale nakonec se ukázalo, že dat není až tolik, jako jsme předpokládali, takže v další verzi jsme to nahradili lokálním FS. Naopak Ceph používám jako úložiště virtuálních disků pro OpenNebulu a jako objektové úložiště. K CephFS (POSIXová vrstva nad Cephem) jsem se ještě nedostal. Ale jinak zkušenosti s Cephem jsou veskrze pozitivní včetně reakcí na náhodné restarty strojů nebo reakcí na postupně odcházející a různě chybující disky. Co tam nemá dobré řešení je umístění více různých typů disků (SSD a HDD) do jednoho stroje - CRUSH rules tohle neumí dobře popsat, a pak se musí dělat nějaké obezličky, které neřeší všechny situace.
-Yenya
-
My jsme zkoušeli na škole před 12 lety psát síťový filesystém. Měli jsme z toho pocit, že polovina chyb přisuzovaná NFS plyne z omezení linuxového VFS, respektive toho, že vyšší vrstvy nepočítají s tím, že se na nižší vrsvtvě může rozpadnout spojení se serverem a že může znovunavázání spojení trvat. Takže se síťovým FS bych byl opatrný. Rozhodně se nebude chovat 100% jako lokákní FS. Na druhou stranu aplikace většinou nevyžadují 100% kompatibilitu. Jde o to ale vědět co aplikace potřebuje a zda to danný síťový fs splňuje. což je přesně to co chybí věem článkům z tohoto seriálu, čímž snižuje informační hodnotu článku na manuál glusterfs, s tím, že to druhé je snadněji dohledatelné.
*) kde síť zaručuje maximálně tolik co zaručuje řekněme TCP samotné.
-
j (neregistrovaný)
Jinak receno, na ty nizsi vrstve musis fejkovat ze neco funguje az do okamziku, kdy si uz i ty myslis, ze to chciplo ... ;D
Hele ja mam osobni zkusenosti s temahle vecma (clustering a obecne cokoli distribuovanyho) ze ac ti kazdej jeden dodavatel bude tvrdit, jak je to uzasne transparentni ze o tom aplikace vubec nevi ... tak to proste bez toho, aby to primo podporovala prave aplikace jednoduse nefunguje. A kazdej dodavatel aplikaci ti do podminek dopise, ze to clustering nepodporuje nejpozdejs v okamziku, kdy se na nej obrati prvni zakaznik s tim, ze "mu to z neznamyho duvodu padlo".
Je to uz par patku a nevzpomenu si presne co to bylo, ale pamatuju si ze to melo vyrobit "jeden" server z 1-N fyzickych ... Hral sem si s tim, a blbosti na tom *nejak fungovaly. Ale pak sem na tom zkusil pustit databazi a zacly se dit veci ... deadlocky, timeouty, ...
A tohle plati na vsech urovnich navrhu - databaze trebas umi tableclustering, ale pokud s tim aplikace nativne nepocita, tak v nejlepsim pripade te support posle do rite az zacnes neco resit.
Ve finale dojdes k tomu, ze pokud existuje libovolnej zpusob jak se tomu vyhnout, udelej to, pokud ne, priprav si hodne velkej ranec $$$, protoze to je na custom, vyvoj 1/2 operacniho systemu.
*nejak = nepadlo to nahubu
-
Konkrétně 99% podobných problémů pramení z toho, že každá aplikace na světě implicitně (a naprosto správně) předpokládá, že jak jednou obdrží file descriptor, tak bude zaručeno, že příslušný objekt existuje až do close, je kdykoli přístupný a typ přístupu se průběžně nezmění (samovolné přepnutí do read-only apod.). V distribuovaném prostředí tohle zaručené samozřejmě není a stoprocentně to zaručit ani nejde.
-
Nassir (neregistrovaný)
Sedem rokov dozadu som nasadil na hromadku serverov koli rozkladaniu zataze pri hromadnom stahovani suborov.
Aj ked boli serveri spojene priamo kablom, tak sa to nahodne vyplo. Citanie malych suborov nehorazne pomale - aj ked sa zapla lokalna cache. Opravy po nejakom rozsipani su uplne super - aby si admin hladal zakaznicke data, lebo sw ma zasa svoje dni, a nahodne ich odmazaval, ci sa to nahodou nepreberie...Projekt sa zial zrusil, tak sme par rokov nepotrebovali glusterfs. Pred rokom som ho chcel pouzit znova. NIC sa nezmenilo, iba sa zrusili niektore urychlovacie medzivrstvy a je menej dokumentacie.
Na produkcne nasadenie je to fakt odvaha pouzit. Ale ak Vam to funguje tak mate super nastroj. Mne nahodne nefunguje a trapit sa s tym nebudem...
-
No nestačím se divit... to je opravdu na produkci? A opravdu je split-brainu věnován jen jeden odstavec? Opravdu není v článku vůbec zmíněno quorum?
Já pořád čekám, kdo to řekne na plnou hubu, nejblíž je tomu Jéčko, ale je to asi takhle... Jako školní projekt dobrý, ale pokud by to mělo být nasazeno v produkci, dostupnost systému se cca o řád zvedne jen tím, že to celý hodíme do koše, vše dáme na jeden server, vyřešíme zálohování a v případě problému to nějakou dobu prostě nepojede. V clusteru lze provozovat služby, které cluster podporují a jakékoliv přesvědčování těch ostatních povede jen k těžko, nebo vůbec, řešitelným problémům. Podpora takového řešení se limitně blíží nule a pokud vám za mohutného výpisu kryptických logů a dumpů zdechne celá infrastruktura, tak bude vaší jedinou možností obětování všech oken v celé firmě, pomazání se olejem z olejovek a třídenní nepřetržité modlení se ke svatému tučňákovi.
Hodně štěstí...
-
j (neregistrovaný)
Satane ... 3x se krizuju a polejvam svecenou vodou ... ty jim tady takhle rozbijis babovicky ... od toho abych dostaval minusy sem tu prece vyhradne ja.
Jinak se staci mrknout, jak uzasne funguje trebas replikace databazi ... trochu zaguuglis ... a zjistis ze vsichni resej, co maj delat, kdyz tu repliku maj out of sync. Do kteryhoz stavu se to dostane kdykoli a jakkoli, predevsim pak snadno a casto. Takze vysledek je ten, ze oni resej zlepseni dostupnosti, a ve finale dostanou dostupnost o rad horsi nez kdyby nic nikam nereplikovali a delali blbou zalohu.
A pro zajimavost, ruzny zkaznici ruzny pozadavky ... nejkratsi cas, za kterej prvni zamestnanec zahlasi, ze neco nefunguje po vypnuti SQL serveru (= nefunguje vazne vubec nic) je ... 30 minut. Ale to je vazne extrem. Zcela in natura sem zazil, ze cosi exlo ... a po !4 hodinach! volal sisma ze skladu, ze asi neco nefunguje. Stredni doba reakce se pak pohybuje kolem hodiny. Nikomu neprijde divny ze u kasy ceka 20 lidi a neni jak je zkasirovat ... a pokud jim to divny prijde, tak cekaj asi na smilovani bozi, misto aby zvedli telefon.
Provoz ze zalohy pak pri rozumnym navrhu obnovis do 15 minut. Takze si nikdo ani nevsimne, ze neco nefungovalo.
-
j (neregistrovaný)
Hele me to taky hlava nebere, ale casto kdyz se na to podivas bliz, tak zjistis, ze ryba jak se rika smrdi od hlavy. Na druhou stranu sem opakovane zazil, ze ti volaj "ono nefunguje XYZ" ... abys nasledne zjistil, ze v celym arealu pripadne v polovine mesta nefunguje elektrika. Coz potesi specielne tak kolem 3ti rano.
-
VM maji image nad lokalnim FS (btrfs) a je prakticky read-only. Bojim se, ze na glusterfs by to bylo silene pomale. Pouzivame to jako podklad pro par zakaznickych aplikaci, ktere ukladaji data i mimo databazi (typicky nejake uzivatelske uploady dat) a pak jeste pro git. Na nekolika VM bezi instance gitlabu a repositare jsou mountovane skrze glusterfs. Cele to pak jeste skrze geo-replikaci tece na zalohaci server, kde se z toho delaji snapshoty. Snazime se vyuziti FS stahnout na minimum a drzet data radeji v databazi, ale ne vzdy to jde pohodlne. Vyhledove asi budeme prechazet na neco ve stylu S3 uloziste.
-
Nejde tu upravovat post. Dohledal jsem, že ten problém se čtením se táhne snad všema verzema a NFS je 5x rychlejší.
viz.
https://lists.gnu.org/archive/html/gluster-devel/2014-01/msg00010.html
Tohle je rok 2014 a stejnej problém je i ve verzi 4.
Takže tam je nějaká bota, která dělá tenhle systém nepoužitelnej.
ČLÁNKY DO MAILU