SAP S/4HANA Azure-beli Linuxon

Ez az útmutató az S/4HANA és a Suite HANA-n való futtatásának bevált eljárásait mutatja be magas rendelkezésre állású környezetben, amelyek támogatják az Azure-beli vészhelyreállítást (DR). A Fiori-információk csak az S/4HANA-alkalmazásokra vonatkoznak.

Architektúra

Töltse le az architektúra Visio-fájlját.

Ez az útmutató egy gyakori éles rendszert ismertet. Ez az architektúra virtuálisgép-méretekkel van üzembe helyezve, amelyek a szervezet igényeinek megfelelően módosíthatók. Az üzleti igényeknek megfelelően ezt a konfigurációt egyetlen virtuális gépre csökkentheti.

Ebben az útmutatóban a hálózati elrendezés jelentősen leegyszerűsítve mutatja be az architektúra alapelveit. Nem teljes vállalati hálózat leírására szolgál.

Az architektúra a következő összetevőket használja. Egyes megosztott szolgáltatások nem kötelezők.

Azure Virtual Network. A Virtuális hálózat szolgáltatás biztonságosan csatlakoztatja az Azure-erőforrásokat egymáshoz. Ebben az architektúrában a virtuális hálózat egy küllős topológia központjában üzembe helyezett átjárón keresztül csatlakozik egy helyszíni környezethez. A küllő az SAP-alkalmazásokhoz és az adatbázisszintekhez használt virtuális hálózat.

Virtuális hálózatok közötti társviszony-létesítés. Ez az architektúra több, egymáshoz társviszonyban található virtuális hálózatot használ. Ez a topológia az Azure-ban üzembe helyezett szolgáltatások hálózati szegmentálását és elkülönítését biztosítja. A társviszony-létesítés transzparens módon csatlakoztatja a hálózatokat a Microsoft gerinchálózatán keresztül, és nem jár teljesítménybeli büntetéssel, ha egyetlen régióban implementálják. A rendszer külön alhálózatokat használ minden rétegbeli alkalmazáshoz (SAP NetWeaver), adatbázishoz és megosztott szolgáltatásokhoz, például a jump boxhoz és a Windows Server Active Directoryhoz.

Vms. Ez az architektúra linuxos virtuális gépeket használ az alkalmazásszinthez és az adatbázisszinthez, a következő csoportosítás szerint:

• Alkalmazásszint. Ez az architektúraréteg magában foglalja a Fiori előtérbeli kiszolgálókészletet, az SAP Web Dispatcher-készletet, az alkalmazáskiszolgáló-készletet és az SAP Central Services-fürtöt. A Linux rendszerű virtuális gépeken futó Azure-beli központi szolgáltatások magas rendelkezésre állásához magas rendelkezésre állású hálózati fájlmegosztási szolgáltatás szükséges, például NFS-fájlmegosztások az Azure Filesban, az Azure NetApp Filesban, a fürtözött hálózati fájlrendszer -kiszolgálókon vagy a Linuxhoz készült SIOS Protection Suite-ban. Ha magas rendelkezésre állású fájlmegosztást szeretne beállítani a Central Services-fürthöz Red Hat Enterprise Linuxon (RHEL), konfigurálhatja a GlusterFS-t az RHEL-t futtató Azure-beli virtuális gépeken. A SU Standard kiadás Linux Enterprise Server (SLES) 15 SP1 és újabb verzióiban vagy az SAP-alkalmazásokhoz készült SLES-ben az Azure megosztott lemezeit használhatja a Pacemaker-fürtön a magas rendelkezésre állás eléréséhez.

• SAP HANA. Az adatbázisszint két vagy több Linux rendszerű virtuális gépet használ egy fürtben, hogy magas rendelkezésre állást érjen el egy vertikálisan felskálázott üzembe helyezés során. A HANA rendszerreplikációs (HSR) az elsődleges és a másodlagos HANA-rendszerek közötti tartalom replikálására szolgál. A Linux-fürtözés a rendszerhibák észlelésére és az automatikus feladatátvétel megkönnyítésére szolgál. Egy tárolóalapú vagy felhőalapú kerítési mechanizmust kell használni annak biztosítására, hogy a meghibásodott rendszer el legyen különítve vagy le legyen állítva a fürt felosztási állapotának elkerülése érdekében. A HANA kibővített üzemelő példányaiban az alábbi lehetőségek egyikével érheti el az adatbázisok magas rendelkezésre állását:

  • Hana-készenléti csomópontokat konfigurál az Azure NetApp Files linuxos fürtözési összetevő nélküli használatával.
  • Vertikális felskálázás készenléti csomópontok nélkül az Azure Premium Storage használatával. Linux-fürtözés használata feladatátvételhez.

• Azure Bastion. Ez a szolgáltatás lehetővé teszi a virtuális géphez való csatlakozást a böngésző és az Azure Portal használatával, vagy a helyi számítógépen már telepített natív SSH- vagy RDP-ügyfélen keresztül. Ha csak RDP-t és SSH-t használ a felügyelethez, az Azure Bastion nagyszerű megoldás. Ha más felügyeleti eszközöket, például az SQL Server Management Studiót vagy az SAP előtérrendszerét használja, használjon hagyományos, önkiszolgáló jump boxot.

saját DNS szolgáltatás.Az Azure saját DNS megbízható és biztonságos DNS-szolgáltatást biztosít a virtuális hálózat számára. Az Azure saját DNS kezeli és feloldja a virtuális hálózat tartományneveit anélkül, hogy egyéni DNS-megoldást kellene konfigurálnia.

Terheléselosztók. Az SAP-alkalmazásréteg alhálózatán lévő virtuális gépek közötti forgalom magas rendelkezésre állás érdekében történő elosztásához javasoljuk, hogy az Azure Standard Load Balancert használja. Vegye figyelembe, hogy a Standard Load Balancer alapértelmezés szerint biztonsági réteget biztosít. A Standard Load Balancer mögött található virtuális gépek nem rendelkeznek kimenő internetkapcsolattal. A virtuális gépek kimenő internetének engedélyezéséhez frissítenie kell a Standard Load Balancer-konfigurációt. Az Azure NAT Gateway használatával is lekérheti a kimenő kapcsolatokat. Az SAP webalapú alkalmazások magas rendelkezésre állása érdekében használja a beépített SAP Web Dispatchert vagy egy másik kereskedelmi forgalomban elérhető terheléselosztót. A kijelölés alapja:

• A forgalom típusa, például HTTP vagy SAP GUI.
• A szükséges hálózati szolgáltatások, például a Secure Sockets Layer (SSL) leállítása.

A Standard Load Balancer több előtérbeli virtuális IP-címet is támogat. Ez a támogatás ideális az alábbi összetevőket tartalmazó fürtmegvalósításokhoz:

