Redundansväxling och återställning efter fel med hjälp av Azure Site Recovery
Med Azure Site Recovery kan din organisation ha flexibilitet, antingen manuellt växla över till en sekundär Azure-region eller växla tillbaka till en virtuell källdator. Det enklaste sättet att hantera den här processen på är att göra det manuellt i Azure-portalen. Det finns även andra alternativ för att aktivera automatisering om ditt företag vill att en redundans utlöses automatiskt. De här alternativen omfattar tekniker som skript via PowerShell eller konfiguration av runbooks i Azure Automation för att orkestrera redundansväxlingar.
Följ dessa steg för att utföra en fullständig redundans av en skyddad virtuell dator till en sekundär region i din prenumeration. När redundansen har slutförts kommer du att återställa den virtuella datorn.
I den här lektionen utforskar vi redundans och återställning efter fel, att återaktivera skyddet av en virtuell dator, samt att övervaka statusen för återaktiveringen.
Vad är redundans?
En redundans inträffar när ett beslut tas om att köra en haveriberedskapsplan för organisationen. Den befintliga produktionsmiljön som skyddas av Site Recovery, replikeras till en annan region. Målmiljön blir den faktiska produktionsmiljön och blir den miljö där organisationens produktionstjänster körs. När målregionen är aktiv bör källmiljön inte längre användas. Du åstadkommer detta genom att stoppa de virtuella källdatorerna.
Det finns en annan fördel med att stänga av de virtuella källdatorerna. När en virtuell dator stängs av resulterar det i minimal dataförlust, eftersom Site Recovery väntar tills alla data har skrivits till disken innan redundansväxlingen utlöses. För att använda dessa data och ha lägsta möjliga mål för återställningspunkten, väljer vi Senaste (lägsta återställningspunktmål).
Vad är återaktivering av skydd och varför är det viktigt?
När en virtuell dator rededs över är den replikering som Site Recovery utför inte längre aktiv. Du måste återaktivera skyddet för att börja skydda den redundansväxlade virtuella datorn. Eftersom du redan har infrastrukturen i en annan region kan du starta replikeringen tillbaka till källregionen. Med återaktiveringen av skyddet kan Site Recovery börja att replikera tillbaka vår nya målmiljö till källmiljön där den startade.
Du kan använda flexibiliteten att redväxelväxa enskilda virtuella datorer eller växla över med hjälp av en återställningsplan för att återaktivera skyddet av den redediterade infrastrukturen. Du kan återaktivera skyddet för varje virtuell dator separat, eller så kan du återaktivera flera virtuella datorer med en återställningsplan.
Återaktiveringen av skyddet tar mellan 45 minuter och 2 timmar, beroende på den virtuella datorns storlek och typ. Till skillnad från andra Site Recovery-processer som du kan övervaka genom att titta på jobbets förlopp måste du visa återaktiveringsstatus på VM-nivå. Detta beror på att synkroniseringsfasen inte visas som ett webbplatsåterställningsjobb.
Bilden visar status för det skyddade objektet, med procentandel som är synkroniserat markerat.
Vad är återställning efter fel?
En återställning efter fel är motsatsen till en redundansväxling. Det är när redundans har utförts till en sekundär region, som nu är produktionsmiljön. Återaktivering av skyddet har slutförts för den redundansväxlade miljön och källmiljön är nu dess replik. Vid en återställning efter fel redundansväxlar Site Recovery tillbaka till de virtuella källdatorerna.
Processen för att slutföra en återställning efter fel är densamma som en redundans, till och med återställningsplanen återanvänds. Om du väljer redundans i din återställningsplan har från angetts till målregionen och till angetts till källregionen.
Hantera redundans
Site Recovery kan köra redundans på begäran. Redundanstestningar är isolerade, vilket innebär att de inte påverkar produktionstjänsterna. Med den här flexibiliteten kan du köra en redundansväxling utan att störa systemets användare. Det motsatta är också möjligt och återställning på begäran kan göras antingen som en del av ett planerat test eller som en del av en process med en anropad haveriberedskapsprocess.
Återställningsplanerna i Site Recovery möjliggör även anpassning och sekvensering av redundans och återställning efter fel. Med planerna kan du gruppera datorer och arbetsbelastningar.
Flexibiliteten kan också tillämpas i processen för att utlösa redundans. Det är enkelt att utföra manuella redundansväxlingar i Azure-portalen. Med PowerShell-skript eller runbooks i Azure Automation får du även automatiseringsalternativ.
Åtgärda problem med redundans
Även om Site Recovery automatiseras, kan det fortfarande uppstå fel. I följande lista visas de tre vanligaste problemen som har observerats. En fullständig lista med problem och hur du felsöker dem finns i länken i sammanfattningslektionen.
Problem med resurskvoter i Azure
Site Recovery måste skapa resurser i olika regioner. Om vår prenumeration inte kan göra detta, misslyckas replikeringen. Det här felet uppstår också om prenumerationen inte har rätt kvot för att skapa virtuella datorer som matchar storleken på de virtuella källdatorerna.
Du kan korrigera detta genom att kontakta Azure-faktureringssupporten och begära att de skapar rätt storlek på virtuella datorer i den nödvändiga målregionen.
En eller flera diskar är tillgängliga för skydd
Det här felet inträffar om du har konfigurerat Site Recovery för dina virtuella datorer och sedan har lagt till eller initierat ytterligare diskar.
Du kan åtgärda felet genom att lägga till replikering för de nyligen tillagda diskarna, eller så kan du välja att ignorera diskvarningen.
Betrodda rotcertifikat
Kontrollera att de senaste rotcertifikaten har installerats för att tillåta att Site Recovery kommunicerar och autentiserar virtuella datorer för replikering på ett säkert sätt. Felet kan uppstå om de virtuella datorerna inte har de senaste uppdateringarna. Du måste uppdatera både virtuella Windows- och Linux-datorer innan Site Recovery kan aktivera replikering.
Korrigeringen skiljer sig åt mellan operativsystemen. Windows är lika enkelt som att se till att automatisk Windows-uppdatering är påslagen och att uppdateringar tillämpas. För varje Linux-distribution måste du följa de riktlinjer som tillhandahålls av distributören.