Czym jest odzyskiwanie po awarii?

Proces odzyskiwania po awarii (Disaster Recovery, DR) to element nadrzędnych planów zapewnienia ciągłości działania przygotowanych i aktualizowanych przez poszczególne jednostki biznesowe w przedsiębiorstwie. Efektywny plan odzyskiwania po awarii łagodzi skutki niezaplanowanych i planowanych przerw w działaniu systemów o znaczeniu krytycznym na zdolność przedsiębiorstwa do prowadzenia działalności i generowania przychodów.

W tym celu przedstawia elastyczną strukturę, która umożliwia przedsiębiorstwom jednolite i oparte na współpracy działanie w celu przywrócenia, przebudowy i rewitalizacji swoich systemów oraz zbudowania bardziej odpornej infrastruktury.

Dlaczego odzyskiwanie po awarii jest istotne?

Jak długo przedsiębiorstwo mogłoby kontynuować swoją działalność, gdyby straciło swój system płacowy tuż przed naliczeniem i wypłatą wynagrodzeń Jakie kary mogłoby ponieść przedsiębiorstwo z powodu opóźnień w odprowadzaniu podatków? Jakie konsekwencje poniosłoby przedsiębiorstwo w przypadku niewypłacenia pracownikom wynagrodzenia w terminie i jak długo tacy pracownicy chcieliby dalej w nim pracować?

Co zatem z procesem odzyskiwania po awarii? Wdrażać go, czy nie wdrażać? Nie jest to już właściwe pytanie. Prawdziwe pytanie brzmi: jaki jest rzeczywisty koszt krótszego lub dłuższego braku dostępu do ważnych danych oraz natychmiastowej utraty budowanego przez lata zaufania?

Proces odzyskiwania po awarii nie może być już dłużej postrzegany jako kwestia poboczna lub element uwzględniany tylko w przypadku dostępności wystarczającego budżetu, ponieważ od współczesnych przedsiębiorstw oczekuje się szybkiej reakcji na awarie, aby ten sposób zapewnić ciągłość prowadzonej działalności. Zamiast zatem zniechęcać się kosztami wdrożenia planu zapewnienia odporności, przedsiębiorstwo musi oszacować koszty braku takiego planu. W tym celu może na przykład przeanalizować umowy dotyczące poziomu usług (SLA), które nie mogłyby nie zostać dotrzymane lub kary i utracone przychody wynikające z przestoju. Po porównaniu kosztów wdrożenia procesu DR z wysokością kar i utraconych przychodów oraz utraconym zaufaniem klientów wybór staje się oczywisty.

Ten obraz jest zatytułowany „Przychody, produktywność i utracona lojalność”. Widnieją na nim trzy kluczowe wartości. Pochodzą one z przeprowadzonego w 2019 r. przez Forrester Consulting badania na zlecenie IBM. Postawione respondentom pytanie brzmiało: „Z którymi z poniższych kosztów ma do czynienia Państwa przedsiębiorstwo w związku z planowanymi i niezaplanowanymi przestojami”?
Wartość wyświetlona po lewej stronie oznacza, że 53% respondentów wskazało na utracone przychody. Wartość wyświetlona pośrodku oznacza, że 47% respondentów wskazało na utratę produktywności. Wartość wyświetlona po prawej stronie oznacza, że 41% respondentów wskazało na utratę kapitału lub zaufania do marki.

Niezaplanowane przestoje

Niezależnie od tego, czy awaria została spowodowana klęską żywiołową, błędami operatora/dostawcy usług IT, uszkodzeniem danych czy atakiem typu ransomware, przedsiębiorstwo musi być zdolne do zabezpieczenia się przed zakłóceniami prowadzonej działalności, które skutkują ogromnymi stratami, utratę reputacji i renomy oraz możliwością przejęcia klientów przez konkurencję.

Skutki te wydają się dramatyczne, odzwierciedlają jednak niedawne problemy wielu znanych przedsiębiorstw, które utraciły nie tylko duże ilości krytycznych danych transakcyjnych oraz informacji o klientach, ale również samo zaufanie klientów.

Działalność biznesową może zostać zakłócona na wiele różnych sposobów i z różnych przyczyn.

Ten obraz jest zatytułowany „Główne przyczyny niezaplanowanego przestoju”. Znajduje się na nim wykres słupkowy przedstawiający przyczyny niezaplanowanych przestojów. Wykres jest podzielony na trzy kategorie: awarie operacyjne, klęski żywiołowe i zdarzenia spowodowane przez człowieka. Kategoria awarii operacyjnych jest najbardziej na lewo, kategoria klęsk żywiołowych znajduje się pośrodku, a kategorię zdarzeń spowodowanych przez człowieka umieszczono najbardziej na prawo. Źródłem tego wykresu jest Forrester Research, Inc.

Zaplanowane przestoje

Proces odzyskiwania po awarii jako usługa (Disaster Recovery as a Service, DRaaS) w chmurze zapewnia przedsiębiorstwom niezrównaną elastyczność operacyjną. Przedsiębiorstwa częściej korzystają z rozwiązań DR w przypadku zaplanowanych przestojów niż w przypadku przestojów niezaplanowanych (spowodowanych jakąś katastrofą).

Typowe problemy

• Tradycyjne podejścia do procesu odzyskiwania po awarii wymagają inwestycji w mechanizmy automatyzacji.
• Przerwy w dostawie prądu mogą mieć wpływ nawet na systemy biznesowe w centrach przetwarzania danych warstwy 1. Jak często zdarza się, że zwykły incydent, taki jak przerwa w dostawie prądu, powoduje jedno- lub dwudniowy przestój? Pracownicy IT spędzają wówczas wiele godzin lub nawet dni na telekonferencjach, aby ponownie uruchomić systemy w ramach prowizorycznych rozwiązań. • Niektóre przedsiębiorstwa wydają znaczne części swoich budżetów informatycznych na przygotowanie wewnętrznych mechanizmów automatyzacji służących do zarządzania procesem odzyskiwania po awarii, ale nie chcą ich potem ani używać, ani nawet okresowo testować ich działania. • Często potrzeba nawet kilku dni, aby odzyskać dane po zaplanowanym oknie konserwacyjnym. • Nawet dobrze udokumentowane plany odzyskiwania po awarii (runbooki) mogą przewidywać wielodniową utratę możliwości pracy, mimo podejmowanych przez działy IT heroicznych działań zmierzających do przywrócenia systemów do stanu sprzed awarii.

Najważniejsze cele procesu odzyskiwania po awarii

Dwa podstawowe cele procesu odzyskiwania po awarii to jak najszybsze przywrócenie sprawności działania systemów dotkniętych awarią oraz jak ograniczenie do minimum ilości danych utraconych wskutek niezaplanowanego lub planowanego przestoju. Wspomniane cele można mierzyć za pomocą dwóch wskaźników: zakładanego czasu wznowienia funkcji (recovery time objective, RTO) oraz akceptowalnego poziomu utraty danych (recovery point objective, RPO).

Każdy system biznesowy będzie mieć inne wymagania co do tych wartości tych dwóch wskaźników w zależności od umowy SLA zawartej między działami IT a działami biznesowymi.

Ten obraz jest zatytułowany „Terminologia z zakresu ochrony danych”. Tolerancja na utratę danych i tolerancja na przestoje są przedstawione na linii prostej, która biegnie w przeciwnych kierunkach od środka obrazu. Po lewej stronie mamy kategorię „Utrata danych”, a po prawej — „Przestój”

Zakładany czas wznowienia funkcji

Zakładany czas wznowienia funkcji to czas potrzebny na przywrócenie systemu biznesowego do stanu pełnej sprawności po zaplanowanym lub niezaplanowanym przestoju.

Akceptowalny poziom utraty danych

Akceptowalny poziom utraty danych to maksymalna ilość danych, które mogą zostać utracone, zanim zaszkodzi to danemu systemowi biznesowemu. Wskaźnik RPO zazwyczaj mierzy różnicę w danych od momentu wykonania ostatniej kopii zapasowej, replikacji lub migawki.

Odtwarzanie po awarii a wysoka dostępność

Proces zapewnienia wysokiej dostępności (HA) tradycyjnie chroni przed pojedynczymi punktami awarii, natomiast proces odzyskiwania po awarii chroni przed wieloma punktami awarii. W chmurze obliczeniowej ochrona przed pojedynczymi punktami awarii w warstwie infrastruktury fizycznej, w tym zasilania, chłodzenia, przechowywania, sieci i fizycznych serwerów, jest całkowicie przeniesiona do ogólnej architektury poprzez domeny dostępności i błędów.

Proces zapewnienia wysokiej dostępności w tym przypadku jest skalowalny i bardzo odporny na utratę danych lub spadek wydajności przetwarzania. Niemal każdy dostawca chmury klasy korporacyjnej uwzględnia w niej zapewnienie wysokiej dostępności.

Rozwiązania DR o wysokiej dostępności, które zapewniają pełną ochronę baz danych przed utratą danych i przestojami, stają się kosztowne, gdy w grze pojawia się złożona technologia mapowania i replikacji danych. Rozwiązania te nie zapewniają ochrony przed atakami ransomware, którą można osiągnąć poprzez kompleksowe tworzenie kopii zapasowych z określonym magazynem niezmienialnym i akceptowalnym poziomem utraty danych.

Tradycyjne procesy zapewnienia wysokiej dostępności (HA) dobrze sprawdzają się w połączeniu z niedrogim chmurowym procesem DR (CDR). Dodatkowa technologia CDR zapewnia dodatkową warstwę ochrony dla baz, w przypadku których nie można utracić żadnych danych, nie są akceptowalne przestoje i nie można dopuścić do ataków ransomware, ale należy zapewnić długoterminowe przyrostowe wycofywanie danych (incremental rollback).

Zainstalowane lokalnie rozwiązania DR są mało elastyczne i drogie ze względu na wysokie koszty duplikacji infrastruktury IT w lokalizacji źródłowej i stałej lokalizacji docelowego centrum przetwarzania danych. Nie może korzystać z sieci rozległej ani migrować serwerów między rozproszonymi środowiskami, wymaga zatem wydzielonego połączenia między źródłowym i docelowym centrum przetwarzania danych, aby działać jak jedno zintegrowane środowisko LAN. Tradycyjne rozwiązanie DR nie może również migrować serwerów między rozproszonymi środowiskami heterogenicznymi, takimi jak środowisko lokalne i platforma chmurowa lub między dwiema różnymi platformami chmurowymi.

Usługi DRaaS korzystają z wielu zewnętrznych rozwiązań do tworzenia kopii zapasowych i obsługujących migrację narzędzi open source, aby stworzyć ściśle kontrolowane i bardzo specyficzne środowisko. Użytkownik końcowy może odzyskać obciążenia w tradycyjnym środowisku hostingowym dostawcy usług DRaaS tylko z poziomu swojego lokalnego środowiska rozwiązań VMware. Wspomniane rozwiązania zewnętrzne mogą być drogie i ograniczone pod względem chronionych obciążeń i obsługiwanych środowisk obliczeniowych.

Przepływy pracy, runbooki i plany dotyczące odzyskiwania po awarii

W terminologii Oracle przepływ pracy DR określa się zazwyczaj mianem planu DR. Plan odzyskiwania po awarii (inaczej runbook) to lista z góry określonych kroków lub zadań, które należy wykonać, aby przenieść instancję obliczeniową, platformę, bazę danych i aplikacje do wcześniej określonego regionu odzyskiwania w chmurze. Są to m.in. wszystkie wykonywane przez człowieka lub komputery w ramach procesu odzyskiwania po awarii zadania lub kroki, takie jak przełączanie lub przełączanie awaryjne. Terminy „plan DR”, „runbook DR” i „przepływ pracy DR” są stosowane zamiennie.

Operacje DR (przełączanie a przełączanie awaryjne)

Odzyskiwanie po awarii to proces polegający na wykonaniu każdego z ustalonych wcześniej w planie DR kroku lub zadania wymaganego do przywrócenia infrastruktury, bazy danych i aplikacji do stanu pełnej sprawności. Do opisu przeniesienia aplikacji do innej lokalizacji używa się dwóch różnych terminów: przełączanie awaryjne i przełączanie.

Przełączanie awaryjne (failover)

Przełączanie awaryjne implikuje pojawienie się niezaplanowanego przestoju, w związku z którym aplikacje, bazy danych i maszyny wirtualne uległy awarii, a wszystkie zasoby, w tym pamięć masowa, dane i systemy operacyjne gości, znajdują się w niespójnym stanie. W takim przypadku zakłada się, że podstawowy region chmury jest całkowicie niedostępny, co wskazuje na konieczność uruchomienia prawdziwego procesu odzyskiwania po awarii.

Wszystkie określone w planie DR zadania dotyczące odzyskiwania po awarii mogą być zatem wykonywane tylko w rezerwowym regionie chmury. Istotne jest przy tym, aby usługi DRaaS zapewniały wysoką dostępność w takim regionie rezerwowym, aby na wypadek awarii był on dostępny i działał sprawnie.

Przełączanie (switchover)

Przełączanie implikuje istnienie zaplanowanego przestoju, który polega na uporządkowanym wyłączeniu aplikacji, baz danych, maszyn wirtualnych lub serwerów. W takim przypadku zarówno region podstawowy, jak i rezerwowy działają normalnie, a dział IT prawdopodobnie skupia się na przenoszeniu systemów między tymi regionami w celu przeprowadzenia prac konserwacyjnych lub dokończenia aktualizacji.

Strategia wdrożenia chmury

Nowoczesne przedsiębiorstwa mogą korzystać z co najmniej jednego z poniższych modeli wdrażania chmury z różnych względów, w tym ze względu na koszty, wydajność i wymagania dotyczące ciągłości działania. Szeroko zakrojona strategia wdrażania chmury staje się coraz bardziej powszechna, ponieważ przedsiębiorstwa nadal przenoszą swoje operacje do chmury.

Międzyregionalne rozwiązania DR

Międzyregionalne rozwiązania DR służą do ochrony przedsiębiorstw przed całkowitymi przestojami, które ograniczałyby dostęp do systemów biznesowych w infrastrukturze chmurowej jednego dostawcy usług chmurowych. Jak sama nazwa wskazuje, wszystkie aplikacje z danego systemu biznesowego, w tym maszyny wirtualne, bazy danych i inne aplikacje, mogą zostać na żądanie przeniesione do całkowicie innego regionu chmury w innej lokalizacji geograficznej.

Usługi DRaaS powinny być zdolne do przeniesienia całego systemu przedsiębiorstwa, w tym portalu kadrowego, portalu finansowego lub aplikacji do zarządzania zasobami przedsiębiorstwa, do całkowicie innego regionu chmury. Ponadto usługi DRaaS powinny być zdolne do zrealizowania celów w zakresie czasu wznowienia i akceptowalnego poziomu utraty danych (wymaganych przez umowy SLA dla poszczególnych aplikacji).

Międzyregionalne rozwiązania DR takie jak Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery chronią aplikacje przedsiębiorstw przed utratą dostępu do całego regionu chmury, w tym przed utratą wszystkich domen dostępności w takim regionie.

Rozwiązania DR w chmurze hybrydowej

Rozwiązania DR w chmurze hybrydowej to bardzo popularne i pozwalają przedsiębiorstwom na przenoszenie obciążeń roboczych i maszyn wirtualnych z własnych centrów przetwarzania danych do infrastruktury chmurowej. Chmura hybrydowa bywa często używana w charakterze rozwiązania DR na potrzeby ochrony danych i działania krytycznych systemów biznesowych przedsiębiorstwa.

Dla klientów Oracle chmura hybrydowa to luźna konfederacja między infrastrukturą OCI a serwerami fizycznymi, urządzeniami chmury Oracle lub innymi systemami w fizycznym centrum przetwarzania danych. Urządzenia chmurowe Oracle, takie jak Oracle Private Cloud Appliance X9-2 i Oracle Exadata Cloud@Customer, to doskonałe przykłady systemów instalowanych lokalnie, które można dobrze zintegrować z OCI.

Niektóre produkty partnerów Oracle, takie jak Rackware, mogą być użyte w postaci rozwiązania DR obejmującego infrastrukturę lokalną i OCI. Oprogramowanie Rackware można nabyć w sklepie Oracle Cloud Marketplace.

Wielochmurowe rozwiązania DR

Wielochmurowe rozwiązania DR chronią aplikacje i dane dzięki rozłożeniu różnych komponentów stosu aplikacji w infrastrukturach chmurowych co najmniej dwóch dostawców chmur. Dobrym przykładem jest tutaj partnerstwo Oracle i Microsoft (Microsoft Azure)

Usługi DRaaS powinny być zdolne do obsługi międzyregionalnych rozwiązań DR, wielochmurowych rozwiązań DR oraz rozwiązań DR w chmurze hybrydowej. Infrastruktura OCI może udostępniać usługi DRaaS na potrzeby międzyregionalnych rozwiązań DR oraz rozwiązań DR w chmurze hybrydowej.

Spójność danych w bazach danych

Efektywne rozwiązania DR dla baz danych powinny zawsze obejmować środki zapewniające spójność danych. Punkt, do którego można odzyskać taką bazę przy zapewnieniu pełnej spójności danych, w tym bieżących transakcji, określa akceptowalny poziom utraty danych.

Spójność danych jest znacznie mniejszym problemem w przypadku bezserwerowych lub prostych baz danych, ale odzyskanie zaawansowanych relacyjnych baz danych, takich jak Oracle Database lub MySQL, do danego punktu w czasie jest procesem bardzo złożonym, choć wciąż bardzo istotnym.

Rozwiązania DR dla baz danych MySQL

W przypadku używania usług MySQL Database Service w infrastrukturze OCI system bazy danych MySQL jest logicznym kontenerem dla co najmniej jednej instancji MySQL. Ponadto zapewnia interfejs na potrzeby zarządzania takimi zadaniami, jak przydzielanie zasobów, automatyczne tworzenie kopii zapasowych oraz odzyskiwanie danych do określonego punktu w czasie.

Technologie dziennika binarnego MySQL i natywnej replikacji pozwalają na odzyskiwanie danych do danego punktu w czasie, zapewnienie wysokiej dostępności i odzyskiwanie po awarii. Usługa MySQL Group Replication jest powszechnie używana do tworzenia odpornych na błędy klastrów lokalnych o wysokiej dostępności, podczas gdy funkcje replikacji asynchronicznej MySQL są zazwyczaj stosowane na potrzeby procesu odzyskiwania po awarii.

System bazodanowy z włączoną funkcją zapewnienia wysokiej dostępności ma trzy instancje MySQL rozmieszczone w różnych domenach dostępności lub domenach błędów. System taki gwarantuje, że w przypadku awarii jednej instancji, druga przejmie jej zadania przy zerowej utracie danych i minimalnym czasie przestoju. Na potrzeby procesu odzyskiwania po awarii w różnych regionach można również utworzyć kanały przychodzących replikacji między dwoma systemami baz danych.

Więcej informacji na temat rozwiązań DR dla systemu MySQL w chmurze można znaleźć za pośrednictwem poniższych łączy.

• Zapewnienie ciągłości działania baz danych MySQL
• Zapewnienie wysokiej dostępności baz danych MySQL
• Replikacja przychodząca w bazach danych MySQL

Rozwiązania DR dla baz danych Oracle

Oracle Maximum Availability Architecture (MAA) udostępnia najlepsze praktyki dotyczące architektury, konfiguracji i cyklu życia baz danych Oracle, umożliwiając uzyskanie wysokiego poziomu dostępności usług baz danych zainstalowanych lokalnie, w chmurze lub mających postać hybrydową.

Więcej informacji na temat rozwiązania Oracle Maximum Availability Architecture do odzyskiwania po awarii w chmurze można znaleźć za pośrednictwem poniższych łączy.

• Oracle Maximum Availability Architecture — strona startowa
• Oracle Maximum Availability Architecture — architektury referencyjne
• Oracle Maximum Availability Architecture — najlepsze praktyki dla Oracle Fusion Middleware
• Oracle Maximum Availability Architecture — najlepsze praktyki dla aplikacji

Chmurowe architektury wdrożeniowe

Architektura wdrożeniowa opisuje, w jaki sposób różne elementy, takie jak obliczenia, platforma/baza danych i aplikacje, są rozmieszczane w poszczególnych regionach chmury, aby stworzyć odporny system pozwalający na odzyskanie danych po całkowitej awarii centrum przetwarzania danych. Architektura taka opisuje lokalizację wszystkich elementów podczas zwykłego działania pakietu aplikacji oraz elementy, które muszą zostać odzyskane w regionie rezerwowym, aby wszystko znowu mogło działać dobrze.

Zdaniem Oracle usługi DRaaS powinny cechować się elastycznością pozwalającą na obsługę dowolnych kombinacji architektur wdrożeniowych dla rozwiązań DR w celu spełnienia indywidualnych wymagań dotyczących poziomu usług dla poszczególnych systemów biznesowych. Dostawcy chmur powinni oferować swoim klientom swobodę wyboru opisanych powyżej rozwiązań, aby klienci ci mogli dotrzymywać zobowiązań w zakresie poziomów usług świadczonych w ramach swoich systemów biznesowych.

Do opisu strategii odzyskiwania po awarii i architektur wdrożeniowych stosuje się wiele terminów. Niemniej jednak te różne podejścia i wzorce opisujące sposób wdrażania infrastruktury, platformy i aplikacji DR można podzielić na dwie szerokie kategorie strategiczne: aktywna/aktywna i aktywna/rezerwowa.

W poniższej tabeli przedstawiono typowe terminy używane do opisania różnych architektur wdrażania w ramach dwóch szeroko rozumianych strategii DR.

Strategia	Architektura wdrożeniowa	RPO	RTO
aktywna/rezerwowa	zimna rezerwa	godziny	godziny
aktywna/rezerwowa	czuwanie	minuty	godziny
aktywna/rezerwowa	ciepła rezerwa	sekundy	godziny
aktywna/rezerwowa	gorąca rezerwa	sekundy	minuty
aktywna/aktywna	aktywna/aktywna	bliski zeru	bliski zeru

W tej sekcji podjęto próbę wyjaśnienia niektórych odmian podejścia aktywna/aktywna i aktywna/rezerwowa do procesu odzyskiwania po awarii. Obie te strategie odzyskiwania danych po awarii służą zapewnieniu ciągłości działania.

Architektura wdrożeniowa aktywna/rezerwowa

Istnieje wiele odmian architektury wdrożeniowej aktywna/rezerwowa. Architekturze aktywnej/rezerwowej, czasami nazywanej aktywną/pasywną, często towarzyszą określenia czuwanie (pilot light), zimna rezerwa (cold standby), ciepła rezerwa (warm standby) i gorąca rezerwa (hot standby).

Określenia te dotyczą w sumie tego samego motywu, w którym 100% aplikacji działa w regionie podstawowym, podczas gdy mniej niż 100% tych aplikacji działa aktywnie w regionie rezerwowym.

Na poniższych diagramach ogólnych przedstawiono kilka podstawowych różnic między typowymi architekturami wdrożeniowymi, ale nie są to architektury referencyjne. Nie opisano tu również sposobu wdrożenia procesu DR dla stosu aplikacji.

zimna rezerwa

W tym przypadku maszyny wirtualne (VM), baza danych i aplikacje znajdują się tylko w bieżącym regionie podstawowym. Grupy wolumenów pamięci masowej plików i bloków zawierające dysk rozruchowy i wszelkie inne dyski wirtualne dla każdej maszyny wirtualnej są replikowane do regionu rezerwowego.

Pokazuje obraz z regionem podstawowym po lewej stronie i regionem rezerwowym po prawej stronie. Region podstawowy składa się z trzech bloków (aplikacja, baza danych i infrastruktura) i w każdym z nich znajdują się odpowiednie ikony. W obu regionach u góry znajduje się ikona przedstawiająca moduł równoważenia obciążenia. Ikona modułu równoważenia obciążenia w regionie rezerwowym ma jaśniejszy odcień odpowiednia ikona w regionie podstawowym. Region rezerwowy składa się z trzech bloków: aplikacja, baza danych i infrastruktura. W regionie rezerwowym ikony są tylko w bloku infrastruktury (po jednej dla magazynu obiektów, magazynu blokowego i magazynu plików). W regionie rezerwowym bloki bazy danych i aplikacji są puste. Między dwoma blokami infrastruktury widoczne są dwie strzałki reprezentujące replikację magazynu obiektów i replikację magazynu. Strzałki te przedstawiają replikację z regionu podstawowego do regionu rezerwowego.

Podczas operacji odzyskiwania po awarii, takiej jak przełączenie lub przełączenie awaryjne, zreplikowany magazyn zawierający te same maszyny wirtualne jest aktywowany w regionie rezerwowym, a dokładnie te same maszyny wirtualne są ponownie uruchamiane w miejscu, w którym zostały zatrzymane lub uległy awarii. Maszyny wirtualne to dokładnie te same maszyny, które wcześniej były uruchomione w aktywnym regionie.

Ta architektura wdrożeniowa ma kilka zalet obejmujących niższe koszty wdrożenia, niższe koszty ogólne utrzymania i niższe koszty operacyjne. Może to jednak nie być najlepsze rozwiązanie dla aplikacji opartych na relacyjnych bazach danych do obsługi systemów zaplecza, ponieważ jedynym sposobem zapewnienia spójności danych jest w takim przypadku okresowe wykonywanie zimnych kopii zapasowych. Takie podejście sprawdza się w przypadku aplikacji, w przypadku których dopuszczalne są krótkie, sporadyczne przestoje.

Większość operacji IT rozwiązuje ten problem poprzez okresowe wyłączenie bazy danych, wykonanie migawki magazynu blokowego, a następnie wznowienie zwykłych operacji. W ten sposób definiuje się akceptowalny poziom utraty danych, ponieważ system można przywrócić tylko do punktu, w którym została wykonana kopia zapasowa.

W tej architekturze czas odzyskiwania danych będzie nieco dłuższy i istnieje znacznie większe ryzyko utraty danych, ale jest to rozsądne rozwiązanie w przypadku odpowiedniego obciążenia. Na przykład może to być idealne rozwiązanie w przypadku aplikacji opartych na prostej bazie danych, opartych na bezserwerowej bazie danych lub w ogóle nieużywających bazy danych lub dla klientów, którzy po prostu chcą przenosić maszyny wirtualne między regionami w celu uzyskania większej elastyczności.

Przykładowe przepływy pracy DR dla tej architektury wdrożeniowej

W poniższych dwóch scenariuszach przedstawiono, w jaki sposób może przebiegać proces realizacji operacji DR dla wdrożeń z zimną rezerwą.

W przypadku przełączenia zarówno w regionie podstawowym, jak i rezerwowym wykonywane są następujące zadania:

• Aplikacje podstawowe są przełączane w stan spoczynku.
• Podstawowe bazy danych są przełączane w stan spoczynku i synchronizowane z regionem rezerwowym.
• Podstawowe maszyny wirtualne są zatrzymywane.
• Podstawowy magazyn jest synchronizowany z regionem rezerwowym.
• Zreplikowany magazyn jest uruchamiany w trybie online, replikacja jest cofana, a w regionie rezerwowym magazyn ten jest już magazynem podstawowym.
• Zreplikowane kopie podstawowych maszyn wirtualnych są uruchamiane, a wszystkie aplikacje systemowe lub narzędzia wymagane przez stos aplikacji są włączane i w regionie rezerwowym są już aplikacjami lub narzędziami podstawowymi.
• Zreplikowane kopie podstawowych baz danych są odzyskiwane w regionie rezerwowym przy użyciu najnowszej zimnej kopii zapasowej lub dzienników transakcji i dzienników ponownego wykonania z replikowanego magazynu.
• Zreplikowane kopie podstawowych baz danych są uruchamiane i instalowane i są już podstawowymi bazami danych w regionie rezerwowym.
• Zreplikowane kopie podstawowych aplikacji są uruchamiane i walidowane i są teraz podstawowymi aplikacjami w regionie rezerwowym.
• Dokonywane są wszelkie zmiany w bazie danych DNS i modułach równoważenia obciążenia, aby umożliwić dostęp do aplikacji przez sieć publiczną.

W przypadku przełączenia awaryjnego w wyłącznie regionie rezerwowym wykonywane są następujące zadania:

• Zreplikowany magazyn jest uruchamiany w trybie online, replikacja jest cofana, a w regionie rezerwowym magazyn ten jest już magazynem podstawowym.
• Zreplikowane kopie podstawowych maszyn wirtualnych są uruchamiane, a wszystkie aplikacje systemowe lub narzędzia wymagane przez stos aplikacji są włączane i w regionie rezerwowym są już aplikacjami lub narzędziami podstawowymi.
• Zreplikowane kopie podstawowych baz danych są odzyskiwane w regionie rezerwowym przy użyciu najnowszej zimnej kopii zapasowej lub dzienników transakcji i dzienników ponownego wykonania z replikowanego magazynu.
• Zreplikowane kopie podstawowych baz danych są uruchamiane i instalowane i są już podstawowymi bazami danych w regionie rezerwowym.
• Zreplikowane kopie podstawowych aplikacji są uruchamiane i walidowane i są teraz podstawowymi aplikacjami w regionie rezerwowym.
• Dokonywane są wszelkie zmiany w bazie danych DNS i modułach równoważenia obciążenia, aby umożliwić dostęp do aplikacji przez sieć publiczną.

ciepła rezerwa

W tym scenariuszu maszyny wirtualne znajdują się zarówno w regionie podstawowym, jak i w regionie rezerwowym, ale są od siebie całkowicie niezależne i mają własne niepowtarzalne nazwy hostów oraz wstępnie przypisane adresy IP. Maszyny wirtualne w regionie rezerwowym mogą być zatrzymane lub uruchomione w zależności od preferencji klienta.

Pokazuje obraz z regionem podstawowym po lewej stronie i regionem rezerwowym po prawej stronie. Region podstawowy składa się z trzech bloków (aplikacja, baza danych i infrastruktura) i w każdym z nich znajdują się odpowiednie ikony. W obu regionach u góry znajduje się ikona przedstawiająca moduł równoważenia obciążenia. Ikona modułu równoważenia obciążenia w regionie rezerwowym ma jaśniejszy odcień odpowiednia ikona w regionie podstawowym. Region rezerwowy składa się z trzech bloków: aplikacja, baza danych i infrastruktura. W regionie rezerwowym w bloku infrastruktury znajdują się ikony (po jednej dla magazynu obiektów, magazynu blokowego i magazynu plików). W bloku infrastruktury jest też ikona dla maszyn wirtualnych, ale ma ona jaśniejszy odcień. Ikony bazy danych i ikona aplikacji w regionie rezerwowym również mają jaśniejszy odcień. Między dwoma blokami infrastruktury widoczne są dwie strzałki reprezentujące replikację magazynu obiektów i replikację magazynu. Strzałki te przedstawiają replikację z regionu podstawowego do regionu rezerwowego.

Bazy danych powinny być uruchomione zarówno w regionie podstawowym, jak i w regionie rezerwowym.

W przypadku baz danych Oracle zalecamy użycie Oracle Data Guard na potrzeby replikacji podstawowej i rezerwowej bazy danych. Więcej informacji na ten temat można znaleźć tutaj.

Do synchronizacji regionów podstawowych i rezerwowych w bazach danych innych niż Oracle zostaną zastosowane odpowiednie natywne technologie replikacji.

Aplikacje istnieją również w rezerwowym regionie chmury, ale nie są ani uruchomione, ani dostępne.

Przykładowe przepływy pracy DR dla tej architektury wdrożeniowej

W poniższych dwóch scenariuszach przedstawiono, w jaki sposób może przebiegać proces realizacji operacji DR dla wdrożeń z ciepłą rezerwą.

W przypadku przełączenia zarówno w regionie podstawowym, jak i rezerwowym wykonywane są następujące zadania:

• Aplikacje podstawowe są przełączane w stan spoczynku.
• Podstawowe bazy danych są przełączane w stan spoczynku i synchronizowane z regionem rezerwowym.
• Podstawowe maszyny wirtualne są zatrzymywane.
• Podstawowy magazyn jest synchronizowany z regionem rezerwowym.
• Zreplikowany magazyn jest uruchamiany w trybie online, replikacja jest cofana, a w regionie rezerwowym magazyn ten jest już magazynem podstawowym.
• Rezerwowe maszyny wirtualne (o ile nie zostały już uruchomione) oraz wszelkie aplikacje lub narzędzia systemowe wymagane przez stos aplikacji są uruchamiane i są już podstawowymi elementami w regionie rezerwowym.
• Rezerwowe bazy danych są przełączane na pełny dostęp do odczytu/zapisu i są już podstawowymi bazami danych w regionie rezerwowym.
• Aplikacje rezerwowe są uruchamiane i walidowane i są teraz aplikacjami podstawowymi w regionie rezerwowym.
• Dokonywane są wszelkie zmiany w bazie danych DNS i modułach równoważenia obciążenia, aby umożliwić dostęp do aplikacji przez sieć publiczną.

W przypadku przełączenia awaryjnego w wyłącznie regionie rezerwowym wykonywane są następujące zadania:

• Zreplikowany magazyn jest uruchamiany w trybie online, replikacja jest w miarę możliwości cofana, a w regionie rezerwowym magazyn ten jest już magazynem podstawowym.
• Rezerwowe maszyny wirtualne (o ile nie zostały już uruchomione) oraz wszelkie aplikacje lub narzędzia systemowe wymagane przez stos aplikacji są uruchamiane i są już podstawowymi elementami w regionie rezerwowym.
• Rezerwowe bazy danych są odzyskiwane przy użyciu najnowszych dzienników transakcji i dzienników powtórzeń z replikowanego magazynu.
• Rezerwowe bazy danych są przełączane na pełny dostęp do odczytu/zapisu i są już podstawowymi bazami danych w regionie rezerwowym.
• Aplikacje rezerwowe są uruchamiane i walidowane i są teraz aplikacjami podstawowymi w regionie rezerwowym.
• Dokonywane są wszelkie zmiany w bazie danych DNS i modułach równoważenia obciążenia, aby umożliwić dostęp do aplikacji przez sieć publiczną.

gorąca rezerwa

W tym scenariuszu maszyny wirtualne istnieją i są uruchamiane zarówno w regionie podstawowym, jak i w regionie rezerwowym z własnymi niepowtarzalnymi nazwami hostów i wstępnie przypisanymi adresami IP.

Pokazuje obraz z regionem podstawowym po lewej stronie i regionem rezerwowym po prawej stronie. Region podstawowy składa się z trzech bloków (aplikacja, baza danych i infrastruktura) i w każdym z nich znajdują się odpowiednie ikony. W obu regionach u góry znajduje się ikona przedstawiająca moduł równoważenia obciążenia. Ikona modułu równoważenia obciążenia w regionie rezerwowym ma jaśniejszy odcień odpowiednia ikona w regionie podstawowym. Region rezerwowy składa się z trzech bloków: aplikacja, baza danych i infrastruktura. Zarówno region podstawowy, jak i region rezerwowy mają ikony w blokach aplikacji, bazy danych i infrastruktury. W bloku infrastruktury są ikony maszyny wirtualnej, magazynu plików, magazynu obiektów i magazynu bloków zarówno w regionie podstawowym, jak i w regionie rezerwowym. Jedynie ikony baz danych w regionie rezerwowym mają jaśniejszy odcień. Między dwoma blokami infrastruktury widoczne są dwie strzałki reprezentujące replikację magazynu obiektów i replikację magazynu. Strzałki te przedstawiają replikację z regionu podstawowego do regionu rezerwowego.

Bazy danych powinny być uruchomione zarówno w regionie podstawowym, jak i w regionie rezerwowym.

W przypadku baz danych Oracle zalecamy użycie Oracle Data Guard na potrzeby replikacji podstawowej i rezerwowej bazy danych. Więcej informacji na ten temat można znaleźć tutaj.

Do synchronizacji regionów podstawowych i rezerwowych w bazach danych innych niż Oracle zostaną zastosowane odpowiednie natywne technologie replikacji.

Aplikacje działają w regionie rezerwowym chmury, ale nie są dostępne za pośrednictwem sieci publicznej.

Przykładowe przepływy pracy DR dla tej architektury wdrożeniowej

W poniższych dwóch scenariuszach przedstawiono potencjalny sposób przebiegu procesu odzyskiwania po awarii dla wdrożeń z gorącą rezerwą.

W przypadku przełączenia zarówno w regionie podstawowym, jak i rezerwowym wykonywane są następujące zadania:

• Aplikacje podstawowe są przełączane w stan spoczynku.
• Podstawowe bazy danych są przełączane w stan spoczynku i synchronizowane z regionem rezerwowym.
• Podstawowe maszyny wirtualne są zatrzymywane.
• Podstawowy magazyn jest synchronizowany z regionem rezerwowym.
• Zreplikowany magazyn jest uruchamiany w trybie online, replikacja jest cofana, a w regionie rezerwowym magazyn ten jest już magazynem podstawowym.
• Rezerwowe maszyny wirtualne są już uruchomione a wszelkie aplikacje lub narzędzia systemowe wymagane przez stos aplikacji są uruchamiane i są już podstawowymi elementami w regionie rezerwowym.
• Rezerwowe bazy danych są przełączane na pełny dostęp do odczytu/zapisu i są już podstawowymi bazami danych w regionie rezerwowym.
• Aplikacje rezerwowe są uruchamiane i walidowane i są teraz aplikacjami podstawowymi w regionie rezerwowym.
• Dokonywane są wszelkie zmiany w bazie danych DNS i modułach równoważenia obciążenia, aby umożliwić dostęp do aplikacji przez sieć publiczną.

W przypadku przełączenia awaryjnego w wyłącznie regionie rezerwowym wykonywane są następujące zadania:

• Zreplikowany magazyn jest uruchamiany w trybie online, replikacja jest w miarę możliwości cofana, a w regionie rezerwowym magazyn ten jest już magazynem podstawowym.
• Rezerwowe maszyny wirtualne (o ile nie zostały już uruchomione) oraz wszelkie aplikacje lub narzędzia systemowe wymagane przez stos aplikacji są uruchamiane i są już podstawowymi elementami w regionie rezerwowym.
• Rezerwowe bazy danych są odzyskiwane przy użyciu najnowszych dzienników transakcji i dzienników powtórzeń z replikowanego magazynu.
• Rezerwowe bazy danych są przełączane na pełny dostęp do odczytu/zapisu i są już podstawowymi bazami danych w regionie rezerwowym.
• Aplikacje rezerwowe są uruchamiane i walidowane i są teraz aplikacjami podstawowymi w regionie rezerwowym.
• Dokonywane są wszelkie zmiany w bazie danych DNS i modułach równoważenia obciążenia, aby umożliwić dostęp do aplikacji przez sieć publiczną.

Architektura wdrożeniowa aktywna/aktywna

W tym scenariuszu cały stos aplikacji jest w pełni funkcjonalny i obsługuje obciążenie zarówno w regionie podstawowym, jak i w regionie rezerwowym.

Pokazuje obraz z regionem podstawowym po lewej stronie i regionem rezerwowym po prawej stronie. Regiony podstawowy i rezerwowy składają się każdy z trzech bloków (aplikacja, baza danych i infrastruktura) i w każdym z nich znajdują się odpowiednie ikony. W obu regionach u góry znajduje się ikona przedstawiająca moduł równoważenia obciążenia. Żadna z nich nie jest wyszarzona. Ikony w blokach aplikacji, bazy danych i infrastruktury zarówno w regionie podstawowym, jak i w regionie rezerwowym są wyświetlane w odpowiednim kolorze. Między dwoma blokami infrastruktury widoczna jest strzałka przedstawiająca opcjonalną replikację pamięci masowej. Strzałka ta biegnie od regionu podstawowego do regionu rezerwowego.

Bazy danych powinny być uruchomione zarówno w regionie podstawowym, jak i w regionie rezerwowym.

W przypadku baz danych Oracle zalecamy używanie oprogramowania Oracle GoldenGate do konfigurowania aplikacji w modelu aktywna/aktywna. Ponadto zalecamy utrzymywanie lokalnych rezerwowych baz danych w każdym regionie przy pomocy oprogramowania Oracle Data Guard, aby uzyskać niemal zerową wartość wskaźników RTO i RPO. Więcej informacji na ten temat można znaleźć tutaj.

Do synchronizacji regionów podstawowych i rezerwowych w bazach danych innych niż Oracle zostaną zastosowane odpowiednie natywne technologie replikacji i modele aktywna/aktywna.

Aplikacje są uruchomione i dostępne w sieci publicznej w regionie chmury rezerwowej i mają uruchomione obciążenie robocze.

Automatyzacja zadań związanych z odzyskiwaniem po awarii za pomocą usługi DRaaS

W swoich produktach, a zwłaszcza w większości swoich baz danych i aplikacji klasy korporacyjnej, Oracle stosuje mechanizmy zapewnienia wysokiej dostępności oraz często przygotowuje najlepsze praktyki i architektury wdrożeniowe pozwalające na odzyskiwanie po awarii zarówno w środowisku tradycyjnym, jak i w środowisku chmurowym. Każda linia produktów opracowuje własne podejście DR do swoich aplikacji, które obejmuje luźno powiązane kroki mające na celu odzyskanie wszystkich komponentów potrzebnych do obsługi danej aplikacji.

Chmurowa usługa DRaaS pozwala na połączenie wszystkich luźno powiązanych kroków opracowanych przez programistów, architektów chmur i architektów produktów w jeden, płynny przepływ pracy, który można zainicjować jednym kliknięciem. Infrastruktura OCI oferuje elastyczną, wysoce skalowalną i rozszerzalną usługę DRaaS pod nazwą Full Stack Disaster Recovery.

OCI Full Stack Disaster Recovery pozwala na zarządzanie przeniesieniami infrastruktury, baz danych i aplikacji między regionami OCI z dowolnego miejsca na świecie za pomocą jednego kliknięcia. Klienci mogą wdrażać środowiska DR bez konieczności przeprojektowywania lub przenoszenia istniejących infrastruktur, baz danych lub aplikacji, co jednocześnie eliminuje konieczność korzystania ze specjalistycznych serwerów służących do zarządzania lub konwersji.

• Dowiedz się więcej o rozwiązaniu OCI Full Stack Disaster Recovery
• Dowiedz się więcej o odzyskiwaniu po awarii w infrastrukturze OCI