Felövergång och återställning
Azure Site Recovery ger dig flexibiliteten att redundansväxla till Azure om ett haveri inträffar och återställa till lokala datorer när händelsen är över.
Nu vill du göra en fullständig failover för resten av den skyddade miljön till Azure. Du utför en komplett redundansväxling efter att du framgångsrikt har kört ett redundanstest på en enskild testvirtuell maskin. Sedan gör du "failback" efter att redundansväxlingen har slutförts.
I den här enheten utforskar du skillnaderna mellan övergång vid fel och återställning efter fel. Du får också lära dig hur en återställningspolicy skapas automatiskt efter att du har konfigurerat en replikeringspolicy för Azure.
Redundans och återställning efter fel
En failover är den process som äger rum när beslutet fattas att aktivera BCDR-planen för verksamheten. Övergång till reservsystem sker när den aktuella aktiva miljön som skyddas med hjälp av Site Recovery överförs till replikenvironmenten. Den här målreplikmiljön ersätter den aktiva miljön och blir den primära infrastrukturen.
En återställning efter fel är motsatsen till en redundansväxling. Den tidigare livemiljön (som nu är replikmiljön eftersom en redundansväxling ägde rum) tar tillbaka sin ursprungliga roll och blir livemiljön igen. När redundansväxlingen har inträffat i den första omgången måste en återskyddsfas utföras. I den här fasen synkroniserar du den ursprungliga miljön igen med den nya livemiljön. Den här processen möjliggör att överflyttning och återställning kan ske utan dataförlust. Återaktiveringsfasen är troligen en lång process eftersom du måste fastställa att den gamla livemiljön fungerar korrekt efter katastrofen.
De fyra stegen i redundans- och återställningsåtgärder är:
- Redundansväxling till Azure: Om den lokala primära platsen slutar fungera fattas beslutet att redundansväxla till Azure (eller den sekundära platsen) som skapar virtuella datorer från de primära replikerade data.
- Återskydda virtuella Azure-datorer: När felövergången har inträffat måste de virtuella Azure-datorerna återskyddas så att de kan replikera ändringar tillbaka till miljön på plats efter att katastrofen har avvärjts. Virtuella datorer stängs av för att säkerställa datakonsekvens.
- Återgå till lokala system: När det lokala systemet är igång igen kan du återgå till den miljön. Det blir sedan den levande miljön igen. Du kan inte återställa till fysiska servrar. Alla system måste återställas till virtuella datorer.
- Återskydda lokala virtuella datorer: Återskyddet av de lokala virtuella datorerna sker så att de börjar replikera till Azure när återgången från failover har utförts.
Principer för återställning efter fel
När du skapar en lokal replikeringsprincip för att kopiera dina lokala datorer till Azure skapas automatiskt en associerad princip för återställning efter fel. Principen har vissa fasta attribut som inte kan ändras. Följande attribut är:
- Det går bara att replikera tillbaka till den lokala konfigurationsservern.
- Återställningspunktmålet anges till 15 minuter.
- Återställningspunkten är inställd på att behållas i 24 timmar.
- Appkonsekventa ögonblicksbilder tas varje timme.
När du kör återställning efter fel stoppas de virtuella Azure-datorerna. När replikeringen är klar startar du den lokala virtuella datorn för att ta över arbetsbelastningarna. Tjänsten avbryts, så schemalägg återställningen vid en tidpunkt som inte påverkar din verksamhet.
Planer för affärskontinuitet och haveriberedskap
BCDR-planer i Site Recovery möjliggör anpassning och sekvensering av övergång och återgång för virtuella datorer och de program som körs på dem. Maskiner grupperas tillsammans, och återställningsåtgärder kan automatiseras med hjälp av skript under felövergång eller återställning. Du kan också lägga till fler manuella steg för åtgärder om du behöver. Om du testar BCDR-planen innan en katastrof inträffar kan du vara mer säker på ett positivt resultat. Du måste snabbt få igång infrastrukturen igen på den sekundära platsen för att uppfylla företagets mål för återställningstid.
Flexibla övergångar
Med möjligheten att vara flexibel med redundansväxlingar kan Site Recovery köra redundansväxlingar på begäran i testsyfte. Att isolera dessa tester innebär att livetjänster inte avbryts. Den här flexibiliteten gör det också möjligt att köra en redundansväxling under ett planerat avbrott i livetjänsten. Avbrottet avbryter inte användare av systemet eftersom de automatiskt växlas över till den replikerade miljön. Flexibiliteten fungerar också åt andra hållet. Återställning på begäran kan antingen ingå i ett planerat test eller som en del av ett fullt aktiverat katastrofåterställningsscenario.