xen en automatic live migration failover?

Magus · #1 (**permalink**) 13 January 2010, 13:31

Hallo allemaal,

ik ben met wat testmachines bezig een HA clustertje te bouwen op basis van xen.

Op dit moment heb ik een storage draaien die via iscsi (drbd, 2 machines, auto failover) op een pool van 2 identieke xenserver (citrix, free) gekoppeld is. Live migration werkt vlekkeloos met slechts enkele ms lag op de virtuele serverlaag

De iscsi neemt bij wegvallen van de master automatisch over op de slave. Uitschakelen van de master geeft wel een downtime van enkele seconden tijdens het overschakelen. Misschien is dit nog verder te optimaliseren, maar dat zullen de tests wel uitwijzen (trial en error. Maar als je tips hebt...

)

Waar ik echter niet uitkom is de automatische failover op de xen nodes. Voor onderhoud aan 1 van de xen nodes kan ik eenvoudig een live migration uitvoeren, maar wat nu als een node onverwacht down gaat? Natuurlijk is er een commerciele HA oplossing maar ik neem aan dat er ook wel wat te scripten is. Hoe hebben jullie dit opgelost? Gewoon heartbeat? of een andere oplossing? Welke richting moet ik denken?

Mikey · #2 (**permalink**) 13 January 2010, 13:34

Citaat:

Oorspronkelijk geplaatst door Magus

De iscsi neemt bij wegvallen van de master automatisch over op de slave. Uitschakelen van de master geeft wel een downtime van enkele seconden tijdens het overschakelen. Misschien is dit nog verder te optimaliseren, maar dat zullen de tests wel uitwijzen (trial en error. Maar als je tips hebt...

)

Ik weet niet of het voor iscsi hetzelfde werkt, maar voor nfs ontstaat er een kleine buffer die opgevangen kan worden in de tijd dat je overschakelt. In de praktijk werkt dit voor de meeste vms maar niet voor alle. Die uiteindelijk een read only filesystem overhouden.

Sander- · #3 (**permalink**) 13 January 2010, 13:57

Er zijn wel meer partijen die hier naar gekeken hebben en mee bezig zijn geweest. Volgens mij is het ook niet heel spannend om zoiets via de Xen Api zelf te bouwen, het is alleen even de vraag of de tijd die je erin moet investeren om zoiets te ontwikkelen en stabiel te krijgen opweegt tegen de licentiekosten van het full product. Als je namelijk gaat bouwen moet je eigenlijk per xen node gaan bijhouden wat er aan geheugen vrij is, per vm gaan bijhouden of deze ergens anders opgestart moet worden, een goed heartbeat mechanisme verzinnen, etc etc etc ;-)

Daarnaast is het inmiddels zo dat Xen ook een monthly usage licentiestructuur heeft uitgerold. Het is dus even de vraag hoe lang XenServer nog "gratis" gebruikt mag worden voor commerciële hosting. Als dat nu al mag, aangezien de EULA daar niet helemaal helder in is.

Citaat:

Oorspronkelijk geplaatst door Mikey

Ik weet niet of het voor iscsi hetzelfde werkt, maar voor nfs ontstaat er een kleine buffer die opgevangen kan worden in de tijd dat je overschakelt. In de praktijk werkt dit voor de meeste vms maar niet voor alle. Die uiteindelijk een read only filesystem overhouden.

Ik neem aan dat de TS bedoelt dat de VM's gewoon automatisch gestart worden op een andere node. Dat is iig wat xen in de commerciele variant aanbiedt. Iets als FTA zoals Vmware dat aanbiedt heeft Xen (nog) niet voor zover ik weet.

Yourwebhoster · #4 (**permalink**) 13 January 2010, 14:35

Je moet wel bijhouden of een guest moet draaien of niet, zodra een node onbereikbaar is evenals een test guest start je de guests op een andere node of je verdeelt dit over een aantal nodes.

Magus · #5 (**permalink**) 13 January 2010, 14:56

Citaat:

Oorspronkelijk geplaatst door Sander-

Er zijn wel meer partijen die hier naar gekeken hebben en mee bezig zijn geweest. Volgens mij is het ook niet heel spannend om zoiets via de Xen Api zelf te bouwen, het is alleen even de vraag of de tijd die je erin moet investeren om zoiets te ontwikkelen en stabiel te krijgen opweegt tegen de licentiekosten van het full product. Als je namelijk gaat bouwen moet je eigenlijk per xen node gaan bijhouden wat er aan geheugen vrij is, per vm gaan bijhouden of deze ergens anders opgestart moet worden, een goed heartbeat mechanisme verzinnen, etc etc etc ;-)

