Udostępnij za pośrednictwem

SAP S/4HANA w systemie Linux na platformie Azure

Ten przewodnik przedstawia zestaw sprawdzonych rozwiązań dotyczących uruchamiania oprogramowania S/4HANA i Pakietu na platformie HANA w środowisku wysokiej dostępności(HA), które obsługuje odzyskiwanie po awarii na platformie Azure. Informacje Fiori dotyczą tylko aplikacji S/4HANA.

Architektura

Diagram architektury przedstawiający platformę SAP S/4HANA dla maszyn wirtualnych z systemem Linux w zestawie dostępności platformy Azure.

Pobierz plik programu Visio z tą architekturą.

Uwaga

Aby wdrożyć tę architekturę, upewnij się, że masz niezbędne licencje dla produktów SAP i innych technologii innych niż microsoft.

W tym przewodniku opisano typowy system produkcyjny. Ta architektura używa różnych rozmiarów maszyn wirtualnych. Aby zaspokoić potrzeby organizacji, możesz dostosować rozmiary lub zmniejszyć tę konfigurację do jednej maszyny wirtualnej.

W tym przewodniku układ sieciowy jest uproszczony w celu zademonstrowania zasad architektury. Nie reprezentuje pełnej sieci przedsiębiorstwa.

Architektura używa następujących składników. Niektóre usługi współdzielone są opcjonalne.

Azure Virtual Network. Usługa Virtual Network łączy zasoby platformy Azure ze sobą z zwiększonymi zabezpieczeniami. W tej architekturze sieć wirtualna łączy się ze środowiskiem lokalnym za pośrednictwem bramy wdrożonej w centrum topologii piasta-szprycha. Szprycha to sieć wirtualna używana dla aplikacji SAP i warstw baz danych.

Peering sieci wirtualnych. Ta architektura używa wielu sieci wirtualnych połączonych równorzędnie. Ta topologia zapewnia segmentację sieci i izolację usług wdrożonych na platformie Azure. Peering łączy sieci w sposób przejrzysty poprzez sieć szkieletową Microsoft i nie powoduje pogorszenia wydajności, jeśli jest zaimplementowany w jednym regionie. Oddzielne podsieci są używane dla każdej warstwy, w tym warstwy aplikacji (SAP NetWeaver) i warstwy bazy danych, oraz dla wspólnych komponentów, takich jak serwer przesiadkowy i Active Directory.

Vms. Ta architektura organizuje maszyny wirtualne, które uruchamiają system Linux w grupach dla warstwy aplikacji i warstwy bazy danych w następujący sposób:

  • Warstwa aplikacji. Ta warstwa architektury obejmuje pulę serwerów frontonu Fiori, pulę programu SAP Web Dispatcher, pulę serwerów aplikacji i klaster usług SAP Central Services. W przypadku wysokiej dostępności usług centralnych na platformie Azure, które działają na maszynach wirtualnych z systemem Linux, konieczna jest sieciowa usługa udziału plików, taka jak udziały plików systemu plików sieciowych (NFS) w usługach Azure Files, Azure NetApp Files, klastrowane serwery NFS lub pakiet SIOS Protection Suite dla systemu Linux. Aby skonfigurować wysokodostępny udział plików dla centralnego klastra usług w systemie Red Hat Enterprise Linux (RHEL), można skonfigurować GlusterFS na maszynach wirtualnych Azure uruchamiających RHEL. W systemie SUSE Linux Enterprise Server (SLES) 15 SP1 i nowszych wersjach lub SLES for SAP Applications można użyć dysków udostępnionych platformy Azure w klastrze Pacemaker jako mechanizmu izolującego w celu osiągnięcia wysokiej dostępności.

  • SAP HANA. Warstwa bazy danych używa co najmniej dwóch maszyn wirtualnych z systemem Linux w klastrze w celu uzyskania wysokiej dostępności we wdrożeniu skalowalnym w górę. Replikacja systemu HANA (HSR) służy do replikowania zawartości między podstawowymi i pomocniczymi systemami HANA. Klaster systemu Linux służy do wykrywania awarii systemu i ułatwia automatyczne przechodzenie w tryb failover. Należy użyć mechanizmu ogrodzenia opartego na magazynie lub w chmurze, aby zapewnić, że system, który zakończył się niepowodzeniem, jest odizolowany lub zamknięty, aby uniknąć partycjonowanego klastra. W przypadku rozproszonych wdrożeń systemu HANA można uzyskać wysoką dostępność bazy danych przy użyciu jednej z następujących opcji:

    • Konfigurowanie węzłów rezerwowych platformy HANA przy użyciu usługi Azure NetApp Files bez składnika klastrowania systemu Linux.

    • Skalowanie poziome bez węzłów rezerwowych przy użyciu usługi Azure Premium Storage. Użyj klastrowania systemu Linux dla awaryjnego przełączenia.

  • Azure Bastion. Ta usługa umożliwia nawiązywanie połączenia z maszyną wirtualną przy użyciu przeglądarki i witryny Azure Portal lub natywnego klienta protokołu Secure Shell (SSH) lub klienta protokołu RDP (Remote Desktop Protocol) zainstalowanego na komputerze lokalnym. Jeśli do administrowania są używane tylko protokoły RDP i SSH, rozważ użycie usługi Azure Bastion. Jeśli używasz innych narzędzi do zarządzania, takich jak SQL Server Management Studio lub interfejs SAP, użyj tradycyjnego serwera przesiadkowego, który samodzielnie wdrożysz.

Prywatna strefa DNS usługi.Usługa Azure Prywatna strefa DNS zapewnia niezawodną i bezpieczną usługę DNS dla sieci wirtualnej. Usługa Azure Prywatna strefa DNS zarządza i rozpoznaje nazwy domen w sieci wirtualnej bez konieczności konfigurowania niestandardowego rozwiązania DNS.

Moduły równoważenia obciążenia. Aby rozłożyć ruch do maszyn wirtualnych w podsieci warstwy aplikacji SAP i zwiększyć dostępność, użyj Azure Standard Load Balancer. Standardowy Load Balancer zapewnia warstwę zabezpieczeń domyślnie. Maszyny wirtualne, które znajdują się za standardową usługą Load Balancer, nie mają wychodzącej łączności z Internetem. Aby włączyć wychodzący ruch internetowy na maszynach wirtualnych, należy zaktualizować konfigurację Standardowego Load Balancera. Możesz również użyć usługi Azure NAT Gateway , aby uzyskać łączność wychodzącą. W przypadku aplikacji internetowej SAP wysokiej dostępności należy użyć wbudowanego modułu SAP Web Dispatcher lub innego komercyjnie dostępnego modułu równoważenia obciążenia. W oparciu o wybór:

  • Twój typ ruchu, taki jak ruch HTTP lub graficzny interfejs użytkownika SAP (GUI).
  • Potrzebne funkcje sieciowe, takie jak zakończenie SSL.

