Wytyczne dotyczące odzyskiwania po awarii dla aplikacji SAP
Aby skonfigurować odzyskiwanie po awarii dla obciążenia SAP na platformie Azure, należy regularnie testować, dostosowywać i aktualizować proces. Testowanie odzyskiwania po awarii pomaga zidentyfikować sekwencję usług zależnych, które są wymagane przed wyzwoleniem trybu failover obciążenia SAP DR lub uruchomieniem systemu w lokacji dodatkowej. Organizacje zwykle mają swoje systemy SAP połączone z usługami Active Directory (AD) i Dns (Domain Name System) w celu poprawnego działania. Podczas konfigurowania odzyskiwania po awarii dla obciążenia SAP upewnij się, że usługi AD i DNS działają przed odzyskaniem systemu SAP i innych systemów innych niż SAP, aby zapewnić prawidłowe funkcje aplikacji. Aby uzyskać wskazówki dotyczące ochrony usług Active Directory i DNS, dowiedz się , jak chronić usługę Active Directory i usługę DNS. Zalecenie odzyskiwania po awarii dla aplikacji SAP opisane w tym dokumencie jest na poziomie abstrakcyjnym. Należy zaprojektować strategię odzyskiwania po awarii na podstawie określonej konfiguracji i udokumentować kompleksowe scenariusze.
Zalecenie odzyskiwania po awarii dla obciążeń SAP
Zwykle w rozproszonych systemach SAP NetWeaver; usługi centralne, baza danych i magazyn udostępniony (NFS/SMB) to pojedynczy punkt awarii (SPOF). Aby wyeliminować wpływ różnych funkcji SPOF, należy skonfigurować nadmiarowość tych składników. Nadmiarowość tych składników SPOF w regionie podstawowym jest osiągana przez skonfigurowanie wysokiej dostępności. Konfiguracja wysokiej dostępności składnika chroni system SAP przed awarią lokalną lub katastrofą. Jednak aby chronić aplikacje SAP przed geograficzną rozproszoną awarią, należy wdrożyć strategię odzyskiwania po awarii dla wszystkich składników SAP.
W przypadku systemów SAP działających na maszynach wirtualnych można użyć usługi Azure Site Recovery do utworzenia planu odzyskiwania po awarii. Poniżej przedstawiono zalecane podejście do odzyskiwania po awarii dla każdego składnika systemu SAP. Autonomiczne aparaty SAP inne niż NetWeaver, takie jak TREX i aplikacje inne niż SAP, nie są omówione w tym dokumencie.
| Składniki | Zalecenie |
|---|---|
| SAP Web Dispatcher | Replikowanie maszyny wirtualnej przy użyciu usługi Azure Site Recovery |
| SAP Central Services | Replikowanie maszyny wirtualnej przy użyciu usługi Azure Site Recovery |
| Serwer aplikacji SAP | Replikowanie maszyny wirtualnej przy użyciu usługi Azure Site Recovery |
| Baza danych SAP | Korzystanie z metody replikacji oferowanej przez bazę danych |
| Magazyn udostępniony | Replikowanie zawartości przy użyciu odpowiedniej metody na typ magazynu |
SAP Web Dispatcher
Składnik SAP Web Dispatcher działa jako moduł równoważenia obciążenia dla ruchu SAP między serwerami aplikacji SAP. Dostępne są różne opcje zapewnienia wysokiej dostępności składnika SAP Web Dispatcher w regionie podstawowym. Aby uzyskać więcej informacji na temat tej opcji, zobacz Wysoka dostępność konfiguracji programu SAP Web Dispatcher i SAP Web dispatcher HA na platformie Azure.
- Opcja 1. Wysoka dostępność przy użyciu rozwiązania klastra.
- Opcja 2. Wysoka dostępność z równoległymi usługami SAP Web Dispatcher.
Aby uzyskać odzyskiwanie po awarii dla konfiguracji programu SAP Web Dispatcher o wysokiej dostępności w regionie podstawowym, możesz użyć usługi Azure Site Recovery. W przypadku równoległych dyspozytorów internetowych (opcja 2) działających w regionie podstawowym można skonfigurować usługę Azure Site Recovery w celu uzyskania odzyskiwania po awarii. Jednak w przypadku programu SAP Web Dispatcher skonfigurowanego przy użyciu opcji 1 w regionie podstawowym należy wprowadzić pewne dodatkowe zmiany po przejściu w tryb failover, aby mieć podobną konfigurację wysokiej dostępności w regionie odzyskiwania po awarii. Ponieważ konfiguracja wysokiej dostępności programu SAP Web Dispatcher z rozwiązaniem klastra jest skonfigurowana w podobny sposób do usług centralnych SAP. Postępuj zgodnie z tymi samymi wytycznymi, jak wspomniano w przypadku usług SAP Central Services.
SAP Central Services
Usługi centralne SAP zawierają kolejkę i serwer komunikatów, który jest jednym z spOF aplikacji SAP. W systemie SAP może istnieć tylko jedno takie wystąpienie i można go skonfigurować pod kątem wysokiej dostępności. Przeczytaj artykuł Wysoka dostępność usługi SAP Central Service , aby zrozumieć różne rozwiązanie o wysokiej dostępności dla obciążenia SAP na platformie Azure.
Konfigurowanie wysokiej dostępności dla usług SAP Central Services chroni zasoby i procesy przed zdarzeniami lokalnymi. Aby uzyskać odzyskiwanie po awarii dla usług SAP Central Services, możesz użyć usługi Azure Site Recovery. Usługa Azure Site Recovery replikuje maszyny wirtualne i dołączone dyski zarządzane, ale istnieją dodatkowe zagadnienia dotyczące strategii odzyskiwania po awarii. Zapoznaj się z poniższą sekcją, aby uzyskać więcej informacji na podstawie systemu operacyjnego używanego dla usług centralnych SAP.
W przypadku systemu SAP nadmiarowość składnika SPOF w regionie podstawowym jest osiągana przez skonfigurowanie wysokiej dostępności. Aby osiągnąć podobną konfigurację wysokiej dostępności w regionie odzyskiwania po awarii po przejściu w tryb failover, należy rozważyć dodatkowe punkty. Obejmują one ponowne skonfigurowanie klastra, upewnienie się, że są dostępne katalogi udostępnione sap, a także replikowanie maszyn wirtualnych i ich dysków zarządzanych do lokacji odzyskiwania po awarii za pomocą usługi Azure Site Recovery. W systemie Linux można osiągnąć wysoką dostępność aplikacji SAP przy użyciu rozwiązania klastra pacemaker. Na poniższym diagramie przedstawiono różne składniki związane z konfigurowaniem wysokiej dostępności dla usług centralnych SAP za pomocą programu Pacemaker. Każdy składnik należy wziąć pod uwagę, aby mieć podobną wysoką dostępność skonfigurowaną w lokacji odzyskiwania po awarii. Jeśli skonfigurowano program SAP Web Dispatcher przy użyciu rozwiązania klastra pacemaker, należy również rozważyć podobne zagadnienia.
Wewnętrzny moduł równoważenia obciążenia
Usługa Azure Site Recovery replikuje maszyny wirtualne do lokacji odzyskiwania po awarii, ale nie replikuje modułu równoważenia obciążenia platformy Azure. Należy wcześniej utworzyć oddzielny wewnętrzny moduł równoważenia obciążenia w witrynie odzyskiwania po awarii lub po przejściu w tryb failover. Jeśli wcześniej utworzysz wewnętrzny moduł równoważenia obciążenia, utwórz pustą pulę zaplecza i dodaj maszyny wirtualne po zdarzeniu trybu failover.
Rozwiązanie klastra Pacemaker
Konfiguracje klastra pacemaker znajdują się w lokalnych plikach maszyn wirtualnych, które są replikowane do lokacji odzyskiwania po awarii za pomocą usługi Azure Site Recovery. Konfiguracja klastra pacemaker nie będzie działać poza polem na maszynach wirtualnych po przejściu w tryb failover. Aby rozwiązanie działało, wymagane jest dodatkowe ponowne skonfigurowanie klastra.
Przeczytaj te blogi, aby dowiedzieć się więcej o rekonfiguracji klastra pacemaker w regionie odzyskiwania po awarii na podstawie typu magazynu i mechanizmu ogrodzenia.
- Klaster wysokiej dostępności SAP ASCS/ERS z urządzeniem SBD (przy użyciu serwera docelowego iSCSI) przełączenie w tryb failover do regionu odzyskiwania po awarii przy użyciu usługi Azure Site Recovery.
- Tryb failover klastra SAP ASCS HA (w systemie operacyjnym Linux) do regionu odzyskiwania po awarii przy użyciu usługi Azure Site Recovery.
Katalogi udostępnione SAP dla systemu Linux
Konfiguracja wysokiej dostępności platformy SAP NetWeaver lub ABAP używa serwera replikacji w kolejce do osiągnięcia nadmiarowości na poziomie aplikacji dla usługi enqueue systemu SAP z konfiguracją klastra Pacemaker. Konfiguracja wysokiej dostępności usług centralnych SAP (ASCS i ERS) korzysta z instalacji NFS. Dlatego należy upewnić się, że pliki binarne i dane SAP w tych instalacjach systemu plików NFS są replikowane do lokacji odzyskiwania po awarii. Usługa Azure Site Recovery replikuje maszyny wirtualne i lokalny dysk zarządzany dołączony, ale nie replikuje instalacji systemu plików NFS. Na podstawie typu magazynu NFS skonfigurowanego dla konfiguracji należy upewnić się, że dane są replikowane i dostępne w lokacji odzyskiwania po awarii. Metodologia replikacji między regionami dla każdego magazynu jest prezentowana na poziomie abstrakcyjnym. Należy potwierdzić dokładne kroki replikacji magazynu i przeprowadzania testów.
| Katalogi udostępnione SAP | Replikacja między regionami |
|---|---|
| System plików NFS w usłudze Azure Files | Niestandardowe (na przykład rsync) |
| NFS w usłudze ANF | Tak (replikacja między regionami) |
| Klaster NFS | Niestandardowy |
Napiwek
Zalecamy wdrożenie jednej z usług NFS platformy Azure: NFS w usłudze Azure Files lub woluminach ANF NFS do przechowywania udostępnionych danych w systemie SAP o wysokiej dostępności. Należy pamiętać, że wyróżniamy architektury referencyjne sap, korzystając z klastrów NFS.
Mechanizm ogrodzenia
Niezależnie od systemu operacyjnego (SLES lub RHEL) i jego wersji, program pacemaker wymaga prawidłowego mechanizmu ogrodzenia, aby całe rozwiązanie działało prawidłowo. Na podstawie typu mechanizmu ogrodzenia, który został skonfigurowany w regionie podstawowym, należy upewnić się, że ten sam mechanizm ogrodzenia jest skonfigurowany w lokacji odzyskiwania po awarii.
| Mechanizm ogrodzenia | Rekomendacja odzyskiwania po awarii między regionami |
|---|---|
| Usługa SBD korzystająca z serwera docelowego iSCSI | Replikowanie serwera docelowego iSCSI przy użyciu usługi Azure Site Recovery. Na maszynach wirtualnych odzyskiwania po awarii odnajdź ponownie dysk iSCSI. |
| Agent ogrodzenia platformy Azure | Włącz tożsamości zarządzanego systemu (MSI) na maszynach wirtualnych odzyskiwania po awarii. Przypisz role niestandardowe. Zaktualizuj zasób agenta ogrodzenia w klastrze. |
| Usługa SBD korzystająca z dysku udostępnionego platformy Azure* | Skonfiguruj nowy dysk udostępniony platformy Azure w regionie odzyskiwania po awarii. Dołączanie dysku udostępnionego platformy Azure do maszyn wirtualnych odzyskiwania po awarii po przejściu w tryb failover. Konfigurowanie urządzenia SBD dysku udostępnionego platformy Azure. |
*Magazyn ZRS dla dysku udostępnionego platformy Azure jest dostępny w ograniczonych regionach.
Uwaga
Zalecamy korzystanie z tego samego mechanizmu ogrodzenia zarówno dla regionu podstawowego, jak i odzyskiwania po awarii w celu ułatwienia działania i przejścia w tryb failover. Nie zaleca się posiadania innego mechanizmu ogrodzenia po przejściu w tryb failover do lokacji odzyskiwania po awarii.
Serwery aplikacji SAP
W regionie podstawowym nadmiarowość serwerów aplikacji SAP jest osiągana przez zainstalowanie wystąpień na wielu maszynach wirtualnych. Aby mieć odzyskiwanie po awarii dla serwerów aplikacji SAP, usługę Azure Site Recovery można skonfigurować dla każdej maszyny wirtualnej serwera aplikacji. W przypadku magazynów udostępnionych (systemu plików transportu, systemu plików interfejsu) dołączonego do serwerów aplikacji należy postępować zgodnie z odpowiednią praktyką odzyskiwania po awarii na podstawie typu magazynu udostępnionego.
Serwery bazy danych SAP
W przypadku baz danych z obciążeniem SAP użyj natywnej technologii replikacji systemu DBMS do skonfigurowania odzyskiwania po awarii. Korzystanie z usługi Azure Site Recovery dla baz danych nie jest zalecane, ponieważ nie gwarantuje spójności bazy danych i ma ograniczenie zmian danych. Technologia replikacji dla każdej bazy danych jest inna, dlatego postępuj zgodnie z odpowiednimi wytycznymi dotyczącymi bazy danych. W poniższej tabeli przedstawiono listę baz danych używanych dla obciążeń SAP oraz odpowiednie zalecenie odzyskiwania po awarii.
| baza danych | Zalecenie dotyczące odzyskiwania po awarii |
|---|---|
| SAP HANA | Replikacja systemu HANA (HSR) |
| Oracle | Oracle Data Guard (FarSync) |
| IBM DB2 | Odzyskiwanie po awarii o wysokiej dostępności (HADR) |
| Microsoft SQL | Microsoft SQL Always On |
| SAP ASE | USŁUGA ASE HADR zawsze włączona |
| SAP MaxDB | Rezerwowa baza danych |
W przypadku rozwiązania zoptymalizowanego pod kątem kosztów można nawet użyć opcji tworzenia kopii zapasowych i przywracania dla strategii odzyskiwania po awarii bazy danych.
Kopia zapasowa i przywracanie
Tworzenie i przywracanie kopii zapasowych to inne rozwiązanie, którego można użyć do osiągnięcia odzyskiwania po awarii dla obciążeń SAP, jeśli cel czasu odzyskiwania firmy i cel punktu odzyskiwania są niekrytyczne. Za pomocą usługi Azure Backup, usługi tworzenia kopii zapasowych opartej na chmurze możesz tworzyć kopie różnych składników obciążenia SAP, takich jak maszyny wirtualne, dyski zarządzane i obsługiwane bazy danych. Aby dowiedzieć się więcej na temat ogólnych ustawień i ograniczeń dotyczących scenariuszy i wdrożeń usługi Azure Backup, zobacz Macierz obsługi usługi Azure Backup.
| Usługi | Składnik | Obsługa usługi Azure Backup |
|---|---|---|
| Compute | Maszyny wirtualne platformy Azure | Obsługiwane |
| Storage | Dyski zarządzane platformy Azure, w tym dyski udostępnione | Obsługiwane |
| Storage | Udział plików platformy Azure — SMB (Standardowa lub Premium) | Obsługiwane |
| Storage | Obiekty blob platformy Azure | Obsługiwane |
| Storage | Udostępnione pliki platformy Azure — NFS (Standardowa lub Premium) | Nieobsługiwany |
| Storage | Azure NetApp Files | Nieobsługiwany |
| baza danych | Baza danych SAP HANA na maszynach wirtualnych platformy Azure | Obsługiwane |
| baza danych | Serwer SQL na maszynach wirtualnych platformy Azure | Obsługiwane |
| baza danych | Oracle | Obsługiwane* |
| baza danych | IBM DB2, SAP ASE | Nieobsługiwany |
Uwaga
*Kopia zapasowa platformy Azure obsługuje bazę danych Oracle przy użyciu kopii zapasowej maszyny wirtualnej platformy Azure dla migawek spójnych na poziomie bazy danych.
Usługa Azure Backup nie obsługuje wszystkich magazynów i baz danych platformy Azure, które są używane na potrzeby obciążenia SAP.
Usługa Azure Backup przechowuje kopie zapasowe w magazynie usługi odzyskiwania, który replikuje dane na podstawie wybranego typu replikacji (LRS, ZRS lub GRS). W przypadku magazynu geograficznie nadmiarowego (GRS) dane kopii zapasowej są replikowane do sparowanego regionu pomocniczego. Po włączeniu funkcji przywracania między regionami można przywrócić dane obsługiwanego typu zarządzania w regionie pomocniczym.
Tworzenie i przywracanie kopii zapasowych to bardziej tradycyjne podejście zoptymalizowane pod kątem kosztów, ale wiąże się z kompromisem w zakresie wyższego celu odzyskiwania. Ponieważ musisz przywrócić wszystkie aplikacje z kopii zapasowej, jeśli nastąpi przejście w tryb failover do regionu odzyskiwania po awarii. Dlatego musisz przeanalizować potrzeby biznesowe i odpowiednio zaprojektować strategię odzyskiwania po awarii.