Full Stack Disaster Recovery — często zadawane pytania

Informacje ogólne

1. Do czego służy usługa Oracle Cloud Infrastructure Full Stack Disaster Recovery?

Usługa Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery umożliwia orkiestrację procesu przenoszenia zasobów obliczeniowych, baz danych i aplikacji między regionami OCI na całym świecie za pomocą jednego kliknięcia. Klienci mogą zautomatyzować kroki niezbędne do odzyskania dowolnej liczby systemów biznesowych bez konieczności przeprojektowywania lub zmiany architektury istniejącej infrastruktury, baz danych lub aplikacji i bez konieczności posiadania specjalistycznych serwerów zarządzania lub konwersji.

2. Gdzie usługa OCI Full Stack DR jest obecnie dostępna?

Usługa OCI Full Stack DR jest dostępna w regionach komercyjnych OCI, regionach administracji rządowej Zjednoczonego Królestwa, regionach suwerennych UE, regionach Oracle Alloy i regionach dedykowanych dla OCI. Pełną listę dostępności usług można znaleźć tutaj. Proces wdrażania w regionach chmury Oracle US Government Cloud i Oracle US Defense Cloud jest nadal w toku. Więcej informacji na temat regionów OCI, w tym przestrzeni OCI i ich konkretnych lokalizacji, można znaleźć tutaj.

3. Czy usługa OCI Full Stack DR może obsługiwać odzyskiwanie po awarii w środowiskach lokalnych, hybrydowych i wielochmurowych?

OCI Full Stack Disaster Recovery obecnie obsługuje zasoby dostępne w regionach OCI, przy czym zasoby muszą znajdować się w ramach tej samej dzierżawy. Full Stack DR wspiera ofertę rozwiązań Oracle Database@Azure, co oznacza, że przejścia ról na poziomie bazy danych mogą być obsługiwane tylko przy użyciu usługi Full Stack DR. Zdolność do obsługi funkcji przywracania awaryjnego (DR) w środowiskach lokalnych, hybrydowych i wielochmurowych będzie rozwijana. Planujemy rozszerzyć funkcjonalność usługi OCI Full Stack DR o te środowiska, aby udostępniać kompleksowe rozwiązanie do odzyskiwania danych po awarii, obejmujące szerszy zakres zastosowań.

4. Czy rozwiązanie Full Stack DR obsługuje przywracanie awaryjne między różnymi dzierżawami?

Nie. Rozwiązanie Full Stack DR używa innych usług OCI na potrzeby przywracania awaryjnego. Bardzo niewiele usług OCI obsługuje replikację lub udostępnianie danych między dzierżawami, co oznacza, że rozwiązanie Full Stack DR nie może obsługiwać przywracania awaryjnego między dzierżawami, dopóki wszystkie usługi OCI nie będą obsługiwać takiego udostępniania. Uwaga: W usługach Amazon Web Services znaczenie terminu „dzierżawa” (tenancy) jest inne niż w przypadku usług OCI. Na przykład w przypadku rozwiązania AWS Elastic Disaster Recovery za dzierżawę uznaje się platformę sprzętową hostującą maszyny wirtualne. Full Stack DR w pełni obsługuje przywracanie awaryjne między różnymi platformami sprzętowymi, takimi jak platformy współdzielone i dedykowane hosty wirtualne.

4. Czy rozwiązanie OCI Full Stack DR obsługuje przywracanie awaryjne między regionami?

Tak. OCI Full Stack DR obsługuje zasoby wdrożone w różnych regionach. Oracle zaleca skonfigurowanie funkcji przywracania awaryjnego we wszystkich regionach, aby zapewnić lepszą ochronę przed błędami, realne zdolności przywracania awaryjnego, zgodność z wymogami regulacyjnymi oraz lepsze poziomy ciągłości działania. W regionach z tylko jedną domeną dostępności (AD) trzeba skonfigurować infrastrukturę przywracania awaryjnego w innym regionie. Listę regionów z jedną domeną dostępności można znaleźć w dokumentacji w sekcji Obszary dostępności infrastruktury Oracle Cloud Infrastructure.

6. Czy rozwiązanie OCI Full Stack DR obsługuje przywracanie awaryjne między domenami dostępności?

Tak. OCI Full Stack DR obsługuje zasoby wdrożone w wielu domenach dostępności. Listę regionów z trzeba domenami dostępności można znaleźć w dokumentacji w sekcji Obszary dostępności infrastruktury Oracle Cloud Infrastructure.

7. Czy po wdrożeniu usługi OCI Full Stack DR trzeba zarządzać dodatkową infrastrukturą?

Nie. Usługa OCI Full Stack DR jest usługą świadczoną w ramach pełnego outsourcingu.

8. Czy usłudze OCI Full Stack Disaster Recovery towarzyszą umowy o poziom usług (SLA)?

Tak. W przypadku usługi OCI Full Stack DR zawierane są umowy SLA dotyczące dostępności i wydajności. Więcej informacji na ten temat można znaleźć tutaj.

9. Jak uzyskać dostęp do usługi OCI Full Stack Disaster Recovery?

Dostęp do usługi OCI Full Stack DR można uzyskać za pośrednictwem konsoli Oracle Cloud Infrastructure (interfejs oparty na przeglądarce), interfejsów API REST, zestawów SDK Oracle Cloud Infrastructure, interfejsu wiersza poleceń i narzędzi DevOps.

10. Czy usługa OCI Full Stack DR obsługuje dowolne obciążenia robocze?

Tak. Usługa OCI Full Stack DR obsługuje operacje wykonywane zarówno w środowisku Oracle, jak i w środowiskach innych niż Oracle.

11. Czy można tworzyć plany DR w regionie podstawowej grupy chronionej usługą DR?

Nie. Usługę Full Stack DR zaprojektowano tak, że umożliwia tworzenie planów DR tylko w regionie rezerwowej grupy chronionej usługą DR. Zdecydowanie zaleca się używanie testowego wykonania planu przełączania do tworzenia wszystkich planów przywracania awaryjnego (przełączania, przejmowania awaryjnego i testowania) w innej grupie chronionej usługą DR. Dzięki temu plany przywracania awaryjnego będą dostępne w obu regionach.

12. Czy potrzebuję wielu grup objętych ochroną w ramach przywracania awaryjnego, czy też mogę użyć jednej takiej grupy do zarządzania planami przywracania awaryjnego?

To zależy od wymagań aplikacji. Jeśli nie ma zależności między aplikacjami (na przykład, jeśli wiele przełączeń w ramach przywracania awaryjnego może odbywać się równolegle z przywracaniem serwera aplikacji), wówczas posiadanie wielu grup objętych ochroną w ramach przywracania awaryjnego byłoby idealnym rozwiązaniem. Pomogłoby to również skrócić docelowy czas przywracania aplikacji biznesowych. Jeśli jednak etapy odzyskiwania zależą od siebie nawzajem, posiadanie planu odzyskiwania w jednej grupie chronionej usługą DR miałoby sens. Usługa Full Stack DR jest bardzo elastyczna, dzięki czemu pozwala na tworzenie grup chronionych usługą DR i planów przywracania awaryjnego zgodnie z wymaganiami użytkownika.

Wymagania wstępne i obsługiwane usługi OCI

1. Jakie są wymagania wstępne dotyczące korzystania z usługi OCI Full Stack Disaster Recovery?

Usługa OCI Full Stack DR pomaga zautomatyzować etapy odzyskiwania danych dla istniejących aplikacji. Aby zintegrować usługę Full Stack DR z istniejącym systemem, należy:

• zapoznać się z planem odzyskiwania po awarii lub szczegółowymi informacjami na temat odzyskiwania po awarii systemu biznesowego;
• Wdrażanie aplikacji
• dostosować skrypty do wymagań aplikacji.

2. Czy można korzystać z usługi OCI Full Stack Disaster Recovery w dowolnej topologii DR?

Tak. Usługa Full Stack DR jest bardzo elastyczna. Z usługą OCI Full Stack Disaster Recovery można zintegrować dowolnewdrożenia DR.

