Vraag DRBD versus GlusterFS voor replicatie


Ik moet een oplossing bouwen om interne git-repositories te hosten. Het moet honderdduizenden (of meer) opslagplaatsen ondersteunen.

Ik ben van plan om meerdere "domme" servers te gebruiken met een gedeelde opslag, dus in principe wanneer een client toegang probeert te krijgen tot een repository - het zal door de load-balancer worden omgeleid naar een van de beschikbare servers. Elke wijziging in de repository - wordt gerepliceerd over alle knooppunten.

Mijn eerste gedachte was om GlusterFS daarvoor te gebruiken, maar ik heb gelezen dat het niet goed overweg kan met kleine bestanden. Ik denk er ook aan om alles zelf te repliceren met DRBD, maar dit vereist meer setup en lijkt ingewikkelder in vergelijking met GlusterFS.

Welke van de twee levert betere prestaties op? Eigenlijk is het probleem dat ik probeer op te lossen, dat wanneer een van de servers uitvalt, ik wil dat anderen de gegevens nog steeds kunnen gebruiken.


6
2018-01-28 05:00


oorsprong




antwoorden:


Dit is een klassieke use-to-case, en IMO GlusterFS zou moeten passen. U kunt het proberen. Breng gewoon een paar VM's mee, stel een paar stenen in voor opslag in de opslagplaats en voer een stresstest uit.

DRBD is hier sowieso geen optie - het schaalt niet. Als er iets is, zou ik andere objectopslagprojecten bekijken (bijvoorbeeld Swift), als Gluster niet goed genoeg werkt, maar geen van hen is uiterst prestatiegericht


5
2018-01-28 06:04



Het lijkt erop dat GitHub DRBD gebruikt voor hun opslag (ik denk dat het wel schaalt), maar het leek een overdreven IMO, en ik verkies een gedistribueerde bestandsysteemoplossing waar alles "gewoon werkt". - Gilad Novik
Welnu, het feit dat iemand het gebruikt, betekent niet dat het schaalt. Het betekent alleen dat ze een aantal failover-clusters hebben die DRBD gebruiken, wat niet hetzelfde is als meerdere actieve / actieve bestandstoegangsknooppunten die je kunt krijgen met glipe / swift / ceph / etc - dyasny
Daalt de prestaties van DFS samen met een toenemend aantal knooppunten? - CMCDragonkai
wat heeft DFS met glunk / drbd te maken? - dyasny


Ik had een soortgelijke set-up voor cyrus-mailservers waarin gluscaproblemen de belasting tijdens stress tests niet aankonden. we kozen oorspronkelijk voor gluren omdat het eenvoudig was maar terug moest naar drbd. echter, zoals dyasny benadrukt, is drbd activs / active cfg niet aan te raden (om nog maar te zwijgen van de pijn). als je alle servers nodig hebt om de gedeelde opslag tegelijkertijd te mounten is drbd geen optie. Een ander ding dat je misschien wilt bekijken, is clvmd met lock-manager. lvm2 heeft nu ondersteuning voor raid-type lv en gebruikt hiervoor de man-code. dit gemengd met het juiste bestandssysteem (sommige clusterbewuste degenen indien nodig) kan een optie zijn. maar ik heb het zelf nooit in productie getest, alleen als PoC.


4
2018-01-28 07:17



Slechts één ding dat ik zou willen toevoegen, cluster kon mijn setup niet aan, maar houd er rekening mee dat het een cluster met 2 knooppunten was. Gluster zou zich beter gedragen hebben met meer knooppunten. - alxgomz


Het probleem dat u met Gluster ondervindt, is vooral de wachttijd tussen de knooppunten. Ik zou u adviseren het eens te proberen en te kijken of het uw werklast aankan. Als uw servers krachtig genoeg zijn en een snelle verbinding hebben, zou u een redelijk goede prestatie moeten halen. Misschien wilt u ook de ingebouwde NFS-server proberen, die vanuit mijn ervaring kleine bestanden een beetje sneller verwerkt.

Maar als u uw oplossing zo snel mogelijk nodig hebt, dan is GlusterFS waarschijnlijk niet voor u bedoeld. Andere opties zijn commerciële producten zoals Git Clustering(heb dat nog niet getest) of je zou je eigen oplossing kunnen bouwen met gratis tools zoals gitmirror.


3
2018-01-28 07:48



Eigenlijk is uitvoeringen niet mijn # 1-prioriteit (nog enkele seconden zijn nog steeds goed), maar stabiliteit en replicatie wel. Over welke NFS-server had u het? - Gilad Novik
GlusterFS heeft een ingebouwde NFS-server. De prestaties zijn beter, maar u moet zelf de failover van de clients afhandelen. Aan de andere kant bespaart u uzelf de noodzaak om de FUSE-client te installeren voor toegang tot de GlusterFS-servers. - Izzy


Als u Gluster overweegt (wat naar mijn ervaring bruikbaar is met veel kleine bestanden maar met YMMV), wilt u misschien ook eens naar Ceph kijken http://ceph.com/


2
2018-01-28 10:03



Mijn probleem met Ceph is dat het een meta-gegevensserver heeft, die eigenlijk prestaties schaadt omdat elke gegevenstoegang ook toegang tot de metadataserver vereist. Heb ik het fout? - Gilad Novik
metadata-servers kunnen ook worden gedupliceerd en kunnen op dezelfde knooppunten worden uitgevoerd als objectopslagservers. U moet op elk gewenst moment metagegevens ophalen, of u deze nu ophaalt uit het objectarchief of van de metadataserver, zodat het moet niet aanzienlijke invloed op de prestaties. Ik heb dit nog niet echt geprobeerd. - Wouter Verhelst


Ik zou ook de advertentie van Glustet aanraden, de eenvoudigste en snelst te configureren, configuratie. Ook schalen het heel erg goed. Het probleem is snelheid, en mijn tweede is dat je moet kiezen tussen eenvoudige configuratie en eenvoudige schaalverdeling, en tussen een aantal technische problemen (sommige fraaie drbd / ocfs2 / Glances-blokopslag) met de snelheidswinst. Maar ... hoeveel snelheid krijg je? Je moet wat stresstesten doen en kiezen.


0
2018-01-28 09:08



Ervan uitgaande dat ik de opslag wil uitbreiden, kan ik eenvoudigweg een andere VM aan de lijst toevoegen en deze ernaar repliceren of blokkeert het de toegang tot volledige opslag tot deze VM klaar is om in het cluster te worden gebruikt? Herbalans gebeurt asynchroon? - Gilad Novik
Gluster is te rijgen, dus elke nieuwe steen zal worden toegevoegd aan de ene, enkele, unieke steen. - x86fantini
Dus ik denk dat als ik de snelste manier wil om een ​​steen toe te voegen zonder het cluster te lang te stoppen, ik alleen een vaste lay-out moet gebruiken en geen gegevens migreer? - Gilad Novik