De meeste migratieplannen die we zien beginnen bij de apparatuur: welke server gaat in welke bus, wie rijdt, hoe laat draait alles weer. Dat is het makkelijke deel. Het lastige deel is dat je geen servers verhuist maar afhankelijkheden — en die zitten niet in de bus.
Begin bij wat met wat praat
Voordat er iets de deur uit gaat, wil je weten welke systemen elkaar nodig hebben om überhaupt op te kunnen komen. Dat is zelden hetzelfde als het organogram van je applicaties.
- Quorum — bij het opstarten doet een cluster niets tot een meerderheid van de nodes terug is. Reken uit hoeveel dat er zijn en zorg dat je die als eerste opbouwt; alvast een paar VM's aanzetten met wat er staat, gaat niet.
- Opslag vóór rekenkracht — de storagenodes moeten eerst bereikbaar zijn. Komen de compute-nodes eerder, dan zoeken VM's naar disks die er nog niet zijn, en dat gaat natuurlijk niet werken.
- Herverdeling die je niet wilt — zet het cluster in onderhoudsstand vóór je een node afsluit.
- Tijd — kloksynchronisatie is bij gedistribueerde systemen een harde eis. Kan een node zijn klok niet syncen, dan wordt clustercommunicatie onbetrouwbaar.
- DNS — laat nodes elkaar niet vinden via een DNS-server die zelf op dat cluster draait. Die cirkel sluit pas als alles al draait.
- Verkeer naar buiten — welke systemen moeten vanaf internet bereikbaar zijn, en op welke adressen rekenen anderen?
Die laatste wordt het vaakst onderschat. Bij relaties, betaalproviders en koppelpartners staan jouw IP-adressen in een firewall of allowlist — vaak omdat je ze daar ooit zelf hebt opgegeven. Verhuis je naar andere adressen, dan is dat aanpassen geen technisch werk meer maar wachten op een ander: een wijzigingsverzoek, een wachtrij, soms een onderhoudsvenster. Neem je je eigen IP-ruimte mee, dan vervalt dat wachten — alleen de BGP-convergentie blijft, en die is een kwestie van minuten. Zie wat is IP-transit voor hoe dat werkt. Kun je je adressen niet meenemen, verlaag dan ruim van tevoren de TTL van je externe DNS-records, zodat de omzetting niet blijft hangen in caches — en vergeet die allowlists niet.
De opstartvolgorde ís het plan
Zodra je weet wat waarvan afhangt, valt de volgorde vanzelf op zijn plek: network, storage, compute. Eerst het netwerk, dan de storagenodes tot het cluster zich gezond meldt, dan de rest van de nodes, en pas daarna de VM's en de applicaties die daarop leunen.
Drie dingen die daarbij vaak misgaan:
- Alles tegelijk aanzetten — valt er dan één systeem om, dan zoek je in tien logbestanden tegelijk. Zet ze in blokken aan en controleer per blok.
- Doorgaan terwijl het cluster nog herstelt — "up" is niet hetzelfde als klaar. Laat er pas VM's op los als het zich gezond meldt, anders bouw je herstel op herstel.
- Aannemen dat een machine netjes opstart — een dienst die ooit handmatig is gestart en nooit is ingesteld om bij een herstart vanzelf mee te komen, ontdek je op het slechtste moment. Test de herstart op de oude locatie, waar terugvallen nog gratis is.
Verhuis logisch wat je niet fysiek hoeft te verhuizen
Een cluster waarvan de nodes aan dezelfde clusteropslag hangen, verhuis je in één keer. De helft achterlaten kan alleen als je die opslag over beide locaties kunt stretchen, en daar koop je latency en een witness-vraagstuk voor terug — een keuze die je vooraf maakt, niet iets waar je in de verhuisnacht achter komt.
Wat je wél kunt faseren is de logische kant, en daar valt de meeste spanning weg:
- Stateless componenten rol je vooraf opnieuw uit. Loadbalancers, reverse proxies en workers hoeven niet mee in de bus — die draaien al op de nieuwe locatie voordat er iets fysiek beweegt.
- Zet replicatie op zodat data alvast meeloopt. Dan is de omschakeling een kwestie van bijwerken, niet van overzetten.
- Bepaal vooraf hoe je het verkeer omzet. Via DNS, via een announcement, of door de loadbalancer op de nieuwe locatie te laten overnemen — elk met een eigen terugvalpad.
Hoe meer je zo naar voren haalt, hoe kleiner het deel dat écht die nacht moet gebeuren.
Wat op de nieuwe locatie klaar moet staan
Op de verhuisdag wil je niets meer hoeven inrichten. De basis staat dan al, en "staan" betekent dat je het getest hebt, niet dat het geleverd is.
De omgeving:
- Het rack — units op de juiste hoogte ingedeeld, PDU's aangesloten op beide feeds.
- Stroom — de aansluitwaarde past bij wat je werkelijk gaat trekken, inclusief geplande upgrades.
- Cross-connects — liggen erin en zijn doorgemeten, niet alleen geprikt.
Het netwerk is geconfigureerd en in alle onderdelen getest:
- Management — kun je er straks bij zonder dat je ervoor in de auto moet? Out-of-band toegang test je nu, niet als je hem nodig hebt.
- Het lokale netwerk — VLAN's geconfigureerd, segmentatie zoals bedoeld, en verkeer tussen de segmenten daadwerkelijk gestuurd.
- Uitgaand verkeer — IP-transit of direct internet access, IP-ruimte toegewezen en waar nodig geadvertised. Test met echt verkeer over de uplink; een groen lampje zegt alleen dat er een kabel in zit.
Doe die tests voordat er ook maar één server verhuist. Een netwerkprobleem is op een rustige dinsdagmiddag een kwestie van uitzoeken, en in een migratienacht een reden om terug te vallen.
Zet ook je monitoring vooraf goed. Die wijst vaak nog naar de oude locatie, blijft dan stil precies wanneer je hem nodig hebt — of draait, nog vervelender, op het cluster dat je aan het verhuizen bent.
Juist tijdens een migratie wil je zien wanneer iets offline gaat en wanneer het weer terug is. Dat is niet alleen om af te vinken: als er halverwege iets misgaat, merk je dat doordat een dienst die al draaide opeens weer wegvalt. Bijvoorbeeld omdat iemand tijdens het racken net even een aan-uitknop raakte.
Regel vooraf wie er die nacht komt. Bij ons kan toegang snel — binnen vijf minuten als het moet — maar wie naar binnen gaat moet zich kunnen legitimeren. Zorg dat de legitimatie mee is.
Ruim pas op als het een werkdag heeft overleefd
Zolang de oude opstelling er nog staat en de oude verbinding nog leeft, is terugvallen goedkoop. Die geruststelling is een paar dagen dubbele kosten waard. Laat de nieuwe situatie minstens één volledige werkdag draaien — inclusief de nachtelijke backup en de maandelijkse batch als die eraan komt — voordat je iets afkoppelt.
Migreren met Xyphen IT
Wij doen dit op projectbasis en pakken het van begin tot eind op: afhankelijkheden in kaart, opstartvolgorde bepalen, colocatie inrichten en de verbindingen klaarzetten. Onze engineers kennen je omgeving, dus als er om twee uur 's nachts iets niet opkomt, hoeft er niemand eerst een tekening te zoeken.
Wil je weten wat er in jouw geval bij komt kijken? Vraag een voorstel aan of neem contact op — dan kijken we naar je huidige opstelling.