Szerkesztés

Share via

SAP-üzembe helyezés az Azure-ban Oracle-adatbázis használatával

Azure ExpressRoute
SAP HANA on Azure Large Instances
Azure Virtual Machines
Azure Virtual Network
Azure NetApp Files

Ez a referenciaarchitektúra számos bevált eljárást mutat be a magas rendelkezésre állású SAP NetWeaver és az Oracle Database azure-beli futtatásához. Az architektúra alapelvei os-agnosztikusak, de ha másként nem határoznak meg, az architektúra Linuxon alapul.

Az első ábra egy referenciaarchitektúrát mutat be az Azure-beli Oracle SAP-hoz. Az architektúra rendelkezésre állási csoportokat használ.

Egy éles SAP-rendszer architektúrájának ábrája az Oracle-ben az Azure-ban.

Töltse le az architektúra és a kapcsolódó architektúrák Visio-fájlját.

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.

Összetevők

Ez a referenciaarchitektúra egy azure-beli Oracle Database-en futó tipikus SAP éles rendszert ír 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 virtuális magánhálózati (VPN-) átjárón keresztül csatlakozik egy helyszíni környezethez. Az SAP-alkalmazások és -adatbázisok saját küllős virtuális hálózatukban találhatók. A virtuális hálózatok különböző alhálózatokra vannak felosztva az egyes szintekhez: az alkalmazáshoz (SAP NetWeaver), az adatbázishoz és a megosztott szolgáltatásokhoz (például az Azure Bastionhoz).

Ez az architektúra alhálózatokra bontja a virtuális hálózati címteret. Helyezze az alkalmazáskiszolgálók egy másik alhálózatra és adatbázis-kiszolgálókra. Ezzel egyszerűbben védheti őket az alhálózati biztonsági szabályzatok kezelésével, nem pedig az egyes kiszolgálókkal, és tisztán elkülöníti az adatbázisokra vonatkozó biztonsági szabályokat az alkalmazáskiszolgálóktól.

Virtuális hálózatok közötti társviszony-létesítés. Ez az architektúra küllős hálózati topológiát használ több, egymáshoz társviszonyban lévő virtuális hálózattal. 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 kapcsolatot tesz lehetővé a társhálózatok között a Microsoft gerinchálózatán keresztül. Nem jár teljesítménybeli büntetéssel, ha egyetlen régióban van üzembe helyezve.

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, de használhat helyek közötti kapcsolatot is. 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. Itt érdemes megemlíteni, hogy 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. A virtuális hálózat bejövő, kimenő és alhálózati forgalmának korlátozásához hozzon létre olyan hálózati biztonsági csoportokat , amelyek 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. 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 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 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 teljesítménybeli okokból nem szükséges több hálózati adaptert használni. 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.)

Virtual machines (Virtuális gépek)

Ez az architektúra virtuális gépeket (VM) használ. AZ SAP-alkalmazásszint esetében a virtuális gépek az összes példányszerepkörhöz – webkonzolhoz és alkalmazáskiszolgálóhoz – üzembe vannak helyezve, mind a központi szolgáltatások, az SAP (A)SCS és az ERS, mind az alkalmazáskiszolgálók (PAS, AAS) számára. Állítsa be a virtuális gépek számát a követelményeknek megfelelően. Az Azure Virtual Machines tervezési és megvalósítási útmutatója részletesen ismerteti az SAP NetWeaver virtuális gépeken való futtatását.

Hasonlóképpen minden Oracle-célra használnak virtuális gépeket, mind az Oracle Database-hez, mind az Oracle megfigyelő virtuális gépekhez. Az architektúra megfigyelő virtuális gépei kisebbek a tényleges adatbázis-kiszolgálókhoz képest.

  • Korlátozott vCPU virtuális gépek. Az Oracle-licencelés költségeinek potenciális megtakarítása érdekében fontolja meg a vCPU által korlátozott virtuális gépek kihasználását
  • Minősített virtuálisgép-családok az SAP-hoz. Az Azure-beli virtuális gépek típusok és átviteli sebesség mérőszámok (SAPS) SAP-támogatásával kapcsolatos részletekért tekintse meg az SAP megjegyzését 1928533. (Az SAP-jegyzetek eléréséhez SAP Service Marketplace-fiókra van szüksége.)

Közelségi elhelyezési csoportok (PPG). A hálózati késés optimalizálásához 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 az alkalmazás késésének minimalizálása érdekében. Nagy mértékben javíthatják a felhasználói élményt a legtöbb SAP-alkalmazás esetében. 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 részletekért lásd a csatolt dokumentációt.

2. generációs (Gen2) virtuális gépek. Az Azure választást kínál a virtuális gépek üzembe helyezésekor, ha 1. vagy 2. generációsnak kell lenniük. A 2. generációs virtuális gépek támogatják az 1. generációs virtuális gépekhez nem elérhető kulcsfontosságú funkciókat. Különösen a nagyon nagy Oracle-adatbázisok esetében fontos ez, mivel egyes virtuálisgép-családok, például az Mv2 vagy az Mdsv2csak 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-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 Gen2-ként telepítse, még akkor is, ha a memóriakövetelmények nagyon alacsonyak. Még a Gen2-ként üzembe helyezett legkisebb virtuális gépek is felskálázhatók a legnagyobb elérhetőre egy egyszerű felszabadítással és átméretezéssel. Az 1. generációs virtuális gépek csak az 1. generációs virtuális gépek futtatására engedélyezett virtuálisgép-családokra méretezhetők át.

Tárolás

Ez az architektúra azure-beli felügyelt lemezeket használ a virtuális gépekhez és az Azure Files NFS-hez vagy az Azure NetApp Fileshoz az NFS megosztott tárolási követelményeihez, például az sapmnt és az SAP átviteli NFS-kötetekhez. Az AZURE-beli SAP-val való tárolótelepítésre vonatkozó irányelvek részletesen az AZURE Storage-típusok sap számítási feladatokkal kapcsolatos útmutatójában találhatók

  • Minősített tárolás az SAP-hoz. Az SAP-használat minősített virtuálisgép-típusaihoz hasonlóan tekintse meg az SAP megjegyzés 2015553 és az SAP megjegyzés 2039619 részleteit.
  • Tárolótervezés az SAP-hoz az Oracle-en. Az Azure-beli Oracle-beli SAP-hez ajánlott tárolótervet talál az ORACLE-hez, amely az SAP számítási feladataihoz készült Oracle DBMS-üzembe helyezést teszi lehetővé. Ez a cikk konkrét útmutatást nyújt a fájlrendszer elrendezésével, a lemezméretezési javaslatokkal és más tárolási lehetőségekkel kapcsolatban.
  • Oracle Database-fájlok tárolása. Linux ext4 vagy xfs fájlrendszereken adatbázishoz, NTFS fájlrendszert kell használni Windows-környezetekhez. Az Oracle ASM az Oracle Database 12c Release 2-es és újabb verzióihoz készült Oracle-telepítések esetében is támogatott.
  • A felügyelt lemezek alternatívái. Másik lehetőségként használhatja az Azure NetApp Filest az Oracle-adatbázishoz. További információ: SAP-megjegyzés 2039619 és az Oracle az Azure-beli dokumentációban. Az Azure Files NFS-kötetek nem Oracle Database-fájlok tárolására szolgálnak, ellentétben az Azure NetApp Files szolgáltatással.
  • Az Azure Premium SSD v2 olyan teljesítménykritikus számítási feladatokhoz készült, mint az SAP. Lásd: Prémium SSD v2 üzembe helyezése a tárolási megoldás előnyeihez és jelenlegi korlátaihoz.

Magas szintű rendelkezésre állás

Az előző architektúra egy magas rendelkezésre állású üzembe helyezést ábrázol, és minden alkalmazásréteg két vagy több virtuális gépen található. A rendszer a következő összetevőket használja.

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 növelése érdekében. Ha átfogó képet szeretne kapni az üzembe helyezé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 is, egyetlen zónán belül vagy zónák nélküli régióban), tekintse meg az SAP NetWeaver magas rendelkezésre állású architektúráját és forgatókönyveit.

Terheléselosztók.Az Azure Load Balancer az SAP-alhálózatok virtuális gépei 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, mindenképpen válassza ki a standard termékváltozatú terheléselosztót. Az alapszintű termékváltozat-kiegyensúlyozó nem támogatja a zonális redundanciát.

Vegye figyelembe a döntési tényezőket, amikor virtuális gépeket helyez üzembe az SAP rendelkezésre állási zónái között. A közelségi elhelyezési csoportok rendelkezésre állási zónával való használatát értékelni kell, és csak alkalmazásszintű virtuális gépekhez kell használni.

Feljegyzés

A rendelkezésre állási zónák támogatják a régión belüli magas rendelkezésre állást, de a dr. A zónák közötti távolságok túl rövidek. A tipikus DR-régióknak legalább 100 mérföldnyire kell lenniük az elsődleges régiótól.

Oracle-specifikus összetevők. Az Oracle Database virtuális gépek egy rendelkezésre állási csoportban vagy különböző rendelkezésre állási zónákban vannak üzembe helyezve. Minden virtuális gép tartalmazza az adatbázisszoftver és a virtuálisgép-helyi adatbázis-tároló saját telepítését. Állítsa be a szinkron adatbázis-replikációt az Oracle Data Guardon keresztül az adatbázisok között, hogy biztosítsa a konzisztenciát, és lehetővé tegye az alacsony RTO & RPO szolgáltatásidőt, ha egyéni hibák lépnek fel. Az adatbázis virtuális gépei mellett további, Oracle Data Guard Observerrel rendelkező virtuális gépekre is szükség van az Oracle Data Guard gyors üzembe helyezési feladatátvételi beállításához. Az Oracle megfigyelő virtuális gépei figyelik az adatbázis és a replikáció állapotát, és automatizált módon segítik elő az adatbázis feladatátvételét anélkül, hogy szükség lenne a fürtkezelőre. Az adatbázis-replikáció kezelése akkor végezhető el, ha az Oracle Data Guard Brokert használja a könnyű használat érdekében.

Az Oracle Data Guard üzembe helyezésével kapcsolatos részletekért lásd:

Ez az architektúra natív Oracle-eszközöket használ a fürt tényleges beállítása vagy az adatbázisszint terheléselosztójának szükségessége nélkül. Az Oracle Data Guard gyors üzembe helyezési feladatátvételi és SAP-konfigurációjával a feladatátvételi folyamat automatikus, és az SAP-alkalmazások újra csatlakoznak az új elsődleges adatbázishoz feladatátvétel esetén. Alternatív megoldásként különböző külső fürtmegoldások is léteznek, mint például az SIOS Protection Suite vagy a Veritas InfoScale, amelyek telepítésének részletei a külső gyártó dokumentációjában találhatók.

Oracle RAC. Az Oracle Real Application Cluster (RAC) jelenleg nem rendelkezik az Oracle minősítésével vagy támogatásával az Azure-ban. Az Oracle Data Guard magas rendelkezésre állású technológiái és architektúrája azonban rendkívül rugalmas SAP-környezeteket biztosíthat az állványok, adatközpontok vagy a szolgáltatás regionális megszakadása elleni védelemmel.

NFS-szint. Minden magas rendelkezésre állású SAP-üzembe helyezéshez rugalmas NFS-szintet kell használni, amely NFS-köteteket biztosít az SAP átviteli könyvtárához, sapmnt kötetet az SAP bináris fájljaihoz, valamint további köteteket az (A)SCS és az ERS-példányokhoz. Az NFS-szint megadásának lehetőségei a következők:

SAP központi szolgáltatási fürt. Ez a referenciaarchitektúra központi szolgáltatásokat futtat különálló virtuális gépeken. A Central Services egy lehetséges meghibásodási pont (SPOF), ha egyetlen virtuális gépen van üzembe helyezve. Egy magas rendelkezésre állású megoldás implementálásához fürtkezelési szoftverre van szükség, amely automatizálja az (A)SCS- és ERS-példányok feladatátvételét a megfelelő virtuális gépre. Mivel ez szorosan kötődik a kiválasztott NFS-megoldáshoz

A kiválasztott fürtmegoldáshoz szükség van egy mechanizmusra annak eldöntésére, hogy a szoftver vagy az infrastruktúra elérhetetlensége esetén melyik virtuális gépnek kell kiszolgálnia a megfelelő szolgáltatást(ok). Az Azure-beli SAP-ral két lehetőség áll rendelkezésre a STONITH Linux-alapú implementációjához – a nem válaszoló virtuális gép vagy alkalmazás kezelése

  • SU Standard kiadás-CsakLinux rendszerű SBD (STONITH Block Device) – egy vagy három további virtuális gép használata, amelyek egy kis blokkeszköz iSCSI-exportálásaként szolgálnak, amelyet a fürt tényleges tag virtuális gépei rendszeresen érnek el, két (A)SCS/ERS virtuális gép ebben a fürtkészletben. A virtuális gépek ezeket az SBD-csatlakoztatásokat használják szavazatok leadására, és így kvórumot hoznak a fürt döntéseihez. Az ezen a lapon található architektúra NEM tartalmazza az 1 vagy 3 további SBD virtuális gépet. A RedHat nem támogatja az SBD-implementációkat az Azure-ban, ezért ez a lehetőség csak az SU Standard kiadás SLES operációs rendszer számára érhető el.
  • Azure Fence Agent. További virtuális gépek használata nélkül az Azure Management API a virtuális gépek rendelkezésre állásának rendszeres ellenőrzésére szolgál.

Az NFS-réteg szakaszában csatolt segédvonalak tartalmazzák a megfelelő fürtválasztáshoz szükséges lépéseket és kialakítást. Külső Azure-minősített fürtmenedzserek is használhatók az SAP központi szolgáltatásainak magas rendelkezésre állásához.

SAP-alkalmazáskiszolgálók készlete. Két vagy több alkalmazáskiszolgáló, ahol magas rendelkezésre állás érhető el az SAP üzenetkiszolgálón vagy webkonzolon keresztüli terheléselosztási kérésekkel. Minden alkalmazáskiszolgáló független, és ehhez a virtuálisgép-készlethez nincs szükség hálózati terheléselosztásra.

SAP web diszpécserkészlet. A Web Dispatcher összetevő terheléselosztóként használható az SAP-alkalmazások kiszolgálói közötti SAP-forgalomhoz. Az SAP Web Dispatcher magas rendelkezésre állásának elérése érdekében az Azure Load Balancer a feladatátvevő fürtöt vagy a párhuzamos webküldő telepítőt implementálja.

Az Embedded Web Dispatcher on (A)SCS egy speciális lehetőség. Az (A)SCS további számítási feladatai miatt figyelembe kell vennie a megfelelő méretezést.

Az internetre irányuló kommunikációhoz a peremhálózaton (más néven DMZ-ben) egy különálló megoldást ajánlunk a biztonsági problémák kielégítése érdekében.

Windows-környezetek. Ez a dokumentum, mint az elején, elsősorban Linux-alapú üzemelő példányokkal foglalkozik. A Windows használata esetén ugyanazok az architekturális alapelvek érvényesek, és nincsenek architekturális különbségek az Oracle és a Linux között.

Az SAP-alkalmazásrészt az azure-beli Windowsban futó SAP NetWeaver futtatása architektúra-útmutatóban találja.

Megfontolások

Vészhelyreállítás

Az alábbi ábra egy éles SAP-rendszer architektúráját mutatja be az Oracle-en az Azure-ban. Az architektúra dr. és rendelkezésre állási zónákat használ.

Egy éles SAP-rendszer architektúráját bemutató ábra az Oracle-ben az Azure-ban.

Töltse le az architektúra és a kapcsolódó architektúrák Visio-fájlját.

Az SAP-alkalmazásverem minden architekturális rétege más megközelítést alkalmaz 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.

Backup

Az Oracle azure-beli biztonsági mentése több módon is elérhető:

  • Azure Backup.Az Azure által biztosított és karbantartott szkriptek az Oracle Database-hez, hogy megkönnyítsék az Oracle-műveleteket a biztonsági mentés végrehajtása előtt és után.
  • Azure Storage. Az Azure Blob NFS, az Azure Blob vagy az Azure Files storage szolgáltatásban fájlként/könyvtárként tárolt, például az SAP BR-eszközeivel ütemezett fájlalapú adatbázis-biztonsági másolatok használatával. Tekintse meg az Oracle-adatok és a naplók biztonsági mentésének dokumentált részleteit .
  • Külső biztonsági mentési megoldások. Tekintse meg a biztonsági mentési társzolgáltató architektúráját, amely támogatja az Oracle-t az Azure-ban.

Nem adatbázis-alapú virtuális gépek esetén az Azure Backup for VM ajánlott az SAP-alkalmazás virtuális gépeinek védelme és az olyan infrastruktúra körülvéve, mint az SAP Web Dispatcher.

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ő:

Következő lépések

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:

További információkért és példákért tekintse meg ezeket a cikkeket, és példákat azokra az SAP-számítási feladatokra, amelyek ugyanazokat a technológiákat használják: