Dostępność oprogramowania SAP HANA w różnych regionach świadczenia usługi Azure
W tym artykule opisano scenariusze związane z dostępnością oprogramowania SAP HANA w różnych regionach świadczenia usługi Azure. Ze względu na odległość między regionami świadczenia usługi Azure konfigurowanie dostępności platformy SAP HANA w wielu regionach świadczenia usługi Azure obejmuje specjalne zagadnienia.
Dlaczego warto wdrożyć w wielu regionach świadczenia usługi Azure
Regiony platformy Azure często są oddzielone dużymi odległościami. W zależności od regionu geopolitycznego odległość między regionami platformy Azure może wynosić setki mil, a nawet kilka tysięcy mil, na przykład w Stany Zjednoczone. Ze względu na odległość ruch sieciowy między elementami zawartości wdrożonymi w dwóch różnych regionach świadczenia usługi Azure ma znaczne opóźnienie między sieciami. Opóźnienie jest wystarczająco duże, aby wykluczyć synchroniczną wymianę danych między dwoma wystąpieniami platformy SAP HANA w ramach typowych obciążeń SAP.
Z drugiej strony organizacje często mają wymóg odległości między lokalizacją podstawowego centrum danych a pomocniczym centrum danych. Wymóg odległości pomaga zapewnić dostępność, jeśli klęska żywiołowa wystąpi w szerszej lokalizacji geograficznej. Przykłady obejmują huragany, które uderzyły w Karaiby i Florydę we wrześniu i październiku 2017 roku. Organizacja może mieć co najmniej minimalne wymaganie dotyczące odległości. W przypadku większości klientów platformy Azure minimalna definicja odległości wymaga zaprojektowania dostępności w różnych regionach świadczenia usługi Azure. Ponieważ odległość między dwoma regionami świadczenia usługi Azure jest zbyt duża, aby użyć trybu replikacji synchronicznej platformy HANA, wymagania dotyczące celu czasu odzyskiwania i celu punktu odzyskiwania mogą wymusić wdrożenie konfiguracji dostępności w jednym regionie, a następnie uzupełnienie dodatkowych wdrożeń w drugim regionie.
Innym aspektem, który należy wziąć pod uwagę w tym scenariuszu, jest tryb failover i przekierowanie klienta. Założeniem jest to, że przejście w tryb failover między wystąpieniami platformy SAP HANA w dwóch różnych regionach świadczenia usługi Azure zawsze jest ręcznym trybem failover. Ponieważ tryb replikacji systemu SAP HANA jest ustawiony na asynchroniczny, istnieje potencjał, że dane zatwierdzone w podstawowym wystąpieniu platformy HANA nie zostały jeszcze wprowadzone do pomocniczego wystąpienia platformy HANA. W związku z tym automatyczne przełączanie w tryb failover nie jest opcją dla konfiguracji, w których replikacja jest asynchroniczna. Nawet w przypadku ręcznego kontrolowanego trybu failover, podobnie jak w ćwiczeniu trybu failover, należy podjąć środki, aby upewnić się, że wszystkie zatwierdzone dane po stronie podstawowej zostały przeniesione do wystąpienia pomocniczego przed ręcznym przejściem do innego regionu świadczenia usługi Azure.
Usługa Azure Virtual Network używa innego zakresu adresów IP. Adresy IP są wdrażane w drugim regionie świadczenia usługi Azure. Dlatego musisz zmienić konfigurację klienta SAP HANA lub najlepiej utworzyć kroki zmiany rozpoznawania nazw. W ten sposób klienci są przekierowywani do adresu IP serwera nowej lokacji dodatkowej. Aby uzyskać więcej informacji, zobacz artykuł Odzyskiwanie połączenia klienta z oprogramowaniem SAP po przejęciu.
Prosta dostępność między dwoma regionami świadczenia usługi Azure
Jeśli wystąpi awaria, możesz zdecydować, że nie zostanie umieszczona żadna konfiguracja dostępności w jednym regionie, ale nadal istnieje zapotrzebowanie na obsłużenie obciążenia. Typowe przypadki takich scenariuszy to systemy nieprodukcyjne. Mimo że system nie działa przez pół dnia, a nawet dzień jest zrównoważony, nie można zezwolić systemowi na niedostępności przez 48 godzin lub więcej. Aby konfiguracja jest mniej kosztowna, uruchom inny system, który jest jeszcze mniej ważny na maszynie wirtualnej. Drugi system działa jako miejsce docelowe. Możesz również zmniejszyć rozmiar maszyny wirtualnej w regionie pomocniczym i nie ładować wstępnie danych. Ponieważ przejście w tryb failover jest ręczne i wiąże się z wieloma dodatkowymi krokami przechodzenia w tryb failover całego stosu aplikacji, dodatkowy czas zamykania maszyny wirtualnej, zmieniania jej rozmiaru, a następnie ponownego uruchamiania maszyny wirtualnej jest akceptowalne.
Jeśli używasz scenariusza udostępniania docelowego odzyskiwania po awarii systemowi kontroli jakości na jednej maszynie wirtualnej, należy wziąć pod uwagę następujące kwestie:
- Istnieją dwa tryby operacji z delta_datashipping i logreplay, które są dostępne dla takiego scenariusza
- Oba tryby operacji mają różne wymagania dotyczące pamięci bez wstępnego ładowania danych
- Delta_datashipping może wymagać drastycznie mniejszej ilości pamięci bez opcji wstępnego ładowania, niż może być wymagana funkcja logreplay. Zobacz rozdział 4.3 dokumentu SAP How To Perform System Replication for SAP HANA (Jak wykonać replikację systemu dla platformy SAP HANA)
- Wymaganie pamięci trybu operacji logreplay bez wstępnego ładowania nie jest deterministyczne i zależy od załadowanych struktur magazynu kolumn. W skrajnych przypadkach może być wymagane 50% pamięci wystąpienia podstawowego. Pamięć trybu operacji logreplay jest niezależna od tego, czy wybrano zestaw wstępnie załadowanych danych.
Uwaga
W tej konfiguracji nie można podać celu punktu odzyskiwania =0, ponieważ tryb replikacji systemu HANA jest asynchroniczny. Jeśli musisz podać cel punktu odzyskiwania =0, ta konfiguracja nie jest wybraną konfiguracją.
Niewielką zmianą, którą można wprowadzić w konfiguracji, może być skonfigurowanie danych jako wstępnego ładowania. Jednak ze względu na ręczny charakter trybu failover i fakt, że warstwy aplikacji również muszą przejść do drugiego regionu, może nie mieć sensu wstępnego ładowania danych.
Łączenie dostępności w jednym regionie i w różnych regionach
Kombinacja dostępności w różnych regionach i między nimi może być oparta na następujących czynnikach:
- Wymaganie celu punktu odzyskiwania =0 w regionie świadczenia usługi Azure.
- Organizacja nie jest gotowa ani nie może mieć globalnych operacji dotkniętych poważnymi klęskami żywiołowymi, które mają wpływ na większy region. Tak było w przypadku niektórych huraganów, które uderzyły na Karaiby w ciągu ostatnich kilku lat.
- Przepisy, które wymagają odległości między lokacjami podstawowymi i dodatkowymi, które są wyraźnie poza tym, jakie strefy dostępności platformy Azure mogą zapewnić.
W takich przypadkach można skonfigurować konfigurację replikacji wielowarstwowej replikacji systemu SAP HANA przy użyciu replikacji systemu HANA. Architektura wygląda następująco:
Oprogramowanie SAP wprowadziło replikację systemu wielocelowego z platformą HANA 2.0 SPS3. Replikacja systemu z wieloma celami przynosi pewne korzyści w scenariuszach aktualizacji. Na przykład lokacja odzyskiwania po awarii (region 2) nie ma wpływu, gdy lokacja dodatkowej wysokiej dostępności nie działa w celu konserwacji lub aktualizacji. Więcej informacji na temat replikacji systemu wielocelowego platformy HANA można znaleźć w portalu pomocy sap. Możliwa architektura z replikacją wielokierunkową wyglądałaby następująco:
Jeśli organizacja ma wymagania dotyczące gotowości na wysoką dostępność w drugim regionie świadczenia usługi Azure(DR), architektura będzie wyglądać następująco:
Przy użyciu funkcji logreplay jako trybu operacji ta konfiguracja zapewnia cel punktu odzyskiwania =0 z niskim celem czasu odzyskiwania w regionie podstawowym. Konfiguracja zapewnia również przyzwoity cel punktu odzyskiwania, jeśli jest zaangażowany przejście do drugiego regionu. Czas czasu czasu odzyskiwania w drugim regionie zależy od tego, czy dane są wstępnie ładowane. Wielu klientów używa maszyny wirtualnej w regionie pomocniczym do uruchamiania systemu testowego. W takim przypadku użycia nie można wstępnie załadować danych.
Ważne
Tryby operacji między różnymi warstwami muszą być jednorodne. Nie można użyć funkcji logreplay jako trybu operacji między warstwą 1 a warstwą 2 i delta_datashipping, aby dostarczyć warstwę 3. Można wybrać tylko jeden lub drugi tryb operacji, który musi być spójny dla wszystkich warstw. Ponieważ delta_datashipping nie nadaje się do nadania celowi punktu odzyskiwania =0, jedynym rozsądnym trybem operacji dla takiej wielowarstwowej konfiguracji pozostaje replay. Aby uzyskać szczegółowe informacje na temat trybów operacji i niektórych ograniczeń, zobacz artykuł Tryby operacji dla replikacji systemu SAP HANA.
Następne kroki
Aby uzyskać szczegółowe wskazówki dotyczące konfigurowania tych konfiguracji na platformie Azure, zobacz: