SAP HANA futtatása Linux rendszerű virtuális gépeken egy Azure-beli vertikális felskálázási architektúrában

Azure
Azure Virtual Machines

Ez a referenciaarchitektúra az SAP HANA magas rendelkezésre állású, vertikálisan felskálázott környezetben való futtatásának bevált eljárásait mutatja be, amelyek támogatják az Azure-beli vészhelyreállítást. Ez az implementáció csak az adatbázisrétegre összpontosít.

Architektúra

Ez a referenciaarchitektúra egy gyakori éles rendszert ír le. Kiválaszthatja a virtuális gépek méretét a szervezet igényeinek megfelelően. Ez a konfiguráció az üzleti követelményektől függően egy virtuális gépre is csökkenthető.

Az alábbi ábra egy referenciaarchitektúrát mutat be az SAP HANA-hoz az Azure-ban:

Egy regionális üzembehelyezési architektúrát bemutató diagram.

Töltse le a cikkben szereplő diagramokat tartalmazó Visio-fájlt.

Feljegyzés

A referenciaarchitektúra üzembe helyezéséhez az SAP-termékek és más nem Microsoft-technológiák megfelelő licencelésére van szükség.

Munkafolyamat

Ez a referenciaarchitektúra az Azure-ban futó tipikus SAP HANA-adatbázist írja le egy magas rendelkezésre állású üzembe helyezésben a rendszer rendelkezésre állásának maximalizálása érdekében. Az architektúra és összetevői üzleti követelmények (RTO, RPO, üzemidővel kapcsolatos elvárások, rendszerszerepkör) alapján testre szabhatók, és akár egyetlen virtuális gépre is csökkenthetők. A hálózati elrendezés leegyszerűsítve mutatja be az ilyen SAP-környezet architektúraneveit, és nem egy teljes vállalati hálózat leírására szolgál.

Hálózatkezelés

Virtuális hálózatok. Az Azure Virtual Network szolgáltatás fokozott biztonsággal összekapcsolja az Azure-erőforrásokat egymással. Ebben az architektúrában a virtuális hálózat egy küllős topológia központjában üzembe helyezett ExpressRoute-átjárón keresztül csatlakozik egy helyszíni környezethez. Az SAP HANA-adatbázis saját küllős virtuális hálózatban található. A küllős virtuális hálózatok egy alhálózatot tartalmaznak az adatbázis virtuális gépeihez.

Ha az SAP HANA-hoz csatlakozó alkalmazások virtuális gépeken futnak, az alkalmazás virtuális gépeinek ugyanabban a virtuális hálózaton, de egy dedikált alkalmazásalhálózaton belül kell lenniük. Ha az SAP HANA-kapcsolat nem az elsődleges adatbázis, akkor az alkalmazás virtuális gépei más virtuális hálózatokban is elhelyezhetők. Az alhálózatokra számítási feladat alapján való elkülönítés lehetővé teszi a hálózati biztonsági csoportok (NSG) egyszerűbb engedélyezését, hogy csak az SAP HANA virtuális gépekre vonatkozó biztonsági szabályokat állítson be.

Zónaredundáns átjáró. Az átjárók különböző hálózatokat kötnek össze, így a helyszíni hálózatot kiterjesztik az Azure-beli virtuális hálózatra. Javasoljuk, hogy az ExpressRoute használatával hozzon létre olyan privát kapcsolatokat, amelyek nem mennek át a nyilvános interneten. A helyek közötti kapcsolatot is használhatja. Az Azure ExpressRoute- vagy VPN-átjárók zónákon keresztül is üzembe helyezhetők a zónahibák elleni védelem érdekében. A zónaredundáns virtuális hálózati átjárókban megismerheti a zónaredundáns és a zónaredundáns üzembe helyezés közötti különbségeket. A használt IP-címeknek standard termékváltozatnak kell lenniük az átjárók zónatelepítéséhez.

Hálózati biztonsági csoportok (NSG). A virtuális hálózat bejövő és kimenő hálózati forgalmának korlátozásához hozzon létre hálózati biztonsági csoportokat, amelyek viszont adott alhálózatokhoz vannak rendelve. A adatbázis- és alkalmazásalhálózatok számítási feladatspecifikus NSG-kkel vannak védve.

