Udostępnij za pośrednictwem

Ciągłość działalności biznesowej i odzyskiwanie po awarii na potrzeby migracji sap

  • Artykuł

W tym artykule omówiono niektóre zagadnienia i zalecenia zdefiniowane w obszarze projektowania strefy docelowej platformy Azure dla strategii BCDR. Ten artykuł może pomóc w zrozumieniu unikatowych ograniczeń w dowolnej strefie docelowej, która obsługuje platformę SAP. Ponieważ oprogramowanie SAP jest platformą o kluczowym znaczeniu, należy również zapoznać się z innymi wskazówkami przedstawionymi w sekcji Obszary projektowania strefy docelowej platformy Azure w tej dokumentacji i uwzględnić ją w projekcie.

Scenariusz i zakres

Twoja architektura musi uwzględniać zasady, które dotyczą lokalnych scenariuszy ciągłości działania i odzyskiwania po awarii (BCDR). Te zasady dotyczą również platformy Azure. Główną różnicą jest to, że platforma Azure może mieć większą pojemność sprzętową niż środowisko lokalne, aby zrekompensować awarię hosta. Możesz automatycznie odzyskać nawet największe maszyny wirtualne platformy Azure, konfigurując 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 wdrożono systemy lokalne lub sprzęt bez systemu operacyjnego przy użyciu automatycznych konfiguracji klastra trybu failover, 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 awarii.
  • Cele punktu odzyskiwania (RPO) dla scenariuszy awarii.
  • Zadania zarządzania operacjami i cyklem życia oraz technologia wypełniana 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.

Porada

Zgadzam się na rozwiązanie wysokiej dostępności i odzyskiwania po awarii (HADR) dla każdego archetypu w środowisku SAP na wczesnym etapie. Upewnij się, że wszystkie składniki SAP są objęte odpowiednim rozwiązaniem.

Skonfiguruj usługę HADR na platformie Azure na wczesnym etapie, w co najmniej jednym krajobrazie i kontynuuj jej działanie. Daje to zespołom możliwość uzyskania doświadczenia w zakresie technologii, które są zaangażowane, które mogą różnić się od istniejących technologii. Wczesne konfigurowanie usługi HADR może również pomóc w opracowaniu i rozwinięciu standardowych procedur operacyjnych (SOP).

Zaplanuj pełną dostępność, odzyskiwanie po awarii i ochronę kopii zapasowych obciążeń produkcyjnych, gdy tylko system jest na żywo.

W tym artykule opisano następujące aspekty strategii 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 regionalnym i regionalnym odzyskiwaniem po awarii.

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

W celu zapewnienia wysokiej dostępności celem jest zapewnienie dostępności pojedynczego punktu awarii oprogramowania SAP, takiego jak:

  • Systemy zarządzania bazami danych.
  • Pojedyncze punkty awarii w aplikacji, takie jak SAP ABAP i ASCS + SCS. Przykłady 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 oprogramowania. Zastosuj dostępność do wszystkich niezbędnych zadań zarządzania cyklem życia, takich jak stosowanie poprawek systemu operacyjnego na maszynach wirtualnych, systemach 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 klaster trybu failover systemu Windows Server obsługuje tryb failover. W systemie Linux narzędzie Pacemaker lub narzędzia innych firm, takie jak SIOS Protection Suite i Veritas InfoScale, obsługują tryb failover. Za pomocą platformy Azure można wdrożyć tylko konfigurację wysokiej dostępności podzbioru we własnym centrum danych.

Aby dowiedzieć się więcej o tym, jak platforma Azure obsługuje oprogramowanie SAP, zobacz Obsługiwane scenariusze dla 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ą podstawowe i pomocnicze maszyny wirtualne. Platforma Azure nie obsługuje architektur, w których podstawowe i pomocnicze maszyny wirtualne współużytkuje magazyn danych systemu DBMS. Nie pomoc techniczna platformy Azure również dzienników transakcji lub ponownego wdrażania. Przewodnią zasadą jest użycie dwóch niezależnych stosów magazynu, nawet jeśli są oparte na udziałach systemu plików sieciowych (NFS). To podejście jest głównym ograniczeniem podczas porównywania możliwych elementów lokalnych z możliwymi elementami na platformie Azure.

