Omówienie odzyskiwania po awarii i wytyczne dotyczące infrastruktury dla obciążenia SAP

  • Artykuł

Wiele organizacji, które uruchamia krytyczne aplikacje biznesowe na platformie Azure, konfiguruje strategię wysokiej dostępności i odzyskiwania po awarii (DR). Celem wysokiej dostępności jest zwiększenie umowy SLA systemów biznesowych poprzez wyeliminowanie pojedynczych punktów awarii w podstawowej infrastrukturze systemu. Technologie wysokiej dostępności zmniejszają wpływ nieplanowanej awarii infrastruktury i pomagają w planowanej konserwacji. Odzyskiwanie po awarii jest definiowane jako zasady, narzędzia i procedury umożliwiające odzyskiwanie lub kontynuację istotnej infrastruktury technologicznej i systemów po geograficznie powszechnej klęski żywiołowej lub wywołanej przez człowieka.

Aby zapewnić wysoką dostępność obciążenia SAP na platformie Azure, maszyny wirtualne są zwykle wdrażane w zestawie dostępności, strefach dostępności lub w elastycznym zestawie skalowania w celu ochrony aplikacji przed konserwacją infrastruktury lub awarią w regionie. Jednak wdrożenie nie chroni aplikacji przed powszechną awarią w regionie. Aby chronić aplikacje przed awariami regionalnymi, należy stosować strategię odzyskiwania po awarii dla aplikacji. Odzyskiwanie po awarii to udokumentowane i ustrukturyzowane podejście, które ma pomóc organizacji w wykonywaniu procesów odzyskiwania w odpowiedzi na awarię oraz w celu ochrony lub zminimalizowania zakłóceń usług IT i promowania odzyskiwania.

Ten dokument zawiera szczegółowe informacje na temat ochrony obciążeń SAP przed katastrofą na dużą skalę przez zaimplementowanie ustrukturyzowanego podejścia odzyskiwania po awarii. Szczegóły przedstawione w tym dokumencie są na poziomie abstrakcyjnym na podstawie różnych usług platformy Azure i składników SAP. Dokładna strategia odzyskiwania po awarii i kolejność odzyskiwania dla obciążenia SAP muszą być testowane, udokumentowane i dostosowane regularnie. Ponadto dokument koncentruje się na strategii odzyskiwania po awarii na platformie Azure dla obciążenia SAP.

Ogólne zagadnienia dotyczące planu odzyskiwania po awarii

Obciążenie SAP na platformie Azure działa na maszynach wirtualnych w połączeniu z różnymi usługami platformy Azure w celu wdrożenia różnych warstw (usług centralnych, serwerów aplikacji, serwera bazy danych) typowej aplikacji SAP NetWeaver. Ogólnie rzecz biorąc, strategia odzyskiwania po awarii powinna być planowana dla całego środowiska IT działającego na platformie Azure, co oznacza również uwzględnienie aplikacji innych niż SAP. Rozwiązanie biznesowe działające w systemach SAP może nie działać jako całości, jeśli zależne usługi lub zasoby nie są odzyskiwane w lokacji odzyskiwania po awarii. Dlatego należy wymyślić dobrze zdefiniowany kompleksowy plan odzyskiwania po awarii, biorąc pod uwagę wszystkie składniki i systemy.

W przypadku odzyskiwania po awarii na platformie Azure organizacje powinny rozważyć różne scenariusze, które mogą wyzwalać tryb failover.

  • Dostępność aplikacji SAP lub procesów biznesowych.
  • Usługi platformy Azure (takie jak maszyny wirtualne, magazyn, moduł równoważenia obciążenia itp.) niedostępność w regionie z powodu powszechnego niepowodzenia.
  • Potencjalne zagrożenia i luki w zabezpieczeniach aplikacji (na przykład atak DDoS warstwy aplikacji)
  • Zgodność biznesowa wymagała zadań operacyjnych w celu przetestowania strategii odzyskiwania po awarii (na przykład wykonywania operacji odzyskiwania po awarii odzyskiwania po awarii co rok zgodnie ze zgodnością).

