Dostępność oprogramowania SAP HANA w jednym regionie świadczenia usługi Azure
W tym artykule opisano kilka scenariuszy dostępności dla platformy SAP HANA w jednym regionie świadczenia usługi Azure. Platforma Azure ma wiele regionów, rozmieszczonych na całym świecie. Aby uzyskać listę regionów świadczenia usługi Azure, zobacz Regiony świadczenia usługi Azure. W przypadku wdrażania oprogramowania SAP HANA na maszynach wirtualnych w jednym regionie świadczenia usługi Azure firma Microsoft oferuje wdrożenie pojedynczej maszyny wirtualnej z wystąpieniem platformy HANA. W celu zwiększenia dostępności można wdrożyć dwie maszyny wirtualne z dwoma wystąpieniami platformy HANA przy użyciu elastycznego zestawu skalowania z FD =1, stref dostępności lub zestawu dostępności, który używa replikacji systemu HANA na potrzeby dostępności.
Regiony platformy Azure, które zapewniają Strefy dostępności składają się z wielu centrów danych, z których każdy ma własne źródło zasilania, chłodzenie i infrastrukturę sieci. Celem oferowania różnych stref w jednym regionie świadczenia usługi Azure jest umożliwienie wdrażania aplikacji w dwóch lub trzech dostępnych Strefy dostępności. Dzięki dystrybucji wdrożenia aplikacji w różnych strefach wszelkie problemy z zasilaniem lub siecią wpływające na określoną infrastrukturę strefy dostępności platformy Azure nie zakłócają w pełni funkcjonalności aplikacji w regionie świadczenia usługi Azure. Chociaż w jednej strefie może istnieć ograniczona pojemność, taka jak potencjalna utrata maszyn wirtualnych w jednej strefie, maszyny wirtualne w pozostałych strefach będą nadal działać bez przerwy. Aby skonfigurować dwa wystąpienia platformy HANA na oddzielnych maszynach wirtualnych obejmujących różne strefy, możesz wdrożyć maszyny wirtualne przy użyciu elastycznego zestawu skalowania z opcją wdrożenia FD=1 lub stref dostępności.
W celu zwiększenia dostępności w regionie zaleca się wdrożenie dwóch maszyn wirtualnych z dwoma wystąpieniami platformy HANA przy użyciu zestawu dostępności. Zestaw dostępności platformy Azure to funkcja grupowania logicznego, która zapewnia, że zasoby maszyn wirtualnych skonfigurowane w zestawie dostępności są odizolowane od siebie po awarii podczas wdrażania w centrum danych platformy Azure. Maszyny wirtualne platformy Azure umieszczone w zestawie dostępności korzystają z wielu serwerów fizycznych, regałów obliczeniowych, jednostek magazynowych i przełączników sieciowych. W dokumentacji platformy Azure ta konfiguracja jest określana jako umieszczanie w różnych domenach aktualizacji i błędów. Te umieszczania zwykle znajdują się w centrum danych platformy Azure. Zakładając, że problemy ze źródłem zasilania i siecią będą miały wpływ na wdrażane centrum danych, wpłynie to na całą pojemność w jednym regionie świadczenia usługi Azure.
Umieszczanie centrów danych reprezentujących platformę Azure Strefy dostępności jest kompromisem między zapewnieniem akceptowalnego opóźnienia sieci między usługami wdrożonym w różnych strefach i odległością między centrami danych. Klęski żywiołowe w idealnym przypadku nie miałyby wpływu na energię, zaopatrzenie w sieć i infrastrukturę dla wszystkich Strefy dostępności w tym regionie. Jednak jak wykazały monumentalne katastrofy naturalne, Strefy dostępności mogą nie zawsze zapewnić dostępność, której potrzebujesz w jednym regionie. Pomyśl o huraganie Maria, który uderzył na wyspę Portoryko 20 września 2017 roku. Huragan w zasadzie spowodował prawie 100 procent zaciemnienia na 90-milowej wyspie.
Scenariusz z pojedynczą maszyną wirtualną
W scenariuszu z jedną maszyną wirtualną tworzysz maszynę wirtualną platformy Azure dla wystąpienia platformy SAP HANA. Usługa Azure Premium Storage służy do hostowania dysku systemu operacyjnego i wszystkich dysków danych. Umowa SLA dotycząca czasu działania platformy Azure w wysokości 99,9 procent, a umowy SLA innych składników platformy Azure są wystarczające do spełnienia umów SLA dotyczących dostępności dla klientów. W tym scenariuszu nie trzeba używać zestawu dostępności platformy Azure dla maszyn wirtualnych z uruchomioną warstwą DBMS. W tym scenariuszu polegasz na dwóch różnych funkcjach:
- Automatyczne ponowne uruchamianie maszyny wirtualnej platformy Azure (nazywane również naprawianiem usługi platformy Azure)
- Automatyczne ponowne uruchamianie oprogramowania SAP HANA
Automatyczne ponowne uruchamianie maszyny wirtualnej platformy Azure lub naprawianie usługi to funkcja platformy Azure, która działa na dwóch poziomach:
- Host serwera platformy Azure sprawdza kondycję maszyny wirtualnej hostowanej na hoście serwera.
- Kontroler sieci szkieletowej platformy Azure monitoruje kondycję i dostępność hosta serwera.
Funkcja sprawdzania kondycji monitoruje kondycję każdej maszyny wirtualnej hostowanej na hoście serwera platformy Azure. Jeśli maszyna wirtualna wchodzi w stan niezdrowy, ponowne uruchomienie maszyny wirtualnej może zostać zainicjowane przez agenta hosta platformy Azure, który sprawdza kondycję maszyny wirtualnej. Kontroler sieci szkieletowej sprawdza kondycję hosta, sprawdzając wiele różnych parametrów, które mogą wskazywać na problemy ze sprzętem hosta. Sprawdza również dostępność hosta za pośrednictwem sieci. Wskazanie problemów z hostem może prowadzić do następujących zdarzeń:
- Jeśli host sygnalizuje nieprawidłowy stan kondycji, zostanie wyzwolony ponowny rozruch hosta i ponowne uruchomienie maszyn wirtualnych, które były uruchomione na hoście.
- Jeśli host nie jest w dobrej kondycji po pomyślnym ponownym uruchomieniu, zainicjowano ponowne wdrożenie maszyn wirtualnych, które pierwotnie znajdowały się w węźle w złej kondycji na serwerze hosta w dobrej kondycji. W takim przypadku oryginalny host jest oznaczony jako nie w dobrej kondycji. Nie będzie on używany do dalszych wdrożeń, dopóki nie zostanie wyczyszczone lub zastąpione.
- Jeśli host w złej kondycji ma problemy podczas procesu ponownego uruchamiania, zostanie wyzwolone natychmiastowe ponowne uruchomienie maszyn wirtualnych na hoście w dobrej kondycji.
Dzięki monitorowaniu hostów i maszyn wirtualnych udostępnianych przez platformę Azure maszyny wirtualne platformy Azure, które napotykają problemy z hostem, są automatycznie uruchamiane ponownie na hoście platformy Azure w dobrej kondycji.
Ważne
Naprawianie usługi platformy Azure nie spowoduje ponownego uruchomienia maszyn wirtualnych z systemem Linux, na których system operacyjny gościa jest w stanie paniki jądra. Domyślne ustawienia powszechnie używanych wydań systemu Linux nie są automatycznie uruchamiane ponownie maszyn wirtualnych lub serwera, na których jądro systemu Linux jest w stanie paniki. Zamiast tego ustawienie domyślne przewiduje zachowanie systemu operacyjnego w stanie paniki jądra, aby móc dołączyć debuger jądra do analizy. Platforma Azure przestrzega tego zachowania, nie uruchamiając automatycznie ponownie maszyny wirtualnej z systemem operacyjnym gościa w takim stanie. Założenie polega na tym, że takie wystąpienia są niezwykle rzadkie. Możesz zastąpić domyślne zachowanie, aby włączyć ponowne uruchomienie maszyny wirtualnej. Aby zmienić domyślne zachowanie, włącz parametr "kernel.panic" w /etc/sysctl.conf. Czas ustawiony dla tego parametru wynosi w sekundach. Typowe zalecane wartości to odczekanie 20–30 sekund przed wyzwoleniem ponownego uruchomienia za pomocą tego parametru. Aby uzyskać więcej informacji, zobacz sysctl.conf.
Drugą funkcją, na której polegasz w tym scenariuszu, jest fakt, że usługa HANA uruchamiana na ponownie uruchomionej maszynie wirtualnej jest uruchamiana automatycznie po ponownym uruchomieniu maszyny wirtualnej. Automatyczne ponowne uruchamianie usługi HANA można skonfigurować za pośrednictwem usług watchdog różnych usług HANA.
Ten scenariusz z jedną maszyną wirtualną można poprawić, dodając zimny węzeł trybu failover do konfiguracji oprogramowania SAP HANA. W dokumentacji platformy SAP HANA ta konfiguracja jest nazywana automatycznym przełączaniem hosta. Ta konfiguracja może mieć sens w sytuacji wdrożenia lokalnego, w której sprzęt serwera jest ograniczony, a węzeł pojedynczego serwera jest przeznaczony jako węzeł automatycznego przełączania hosta dla zestawu hostów produkcyjnych. Jednak na platformie Azure, gdzie podstawowa infrastruktura platformy Azure zapewnia serwer docelowy w dobrej kondycji na potrzeby pomyślnego ponownego uruchomienia maszyny wirtualnej, nie ma sensu wdrażać automatycznego przełączania hosta SAP HANA. Ze względu na naprawianie usługi platformy Azure nie ma architektury referencyjnej, która przewiduje węzeł rezerwowy dla automatycznego przełączania hosta HANA.
Szczególny przypadek konfiguracji skalowalnego w poziomie platformy SAP HANA na platformie Azure
Architektury wysokiej dostępności oparte na węźle rezerwowym lub replikacji systemu HANA można znaleźć w następujących dokumentach. W przypadkach, gdy węzły rezerwowe lub replikacja systemu HANA wysokiej dostępności nie są używane w konfiguracjach skalowalnych w poziomie platformy SAP HANA, możesz zależeć od możliwości naprawiania usługi maszyn wirtualnych platformy Azure i automatycznego ponownego uruchamiania wystąpienia sap HANA po ponownym uruchomieniu maszyny wirtualnej.
- RedHat Enterprise Linux
- SUSE Linux Enterprise Server
Scenariusze dostępności dla dwóch różnych maszyn wirtualnych
Aby zapewnić dostępność systemu HANA w określonym regionie, możesz skonfigurować dwie maszyny wirtualne w różnych strefach dostępności regionu lub w regionie. Aby osiągnąć ten cel, można skonfigurować maszyny wirtualne przy użyciu elastycznego zestawu skalowania, stref dostępności lub opcji wdrożenia zestawu dostępności. Podstawowa konfiguracja na platformie Azure wygląda następująco:
Aby zilustrować różne scenariusze dostępności oprogramowania SAP HANA, kilka warstw na diagramie zostanie pominiętych. Na diagramie przedstawiono tylko warstwy przedstawiające maszyny wirtualne, hosty, zestawy dostępności i regiony platformy Azure. Wystąpienia usługi Azure Virtual Network, grupy zasobów i subskrypcje nie odgrywają roli w scenariuszach opisanych w tej sekcji.
Replikowanie kopii zapasowych do drugiej maszyny wirtualnej
Jedną z najbardziej rudimentarnych konfiguracji jest użycie kopii zapasowych. W szczególności mogą istnieć kopie zapasowe dziennika transakcji wysyłane z jednej maszyny wirtualnej do innej maszyny wirtualnej platformy Azure. Możesz wybrać typ usługi Azure Storage. W tej konfiguracji odpowiadasz za wykonywanie skryptów kopii zaplanowanych kopii zapasowych, które są wykonywane na pierwszej maszynie wirtualnej do drugiej maszyny wirtualnej. Jeśli musisz użyć drugiego wystąpienia maszyny wirtualnej, musisz przywrócić pełne, przyrostowe/różnicowe kopie zapasowe dziennika transakcji do potrzebnego punktu.
Architektura wygląda następująco:
Ta konfiguracja nie jest odpowiednia do osiągnięcia doskonałych czasów celu punktu odzyskiwania (RPO) i celu czasu odzyskiwania (RTO). Czas czasu odzyskiwania, szczególnie spowodowany koniecznością pełnego przywrócenia pełnej bazy danych przy użyciu kopiowanych kopii zapasowych. Ta konfiguracja jest jednak przydatna do odzyskiwania po niezamierzonym usunięciu danych w wystąpieniach głównych. Dzięki tej konfiguracji w dowolnym momencie można przywrócić dane do określonego punktu w czasie, wyodrębnić dane i zaimportować usunięte dane do wystąpienia głównego. W związku z tym warto użyć metody kopiowania kopii zapasowej w połączeniu z innymi funkcjami wysokiej dostępności.
Podczas kopiowania kopii zapasowych może być możliwe użycie mniejszej maszyny wirtualnej niż główna maszyna wirtualna uruchomiona przez wystąpienie sap HANA. Należy pamiętać, że można dołączyć mniejszą liczbę dysków VHD do mniejszych maszyn wirtualnych. Aby uzyskać informacje o limitach poszczególnych typów maszyn wirtualnych, zobacz Rozmiary maszyn wirtualnych z systemem Linux na platformie Azure.
Replikacja systemu SAP HANA bez automatycznego przejścia w tryb failover
Scenariusze opisane w tej sekcji korzystają z replikacji systemu SAP HANA. Aby uzyskać dokumentację systemu SAP, zobacz Replikacja systemu. Scenariusze bez automatycznego trybu failover nie są typowe dla konfiguracji w jednym regionie świadczenia usługi Azure. Konfiguracja bez automatycznego trybu failover, choć unikanie konfiguracji programu Pacemaker, zobowiązuje Cię do ręcznego monitorowania i przełączania w tryb failover. Ponieważ wymaga to również działań i wysiłków, większość klientów polega zamiast tego na naprawie usługi platformy Azure. Istnieje kilka przypadków brzegowych, w których ta konfiguracja może pomóc w scenariuszach awarii. W niektórych przypadkach klient może chcieć zrealizować większą wydajność.
Replikacja systemu SAP HANA bez automatycznego trybu failover i bez wstępnego ładowania danych
W tym scenariuszu użyjesz replikacji systemu SAP HANA, aby przenieść dane w sposób synchroniczny w celu osiągnięcia celu celu punktu odzyskiwania o wartości 0. Z drugiej strony masz wystarczająco długi cel czasu odzyskiwania, że nie potrzebujesz przejścia w tryb failover lub wstępnego ładowania danych do pamięci podręcznej wystąpienia HANA. W takim przypadku można osiągnąć dalszą gospodarkę w konfiguracji, wykonując następujące działania:
- Uruchom kolejne wystąpienie sap HANA na drugiej maszynie wirtualnej. Wystąpienie sap HANA na drugiej maszynie wirtualnej zajmuje większość pamięci maszyny wirtualnej. W przypadku przejścia w tryb failover do drugiej maszyny wirtualnej należy zamknąć uruchomione wystąpienie platformy SAP HANA zawierające dane w pełni załadowane na drugiej maszynie wirtualnej, aby można było załadować zreplikowane dane do pamięci podręcznej docelowego wystąpienia platformy HANA na drugiej maszynie wirtualnej.
- Użyj mniejszego rozmiaru maszyny wirtualnej na drugiej maszynie wirtualnej. Jeśli nastąpi przejście w tryb failover, masz dodatkowy krok przed ręcznym przejściem w tryb failover. W tym kroku zmieniasz rozmiar maszyny wirtualnej na rozmiar źródłowej maszyny wirtualnej.
Scenariusz wygląda następująco:
Uwaga
Nawet jeśli nie używasz wstępnego ładowania danych w docelowym celu replikacji systemu HANA, potrzebujesz co najmniej 64 GB pamięci. Potrzebujesz również wystarczającej ilości pamięci oprócz 64 GB, aby zachować dane magazynu wierszy w pamięci wystąpienia docelowego.
Replikacja systemu SAP HANA bez automatycznego przełączania w tryb failover i przy wstępnego ładowania danych
W tym scenariuszu dane replikowane do wystąpienia platformy HANA na drugiej maszynie wirtualnej są wstępnie ładowane. Eliminuje to dwie zalety braku wstępnego ładowania danych. W takim przypadku nie można uruchomić innego systemu SAP HANA na drugiej maszynie wirtualnej. Nie można również użyć mniejszego rozmiaru maszyny wirtualnej. W związku z tym klienci rzadko implementują ten scenariusz.
Replikacja systemu SAP HANA z automatycznym trybem failover
W standardowej i najbardziej typowej konfiguracji dostępności w jednym regionie świadczenia usługi Azure dwie maszyny wirtualne platformy Azure z systemem Linux z pakietami wysokiej dostępności mają zdefiniowany klaster trybu failover. Klaster systemu Linux wysokiej dostępności jest oparty na Pacemaker strukturze korzystającej z systemów SLES lub RHEL z fencing device systemem SLES lub RHEL jako przykładem.
Z perspektywy platformy SAP HANA używany tryb replikacji jest synchronizowany i konfigurowany jest automatyczny tryb failover. Na drugiej maszynie wirtualnej wystąpienie platformy SAP HANA działa jako węzeł rezerwy dynamicznej. Węzeł rezerwowy odbiera synchroniczny strumień rekordów zmian z podstawowego wystąpienia platformy SAP HANA. Ponieważ transakcje są zatwierdzane przez aplikację w węźle podstawowym platformy HANA, podstawowy węzeł platformy HANA czeka na potwierdzenie zatwierdzenia do aplikacji, dopóki pomocniczy węzeł SAP HANA nie potwierdzi, że otrzymał rekord zatwierdzenia. Platforma SAP HANA oferuje dwa synchroniczne tryby replikacji. Aby uzyskać szczegółowe informacje i opis różnic między tymi dwoma synchronicznymi trybami replikacji, zobacz artykuł Tryby replikacji sap HANA dla replikacji systemu SAP HANA.
Ogólna konfiguracja wygląda następująco:
Możesz wybrać to rozwiązanie, ponieważ umożliwia osiągnięcie celu punktu odzyskiwania =0 i niskiego celu czasu odzyskiwania. Skonfiguruj łączność klienta SAP HANA, aby klienci SAP HANA używali wirtualnego adresu IP do nawiązywania połączenia z konfiguracją replikacji systemu HANA. Taka konfiguracja eliminuje konieczność ponownego skonfigurowania aplikacji, jeśli wystąpi przejście w tryb failover do węzła pomocniczego. W tym scenariuszu jednostki SKU maszyn wirtualnych platformy Azure dla podstawowych i pomocniczych maszyn wirtualnych muszą być takie same.
Następne kroki
Aby uzyskać szczegółowe wskazówki dotyczące konfigurowania tych konfiguracji na platformie Azure, zobacz:
- Konfigurowanie replikacji systemu SAP HANA na maszynach wirtualnych platformy Azure
- Wysoka dostępność platformy SAP HANA przy użyciu replikacji systemu
Aby uzyskać więcej informacji na temat dostępności oprogramowania SAP HANA w różnych regionach świadczenia usługi Azure, zobacz: