Megosztás a következőn keresztül:

SAP-tevékenységprofil az Azure-beli virtuális gépek támogatott forgatókönyveiben

  • Cikk

Az SAP NetWeaver, business one Hybris vagy S/4HANA rendszerarchitektúra tervezése az Azure-ban számos különböző lehetőséget kínál a különböző architektúrák és eszközök számára a méretezhető, hatékony és magas rendelkezésre állású üzembe helyezéshez. Bár a használt operációs rendszertől vagy DBMS-től függ, vannak korlátozások. Emellett nem minden, a helyszínen támogatott forgatókönyv is ugyanúgy támogatott az Azure-ban. Ez a dokumentum végigvezeti a támogatott nem magas rendelkezésre állású konfigurációkon, valamint a magas rendelkezésre állású konfigurációkon és architektúrákon kizárólag Azure-beli virtuális gépek használatával.

Feljegyzés

A HANA Large Instance szolgáltatás naplemente módban van, és már nem fogad új ügyfeleket. A meglévő NAGY MÉRETŰ HANA-ügyfelek számára továbbra is lehetséges egységek biztosítása. Alternatív megoldásokért tekintse meg a HANA-tanúsítvánnyal rendelkező Azure-beli virtuális gépek ajánlatait a HANA hardverkönyvtárában. Az olyan forgatókönyvek esetében, amelyek a NAGY HANA-példányokkal rendelkező meglévő HANA nagypéldány-ügyfelek esetében támogatottak, tekintse meg a hana-nagy példányok támogatott forgatókönyveit ismertető cikket.

Általános platformkorlátozások

Az Azure számos platformot kínál az úgynevezett natív Azure-beli virtuális gépeken kívül, amelyeket első féltől származó szolgáltatásként kínálnak. A NAGY HANA-példányok, amelyek naplemente módban vannak, ezen platformok egyike. Az Azure VMware Services ezen első féltől származó szolgáltatások egyike. Az SAP általában nem támogatja az Azure VMware-szolgáltatásokat az SAP számítási feladatainak üzemeltetéséhez. Tekintse meg az SAP támogatási megjegyzését #2138865 – SAP-alkalmazások a VMware Cloudon: Támogatott termékek és virtuálisgép-konfigurációk a VMware különböző platformokon történő támogatásának további részleteiért.

A helyi Active Directory mellett az Azure egy felügyelt Active Directory SaaS szolgáltatást is kínál a Microsoft Entra Domain Services (a Microsoft által felügyelt hagyományos AD) és a Microsoft Entra ID használatával. A Windows operációs rendszeren üzemeltetett SAP-összetevők gyakran a Windows Active Directory használatára támaszkodnak. Ebben az esetben a hagyományos Active Directoryt, amelyet Ön üzemeltet a helyszínen, vagy a Microsoft Entra Domain Servicest (még tesztelés alatt). Ezek az SAP-összetevők azonban nem működnek a natív Microsoft Entra-azonosítóval. Ennek az az oka, hogy az Active Directory még mindig nagyobb funkcionalitásbeli hiányosságokat mutat a helyszíni formájában vagy SaaS-űrlapja (Microsoft Entra Domain Services) és a natív Microsoft Entra-azonosító között. Ez a függőség az oka annak, hogy a Microsoft Entra-fiókok nem támogatottak az SAP NetWeaver és az S/4 HANA-n alapuló alkalmazások esetében Windows operációs rendszeren. Ilyen esetekben hagyományos Active Directory-fiókokat kell használni.

AD-szolgáltatás Az SAP NetWeaver és az S/4 HANA-n alapuló támogatott alkalmazások Windows operációs rendszeren
Helyszíni Windows Active Directory Támogatott
Microsoft Entra tartományi szolgáltatások Támogatott
Microsoft Entra ID Nem támogatott

A fentiek nem befolyásolják a Microsoft Entra-fiókok használatát az SAP-alkalmazásokkal rendelkező egyszeri bejelentkezéses (SSO-) forgatókönyvekhez.

Kétrétegű konfiguráció

Az SAP 2 szintű konfiguráció az SAP DBMS és az ugyanazon a kiszolgálón vagy virtuálisgép-egységen futó alkalmazásréteg egy kombinált rétegéből épül fel. A második réteg a felhasználói felület rétege. Kétszintű konfiguráció esetén a DBMS és az SAP alkalmazásrétege megosztja az Azure-beli virtuális gép erőforrásait. Ennek eredményeképpen úgy kell konfigurálnia a különböző összetevőket, hogy ezek az összetevők ne versenyezzenek az erőforrásokért. Arra is ügyelnie kell, hogy ne írja felül a virtuális gép erőforrásait. Az ilyen konfiguráció nem biztosít magas rendelkezésre állást a különböző Azure-összetevők Azure-beli szolgáltatásiszint-szerződésén túl.

