PDA

Bekijk Volledige Versie : Migratie VPS naar PHYSICAL



Trimmer
21/10/11, 13:39
Heeft er iemand ervaring met het migreren van een ESXi VPS naar een dedicated server? VPS draait momenteel CentOS 6.0.

Wat zou de beste methode zijn om dit uit te voeren? Het hele process moet zo kort mogelijk duren. Klant wil down time kost-wat-kost zo kort mogelijk houden.

Advies is welkom.

systemdeveloper
21/10/11, 13:43
Server installeren, rsyncen totdat er geen wijzigingen meer zijn en ip switchen.

Trimmer
21/10/11, 13:54
Iets als dit ? rsync -arP --delete root@server:/ /

Heb je echt getest of dat goed werkt? Het klinkt zo raar om dit met rsync te gaan uitvoeren.

systemdeveloper
21/10/11, 14:05
Iets als dit ? rsync -arP --delete root@server:/ /

Heb je echt getest of dat goed werkt? Het klinkt zo raar om dit met rsync te gaan uitvoeren.
Afhankelijk van je situatie heb je verschillende mogelijkheden. Ik heb ook wel eens gewoon plain parties met tar/ssh over getrokken.

Maar je kunt rsync een paar keer achter elkaar aantrappen. Uiteindelijk zeurt die dan alleen nog over open files (db e.d). Die services stop je dan even op beide machines, voordat je de laatste rsync doet, en dan rebooten met de nieuwe bak en met het oude ip. Vanacht nog paar gedaan, werkt perfect.

Apoc
21/10/11, 15:04
Is het niet veel logischer om op die dedicated server simpelweg ESXi te installeren en vervolgens die VPS als geheel te migreren (en dus als standalone VPS op de dedicated server te laten draaien)?

Om alles te rsyncen is nogal een houtje-touwtje oplossing.

Trimmer
21/10/11, 15:12
ESXi installeren op dedicated server en daar de VPS naartoe verhuizen, dat zou eenvoudig zijn. Maar de bedoeling om naar een dedicated server te migreren is omwille van performance. Virtualisatie is toch altijd minder performant dan rechtstreeks op de hardware draaien hé...

systemdeveloper
21/10/11, 15:21
Om alles te rsyncen is nogal een houtje-touwtje oplossing.
Hoe wil je het dan op een dedi krijgen?

Je kunt nog gekker gaan doen door partities te tarren of wat kloten met lvm snapshots, maar uiteindelijk zit er een tijd in het overzetten van de data. Met rsync hou je daarmee je downtijd het meeste beperkt als je naar een andere platform moet. (zonder nog gekkere dingen zoals een snelle HA omgeving optuigen en het vps gewoon plat te gooien na de sync :) )

Apoc
21/10/11, 15:21
ESXi installeren op dedicated server en daar de VPS naartoe verhuizen, dat zou eenvoudig zijn. Maar de bedoeling om naar een dedicated server te migreren is omwille van performance. Virtualisatie is toch altijd minder performant dan rechtstreeks op de hardware draaien hé...

Mwaaa dat valt reuze mee hoor. Over het algemeen is de overhead zeer klein - zeker met VMware, dus dat is niet echt een argument. Daarnaast behoud je op deze manier ook de mogelijkheid om de VPS later naar een grotere server te verhuizen indien dat nodig mocht zijn.

Magus
21/10/11, 15:23
wat draait er binnen die VPS? Iets bijzonders dat de hele handel 1 op 1 over moet naar physical? Is het niet handiger een goede, stabiele installatie op de dedicated bak te zetten, de benodigde services en deamons erop te knallen en dan de files (web/sql?) over te zetten? vervolgens even testen of alles werkt en dan ip switchen.

systemdeveloper
21/10/11, 15:23
Mwaaa dat valt reuze mee hoor. Over het algemeen is de overhead zeer klein - zeker met VMware, dus dat is niet echt een argument. Daarnaast behoud je op deze manier ook de mogelijkheid om de VPS later naar een grotere server te verhuizen indien dat nodig mocht zijn.
Agree! De paar procent die je verliest kost je in de praktijk hooguit eenmalig een paar tientjes op de prijs van je server als je een iets snellere proc pakt.

Trimmer
21/10/11, 15:25
Wat ik me nog afvraag.
Als ik ga rsync'en. Gaat dat geen problemen geven met grub? Want die config in /boot wijzigt dan toch ook? Ik denk bijvoorbeeld aan device.map.