Aby osiągnąć cel odzyskiwania dla różnych scenariuszy, organizacja musi przedstawić cel czasu odzyskiwania (RTO) i cel punktu odzyskiwania (RPO) dla obciążenia na podstawie wymagań biznesowych. Cel czasu odzyskiwania opisuje, ile czasu aplikacja może być wyłączona, zwykle mierzona w godzinach, minutach lub sekundach. Cel punktu odzyskiwania opisuje ilość danych transakcyjnych, które są akceptowalne przez firmę do utraty w celu wznowienia normalnych operacji. Identyfikowanie celu odzyskiwania po awarii i celu punktu odzyskiwania firmy ma kluczowe znaczenie, ponieważ ułatwia optymalne projektowanie strategii odzyskiwania po awarii. Składniki (obliczenia, magazyn, baza danych itp.) związane z obciążeniem SAP są replikowane do regionu odzyskiwania po awarii przy użyciu różnych technik (usługi natywne platformy Azure, natywna technologia replikacji bazy danych, niestandardowe skrypty). Każda technika zapewnia inny cel punktu odzyskiwania, który należy uwzględnić podczas projektowania strategii odzyskiwania po awarii. Na platformie Azure możesz użyć niektórych usług natywnych platformy Azure, takich jak Azure Site Recovery, Azure Backup, które mogą ułatwić spełnienie celu czasu odzyskiwania i celu punktu odzyskiwania obciążeń SAP. Zapoznaj się z umową SLA usługi Azure Site Recovery i usługą Azure Backup , aby optymalnie dopasować się do celu punktu odzyskiwania i celu punktu odzyskiwania.

Zagadnienia dotyczące projektowania odzyskiwania po awarii na platformie Azure

Podczas projektowania rozwiązania odzyskiwania po awarii na platformie Azure należy wziąć pod uwagę różne elementy. Zasady i pojęcia, które są uważane za projektowanie lokalnych rozwiązań odzyskiwania po awarii, mają zastosowanie również do platformy Azure. Jednak na platformie Azure wybór regionów jest kluczową częścią strategii projektowania odzyskiwania po awarii. Dlatego podczas wybierania regionu odzyskiwania po awarii na platformie Azure należy pamiętać o następujących kwestiach.

  • Wymagania dotyczące zgodności biznesowej lub regulacyjnej mogą określać wymagania dotyczące odległości między lokacją podstawową a lokacją odzyskiwania po awarii. Wymóg odległości pomaga zapewnić dostępność, jeśli klęska żywiołowa wystąpi w szerszej lokalizacji geograficznej. W takim przypadku organizacja może wybrać inny region świadczenia usługi Azure jako lokację odzyskiwania po awarii. Regiony platformy Azure są często oddzielone dużą odległością, która może wynosić setki, a nawet tysiące kilometrów, takich jak w Stany Zjednoczone. Ze względu na odległość opóźnienie rundy sieci będzie wyższe, co może spowodować wyższe cel punktu odzyskiwania.

  • Klienci, którzy chcą naśladować lokalną strategię odzyskiwania po awarii metra na platformie Azure, mogą używać stref dostępności do odzyskiwania po awarii. Jednak strategia odzyskiwania po awarii między strefami może nie być wymagana odporność, jeśli istnieje geograficznie powszechna klęska żywiołowa.

  • Na platformie Azure każdy region jest sparowany z innym regionem w tej samej lokalizacji geograficznej (z wyjątkiem Brazylii Południowej). Takie podejście umożliwia platformę zapewnianą replikację zasobów w całym regionie. Korzyści wynikające z wyboru sparowanego regionu można znaleźć w dokumencie pary regionów. Jeśli organizacja zdecyduje się używać sparowanych regionów platformy Azure, należy wziąć pod uwagę kilka dodatkowych punktów dla obciążenia SAP:

    • Nie wszystkie usługi platformy Azure oferują replikację między regionami w sparowanym regionie.

    • Usługi i funkcje platformy Azure w sparowanych regionach świadczenia usługi Azure mogą nie być symetryczne. Na przykład usługi Azure NetApp Files, jednostki SKU maszyn wirtualnych, takie jak seria M dostępne w regionie podstawowym, mogą nie być dostępne w sparowanym regionie. Aby sprawdzić, czy produkt lub usługi platformy Azure są dostępne w regionie, zobacz Produkty platformy Azure według regionów.

    • Opcja GRS jest dostępna dla konta magazynu ze standardowym typem magazynu, który replikuje dane do sparowanego regionu. Jednak magazyn w warstwie Standardowa nie jest odpowiedni dla dysków SAP DBMS ani wirtualnych danych.

    • Usługa Azure Backup używana do tworzenia kopii zapasowych obsługiwanych rozwiązań może replikować kopie zapasowe tylko między sparowanych regionów. W przypadku wszystkich innych danych uruchom własne replikacje z natywnymi funkcjami systemu DBMS, takimi jak zawsze włączone programu SQL Server, replikacja systemu SAP HANA i inne usługi. Użyj kombinacji usługi Azure Site Recovery, rsync lub robocopy oraz innego oprogramowania innej firmy dla warstwy aplikacji SAP.

