Dela via


Aktivera VM-skydd i Azure Site Recovery

När målet och källmiljöerna har konfigurerats kan du börja aktivera skyddet av virtuella datorer (från källan till målet). All konfiguration görs i målmiljön i själva Site Recovery-valvet.

Förutsättningar

Du kan konfigurera replikeringsprincipen för respektive virtuella datorer som du vill skydda i Site Recovery-valvet. Dessa virtuella datorer finns i källmiljön, där de konfigurerade en specifik resursgruppsstruktur, virtuella nätverk, offentliga IP-adresser och NSG:er.

Site Recovery hjälper till att replikera alla virtuella datordata, men se till att följande förutsättningar uppfylls innan du börjar:

  • Målnätverksanslutningen har konfigurerats.

  • De virtuella målnätverken är konfigurerade, där varje skyddad virtuell dator ansluts när en felövergång sker.

  • Målanvändarprenumerationen har tillräcklig beräkningskvot för alla virtuella datorer som du planerar att eventuellt överflytta.

  • Dessa virtuella nätverk kan konfigureras på samma sätt som källnätverken, eller så kan de ha en annan design, beroende på din plan och ditt mål för haveriberedskap.

  • Se till att de nya offentliga och privata IP-adresserna fungerar som förväntat för de specifika arbetslaster som du skyddar (när översvängningar inträffar, har de översvängda virtuella datorerna IP-adresser från målmiljön).

  • Önskad resursgruppskonfiguration skapas.

  • När du konfigurerar replikeringen kan du också skapa resursgrupperna, men för en produktionsmiljö bör du skapa dem i förväg enligt din namngivningsprincip och struktur.

  • Kontrollera att rätt RBAC har tilldelats och att taggningen är på plats – allt enligt din företagsprincip.

  • "Cachelagringskontot" skapas och är tillgängligt.

  • "Cachelagringskontot" är ett tillfälligt lagringskonto som används i replikeringsprocessen.

    Notera

    Omfånget för det här lagringskontot är komplext och kapaciteten för Plan för Hyper-V VM katastrofåterställning beskrivs i artikel för att förtydliga dessa begrepp. Information om Azure Site Recovery på Azure Stack Hub finns i artikeln Kapacitetsplanering.

Aktivera replikering

I målmiljön öppnar du Site Recovery-valvet i Azure Stack Hub-användarportalen och väljer Skydda arbetsbelastningar:

Skärmbild av portalen för att skydda arbetsbelastningar.

Välj den installation som du har konfigurerat och kontrollera att den är felfri:

Skärmbild av portalens hälsoförcheckning.

Bladet ber dig sedan att välja källmiljön och källprenumerationen. Du bör se alla Azure Stack Hub-användarprenumerationer som användaren (eller SPN) som du har konfigurerat har åtkomst till.

Välj den prenumeration som innehåller källarbetsbelastningarna och välj de virtuella datorer som du planerar att aktivera skydd för. Du kan skydda upp till 10 virtuella datorer åt gången. PowerShell-skript är tillgängliga som kan aktivera större distributioner.

Skärmbild av skärmen för att aktivera replikeringsportalen.

Azure Site Recovery replikerar alla diskar som är anslutna till den virtuella datorn. I den här versionen är alla diskar skyddade.

Skärmbild av inställningar för portalreplikering.

I nästa steg väljer du målmiljökonfigurationen. Den här konfigurationen omfattar de nätverk som de virtuella datorerna ansluter till och det cachelagringskonto som de använder. Du måste använda PowerShell för att konfigurera replikeringsprincipen. Skript är tillgängliga som hjälper dig att starta anpassningsprocessen.

Skärmbild av inställningar för målmiljön på portalen.

Granska den valda konfigurationen och aktivera replikeringen:

Skärmbild av skärmen för slutlig replikeringsgranskning.

Kontrollera replikeringsstatus och redigera inställningar

I Site Recovery-valvet på bladet replikerade objekt kan du se var och en av de virtuella datorer som du har aktiverat replikering för:

Skärmbild av kopierade objekt på portalen.

Genom att välja dessa objekt kan du visa aktuellt tillstånd, redigera inställningarna för det skyddade objektet eller utlösa åtgärder som ett redundanstest:

Skärmbild av inställningar och egenskaper för skyddade objekt.

Förstå de olika tillstånden för skyddade virtuella datorer

