Vlákno názorů k článku Velká řešení otevřeně: souborový systém GlusterFS od Yenya - Škoda že na začátku článku není aspoň nějaké...
-
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.
