Onderwerp: GlusterFS Schaalbaarheid voor Storage.

Oke, vond dat dit toch even een plaatjse verdiende in dit forum. En vond niet echt mooie topics.

Wat is Gluster ?
GlusterFS is een beetje vergelijkbaar met DBRD. Een van de grote verschillen is dat je makelijk de cluster ook kan uitgroten.

Zoals bij DBRD kan je echter wel nodes bij voegen voor meer load balancing te krijgen maar niet echt voor meer storage cap.
Dit kan je bij gluster dus wel. Ook kan je gewoon rebalance als je nodes gaat bij plaatsen.

Wat houd dat dan in ?
Laten we snel eventjes een voorbeeld nemen.
Als je 2 Nodes hebt bij gluster en je gaat die 2 draaien in dual parity. Dan zullen all je files op beiden server geplaatst worden en kan een van je servers uitvallen en zal je newerk nog altijd aan alle files kunnen. Tot zo ver nog het zelfde als DBRD.

Maar! als je nu zegt, ik wil meer storage gaan hebben in men clustertje. Dan zorg je dat je nog 2 nodes bij koopt. Plaast de 2 nieuwe nodes in je bestaander cluster en maakt de 2 nieuwe nodes ook parity 2. Dan maak je dezelfde folder aan dat je in je eerste node hebt. Nu heb je 4 servers waar je je files op dropt waarvan er 2 redundant zijn.

Wat is er dan zo prachtig aan Gluster. Nu dat je die 2 nieuwe nodes hebt staan all je files nog op de oude 2 Nodes, en belast je iegenlijk alleen die 2 oude.
Je kan gewoon eventjes een "Rebalance" commandotje in je gluster console invoeren en gluster gaat rusting alle files beginnen herverdelen over de oude en nieuwe servers.

Instalatie.
Dit is poep simpel. Als je het eventjes wil testen, start eventjes 4 VM's en zet er Debian ofzo op. En zorg dat je een koekje, glaasje melk en ongeveer 15 minutjes tijd hebt. Meer tijd heb je niet nodig om een fully working GlusterFS Cluster te maken over 4 nodes (kan ook meer of minder)

Waar moet je rekening me houden?
Je parity nummer is hoeveel keer je dezelfde files wil redundant hebben staan. 2 = 2 servers dezelfde files. Je kan van 2 tot en met 5 gaan maar meer dan 3 is overkill.
Als je dan nodes gaat toe voegen om je meer Data cap te geven. Dan moet je wel rekening houden met je Parity nummertje. Als je Parity 3 neemt, moet je telkens 3 Nodes aan je cluster toevoegen.

Connection naar de Cluster ?
Er zijn heel wat manieren om dit te doen. Maar de simpelste en snelste is via de FUSE based client van Gluster. Dit is een kleine app die je op de OS kan instaleren.
In korte lijnen, Deze tool verbind met je node's en zal er voor zorgen dat je data vertrekt en aankomt. Dus je OS zal praten met de FUSE, en de FUSE met de cluster.

Waarom FUSE?
Het voordeel aan dit is dat de client rekening kan houden met de servers hun belasting. FUSE houd in de gaten welke cluster node's online zijn en of ze het niet te druk hebben. En op basis van die info zal hij de request naar de beste server sturen, om zo de snelste data verwerking te krijgen.

Meer weten over GlusterFS ? Of de Gluster Client? Of eventjes een prachtige use case post op OC.

Vroeger ook wel eens mee geknutseld. Ik geloof zeer in gedistribueerde opslagsystemen zoals bv GlusterFS.
Echter voelde GlusterFS toen erg experimenteel aan.
Uiteindelijk met Scality software verder gegaan (http://www.scality.com/)

Oorspronkelijk geplaatst door PimEffting

Vroeger ook wel eens mee geknutseld. Ik geloof zeer in gedistribueerde opslagsystemen zoals bv GlusterFS.
Echter voelde GlusterFS toen erg experimenteel aan.
Uiteindelijk met Scality software verder gegaan (http://www.scality.com/)

Gluster is nog relatief jong. En het is maar sins kort dat de releases van Gluster echt zeer stable aant worden zijn. Hoop dat ze nog meer gaan implementeren.
Wat wel fijn is, is dat software zoals proxmox gewoon all ingebouwde compatibility heeft met GlusterFS.

Ik kijk bij iedere HA implementatie weer naar GlusterFS, maar het blijft traag met kleine bestanden/bewerkingen. Voorlopig dus nog DRBD.

Google maar eens op "apache webserver glusterfs". Dan begrijp je wat ik bedoel.

Sent from my GT-I9505 using webhostingtalk mobile app

Oorspronkelijk geplaatst door 24x7hosting

Ik kijk bij iedere HA implementatie weer naar GlusterFS, maar het blijft traag met kleine bestanden/bewerkingen. Voorlopig dus nog DRBD.

Google maar eens op "apache webserver glusterfs". Dan begrijp je wat ik bedoel.

Maar dat is inherent aan de oplossing. DRBD is een block device wat onder water wordt gerepliceerd. Daar werk je dus lokaal en heb je niet de netwerk overhead die je bij Gluster wel hebt. Het is niet geschikt als onderliggende storage voor je applicatie en daar moet je het dus ook niet voor in zetten.

Dat ligt er maar net aan hoe je DRBD inricht, voor write wacht hij wel degelijk (in ieder geval bij ons) tot ie de andere kant zegt "succesvol geschreven". Wij hebben diverse DRBD clusters draaien met minimaal 4x 1 Gbit er tussen (direct) en moet zeggen dat dit bijzonder bevalt.

Ook wij kijken in de toekomst naar GlusterFS ,maar kijken nog heel even de kat uit de boom

Voor backup storage zijn we naar Nexenta aan het kijken op dit moment, mocht dat bevallen.... dan gok ik zomaar dat we daar ook mee gaan kijken of een HA storage goed te doen is e.d.

Oorspronkelijk geplaatst door Bart L

Dat ligt er maar net aan hoe je DRBD inricht, voor write wacht hij wel degelijk (in ieder geval bij ons) tot ie de andere kant zegt "succesvol geschreven".

Maar dat is iets anders dan het laden van de applicatie over het netwerk. Het ligt een beetje aan de writes die je uitvoert en hoe vaak je dit doet, maar voor de meeste applicaties is dit minder dan de reads. Er zijn behoorlijk wat bestanden die je niet in de synchronisatie mee wilt hebben (bijv. logging, temporary files, misschien wat caching). Daarmee beperk je de latency van writes nog verder. En het weg schrijven van een PDF of ander bestand is minder afhankelijk van de netwerk overhead dan dat het lezen van ~200 applicatie bestanden per bezoeker is.

Het opzetten van GlusterFS is inderdaad vrij simpel. Ik heb ook gekeken naar ceph, dat is toch wat complexer.

Ceph is inderdaad vrij complex om op te zetten, maar dit heb ik ooit wel met een groepje voor elkaar weten te krijgen. Ik kan zeggen: zodra je het werkend hebt, werkt het echt heel fijn! Het heeft in principe een steile leercurve, maar dat wordt wel beloond!

Oorspronkelijk geplaatst door Bart L

Dat ligt er maar net aan hoe je DRBD inricht, voor write wacht hij wel degelijk (in ieder geval bij ons) tot ie de andere kant zegt "succesvol geschreven". Wij hebben diverse DRBD clusters draaien met minimaal 4x 1 Gbit er tussen (direct) en moet zeggen dat dit bijzonder bevalt.

Ook wij kijken in de toekomst naar GlusterFS ,maar kijken nog heel even de kat uit de boom

Voor backup storage zijn we naar Nexenta aan het kijken op dit moment, mocht dat bevallen.... dan gok ik zomaar dat we daar ook mee gaan kijken of een HA storage goed te doen is e.d.

Heb je je Gigabit links op infiniband staan ?
Als je dat doet kan je veel meer uit je netwerk halen, en als er packets verloren gaan, dan zorgt de cluster er wel voor dat ze er toch komen. De netwerk checksum is niet echt nodig, toch?