När en virtuell dator har skyddats och data replikerats finns det ytterligare uppgifter som du kan utföra:

  • Kör ett redundanstest:

    • Du kan köra ett redundanstest för att verifiera din strategi för replikering och haveriberedskap, utan dataförlust eller driftstopp. Ett redundanstest påverkar inte pågående replikering eller produktionsmiljön. Du kan köra ett redundanstest på en specifik virtuell dator eller på en återställningsplan som innehåller flera virtuella datorer.
  • Ett redundanstest simulerar redundansväxlingen för den här virtuella datorn (från källan till målet) genom att skapa den virtuella måldatorn. När du gör ett redundanstest kan du välja:

    • Återställningspunkten att växla över till vid fel:

      • Senaste återställningspunkten (lägsta RPO): Det här alternativet bearbetar först alla data som har skickats till Site Recovery-tjänsten för att skapa en återställningspunkt för varje VM innan det sväxlas till den. Det här alternativet ger det lägsta RPO (mål för återställningspunkt), eftersom den virtuella datorn som skapas efter failover kommer att ha alla sina data replikerade till Site Recovery när failover utlöses.
      • Senaste bearbetade (lägsta RTO): överföra alla virtuella datorer i planen till den senaste återställningspunkten som har bearbetats av Site Recovery. Om du vill se den senaste återställningspunkten för en specifik virtuell dator kontrollerar du senaste återställningspunkterna i inställningarna för den virtuella datorn. Det här alternativet ger en låg RTO (mål för återställningstid), eftersom ingen tid ägnas åt bearbetning av obearbetade data.
      • Senaste appkonsekventa: växlar över alla virtuella datorer i planen till den senaste programkonsekventa återställningspunkten som har bearbetats av Site Recovery. Om du vill se den senaste återställningspunkten för en specifik virtuell dator kontrollerar du senaste återställningspunkterna i inställningarna för den virtuella datorn.
      • Anpassad: Använd det här alternativet för att växla över en specifik virtuell maskin till en specifik återställningspunkt.
    • Du kan inte välja nätverket just nu. Det redundanstestnätverket har konfigurerats för varje skyddad virtuell dator. Om du behöver ändra den går du tillbaka till egenskaperna för den skyddade virtuella datorn och väljer sedan Visa eller redigera.

      Skärmbild av egenskaperna för portalens virtuella maskin.

  • Test-failover kan hjälpa dig att kontrollera applikationens beteende vid ett avbrott. Den virtuella källdatorn kan dock fortfarande köras. Du måste tänka på det här beteendet när du utför ett redundanstest.

    Not

    Azure Site Recovery replikerar den virtuella datorn helt när du gör ett redundanstest. Den virtuella datorn körs i både käll- och målmiljöer. Du måste ta hänsyn till detta eftersom det kan påverka appens beteende.

  • När redundanstestet är klart kan du välja Rensa redundanstest. Det här alternativet tar bort den virtuella datorn för redundanstest och alla testresurser

    Skärmbild av rensningsskärmen för redundanstest.

  • Felövertagning

    • I händelse av ett problem i källmiljön kan du välja att växla över de virtuella datorerna till målmiljön.

      Skärmbild av failover vm-skärm.

    • När du startar redundansväxlingen kan du Stäng av datorn innan du påbörjar redundansväxlingen. Eftersom det här alternativet flyttar hela den virtuella datorn från källan till målet bör den virtuella källdatorn stängas av innan du väljer det här alternativet.

      Obs

      Om ingen test-failover har utförts under de senaste 180 dagarna rekommenderar Site Recovery att du genomför en innan en faktisk failover. Om du hoppar över valideringen av replikeringen via redundanstest kan det leda till dataförlust eller oförutsägbar stilleståndstid.

    • När övergången är klar måste du bekräfta ändringarna för att fullt ut slutföra processen. Om du inte checkar in först och sedan försöker skydda igen utlöser åtgärden för återskydd först en incheckning och fortsätter sedan med återskydd (därför tar det längre tid eftersom båda åtgärderna krävs).

    • När källmiljön är felfri igen kan du starta en "återgångsprocess". Den här processen utförs i två steg:

      • Kör re-protect för att börja replikera data tillbaka till källan.
      • När data har replikerats fullständigt kör du den planerade redundansväxlingen för att flytta tillbaka resursen till den ursprungliga miljön.

      Du kan kontrollera följande avsnitt för en lista över överväganden som behövs under var och en av dessa faser.

    Notera

    För närvarande stöder vi inte återaktivering av skydd (efter en återställning efter fel). Du måste inaktivera skydd, ta bort agenten och sedan aktivera skydd igen för den här virtuella datorn. Den här processen kan automatiseras och vi tillhandahåller skript som hjälper dig att komma igång.

Avinstallera Azure Site Recovery VM-tillägget

När du avinstallerar Azure Site Recovery-tillägget tar det avsiktligt inte bort mobilitetstjänsten som körs inom den virtuella datorn. Detta blockerar framtida skydd och kräver manuella steg för att aktivera skydd igen för den virtuella datorn.

När du har tagit bort Azure Site Recovery VM-tillägget måste du avinstallera mobilitetstjänsten som körs på den virtuella datorn. Följ dessa steg för att avinstallera mobilitetstjänsten.

