Förbereda för återaktivering av skydd och återställning efter fel för virtuella VMware-datorer

  • Artikel

Efter redundansväxling av lokala virtuella VMware-datorer eller fysiska servrar till Azure skyddar du de virtuella Azure-datorer som skapats efter redundansväxlingen, så att de replikeras tillbaka till den lokala platsen. När replikeringen från Azure till den lokala miljön är på plats kan du sedan växla tillbaka genom att köra en redundansväxling från Azure till en lokal plats när du är klar.

Återaktivering av 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 Information
Lokal konfigurationsserver Den lokala konfigurationsservern måste köras och anslutas till Azure.

Den virtuella dator som du återställer 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 nätverkskortet för återställning efter fel på konfigurationsservern. För kvarhå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 redväxlar 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 proof-of-concept kan du använda den lokala processervern och ExpressRoute med privat peering.

Processervern ska finnas i Det Azure-nätverk där den redolkade virtuella datorn finns. Processervern måste också kunna kommunicera med den lokala konfigurationsservern och huvudmålservern.
Separat huvudmålserver Huvudmålservern tar emot redundansdata och som standard körs en Windows-huvudmålserver på den lokala konfigurationsservern.

En huvudmålserver kan ha upp till 60 anslutna diskar. Om de virtuella datorer som växlas tillbaka har fler än totalt 60 diskar, eller om du växlar tillbaka 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 bör 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 paravirtuell SCSI-styrenhet. Kontrollanten kan bara vara en LSI-logikkontrollant. Utan en LSI-logikkontrollant misslyckas återaktiveringen av skyddet.
Replikeringsprincip för återställning efter fel Om du vill replikera tillbaka till en lokal plats behöver du en princip för återställning efter fel. Den här principen skapas automatiskt när du skapar en replikeringsprincip till Azure.

Principen associeras automatiskt med konfigurationsservern. Den är inställd på ett tröskelvärde för återställningspunkt på 15 minuter, kvarhållning av återställningspunkter på 24 timmar och appkonsekvent ögonblicksbildsfrekvens ä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 återaktivering av skydd/återställning efter fel.

Portar för redundans och återställning efter fel

Distribuera en processerver i Azure

  1. Konfigurera en processerver i Azure för återställning efter fel.
  2. Se till att virtuella Azure-datorer kan nå processervern.
  3. 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

  1. Observera kraven och begränsningarna för huvudmålservern.

  2. Skapa en Huvudmålserver för Windows eller Linux för att matcha operativsystemet för de virtuella datorer som du vill återaktivera skyddet och återställa.

  3. Se till 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.

    • Om du vill förhindra detta undantar du 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 vMotion-aktivitetens mål. 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.

  4. Lägg till en kvarhållningsenhet på 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 syfte, 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 är installerade på en volym är volymen en cachevolym för huvudmålet.
    • Volymens filsystemtyp är inte FAT eller FAT32.
    • Volymkapaciteten är inte noll.
    • Standardkvarhållningsvolymen för Windows är R-volymen.
    • Standardkvarhållningsvolymen för Linux är /mnt/retention.

  5. Lägg till en enhet om du använder en befintlig processerver. Den nya enheten måste uppfylla kraven i det sista steget. Om kvarhållningsenheten inte finns visas den inte i listrutan för val 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 i portalen. Du kan uppdatera konfigurationsservern om enheten inte visas efter 15 minuter.

  6. Installera VMware-verktyg eller open-vm-tools på huvudmålservern. Utan verktygen kan datalager på huvudmålets ESXi-värd inte identifieras.

  7. 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 en konsekvent UUID till VMDK så att den monteras korrekt.

  8. Kontrollera åtkomstkraven för vCenter Server:

    • Om den virtuella dator som du återställer 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-/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 ESXi-huvudmålvärden. När du växlar tillbaka till en alternativ plats återställs data till samma datalager och samma ESXi-värd som används av den lokala huvudmålservern.

  9. 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.

  10. Kontrollera att ESXi-värden där den virtuella huvudmåldatorn har minst ett VMFS-datalager (Virtual Machine File System) kopplat till sig. Om inga VMFS-datalager är anslutna är datalagringsindata i återaktiveringsinställningarna tomma och du kan inte fortsätta.

Nästa steg

Lär dig hur du återaktivera skyddet av en virtuell dator.