3. Jakie zasoby OCI są wymagane przed zastosowaniem usługi Full Stack Disaster Recovery?

Konieczne będzie skonfigurowanie całej infrastruktury produkcyjnej i przywracania awaryjnego oraz komponentów aplikacji. W zależności od wdrożeń DR mogą to być:

• zasoby sieciowe, takich jak Oracle Cloud Infrastructure VCN i urządzenie równoważenia obciążenia OCI;
• Rezerwowy system baz danych lub baza danych, która będzie używana w zależności od typu usług Oracle Database PaaS (Usługa Oracle Data Guard jest używana wewnętrznie do replikacji Oracle Database)
• funkcja replikacji pamięci masowej w zależności od typu usług OCI Storage, które będą używane do konfiguracji rozruchu/bloków i replikacji grup woluminów.

4. Które usługi OCI można zintegrować z usługą OCI Full Stack Disaster Recovery?

Do grupy chronionej usługą DR można dodać jako elementy członkowskie następujące typy zasobów.

• Maszyny wirtualne Oracle Cloud Infrastructure (OCI) Compute (maszyny wirtualne i dedykowane do lokalizacji maszyny wirtualne)
• usługi Oracle Database PaaS:
• Oracle Autonomous Database Serverless
• Oracle Autonomous Database on Dedicated Exadata Infrastructure
• Oracle Autonomous Database on Exadata Cloud@Customer
• Oracle Base Database Service
• Oracle Exadata Database Service dla dedykowanej infrastruktury
• Oracle Exadata Database Service on Cloud@Customer
• Oracle Exadata Database Service w infrastrukturze Exascale
• OCI Load Balancer
• OCI Network Load Balancer
• OCI Block Storage (woluminy rozruchowe i blokowe są zawarte w grupach woluminów)
• OCI File Storage
• OCI Object Storage
• OCI Kubernetes Engine

Podczas tworzenia planu DR usługa OCI Full Stack Disaster Recovery automatycznie generuje wbudowane grupy planów. Za pomocą skryptów lub funkcji Oracle Cloud Infrastructure plan DR można dodatkowo dostosować do interakcji z dowolnymi innymi usługami OCI za pośrednictwem zdefiniowanych przez użytkownika grup planów.

5. Jakie typy planów DR są dostępne?

Istnieją cztery typy planów DR.

• Przełączanie (switchover)
• Przełączanie awaryjne (failover)
• Rozpoczęcie drążenia
• Zatrzymanie drążenia

6. Czy planowane jest dodanie nowych elementów członkowskich jako typów zasobów w grupie chronionej usługą DR?

Tak. Planujemy dodać inne podstawowe usługi OCI, takie jak OCI Kubernetes Engine (OKE). Będziemy o tym informować w stosownym czasie.

7. Czy do skonfigurowania rezerwowego systemu baz danych lub bazy danych potrzebna jest konsola OCI lub wbudowane funkcje automatyzacji dostępne w ramach usługi Oracle Database PaaS?

Tak. Usługa OCI Full Stack DR wymaga interfejsów API Oracle Database PaaS Data Guard do generowania grup planów na potrzeby przełączania lub przełączania awaryjnego bazy danych. Mając to na uwadze, można używać skryptów niestandardowych do kontrolowania zmian ról w systemie Oracle Data Guard, gdy system ten został skonfigurowany ręcznie.

8 Czy z usługą Full Stack Disaster Recovery można zintegrować wystąpienia Oracle Database działające na maszynach wirtualnych OCI Compute?

Tak. W takim przypadku usługa Oracle Data Guard musi być skonfigurowana dla baz danych uruchomionych na maszynie wirtualnej OCI. Użytkownik może tu tworzyć swoje grupy planów i korzystać ze skryptów brokera Data Guard lub skryptów umożliwiających zamianę ról.

9. Czy z usługą OCI Full Stack DR można zintegrować bazy danych inne niż Oracle?

Do replikacji produkcyjnych i rezerwowych baz danych zalecamy stosowanie natywnych technologii replikacji baz danych. Użytkownik może użyć swoich grup planów i wprowadzić swoje skrypty umożliwiające zamianę ról bazy danych.

10. Czym są łatwe i trudne do przeniesienia typy zasobów obliczeniowych?

Instancje łatwe do przeniesienia. Zazwyczaj używane w topologach odzyskiwania po awarii typu „pilot light” lub „cold VM”, w ramach których instancje składające się na stos aplikacji są wdrażane tylko w regionie podstawowym. Instancje te są przenoszone z podstawowej grupy chronionej usługą DR do rezerwowej grupy chronionej usługą DR.

Instancje trudne do przeniesienia. Zwykle używane w topologiach aktywnego i pasywnego odtwarzania po awarii, w ramach których instancje składające się na stos aplikacji są wstępnie wdrażane zarówno w regionach, jak i komponentach oprogramowania aplikacji. Instancje te są uruchamiane lub zatrzymywane podczas operacji odzyskiwania po awarii na potrzeby przeniesienia usługi między regionami.

11. Kiedy trzeba dodać grupę woluminów jako element członkowski grupy chronionej usługą DR?

Jeśli dodano łatwe do przeniesienia lub trudne do przeniesienia instancje obliczeniowe jako elementy członkowskie w podstawowej grupie chronionej usługą DR, należy dodać do tej grupy jako elementy członkowskie odpowiednią grupę woluminów rozruchowych/blokowych.

12. Jak obsługiwać replikację pamięci masowej dla maszyn wirtualnych dodanych jako trudne do przeniesienia instancje obliczeniowe w grupie chronionej usługą DR?

We właściwościach elementu członkowskiego instancji trudnej do przeniesienia można określić szczegóły opcji montażu woluminu blokowego. Należy dodać odpowiednią grupę woluminów blokowych jako element członkowski w podstawowej grupie chronionej usługą DR.

13. Czy w usłudze Full Stack DR można dodać bazy danych usług zarządzanych przez Oracle HeatWave MySQL i PostgreSQL jako typy elementów członkowskich?

Nie. Nie można dodawać tych baz danych jako typów elementów członkowskich za pomocą usługi Full Stack DR. Gdy natywne funkcje replikacji między regionami zostaną udostępnione przez odpowiednią usługę, zespół Full Stack DR planuje dodać wsparcie dla tych usług jako typów elementów członkowskich. Obecnie klienci mogą używać skryptów niestandardowych i integrować je z funkcją Full Stack DR, jeśli proces przywracania baz danych może zostać zakończony. Na przykład oprogramowanie HeatWave MySQL obsługuje funkcje tworzenia i odtwarzania kopii zapasowej między regionami. Jeśli można wykonać skrypty procesu przywracania, to można je dodać do planu DR, używając grup planów zdefiniowanych przez użytkownika.

Docelowy czas przywracania (RTO) i docelowy punkt przywracania (RPO)

1. Czym jest docelowy czas przywracania? Czym jest docelowy punkt przywracania? Dlaczego wskaźniki te są ważne?

Docelowy czas przywracania (Recovery Time Objective, RTO) to docelowe ramy czasowe, w których dana aplikacja lub dany system muszą zostać w pełni przywrócone do działania po awarii lub innym zakłóceniu. Wskaźnik ten określa maksymalny dopuszczalny czas przestoju, jaki użytkownik może tolerować dla danej aplikacji. Innymi słowy, wskazuje, jak szybko należy wznowić działanie aplikacji, aby spełnić wymagania dotyczące ciągłości działania. Wskaźnik RTO dla aplikacji o znaczeniu krytycznym jest często niski, ponieważ muszą być one szybko przywrócone, aby zminimalizować skutki zakłóceń i utrzymać realizację podstawowych operacji.

Docelowy punkt przywracania (Recovery Point Objective, RPO) to maksymalna tolerowana utrata danych po awarii lub innym zakłóceniu. Wskaźnik ten określa czas, w którym dane mogą zostać utracone (bez tworzenia kopii zapasowych lub replikacji), zanim awaria zacznie znacząco negatywnie wpływać na działalność biznesową. Jeśli na przykład wskaźnik RPO dla aplikacji wynosi jedną godzinę, oznacza to, że po awarii dane muszą zostać odzyskane do punktu nie wcześniejszego niż jedna godzina przed wystąpieniem incydentu. Aplikacje o niższej wartości wskaźnika RPO zazwyczaj wymagają częstszego tworzenia kopii zapasowych lub częstszej replikacji, aby zapewnić jedynie minimalną utratę danych.

Wskaźniki RTO i RPO mają zasadnicze znaczenie w planowaniu odzyskiwania danych po awarii, ponieważ bezpośrednio wpływają na ciągłość i niezawodność operacji biznesowych w trakcie awarii i po jej zakończeniu. Wartości tych wskaźników muszą być wyważone na podstawie krytyczności aplikacji i kosztów wdrożenia niezbędnych środków odzyskiwania po awarii.

2. W jaki sposób usługa OCI Full Stack Disaster Recovery wpływa na wartość wskaźnika RTO mojej aplikacji?

Wartość wskaźnika RTO dla aplikacji można określić na podstawie czasu potrzebnego do ukończenia planu przełączania lub przełączania awaryjnego. Dzięki w pełni zautomatyzowanemu procesowi odzyskiwania po awarii usługa OCI Full Stack DR może znacznie poprawić wartość wskaźnika RTO, ponieważ minimalizuje czas przestoju i ogranicza ręczną interwencję wymaganą do odzyskania danych.

Dzięki automatyzacji procesów przełączania i przełączania awaryjnego usługa OCI Full Stack DR usprawnia proces odzyskiwania po awarii i umożliwia szybkie przywracanie aplikacji do trybu online. Może to prowadzić do zapewnienia lepszej ciągłości biznesowej i ograniczenia zakłóceń działania aplikacji podczas awarii.

3. W jaki sposób usługa OCI Full Stack Disaster Recovery wpływa na wartość wskaźnika RPO mojej aplikacji?

Usługa OCI Full Stack DR nie kontroluje wartości wskaźnika RPO, ponieważ może się ona różnić w zależności od stosowanych usług OCI i ich metod replikacji oraz konfiguracji. W zależności od sposobu obsługi replikacji i synchronizacji danych, różne usługi w ramach Oracle Cloud Infrastructure mogą mieć określone wytyczne dotyczące RPO.

Na przykład w przypadku usługi Oracle Autonomous Database Serverless Oracle może opublikować wartości RPO dla międzyregionalnych rezerwowych baz danych, wskazując maksymalną tolerowaną utratę danych dla tej konkretnej konfiguracji.

Aby uzyskać określoną wartość wskaźnika RPO i poznać możliwości odzyskiwania danych w ramach poszczególnych usług OCI, należy zapoznać się z dokumentacją poszczególnych usług OCI. Znajdują się tam szczegółowe informacje na temat sposobu replikacji danych, dostępnych opcji odzyskiwania oraz oczekiwanej wartości wskaźnika RPO dla różnych konfiguracji. Postępując zgodnie z zaleceniami zawartymi w tej dokumentacji, można wdrożyć odpowiednią strategię odzyskiwania po awarii, która będzie zgodna z indywidualnymi potrzebami biznesowymi i wymaganiami w zakresie ochrony danych.

Cennik

1. Jaki jest model cenowy dla usługi OCI Full Stack Disaster Recovery?

Cena usługi OCI Full Stack DR jest zgodna ze standardowym dla OCI modelem cenowym (jednostka OCPU i ECPU za godzinę). Cena usługi jest ustalana na podstawie liczby jednostek CPU (OCPU i ECPU) każdego typu elementu członkowskiego dodanego do grupy chronionej usługą DR. Do obliczania opłat używane są tylko zaalokowane jednostki CPU. Użycia magazynu, sieci i innych zasobów będących częścią grup chronionych usługą Full Stack DR, nie są fakturowane w ramach tej usługi.

• OCI Full Stack Disaster Recovery Service — OCPU za godzinę — B95485
• OCI Full Stack Disaster Recovery Service — ECPU za godzinę — B110274