Notera

Om du planerar att återaktivera skyddet för den virtuella datorn ska du, efter att ha följt föregående steg, starta om den virtuella datorn innan du försöker lägga till skydd med Azure Site Recovery.

Överväganden

Följande information är inte nödvändig för normala åtgärder. De här anteckningarna kan dock hjälpa dig att bättre förstå de processer som sker bakom kulisserna.

För var och en av tillstånden finns det flera saker att tänka på:

  • Skydda igen:

    • Kontrollera att den första källprenumerationen, den första resursgruppen och det virtuella nätverket/undernätet för det ursprungliga primära nätverkskortet fortfarande finns på den primära stämpeln. Du kan hämta den här informationen från det skyddade objektet med hjälp av PowerShell:

      Get-AzResource -ResourceID "/subscriptions/<subID>/resourceGroups/<RGname>/providers/Microsoft.DataReplication/replicationVaults/<vaultName>/protectedItems/<vmName>"
      

      Följande bild visar exempelutdata från det här kommandot:

      Skärmbild av PowerShell-kommandoutdata.

    • Innan du kör återskydd för virtuella Linux-datorer kontrollerar du att certifikatet för Site Recovery-tjänsten är betrott på de virtuella Linux-datorer som du vill skydda igen. Detta förtroende avblockerar registreringen av den virtuella datorn med Site Recovery-tjänsten, vilket är nödvändigt för omskydd.

      För virtuella Ubuntu-/Debian-datorer:

      sudo cp /var/lib/waagent/Certificates.pem /usr/local/share/ca-certificates/Certificates.crt
      
      sudo update-ca-certificates
      

      För virtuella Red Hat-datorer:

      sudo update-ca-trust force-enable
      
      sudo cp /var/lib/waagent/Certificates.pem /etc/pki/ca-trust/source/anchors/
      
      sudo update-ca-trust extract
      
    • Se till att den virtuella datorn Site Recovery-installationen har tillräckligt med tillgängliga datadiskplatser. Replikdiskarna för återskydd är anslutna till installationen (mer information finns i Kapacitetsplanering).

    • Under återskyddsprocessen stängs den virtuella källdatorn (som skulle ha den källanAzStackVirtualMachineId på källstämpeln) av när återskyddet utlöses och os-diskarna och datadiskarna som är anslutna till den kopplas från och ansluts till installationen som replikdiskar om de är gamla. OS-disken ersätts med en tillfällig OS-disk med storlek 1 GB.

    • Även om en disk kan återanvändas som replik i återskydd, men den finns i en annan prenumeration än den virtuella datorn, skapas en ny disk från den i samma prenumeration och resursgrupp som enheten, så att den nya disken kan anslutas till installationen.

    • Anslutna datadiskar för apparaten bör inte modifieras/anslutas/frånkopplas/ändras manuellt, eftersom manuell omsynkronisering med återskydd inte stöds i offentlig förhandsversion (se artikeln om kända problem). Det går inte att återställa återskyddet om replikdiskarna tas bort.

  • Failback (planerad övergång): återställa ett återskyddat objekt från målstämpeln till källstämpeln:

    • Kontrollera att den första källprenumerationen, den första resursgruppen och det virtuella nätverket/undernätet för det ursprungliga primära nätverkskortet fortfarande finns på källstämpeln. Du kan hämta den här informationen från det skyddade objektet med hjälp av PowerShell.
    • Den virtuella datorn med källanAzStackVirtualMachineId på källstämpeln skapas med replikdiskarna och nyligen skapade nätverkskort om den inte finns. eller så ersätts den med en replik-OS-disk och datadiskar om den finns.
    • Om den virtuella datorn med den källanAzStackVirtualMachineId på den primära stämpeln finns, kopplas alla diskar som är anslutna till den bort men tas inte bort och nätverkskorten förblir desamma.
    • Om den virtuella datorn med källan AzStackVirtualMachineId på den primära stämpeln finns, och om den är i en annan prenumeration än den virtuella maskinen, skapas nya diskar i samma prenumeration och resursgrupp som återställnings-VM:t. Dessa diskar skapas från replikdiskarna som kopplats från installationen, så att de nya diskarna kan anslutas till återställnings-VM:t.
  • Bekräfta att övergång/återställning har genomförts. Den felöverflyttade virtuella datorn på återställningspunkten tas bort när återväxlingen har bekräftats.

  • När du avinstallerar Azure Site Recovery-resursprovidern tas även alla valv som skapats i dessa Azure Stack Hub-målstämplar bort. Det här är en Azure Stack Hub-operatörsåtgärd utan varningar eller aviseringar för användare när det händer.

Nästa steg

Översikt över Azure Site Recovery