Egy ilyen konfiguráció grafikus ábrázolása a következőképpen nézhet ki:

Egyszerű kétrétegű konfiguráció

Az ilyen konfigurációkat a Windows, a Red Hat, a SUSE és az Oracle Linux támogatja az SQL Server, az Oracle, a Db2, a maxDB és az SAP ASE DBMS-rendszereihez éles és nem éles esetekben. Az SAP HANA mint DBMS esetében az SAP támogatja az SAP megjegyzés # 1953429. Eddig egyik Linux-disztribúció sem biztosított elegendő HA-dokumentációt a Pacemaker-fürt ilyen konfigurációban való beállításához és működtetéséhez. Ennek eredményeképpen az ilyen típusú konfigurációk csak olyan nem éles esetekben támogatottak az Azure-ban, amelyekhez nincs szükség magas rendelkezésre állású feladatátvevő fürtre.

Az Azure-ban támogatott összes operációsrendszer-/DBMS-kombináció esetében ez a konfigurációtípus támogatott. Kötelező azonban úgy beállítani a DBMS és az SAP-összetevők konfigurációját, hogy a DBMS és az SAP-összetevők ne versenyezzenek a memória- és CPU-erőforrásokért, és ez meghaladja a fizikai rendelkezésre álló erőforrásokat. Ezt úgy kell elvégezni, hogy korlátozza a DBMS által lefoglalható memóriát. Az sap extended memory-t az alkalmazáspéldányokon is korlátoznia kell. Emellett figyelnie kell a virtuális gép processzorhasználatát is, hogy az összetevők ne maximalizálják a processzorerőforrásokat.

Feljegyzés

Éles SAP-rendszerek esetén javasoljuk, hogy további magas rendelkezésre állású és esetleges vészhelyreállítási konfigurációkat használjanak a jelen dokumentum későbbi részében leírtak szerint.

3 rétegű konfiguráció

Ilyen konfigurációkban az SAP-alkalmazásréteget és a DBMS-réteget különböző virtuális gépekre kell elválasztani. Ezt általában nagyobb rendszerek esetében, illetve az SAP-alkalmazásréteg erőforrásainak rugalmasabbsága miatt teheti meg. A legegyszerűbb beállításban nincs magas rendelkezésre állás a különböző Azure-összetevők Azure-beli szolgáltatásiszint-szerződésén túl.

A grafikus ábrázolás a következőképpen néz ki:

Egy egyszerű, háromrétegű konfigurációt bemutató diagram.

Ez a konfiguráció windowsos, Red Hat, SUSE és Oracle Linux rendszeren támogatott az SQL Server, Oracle, Db2, SAP HANA, maxDB és SAP ASE DBMS-rendszereihez éles és nem éles esetekben. Az egyszerűsítés érdekében nem különböztettük meg az SAP Central Servicest és az SAP-párbeszédpanel-példányokat az SAP-alkalmazásrétegben. Ebben az egyszerű, háromrétegű konfigurációban nem lenne magas rendelkezésre állású védelem az SAP Central Services számára.

Feljegyzés

Éles SAP-rendszerek esetén javasoljuk, hogy további magas rendelkezésre állású és esetleges vészhelyreállítási konfigurációkat használjanak a jelen dokumentum későbbi részében leírtak szerint.

Több DBMS-példány virtuális gépenként

Ebben a konfigurációs típusban azure-beli virtuális gépenként több DBMS-példányt is üzemeltethet. Ennek a motivációnak az lehet az oka, hogy kevesebb operációs rendszerrel kell karbantartani és csökkenteni a költségeket. További motiváció, hogy nagyobb rugalmassággal és hatékonysággal rendelkezzen egy nagyobb virtuális gép vagy HANA nagypéldány-egység erőforrásainak több DBMS-példány között való megosztásával. Ezek a konfigurációk eddig többnyire nem éles rendszerek esetében voltak láthatók.

Az ehhez hasonló konfigurációk a következőképpen nézhetnek ki:

Több DBMS-példány egy egységben

A DBMS ilyen típusú üzembe helyezése a következő célokra támogatott:

  • SQL Server on Windows
  • IBM Db2. Részletek a több példány (Linux, UNIX) című cikkben
  • Oracle esetén. További részletekért lásd az SAP támogatási megjegyzését #1778431 és a kapcsolódó SAP-megjegyzéseket
  • Az SAP HANA esetében egy virtuális gépen több példány is támogatott, az SAP ezt az MCOS üzembehelyezési módszert hívja meg. További részletekért lásd az SAP-cikket több SAP HANA-rendszer egy gazdagépen (MCOS)