Standardowy Load Balancer obsługuje wiele front-endowych wirtualnych adresów IP. Ta obsługa jest idealna w przypadku implementacji klastrów, które obejmują następujące składniki:

  • Advanced Business Application Programming (ABAP) SAP Central Services (ASCS)
  • Kolejkowanie serwera replikacji

Te dwa składniki mogą współużytkować moduł równoważenia obciążenia, aby uprościć rozwiązanie.

Standardowy Load Balancer obsługuje również klastry SAP z wieloma identyfikatorami systemu (multi-SID). Ta funkcja umożliwia wielu systemom SAP w systemach SLES lub RHEL współużytkowanie wspólnej infrastruktury wysokiej dostępności w celu zmniejszenia kosztów. Zalecamy ocenę oszczędności kosztów i unikanie umieszczania zbyt wielu systemów w jednym klastrze. Platforma Azure obsługuje maksymalnie pięć identyfikatorów SID na klaster.

Application Gateway. aplikacja systemu Azure Gateway to moduł równoważenia obciążenia ruchu internetowego, którego można użyć do zarządzania ruchem do aplikacji internetowych. Tradycyjne moduły równoważenia obciążenia działają na warstwie transportowej, znanej jako warstwa 4 modelu Open Systems Interconnection (OSI), przy użyciu protokołu Transmission Control Protocol i protokołu User Datagram Protocol. Kierują ruch na podstawie źródłowego adresu IP i portu do docelowego adresu IP i portu. Usługa Application Gateway może podejmować decyzje dotyczące routingu na podstawie dodatkowych atrybutów żądania HTTP, takich jak jednolita ścieżka identyfikatora zasobu lub nagłówki hosta. Ten typ routingu jest nazywany warstwą aplikacji lub warstwą OSI 7, równoważeniem obciążenia. Platforma S/4HANA udostępnia usługi aplikacji internetowych za pośrednictwem aplikacji Fiori. Możesz zrównoważyć obciążenie tego frontonu Fiori, który składa się z aplikacji internetowych przy użyciu usługi Application Gateway. Jeśli używasz publicznych adresów IP, upewnij się, że używają one jednostki SKU standardowego adresu IP. Unikaj SKU podstawowego adresu IP, ponieważ zaplanowano jego wycofanie z użycia 30 września 2025 r.

Brama. Brama łączy odrębne sieci i rozszerza sieć lokalną na sieć wirtualną platformy Azure. Usługa Azure ExpressRoute to zalecana usługa platformy Azure do tworzenia połączeń prywatnych, które nie przechodzą przez publiczny Internet. Można również użyć połączenia lokacja-lokacja. Aby zmniejszyć opóźnienie, użyj usługi ExpressRoute Global Reach lub ExpressRoute FastPath.

Brama strefowo nadmiarowa. Bramy dostępu usługi ExpressRoute lub wirtualnej sieci prywatnej (VPN) można wdrażać w różnych strefach w celu ochrony przed awariami stref. Ta architektura używa strefowo redundantnych bram sieci wirtualnych zwiększających odporność zamiast wdrożenia strefowego, które bazuje na tych samych strefach dostępności.

Grupa rozmieszczania w bliskości. Ta grupa logiczna umieszcza ograniczenie na maszynach wirtualnych wdrożonych w zestawie dostępności lub zestawie skalowania maszyn wirtualnych. Grupa umiejscowienia w pobliżu pomaga wymusić kolokację, gwarantując, że maszyny wirtualne są wdrażane w tym samym centrum danych. Ta konfiguracja zmniejsza odległość fizyczną między zasobami w celu zminimalizowania opóźnienia aplikacji.

Uwaga

Aby uzyskać zaktualizowaną strategię konfiguracji, zobacz Opcje konfiguracji, aby zminimalizować opóźnienie sieci za pomocą aplikacji SAP. W tym artykule opisano potencjalne kompromisy w elastyczności wdrażania podczas optymalizowania systemu SAP pod kątem opóźnienia sieci.

Sieciowe grupy zabezpieczeń. Aby ograniczyć ruch przychodzący, wychodzący i wewnątrz podsieci w sieci wirtualnej, możesz utworzyć sieciowe grupy zabezpieczeń.

Grupy zabezpieczeń aplikacji. Aby zdefiniować szczegółowe zasady zabezpieczeń sieci oparte na obciążeniach i wyśrodkowane w aplikacjach, użyj grup zabezpieczeń aplikacji zamiast jawnych adresów IP. Maszyny wirtualne można grupować według nazw i bezpiecznych aplikacji, filtrując ruch z zaufanych segmentów sieci.

Azure Storage. Magazyn zapewnia trwałość danych dla maszyny wirtualnej w postaci wirtualnego dysku twardego. Zalecamy używanie dysków zarządzanych platformy Azure.

Zalecenia

Ta architektura opisuje małe wdrożenie na poziomie produkcyjnym. Wdrożenia różnią się w zależności od wymagań biznesowych, dlatego należy wziąć pod uwagę te rekomendacje jako punkt wyjścia.

Maszyny wirtualne

W pulach serwerów aplikacji i klastrach dostosuj liczbę maszyn wirtualnych w zależności od wymagań. Aby uzyskać więcej informacji na temat uruchamiania oprogramowania SAP NetWeaver na maszynach wirtualnych, zobacz Przewodnik planowania i implementacji usługi Azure Virtual Machines. Przewodnik dotyczy również wdrożeń sap S/4HANA.

Aby uzyskać więcej informacji na temat obsługi oprogramowania SAP dla typów maszyn wirtualnych platformy Azure i metryk przepływności, zobacz uwaga sap 1928533. Aby uzyskać dostęp do notatek SAP, potrzebne jest konto sap Service Marketplace. Aby uzyskać listę certyfikowanych maszyn wirtualnych platformy Azure dla bazy danych HANA, zobacz certyfikowany i obsługiwany przez SAP katalog sprzętu SAP HANA.

SAP Web Dispatcher

Składnik Web Dispatcher służy do równoważenia obciążenia ruchu SAP między serwerami aplikacji SAP. Aby uzyskać wysoką dostępność programu SAP Web Dispatcher, usługa Azure Load Balancer implementuje klaster trybu failover lub równoległą konfigurację narzędzia Web Dispatcher. W przypadku komunikacji z Internetem rozwiązanie autonomiczne w sieci obwodowej jest zalecaną architekturą spełniającą wymagania dotyczące zabezpieczeń. Wbudowany Dispatcher internetowy na ASCS to zaawansowana konfiguracja. Jeśli używasz tej konfiguracji, rozważ odpowiedni dobór rozmiaru ze względu na dodatkowe obciążenie na usłudze ASCS.

Serwer frontonu Fiori (FES)

Ta architektura spełnia wiele wymagań i zakłada, że używasz osadzonego modelu FIORI FES. Wszystkie składniki technologiczne są instalowane bezpośrednio w systemie S/4, więc każdy system S/4 ma własny launchpad Fiori. System S/4 zarządza konfiguracją wysokiej dostępności dla tego modelu wdrażania. Takie podejście eliminuje konieczność dodatkowego klastrowania lub maszyn wirtualnych. Z tego powodu diagram architektury nie zawiera składnika FES.

