Obsługiwane scenariusze obciążenia SAP na maszynie wirtualnej na platformie Azure

  • Artykuł

Projektowanie architektury systemów SAP NetWeaver, Hybris Business one lub S/4HANA na platformie Azure otwiera wiele różnych możliwości dla różnych architektur i narzędzi do użycia w celu uzyskania skalowalnego, wydajnego i wysoce dostępnego wdrożenia. Chociaż jest to zależne od używanego systemu operacyjnego lub systemu DBMS, istnieją ograniczenia. Ponadto nie wszystkie scenariusze obsługiwane lokalnie są obsługiwane w taki sam sposób na platformie Azure. W tym dokumencie przedstawiono obsługiwane konfiguracje nieodostępne oraz konfiguracje i architektury o wysokiej dostępności przy użyciu wyłącznie maszyn wirtualnych platformy Azure.

Uwaga

Usługa dużych wystąpień platformy HANA jest w trybie zachodu słońca i nie akceptuje już nowych klientów. Zapewnianie jednostek dla istniejących klientów dużych wystąpień HANA jest nadal możliwe. Aby uzyskać alternatywy, zapoznaj się z ofertami certyfikowanych maszyn wirtualnych platformy Azure HANA w katalogu sprzętowym HANA. W przypadku scenariuszy, które były i nadal są obsługiwane dla istniejących klientów dużych wystąpień HANA z dużymi wystąpieniami platformy HANA, zapoznaj się z artykułem Obsługiwane scenariusze dla dużych wystąpień platformy HANA.

Ogólne ograniczenia platformy

Platforma Azure ma różne platformy oprócz tak zwanych natywnych maszyn wirtualnych platformy Azure, które są oferowane jako usługa pierwszej firmy. Duże wystąpienia platformy HANA, które są w trybie zachodu słońca, jest jedną z tych platform. Usługi Azure VMware Services to kolejna z tych usług innych firm. Ogólnie rzecz biorąc, usługi Azure VMware Services nie są obsługiwane przez oprogramowanie SAP do hostowania obciążenia SAP. Aby uzyskać więcej informacji na temat obsługi oprogramowania VMware na różnych platformach, zapoznaj się z artykułem #2138865 — aplikacje SAP w chmurze VMware: obsługiwane produkty i konfiguracje maszyn wirtualnych .

Oprócz lokalna usługa Active Directory platforma Azure oferuje zarządzaną usługę Active Directory SaaS z usługami Microsoft Entra Domain Services (tradycyjnymi usługami AD zarządzanymi przez firmę Microsoft) i Microsoft Entra ID. Składniki SAP hostowane w systemie operacyjnym Windows często polegają na użyciu usługi Windows Active Directory. W takim przypadku tradycyjna usługa Active Directory, która jest hostowana lokalnie przez Ciebie, lub microsoft Entra Domain Services (nadal w testach). Jednak te składniki SAP nie mogą działać z natywnym identyfikatorem Microsoft Entra ID. Przyczyną jest to, że nadal istnieją większe luki w funkcjonalności między usługą Active Directory w formularzu lokalnym lub w formularzu SaaS (Microsoft Entra Domain Services) i natywnym identyfikatorem Microsoft Entra. Ta zależność jest powodem, dla którego konta Microsoft Entra nie są obsługiwane w przypadku aplikacji opartych na oprogramowaniu SAP NetWeaver i S/4 HANA w systemie operacyjnym Windows. W takich scenariuszach należy używać tradycyjnych kont usługi Active Directory.

Usługa AD Obsługiwane aplikacje oparte na oprogramowaniu SAP NetWeaver i S/4 HANA w systemie operacyjnym Windows
Lokalna usługa Active Directory systemu Windows Obsługiwane
Usługi domenowe Microsoft Entra Obsługiwane
Identyfikator usługi Microsoft Entra Nieobsługiwane

Powyższe nie ma wpływu na użycie kont Microsoft Entra dla scenariuszy logowania jednokrotnego (SSO) z aplikacjami SAP.

Konfiguracja 2-warstwowa

Konfiguracja sap 2-warstwowa jest uważana za zbudowaną z połączonej warstwy systemu SAP DBMS i warstwy aplikacji działającej na tym samym serwerze lub jednostce maszyny wirtualnej. Druga warstwa jest uważana za warstwę interfejsu użytkownika. W przypadku konfiguracji dwuwarstwowej warstwa aplikacji DBMS i SAP współużytkuje zasoby maszyny wirtualnej platformy Azure. W związku z tym należy skonfigurować różne składniki w taki sposób, aby te składniki nie konkurowały o zasoby. Należy również zachować ostrożność, aby nie zastępować zasobów maszyny wirtualnej. Taka konfiguracja nie zapewnia żadnej wysokiej dostępności poza umowami dotyczącymi poziomu usług platformy Azure dotyczącymi różnych składników platformy Azure.

Graficzna reprezentacja takiej konfiguracji może wyglądać następująco:

Simple 2-Tier configuration

