Uruchamianie platformy SAP HANA dla maszyn wirtualnych z systemem Linux w architekturze skalowanej w górę na platformie Azure

Azure
Azure Virtual Machines

Ta architektura referencyjna przedstawia zestaw sprawdzonych rozwiązań dotyczących uruchamiania oprogramowania SAP HANA w środowisku o wysokiej dostępności skalowalnym w górę obsługującym odzyskiwanie po awarii na platformie Azure. Ta implementacja koncentruje się tylko na warstwie bazy danych.

Architektura

Ta architektura referencyjna opisuje wspólny system produkcyjny. Rozmiary maszyn wirtualnych można wybrać, aby zaspokoić potrzeby organizacji. Tę konfigurację można również zmniejszyć do jednej maszyny wirtualnej, w zależności od wymagań biznesowych.

Na poniższym diagramie przedstawiono architekturę referencyjną platformy SAP HANA na platformie Azure:

Diagram przedstawiający architekturę wdrażania regionalnego.

Pobierz plik programu Visio zawierający diagramy w tym artykule.

Uwaga

Aby wdrożyć tę architekturę referencyjną, potrzebne jest odpowiednie licencjonowanie produktów SAP i innych technologii innych niż microsoft.

Przepływ pracy

Ta architektura referencyjna opisuje typową bazę danych SAP HANA działającą na platformie Azure we wdrożeniu o wysokiej dostępności w celu zmaksymalizowania dostępności systemu. Architektura i jej składniki można dostosować na podstawie wymagań biznesowych (RTO, RPO, oczekiwań czasu pracy, roli systemu) i potencjalnie zredukowanych do pojedynczej maszyny wirtualnej. Układ sieciowy jest uproszczony, aby zademonstrować jednostki architektury takiego środowiska SAP i nie mają na celu opisania pełnej sieci przedsiębiorstwa.

Sieć

Sieci wirtualne. Usługa Azure Virtual Network łączy ze sobą zasoby platformy Azure z zwiększonymi zabezpieczeniami. W tej architekturze sieć wirtualna łączy się ze środowiskiem lokalnym za pośrednictwem bramy usługi ExpressRoute wdrożonej w centrum topologii piasty i szprych. Baza danych SAP HANA jest zawarta we własnej sieci wirtualnej będącej szprychą. Sieci wirtualne będące szprychami zawierają jedną podsieć dla maszyn wirtualnych bazy danych.

Jeśli aplikacje łączące się z platformą SAP HANA są uruchomione na maszynach wirtualnych, maszyny wirtualne aplikacji powinny znajdować się w tej samej sieci wirtualnej, ale w dedykowanej podsieci aplikacji. Alternatywnie, jeśli połączenie SAP HANA nie jest podstawową bazą danych, maszyny wirtualne aplikacji mogą znajdować się w innych sieciach wirtualnych. Rozdzielenie na podsieci według obciążenia umożliwia łatwiejsze włączanie sieciowych grup zabezpieczeń w celu ustawienia reguł zabezpieczeń mających zastosowanie tylko do maszyn wirtualnych SAP HANA.

Brama strefowo nadmiarowa. Brama łączy różne sieci, rozszerzając sieć lokalną na sieć wirtualną platformy Azure. Zalecamy używanie usługi ExpressRoute do tworzenia połączeń prywatnych, które nie przechodzą przez publiczny Internet. Można również użyć połączenia lokacja-lokacja. Bramy usługi Azure ExpressRoute lub vpn można wdrażać w różnych strefach, aby chronić przed awariami stref. Zobacz Strefowo nadmiarowe bramy sieci wirtualnej, aby zrozumieć różnice między wdrożeniem strefowym a wdrożeniem strefowo nadmiarowym. Używane adresy IP muszą być standardową jednostkę SKU dla wdrożenia stref bram.

Sieciowe grupy zabezpieczeń (NSG). Aby ograniczyć przychodzący i wychodzący ruch sieciowy sieci wirtualnej, utwórz sieciowe grupy zabezpieczeń, które są z kolei przypisane do określonych podsieci. Podsieci bazy danych i aplikacji są zabezpieczone za pomocą sieciowych grup zabezpieczeń specyficznych dla obciążenia.