Aby uzyskać więcej informacji na temat opcji wdrażania, zobacz Opcje wdrażania SAP Fiori i zalecenia dotyczące krajobrazu systemu. Dla uproszczenia i wydajności wersje oprogramowania między składnikami technologii Fiori a aplikacjami S/4 są ściśle powiązane. Ta konfiguracja sprawia, że implementacja koncentratora jest odpowiednia tylko dla kilku konkretnych przypadków użycia.

Jeśli używasz wdrożenia centrum FES, feS jest składnikiem dodatku do klasycznego stosu SAP NetWeaver ABAP. Skonfiguruj wysoką dostępność w taki sam sposób, jak w przypadku ochrony trójwarstwowego stosu aplikacji ABAP, który ma możliwość klastrowania lub wielu hostów. Użyj warstwy bazy danych w trybie serwera zapasowego, klastrowanej warstwy ASCS z wysokodostępnym systemem plików NFS dla współdzielonego magazynu oraz co najmniej dwóch serwerów aplikacji. Ruch sieciowy jest zrównoważony za pośrednictwem pary wystąpień usługi Web Dispatcher, które mogą tworzyć klaster lub działać równolegle. W przypadku aplikacji Fiori dostępnej z Internetu zalecamy wdrożenie centrum FES w sieci obwodowej. Użyj usługi Azure Web Application Firewall w usłudze Application Gateway jako składnika krytycznego, aby odwrócić zagrożenia. Użyj identyfikatora Entra firmy Microsoft z językiem Security Assertion Markup Language na potrzeby uwierzytelniania użytkowników i logowania jednokrotnego dla oprogramowania SAP Fiori.

Diagram architektury przedstawiający przepływ danych między Internetem a dwiema sieciami wirtualnymi, jeden z sap Fiori i jeden z oprogramowaniem SAP S/4HANA.

Pobierz plik programu Visio z tą architekturą.

Aby uzyskać więcej informacji, zobacz Przychodzące i wychodzące połączenia internetowe dla oprogramowania SAP na platformie Azure.

Pula serwerów aplikacji

Aby zarządzać grupami logowania dla serwerów aplikacji ABAP, użyj następujących kodów transakcji:

  • SMLG: Równoważenie obciążenia użytkowników logujących się.
  • SM61: Zarządzanie grupami serwerów wsadowych.
  • RZ12: Zarządzanie grupami wywołań funkcji zdalnych (RFC).

Te transakcje opierają się na możliwości równoważenia obciążenia na serwerze komunikatów usług centralnych w celu dystrybucji sesji przychodzących i obciążeń w puli serwerów aplikacji SAP, które zarządzają ruchem INTERFEJSU UŻYTKOWNIKA SAP i RFC.

Klaster usług SAP Central Services

Usługi SAP Central Services zawierają jedno wystąpienie serwera komunikatów i usługę replikacji w kolejce. W przeciwieństwie do procesów roboczych serwerów aplikacji te składniki są pojedynczymi punktami awarii w stosie aplikacji SAP. Usługi Centralne można wdrożyć na jednej maszynie wirtualnej, gdy umowa dotycząca poziomu usług (SLA) platformy Azure dla maszyn wirtualnych z pojedynczym wystąpieniem spełnia Twoje wymagania. Jeśli umowa SLA wymaga wyższej dostępności, musisz wdrożyć te usługi w klastrze wysokiej dostępności. Aby uzyskać więcej informacji, zobacz Usługi centralne w warstwie serwerów aplikacji.

Networkowanie

Ta architektura wykorzystuje topologię z węzłem centralnym i odgałęzieniami, w której wirtualna sieć węzła centralnego służy jako centralny punkt łączności z firmową siecią lokalną. Szprychy to sieci wirtualne, które łączą się z piastą. Szprychy umożliwiają izolowanie obciążeń. Ruch przepływa między lokalnym centrum danych a koncentratorem za pośrednictwem połączenia bramy.

Karty interfejsu sieciowego

Tradycyjne lokalne wdrożenia SAP implementują wiele kart interfejsów sieciowych na maszynę w celu oddzielenia ruchu administracyjnego od ruchu biznesowego. Na platformie Azure sieć wirtualna to sieć zdefiniowana programowo, która kieruje cały ruch przez jedną sieć szkieletową sieci. W związku z tym nie potrzebujesz wielu kart sieciowych ze względu na wydajność. Jeśli twoja organizacja musi segregować ruch, możesz wdrożyć wiele kart sieciowych dla każdej maszyny wirtualnej, połączyć każdą kartę sieciową z inną podsiecią, a następnie użyć sieciowych grup zabezpieczeń, aby ułatwić wymuszanie różnych zasad kontroli dostępu.

Karty sieciowe platformy Azure obsługują wiele adresów IP. Ta obsługa jest zgodna z praktyką, którą firma SAP zaleca: używanie wirtualnych nazw hostów dla instalacji opisanych w SAP note 962955.

Podsieci i sieciowe grupy zabezpieczeń

Ta architektura dzieli przestrzeń adresową sieci wirtualnej na podsieci. Każdą podsieć można skojarzyć z sieciową grupą zabezpieczeń, która definiuje zasady dostępu dla podsieci. Umieść serwery aplikacji w oddzielnej podsieci. Takie podejście ułatwia zabezpieczanie serwerów aplikacji przez zarządzanie zasadami zabezpieczeń podsieci zamiast poszczególnych serwerów.

Po skojarzeniu sieciowej grupy zabezpieczeń z podsiecią sieciowa grupa zabezpieczeń ma zastosowanie do wszystkich serwerów w podsieci i zapewnia szczegółową kontrolę nad serwerami. Skonfiguruj sieciowe grupy zabezpieczeń przy użyciu portalu Azure, programu Azure PowerShell lub interfejsu Azure CLI.

ExpressRoute Global Reach

Jeśli środowisko sieciowe zawiera co najmniej dwa obwody usługi ExpressRoute, usługa ExpressRoute Global Reach może pomóc zmniejszyć przeskoki sieciowe i zmniejszyć opóźnienie. Ta technologia to połączenie równorzędne trasowania protokołu Border Gateway Protocol skonfigurowane między co najmniej dwoma obwodami usługi ExpressRoute w celu połączenia dwóch domen routingu usługi ExpressRoute. Usługa Global Reach zmniejsza opóźnienie, gdy ruch sieciowy przechodzi przez więcej niż jeden obwód usługi ExpressRoute. Jest dostępna tylko dla prywatnego łącza równorzędnego w obwodach usługi ExpressRoute.

Usługa Global Reach nie obsługuje zmian list kontroli dostępu do sieci ani innych atrybutów. Wszystkie trasy otrzymane przez obwód usługi ExpressRoute, zarówno ze środowiska lokalnego, jak i platformy Azure, są rozgłaszane w ramach komunikacji równorzędnej do innych obwodów usługi ExpressRoute. Zalecamy skonfigurowanie lokalnego filtrowania ruchu sieciowego w celu ograniczenia dostępu do zasobów.