Het projectje draait in ons lab, er wordt aan gewerkt op tijden dat er even niet veel anders te doen is. Op deze manier kost het vrij weinig, valt een beetje onder onze 'r&d' investering zeg maar. Een licentie is toch al snel 2000 euro voor de HA. Mocht het met wat trial en error en enkele scriptjes ook op te lossen zijn dan heeft dat onze voorkeur. Daarnaast is het natuurlijk gewoon leuk om mee te stoeien

Citaat:

Daarnaast is het inmiddels zo dat Xen ook een monthly usage licentiestructuur heeft uitgerold. Het is dus even de vraag hoe lang XenServer nog "gratis" gebruikt mag worden voor commerciële hosting. Als dat nu al mag, aangezien de EULA daar niet helemaal helder in is.

Wellicht is de open source versie voor ditzelfde doel ook bruikbaar, mits deze live migration ondersteund. Wellicht kan iemand dit simpel beantwoorden?

Citaat:

Ik neem aan dat de TS bedoelt dat de VM's gewoon automatisch gestart worden op een andere node. Dat is iig wat xen in de commerciele variant aanbiedt. Iets als FTA zoals Vmware dat aanbiedt heeft Xen (nog) niet voor zover ik weet.

Klopt, dat is uiteindelijk het doel.

Citaat:

Oorspronkelijk geplaatst door Yourwebhoster

Je moet wel bijhouden of een guest moet draaien of niet, zodra een node onbereikbaar is evenals een test guest start je de guests op een andere node of je verdeelt dit over een aantal nodes.

Goed punt!

Sander- · #6 (**permalink**) 13 January 2010, 15:07

Citaat:

Oorspronkelijk geplaatst door Magus

Het projectje draait in ons lab, er wordt aan gewerkt op tijden dat er even niet veel anders te doen is. Op deze manier kost het vrij weinig, valt een beetje onder onze 'r&d' investering zeg maar. Een licentie is toch al snel 2000 euro voor de HA. Mocht het met wat trial en error en enkele scriptjes ook op te lossen zijn dan heeft dat onze voorkeur. Daarnaast is het natuurlijk gewoon leuk om mee te stoeien

Wellicht is de open source versie voor ditzelfde doel ook bruikbaar, mits deze live migration ondersteund. Wellicht kan iemand dit simpel beantwoorden?

Klopt, dat is uiteindelijk het doel.

Goed punt!

Mocht je het af krijgen dan kun je er vast een hoop concullega's blij mee maken, oftewel, wss kun je nog wat van je kosten terugverdienen ;-)

Magus · #7 (**permalink**) 13 January 2010, 15:56

Voor ons is hoofdzakelijk de reden om een makkelijk werkbaar platform te hebben wat bij voorkeur HA is natuurlijk

Maar dat sluit idd niet uit dat er meer mensen in geinteresseerd zullen zijn

Kreft · #8 (**permalink**) 13 January 2010, 16:46

De open source versie van Xen ondersteund iig live-migration. Maar wanneer een server faalt, bijvoorbeeld door defecte hardware, dan heb je uiteindelijk niks meer aan de live-migration zelf. Aangezien de node van waarop je moet gaan migraten niet meer bereikbaar is.

In dat geval komt het er dus op neer (simplistisch uitgedrukt) om te kunnen gaan detecteren of de VPS nodes bereikbaar zijn en per node te gaan bijhouden welke VPS'en die op elk moment draait. Mocht er dan eentje weggevallen weet je welke VPS'en "verloren" zijn gegaan als gevolg van de failure en kan je die elders gaan deployen. (hiervoor moet je uiteraard van elke node weten hoeveel resources er nog ter beschikking zijn)

Op zich is het allemaal niet zo moeilijk te realiseren. Het wordt pas lastig wanneer je dit gaat ontwikkelen voor een omvangrijke infrastructuur die zichzelf draaiende moet houden en extra zaken gaat toevoegen zoals deployment heuristieken voor resource usage scheduling enzomeer.

eXtreme Service · #9 (**permalink**) 13 January 2010, 18:24

