OCFS2 vs NFS

[Snow_King]

Al een tijdje maak ik binnen het bedrijf waar ik werk gebruik van NFS, eigenlijk al onze diensten draaien er op en het werkt prima, maar toch kent NFS (v3) zijn beperkingen, dus werd het toch eens tijd om te gaan kijken naar iets anders dan NFS.

Nu zijn de cluster filesystems steeds meer aan het opkomen en daarom heb ik mijn blik eens geworpen op OCFS2 een clustered filesystem.

Nu weet ik, NFS en OCFS2 zijn fundamenteel heel anders, maar uiteindelijk serveren ze het zelfde doen (in mijn geval), bestanden vanaf één centraal punt R/W beschikbaar maken op meerdere servers.

Het probleem met NFS is onder andere:
* Cache synchronisatie
* Locking
* Hangups

Nu zal ik de hangups eens wat verder verklaren, maar eigenlijk kent iedereen die NFS gebruikt ze wel:

code:

[3362745.908558] nfs: server XXX not responding, still trying
[3362753.895108] nfs: server XXX not responding, still trying
[3362753.896417] nfs: server XXX OK

Hier maak ik voor de performance gebruik van NFS over UDP, nu kan je deze meldingen onderdrukken door je timeout waarde simpelweg te verhogen, echter lost dat de hangup niet op! Het maskeert de melding alleen.

Alle FAQ's zeggen: Controleer je NIC, je netwerk, etc, etc. Maar het blijft gebeuren, dit zit gewoon fundamenteel in NFS v3.

Maar genoeg over NFS, dat was eigenlijk alleen de inleiding, ik ben gaan kijken naar OCFS2 en heb hier wat benchmarks op los gelaten ten opzichte van NFS. Hier heb ik geprobeerd de omstandigheden zo eerlijk mogelijk te houde, al is dat niet volledig mogelijk omdat ze van elkaar verschillen.

Zie daarom mijn benchmarks (PDF). Hierbij moet ik wel zeggen, dit document is geschreven om intern binnen het bedrijf te verspreiden, daarom de korte context.

Mijn vraag aan jullie is, wat is jullie ervaring met OCFS2 of andere clustered filesystems en wat kunnen jullie aanraden? Maak ik verder fundamentele fouten door OCFS2 en NFS zo tegen elkaar te vergelijken?

Wat wellicht nog interessant is om te weten:
* We hosten websites en mailboxes, dat betekend VEEL kleine files
* De totale data omvang (overspreid over 12 storage bakken) is ruim 2.5TB

[Borromini]

Zonder naar je lijstje met vereisten te kijken (), heb je al naar NFS v4 gekeken? Dat is toch een significante update...

[Verwijderd]

Ik begrijp niet helemaal hoe je je setup wilt maken. Je kunt ook een combinatie gebruiken van OCFS2 en NFS.

Als je het over storage servers hebt, dan neem ik aan dat je een high availability oplossing bedoelt? Dan gebruik je wel bijvoorbeeld DRBD en OCFS2 om de files op meerdere storage servers te syncen, en gebruik je bijvoorbeeld NFS of iSCSI om een client de files te laten benaderen.

Een webserver of mailserver zou dan een iSCSI volume kunnen mounten.

Of je zou een stapeltje loadbalanced webservers allemaal kunnen uitrusten met dezelfde DRBD + OCFS2 setup zodat een wijziging (upload in een CMS bijvoorbeeld) direct overal beschikbaar is. Dan heb je niet zozeer aparte storage, maar is toch alle data "safe".

[ Voor 5% gewijzigd door Verwijderd op 24-10-2009 18:39 ]

[Snow_King]

Borromini schreef op zaterdag 24 oktober 2009 @ 18:32:
Zonder naar je lijstje met vereisten te kijken (), heb je al naar NFS v4 gekeken? Dat is toch een significante update...

Nee, ik moet zeggen dat ik dat nog niet gedaan heb. Wat me alleen tegen staat aan de docs van NFSv4 is de security. NFSv3 leent zich érg makkelijk voor een share doordat het zo simpel te configureren is.

Bij NFSv4 krijg je direct te maken met kerberos en andere zaken en dat heeft me tot nu toe ver bij NFSv4 vandaan gehouden.

EDIT: Een korte "Google sessie" bewijst me dat NFSv4 toch wel erg simpel kán draaien.

Laten we dan een kleine draai geven aan dit topic, hoe denken jullie over clustered filesystems zoals OCFS2? Want het voordeel is daarmee wel dat je iSCSI met multi-pathing kan aanleggen er onder wat de redundantie ten goede komt.

@ Cheatah, het gaat mij er om dat de servers oa de mailboxen en websites kunnen lezen. Hier draait nu NFS voor en daar ben ik aan het kijken naar de mogelijkheid om hier OCFS2 of een andere filesystem voor de plaatsen.

Ben verder bekend met DRBD, we gebruiken dat intern om diverse NFS en iSCSI servers HA uit te rusten.

[ Voor 37% gewijzigd door Snow_King op 24-10-2009 18:54 ]

[Borromini]

NFS v4 is inderdaad een stuk complexer qua setup. Uiteindelijk ben ik lokaal van NFS v3 naar sshfs gegaan maar ik weet niet of dat in een bedrijfsomgeving een aangewezen oplossing is...

[Verwijderd]

Soms heb je gewoon een clustered filesystem nodig. Als de klant wil dat alles redundant is uitgevoerd en dat de kans op dataloss minimaal moet zijn, moet je gewoon een block device op meerdere servers hebben met daaroverheen een laagje clustered filesystemsaus in de vorm van bijvoorbeeld GFS2 of OCFS2.

Maar ik zou dit absoluut niet gebruiken als manier om een filesystem van een storage server te "mounten". Ik zou dit wel gebruiken in setups waarin de servers gelijkwaardig zijn. Bijvoorbeeld een loadbalanced webserver en/of mailserver-cluster.

Als je toch aparte storage wilt, gebruik dan OCFS2 om meerdere redundante storage bakken te syncen, maar gebruik NFS of iSCSI of CIFS om je web/mailservers bij de data te laten komen.

[Snow_King]

Verwijderd schreef op zaterdag 24 oktober 2009 @ 18:56:
Maar ik zou dit absoluut niet gebruiken als manier om een filesystem van een storage server te "mounten". Ik zou dit wel gebruiken in setups waarin de servers gelijkwaardig zijn. Bijvoorbeeld een loadbalanced webserver en/of mailserver-cluster.

Met dat idee speelde ik dus ook al. Clustered filesystems zijn aardig gevaarlijk.

Het voordeel met NFS is dat als een client/node er aan gaat, er helemaal niets aan de hand is, alles draait lekker door zoals het al deed.

In theorie kan een rogue client met een clustered filesystem je data heel snel om zeep helpen.

Alleen blijf ik tegen die bottleneck NFS aanlopen.

[Verwijderd]

Snow_King schreef op zaterdag 24 oktober 2009 @ 18:58:

In theorie kan een rogue client met een clustered filesystem je data heel snel om zeep helpen.

Daar heb je fencing voor, maar dat kan een enorme bitch zijn.

[Kees]

Oei, een leuk topic \o/

Ok, NFSv4 is ontzettend eenvoudig op te zetten, het enige wat je moet doen is je exports grouperen in 1 dir en de root exporteren. Verder moet je rpc.idmapd draaien op je clients en dan is het klaar.

Wat is jouw data, en wat is je data je waard? Hier draai ik OCFS2 via iscsi op 6 nodes, waarvan 1 node het exporteerd via nfs naar servers die afentoe eens een file lezen vanaf de shared disk. Het betreft webdata (images, videos - javascripts/css/php staan allemaal op de lokale schijf en worden gersynced door de devvers als zij dat nodig vinden). Mijn data is mij niet bijzonder veel waard, ik heb liever een server die respond met een 403 op een image dan een viertal servers die niet responden en mij met een load van 255 (255 clients / apache) mij uit bed piept.

Vandaar dat ik juist aan het overstappen ben op NFSv4 in plaats van naar een clustered filesystem (wat ik nu dus heb en waar ik niet tevreden over ben, meer daarover later). NFSv4 ga ik met de volgende (relevante) opties mounten:
• noatime - duidelijk, geen acccesstime
• intr - je mag een process dat op nfs wacht interupten
• timeo=2 - als hij na 200 ms geen antwoord krijgt van de server geef een error of probeer het opnieuw
• retrans=1 - probeer het maximaal 1 keer opnieuw
• soft - maak gebruik van de timeo en retrans - maakt de processen killable en de mount geeft errors

Voornamelijk de laatste; als je database servers gaat draaien of mail erop gaat opslaan (in het kort: als je non-reproduceerbare data erop gaat opslaan) dan ben je gek als je die optie neemt. Ik ga er echter vanuit dat een gebruiker een image die hij upload niet meteen weggooit, en in het geval van een error of verrot plaatje deze meteen opnieuw kan oploaden, hetzelfde met video's en bijvoorbeeld door een script gegenereerde grafieken; die zijn allemaal reproduceerbaar en te checken. Op die manier hoop ik binnen een paar weken Tweakers.net via nfsv4 te laten draaien die door een VM geserveerd wordt welke een pacemaker cluster vormt met een vm op een andere server die in principe zo die taken kan overnemen (shared disk = ext4 via iscsi geexporteerd). De details zijn nog niet voor 100% rond, en ik moet nog testen, maar de caching (en state machine) van nfs4 bevalt mij dusver goed. Ik zie in je PDF dat jij ook soft mount, dus ik neem aan dat jij ook over soortgelijke data beschikt.

Ook heb ik een korte tijd UDP gebruikt, maar alhoewel ik hem met soft,intr,timeo=2,retrans=1 had gemount, hing hij op een gegeven moment wel de webserver op met 'error 88', inunteruptable en er werden geen errors gegeven alla 'nfs input/output error'. Na wat greppen in de error includes bleek dt te gaan om een 'socket operation on a non-socket'. Wat het precies was weet ik niet, maar ineens waren al mijn opties invalid blijkbaar. Vervolgens de boel met TCP gemount en geen problemen mee gehad.

Verder. Het gebruik van syntethische benchmarks zegt mij niet bijzonder veel. Ik heb voor mijn benchmark gekeken in de apachelogs welke images uit de image dir opgevraagt werden in een dat. Dit leverde mij een kleine 100.000 files op uit een set van ~1 miljoen files. Deze files heb ik vervolgens met 1-2-4-8-16 clients tegelijkertijd opgevraagt, voornamelijk om de caching te testen. OCFS2 won het hier ruim op, met een gemiddelde snelheid van dik 200MB/s. NFS verloor het met zo'n 75-80MB/s. NFS4 echter ziet er op dat punt so far een stuk beter uit, maar daar heb ik deze test nog niet op gedraaid.

Goed, waarom neem ik nu NFSv4 in plaats van OCFS2 of GFS[1/2].
Ik heb beiden uitgeprobeert en lopen testen.. maar het is teveel voor mijn webserver cluster. Het kan mij echt helemaal niets schelen dat een client geen connectie maakt met anderen, dat de andere dan even niet mogen schrijven vind ik prima, maar beiden zullen je keihard eruit gooien en ook reads blocken. Dus als je 1 server hebt die vervelend doet, dan is je cluster plat. Niet 1 webserver die dan hangt, neen, allemaal. En je minder van shared-disk afhankelijke servers kunnen ineens ook niet meer bij de shared disk komen, kortom JOY!

GFS2 was het eerste wat ik probeerde. Ondanks de afkorting 'GFS = Good-grief-where-the-hell-is-the-documentation File System' lukte het mij het wel om het te instaleren, maar tijdens het testen ging het ontzettend fout. GFS2 was toen nog niet productie ready, maar om nu een file 0 bytes groot te maken als hij groter was dan 3665 bytes vond ik niet leuk. Dus teruggestapt naar GFS1 en dat uiteindelijk in productie gezet. Echter bleek deze ook over bijzonder slechte kwaliteiten te beschikken zoals het uitsluiten van alles en iedereen als het maar een klein beetje fout gaat. Gelukkig was hij nog niet volledig in prodcutie (1 dir gesymlinked) en was het dus heel snel exit voor gfs.

OCFS2 leek een heel stuk beter. Betere documentatie, groter commercieel bedrijf erachter, betere mailinglists, en veeel eenvoudiger op te zetten. En het crashte niet tijdens de tests, of in de weken erna. Na een paar maand gebeurde het afentoe dat OCFS2 ermee kapte, waardoor we uiteindelijk het cluster van 7 nodes naar 6 terugbrachten - 1 oude dev server die er ook op zat aangesloten bleek dermate gevoelig voor load, dat zodra iemand wat ging testen op die bak het hele cluster eruit viel.

En dat ging zo een jaar goed, natuurlijk kon je, als je een kernel update, er donder op zeggen dat het cluster niet meer werkte en ocfs2 hing op 'joining cluster' en natuurlijk werkte een volgende kernelversie ineens wel weer. En natuurlijk moest je zo ontzettend voorzichtig zijn met de servers dat je ze maar geen nieuwe kernels gaf, want unmounten van ocfs2 duurde zo een paar minuten - en mocht je een server hard rebooten; je snapt het al, de rest ging 'even' wachten -> load richting de 255.

Maar de laatste tijd is het helemaal raak. Soms stopt 1 server er gewoon mee, en dan wordt hij soms automatisch gereboot, maar in zeker 50% van de gevallen hangt hij gewoon totdat iemand van ons hem een doodschop verkoopt. Of het hangt heel even, maar ocfs2 vind het niet nodig om de ~60 hangende apache processen ervan te verwittigen dat het filesystem weer terug is. Wat je dan hebt is een load van 60 op de servers, die verder wel gewoon soepel werken en bij het filesystem komen. En niet reageren op kills of unmounts; natuurlijk niet, en apache opnieuw opstarten werkt niet want de hangende apaches blokeren de poort. De oplossing bleek uiteindelijk dat we gewoon 1 server moesten rebooten; ocfs2 schiet dan in de paniek met 'wtf waar is die server' en deed even wat interne checks, en voila ineens daalde de load op de andere servers terwijl we maar 1 server een schop hadden verkocht.

Kortom, voor ons is op dit mometn OCFS2 veel meer werk dan de kleine performance winst die het oplevert. Helemaal omdat NFSv4 weer iets beter werkt dan v3 zijn we daar nu mee bezig. Maar een shared cluster file system komt er voorlopig niet in, tenzij het over een soft mount optie beschikt zoals nfs heeft.

Anyway ik moet er nog verder mee testen, vandaag eerst even een nieuwe server in gebruik genomen waardoor ik weer tijd heb om hier aan te werken. Je zult het ongetwijfeld wel ergens lezen wanneer wij weer terug gaan naar nfs, dat ondanks zijn vele tekortkomingen voor minder downtime heeft gezorgt dan ocfs2 in zijn hele jaar bij ons.

[Snow_King]

Kees schreef op zaterdag 24 oktober 2009 @ 19:40:
Oei, een leuk topic \o/

Ok, NFSv4 is ontzettend eenvoudig op te zetten, het enige wat je moet doen is je exports grouperen in 1 dir en de root exporteren. Verder moet je rpc.idmapd draaien op je clients en dan is het klaar.

Leuk topic en een super reply van je, tnx!

Ja, ik ben toch maar eens gaan spelen met NFSv4 en het was eigenlijk een klusje van niets. Even wennen dat de export paden wat anders zijn, maar dat is niet zo boeiend.

Wat jij verteld over OCFS2 en cluster filesystems is de gedachte die ik er bij had, best wel tricky!

Bij ons zijn frontends, ofwel webservers, mailservers, etc, etc apparaten die uit mogen vallen, alles hangt achter loadbalancers en de frontends moeten rekenen, rekenen en rekenen. Crashen ze een keer ergens door, vervelend, maar meer ook niet.

Dat "voordeel" ben je dus grotendeels kwijt met een cluster filesystem en dat stond me ook al tegen, hoe mooi de benchmarks ook mogen zijn.

Dan wordt het denk ik toch eens tijd om met NFSv4 te gaan spelen waar mijn desktop denk ik een mooi eikpunt is. Mijn /home draait over NFS en als ik in Evolution mijn "Archief" map van mijn mailbox open wil Firefox daarnaast (of eigenlijk de hele desktop) nog wel eens freezen. Dit omdat ik de "server not responding" berichten weer zie.

Als NFSv4 goed presteert voor mijn desktop kan het wellicht wel eens de opvolger gaan worden bij ons, waar de migratie ook nog eens héél makkelijk bij is!

[Kees]

Tja, dat is een open-source project wat iemand wel eens mag opzetten.

Een FS dat:
- met shared disks overweg kan, en dus met andere gebruikers van die shared disk kunnen praten en op die manier kunnen locken (voor writes vnmlijk)
- Niet anaal is met locks, en als je dus geen lock kan krijgen omdat een andere server niet respond, dat je dan maar geen access toestaat op de disk
- Tolerant is - als hij iets niet kan lezen geef dat verdorie dan toe, ga niet hangen op diskio. Ook, degene die de 'D' state heeft bedacht en ervoor gezorgt hebt dat je die processen vrijwel nooit kan afschieten omdat de data zo bloody important is moet dood, i do not care. Liever een plaatje kaput dan een dode site.

En uiteraard eenvoudig op te zetten

[Snow_King]

