Live-migrering i Hyper-V: en komplet guide til at flytte VM'er uden at stoppe tjenester

Live-migrering i Hyper-V Det er blevet en nøglekomponent i enhver moderne virtuel infrastruktur, der skal holde sine tjenester altid tilgængelige, selv under vedligeholdelse eller omorganisering af ressourcer mellem servere. Takket være denne funktionalitet er det muligt at flytte kørende virtuelle maskiner mellem fysiske værter transparent for brugeren, med så minimal nedetid, at det i praksis normalt er umærkeligt.

Bag denne "magi" ligger der mange kravKomplementære teknologier og også typiske problemer, der kan opstå, hvis noget ikke er konfigureret korrekt: fra CPU-inkompatibiliteter til Kerberos-godkendelsesfejl, netværksfejl, forkert konfigureret delt lagring eller VM-konfigurationsversioner, der ikke stemmer overens på tværs af værter. En grundig forståelse af, hvordan Hyper-V Live Migration fungerer, hvilke tilstande den tilbyder, hvad den skal bruge for at fungere pålideligt, og hvordan man fejlfinder, når den fejler, er afgørende, hvis du administrerer miljøer. Windows Server i produktion.

Hvad er livemigrering præcist i Hyper-V?

Hyper-V Live-migrering Det er en Windows Server-funktion (introduceret i Windows Server 2008 R2 og forbedret i senere versioner), der giver dig mulighed for at flytte en kørende virtuel maskine fra én Hyper-V-vært til en anden uden at lukke den ned. Hovedformålet er at muliggøre belastningsbalancering, planlagt vedligeholdelse og ressourceoptimering, samtidig med at påvirkningen på brugertjenester minimeres.

I modsætning til en "kold" migrationI denne proces slukkes den virtuelle maskine, flyttes og tændes derefter igen på den nye vært. Live Migration kopierer hukommelses- og CPU-tilstanden, mens den virtuelle maskine fortsætter med at køre. Der er kun en meget kort pause i slutningen af ​​processen, hvor den resterende hukommelse synkroniseres, og udførelsen skifter til destinationsværten.

Denne funktionalitet er tæt forbundet med høj tilgængelighedNår det kombineres med failover-klynger (WSFC) og i mange tilfælde med System Center Virtual Machine Manager (SCVMM), giver det dig mulighed for at bygge fejltolerante platforme, der er i stand til at flytte kritiske arbejdsbelastninger fra én node til en anden på få sekunder.

I moderne versioner som Windows Server 2016, 2019 eller 2022Hyper-V Live Migration har fjernet restriktioner, såsom det strenge krav om en klynge i alle scenarier. I dag er det muligt at udføre live-migreringer uden en failover-klynge, blot mellem korrekt konfigurerede, separate værter, hvilket åbner døren til mere fleksible miljøer.

Grundlæggende arkitektur og krav til Hyper-V Live Migration

For at live-migreringen kan fungere pålideligtDet er vigtigt, at kilde- og destinationsværterne opfylder en række krav til hardware, software, netværk og lagring. Selvom nogle krav er blevet lempet med El tiempoAt følge visse bedste fremgangsmåder gør forskellen mellem en problemfri migrering og en masse fejl i hændelsesvisningen.

På operativsystemniveauBegge servere skal køre kompatible versioner af Windows Server med Hyper-V aktiveret og korrekt opdateret (servicepakker, kumulative opdateringer og opdateret firmware/BIOS). Ideelt set bør alle noder i produktion dele den samme systemversion og et ensartet patchniveau.

Med hensyn til processorenTypisk har værter CPU'er fra samme familie og generation (for eksempel Intel-Intel fra samme linje) for at undgå avancerede instruktionskonflikter. Hyper-V giver dig mulighed for at aktivere indstillingen "migrer til en fysisk maskine med en anden processorversion" i VM-indstillingerne for at udjævne forskelle mellem generationer, men det løser ikke producentændringer: du kan ikke flytte en kørende VM fra en vært med en AMD CPU til en med en Intel CPU. IntelMedmindre du slukker den virtuelle maskine og udfører en migrering uden at den er tændt.