• Advanced Business Application Programming (ABAP) SAP Central Service (ASCS)
• Replikációs kiszolgáló (ERS) létrehozása

Ez a két összetevő megoszthat egy terheléselosztót a megoldás egyszerűsítése érdekében.

A Standard Load Balancer támogatja a többrendszer-azonosítós (több SID-alapú) SAP-fürtöket is. Más szóval, több SLES-en vagy RHEL-en futó SAP-rendszer közös magas rendelkezésre állású infrastruktúrával rendelkezhet a költségek csökkentése érdekében. Javasoljuk, hogy értékelje ki a költségmegtakarítást, és ne helyezzen túl sok rendszert egy fürtbe. Azure-támogatás fürtönként legfeljebb öt SID-t ad meg.

Application Gateway. Azure-alkalmazás Gateway egy webes forgalom terheléselosztója, amellyel kezelheti a webalkalmazások forgalmát. A hagyományos terheléselosztók a szállítási rétegen működnek (OSI 4. réteg – TCP és UDP). A forrás IP-címe és portja alapján átirányítják a forgalmat egy cél IP-címre és portra. Az Application Gateway a HTTP-kérések további attribútumai, például az URI-elérési út vagy a gazdagépfejlécek alapján hozhat útválasztási döntéseket. Ezt a fajta útválasztást alkalmazásrétegbeli (OSI 7. réteg) terheléselosztásnak nevezzük. Az S/4HANA webalkalmazási szolgáltatásokat kínál a Fiorin keresztül. Az Application Gateway használatával terheléselosztást végezhet a webalkalmazásokból álló Fiori előtéren.

Átjáró. Az átjárók különböző hálózatokat kapcsolnak össze, és kiterjesztik a helyszíni hálózatot egy Azure-beli virtuális hálózatra. Az Azure ExpressRoute az ajánlott Azure-szolgáltatás olyan privát kapcsolatok létrehozásához, amelyek nem mennek át a nyilvános interneten, de helyek közötti kapcsolatot is használhat. A késés csökkentése érdekében az ExpressRoute Global Reach és az ExpressRoute FastPath a jelen cikk későbbi részében tárgyalt csatlakozási lehetőségek.

Zónaredundáns átjáró. ExpressRoute- vagy virtuális magánhálózati (VPN-) átjárókat helyezhet üzembe zónák között a zónahibák elleni védelem érdekében. Ez az architektúra zónaredundáns virtuális hálózati átjárókat használ a rugalmasság érdekében, nem pedig egy azonos rendelkezésre állási zónán alapuló zónaalapú üzembe helyezést.

Közelségi elhelyezési csoport. Ez a logikai csoport korlátozza a rendelkezésre állási csoportban vagy virtuálisgép-méretezési csoportban üzembe helyezett virtuális gépeket. A közelségi elhelyezési csoport előnyben részesíti a közös elhelyezést, amely a virtuális gépeket ugyanabban az adatközpontban helyezi el az alkalmazás késésének minimalizálása érdekében.

Hálózati biztonsági csoportok. A virtuális hálózatok bejövő, kimenő és alhálózati forgalmának korlátozásához hálózati biztonsági csoportokat hozhat létre.

Alkalmazásbiztonsági csoportok. A számítási feladatokon alapuló és alkalmazásokra összpontosító részletes hálózati biztonsági szabályzatok meghatározásához használjon alkalmazásbiztonsági csoportokat explicit IP-címek helyett. A virtuális gépeket név és alkalmazások szerint csoportosíthatja a hálózat megbízható szegmenseiből származó forgalom szűrésével.

Azure Storage. A Tároló virtuális merevlemez formájában biztosítja a virtuális gépek adatmegőrzését. Az Azure által felügyelt lemezeket javasoljuk.

Ajánlások

Ez az architektúra egy kis, éles szintű üzembe helyezést ír le. Az üzemelő példányok az üzleti követelményektől függően eltérőek lehetnek, ezért érdemes kiindulópontként tekinteni ezekre a javaslatokra.

Virtuális gépek

Az alkalmazáskiszolgáló-készletekben és -fürtökben a követelményeknek megfelelően állítsa be a virtuális gépek számát. Az SAP NetWeaver virtuális gépeken való futtatásával kapcsolatos részletes információkért tekintse meg az Azure Virtual Machines tervezési és megvalósítási útmutatójában. Az útmutató az SAP S/4HANA üzemelő példányokra is vonatkozik.

Az Azure-beli virtuális gépek típusaihoz és az átviteli sebesség mérőszámához (SAPS) nyújtott SAP-támogatással kapcsolatos részletekért tekintse meg az SAP Megjegyzés 1928533. Az SAP-jegyzetek eléréséhez SAP Service Marketplace-fiókra van szüksége. A HANA-adatbázishoz tartozó minősített Azure-beli virtuális gépek listáját az SAP Certified and Supported SAP HANA Hardware Directoryban találja.

SAP Web Dispatcher

A Web Dispatcher összetevő az SAP-forgalom terheléselosztására szolgál az SAP-alkalmazáskiszolgálók között. Az SAP Web Dispatcher magas rendelkezésre állásának elérése érdekében az Azure Load Balancer feladatátvevő fürtöt vagy párhuzamos webküldő telepítőt implementál. Az internetkapcsolattal rendelkező kommunikációhoz a peremhálózaton található önálló megoldás az ajánlott architektúra a biztonsági problémák kielégítése érdekében. Az ASCS beágyazott webküldője egy speciális lehetőség. Ha ezt a lehetőséget használja, fontolja meg a megfelelő méretezést az ASCS extra számítási feladatai miatt.

Fiori előtérbeli kiszolgáló (FES)

Ez az architektúra számos követelményt kielégít, és feltételezi, hogy a beágyazott Fiori FES-modellt használják. Az összes technológiai összetevő az S/4 rendszerre van telepítve, ami azt jelenti, hogy minden S/4 rendszer saját Fiori indítópaddal rendelkezik. Az üzembehelyezési modell magas rendelkezésre állási beállítása az S/4 rendszeré – nincs szükség további fürtözésre vagy virtuális gépekre. Ezért az architektúradiagram nem jeleníti meg a FES-összetevőt.

Az elsődleges üzembehelyezési lehetőségek leírását – akár beágyazott, akár központ– a forgatókönyvek alapján az SAP Fiori telepítési lehetőségei és a rendszerállapotra vonatkozó javaslatok ismertetik. Az egyszerűség és a teljesítmény érdekében a Fiori technológiai összetevők és az S/4-alkalmazások közötti szoftverkiadások szorosan kapcsolódnak egymáshoz. Ez a beállítás olyan központi telepítést tesz lehetővé, amely csak néhány szűk használati esetnek felel meg.

Ha a FES Hub üzembe helyezését használja, a FES egy kiegészítő összetevő a klasszikus SAP NetWeaver ABAP-veremhez. Állítsa be a magas rendelkezésre állást ugyanúgy, mint egy háromrétegű, fürtözött vagy több gazdagépet tartalmazó ABAP-alkalmazásverem védelmét: használjon készenléti kiszolgálói adatbázisréteget, egy fürtözött ASCS-réteget magas rendelkezésre állású NFS-vel a megosztott tárterülethez, és legalább két alkalmazáskiszolgálót. A forgalom terheléselosztása egy webküldő példánypáron keresztül történik, amelyek fürtözöttek vagy párhuzamosak lehetnek. Az internetkapcsolattal rendelkező Fiori-alkalmazások esetében fes hub üzembe helyezését javasoljuk a szegélyhálózaton. Az Azure Web Application Firewall használata az Application Gatewayen kritikus fontosságú összetevőként a fenyegetések visszafejtéséhez. A Microsoft Entra ID és az SAML használata a felhasználói hitelesítéshez és az SAP Fiori egyszeri bejelentkezéséhez.

Néhány internetkapcsolattal rendelkező bejövő/kimenő tervezési példáért tekintse meg az Azure-beli SAP bejövő és kimenő internetkapcsolatait.

Alkalmazáskiszolgálók készlete

Az ABAP-alkalmazáskiszolgálók bejelentkezési csoportjainak kezeléséhez gyakori az SMLG-tranzakció használata a bejelentkezési felhasználók terheléselosztására, az SM61 kötegelt kiszolgálócsoportokhoz való használata, az RZ12 használata távoli függvényhívási (RFC-) csoportokhoz stb. Ezek a tranzakciók a Central Services üzenetkiszolgálón található terheléselosztási képességet használják a bejövő munkamenetek vagy számítási feladatok elosztására az SAP GUI-kat és RFC-forgalmat kezelő SAP-alkalmazáskiszolgálók készlete között.

SAP Central Services-fürt

Központi szolgáltatásokat egyetlen virtuális gépen is üzembe helyezhet, ha az Azure egypéldányos virtuális gép rendelkezésre állási szolgáltatásiszint-szerződése (SLA) megfelel a követelménynek. A virtuális gép azonban az SAP-környezet lehetséges meghibásodási pontjává (SPOF) válik. Magas rendelkezésre állású Központi szolgáltatások üzembe helyezéséhez használja az NFS-t az Azure Fileson keresztül, vagy az Azure NetApp Files szolgáltatást és egy Central Services-fürtöt.

Egy másik lehetőség az Azure-beli megosztott lemezek használata a magas rendelkezésre állás eléréséhez. Az SLES 15 SP1-en és újabb verziókon, illetve az SAP-alkalmazásokhoz készült SLES-en beállíthatja a Pacemaker-fürtöt a Linuxhoz készült Azure megosztott lemezek használatával.

Másik lehetőségként NFS-fájlmegosztást is használhat a Linux-fürt megosztott tárhelyéhez.

Egy Azure-üzemelő példányon az alkalmazáskiszolgálók a Központi szolgáltatások vagy az ERS-szolgáltatások virtuális gazdagépnevén keresztül csatlakoznak a magas rendelkezésre állású Központi szolgáltatásokhoz. Ezek a gazdagépnevek a terheléselosztó fürt előtér-IP-konfigurációjába vannak rendelve. A Load Balancer több előtérbeli IP-címet is támogat, így a Central Services és az ERS virtuális IP-címek is konfigurálhatók egy terheléselosztóra.

Általánosan elérhető az ASCS több SID-alapú telepítésének Linux-fürttámogatása az Azure-ban. A rendelkezésre állási fürt több SAP-rendszer között való megosztása leegyszerűsíti az SAP-környezetet.

Hálózatkezelés

Ez az architektúra küllős topológiát használ, ahol a központi virtuális hálózat központi kapcsolódási pontként működik egy helyszíni hálózathoz. A küllők a központtal társviszonyban lévő virtuális hálózatok. A küllőkkel elkülönítheti a számítási feladatokat. A forgalom átjárókapcsolaton keresztül áramlik a helyszíni adatközpont és a központ között.

Hálózati adapterek (NIC-k)

A hagyományos helyszíni SAP-üzemelő példányok gépenként több hálózati adaptert implementálnak, hogy elkülönítse a rendszergazdai forgalmat az üzleti forgalomtól. Az Azure-ban a virtuális hálózat egy szoftveralapú hálózat, amely az összes forgalmat ugyanazon a hálózati hálón keresztül küldi el. Ezért a teljesítmény szempontjából szükségtelen több hálózati adapter használata. Ha azonban a szervezetnek el kell különítenie a forgalmat, virtuális gépenként több hálózati adaptert is üzembe helyezhet, az egyes hálózati adaptereket egy másik alhálózathoz csatlakoztathatja, majd hálózati biztonsági csoportokkal kényszerítheti ki a különböző hozzáférés-vezérlési szabályzatokat.

Az Azure NIC-k több IP-címet is támogatnak. Ez a támogatás összhangban van azzal a gyakorlattal, amelyet az SAP a virtuális gazdagépnevek telepítéshez való használatát javasolja az SAP megjegyzésében 962955 leírtak szerint. Az SAP-jegyzetek eléréséhez SAP Service Marketplace-fiókra van szüksége.

Alhálózatok és hálózati biztonsági csoportok

Ez az architektúra alhálózatokra osztja a virtuális hálózati címteret. Minden alhálózatot társíthat egy hálózati biztonsági csoporttal, amely meghatározza az alhálózat hozzáférési szabályzatait. Helyezze az alkalmazáskiszolgálót egy külön alhálózatra. Ezzel egyszerűbben védheti meg őket az alhálózati biztonsági szabályzatok kezelésével, nem pedig az egyes kiszolgálókkal.

Ha egy hálózati biztonsági csoportot alhálózathoz társít, a hálózati biztonsági csoport az alhálózaton belüli összes kiszolgálóra vonatkozik, és részletes vezérlést biztosít a kiszolgálók felett. Állítsa be a hálózati biztonsági csoportokat az Azure Portal, a PowerShell vagy az Azure CLI használatával.

Az ExpressRoute Global Reach

Ha a hálózati környezet két vagy több ExpressRoute-kapcsolatcsoportot tartalmaz, az ExpressRoute Global Reach segíthet csökkenteni a hálózati ugrásokat és a késést. Ez a technológia egy határátjáró protokoll (BGP) útvonal-társviszony-létesítés, amely két vagy több ExpressRoute-kapcsolatcsoport között van beállítva két ExpressRoute-útválasztási tartomány áthidalásához. A Global Reach csökkenti a késést, ha a hálózati forgalom egynél több ExpressRoute-kapcsolatcsoporton halad át. Jelenleg csak az ExpressRoute-kapcsolatcsoportok privát társviszony-létesítése esetén érhető el.

Jelenleg nincsenek olyan hálózati hozzáférés-vezérlési listák vagy egyéb attribútumok, amelyek módosíthatók a Global Reachben. Így egy adott ExpressRoute-kapcsolatcsoport által (a helyszínen és az Azure-ban) tanult összes útvonal meghirdetve lesz a kapcsolatcsoport másik ExpressRoute-kapcsolatcsoporthoz való társviszony-létesítésében. Javasoljuk, hogy helyszíni hálózati forgalomszűrést hozzon létre az erőforrásokhoz való hozzáférés korlátozása érdekében.

ExpressRoute FastPath

A FastPath az Azure-hálózat belépési pontján implementálja a Microsoft Edge-csereprogramokat. A FastPath csökkenti a hálózati ugrásokat a legtöbb adatcsomag esetében. Ennek eredményeképpen a FastPath csökkenti a hálózati késést, javítja az alkalmazás teljesítményét, és ez az azure-beli új ExpressRoute-kapcsolatok alapértelmezett konfigurációja.

Meglévő ExpressRoute-kapcsolatcsoportok esetén lépjen kapcsolatba Azure-támogatás a FastPath aktiválásához.

A FastPath nem támogatja a virtuális hálózatok közötti társviszony-létesítést. Ha más virtuális hálózatok vannak társviszonyban az ExpressRoute-hoz csatlakoztatott hálózattal, a rendszer elküldi a helyszíni hálózatról a másik küllős virtuális hálózatra érkező hálózati forgalmat a virtuális hálózati átjárónak. A megkerülő megoldás az, hogy az összes virtuális hálózatot közvetlenül az ExpressRoute-kapcsolatcsoporthoz csatlakoztatja.

Terheléselosztók

Az SAP Web Dispatcher kezeli az SAP-alkalmazáskiszolgálók készletéhez tartozó HTTP(S) forgalom terheléselosztását. Ez a szoftveres terheléselosztó olyan alkalmazásréteg-szolgáltatásokat (az ISO hálózati modell 7. rétegét) kínál, amelyek SSL-leállításra és egyéb kiszervezési funkciókra képesek.

A Load Balancer egy hálózati átviteli réteg szolgáltatás (4. réteg), amely az adatfolyamokból származó ötrekordos kivonat használatával egyensúlyozza a forgalmat. A kivonat alapja a forrás IP-címe, a forrásport, a cél IP-címe, a célport és a protokoll típusa. A Load Balancer a fürtbeállításokkal irányítja a forgalmat az elsődleges szolgáltatáspéldányra vagy az kifogástalan állapotú csomópontra, ha hiba történt. Javasoljuk, hogy az Azure Standard Load Balancert használja az összes SAP-forgatókönyvhöz. Fontos megjegyezni, hogy a Standard Load Balancer alapértelmezés szerint biztonságos, és a Standard Load Balancer mögötti virtuális gépek nem rendelkeznek kimenő internetkapcsolattal. A virtuális gépek kimenő internetének engedélyezéséhez módosítania kell a Standard Load Balancer-konfigurációt .

A DIAG protokollon vagy RFC-n keresztül egy SAP-kiszolgálóhoz csatlakozó SAP GUI-ügyfelekről érkező forgalom esetén a Central Services üzenetkiszolgálója az SAP-alkalmazáskiszolgáló bejelentkezési csoportjain keresztül egyensúlyozza a terhelést. Nincs szükség további terheléselosztóra.

Tárolás

Egyes ügyfelek standard tárolót használnak az alkalmazáskiszolgálóikhoz. Mivel a standard felügyelt lemezek nem támogatottak, az SAP megjegyzésében 1928533 leírtaknak megfelelően javasoljuk, hogy minden esetben prémium szintű Felügyelt Azure-lemezeket vagy Azure NetApp Files-fájlokat használjunk. Az SAP legutóbbi frissítése 2015553 kizárja a standard HDD-tároló és a standard SSD-tároló használatát néhány konkrét használati esetre.

Mivel az alkalmazáskiszolgálók nem tárolnak üzleti adatokat, a kisebb P4 és P6 prémium lemezeket is használhatja a költségek kezeléséhez. A tárolótípus a virtuális gépek rendelkezésre állási SLA-jára gyakorolt hatásának megismeréséhez tekintse meg a virtuális gépekhez készült SLA-t. Magas rendelkezésre állású forgatókönyvek esetén az Azure megosztott lemez funkciói elérhetők az Azure Premium SSD-ben és az Azure Ultra Disk Storage-ban. További információkért tekintse meg az Azure által felügyelt lemezeket.

Az Azure-beli megosztott lemezeket Windows Server, SLES 15 SP 1 és újabb, az SAP-hoz pedig SLES-t használhat. Ha Megosztott Azure-lemezt használ Linux-fürtökben, az Azure megosztott lemez STONITH blokkeszközként (SBD) szolgál. A fürthálózat particionálási helyzetében kvórumszavazást biztosít. Ez a megosztott lemez nem rendelkezik fájlrendszerrel, és nem támogatja több fürttag virtuális gép egyidejű írását.

Az Azure NetApp Files beépített fájlmegosztási funkciókkal rendelkezik az NFS-hez és az SMB-hez.

NFS-megosztási forgatókönyvek esetén az Azure NetApp Files rendelkezésre állást biztosít a kötetekhez és /hana/log kötetekhez /hana/datahasználható /hana/sharedNFS-megosztásokhoz. A rendelkezésre állási garanciáért tekintse meg az Azure NetApp Files SLA-ját. Ha Azure NetApp Files-alapú NFS-megosztásokat használ a kötetekhez és /hana/log a /hana/data kötetekhez, az NFS v4.1 protokollt kell használnia. A /hana/shared kötet esetében az NFS v3 protokoll támogatott.

A biztonsági mentési adattár esetében javasoljuk, hogy az Azure ritka elérésű és archív hozzáférési szintjeit használja. Ezek a tárolási szintek költséghatékony módszerek a ritkán használt hosszú élettartamú adatok tárolására. Érdemes lehet az Azure NetApp Files standard szintjét biztonsági mentési célként vagy az Azure NetApp Files biztonsági mentési lehetőségként használni. Felügyelt lemezek esetén az ajánlott biztonsági mentési adatszint az Azure ritka elérésű vagy archív hozzáférési szintje.

Az Ultra Disk Storage és az Azure NetApp Files ultra teljesítményszintje jelentősen csökkenti a lemezkéseket, és kihasználja a teljesítmény szempontjából kritikus fontosságú alkalmazásokat és az SAP-adatbázis-kiszolgálókat.

Az Azure Premium SSD v2 olyan teljesítménykritikus számítási feladatokhoz készült, mint az SAP. A tárolási megoldás előnyeivel és jelenlegi korlátaival kapcsolatos információkért tekintse meg a Prémium SSD v2 üzembe helyezését.

