Veelgestelde vragen over de migratie van de AMS-regio naar AMS2

In dit artikel vind je antwoorden op de meestgestelde vragen over de migratie van de OpenStack-regio AMS naar AMS2. We leggen uit hoe de migratie verloopt, hoe je jouw instances voorbereidt en welke impact dit heeft op je omgeving. Hieronder vind je een beknopt overzicht van welke onderdelen worden gemigreerd. Verderop in dit artikel gaan we dieper in op elk onderwerp.

Korte samenvatting

Deze onderdelen worden volledig gemigreerd:

• Instance: Je instance wordt gemigreerd naar AMS2.
• Project: Je OpenStack-project wordt gemigreerd. Het project-ID blijft ongewijzigd.
• Images: Custom images en snapshots worden gemigreerd.
• Interne netwerken: Je interne netwerken worden uitgebreid naar AMS2.
• Volumes: Gekoppelde volumes worden gemigreerd.
• IP-adressen: Interne IP-adressen, publieke IP-adressen en floating IP's worden gemigreerd.

Deze onderdelen worden gedeeltelijk gemigreerd of gewijzigd:

• Router-IP: Gebruik je een router voor internettoegang vanuit je interne netwerk? Dan wijzigt het publieke IP-adres van deze router.
• Cloud-init/Cloudbase-init: Als cloud-init actief blijft, wijzigt de SSH-hostkey. Op Windows wordt cloudbase-init bijvoorbeeld gebruikt om het administratorwachtwoord te wijzigen.
• Loadbalancers: Loadbalancers worden gemigreerd nadat alle instances in het project zijn gemigreerd. Houd rekening met enkele minuten downtime.
• Beschikbaarheid: Na de migratie controleren we je instance met een ICMP-ping en veelgebruikte poorten, zoals 22, 80 en 443.

Deze onderdelen worden niet gemigreerd:

• Volumesnapshots: Snapshots van volumes worden niet meegenomen.
• HEAT-stacks: Resources uit HEAT-stacks worden als losse resources gemigreerd, maar de HEAT-template zelf wordt niet meegenomen.
• Key-pairs & SSH-Keys: SSH keys worden naar de nieuwe regio gekopieerd voor de gemigreerde instance. De Keypair wordt niet als losse key naar jouw gebruiker in de nieuwe regio gemigreerd.

Voorbereiding

Hoe bereid ik mijn instances voor op de migratie?

Zet voorafgaand aan de migraties je instance(s) minimaal een keer volledig uit (SHUTDOWN) en start deze daarna opnieuw op. Een reboot is hiervoor niet voldoende. Hiermee controleer je of de instance zonder foutmeldingen of onderbrekingen opstart.

Schakel cloud-init of cloudbase-init uit voordat de migratie start. Voer daarnaast een filesystem check uit op alle filesystems en controleer of er geen pending updates klaarstaan. Zo voorkom je dat updates of patches tijdens de migratie worden onderbroken.

De namen van de regio en availability zones veranderen. Maak je gebruik van deze namen in scripts, automatisering, Infrastructure as Code, monitoring of applicatieconfiguraties? Dan adviseren we je om tijdig te controleren welke aanpassingen nodig zijn. Verderop in het artikel staat wat deze namen zijn.

Wil je tijdens de migraties op de hoogte blijven van de voortgang? Controleer dan of de optie 'Onderhouds- en storingsmeldingen' is ingeschakeld bij de Communicatievoorkeuren in je TransIP-account.

Meer informatie over de verschillen de beide regio's vind je in ons artikel over de verschillen tussen de AMS- en AMS2-regio.

Migratie plannen en starten

Hoe wijzig ik de planning en start ik de migratie zelf?

Uiterlijk twee weken voordat een instance wordt gemigreerd, ontvang je een e-mail met de op dat moment geplande migratiedatum en een overzicht van de instances die voor die migratie zijn ingepland.

Vanaf dat moment kun je de planning van iedere instance zelf aanpassen, zodat de migratie plaatsvindt op een moment dat jou beter uitkomt. De opgegeven datum en tijd worden geïnterpreteerd in de tijdzone Europe/Amsterdam.

Wil je de migratie zo snel mogelijk laten starten? Dan zijn er twee mogelijkheden:

• Plan de migratie op een datum en tijd die in het verleden ligt. De migratie wordt dan gestart zodra er een migratieslot beschikbaar is. In de meeste gevallen is dit binnen één minuut.
• Of stel de metadata key migrate_flag in op o2o-migrate-now. De migratie wordt dan direct ingepland op het eerstvolgende beschikbare migratieslot.

Wil je op de hoogte blijven van de planning en voortgang van de migraties? Controleer dan in de Communicatievoorkeuren van je TransIP-account of Onderhouds- en storingsmeldingen is ingeschakeld. Alleen wanneer deze voorkeur is ingeschakeld, ontvang je e-mailupdates over de planning en voortgang van je migratie.