Odwołowanie się do wdrożenia obciążenia SAP

Po zidentyfikowaniu regionu odzyskiwania po awarii ważne jest, aby zakres podstawowych usług platformy Azure (takich jak sieć, obliczenia, magazyn) skonfigurowanych w regionie podstawowym był dostępny i można go skonfigurować w regionie odzyskiwania po awarii. Organizacja musi opracować wzorzec wdrażania odzyskiwania po awarii dla obciążenia SAP. Wzorzec wdrażania różni się i musi być zgodny z potrzebami organizacji.

  • Wdróż produkcyjne obciążenie SAP w regionie podstawowym i nieprodukcyjnym w regionie odzyskiwania po awarii.
  • Wdróż wszystkie obciążenia SAP (produkcyjne i nieprodukcyjne) w regionie podstawowym. Region odzyskiwania po awarii jest używany tylko w przypadku przejścia w tryb failover.

Poniższa architektura referencyjna przedstawia typowy system SAP NetWeaver działający na platformie Azure wraz z wysoką dostępnością w regionie podstawowym. Lokacja dodatkowa pokazana poniżej to lokacja odzyskiwania po awarii, w której systemy SAP zostaną przywrócone po wystąpieniu awarii. Oba regiony podstawowe i odzyskiwania po awarii są częścią tej samej subskrypcji. Aby uzyskać odzyskiwanie po awarii dla obciążenia SAP, należy zidentyfikować strategię odzyskiwania dla każdej warstwy SAP wraz z różnymi usługami platformy Azure używanymi przez aplikację.

Organizacje powinny planować i projektować strategię odzyskiwania po awarii dla całego środowiska IT. Zazwyczaj systemy SAP działające w środowisku produkcyjnym są zintegrowane z różnymi usługami i interfejsami, takimi jak Active Directory, DNS, aplikacja innej firmy itd. Dlatego należy uwzględnić systemy inne niż SAP i inne usługi w planowaniu odzyskiwania po awarii. Ten dokument koncentruje się na planowaniu odzyskiwania aplikacji SAP. Można jednak rozszerzyć rozmiar i zakres planowania odzyskiwania po awarii dla składników zależnych zgodnie z wymaganiami.

Disaster Recovery reference architecture for SAP workload

Składniki infrastruktury rozwiązania odzyskiwania po awarii dla obciążenia SAP

Obciążenie SAP uruchomione na platformie Azure używa różnych składników infrastruktury do uruchamiania rozwiązania biznesowego. Aby zaplanować odzyskiwanie po awarii dla takiego rozwiązania, ważne jest, aby wszystkie składniki infrastruktury skonfigurowane w regionie podstawowym są dostępne i można je również skonfigurować w regionie odzyskiwania po awarii. Podczas projektowania rozwiązania odzyskiwania po awarii dla obciążenia SAP na platformie Azure należy uwzględnić następujące składniki infrastruktury.

  • Sieć
  • Compute
  • Storage

Sieć

  • Usługa ExpressRoute rozszerza sieć lokalną na chmurę firmy Microsoft za pośrednictwem połączenia prywatnego z pomocą dostawcy łączności. Podczas projektowania architektury odzyskiwania po awarii należy uwzględnić tworzenie niezawodnej łączności sieciowej zaplecza przy użyciu geograficznie nadmiarowego obwodu usługi ExpressRoute. Zaleca się skonfigurowanie co najmniej jednego obwodu usługi ExpressRoute ze środowiska lokalnego do regionu podstawowego. A pozostałe powinny łączyć się z regionem odzyskiwania po awarii. Zapoznaj się z artykułem Projektowanie usługi Azure ExpressRoute na potrzeby odzyskiwania po awarii, w którym opisano różne scenariusze projektowania odzyskiwania po awarii dla usługi ExpressRoute.

    Uwaga

    Rozważ skonfigurowanie sieci VPN typu lokacja-lokacja (S2S) jako kopii zapasowej usługi Azure ExpressRoute. Aby uzyskać więcej informacji, zobacz Using S2S VPN as a backup for Azure ExpressRoute Private Peering (Używanie sieci VPN typu lokacja jako kopii zapasowej prywatnej komunikacji równorzędnej usługi Azure ExpressRoute).

  • Sieć wirtualna i podsieci obejmują wszystkie strefy dostępności w regionie. W przypadku odzyskiwania po awarii w dwóch regionach należy skonfigurować oddzielne sieci wirtualne i podsieci w regionie odzyskiwania po awarii. Zapoznaj się z artykułem Informacje o sieci w odzyskiwaniu po awarii maszyny wirtualnej platformy Azure, aby dowiedzieć się więcej na temat konfiguracji sieci w regionie odzyskiwania po awarii.

  • Usługa Azure usługa Load Balancer w warstwie Standardowa udostępnia elementy sieciowe do projektowania wysokiej dostępności systemów SAP. W przypadku systemów klastrowanych usługa Load Balancer w warstwie Standardowa udostępnia wirtualny adres IP usługi klastra, taki jak wystąpienia usługi ASCS/SCS i bazy danych uruchomione na maszynach wirtualnych. Aby uruchomić system SAP o wysokiej dostępności w lokacji odzyskiwania po awarii, należy utworzyć oddzielny moduł równoważenia obciążenia i odpowiednio dostosować konfigurację klastra.

  • aplikacja systemu Azure Gateway to moduł równoważenia obciążenia ruchu internetowego. Dzięki funkcjonalności zapory aplikacji internetowej dobrze nadaje się do uwidaczniania aplikacji internetowych w Internecie przy użyciu ulepszonych zabezpieczeń. aplikacja systemu Azure Gateway może obsługiwać klientów publicznych (internetowych) lub prywatnych albo obu, w zależności od konfiguracji. Aby po przejściu w tryb failover akceptować podobny przychodzący ruch HTTP w regionie odzyskiwania po awarii, należy skonfigurować oddzielną bramę aplikacja systemu Azure w regionie odzyskiwania po awarii.

  • Ponieważ składniki sieciowe (takie jak sieć wirtualna, zapora itp.) są tworzone oddzielnie w regionie odzyskiwania po awarii, należy upewnić się, że obciążenie SAP w regionie odzyskiwania po awarii jest dostosowane do zmian sieciowych, takich jak aktualizacja DNS, zapora itp.

  • Sieci wirtualne w obu regionach są niezależne i aby nawiązać komunikację między nimi, należy włączyć komunikację równorzędną sieci wirtualnych między dwoma regionami.

