Sla over en ga naar content

De stap-voor-stap gids voor het migreren van VM’s naar GCP met behulp van Migrate to Virtual Machines

Inzicht van experts in de migratie van een groep VM's met behulp van Migrate to Virtual Machines.

Google Cloud

Uw VM’s naar Google Compute Engine in 9 stappen. 

Beheert u nog on-premise VM’s? Dan herkent u ongetwijfeld de volgende punten: de serverapparatuur heeft onderhoud nodig, er is voldoende IT-personeel nodig, de energieprijzen rijzen de pan uit, u heeft voldoende capaciteit nodig voor piekbelastingen en ga zo maar door. Vanwege al deze zaken stappen veel bedrijven over van lokale datacenters naar een cloudomgeving, hetzij volledig, hetzij in een hybride configuratie.

GCP heeft een tool beschikbaar om de migratie van VM’s naar Compute Engine te vergemakkelijken, genaamd Migrate to Virtual Machines (voorheen Migrate for Compute Engine). Deze tool maakt relatief eenvoudige VM-migraties mogelijk, met minimale downtime. VM’s kunnen alleen of als onderdeel van een migratiegroep worden gemigreerd. 

Bij deze lift-and-shift-migratie worden bestaande workloads met minimale wijzigingen naar de cloud verplaatst, zodat iedereen ze kan blijven gebruiken zoals voorheen. Veel gemakkelijker en sneller dan de improve-and-move of remove-and-replace migraties. Ideaal als u uw workloads in een kort tijdsbestek wilt migreren alvorens ze te refactoren naar een meer cloud-native oplossing, of als u ze om technische redenen niet kunt refactoren. Deze post biedt een snelle stap-voor-stap handleiding en enkele tips voor het migreren van een groep VM’s met Migrate to Virtual Machines.

Het project opzetten 

Stap 1: het opzetten van het hostproject

Om Migrate to Virtual Machines te gebruiken, hebt u een hostproject nodig. Het host project zal alle migraties initiëren en zich registreren bij de connector (zie later). Als u dat wilt, kan het project ook de gemigreerde workloads uitvoeren. Verderop in de gids krijg je meer informatie over het instellen van doelprojecten. 

Het host project moet de volgende API’s hebben ingeschakeld:

  • Migrate to Virtual Machines API
  • Service Management API (standaard ingeschakeld op een nieuw project)
  • Service Control API
  • Identity and Access Management (IAM) API
  • Cloud Resource Manager API
  • Compute Engine API

Groepen met gebruikers die migraties moeten kunnen uitvoeren, hebben de rol VM Migration Administrator nodig. Groepen met gebruikers die informatie over migraties moeten bekijken, krijgen de rol VM Migration Viewer.

Stap 2: de bron instellen

Om uw VM’s te kunnen bereiken, moet u een bron instellen. Dit doet u door een connector te installeren op de bron en deze te registreren bij uw hostproject. Het verkeer van uw bron naar de Google Cloud API’s gaat over een beveiligd pad via het openbare internet. Voor een VPN of interconnectie kunt u in plaats daarvan Private Google Access gebruiken. Zie dit architectuurdocument voor meer details. 

In deze post gaan we niet verder in op het proces, maar u kunt de stappen in deze snelstartgids volgen (kleine opmerking: het commando dat in deze gids wordt gebruikt om de connector te registreren is m4c (migrate for compute), terwijl het nu m2vm is).

Stap 3: doelproject

Het doelproject zal de werklasten uitvoeren. Zoals gezegd kan dit hetzelfde zijn als het hostproject. 

De volgende API’s moeten worden ingeschakeld:

  • Service Management API
  • Service Control API
  • Identity and Access Management (IAM) API
  • Cloud Resource Manager API
  • Compute Engine API

De gebruiker die het doelproject toevoegt heeft de Project IAM Admin rol nodig, naast de VM Migration Administrator rol op het hostproject. Als u over deze rollen beschikt, voegt u het doelproject toe in de console, onder het tabblad Doelen in Migreren naar virtuele machines. 

Als u de IAM Admin-rol niet kunt toewijzen aan de gebruiker die het doelproject opzet, moet u handmatig de Migrate to Virtual Machines default service account toewijzen aan de VM Migration service agent rol op het doelproject.

