Gå från klassisk till moderniserad haveriberedskap för VMware
Den här artikeln innehåller information om arkitektur, nödvändig infrastruktur och vanliga frågor och svar om hur du flyttar dina VMware- eller Fysiska datorreplikeringar från klassisk till moderniserad skyddsarkitektur. Med den här funktionen för migrering kan du överföra dina replikerade objekt från en konfigurationsserver till en Azure Site Recovery-replikeringsinstallation. Den här migreringen styrs av en mekanism för smart replikering, som säkerställer att fullständig inledande replikering inte utförs igen för icke-kritiska replikerade objekt, och endast differentiella data överförs.
Kommentar
Återställningsplaner migreras inte och måste skapas igen i det moderniserade Recovery Services-valvet.
Arkitektur
De komponenter som ingår i migreringen av replikerade objekt i en VMware- eller fysisk dator sammanfattas i följande tabell:
| Komponent | Krav |
|---|---|
| Replikerade objekt i ett klassiskt Recovery Services-valv | Ett eller flera replikerade objekt som skyddas med den klassiska arkitekturen och en felfri konfigurationsserver. Det replikerade objektet ska vara i ett icke-kritiskt tillstånd och måste replikeras från lokalt till Azure med mobilitetsagenten som körs på version 9.50 eller senare. |
| Konfigurationsserver som används av de replikerade objekten | Konfigurationsservern, som används av de replikerade objekten, bör vara i ett icke-kritiskt tillstånd och dess komponenter bör uppgraderas till den senaste versionen (9.50 eller senare). |
| Ett Recovery Services-valv med moderniserad erfarenhet | Ett Recovery Services-valv med moderniserad erfarenhet. |
| En felfri Azure Site Recovery-replikeringsinstallation | En icke-kritisk Azure Site Recovery-replikeringsinstallation, som kan identifiera lokala datorer, med alla dess komponenter uppgraderade till den senaste versionen (9.50 eller senare). De exakta nödvändiga versionerna är följande: Processserver: 9.50 Proxyserver: 1.35.8419.34591 Recovery Services-agent: 2.0.9249.0 Replikeringstjänst: 1.35.8433.24227 |
Nödvändig infrastruktur
Kontrollera följande för en lyckad förflyttning av replikerat objekt:
- Ett Recovery Services-valv med hjälp av den moderniserade upplevelsen.
- En Azure Site Recovery-replikeringsinstallation, som har registrerats till valvet, och alla dess komponenter är i ett icke-kritiskt tillstånd.
- Versionen av apparaten måste vara 9.50 eller senare. En detaljerad versionsbeskrivning finns här.
- VCenter-serverns eller vSphere-värdens information, där de befintliga replikerade datorerna finns, läggs till i installationen för att den lokala identifieringen ska lyckas.
Förhandskrav
Förbereda infrastrukturen
Kontrollera följande innan du går från klassisk arkitektur till moderniserad arkitektur:
- Skapa ett Recovery Services-valv och se till att upplevelsen inte har bytts till klassisk
- Distribuera en Azure Site Recovery-replikeringsinstallation.
- Lägg till den lokala datorns vCenter Server-information i installationen så att den kan utföra identifieringen.
Förbereda klassiska Recovery Services-valv
Kontrollera följande för de replikerade objekt som du planerar att flytta:
- Det replikerade objektet är en VMware- eller fysisk dator som replikeras via en konfigurationsserver.
- Replikering sker inte till ett ohanterat lagringskonto utan snarare till en hanterad disk.
- Replikering sker från lokal plats till Azure och det replikerade objektet är inte i redväxlade tillstånd eller i felläge.
- Det replikerade objektet replikerar inte data från Azure till lokalt.
- Den inledande replikeringen pågår inte och har redan slutförts.
- Det replikerade objektet är inte i tillståndet "omsynkronisering".
- Konfigurationsserverns version är 9.50 eller senare och dess hälsotillstånd är i ett icke-kritiskt tillstånd.
- Konfigurationsservern har ett friskt pulsslag.
- Mobilitetstjänstagentens version, installerad på källdatorn, är 9.50 eller senare.
- Recovery Services-valv med MSI aktiverat stöds.
- Recovery Services-valv med privata slutpunkter aktiverade stöds.
- Det replikerade objektets hälsotillstånd är i ett icke-kritiskt tillstånd, eller så skapas dess återställningspunkter.
Förbereda moderniserat Recovery Services-valv
För den moderniserade arkitekturkonfigurationen kontrollerar du att:
- Recovery Services-valvet som används för att modernisera arkitekturkonfigurationen finns på samma geografiska plats som det klassiska valvet.
- En Azure Site Recovery-replikeringsinstallation distribueras lokalt med version 9.50 eller senare.
- Installationen har registrerats i valvet.
- Installationen och alla dess komponenter är i ett icke-kritiskt tillstånd och enheten har ett friskt pulsslag.
- VCenter Server-versionen stöds av den moderniserade arkitekturen.
- VCenter Server-informationen för källdatorn läggs till i installationen.
- Linux-distributionsversionen stöds av den moderniserade arkitekturen. Läs mer.
- Windows Server-versionen stöds av den moderniserade arkitekturen. Läs mer.
Beräkna total tid att flytta
Den totala tid som krävs för att flytta ett replikerat objekt från klassiskt valv till moderniserat valv beror på objektets replikeringsstatus och diskstorlek.
| Tillstånd | Dags att migrera till moderniserat valv |
|---|---|
| Det replikerade objektets skyddsstatus är felfri och den senaste återställningspunkten skapades för mindre än 50 minuter sedan | Migreringen är klar om 1–2 timmar |
| Det replikerade objektets skyddsstatus är inte felfri eller så skapades den senaste återställningspunkten för mer än 50 minuter sedan | Migreringstiden varierar och beror på diskstorleken |
Om datorns skyddsstatus inte är felfri använder du formeln nedan för att beräkna den exakta tiden för dina datorer:
Tid att migrera = 1 timme + 45 sekund/GiB
| Datorkonfiguration | Tid att migrera |
|---|---|
| En dator med två diskar, båda av storlek 256 GiB | ~ 4 timmar 15 minuter [Båda diskarna migreras parallellt] |
| 10 datorer med två diskar vardera, båda av storlek 256 GiB | ~ 4 timmar 15 minuter [Alla virtuella datorer och deras diskar migreras parallellt] |
| En dator med fyra diskar, alla i storlek 512 GiB | ~ 7 timmar 30 minuter [Båda diskarna migreras parallellt] |
| 10 datorer med fyra diskar vardera, alla av storlek 512 GiB | ~ 7 timmar 30 minuter [Alla virtuella datorer och deras diskar migreras parallellt] |
Samma formel används för att beräkna tid för migrering och visas på portalen.
Definiera nödvändig infrastruktur
När du migrerar datorer från klassisk till moderniserad arkitektur måste du se till att nödvändig infrastruktur redan har registrerats i det moderniserade Recovery Services-valvet. Se storleks- och kapacitetsinformation för replikeringsinstallationen för att definiera den infrastruktur som krävs.
Som regel bör du konfigurera samma antal replikeringsenheter som antalet processservrar i det klassiska Recovery Services-valvet. Om det fanns en konfigurationsserver och fyra processerver i det klassiska valvet bör du konfigurera fyra replikeringsenheter i det moderniserade Recovery Services-valvet.
Prissättning
Licensavgiften för Site Recovery fortsätter att debiteras för det klassiska valvet tills kvarhållningsperioden för alla återställningspunkter har upphört att gälla. När alla återställningspunkter har rensats stoppas även prissättningen på det klassiska valvet. När kvarhållningsperioden för alla återställningspunkter har upphört att gälla tas det replikerade objektet bort automatiskt via en systemutlöst rensningsreplikeringsåtgärd.
Site Recovery börjar ta ut licensavgifter för replikerade objekt i det moderniserade valvet först efter att den första återställningspunkten har genererats och äldre valv har rensats. Om det finns några kostnadsfria användningsdagar för utvärderingsversionen som väntar på det klassiska valvet skickas samma information vidare till det moderniserade valvet. Prissättningen börjar på det moderniserade valvet först efter att utvärderingsperioden har passerat.
Kommentar
Vid ett tillfälle sker prissättningen endast med hjälp av ett valv, antingen det klassiska eller moderniserade valvet.
Vanliga frågor och svar
Varför ska jag migrera mina datorer till den moderniserade arkitekturen?
Det är viktigt att observera att den klassiska arkitekturen för haveriberedskap fasas ut, så användarna bör se till att växla till den senaste och moderniserade versionen. Följande tabell innehåller en jämförelse av de två arkitekturerna som hjälper dig att välja rätt alternativ för att skydda dina datorer i händelse av en katastrof.
| Klassisk arkitektur | Moderniserad arkitektur [Ny] |
|---|---|
| Flera installationer krävs för att identifiera lokala data. | Central identifiering av lokalt datacenter med identifieringstjänsten. |
| Omfattande antal steg som krävs för inledande registrering. | Förenklade onboarding-upplevelsen genom att automatisera skapande av artefakter och introducerade standardvärden för att minska nödvändiga indata. |
| Använder en manuellt nedladdad fil för att hämta molnkontexten. | Introducerade replikeringsnyckel för att hämta molnkontext när installationen konfigureras. |
| Omfattande antal steg som krävs för en enkel aktivering av replikeringsprocessen. | Förenklade funktionen för att aktivera replikering genom att minska antalet nödvändiga indata och omdefiniera varje blad. |
| Konfigurationsservern fortsätter att vara en lokal infrastruktur med omfattande installation för olika komponenter. | Förbättrade installationen genom att konvertera alla komponenter till Azure-värdbaserade mikrotjänster. Detta förenklar skalning, övervakning och felsökning av installationer. |
| Behovet av utskalningsprocessserver och huvudmålserver i Azure för Linux-datorer är ett hindrar krav. | Tog bort behovet av att underhålla en separat processserver och huvudmålserver. |
| Använde en statisk lösenfras för autentisering, vilket störde kundens affärskrav för periodisk lösenordsrotation. | Introducerade certifikatbaserad autentisering, vilket är säkrare och löser kundens säkerhetsproblem. |
| Uppgradering till en uppdaterad version bör göras manuellt och är en besvärlig process. | Introducerade automatiska uppgraderingar för både installationskomponenter och tjänsten Mobility. |
| Konfigurationsservern har inte hög tillgänglighet och riskerar att kollapsa. | Implementerad hög tillgänglighet för installationen för att säkerställa återhämtning. |
| Rotautentiseringsuppgifter bör uppdateras regelbundet för att säkerställa en felfri uppgraderingsupplevelse. | Eliminerade kravet på att underhålla datorns rotautentiseringsuppgifter för att utföra automatiska uppgraderingar. |
| Statisk IP-adress ska tilldelas till konfigurationsservern för att upprätthålla anslutningen. | Introducerade FQDN-baserad anslutning mellan installation och lokala datorer. |
| Endast det virtuella nätverket, som har plats-till-plats-VPN eller Express Route aktiverat, ska användas. | Tog bort behovet av att underhålla en plats-till-plats-VPN eller Express Route för omvänd replikering. |
| Verktyget MySQL från tredje part måste också konfigureras. | Tog bort beroendet av verktyg från tredje part. |
Vilka datorer ska migreras till den moderniserade arkitekturen?
Alla VMware- eller fysiska datorer som replikeras med hjälp av en konfigurationsserver ska migreras till den moderniserade arkitekturen.
Var ska mitt moderniserade Recovery Services-valv skapas?
Det moderniserade Recovery Services-valvet ska finnas i samma region och klientorganisation som det klassiska valvet. Det kan ingå i valfri prenumeration eller resursgrupp.
Kommer min replikering att fortsätta medan migreringen sker?
Nej, replikeringen bryts under en tid medan migreringen pågår. Under den här tiden kommer den senast skapade återställningspunkten i det klassiska Recovery Services-valvet att vara tillgänglig för redundansväxling till. När migreringen är klar genereras en ny återställningspunkt i det moderniserade Recovery Services-valvet.
När markeras min migreringsåtgärd som slutförd?
Migreringsåtgärden markeras bara som slutförd när den första återställningspunkten har skapats i det moderniserade Recovery Services-valvet.
Vilka åtgärder kan utföras från mitt klassiska Recovery Services-valv när migreringen är klar?
Du kan utföra redundansväxling från det klassiska valvet efter migreringen. Redundansåtgärden fortsätter att vara tillgänglig i det klassiska valvet tills återställningspunkterna upphör att gälla.
Om kvarhållningsperioden för ett replikerat objekt till exempel är 72 timmar (tre dagar) fortsätter den senaste återställningspunkten i det klassiska valvet att vara tillgänglig i 72 timmar (tre dagar) efter en lyckad migrering. Efter den angivna tiden utlöser Azure Site Recovery automatiskt en rensningsreplikeringsåtgärd på det replikerade objektet och utför rensningen av alla associerade lagrings- och faktureringsorsakande objekt.
Vad händer om en katastrof drabbar min dator när migreringsåtgärden pågår?
Alla replikerade objekt som genomgår migrering kan fortfarande stödja redundansåtgärden via det klassiska Recovery Services-valvet tills kvarhållningsperioden för den slutliga återställningspunkten har avslutats. Om du försöker köra en redundansåtgärd har den företräde framför migreringsåtgärden och migreringsjobbet avbryts. För att säkerställa att det replikerade objektet migreras måste du utlösa migreringsåtgärden igen vid ett senare tillfälle.
Kommentar
Egenskaperna Beräkning och nätverk för replikerade objekt kan uppdateras medan migreringen pågår. Ändringarna kanske dock inte replikeras i det moderniserade Recovery Services-valvet.
Hur många datorer kan jag migrera på en går från klassiskt till moderniserat valv?
Du kan migrera upp till 10 datorer via portalen på ett och samma sätt.
Ska jag återskapa de virtuella nätverk, lagringskonton och replikeringsprinciper som ska användas i det nya valvet?
Nej, samma resurser som användes tidigare är standard i det moderniserade valvet också. Du kan alltid ändra dem från bladet Beräkning och nätverk för det replikerade objektet. Du måste se till att resurserna fortsätter att ha den åtkomst som krävs.
Hur kommer mina replikeringsprinciper att flyttas till det moderniserade valvet?
Som en förutsättning skapar Site Recovery replikeringsprinciper i det moderniserade valvet med samma konfiguration som i det klassiska valvet. Innan ett replikerat objekt flyttas skapas alltså den associerade principen i det moderniserade valvet. Vi rekommenderar att du undviker att göra ändringar i konfigurationen av replikeringsprinciper i det klassiska valvet efter att migreringen har utlösts, eftersom dessa ändringar inte återspeglas i det moderniserade valvet. Det är bäst att göra dessa ändringar innan du påbörjar migreringsprocessen.
Replikeringsprincipen som skapas i det moderniserade valvet får sitt namn ändrat i det moderniserade valvet. Det är prefixet med resursgruppens namn och valvnamnet för det moderniserade Recovery Services-valvet. Så om principnamnet var "standardreplikeringsprincip" i det klassiska valvet är default replication policy contoso-modern-vault_contoso-rgprincipens namn i det moderniserade valvet , med tanke på att valvets namn är contoso-modern-vault och valvets resursgrupp är contoso-rg.
Kan jag redigera min replikeringsprincip under migreringen eller efter migreringen i det klassiska valvet?
Om repliken av en replikeringsprincip redan har skapats i det moderniserade valvet sprids inga ändringar av principen i det klassiska valvet till det moderniserade valvet.
Så om det finns 10 replikerade objekt, som replikeras med en princip och du bestämmer dig för att flytta 5 av dem till den moderniserade upplevelsen, skapas en kopia av principen innan migreringen startar. Innan du utför migreringen av de återstående fem objekten uppdateras inte principen från det moderniserade valvet om några ändringar görs i principen i det klassiska valvet. Du måste också göra dessa konfigurationsändringar i det moderniserade valvet.
Hur gör jag för att migrera replikerade objekt, som finns i en replikeringsgrupp, även kallade konsekvensgrupper för flera virtuella datorer?
Alla replikerade objekt som ingår i en replikeringsgrupp migreras tillsammans. Du kan välja alla genom att välja replikeringsgruppen eller hoppa över alla. Om migreringsprocessen misslyckas för vissa datorer i en replikeringsgrupp men lyckas för andra utförs en återställning till den klassiska upplevelsen för de misslyckade replikerade objekten och migreringsprocessen kan utlösas igen för dessa objekt.
Kan jag migrera min klassiska installation med offentlig slutpunkt till moderniserad installation med privat slutpunkt?
Nej, du kan bara flytta den klassiska haveriberedskapskonfigurationen med en offentlig slutpunkt till en moderniserad offentlig slutpunktskonfiguration. Observera att icke-privat slutpunkt till privat slutpunktsmigrering inte stöds, men privat slutpunkt till privat slutpunktsmigrering stöds.
Nästa steg
- Lär dig hur du går från klassisk till moderniserad VMware-haveriberedskap.