Ik ben al tijden op zoek naar een mooie "fail-safe" oplossing voor onze ontwikkelomgeving.
Momenteel hebben we één machine met KVM. Deze machine deelt een data partitie met z'n clients over NFS.
Dit houd de client images klein en maakt het gemakkelijk om de backups op één plek te regelen.
Deze situatie heeft een hoop nadelen, waarvan de grootste is dat deze ene machine een te groot risico is.
Backups maken we genoeg, maar alle data terugzetten na een failure zal wel veel tijd in beslag nemen.
Wat mij een mooie oplossing leek was om 2 (relatief simpele) identieke machines aan te schaffen die beide exact hetzelfde gaan doen. Beide krijgen een hypervisor, in dit geval KVM, en beide kunnen dus de VM's draaien. In de praktijk zullen de VM's (er zijn nu nog maar 4 "kritieke" VM's) ook verspreid worden over beide servers.
In het geval van een failure moet één van de twee machines alle taken kunnen overnemen, vrijwel zonder downtime. Of in ieder geval zo min mogelijk. De beste manier om dit te realiseren is door te repliceren, waar GlusterFS om de hoek komt kijken.
Ik ben er redelijk van overtuigd dat dit te realiseren is, met naar mijn idee meer garanties dan één enkele dure server. We kunnen uiteindelijk nog een machine aanschaffen, die ook weer een replica zal zijn, om zowel meer rekenkracht te krijgen als veiligheid.
Het knelpunt is de concessie die we moeten doen in snelheid. VM's draaien vanaf een Gluster mount (via NFS, niet de native client) is re-de-lijk te doen. Een benchmark in de VM geef schrijf snelheden van maximaal 40MB/s, hier kan ik mee leven. Het probleem ontstaat zodra 4 VM's tegelijk veel moeten schrijven of lezen. Theoretisch moet de bandbreedte van 1Gbit direct al door 4 gedeeld worden. Met overhead zal dit per client niet meer dan 15 - 20 MB/s betekenen.
Ook houd ik straks het liefst de data binnen de VM's zelf, zodat deze ook als enige gescyned hoeven te worden. Dit kan VM's van 100GB+ betekenen. Is dit dan wel te realiseren?
De andere optie zou weer kleine VM's zijn en alleen de data syncen. Het nadeel is dat VM images dan een dag achter kunnen lopen op de andere machine. Wat bij een failover misschien voor rare situaties kan zorgen.
Om een lang verhaal kort te maken: zoek ik het wel in de goede hoek?
Is er iemand die überhaupt een soortgelijke situatie heeft?
Edit: Mijn tests zijn nu nog met relatief kleine VM's geweest op consumenten hardware. Wel met een dedicated 1Gbit lijn tussen de machines. iperf gaf ongeveer 800Mbit aan over UDP, er is dus al meer te behalen door betere hardware. Is de uiteindelijk performance ook te verhogen door een round-robin bond van 3 Gbit lijnen?
Momenteel hebben we één machine met KVM. Deze machine deelt een data partitie met z'n clients over NFS.
Dit houd de client images klein en maakt het gemakkelijk om de backups op één plek te regelen.
Deze situatie heeft een hoop nadelen, waarvan de grootste is dat deze ene machine een te groot risico is.
Backups maken we genoeg, maar alle data terugzetten na een failure zal wel veel tijd in beslag nemen.
Wat mij een mooie oplossing leek was om 2 (relatief simpele) identieke machines aan te schaffen die beide exact hetzelfde gaan doen. Beide krijgen een hypervisor, in dit geval KVM, en beide kunnen dus de VM's draaien. In de praktijk zullen de VM's (er zijn nu nog maar 4 "kritieke" VM's) ook verspreid worden over beide servers.
In het geval van een failure moet één van de twee machines alle taken kunnen overnemen, vrijwel zonder downtime. Of in ieder geval zo min mogelijk. De beste manier om dit te realiseren is door te repliceren, waar GlusterFS om de hoek komt kijken.
Ik ben er redelijk van overtuigd dat dit te realiseren is, met naar mijn idee meer garanties dan één enkele dure server. We kunnen uiteindelijk nog een machine aanschaffen, die ook weer een replica zal zijn, om zowel meer rekenkracht te krijgen als veiligheid.
Het knelpunt is de concessie die we moeten doen in snelheid. VM's draaien vanaf een Gluster mount (via NFS, niet de native client) is re-de-lijk te doen. Een benchmark in de VM geef schrijf snelheden van maximaal 40MB/s, hier kan ik mee leven. Het probleem ontstaat zodra 4 VM's tegelijk veel moeten schrijven of lezen. Theoretisch moet de bandbreedte van 1Gbit direct al door 4 gedeeld worden. Met overhead zal dit per client niet meer dan 15 - 20 MB/s betekenen.
Ook houd ik straks het liefst de data binnen de VM's zelf, zodat deze ook als enige gescyned hoeven te worden. Dit kan VM's van 100GB+ betekenen. Is dit dan wel te realiseren?
De andere optie zou weer kleine VM's zijn en alleen de data syncen. Het nadeel is dat VM images dan een dag achter kunnen lopen op de andere machine. Wat bij een failover misschien voor rare situaties kan zorgen.
Om een lang verhaal kort te maken: zoek ik het wel in de goede hoek?
Is er iemand die überhaupt een soortgelijke situatie heeft?
Edit: Mijn tests zijn nu nog met relatief kleine VM's geweest op consumenten hardware. Wel met een dedicated 1Gbit lijn tussen de machines. iperf gaf ongeveer 800Mbit aan over UDP, er is dus al meer te behalen door betere hardware. Is de uiteindelijk performance ook te verhogen door een round-robin bond van 3 Gbit lijnen?
[ Voor 6% gewijzigd door JJerome op 09-07-2012 21:58 ]
