Ciągłość działania i odzyskiwanie po awarii dla rozwiązania Oracle w akceleratorze strefy docelowej usługi Azure Virtual Machines

Ten artykuł opiera się na zagadnieniach i zaleceniach zdefiniowanych w obszarze projektowania strefy docelowej platformy Azure na potrzeby ciągłości działania i odzyskiwania po awarii (BCDR). W tym artykule przedstawiono wskazówki i opisano zagadnienia dotyczące projektowania oraz najlepsze rozwiązania dotyczące opcji BCDR dla wdrożeń obciążeń Oracle na maszynach wirtualnych infrastruktury platformy Azure.

Platforma Azure udostępnia usługi, których można użyć do projektowania architektur o wysokiej dostępności i odporności. W tym przewodniku opisano różne opcje i najlepsze rozwiązania ułatwiające projektowanie wysokiej dostępności i odzyskiwania po awarii baz danych Oracle w akceleratorze strefy docelowej usługi Azure Virtual Machines. W tym artykule opisano również sposób konfigurowania towarzyszących usług platformy Azure, aby ułatwić osiągnięcie wysokiej dostępności rozwiązania.

Rozpocznij

Aby utworzyć odporną architekturę dla środowiska obciążenia, określ wymagania dotyczące dostępności rozwiązania na podstawie celu czasu odzyskiwania (RTO) i celu punktu odzyskiwania (RPO) dla różnych poziomów awarii. Cel czasu odzyskiwania to maksymalny czas niedostępności aplikacji po wystąpieniu zdarzenia. Cel punktu odzyskiwania to maksymalna ilość utraty danych podczas awarii. Po określeniu wymagań dotyczących rozwiązania zaprojektuj architekturę, aby zapewnić ustalone poziomy odporności i dostępności.

Obciążenia oracle na platformie Azure korzystają głównie z funkcji Oracle Data Guard, która jest wbudowaną funkcją Oracle Database Enterprise Edition korzystającą z technologii replikacji. Funkcja Data Guard umożliwia spełnienie wymagań dotyczących wysokiej dostępności i odzyskiwania po awarii. Funkcja Data Guard oferuje trzy tryby ochrony: maksymalną wydajność, maksymalną dostępność i maksymalną ochronę. Wybierz tryb ochrony na podstawie projektu architektury i określonych wymagań celu punktu odzyskiwania i celu odzyskiwania.

Konfigurowanie obciążenia pod kątem wysokiej dostępności

Wystąpienia usługi Azure Virtual Machines, które uruchamiają obciążenia Oracle, korzystają z architektury usługi Azure Virtual Machine Scale Sets, w szczególności elastycznego trybu aranżacji. Konfiguracja wysokiej dostępności zapewnia replikację danych niemal w czasie rzeczywistym z potencjalnie szybkim trybem failover. Konfiguracja wysokiej dostępności nie zapewnia ochrony błędów na poziomie centrum danych platformy Azure ani na poziomie regionu.

Wybieranie odpowiedniej opcji wysokiej dostępności

Użyj poniższego wykresu blokowego, aby wybrać najlepszą opcję wysokiej dostępności dla bazy danych Oracle.

Używanie funkcji Data Guard w trybie maksymalnej dostępności w celu zapewnienia wysokiej dostępności

Funkcja Data Guard w trybie maksymalnej dostępności zapewnia najwyższą dostępność z obietnicą zerowej utraty danych (RPO=0) dla normalnych operacji. W przypadku konfiguracji o wysokiej dostępności dwóch serwerów baz danych Oracle utworzonych w ramach elastycznej aranżacji zestawów skalowania maszyn wirtualnych platforma Azure zapewnia dostępność usług na poziomie 99,95% dla umowy dotyczącej poziomu usług (SLA) dla wystąpień rozmieszczonych w różnych domenach błędów. Platforma Azure zapewnia dostępność usługi w 99,99% dla wystąpień rozmieszczonych w różnych strefach dostępności. Aby uzyskać więcej informacji, zobacz Wysoka dostępność zestawów skalowania maszyn wirtualnych.

Aby uzyskać instrukcje krok po kroku konfiguracji funkcji Data Guard na platformie Azure, zobacz Implementowanie funkcji Oracle Data Guard na maszynie wirtualnej platformy Azure opartej na systemie Linux.

Używanie funkcji Data Guard w trybie maksymalnej ochrony w celu zapewnienia wysokiej dostępności

Jeśli potrzebujesz transakcyjnie spójnej kopii bazy danych, rozważ użycie funkcji Data Guard w trybie maksymalnej ochrony. Jednak maksymalny tryb ochrony nie zezwala na kontynuowanie transakcji, gdy rezerwowa baza danych nie jest dostępna. W związku z tym pomimo korzystania z elastycznej aranżacji usługi Virtual Machines Scale Sets umowa SLA jest ograniczona do 99,9% x 99,9% = 99,8% w przypadku korzystania z maksymalnego trybu ochrony. Ta konfiguracja zapewnia spójną kopię danych, ale niekoniecznie zwiększa dostępność.

Inne atrybuty tej architektury są takie same jak tryb maksymalnej dostępności. Na przykład cel punktu odzyskiwania wynosi zero, a cel czasu odzyskiwania jest mniejszy lub równy dwóm minutom.

Rozważ inne sposoby implementowania wysokiej dostępności

W poniższych sekcjach opisano specjalne zagadnienia dotyczące wysokiej dostępności.

Korzystanie ze stref dostępności w celu zwiększenia wysokiej dostępności

Strefy dostępności platformy Azure to centra danych platformy Azure, które znajdują się w tym samym regionie świadczenia usługi Azure. Strefy dostępności mają opóźnienie dwukierunkowe mniejsze niż dwa milisekundy. Zazwyczaj strefy dostępności są używane do celów odzyskiwania po awarii, ale można ich użyć do zwiększenia wysokiej dostępności. W takim przypadku należy upewnić się, że rozwiązanie może działać z opóźnieniem i przepływnością zapewnianą przez strefy dostępności.

Zaletą stref dostępności dzięki elastycznej aranżacji zestawów skalowania maszyn wirtualnych jest zwiększenie dostępności maszyn wirtualnych do 99,99%.

Używanie klastra magazynu udostępnionego w celu zapewnienia wysokiej dostępności

Technologie klastrowania magazynów udostępnionych zapewniają unikatowe atrybuty, które mogą pomóc w osiągnięciu celów biznesowych. Można na przykład zaimplementować klaster Pacemaker i Corosync (PCS) z udostępnionym magazynem. Dyski zarządzane lub usługa Azure NetApp Files można używać jako magazynu udostępnionego dla wystąpień klastra PCS. Klaster PCS nie duplikuje danych. Zapewnia ona wirtualną usługę IP ze statycznym adresem IP lub nazwą sieci IP, która nie zmienia się w trybie failover.

Korzystanie z grup umieszczania w pobliżu

Aby zapewnić najmniejsze możliwe opóźnienie, umieść maszyny wirtualne tak blisko, jak to możliwe. Można je wdrożyć w grupie umieszczania w pobliżu. Grupa umieszczania w pobliżu to logiczne grupowanie, które gwarantuje, że zasoby obliczeniowe platformy Azure znajdują się fizycznie blisko siebie. Grupy umieszczania w pobliżu są przydatne w przypadku obciążeń wymagających małych opóźnień.

Konfigurowanie obciążenia na potrzeby odzyskiwania po awarii

Architektura odzyskiwania po awarii zapewnia odporność na awarie wpływające na centra danych platformy Azure lub regiony lub awarie, które utrudniają działanie aplikacji w całym regionie. W takim scenariuszu należy przenieść całe obciążenie do innego centrum danych lub regionu.

Wybierz architekturę odzyskiwania po awarii na podstawie wymagań dotyczących rozwiązania. Określasz wymagania na podstawie celu czasu odzyskiwania i celu punktu odzyskiwania. Architektury odzyskiwania po awarii są przeznaczone dla wyjątkowych przypadków awarii, dlatego procesy trybu failover są ręczne. W projekcie wysokiej dostępności procesy trybu failover są automatyczne. W architekturze odzyskiwania po awarii należy mieć bardziej złagodzone wymagania dotyczące celu odzyskiwania i celu punktu odzyskiwania, co pozwala zaoszczędzić pieniądze.

Ten artykuł koncentruje się na scenariuszach, w których zarówno serwer podstawowy, jak i serwery pomocnicze znajdują się na platformie Azure. Możesz również mieć serwer podstawowy lokalnie i serwer pomocniczy na platformie Azure na potrzeby odzyskiwania po awarii. Aby uzyskać więcej informacji, zobacz Lokacja główna lokalna i lokacja odzyskiwania po awarii na platformie Azure.

Wybieranie odpowiedniej opcji odzyskiwania po awarii

Użyj poniższego wykresu blokowego, aby wybrać najlepszą opcję odzyskiwania po awarii dla bazy danych Oracle.

Używanie funkcji Data Guard do odzyskiwania po awarii

Funkcja Data Guard umożliwia replikowanie danych do lokacji odzyskiwania po awarii. Użyj tej witryny jako innej strefy dostępności w tym samym regionie lub w innym regionie w zależności od wymagań dotyczących ochrony danych. Konfiguracja zależy również od struktury strefy dostępności w lokacji produkcyjnej. Implementacja funkcji Data Guard w scenariuszu odzyskiwania po awarii jest podobna do omówionego wcześniej scenariusza wysokiej dostępności z kilkoma ważnymi różnicami. Na przykład:

• Po przejściu w tryb failover do repliki pomocniczej w scenariuszu wysokiej dostępności skonfigurujesz usługę Azure Load Balancer w celu przekierowania żądań do nowego wystąpienia podstawowej bazy danych.

• Po przejściu w tryb failover do lokacji odzyskiwania po awarii przełącz całe rozwiązanie w tryb failover do nowej lokacji. Aby uniknąć wyzwań związanych z opóźnieniami, zazwyczaj należy skonfigurować tryb failover dla usług aplikacji.

Jeśli lokacja odzyskiwania po awarii znajduje się w innym regionie, musisz zaprojektować lokację dla trybu failover w zależności od wymagań.

Opóźnienie w jednym centrum danych jest mniejsze niż opóźnienie między centrami danych, które są oddzielone od siebie i znacznie mniejsze niż opóźnienie między różnymi regionami. W związku z tym najmniej złożoną i najmniej kosztowną opcją jest użycie funkcji Data Guard w trybie maksymalnej wydajności na potrzeby odzyskiwania po awarii. Jeśli potencjalna utrata danych w trybie maksymalnej wydajności jest zbyt wysoka, możesz użyć trybu maksymalnej dostępności z mechanizmem oracle Data Guard Far Sync. Jednak wystąpienie usługi Far Sync wyzwala licencjonowanie usługi Active Data Guard w środowisku podstawowym i w środowisku rezerwowym. Aby uzyskać więcej informacji, zobacz Szczegóły licencji Oracle.

Ponadto podczas wysyłania danych między regionami platformy Azure lub centrami danych płacisz koszty ruchu wychodzącego dla danych, takich jak dzienniki ponownego uruchamiania, wysyłane do lokacji odzyskiwania po awarii. Jeśli nie musisz replikować wszystkich danych w bazie danych, możesz użyć replikacji opartej na rozwiązaniu Oracle Golden Gate, aby replikować tylko częściowe dane zgodnie z potrzebami, co zmniejsza koszty ruchu wychodzącego.

Aby uzyskać instrukcje krok po kroku konfiguracji funkcji Data Guard na platformie Azure, zobacz Implementowanie funkcji Data Guard na maszynie wirtualnej z systemem Linux opartej na systemie Linux.

Używanie złotej bramy do odzyskiwania po awarii

Golden Gate to oprogramowanie do replikacji logicznej, które umożliwia replikację, filtrowanie i przekształcanie danych ze źródłowej bazy danych do docelowej bazy danych lub między wieloma podstawowymi bazami danych. Ta funkcja zapewnia, że zmiany w źródłowej bazie danych są replikowane niemal w czasie rzeczywistym, dzięki czemu docelowa baza danych jest aktualna z najnowszymi danymi.

Za pomocą złotej bramy można replikować dane z podstawowej bazy danych do pomocniczej bazy danych w konfiguracji odzyskiwania po awarii. Golden Gate jest szczególnie praktyczny, jeśli musisz chronić tylko niektóre dane. Aby uniknąć replikacji niepotrzebnych danych, użyj złotej bramy, aby selektywnie replikować tabele i filtrować wiersze tabeli podczas replikacji.

Aby zapoznać się z przewodnikiem krok po kroku dotyczącym implementowania rozwiązania Golden Gate na platformie Azure, zobacz Implement Golden Gate on a Linux-based Azure VM (Implementowanie złotej bramy na maszynie wirtualnej platformy Azure opartej na systemie Linux).

Używanie kopii zapasowej na potrzeby odzyskiwania po awarii

Tworzenie i przywracanie kopii zapasowych to tradycyjna metoda architektury odzyskiwania po awarii. Istnieją dwa główne składniki tworzenia kopii zapasowej jako metoda odzyskiwania po awarii dla baz danych Oracle na platformie Azure:

• Wyodrębnij i przenieś kopię zapasową danych z bazy danych, aby upewnić się, że lokacja odzyskiwania po awarii ma aktualne dane.

• Upewnij się, że wdrożenie jest aktualne w lokacji odzyskiwania po awarii. Aby zaktualizować lokację, zreplikuj to samo wdrożenie wszystkich składników sieciowych, serwerów aplikacji i konfiguracji do lokacji odzyskiwania po awarii.

Istnieje kilka opcji tworzenia kopii zapasowej, których można użyć do replikowania danych. Aby uzyskać więcej informacji, zobacz Strategie tworzenia kopii zapasowych dla bazy danych Oracle Database na platformie Azure.

Rozważ użycie jednej z następujących metod obsługi lokacji odzyskiwania po awarii:

Podejście 1: Aby uniknąć dodatkowego nakładu pracy konserwacyjnego i kosztów, nie należy utrzymywać żadnego fizycznego wdrożenia w lokacji odzyskiwania po awarii. Możesz użyć infrastruktury jako praktyk inżynierii niezawodności kodu i lokacji, aby tworzyć i obsługiwać repozytorium. To repozytorium może replikować wdrożenie jako konfigurację do lokacji odzyskiwania po awarii w momencie przejścia w tryb failover. Ta metoda optymalizuje koszt, ponieważ nie używa żadnych zasobów fizycznych do czasu przejścia w tryb failover.

Podejście 2. Wdrażanie i utrzymywanie skalowanej wersji środowiska produkcyjnego. Mieć wersję, która może działać prawidłowo dla małego obciążenia i którą można potencjalnie skalować w górę w razie potrzeby podczas pracy w trybie failover w celu obsługi obciążenia produkcyjnego. Ta metoda jest często używana, szczególnie w przypadku złożonych wdrożeń, w których nie chcesz ryzykować tworzenia całego środowiska lub szybkiego przełączania w tryb failover w celu zapewnienia niskiego celu czasu odzyskiwania.

Podejście 3. Wdrażanie i utrzymywanie całego rozwiązania w lokacji odzyskiwania po awarii w celu uzyskania najszybszych czasów czasu odzyskiwania i trybu failover. Ta metoda zwiększa koszt z powodu uruchomienia w pełni nadmiarowej infrastruktury.

Rozważ inne sposoby implementowania odzyskiwania po awarii

W poniższych sekcjach opisano specjalne zagadnienia dotyczące odzyskiwania po awarii.

Korzystanie z usługi Far Sync

Usługa Far Sync nie zwiększa możliwości wysokiej dostępności, ale można jej użyć do osiągnięcia zerowych możliwości ochrony przed utratą danych dla baz danych Oracle. Obciążenie może wymagać zerowej utraty danych, jeśli podstawowa baza danych ulegnie awarii. Aby uzyskać więcej informacji, zobacz Architektury referencyjne Oracle na platformie Azure.

Wybieranie odpowiedniej technologii replikacji danych

Oprócz technologii w tym artykule można użyć dowolnej technologii, która ułatwia replikację danych w dwóch bazach danych Oracle w celu utrzymania repliki wysokiej dostępności i repliki odzyskiwania po awarii dla baz danych Oracle na platformie Azure. Wybrana technologia musi spełniać wymagania dotyczące rozwiązania w tych kategoriach.

Opóźnienie: czas potrzebny na replikowanie aktualizacji z podstawowej bazy danych do pomocniczych baz danych w celu zapewnienia wysokiej dostępności i odzyskiwania po awarii powinien być zgodny z wymaganiami rozwiązania.

Przepustowość: ilość i koszt przepustowości potrzebnej do replikowania danych do pomocniczych baz danych w celu zapewnienia wysokiej dostępności i odzyskiwania po awarii. Platforma Azure zapewnia szybką infrastrukturę sieciową między strefami dostępności. Jeśli rozważasz replikację do innych regionów świadczenia usługi Azure w celach odzyskiwania po awarii, rozważ użycie przepustowości i kosztów ruchu wychodzącego dla danych opuszczających centrum danych platformy Azure.

Wpływ: poziom wpływu replikacji na przetwarzanie transakcji w podstawowej bazie danych powinien być zgodny z wymaganiami rozwiązania.

Utrata danych: ilość utraty danych oczekiwana podczas nagłej awarii podstawowej bazy danych powinna być zgodna z wymaganiami rozwiązania.

Całkowity koszt posiadania: rozważ zakup rozwiązania replikacji innej firmy niż Microsoft oraz nakład pracy, który należy skonfigurować i obsługiwać rozwiązanie replikacji. Sprawdź, czy te czynniki są zgodne z wymaganiami rozwiązania.

Optymalizowanie wystąpienia trybu failover

W przypadku korzystania z funkcji Data Guard w trybie wysokiej dostępności lub w trybie wysokiej ochrony można skonfigurować automatyczne przełączanie w tryb failover, aby w przypadku awarii serwera podstawowego serwer pomocniczy był automatycznie wywoływany. Podczas prawidłowego konfigurowania serwerów aplikacji możesz mieć pewność, że podczas pracy w trybie failover nie ma prawie żadnych przestojów aplikacji.

W tej implementacji baza danych musi działać tak samo po przejściu w tryb failover. Dlatego należy skonfigurować serwer pomocniczy z tą samą pojemnością procesora CPU, pamięci i wejścia/wyjścia (we/wy) co serwer podstawowy. Musisz zachować wysoką pojemność przy użyciu serwera pomocniczego, co zwiększa koszty platformy Azure i koszty licencji bazy danych Oracle Database. Serwer pomocniczy zwykle nie przetwarza żądań użytkowników.

Platforma Azure zapewnia dostępność na 99,9% dla maszyn wirtualnych w strefie dostępności. Aby uzyskać więcej informacji, zobacz Umowa SLA dotycząca czasu działania maszyny wirtualnej. Jeśli używasz technologii replikacji danych do obsługi pomocniczej repliki bazy danych w tej samej strefie dostępności, innej strefie dostępności lub innym regionie, możesz zoptymalizować pojemność pomocniczą.

Dzięki temu podejściu pomocnicza baza danych jest skonfigurowana z pojemnością, która musi pozostać aktualna. W przypadku awarii pomocnicza baza danych zostanie zmieniona na taką samą pojemność jak podstawowa baza danych. Ta operacja występuje tylko wtedy, gdy wystąpi błąd. Dlatego podczas normalnego działania płacisz tylko za ułamek kosztów serwera podstawowego. Podstawowa baza danych nie działa podczas awarii, więc nie potrzebujesz innych licencji bazy danych Oracle.

Pojemność, którą należy obsługiwać pomocniczą bazę danych jako miejsce docelowe replikacji, zależy od używanej technologii replikacji. Zasadniczo obciążenie, które znajduje się w transakcyjnym systemie przetwarzania transakcji online (OLTP) ma głównie żądania odczytu. Na przykład 90% operacji odczytu i 10% operacji zapisu lub 95% operacji odczytu i 5% operacji zapisu są typowe w aplikacjach OLTP. Replikacja danych zasadniczo replikuje wynik pisania żądań w źródłowej bazie danych. Dzięki tej konfiguracji można oczekiwać, że pomocnicza baza danych będzie działać z 1/10 (jeśli masz 90% odczytu i 10% współczynnika zapisu) pojemności podstawowej bazy danych.

Zautomatyzuj procedury trybu failover, aby upewnić się, że spełniasz standardy przedsiębiorstwa podczas procesu pracy w trybie failover. Procedury trybu failover można skonfigurować tak, aby obejmowały operacje zmiany rozmiaru serwera, które usprawniają proces kompleksowego.

Konfigurowanie topologii sieci na potrzeby ochrony usług i ochrony danych

Aby uzyskać wysoką dostępność i odzyskiwanie po awarii, należy podjąć decyzje finansowe i biznesowe, które równoważą czas odzyskiwania lub cel czasu odzyskiwania oraz potencjalną utratę danych lub cel punktu odzyskiwania, względem innych licencji Oracle, obsługi maszyn wirtualnych i kosztów transferu danych. W przypadku hostowania obciążenia na jednej maszynie wirtualnej platformy Azure uzyskujesz podstawową ochronę typowych awarii sprzętowych przy niskich kosztach. Jednak awaria pojedynczej maszyny wirtualnej prawdopodobnie powoduje przestój i utratę danych. Dlatego w środowiskach produkcyjnych uwzględnij co najmniej jedną pomocniczą bazę danych Oracle hostowaną na oddzielnej maszynie wirtualnej z funkcją Data Guard. W zależności od wymagań użyj co najmniej jednej z następujących konfiguracji funkcji Data Guard na potrzeby replikacji danych:

• Optymalny cel czasu odzyskiwania i cel punktu odzyskiwania. Aby zminimalizować opóźnienia, uwzględnij pomocniczą bazę danych Oracle na oddzielnej maszynie wirtualnej w ramach tej samej elastycznej aranżacji usługi Virtual Machine Scale Sets i w tej samej strefie dostępności co podstawowa baza danych. Ta konfiguracja zapewnia wysoką dostępność i ochronę przed awarią pojedynczego wystąpienia.

• Ochrona danych przed awarią centrum danych. Umieść pomocniczą bazę danych Oracle w drugiej strefie dostępności, aby zapewnić konfigurację wysokiej dostępności i zapewnić ochronę w przypadku awarii całej strefy dostępności. Ta konfiguracja może mieć maksymalnie dwie milisekundy opóźnienia między podstawową i pomocniczą bazą danych, co może mieć wpływ na wydajność, obiekty RTO i obiekty żądań odzyskiwania.

• Ochrona danych przed awarią regionalną. Aby chronić przed potencjalną utratą danych z powodu awarii regionalnej platformy Azure, możesz umieścić pomocniczą bazę danych w innym regionie. Ta konfiguracja może zawierać od 30 milisekund do 300 milisekund opóźnienia między regionami, dzięki czemu nie można spełnić celów celu czasu odzyskiwania i celu punktu odzyskiwania. To rozwiązanie jest najlepsze w przypadku regionalnego odzyskiwania po awarii, a nie wysokiej dostępności.

Ciągłość działania wymaga zintegrowanego podejścia, które obejmuje wszystkie składniki obciążenia. Infrastruktura sieciowa jest podstawowym składnikiem dowolnego obciążenia na platformie Azure. Infrastruktura sieci musi być zgodna z architekturą wysokiej dostępności lub odzyskiwania po awarii. Rozważ następujące czynniki infrastruktury sieciowej:

• Funkcja Data Guard zapewnia wysoką dostępność i w większości scenariuszy zapewnia wystarczającą obsługę typowych błędów. Maszyny wirtualne można umieścić w elastycznej aranżacji zestawów skalowania maszyn wirtualnych. Aby zmniejszyć opóźnienie sieci, wszystkie usługi w jednym rozwiązaniu powinny znajdować się w tej samej strefie dostępności, a usługi powinny współużytkować tę samą sieć wirtualną.

  W celu zapewnienia dalszej ochrony można strategicznie umieścić maszyny wirtualne w oddzielnych strefach dostępności, a nie w jednej strefie dostępności. Takie podejście może zapobiec przestojom podczas awarii centrum danych.

• Aby uzyskać maksymalną ochronę, możesz umieścić pomocniczą bazę danych w innym regionie świadczenia usługi Azure od podstawowego regionu bazy danych. Aby zastosować aktualizacje ciągłe, możesz użyć funkcji Data Guard do zaimplementowania globalnej komunikacji równorzędnej sieci wirtualnych. Użyj tego podejścia, aby zastosować aktualizacje danych do regionu pomocniczego prywatnie za pośrednictwem sieci szkieletowej firmy Microsoft. Zasoby komunikują się bezpośrednio bez bram, dodatkowych przeskoków lub przesyłania przez publiczny Internet.

  Ta opcja sieci zapewnia połączenie o wysokiej przepustowości i małych opóźnieniach w równorzędnych sieciach wirtualnych w różnych regionach. Globalna komunikacja równorzędna sieci wirtualnych umożliwia połączenie lokacji głównej z lokacją odzyskiwania po awarii w innym regionie za pośrednictwem szybkiej sieci.

Podsumowanie odporności na różne typy błędów

Następny krok

Dowiedz się więcej na temat zagadnień projektowych dotyczących zabezpieczeń akceleratora strefy docelowej Oracle on Virtual Machines w scenariuszu o skali przedsiębiorstwa.

Wytyczne dotyczące zabezpieczeń dla akceleratora strefy docelowej oracle on Virtual Machines