Rehost med Azure Migrate (Lift and Shift)

Rehost — ofte kaldet Lift and Shift — er den migrationsstrategi, hvor du flytter en VM fra det lokale miljø til Azure uden at ændre operativsystemet, programbinærfilerne eller dataene. Azure Migrates værktøj Migration and Modernisation (tidligere Server Migration) automatiserer denne proces ved at replikere diskdata til Azure og derefter skifte over med minimal nedetid. Lift and Shift er ideel til applikationer, der ikke let kan refaktoreres, eller som har stramme migrationsfrister.

Før du starter replikeringen, skal du: gennemføre registrering og vurdering, så du har anbefalinger til mål-VM-SKU'er, oprette de Azure-ressourcer, der skal bruges som mål (ressourcegruppe, virtuelt netværk og undernet) og sikre, at Azure Migrate-apparatet er sundt. For VMware-kilder skal apparatet have læsetilladelser til vCenter, og gæste-VM'en skal kunne nås via netværket fra apparatet. Download og registrer softwaren Replication Provider, hvis du migrerer fra Hyper-V eller fysiske servere.

Replikering kopierer alle diskdata fra kilde-VM'en til en Azure-administreret cachelagringskonto og placerer derefter dataene asynkront i Azure. Gå til Replicate i Azure Migrate-portalen, vælg dine kilde-VM'er, tilknyt dem til den anbefalede Azure-VM-SKU, og vælg det virtuelle netværk som mål. Den indledende replikeringstid afhænger af diskstørrelsen og båndbredden — en disk på 100 GB via en forbindelse på 100 Mbps tager cirka 2 timer at synkronisere første gang.

Efter at det indledende diskaftryk er kopieret, skifter Azure Migrate til deltareplikering — kun ændrede diskblokke sendes, så Azure-kopien holdes synkroniseret med den lokale kilde næsten i realtid. VM'en fortsætter med at køre lokalt i denne fase. Du kan overvåge replikeringens tilstand, RPO-forsinkelsen og dataoverførselshastighederne i portalen. Deltareplikering stabiliserer sig typisk med en forsinkelse på kun få minutter inden for 24 timer efter afslutningen af den indledende synkronisering.

Før du skifter produktionstrafikken over, skal du altid køre en testmigrering. Det starter den replikerede VM i Azure på et isoleret virtuelt testnetværk, som ikke har forbindelse til produktionssystemer. Du validerer, at operativsystemet starter, tjenesterne kører, og applikationens funktionalitet virker som forventet. Testmigreringer afbryder ikke den lokale replikering — kilde-VM'en fortsætter med at køre. Efter testen skal du rydde testressourcerne op i portalen for at undgå unødvendige omkostninger.

Overdragelsen er det sidste trin, hvor produktionstrafikken flyttes fra det lokale miljø til Azure. Under overdragelsen sættes kilde-VM'en i bero (eller du lukker den manuelt), eventuelle resterende deltaændringer anvendes på Azure-replikaen, og den nye Azure-VM startes. Fordi dette er en migrering på lagerniveau, går overdragelsen typisk meget hurtigt — under 10 minutter for de fleste VM'er. Planlæg overdragelsen i et vedligeholdelsesvindue, og informer de ansvarlige for applikationen på forhånd.

Klik på Migrate for den valgte server i Azure Migrate-portalen. Du bliver spurgt, om du vil lukke den lokale VM ned før migreringen (anbefales for at undgå datatab). Azure anvender den sidste delta, opretter Azure-VM'en og markerer migreringen som fuldført. Du skal derefter opdatere DNS-poster, backends for belastningsfordelere eller forbindelsesstrenge til applikationen, så de peger på den nye private Azure-IP-adresse eller det nye FQDN, så klienterne begynder at bruge Azure-VM'en.

Efter overdragelsen skal du udføre disse kontroller efter migreringen: applikationens tilstand (indlæs alle applikationssider, og kør smoke tests), forbindelse (bekræft, at Azure-VM'en kan nå afhængige databaser og tjenester), overvågning (installer Azure Monitor-agenten, og aktivér diagnosticering) og sikkerhedskopiering (tilmeld VM'en i Azure Backup). Hvis der opdages problemer, kan den lokale kilde-VM genstartes — den er stadig intakt, indtil du udtrykkeligt tager den ud af drift.

Når den migrerede VM er stabil i Azure, og de ansvarlige har godkendt resultatet, kan du tage den lokale kilde-VM ud af drift. Vælg Complete Migration i Azure Migrate for at afslutte replikeringen. Dette lukker ikke automatisk den lokale VM ned — du skal slukke den og frigive hardwaren gennem din normale proces for IT-aktivstyring. Nedlukning reducerer omkostningerne til lokal infrastruktur og bringer dig tættere på en driftsmodel, der udelukkende er baseret på skyen.

Ved store migreringer, der omfatter hundredvis af VM'er, understøtter Azure Migrate massehandlinger via CSV-import. Du forbereder en CSV-fil med hver kilde-VM, dens mål-SKU, målressourcegruppe og virtuelle netværk og uploader den derefter for at starte replikering af alle VM'er samtidigt. Migrationsgrupper lader dig fastlægge rækkefølgen for replikering og overdragelse, så afhængige applikationslag (database, applikation og web) migreres i den korrekte rækkefølge inden for det samme vedligeholdelsesvindue.

Vær opmærksom på disse almindelige problemer ved Lift and Shift: kryptering af startdisken på Linux-VM'er kan forhindre Azure i at starte dem (brug Azure Disk Encryption efter migreringen); statiske IP-adresser, der er fast indkodet i applikationskonfigurationer, skal opdateres til private Azure-IP-adresser eller DNS-navne; firewallregler i det lokale miljø, der henviser til serverens IP-adresse, skal muligvis genskabes i en Azure-NSG; og indstillinger for tidszone på Windows-VM'er kan medføre ændringer i applikationens adfærd i Azures UTC-miljø.

I denne lektion lærte du, at Rehost-migreringsforløbet går fra replikering til deltasynkronisering, testmigrering og overdragelse, at testmigrering validerer VM'en på et isoleret netværk, før den sættes i drift, og at trinene efter migreringen (overvågning, sikkerhedskopiering og DNS-opdatering) er afgørende, før lokale ressourcer tages ud af drift. Det næste, vi gennemgår, er bedste praksis for migrering af databaser til Azure.