Maszyny wirtualne

  • Na platformie Azure różne składniki pojedynczego systemu SAP działają na maszynach wirtualnych z różnymi typami jednostek SKU. W przypadku odzyskiwania po awarii ochronę aplikacji (SAP NetWeaver i innych niż SAP) działających na maszynach wirtualnych platformy Azure można włączyć przez replikowanie składników przy użyciu usługi Azure Site Recovery do innego regionu lub strefy platformy Azure. Dzięki usłudze Azure Site Recovery maszyny wirtualne platformy Azure są replikowane w sposób ciągły z lokacji podstawowej do lokacji odzyskiwania po awarii. W zależności od wybranego regionu odzyskiwania po awarii platformy Azure typ jednostki SKU maszyny wirtualnej może być niedostępny w witrynie odzyskiwania po awarii. Należy upewnić się, że wymagane typy jednostek SKU maszyn wirtualnych są również dostępne w regionie Azure DRregion. Sprawdź produkty platformy Azure według regionów , aby sprawdzić, czy wymagany typ jednostki SKU rodziny maszyn wirtualnych jest dostępny, czy nie.

    Ważne

    Jeśli system SAP jest skonfigurowany z elastycznym zestawem skalowania z FD=1, należy użyć programu PowerShell do skonfigurowania usługi Azure Site Recovery na potrzeby odzyskiwania po awarii. Obecnie jest to jedyna dostępna metoda konfigurowania odzyskiwania po awarii dla maszyn wirtualnych wdrożonych w zestawie skalowania.

  • W przypadku baz danych działających na maszynach wirtualnych platformy Azure zaleca się użycie natywnej technologii replikacji bazy danych do synchronizowania danych z lokacją odzyskiwania po awarii. Duże maszyny wirtualne, na których działają bazy danych, mogą nie być dostępne we wszystkich regionach. Jeśli używasz stref dostępności na potrzeby odzyskiwania po awarii, sprawdź, czy odpowiednie jednostki SKU maszyn wirtualnych są dostępne w strefie lokacji odzyskiwania po awarii.

    Uwaga

    Nie zaleca się korzystania z usługi Azure Site Recovery dla baz danych, ponieważ nie gwarantuje spójności bazy danych i ma ograniczenie współczynnika zmian danych.

  • W przypadku aplikacji produkcyjnych działających w regionie podstawowym przez cały czas wystąpienia rezerwowe są zwykle używane do ekonomizowania kosztów platformy Azure. Jeśli korzystasz z wystąpień zarezerwowanych, musisz zarejestrować się w celu uzyskania 1-letniego lub 3-letniego zobowiązania, które może nie być opłacalne dla witryny odzyskiwania po awarii. Ponadto skonfigurowanie usługi Azure Site Recovery nie gwarantuje pojemności wymaganej jednostki SKU maszyny wirtualnej podczas pracy w trybie failover. Aby upewnić się, że pojemność jednostki SKU maszyny wirtualnej jest dostępna, możesz rozważyć opcję włączenia rezerwacji pojemności na żądanie. Rezerwuje pojemność obliczeniową w regionie platformy Azure lub strefie dostępności platformy Azure przez dowolny czas bez zobowiązania. Usługa Azure Site Recovery jest zintegrowana z rezerwacją pojemności na żądanie. Dzięki tej integracji możesz użyć możliwości rezerwacji pojemności w usłudze Azure Site Recovery, aby zarezerwować pojemność obliczeniową w lokacji odzyskiwania po awarii i zagwarantować przejście w tryb failover. Aby uzyskać więcej informacji, przeczytaj ograniczenia i ograniczenia dotyczące rezerwacji pojemności na żądanie.

  • Subskrypcja platformy Azure ma limity przydziału dla rodzin maszyn wirtualnych (na przykład rodziny Mv2) i innych zasobów. Czasami organizacje chcą używać innej subskrypcji platformy Azure na potrzeby odzyskiwania po awarii. Każda subskrypcja (podstawowa i odzyskiwanie po awarii) może mieć różne przydziały przypisane dla każdej rodziny maszyn wirtualnych. Upewnij się, że subskrypcja używana dla witryny odzyskiwania po awarii ma wystarczającą ilość dostępnych przydziałów obliczeniowych.

Storage

  • Po włączeniu usługi Azure Site Recovery dla maszyny wirtualnej w celu skonfigurowania odzyskiwania po awarii system operacyjny i lokalne dyski danych dołączone do maszyn wirtualnych są replikowane do lokacji odzyskiwania po awarii. Podczas replikacji zapisy dysku maszyny wirtualnej są wysyłane do konta magazynu pamięci podręcznej w regionie źródłowym. Dane są wysyłane stamtąd do regionu docelowego, a punkty odzyskiwania są generowane na podstawie danych. Podczas przełączania maszyny wirtualnej w tryb failover podczas odzyskiwania po awarii punkt odzyskiwania służy do przywracania maszyny wirtualnej w regionie docelowym. Usługa Azure Site Recovery nie obsługuje jednak wszystkich typów magazynów dostępnych na platformie Azure. Aby uzyskać więcej informacji, zobacz Macierz obsługi usługi Azure Site Recovery dla magazynów.

  • Oprócz dysków danych zarządzanych platformy Azure dołączonych do maszyn wirtualnych różne rozwiązania magazynu natywnego platformy Azure są używane do uruchamiania aplikacji SAP na platformie Azure. Podejście odzyskiwania po awarii dla każdego rozwiązania usługi Azure Storage może się różnić, ponieważ nie wszystkie usługi magazynu dostępne na platformie Azure są obsługiwane w usłudze Azure Site Recovery. Poniżej znajduje się lista typu magazynu, który jest zwykle używany dla obciążenia SAP.

    Typ magazynu Zalecenie dotyczące strategii odzyskiwania po awarii
    Dysk zarządzany Azure Site Recovery
    System plików NFS w usłudze Azure Files (LRS lub ZRS) Skrypt niestandardowy do replikowania danych między dwiema lokacjami (na przykład rsync)
    System plików NFS w usłudze Azure NetApp Files Używanie replikacji między regionami woluminów usługi Azure NetApp Files
    Dysk udostępniony platformy Azure (LRS lub ZRS) Niestandardowe rozwiązanie do replikowania danych między dwiema lokacjami
    Protokół SMB w usłudze Azure Files (LRS lub ZRS) Kopiowanie plików między dwiema lokacjami za pomocą narzędzia RoboCopy
    Protokół SMB w usłudze Azure NetApp Files Używanie replikacji między regionami woluminów usługi Azure NetApp Files

  • W przypadku niestandardowych wbudowanych rozwiązań magazynu, takich jak klaster NFS, należy upewnić się, że jest odpowiednia strategia odzyskiwania po awarii.

  • Różne natywne usługi azure storage (takie jak Azure Files, Azure NetApp Files, Azure Shared Disk) mogą nie być dostępne we wszystkich regionach. Aby mieć podobną konfigurację systemu SAP w regionie odzyskiwania po awarii po przejściu w tryb failover, upewnij się, że odpowiednia usługa magazynu jest oferowana w lokacji odzyskiwania po awarii. Aby uzyskać więcej informacji, zobacz Produkty platformy Azure według regionów.

  • W przypadku korzystania ze stref dostępności na potrzeby odzyskiwania po awarii należy pamiętać o następujących kwestiach:

    • Funkcja usługi Azure NetApp Files nie jest jeszcze świadoma strefy. Obecnie funkcja usługi Azure NetApp Files nie jest wdrażana we wszystkich strefach dostępności w regionie świadczenia usługi Azure. Może się tak zdarzyć, że usługa Azure NetApp Files nie jest dostępna w wybranej strefie dostępności dla strategii odzyskiwania po awarii.
    • Replikacja między regionami woluminów usługi Azure NetApp File jest dostępna tylko w parach stałych regionów, a nie w różnych strefach.

  • Jeśli magazyn został skonfigurowany z integracją z usługą Active Directory, na koncie magazynu lokacji odzyskiwania po awarii należy również wykonać podobną konfigurację.

  • Dyski udostępnione platformy Azure wymagają oprogramowania klastra, takiego jak klaster trybu failover systemu Windows Server (WSFC), który obsługuje komunikację węzłów klastra i blokowanie zapisu. Aby mieć strategię odzyskiwania po awarii dla dysku udostępnionego platformy Azure, musisz mieć również dysk udostępniony zarządzany przez oprogramowanie klastra w lokacji odzyskiwania po awarii. Następnie możesz użyć skryptu, aby skopiować dane z dysku udostępnionego dołączonego do klastra w regionie podstawowym do udostępnionego dysku dołączonego do innego klastra w regionie odzyskiwania po awarii.

Następne kroki