FastPath

Program FastPath implementuje wymiany przeglądarki Microsoft Edge w punkcie wejścia sieci platformy Azure. Funkcja FastPath zmniejsza przeskoki sieciowe dla większości pakietów danych. W związku z tym funkcja FastPath zmniejsza opóźnienie sieci, zwiększa wydajność aplikacji i jest domyślną konfiguracją nowych połączeń usługi ExpressRoute z platformą Azure.

W przypadku istniejących obwodów usługi ExpressRoute skontaktuj się z pomoc techniczna platformy Azure, aby aktywować usługę FastPath.

Program FastPath nie obsługuje komunikacji równorzędnej sieci wirtualnych. Jeśli sieć wirtualna połączona z usługą ExpressRoute jest połączona z innymi sieciami wirtualnymi, ruch z sieci lokalnej do innych peryferyjnych sieci wirtualnych jest kierowany przez bramę sieci wirtualnej. Aby rozwiązać ten problem, połącz wszystkie sieci wirtualne bezpośrednio z obwodem usługi ExpressRoute.

Moduły równoważenia obciążenia

Program SAP Web Dispatcher obsługuje równoważenie obciążenia ruchu HTTP i HTTPS do puli serwerów aplikacji SAP. Ten programowy moduł równoważenia obciążenia oferuje usługi warstwy aplikacyjnej, znane jako warstwa 7 w modelu sieci ISO, które umożliwiają kończenie sesji SSL i wykonywanie innych funkcji odciążających.

Load Balancer to usługa warstwy transportowej (warstwa 4), która równoważy ruch przy użyciu skrótu pięcioelementowego ze strumieni danych. Skrót jest oparty na źródłowym adresie IP, porcie źródłowym, docelowym adresie IP, porcie docelowym i typie protokołu. Usługa Load Balancer jest używana w konfiguracjach klastra do kierowania ruchu do wystąpienia podstawowej usługi lub zdrowego węzła, jeśli wystąpi błąd. Zalecamy używanie usługa Load Balancer w warstwie Standardowa dla wszystkich scenariuszy SAP. Standardowy Load Balancer jest domyślnie bezpieczny, a żadne maszyny wirtualne za Standardowym Load Balancerem nie mają wychodzącej łączności z Internetem. Aby włączyć wychodzący internet w maszynach wirtualnych, należy dostosować konfigurację Standardowego Load Balancer.

W przypadku ruchu z klientów SAP GUI łączących się z serwerem SAP za pośrednictwem protokołu Dynamic Information and Action Gateway (DIAG) lub RFC, serwer komunikatów usług centralnych równoważy obciążenie za pośrednictwem grup logowania serwera aplikacji SAP. Nie jest potrzebny dodatkowy moduł równoważenia obciążenia.

Magazynowanie

Niektórzy klienci używają magazynu standardowego dla serwerów aplikacji. Ponieważ standardowe zarządzane dyski nie są obsługiwane, zalecamy używanie dysków Azure Premium SSD lub Azure NetApp Files w każdym przypadku. Najnowsza aktualizacja noty SAP 2015553 wyklucza korzystanie z magazynu Azure Standard HDD i Azure Standard SSD dla kilku konkretnych przypadków użycia.

Ponieważ serwery aplikacji nie hostują żadnych danych biznesowych, można również użyć mniejszych dysków P4 i P6 Premium, aby ułatwić zarządzanie kosztami. W przypadku aplikacji SAP zdecydowanie zalecamy używanie dysków SSD platformy Azure w wersji 1, SSD w wersji 2 lub Ultra Disk. Aby dowiedzieć się, jak typ magazynu wpływa na umowę SLA dotyczącą dostępności maszyny wirtualnej, zobacz Umowy SLA dotyczące usług online. W przypadku scenariuszy wysokiej dostępności funkcje dysków współdzielonych Azure są dostępne na Azure Premium SSD i Azure Ultra Dysk Storage. Aby uzyskać więcej informacji, zobacz Dyski zarządzane platformy Azure i typy dysków zarządzanych platformy Azure.

Można używać udostępnionych dysków Azure z systemami Windows Server, SLES 15 z Service Packiem SP1 lub nowszym i SLES dla systemu SAP. W przypadku korzystania ze współdzielonego dysku Azure w klastrach Linux, współdzielony dysk Azure działa jako element odgradzający dla urządzenia blokowego uszkodzonego węzła. Zapewnia głosowanie kworum w scenariuszu rozdzielenia sieci klastra. Ten dysk udostępniony nie ma systemu plików i nie obsługuje równoczesnych zapisów z wielu maszyn wirtualnych członkowskich klastra.

Usługa Azure NetApp Files ma wbudowane funkcje udostępniania plików dla systemu plików NFS i SMB.

W przypadku scenariuszy udostępniania NFS usługa Azure NetApp Files zapewnia wysoką dostępność zasobów NFS, które mogą być używane dla /hana/shared, /hana/data, i /hana/log woluminów. Aby uzyskać gwarancję dostępności, zobacz Umowy SLA dotyczące usług online. Jeśli używasz udziałów NFS opartych na Azure NetApp Files dla woluminów /hana/data i /hana/log, musisz użyć protokołu NFS w wersji 4.1. W przypadku woluminu /hana/shared obsługiwany jest protokół NFS v3.

W przypadku magazynu danych kopii zapasowych zalecamy korzystanie z chłodnej i archiwalnej warstwy dostępu platformy Azure. Te warstwy magazynowania to ekonomiczne sposoby przechowywania długożytnych danych, do których rzadko uzyskuje się dostęp. Rozważ również użycie warstwy standardowej usługi Azure NetApp Files jako elementu docelowego kopii zapasowej lub opcji kopii zapasowej usługi Azure NetApp Files. W przypadku dysku zarządzanego zalecana warstwa danych kopii zapasowej to warstwa chłodnego dostępu lub archiwalnego dostępu platformy Azure.

Warstwa Ultra Disk Storage i Azure NetApp Files w warstwie Ultra znacznie zmniejszają opóźnienie dysku i zwiększają wydajność krytycznych aplikacji i serwerów baz danych SAP.

Premium SSD w wersji 2 jest przeznaczony dla obciążeń o kluczowym znaczeniu dla wydajności, takich jak SAP. Aby uzyskać więcej informacji na temat korzyści i ograniczeń tego rozwiązania do przechowywania, zobacz Deploy a Premium SSD v2.

Zagadnienia dotyczące wydajności

Serwery aplikacji SAP stale komunikują się z serwerami baz danych. W przypadku aplikacji o krytycznym znaczeniu dla wydajności, które działają na dowolnej platformie bazy danych, w tym sap HANA, włącz akcelerator zapisu dla woluminu dziennika, jeśli używasz dysku SSD w warstwie Premium w wersji 1. Takie podejście może poprawić opóźnienie zapisu w dzienniku. Dysk SSD na warstwie Premium v2 nie używa przyspieszacza zapisu. Akcelerator zapisu jest dostępny dla maszyn wirtualnych serii M.