A teljesítménnyel kapcsolatos megfontolások

Az SAP-alkalmazáskiszolgálók folyamatosan kommunikálnak az adatbázis-kiszolgálókkal. A teljesítmény szempontjából kritikus fontosságú alkalmazások esetében, amelyek bármely adatbázisplatformon futnak, beleértve az SAP HANA-t is, engedélyezze az Írásgyorsítót a naplókötethez, ha Prémium SSD v1-et használ. Ezzel javíthatja a naplóírás késését. A Prémium SSD v2 nem használja az Írásgyorsítót. Az Írásgyorsító M sorozatú virtuális gépekhez érhető el.

A kiszolgálóközi kommunikáció optimalizálásához használja a gyorsított hálózatkezelést. A legtöbb általános célú és számításra optimalizált virtuálisgép-példányméret, amely két vagy több vCPU-val rendelkezik, támogatja a gyorsított hálózatkezelést. A hyperthreadinget támogató példányok esetén a négy vagy több vCPU-val rendelkező virtuálisgép-példányok támogatják a gyorsított hálózatkezelést.

Az SAP HANA teljesítménykövetelményeiről az SAP megjegyzése 1943937 – Hardverkonfiguráció-ellenőrző eszköz című témakörben olvashat. Az SAP-jegyzetek eléréséhez SAP Service Marketplace-fiókra van szüksége.

A magas IOPS- és lemez sávszélesség-átviteli sebesség elérése érdekében a tárolókötet teljesítményének optimalizálásával kapcsolatos gyakori eljárások a Storage-elrendezésre vonatkoznak. Ha például több lemezt egyesít csíkos lemezkötet létrehozásához, javíthatja az IO teljesítményét. A ritkán változó tártartalmak olvasási gyorsítótárának engedélyezésével növelheti az adatlekérés sebességét. Az SAP HANA futtatásakor a különböző virtuálisgép-méretek tárolási konfigurációira vonatkozó javaslatokért tekintse meg az SAP HANA Azure-beli virtuálisgép-tárolókonfigurációit.

Az Azure Premium SSD v2 olyan teljesítménykritikus számítási feladatokhoz készült, mint az SAP. Az azure-beli felügyelt lemeztípusokban megismerheti annak előnyeit és korlátait, valamint az optimális használati forgatókönyveket.

Az Ultra Disk Storage a tárolók új generációja, amely megfelel az intenzív IOPS-nak és az olyan alkalmazások átviteli sávszélesség-igényeinek, mint az SAP HANA. A virtuális gép újraindítása nélkül dinamikusan módosíthatja az ultralemezek teljesítményét, és egymástól függetlenül konfigurálhat olyan metrikákat, mint az IOPS és az MB/s. Ha az Ultra Disk Storage elérhető, az Írásgyorsító helyett az Ultra Disk Storage-t javasoljuk.

Egyes SAP-alkalmazások gyakori kommunikációt igényelnek az adatbázissal. Az alkalmazás és az adatbázisrétegek közötti hálózati késés a távolság miatt hátrányosan befolyásolhatja az alkalmazás teljesítményét. Az Azure közelségi elhelyezési csoportjai elhelyezési kényszert állítottak be a rendelkezésre állási csoportokban üzembe helyezett virtuális gépekre. A csoport logikai szerkezetén belül a közös hely és a teljesítmény előnyben részesíti a méretezhetőséget, a rendelkezésre állást és a költségeket. A közelségi elhelyezési csoportok nagy mértékben javíthatják a felhasználói élményt a legtöbb SAP-alkalmazás esetében. A GitHubon a közelségi elhelyezési csoportokhoz elérhető szkriptekkel és segédprogramokkal kapcsolatban lásd: Azure Proximity Placement Groups.

A hálózati virtuális berendezés (NVA) elhelyezése az alkalmazás és bármely SAP-alkalmazásverem adatbázisrétegei között nem támogatott. Az NVA jelentős időt igényel az adatcsomagok feldolgozásához. Emiatt elfogadhatatlanul lassítja az alkalmazás teljesítményét.

Azt is javasoljuk, hogy fontolja meg a teljesítményt, amikor rendelkezésre állási zónákkal rendelkező erőforrásokat helyez üzembe, amelyek javíthatják a szolgáltatás rendelkezésre állását a cikk későbbi részében leírtak szerint. Érdemes lehet létrehozni egy egyértelmű hálózati késési profilt a célrégió összes zónája között. Ez a megközelítés segít eldönteni, hogy a zónák közötti minimális késéshez milyen erőforrás-elhelyezésre van szüksége. A profil létrehozásához futtasson egy tesztet kis virtuális gépek üzembe helyezésével az egyes zónákban. A teszthez ajánlott eszközök közé tartozik a PsPing és az Iperf. A tesztelés után távolítsa el ezeket a virtuális gépeket. A nyilvános tartomány hálózati késési teszteszközét a rendelkezésre állási zóna késési tesztje című témakörben találja.

Az Azure NetApp Files egyedi teljesítményfunkciókkal rendelkezik, amelyek lehetővé teszik a valós idejű finomhangolást, amely megfelel a legigényesebb SAP-környezetek igényeinek. Az Azure NetApp Files használatakor figyelembe veendő teljesítménybeli szempontokat lásd: Méretezés HANA-adatbázishoz az Azure NetApp Fileson.

Méretezési szempontok

Az SAP-alkalmazásrétegben az Azure számos virtuálisgép-méretet kínál a vertikális felskálázáshoz és a horizontális felskálázáshoz. A befogadó listát az SAP Note 1928533 "SAP Applications on Azure: Supported Products and Azure VM types" (SAP-alkalmazások az Azure-ban: Támogatott termékek és Azure virtuálisgép-típusok) című témakörében találja. Az SAP-jegyzetek eléréséhez SAP Service Marketplace-fiókra van szüksége. A rendszer folyamatosan több virtuálisgép-típust minősít, így ugyanazon a felhőbeli üzembe helyezésen belül vertikálisan fel- vagy leskálázhatja a skálázást.

Az adatbázisrétegen ez az architektúra SAP HANA S/4-alkalmazásokat futtat azure-beli virtuális gépeken, amelyek egy példányban akár 24 terabájtig (TB) is skálázhatók. Ha a számítási feladat meghaladja a virtuális gépek maximális méretét, akár 96 TB-os (4 x 24) többcsomópontos konfigurációt is használhat online tranzakciófeldolgozási (OLTP) alkalmazásokhoz. További információ: Minősített és támogatott SAP HANA Hardverkönyvtár.

Rendelkezésre állási szempontok

Az erőforrás-redundancia a magas rendelkezésre állású infrastruktúra-megoldások általános témája. Az egypéldányos virtuálisgép-rendelkezésre állási SLA-k különböző tárolási típusok esetében lásd a virtuális gépek SLA-ját. A szolgáltatás rendelkezésre állásának növeléséhez helyezzen üzembe virtuálisgép-erőforrásokat rugalmas vezénylési, rendelkezésre állási zónákkal vagy rendelkezésre állási csoportokkal rendelkező virtuálisgép-méretezési csoportokkal.

Az SAP-alkalmazás ezen elosztott telepítésében a rendszer replikálja az alaptelepítést a magas rendelkezésre állás érdekében. Az architektúra minden rétegében eltérő a magas rendelkezésre állási kialakítás.

Üzembe helyezési módszerek

Az Azure-ban az SAP-számítási feladatok üzembe helyezése lehet regionális vagy zónaszintű, az SAP-alkalmazások rendelkezésre állási és rugalmassági követelményeitől függően. Az Azure különböző üzembehelyezési lehetőségeket biztosít, például a rugalmas vezénylésű virtuálisgép-méretezési csoportokat (FD=1), a rendelkezésre állási zónákat és a rendelkezésre állási csoportokat az erőforrások rendelkezésre állásának javítása érdekében. Ha átfogó képet szeretne kapni az elérhető üzembehelyezési lehetőségekről és azok alkalmazhatóságáról a különböző Azure-régiókban (beleértve a zónákat, egyetlen zónán belül vagy zónák nélküli régióban is), tekintse meg az SAP NetWeaver magas rendelkezésre állású architektúráját és forgatókönyveit.

Web Dispatcher az alkalmazáskiszolgálók szintjén

A magas rendelkezésre állást redundáns Web Dispatcher-példányok használatával érheti el. További információ: SAP Web Dispatcher az SAP dokumentációjában. A rendelkezésre állási szint a Web Dispatcher mögötti alkalmazás méretétől függ. Kisebb, skálázhatósági problémákkal rendelkező üzemelő példányokban az ASCS virtuális gépekkel együtt is megtalálhatja a Web Dispatchert. Így mentheti a független operációsrendszer-karbantartást, és egyidejűleg magas rendelkezésre állást érhet el.

Központi szolgáltatások az alkalmazáskiszolgálók szintjén

Az Azure Linux rendszerű virtuális gépek központi szolgáltatásainak magas rendelkezésre állásához használja a megfelelő magas rendelkezésre állású bővítményt a kiválasztott Linux-disztribúcióhoz. A megosztott fájlrendszereket a su Standard kiadás DRBD vagy Red Hat GlusterFS használatával szokás magas rendelkezésre állású NFS-tárolóra helyezni. Ha magas rendelkezésre állású NFS-t szeretne biztosítani, és nincs szükség NFS-fürtökre, használhat más költséghatékony vagy robusztus megoldásokat, például az NFS-t az Azure Fileson vagy az Azure NetApp Fileson keresztül. Mellékes megjegyzésként az Azure NetApp Files-megosztások üzemeltethetik az SAP HANA-adatokat és naplófájlokat. Ez a beállítás lehetővé teszi a HANA kibővített üzemi modelljét készenléti csomópontokkal, míg az Azure Fileson keresztüli NFS kiválóan alkalmas a magas rendelkezésre állású, nem adatbázisalapú fájlok megosztására.

Az Azure Fileson keresztüli NFS mostantól támogatja a magas rendelkezésre állású fájlmegosztásokat az SLES-hez és az RHEL-hez is. Ez a megoldás jól működik a magas rendelkezésre állású fájlmegosztásokhoz, például az SAP-telepítésekben/sapmnt/saptrans.

Az Azure NetApp Files támogatja az ASCS magas rendelkezésre állását az SLES-en. Az RHEL magas rendelkezésre állású ASCS-ével kapcsolatos részletes információkért lásd a Linuxhoz készült SIOS Protection Suite-t.

A továbbfejlesztett Azure Fence Agent az SU Standard kiadás és a Red Hat számára is elérhető, és jelentősen gyorsabb szolgáltatás-feladatátvételt biztosít, mint az ügynök korábbi verziója.

Egy másik lehetőség az Azure-beli megosztott lemezek használata a magas rendelkezésre állás eléréséhez. Az SLES 15 SP 1 és újabb verzióiban vagy az SAP SLES-ben a magas rendelkezésre állás érdekében azure-beli megosztott lemezek használatával állíthat be Pacemaker-fürtöt .

Az Azure Standard Load Balancerben engedélyezheti a magas rendelkezésre állású portot , és elkerülheti a terheléselosztási szabályok konfigurálását számos SAP-porton. Ha egy terheléselosztó beállításakor engedélyezi a közvetlen kiszolgálói visszatérési (DSR) funkciót, az ügyfélkérdésekre adott kiszolgálói válaszok megkerülhetik a terheléselosztót. Ezt a funkciót lebegő IP-címnek is nevezik. A terheléselosztó lehet helyszíni vagy Azure-beli. Ez a közvetlen kapcsolat megakadályozza, hogy a terheléselosztó az adatátviteli útvonal szűk keresztmetszetévé váljon. Az ASCS- és HANA DB-fürtök esetében javasoljuk, hogy engedélyezze a DSR-t. Ha a háttérkészlet virtuális gépei nyilvános kimenő kapcsolatot igényelnek, további konfigurációra van szükség.

Az SAP-kiszolgálóhoz DIAG protokollon vagy RFC-n keresztül csatlakozó SAP GUI-ügyfelekről érkező forgalom esetén a Central Services üzenetkiszolgálója az SAP-alkalmazáskiszolgáló bejelentkezési csoportjaival egyensúlyozza a terhelést. Nincs szükség további terheléselosztóra.

Alkalmazáskiszolgálók az alkalmazáskiszolgálók szintjén

A magas rendelkezésre állást az alkalmazáskiszolgálók készletében lévő forgalom terheléselosztásával érheti el.

ASCS-szint

Az alkalmazáskiszolgálók rétegéhez hasonlóan a Linuxhoz gyakran üzembe helyezett HANA magas rendelkezésre állású megoldás a Pacemaker.

Adatbázisszint

Az útmutató architektúrája egy magas rendelkezésre állású SAP HANA-adatbázisrendszert mutat be, amely két Azure-beli virtuális gépből áll. Az adatbázisszint natív rendszerreplikációs funkciója manuális vagy automatikus feladatátvételt biztosít a replikált csomópontok között:

• Manuális feladatátvételhez helyezzen üzembe több HANA-példányt, és használja a HSR-t.
• Az automatikus feladatátvételhez használja a HSR és a Linux magas rendelkezésre állású bővítményét (HAE) a Linux-disztribúcióhoz. A Linux HAE biztosítja a fürtszolgáltatásokat a HANA-erőforrásoknak, észleli a hibaeseményeket, és vezényli a hibás szolgáltatások feladatátvételét az kifogástalan állapotú csomópontra.

Virtuális gépek üzembe helyezése rendelkezésre állási zónákban

A rendelkezésre állási zónák növelhetik a szolgáltatás rendelkezésre állását. A zónák egy adott Azure-régióban fizikailag elkülönített helyekre vonatkoznak. Javítják a számítási feladatok rendelkezésre állását, és védik az alkalmazásszolgáltatásokat és a virtuális gépeket az adatközpontok leállása ellen. Az egyetlen zónában lévő virtuális gépeket úgy kezeli a rendszer, mintha egyetlen frissítési vagy tartalék tartományban lennének. Ha a zónaalapú üzembe helyezés van kiválasztva, az ugyanabban a zónában lévő virtuális gépek a lehető legjobb munkamennyiség alapján lesznek elosztva a tartalék és a frissítési tartományok között.

A funkciót támogató Azure-régiókban legalább három zóna érhető el. Az ezekben a zónákban lévő adatközpontok közötti maximális távolság azonban nem garantált. A többrétegű SAP-rendszer zónák közötti üzembe helyezéséhez ismernie kell a zónán belüli és a célzott zónák közötti hálózati késést, valamint azt, hogy az üzembe helyezett alkalmazások mennyire érzékenyek a hálózati késésre.

Vegye figyelembe ezeket a szempontokat , amikor úgy dönt, hogy erőforrásokat helyez üzembe a rendelkezésre állási zónákban:

• Késés egy zónában lévő virtuális gépek között
• A kiválasztott zónák közötti virtuális gépek közötti késés
• Ugyanazon Azure-szolgáltatások (virtuálisgép-típusok) rendelkezésre állása a kiválasztott zónákban

Aktív/passzív üzembe helyezési példa

Ebben a példában az aktív/passzív állapot a zónákon belüli alkalmazásszolgáltatás állapotára hivatkozik. Az alkalmazásrétegben az SAP-rendszer mind a négy aktív alkalmazáskiszolgálója az 1. zónában található. Egy másik négy passzív alkalmazáskiszolgálóból álló készlet a 2. zónába van beépítve, de le van állítva. Csak akkor aktiválódik, ha szükség van rájuk.

A Central Services kétcsomópontos fürtjei és az adatbázis két zónán keresztül vannak elosztva. Ha az 1. zóna meghibásodik, a Central Services és az adatbázis-szolgáltatások a 2. zónában futnak. A 2. zónában lévő passzív alkalmazáskiszolgálók aktiválva lesznek. Ha az SAP-rendszer összes összetevője ugyanabban a zónában található, a hálózati késés minimálisra csökken.

Aktív/aktív üzembe helyezési példa

Egy aktív/aktív üzemelő példányban két alkalmazáskiszolgáló épül fel két zónában. Az egyes zónákban az egyes csoportok két alkalmazáskiszolgálója inaktív vagy leáll. Ennek eredményeképpen a normál műveletek mindkét zónájában vannak aktív alkalmazáskiszolgálók.

Az ASCS és az adatbázis-szolgáltatások az 1. zónában futnak. A 2. zónában lévő alkalmazáskiszolgálók hálózati késése hosszabb lehet, amikor az ASCS-hez és az adatbázis-szolgáltatásokhoz csatlakoznak a zónák közötti fizikai távolság miatt.

Ha az 1. zóna offline állapotba kerül, az ASCS és az adatbázis-szolgáltatások feladatátvétele a 2. zónába történik. A alvó alkalmazáskiszolgálók online állapotba állíthatók, hogy teljes kapacitást biztosítsanak az alkalmazásfeldolgozáshoz.

DR-szempontok

Az SAP-alkalmazásverem minden szintje más megközelítést használ a DR-védelem biztosításához. A DR-stratégiákról és a megvalósítás részleteiről lásd: Vészhelyreállítás áttekintése és az SAP-számítási feladatokra vonatkozó infrastruktúra-irányelvek, valamint az SAP-alkalmazás vészhelyreállítási irányelvei.

Költségekkel kapcsolatos szempontok

Az Azure díjkalkulátorával megbecsülheti költségeit.

További információért lásd a Microsoft Azure Well-Architected Framework költségekkel kapcsolatos részét.

Virtuális gépek

Ez az architektúra linuxos virtuális gépeket használ a felügyeleti, SAP-alkalmazás- és adatbázisszintekhez.

A virtuális gépekhez általában számos fizetési lehetőség áll rendelkezésre:

• A kiszámítható befejezési vagy erőforrás-felhasználás nélküli számítási feladatok esetében fontolja meg a használatalapú fizetést.

• Fontolja meg az Azure Reservations használatát, ha egy vagy hároméves időtartamon keresztül véglegesítheti a virtuális gép használatát. A virtuálisgép-foglalások jelentősen csökkenthetik a költségeket. A használatalapú fizetéses szolgáltatás költségeinek akár 72 százalékát is kifizetheti.

• Az Azure-beli kihasználatlan virtuális gépek használatával olyan számítási feladatokat futtathat, amelyek megszakíthatók, és nem igényelnek befejezést előre meghatározott időkereten vagy SLA-on belül. Az Azure kihasználatlan virtuális gépeket helyez üzembe, amikor rendelkezésre áll kapacitás, és kiüríti őket, amikor vissza kell igényelnie a kapacitást. A kihasználatlan virtuális gépekhez társított költségek alacsonyabbak, mint a többi virtuális gép esetében. Fontolja meg a kihasználatlan virtuális gépeket ezekhez a számítási feladatokhoz:

  • Nagy teljesítményű számítási forgatókönyvek, kötegelt feldolgozási feladatok vagy vizuális renderelési alkalmazások
  • Tesztkörnyezetek, beleértve a folyamatos integrációt és a folyamatos teljesítési számítási feladatokat
  • Nagy méretű, állapot nélküli alkalmazások

• Az Azure Reserved Virtual Machine Instances csökkentheti a teljes tulajdonjogi költséget, ha az Azure Reserved Virtual Machine Instances díjszabását egy használatalapú előfizetéssel kombinálja, így kiszámítható és változó számítási feladatokban kezelheti a költségeket. Az ajánlatról további információt az Azure Reserved Virtual Machine Instances (Fenntartott virtuálisgép-példányok) című témakörben talál.

A díjszabás áttekintéséért tekintse meg a Linux rendszerű virtuális gépek díjszabását.

Load Balancer

Ebben a forgatókönyvben az Azure-terheléselosztók az alkalmazásréteg alhálózatában lévő virtuális gépek közötti forgalom elosztására szolgálnak.

Csak a konfigurált terheléselosztási és kimenő szabályok számáért kell fizetnie. A bejövő hálózati címfordítási (NAT) szabályok ingyenesek. A Standard Load Balancer nem számít fel óránkénti díjat, ha nincsenek szabályok konfigurálva.

ExpressRoute

Ebben az architektúrában az ExpressRoute a helyszíni hálózat és az Azure-beli virtuális hálózatok közötti privát kapcsolatok létrehozásához használt hálózati szolgáltatás.

Minden bejövő adatátvitel ingyenes. Minden kimenő adatátvitelt előre meghatározott díj alapján számítunk fel. További információkért tekintse meg az Azure ExpressRoute díjszabását.

Felügyeleti és üzemeltetési szempontok

Annak érdekében, hogy a rendszer éles környezetben fusson, vegye figyelembe az alábbi szempontokat.

Azure Center sap-megoldásokhoz

Az SAP-megoldásokhoz készült Azure Center egy teljes körű megoldás, amely lehetővé teszi SAP-rendszerek egységes számítási feladatként való létrehozását és futtatását az Azure-ban, továbbá zökkenőmentesebben kezelhető alapot biztosít az innovációhoz. Emellett az Azure Center for SAP-megoldások irányított üzembe helyezési felülete létrehozza az SAP-rendszer futtatásához szükséges számítási, tárolási és hálózati összetevőket. Ezután segít automatizálni az SAP-szoftverek telepítését a Microsoft ajánlott eljárásainak megfelelően. A felügyeleti képességeket az új és meglévő Azure-alapú SAP-rendszerekhez is használhatja. További információkért tekintse meg az Azure Center for SAP-megoldásokat.

Backup

Az SAP HANA-adatokról sokféleképpen készíthet biztonsági másolatot. Az Azure-ba való migrálás után folytassa a meglévő biztonsági mentési megoldások használatát. Az Azure két natív módszert biztosít a biztonsági mentéshez. Biztonsági másolatot készíthet az SAP HANA-ról virtuális gépeken, vagy használhatja az Azure Backupot fájlszinten. Az Azure Backup az SAP által minősített BackInt. További információ: Azure Backup – Gyakori kérdések és támogatási mátrix az SAP HANA-adatbázisok Azure-beli virtuális gépeken történő biztonsági mentéséről.

Identitáskezelés

Központosított identitáskezelő rendszer használatával szabályozhatja az erőforrásokhoz való hozzáférést minden szinten:

• Azure-erőforrásokhoz való hozzáférés biztosítása azure-beli szerepköralapú hozzáférés-vezérléssel (Azure RBAC).

• Hozzáférést biztosíthat az Azure-beli virtuális gépekhez a Lightweight Directory Access Protocol (LDAP), a Microsoft Entra ID, a Kerberos vagy egy másik rendszeren keresztül.

• Az SAP által biztosított szolgáltatásokon keresztül, illetve az OAuth 2.0 és a Microsoft Entra ID használatával is támogathatja az alkalmazásokon belüli hozzáférést.

Figyelés

Az azure-beli alkalmazások és szolgáltatások rendelkezésre állásának és teljesítményének maximalizálása érdekében használja az Azure Monitort, amely átfogó megoldás a felhőből és a helyszíni környezetekből származó telemetriai adatok gyűjtésére, elemzésére és kezelésére. Az Azure Monitor bemutatja az alkalmazások működését, és proaktív módon azonosítja az őket érintő problémákat és az erőforrásokat, amelyektől függenek. Az SAP HANA-n és más fő adatbázis-megoldásokon futó SAP-alkalmazások esetében tekintse meg az Azure Monitor for SAP-megoldásokat , amelyekből megtudhatja, hogyan segítheti az Azure Monitor for SAP az SAP-szolgáltatások rendelkezésre állásának és teljesítményének kezelését.

Biztonsági szempontok

Az SAP saját felhasználói felügyeleti motorral (UME) rendelkezik a szerepköralapú hozzáférés és engedélyezés szabályozásához az SAP-alkalmazáson és -adatbázisokon belül. További részletekért lásd: SAP HANA Security: Áttekintés.

A hálózatbiztonság javítása érdekében fontolja meg egy peremhálózat használatát, amely egy NVA használatával hoz létre tűzfalat a Web Dispatcher alhálózata és a Fiori előtérbeli kiszolgálókészletek előtt. Az adatátvitel költsége ok arra, hogy a Fiori-alkalmazásokat futtató aktív előtér-kiszolgálókat ugyanabban a virtuális hálózaton helyezze el, mint az S/4 rendszerek. Az alternatív megoldás az, hogy a szegélyhálózaton helyezi el őket, és virtuális hálózati társviszony-létesítésen keresztül csatlakoztatja őket az S/4-hez.

Az infrastruktúra biztonsága érdekében az adatok átvitel közben és inaktív állapotban vannak titkosítva. Az SAP NetWeaver azure-beli virtuális gépekre vonatkozó tervezési és megvalósítási útmutatójának "Biztonsági szempontok" szakasza az S/4HANA-re vonatkozó hálózati biztonsággal kapcsolatos információkat tartalmaz. Ez az útmutató azt is meghatározza, hogy mely hálózati portok nyíljanak meg a tűzfalakon az alkalmazáskommunikáció engedélyezéséhez.

Linux rendszerű virtuálisgép-lemezek titkosításához különböző lehetőségek közül választhat, a lemeztitkosítás áttekintésében leírtak szerint. Az SAP HANA inaktív adatok titkosításához javasoljuk, hogy használja az SAP HANA natív titkosítási technológiát. Az Azure-lemeztitkosítás bizonyos Linux-disztribúciókon, verziókon és lemezképeken való támogatásáról a Linux rendszerű virtuális gépek Azure-lemeztitkosításáról szóló cikkben olvashat.

Az SAP HANA inaktív adatok titkosításához javasoljuk, hogy használja az SAP HANA natív titkosítási technológiát.

Közösségek

A közösségek választ adhatnak a kérdéseire, továbbá segíthetnek a sikeres üzembe helyezésben. Vegye figyelembe az alábbi erőforrásokat:

• SAP-alkalmazások futtatása a Microsoft Platform blogján
• Azure-közösség támogatása
• SAP-közösség
• Stack Overflow SAP

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködő írta.

Fő szerző:

• Ben Trinh | Főépítész

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

Következő lépések

További információkért és az architektúrához hasonló technológiákat használó SAP-számítási feladatokra vonatkozó példákért tekintse meg az alábbi cikkeket:

• SAP S/4HANA vagy BW/4HANA üzembe helyezése az Azure-ban
• Azure-beli virtuális gépek tervezése és implementálása az SAP NetWeaverhez
• SAP számítási feladatok forgatókönyveinek üzemeltetésére és futtatására az Azure használatával

Kapcsolódó erőforrások

• SAP éles számítási feladatok futtatása Oracle Database használatával az Azure-ban