Definere RTO, RPO og gjenopprettingsnivåer

Planlegging for virksomhetskontinuitet (BCP) er prosessen med å sikre at kritiske forretningsfunksjoner kan fortsette under og etter en katastrofe. I nettskyen innebærer dette å utforme systemer som kan gjenopprettes etter feil innenfor akseptable grenser for tid og datatap. To viktige måleverdier – RTO og RPO – definerer hva «akseptabelt» betyr for hver arbeidsbelastning.

Recovery Time Objective (RTO) er den lengste akseptable tiden et system kan være utilgjengelig etter en katastrofe. Det besvarer spørsmålet: «Hvor lenge kan virksomheten tåle at dette programmet er nede?». RTO uttrykkes i tid – timer, minutter eller sekunder. Et system for betalingsbehandling kan ha en RTO på 15 minutter, mens en intern HR-portal kan ha en RTO på 24 timer.

Recovery Point Objective (RPO) er den største akseptable mengden datatap, målt i tid. Det besvarer spørsmålet: «Hvor mye data har virksomheten råd til å miste?». Hvis RPO er 1 time, aksepterer virksomheten å miste opptil 1 times transaksjoner. RPO avgjør hvor ofte data må sikkerhetskopieres eller replikeres. En RPO på 0 krever synkron replikering, noe som er kostbart og kan påvirke skriveytelsen.

Det er viktig å ikke forveksle RTO og RPO:

• RTO handler om tid – hvor lenge systemet er nede
• RPO handler om data – hvor mye data som går tapt

Et system kan ha en kort RTO (rask gjenoppretting), men en lang RPO (akseptert betydelig datatap), eller omvendt. Det ideelle er at begge er korte, men dette krever betydelige investeringer i replikering og kapasitet for varm standby.

Alle arbeidsbelastninger er ikke like kritiske. En vanlig fremgangsmåte er å klassifisere arbeidsbelastninger i gjenopprettingsnivåer basert på forretningspåvirkning:

• Nivå 1 (oppdragskritisk) – strenge RTO/RPO-krav, høyest kostnad (for eksempel betalingstjenester og handelsplattformer)
• Nivå 2 (forretningskritisk) – moderate RTO/RPO-krav (for eksempel CRM og ERP)
• Nivå 3 (ikke-kritisk) – mindre strenge RTO/RPO-krav, lavest kostnad (for eksempel utviklingsmiljøer og arkiver)

Ulike gjenopprettingsnivåer knyttes til ulike Azure-funksjoner:

• Nivå 1 – skriving til flere regioner i Cosmos DB, automatiske failover-grupper i SQL, aktiv-aktiv-arkitektur og Traffic Manager
• Nivå 2 – Azure Site Recovery til en sekundær region, geo-replikering i SQL (lesereplika) og daglige sikkerhetskopier med 30 dagers oppbevaring
• Nivå 3 – Azure Backup med ukentlige tidsplaner, ingen replikering og gjenoppretting fra snapshot

For å begrunne investeringen i en arkitektur med lav RTO bør De beregne kostnaden ved nedetid for arbeidsbelastningen. Dette omfatter tapte inntekter, SLA-gebyrer til kunder, redusert produktivitet blant ansatte og omdømmeskade. Hvis én times nedetid koster 500 000 USD, er det enkelt å begrunne en månedlig kostnad på 50 000 USD for et aktiv-aktiv-oppsett. Bruk disse tallene til å utarbeide en forretningsmessig begrunnelse for riktig gjenopprettingsnivå.

Azure Site Recovery (ASR) er den primære tjenesten for å oppnå RTO/RPO-målene for nivå 2 i Azure. ASR replikerer kontinuerlig virtuelle maskiner til en sekundær region og kan starte en failover i løpet av minutter. Replikeringsfrekvensen for Azure-virtuelle maskiner er hvert 30. sekund (krasjkonsistent) eller hver 1.–4. time (programkonsistent), noe som vanligvis gir en RPO innenfor dette intervallet, avhengig av konfigurasjonen.

For arbeidsbelastninger der RPO måles i timer, er Azure Backup med en passende tidsplan tilstrekkelig. En RPO på 4 timer krever for eksempel et sikkerhetskopieringsintervall på maksimalt 4 timer. Azure Backup støtter utvidede policyer som tillater sikkerhetskopiering hver time for Azure-virtuelle maskiner. For databaser kan gjenoppretting til et bestemt tidspunkt (PITR) med sikkerhetskopier av transaksjonslogger oppnå en RPO på under én time til en lavere kostnad enn ASR.

RTO- og RPO-mål bør dokumenteres formelt i en Business Impact Analysis (BIA) og gjennomgås av både tekniske og forretningsmessige interessenter. BIA-en knytter hvert program til dets gjenopprettingsnivå, dokumenterer RTO/RPO-målene, identifiserer Azure-tjenestene som skal oppfylle målene, og angir testplanen (hvor ofte DR-planen valideres gjennom øvelser).

RTO- og RPO-mål er bare ambisjoner før de valideres gjennom DR-testing. Under en DR-test måler De den faktiske tiden det tar å gjenopprette systemet (oppfyller den angitt RTO?) og det faktiske datatapet ved gjenopprettingspunktet (oppfyller det angitt RPO?). Hvis testen avdekker mangler, må arkitekturen eller prosedyrene oppdateres til målene oppnås konsekvent. Dokumenter testresultatene for samsvarsrevisjoner.

I denne leksjonen lærte De at RTO er den lengste akseptable nedetiden, mens RPO er det største akseptable datatapet målt i tid; arbeidsbelastninger klassifiseres i gjenopprettingsnivåer som knyttes til bestemte Azure-tjenester; og testing er avgjørende for å validere at RTO/RPO-målene kan oppnås. Deretter skal vi se nærmere på gjenopprettingsplaner og automatisert failover med Azure Site Recovery.