Aby zoptymalizować komunikację między serwerami, użyj przyspieszonej sieci. Większość rozmiarów wystąpień maszyn wirtualnych ogólnego przeznaczenia i zoptymalizowanych pod kątem obliczeń, które mają co najmniej dwa procesory wirtualne, obsługują przyspieszoną sieć. Na instancjach obsługujących hiperwątkowość, instancje maszyn wirtualnych z czterema lub więcej wirtualnymi jednostkami CPU obsługują przyspieszoną sieć.

Należy zoptymalizować stos TCP/IP i bufory systemu Linux w interfejsie sieciowym aby osiągnąć spójną wydajność. Postępuj zgodnie z zalecanymi ustawieniami firmy Microsoft. Na przykład dostosujesz elementy, takie jak:

  • Parametry jądra do optymalizowania pamięci odczytu i zapisu
  • Kontrola przeciążenia przepustowości wąskich gardeł i czasu propagacji w obie strony (BBR)
  • Dostosowywanie parametrów TCP w celu zapewnienia lepszej spójności i przepływności
  • Bufory pierścieniowe kart sieciowych dla TX/RX

Aby uzyskać więcej informacji na temat wymagań dotyczących wydajności platformy SAP HANA, zobacz uwaga sap 1943937.

Aby uzyskać wysokie operacje wejścia/wyjścia na sekundę (IOPS) i przepływność przepustowości dysku, postępuj zgodnie z typowymi rozwiązaniami dotyczącymi optymalizacji wydajności woluminu magazynu. Na przykład połączenie wielu dysków w celu utworzenia woluminu dysku paskowego może zwiększyć wydajność I/O. Włączenie pamięci podręcznej odczytu dla zawartości pamięci masowej, która zmienia się rzadko, może również przyspieszyć pobieranie danych. Aby uzyskać więcej informacji, zobacz Konfiguracje magazynu maszyn wirtualnych platformy Azure SAP HANA.

Premium SSD w wersji 2 jest zaprojektowany dla obciążeń krytycznych dla wydajności, takich jak SAP. Aby uzyskać więcej informacji o korzyściach, ograniczeniach i optymalnych scenariuszach użycia, zobacz Typy dysków zarządzanych platformy Azure.

Ultra Disk Storage to nowa generacja pamięci, która spełnia intensywne wymagania dotyczące operacji wejścia/wyjścia na sekundę (IOPS) oraz zapewnia wymaganą przepustowość transferu dla aplikacji, takich jak SAP HANA. Możesz dynamicznie zmieniać wydajność dysków w warstwie Ultra i niezależnie konfigurować metryki, takie jak liczba operacji we/wy na sekundę i mb/s bez ponownego uruchamiania maszyny wirtualnej. Zalecamy korzystanie z pamięci Ultra Disk Storage zamiast technologii Write Accelerator, kiedy tylko to możliwe.

Niektóre aplikacje SAP wymagają częstej komunikacji z bazą danych. Ze względu na odległość opóźnienie sieci między warstwami aplikacji i bazy danych może negatywnie wpłynąć na wydajność aplikacji. Grupy umieszczania w pobliżu usługi Azure nakładają ograniczenie dotyczące umieszczenia dla maszyn wirtualnych, które są wdrażane w zestawach dostępności. W ramach logicznej konstrukcji grupy kolokacja i wydajność są preferowane w przypadku skalowalności, dostępności i kosztów. Grupy umieszczania w bliskości mogą znacznie poprawić doświadczenie użytkownika dla większości aplikacji SAP.

Umieszczanie wirtualnego urządzenia sieciowego (WUS) między aplikacją a warstwami bazy danych dowolnego stosu aplikacji SAP nie jest obsługiwane. NVA wymaga znacznego czasu na przetwarzanie pakietów danych. W związku z tym niedopuszczalnie spowalnia wydajność aplikacji.

Zalecamy również rozważenie wydajności podczas wdrażania zasobów ze strefami dostępności, co może zwiększyć dostępność usługi. Rozważ utworzenie jasnego profilu opóźnienia sieci między wszystkimi strefami regionu docelowego. Takie podejście ułatwia podjęcie decyzji o umieszczeniu zasobów w celu minimalnego opóźnienia między strefami. Aby utworzyć ten profil, uruchom test, wdrażając małe maszyny wirtualne w każdej strefie. Zalecane narzędzia do testu obejmują psPing i Iperf. Po przetestowaniu usuń te maszyny wirtualne. Aby zapoznać się z narzędziem do testowania opóźnienia sieci w domenie publicznej, którego można użyć, zobacz Test opóźnienia strefy dostępności.

Usługa Azure NetApp Files oferuje unikatowe funkcje wydajności, które umożliwiają dostrajanie w czasie rzeczywistym w celu zaspokojenia potrzeb najbardziej wymagających środowisk SAP. Aby zapoznać się z zagadnieniami dotyczącymi wydajności podczas korzystania z usługi Azure NetApp Files, zobacz Ustalanie rozmiaru bazy danych HANA w usłudze Azure NetApp Files.

Zagadnienia dotyczące skalowalności

W warstwie aplikacji SAP platforma Azure udostępnia szeroką gamę rozmiarów maszyn wirtualnych na potrzeby skalowania w górę i skalowania w poziomie. Aby zapoznać się z pełną listą, zobacz Aplikacje SAP na platformie Azure: obsługiwane produkty i typy maszyn wirtualnych platformy Azure w notatce SAP 1928533. Więcej typów maszyn wirtualnych jest stale certyfikowanych, dzięki czemu można skalować w górę lub w dół w tym samym wdrożeniu w chmurze.

W warstwie bazy danych ta architektura uruchamia aplikacje SAP S/4HANA na maszynach wirtualnych platformy Azure, które mogą skalować do 24 terabajtów (TB) w jednym wystąpieniu. Jeśli obciążenie przekracza maksymalny rozmiar maszyny wirtualnej, możesz użyć konfiguracji wielu węzłów dla maksymalnie 96 tb (cztery wystąpienia 24 TB) na potrzeby aplikacji przetwarzania transakcji online. Aby uzyskać więcej informacji, zobacz Certyfikowany i obsługiwany katalog sprzętowy SAP HANA.

Zagadnienia dotyczące dostępności

Nadmiarowość zasobów to ogólny motyw rozwiązań infrastruktury o wysokiej dostępności. Aby uzyskać informacje o poziomach usług SLA dotyczących dostępności maszyn wirtualnych dla pojedynczego wystąpienia i różnych typów magazynu, zobacz Poziomy usług SLA dla usług online. Aby zwiększyć dostępność usług na platformie Azure, wdróż zasoby maszyn wirtualnych przy użyciu usługi Azure Virtual Machine Scale Sets, która zapewnia elastyczne aranżacje, strefy dostępności i zestawy dostępności.