Netværkskomponenten er også fundamentalDe netværk, der bruges til administration, livemigrering, VM-trafik og, hvis relevant, lagring, skal være korrekt konfigureret med statiske IP-adresser, lav latenstid og tilstrækkelig båndbredde. I produktionsmiljøer er det almindelig praksis at reservere dedikerede netværk til livemigrering for at undgå overbelastning af brugertrafik.

I klassiske scenarier med failover-klyngerAnbefalingen er at have delt lagerplads (SAN, NAS(SMB 3.0) tilgængelig fra alle noder i klyngen. Delt lagring forenkler migrering betydeligt, fordi virtuelle diske ikke fysisk skal flyttes fra én vært til en anden; kun ejeren, der administrerer dem, ændres.

Live-migreringstilstande i Hyper-V

Hyper-V tilbyder adskillige tilstande og teknologier At udføre en live-migrering og optimere båndbreddeforbrug, migreringstid og integration med eksisterende lagerplads. Valget af den ene eller den anden afhænger af dit infrastrukturdesign.

Standard live-migrering Dette er den grundlæggende tilstand, hvor kildeværten gradvist kopierer VM'ens hukommelse til destinationsværten, mens maskinen forbliver kørende. Adskillige gennemløb gentages, indtil hukommelsesforskellene mellem de to sider er tilstrækkeligt reduceret. I det sidste trin holder VM'en kort pause, CPU-tilstanden og de sidste resterende hukommelsessider overføres, og VM'en genoptager driften på den nye vært.

Live-migrering med komprimering Det tilføjer et optimeringslag: data i hukommelsen komprimeres, før de sendes over netværket, hvilket reducerer mængden af ​​overført information. Dette er især nyttigt i netværk med begrænset båndbredde eller når der er mange samtidige migreringer.

Livemigrering via SMB Den udnytter SMB-protokollen (typisk SMB 3.x) til at transportere VM-data og deres tilstand. Dette er især nyttigt, når det underliggende lager allerede er monteret via SMB, for eksempel med VHDX-filer placeret på en SMB-kompatibel filserver eller et lagersystem. I dette tilfælde kombineres det rigtig godt med funktioner som SMB Multichannel og SMB Direct for at optimere netværksbåndbredden.

I nyere versioner af Windows ServerDerudover kan du justere avancerede indstillinger, såsom det maksimale antal samtidige migreringer, der er tilladt på en vært, eller konfigurere båndbreddegrænsen dedikeret til Live Migration, så andre kritiske tjenester, der deler netværket, ikke begrænses.

Forberedelse af Hyper-V-værter til at bruge Live Migration

Før du begynder at flytte virtuelle maskiner på fartenDet er tilrådeligt at forberede Hyper-V-serverne korrekt. Proceduren varierer en smule afhængigt af, om du arbejder med en failover-klynge eller separate værter, men de grundlæggende idéer er de samme.

I systemer før Windows Server 2016Typisk oprettes en failover-klynge (WSFC), der grupperer flere Hyper-V-værter. Disse noder deler lagerplads og administreres som en enkelt logisk enhed, hvilket gør det muligt at flytte VM-roller fra én node til en anden med høj tilgængelighed.

På Windows Server 2016 og nyereMicrosoft forenklede processen betydeligt ved at aktivere live-migreringer mellem værter, der ikke nødvendigvis er en del af en klynge. Alligevel er det vigtigt at konfigurere netværkslaget, godkendelse (CredSSP eller Kerberos), de IP-adresser, der bruges til live-migrering, og eventuelt delt lagring korrekt, hvis du vil reducere kompleksiteten.

Fra Hyper-V ManagerPå hver vært skal du gå til "Hyper-V-konfiguration", navigere til afsnittet "Live-migreringer" og aktivere indgående og udgående migreringer. I samme afsnit konfigurerer du de IP-adresser, der skal bruges til Live-migrering, og godkendelsesmetoden (CredSSP eller Kerberos). CredSSP er enklere at konfigurere, selvom det kræver login med den samme bruger på begge værter, når en VM flyttes.

Hvis du vælger KerberosImplementeringen er noget mere kompleks, fordi den involverer konfiguration af begrænset delegering i Active Directory, korrekt registrering af SPN'er (Service Principal Names) for migreringstjenesten og generelt kontrol af, hvordan legitimationsoplysninger delegeres mellem computere. Til gengæld er det mere praktisk til automatisering og kræver ikke samtidige interaktive sessioner.

Grundlæggende trin til at udføre en live-migrering i Hyper-V

Når værterne er klarProcessen med at flytte en live VM fra Hyper-V Manager er ret guidet og ikke for kompliceret, forudsat at kompatibilitets- og netværkskravene er opfyldt.

1. Åbn konsollen og opret forbindelse til serverneI Hyper-V Manager opretter du forbindelse til både kilde- og destinationsserverne (ved hjælp af "Opret forbindelse til server"). Dette giver dig mulighed for at se alle VM'er fra ét punkt.

2. Start bevægelsesassistentenHøjreklik på den VM, du vil flytte, på kildeværten, og vælg "Flyt". Migreringsguiden åbnes, hvor du bliver bedt om at angive den type flytning, du vil udføre.

3. Vælg typen af ​​forskydningI tilfælde af en typisk live-migrering vælger du "Flyt den virtuelle maskine" (ikke kun lageret eller andre variationer). Derefter angiver du navnet på den destinationsvært, som den virtuelle maskine skal sendes til.

4. Beslut, hvad der skal ske med filerneGuiden tilbyder flere muligheder, herunder at flytte alle VM-data til en enkelt placering på destinationen eller distribuere filer på en mere tilpasset måde. Hvis hele VM'en skal være på et enkelt volumen eller en sti på den nye vært, er det normalt mere bekvemt at vælge indstillingen "flyt alle data til en enkelt placering".

5. Bekræft og udfør migreringenNår du har gennemgået destinationsstien og de valgte muligheder, skal du klikke på "Udfør", og flytningen begynder. Den tid, det tager, afhænger primært af størrelsen på den virtuelle maskine (hukommelse og diske involveret), netværkshastigheden og den aktuelle belastning på maskinen.

Godkendelse, delegering og SPN i Live Migration

Et af de punkter, der normalt forårsager mest hovedpine I Hyper-V-miljøer refererer dette til alt, der er relateret til godkendelse mellem værter for at muliggøre live-migrering. Typiske fejl omfatter koder som 0x80070005 (adgang nægtet) eller 0x8009030E/0x8009030D, der er relateret til forkert konfigurerede Kerberos-, delegerings- eller SPN'er.

Hvis du bruger Kerberos som din godkendelsesprotokol For Live Migration skal du eksplicit aktivere det i værtens avancerede Live Migration-indstillinger. Gå derefter til serverens computerobjektegenskaber i Active Directory, og vælg under fanen "Delegering" den indstilling, der tillader den pågældende computer kun at delegere til bestemte tjenester.

I den begrænsede delegationDet er almindeligt at tilføje mindst "cifs"-tjenesten (for adgang til delte ressourcer) og "Microsoft Virtual System Migration Service" for at muliggøre overførsel af VM-tilstand mellem værter. Derudover skal du sikre dig, at de korrekte servicepunktnavne (SPN'er) findes for denne tjeneste ved at registrere dem hos [den relevante tjenesteudbyder]. kommandoer såsom setspn om nødvendigt.

Når SPN'erne er ufuldstændige, eller delegationerne er forkerteMigreringen mislykkes ofte med godkendelsesfejl, og i nogle tilfælde er det nyttigt at slette gamle Kerberos-sager med værktøjer som KLIST for at gennemtvinge generering af nye sager baseret på den opdaterede konfiguration.

Hvis du foretrækker CredSSPImplementeringen er mere ligetil, men ulempen er, at du skal åbne den samme brugersession med tilstrækkelige rettigheder på begge værter, hver gang du vil køre en migrering. I små miljøer eller laboratoriemiljøer er dette ret praktisk; i produktion er Kerberos og begrænset delegering normalt den foretrukne mulighed for automatisering.

Netværk, virtuelle switche og lagring i Live Migration

Ud over godkendelse, netværksforbindelse Dette er en anden væsentlig kilde til problemer i Hyper-V Live Migration. Hvis værter ikke er korrekt opløst efter navn eller IP-adresse, eller hvis WinRM-, SMB- eller klyngetrafik blokeres af en firewall, vil migreringen mislykkes, før den overhovedet begynder at overføre hukommelse.

Typiske fejl omfatter meddelelser såsom "Klienten kan ikke oprette forbindelse til den destination, der er angivet i anmodningen" eller WinRM-protokolfejl, ofte ledsaget af hændelser med ID 20406 eller 280. For at diagnosticere disse tilfælde anbefales det først at teste grundlæggende forbindelse (ping, DNS-opløsning), gennemgå firewallregler og verificere, at WinRM er korrekt aktiveret med kommandoer som f.eks. winrm quickconfig.

Et andet vigtigt aspekt er matchningen af ​​virtuelle switche mellem værter. Hvis de virtuelle maskiner bruger en virtuel switch, der ikke findes med samme navn på destinationen, kan migreringen kræve, at du omfordeler netværkskortet på destinationsværten. Dette er ikke nødvendigvis et problem, men det er en god idé at planlægge det, så VM-trafik ikke utilsigtet ændrer VLAN'er eller netværk.

Angående opbevaringTypisk bruger VM'er VHDX-diske på delt lager, der er tilgængeligt via klyngenoder, eller de flyttes sammen med VM'en, hvis delt lager ikke er tilgængeligt. Delte virtuelle diske (f.eks. de delte VHDX-diske, der bruges af visse klyngekonfigurationer) har begrænsninger: de kan ikke flyttes ved hjælp af standardmigreringsmetoder, og i mange tilfælde skal du manuelt flytte og gentilslutte dem på destinationen.

Kontrolpunkter og øjebliksbilleder skal også overvåges.Meget lange eller beskadigede checkpoint-kæder eller beskadigede gemte tilstandsfiler (.bin og .vsv) kan forhindre gendannelse eller flytning af en VM. I disse tilfælde er det normalt nødvendigt at slette den gemte tilstand fra Hyper-V Manager eller manuelt slette bestemte filer samt flette eller rydde op i problematiske checkpoints.

Almindelige problemer i Live Migration og hvordan man løser dem

Selvom Live Migrations teori er ret klarI praksis er det ikke ualmindeligt at støde på fejl, når man flytter VM'er mellem noder, især i miljøer, hvor der har været adskillige systemopdateringer, hardwareændringer eller inkonsistente netværkskonfigurationer.

Et af de hyppigste tilfælde Dette skyldes en CPU- eller firmware-inkompatibilitet mellem værter. Migrering kan fungere i én retning (f.eks. fra en ældre server til en nyere), men ikke i den anden, og hændelsesvisninger vil vise ID'er som 10698 eller 21502 med meddelelser om problemer med konfigurationskompatibilitet.

Den typiske løsning involverer opdatering af VM-konfigurationsversionen. på den nye vært (fra Hyper-V Manager → Handling → Opdater version af virtuel maskinekonfiguration) og tjek med PowerShell (Get-VM | vælg Navn, Version) sikrer, at alle VM'er har versioner, der er i overensstemmelse med Hyper-V-niveauet på den nye server. Efter opgraderingen vil disse VM'er ikke længere kunne vende tilbage til værter med ældre Hyper-V-versioner.

Netværksproblemer eller WinRM De løses normalt ved at sikre, at begge værter kan kommunikere via navn og IP, kontrollere WinRM (winrm quickconfig), justere TrustedHosts-listen, hvis det er relevant (Set-Item WSMan:\localhost\Client\TrustedHosts) og sikre, at de porte, der kræves til SMB, Live Migration og clustering (f.eks. UDP 3343), ikke er blokeret.

I scenarier med vTPM eller afskærmede virtuelle maskinerMigreringsfejl nævner ofte manglende evne til at "dekapsulere den virtuelle maskines nøglebeskytter". I disse tilfælde er det et certifikat- og tillidsproblem mellem værter: Du skal eksportere nøglebeskyttercertifikaterne fra kildeværten og importere dem til destinationsværten, enten ved hjælp af Windows Certificate-snap-in'en (certmgr.msc) eller PowerShell-cmdlets som Export-PfxCertificate og Import-PfxCertificate.

Tjekliste til diagnosticering af Live Migration-fejl

Når en live-migrering mislykkesDen mest praktiske fremgangsmåde er at følge en organiseret tjekliste, der hjælper dig med at udelukke potentielle årsager uden at gå i blinde. Mange problemer løses med en systematisk gennemgang af status, konfiguration og tilladelser.

1. Status for værter og virtuelle maskinerBekræft, at VM-integrationstjenesterne er opdaterede, at værterne er fuldt opdaterede og har kompatible versioner, og at VM'en ikke er i særlige tilstande, såsom "Sikkerhedskopiering" eller "Stoppet", der forhindrer dens flytning.

2. Klyngekonfiguration og nodekompatibilitetKontroller, at alle klyngenoder er online og sunde i Failover Cluster Manager, at CPU'er, BIOS/firmware og VM-konfigurationsversioner er kompatible, og at alle noder har en så homogen konfiguration som muligt.

3. Netværk og lagringKontroller, at lager-, administrations- og migreringsnetværkene er korrekt konfigureret og tilgængelige, at VM-lageret er synligt fra destinationsværten, og at firewallregler ikke blokerer klyngedannelse, SMB- eller WinRM-trafik.

4. Godkendelse og tilladelserbekræfter, at Kerberos eller CredSSP er aktiveret og konfigureret, at de nødvendige SPN'er er registreret, at den begrænsede delegering i AD er passende, og at tjenesten eller brugerkontiene har det nødvendige tilladelsesniveau til at starte migreringer.

5. Virtuelle switche og VM-netværkSørg for, at de nødvendige virtuelle switche findes og er konfigureret identisk på tværs af værter (navn, VLAN'er, type), og at netværksteamingen (SET, LBFO) er ensartet for at undgå at miste VM-forbindelsen efter migrering.

6. Specifikke karakteristika for den virtuelle maskineHvis du arbejder med pansrede maskiner, vTPM, omfattende checkpoint-kæder eller delte diske, skal du gennemgå kompatibilitetsdokumentationen og om nødvendigt konsolidere checkpoints, fjerne problematiske gemte tilstande og gennemgå certifikatkrav.

Data- og journalindsamling til support

Når problemet ikke løses med de sædvanlige kontrollerDet er tid til at indsamle mere detaljerede data til din egen analyse eller at eskalere dem til Microsoft support eller den relevante leverandør. Hyper-V og Windows Server afslører en hel del nyttige logfiler.

Først, hændelsesloggene Hyper-V og klyngespecifikke logfiler giver en masse information. Du kan bruge PowerShell til at udtrække dem, for eksempel med Get-WinEvent på logfilerne "Microsoft-Windows-Hyper-V-VMMS/Admin" eller "Microsoft-Windows-Hyper-V-Worker-Admin", og Get-ClusterLog til at hente logs af klyngen med lokalt tidsstempel.

Derudover er det tilrådeligt at indsamle netværks- og systemdata såsom outputtet fra Get-NetAdapter, ipconfig /all, msinfo32Netværksruter, WinRM-konfiguration, SPN-liste (setspn -L) og vigtige Hyper-V-indstillinger (Get-VM, Get-VMSwitch, Get-VMProcessor osv.) hjælper alle med at se med et hurtigt blik, om der er uoverensstemmelser mellem værter.

I mere komplekse scenarierDet kan være nødvendigt at aktivere specifikke live-migreringsspor ved hjælp af Microsofts supportscripts (f.eks. TSS.ps1 med forskellige parametre), samt at kontrollere VHD-kæder med Get-VHDChain-type værktøjer for at registrere korruption eller fejl i diskstier.

Målet med hele denne samling Det handler om at kunne korrelere fejlhændelser, migreringstider, nylige patch- eller firmwareændringer og netværkstilstande, så den grundlæggende årsag hurtigt kan isoleres, og den endelige løsning kan anvendes (uanset om det er en konfigurationsrettelse eller en kodeopdatering).

Live Migration og dens forhold til backup og V2V-løsninger

Live-migrering i Hyper-V løser problemet med hot moving mellem værter i et Windows Server-miljø, men det dækker ikke alle de behov for arbejdsbelastningsmobilitet og databeskyttelse, der normalt findes i et datacenter eller i en virksomhed med flere hypervisorer.

Værktøjer til backup ligesom BackupChain De leverer live backups af virtuelle Hyper-V-maskiner, VMware, VirtualBox og andre hypervisorer, så du kan gemme VM'er uden at stoppe dem og gemme dem i både lokale lagre og i skyen. Disse typer løsninger fungerer på værtsniveau og tilbyder ubegrænsede VM-kopier under en enkelt licens, udover avancerede funktioner til sikkerhedskopiering af fysiske servere.

BackupChain inkluderer også funktioner såsom granulær backup og granulære gendannelser, designet til at fremskynde datagendannelse, når du kun har brug for bestemte filer på en VM og ikke en fuld gendannelse, hvilket supplerer Live Migrations daglige funktioner rigtig godt.

Andre løsninger, såsom Vinchin Backup & RecoveryDe går et skridt videre ved ikke kun at tillade sikkerhedskopier af Hyper-V VM'er, men også deres gendannelse på andre hypervisorer (ESXi, XenServer, Proxmox osv.) uden at skulle lukke serveren ned, hvilket letter V2V (virtuel til virtuel) migreringsprocesser mellem forskellige platforme.

I heterogene miljøer, hvor flere hypervisorer eksisterer side om sideDisse typer værktøjer fungerer som en bro til at flytte arbejdsbyrder mellem teknologier, som Hyper-V Live Migration alene ikke kan dække (for eksempel migrering af en VM fra Hyper-V til VMware vSphere), og kombinerer sikkerhedskopier, deduplikering, komprimering, GFS-tilbageholdelsespolitikker og detaljeret gendannelse for at dække både forretningskontinuitet og arbejdsbyrdemobilitet.

Hyper-V Live-migrering er kun et stykke inden for et større puslespil, der omfatter høj tilgængelighed, backup, gendannelse og i mange tilfælde mobilitet på tværs af platforme. Effektiv styring af hele dette økosystem er det, der gør det muligt for kritiske virtuelle maskiner at køre problemfrit, mens der foretages ændringer i det fysiske miljø.

• Hyper-V Live Migration Det giver mulighed for at flytte kørende VM'er mellem værter med minimal påvirkning, afhængigt af hurtige netværk, Kerberos- eller CredSSP-godkendelse og ofte delt lagring.
• En stabil implementering Det kræver homogenitet af CPU-, firmware- og VM-konfiguration, samt virtuelle switche og ensartede firewallregler på tværs af alle noder.
• Løsning af migreringsfejl Det involverer kontrol af kompatibilitet, netværk, godkendelse, diske, kontrolpunkter og certifikater, baseret på logfiler og diagnosticeringsværktøjer.
• Backup- og V2V-løsninger De supplerer Live Migration ved at dække live backups, detaljerede gendannelser og flytninger mellem forskellige hypervisorer.