De planning aanpassen

Stap 1 

Open in Horizon Project → Compute → Instances.

Stap 2

Klik bij de betreffende instance op het menu (▼) en kies Update Metadata.

Stap 3

Open Provider platform options → Migration.

Stap 4

Klik op het +-icoon naast Scheduling options.

Stap 5

Wijzig vervolgens de waarde van migrate_flag:

• o2o-scheduled-YYYY-MM-DDTHH:MM:SS om een specifieke datum en tijd in te plannen.
  • Voorbeeld: o2o-scheduled-2025-12-16T08:25:00
• o2o-migrate-now om de migratie zo snel mogelijk te starten.

Stap 6

Klik op Save om de wijziging op te slaan.
 

Let op: De migratie start altijd op het eerstvolgende beschikbare migratieslot. Ook wanneer je o2o-migrate-now gebruikt of een tijdstip in het verleden opgeeft, kan er dus een korte wachttijd zijn. In de meeste gevallen bedraagt deze minder dan één minuut.

Wat gebeurt er als ik de migratie niet zelf plan?

Dan wordt je instance gemigreerd tijdens kantooruren, tussen 09:00 en 17:00 Europe/Amsterdam, op de datum die per e-mail is gecommuniceerd en in de metadata staat.

Kan ik buiten kantooruren migreren?

Ja. Plan de migratie zelf via de migratie metadata wanneer je buiten kantooruren wilt migreren.

Kan ik al mijn resources zo snel mogelijk laten migreren?

Neem contact op met support om te laten controleren of je instances al gemigreerd kunnen worden. Sommige migraties worden pas beschikbaar nadat technische blokkades zijn opgelost.

Waarom heeft niet elke instance migratiemetadata?

Niet iedere configuratie wordt tegelijk vrijgegeven voor migratie. HA- en VRRP-setups, interne netwerken met custom routers en andere specifieke platformconfiguraties worden in een latere fase gemigreerd.

Wanneer een instance nog geen migratiemetadata heeft, worden de laatste technische blokkades eerst opgelost voordat de migratie voor die instance beschikbaar komt.

Downtime en impact

Wat is de verwachte downtime tijdens de migratie?

In vele gevallen is de migratie van een kleine instance binnen een minuut rond. Voor grotere instances dien je rekening te houden met maximaal vijftien minuten downtime. De daadwerkelijke downtime hangt af van de tijd die nodig is om de instance te starten en services beschikbaar te maken. 

De migratie start met een graceful shutdown via de OpenStack API. Daarna wordt in de nieuwe regio een nieuwe instance gemaakt met een kopie van de disk. Als het opstarten langer dan tien minuten duurt, wordt automatisch een rollback gestart.

Is je instance verbonden met een intern netwerk? Dan kan de verbinding met dat netwerk tot tien minuten onderbroken zijn. Reken na een succesvolle start in de nieuwe regio op nog eens tien minuten voordat het interne netwerk volledig klaar is. Reageert het interne netwerk twintig minuten na afronding van de migratie nog niet, neem dan contact op met support en start een rollback.

Loadbalancers hebben tot vijf minuten downtime, omdat de loadbalancer opnieuw wordt aangemaakt in de nieuwe regio.

Heeft de migratie invloed op andere actieve instances?

Nee, tenzij je zelf de overige instances afhankelijk hebt gemaakt naar de instance die wordt gemigreerd. Controleer daarom vooraf of andere services, scripts of interne koppelingen afhankelijk zijn van die instance die gemigreerd zal worden.

Wat gebeurt er als de migratie mislukt?

Als de migratie mislukt, zal er een rollback plaatsvinden en wordt je instance opnieuw gestart in de oude OpenStack-regio. Daarna wordt de oorzaak onderzocht en ontvang je informatie over een nieuwe migratiedatum.

Na de migratie

Hoe zie ik of de migratie succesvol was?

Na een succesvolle migratie krijgt de instance op het oude platform de status ‘SHUTOFF’ en wordt de instance gelocked. Je controleert dit via het oude Horizon dashboard. 

De voortgang van de migratie volg je via de metadata key ‘_export_progress’.

Waar beheer ik mijn gemigreerde instance?

Je beheert de gemigreerde instance via het nieuwe Horizon dashboard. 

Kan ik een rollback uitvoeren?

Ja. Na een succesvolle migratie kan je binnen vijf dagen een rollback uitvoeren door in het oude Horizon dashboard de metadata key ‘rollback-now’ op de oude instance te zetten.

Geef daarna aan support door waarom je een rollback hebt uitgevoerd. Wijzigingen die je na de migratie op de nieuwe instance hebt gemaakt, worden niet teruggezet naar de oude instance en moet je als verloren beschouwen.

Resources en configuraties

Wat gebeurt er met loadbalancers?

Loadbalancers worden gemigreerd nadat alle instances in je project zijn gemigreerd. De migratie start automatisch op dezelfde dag als de laatste instancemigratie binnen je project.

Tijdens de migratie is de loadbalancer enkele minuten niet beschikbaar, omdat deze opnieuw wordt aangemaakt in de nieuwe regio. Loadbalancers worden omgezet naar Octavia-loadbalancers met de flavor ‘Small’. De verwachte performance is vergelijkbaar of beter dan de performance van de oude loadbalancer.

Wat gebeurt er met HEAT-stacks?

Resources in een HEAT-stack worden als losse resources naar het nieuwe platform gemigreerd. De HEAT-template zelf wordt niet meegenomen. Na afronding van de migratie wordt de HEAT-template van het oude platform verwijderd.

Wil je HEAT blijven gebruiken in de nieuwe regio? Hou er dan rekening mee dat de regio en availability zone's wijzigen bij het maken van je nieuwe HEAT-stack. Pas zodoende je HEAT-template aan.

Wat gebeurt er met de OpenStack CLI / Terraform / andere tools die ik heb geconfigureerd?

Als je gebruik maakt van programma's of tools om je OpenStack project mee te beheren, dan dien je hierin ook een aanpassing te maken. Zo wijzigt het regio van AMS naar AMS2, en ook de availability zones:

Blijven interne netwerken werken na de migratie?

Ja. Het interne netwerk wordt uitgebreid naar de nieuwe regio. Houd wel rekening met extra hersteltijd na de migratie van uiterlijk 20 minuten.

Moet ik zelf een project in de nieuwe regio aanmaken?

Nee. Een identiek project met dezelfde project-id wordt geactiveerd in de nieuwe regio. Hier hoef je zelf niets voor te doen.

Kan er naar een bestaand project in de nieuwe regio worden gemigreerd?

Ja. Heb je een of meerdere projecten in de nieuwe regio en wil je naar een specifiek bestaand project migreren? Neem dan contact op met support om dit te configureren.

Wat gebeurt er met snapshots op volumes?

Snapshots op volumes worden niet meegenomen, omdat deze niet kunnen worden gedupliceerd.

Wil je een snapshot bewaren? Maak dan voor de migratie een nieuw volume met de snapshot als bron. Dit doe je in Horizon via ‘Volumes’ > ‘New Volume’ > ‘Clone an existing volume’. Selecteer daar het volume en de snapshot die je wilt gebruiken.

Worden custom images en snapshots gemigreerd?

Ja, deze worden inderdaad gemigreerd naar de nieuwe regio.

Wat gebeurt er als ik een floating IP-adres heb zonder router?

Helaas ondersteunt de nieuwe AMS2-regio niet langer het gebruik van een floating IP-adres zonder router. Daarom maken wij voor elk netwerk waarop een floating IP zonder router is geconfigureerd automatisch een router aan en verbinden deze met het floating network.

Hierdoor wordt één extra publiek IPv4-adres toegevoegd aan je maandelijkse factuur (€2,77 excl. btw).

Word ik nog gefactureerd voor resources op het oude platform?

De facturatie voor gemigreerde resources op het oude platform stopt zodra de instance op het oude platform is uitgeschakeld. Resources op het nieuwe platform worden gefactureerd vanaf het moment dat ze zijn aangemaakt.

Worden SSH keys gemigreerd?

Ja. SSH keys worden naar de nieuwe regio gekopieerd voor de gemigreerde instance. De Keypair wordt niet als losse key naar jouw gebruiker in de nieuwe regio gemigreerd.

Besturingssystemen en instance-eigenschappen

Wat gebeurt er met mijn Windows-licentie?

Tijdens de migratie wordt een nieuwe virtual machine op het nieuwe platform aangemaakt. Windows detecteert de nieuwe hardware en configureert het besturingssysteem opnieuw waar nodig. Daardoor kan Windows na de migratie opnieuw om activatie vragen.

Controleer de activatie via ‘Windows System settings’ > ‘Activation’ > ‘Troubleshoot’ of ‘Activate’.

Wijzigt mijn SSH host key als cloud-init actief is?

Ja. Door de migratie krijgt de instance een nieuwe UUID en naam. Cloud-init ziet dit standaard als een nieuwe instance en initialiseert het systeem opnieuw. Daardoor wordt ook de SSH host key uit cloud-init gebruikt.

Wil je dit voorkomen? Schakel cloud-init uit voordat de migratie naar de nieuwe regio start.

Welke flavor krijgt mijn nieuwe instance?

De flavors in de oude regio en de nieuwe regio zijn gelijk. Je nieuwe instance krijgt daarom dezelfde flavor.

Mocht je aan de hand van deze FAQ nog vragen hebben, neem dan contact op met support.