Model wdrażania regionalnych zestawów dostępności platformy Azure jest obsługiwaną opcją. Zalecamy jednak wdrożenie zestawów skalowania maszyn wirtualnych z modelem stref dostępności dla nowych wdrożeń SAP w celu zwiększenia dostępności i zwiększenia elastyczności wdrażania.

W tej rozproszonej instalacji aplikacji SAP instalacja podstawowa jest replikowana w celu uzyskania wysokiej dostępności. Dla każdej warstwy architektury projekt wysokiej dostępności (HA) różni się.

Metody 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 oferuje różne opcje wdrażania, takie jak zestawy skalowania maszyn wirtualnych z elastyczną aranżacją (jedną konfiguracją domeny błędów), strefami dostępności i zestawami dostępności, aby zwiększyć dostępność zasobów.

W miarę zwiększania się wdrożeń klientów na platformie Azure firma Microsoft zwiększyła modele wdrażania maszyn wirtualnych platformy Azure w celu uwzględnienia zestawów skalowania maszyn wirtualnych w celu zapewnienia elastyczności i odporności w chmurze. Biorąc pod uwagę dostępne opcje wdrażania, zdecydowanie zalecamy użycie wdrożenia strefowego zestawu skalowania elastycznego platformy Azure dla wszystkich nowych wdrożeń. Aby uzyskać więcej informacji na temat wdrażania między strefami, w ramach jednej strefy i w regionach bez stref, zobacz Architektura wysokiej dostępności i scenariusze dla oprogramowania SAP NetWeaver.

Dyspozytor sieci Web w warstwie serwerów aplikacji

Wysoką dostępność można osiągnąć dzięki nadmiarowym instancjom narzędzia Web Dispatcher. Aby uzyskać więcej informacji, zobacz SAP Web Dispatcher. Poziom dostępności zależy od rozmiaru aplikacji, która znajduje się za usługą Web Dispatcher. W małych wdrożeniach, które mają kilka problemów ze skalowalnością, można kolokować usługę Web Dispatcher za pomocą maszyn wirtualnych usługi ASCS. Takie podejście pomaga zaoszczędzić na niezależnej konserwacji systemu operacyjnego i uzyskać wysoką dostępność w tym samym czasie.

Usługi centralne w warstwie serwerów aplikacji

W przypadku wysokiej dostępności usług centralnych na maszynach wirtualnych z systemem Linux platformy Azure użyj odpowiedniego rozszerzenia wysokiej dostępności dla wybranej dystrybucji systemu Linux. Zwyczajowe jest umieszczanie udostępnionych systemów plików na magazynie NFS o wysokiej dostępności przy użyciu SUSE Distributed Replicated Block Device lub Red Hat GlusterFS. Aby zapewnić system plików NFS o wysokiej dostępności i wyeliminować potrzebę klastra NFS, możesz użyć innych ekonomicznych lub niezawodnych rozwiązań, takich jak NFS za pośrednictwem usługi Azure Files lub Azure NetApp Files. Udziały usługi Azure NetApp Files mogą hostować pliki danych i dziennika SAP HANA. Ta konfiguracja umożliwia skalowalne wdrażanie HANA z węzłami zapasowymi, podczas gdy NFS na platformie Azure Files dobrze sprawdza się w przypadku udostępniania plików o wysokiej dostępności niezwiązanych z bazą danych.

System plików NFS za pośrednictwem usługi Azure Files obsługuje teraz udziały plików o wysokiej dostępności zarówno dla systemów SLES , jak i RHEL. To rozwiązanie działa dobrze w przypadku wysoko dostępnych udziałów plików, takich jak /sapmnt i /saptrans w instalacjach SAP.

Usługa Azure NetApp Files obsługuje HA dla ASCS w systemie SLES. Aby uzyskać więcej informacji na temat usługi ASCS w systemie RHEL HA, zobacz SIOS Protection Suite for Linux.

Ulepszony agent ogrodzenia platformy Azure jest dostępny zarówno dla systemów SUSE jak i Red Hat, i zapewnia znacznie szybsze przejście w tryb failover usługi niż poprzednia wersja agenta.

Inną opcją ogrodzenia jest użycie dysków udostępnionych platformy Azure dla urządzenia ogrodzenia. W systemie SLES 15 SP1 lub SLES dla SAP 15 i późniejszych wersjach można skonfigurować klaster Pacemaker przy użyciu dysków udostępnionych platformy Azure. Ta opcja jest prosta i nie wymaga otwartego portu sieciowego, takiego jak agent ogrodzenia platformy Azure.

Niedawno obsługiwana i prostsza konfiguracja programu Pacemaker w systemie SLES 15 i nowszych jest wysoka dostępność oprogramowania SAP NetWeaver z prostą instalacją i systemem plików NFS w systemie SLES dla maszyn wirtualnych aplikacji SAP. W tej konfiguracji udziały plików SAP są wyjęte z zarządzania klastrem, co upraszcza obsługę. Użyj tej konfiguracji wysokiej dostępności dla wszystkich nowych wdrożeń.

Aby dodatkowo zarządzać kosztami dużego środowiska SAP, klaster systemu Linux obsługuje instalację wielu identyfikatorów SID usługi ASCS na platformie Azure. Udostępnianie klastra dostępności między wieloma systemami SAP upraszcza środowisko SAP i zmniejsza koszty operacji.

W warstwie Standard Load Balancer można włączyć port HA i uniknąć konieczności konfigurowania reguł równoważenia obciążenia dla wielu portów SAP. Ogólnie rzecz biorąc, jeśli podczas konfigurowania modułu równoważenia obciążenia włączysz funkcję zwrotu bezpośredniego serwera (DSR), odpowiedzi serwera na zapytania klienta mogą pominąć moduł równoważenia obciążenia. Ta funkcja jest również nazywana zmiennym adresem IP. Moduł równoważenia obciążenia może być lokalny lub na platformie Azure. To bezpośrednie połączenie sprawia, że moduł równoważenia obciążenia staje się wąskim gardłem w ścieżce transmisji danych. W przypadku klastrów baz danych ASCS i HANA zalecamy włączenie DSR. Jeśli maszyny wirtualne w puli zaplecza wymagają publicznej łączności wychodzącej, wymagana jest dalsza konfiguracja .

W przypadku ruchu z klientów interfejsu GUI SAP łączących się z serwerem SAP za pośrednictwem protokołu DIAG lub RFC serwer komunikatów usług centralnych równoważy obciążenie przy użyciu grup logowania serwera aplikacji SAP. Nie jest potrzebny dodatkowy moduł równoważenia obciążenia.

Serwery aplikacji w warstwie serwerów aplikacji

Wysoką dostępność można osiągnąć przez równoważenie obciążenia ruchu w puli serwerów aplikacji.

Warstwa bazy danych

Architektura w tym przewodniku przedstawia wysoce dostępny system bazy danych SAP HANA składający się z dwóch maszyn wirtualnych platformy Azure. Funkcja natywnej replikacji systemu na poziomie bazy danych zapewnia ręczne lub automatyczne przełączanie awaryjne między zreplikowanymi węzłami.

  • W przypadku ręcznego przejścia w tryb failover wdróż więcej niż jedno wystąpienie platformy HANA i użyj modułu HSR.

  • W przypadku automatycznego przełączenia awaryjnego użyj zarówno rozszerzenia HSR, jak i rozszerzenia Linux HA (HAE) dla swojej dystrybucji systemu Linux. Rozszerzenie Wysokiej Dostępności dla systemu Linux zapewnia usługi klastrowe dla zasobów platformy HANA, wykrywa zdarzenia awarii i koordynuje automatyczną zmianę uszkodzonych usług do węzła w dobrej kondycji.

Wdrażanie maszyn wirtualnych w różnych strefach dostępności

Strefy dostępności mogą zwiększyć dostępność usługi. Strefy odwołują się do fizycznie rozdzielonych lokalizacji w określonym regionie świadczenia usługi Azure. Zwiększają one dostępność obciążeń i chronią usługi aplikacji i maszyny wirtualne przed awariami centrum danych. Maszyny wirtualne w jednej strefie są traktowane tak, jakby były w jednej domenie aktualizacji lub błędów. Po wybraniu wdrożenia strefowego maszyny wirtualne w tej samej strefie są dystrybuowane do domen usuwania awarii i aktualizacji na zasadzie najlepszych starań.

W regionach platformy Azure , które obsługują tę funkcję, dostępne są co najmniej trzy strefy. Maksymalna odległość między centrami danych w tych strefach nie jest gwarantowana. Aby wdrożyć wielowarstwowy system SAP w różnych strefach, musisz znać opóźnienie sieci w strefie i w różnych strefach docelowych oraz jak wrażliwe są wdrożone aplikacje w przypadku opóźnienia sieci.

Podczas podejmowania decyzji o wdrożeniu zasobów w różnych strefach dostępności należy wziąć pod uwagę następujące kwestie:

  • Opóźnienie między maszynami wirtualnymi w jednej strefie
  • Opóźnienie między maszynami wirtualnymi w wybranych strefach
  • Dostępność tych samych usług platformy Azure lub typów maszyn wirtualnych w wybranych strefach

Uwaga

Nie zalecamy stref dostępności do odtwarzania po awarii. Lokalizacja DR powinna znajdować się co najmniej 100 mil od lokalizacji głównej, aby uwzględnić klęski żywiołowe. Nie można zagwarantować dokładnej odległości między centrami danych.

Przykład wdrożenia aktywnego/pasywnego

W tym przykładowym wdrożeniu stan aktywny/pasywny odnosi się do stanu usługi aplikacji w strefach. W warstwie aplikacji wszystkie cztery aktywne serwery aplikacji systemu SAP znajdują się w strefie 1. Inny zestaw czterech pasywnych serwerów aplikacji jest wbudowany w strefę 2, ale jest zamykany. Są one aktywowane tylko w razie potrzeby.

Dwuwęzłowe klastry dla usługi centralnej i bazy danych są rozmieszczone w dwóch strefach. Jeśli strefa 1 zakończy się niepowodzeniem, usługi centralne i usługi bazy danych działają w strefie 2. Pasywne serwery aplikacji w strefie 2 są aktywowane. Po przeniesieniu wszystkich składników tego systemu SAP w tej samej strefie opóźnienie sieci jest zminimalizowane.

Przykład aktywnego/aktywnego wdrożenia

W przypadku wdrożenia aktywnego/aktywnego dwa zestawy serwerów aplikacji są tworzone w dwóch strefach. W każdej strefie dwa serwery aplikacji w każdym zestawie są aktywne. W związku z tym istnieją aktywne serwery aplikacji w obu strefach w normalnych operacjach.

Usługi ASCS i bazy danych działają w strefie 1. Serwery aplikacji w strefie 2 mogą mieć dłuższe opóźnienie sieci podczas nawiązywania połączenia z usługami ASCS i baz danych ze względu na fizyczną odległość między strefami.

Jeśli strefa 1 przejdzie w tryb offline, usługi ASCS i bazy danych przełączają się do strefy 2. Uśpione serwery aplikacji mogą zostać uruchomione, aby zapewnić pełną moc obliczeniową dla przetwarzania aplikacji.

Zagadnienia dotyczące odzyskiwania po awarii

Każda warstwa w stosie aplikacji SAP używa innego podejścia do zapewnienia ochrony po awarii. Aby uzyskać informacje na temat strategii odzyskiwania po awarii i implementacji, zobacz Omówienie odzyskiwania po awarii i wskazówki dotyczące infrastruktury dla obciążeń SAP i wytycznych dotyczących odzyskiwania po awarii dla aplikacji SAP.

Uwaga

Jeśli wystąpi katastrofa regionalna, która powoduje masowe przełączanie awaryjne dla wielu klientów platformy Azure w jednym regionie, pojemność zasobów regionu docelowego nie jest gwarantowana. Podobnie jak wszystkie usługi platformy Azure, usługa 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.

Aby zapewnić dostępną wydajność zasobów dla regionu odzyskiwania po awarii, użyj rezerwacji wydajności na żądanie. Platforma Azure umożliwia połączenie zniżki na zarezerwowane instancje z rezerwacją pojemności w celu zmniejszenia kosztów.

Zagadnienia dotyczące kosztów

Koszty możesz szacować za pomocą kalkulatora cen platformy Azure.

Aby uzyskać więcej informacji, zobacz Optymalizacja kosztów platformy Azure Well-Architected Framework.

Maszyny wirtualne

Ta architektura korzysta z maszyn wirtualnych z systemem Linux na potrzeby zarządzania, aplikacji SAP i warstw bazy danych.

Istnieje kilka opcji płatności dla maszyn wirtualnych:

  • W przypadku obciążeń, które nie mają przewidywalnego czasu ukończenia lub użycia zasobów, rozważ opcję płatności zgodnie z rzeczywistym użyciem.

  • Rozważ użycie rezerwacji platformy Azure , jeśli możesz zobowiązać się do korzystania z maszyny wirtualnej w okresie jednego roku lub trzech lat. Rezerwacje maszyn wirtualnych mogą znacznie obniżyć koszty. Możesz zaoszczędzić do 72% w porównaniu do opcji płatności z bieżącą stawką.

  • Użyj Spot VMs Azure do uruchamiania obciążeń, które mogą być przerywane i nie muszą być ukończone w wcześniej określonych ramach czasowych ani zgodnie z umową SLA. Platforma Azure wdraża maszyny wirtualne typu spot, gdy jest dostępna pojemność i eksmituje je, gdy potrzebuje pojemności z powrotem. Koszty maszyn wirtualnych typu spot są niższe niż inne maszyny wirtualne. Rozważ użycie maszyn wirtualnych typu spot dla tych obciążeń:

    • Scenariusze obliczeń o wysokiej wydajności, zadania przetwarzania wsadowego lub aplikacje do renderowania wizualnego

    • Środowiska testowe, w tym obciążenia ciągłej integracji i ciągłego dostarczania

    • aplikacje bezstanowe na dużą skalę;

  • Zarezerwowane wystąpienia maszyn wirtualnych platformy Azure mogą zmniejszyć całkowity koszt użytkowania, łącząc stawki za zarezerwowane wystąpienia z subskrypcją w modelu płatności za rzeczywiste użycie, dzięki czemu można zarządzać kosztami w przewidywalnych i zmiennych obciążeniach. Aby uzyskać więcej informacji, zobacz Wystąpienia zarezerwowane maszyn wirtualnych platformy Azure.

Aby zapoznać się z omówieniem cen, zobacz Cennik maszyn wirtualnych z systemem Linux.

Równoważnik obciążenia

W tym scenariuszu moduły równoważenia obciążenia platformy Azure są używane do dystrybucji ruchu do maszyn wirtualnych w podsieci warstwy aplikacji.

Opłaty są naliczane tylko za liczbę skonfigurowanych reguł równoważenia obciążenia i ruchu wychodzącego. Reguły tłumaczenia adresów sieciowych dla ruchu przychodzącego są bezpłatne. Nie ma opłaty godzinowej za usługa Load Balancer w warstwie Standardowa, gdy nie skonfigurowano żadnych reguł.

ExpressRoute

W tej architekturze usługa ExpressRoute to usługa sieciowa używana do tworzenia połączeń prywatnych między siecią lokalną a sieciami wirtualnymi platformy Azure.

Cały transfer danych przychodzących jest bezpłatny. Opłaty za cały transfer danych wychodzących są naliczane na podstawie wstępnie ustalonej stawki. Aby uzyskać więcej informacji, zobacz Cennik usługi ExpressRoute.

Zagadnienia dotyczące zarządzania i operacji

Aby ułatwić utrzymanie działania systemu w środowisku produkcyjnym, należy wziąć pod uwagę następujące kwestie.

Centrum platformy Azure dla rozwiązań SAP

Usługa Azure Center for SAP Solutions to kompleksowe rozwiązanie umożliwiające tworzenie i uruchamianie systemów SAP jako ujednoliconego obciążenia na platformie Azure i zapewniające bardziej bezproblemowe podstawy innowacji. Przewodnik wskazujący proces wdrażania w Azure Center for SAP solutions tworzy niezbędne składniki obliczeniowe, magazynowe i sieciowe potrzebne do uruchomienia systemu SAP. Następnie możesz zautomatyzować instalację oprogramowania SAP zgodnie z najlepszymi rozwiązaniami firmy Microsoft. Możesz skorzystać z możliwości zarządzania zarówno dla nowych, jak i istniejących systemów SAP opartych na platformie Azure.

Kopia zapasowa

Kopie zapasowe danych platformy SAP HANA można tworzyć na wiele sposobów. Po przeprowadzeniu migracji na platformę Azure kontynuuj korzystanie z istniejących rozwiązań do tworzenia kopii zapasowych. Platforma Azure oferuje dwa natywne podejścia do tworzenia kopii zapasowych. Możesz utworzyć kopię zapasową oprogramowania SAP HANA na maszynach wirtualnych lub użyć usługi Azure Backup na poziomie pliku. Usługa Azure Backup ma certyfikat Backint firmy SAP. Aby uzyskać więcej informacji, zobacz Azure Backup FAQ and Support matrix for backup of SAP HANA databases on Azure VMs (Często zadawane pytania dotyczące usługi Azure Backup i macierz obsługi tworzenia kopii zapasowych baz danych SAP HANA na maszynach wirtualnych platformy Azure).

Uwaga

Tylko wdrożenia pojedynczego kontenera lub skalowania w górę platformy HANA obsługują migawki usługi Azure Storage.

Zarządzanie tożsamościami

Użyj scentralizowanego systemu zarządzania tożsamościami, aby kontrolować dostęp do zasobów na wszystkich poziomach.

Nadzorowanie

Aby zmaksymalizować dostępność i wydajność aplikacji i usług na platformie Azure, użyj usługi Azure Monitor. Usługa Azure Monitor to kompleksowe rozwiązanie do zbierania, analizowania i działania na podstawie danych telemetrycznych z chmury i środowisk lokalnych. Usługa Azure Monitor pokazuje, jak aplikacje działają i aktywnie identyfikują problemy, które mają na nie wpływ, oraz zasoby, od których zależą. Aby uzyskać informacje o aplikacjach SAP uruchamianych na platformie SAP HANA i innych głównych rozwiązaniach 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.

Zagadnienia dotyczące zabezpieczeń

System SAP ma własny aparat zarządzania użytkownikami do kontrolowania dostępu opartego na rolach i autoryzacji w aplikacjach i bazach danych SAP. Aby uzyskać więcej informacji, zobacz Omówienie zabezpieczeń oprogramowania SAP HANA.

Aby zwiększyć bezpieczeństwo sieci, rozważ użycie sieci obwodowej korzystającej z NVA do utworzenia zapory przed podsiecią dla usługi Web Dispatcher i pul serwerów frontend Fiori. Aby zminimalizować koszty transferu danych, należy wdrożyć aktywne serwery frontonu hostujące aplikacje Fiori w tej samej sieci wirtualnej co systemy S/4. Alternatywnie można skonfigurować te serwery front-end w sieci obwodowej, wykorzystując peering sieci wirtualnych do nawiązania łączności z systemami S/4.

W przypadku zabezpieczeń infrastruktury dane są szyfrowane podczas przesyłania i przechowywania. Aby uzyskać informacje na temat zabezpieczeń sieci, które dotyczą platformy S/4HANA, zobacz Zabezpieczenia dla środowiska SAP.

Aby zaszyfrować dyski maszyn wirtualnych z systemem Linux, masz kilka opcji. W przypadku szyfrowania danych w stanie spoczynku SAP HANA zalecamy użycie natywnej technologii szyfrowania SAP HANA. Aby uzyskać obsługę szyfrowania dysków platformy Azure w określonych dystrybucjach, wersjach i obrazach systemu Linux, zobacz Usługa Azure Disk Encryption dla maszyn wirtualnych z systemem Linux.

Uwaga

Nie używaj szyfrowania danych magazynowanych HANA i usługi Azure Disk Encryption na tym samym woluminie pamięci. W przypadku platformy HANA użyj szyfrowania danych HANA za pośrednictwem szyfrowania po stronie serwera usługi Azure Disk Storage. Użycie kluczy zarządzanych przez klienta może mieć wpływ na przepływność operacji we/wy.

Społeczności

Społeczności mogą odpowiadać na pytania i pomagać w skonfigurowaniu udanego wdrożenia. Rozważ następujące zasoby:

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główny autor:

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

Następne kroki

Aby uzyskać więcej informacji i przykłady obciążeń SAP korzystających z niektórych tych samych technologii co ta architektura, zobacz następujące artykuły: