Onderwerp: Storage FS en Gluster

Wij zijn aan het rondkijken om een nieuw storage platform neer te zetten. Dit mag met commerciële software/support maar er wordt nu vooral gekeken naar een systeem als GlusterFS in combinatie met of hardware raid en LVM/XFS of alleen ZFS. Nu weet ik dat er een aantal heel erg tevreden zijn met ZFS maar waar ik wel benieuwd naar ben is waarom. Waarom ZFS en geen RAID met LVM/XFS?

Gluster adviseert XFS. Met name omdat het standaard in de kernel zit. Maar dat is bij Ubuntu bijvoorbeeld weer niet het geval - niet in onze installaties tenminste - dus ik ben niet overtuigd. De storage gaat uitsluitend gebruikt worden voor virtuele servers en we willen graag kunnen schalen in de vorm van extra iops en data. Vandaar dus ook Gluster.

Voor we beginnen met testen was ik benieuwd naar de ervaring van all knowing WHT.

Al een behoorlijke tijd draai ik een fileserver(tje) met XFS op LVM en ging altijd prima. Met Ubuntu 12.04 krijg ik nog wel eens segfaults van xfs bij flinke IO (waarschijnlijk door de nieuwere kernel versie). Na wat zoeken daarop kwam ik een aantal posts tegen waarin afgeraden werd om XFS op LVM te draaien. Waarom dat zo is begrijp ik nog niet helemaal. Ik heb nu wel vm.min_free_kbytes aangepast naar boven, waardoor de segfault flink minder vaak voorkomt, dus misschien is het in mijn geval gewoon een geheugen issue (server heeft maar 4GB RAM).
Mocht je dus XFS op LVM willen gaan draaien is het misschien dus wel even handig dit wat meer uit te zoeken.

Zelf ga ik het ombouwen naar ZFS (op andere hardware), dus heb er verder niet zo veel aandacht meer aan besteed.
Ik heb een aantal machines draaien met ZFS, en dat bevalt mij prima. Het werkt flexibel, en zolang je de deduplication maar uit laat staan heeft het bij mij nog geen rare issues opgeleverd. Je bent ook niet meer afhankelijk van specifieke RAID hardware, wat ik ook een bijkomend voordeel vind.
Welk OS zou je dan willen kiezen voor je ZFS implementatie? (Nexenta/Openindiana/FreeBSD)

Iedere node / brick die we toevoegen zal vol zitten met schijven; we gaan dus niet lopen spelen met het vergroten van LVM volumes bijvoorbeeld maar hebben wel een volume manager nodig in onze setup. Het idee is om meerdere RAID arrays te gebruiken en deze via LVM te bundelen. Volgens mij zijn er weinig alternatieven voor LVM in dat opzicht. XLV is volgens mij niet beschikbaar onder Linux. En we willen het wel graag mainstream houden en niet allerlei custom speelgoed inzetten. Ik ben er zelf nog niet veel over tegen gekomen moet ik zeggen.

Als we kiezen voor ZFS begrijp ik vooralsnog dat je eigenlijk het beste kunt kiezen voor bijvoorbeeld FreeBSD. Iets wat in ons geval niet erg verstandig is omdat er simpelweg de kennis niet voor is. Uiteindelijk zal het wel productie machines gaan draaien. Het meeste ervaring hebben we met RHEL en daarop gebaseerde systemen. Ik verwacht dan ook dat we iets gaan kiezen in die richting. Maar is dat wel slim om samen met ZFS te gaan bundelen?

zfs is wel een freebsd 'iets' uiteraard, maar de linux/fuse is vaak weer een beetje meer up2date (hoger versienummer). Bij ons draait het op verschillende plekken super stabiel.
Wij hebben o.a. een aantal backupservers met honderden zfs filesystems (Voor elke server 2; 1 voor snapshots, 1 voor rsyncs) waarbij wij elk zfs fs (rsync) weer terug in de server (die gebackupped is) kunnen mounten en de snapshot fs'en aan de vps master node. Wel met alleen compressie geactiveerd en geen deduplication.
Dit heeft behoorlijk wat sustained load omdat er doorlopend backups lopen. Mij hoor je niet klagen over zfs+linux dus.

Je moet alleen een beetje opletten dat je niet teveel dingen dubbel gaat doen zoals redundantie op raid (hardware) nivo, dan nog eens op zfs, dan nog eens op gluster.
Voor gluster wil je uiteindelijk wel replicatie om te voorkomen dat je data kwijt raakt bij een totale uitval van een machine.

Als we ZFS gaan gebruiken zullen de controllers als JBOD ingesteld worden. Nog niet kunnen testen maar wat ik begreep vind ZFS het niet erg fijn om samen met raid te werken dus is een JBOD opstelling dan de beste keuze. Op een van onze huidige systemen met striping over meerdere disks/servers zien we soms dat er enkele disks het veel drukker hebben dan andere. In theorie zou dat niet moeten gebeuren maar toch hebben we er last van. Zien jullie hetzelfde?

Het is even wachten tot we wat machines vrij hebben zodat we wat tests kunnen doen. ZFS lijkt wat meer maintenance te hebben dan XFS zover ik kan zien. Het failen van een disk gaat handmatig (?) en is niet een kwestie van de disk eruit trekken en klaar (wanneer deze nog niet onbruikbaar is; maar mogelijk wel problemen geeft). Verder is het vooral een kwestie van smaak en vertrouwen denk ik.

Gebruiken jullie ook gluster bovenop ZFS? Wij zitten deels vast aan NFS en kunnen dus niet overal FUSE gebruiken en dan is gluster leuk maar moet je eigenlijk wel een failover doen. Als proof of concept hebben we dat gesimuleerd met ucarp en dat ging zover ik heb kunnen testen goed. Wat doen jullie daar mee?

Wij hebben sowieso overal hardware raid in, juist om zeker te zijn dat een disk gewoon dood kan gaan. (oftewel, eruit gerukt kan worden als ie begint te rammelen).
Voor zfs maakt dat verder niet uit dan. Doe je het zonder hw raid en heb je dus een redundante zfs 'raid', dan vervang je gewoon de disk en doe je een 'zpool replace' en ben je verder ook klaar.
Ik heb zfs zelf wel op hw raid draaien, maar nooit getest op jbod, dus daar kan ik weinig over zeggen

Je kunt wel, als het goed is, gewoon via fuse je gluster storage mounten en dan dat mountpoint exporteren onder nfs. Dit doe je dan op de client zelf. Is een iets langere weg, maar als je 'vast' zit aan nfs is het zo wel te doen lijkt me? Op de gluster bricks is alle data trouwens ook beschikbaar via het mountpoint van het gluster volume, dus ook daar zou je eventueel een nfsd kunnen draaien...

Verder heb ik zelf nfs alleen nog voor wat iso's en pxe gedoe wat eigenlijk nooit kapot kan gaan en redundant genoeg is. Deze mount ik gewoon direct vanaf een zfs fs ergens (zfs sharenfs). In het geval dat ik nfs failover ergens zou willen, zou ik waarschijnlijk gewoon een dss van open-e installeren en niks zelf gaan prutsen, maar dat is puur een tijd/kosten overweging omdat ik dan niet zelf een failover hoef op te zetten en te testen.
Nadeel is dat je dan wel direct een 1800 euro kwijt bent voor 2 open-e licentes plus het nfs failover feature pack en dat je eigen meer hebt dan je nodig hebt (ook de iscsi, smb, whatever allemaal). Het is leuker en leerzamer om dit zelf uit te vogelen in idle tijd, maar als je die kosten op je klanten kunt verhalen door het stukje extra zekerheid/coolness dan hoeft dat niet eens zo duur te zijn aangezien je al snel een hele hoop tijd aan testen kunt overslaan.

Nadeeltje van gluster bij een kapotte brick is dat je direct een veelvoud van 2 bricks (afhankelijk van je replicatie aantal) eruit moet mikken en daarna weer toevoegen. Het rebalancen van de data kan, zeker bij grote hoeveelheden, best wat tijd in beslag nemen. Dus zeker bij tb's per brick wil je wel 10gbe ertussen hebben liggen.

Wij gebruiken overigens gewoon ext4 onder GlusterFS. Volgens mij zit de pijngrens op 16 TB en onze grootste share is 14 TB, dus daar nog geen problemen. De grap is dat Gluster lange tijd heeft gezegd: "Gebruik ext4 want XFS en dergelijke zijn niet volledig getest.". En nu zeggen ze "Gebruik XFS want ext4 en dergelijke zijn niet volledig getest.". In ieder geval voel ik mij prettig bij ext4 en voor de toepassing waar wij het voor gebruiken werkt het prima. ZFS (op Linux) vind ik persoonlijk te experimenteel.

We hebben nu twee servers met met RAID5 en XFS met Gluster draaien en lopen nu echt tegen wat vreemde problemen aan. Allereerst ondersteunt 3.3.0 geen VMware. Het aanmaken van servers is geen probleem maar het starten is onmogelijk. Een upgrade naar een QA release lost het op maar alleen hierdoor valt Gluster in principe al af. In ieder geval voor een live omgeving.

Toch nieuwsgierig en we draaien nu 3.3.1qa1. Het starten van een server binnen VMware werkt. Een storage migration alleen niet. Misschien niet de beste test met maar 1 pool maar er zijn twee verschillende volumes aangemaakt en tussen deze twee willen we de migratie uitvoeren. Deze blijft hangen bij 13 procent. Ik zie nergens iets terug komen in nfs.log en ik wil hier ook niet teveel tijd aan besteden om op te lossen tenzij we echt iets over het hoofd hebben gezien bij de configuratie. We zoeken geen plug & play omgeving maar wel iets wat in principe gewoon werkt.

Zijn er commerciële oplossingen die ongeveer doen wat ZFS en Gluster in combinatie kunnen? Als ze Gluster gebruiken is prima zolang de support maar goed genoeg is. Heeft er iemand andere ervaringen?

Voordat je GlusterFS gaat gebruiken als storage voor VM images, zou ik eerst een paar performance tests doen. Pas sinds de laatste versie (3.3) zit er een feature in die het mogelijk maakt om tijdens een recovery je images te gebruiken. Op de gluster mailinglists staan een aantal berichten over tegenvallende performance. Dit is natuurlijk altijd afhankelijk van het exacte gebruik. Ook moet je rekening houden dat direct I/O niet werkt met gluster (voor zover ik weet dan) en de VMs dus niet met cache=none opgestart kunnen worden. Er zitten ook wat verschillen in functionaliteit als je de gluster-client (fuse) gebruikt of de nfs koppeling van gluster.

Je zou ook eens kunnen kijken naar MooseFS of Ceph. Moosefs heeft ook wat problemen met VM images en performance. Ceph heeft net de eerste supported versie uitgebracht, 0.48 (argonaut), het is nog geen 1.0 versie, maar er zijn behoorlijke vorderingen gemaakt.

Oorspronkelijk geplaatst door getUP

We hebben nu twee servers met met RAID5 en XFS met Gluster draaien en lopen nu echt tegen wat vreemde problemen aan. Allereerst ondersteunt 3.3.0 geen VMware. Het aanmaken van servers is geen probleem maar het starten is onmogelijk.

Ik vind het een beetje voorbarig om te zeggen dat GlusterFS geen VMware ondersteunt. Ik zou eerder zeggen VMware ondersteunt geen GlusterFS Gebruik je NFS?

Oorspronkelijk geplaatst door getUP

Misschien niet de beste test met maar 1 pool maar er zijn twee verschillende volumes aangemaakt en tussen deze twee willen we de migratie uitvoeren. Deze blijft hangen bij 13 procent. Ik zie nergens iets terug komen in nfs.log en ik wil hier ook niet teveel tijd aan besteden om op te lossen tenzij we echt iets over het hoofd hebben gezien bij de configuratie. We zoeken geen plug & play omgeving maar wel iets wat in principe gewoon werkt.

Uhm je wilt een live migration doen tussen twee volumes? Naar mijn mening wil je juist een enkel volume aanmaken en op iedere hypervisor mounten. Zo kun je (dankzij de granular locking van GlusterFS) een live migration doen aangezien het bestand op één volume staat. Je wilt naar mijn mening dus één storage pool (cluster), met één volume (vmstorage) die minimaal twee bricks (server1, server2) heeft met replication.

Dat je niet op een beta versie wilt draaien geef ik je groot gelijk aan. Ik denk dat de QA versie over een paar weken wel final zal worden.

Je hebt met VMware en GlusterFS geen andere mogelijkheid dan NFS. Wat betreft de problemen, zie ook: https://bugzilla.redhat.com/show_bug.cgi?id=835336. Het gaat dus om de NFS implementatie van GlusterFS.

Je wilt naar mijn mening dus één storage pool (cluster), met één volume (vmstorage) die minimaal twee bricks (server1, server2) heeft met replication.

Ik snap de achterliggende gedachte maar daarmee testen we natuurlijk niet of een storage migration in VMware mogelijk is. Zodra we deze starten gebruikt Gluster ongeveer 50% CPU en blijft deze hangen. Er gebeurt verder helemaal niets. Geen informatie in de logs, nul komma nul.

Ik ben helaas te weinig bekend met VMware om hier iets zinnigs over te zeggen. Het is bij Linux KVM in ieder geval de bedoeling dat bij een live migration het bronbestand gelijk is aan het doelbestand en dat je op beide hypervisors gelijktijdig kunt lezen en schrijven in je disk image. Naar mijn mening bereik je dat alleen als je één volume gebruikt voor beide hypervisors.

Wellicht kun je met iotop iets meer info krijgen over je hoge CPU gebruik?

Wat betreft XFS op Ubuntu, dit zou volgens mij geen probleem moeten zijn.
Ik zou het alleen niet als root filesystem gebruiken

Oorspronkelijk geplaatst door MediaServe

Het is bij Linux KVM in ieder geval de bedoeling dat bij een live migration ...

Bij VMware heb je diverse live migraties. Waar jij aan denkt is een zogenaamde "VMotion" een migratie van de host waar de machine wordt uitgevoerd.
GetUp heeft het over een andere live migratie. Een zogenaamde SVMotion, een storage migratie. Hierbij wordt de virtuele machine storage lokatie verplaatst van LUN1 naar LUN2. Dit kan je bijvoorbeeld doen omdat je meer ruimte nodig hebt voor de VM of omdat je de VM naar een LUN wilt verplaatsen die beter presteerd.

We zijn ondertussen overgestapt op een test versie van Nexenta. Gluster was voor ons teveel werk om op te zetten en zoals al eerder gezegd werd is dat een overweging die je moet/kunt maken. Tot zover positief over Nexenta maar we zijn nog niet klaar met testen.