Al zou dat in dit geval wellicht gewoon twee maal hetzelfde zijn (hd0=/dev/sda)

Trimmer
21/10/11, 15:29
@magus : het is een bak van een klant en ik weet zelf niet 100% wat er allemaal op draait. Maar er draait enorm veel tegelijk op en alles overzetten naar een nieuwe installatie zou dan ook een hele klus zijn.

systemdeveloper
21/10/11, 15:32
Nou, ik zou eerst mijn target server goed installeren en dan de data rsyncen. Nu weet ik dat ik met FreeBSD gewoon een partitie kan overmikken en de boel draait. Of dat ook met Centos zo is, weet ik niet.
Voor mij is Cento 6.0 nog niet stabiel genoeg voor productie, dus laat staan voor die soort meuk.

Als je wegkomt met alleen je data te syncen dan zou ik me daarop richten.

Trimmer
21/10/11, 16:29
Het probleem is een beetje het feit dat de klant zoveel dingen geïnstalleerd heeft en aangepast en er geen overzicht is van welke configbestanden zijn aangepast. Er zijn in de loop der tijd ook al wat aanpassingen gedaan zoals symlinks leggen als een compile fout ging en nog wat zooi.
Omdat het zoveel wijzigingen zijn is het dus niet eenvoudig mogelijk om een nieuw OS te installeren en enkel de data over te kopieren.

We zouden dus het VPS systeem willen overzetten naar een dedicated server, waarbij de dedicated server uiteindelijk een exacte copie moet worden van de VPS. Zodat we ons geen zorgen hoeven te maken over configuratie-problemen o.i.d...

Misschien is het beter om toch te kiezen voor een disk imaging tool en gewoon een backup + restore uitvoeren? Indien zo, welk disk imaging pakket is aan te raden?

Misschien moete

t.bloo
21/10/11, 16:53
Zodat we ons geen zorgen hoeven te maken over configuratie-problemen o.i.d...

Ik zou me in deze situatie juist heel erg zorgen maken.

Afwijken van de default instellingen is geen probleem, behalve als je niet weet wat er anders is! Straks heb je een keer een crash of een hack of een update en werkt het niet meer en weet je ook niet hoe je het terug moet krijgen.

Misschien een idee om deze upgrade aan te grijpen om orde in de chaos te scheppen?

systemdeveloper
21/10/11, 17:07
Je kunt het eventueel 'makkelijk' testen als je access tot de dedi hebt. Installeer centos 6.0, rsync ALLES van het vps naar een /tijdelijk direcory op de dedi.
Boot dedi in single user en swap de content. Zolang je proc architectuur hetzelfde is en je disklabels ook, dan lijkt me dat dit wel gaat werken.
Maar ik ben meer een FreeBSD persoon dan centos... :)

systemdeveloper
21/10/11, 17:08
Ik zou me in deze situatie juist heel erg zorgen maken.

Afwijken van de default instellingen is geen probleem, behalve als je niet weet wat er anders is! Straks heb je een keer een crash of een hack of een update en werkt het niet meer en weet je ook niet hoe je het terug moet krijgen.

Misschien een idee om deze upgrade aan te grijpen om orde in de chaos te scheppen?
Eigenlijk wilde ik dat ook al zeggen... een ongedocumenteerd vps lijkt me veiliger dan een ongedocumenteerde dedi namelijk :)

Mikey
22/10/11, 02:19
wat je kan doen is het volgende, je installeert hetzelfde os en versie. Je zorgt dat de partities groot deel hetzelfde zijn.

daarna maak je file aan met onderstaande content:
/tmp/nocopy:
boot
proc
dev
sys
etc/fstab
etc/lvm
etc/blkid

op de source stuur je onderstaand command

cd /; tar -zcvpf - -X /tmp/nocopy * |ssh <IP NIEUW> "cd /; tar -zxvpf - --numeric-owner"

hierna update je het systeem en reboot je. done.

maxnet
22/10/11, 02:54
Misschien is het beter om toch te kiezen voor een disk imaging tool en gewoon een backup + restore uitvoeren? Indien zo, welk disk imaging pakket is aan te raden?


Clonezilla is gratis.

ju5t
22/10/11, 11:04
Ik zou kiezen voor de manier die Apoc aangeeft. Gewoon ESXi gebruiken. Wij doen elke week migraties en met rsync of tar of wat dan ook gaat het vaak goed, maar vaak gaat er ook wel iets mis. Met ESXi heb je gewoon minder zorgen.

