Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Den här artikeln innehåller svar på vanliga frågor om övergång från klassisk till moderniserad återställning efter katastrof för VMware med användning av Azure Site Recovery.
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. | Centralt upptäckande av lokalt datacenter via upptäckstjä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 apparaten ställs in. |
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 tillämpningen genom att konvertera alla komponenter till mikrotjänster värdbaserade på Azure. Detta förenklar skalning, övervakning och felsökning av installationer. |
Behovet av en skalningsbar processserver och en huvudmålserver i Azure för Linux-datorer är ett begränsande 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 enheten för att säkerställa resiliens. |
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 enhet och datorer på plats. |
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 klient 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 är den senaste återställningspunkten som skapats i det klassiska Recovery Services-valvet tillgänglig för att växla över 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 endast 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.
Anmärkning
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 maskiner kan jag migrera på en gång 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 kommer att användas som standard i det moderniserade valvet också. Du kan alltid ändra dessa från Beräkningsbladet och Nätverksbladet för ditt replikerade objekt. 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 den associerade policyn 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.
Replikeringsprincipens namn som skapades i det moderniserade valvet har ändrats i det moderniserade valvet. Det har resursgruppens namn och valvnamnet för det moderniserade Recovery Services-valvet som prefix. Så, om principnamnet var default replication policy
i det klassiska valvet, är denna princips namn default replication policy contoso-modern-vault_contoso-rg
i det moderniserade valvet, där 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, kommer inte policyn från det moderniserade valvet att uppdateras om några ändringar görs i policyn i det klassiska valvet. Du måste också göra dessa konfigurationsändringar i det moderniserade valvet.
Hur migrerar jag replikerade objekt som finns i en replikeringsgrupp, även kallad konsekventgrupp för flera virtuella maskiner?
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-katastrofåterställning.
- Läs mer om klassisk till moderniserad arkitektur.