Grupy zabezpieczeń aplikacji (ASG). Aby zdefiniować szczegółowe zasady zabezpieczeń sieci wewnątrz sieciowych grup zabezpieczeń na podstawie obciążeń, które są skoncentrowane na aplikacjach, użyj grup zabezpieczeń aplikacji zamiast jawnych adresów IP. Umożliwiają one grupowanie interfejsów sieciowych maszyn wirtualnych według nazw i ułatwia zabezpieczanie aplikacji przez filtrowanie ruchu z zaufanych segmentów sieci.

Karty interfejsu sieciowego (karty sieciowe). Karty interfejsu sieciowego umożliwiają całą komunikację między maszynami wirtualnymi w sieci wirtualnej. Tradycyjne lokalne wdrożenia SAP implementują wiele kart sieciowych na maszynę w celu oddzielenia ruchu administracyjnego od ruchu biznesowego.

Na platformie Azure nie jest konieczne używanie wielu kart sieciowych ze względów wydajności. Wiele kart sieciowych ma ten sam limit przepływności sieci maszyny wirtualnej. Jeśli jednak twoja organizacja musi segregować ruch, możesz wdrożyć wiele kart sieciowych na maszynę wirtualną i połączyć każdą kartę sieciową z inną podsiecią. Następnie można użyć sieciowych grup zabezpieczeń, aby wymusić różne zasady kontroli dostępu w każdej podsieci.

Karty sieciowe platformy Azure obsługują wiele adresów IP. Ta obsługa jest zgodna z zalecaną praktyką sap dotyczącą używania nazw hostów wirtualnych do instalacji. Aby uzyskać pełny konspekt, zobacz 962955 uwagi SAP. (Aby uzyskać dostęp do notatek SAP, potrzebne jest konto w witrynie SAP Service Marketplace).

Uwaga

Jak określono w artykule SAP Note 2731110, nie umieszczaj żadnego wirtualnego urządzenia sieciowego (WUS) między aplikacją a warstwami bazy danych dla stosu aplikacji SAP. W ten sposób wprowadzono znaczne ilości czasu przetwarzania pakietów danych i niedopuszczalnie spowalnia wydajność aplikacji.

Maszyny wirtualne

Ta architektura korzysta z maszyn wirtualnych. Platforma Azure oferuje skalowanie pojedynczego węzła w górę do 23.5 Tebibytes (TiB) pamięci na maszynach wirtualnych. Katalog sprzętowy SAP Certified and Supported SAP HANA zawiera listę maszyn wirtualnych certyfikowanych dla bazy danych SAP HANA. Aby uzyskać szczegółowe informacje o obsłudze oprogramowania SAP dla typów maszyn wirtualnych i metryk przepływności (SAPS), zobacz SAP Note 1928533 — SAP Applications on Microsoft Azure: Supported Products and Azure VM types (Sap Applications on Microsoft Azure: Supported Products and Azure VM types). (Aby uzyskać dostęp do tych i innych notatek SAP, wymagane jest konto platformy Marketplace sap Service).

Firma Microsoft i SAP wspólnie certyfikowają szereg rozmiarów maszyn wirtualnych dla obciążeń SAP HANA. Na przykład mniejsze wdrożenia mogą być uruchamiane na maszynie wirtualnej Edsv4 lub Edsv5 z 160 GiB lub więcej pamięci RAM. Aby obsługiwać największe rozmiary pamięci sap HANA na maszynach wirtualnych, aż 23 TiB, można użyć maszyn wirtualnych serii Mv2. Typy maszyn wirtualnych M208 osiągają około 260 000 SAPS i M832ixs, osiągając około 795 900 SAPS.

Maszyny wirtualne generacji 2 (Gen2). Podczas wdrażania maszyn wirtualnych można użyć maszyn wirtualnych generacji 1 lub 2. generacji. Maszyny wirtualne generacji 2 obsługują kluczowe funkcje, które nie są dostępne dla maszyn wirtualnych generacji 1. W przypadku platformy SAP HANA jest to szczególnie ważne, ponieważ niektóre rodziny maszyn wirtualnych, takie jak Mv2 i Mdsv2, są obsługiwane tylko jako maszyny wirtualne gen2. Podobnie certyfikacja oprogramowania SAP na platformie Azure dla niektórych nowszych maszyn wirtualnych może wymagać, aby były tylko gen2 w celu uzyskania pełnej pomocy technicznej, nawet jeśli platforma Azure zezwala na obie te maszyny. Zobacz szczegóły w temacie SAP Note 1928533 — SAP Applications on Microsoft Azure: Supported Products and Azure VM types (Aplikacje SAP na platformie Microsoft Azure: obsługiwane produkty i typy maszyn wirtualnych platformy Azure).

Ponieważ wszystkie inne maszyny wirtualne obsługujące platformę SAP HANA zezwalają na wybór tylko gen2 lub gen1+2 selektywnie, zalecamy wdrożenie wszystkich maszyn wirtualnych SAP tylko jako gen2. Dotyczy to również maszyn wirtualnych z niskimi wymaganiami dotyczącymi pamięci. Nawet najmniejsza 160 gib maszyny wirtualnej SAP HANA może działać jako maszyna wirtualna Gen2 i może być, po cofnięciu przydziału, można zmienić rozmiar na największą maszynę wirtualną dostępną w twoim regionie i subskrypcji.

Grupy umieszczania w pobliżu (PPG). Aby zoptymalizować opóźnienie sieci, można użyć grup umieszczania w pobliżu, co sprzyja kolokacji, co oznacza, że maszyny wirtualne znajdują się w tym samym centrum danych, aby zminimalizować opóźnienia między platformą SAP HANA i łączeniem maszyn wirtualnych aplikacji. W przypadku samej architektury platformy SAP HANA nie są potrzebne żadne grupy zabezpieczeń, są one tylko opcją kolokowania platformy SAP HANA z maszynami wirtualnymi warstwy aplikacji. Ze względu na potencjalne ograniczenia dotyczące ppg należy dodać bazę danych AvSet do ppG systemu SAP, a tylko wtedy, gdy jest to wymagane w przypadku opóźnienia między ruchem aplikacji SAP i bazy danych. Aby uzyskać więcej informacji na temat scenariuszy użycia ppg, zobacz połączoną dokumentację. Ponieważ grupy ppg ograniczają obciążenia do pojedynczego centrum danych, grupa PPG nie może obejmować wielu stref dostępności.

Składniki

Kwestie wymagające rozważenia

W tej sekcji opisano kluczowe zagadnienia dotyczące uruchamiania oprogramowania SAP HANA na platformie Azure.

Skalowalność

Ta architektura umożliwia uruchomienie oprogramowania SAP HANA na maszynach wirtualnych, które mogą skalować w górę do 23 TiB w jednym wystąpieniu.

Jeśli obciążenie przekracza maksymalny rozmiar maszyny wirtualnej, zalecamy użycie konfiguracji platformy HANA z wieloma węzłami. W przypadku aplikacji przetwarzania transakcji online (OLTP) łączna pojemność pamięci skalowanej w poziomie może wynosić nawet 4 x 23 TiB. W przypadku aplikacji przetwarzania analitycznego online (OLAP) pojemność pamięci skalowanej w poziomie może wynosić nawet 16 x 7,6 TiB. Można na przykład wdrożyć platformę SAP HANA w konfiguracji skalowanej w poziomie z rezerwą na maszynach wirtualnych — z systemem Red Hat Enterprise Linux lub SUSE Linux Enterprise Server — przy użyciu usługi Azure NetApp Files dla udostępnionych woluminów magazynu.

Storage

Ta architektura używa dysków zarządzanych platformy Azure do magazynowania na maszynach wirtualnych lub w usłudze Azure NetApp Files. Wytyczne dotyczące wdrażania magazynu z dyskami zarządzanymi znajdują się szczegółowo w dokumencie Konfiguracja magazynu maszyn wirtualnych platformy Azure sap HANA. Alternatywnie w przypadku dysków zarządzanych woluminy NFS usługi Azure NetApp Files mogą być używane jako rozwiązanie magazynu dla platformy SAP HANA.

