In dit artikel vind je een antwoord op de meest gestelde vragen over de migratie naar het nieuwe OpenStack-platform.
- Hoe kan ik mijn instances op deze migratie voorbereiden?
- Kun je me een korte samenvatting van het proces geven?
- Niet al mijn instances hebben de migratie-metadata, wat is de reden?
- Worden mijn SSH-keys gemigreerd?
- Mijn instance werkt niet zoals verwacht na de migratie, kan ik een roll-back uitvoeren?
- Als ik al instances met dezelfde naam in de nieuwe regio heb, worden die dan overschreven?
- Wat is de verwachte downtime tijdens de migratie?
- Zal de migratie van een instance invloed hebben op mijn andere operationele instances?
- Hoe kan ik de migratie zelf starten?
- Wat gebeurt er als ik de migratie niet zelf start of inplan?
- Kan ik buiten de kantooruren migreren?
- Wat gebeurt er als de migratie mislukt?
- Hoe kan ik zien of de migratie succesvol was?
- Waar kan ik mijn gemigreerde instance beheren?
- Mijn instance is via een intern netwerk verbonden met mijn andere instances, werkt dit nog na de migratie?
- Ik heb geen projecten in de nieuwe regio, moet ik er zelf een aanmaken?
- Ik heb meerdere projecten in de nieuwe regio, kunnen jullie mijn huidige resources naar mijn bestaande project migreren?
- Wat gebeurt er met snapshots die aan mijn volumes gekoppeld zijn?
- Worden glance-images (snapshots/custom images) ook geïmporteerd in de nieuwe regio?
- Behoud ik mijn huidige IP-adressen?
- Ik wil al mijn resources zo snel mogelijk migreren, is dat mogelijk?
- Blijf ik gefactureerd worden voor mijn gemigreerde resources op het oude platform?
- Zal mijn SSH-hostkey veranderen als cloud-init is ingeschakeld?
- Welke flavor krijgt mijn nieuwe instance?
Hoe kan ik mijn instances op deze migratie voorbereiden?
- Schakel je instance uit en start deze opnieuw op vóór de migratie om te controleren of de instance zonder onderbrekingen of foutmeldingen probleemloos opstart (een gewone reboot is niet voldoende).
- Zorg ervoor dat cloud(base)-init is uitgeschakeld voordat je met de migratie start.
- Voer voorafgaand aan de migratie een bestandssysteemcontrole uit op alle bestandssystemen.
- Zorg ervoor dat er geen updates voor je systeem klaarstaan, zodat het installeren van patches de migratie niet kan onderbreken (aangezien dit proces mogelijk voortijdig wordt afgebroken).
Kun je me een korte samenvatting van het proces geven?
- Je instance wordt gemigreerd naar een boot-from-volume-instance.
- Als je een floating IP hebt, migreren we dat mee.
- We hebben voor jou een nieuw project aangemaakt op het nieuwe platform.
- Als je gebruikmaakt van custom images of een snapshot om je instance van op te starten, migreren we deze Glance-images ook.
- Als je je instance verbonden hebt met een intern netwerk, zullen we dat netwerk uitbreiden naar de nieuwe regio.
- Als je een router voor internettoegang op je netwerk hebt, zal het publieke IP-adres veranderen.
- Als je volumes aan je instance gekoppeld hebt, zullen we die naar het nieuwe platform kopiëren.
- Als je snapshots op die volumes hebt, zullen die verloren gaan.
- Als je cloud-init niet uitschakelt, zal je SSH-hostkey wijzigen bij de migratie naar de nieuwe regio.
- Op Windows-guests zal het admin-wachtwoord worden gewijzigd als cloudbase-init niet werd uitgeschakeld.
- We gebruiken ICMP-ping om te bepalen of je instance actief is en goed draait, bereid je instance hier dus op voor.
- We zullen vaak gebruikte poorten controleren (zoals poort 22, 80, 443, enz.).
- Als je een HA-setup hebt, zijn er wel enkele aandachtspunten.
Niet al mijn instances hebben de migratie-metadata, wat is de reden?
We zijn de laatste stappen aan het afronden om de migratie van alle instances naar de nieuwe regio mogelijk te maken.
- Als je instance volumes gebruikt die groter dan of gelijk aan 1024 GByte zijn, moet deze instance op een strak schema worden gemigreerd om de impact van de migratie te beperken.
- Als je instance gebruikmaakt van load balancing, zullen we je instance in een later stadium migreren.
- Instances die deel uitmaken van een groot intern netwerk zullen in een later stadium worden gemigreerd.
- HA-/VRRP-setups zullen in een later stadium worden gemigreerd.
- Interne netwerken met custom routers zullen in een later stadium worden gemigreerd.
Worden mijn SSH-keys gemigreerd?
Ja, die worden gemigreerd. Je SSH-keys worden naar de nieuwe regio gekopieerd, maar alleen voor de instance (ze worden niet naar je gebruiker gemigreerd).
Mijn instance werkt niet zoals verwacht na de migratie, kan ik een roll-back uitvoeren?
Ja, zodra de migratie succesvol is afgerond, kun je een rollback uitvoeren door de metadatakey rollback-now in te stellen op je instance binnen het legacy Horizon-dashboard.
Als je een rollback uitvoert, laat ons dan zeker weten wat de reden is. We horen graag wat er misliep zodat we het proces kunnen verbeteren en gelijkaardige situaties in de toekomst kunnen voorkomen.
Let op: alle wijzigingen die op de nieuwe instance zijn aangebracht, worden niet teruggezet en gaan dus verloren. Een rollback is enkel mogelijk binnen de eerste 5 dagen na de migratie.
Als ik al instances met dezelfde naam in de nieuwe regio heb, worden die dan overschreven?
Nee, we zullen niets in de nieuwe regio overschrijven.
Wat is de verwachte downtime tijdens de migratie?
- We hebben instances gezien met een downtime van minder dan een minuut, maar om veilig te zijn, hou je best rekening met tot 15 minuten (de migratie hangt af van de tijd die nodig is om de instance op te starten en alle services te laten draaien).
- Onze tests tonen aan dat de downtime zo laag als 40 seconden kan zijn bij minimale load op je instance. Er wordt een nette (graceful) shutdown gestart via de OpenStack-API’s. Daarna wordt een nieuwe instance opgestart en aangemaakt in de nieuwe regio, met een kopie van de schijf. Het proces monitort de opstarttijd en als die meer dan 10 minuten bedraagt, zullen we automatisch een rollback starten.
- Als de instance verbonden is met een intern netwerk, zal die verbinding tot 10 minuten onderbroken zijn. Deze verbinding is nodig om het interne netwerk tussen de legacy-regio en de nieuwe regio te synchroniseren.
- Wanneer de migratie is afgerond en je instance succesvol is opgestart in de nieuwe regio, voorzie dan nog eens 10 extra minuten voor het interne netwerk om volledig beschikbaar te worden.
- Als het interne netwerk binnen 20 minuten na het voltooien van de migratie nog steeds niet reageert, neem dan contact op met support en start een rollback van je instance.
Zal de migratie van een instance invloed hebben op mijn andere operationele instances?
Tenzij je zelf een afhankelijkheid hebt gecreëerd met die instance, zullen je andere instances niet beïnvloed worden.
Hoe kan ik de migratie zelf starten?
Wanneer je instance gemarkeerd is voor migratie, wordt er extra metadata toegevoegd aan je instance met de naam o2o-scheduled-YYYY-MM-DDTHH:MM:SS. Je kunt de migratie inplannen door de datum/tijd aan te passen (tijden zijn in de Europe/Amsterdam-tijdzone!) naar jouw voorkeur. Een datum/tijd in het verleden zal de migratie zo snel mogelijk starten zodra er een migratieslot beschikbaar is (normaal binnen een minuut). Als alternatief kun je de metadata o2o-migrate-now instellen op de metadatakey migrate_flag.
Om de metadata van je instance in te stellen of te wijzigen, ga je in de Horizon-interface naar Project > Compute > Instances. Klik op het driehoekje More options naast de betreffende instance en kies Update Metadata.