Takie konfiguracje są obsługiwane w systemach Windows, Red Hat, SUSE i Oracle Linux dla systemów DBMS programu SQL Server, Oracle, Db2, maxDB i SAP ASE na potrzeby przypadków produkcyjnych i nieprodukcyjnych. W przypadku oprogramowania SAP HANA jako systemu DBMS oprogramowanie SAP obsługuje taki scenariusz, jak określono w notatce SAP #1953429. Do tej pory żadna z dystrybucji systemu Linux nie dostarczyła wystarczającej dokumentacji wysokiej dostępności do skonfigurowania i obsługi klastra Pacemaker w takiej konfiguracji. W związku z tym taki typ konfiguracji jest obsługiwany na platformie Azure tylko w przypadku przypadków nieprodukcyjnych, które nie wymagają klastra trybu failover o wysokiej dostępności.

W przypadku wszystkich kombinacji systemów operacyjnych/DBMS obsługiwanych na platformie Azure ten typ konfiguracji jest obsługiwany. Jednak należy ustawić konfigurację systemu DBMS i składników SAP w taki sposób, aby składniki DBMS i SAP nie konkurowały o zasoby pamięci i procesora CPU oraz że przekraczają fizyczne dostępne zasoby. Należy to zrobić, ograniczając pamięć, którą może przydzielić system DBMS. Należy również ograniczyć pamięć rozszerzoną SAP dla wystąpień aplikacji. Należy również monitorować ogólne użycie procesora CPU maszyny wirtualnej, aby upewnić się, że składniki nie maksymalizuje zasobów procesora CPU.

Uwaga

W przypadku produkcyjnych systemów SAP zalecamy dodatkowe konfiguracje wysokiej dostępności i ewentualnego odzyskiwania po awarii zgodnie z opisem w dalszej części tego dokumentu

Konfiguracja 3-warstwowa

W takich konfiguracjach należy oddzielić warstwę aplikacji SAP i warstwę DBMS na różne maszyny wirtualne. Zazwyczaj robisz to w przypadku większych systemów i z powodów bardziej elastycznego korzystania z zasobów warstwy aplikacji SAP. W najprostszej konfiguracji nie ma wysokiej dostępności poza umowami dotyczącymi poziomu usług platformy Azure dotyczącymi różnych składników platformy Azure.

Graficzna reprezentacja wygląda następująco:

Diagram that shows a simple 3-Tier configuration.

Ten typ konfiguracji jest obsługiwany w systemach Windows, Red Hat, SUSE i Oracle Linux dla systemów DBMS programu SQL Server, Oracle, Db2, SAP HANA, maxDB i SAP ASE w przypadku produkcji i nieprodukcyjnej. W celu uproszczenia nie rozróżnialiśmy wystąpień okien dialogowych SAP Central Services i SAP w warstwie aplikacji SAP. W tej prostej konfiguracji 3-warstwowej nie będzie ochrony wysokiej dostępności dla usług SAP Central Services.

Uwaga

W przypadku produkcyjnych systemów SAP zalecamy dodatkowe konfiguracje wysokiej dostępności i ewentualnego odzyskiwania po awarii zgodnie z opisem w dalszej części tego dokumentu

Wiele wystąpień systemu DBMS na maszynę wirtualną

W tym typie konfiguracji hostujesz wiele wystąpień programu DBMS na maszynę wirtualną platformy Azure. Motywacją może być posiadanie mniej systemów operacyjnych do utrzymania i przy tym obniżonych kosztów. Inne motywacje to zwiększenie elastyczności i większej wydajności dzięki udostępnianiu zasobów większej maszyny wirtualnej lub dużej jednostki wystąpienia HANA między wieloma wystąpieniami usługi DBMS. Do tej pory te konfiguracje były wyświetlane głównie w systemach nieprodukcyjnych.

Taka konfiguracja może wyglądać następująco:

Multiple DBMS instances in one unit

Ten typ wdrożenia systemu DBMS jest obsługiwany w następujących celach:

Uruchamianie wielu wystąpień bazy danych na jednym hoście wymaga upewnienia się, że różne wystąpienia nie konkurują o zasoby, a tym samym przekraczają limity zasobów fizycznych maszyny wirtualnej. Jest to szczególnie istotne w przypadku pamięci, w której należy ograniczyć pamięć, którą może przydzielić każda osoba z wystąpień współużytkujących maszynę wirtualną. Może to być również prawdziwe w przypadku zasobów procesora CPU, z których mogą korzystać różne wystąpienia bazy danych. Wszystkie wymienione systemy baz danych mają konfiguracje, które umożliwiają ograniczenie alokacji pamięci i zasobów procesora CPU na poziomie wystąpienia. Aby zapewnić obsługę takiej konfiguracji dla maszyn wirtualnych platformy Azure, należy oczekiwać, że dyski lub woluminy używane dla plików dziennika/ponownego rejestrowania baz danych zarządzanych przez różne wystąpienia są oddzielne. Albo innymi słowy, pliki dziennika/ponownego rejestrowania baz danych, które są zarządzane przez inne wystąpienie systemu DBMS, nie powinny współużytkować tych samych dysków ani woluminów.

Uwaga

W przypadku produkcyjnych systemów SAP zalecamy dodatkowe konfiguracje wysokiej dostępności i ewentualnego odzyskiwania po awarii zgodnie z opisem w dalszej części tego dokumentu. Maszyny wirtualne z wieloma wystąpieniami systemu DBMS nie są obsługiwane w przypadku konfiguracji wysokiej dostępności opisanych w dalszej części tego dokumentu.

Wiele wystąpień okna dialogowego SAP na jednej maszynie wirtualnej

W wielu przypadkach wiele wystąpień okna dialogowego zostało wdrożonych na serwerach bez systemu operacyjnego, a nawet na maszynach wirtualnych działających w chmurach prywatnych. Przyczyną takich konfiguracji było dostosowanie niektórych wystąpień okien dialogowych SAP do określonych typów obciążeń, funkcji biznesowych lub obciążeń. Przyczyną braku izolowania tych wystąpień na oddzielnych maszynach wirtualnych było nakład pracy nad konserwacją i operacjami systemu operacyjnego. Lub w wielu przypadkach koszty w przypadku, gdy hoster lub operator maszyny wirtualnej prosi o miesięczną opłatę za maszynę wirtualną obsługiwaną i zarządzaną. Na platformie Azure scenariusz hostowania wielu wystąpień okien dialogowych SAP w ramach jednej maszyny wirtualnej obsługiwanej w celach produkcyjnych i nieprodukcyjnych w systemach operacyjnych Windows, Red Hat, SUSE i Oracle Linux. Parametr jądra SAP PHYS_MEMSIZE, dostępny w jądrach systemu Windows i nowoczesnych systemu Linux, należy ustawić, jeśli na jednej maszynie wirtualnej jest uruchomionych wiele wystąpień serwera aplikacji SAP. Zaleca się również ograniczenie rozszerzenia rozszerzonej pamięci SAP w systemach operacyjnych, takich jak Windows, w którym zaimplementowano automatyczny wzrost rozszerzonej pamięci SAP. Można to zrobić za pomocą parametru em/max_size_MBprofilu SAP .

W konfiguracji 3-warstwowej, w której wiele wystąpień okna dialogowego SAP jest uruchamianych na maszynach wirtualnych platformy Azure, może wyglądać następująco:

Diagram that shows a 3-Tier configuration where multiple SAP dialog instances are run within Azure VMs.

W celu uproszczenia nie rozróżnialiśmy wystąpień okien dialogowych SAP Central Services i SAP w warstwie aplikacji SAP. W tej prostej konfiguracji 3-warstwowej nie będzie ochrony wysokiej dostępności dla usług SAP Central Services. W przypadku systemów produkcyjnych nie zaleca się opuszczania niechronionych usług SAP Central Services. Aby uzyskać szczegółowe informacje na temat tak zwanych konfiguracji z wieloma identyfikatorami SID wokół wystąpień usługi SAP Central Instances i wysokiej dostępności takich konfiguracji z wieloma identyfikatorami SID, zobacz kolejne sekcje tego dokumentu.

Ochrona wysokiej dostępności dla warstwy SAP DBMS

Podczas wdrażania systemów produkcyjnych SAP należy rozważyć typ rezerwy dynamicznej konfiguracji wysokiej dostępności. Szczególnie w przypadku platformy SAP HANA, gdzie dane muszą być ładowane do pamięci, zanim będą mogły uzyskać pełną wydajność i skalowalność, naprawa usługi platformy Azure nie jest idealną miarą wysokiej dostępności.

Ogólnie rzecz biorąc, firma Microsoft obsługuje tylko konfiguracje wysokiej dostępności i pakiety oprogramowania opisane w scenariuszach obciążeń SAP. Tę samą instrukcję można odczytać w notatce SAP #1928533. Firma Microsoft nie zapewni obsługi innych platform oprogramowania innych firm o wysokiej dostępności, które nie są udokumentowane przez firmę Microsoft z obciążeniem SAP. W takich przypadkach dostawca platformy wysokiej dostępności innej firmy jest stroną pomocniczą dla konfiguracji wysokiej dostępności, która musi być zaangażowana przez Ciebie jako klient w proces pomocy technicznej. Wyjątki zostaną wymienione w tym artykule.

Ogólnie rzecz biorąc, firma Microsoft obsługuje ograniczony zestaw konfiguracji wysokiej dostępności na maszynach wirtualnych platformy Azure lub w jednostkach dużych wystąpień platformy HANA.

W przypadku maszyn wirtualnych platformy Azure następujące konfiguracje wysokiej dostępności są obsługiwane na poziomie systemu DBMS:

Ważne

W przypadku żadnego z opisanych powyżej scenariuszy obsługujemy konfiguracje wielu wystąpień systemu DBMS na jednej maszynie wirtualnej. Oznacza to, że w każdym z przypadków można wdrożyć tylko jedno wystąpienie bazy danych na maszynę wirtualną i chronione za pomocą opisanych metod wysokiej dostępności. Ochrona wielu wystąpień systemu DBMS w tym samym klastrze trybu failover systemu Windows lub Pacemaker nie jest obecnie obsługiwana. Ponadto funkcja Oracle Data Guard jest obsługiwana tylko dla pojedynczego wystąpienia na maszynę wirtualną.

Różne systemy baz danych umożliwiają hostowanie wielu baz danych w ramach jednego wystąpienia programu DBMS. Podobnie jak w przypadku platformy SAP HANA, wiele baz danych może być hostowanych w wielu kontenerach bazy danych (MDC). W przypadku, gdy te konfiguracje z wieloma bazami danych działają w ramach jednego zasobu klastra trybu failover, te konfiguracje są obsługiwane. Konfiguracje, które nie są obsługiwane, to przypadki, w których wymagane będzie wiele zasobów klastra. Jeśli chodzi o konfiguracje, w których należy zdefiniować wiele grup dostępności programu SQL Server, w ramach jednego wystąpienia programu SQL Server.

DBMS HA configuration

Składniki, takie jak moduł równoważenia obciążenia platformy Azure, mogą być wymagane lub nie są wymagane w ramach architektury rozwiązania w zależności od systemu DBMS lub systemów operacyjnych.

W szczególności w przypadku bazy danych maxDB konfiguracja magazynu musi być inna. W przypadku bazy danych maxDB pliki danych i dziennika muszą znajdować się w magazynie udostępnionym w celu zapewnienia wysokiej dostępności konfiguracji. Tylko w przypadku maksymalnej bazy danych magazyn udostępniony jest obsługiwany w celu zapewnienia wysokiej dostępności. W przypadku wszystkich innych systemów DBMS oddzielne stosy magazynu na węzeł są jedynymi obsługiwanymi konfiguracjami dysków.

Znane są również inne struktury wysokiej dostępności i są znane z uruchamiania na platformie Microsoft Azure. Firma Microsoft nie przetestowała jednak tych struktur. Jeśli chcesz utworzyć konfigurację wysokiej dostępności za pomocą tych struktur, musisz współpracować z dostawcą tego oprogramowania, aby:

  • Opracowywanie architektury wdrażania
  • Wdrażanie architektury
  • Obsługa architektury

Ważne

Witryna Microsoft Azure Marketplace oferuje różne urządzenia programowe, które udostępniają rozwiązania magazynu natywne dla platformy Azure. Te urządzenia nietrwałe mogą służyć do tworzenia udziałów NFS, a także teoretycznie mogą być używane we wdrożeniach sap HANA skalowanych w poziomie, w których wymagany jest węzeł rezerwowy. Z różnych powodów żadne z tych urządzeń nietrwałych magazynu nie jest obsługiwane w przypadku dowolnego wdrożenia systemu DBMS przez firmę Microsoft i oprogramowanie SAP na platformie Azure. Wdrożenia systemu DBMS w udziałach SMB nie są w ogóle obsługiwane w tym momencie. Wdrożenia systemu DBMS w udziałach NFS są ograniczone do udziałów NFS 4.1 w usłudze Azure NetApp Files.

Wysoka dostępność dla usługi SAP Central

Usługi SAP Central Services to drugi pojedynczy punkt awarii konfiguracji sap. W związku z tym należy również chronić te procesy usług centralnych. Oferta obsługiwana i udokumentowana dla obciążeń SAP jest odczytywana w następujący sposób:

Spośród wymienionych rozwiązań potrzebna jest relacja pomocy technicznej z usługą SIOS, aby obsługiwać Datakeeper produkt i bezpośrednio kontaktować się z usługą SIOS w przypadku napotkania problemów. W zależności od sposobu licencjonowania systemu Windows, Red Hat i/lub SYSTEMU operacyjnego SUSE może być również wymagane posiadanie umowy pomocy technicznej z dostawcą systemu operacyjnego, aby mieć pełną obsługę wymienionych konfiguracji wysokiej dostępności.

Konfigurację można również wyświetlić w następujący sposób:

DBMS and ASCS HA configuration

Po prawej stronie grafiki wyświetlane są usługi SAP Central Services o wysokiej dostępności. Oprócz ochrony usług SAP Central za pomocą struktury klastra trybu failover, które mogą przejść w tryb failover w scenariuszach awarii. Istnieje konieczność zapewnienia wysokiej dostępności udziału NFS lub SMB albo dysku udostępnionego systemu Windows, aby upewnić się, że katalog sapmnt i globalny transport są dostępne niezależnie od istnienia jednej maszyny wirtualnej. Dodatkowe rozwiązania, takie jak serwer klastra trybu failover systemu Windows i program Pacemaker, wymagają modułu równoważenia obciążenia platformy Azure do kierowania lub przekierowywania ruchu do węzła w dobrej kondycji.

Na wyświetlonej liście nie ma wzmianki o systemie operacyjnym Oracle Linux. System Oracle Linux nie obsługuje programu Pacemaker jako struktury klastra. Jeśli chcesz wdrożyć system SAP w systemie Oracle Linux i potrzebujesz platformy wysokiej dostępności dla systemu Oracle Linux, musisz współpracować z dostawcami innych firm. Jednym z dostawców jest usługa SIOS z pakietem Protection Suite dla systemu Linux obsługiwanym przez oprogramowanie SAP na platformie Azure. Aby uzyskać więcej informacji, przeczytaj artykuł SAP note #1662610 — szczegóły pomocy technicznej pakietu SIOS Protection Suite dla systemu Linux , aby uzyskać więcej informacji.

Obsługiwany magazyn ze scenariuszami usług SAP Central Services wymienionymi powyżej

Ponieważ tylko podzbiór typów magazynu platformy Azure udostępnia udziały NFS lub SMB o wysokiej dostępności, które zapewniają jakość użycia w naszych scenariuszach klastra usług SAP Central Services, lista obsługiwanych typów magazynów

  • Serwer klastra trybu failover systemu Windows z serwerem plików skalowalnym w poziomie systemu Windows można wdrożyć na wszystkich natywnych typach magazynu platformy Azure, z wyjątkiem usługi Azure NetApp Files. Zaleca się jednak użycie usługi Premium Storage ze względu na lepsze umowy dotyczące poziomu usług w przepływności i liczby operacji we/wy na sekundę.
  • Serwer klastra trybu failover systemu Windows z funkcją SMB w usłudze Azure NetApp Files jest obsługiwany w usłudze Azure NetApp Files. Udziały SMB hostowane w usługach Plików Azure Premium są również obsługiwane w tym scenariuszu. Usługa Azure Standard Files nie jest obsługiwana
  • Serwer klastra trybu failover systemu Windows z udostępnionym dyskiem systemu Windows opartym na protokole SIOS Datakeeper można wdrożyć na wszystkich natywnych typach magazynu platformy Azure, z wyjątkiem usługi Azure NetApp Files. Zaleca się jednak użycie usługi Premium Storage ze względu na lepsze umowy dotyczące poziomu usług w przepływności i liczby operacji we/wy na sekundę.
  • Obsługiwane są programy SUSE lub Red Hat Pacemaker korzystające z udziałów NFS w usłudze Azure NetApp Files.
  • SusE lub Red Hat Pacemaker przy użyciu udziałów NFS w usłudze Azure Premium Files przy użyciu obsługiwanych magazynów LRS lub ZRS. Usługa Azure Standard Files nie jest obsługiwana
  • Program SUSE Pacemaker korzystający z drdb konfiguracji między dwiema maszynami wirtualnymi jest obsługiwany przy użyciu natywnych typów magazynu platformy Azure, z wyjątkiem usługi Azure NetApp Files. Zalecamy jednak używanie jednej z usług innych firm z usługami Azure Premium Files lub Azure NetApp Files.
  • Narzędzie Red Hat Pacemaker używane glusterfs do udostępniania udziału NFS jest obsługiwane przy użyciu natywnych typów magazynu platformy Azure, z wyjątkiem usługi Azure NetApp Files. Zalecamy jednak używanie jednej z usług innych firm z usługami Azure Premium Files lub Azure NetApp Files.

Ważne

Witryna Microsoft Azure Marketplace oferuje różne urządzenia programowe, które udostępniają rozwiązania magazynu natywne dla platformy Azure. Te urządzenia programowe magazynu mogą służyć do tworzenia udziałów NFS lub SMB, a także teoretycznie mogą być używane w klastrze klastra trybu failover SAP Central Services. Te rozwiązania nie są bezpośrednio obsługiwane w przypadku obciążenia SAP przez firmę Microsoft. Jeśli zdecydujesz się użyć takiego rozwiązania do utworzenia udziału NFS lub SMB, należy zapewnić obsługę konfiguracji usługi SAP Central Service przez inną firmę będącą właścicielem oprogramowania w urządzeniu nietrwałym magazynu.

Klastry trybu failover usług SAP Central Services z wieloma identyfikatorami SID

Aby zmniejszyć liczbę maszyn wirtualnych potrzebnych w dużych środowiskach SAP, system SAP umożliwia uruchamianie wystąpień usług sap Central Services wielu różnych systemów SAP w konfiguracji klastra trybu failover. Wyobraź sobie przypadki, w których masz co najmniej 30 systemów produkcyjnych NetWeaver lub S/4HANA. Bez klastrowania z wieloma identyfikatorami SID te konfiguracje wymagają co najmniej 60 maszyn wirtualnych w 30 lub więcej konfiguracjach klastra trybu failover systemu Windows lub Pacemaker. Wdrażanie wielu usług centralnych SAP w dwóch węzłach w konfiguracji klastra trybu failover może znacznie zmniejszyć liczbę maszyn wirtualnych. Jednak wdrożenie wielu wystąpień usług SAP Central w jednej konfiguracji klastra z dwoma węzłami ma również pewne wady. Problemy dotyczące pojedynczej maszyny wirtualnej w konfiguracji klastra dotyczą wielu systemów SAP. Konserwacja systemu operacyjnego gościa uruchomionego w konfiguracji klastra wymaga większej koordynacji, ponieważ ma to wpływ na wiele produkcyjnych systemów SAP. Narzędzia takie jak SAP LaMa nie obsługują klastrowania z wieloma identyfikatorami SID w procesie klonowania systemu.

Na platformie Azure konfiguracja klastra z wieloma identyfikatorami SID jest obsługiwana dla systemu operacyjnego Windows z enSA1 i ENSA2. Zaleceniem nie jest połączenie starszej architektury usługi replikacji kolejki (ENSA1) z nową architekturą (ENSA2) w jednym klastrze z wieloma identyfikatorami SID. Szczegółowe informacje o takiej architekturze opisano w artykułach

W przypadku systemu SUSE obsługiwany jest również klaster z wieloma identyfikatorami SID oparty na usłudze Pacemaker. Do tej pory konfiguracja jest obsługiwana w następujących celach:

  • Maksymalnie pięć wystąpień SAP ASCS/SCS
  • Stara architektura lodu serwera replikacji w kolejce (ENSA1)
  • Konfiguracje klastra Pacemaker z dwoma węzłami

Konfiguracja jest udokumentowana w artykule Wysoka dostępność oprogramowania SAP NetWeaver na maszynach wirtualnych platformy Azure na serwerze SUSE Linux Enterprise Server dla aplikacji SAP — przewodnik dotyczący wielu identyfikatorów SID

Klaster z wieloma identyfikatorami SID z serwerem replikacji w kolejce wygląda schematowo

Diagram that shows a multi-SID cluster with Enqueue Replication server.

Scenariusze skalowania w poziomie oprogramowania SAP HANA

Scenariusze skalowania w poziomie platformy SAP HANA są obsługiwane w przypadku podzestawu certyfikowanych maszyn wirtualnych platformy Azure HANA wymienionych w katalogu sprzętowym SAP HANA. Wszystkie maszyny wirtualne oznaczone wartością "Tak" w kolumnie "Clustering" mogą służyć do skalowania OLAP lub S/4HANA w poziomie. Konfiguracje bez wstrzymania są obsługiwane w przypadku typów usługi Azure Storage:

Konfiguracje skalowane w poziomie oprogramowania SAP HANA dla OLAP lub S/4HANA z węzłami rezerwowymi są obsługiwane wyłącznie w systemie plików NFS hostowanych w usłudze Azure NetApp Files.

Aby uzyskać więcej informacji na temat dokładnych konfiguracji magazynu z węzłem rezerwowym lub bez tego węzła, zapoznaj się z artykułami:

Scenariusz odzyskiwania po awarii

Istnieje wiele obsługiwanych scenariuszy odzyskiwania po awarii. Definiujemy architektury po awarii jako architektury, które powinny zrekompensować pełny region świadczenia usługi Azure przechodzący poza siatkę. Oznacza to, że potrzebujemy docelowego odzyskiwania po awarii, aby był innym regionem świadczenia usługi Azure jako elementem docelowym uruchamiania środowiska SAP. Oddzielamy metody i konfiguracje w warstwie DBMS i w warstwie innej niż DBMS.

Warstwa systemu DBMS

W przypadku warstwy DBMS konfiguracje korzystające z natywnych mechanizmów replikacji systemu DBMS, takich jak Always On, Oracle Data Guard, Db2 HADR, SAP ASE Always-On lub Replikacja systemu HANA są obsługiwane. Jest to obowiązkowe, aby strumień replikacji w takich przypadkach był asynchroniczny, a nie synchroniczny, jak w typowych scenariuszach wysokiej dostępności wdrożonych w jednym regionie świadczenia usługi Azure. Typowy przykład takiej obsługiwanej konfiguracji odzyskiwania po awarii systemu DBMS został opisany w artykule Dostępność oprogramowania SAP HANA w różnych regionach świadczenia usługi Azure. Druga grafika w tej sekcji opisuje scenariusz z platformą HANA jako przykład. Główne bazy danych obsługiwane dla aplikacji SAP mogą być wdrażane w takim scenariuszu.

Ta maszyna wirtualna jest obsługiwana w celu użycia mniejszej maszyny wirtualnej jako wystąpienia docelowego w regionie odzyskiwania po awarii, ponieważ ta maszyna wirtualna nie ma pełnego ruchu obciążenia. W tym celu należy pamiętać o następujących kwestiach:

  • Mniejsze typy maszyn wirtualnych nie zezwalają na dołączanie wielu dysków niż mniejsze maszyny wirtualne
  • Mniejsze maszyny wirtualne mają mniejszą przepływność sieci i magazynu
  • Zmiana rozmiaru między rodzinami maszyn wirtualnych może być problemem, gdy różne maszyny wirtualne są zbierane w jednym zestawie dostępności platformy Azure lub gdy zmiana rozmiaru powinna wystąpić między rodziną serii M a rodziną mv2 maszyn wirtualnych
  • Użycie procesora CPU i pamięci dla wystąpienia bazy danych jest w stanie odbierać strumień zmian z minimalnym opóźnieniem i wystarczającą ilością zasobów procesora CPU i pamięci, aby zastosować te zmiany z minimalnym opóźnieniem do danych

Więcej szczegółów na temat ograniczeń różnych rozmiarów maszyn wirtualnych można znaleźć na stronie Rozmiary maszyn wirtualnych

Inną obsługiwaną metodą wdrażania docelowego odzyskiwania po awarii jest zainstalowanie drugiego wystąpienia systemu DBMS na maszynie wirtualnej z uruchomionym nieprodukcyjnym wystąpieniem systemu DBMS wystąpienia oprogramowania SAP nieprodukcyjnego. Może to być nieco trudniejsze, ponieważ należy ustalić, co w przypadku pamięci, zasobów procesora CPU, przepustowości sieci i przepustowości magazynu jest potrzebne dla określonych wystąpień docelowych, które powinny działać jako główne wystąpienie w scenariuszu odzyskiwania po awarii. Szczególnie w przypadku platformy HANA zdecydowanie zaleca się skonfigurowanie wystąpienia, które działa jako obiekt docelowy odzyskiwania po awarii na udostępnionym hoście, aby dane nie zostały wstępnie załadowane do wystąpienia docelowego odzyskiwania po awarii.

Uwaga

Użycie usługi Azure Site Recovery nie zostało przetestowane pod kątem wdrożeń systemu DBMS w ramach obciążenia SAP. W związku z tym nie jest ona obsługiwana w przypadku warstwy SYSTEMU DBMS systemów SAP w tym momencie. Inne metody replikacji firmy Microsoft i sap, które nie są wymienione na liście, nie są obsługiwane. Używanie oprogramowania innej firmy do replikowania warstwy systemów SAP DBMS między różnymi regionami świadczenia usługi Azure musi być obsługiwane przez dostawcę oprogramowania i nie będzie obsługiwane za pośrednictwem kanałów pomocy technicznej firmy Microsoft i SAP.

Warstwa niezwiązana z systemem DBMS

W przypadku warstwy aplikacji SAP i wymaganych udziałów lub lokalizacji magazynu dwa główne scenariusze są używane przez klientów:

  • Cele odzyskiwania po awarii w drugim regionie świadczenia usługi Azure nie są używane do celów produkcyjnych ani nieprodukcyjnych. W tym scenariuszu maszyny wirtualne, które działają jako cel odzyskiwania po awarii, nie są wdrażane, a obraz i zmiany obrazów produkcyjnej warstwy aplikacji SAP są replikowane do regionu odzyskiwania po awarii. Funkcja, która może wykonać takie zadanie, to Azure Site Recovery. Usługa Azure Site Recovery obsługuje scenariusz replikacji z platformy Azure do platformy Azure w następujący sposób.
  • Cele odzyskiwania po awarii to maszyny wirtualne, które są rzeczywiście używane przez systemy nieprodukcyjne. Cały krajobraz SAP jest rozmieszczony w dwóch różnych regionach świadczenia usługi Azure z systemami produkcyjnymi zwykle w jednym regionie i systemach nieprodukcyjnych w innym regionie. W wielu wdrożeniach klientów klient ma system nieprodukcyjny, który jest odpowiednikiem systemu produkcyjnego. Klient ma wstępnie zainstalowane wystąpienia aplikacji produkcyjnych w warstwie aplikacji nieprodukcyjnej. W przypadku przejścia w tryb failover wystąpienia nieprodukcyjne zostaną zamknięte, nazwy wirtualne produkcyjnych maszyn wirtualnych przeniesione do nieprodukcyjnych maszyn wirtualnych (po przypisaniu nowych adresów IP w systemie DNS) i wstępnie zainstalowane wystąpienia produkcyjne są coraz rozpoczynane

Klastry usług SAP Central Services

Klastry usług sap Central Services korzystające z dysków udostępnionych (Windows), udziałów SMB (Windows) lub udziałów NFS są nieco trudniejsze do replikacji. Po stronie systemu Windows możliwe jest rozwiązanie replikacji magazynu systemu Windows. W systemie Linux rsync jest realnym rozwiązaniem. Ponadto replikacja między regionami usługi Azure NetApp Files jest realnym rozwiązaniem.

Scenariusz nieobsługiwany

Istnieje lista scenariuszy, które nie są obsługiwane w przypadku obciążeń SAP w architekturach platformy Azure. Nieobsługiwane oznacza, że systemy SAP i Microsoft nie mogą zapewnić obsługi tych konfiguracji i muszą odroczyć ewentualne zaangażowane oprogramowanie innych firm w celu ustanowienia takich architektur. Dwie kategorie to:

  • Urządzenia nietrwałe do magazynowania: na rynku istnieją różne urządzenia nietrwałe magazynujące. Niektórzy dostawcy oferują własną dokumentację dotyczącą korzystania z urządzeń nietrwałych magazynu na platformie Azure związanych z oprogramowaniem SAP. Obsługa konfiguracji lub wdrożeń obejmujących takie urządzenia nietrwałe magazynu musi być zapewniona przez dostawcę urządzenia nietrwałego magazynu. Ten fakt jest również manifestowany w notatce pomocy technicznej sap #2015553
  • Platformy wysokiej dostępności: obsługiwane są tylko platformy Pacemaker i Klaster trybu failover systemu Windows Server dla obciążeń SAP na platformie Azure. Jak wspomniano wcześniej, rozwiązanie SIOS Datakeeper zostało opisane i udokumentowane przez firmę Microsoft. Niemniej jednak składniki SIOS muszą być obsługiwane za pośrednictwem usług SIOS Datakeeper , ponieważ dostawca dostarcza te składniki. Firma SAP wymieniła również inne certyfikowane platformy wysokiej dostępności w różnych notatkach SAP. Niektóre z nich zostały certyfikowane przez innego dostawcę dla platformy Azure. Niemniej jednak obsługa konfiguracji korzystających z tych produktów musi być zapewniona przez dostawcę produktu. Różni dostawcy mają inną integrację z procesami pomocy technicznej sap. Przed podjęciem decyzji o użyciu produktu z konfiguracjami SAP wdrożonych na platformie Azure należy wyjaśnić, jaki proces pomocy technicznej najlepiej sprawdza się u konkretnego dostawcy.
  • Klastry dysków udostępnionych, w których pliki bazy danych znajdują się na dyskach udostępnionych, nie są obsługiwane, z wyjątkiem maxDB. W przypadku wszystkich innych baz danych obsługiwane rozwiązanie polega na oddzielnych lokalizacjach magazynu zamiast udziałów SMB lub NFS lub dysku udostępnionego w celu skonfigurowania scenariuszy wysokiej dostępności

Inne scenariusze, które nie są obsługiwane, to scenariusze takie jak:

  • Scenariusze wdrażania, które wprowadzają większe opóźnienie sieci między warstwą aplikacji SAP i warstwą SAP DBMS, jak w programie NetWeaver, S/4HANA i np. . Hybris Obejmuje to:
    • Wdrażanie jednej z warstw lokalnych, natomiast druga warstwa jest wdrażana na platformie Azure
    • Wdrażanie warstwy aplikacji SAP systemu w innym regionie świadczenia usługi Azure niż warstwa DBMS
    • Wdrażanie jednej warstwy w centrach danych, które są współlokowane na platformie Azure i w drugiej warstwie platformy Azure, z wyjątkiem sytuacji, w których taki wzorzec architektury jest udostępniany przez natywną usługę platformy Azure
    • Wdrażanie wirtualnych urządzeń sieciowych między warstwą aplikacji SAP i warstwą systemu DBMS
    • Korzystanie z magazynu hostowanego we współlokowanych centrach danych w centrum danych platformy Azure dla warstwy SAP DBMS lub globalnego katalogu transportu SAP
    • Wdrażanie dwóch warstw z dwoma różnymi dostawcami usług w chmurze. Na przykład wdrażanie warstwy DBMS w infrastrukturze Oracle Cloud Infrastructure i warstwie aplikacji na platformie Azure
  • Konfiguracje klastra HANA Pacemaker z wieloma wystąpieniami
  • Konfiguracje klastra systemu Windows z dyskami udostępnionymi za pośrednictwem serwera SOFS lub protokołu SMB w usłudze ANF dla baz danych SAP obsługiwanych w systemie Windows. Zamiast tego zalecamy użycie natywnej replikacji wysokiej dostępności określonych baz danych i używania oddzielnych stosów magazynu
  • Wdrażanie baz danych SAP obsługiwanych w systemie Linux z plikami bazy danych znajdującymi się w udziałach NFS oprócz oprogramowania SAP HANA, Oracle w systemie Oracle Linux i Db2 w systemach Suse i Red Hat
  • Wdrażanie systemu operacyjnego Oracle DBMS w dowolnym innym systemie operacyjnym gościa niż Windows i Oracle Linux. Zobacz również notatkę dotyczącą pomocy technicznej sap #2039619

Scenariusze, które nie zostały przetestowane i w związku z tym nie mają doświadczenia z listą, na przykład:

  • Replikowanie maszyn wirtualnych warstwy DBMS w usłudze Azure Site Recovery. W związku z tym zalecamy użycie natywnej funkcji replikacji asynchronicznej bazy danych w celu uzyskania potencjalnej konfiguracji odzyskiwania po awarii

Następne kroki

Zapoznaj się z kolejnymi krokami w temacie Planowanie i implementacja usługi Azure Virtual Machines dla oprogramowania SAP NetWeaver