Aby uzyskać operacje na dużą liczbę operacji wejścia/wyjścia na sekundę (IOPS) i przepływność magazynu na dysku, typowe rozwiązania w zakresie optymalizacji wydajności woluminu magazynu mają zastosowanie również do układu magazynu platformy Azure. Na przykład połączenie wielu dysków z lvm w celu utworzenia woluminu dysku rozłożonego zwiększa wydajność operacji we/wy. Buforowanie dysków platformy Azure odgrywa również znaczącą rolę w osiągnięciu wymaganej wydajności operacji we/wy.

W przypadku dysków dziennika SAP HANA, które działają na dyskach SSD w warstwie Premium platformy Azure w wersji 1, użyj jednej z następujących technologii w lokalizacjach, które przechowują /hana/log w środowisku produkcyjnym:

Te technologie są potrzebne do spójnego spełnienia wymaganego opóźnienia magazynu mniejszego niż 1 ms.

Usługa Azure Premium SSD w wersji 2 została zaprojektowana pod kątem obciążeń o znaczeniu krytycznym dla wydajności, takich jak SAP. Akcelerator zapisu nie jest wymagany, gdy /hana/log jest uruchomiony na dysku SSD w warstwie Premium w wersji 2. Aby uzyskać informacje na temat korzyści i bieżących ograniczeń rozwiązania magazynu, zobacz Wdrażanie dysku SSD w warstwie Premium w wersji 2.

Aby uzyskać szczegółowe informacje na temat wymagań dotyczących wydajności platformy SAP HANA, zobacz Sap Note 1943937 — narzędzie do sprawdzania konfiguracji sprzętu.

  • Projekt magazynu świadomy kosztów dla systemów nieprodukcyjnych. W przypadku środowisk SAP HANA, które nie wymagają maksymalnej wydajności magazynu we wszystkich sytuacjach, możesz użyć architektury magazynu zoptymalizowanej pod kątem kosztów. Ten wybór optymalizacji magazynu może mieć zastosowanie do mało używanych systemów produkcyjnych lub niektórych nieprodukcyjnych środowisk SAP HANA. Opcja magazynu zoptymalizowana pod kątem kosztów korzysta z kombinacji dysków SSD w warstwie Standardowa zamiast dysków SSD w warstwie Premium lub Ultra, które są używane w środowiskach produkcyjnych. Łączy również /hana/data i /hana/log systemy plików na jeden zestaw dysków. Wytyczne i najlepsze rozwiązania są dostępne dla większości rozmiarów maszyn wirtualnych. Jeśli używasz usługi Azure NetApp Files dla platformy SAP HANA, możesz użyć woluminów o mniejszym rozmiarze, aby osiągnąć ten sam cel.

  • Zmiana rozmiaru magazynu podczas skalowania w górę. W przypadku zmiany rozmiaru maszyny wirtualnej ze względu na zmienione wymagania biznesowe lub z powodu rosnącego rozmiaru bazy danych konfiguracja magazynu może ulec zmianie. pomoc techniczna platformy Azure rozszerzenie dysku online bez żadnych przerw w działaniu usługi. W przypadku konfiguracji dysku rozłożonego, tak jak w przypadku platformy SAP HANA, należy wykonać operację zmiany rozmiaru równą wszystkim dyskom w grupie woluminów. Dodanie większej liczby dysków do grupy woluminów może potencjalnie nie równoważyć danych rozłożonych. Jeśli dodasz więcej dysków do konfiguracji magazynu, lepiej jest utworzyć nowy wolumin magazynu na nowych dyskach. Następnie skopiuj zawartość podczas przestoju i zmodyfikuj punkty instalacji. Na koniec odrzuć starą grupę woluminów i dyski bazowe.

  • Grupa woluminów aplikacji usługi Azure NetApp Files. W przypadku wdrożeń z plikami SAP HANA zawartymi w woluminach NFS usługi Azure NetApp Files grupy woluminów aplikacji umożliwiają wdrażanie wszystkich woluminów zgodnie z najlepszymi rozwiązaniami. Ten proces zapewnia również optymalną wydajność bazy danych SAP HANA. Szczegółowe informacje o tym, jak kontynuować ten proces. Wymaga ręcznej interwencji. Poczekaj trochę czasu na utworzenie.

Wysoka dostępność

Poprzednia architektura przedstawia wdrożenie o wysokiej dostępności, a platforma SAP HANA znajduje się na co najmniej dwóch maszynach wirtualnych. Używane są następujące składniki.

