Haveriberedskapsarkitektur för VMware till Azure – klassisk
Den här artikeln beskriver arkitekturen och processerna som används när du distribuerar replikering, redundans och återställning av virtuella VMware-datorer mellan en lokal VMware-plats och Azure med hjälp av Azure Site Recovery-tjänsten – klassisk.
Mer information om moderniserad arkitektur finns i den här artikeln
Arkitekturkomponenter
Följande tabell och grafik ger en översikt över de komponenter som används för haveriberedskap för virtuella VMware-datorer/fysiska datorer till Azure.
| Komponent | Krav | Detaljer |
|---|---|---|
| Azure | En Azure-prenumeration, Ett Azure Storage-konto för cacheminne, hanterad disk och Ett Azure-nätverk. | Replikerade data från lokala virtuella datorer lagras i Azure Storage. Virtuella Azure-datorer skapas med replikerade data när du kör en redundansväxling från en lokal plats till Azure. Virtuella Azure-datorer ansluter till det virtuella Azure-nätverket när de skapas. |
| Konfigurationsserverdator | En enda lokal dator. Vi rekommenderar att du kör den som en virtuell VMware-dator som kan distribueras från en nedladdad OVF-mall. Datorn kör alla lokala Site Recovery-komponenter, inklusive konfigurationsservern, processervern och huvudmålservern. |
Konfigurationsserver: Samordnar kommunikationen mellan lokalt och Azure och hanterar datareplikering. Processserver: Installeras som standard på konfigurationsservern. Den tar emot replikeringsdata. optimerar den med cachelagring, komprimering och kryptering. och skickar den till Azure Storage. Processervern installerar också mobilitetstjänsten Azure Site Recovery på de virtuella datorer du vill replikera, samt utför automatisk identifiering av lokala virtuella VMware-datorer. När distributionen växer kan du lägga till ytterligare, separata processerver för att hantera större volymer replikeringstrafik. Huvudmålserver: Installeras som standard på konfigurationsservern. Den hanterar replikeringsdata under återställning efter fel från Azure. För stora distributioner kan du lägga till ytterligare en separat huvudmålserver för återställning efter fel. |
| VMware-servrar | Virtuella VMware-datorer finns på lokala vSphere ESXi-servrar. Vi rekommenderar en vCenter-server för att hantera värdarna. | Under Site Recovery-distributionen lägger du till VMware-servrar i Recovery Services-valvet. |
| Replikerade datorer | Mobilitetstjänsten installeras på varje virtuell VMware-dator som du replikerar. | Vi rekommenderar att du tillåter automatisk installation från processervern. Du kan också installera tjänsten manuellt eller använda en automatiserad distributionsmetod, till exempel Configuration Manager. |
Konfigurera utgående nätverksanslutning
För att Site Recovery ska fungera som förväntat måste du ändra utgående nätverksanslutning så att din miljö kan replikeras.
Kommentar
Site Recovery för VMware/fysiska datorer med klassisk arkitektur stöder inte användning av en autentiseringsproxy för att styra nätverksanslutningen. Samma sak stöds när du använder den moderniserade architecutre.
Utgående anslutning för webbadresser
Om du använder en URL-baserad brandväggsproxy för att styra utgående anslutning kan du tillåta åtkomst till dessa URL:er:
| Namn | Kommersiell | Myndigheter | Beskrivning |
|---|---|---|---|
| Storage | *.blob.core.windows.net |
*.blob.core.usgovcloudapi.net |
Gör att data kan skrivas från den virtuella datorn till cachelagringskontot i källregionen. |
| Microsoft Entra ID | login.microsoftonline.com |
login.microsoftonline.us |
Tillhandahåller auktorisering och autentisering för Site Recovery-tjänstens webbadresser. |
| Replikering | *.hypervrecoverymanager.windowsazure.com |
*.hypervrecoverymanager.windowsazure.us |
Låter den virtuella datorn kommunicera med Site Recovery-tjänsten. |
| Service Bus | *.servicebus.windows.net |
*.servicebus.usgovcloudapi.net |
Låter den virtuella datorn skriva övervaknings- och diagnostikdata för Site Recovery. |
En fullständig lista över URL:er som ska filtreras för kommunikation mellan lokal Azure Site Recovery-infrastruktur och Azure-tjänster finns i avsnittet om nätverkskrav i artikeln om förhandskrav.
Replikeringsprocessen
När du aktiverar replikering för en virtuell dator påbörjas den inledande replikeringen till Azure Storage med den angivna replikeringsprincipen. Notera följande:
- För virtuella VMware-datorer är replikeringen blocknivå, nästan kontinuerlig, med hjälp av den tjänsten Mobility agent som körs på den virtuella datorn.
- Eventuella inställningar för replikeringsprinciper tillämpas:
- Tröskelvärde för RPO. Den här inställningen påverkar inte replikeringen. Det hjälper till med övervakning. En händelse utlöses och du kan också skicka ett e-postmeddelande om det aktuella RPO:t överskrider den tröskelvärdesgräns som du anger.
- Kvarhållning av återställningspunkt. Den här inställningen anger hur långt tillbaka i tiden du vill gå när ett avbrott inträffar. Maximal kvarhållning är 15 dagar på hanterad disk.
- Appkonsekventa ögonblicksbilder. Appkonsekvent ögonblicksbild kan tas var 1:e till 12:e timme, beroende på dina appbehov. Ögonblicksbilder är standardögonblicksbilder för Azure-blobar. Mobilitetsagenten som körs på en virtuell dator begär en VSS-ögonblicksbild i enlighet med den här inställningen och bokmärken som pekar i tid som en programkonsekvent punkt i replikeringsströmmen.
Kommentar
Kvarhållningsperioden för hög återställningspunkt kan påverka lagringskostnaden eftersom fler återställningspunkter kan behöva sparas.
Trafiken replikeras till offentliga Slutpunkter för Azure Storage via Internet. Alternativt kan du använda Azure ExpressRoute med Microsoft-peering. Det går inte att replikera trafik via ett virtuellt privat nätverk (VPN) från en lokal plats till Azure.
Den inledande replikeringsåtgärden säkerställer att hela data på datorn vid tidpunkten för aktivering av replikering skickas till Azure. När den inledande replikeringen är klar börjar replikeringen av deltaändringar till Azure. Spårade ändringar för en dator skickas till processervern.
Kommunikationen sker på följande sätt:
- Virtuella datorer kommunicerar med den lokala konfigurationsservern på port HTTPS 443 inkommande för replikeringshantering.
- Konfigurationsservern samordnar replikering med Azure via utgående port HTTPS 443.
- Virtuella datorer skickar replikeringsdata till processervern (körs på konfigurationsserverdatorn) på port HTTPS 9443 inkommande. Den här porten kan ändras.
- Processervern tar emot replikeringsdata, optimerar och krypterar dem och skickar dem till Azure Storage via utgående port 443.
Replikeringsdataloggarna hamnar först i ett cachelagringskonto i Azure. Dessa loggar bearbetas och data lagras på en Azure Managed Disk (kallas för Azure Site Recovery-startdisk). Återställningspunkterna skapas på den här disken.
Omsynkroniseringsprocess
- Ibland kan det under den inledande replikeringen eller vid överföring av deltaändringar uppstå problem med nätverksanslutningen mellan källdatorn för att bearbeta servern eller mellan processervern till Azure. Något av dessa kan leda till fel vid dataöverföring till Azure tillfälligt.
- För att undvika dataintegritetsproblem och minimera kostnaderna för dataöverföring markerar Site Recovery en dator för omsynkronisering.
- En dator kan också markeras för omsynkronisering i situationer som följande för att upprätthålla konsekvensen mellan källdatorn och data som lagras i Azure
- Om en maskin genomgår en force-avstängning
- Om en dator genomgår konfigurationsändringar som storleksändring av disk (ändra storleken på disken från 2 TB till 4 TB)
- Omsynkronisering skickar endast deltadata till Azure. Dataöverföring mellan lokal plats och Azure genom att minimeras genom databeräkning av datakontrollsummor mellan källdatorn och data som lagras i Azure.
- Som standard schemaläggs omsynkronisering att köras automatiskt utanför kontorstid. Om du inte vill vänta på standardsynkronisering utanför timmar kan du synkronisera om en virtuell dator manuellt. Det gör du genom att gå till Azure Portal och välja den virtuella datorns >omsynkronisering.
- Om standardsynkroniseringen misslyckas utanför kontorstid och en manuell åtgärd krävs genereras ett fel på den specifika datorn i Azure Portal. Du kan lösa felet och utlösa omsynkroniseringen manuellt.
- När omsynkroniseringen har slutförts återupptas replikeringen av deltaändringar.
Hantera replikeringsprinciper
- Du kan anpassa inställningarna för replikeringsprinciper när du aktiverar replikering.
- Du kan skapa en replikeringsprincip när som helst och sedan tillämpa den när du aktiverar replikering.
Konsekvens för flera virtuella datorer
Om du vill att virtuella datorer ska replikeras tillsammans och har delade kraschkonsekventa och appkonsekventa återställningspunkter vid redundansväxling kan du samla dem i en replikeringsgrupp. Konsekvens för flera virtuella datorer påverkar arbetsbelastningens prestanda och bör endast användas för virtuella datorer som kör arbetsbelastningar som behöver konsekvens på alla datorer.
Ögonblicksbilder och återställningspunkter
Återställningspunkter skapas från ögonblicksbilder av virtuella datordiskar som tas vid en viss tidpunkt. När du redundansväxlar en virtuell dator använder du en återställningspunkt för att återställa den virtuella datorn på målplatsen.
När vi reder över vill vi vanligtvis se till att den virtuella datorn börjar utan skada eller dataförlust, och att vm-data är konsekventa för operativsystemet och för appar som körs på den virtuella datorn. Detta beror på vilken typ av ögonblicksbilder som tas.
Site Recovery tar ögonblicksbilder på följande sätt:
- Site Recovery tar kraschkonsekventa ögonblicksbilder av data som standard och appkonsekventa ögonblicksbilder om du anger en frekvens för dem.
- Återställningspunkter skapas från ögonblicksbilderna och lagras i enlighet med kvarhållningsinställningarna i replikeringsprincipen.
Konsekvens
I följande tabell beskrivs olika typer av konsekvens.
Kraschkonsekvent
| Beskrivning | Detaljer | Rekommendation |
|---|---|---|
| En krasch konsekvent ögonblicksbild samlar in data som fanns på disken när ögonblicksbilden togs. Den innehåller inte något i minnet. Den innehåller motsvarigheten till de data på disken som skulle finnas om den virtuella datorn kraschade eller strömkabeln hämtades från servern när ögonblicksbilden togs. En kraschkonsekvent garanterar inte datakonsekvens för operativsystemet eller för appar på den virtuella datorn. |
Site Recovery skapar kraschkonsekventa återställningspunkter var femte minut som standard. Den här inställningen går inte att ändra. |
I dag kan de flesta appar återställas bra från kraschkonsekventa punkter. Kraschkonsekventa återställningspunkter räcker vanligtvis för replikering av operativsystem och appar som DHCP-servrar och utskriftsservrar. |
Appkonsekvent
| Beskrivning | Detaljer | Rekommendation |
|---|---|---|
| Appkonsekventa återställningspunkter skapas från appkonsekventa ögonblicksbilder. En appkonsekvent ögonblicksbild innehåller all information i en kraschkonsekvent ögonblicksbild, plus alla data i minnet och pågående transaktioner. |
Appkonsekventa ögonblicksbilder använder Volume Shadow Copy Service (VSS): 1) Azure Site Recovery använder metoden Kopiera endast säkerhetskopiering (VSS_BT_COPY) som inte ändrar Microsoft SQL:s säkerhetskopieringstid för transaktionslogg och sekvensnummer 2) När en ögonblicksbild initieras utför VSS en kopieringsåtgärd (COW) på volymen. 3) Innan den utför COW informerar VSS varje app på datorn om att den behöver tömma sina minnesbaserade data till disken. 4) VSS tillåter sedan säkerhetskopierings-/haveriberedskapsappen (i det här fallet Site Recovery) att läsa ögonblicksbilddata och fortsätta. |
Appkonsekventa ögonblicksbilder tas i enlighet med den frekvens du anger. Den här frekvensen bör alltid vara mindre än du har angett för att behålla återställningspunkter. Om du till exempel behåller återställningspunkter med standardinställningen 24 timmar bör du ange frekvensen på mindre än 24 timmar. De är mer komplexa och tar längre tid att slutföra än kraschkonsekventa ögonblicksbilder. De påverkar prestanda för appar som körs på en virtuell dator som är aktiverade för replikering. |
Processen för redundans och återställning efter fel
När replikeringen har konfigurerats och du kör ett haveriberedskapstest (redundanstest) för att kontrollera att allt fungerar som förväntat kan du köra redundans och återställning efter fel som du behöver.
Du kör ett fel för en enskild dator eller skapar en återställningsplan för att redundansväxla flera virtuella datorer samtidigt. Fördelen med en återställningsplan i stället för redundans för en enskild dator är:
- Du kan modellera appberoenden genom att inkludera alla virtuella datorer i appen i en enda återställningsplan.
- Du kan lägga till skript, Azure-runbooks och pausa för manuella åtgärder.
När du har utlöst den första redundansväxlingen checkar du in den för att börja komma åt arbetsbelastningen från den virtuella Azure-datorn.
När din primära lokala plats är tillgänglig igen kan du förbereda för återställning efter fel. För att kunna återställa vid fel måste du konfigurera en infrastruktur för återställning efter fel, inklusive:
- Tillfällig processserver i Azure: Om du vill återställa från Azure konfigurerar du en virtuell Azure-dator för att fungera som en processserver för att hantera replikering från Azure. Du kan ta bort den här virtuella datorn när återställningen är klar.
- VPN-anslutning: Om du vill återställa behöver du en VPN-anslutning (eller ExpressRoute) från Azure-nätverket till den lokala platsen.
- Separat huvudmålserver: Som standard hanterar huvudmålservern som installerades med konfigurationsservern på den lokala virtuella VMware-datorn återställning efter fel. Om du behöver återställa stora trafikvolymer konfigurerar du en separat lokal huvudmålserver för detta ändamål.
- Återställningsprincip: Om du vill replikera tillbaka till din lokala plats behöver du en återställningsprincip. Den här principen skapas automatiskt när du skapar en replikeringsprincip från en lokal plats till Azure.
När komponenterna är på plats sker återställning efter fel i tre åtgärder:
- Steg 1: Skydda de virtuella Azure-datorerna igen så att de replikeras från Azure tillbaka till de lokala virtuella VMware-datorerna.
- Steg 2: Kör en redundansväxling till den lokala platsen.
- Steg 3: När arbetsbelastningarna har misslyckats igen kan du återaktivera replikering för de lokala virtuella datorerna.
Nästa steg
Följ den här självstudien om du vill aktivera VMware till Azure-replikering.