Mikey
22/10/11, 14:44
Ik kan in ieder geval uit ervaring zeggen dat bovenstaand voor ons meer dan voldoende is. Zowel p2v als v2p.

Verder op een dedicated esx(i) installeren en de rest bestempelen als houwtje touwtje.... Tja. Je hebt beheerders of je hebt ze niet. Het idee is leuk, maar wie zegt dat de gekozen hardware op de compat. list van vmware staat. Nou kan het allemaal werken, maar wie weet wat voor performance drops je in de toekomst kan krijgen. Of onverklaarbare vastlopers bijvoorbeeld.

Ik zou hem migreren (v2p), alleen al uit het feit om de discussie met de klant op lange termijn te voorkomen.

Pantsy
22/10/11, 17:31
Vaak zijn er goede redenen om terug te vallen naar een dedicated, denk aan I/O performance. Leuk dat je dan esxi op een stand alone server installed maar dat lost vrijwel niks op.

Imaging software kan zeker worden gebruikt, clonezilla ken ik niet, wij maken gebruik van R1soft en dat werkt prima (restore op een virtual of dedicated maakt niks uit).

Migreer die hele bende handmatig zou ik zeggen, je zult wel moeten wanneer een klant gebruik maakt van vele op maat applications. Misschien dat je de klant zelfs kan helpen met het stroom lijnen hiervan zodat het gemakkelijker word om te migreren in de toekomst (of uit te breiden).

ju5t
22/10/11, 20:12
Oh, daar heb je trouwens een heel goed punt. R1soft is er bij ingeschoten, dat kan soms ook zeker een oplossing zijn.

Apoc
25/10/11, 13:11
Vaak zijn er goede redenen om terug te vallen naar een dedicated, denk aan I/O performance. Leuk dat je dan esxi op een stand alone server installed maar dat lost vrijwel niks op.

Waarom niet? Hij geeft aan dat er nu in een shared omgeving gedraaid wordt. Wanneer je dat migreert naar een dedicated omgeving (met standalone virtualisatie) waarin veel meer I/O beschikbaar is, lost dat natuurlijk wel een hoop op.

PimEffting
25/10/11, 20:04
Je kunt ook met bijvoorbeeld Symantec Ghost aan de slag. Die kan ook over het netwerk images streamen.
Even CD image koppelen bij je virtuele machine, boot CDtje in je nieuwe machine, en binnen korte tijd ben je helemaal klaar.

systemdeveloper
26/10/11, 12:03
Je kunt ook direct beginnen... dan was je al 5 dagen klaar geweest ;)

Trimmer
26/10/11, 12:37
Systemdeveloper. Van een nuttige bijdrage gesproken :)

Het is intussen al allemaal overgezet met rsync.

systemdeveloper
26/10/11, 12:43
Systemdeveloper. Van een nuttige bijdrage gesproken :)

Het is intussen al allemaal overgezet met rsync.
Mja, ok... misschien was ie niet zo nuttig, maar het werd zo'n discussie van allerlei tools en goodies... Ik denk al 'straks zit ts met 20 extra pakketten' :)

Pantsy
27/10/11, 16:11
Oh, daar heb je trouwens een heel goed punt. R1soft is er bij ingeschoten, dat kan soms ook zeker een oplossing zijn.

Esxi geeft niet de I/O performance die je kan behalen wanneer je een traditionele dedicated server in gebruik heb, doe anders wat speed checks en trek je eigen conclusies zou ik zeggen. Dit is overigens naar mijn weten de bottleneck van elke virtualisatie techniek en daarom soms niet interessant voor bepaalde doeleinden.

Apoc
27/10/11, 16:56
Esxi geeft niet de I/O performance die je kan behalen wanneer je een traditionele dedicated server in gebruik heb, doe anders wat speed checks en trek je eigen conclusies zou ik zeggen. Dit is overigens naar mijn weten de bottleneck van elke virtualisatie techniek en daarom soms niet interessant voor bepaalde doeleinden.

Heb jij die speedchecks gebaseerd op een configuratie waarin gebruikt gemaakt werd van SAN storage? Zo ja, dan lijkt het me dat de I/O afwijking daar aan ligt, en in veel mindere mate aan de virtualisatie zelf. Zo groot is die overhead namelijk niet.

Pantsy
27/10/11, 17:03
Ik heb performance checks gedaan op meerdere configuratie, local storage en SAN storage. SAN storage zou per definitie sneller moeten zijn wanneer je een hoge I/O throughput hebt, dit hangt uiteraard van je setup af.

Nielsvk
30/10/11, 15:41
VMware converter tool?