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.
Arkitekturinformation i förhandsversionen finns i den här artikeln
Arkitekturkomponenter
Följande tabell och bild ger en högnivåvy över de komponenter som används för haveriberedskap för virtuella VMware-datorer/fysiska datorer till Azure.
| Komponent | Krav | Information |
|---|---|---|
| Azure | En Azure-prenumeration, Azure Storage för cache, Managed Disk och 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 redundans 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 komponenter Site Recovery, inklusive konfigurationsserver, processerserver och huvudmålserver. |
Konfigurationsserver: Samordnar kommunikationen mellan den lokala platsen och Azure och hanterar datareplikering. Processerserver: 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 processer 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 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 processerservern. Du kan också installera tjänsten manuellt eller använda en automatiserad distributionsmetod, till exempel Konfigurationshanteraren. |
Konfigurera utgående nätverksanslutning
För Site Recovery fungerar som förväntat måste du ändra utgående nätverksanslutning så att din miljö kan replikeras.
Anteckning
Site Recovery har inte stöd för en autentiseringsproxy för att styra nätverksanslutningar.
Utgående anslutning för webbadresser
Om du använder en URL-baserad brandväggsproxy för att styra utgående anslutningar ska du tillåta åtkomst till följande WEBBADRESSer:
| Namn | Kommersiellt | 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. |
| Azure Active Directory | 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 lokala Azure Site Recovery och Azure-tjänster finns i avsnittet om nätverkskrav i kravartikeln.
Replikeringsprocessen
När du aktiverar replikering för en virtuell dator börjar den inledande replikeringen till Azure Storage med hjälp av den angivna replikeringsprincipen. . Tänk på följande:
- För virtuella VMware-datorer är replikeringen nästan kontinuerlig på blocknivå med hjälp tjänsten Mobility som körs på den virtuella datorn.
- Alla 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 eventuellt ett e-postmeddelande skickas om det aktuella RPO-värdet överskrider den grä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 på Premium Storage är 24 timmar. På standardlagring är det 72 timmar.
- App-konsekventa ögonblicksbilder. App-konsekvent ögonblicksbild kan tas var 1:e till 12:e timme, beroende på dina appbehov. Ögonblicksbilder är Azure Blob-standardögonblicksbilder. 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 används som program konsekventa platser i replikeringsströmmen.
Trafiken replikeras till offentliga slutpunkter för Azure Storage via Internet. Alternativt kan du använda Azure ExpressRoute med Microsoft-peering. Replikering av trafik via ett virtuellt privat nätverk för plats-till-plats (VPN) från en lokal plats till Azure stöds inte.
Inledande replikeringsåtgärd säkerställer att hela data på datorn vid tidpunkten för att aktivera 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 processerservern.
Kommunikationen sker på följande sätt:
- Virtuella datorer kommunicerar med den lokala konfigurationsservern på port HTTPS 443 inkommande för replikeringshantering.
- Konfigurationsservern dirigerar replikering med Azure via port HTTPS 443 utgående.
- Virtuella datorer skickar replikeringsdata till processervservern (körs på konfigurationsserverdatorn) på port HTTPS 9443 inkommande. Den här porten kan ändras.
- Processerservern tar emot replikeringsdata, optimerar och krypterar dem och skickar dem till Azure Storage via port 443 utgående.
Replikeringsdataloggarna hamnar först i ett cachelagringskonto i Azure. Dessa loggar bearbetas och data lagras på en Azure-hanterad disk (kallas för Azure Site Recovery start seed-disk). Återställningspunkterna skapas på den här disken.
Omsynkroniseringsprocess
- Ibland, under den inledande replikeringen eller vid överföring av deltaändringar, kan det finnas problem med nätverksanslutningen mellan källdatorn till processerserver eller mellan processerserver till Azure. Endera av dessa kan leda till fel vid dataöverföring till Azure tillfälligt.
- För att undvika problem med dataintegriteten och minimera kostnaderna för dataöverföring Site Recovery markerar en dator för omsynkronisering.
- En dator kan också markeras för omsynkronisering i situationer som följande för att upprätthålla konsekvens mellan källdatorn och data som lagras i Azure
- Om en dator genomgår force-avstängning
- Om en dator genomgår konfigurationsändringar som diskstorleksändring (ändra storleken på disken från 2 TB till 4 TB)
- Omsynkronisering skickar endast deltadata till Azure. Dataöverföring mellan lokalt och Azure genom att minimera genom att beräkna kontrollsummer av data mellan källdatorn och data som lagras i Azure.
- Omsynkronisering schemaläggs som standard att köras automatiskt utanför kontorstid. Om du inte vill vänta på standardsynkronisering utanför arbetstid kan du synkronisera om en virtuell dator manuellt. Det gör du genom att gå Azure Portal, välja den virtuella > synkronisera om.
- Om standardinsynkroniseringen 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 är klar återupptas replikeringen av deltaändringarna.
Replikeringsprincip
När du aktiverar replikering av virtuella Azure-datorer skapar Site Recovery som standard en ny replikeringsprincip med standardinställningarna sammanfattade i tabellen.
| Principinställning | Information | Standardvärde |
|---|---|---|
| Kvarhållning av återställningspunkt | Anger hur länge Site Recovery behåller återställningspunkter | 24 timmar |
| Frekvens för app-konsekvent ögonblicksbild | Hur ofta Site Recovery tar en app-konsekvent ögonblicksbild. | Var fjärde timme |
Hantera replikeringsprinciper
Du kan hantera och ändra standardinställningarna för replikeringsprinciper på följande sätt:
- Du kan ändra inställningarna 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 krasch-konsekventa och app-konsekventa återställningspunkter vid redundans, 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 VM-diskar som tas vid en viss tidpunkt. När du redundansåterställer en virtuell dator använder du en återställningspunkt för att återställa den virtuella datorn på målplatsen.
Vid en vidarefördrkning vill vi normalt se till att den virtuella datorn inte skadas eller data går förlorade 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 krasch konsekventa ögonblicksbilder av data som standard och app-konsekventa ö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.
Krasch-konsekvent
| Beskrivning | Information | 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 togs 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 som standard krasch konsekventa återställningspunkter var femte minut. Den här inställningen kan inte ändras. |
I dag kan de flesta appar återställas väl från kraschsekventa punkter. Krascha konsekventa återställningspunkter är vanligtvis tillräckliga för replikering av operativsystem och appar som DHCP-servrar och utskriftsservrar. |
App-konsekvent
| Beskrivning | Information | Rekommendation |
|---|---|---|
| App-konsekventa återställningspunkter skapas från app-konsekventa ögonblicksbilder. En app-konsekvent ögonblicksbild innehåller all information i en krasch konsekvent ögonblicksbild, plus alla data i minnet och pågående transaktioner. |
App-konsekventa ögonblicksbilder använder tjänsten Volume Shadow Copy (VSS): 1) Azure Site Recovery använder metoden för säkerhetskopiering med endast kopiering (VSS_BT_COPY) som inte ändrar Microsoft SQL:s säkerhetskopieringstid och sekvensnummer för transaktionsloggen 2) När en ögonblicksbild initieras utför VSS en COPY-on-write-åtgärd (COW) på volymen. 3) Innan DEN utför KON informerar VSS varje app på datorn om att den behöver tömma sina minnesbaserade data till disk. 4) VSS tillåter sedan att appen för säkerhetskopiering/haveriberedskap (i det här Site Recovery) läser ögonblicksbildsdata och fortsätter. |
App-konsekventa ögonblicksbilder tas i enlighet med den frekvens som du anger. Den här frekvensen bör alltid vara mindre än vad 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 ställa in frekvensen på mindre än 24 timmar. De är mer komplexa och tar längre tid att slutföra än kraschsekventa ö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 ställts in och du kör ett återställningstest (testa redundans) för att kontrollera att allt fungerar som förväntat kan du köra redundans och återställning efter fel efter behov.
Du kör redundans för en enskild dator eller skapar en återställningsplan för redundans för flera virtuella datorer samtidigt. Fördelen med en återställningsplan i stället för en enskild dators redundans ä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 redundansen, genomför du den för att börja komma åt arbetsbelastningen från den virtuella Azure-datorn.
När den primära lokala platsen är tillgänglig igen kan du förbereda för återställning efter fel. För att kunna växla tillbaka måste du konfigurera en infrastruktur för återställning efter fel, inklusive:
- Tillfällig processerserver i Azure: Om du vill växla tillbaka från Azure måste du konfigurera en virtuell Azure-dator så att den fungerar som en processerserver 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 växla tillbaka behöver du en VPN-anslutning (eller ExpressRoute) från Azure-nätverket till den lokala platsen.
- Separat huvudmålserver: Som standard hanterar den huvudmålserver som installerades med konfigurationsservern på den lokala virtuella VMware-datorn återställning efter fel. Om du behöver växla tillbaka stora volymer med trafik kan du konfigurera 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: Återaktivera skyddet av de virtuella Azure-datorerna så att de replikeras från Azure tillbaka till de lokala virtuella VMware-datorerna.
- Steg 2: Kör en redundans till den lokala platsen.
- Steg 3: När arbetsbelastningarna har havererat tillbaka kan du återererbara replikeringen för de lokala virtuella datorerna.
Nästa steg
Följ den här självstudien för att aktivera replikering från VMware till Azure.