Open Provider platform options > Migration en klik op + bij Scheduling options. Pas de datum/tijdstempel aan naar wens en klik op Save.
Open Provider platform options > Migration en klik op + bij Scheduling options. Update de datum/tijdstempel aan naar wens en klik op Save

Wat gebeurt er als ik de migratie niet zelf start of inplan?
Je instance wordt tijdens de kantooruren (9:00–17:00, tijdzone Europe/Amsterdam) gemigreerd op de datum die we per e-mail hebben gecommuniceerd en die in de metadata is ingesteld.
Kan ik buiten de kantooruren migreren?
Ja, dat kan door de migratie in te plannen via de meegegeven metadata (zie hierboven: Hoe kan ik de migratie zelf starten?).
Wat gebeurt er als de migratie mislukt?
Als de migratie mislukt, wordt je instance opnieuw opgestart op het huidige OpenStack-platform. We onderzoeken vervolgens de oorzaak van de fout en informeren je over een nieuwe migratiedatum.
Hoe kan ik zien of de migratie succesvol was?
Als de migratie succesvol is, zal de instance in de status ‘SHUTOFF’ terechtkomen. Dit kun je controleren via de OpenStack Legacy API of in het Horizon-dashboard. De instance zal vergrendeld (locked) zijn. De voortgang van de migratie kan worden opgevolgd via de metadatakey _export_progress.
Waar kan ik mijn gemigreerde instance beheren?
Je gemigreerde instance kan beheerd worden via het nieuwe Horizon-dashboard, dat toegankelijk is via het controlepaneel.
Mijn instance is via een intern netwerk verbonden met mijn andere instances, werkt dit nog na de migratie?
Ja, je interne netwerk wordt uitgebreid naar de nieuwe regio.
Ik heb geen projecten in de nieuwe regio, moet ik er zelf een aanmaken?
Nee, als je nog geen projecten in onze nieuwe regio hebt aangemaakt, hebben wij al een project voor je aangemaakt.
Ik heb meerdere projecten in de nieuwe regio, kunnen jullie mijn huidige resources naar mijn bestaande project migreren?
Ja, neem hiervoor contact op met support met de gewenste projectmapping(s), zodat wij dit correct kunnen instellen.
Wat gebeurt er met snapshots die aan mijn volumes gekoppeld zijn?
Die gaan verloren, omdat we snapshots niet kunnen dupliceren van het legacy-platform naar het nieuwe platform. Als je een snapshot van je volume wilt bewaren, maak dan een nieuw volume aan met de snapshot als bron. Dit kan in Horizon via: Volumes > New Volume > Clone an existing volume. Daar selecteer je het volume waarvan je de snapshot wilt klonen en kun je de snapshot zelf kiezen.
Worden glance-images (snapshots/custom images) ook geïmporteerd in de nieuwe regio?
Ja, maar alleen als de image nog beschikbaar is (niet verwijderd).
Behoud ik mijn huidige IP-adressen?
Ja, al je publieke (floating) en interne IP-adressen worden gemigreerd.
Ik wil al mijn resources zo snel mogelijk migreren, is dat mogelijk?
We werken continu aan het oplossen van problemen die bepaalde migraties kunnen blokkeren. Je kunt contact opnemen met support om te laten nakijken of je instances al gemigreerd kunnen worden.
Blijf ik gefactureerd worden voor mijn gemigreerde resources op het oude platform?
Vanaf het moment dat de eerste migratie wordt gestart, blijven we je huidige resources factureren totdat alle resources van je project gemigreerd zijn. Zodra alle resources in je project gemigreerd zijn, starten we de facturatie van je resources vanuit ams2 en stoppen we de facturatie vanaf het legacy-platform.
Zal mijn SSH-hostkey veranderen als cloud-init is ingeschakeld?
Ja, de migratie van het legacy-platform naar de nieuwe regio resulteert in een nieuwe UUID en naam voor je instance. Door de manier waarop cloud-init standaard werkt, zal cloud-init je systeem daardoor opnieuw initialiseren alsof het een nieuwe instance is. Dit zorgt er ook voor dat je SSH-hostkey wordt vernieuwd. Als je dit niet wilt, schakel dan cloud-init uit voordat de migratie naar de nieuwe regio start.
Welke flavor krijgt mijn nieuwe instance?
We hebben zorgvuldig doel-flavors geselecteerd die zo goed mogelijk overeenkomen met de specificaties en prijs van je OpenStack Legacy-flavor. In de volgende tabel (niet hier weergegeven) kun je zien hoe flavors worden gematcht. Als de gekozen flavor niet volstaat, kun je je instance na de migratie resizen naar een andere flavor.
| Openstack Legacy | destination |
|---|---|
| m1.tiny | Small HD 2GB |
| m1.small | Standard 4GB |
| m1.medium | Small HD 8GB |
| m1.xlarge | Small HD 32GB |
| m1.large | Small HD 16GB |
| m1.tiny.windows | Standard 1GB |
| m1.small.windows | Standard 4GB |
| m1.medium.windows | Small HD 8GB |
| m1.large.windows | Small HD 16GB |
| m1.xlarge.windows | Small HD 32GB |
| vps.1 | Standard 1GB |
| vps.2 | Standard 4GB |
| vps.3 | Medium HD 8GB |