Więcej informacji o cenach można znaleźć w kalkulatorze kosztów OCI i cenniku OCI (PDF).

2. Jak usługa OCI Full Stack Disaster Recovery jest wyceniana?

Usługa OCI Full Stack DR jest wyceniana na podstawie liczby jednostek OCPU (Oracle Compute Unit) i ECPU (Elastic Compute Unit) zasobów obliczeniowych i bazodanowych, które są dodawane jako elementy członkowskie zarówno w podstawowych, jak i rezerwowych grupach chronionych usługą DR.

Przykład 1

• Konfiguracja Podstawowa-DRPG zawiera następujące elementy członkowskie: Zasoby obliczeniowe-A (2 OCPU) i ADB-Podstawowa (1 ECPU)
• Konfiguracja Rezerwowa-DRPG zawiera następujące elementy członkowskie: Zasoby obliczeniowe-B (2 OCPU) i ADB-Rezerwowa (1 ECPU)
• Łączna liczba jednostek OCPU za godzinę (zasoby obliczeniowe i bazodanowe): 4 OCPU za godzinę i 2 ECPU za godzinę.
• Cena usługi Full Stack DR za godzinę: (4 × 0,0128 USD) + (2 × 0,0032 USD) = 0,0576 USD

Przykład 2

• Konfiguracja Podstawowa-DRPG zawiera następujące elementy członkowskie: Zasoby obliczeniowe-A (4 OCPU), ADB-Podstawowa (2 OCPU) i grupa woluminów-500 GB
• Konfiguracja Rezerwowa-DRPG zawiera następujące elementy członkowskie: ADB-Rezerwowa (2 OCPU)
• Łączna liczba jednostek OCPU za godzinę (zasoby obliczeniowe i bazodanowe): 8
• Cena usługi Full Stack DR za godzinę: 8 x 0,0128 USD = 0,1024 USD

Ceny za godzinę i model mogą ulec zmianie. Aby poznać aktualne ceny, zapoznaj się z najnowszymi cennikami lub skontaktuj się z przedstawicielem handlowym Oracle.

3. Czy dodanie grupy woluminów, magazynu plików lub urządzenia równoważenia obciążenia jako elementu członkowskiego grupy chronionej usługą DR jest płatne?

Nie. Dodanie grupy woluminów jako elementu członkowskiego grupy chronionej usługą DR nie wiąże się z żadnymi osobnymi opłatami. Cennik usługi OCI Full Stack DR ma zastosowanie tylko do obliczeniowych i bazodanowych typów elementów członkowskich. W ramach usługi Full Stack DR nie pobiera się dodatkowych opłat za następujące typy zasobów OCI:

• OCI Load Balancer
• OCI Network Load Balancer
• OCI Block Storage (grupy woluminów rozruchowych i blokowych)
• OCI File Storage
• OCI Object Storage

4. Czy konfiguracja infrastruktury DR wiąże się z dodatkowymi kosztami?

Tak. Koszty zwykłe usług OCI potrzebnych do wdrożenia stosu aplikacji są ponoszone niezależnie od tego, czy korzysta się z usługi Full Stack DR. Opłaty są naliczane za usługi OCI Networking, OCI Compute, OCI Load Balancer, miejsce składowania OCI, bazy danych Oracle i wszelkie inne usługi OCI wymagane przez Twój stos aplikacji. Koszt usługi Full Stack DR to dodatkowy koszt oparty na liczbie jednostek ECPU i OCPU zgodnie z wyjaśnieniem w odpowiedzi na pytanie 2 w tej sekcji.

Koszty związane z usługami OCI i modelem wdrożenia DR różnią się w zależności od wybranych usług i konfiguracji. W przypadku wybrania na przykład międzyregionalnej replikacji bloków, pojawią się dodatkowe koszty związane z pamięcią masową. Korzystanie z autonomicznej rezerwowej bazy danych również wiąże się z dodatkowymi kosztami. Więcej szczegółowych informacji na temat cen poszczególnych usług OCI można znaleźć w cenniku usług Oracle Cloud Infrastructure.