Moduły równoważenia obciążenia.Usługa Azure Load Balancer służy do dystrybucji ruchu do maszyn wirtualnych SAP HANA. W przypadku uwzględnienia usługi Azure Load Balancer we wdrożeniu strefowym oprogramowania SAP upewnij się, że wybrano moduł równoważenia obciążenia jednostki SKU w warstwie Standardowa. Moduł równoważenia jednostek SKU w warstwie Podstawowa nie obsługuje nadmiarowości strefowej. W tej architekturze usługa Load Balancer działa jako wirtualny adres IP dla platformy SAP HANA. Ruch sieciowy jest wysyłany do aktywnej maszyny wirtualnej, na której działa podstawowe wystąpienie bazy danych. Dostępna jest architektura systemu SAP HANA z obsługą aktywnego/odczytu (SLES/RHEL), w której drugi wirtualny adres IP skierowany do modułu równoważenia obciążenia służy do kierowania ruchu sieciowego do pomocniczego wystąpienia platformy SAP HANA na innej maszynie wirtualnej na potrzeby obciążeń intensywnie obciążanych odczytem.

Usługa Load Balancer w warstwie Standardowa domyślnie zapewnia warstwę zabezpieczeń. Maszyny wirtualne, które znajdują się za usługa Load Balancer w warstwie Standardowa, nie mają wychodzącej łączności z Internetem. Aby włączyć wychodzący Internet na tych maszynach wirtualnych, należy zaktualizować konfigurację usługa Load Balancer w warstwie Standardowa. Ponadto możesz również użyć bramy translatora adresów sieciowych platformy Azure, aby uzyskać łączność wychodzącą.

W przypadku klastrów baz danych SAP HANA należy włączyć bezpośredni zwrot serwera (DSR), znany również jako pływający adres IP. Ta funkcja umożliwia serwerowi odpowiadanie na adres IP frontonu modułu równoważenia obciążenia. To bezpośrednie połączenie sprawia, że moduł równoważenia obciążenia staje się wąskim gardłem w ścieżce transmisji danych.

Opcje wdrażania. Na platformie Azure wdrożenie obciążenia SAP może być regionalne lub strefowe, w zależności od wymagań dotyczących dostępności i odporności aplikacji SAP. Platforma Azure udostępnia różne opcje wdrażania, takie jak zestawy skalowania maszyn wirtualnych z elastyczną orkiestracją (FD=1), strefami dostępności i zestawami dostępności, aby zwiększyć dostępność zasobów. Aby uzyskać kompleksową wiedzę na temat dostępnych opcji wdrażania i ich stosowania w różnych regionach platformy Azure (w tym między strefami, w jednej strefie lub w regionie bez stref), zobacz Architektura i scenariusze wysokiej dostępności oprogramowania SAP NetWeaver.

SAP HANA. Aby zapewnić wysoką dostępność, platforma SAP HANA działa na co najmniej dwóch maszynach wirtualnych z systemem Linux. Replikacja systemu SAP HANA (HSR) służy do replikowania danych między podstawowymi i pomocniczymi (replikami) systemami SAP HANA. Moduł HSR jest również używany do odzyskiwania po awarii między regionami lub między strefami. W zależności od opóźnienia komunikacji między maszynami wirtualnymi replikacja synchroniczna może być używana w obrębie regionu. Moduł HSR między regionami na potrzeby odzyskiwania po awarii w większości przypadków będzie działać w sposób asynchroniczny.

W przypadku klastra Pacemaker systemu Linux należy zdecydować, który mechanizm ogrodzenia klastra ma być używany. Ogrodzenie klastra to proces izolowania maszyny wirtualnej, która zakończyła się niepowodzeniem z klastra i ponownego uruchomienia. W przypadku systemu RedHat Enterprise Linux (RHEL) jedynym obsługiwanym mechanizmem ogrodzenia dla programu Pacemaker na platformie Azure jest agent ogrodzenia platformy Azure. W przypadku serwera SUSE Linux Enterprise Server (SLES) można użyć agenta ogrodzenia platformy Azure lub urządzenia STONITH Block Device (SBD). Porównaj czasy pracy w trybie failover dla każdego rozwiązania i, jeśli istnieje różnica, wybierz rozwiązanie na podstawie wymagań biznesowych dotyczących celu czasu odzyskiwania (RTO).

