Definiowanie RTO, RPO i poziomów odtwarzania

Planowanie ciągłości działania (BCP) to proces zapewniania możliwości kontynuowania kluczowych funkcji biznesowych w trakcie katastrofy i po niej. W przetwarzaniu w chmurze oznacza to projektowanie systemów, które mogą odzyskać sprawność w granicach akceptowalnego czasu i poziomu utraty danych. Dwie kluczowe metryki — RTO i RPO — określają, co oznacza termin „akceptowalny” dla danego obciążenia.

Docelowy czas odtworzenia (RTO) to maksymalny akceptowalny czas, przez jaki system może pozostawać niedostępny po katastrofie. Odpowiada na pytanie: „Jak długo firma może tolerować niedostępność tej aplikacji?”. RTO wyraża się w jednostkach czasu — godzinach, minutach lub sekundach. System przetwarzania płatności może mieć RTO wynoszące 15 minut, podczas gdy wewnętrzny portal HR może mieć RTO wynoszące 24 godziny.

Docelowy punkt odtworzenia (RPO) to maksymalna akceptowalna ilość utraconych danych mierzona w jednostkach czasu. Odpowiada na pytanie: „Ile danych firma może sobie pozwolić utracić?”. Jeśli RPO wynosi 1 godzinę, firma akceptuje utratę danych z maksymalnie 1 godziny transakcji. RPO określa, jak często należy tworzyć kopie zapasowe lub replikować dane. RPO równe 0 wymaga replikacji synchronicznej, która jest kosztowna i może obniżać wydajność operacji zapisu.

Ważne jest, aby nie mylić RTO z RPO:

• RTO dotyczy czasu — tego, jak długo system pozostaje niedostępny
• RPO dotyczy danych — tego, ile danych zostaje utraconych

System może mieć krótki RTO (szybkie odzyskiwanie), ale długi RPO (akceptowanie znacznej utraty danych), lub odwrotnie. Najlepiej, aby oba parametry były krótkie, jednak osiągnięcie tego wymaga znacznych inwestycji w replikację i zasoby ciepłego trybu gotowości.

Nie wszystkie obciążenia mają taką samą krytyczność. Typowym podejściem jest klasyfikowanie obciążeń do poziomów odzyskiwania na podstawie wpływu na działalność biznesową:

• Poziom 1 (krytyczny dla działania firmy) — rygorystyczne RTO/RPO, najwyższy koszt (np. płatności, platformy transakcyjne)
• Poziom 2 (krytyczny dla biznesu) — umiarkowane RTO/RPO (np. CRM, ERP)
• Poziom 3 (niekrytyczny) — mniej rygorystyczne RTO/RPO, najniższy koszt (np. środowiska deweloperskie, archiwa)

Różne poziomy odzyskiwania odpowiadają różnym możliwościom platformy Azure:

• Poziom 1 — zapis wieloregionowy Cosmos DB, grupy automatycznego przełączania SQL, architektura active-active, Traffic Manager
• Poziom 2 — Azure Site Recovery do regionu pomocniczego, replikacja geograficzna SQL (replika tylko do odczytu), codzienne kopie zapasowe z przechowywaniem przez 30 dni
• Poziom 3 — Azure Backup z cotygodniowym harmonogramem, brak replikacji, odtwarzanie z migawki

Aby uzasadnić inwestycję w architekturę o niskim RTO, należy obliczyć koszt przestoju danego obciążenia. Obejmuje on utracone przychody, kary wynikające z umów SLA z klientami, spadek produktywności pracowników i utratę reputacji. Jeśli koszt 1 godziny przestoju wynosi 500 000 USD, wydawanie 50 000 USD miesięcznie na konfigurację active-active jest łatwe do uzasadnienia. Należy użyć tych danych do przygotowania uzasadnienia biznesowego dla odpowiedniego poziomu odzyskiwania.

Azure Site Recovery (ASR) to podstawowa usługa służąca do osiągania docelowych wartości RTO/RPO poziomu 2 na platformie Azure. ASR stale replikuje maszyny wirtualne do regionu pomocniczego i może zainicjować przełączenie awaryjne w ciągu kilku minut. Częstotliwość replikacji maszyn wirtualnych platformy Azure wynosi 30 sekund (spójność awaryjna) lub 1–4 godziny (spójność aplikacji), co w zależności od konfiguracji zwykle wyznacza zakres RPO.

W przypadku obciążeń, dla których RPO jest mierzone w godzinach, wystarczająca jest usługa Azure Backup z odpowiednim harmonogramem. Na przykład RPO wynoszące 4 godziny wymaga wykonywania kopii zapasowej co najmniej co 4 godziny. Usługa Azure Backup obsługuje rozszerzone zasady, które umożliwiają tworzenie godzinowych harmonogramów kopii zapasowych maszyn wirtualnych platformy Azure. W przypadku baz danych funkcja odtwarzania do określonego punktu w czasie (PITR) wraz z kopiami dzienników transakcji może zapewnić RPO krótsze niż 1 godzina przy niższym koszcie niż ASR.

Docelowe wartości RTO i RPO powinny być formalnie udokumentowane w ramach analizy wpływu na działalność (BIA) i przeglądane zarówno przez interesariuszy technicznych, jak i biznesowych. BIA przypisuje każdą aplikację do odpowiedniego poziomu odzyskiwania, dokumentuje docelowe wartości RTO/RPO, wskazuje usługi Azure, które zapewnią osiągnięcie tych wartości, oraz określa harmonogram testów (częstotliwość sprawdzania planu odtwarzania po awarii podczas ćwiczeń).

Docelowe wartości RTO i RPO pozostają jedynie założeniami, dopóki nie zostaną zweryfikowane podczas testów odtwarzania po awarii. Podczas testu należy zmierzyć rzeczywisty czas odzyskiwania (czy spełnia określone RTO?) oraz rzeczywistą utratę danych w punkcie odtworzenia (czy spełnia określone RPO?). Jeśli test ujawni luki, należy zaktualizować architekturę lub procedury, aż do uzyskania stałej zgodności z celami. Wyniki testów należy udokumentować na potrzeby audytów zgodności.

Sprawdź swoją wiedzę na temat zagadnień Microsoft Azure Fundamentals (AZ-900) omówionych w tej lekcji.

W tej lekcji poznali Państwo następujące zagadnienia: RTO to maksymalny akceptowalny czas przestoju, natomiast RPO to maksymalna akceptowalna utrata danych mierzona w jednostkach czasu; obciążenia są klasyfikowane do poziomów odzyskiwania, którym odpowiadają konkretne usługi Azure; a testowanie jest niezbędne do sprawdzenia, czy można osiągnąć docelowe wartości RTO/RPO. W następnej części omówimy plany odzyskiwania i automatyczne przełączanie awaryjne za pomocą Azure Site Recovery.