Alkalmazásbiztonsági csoportok (ASG). Ha részletes hálózati biztonsági szabályzatokat szeretne definiálni az NSG-kben az alkalmazásokon alapuló számítási feladatok alapján, használjon alkalmazásbiztonsági csoportokat explicit IP-címek helyett. Lehetővé teszik a virtuális gépek hálózati adaptereinek név szerinti csoportosítását és az alkalmazások védelmét azáltal, hogy szűri a hálózat megbízható szegmenseiből érkező forgalmat.

Hálózati adapterek (NIC-k). A hálózati adapterek lehetővé teszik a virtuális hálózaton lévő virtuális gépek közötti kommunikációt. 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 teljesítménybeli okokból nem szükséges több hálózati adaptert használni. Több hálózati adapter ugyanazt a hálózati átviteli sebességkorlátot használja egy virtuális géphez. 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, és mindegyik hálózati adaptert egy másik alhálózathoz csatlakoztathatja. Ezután a hálózati biztonsági csoportokkal különböző hozzáférés-vezérlési szabályzatokat kényszeríthet ki az egyes alhálózatokon.

Az Azure NIC-k több IP-címet is támogatnak. Ez a támogatás megfelel a virtuális gazdagépnevek telepítéshez való használatát az SAP által ajánlott gyakorlatnak. A teljes vázlatért tekintse meg az SAP megjegyzését 962955. (Az SAP-jegyzetek eléréséhez SAP Service Marketplace-fiókra van szüksége.)

Feljegyzés

Az SAP Megjegyzés 2731110 leírtaknak megfelelően ne helyezzen hálózati virtuális berendezést (NVA) az alkalmazás és az adatbázisrétegek közé egyetlen SAP-alkalmazásverem esetében sem. Ez jelentős adatcsomagok feldolgozási idejét mutatja be, és elfogadhatatlanul lassítja az alkalmazás teljesítményét.

Virtual machines (Virtuális gépek)

Ez az architektúra virtuális gépeket (VM) használ. Az Azure 23,5 terabájtos (TiB) memóriát kínál virtuális gépeken egycsomópontos skálázásra. Az SAP Minősített és támogatott SAP HANA hardverkönyvtár felsorolja az SAP HANA-adatbázishoz minősített virtuális gépeket. A virtuálisgép-típusok és átviteli sebesség mérőszámainak (SAPS) SAP-támogatásával kapcsolatos részletekért lásd: SAP Note 1928533 – SAP Applications on Microsoft Azure: Támogatott termékek és Azure-beli virtuálisgép-típusok. (Ehhez és más SAP-megjegyzésekhez SAP Service Marketplace-fiók szükséges.)

A Microsoft és az SAP közösen minősíti az SAP HANA számítási feladataihoz tartozó virtuálisgép-méreteket. A kisebb üzemelő példányok például 160 GiB vagy több RAM-mal rendelkező Edsv4 vagy Edsv5 virtuális gépen futtathatók. A virtuális gépek legnagyobb SAP HANA-memóriaméretének támogatásához akár 23 TiB-ot is használhat Mv2 sorozatú virtuális gépeket. Az M208 virtuálisgép-típusok körülbelül 260 000 SAPS-t, az M832ixs virtuálisgép-típusok pedig körülbelül 795 900 SAPS-t érnek el.

2. generációs (Gen2) virtuális gépek. Virtuális gépek üzembe helyezésekor használhatja az 1. vagy a 2. generációs virtuális gépeket. A 2. generációs virtuális gépek támogatják az 1. generációs virtuális gépekhez nem elérhető főbb funkciókat. Az SAP HANA esetében ez különösen fontos, mivel egyes virtuálisgép-családok, például az Mv2 és az Mdsv2 csak Gen2 virtuális gépekként támogatottak. Hasonlóképpen, egyes újabb virtuális gépek azure-beli tanúsítványához az SAP-nak csak Gen2-nek kell lennie a teljes támogatáshoz, még akkor is, ha az Azure mindkettőt engedélyezi rajtuk. A részleteket az SAP Megjegyzés 1928533 – SAP-alkalmazások a Microsoft Azure-ban: Támogatott termékek és Azure virtuálisgép-típusok.

Mivel az SAP HANA-t támogató összes többi virtuális gép csak Gen2 vagy Gen1+2 választását teszi lehetővé szelektíven, javasoljuk, hogy az összes SAP virtuális gépet csak Gen2-ként telepítse. Ez a kevés memóriaigényű virtuális gépekre is vonatkozik. Még a legkisebb 160 GiB SAP HANA virtuális gép is Futtatható Gen2 virtuális gépként, és felszabadításkor átméretezhető a régióban és az előfizetésben elérhető legnagyobb virtuális gépre.

Közelségi elhelyezési csoportok (PPG). A hálózati késés optimalizálása érdekében használhat közelségi elhelyezési csoportokat, amelyek előnyben részesítik az elhelyezést, ami azt jelenti, hogy a virtuális gépek ugyanabban az adatközpontban vannak, hogy minimalizálják az SAP HANA és az alkalmazás virtuális gépei közötti késést. Maga az SAP HANA-architektúra esetében nincs szükség PPG-re, csak az SAP HANA alkalmazásszintű virtuális gépekkel való áthelyezésének lehetősége. A PPG-k lehetséges korlátozásai miatt az adatbázis AvSet-et ritkán kell hozzáadni az SAP-rendszer PPG-jéhez, és csak akkor, ha szükséges az SAP-alkalmazás és az adatbázis-forgalom közötti késéshez. A PPG-k használati forgatókönyvével kapcsolatos további információkért tekintse meg a csatolt dokumentációt. Mivel a PPG-k egyetlen adatközpontra korlátozzák a számítási feladatokat, a PPG-k nem képesek több rendelkezésre állási zónára is kiterjedni.

Összetevők

Megfontolások

Ez a szakasz az SAP HANA Azure-on való futtatásának főbb szempontjait ismerteti.

Méretezhetőség

Ez az architektúra SAP HANA-t futtat olyan virtuális gépeken, amelyek egy példányban akár 23 TiB méretűre is méretezhetők.

Ha a számítási feladat meghaladja a virtuális gépek maximális méretét, javasoljuk, hogy többcsomópontos HANA-konfigurációkat használjon. Az online tranzakciófeldolgozási (OLTP) alkalmazások esetében a kibővített memóriakapacitás akár 4 x 23 TiB is lehet. Az online elemzési (OLAP) alkalmazások esetében a kibővített memóriakapacitás akár 16 x 7,6 TiB is lehet. Az SAP HANA-t például kibővített konfigurációban helyezheti üzembe készenléti állapotban virtuális gépeken –Red Hat Enterprise Linux vagy SU Standard kiadás Linux Enterprise Server használatával – az Azure NetApp Files használatával a megosztott tárkötetek esetében.

Tárolás

Ez az architektúra Azure-beli felügyelt lemezeket használ a virtuális gépeken vagy az Azure NetApp Filesban való tároláshoz. A felügyelt lemezekkel történő tárolótelepítésre vonatkozó irányelvek részletesen az SAP HANA Azure-beli virtuálisgép-tárolókonfigurációk dokumentumában találhatók. A felügyelt lemezek mellett az Azure NetApp Files NFS-kötetek tárolási megoldásként is használhatók az SAP HANA-hoz.

A másodpercenkénti magas bemeneti/kimeneti műveletek (IOPS) és a lemeztárolás átviteli teljesítményének elérése érdekében a tárolókötet optimalizálásának gyakori eljárásai az Azure Storage-elrendezésre is vonatkoznak. Ha például több lemezt kombinál az LVM-sel egy csíkos lemezkötet létrehozásához, az javítja az IO teljesítményét. Az Azure lemez gyorsítótárazása is jelentős szerepet játszik a szükséges I/O-teljesítmény elérésében.

Az Azure Premium SSD v1-en futó SAP HANA-naplólemezek esetében használja az alábbi technológiák egyikét az éles /hana/naplót tároló helyeken:

Ezekre a technológiákra az 1 ms-nál kisebb tárolási késés következetes teljesítéséhez van szükség.

Az Azure Premium SSD v2 olyan teljesítménykritikus számítási feladatokhoz készült, mint az SAP. Nincs szükség írásgyorsítóra, ha a /hana/log premium SSD v2-n fut. A tárolási megoldás előnyeiről és az aktuális korlátozásokról további információt a Prémium SSD 2-s verziójának üzembe helyezése című témakörben talál.

Az SAP HANA teljesítménykövetelményeiről további információt az SAP Megjegyzés 1943937 – Hardverkonfiguráció-ellenőrző eszköz című témakörben talál.

  • Költségtudatos tárolás tervezése nem éles rendszerekhez. Olyan SAP HANA-környezetek esetén, amelyek nem igényelnek maximális tárolási teljesítményt minden helyzetben, költségre optimalizált tárolási architektúrát használhat. Ez a tárolási optimalizálási lehetőség a kevés használatú éles rendszerekre vagy néhány nem éles SAP HANA-környezetre is alkalmazható. A költségoptimalizált tárolási lehetőség standard SSD-k kombinációját használja az éles környezetekhez használt Prémium vagy Ultra SSD-k helyett. A /hana/data és a /hana/log fájlrendszereket is egyetlen lemezre egyesíti. A legtöbb virtuálisgép-mérethez útmutatók és ajánlott eljárások érhetők el. Ha az Azure NetApp Filest használja az SAP HANA-hoz, a méretcsökkentést használó kötetekkel ugyanezt a célt érheti el.

  • A tárterület átméretezése vertikális felskálázáskor. Ha egy virtuális gépet a megváltozott üzleti igények vagy az adatbázis méretének növekedése miatt átméretez, a tárolókonfiguráció megváltozhat. Azure-támogatás az online lemezbővítést, a szolgáltatás megszakítása nélkül. Az SAP HANA-hoz használt csíkos lemezbeállítással az átméretezési műveletet a kötetcsoport összes lemezén egyformán el kell végezni. Ha több lemezt ad hozzá egy kötetcsoporthoz, az esetleg kiegyensúlyozhatja a csíkos adatokat. Ha több lemezt ad hozzá egy tárolókonfigurációhoz, sokkal előnyösebb új tárolókötetet létrehozni az új lemezeken. Ezután másolja ki a tartalmat állásidő alatt, és módosítsa a csatlakoztatási pontokat. Végül elveti a régi kötetcsoportot és a mögöttes lemezeket.

  • Azure NetApp Files-alkalmazáskötetcsoport. Az Azure NetApp Files NFS-köteteken található SAP HANA-fájlokat tartalmazó központi telepítések esetében az alkalmazáskötet-csoportok lehetővé teszik az összes kötet üzembe helyezését az ajánlott eljárásoknak megfelelően. Ez a folyamat az SAP HANA-adatbázis optimális teljesítményét is biztosítja. A folyamat folytatásáról további információk érhetők el . Manuális beavatkozást igényel. Hagyjon egy kis időt a létrehozásra.

Magas szintű rendelkezésre állás

Az előző architektúra egy magas rendelkezésre állású üzembe helyezést ábrázol, amely az SAP HANA-t két vagy több virtuális gépen tartalmazza. A rendszer a következő összetevőket használja.

Terheléselosztók.Az Azure Load Balancer az SAP HANA virtuális gépek közötti forgalom elosztására szolgál. Ha az Azure Load Balancert az SAP zonális üzembe helyezésébe építi be, győződjön meg arról, hogy a standard termékváltozatú terheléselosztót választja. Az alapszintű termékváltozat-kiegyensúlyozó nem támogatja a zonális redundanciát. Ebben az architektúrában a Load Balancer az SAP HANA virtuális IP-címeként működik. A rendszer hálózati forgalmat küld az aktív virtuális gépnek, ahol az elsődleges adatbázispéldány fut. Az SAP HANA aktív/írásvédett architektúrája (SLES/RHEL) érhető el, ahol a terheléselosztón megcímzett második virtuális IP-cím a hálózati forgalmat a másodlagos SAP HANA-példányra irányítja más virtuális gépeken olvasásigényes számítási feladatokhoz.

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. Ha engedélyezni szeretné a kimenő internetet ezekben a virtuális gépeken, frissítenie kell a Standard Load Balancer-konfigurációt . Emellett az Azure NAT Gateway használatával is lekérheti a kimenő kapcsolatokat.

SAP HANA-adatbázisfürtök esetén engedélyeznie kell a Direct Server Return (DSR) protokollt, más néven lebegő IP-címet. Ez a funkció lehetővé teszi, hogy a kiszolgáló válaszoljon a terheléselosztó előtér ip-címére. Ez a közvetlen kapcsolat megakadályozza, hogy a terheléselosztó az adatátviteli útvonal szűk keresztmetszetévé váljon.