Ha több adatbázispéldányt futtat egy gazdagépen, győződjön meg arról, hogy a különböző példányok nem versengenek az erőforrásokért, és így túllépik a virtuális gép fizikai erőforráskorlátjait. Ez különösen igaz azokra a memóriára, ahol a virtuális gépet megosztó példányok közül bárki lefoglalhatja a memóriát. Ez a különböző adatbázispéldányok által felhasználható CPU-erőforrásokra is igaz lehet. Az összes említett adatbázisrendszer rendelkezik olyan konfigurációkkal, amelyek lehetővé teszik a memóriafoglalás és a CPU-erőforrások egy példányszintű korlátozását. Ahhoz, hogy az Azure-beli virtuális gépek ilyen konfigurációja támogatott legyen, a különböző példányok által felügyelt adatbázisok adataihoz és naplófájljaihoz használt lemezek vagy kötetek külön-külön lesznek. Más szóval a különböző DBMS-példányok által felügyelt adatbázisok adatainak vagy naplóinak/újrado-fájljainak nem kellene ugyanazokat a lemezeket vagy köteteket megosztaniuk.

Feljegyzés

Éles SAP-rendszerek esetén további magas rendelkezésre állású és esetleges vészhelyreállítási konfigurációkat javasoljuk a jelen dokumentum későbbi részében leírtak szerint. A több DBMS-példányt tartalmazó virtuális gépek nem támogatottak a dokumentum későbbi részében ismertetett magas rendelkezésre állási konfigurációkkal.

Több SAP dialog instances in one VM

Sok esetben több párbeszédpanel-példány is üzembe lett helyezve operációs rendszer nélküli kiszolgálókon vagy akár magánfelhőkben futó virtuális gépeken. Az ilyen konfigurációk oka az volt, hogy bizonyos SAP-párbeszédpanel-példányokat bizonyos számítási feladatokhoz, üzleti funkciókhoz vagy számítási feladatokhoz kellett igazítani. A példányok külön virtuális gépekre való elkülönítésének oka az operációs rendszer karbantartása és üzemeltetése volt. Vagy számos esetben a költségek arra az esetre, ha a virtuális gép üzemeltetője vagy üzemeltetője havi díjat kér a üzemeltetett és felügyelt virtuális gépenként. Az Azure-ban a Windows, Red Hat, SUSE és Oracle Linux operációs rendszereken éles és nem éles környezetben támogatott egyetlen virtuális gépen több SAP-párbeszédpanelpéldány üzemeltetésének forgatókönyve. Ha több SAP Application Server-példány fut egyetlen virtuális gépen, a windowsos és a modern Linux-kerneleken elérhető PHYS_MEMSIZE SAP kernelparamétert kell beállítani. azt is javasoljuk, hogy korlátozza az SAP kiterjesztett memória kiterjesztését az operációs rendszereken, például a Windowsban, ahol az SAP kiterjesztett memória automatikus növekedése implementálva van. Ez az SAP-profil paraméterrel em/max_size_MBvégezhető el.

Háromszintű konfiguráció esetén, ahol több SAP-párbeszédpanelpéldány fut az Azure-beli virtuális gépeken, a következőképpen nézhet ki:

Egy háromrétegű konfigurációt bemutató ábra, amelyen több SAP-párbeszédpanel-példány fut az Azure-beli virtuális gépeken.

Az egyszerűsítés érdekében nem különböztettük meg az SAP Central Servicest és az SAP-párbeszédpanel-példányokat az SAP-alkalmazásrétegben. Ebben az egyszerű, háromrétegű konfigurációban nem lenne magas rendelkezésre állású védelem az SAP Central Services számára. Éles rendszerek esetén nem ajánlott az SAP Central Services védelmét érintetlenül hagyni. Az SAP Central-példányok körüli úgynevezett több SID-konfigurációkra és az ilyen több SID-konfigurációk magas rendelkezésre állására vonatkozó részletekért tekintse meg a dokumentum későbbi szakaszait.

Magas rendelkezésre állású védelem az SAP DBMS-réteghez

Az SAP éles rendszerek üzembe helyezéséhez figyelembe kell vennie a magas rendelkezésre állású konfigurációk gyakori készenléti típusát. Különösen az SAP HANA esetében, ahol az adatokat be kell tölteni a memóriába a teljes teljesítmény és a méretezhetőség visszaállítása előtt, az Azure szolgáltatásjavítás nem ideális mérték a magas rendelkezésre álláshoz.

A Microsoft általában csak az SAP számítási feladatok forgatókönyveiben leírt magas rendelkezésre állású konfigurációkat és szoftvercsomagokat támogatja. Ugyanezt az utasítást az SAP-megjegyzés #1928533 is elolvashatja. A Microsoft nem nyújt támogatást más, magas rendelkezésre állású, harmadik féltől származó szoftverkeretekhez, amelyeket a Microsoft nem dokumentál sap számítási feladattal. Ilyen esetekben a magas rendelkezésre állású keretrendszer harmadik fél szállítója a magas rendelkezésre állású konfiguráció támogatója, akinek ügyfélként be kell vonnia a támogatási folyamatba. Ebben a cikkben kivételeket fogunk megemlíteni.

A Microsoft általában korlátozott számú magas rendelkezésre állású konfigurációt támogat az Azure-beli virtuális gépeken vagy a NAGY HANA-példányokban.

Azure-beli virtuális gépek esetén a következő magas rendelkezésre állású konfigurációk támogatottak DBMS-szinten:

Fontos

A fent ismertetett forgatókönyvek egyike sem támogatja több DBMS-példány konfigurációját egy virtuális gépen. Azt jelenti, hogy az egyes esetekben virtuális gépenként csak egy adatbázispéldány helyezhető üzembe, és a leírt magas rendelkezésre állási módszerekkel védhető. Több DBMS-példány védelme ugyanabban a Windows- vagy Pacemaker-feladatátvevő fürtben jelenleg NEM támogatott. Az Oracle Data Guard emellett csak a virtuális gépek üzembe helyezési eseteinek egyetlen példánya esetén is támogatott.

A különböző adatbázisrendszerek lehetővé teszik több adatbázis üzemeltetését egy DBMS-példányban. Az SAP HANA-hez hasonlóan több adatbázis is üzemeltethető több adatbázistárolóban (MDC). Azokban az esetekben, amikor ezek a többadatbázis-konfigurációk egy feladatátvevő fürterőforráson belül működnek, ezek a konfigurációk támogatottak. A nem támogatott konfigurációk olyan esetek, amikor több fürterőforrásra lenne szükség. Olyan konfigurációk esetében, ahol több SQL Server-rendelkezésre állási csoportot határozna meg egy SQL Server-példányban.

DBMS HA-konfiguráció

A DBMS an/vagy operációs rendszerektől függően előfordulhat, hogy a megoldásarchitektúra részeként olyan összetevőkre van szükség, mint az Azure Load Balancer.

Kifejezetten a maxDB esetében a tárolókonfigurációnak eltérőnek kell lennie. A maxDB-vel az adatoknak és a naplófájloknak megosztott tárolóban kell lenniük a magas rendelkezésre állású konfigurációk érdekében. A megosztott tárterület csak maxDB esetén támogatott a magas rendelkezésre álláshoz. Az összes többi DBMS esetében a csomópontonkénti különálló tárolóveremek az egyetlen támogatott lemezkonfigurációk.

Ismert, hogy léteznek más magas rendelkezésre állású keretrendszerek is, amelyek a Microsoft Azure-on is futtathatók. A Microsoft azonban nem tesztelte ezeket a keretrendszereket. Ha magas rendelkezésre állású konfigurációt szeretne létrehozni ezekkel a keretrendszerekkel, a szoftver szolgáltatójával együtt kell dolgoznia a következők érdekében:

  • Üzembehelyezési architektúra fejlesztése
  • Az architektúra üzembe helyezése
  • Az architektúra támogatása

Fontos

A Microsoft Azure Marketplace számos olyan puha berendezést kínál, amelyek tárolási megoldásokat biztosítanak az Azure natív tárolóján felül. Ezek a puha berendezések NFS-megosztások létrehozására is használhatók, amelyek elméletileg felhasználhatók az SAP HANA vertikális felskálázású üzemelő példányaiban, ahol készenléti csomópontra van szükség. A Microsoft és az SAP által az Azure-ban telepített DBMS-környezetek esetében a különböző okok miatt ezek közül a helyreállítható tárolóberendezések egyike sem támogatott. A DBMS SMB-megosztásokon való üzembe helyezése jelenleg egyáltalán nem támogatott. A DBMS NFS-megosztásokon való üzembe helyezése csak NFS 4.1-megosztásokra korlátozódik az Azure NetApp Filesban.

Magas rendelkezésre állás az SAP Central szolgáltatáshoz

Az SAP Central Services az SAP-konfiguráció második meghibásodási pontja. Ennek eredményeképpen ezeket a Central Services-folyamatokat is védenie kell. Az SAP számítási feladataihoz támogatott és dokumentált ajánlat a következőhöz hasonló:

A felsorolt megoldások közül támogatási kapcsolatra van szüksége az SIOS-vel a termék támogatásához és az Datakeeper SIOS-hez való közvetlen kapcsolódáshoz, ha problémák merülnek fel. A Windows, a Red Hat és/vagy a SUSE OPERÁCIÓS RENDSZER licencelésének módjától függően az operációs rendszer szolgáltatójával támogatási szerződéssel is rendelkeznie kell a felsorolt magas rendelkezésre állású konfigurációk teljes körű támogatásához.

A konfiguráció a következőképpen is megjeleníthető:

DBMS és ASCS HA-konfiguráció

A grafika jobb oldalán megjelenik a magas rendelkezésre állású SAP Central Services. Azonkívül, hogy az SAP Central-szolgáltatásokat egy feladatátvevő fürt keretrendszere védi, amely feladatátvételt végezhet a hibahelyzetekben. Szükség van egy magas rendelkezésre állású NFS- vagy SMB-megosztásra, illetve windowsos megosztott lemezre, hogy az sapmnt és a globális átviteli könyvtár elérhető legyen, függetlenül attól, hogy létezik-e egyetlen virtuális gép. További megoldások, például a Windows feladatátvevő fürtkiszolgálója és a Pacemaker megkövetelik, hogy egy Azure-terheléselosztó irányítsa vagy irányítsa a forgalmat egy kifogástalan állapotú csomópontra.

A megjelenő listában nem szerepel az Oracle Linux operációs rendszer. Az Oracle Linux nem támogatja a Pacemakert fürt-keretrendszerként. Ha az SAP-rendszert Oracle Linuxon szeretné üzembe helyezni, és magas rendelkezésre állású keretrendszerre van szüksége az Oracle Linuxhoz, külső szállítókkal kell együttműködnie. Az egyik szállító az SIOS a Linuxhoz készült Védelmi csomaggal, amelyet az SAP támogat az Azure-ban. További információ: SAP-megjegyzés #1662610 – A Linuxhoz készült SIOS Protection Suite támogatási részletei.

Támogatott tárolás a fent felsorolt SAP Central Services-forgatókönyvekkel

Mivel az Azure Storage-típusoknak csak egy részhalmaza biztosít magas rendelkezésre állású NFS- vagy SMB-megosztásokat az SAP Central Services-fürtforgatókönyvekben való használathoz, a támogatott tárolótípusok listája

  • A Windows kibővített fájlkiszolgálóval rendelkező Windows feladatátvevő fürtkiszolgáló az Azure NetApp Files kivételével minden natív Azure-tárolótípuson üzembe helyezhető. Javasoljuk azonban a Premium Storage használatát a kiváló szolgáltatási szintű szerződéseknek köszönhetően az átviteli sebességben és az IOPS-ben.
  • Az Azure NetApp Fileson támogatott az SMB-vel rendelkező Windows Feladatátvevő fürtkiszolgáló az Azure NetApp Filesban. Az Azure Premium File-szolgáltatásokban üzemeltetett SMB-megosztások ebben a forgatókönyvben is támogatottak. Az Azure Standard Files nem támogatott
  • Az SIOS-alapú Datakeeper windowsos megosztott lemezzel rendelkező Windows feladatátvevő fürtkiszolgáló az Azure NetApp Files kivételével minden natív Azure-tárolótípuson üzembe helyezhető. Javasoljuk azonban a Premium Storage használatát a kiváló szolgáltatási szintű szerződéseknek köszönhetően az átviteli sebességben és az IOPS-ben.
  • Az Azure NetApp Files NFS-megosztásait használó SUSE vagy Red Hat Pacemaker támogatott.
  • SUSE vagy Red Hat Pacemaker NFS-megosztásokat használ az Azure Premium Filesban LRS vagy ZRS támogatott használatával. Az Azure Standard Files nem támogatott
  • A két virtuális gép közötti konfigurációt használó drdb SUSE Pacemaker natív Azure-tárolótípusokkal támogatott, kivéve az Azure NetApp Filest. Javasoljuk azonban, hogy az egyik első féltől származó szolgáltatást használja az Azure Premium Files vagy az Azure NetApp Files használatával.
  • Az NFS-megosztás biztosításához használt glusterfs Red Hat Pacemaker natív Azure-tárolótípusokkal támogatott, kivéve az Azure NetApp Filest. Javasoljuk azonban, hogy az egyik első féltől származó szolgáltatást használja az Azure Premium Files vagy az Azure NetApp Files használatával.

Fontos

A Microsoft Azure Marketplace számos olyan puha berendezést kínál, amelyek tárolási megoldásokat biztosítanak az Azure natív tárolóján felül. Ezek a helyreállítható tárolóberendezések NFS- vagy SMB-megosztások létrehozására is használhatók, amelyek elméletileg a feladatátvevő fürtözött SAP Central Servicesben is használhatók. Ezeket a megoldásokat a Microsoft közvetlenül nem támogatja az SAP számítási feladataihoz. Ha úgy dönt, hogy egy ilyen megoldást használ az NFS- vagy SMB-megosztás létrehozásához, az SAP Central Service konfigurációjának támogatását a szoftver tárolóeszközben lévő tulajdonosának kell nyújtania.

Több SID SAP Central Services feladatátvevő fürtök

A nagy SAP-környezetekben szükséges virtuális gépek számának csökkentése érdekében az SAP lehetővé teszi több különböző SAP-rendszer SAP Central Services-példányainak futtatását feladatátvevő fürtkonfigurációban. Képzelje el azokat az eseteket, amikor 30 vagy több NetWeaver vagy S/4HANA éles rendszer van. Több SID-fürtözés nélkül ezek a konfigurációk 60 vagy több virtuális gépet igényelnek 30 vagy több Windows vagy Pacemaker feladatátvevő fürtkonfigurációban. Ha több SAP központi szolgáltatást helyez üzembe két csomóponton feladatátvevő fürtkonfigurációban, azzal jelentősen csökkentheti a virtuális gépek számát. A több SAP Central-szolgáltatáspéldány egyetlen két csomópontos fürtkonfiguráción való üzembe helyezése azonban hátrányokkal is rendelkezik. A fürtkonfiguráció egyetlen virtuális gépével kapcsolatos problémák több SAP-rendszerre is érvényesek. A fürtkonfigurációban futó vendég operációs rendszer karbantartása több koordinációt igényel, mivel több éles SAP-rendszer is érintett. Az olyan eszközök, mint az SAP LaMa, nem támogatják a több SID-fürtözést a rendszer klónozási folyamatában.

Az Azure-ban több SID-fürtkonfiguráció támogatott az ENSA1 és ENSA2 rendszerű Windows operációs rendszerekhez. Nem javasolt a régebbi Enqueue Replikációs Szolgáltatás architektúrájának (ENSA1) és az új architektúra (ENSA2) kombinálása egy több SID-fürtön. Az ilyen architektúrával kapcsolatos részletek a cikkekben találhatók

SUSE esetén a Pacemakeren alapuló több SID-fürt is támogatott. A konfiguráció egyelőre a következő célokra támogatott:

  • Legfeljebb öt SAP ASCS/SCS-példány
  • A régi enqueue replikációs kiszolgáló ice architektúrája (ENSA1)
  • Két csomópont pacemaker-fürtkonfigurációja

A konfiguráció dokumentálva van az SAP NetWeaver magas rendelkezésre állása az Azure-beli virtuális gépeken a SUSE Linux Enterprise Server for SAP-alkalmazásokhoz több SID-útmutatóban

Az Enqueue Replikációs kiszolgálóval rendelkező több SID-fürt séma szerint úgy néz ki, mint

Az Enqueue Replikációs kiszolgálóval rendelkező több SID-fürtöt bemutató diagram.

SAP HANA vertikális felskálázási forgatókönyvek

Az SAP HANA vertikális felskálázási forgatókönyvei támogatottak a HANA-tanúsítvánnyal rendelkező Azure-beli virtuális gépek egy részhalmazához az SAP HANA hardverkönyvtárában felsoroltak szerint. A "Fürtözés" oszlopban az "Igen" jelölésű virtuális gépek OLAP- vagy S/4HANA-felskálázáshoz is használhatók. A készenléti állapot nélküli konfigurációkat az Alábbi Azure Storage-típusok támogatják:

  • Azure Premium Storage v1, beleértve az Azure Write acceleratort a /hana/log kötethez
  • Azure Premium Storage v2
  • Ultralemez
  • Azure NetApp Files

Az OLAP-hoz vagy az S/4HANA-hoz készült SAP HANA kibővített konfigurációk készenléti csomópont(ok) esetén kizárólag az Azure NetApp Fileson megosztott NFS-sel támogatottak.

A készenléti csomóponttal vagy anélkül történő pontos tárolási konfigurációval kapcsolatos további információkért tekintse meg a következő cikkeket:

Vészhelyreállítási forgatókönyv

Számos különböző vészhelyreállítási forgatókönyv támogatott. A vészarchitektúrákat architektúrákként határozzuk meg, amelyek kompenzálják a teljes Azure-régiót, amely a rácson kívül halad. Ez azt jelenti, hogy a vészhelyreállítási célnak egy másik Azure-régiónak kell lennie az SAP-környezet futtatásához. Elkülönítjük a metódusokat és konfigurációkat a DBMS-rétegben és a nem DBMS-rétegben.

DBMS-réteg

A DBMS-réteg esetében támogatottak a dbMS natív replikációs mechanizmusait használó konfigurációk, például az Always On, az Oracle Data Guard, a Db2 HADR, az SAP ASE Always-On vagy a HANA rendszerreplikációs szolgáltatás. kötelező, hogy a replikációs stream ilyen esetekben aszinkron legyen, ahelyett, hogy szinkron lenne, mint a tipikus magas rendelkezésre állású forgatókönyvekben, amelyek egyetlen Azure-régióban vannak üzembe helyezve. Egy ilyen támogatott DBMS-vészhelyreállítási konfiguráció tipikus példáját az SAP HANA rendelkezésre állása az Azure-régiókban című cikkben ismertetjük. A szakasz második ábrája egy hana-forgatókönyvet ír le példaként. Az SAP-alkalmazásokhoz támogatott fő adatbázisok mind üzembe helyezhetők ilyen esetekben.

a vészhelyreállítási régióban egy kisebb virtuális gép használata támogatott célpéldányként, mivel a virtuális gép nem tapasztalja a teljes számítási feladat forgalmát. Ennek során szem előtt kell tartania a következő szempontokat:

  • A kisebb virtuálisgép-típusok nem teszik lehetővé a kisebb virtuális gépeknél több lemez csatlakoztatását
  • A kisebb virtuális gépek kevesebb hálózati és tárolási átviteli sebességgel rendelkeznek
  • A virtuálisgép-családok közötti átméretezés akkor lehet probléma, ha a különböző virtuális gépeket egy Azure Rendelkezésre állási csoportban gyűjti össze, vagy ha az átméretezésnek az M-sorozatcsalád és az Mv2 virtuálisgép-család között kell történnie
  • Az adatbázispéldány processzor- és memóriahasználata minimális késleltetéssel és elegendő processzor- és memóriaerőforrással képes fogadni a módosítások adatfolyamát, hogy ezeket a módosításokat minimális késleltetéssel alkalmazza az adatokra.

A különböző virtuálisgép-méretek korlátozásával kapcsolatos további részletek a virtuálisgép-méretek oldalán találhatók

A DR-cél üzembe helyezésének egy másik támogatott módja, ha egy második DBMS-példány van telepítve egy olyan virtuális gépen, amely nem éles SAP-példány nem éles DBMS-példányát futtatja. Ez egy kicsit nagyobb kihívást jelenthet, mivel ki kell derítenie, hogy mi szükséges a memórián, a CPU-erőforrásokon, a hálózati sávszélességen és a tárolási sávszélességen azon célpéldányok esetében, amelyeknek fő példányként kell működnie a dr. forgatókönyvben. Különösen a HANA esetében ajánlott, hogy a megosztott gazdagépen DR-célként működő példányt konfigurálja, hogy az adatok ne töltődhessenek be előre a dr. célpéldányba.

Feljegyzés

Az Azure Site Recovery használatát nem tesztelték a DBMS-környezetekhez az SAP számítási feladat alatt. Emiatt jelenleg nem támogatott az SAP-rendszerek DBMS-rétege. A Microsoft és az SAP más, nem felsorolt replikációs módszerei nem támogatottak. Az SAP-rendszerek DBMS-rétegének különböző Azure-régiók közötti replikálásához külső szoftvereket kell használnia a szoftver gyártójának, és nem támogatott a Microsoft és az SAP támogatási csatornáin keresztül.

Nem DBMS-réteg

Az SAP-alkalmazásréteg és a szükséges végleges megosztások vagy tárolási helyek esetében az ügyfelek a két fő forgatókönyvet használják:

  • A második Azure-régió vészhelyreállítási céljait nem használják éles vagy nem éles célokra. Ebben a forgatókönyvben a vészhelyreállítási célként működő virtuális gépek ideális esetben nem lesznek üzembe helyezve, és az éles SAP-alkalmazásréteg rendszerképeinek képét és módosításait a rendszer replikálja a vészhelyreállítási régióba. Egy ilyen feladat elvégzésére képes funkció az Azure Site Recovery. Az Azure Site Recovery ehhez hasonló Azure-ról Azure-ra történő replikációs forgatókönyvet támogat.
  • A vészhelyreállítási célok olyan virtuális gépek, amelyeket ténylegesen nem éles rendszerek használnak. A teljes SAP-környezet két különböző Azure-régióban oszlik meg, amelyek általában egy régióban, egy másik régióban pedig nem éles rendszereken üzemelnek. Számos ügyféltelepítés esetén az ügyfél egy éles rendszerrel egyenértékű, nem éles rendszerrel rendelkezik. Az ügyfél előre telepített éles alkalmazáspéldányokkal rendelkezik az alkalmazásréteg nem éles rendszereire. Feladatátvételi esemény esetén a nem éles példányok le lesznek állítva, az éles virtuális gépek virtuális nevei átkerülnek a nem éles virtuális gépekre (miután új IP-címeket rendeltek a DNS-hez), és az előre telepített éles példányok megkezdődnek

SAP Central Services-fürtök

A megosztott lemezeket (Windows), SMB-megosztásokat (Windows) vagy NFS-megosztásokat használó SAP Central Services-fürtöket egy kicsit nehezebb replikálni. A Windows oldalán a Windows Storage replikációja lehetséges megoldás. Linuxon az rsync egy életképes megoldás. Az Azure NetApp Files régiók közötti replikációja is életképes megoldás.

Nem támogatott forgatókönyv

Az Azure-architektúrákban az SAP számítási feladataihoz nem támogatott forgatókönyvek listája található. A nem támogatott eszközök azt jelentik, hogy az SAP és a Microsoft nem tud támogatást nyújtani ezekhez a konfigurációkhoz, és el kell halasztania az ilyen architektúrák létrehozásához szükséges szoftvereket biztosító külső felekre. A kategóriák közül kettő a következő:

  • Tároló puha berendezések: Vannak különböző tárolási puha berendezések a piacon. Néhány gyártó saját dokumentációt kínál az SAP-szoftverekhez kapcsolódó tárolási puha berendezéseik Azure-beli használatára vonatkozóan. Az ilyen tárolólágyító berendezéseket tartalmazó konfigurációk vagy üzembe helyezések támogatását a tárolólágyító berendezés szállítójának kell nyújtania. Ez a tény az SAP támogatási megjegyzésében is megjelenik #2015553
  • Magas rendelkezésre állású keretrendszerek: Csak a Pacemaker és a Windows Server feladatátvevő fürt támogatja a magas rendelkezésre állású keretrendszereket az Azure-beli SAP-számítási feladatokhoz. Ahogy korábban említettük, az SIOS Datakeeper megoldását a Microsoft ismerteti és dokumentálja. Ennek ellenére az SIOS Datakeeper összetevőit az SIOS-en keresztül kell támogatni, mint az összetevőket biztosító szállítót. Az SAP más minősített magas rendelkezésre állású keretrendszereket is felsorolt különböző SAP-megjegyzésekben. Néhányat a külső gyártó is minősített az Azure-hoz. Ennek ellenére az ilyen termékeket használó konfigurációk támogatását a termék gyártójának kell nyújtania. A különböző szállítók különböző integrációval rendelkeznek az SAP támogatási folyamataiban. Mielőtt úgy dönt, hogy a terméket az Azure-ban üzembe helyezett SAP-konfigurációkkal használja, tisztáznia kell, hogy melyik támogatási folyamat működik a legjobban az adott gyártó számára.
  • Azok a megosztott lemezfürtök, amelyeken az adatbázisfájlok a megosztott lemezeken találhatók, a maxDB kivételével nem támogatottak. Az összes többi adatbázis esetében a támogatott megoldás az, hogy SMB- vagy NFS-megosztás vagy megosztott lemez helyett külön tárolóhelyekkel kell rendelkeznie a magas rendelkezésre állású forgatókönyvek konfigurálásához

Más, nem támogatott forgatókönyvek például a következők:

  • Olyan üzembehelyezési forgatókönyvek, amelyek nagyobb hálózati késést eredményeznek az SAP-alkalmazásszint és az SAP DBMS-szint között, mint a NetWeaver, az S/4HANA és például a Hybris. Ez a következőket foglalja magában:
    • Az egyik szint üzembe helyezése a helyszínen, míg a másik szint az Azure-ban van üzembe helyezve
    • Egy rendszer SAP-alkalmazásszintjének üzembe helyezése egy másik Azure-régióban, mint a DBMS-szint
    • Egy szint üzembe helyezése az Azure-ban közösen található adatközpontokban, a másik pedig az Azure-ban, kivéve, ha az ilyen architektúramintát egy natív Azure-szolgáltatás biztosítja
    • Hálózati virtuális berendezések üzembe helyezése az SAP-alkalmazásszint és a DBMS-réteg között
    • Az Azure-adatközpontokban közösen üzemeltetett tároló használata az SAP DBMS-szinthez vagy az SAP globális átviteli címtárához
    • A két réteg üzembe helyezése két különböző felhőszolgáltatóval. Például a DBMS-szint üzembe helyezése az Oracle cloud infrastructure-ben és az alkalmazásszint az Azure-ban
  • Többpéldányos HANA Pacemaker-fürtkonfigurációk
  • Windows-fürtkonfigurációk megosztott lemezekkel SOFS-en vagy SMB-n keresztül az ANF-en a Windowson támogatott SAP-adatbázisokhoz. Ehelyett javasoljuk az adott adatbázisok natív magas rendelkezésre állású replikációjának használatát, és használjon külön tárolóvermeket
  • Linuxon támogatott SAP-adatbázisok üzembe helyezése NFS-megosztásokban található adatbázisfájlokkal, kivéve az SAP HANA-t, az Oracle-t Oracle Linuxon, a Db2-t a Suse-n és a Red Haton
  • Az Oracle DBMS üzembe helyezése bármely más vendég operációs rendszeren, a Windowson és az Oracle Linuxon kívül. Lásd még : SAP támogatási megjegyzés #2039619

Olyan forgatókönyv(ek), amelyeket nem teszteltünk, és ezért nincs tapasztalatunk a következő listával kapcsolatban:

  • Az Azure Site Recovery replikálja a DBMS-rétegbeli virtuális gépeket. Ennek eredményeképpen javasoljuk, hogy az adatbázis natív aszinkron replikációs funkcióját használja a lehetséges vészhelyreállítási konfigurációhoz

Következő lépések

Az SAP NetWeaver azure-beli virtuális gépek tervezésének és implementálásának következő lépései