Ciągłość działania i odzyskiwanie po awarii na potrzeby migracji sap
Ten artykuł opiera się na zagadnieniach i zaleceniach w obszarze projektowania strefy docelowej platformy Azure dla trasy BCDR. W tym artykule opisano unikatowe ograniczenia dotyczące stref docelowych, które obsługują platformę SAP. SAP to platforma o znaczeniu krytycznym, dlatego należy również uwzględnić inne wskazówki o znaczeniu krytycznym w projekcie.
Scenariusz i zakres
Uwzględnij zasady w architekturze, które dotyczą lokalnych scenariuszy ciągłości działania i odzyskiwania po awarii (BCDR). Te zasady dotyczą również platformy Azure. Jednak platforma Azure może mieć większą pojemność sprzętową niż środowisko lokalne, aby zrekompensować awarię hosta. Aby automatycznie odzyskać nawet największe maszyny wirtualne platformy Azure, można skonfigurować je do ponownego uruchomienia na innym serwerze. Skonfiguruj wdrożenia platformy Azure, aby używać tych samych warunków co wdrożenia lokalne. Jeśli używasz automatycznych konfiguracji klastra trybu failover do wdrażania systemów lokalnych lub sprzętu bez systemu operacyjnego, wdróż je w taki sam sposób na platformie Azure. Aplikacje SAP, które uruchamiają najbardziej krytyczne procesy biznesowe organizacji, wymagają:
Dostępność usług i procesów biznesowych.
Cele czasu odzyskiwania (RTO) dla scenariuszy awarii lub scenariuszy awarii.
Cele punktu odzyskiwania (RPO) dla scenariuszy awarii.
Zadania zarządzania operacjami i cyklem życia oraz technologia uruchamiana podczas scenariuszy awarii. Te zadania zarządzania obejmują stosowanie poprawek systemów operacyjnych gościa i systemów zarządzania bazami danych, klonowanie i odświeżanie systemów SAP.
Napiwek
Określ rozwiązanie wysokiej dostępności i odzyskiwania po awarii (HADR) dla każdego z archetypów w środowisku SAP na wczesnym etapie. Upewnij się, że rozwiązanie obejmuje wszystkie składniki SAP.
Skonfiguruj rozwiązanie HADR na platformie Azure na początku, co najmniej jednego krajobrazu i zachowaj je aktywne. Następnie zespoły mogą korzystać z technologii rozwiązania, które mogą różnić się od istniejących technologii. Skonfiguruj usługę HADR na wczesnym etapie, aby ułatwić opracowywanie i rozwijanie standardowych procedur operacyjnych (SOP).
Zaplanuj pełną dostępność, odzyskiwanie po awarii i ochronę kopii zapasowych dla obciążeń produkcyjnych, gdy tylko system jest żywy.
W tym artykule opisano następujące aspekty bcDR dla scenariusza SAP w skali przedsiębiorstwa:
Wysoka dostępność w regionie świadczenia usługi Azure
Zagadnienia dotyczące tworzenia kopii zapasowych i przywracania
Kryteria podejmowania decyzji między odzyskiwaniem po awarii między regionami i regionami
Wysoka dostępność w regionie świadczenia usługi Azure
W poniższych sekcjach przedstawiono zagadnienia dotyczące projektowania i zalecenia dotyczące wysokiej dostępności w regionie świadczenia usługi Azure dla scenariusza sap enterprise.
Zagadnienia dotyczące projektowania pod kątem wysokiej dostępności
Podczas implementowania wysokiej dostępności celem jest zapewnienie dostępności pojedynczego punktu awarii oprogramowania SAP, na przykład:
Systemy zarządzania bazami danych.
Pojedyncze punkty awarii w aplikacji, takie jak SAP Advanced Business Application Programming (ABAP), ABAP SAP Central Services (ASCS) i SAP Central Services (SCS). Przykłady wysokiej dostępności obejmują oprogramowanie SAP NetWeaver i architekturę SAP S/4HANA.
Inne narzędzia, takie jak SAP Web Dispatcher.
W przypadku innych scenariuszy nie ograniczaj dostępności do awarii infrastruktury ani awarii oprogramowania. Zastosuj dostępność do wszystkich niezbędnych zadań zarządzania cyklem życia. Można na przykład zastosować poprawki systemu operacyjnego na maszynach wirtualnych, systemie zarządzania bazami danych (DBMS) i oprogramowaniu SAP. Aby zminimalizować awarie, które mogą wystąpić podczas planowanych przestojów i operacji zarządzania cyklem życia, użyj typowych narzędzi, które pomagają chronić systemy przed nieplanowanymi zakłóceniami usług.
Bazy danych SAP i SAP obsługują automatyczne klastry trybu failover. W systemie Windows funkcja klastra trybu failover systemu Windows Server 2022 obsługuje tryb failover. W systemie Linux narzędzie Pacemaker lub narzędzia partnerskie, takie jak SIOS Protection Suite i Veritas InfoScale, obsługują tryb failover. Na platformie Azure można wdrożyć tylko konfigurację wysokiej dostępności podzestawu we własnym centrum danych.
Aby uzyskać więcej informacji, zobacz Obsługiwane scenariusze obciążeń SAP na maszynach wirtualnych platformy Azure i obsługiwane scenariusze dla dużych wystąpień sap HANA.
W przypadku warstwy SYSTEMU DBMS typowy wzorzec architektury polega na replikacji baz danych w tym samym czasie i z różnymi stosami magazynu niż te, z których korzystają podstawowa maszyna wirtualna i pomocnicze maszyny wirtualne. Platforma Azure nie obsługuje architektur, w których podstawowe maszyny wirtualne i pomocnicze maszyny wirtualne współużytkuje magazyn danych systemu DBMS. Platforma Azure nie obsługuje również dzienników transakcji ani dzienników ponownego wdrażania. Podstawową zasadą jest użycie dwóch niezależnych stosów magazynu, nawet jeśli są one oparte na udziałach systemu plików sieciowych (NFS). Te ograniczenia dotyczą wyłącznie rozwiązań platformy Azure, a nie rozwiązań lokalnych.
Platforma Azure udostępnia inne opcje, ponieważ obsługuje udostępnianie NFS i bloku komunikatów serwera. Dyski udostępnione platformy Azure można używać w systemie Windows dla składników USŁUGI ASCS i SCS oraz określonych scenariuszy wysokiej dostępności. Skonfiguruj klastry trybu failover oddzielnie dla składników warstwy aplikacji SAP i warstwy DBMS. Platforma Azure nie obsługuje architektur wysokiej dostępności, które łączą składniki warstwy aplikacji SAP i warstwę DBMS w jeden klaster trybu failover.
Większość klastrów trybu failover dla składników warstwy aplikacji SAP i warstwa DBMS wymaga wirtualnego adresu IP klastra trybu failover. Typowym wyjątkiem jest użycie funkcji Oracle Data Guard, która nie wymaga wirtualnego adresu IP. Usługa Azure Load Balancer powinna obsługiwać wirtualny adres IP dla wszystkich innych przypadków. Dla każdej konfiguracji klastra można użyć jednego modułu równoważenia obciążenia. Zalecamy użycie standardowej wersji modułu równoważenia obciążenia. Aby uzyskać więcej informacji, zobacz Publiczna łączność punktu końcowego dla maszyn wirtualnych przy użyciu usługi Azure Load Balancer w warstwie Standardowa w scenariuszach wysokiej dostępności oprogramowania SAP.
Aby uzyskać więcej informacji, zobacz architektura i scenariusze wysokiej dostępności dla oprogramowania SAP NetWeaver.
W poniższej tabeli przedstawiono umowy dotyczące poziomu usług (SLA) na poziomie platformy dla różnych opcji wdrażania o wysokiej dostępności. Partnerzy, którzy udostępniają usługi zarządzane, zapewniają również umowę SLA na poziomie aplikacji.
| Warstwa | Scenariusz wysokiej dostępności | Umowa SLA platformy |
|---|---|---|
| 1 | Availability zone | 99,99% |
| 2 | Zestaw dostępności | 99,95% |
| 3 | Pojedyncza maszyna wirtualna (samonaprawiania) | 99.90% |
Zestawy dostępności platformy Azure a strefy dostępności
Przed wdrożeniem infrastruktury wysokiej dostępności określ, czy wdrożyć przy użyciu zestawu dostępności platformy Azure, czy strefy dostępności w zależności od wybranego regionu. Główne różnice w przypadku maszyn wirtualnych wdrażanych za pomocą zestawu dostępności to:
Maszyny wirtualne nie są rozmieszczone w różnych strefach dostępności.
Typ maszyn wirtualnych, które można wdrożyć za pomocą pojedynczego zestawu dostępności, jest ograniczony, ponieważ pierwsza maszyna wirtualna wdrożona w zestawie definiuje hosta. Na przykład nie można połączyć maszyn wirtualnych serii M i maszyn wirtualnych serii E w jeden zestaw dostępności.
Podczas wdrażania architektury wysokiej dostępności w różnych strefach dostępności możesz mieć wyższą umowę SLA dla maszyn wirtualnych. Aby uzyskać więcej informacji, zobacz Umowy SLA maszyn wirtualnych platformy Azure. W zależności od regionu świadczenia usługi Azure mogą wystąpić różne warunki opóźnienia sieci w ruchu sieciowym między maszynami wirtualnymi. Aby uzyskać więcej informacji, zobacz Konfiguracje obciążeń SAP ze strefami dostępności platformy Azure.
Jeśli wybierzesz podejście do wdrożenia strefowego, rozważ, w jaki sposób opóźnienie między strefami dla wybranego regionu platformy Azure może mieć wpływ na wybór projektu wydajności i architektury. Rozważ opóźnienie między serwerem aplikacji a bazą danych i między dwoma węzłami bazy danych.
Jeśli używasz aktywnego/pasywnego wdrożenia strefowego dla warstwy serwera aplikacji, w której serwery aplikacji muszą łączyć się z bazą danych w tej samej strefie dostępności, skonfiguruj automatyzację i utwórz sop, aby umożliwić szybkie i zautomatyzowane odzyskiwanie w przypadku przejścia bazy danych w tryb failover.
Jeśli używasz stref dostępności w rozwiązaniu SAP, zaprojektuj wszystkie inne usługi platformy Azure i składniki infrastruktury w środowisku SAP w celu zapewnienia nadmiarowości stref, aby można było osiągnąć prawdziwą nadmiarowość strefy. Przykłady usług i składników, które należy wziąć pod uwagę, obejmują bramy usługi Azure ExpressRoute, moduł równoważenia obciążenia, usługę Azure Files, usługę Azure NetApp Files, odwrotne serwery proxy, zapory, usługi antywirusowe i infrastrukturę kopii zapasowych.
Zalecenia dotyczące projektowania pod kątem wysokiej dostępności
Platforma Azure oferuje kilka opcji, które ułatwiają spełnienie umów SLA dotyczących infrastruktury aplikacji. Należy wybrać tę samą opcję dla wszystkich trzech składników SAP: usług centralnych, serwera aplikacji i bazy danych. Aby uzyskać więcej informacji na temat umów SLA dla maszyn wirtualnych, zestawów dostępności i stref dostępności, zobacz Umowy SLA dotyczące Usługi online.
Podczas wdrażania maszyn wirtualnych w zestawie dostępności dopasowanie z domenami błędów i aktualizacji uniemożliwia maszynom wirtualnym korzystanie z tego samego sprzętu hosta, co zapewnia ochronę przed awariami sprzętowymi. Podczas wdrażania maszyn wirtualnych za pośrednictwem stref dostępności i używania różnych stref tworzysz maszyny wirtualne w różnych lokalizacjach fizycznych. Ta konfiguracja zapewnia dodatkową ochronę przed problemami z zasilaniem, chłodzeniem lub siecią, które mają wpływ na centra danych strefy jako całości. Nie można jednak wdrożyć zestawów dostępności platformy Azure w strefie dostępności platformy Azure, chyba że używasz grup umieszczania w pobliżu.
Jeśli wybierzesz podejście do wdrożenia strefowego, system SAP DBMS, usługi centralne i warstwy aplikacji będą uruchamiane w różnych strefach dostępności. Jednak każda strefa dostępności najprawdopodobniej ma wiele serwerów aplikacji. W tym scenariuszu serwery aplikacji w każdej strefie nie korzystają automatycznie z domen błędów i domen aktualizacji. Możesz użyć zestawów dostępności, aby uzyskać te korzyści. Aby uzyskać więcej informacji, zobacz Grupy umieszczania w pobliżu platformy Azure w celu uzyskania optymalnego opóźnienia sieci w oprogramowaniu SAP.
Podczas tworzenia zestawów dostępności użyj maksymalnej liczby domen błędów i dostępnych domen aktualizacji. Jeśli na przykład wdrożysz więcej niż dwie maszyny wirtualne w jednym zestawie dostępności, użyj maksymalnej liczby domen błędów (trzy). I używaj wystarczającej liczby domen aktualizacji, aby ograniczyć wpływ potencjalnych awarii sprzętu fizycznego, awarii sieci lub przerw w dostawie prądu oprócz planowanej konserwacji platformy Azure. Domyślna liczba domen błędów to dwie i nie można jej później zmienić w trybie online.
We wdrożeniu zestawu dostępności każdy składnik systemu SAP musi znajdować się we własnym zestawie dostępności. Usługi centralne SAP, baza danych i maszyny wirtualne aplikacji powinny znajdować się we własnych zestawach dostępności.
W przypadku korzystania z grup umieszczania w pobliżu platformy Azure we wdrożeniu zestawu dostępności upewnij się, że wszystkie trzy składniki SAP (usługi centralne, serwer aplikacji i baza danych) znajdują się w tej samej grupie umieszczania w pobliżu.
Jeśli używasz grup umieszczania w pobliżu, użyj jednej dla każdej identyfikacji systemu SAP (SID). Grupy nie obejmują stref dostępności ani regionów świadczenia usługi Azure.
W przypadku korzystania z grup umieszczania w pobliżu platformy Azure we wdrożeniu stref dostępności upewnij się, że dwa składniki SAP (usługi centralne i serwer aplikacji) znajdują się w tej samej grupie umieszczania w pobliżu. Maszyny wirtualne bazy danych w dwóch strefach nie są już częścią grup umieszczania w pobliżu. Grupy umieszczania w pobliżu dla każdej strefy są ograniczone do wdrożenia maszyny wirtualnej z uruchomionymi wystąpieniami sap ASCS i SCS. Zaletą tej konfiguracji jest większa elastyczność zmiany rozmiaru maszyn wirtualnych. Możesz również łatwo przełączyć się na nowe typy maszyn wirtualnych w warstwie systemu DBMS lub warstwie aplikacji systemu SAP.
Platforma Azure nie obsługuje łączenia usługi ASCS i wysokiej dostępności bazy danych w jednym klastrze Pacemaker systemu Linux. Rozdziel je na poszczególne klastry. W parach maszyn wirtualnych można połączyć aż pięć klastrów usług centralnych.
Użyj usługa Load Balancer w warstwie Standardowa przed klastrami ASCS i baz danych.
Uruchom wszystkie systemy produkcyjne na dyskach SSD w warstwie Premium platformy Azure i użyj usługi Azure NetApp Files lub Azure Ultra Disk Storage. Upewnij się co najmniej, że dysk systemu operacyjnego znajduje się w warstwie Premium, dzięki czemu można poprawić wydajność i uzyskać najlepszą umowę SLA.
Wdróż obie maszyny wirtualne w parze wysokiej dostępności w zestawie dostępności lub w strefach dostępności. Upewnij się, że te maszyny wirtualne mają ten sam rozmiar i mają tę samą konfigurację magazynu.
Użyj natywnej technologii replikacji bazy danych, aby zsynchronizować bazę danych w parze o wysokiej dostępności.
Użyj jednej z następujących usług, aby uruchomić klastry usług centralnych SAP, w zależności od systemu operacyjnego:
Klaster Pacemaker systemu SUSE Linux Enterprise Server obsługuje agenta ogrodzenia platformy Azure i aż trzy urządzenia izolacji węzłów.
Klaster Pacemaker systemu Red Hat Enterprise Linux obsługuje agenta ogrodzenia platformy Azure i nie obsługuje urządzeń izolacji węzłów.
Klaster systemu Windows.
Oprogramowanie klastra spoza firmy Microsoft z certyfikatem SAP.
Skonfiguruj parametry limitu czasu klastra zgodnie z zaleceniami w dokumentacji dla centralnych usług i klastrów baz danych.
Magazyn dla obciążeń SAP
Wybierz odpowiednie opcje magazynowania podczas projektowania pod kątem odporności w obciążeniu SAP. Odpowiedni projekt usługi Azure Storage dla obciążeń SAP może zminimalizować opóźnienia i zmaksymalizować przepływność. Weź pod uwagę implementację i sposób, w jaki poniższe wskazówki mogą pomóc w podejmowaniu decyzji dotyczących architektury dla rozwiązania SAP w ramach implementacji platformy Azure. Aby uzyskać więcej informacji, zobacz Typy magazynu platformy Azure dla obciążeń SAP.
Oprogramowanie SAP HANA należy uruchomić na platformie Azure tylko w przypadku typów magazynu certyfikowanych przez oprogramowanie SAP. W niektórych konfiguracjach dysków należy uruchomić pewne woluminy. Na przykład konfiguracje mogą włączać akcelerator zapisu lub używać magazynu SSD w warstwie Premium. Należy również upewnić się, że system plików uruchomiony w magazynie jest zgodny z systemem DBMS uruchomionym na maszynie. Aby uzyskać więcej informacji, zobacz Storage configurations for SAP HANA (Konfiguracje magazynu dla oprogramowania SAP HANA).
Oprócz dysków danych zarządzanych platformy Azure dołączonych do maszyn wirtualnych różne natywne rozwiązania magazynu udostępnionego platformy Azure uruchamiają aplikacje SAP na platformie Azure. Konfiguracja wysokiej dostępności może się różnić, ponieważ usługa Azure Site Recovery nie obsługuje niektórych usług magazynu dostępnych na platformie Azure. Użyj następujących typów magazynu dla obciążeń SAP.
Typ magazynu Obsługa konfiguracji wysokiej dostępności Dyski udostępnione platformy Azure (magazyn lokalnie nadmiarowy (LRS) lub magazyn strefowo nadmiarowy (ZRS)) Klaster trybu failover systemu Windows Server 2022. Aby uzyskać szczegółowe informacje na temat konfiguracji, zobacz Projektowanie wysokiej dostępności oprogramowania SAP przy użyciu klastra trybu failover systemu Windows Server 2022. System plików NFS w usłudze Azure Files (LRS lub ZRS) Klaster oparty na programie Pacemaker w środowiskach systemu Linux. Pamiętaj, aby sprawdzić dostępność systemu plików NFS w różnych regionach. System plików NFS w usłudze Azure NetApp Files Klaster oparty na programie Pacemaker w środowiskach systemu Linux. Aby uzyskać więcej informacji, zobacz Azure NetApp Files for SAP VMs (Usługa Azure NetApp Files dla maszyn wirtualnych SAP). Protokół SMB w usłudze Azure Files (LRS lub ZRS) Klaster trybu failover systemu Windows Server 2022. Aby uzyskać szczegółowe informacje na temat konfiguracji, zobacz Instalowanie oprogramowania SAP NetWeaver o wysokiej dostępności za pomocą protokołu SMB usługi Azure Files. Protokół SMB w usłudze Azure NetApp Files Klaster trybu failover systemu Windows Server 2022. Aby uzyskać szczegółowe informacje o konfiguracji, zobacz Wysoka dostępność oprogramowania SAP NetWeaver z usługą Azure NetApp Files (SMB) dla aplikacji SAP. Zamiast natywnych usług magazynu udostępnionego platformy Azure można użyć tradycyjnych klastrów NFS (opartych na replikacji urządzeń blokowych replikowanych rozproszonych), GlusterFS lub udostępnionego woluminu klastra z usługą Miejsca do magazynowania Direct jako alternatywnego rozwiązania magazynu udostępnionego do uruchamiania obciążeń SAP na platformie Azure. Te opcje są szczególnie przydatne, gdy natywne usługi magazynu udostępnionego platformy Azure nie są dostępne w docelowym regionie świadczenia usługi Azure lub nie obsługują architektury docelowej. Aby uzyskać więcej informacji na temat dostępności usługi storage, zobacz Produkty platformy Azure według regionów.
Aby uzyskać informacje o opcjach magazynowania dostępnych dla obciążeń SAP na platformie Azure, zobacz Zalecenia i wskazówki dotyczące usługi Storage dotyczące konfigurowania odzyskiwania po awarii.
Tworzenie kopii zapasowej i przywracanie
W poniższych sekcjach opisano zagadnienia dotyczące projektowania i zalecenia dotyczące tworzenia kopii zapasowych i przywracania w scenariuszu sap.
Chociaż tworzenie kopii zapasowych i przywracanie nie jest zwykle uznawane za odpowiednie rozwiązanie o wysokiej dostępności dla produkcyjnego obciążenia SAP, technologia zapewnia inne korzyści. Większość firm korzystających z aplikacji SAP musi przestrzegać przepisów dotyczących zgodności, które wymagają długoterminowego przechowywania kopii zapasowych. W innych scenariuszach należy również utworzyć kopię zapasową, z której można przywrócić. W tych wskazówkach przyjęto założenie, że utworzono już tworzenie kopii zapasowych i przywracanie i przestrzegasz najlepszych rozwiązań dotyczących aplikacji SAP, co oznacza, że można wykonywać następujące czynności:
Wykonaj odzyskiwanie do punktu w czasie dla produkcyjnych baz danych w dowolnym momencie w przedziale czasu spełniającym cel czasu odzyskiwania. Odzyskiwanie do punktu w czasie zwykle zapewnia ochronę przed błędami operatora, takimi jak usuwanie danych w warstwie DBMS lub za pośrednictwem systemu SAP.
Zachowaj magazyn, aby zachować długoterminowe kopie zapasowe w celu spełnienia przepisów dotyczących zgodności.
Użyj kopii zapasowych bazy danych, aby sklonować system SAP i przywrócić kopie zapasowe na innym serwerze lub maszynie wirtualnej.
Użyj produkcyjnych danych bazy danych z kopii zapasowych bazy danych, aby odświeżyć systemy nieprodukcyjne.
Tworzenie kopii zapasowych serwerów aplikacji SAP i maszyn wirtualnych, dysków lub migawek maszyn wirtualnych.
Tworzenie kopii zapasowej systemu SAP HANA z włączoną replikacją.
Tworzenie kopii zapasowych migawek wystąpień bazy danych SAP HANA.
Jeśli tworzysz kopię zapasową i przywracasz lokalnie, musisz przenieść te możliwości do systemów SAP na platformie Azure. Jeśli podoba Ci się bieżące rozwiązanie, sprawdź, czy dostawca kopii zapasowych obsługuje wdrożenia platformy Azure, czy ma rozwiązanie typu oprogramowanie jako usługa (SaaS) dla platformy Azure.
Platforma Azure udostępnia usługę SaaS o nazwie Azure Backup, która tworzy migawki maszyn wirtualnych i zarządza strumieniowymi kopiami zapasowymi programu SQL Server i SAP HANA . Jeśli używasz usługi Azure NetApp Files do przechowywania baz danych SAP HANA, możesz uruchamiać kopie zapasowe na podstawie migawek magazynu spójnych na platformie HANA.
Możesz również użyć usługi Azure Backup do tworzenia kopii zapasowych baz danych z włączoną replikacją systemu SAP HANA (HSR). Usługa Azure Backup automatycznie zarządza kopiami zapasowymi w przypadku przejścia w tryb failover i eliminuje konieczność ręcznej interwencji. Kopia zapasowa udostępnia również następujące kopię zapasową:
Natychmiastowa ochrona bez korygowania pełnych kopii zapasowych, dzięki czemu można chronić wystąpienia platformy HANA lub węzły konfiguracji HSR jako pojedynczy kontener HSR.
Zaletą natychmiastowej kopii zapasowej i natychmiastowego przywracania.
Spójne na platformie HANA podejście oparte na migawkach, które integruje się z rozwiązaniem Backint dla platformy SAP HANA. Możesz użyć opcji Kopia zapasowa jako pojedynczy produkt dla całego środowiska HANA i dowolnego rozmiaru bazy danych.
Aby uzyskać więcej informacji, zobacz System bazy danych SAP HANA z włączoną replikacją i tworzenie kopii zapasowej migawki wystąpienia SAP HANA.
Zalecenia dotyczące projektowania kopii zapasowych i przywracania
Za pomocą usługi Azure Backup można utworzyć kopię zapasową serwera aplikacji SAP i maszyn wirtualnych usług centralnych.
Możesz użyć kopii zapasowej sap HANA dla wdrożeń HANA, które są do 8 TB. Aby uzyskać więcej informacji, zobacz Macierz obsługi tworzenia kopii zapasowych baz danych SAP HANA na maszynach wirtualnych platformy Azure.
Jeśli używasz rozwiązania do tworzenia kopii zapasowych infrastruktury jako usługi, należy określić rozmiar infrastruktury kopii zapasowej, aby zapewnić jednoczesne tworzenie kopii zapasowych wszystkich systemów o rozmiarze produkcyjnym lub, podobnie jak w rzeczywistym scenariuszu, w oczekiwanym przedziale czasu. Użyj konfiguracji produkcyjnej lub podobnej konfiguracji dla obszarów, takich jak sieć i zabezpieczenia.
Przetestuj czas tworzenia kopii zapasowej i odzyskiwania, aby sprawdzić, czy spełniają one wymagania celu czasu odzyskiwania, aby przywrócić wszystkie systemy jednocześnie po awarii.
Najlepiej unikać ściągania kopii zapasowych z platformy Azure do lokalnej infrastruktury kopii zapasowych, szczególnie w przypadku dużych baz danych. Takie podejście może mieć wpływ na przepustowość używaną przez obwody usługi ExpressRoute.
Przetestuj obciążenie narzędzi do tworzenia kopii zapasowych i odzyskiwania w ramach planu testów wydajnościowych.
Odzyskiwanie po awarii
W poniższych sekcjach opisano zagadnienia dotyczące projektowania i zalecenia dotyczące odzyskiwania po awarii w scenariuszu SAP.
Zagadnienia dotyczące projektowania odzyskiwania po awarii
Mapa regionów platformy Azure zawiera ponad 65 regionów świadczenia usługi Azure, a nie wszystkie z nich uruchamiają te same usługi. W przypadku większych wdrożeń oprogramowania SAP, zwłaszcza tych, które korzystają z platformy SAP HANA, poszukaj regionów platformy Azure, które oferują maszyny wirtualne z serii M platformy Azure lub maszyny wirtualne z serii Mv2. Usługa Azure Storage łączy również różne regiony, aby replikować mniejszy podzestaw typów magazynu do innego regionu. Aby uzyskać więcej informacji, zobacz Omówienie sparowanych regionów platformy Azure.
Główne wyzwania związane z parowaniem regionów platformy Azure dla obciążeń SAP to:
Pary nie zawsze są spójne z usługami maszyn wirtualnych serii M ani Mv2. Wiele organizacji, które wdrażają swoje systemy SAP, nie korzysta z sparowanych regionów platformy Azure. Zamiast tego wybierają regiony na podstawie dostępności wymaganych typów maszyn wirtualnych.
Magazyn standardowy można replikować między sparowanych regionów, ale nie można użyć magazynu w warstwie Standardowa do przechowywania baz danych ani wirtualnych dysków twardych. Kopie zapasowe można replikować tylko między sparowanych regionów, których używasz. W przypadku wszystkich innych danych uruchom replikację przy użyciu natywnych funkcji systemu DBMS, takich jak zawsze włączone programu SQL Server lub replikacja systemu SAP HANA. Użyj kombinacji usługi Site Recovery, narzędzi, takich jak
rsynclubrobocopy, i innego oprogramowania innego niż Microsoft dla warstwy aplikacji SAP.W przypadku awarii wielu klientów w regionie świadczenia usługi Azure przełączy się w tryb failover do odpowiedniego sparowanego regionu odzyskiwania po awarii. Taka sytuacja prowadzi do konkurencji zasobów w celu przywrócenia nieaktywnych maszyn wirtualnych w regionie odzyskiwania po awarii. Obejście polega na uruchamianiu systemów nieprodukcyjnych w regionie odzyskiwania po awarii i używaniu tych samych zasobów do hostowania replik odzyskiwania po awarii systemów produkcyjnych. To podwójne zastosowanie infrastruktury platformy Azure w regionie odzyskiwania po awarii pomaga uniknąć ograniczeń pojemności zasobów.
Innym ważnym zagadnieniem jest zabezpieczenie wymaganej pojemności operacyjnej w regionie awarii. Jeśli wystąpi awaria, może być konieczne uruchomienie aplikacji SAP przez minimalny przedział czasu z minimalną pojemnością IT i krytycznymi zasobami ludzkimi tylko podczas pracy w celu odzyskania normalnego działania w regionie podstawowym. Ta strategia wymaga minimalnej infrastruktury IT dostępnej w regionie odzyskiwania po awarii.
Po zdefiniowaniu regionów platformy Azure należy wybrać wzorzec wdrożenia:
Czy wdrożysz systemy produkcyjne w regionie podstawowym?
Czy systemy SAP nieprodukcyjne zostaną wdrożone w regionie odzyskiwania po awarii?
Czy użyjesz architektury, która grupuje wszystkie systemy SAP w regionie podstawowym? Ta konfiguracja zapewnia, że region odzyskiwania po awarii jest używany tylko do odzyskiwania po awarii.
Większość organizacji używa obu regionów dla systemów operacyjnych SAP. Organizacje, które uruchamiają pełne kopie systemów produkcyjnych jako systemy testowe regresji biznesowej, zwykle planują używać systemu testowego regresji biznesowej firmy SAP jako celu odzyskiwania po awarii.
Po wybraniu regionu odzyskiwania po awarii upewnij się, że masz łączność usługi ExpressRoute z tym regionem. Jeśli masz wiele obwodów usługi ExpressRoute łączących się z platformą Azure, co najmniej jeden z tych obwodów musi nawiązać połączenie z podstawowym regionem świadczenia usługi Azure. Inne powinny łączyć się z regionem odzyskiwania po awarii. Ten typ architektury łączy Cię z siecią platformy Azure w innym obszarze geograficznym lub geopolitycznym i pomaga chronić połączenie, jeśli katastrofa wpłynie na jeden z regionów świadczenia usługi Azure.
Niektóre organizacje używają kombinacji architektury wysokiej dostępności i odzyskiwania po awarii, która grupuje wysoką dostępność z odzyskiwaniem po awarii w tym samym regionie świadczenia usługi Azure. Jednak grupowanie wysokiej dostępności z odzyskiwaniem po awarii nie jest idealne. Strefy dostępności platformy Azure obsługują tę architekturę. Odległość między strefami dostępności w jednym regionie świadczenia usługi Azure nie jest tak duża, jak odległość między dwoma regionami świadczenia usługi Azure, więc klęska żywiołowa może zagrozić usługom aplikacji w regionie, w którym występuje. Należy również wziąć pod uwagę opóźnienie między serwerami aplikacji SAP i serwerami baz danych. Zgodnie z notą SAP 1100926, czas dwukierunkowy krótszy lub równy 0,3 ms jest dobrą wartością, a czas krótszy lub równy 0,7 ms jest umiarkowaną wartością. W przypadku stref z dużymi opóźnieniami mają procedury operacyjne, aby zapewnić, że serwery aplikacji SAP i serwery baz danych są zawsze uruchamiane w tej samej strefie. Organizacje wybierają tę architekturę z następujących powodów:
Zgodność jest wystarczająca w przypadku konfiguracji, które obsługują mniejsze odległości między wdrożeniem produkcyjnym a celem odzyskiwania po awarii.
Niezależność danych jest czynnikiem.
Czynniki geopolityczne są zaangażowane.
Jest to opcja o niskich kosztach, która obsługuje awarie strefowe, czasami w połączeniu z transferem kopii zapasowych do regionu pomocniczego w przypadku klęsk żywiołowych, które mają wpływ na duży promień.
Innym czynnikiem do rozważenia podczas wybierania regionu odzyskiwania po awarii jest cel punktu odzyskiwania i cel czasu odzyskiwania w trybie failover w lokacji odzyskiwania po awarii. Im większa odległość między regionem produkcyjnym a regionami odzyskiwania po awarii, tym większe jest opóźnienie sieci. Replikacja asynchroniczna między regionami świadczenia usługi Azure, ale opóźnienie sieci może mieć wpływ na przepływność, którą można replikować i cel celu punktu odzyskiwania. Aby zminimalizować cel punktu odzyskiwania, możesz użyć połączonej architektury wysokiej dostępności i odzyskiwania po awarii. Jednak ta konfiguracja stanowi potencjalnie wyższe ryzyko związane z klęskami żywiołowymi na dużą skalę.
Zalecenia dotyczące projektowania odzyskiwania po awarii
Upewnij się, że routing międzydomenowy bezklasowy (CIDR) dla podstawowej sieci wirtualnej nie powoduje konfliktu ani nie nakłada się na trasę CIDR sieci wirtualnej lokacji odzyskiwania po awarii.
Skonfiguruj połączenia usługi ExpressRoute ze środowiska lokalnego do podstawowych i pomocniczych regionów odzyskiwania po awarii platformy Azure.
Rozważ skonfigurowanie połączeń sieci VPN ze środowiska lokalnego do podstawowych i pomocniczych regionów odzyskiwania po awarii platformy Azure. Użyj tej metody jako alternatywy do korzystania z usługi ExpressRoute.
Użyj usługi Site Recovery, aby replikować serwer aplikacji do lokacji odzyskiwania po awarii. Usługa Site Recovery może również pomóc replikować maszyny wirtualne klastra usług centralnych do lokacji odzyskiwania po awarii. Podczas wywoływania odzyskiwania po awarii należy ponownie skonfigurować klaster Pacemaker systemu Linux w lokacji odzyskiwania po awarii. Na przykład może być konieczne zastąpienie wirtualnego adresu IP lub pliku SBD albo uruchomienie polecenia corosync.conf.
Replikowanie zawartości magazynu kluczy, takich jak certyfikaty, wpisy tajne lub klucze w różnych regionach, aby można było odszyfrować dane w regionie odzyskiwania po awarii.
Użyj replikacji między regionami w usłudze Azure NetApp Files , aby zsynchronizować woluminy plików między regionem podstawowym a regionem odzyskiwania po awarii.
Użyj natywnej replikacji bazy danych, a nie usługi Site Recovery, aby zsynchronizować dane z lokacją odzyskiwania po awarii.
Komunikacja równorzędna sieci wirtualnych podstawowej i odzyskiwania po awarii. Na przykład w przypadku replikacji systemu HANA sieć wirtualna SAP HANA DB musi być równorzędna z siecią wirtualną SAP HANA DB w lokacji odzyskiwania po awarii w sieci wirtualnej SAP HANA DB.
Jeśli używasz magazynu usługi Azure NetApp Files dla wdrożeń SAP, co najmniej utwórz dwa konta usługi Azure NetApp Files w warstwie Premium w dwóch regionach.
Rozważ grupowanie systemów na podstawie ich znaczenia biznesowego i zależności w pobliżu na podstawie wydajności aplikacji. Aby zminimalizować efekt biznesowy awarii regionalnej, wdróż każdą grupę w osobnym regionie w sparowanej konstrukcji regionu. Na przykład, aby zminimalizować wpływ awarii regionalnej, można wdrożyć dwa krytyczne systemy składowe ERP Central, które obsługują dwa różne jednostki biznesowe, w Południowej Wielkiej Brytanii i Na Zachodzie Wielkiej Brytanii.