Üzembe helyezési lehetőségek. 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.

SAP HANA. A magas rendelkezésre állás érdekében az SAP HANA két vagy több Linux rendszerű virtuális gépen fut. Az SAP HANA rendszerreplikálás (HSR) az elsődleges és a másodlagos (replika) SAP HANA-rendszerek közötti adatok replikálására szolgál. A HSR régióközi vagy zónák közötti vészhelyreállításhoz is használható. A virtuális gépek közötti kommunikáció késésétől függően a szinkron replikáció egy régión belül is használható. A vészhelyreállításhoz használt régiók közötti HSR a legtöbb esetben aszinkron módon fog futni.

A Linux Pacemaker-fürt esetében el kell döntenie, hogy melyik fürtkerítési mechanizmust használja. A fürtkerítés egy sikertelen virtuális gép fürtről való elkülönítésének és újraindításának folyamata. RedHat Enterprise Linux (RHEL) esetén az Azure Pacemaker egyetlen támogatott kerítési mechanizmusa az Azure-beli kerítésügynök. SU Standard kiadás Linux Enterprise Server (SLES) esetén használhatja az Azure kerítésügynököt vagy a STONITH Block Device (SBD) eszközt. Hasonlítsa össze az egyes megoldások feladatátvételi idejét, és ha van különbség, válasszon egy megoldást a helyreállítási időkorlát (RTO) üzleti követelményei alapján.

Azure kerítésügynök. Ez a kerítési módszer az Azure ARM API-ra támaszkodik, és a Pacemaker lekérdezi az ARM API-t a fürt mindkét SAP HANA virtuális gépének állapotáról. Ha egy virtuális gép meghibásodik, például az operációs rendszer nem válaszol vagy a virtuális gép összeomlik, a fürtkezelő ismét az ARM API-t használja a virtuális gép újraindításához, és szükség esetén az SAP HANA-adatbázist a másik aktív csomópontra. Erre a célra a virtuális gépek lekérdezéséhez és újraindításához egyéni szerepkörrel rendelkező egyszerű szolgáltatásnév (SPN) használható az ARM API-n keresztüli engedélyezéshez. Nincs szükség más infrastruktúrára, az architektúrarajzokban lévő SBD virtuális gépek nem lesznek üzembe helyezve az Azure kerítésügynök használata esetén.

SBD. A STONITH blokkeszköz (SBD) egy lemezt használ, amelyet a fürtkezelő blokkeszközként (nyers, fájlrendszer nélkül) ér el. Ez a lemez vagy több lemez szavazatként működik. Az SAP HANA-t futtató két fürtcsomópont mindegyike hozzáfér az SDB-lemezekhez, és rendszeresen olvas/ír a számukra kis mennyiségű információt az állapotról. Így minden fürtcsomópont ismeri a másik állapotát anélkül, hogy csak a virtuális gépek közötti hálózatkezeléstől függenek.

Lehetőleg három kis virtuális gép legyen üzembe helyezve egy rendelkezésre állási csoportban vagy a rendelkezésre állási zóna beállításában. Minden egyes virtuális gép egy lemez kis részeit exportálja blokkeszközként, amelyet a két SAP HANA-fürtcsomópont ér el. Három SBD virtuális gép biztosítja, hogy az SBD virtuális gépek tervezett vagy nem tervezett állásideje esetén elegendő szavazati jog legyen elérhető.

Az SBD virtuális gépek használata helyett az Azure-beli megosztott lemez is használható. Az SAP HANA-fürtcsomópontok ezután hozzáférnek az egyetlen megosztott lemezhez. A megosztott lemez helyileg (LRS) vagy zóna (ZRS) redundáns lehet, ha a ZRS elérhető az Azure-régióban.

Vészhelyreállítás

Az alábbi architektúra egy éles HANA-környezetet mutat be az Azure-ban, amely vészhelyreállítást biztosít. Az architektúra rendelkezésre állási zónákat tartalmaz.

Egy vészhelyreállítással rendelkező architektúrát bemutató ábra.

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.

Feljegyzés

Ha egy regionális katasztrófa nagy feladatátvételi eseményt okoz számos Azure-ügyfél számára egy régióban, a célrégió erőforrás-kapacitása nem garantált. Mint minden Azure-szolgáltatás, az Azure Site Recovery is folyamatosan bővíti a funkciókat és képességeket. Az Azure-ból Azure-ba történő replikációval kapcsolatos legfrissebb információkért tekintse meg a támogatási mátrixot.

A helyi, kétcsomópontos magas rendelkezésre állású implementáció mellett a HSR támogatja a több- és többtargetes replikációt. A HSR ezért támogatja a zónák közötti és régiók közötti replikációt. A többtargetes replikáció az SAP HANA 2.0 SPS 03 és újabb verzióihoz érhető el.

Ellenőrizze a célrégió erőforrás-kapacitását.

Azure NetApp Files. Lehetőségként az Azure NetApp Files skálázható és nagy teljesítményű tárolási megoldást biztosít az SAP HANA-adatokhoz és naplófájlokhoz. Az Azure NetApp Files támogatja a pillanatképeket a gyors biztonsági mentéshez, a helyreállításhoz és a helyi replikációhoz. Régiók közötti tartalomreplikálás esetén az Azure NetApp Files régiók közötti replikációja használható a pillanatképadatok két régió közötti replikálására. A régiók közötti replikációról és az Azure NetApp Files vészhelyreállításának minden aspektusát leíró tanulmány elérhető.

Backup

Az SAP HANA-adatokról többféleképpen is készíthet biztonsági másolatot. Az Azure-ba való migrálás után továbbra is használhatja a meglévő partner biztonsági mentési megoldásait. Az Azure két natív módszert kínál: az SAP HANA fájlszintű biztonsági mentését és az Azure Backupot az SAP HANA-hoz a Háttér felületen keresztül.

Az SAP HANA fájlszintű biztonsági mentéséhez használhatja a választott eszközt, például a hdbsql-t vagy az SAP HANA Studiót, és tárolhatja a biztonsági mentési fájlokat egy helyi lemezköteten. A biztonsági mentési kötet gyakori csatlakoztatási pontja a /hana/backup. A biztonsági mentési szabályzatok határozzák meg a kötet adatmegőrzési időtartamát. Amint megtörtént a biztonsági mentés, egy ütemezett feladatnak át kell másolnia a biztonsági mentési fájlokat az Azure Blob Storage-ba a megőrzés érdekében. A helyi biztonsági mentési fájlok megmaradnak a gyors helyreállítás érdekében.

Az Azure Backup egy egyszerű, nagyvállalati szintű megoldást kínál a virtuális gépeken futó számítási feladatokhoz. Az SAP HANA-hoz készült Azure Backup teljes integrációt biztosít az SAP HANA biztonsági mentési katalógusával, és garantálja az adatbázis-konzisztens, teljes vagy időponthoz kötött helyreállításokat. Az Azure Backup az SAP által támogatott BackInt-tanúsítvánnyal rendelkezik . Lásd még az Azure Backup gyik- és támogatási mátrixát.

Az Azure NetApp Files támogatja a pillanatképalapú biztonsági mentéseket. Az alkalmazáskonzisztens pillanatképekhez az SAP HANA-val való integráció a Azure-alkalmazás Konzisztens pillanatkép eszközzel (AzAcSnap) történik. A létrehozott pillanatképek felhasználhatók egy új kötetre való visszaállításhoz a rendszer visszaállításához vagy az SAP HANA-adatbázis másolásához. A létrehozott pillanatképek felhasználhatók vészhelyreállításhoz, ahol visszaállítási pontként működik egy másik NFS-kötetre mentett SAP HANA-naplókkal.

Figyelés

A számítási feladatok Azure-beli monitorozásához az Azure Monitor lehetővé teszi a felhőből és a helyszíni környezetekből származó telemetriai adatok átfogó gyűjtését, elemzését és használatát.

Az SAP HANA-n és más fő adatbázis-megoldásokon futó SAP-alkalmazások esetén tekintse meg az Azure Monitor for SAP-megoldásokat , amelyekből megtudhatja, hogyan segíthet az Azure Monitor for SAP az SAP-szolgáltatások rendelkezésre állásának és teljesítményének kezelésében.

Biztonság

Számos biztonsági intézkedést használnak az SAP-környezetek bizalmasságának, integritásának és rendelkezésre állásának védelmére. A felhasználói hozzáférés védelme érdekében például az SAP saját felhasználókezelési 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 információ: SAP HANA Security – Áttekintés.

