Ervaringen advanced network filesystems

[froggie]

Op m'n werk draaien wij hosten/beheren mijn collega's en ik een webapplicatie (Tomcat based, MMBase met een "laagje"). Om een bepaalde beschikbaarheid te garanderen hebben wij een cluster gebouwd waarin alle hardware en software dubbel is uitgevoerd. De files (en dan met name uploads van gebruikers) worden tussen de web nodes gesynchroniseerd dmv NFS en Rsync. Deze setup voldoet voor 2 web nodes (het werkt, maar daar is alles mee gezegt) maar is verre van schaalbaar. Door groei van het aantal gebruikers zijn wij genoodzaakt ons cluster uit te breiden (en in dit geval eigenlijk volledig opnieuw ontwerpen).

De nieuwe setup wordt voor alsnog als volgt:
2 LVS nodes, 3 web nodes en 2 file/db nodes.

Om het probleem met filesynchronisatie op te lossen willen wij gebruik gaan maken van een network filesystem zoals (Open)AFS of Coda. Het is hierbij de bedoeling dat de webnodes een fs van de file/db nodes mounten en hier de te serveren pages vandaan halen en eventuele uploads naartoe wegschrijven. Als het even kan moeten de file/db nodes dmv replicatie hun filesystem consistent houden, zodat ten alle tijden een failover situatie gewaarborgd blijft.

Voordat ik begin met het testen van deze opstelling ben ik benieuwd of hier mensen zijn die ervaring hebben met het gebruik van OpenAFS en/of Coda in een dergelijke opstelling. Ik lees bijv in de OpenAFS documentatie dat replication eigenlijk alleen toe te passen is op min of meer statische volumes. Aan de andere kant zou Coda volgens sommige mailinglists en fora nog niet geschikt zijn voor een productieomgeving.
Zijn er eventueel andere, al dan niet commerciele oplossingen, voor het probleem wat ik hier schets? Op dit moment gebruiken wij Suse SLE9, maar de enige eis die er ligt is dat het op een manier compatible is met onze Apache/Tomcat/MySQL/Java omgeving.

[ Voor 3% gewijzigd door froggie op 23-11-2005 20:17 ]

[Aike]

Als ik het goed begrijp wil je dus een harde schijf op meerdere webnodes tegelijk read/write mounten? Of wil je die harde schijf op een of andere manier ook nog load balancen naar verschillende storage nodes? Tekeningetje?

Het enige product dat ik ken en een partttie op 2 machines tegelijk kan read/write mounten is PeerFS van Radiantdata.

[Wilke]

Al een paar jaar oud, maar mischien nog wel relevant: Kees in "Network file systems (coda,nfs,samba,ftp..."

[froggie]

Gezien het tempo waarmee sommige van deze filesystems ontwikkeld worden is de post nog redelijk relevant.

Een erg interessante optie, die ik via de post van Kees vond, is Lustre. Ik ga vanaf volgende week eens uitgebreid testen met dit fs.

[eborn]

Froggie schreef op donderdag 24 november 2005 @ 19:27:
Gezien het tempo waarmee sommige van deze filesystems ontwikkeld worden is de post nog redelijk relevant.

Inderdaad

Een erg interessante optie, die ik via de post van Kees vond, is Lustre. Ik ga vanaf volgende week eens uitgebreid testen met dit fs.

Laat even weten hoe het gaat Ik ben namelijk ook met dit vraagstuk bezig. Uiteindelijk lijken alle wegen weer bij NFS uit te komen, maar toch vertrouw ik het niet helemaal. Vooral omdat onze servers allemaal Linux draaien

[MikeN]

Froggie schreef op donderdag 24 november 2005 @ 19:27:
Gezien het tempo waarmee sommige van deze filesystems ontwikkeld worden is de post nog redelijk relevant.

Een erg interessante optie, die ik via de post van Kees vond, is Lustre. Ik ga vanaf volgende week eens uitgebreid testen met dit fs.

Ben je al wat verder met Lustre? Ik heb er nu even naar gekeken en heb nog niet echt de mogelijkheid gevonden om je storage ook redundant uit te voeren. Ze gaan steeds ervan uit dat je een enterprise-grade storage array hebt en dat dat ding maar niet faalt, alleen de servers naar die storage toe zijn redundant uit te voeren. Klopt dit, of kan dit wel redundant uitgevoerd worden?

[killercow]

Ik ben hier zelf ook mee bezig,

Ik beheer een cluster met 2 LVS servers, 3 web-nodes, 1 mysql en 1 file server.

Ik ben tot de volgende conclusie gekomen:

Ik heb per web-node een 18gb disk, welke het OS bevat, en op het moment ook de 5gb grote webroot.
De webroot wordt via een rsync achter systeem naar de fileserver gerepliceerd, wat lood en lood zwaar is. (en ook nog eens 5 minuten delay geeft)

Nu heb ik een Sun Fire x2100 gekocht met 2 200gb sata disks (heel mooie en goedkope machine), en wil ik deze als fileserver inzetten.

De web-nodes gaan de webroot nu vanaf de fileserver mounten via NFS.
NFS zelf is snel zat heb ik het idee, en omdat ze allemaal de NFS dir mounten heb ik geen repliceer problemen.

Als Trucje heb ik besloten om elke webnode 5gb swap space te geven op de lokale hdd.
Hierdoor wordt het merendeel van de NFS requests door lokaal geheugen of swap afgehandeld, wat de performance behoorlijk ten goede moet komen.

Doordat NFS als het goed is de cache op de nodes netjes up to date houdt (aka, aangepaste of verwijderde files worden uit de lokale mem/swap gehaald) ben ik altijd uptodate, heb ik geen repliceer problemen, en kan ik gemakkelijk de performance upschalen door meer echt geheugen, meer nodes of een snellere verbinding te gebruiken.

Het enige probleem zij file-locks, maar de gemiddelde lamp applicatie schrijft bizar weinig, dus daar kom ik wel mee weg.

[killercow]

MikeN schreef op vrijdag 23 december 2005 @ 00:33:
[...]


Ben je al wat verder met Lustre? Ik heb er nu even naar gekeken en heb nog niet echt de mogelijkheid gevonden om je storage ook redundant uit te voeren. Ze gaan steeds ervan uit dat je een enterprise-grade storage array hebt en dat dat ding maar niet faalt, alleen de servers naar die storage toe zijn redundant uit te voeren. Klopt dit, of kan dit wel redundant uitgevoerd worden?

Als je dan toch een echter storage oplossing hebt (aka fibrechannel), dan kun je beter GFS gebruiken, wat redhat aanbiedt., deze is ook op dat level redundant.

[eborn]

killercow schreef op vrijdag 23 december 2005 @ 11:54:
Als je dan toch een echter storage oplossing hebt (aka fibrechannel), dan kun je beter GFS gebruiken, wat redhat aanbiedt., deze is ook op dat level redundant.

Op zich kun je GFS ook gebruiken zonder groot storage array. GFS over iSCSI over IP over Gigabit Ethernet bijvoorbeeld Maar ja, zoals je al aangeeft kom je dan weer in een hele andere markt terecht

Ik probeer zelf onze hoofd mailserver redundant te krijgen. Twee identieke machines die uiteindelijk via een LVS moeten gaan werken. Maar de data storage blijft het grootste probleem. Er zit geen storage oplossing achter (vanwege de kosten en als men er wel geld voor vrij kon maken zou het een veredelde pizzadoos worden ) dus zie het zaakje maar eens in sync te houden

[froggie]

Ik heb mezelf eens een paar weken flink in dit probleem verdiept (best leuk, hobbien op kosten van de baas ) en heb tot nu toe de volgende resultaten:

Lustre is interessant project, zeker als je een groot netwerk hebt met 100+ clients en 10 fileservers (al dan niet bijgestaan door verschillende achterliggende opslagsystemen). Lustre verlost je echter nog niet van het data replicatie probleem (zoals ik ten onrechte dacht). Server raid1 en raid5 staan wel op de roadmap, maar dat zal niet eerder production ready zijn dan ergens volgend jaar. De performance van datgene wat er al wel is is wel goed, zeker wanneer je gebruik maakt van meedere clients en filelocking. Het voelt dan allemaal net ff wat sneller aan dan bijv NFS.

Voorlopig vallen wij toch weer terug op NFS. We hebben dit echter gemixed met DRBD (data replicatie over 2 servers) en Heartbeat. Als je dit eventueel nog combineerd met bijv de bonding ethernet driver in de Linux kernel is een verrassend stabiel en goede werkend NFS failover setup te bouwen. Het voordeel van deze setup is dat het redelijk eenvoudig blijft en bovenal redelijk goed gedocumenteerd (je moet wat zoeken hier en daar, maar alle puzzelstukjes zijn gedocumenteerd).
Ons cluster is nog ver van af, maar voorlopig ziet het er goed uit. Wordt vervolgd...

[ Voor 6% gewijzigd door froggie op 17-01-2006 09:09 ]

[eborn]

Froggie schreef op dinsdag 17 januari 2006 @ 09:07:
Voorlopig vallen wij toch weer terug op NFS. We hebben dit echter gemixed met DRBD (data replicatie over 2 servers) en Heartbeat. Als je dit eventueel nog combineerd met bijv de bonding ethernet driver in de Linux kernel is een verrassend stabiel en goede werkend NFS failover setup te bouwen. Het voordeel van deze setup is dat het redelijk eenvoudig blijft en bovenal redelijk goed gedocumenteerd (je moet wat zoeken hier en daar, maar alle puzzelstukjes zijn gedocumenteerd).
Ons cluster is nog ver van af, maar voorlopig ziet het er goed uit. Wordt vervolgd...

Het zal je niet verbazen dat ik tot precies dezelfde conclusie ben gekomen

NFS met de door jou aangedragen combinatie lijkt gewoon het meest stabiel. Qua performance schaalt het niet, maar het biedt wel failover mogelijkheden, en dat is voor de meeste standaard oplossingen voldoende (en het belangrijkste).

[froggie]

Het schaalt inderdaad niet geweldig, maar voor een klein cluster is het voldoende. Mocht je een beter schaalbare oplossing zoeken dan zou je Lustre kunnen proberen bovenop DRBD. Met 4 stevige nodes kun je dan een flink filecluster bouwen waarvan de performance voor 100+ clients voldoende moet zijn en waarmee failover toch gewaarborgd blijft.
Wellicht wordt NFS4 straks ook een optie.

[eborn]

Ben je er overigens al uit hoe je je DB gaat repliceren?

[froggie]

Ik wil het filesystem waar de DB op staat repliceren via DRBD, zodat ik niet afhankelijk ben van de replicatie mogelijkheden van MySQL (waar ik niet zulke beste ervaringen mee heb). Op die manier heb ik in iedergeval een coldstandby. Het schijnt mogelijk te zijn om met MySQL en Heartbeat hetzelfde truukje uit te halen als dat je dat met NFS kunt doen, maar ik vind dit nogal eng omdat we geen gebruik maken van transacties en je in theorie je DB dus kunt vernaggelen bij het switchen van de ene machine naar de andere. Daarnaast is de DB een beetje de Achilles hiel van de applicatie en ik kan niet goed overzien of er geen cache inconsistentie onstaat binnen de applicatie wanneer tijdens een query de DB server switched. Ik denk dat we de MySQL devs maar eens achter hun vodden aan moeten zitten zodat 5.1 snel opgeleverd wordt

[Coen Rosdorff]

Ik las pas op LWN dat Oracle tegenwoordig ook een Cluster Filesystem onder GPL heeft vrij gegeven:
Versie 1: http://oss.oracle.com/projects/ocfs/
Versie 2: http://oss.oracle.com/projects/ocfs2/

Voor mensen die een expiriment wel kunnen waarderen misschien wel een aanrader.

[froggie]

Naar wat ik begrepen heb is OCFS2 een filesystem wat eigenlijk alleen bedoelt is voor gebruik met Oracle RAC, en dus niet volledig general purpose zoals ze zelf beweren. Aan de andere kant heb ik me totaal niet verdiept in dit filesystem dus het zou goed kunnen dat ik nu poep praat

Wellicht is het een testrun waard, zeker gezien het feit dat het al in aardig wat distro's standaard geintegreerd is, dit itt bijv Lustre.

[eborn]

Froggie schreef op woensdag 18 januari 2006 @ 15:18:
Naar wat ik begrepen heb is OCFS2 een filesystem wat eigenlijk alleen bedoelt is voor gebruik met Oracle RAC, en dus niet volledig general purpose zoals ze zelf beweren. Aan de andere kant heb ik me totaal niet verdiept in dit filesystem dus het zou goed kunnen dat ik nu poep praat

Als ik het zo lees was OCFS1 daar voornamelijk voor gemaakt. Maar OCFS2 hoort een all-purposes FS te zijn. Als je de site mag geloven