Automatisch opstarten van servers uitschakelen. Vervolgens een script maken dat verbinding maakt met Citrix XenServers en gaat controleren of deze actief zijn. Is de main server niet actief stuur je de opdracht naar de 2de server om op te starten.
Hier is ook zeker interesse in een dergelijk script maar lijkt ons zeer eenvoudig om deze zelf te schrijven.

Hier ligt nog wel ergens een Webversie van XenCenter in PHP dus alle functies zijn reeds beschikbaar. Scriptje van een 50 tal regels kan dus perfect bovenstaande uitvoeren inclusief enkele controles.

Begrijp ik het goed en draait u de storage ook op een VPS op dezelfde server? Wij hebben hier zelf ook enkele testen mee gedaan maar wij kwamen toch hier en daar enkele problemen tegen. (Weet alleen niet meer direct welke.)

Kippenijzer · #10 (**permalink**) 14 January 2010, 10:26

Project Remus (voor de OSS versie van Xen) doet precies dit en moet er bij de cutting edge versies dacht ik inmiddels in zitten. Probleem blijft dat ook deze failover nooit 100% is, de 'fouten' die je bij live migration kunt hebben kunnen hier ook gebeuren, maar het is dus inderdaad het real-time blijven 'live-migraten' van een guest naar de fallback host, en pas echt het ding overdragen als de primaire node faalt.

Sander- · #11 (**permalink**) 14 January 2010, 10:42

Citaat:

Oorspronkelijk geplaatst door Kippenijzer

Project Remus (voor de OSS versie van Xen) doet precies dit en moet er bij de cutting edge versies dacht ik inmiddels in zitten. Probleem blijft dat ook deze failover nooit 100% is, de 'fouten' die je bij live migration kunt hebben kunnen hier ook gebeuren, maar het is dus inderdaad het real-time blijven 'live-migraten' van een guest naar de fallback host, en pas echt het ding overdragen als de primaire node faalt.

Tja, dat is niet echt handig, lijkt me aangezien je continu een hoop data over je netwerk gooit. Wij zouden persoonlijk genoeg hebben aan een automatische herstart van de machine elders in de pool. Gaat het om 2 machines dan is deze setup misschien niet zo moeilijk, maar stel je hebt 5 servers in een 1 pool hangen. Als er dan 1 uitvalt wil je eigenlijk dat de VM's verdeeld worden over de andere 4. Hoe je bijhoudt welke nodes er ruimte hebben en welke vm's er daadwerkelijk gemigreerd moeten worden vereist in mijn ogen wel meer dan 50 regeltjes code.

Kippenijzer · #12 (**permalink**) 14 January 2010, 12:24

Bij project Remus heb je idd 2x de 'host-capaciteit' nodig. Echter hoeft er natuurlijk enkel RAM over de lijn te gaan en voor syncing gebruiken wij dedicated netwerken, dus dat is geen enorm probleem. Het is inderdaad zonder 10GE niet echt handig voor hele zware guests.

Showeb · #13 (**permalink**) 17 January 2010, 00:25

Ik denk persoonlijk dat het zelf ontwikkelen van een HA oplossing meer kost dan het commerciele product. Wat Sander al aangegeven heeft is het inderdaad meer als 50 regels scriptwerk en of het nog allemaal werkt zoals wenselijk is nog maar de vraag.

Elke keer als je een node vervangt of bijprikt en elke keer als je een nieuwe VM aanmaakt of verplaatst naar een andere node betekent dit dat je het script ook zou moeten aanpassen. Oplossing is dan om een script te maken die variabel is, echter denk ik dat dit niet eenvoudig is.

Bart L · #14 (**permalink**) 18 January 2010, 11:03

Is het niet handiger om met een paar handjes het KVM verhaal omhoog te tillen qua clustering / fall ove, ipv een commercieel project als XEN wat wellicht op een later stadium de licentie voorwaarden aanpast, waardoor je als nog 2k per server mag gaan aftikken ?

Jesperw · #15 (**permalink**) 18 January 2010, 11:57

Ik zou zeggen; als 't HA moet zijn dan moet het echt degelijk zijn en koop je gewoon XenServer Enterprise (zo duur is 't niet). Als 't dat niet hoeft te zijn dan zou ik er niet teveel aan gaan scripten.

Je krijgt 't nooit helemaal rock solid, dus dan is een eenvoudigere opzet misschien wel stabieler dan een zelf gescripte HA setup.