VMs migreren

Migraties kunnen één voor één worden uitgevoerd, of je kunt VM’s groeperen in een migratiegroep om ze te volgen en samen te migreren. U kunt ook groepen gebruiken om individuele VM’s te migreren.Daarom zou ik aanraden altijd de migratiegroepen te gebruiken, zodat u een beter overzicht hebt van de lopende migraties.

Stap 4: zet een migratiegroep op

Navigeer naar de Google Cloud console > Compute Engine > Migreren naar virtuele machines. Ga naar Sources, en selecteer alle te migreren VM’s.

Zodra alle gewenste VM’s zijn geselecteerd, klikt u op ‘Toevoegen aan groep’, en maakt u een nieuwe migratiegroep aan.
Navigeer daarna naar het tabblad ‘Groepen’, en selecteer de nieuw aangemaakte groep. 

U kunt de instellingen voor de doelmigratie voor elke VM afzonderlijk wijzigen. Bij groepsmigraties is het vaak interessanter om alle VM’s tegelijk te configureren. U kunt de migratiegroep exporteren naar een CSV-bestand, en daar de instellingen bewerken. Met de gewenste groep geselecteerd, drukt u op exporteren om het CSV-bestand te genereren.

Sla deze export op en open hem in een editor naar keuze (of importeer hem in google sheets). Vul de vereiste specificaties in. Sommige waarden zijn verplicht, andere zijn optioneel. Regio, bronnaam, bron-VM-naam, bron-VM-ID en migratiegroep zouden al gevuld moeten zijn. De volgende zijn verplicht:

  • Instance name, for example: tutorial-vm
  • Project, for example: projects/pj-m2vm-tutorial-host/locations/global/targetProjects/pj-m2vm-tutorial-target
  • Zone, for example: europe-west3-c
  • Machine type series and machine type: make sure these are sized appropriately. For example: n2, n2-custom-2-2048
  • Network and subnetwork, the name of the VPC and subnet in which to place the VM. For example: nw-m2vm, projects/pj-m2vm-tutorial-target/regions/europe-west3/subnetworks/nwr-m2vm-tutorial

Er zijn verschillende andere opties van belang die waarschijnlijk moeten worden ingevuld:

  • Schijftype, bijvoorbeeld: Standaard
  • Extern IP, het is aanbevolen om het gebruik van externe IP’s op VM’s zoveel mogelijk te beperken. Indien nodig kan dit worden ingesteld op ‘ephemeral’ of op de naam van een eerder gereserveerde externe IP.
  • Intern IP, als u een specifiek intern IP nodig hebt. Anders wordt het automatisch gegenereerd uit uw subnetbereik.
  • Netwerk tags, bijvoorbeeld: nwt-https-server
  • Service account. Aangezien het de beste praktijk is om niet de standaard compute service account te gebruiken, moet u een service account opgeven met beperkte IAM-machtigingen voor uw VM’s.

De andere waarden kunnen naar behoefte worden ingevuld.

Nadat u het CSV-bestand hebt bewerkt, kunt u het importeren om de migratiegegevens van de migratiegroep bij te werken.

Stap 5: start de replicatie

Klik op de migratiegroep, je zou een lijst van alle VM’s in de groep moeten zien. Selecteer degene waarvoor je de replicatie wilt starten, en klik op Replicatie starten.


Afhankelijk van de grootte van de VM’s en de capaciteit van de verbinding, kan de eerste replicatie even duren. Zodra deze klaar is, zijn de VM’s klaar voor cut-over, maar wij raden aan eerst een testkloon te maken.

Stap 6: test-clone

Test-klonen in Compute Engine creëert de laatste replicatie van de VM’s als images, maar raakt de bron-VM’s niet aan. De testklonen valideren of alles correct werkt in de cloud.

De statuskolommen test-clone/cut-over houden je op de hoogte wanneer de test-clone klaar is. De testklonen zullen beschikbaar zijn als normale Compute Engine VM’s, en kunnen worden geïnspecteerd zoals u normaal zou doen. De image blijft gerepliceerd worden, zelfs als de testklonen draaien. De testklonen worden echter niet bijgewerkt als de replicatie doorgaat, ze houden het image zoals het was toen de testkloon werd gestart. Om nieuwere images te testen, start u een nieuwe testkloon. Zodra u klaar bent met testen op de klonen, kunt u ze veilig verwijderen.
Als alles tot dit punt succesvol was, is het tijd om de VM’s over te zetten.

Stap 7: cut-over

Zodra alles is getest en gevalideerd, is het tijd om de cut-over uit te voeren. Houd er rekening mee dat tijdens de cut-over de bron-VM’s worden afgesloten en de VM’s in de cloud worden opgestart. Er zal een klein venster van downtime zijn. Zorg ervoor dat u de nodige voorzorgsmaatregelen neemt voor kritieke applicaties.

De cut-over wacht tot de huidige replicatie is voltooid (als er een aan de gang is), sluit de bron-VM’s af, voert een laatste replicatie uit en maakt de Compute Engine instance aan met de laatste replicatie-image. Hierna worden geen replicaties meer uitgevoerd (tenzij je ze handmatig hervat!). 

Zodra de nieuwe VM’s werken, valideert u ze opnieuw. Als u zeker weet dat alles werkt zoals bedoeld en alle validaties zijn geslaagd, kunt u de migratie afronden. Zo niet, dan moet je de VM’s handmatig terugdraaien door de instance in GCE te verwijderen en de VM’s terug te starten in de bronomgeving.

Stap 8: de migratie afronden

Het voltooien van een migratie betekent dat alle replicatiegegevens en andere opslaggerelateerde bronnen worden verwijderd. Als u deze stap niet uitvoert, blijft u gefactureerd worden voor de replicatieopslag. Het is een belangrijke stap om uit te voeren die gemakkelijk wordt vergeten na migraties. U vindt hem onder het keuzemenu MIGRATIE.

Stap 9: alles in Terraform definiëren (optioneel)

Op dit punt is de migratie zelf klaar. Als u werkt met Infrastructure as Code zoals Terraform (wat wij aanbevelen!), moet u de VM’s en hun schijven definiëren in Terraform. Begin met het definiëren van de resources in Terraform (bij voorkeur met behulp van modules). Na deze stap importeer je ze in je state. Je hebt de volgende gegevens nodig om een instantie te importeren:

  • Het project ID
  • De zone waarin de instantie zich bevindt
  • De naam van de instantie

Om een schijf te importeren heeft u de volgende gegevens nodig:

  • Het project ID
  • De zone waarin de schijf zich bevindt
  • De naam van de schijf (deze kan worden gevonden in de console, zie screenshot hieronder)

Natuurlijk moet je de adressen in je Terraform-definitie weten. Als je niet zeker weet welke adressen je instances en schijven zullen hebben, kun je altijd het Terraform plan uitvoeren om te zien onder welke adresnaam Terraform de resources wil aanmaken.

Het commando om een instantie te importeren ziet er ongeveer zo uit:

terraform import google_compute_instance.imported_vm projects/pj-m2vm-tutorial-target/zones/europe-west3-c/instances/tutorial-vm

Voor een opstartschijf ziet het er ongeveer zo uit:

terraform import google_compute_disk.imported_disk projects/pj-m2vm-tutorial-target/zones/europe-west3-c/disks/tutorial-vm-d0-0e2b9f

Zodra de resources zijn geïmporteerd, voert u het plan uit. Als het plan probeert uw instanties en/of schijven opnieuw aan te maken, moet u wellicht uw Terraform-definitie aanpassen totdat er geen wijzigingen meer zijn in de instanties en schijven.

Gefeliciteerd, u weet nu hoe u met succes VM’s kunt migreren van on-premises naar Google Cloud met behulp van Migrate to Virtual Machines. Het Migratiecentrum, dat in preview is, zal onder andere gebruikmaken van deze tool. Migreren vanuit AWS is momenteel ook in preview. Migrate to Virtual Machines maakt het proces van het migreren van VM’s veel beter beheersbaar en maakt het mogelijk om honderden VM’s tegelijk te migreren.

Mocht u vragen hebben of de komende migraties willen bespreken, neem dan gerust contact met ons op!

Documentation

  • Migrate to Virtual Machines documentation: https://cloud.google.com/migrate/virtual-machines/docs/5.0
  • Importing Google Cloud resources in Terraform: https://cloud.google.com/docs/terraform/resource-management/import