PDA

Bekijk Volledige Versie : NFS-storage redundantie



kuipie85
10/06/13, 17:09
Op dit moment hebben wij 6 fysieke servers, welke geïnstalleerd zijn met Proxmox VE. Hierop draaien een aantal virtuele machines, voornamelijk met Windows Server 2008 R2.
De fysieke servers zijn Intel Blade servers met een centrale RAID5-storage en hebben toegang tot een Intel Shared LUN. De centrale opslag is verbonden met één van de bladeservers en bevatten disk images van alle VM's. Deze disk images zijn toegankelijk via NFS en worden aangeroepen vanuit de fysieke servers.
Omdat de NFS-host enkelvoudig is uitgerust, hebben we ongewild een Single Point of Failure gecreëerd. Bijvoorbeeld, wanneer de NFS-host om een bepaalde reden niet opstart, zullen de VM's ook niet kunnen opstarten, omdat zij hun disk image niet kunnen benaderen.

Daarom de vraag hoe en met welke software de NFS-opslag is om te bouwen naar een redundante fail-proof opslag, zonder dat er iets gebeurd met de bestaande VM disk images.
Het zou bijvoorbeeld een fail-over systeem kunnen zijn, zodat wanneer de primaire NFS-host niet bereikbaar is, een tweede NFS-host die taak automatisch overneemt.
Wat zou de optimale oplossing voor het beschreven probleem zijn?

NixDevs.com
10/06/13, 18:00
Optimale oplossing: DR:BD (http://www.drbd.org/)

systemdeveloper
10/06/13, 20:04
drbd is een goede oplossing, gebruik ik ook op veel plekken.
Er komt wel iets meer bij kijken dan alleen de drbd software (pacemaker, corosync, cman e.d.) en het kan een beetje een pain in the ass zijn om het goed op te zetten (met name het fencing deel).
Voordeel is wel weer dat je het kunt opzetten zodat je beide storageservers tegelijk kunt benaderen (active/active).

Wil je iets wilt dat je in een paar minuten opzet, maar waar je ook een paar centen aan uit moet geven (dan heb je uiteraard wel support en een mooie webinterface) dan kun je naar open-e kijken. (Als je maximaal 2tb ruimte gebruikt voor je storage en geen gebruik maakt van bonding, kun je de gratis versie gebruiken!).

kuipie85
12/06/13, 10:06
Bedankt voor de reacties. We zullen DRBD en Open-E eens onder de loep nemen.
Vooralsnog lijkt de eerste het de meest voor de hand liggende oplossing.