Agent ogrodzenia platformy Azure. Ta metoda ogrodzenia opiera się na interfejsie API usługi Azure ARM, a narzędzie Pacemaker wysyła zapytanie do interfejsu API usługi ARM o stan obu maszyn wirtualnych SAP HANA w klastrze. W przypadku awarii jednej maszyny wirtualnej, na przykład awarii systemu operacyjnego lub awarii maszyny wirtualnej, menedżer klastra ponownie używa interfejsu API usługi ARM do ponownego uruchomienia maszyny wirtualnej i w razie potrzeby baza danych SAP HANA do drugiego, aktywnego węzła. W tym celu jednostka nazwy usługi (SPN) z rolą niestandardową do wykonywania zapytań i ponownego uruchamiania maszyn wirtualnych jest używana do autoryzacji względem interfejsu API usługi ARM. Żadna inna infrastruktura nie jest potrzebna, maszyny wirtualne SBD na rysunkach architektury nie są wdrażane w przypadku użycia agenta ogrodzenia platformy Azure.

SBD. Urządzenie blokowe STONITH (SBD) używa dysku, który jest uzyskiwany jako urządzenie blokowe (nieprzetworzone, bez systemu plików) przez menedżera klastra. Ten dysk lub dyski, jeśli wiele, działa jako głosowanie. Każdy z dwóch węzłów klastra z systemem SAP HANA uzyskuje dostęp do dysków SDB i okresowo odczytuje/zapisuje do nich małe fragmenty informacji o stanie. W związku z tym każdy węzeł klastra wie o innym stanie bez względu na sieć między maszynami wirtualnymi.

Najlepiej, aby trzy małe maszyny wirtualne zostały wdrożone w konfiguracji zestawu dostępności lub strefy dostępności. Każda maszyna wirtualna eksportuje małe części dysku jako urządzenie blokowe, do którego uzyskuje dostęp dwa węzły klastra SAP HANA. Trzy maszyny wirtualne SBD zapewniają dostępność wystarczających członków głosowania w przypadku planowanych lub nieplanowanych przestojów dla maszyny wirtualnej SBD.

Alternatywnie do korzystania z maszyn wirtualnych SBD można zamiast tego użyć dysku udostępnionego platformy Azure. Węzły klastra SAP HANA uzyskują dostęp do pojedynczego dysku udostępnionego. Dysk udostępniony może być lokalnie nadmiarowy (LRS) lub strefowo (ZRS), jeśli magazyn ZRS jest dostępny w Twoim regionie świadczenia usługi Azure.

Odzyskiwanie po awarii

Poniższa architektura przedstawia środowisko produkcyjne platformy HANA na platformie Azure, które zapewnia odzyskiwanie po awarii. Architektura obejmuje strefy dostępności.

Diagram przedstawiający architekturę z odzyskiwaniem po awarii.

Aby uzyskać szczegółowe informacje na temat strategii odzyskiwania po awarii i implementacji, zobacz Omówienie odzyskiwania po awarii i wskazówki dotyczące infrastruktury dotyczące obciążeń SAP i wytycznych dotyczących odzyskiwania po awarii dla aplikacji SAP.

Uwaga

Jeśli wystąpi awaria regionalna, która powoduje duże zdarzenie trybu failover dla wielu klientów platformy Azure w jednym regionie, pojemność zasobu regionu docelowego nie jest gwarantowana. Podobnie jak wszystkie usługi platformy Azure, usługa Azure Site Recovery nadal dodaje funkcje i możliwości. Aby uzyskać najnowsze informacje na temat replikacji z platformy Azure do platformy Azure, zobacz macierz obsługi.

Oprócz lokalnej implementacji wysokiej dostępności z dwoma węzłami moduł HSR obsługuje replikację wielowarstwową i wielotargetową . W związku z tym moduł HSR obsługuje replikację między strefami i między regionami. Replikacja wielotargetowa jest dostępna dla oprogramowania SAP HANA 2.0 SPS 03 lub nowszego.

Upewnij się, że masz zweryfikowaną pojemność zasobu regionu docelowego.

Azure NetApp Files. Jako opcja usługa Azure NetApp Files może służyć do zapewnienia skalowalnego i wysokiej wydajności rozwiązania magazynu dla plików danych i dzienników sap HANA. Usługa Azure NetApp Files obsługuje migawki na potrzeby szybkiej kopii zapasowej, odzyskiwania i replikacji lokalnej. W przypadku replikacji zawartości między regionami replikacja między regionami usługi Azure NetApp Files może służyć do replikowania danych migawki między dwoma regionami. Szczegółowe informacje na temat replikacji między regionami i oficjalny dokument opisujący wszystkie aspekty odzyskiwania po awarii za pomocą usługi Azure NetApp Files są dostępne.

Wykonywanie kopii zapasowej

Kopie zapasowe danych platformy SAP HANA można wykonywać na wiele sposobów. Po przeprowadzeniu migracji na platformę Azure możesz nadal korzystać z istniejących rozwiązań do tworzenia kopii zapasowych partnerów. Platforma Azure oferuje dwa natywne podejścia: tworzenie kopii zapasowych na poziomie plików sap HANA i usługę Azure Backup dla platformy SAP HANA za pośrednictwem interfejsu Backint.

W przypadku tworzenia kopii zapasowej na poziomie plików sap HANA możesz użyć wybranego narzędzia, takiego jak hdbsql lub SAP HANA Studio, i zapisać pliki kopii zapasowej na woluminie dysku lokalnego. Typowym punktem instalacji dla tego woluminu kopii zapasowej jest /hana/backup. Zasady tworzenia kopii zapasowych zdefiniują okres przechowywania danych na woluminie. Po utworzeniu kopii zapasowej zaplanowane zadanie powinno skopiować pliki kopii zapasowej do usługi Azure Blob Storage w celu zapewnienia bezpieczeństwa. Lokalne pliki kopii zapasowej są przechowywane w celu przyspieszenia odzyskiwania.

Usługa Azure Backup oferuje proste rozwiązanie klasy korporacyjnej dla obciążeń działających na maszynach wirtualnych. Usługa Azure Backup dla oprogramowania SAP HANA zapewnia pełną integrację z wykazem kopii zapasowych platformy SAP HANA i gwarantuje spójne, pełne lub pełne odzyskiwanie bazy danych. Usługa Azure Backup ma certyfikat BackInt firmy SAP. Zobacz również macierz często zadawanych pytań i obsługi usługi Azure Backup.

Usługa Azure NetApp Files zapewnia obsługę kopii zapasowych opartych na migawkach. Integracja z platformą SAP HANA na potrzeby migawek spójnych na poziomie aplikacji odbywa się za pomocą narzędzia aplikacja systemu Azure Spójne migawki (AzAcSnap). Utworzone migawki mogą służyć do przywracania do nowego woluminu na potrzeby przywracania systemu lub kopiowania bazy danych SAP HANA. Utworzone migawki mogą służyć do odzyskiwania po awarii, gdzie działa jako punkt przywracania z dziennikami platformy SAP HANA zapisanymi na innym woluminie NFS.

Monitorowanie

Aby monitorować obciążenia na platformie Azure, usługa Azure Monitor umożliwia kompleksowe zbieranie, analizowanie i reagowanie na dane telemetryczne ze środowisk chmurowych i lokalnych.

W przypadku aplikacji SAP uruchamianych na platformie SAP HANA i innych głównych rozwiązań baz danych zobacz Azure Monitor for SAP solutions (Usługa Azure Monitor dla rozwiązań SAP), aby dowiedzieć się, jak usługa Azure Monitor dla systemu SAP może pomóc w zarządzaniu dostępnością i wydajnością usług SAP.

Zabezpieczenia

Wiele środków zabezpieczeń służy do ochrony poufności, integralności i dostępności środowiska SAP. Aby zabezpieczyć dostęp użytkowników, na przykład system SAP ma własny aparat zarządzania użytkownikami (UME) w celu kontrolowania dostępu i autoryzacji opartej na rolach w aplikacjach i bazach danych SAP. Aby uzyskać więcej informacji, zobacz Zabezpieczenia SAP HANA — omówienie.

W przypadku danych magazynowanych różne funkcje szyfrowania zapewniają bezpieczeństwo w następujący sposób:

  • Oprócz natywnej technologii szyfrowania SAP HANA rozważ użycie rozwiązania szyfrowania od partnera obsługującego klucze zarządzane przez klienta.

  • Aby zaszyfrować dyski maszyny wirtualnej, można użyć funkcji opisanych w temacie Omówienie szyfrowania dysków.

  • Serwery bazy danych SAP: użyj funkcji Transparent Data Encryption oferowanego przez dostawcę DBMS (na przykład natywnej technologii szyfrowania SAP HANA), aby ułatwić zabezpieczanie plików danych i dzienników oraz zapewnienie, że kopie zapasowe są również szyfrowane.

  • Dane w magazynie fizycznym platformy Azure (szyfrowanie po stronie serwera) są automatycznie szyfrowane w spoczynku przy użyciu klucza zarządzanego platformy Azure. Możesz również wybrać klucz zarządzany przez klienta (CMK) zamiast klucza zarządzanego platformy Azure.

  • Aby uzyskać informacje o obsłudze usługi Azure Disk Encryption w określonych dystrybucjach, wersjach i obrazach systemu Linux, zobacz Usługa Azure Disk Encryption dla maszyn wirtualnych z systemem Linux.

Uwaga

Nie należy łączyć natywnej technologii szyfrowania SAP HANA z usługą Azure Disk Encryption lub szyfrowaniem opartym na hoście na tym samym woluminie magazynu. Ponadto dyski rozruchowe systemu operacyjnego dla maszyn wirtualnych z systemem Linux nie obsługują usługi Azure Disk Encryption. Zamiast tego w przypadku korzystania z szyfrowania natywnego SAP HANA połącz je z szyfrowaniem po stronie serwera, które jest automatycznie włączone. Należy pamiętać, że użycie kluczy zarządzanych przez klienta może mieć wpływ na przepływność magazynu.

W przypadku zabezpieczeń sieciowych użyj sieciowych grup zabezpieczeń i usługi Azure Firewall lub wirtualnego urządzenia sieciowego w następujący sposób:

  • Sieciowe grupy zabezpieczeń umożliwiają ochronę i kontrolowanie ruchu między podsieciami a warstwami aplikacji/bazy danych. Zastosuj sieciowe grupy zabezpieczeń tylko do podsieci. Sieciowe grupy zabezpieczeń stosowane do karty sieciowej i podsieci bardzo często prowadzą do problemów podczas rozwiązywania problemów i powinny być rzadko używane, jeśli kiedykolwiek.

  • Użyj usługi Azure Firewall lub wirtualnego urządzenia sieciowego platformy Azure, aby sprawdzić i kontrolować routing ruchu z sieci wirtualnej piasty do sieci wirtualnej będącej szprychą, w której znajdują się aplikacje SAP, a także kontrolować wychodzącą łączność z Internetem.

W przypadku użytkowników i autoryzacji zaimplementuj kontrolę dostępu opartą na rolach (RBAC) i blokady zasobów w następujący sposób:

  • Postępuj zgodnie z zasadą najniższych uprawnień, używając kontroli dostępu opartej na rolach na potrzeby przypisywania uprawnień administracyjnych w zasobach na poziomie IaaS hostujących rozwiązanie SAP na platformie Azure. Podstawowym celem kontroli dostępu opartej na rolach jest segregacja i kontrola obowiązków użytkowników/grup. Kontrola dostępu oparta na rolach została zaprojektowana w celu udzielenia dostępu tylko do zasobów potrzebnych do umożliwienia użytkownikom wykonywania zadań.

  • Użyj blokad zasobów, aby zapobiec przypadkowym lub złośliwym zmianom. Blokady zasobów ułatwiają administratorom usuwanie lub modyfikowanie krytycznych zasobów platformy Azure, w których znajduje się rozwiązanie SAP.

Więcej zaleceń dotyczących zabezpieczeń można znaleźć w tych artykułach firmy Microsoft i SAP .

Społeczności

Społeczności mogą odpowiadać na pytania i pomagać w skonfigurowaniu udanego wdrożenia. Weź pod uwagę następujące społeczności:

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

Dowiedz się więcej o technologiach składników:

Zapoznaj się z powiązanymi architekturami: