Förbereda för återaktivering av skydd och återställning efter fel för virtuella VMware-datorer
Efter redundansväxling av lokala virtuella VMware-datorer eller fysiska servrar till Azure kan du återaktivera skyddet av de virtuella Azure-datorer som skapats efter redundansväxlingen så att de replikeras tillbaka till den lokala platsen. Med replikering från Azure till lokal plats kan du sedan återställa genom att köra en redundansväxling från Azure till en lokal plats när du är klar.
Återaktivera skydd eller återställning efter fel
Du behöver ett antal komponenter och inställningar på plats innan du kan återaktivera skyddet och återställa från Azure.
| Komponent | Detaljer |
|---|---|
| Lokal konfigurationsserver | Den lokala konfigurationsservern måste köras och anslutas till Azure. Den virtuella dator som du inte kan återgå till måste finnas i konfigurationsserverdatabasen. Om en katastrof påverkar konfigurationsservern återställer du den med samma IP-adress för att säkerställa att återställning efter fel fungerar. Om IP-adresser för replikerade datorer behålls vid redundansväxling bör plats-till-plats-anslutning (eller ExpressRoute-anslutning) upprättas mellan virtuella Azure-datorer och NIC för återställning efter fel på konfigurationsservern. För behållna IP-adresser behöver konfigurationsservern två nätverkskort – en för källdatoranslutning och en för Azure-återställning efter fel. Detta förhindrar överlappning av undernätsadressintervall för källan och reded över virtuella datorer. |
| Processerver i Azure | Du behöver en processerver i Azure innan du kan återställa till din lokala plats. Processervern tar emot data från den skyddade virtuella Azure-datorn och skickar dem till den lokala platsen. Du behöver ett nätverk med låg latens mellan processervern och den skyddade virtuella datorn, så vi rekommenderar att du distribuerar processervern i Azure för högre replikeringsprestanda. För konceptbevis kan du använda den lokala processervern och ExpressRoute med privat peering. Processervern ska finnas i det Azure-nätverk där den redolkande virtuella datorn finns. Processervern måste också kunna kommunicera med den lokala konfigurationsservern och huvudmålservern. |
| Separat huvudmålserver | Huvudmålservern tar emot återställningsdata och som standard körs en Windows-huvudmålserver på den lokala konfigurationsservern. En huvudmålserver kan ha upp till 60 diskar anslutna till sig. Om de virtuella datorerna som redundansväxlar tillbaka har mer än sammanlagt 60 diskar, eller om du redundansväxlar stora trafikvolymer, skapar du en separat huvudmålserver för återställning efter fel. Om datorer samlas in i en replikeringsgrupp för konsekvens för flera virtuella datorer måste alla virtuella datorer vara Windows, eller alla måste vara Linux. Varför? Eftersom alla virtuella datorer i en replikeringsgrupp måste använda samma huvudmålserver och huvudmålservern måste ha samma operativsystem (med samma eller en högre version) än de replikerade datorerna. Huvudmålservern ska inte ha några ögonblicksbilder på sina diskar, annars fungerar inte återaktivering av skydd och återställning efter fel. Huvudmålet kan inte ha en Paravirtual SCSI-styrenhet. Styrenheten kan bara vara en LSI-logikstyrenhet. Utan en LSI-logikstyrenhet misslyckas återaktiveringen av skyddet. |
| Replikeringsprincip för återställning efter fel | Om du vill replikera tillbaka till den lokala platsen behöver du en återställningsprincip. Den här principen skapas automatiskt när du skapar en replikeringsprincip till Azure. Principen associeras automatiskt med konfigurationsservern. Det är inställt på ett tröskelvärde för återställningspunkt på 15 minuter, kvarhållning av återställningspunkter på 24 timmar och appkonsekvent ögonblicksbildfrekvens är 60 minuter. Det går inte att redigera principen. |
| Plats-till-plats-VPN/Privat ExpressRoute-peering | Återaktivering av skydd och återställning efter fel behöver en plats-till-plats-VPN-anslutning eller privat ExpressRoute-peering för att replikera data. |
Portar för återaktivering av skydd/återställning efter fel
Ett antal portar måste vara öppna för återaktivering av skydd/återställning efter fel. Följande bild illustrerar portarna och återaktivera skyddet/återställningsflödet.
Distribuera en processerver i Azure
- Konfigurera en processserver i Azure för återställning efter fel.
- Se till att virtuella Azure-datorer kan nå processervern.
- Kontrollera att vpn-anslutningen för plats-till-plats eller det privata ExpressRoute-peeringnätverket har tillräckligt med bandbredd för att skicka data från processervern till den lokala platsen.
Distribuera en separat huvudmålserver
Observera huvudmålserverns krav och begränsningar.
Skapa en Windows - eller Linux-huvudmålserver för att matcha operativsystemet för de virtuella datorer som du vill återaktivera skyddet och återställa.
Kontrollera att du inte använder Storage vMotion för huvudmålservern, eller så kan återställning efter fel misslyckas. Det går inte att starta den virtuella datorn eftersom diskarna inte är tillgängliga för den.
- Undvik detta genom att undanta huvudmålservern från vMotion-listan.
- Om ett huvudmål genomgår en Storage vMotion-uppgift efter återaktivering av skyddet migreras de skyddade VM-diskarna som är anslutna till huvudmålservern till målet för vMotion-aktiviteten. Om du försöker återställa efter detta misslyckas diskavkopplingen eftersom diskarna inte hittas. Det är sedan svårt att hitta diskarna i dina lagringskonton. Om detta inträffar hittar du dem manuellt och kopplar dem till den virtuella datorn. Därefter kan den lokala virtuella datorn startas.
Lägg till en kvarhållningsenhet till den befintliga Windows-huvudmålservern. Lägg till en ny disk och formatera enheten. Kvarhållningsenheten används för att stoppa tidpunkten när den virtuella datorn replikeras tillbaka till den lokala platsen. Observera dessa kriterier. Om de inte uppfylls visas inte enheten för huvudmålservern:
- Volymen används inte för något annat ändamål, till exempel ett replikeringsmål, och den är inte i låsläge.
- Volymen är inte en cachevolym. Den anpassade installationsvolymen för processervern och huvudmålet är inte berättigad till en kvarhållningsvolym. När processervern och huvudmålet installeras på en volym är volymen en cachevolym för huvudmålet.
- Volymens filsystemtyp är inte FAT eller FAT32.
- Volymkapaciteten är icke-zero.
- Standardkvarhållningsvolymen för Windows är R-volymen.
- Standardkvarhållningsvolymen för Linux är /mnt/retention.
Lägg till en enhet om du använder en befintlig processserver. Den nya enheten måste uppfylla kraven i det sista steget. Om kvarhållningsenheten inte finns visas den inte i listrutan för markering i portalen. När du har lagt till en enhet i det lokala huvudmålet tar det upp till 15 minuter innan enheten visas i valet på portalen. Du kan uppdatera konfigurationsservern om enheten inte visas efter 15 minuter.
Installera VMware-verktyg eller open-vm-tools på huvudmålservern. Utan verktygen kan datalager på huvudmålets ESXi-värd inte identifieras.
Ange disken. EnableUUID=true-inställningen i konfigurationsparametrarna för den virtuella huvudmåldatorn i VMware. Om den här raden inte finns lägger du till den. Den här inställningen krävs för att tillhandahålla ett konsekvent UUID till VMDK så att det monteras korrekt.
Kontrollera åtkomstkraven för vCenter Server:
- Om den virtuella datorn som du säkerhetskopiera till finns på en ESXi-värd som hanteras av VMware vCenter Server, behöver huvudmålservern åtkomst till den lokala VM Virtual Machine Disk-filen (VMDK) för att kunna skriva replikerade data till den virtuella datorns diskar. Kontrollera att det lokala vm-dataarkivet är monterat på huvudmålvärden med läs- och skrivåtkomst.
- Om den virtuella datorn inte finns på en ESXi-värd som hanteras av en VMware vCenter-server skapar Site Recovery en ny virtuell dator under återaktiveringen av skyddet. Den här virtuella datorn skapas på ESXi-värden där du skapar den virtuella huvudmålserverdatorn. Välj ESXi-värden noggrant för att skapa den virtuella datorn på den värd som du vill använda. Hårddisken på den virtuella datorn måste finnas i ett datalager som kan nås av den värd där huvudmålservern körs.
- Ett annat alternativ, om den lokala virtuella datorn redan finns för återställning efter fel, är att ta bort den innan du gör en återställning efter fel. Återställning efter fel skapar sedan en ny virtuell dator på samma värd som huvudmål-ESXi-värden. När du växlar tillbaka till en annan plats återställs data till samma datalager och samma ESXi-värd som den som används av den lokala huvudmålservern.
För fysiska datorer som misslyckas tillbaka till virtuella VMware-datorer bör du slutföra identifieringen av värden som huvudmålservern körs på innan du kan skydda datorn igen.
Kontrollera att den ESXi-värd där den virtuella huvudmåldatorn har minst ett VMFS-datalager (Virtual Machine File System) som är kopplat till den. Om inga VMFS-datalager är anslutna är datalagerindata i återaktiveringsinställningarna tomma och du kan inte fortsätta.
Nästa steg
Lär dig hur du återaktivera skyddet av en virtuell dator.