Kees schreef op zaterdag 24 oktober 2009 @ 22:09:
- Tolerant is - als hij iets niet kan lezen geef dat verdorie dan toe, ga niet hangen op diskio. Ook, degene die de 'D' state heeft bedacht en ervoor gezorgt hebt dat je die processen vrijwel nooit kan afschieten omdat de data zo bloody important is moet dood, i do not care. Liever een plaatje kaput dan een dode site.

Hail, hail! Status D is zwáár irritant.

[CAPSLOCK2000]

glusterfs is wel leuk, daar heb ik recent wat mee zitten spelen.

Het draait bovenop je bestaande filesystem, hierdoor is migratie van/naar glusterfs erg makkelijk. Als er iets mis gaat kun je het filesystem altijd nog benaderen. Ik liep echter in de problemen bij het terug-synchroniseren van nodes die een tijdje waren gedisconnect.

[CyBeR]

CAPSLOCK2000 schreef op maandag 26 oktober 2009 @ 15:32:
glusterfs is wel leuk, daar heb ik recent wat mee zitten spelen.

Het draait bovenop je bestaande filesystem, hierdoor is migratie van/naar glusterfs erg makkelijk. Als er iets mis gaat kun je het filesystem altijd nog benaderen. Ik liep echter in de problemen bij het terug-synchroniseren van nodes die een tijdje waren gedisconnect.

Ik gebruik ook glusterfs in een simpele setup waar ik moet zorgen dat files op twee dozen tegelijk gedelete worden (of ze aangemaakt worden is minder boeiend, dat kunnen ze zelf ook wel). Mirrored over twee dozen heen, werkt eigenlijk zonder moeite en inderdaad: alle files zijn desnoods ook gewoon lokaal te vinden.

Enige nadelen zijn dat 't via FUSE moet (ben ik nooit fan van geweest) en dat er bij mirrored reads altijd om-en-om geread wordt. De realisatie 'deze data is gewoon lokaal te vinden' bestaat niet bij mirrored. Wel bij NUFA (Non-Uniform Filesystem Access) maar dat is dan weer niet mirrored als ik 't goed begreep.

[ Voor 17% gewijzigd door CyBeR op 26-10-2009 15:54 ]

[_JGC_]

GlusterFS ben ik niet echt voorstander van. Misschien dat het nu beter is, maar in mijn tests een jaar geleden zag het er niet echt goed uit:
Pluspunten:
- goede documentatie
- geen gedoe met kernels, alles is userspace
Minpunten:
- configuratie op elke client
- client kan niet reloaden, alleen restarten
- failover niet betrouwbaar, dataverlies!

Het niet kunnen reloaden van client configuratie vond ik een beperking, alhoewel daar nog wel overheen te komen is. De onbetrouwbare failover met dataverlies was ik alleen iets minder over te spreken. OpenOffice tarball uitpakken en halverwege de VM van een storage server afknallen, weer op laten komen, en toekijken hoe een diff -ruN tussen de uitgepakte tarball op Gluster en local disk een flink aantal verschillen tonen, terwijl er nooit een foutmelding tevoorschijn is gekomen. Dat noem ik nou niet echt failover.

[Snow_King]

Met GlusterFS heb ik inmiddels ook wel wat leuks gebouwd. Al onze servers (webservers / mailservers) hebben een 500GB disk, waar we met OS en al nog geen 5GB op gebruiken.

De overige space heb ik met GlusterFS tot een storage omgebouwd (enkele TB's) waar we gewoon wat files op opslaan die we voor de lange termijn nodig hebben.

Maar snel is GlusterFS niet, het is leuk voor wat opslag e.d., maar de performance is gewoon niet hoog genoeg.

[Snow_King]

Inmiddels draai ik (sinds dit topic) al een paar dagen NFSv4 op mijn desktop (/home gaat via NFS) en moet zeggen, draait stukken beter!

Voorheen had ik nog met regelmaat freezes van Firefox als ik in Evolution (mailclient) door wat grote maildirs aan het scrollen was, ook het slepen van mail tussen folders kon al zorgen voor lockups.

Mijn mount ziet er als volgt uit:

code:

192.168.5.250:/employee on /home/employee type nfs4 (rw,noatime,soft,intr,lock,clientaddr=192.168.5.135,addr=192.168.5.250)

Draait hier echt prima, ben érg tevreden. Heb het verder nog niet op servers toegepast en dat stel ik ook nog even uit. Al is de migratie van v3 naar v4 peanuts.