Platforma Azure udostępnia inne opcje, ponieważ obsługuje udostępnianie NFS lub bloku komunikatów serwera. Dysków udostępnionych platformy Azure można używać w systemie Windows na potrzeby 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 systemu DBMS. Platforma Azure nie obsługuje obecnie 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 systemu DBMS wymaga wirtualnego adresu IP dla klastra trybu failover. Typowym wyjątkiem jest użycie funkcji Oracle Data Guard. Nie wymaga wirtualnego adresu IP. Azure Load Balancer powinien obsługiwać wirtualny adres IP we wszystkich innych przypadkach. Jedną z zasad projektowania jest użycie jednego modułu równoważenia obciążenia na konfigurację klastra. Zalecamy użycie standardowej wersji modułu równoważenia obciążenia. Aby uzyskać więcej informacji, zobacz Łączność z publicznym punktem końcowym dla maszyn wirtualnych korzystających z usługi Azure usługa Load Balancer w warstwie Standardowa w scenariuszach wysokiej dostępności oprogramowania SAP.

Aby uzyskać więcej informacji i opcji, zobacz architektura i scenariusze wysokiej dostępności oprogramowania SAP NetWeaver.

Poniżej przedstawiono umowy SLA na poziomie platformy dla różnych opcji wdrażania o wysokiej dostępności. Partnerzy dostarczający usługi zarządzane zapewniają umowę SLA na poziomie aplikacji.

Warstwa Scenariusz wysokiej dostępności Umowa SLA platformy
Warstwa 1 Strefa dostępności 99,99%
Warstwa 2 Zestaw dostępności 99,95%
Warstwa 3 Pojedyncza maszyna wirtualna (samonaprawiania) 99,9%

Aby uzyskać więcej informacji, zobacz następną sekcję.

Zestawy dostępności platformy Azure a strefy dostępności

Przed wdrożeniem infrastruktury wysokiej dostępności i w zależności od wybranego regionu określ, czy wdrożyć za pomocą zestawu dostępności platformy Azure, czy strefy dostępności. Główne różnice dotyczące maszyn wirtualnych wdrożonych z zestawem 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ż host jest definiowany przez pierwszą maszynę wirtualną wdrożona w zestawie. Jednym z przykładowych wyników jest to, że nie będzie można połączyć maszyn wirtualnych serii M i serii E w jeden zestaw dostępności.

Zaletą wdrażania architektury wysokiej dostępności w różnych strefach dostępności jest to, że umowa dotycząca poziomu usług (SLA) dla maszyn wirtualnych może być wyższa. Aby uzyskać szczegółowe informacje, 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.

W przypadku wybrania podejścia do wdrażania strefowego należy wziąć pod uwagę wpływ opóźnienia między strefami dla wybranego regionu świadczenia usługi Azure między serwerem aplikacji i bazą danych a między dwoma węzłami bazy danych na wybór projektu wydajności i architektury.

Jeśli używasz aktywnego/pasywnego wdrożenia strefowego dla warstwy serwera aplikacji (serwery aplikacji muszą łączyć się z bazą danych w tej samej strefie dostępności), automatyzacja kompilacji i SOP w celu umożliwienia szybkiego i zautomatyzowanego odzyskiwania, jeśli istnieje tryb failover bazy danych.

Jeśli używasz stref dostępności w rozwiązaniu SAP, zaprojektuj również wszystkie inne usługi platformy Azure i składniki infrastruktury w środowisku SAP w celu zapewnienia nadmiarowości strefy, aby zapewnić rzeczywistą nadmiarowość strefy. Przykłady usług i składników do uwzględnienia to bramy usługi Azure ExpressRoute, Azure Load Balancer, Azure Files, Azure NetApp Files, zwrotny serwer proxy, zapory, oprogramowanie antywirusowe i infrastruktura kopii zapasowych.

Zalecenia dotyczące projektowania pod kątem wysokiej dostępności

  • Platforma Azure oferuje kilka opcji ułatwiania spełnienia 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ć informacje o umowach SLA dla maszyn wirtualnych, zestawów dostępności i stref dostępności, zobacz umowa SLA dla Virtual Machines.

  • Podczas wdrażania maszyn wirtualnych w zestawie dostępności dopasowanie do domen 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 maszyny wirtualne są tworzone 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 wdrażać zestawów dostępności platformy Azure w strefie dostępności platformy Azure, chyba że używasz grup umieszczania w pobliżu.

    W przypadku wybrania podejścia do wdrażania strefowego system SAP DBMS, usługi centralne i warstwy aplikacji są uruchamiane w różnych strefach dostępności. Jednak każda strefa dostępności najprawdopodobniej będzie mieć wiele serwerów aplikacji. W tym scenariuszu serwery aplikacji w każdej strefie nie korzystają automatycznie z domen błędów i domen aktualizacji. Te korzyści można osiągnąć, korzystając z zestawów dostępności zgodnie z opisem w grupach umieszczania w pobliżu platformy Azure w celu uzyskania optymalnego opóźnienia sieci za pomocą oprogramowania 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 (trzech) i wystarczającej liczby domen aktualizacji, aby ograniczyć wpływ potencjalnych awarii sprzętu fizycznego, awarii sieci lub przerw w działaniu zasilania, oprócz planowanej konserwacji platformy Azure. Domyślna liczba domen błędów to dwie i nie można jej zmienić w trybie online później.

  • 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 wszystkie trzy składniki SAP (centralne usługi, serwer aplikacji i baza danych) powinny znajdować się w tej samej grupie umieszczania w pobliżu.

  • Jeśli używasz grup umieszczania w pobliżu, użyj jednego identyfikatora SID sap. 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 dwa składniki SAP (usługi centralne i serwer aplikacji) powinny znajdować 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 na strefę są ograniczone do wdrożenia maszyny wirtualnej, która uruchamia wystąpienia SAP ASCS + SCS. Zaletą tej konfiguracji jest większa elastyczność zmiany rozmiaru maszyn wirtualnych. Łatwiej jest również przejść do nowych typów maszyn wirtualnych w warstwie DBMS lub warstwie aplikacji systemu SAP.

  • Platforma Azure nie obsługuje obecnie łączenia usługi ASCS i wysokiej dostępności bazy danych w jednym klastrze programu Pacemaker systemu Linux. Rozdziel je na poszczególne klastry. Można połączyć aż pięć klastrów usług centralnych w dwóch maszynach wirtualnych.

  • Użyj jednostki SKU usługa Load Balancer w warstwie Standardowa przed klastrami usługi ASCS i bazy danych.

  • Uruchom wszystkie systemy produkcyjne na dyskach SSD zarządzanych w warstwie Premium i używaj Azure NetApp Files lub Ultra Disk Storage. Co najmniej dysk systemu operacyjnego powinien znajdować się w warstwie Premium, dzięki czemu można osiągnąć lepszą wydajność i najlepszą umowę SLA.

  • Wdróż obie maszyny wirtualne w parze o wysokiej dostępności w zestawie dostępności lub w strefach dostępności. Te maszyny wirtualne powinny mieć taki sam rozmiar i mieć 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:

  • Skonfiguruj parametry limitu czasu klastra zgodnie z zaleceniami w dokumentacji dla usług centralnych i klastrów baz danych.

Magazyn dla obciążeń SAP

  • Wybór odpowiednich opcji magazynowania jest częścią projektowania pod kątem odporności dla obciążenia SAP. Projekt obciążeń SAP w usłudze Azure Storage ma na celu zachowanie opóźnienia do minimum i zmaksymalizowania przepływności. Weź pod uwagę implementację i sposób, w jaki poniższe wskazówki mogą pomóc w podejmowaniu decyzji dotyczących architektury dla oprogramowania SAP w implementacji platformy Azure. Aby uzyskać informacje na temat różnych typów magazynu i ich zgodności z obciążeniami i składnikami SAP, zobacz Typy usługi Azure Storage dla obciążeń SAP.

  • Oprogramowanie SAP HANA należy uruchomić na platformie Azure tylko w typach magazynu, które są certyfikowane przez oprogramowanie SAP. Należy pamiętać, że niektóre woluminy muszą być uruchamiane w niektórych konfiguracjach dysków, jeśli ma to zastosowanie. Te konfiguracje obejmują włączanie akceleratora zapisu i korzystanie z magazynu w warstwie Premium. Należy również upewnić się, że system plików działający w magazynie jest zgodny z systemem DBMS uruchomionym na maszynie. Aby uzyskać więcej informacji, zobacz Konfiguracje magazynu dla platformy SAP HANA.

  • Oprócz dysków danych zarządzanych platformy Azure dołączonych do maszyn wirtualnych różne rozwiązania magazynu udostępnionego na platformie Azure są używane do uruchamiania aplikacji SAP na platformie Azure. Konfiguracja wysokiej dostępności może się różnić, ponieważ niektóre usługi magazynu dostępne na platformie Azure nie są obsługiwane przez usługę Azure Site Recovery. Następujące typy magazynów są zwykle używane w przypadku obciążeń SAP.

    Typ magazynu Obsługa konfiguracji wysokiej dostępności
    Dyski udostępnione platformy Azure (LRS lub ZRS) Klaster trybu failover systemu Windows Server. Aby uzyskać szczegółowe informacje na temat konfiguracji, zobacz Projektowanie platformy SAP HA z klastrem trybu failover systemu Windows Server .
    System plików NFS w 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.
    NFS w systemie Azure NetApp Files Klaster oparty na programie Pacemaker w środowiskach systemu Linux. Aby uzyskać więcej informacji, zobacz Azure NetApp Files dla maszyn wirtualnych SAP.
    Protokół SMB w Azure Files (LRS lub ZRS) Klaster trybu failover systemu Windows Server. Aby uzyskać szczegółowe informacje na temat konfiguracji, zobacz Wysoka dostępność oprogramowania SAP NetWeaver na maszynach wirtualnych platformy Azure w systemie Windows z Azure Files Premium SMB dla aplikacji SAP.
    Protokół SMB w Azure NetApp Files Klaster trybu failover systemu Windows Server. Aby uzyskać szczegółowe informacje o konfiguracji, zobacz Wysoka dostępność oprogramowania SAP NetWeaver na maszynach wirtualnych platformy Azure w systemie Windows z 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 DRBD), GlusterFS lub udostępnionego woluminu klastra z Bezpośrednie miejsca do magazynowania 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ć informacje o dostępności usługi magazynu, zobacz Produkty platformy Azure według regionów.

  • Aby dowiedzieć się więcej o opcjach magazynowania dostępnych dla obciążeń SAP na platformie Azure, zobacz zalecenia dotyczące magazynu i wskazówki 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 uważane 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ą przechowywania kopii zapasowych przez wiele lat. Konieczne jest również utworzenie kopii zapasowej i możliwość jej przywrócenia w innych scenariuszach. Założeniem jest to, że zostały już ustanowione i są następujące najlepsze rozwiązania dotyczące tworzenia kopii zapasowych i przywracania dla aplikacji SAP, co oznacza, że można:

  • Wykonaj odzyskiwanie do punktu w czasie dla produkcyjnych baz danych w dowolnym momencie w ramie czasowej, która spełnia 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.

Podczas tworzenia kopii zapasowej i przywracania lokalnie należy zapewnić te możliwości systemom SAP na platformie Azure.

Jeśli korzystasz z bieżącego rozwiązania, sprawdź, czy dostawca kopii zapasowej obsługuje wdrożenia platformy Azure, czy ma rozwiązanie SaaS (software as a service) dla platformy Azure.

Platforma Azure udostępnia usługę SaaS do tworzenia kopii zapasowych, Azure Backup, która tworzy migawki maszyn wirtualnych i zarządza kopiami zapasowymi przesyłania strumieniowego SQL Server oraz kopiami zapasowymi sap HANA. Jeśli używasz Azure NetApp Files do przechowywania baz danych SAP HANA, możesz uruchamiać kopie zapasowe na podstawie migawek magazynu spójnych na platformie HANA.

Zalecenia dotyczące projektowania kopii zapasowych i przywracania

  • Aby utworzyć kopię zapasową serwera aplikacji SAP i maszyn wirtualnych usług centralnych, można użyć Azure Backup.

  • Możesz użyć kopii zapasowej platformy SAP HANA dla wdrożeń platformy HANA o pojemności 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 IaaS, określ rozmiar infrastruktury kopii zapasowej, aby zapewnić jednoczesne tworzenie kopii zapasowych wszystkich systemów o rozmiarze produkcyjnym lub tak jak w rzeczywistym scenariuszu, w oczekiwanym czasie i przy użyciu konfiguracji produkcyjnej lub podobnej konfiguracji pod względem sieci, zabezpieczeń itd.

  • Przetestuj czas tworzenia kopii zapasowej i odzyskiwania, aby sprawdzić, czy spełniają one wymagania dotyczące celu odzyskiwania wszystkich systemów 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. Ma to 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 dotyczące odzyskiwania po awarii

Mapa regionów platformy Azure zawiera więcej niż 65 regionów platformy 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 serii M platformy Azure lub mv2 . Usługa Azure Storage paruje 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żywać magazynu standardowego 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 SQL Server zawsze włączone lub replikacja systemu SAP HANA. Użyj kombinacji Site Recovery rsync lub robocopyi innego oprogramowania innej firmy dla warstwy aplikacji SAP.

  • Jeśli wystąpi awaria, wielu klientów dotkniętych awarią w regionie świadczenia usługi Azure będzie chciało przełączyć się w tryb failover do odpowiedniego sparowanego regionu odzyskiwania po awarii. Taka sytuacja prowadzi do konkurencji zasobów w celu wywołania uśpinych 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 przez krytyczne zasoby ludzkie tylko podczas pracy w celu odzyskania normalnego działania w regionie podstawowym. Wymaga to 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 będziesz używać 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 do obsługi systemów SAP. Organizacje, które uruchamiają pełne kopie systemów produkcyjnych jako systemy testowe regresji biznesowej, zwykle planują użyć systemu testowego regresji biznesowej platformy 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 łączyć się z podstawowym regionem świadczenia usługi Azure. Pozostałe powinny łączyć się z regionem odzyskiwania po awarii. Ten typ architektury łączy Się z siecią platformy Azure w innym obszarze geograficznym/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 przy użyciu odzyskiwania po awarii nie jest idealnym rozwiązaniem. Strefy dostępności platformy Azure obsługują tę architekturę. Ponieważ 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, 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. Na wartość SAP Note 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 związku z tym w przypadku stref z dużymi opóźnieniami należy stosować procedury operacyjne, aby zapewnić, że serwery aplikacji SAP i serwery baz danych są uruchomione w tej samej strefie przez cały czas. 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 tania opcja, która obsługuje awarie strefowe, czasami w połączeniu z transferem kopii zapasowych do regionu pomocniczego w przypadku katastrof naturalnych, które mają duży promień wpływu.

Innym czynnikiem, który należy wziąć pod uwagę 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 regionami produkcji i odzyskiwania po awarii, tym większe jest opóźnienie sieci. Mimo że replikacja asynchroniczna między regionami świadczenia usługi Azure, opóźnienie sieci może mieć wpływ na przepływność, którą można replikować i cel celu punktu odzyskiwania. Często można zminimalizować cel punktu odzyskiwania przy użyciu połączonej architektury wysokiej dostępności i odzyskiwania po awarii. Jednak ta konfiguracja stanowi potencjalnie większe ryzyko związane z klęskami żywiołowymi na dużą skalę.

Zalecenia dotyczące projektowania odzyskiwania po awarii

  • Upewnij się, że routing międzydomenowy bez klas (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.
  • Alternatywą dla korzystania z usługi ExpressRoute jest skonfigurowanie połączeń sieci VPN ze środowiska lokalnego do podstawowych i pomocniczych regionów odzyskiwania po awarii platformy Azure.
  • Użyj Site Recovery, aby replikować serwer aplikacji do lokacji odzyskiwania po awarii. Site Recovery mogą 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 musisz zastąpić adres VIP lub SBD, uruchomić plik corosync.conf itd.
  • Replikowanie zawartości magazynu kluczy, takich jak certyfikaty, wpisy tajne lub klucze w różnych regionach, dzięki czemu można odszyfrować dane w regionie odzyskiwania po awarii.
  • Użyj replikacji między regionami w Azure NetApp Files (obecnie w publicznej wersji zapoznawczej), aby zsynchronizować woluminy plików między regionem podstawowym a regionem odzyskiwania po awarii.
  • Użyj natywnej replikacji bazy danych, a nie 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 lokacji odzyskiwania po awarii.
  • Jeśli używasz Azure NetApp Files magazynu dla wdrożeń SAP, utwórz co najmniej dwa konta 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. Wdróż każdą grupę w osobnym regionie w sparowanym regionie, aby zminimalizować wpływ działalności regionalnej na awarię. Na przykład dwa krytyczne systemy ECC obsługujące dwa różne jednostki biznesowe można wdrożyć w Południowej Wielkiej Brytanii i Na Zachodzie Wielkiej Brytanii, aby zminimalizować wpływ regionalnej awarii.

Następne kroki

Opcje wdrażania oprogramowania SAP na platformie Azure