Az inaktív adatok esetében a különböző titkosítási funkciók az alábbiak szerint biztosítják a biztonságot:

  • Az SAP HANA natív titkosítási technológiájával együtt fontolja meg az ügyfél által felügyelt kulcsokat támogató partnertől származó titkosítási megoldás használatát.

  • A virtuálisgép-lemezek titkosításához használhatja a Lemeztitkosítás áttekintése című cikkben ismertetett funkciókat.

  • SAP-adatbáziskiszolgálók: Használja a DBMS-szolgáltató által kínált transzparens adattitkosítás (például az SAP HANA natív titkosítási technológiáját) az adatok és a naplófájlok biztonságossá tételéhez, valamint a biztonsági másolatok titkosításának biztosításához.

  • Az Azure fizikai tárolóban (kiszolgálóoldali titkosítás) tárolt adatok automatikusan titkosítva lesznek inaktív állapotban egy Azure-beli felügyelt kulccsal. Az Azure által felügyelt kulcs helyett ügyfél által felügyelt kulcsot (CMK) is választhat.

  • Az Azure Disk Encryption bizonyos Linux-disztribúciókon, verziókon és rendszerképeken való támogatásáról a Linux rendszerű virtuális gépekhez készült Azure Disk Encryption című témakörben olvashat.

Feljegyzés

Ne kombinálja az SAP HANA natív titkosítási technológiáját az Azure Disk Encryption vagy a Gazdagépalapú titkosítással ugyanazon a tárolóköteten. Emellett a Linux rendszerű virtuális gépek operációs rendszerindító lemezei nem támogatják az Azure Disk Encryptiont. Ehelyett az SAP HANA natív titkosítása esetén kombinálja azt a kiszolgálóoldali titkosítással, amely automatikusan engedélyezve van. Vegye figyelembe, hogy az ügyfél által felügyelt kulcsok használata befolyásolhatja a tárkapacitást.

A hálózati biztonság érdekében használja a hálózati biztonsági csoportokat (NSG-ket) és az Azure Firewallt vagy egy hálózati virtuális berendezést az alábbiak szerint:

  • NSG-k használatával védheti és szabályozhatja az alhálózatok és az alkalmazás-/adatbázisrétegek közötti forgalmat. Csak az alhálózatokra alkalmazza az NSG-ket. A hálózati adapterre és az alhálózatra alkalmazott NSG-k gyakran problémákhoz vezetnek a hibaelhárítás során, és ritkán kell használni, ha valaha is.

  • Az Azure Firewall vagy az Azure hálózati virtuális berendezés használatával vizsgálja meg és szabályozza a forgalom irányítását a központi virtuális hálózatról a küllős virtuális hálózatra, ahol az SAP-alkalmazások találhatók, valamint a kimenő internetkapcsolat szabályozására.

A felhasználó és az engedélyezés esetében hajtsa végre a szerepköralapú hozzáférés-vezérlést (RBAC) és az erőforrás-zárolásokat az alábbiak szerint:

  • Kövesse a minimális jogosultság elvét, és az RBAC használatával rendeljen hozzá rendszergazdai jogosultságokat az SAP-megoldást az Azure-ban üzemeltető IaaS-szintű erőforrásokhoz. Az RBAC alapvető célja a felhasználók/csoportok feladatainak elkülönítése és ellenőrzése. Az RBAC úgy lett kialakítva, hogy csak annyi hozzáférést biztosítson az erőforrásokhoz, amelyek szükségesek ahhoz, hogy a felhasználók elvégezhessék a feladataikat.

  • Használjon erőforrás-zárolásokat a véletlen vagy rosszindulatú módosítások megelőzéséhez. Az erőforrás-zárolások segítenek megakadályozni, hogy a rendszergazdák töröljék vagy módosítsák a kritikus Fontosságú Azure-erőforrásokat, ahol az SAP-megoldás található.

További biztonsági javaslatok a Microsoft és az SAP cikkeiben találhatók.

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 a következő közösségeket:

Közreműködők

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

Fő szerző:

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

Következő lépések

További információ az összetevők technológiáiról:

Ismerkedjen meg a kapcsolódó architektúrákkal: