Oracle-alkalmazások architektúrái azure-beli virtuális gépekkel és adatbázissal az OCI-n

A következőkre vonatkozik: ✔️ Linux rendszerű virtuális gépek

A Microsoft és az Oracle együttműködve lehetővé tette az ügyfelek számára az Oracle-alkalmazások, például az Oracle E-Business Suite, a JD Edwards EnterpriseOne és a Kapcsolatok Soft felhőbeli üzembe helyezését. A Microsoft Azure és az Oracle Cloud Infrastructure (OCI) előzetes magánhálózati összekapcsolhatóságának bevezetésével az Oracle-alkalmazások mostantól üzembe helyezhetők az Azure-ban az Azure-ban vagy az OCI-ban található háttéradatbázisokkal. Az Oracle-alkalmazások integrálhatók a Microsoft Entra-azonosítóval is, lehetővé téve az egyszeri bejelentkezés beállítását, hogy a felhasználók a Microsoft Entra hitelesítő adataikkal jelentkezzenek be az Oracle-alkalmazásba.

Az OCI több Oracle-adatbázis-lehetőséget is kínál oracle-alkalmazásokhoz, például DBaaS, Exadata Cloud Service, Oracle RAC és Infrastruktúra szolgáltatásként (IaaS). Az Autonomous Database jelenleg nem támogatott háttérrendszer oracle-alkalmazásokhoz.

Az Oracle-alkalmazások azure-beli üzembe helyezésének több lehetősége is van, többek között magas rendelkezésre állású és biztonságos módon. Az Azure oracle-adatbázis virtuálisgép-rendszerképeket is kínál, amelyeket üzembe helyezhet, ha úgy dönt, hogy az Oracle-alkalmazásokat teljes egészében az Azure-ban futtatja.

Az alábbi szakaszok a Microsoft és az Oracle architektúrajavaslatait ismertetik az Oracle E-Business Suite, a JD Edwards EnterpriseOne és a Kapcsolatok Soft felhők közötti konfigurációban vagy teljes egészében az Azure-ban történő üzembe helyezéséhez. A Microsoft és az Oracle tesztelte ezeket az alkalmazásokat, és megerősítette, hogy a teljesítmény megfelel az Oracle által ezen alkalmazásokra vonatkozó szabványoknak.

Az architektúra szempontjai

Az Oracle-alkalmazások több szolgáltatásból állnak, amelyek ugyanazon vagy több virtuális gépen üzemeltethetők az Azure-ban, és opcionálisan az OCI-ben is.

Az alkalmazáspéldányok privát vagy nyilvános végpontokkal is beállíthatók. A Microsoft és az Oracle azt javasolja, hogy állítson be egy megerősített gazdagép virtuális gépet egy nyilvános IP-címmel egy külön alhálózaton az alkalmazás kezeléséhez. Ezután csak a magánhálózati IP-címeket rendelje hozzá a többi géphez, beleértve az adatbázisszintet is.

Ha egy alkalmazást felhőközi architektúrában állít be, tervezésre van szükség annak biztosításához, hogy az Azure-beli virtuális hálózat IP-címtere ne fedje át az OCI virtuális felhőhálózat magánhálózati IP-címterét.

A további biztonság érdekében alhálózati szinten állítsa be a hálózati biztonsági csoportokat, hogy csak bizonyos portokon és IP-címeken engedélyezett legyen a forgalom. A középső rétegben lévő gépeknek például csak a virtuális hálózaton belülről kell forgalmat fogadniuk. A külső forgalom nem érheti el közvetlenül a középső rétegbeli gépeket.

A magas rendelkezésre állás érdekében beállíthatja a különböző kiszolgálók redundáns példányait ugyanabban a rendelkezésre állási csoportban vagy különböző rendelkezésre állási zónákban. A rendelkezésre állási zónák lehetővé teszik a 99,99%-os üzemidejű SLA elérését, míg a rendelkezésre állási csoportok lehetővé teszik, hogy 99,95%-os üzemidős SLA-t érjen el a régióban. A cikkben bemutatott mintaarchitektúrák két rendelkezésre állási zónában vannak üzembe helyezve.

Ha egy alkalmazást felhőközi összekapcsolással helyez üzembe, továbbra is használhat egy meglévő ExpressRoute-kapcsolatcsoportot az Azure-környezet helyszíni hálózathoz való csatlakoztatásához. Az OCI-hez való csatlakozáshoz azonban külön ExpressRoute-kapcsolatcsoportra van szükség, mint a helyszíni hálózathoz csatlakozóhoz.

E-Business Suite

Az Oracle E-Business Suite (EBS) olyan alkalmazásokból áll, mint az Ellátási lánc kezelése (SCM) és az ügyfélkapcsolat-kezelés (CRM). Az OCI felügyelt adatbázisportfóliójának kihasználása érdekében az EBS a Microsoft Azure és az OCI közötti felhőközi kapcsolat használatával telepíthető. Ebben a konfigurációban a bemutató- és alkalmazásszintek az Azure-ban, az adatbázisszint pedig az OCI-ben futnak, ahogyan azt az alábbi architektúradiagram szemlélteti (1. ábra).

1. ábra: Az E-Business Suite felhők közötti architektúrája

Ebben az architektúrában az Azure-beli virtuális hálózat egy OCI-beli virtuális felhőhálózathoz csatlakozik a többfelhős összekapcsolás használatával. Az alkalmazásszint az Azure-ban van beállítva, míg az adatbázis az OCI-ben van beállítva. Javasoljuk, hogy minden összetevőt a saját alhálózatán helyezzen üzembe hálózati biztonsági csoportokkal, hogy csak adott alhálózatokról érkező forgalmat engedélyezzen adott portokon.

Az architektúra teljes mértékben az Azure-ban való üzembe helyezéshez is alkalmazható, az Oracle Data Guard használatával konfigurált magas rendelkezésre állású Oracle-adatbázisokkal egy régió két rendelkezésre állási zónájában. Az alábbi diagram (2. ábra) egy példa erre az architekturális mintára:

2. ábra: Csak az E-Business Suite azure-beli architektúrája

A következő szakaszok a különböző összetevőket ismertetik magas szinten.

Bastion tier

A megerősített gazdagép egy választható összetevő, amelyet ugrókiszolgálóként használhat az alkalmazás- és adatbázispéldányok eléréséhez. A megerősített gazdagép virtuális gépéhez nyilvános IP-cím rendelhető, bár a biztonságos hozzáférés érdekében ajánlott ExpressRoute-kapcsolatot vagy helyek közötti VPN-t beállítani a helyszíni hálózattal. Emellett csak SSH-t (22-s, Linux-port) vagy RDP-t (3389-s port, Windows Server) kell megnyitni a bejövő forgalom számára. A magas rendelkezésre állás érdekében helyezzen üzembe egy megerősített gazdagépet két rendelkezésre állási zónában vagy egyetlen rendelkezésre állási csoportban.

Emellett engedélyezheti az SSH-ügynökök továbbítását a virtuális gépeken, így a megerősített gazdagép hitelesítő adatainak továbbításával hozzáférhet a virtuális hálózat többi virtuális gépéhez. Vagy használjon SSH-bújtatást más példányok eléréséhez.

Íme egy példa az ügynöktovábbításra:

ssh -A -t user@BASTION_SERVER_IP ssh -A root@TARGET_SERVER_IP`

Ez a parancs csatlakozik a bástyához, majd azonnal újra fut ssh , így kap egy terminált a célpéldányon. Előfordulhat, hogy a célpéldány gyökérétől eltérő felhasználót kell megadnia, ha a fürt másképpen van konfigurálva. Az -A argumentum továbbítja az ügynökkapcsolatot, így a rendszer automatikusan használja a helyi gépen lévő titkos kulcsot. Vegye figyelembe, hogy az ügynöktovábbítás egy lánc, ezért a második ssh parancs is tartalmazza -A , hogy a célpéldányból kezdeményezett további SSH-kapcsolatok a helyi titkos kulcsot is használják.

Alkalmazásszint (középső)

Az alkalmazásszint a saját alhálózatában van elkülönítve. Több virtuális gép is van beállítva a hibatűrés és az egyszerű javításkezelés érdekében. Ezeket a virtuális gépeket közös tárterület támogatja, amelyet az Azure NetApp Files és az Ultra SSD-k kínálnak. Ez a konfiguráció lehetővé teszi a javítások egyszerűbb üzembe helyezését állásidő nélkül. Az alkalmazásszinten lévő gépeket egy nyilvános terheléselosztónak kell előtérbe helyeznie, hogy az EBS-alkalmazásszintre irányuló kérések akkor is feldolgozva legyenek, ha a réteg egyik gépe hiba miatt offline állapotban van.

Load balancer

Az Azure-terheléselosztó lehetővé teszi a forgalom elosztását a számítási feladat több példánya között a magas rendelkezésre állás biztosítása érdekében. Ebben az esetben egy nyilvános terheléselosztó van beállítva, mert a felhasználók az interneten keresztül férhetnek hozzá az EBS-alkalmazáshoz. A terheléselosztó elosztja a terhelést a középső réteg mindkét gépére. A nagyobb biztonság érdekében csak a vállalati hálózatról a rendszerhez hozzáférő felhasználók számára engedélyezze a forgalmat helyek közötti VPN- vagy ExpressRoute- és hálózati biztonsági csoportokkal.

Adatbázisszint

Ez a réteg üzemelteti az Oracle-adatbázist, és saját alhálózatra van elválasztva. Javasoljuk, hogy olyan hálózati biztonsági csoportokat adjon hozzá, amelyek csak az alkalmazásszintről az Oracle-specifikus adatbázis-port 1521-ben lévő adatbázisszintre irányuló forgalmat engedélyezik.

A Microsoft és az Oracle magas rendelkezésre állású beállítást javasol. A magas rendelkezésre állás az Azure-ban két Oracle-adatbázis beállításával érhető el két rendelkezésre állási zónában az Oracle Data Guard használatával, vagy az Oracle Database Exadata Cloud Service használatával az OCI-ben. Az Oracle Database Exadata Cloud Service használatakor az adatbázis két alhálózaton lesz üzembe helyezve. Az Oracle Database-t az OCI virtuális gépeken is beállíthatja két rendelkezésre állási tartományban az Oracle Data Guard használatával.

Identitásszint

Az identitásszint tartalmazza az EBS Asserter virtuális gépet. Az EBS Asserter lehetővé teszi az identitások szinkronizálását az Oracle Identity Cloud Service (IDCS) és a Microsoft Entra ID szolgáltatásból. Az EBS Asserterre azért van szükség, mert az EBS nem támogatja az olyan egyszeri bejelentkezési protokollokat, mint az SAML 2.0 vagy az OpenID Csatlakozás. Az EBS Asserter az OpenID connect tokent használja (amelyet az IDCS hoz létre), érvényesíti, majd létrehoz egy munkamenetet a felhasználó számára az EBS-ben.

Bár ez az architektúra IDCS-integrációt mutat, a Microsoft Entra ID egységes hozzáférése és az egyszeri bejelentkezés az Oracle Access Managerrel és az Oracle Internet Directoryval vagy az Oracle Unified Directoryval is engedélyezhető. További információkért tekintse meg az Oracle EBS IDCS-integrációval történő üzembe helyezésére vagy az Oracle EBS OAM-integrációval való üzembe helyezésére vonatkozó tanulmányokat.

A magas rendelkezésre állás érdekében ajánlott az EBS Asserter redundáns kiszolgálóit több rendelkezésre állási zónában üzembe helyezni, előtte terheléselosztóval.

Az infrastruktúra beállítása után az E-Business Suite az Oracle által biztosított telepítési útmutatót követve telepíthető.

JD Edwards EnterpriseOne

Az Oracle JD Edwards EnterpriseOne egy átfogó vállalati erőforrás-tervező szoftver integrált alkalmazáscsomagja. Ez egy többrétegű alkalmazás, amely Oracle- vagy SQL Server-adatbázis-háttérrendszerrel is beállítható. Ez a szakasz a JD Edwards EnterpriseOne oracle-adatbázis háttérrendszerrel való üzembe helyezésének részleteit ismerteti az OCI-ben vagy az Azure-ban.

Az alábbi ajánlott architektúrában (3. ábra) az adminisztráció, a bemutató és a középső szintek az Azure-beli virtuális hálózaton vannak üzembe helyezve. Az adatbázis egy virtuális felhőhálózatban van üzembe helyezve az OCI-ben.

Az E-Business Suite-hoz hasonlóan egy választható megerősített szintet is beállíthat biztonságos rendszergazdai célokra. Használja a megerősített virtuálisgép-gazdagépet ugrókiszolgálóként az alkalmazás- és adatbázispéldányok eléréséhez.

3. ábra: JD Edwards EnterpriseOne felhők közötti architektúra

Ebben az architektúrában az Azure-beli virtuális hálózat az OCI virtuális felhőhálózatához csatlakozik a többfelhős összekapcsolás használatával. Az alkalmazásszint az Azure-ban van beállítva, míg az adatbázis az OCI-ben van beállítva. Javasoljuk, hogy minden összetevőt a saját alhálózatán helyezzen üzembe hálózati biztonsági csoportokkal, hogy csak adott alhálózatokról érkező forgalmat engedélyezzen adott portokon.

Az architektúra teljes mértékben az Azure-ban való üzembe helyezéshez is alkalmazható, az Oracle Data Guard használatával konfigurált magas rendelkezésre állású Oracle-adatbázisokkal egy régió két rendelkezésre állási zónájában. Az alábbi diagram (4. ábra) egy példa erre az architekturális mintára:

4. ábra: JD Edwards EnterpriseOne Csak Azure-architektúra

A következő szakaszok a különböző összetevőket ismertetik magas szinten.

Bastion tier

A megerősített gazdagép egy választható összetevő, amelyet ugrókiszolgálóként használhat az alkalmazás- és adatbázispéldányok eléréséhez. A megerősített gazdagép virtuális gépéhez nyilvános IP-cím rendelhető, bár a biztonságos hozzáférés érdekében ajánlott ExpressRoute-kapcsolatot vagy helyek közötti VPN-t beállítani a helyszíni hálózattal. Emellett csak SSH-t (22-s, Linux-port) vagy RDP-t (3389-s port, Windows Server) kell megnyitni a bejövő forgalom számára. A magas rendelkezésre állás érdekében helyezzen üzembe egy megerősített gazdagépet két rendelkezésre állási zónában vagy egyetlen rendelkezésre állási csoportban.

Emellett engedélyezheti az SSH-ügynökök továbbítását a virtuális gépeken, így a megerősített gazdagép hitelesítő adatainak továbbításával hozzáférhet a virtuális hálózat többi virtuális gépéhez. Vagy használjon SSH-bújtatást más példányok eléréséhez.

Íme egy példa az ügynöktovábbításra:

ssh -A -t user@BASTION_SERVER_IP ssh -A root@TARGET_SERVER_IP`

Ez a parancs csatlakozik a bástyához, majd azonnal újra fut ssh , így kap egy terminált a célpéldányon. Előfordulhat, hogy a célpéldány gyökérétől eltérő felhasználót kell megadnia, ha a fürt másképpen van konfigurálva. Az -A argumentum továbbítja az ügynökkapcsolatot, így a rendszer automatikusan használja a helyi gépen lévő titkos kulcsot. Vegye figyelembe, hogy az ügynöktovábbítás egy lánc, ezért a második ssh parancs is tartalmazza -A , hogy a célpéldányból kezdeményezett további SSH-kapcsolatok a helyi titkos kulcsot is használják.

Rendszergazda osztószint

Ahogy a név is sugallja, ezt a szintet használják a felügyeleti feladatokhoz. A felügyeleti szinthez külön alhálózatot is ki lehet faragni. Az ebben a szinten lévő szolgáltatásokat és kiszolgálókat elsősorban az alkalmazás telepítésére és felügyeletére használják. Ezért ezeknek a kiszolgálóknak az egyetlen példánya elegendő. Az alkalmazás magas rendelkezésre állásához nincs szükség redundáns példányokra.

A szint összetevői a következők:

• Kiépítési kiszolgáló – Ez a kiszolgáló az alkalmazás különböző összetevőinek végpontok közötti üzembe helyezésére szolgál. Kommunikál a többi réteg példányaival, beleértve az adatbázisszint példányait is, a 22-s porton keresztül. A JD Edwards EnterpriseOne Kiszolgálókezelő konzolját üzemelteti.
• Üzembehelyezési kiszolgáló – Ez a kiszolgáló elsősorban a JD Edwards EnterpriseOne telepítéséhez szükséges. A telepítési folyamat során ez a kiszolgáló szolgál a szükséges fájlok és telepítési csomagok központi adattáraként. A szoftver el van terjesztve vagy üzembe helyezve a kiszolgálóról származó többi kiszolgálóra és ügyfélre.
• Fejlesztői ügyfél – Ez a kiszolgáló webböngészőben és natív alkalmazásokban futó összetevőket tartalmaz.

Bemutatási réteg

Ez a szint különböző összetevőket tartalmaz, például az Application Interface Servicest (AIS), az Alkalmazásfejlesztési keretrendszert (ADF) és a Java-alkalmazáskiszolgálókat (JAS). Az ebben a rétegben lévő kiszolgálók a középső réteg kiszolgálóival kommunikálnak. Egy terheléselosztó irányítja őket, amely a forgalmat a szükséges kiszolgálóra irányítja a forgalom által fogadott portszám és URL-cím alapján. Javasoljuk, hogy minden kiszolgálótípusból több példányt helyezzen üzembe a magas rendelkezésre állás érdekében.

A réteg összetevői a következők:

• Application Interface Services (AIS) – Az AIS-kiszolgáló biztosítja a JD Edwards EnterpriseOne mobil nagyvállalati alkalmazások és a JD Edwards EnterpriseOne közötti kommunikációs felületet.
• Java Application Server (JAS) – A JAS kéréseket fogad a terheléselosztótól, és átadja azt a középső rétegnek bonyolult feladatok végrehajtásához. A JAS képes egyszerű üzleti logika végrehajtására.
• BI Publisher Server (BIP) – Ez a kiszolgáló a JD Edwards EnterpriseOne alkalmazás által gyűjtött adatokon alapuló jelentéseket jelenít meg. Megtervezheti és szabályozhatja, hogy a jelentés hogyan jeleníti meg az adatokat különböző sablonok alapján.
• Business Services Server (BSS) – A BSS lehetővé teszi az információcserét és az együttműködést más Oracle-alkalmazásokkal.
• Valós idejű eseménykiszolgáló (RTE) – Az RTE-kiszolgáló lehetővé teszi a külső rendszerek értesítéseinek beállítását a JDE EnterpriseOne rendszerben zajló tranzakciókról. Előfizetői modellt használ, és lehetővé teszi a külső rendszerek számára az eseményekre való feliratkozást. A két RTE-kiszolgálóra irányuló kérelmek terheléselosztásához győződjön meg arról, hogy a kiszolgálók fürtben vannak.
• Application Development Framework (ADF) kiszolgáló – Az ADF-kiszolgáló az Oracle ADF-lel fejlesztett JD Edwards EnterpriseOne-alkalmazások futtatására szolgál. Ez egy Oracle WebLogic-kiszolgálón van üzembe helyezve ADF-futtatókörnyezettel.

Middle tier

A középső szint tartalmazza a logikai kiszolgálót és a kötegkiszolgálót. Ebben az esetben mindkét kiszolgáló ugyanazon a virtuális gépen van telepítve. Éles forgatókönyvek esetén azonban ajánlott a logikai kiszolgáló és a batch-kiszolgáló üzembe helyezése külön kiszolgálókon. A magasabb rendelkezésre állás érdekében több kiszolgáló is üzembe van helyezve a középső szinten két rendelkezésre állási zónában. Létre kell hozni egy Azure-terheléselosztót, és ezeket a kiszolgálókat a háttérkészletbe kell helyezni annak érdekében, hogy mindkét kiszolgáló aktív legyen, és feldolgozhassa a kéréseket.

A középső réteg kiszolgálói csak a bemutatószinten lévő kiszolgálóktól és a nyilvános terheléselosztótól fogadják a kéréseket. A hálózati biztonsági csoport szabályait úgy kell beállítani, hogy a bemutatóréteg alhálózatától és a terheléselosztótól eltérő címekről érkező forgalom ne legyen forgalom. Egy NSG-szabályt is beállíthat, amely lehetővé teszi a 22-s port forgalmát a megerősített gazdagépről felügyeleti célokra. Előfordulhat, hogy a nyilvános terheléselosztóval terheléselosztást végezhet a középső réteg virtuális gépei között.

A következő két összetevő a középső rétegben található:

• Logikai kiszolgáló – Az üzleti logikát vagy az üzleti függvényeket tartalmazza.
• Batch-kiszolgáló – Kötegelt feldolgozáshoz használatos

Adatbázisszint

Az adatbázisszint tartalmazza az alkalmazás adatbázispéldányait. Az adatbázis lehet Oracle DB, Oracle RAC vagy Oracle Exadata Database rendszer.

Ha az Oracle DB használata a választás, az adatbázispéldány üzembe helyezhető az Azure-ban az Azure Marketplace-en elérhető Oracle DB-rendszerképeken keresztül. Másik lehetőségként használhatja az Azure és az OCI közötti kapcsolatot az Oracle DB paaS-modellben való üzembe helyezéséhez az OCI-n.

Az Oracle RAC-hez használhatja az OCI-t a PaaS-modellben. Javasoljuk, hogy kétcsomópontos RAC-rendszert használjon. Bár az Oracle RAC üzembe helyezhető az Azure CloudSimple-ben az IaaS-modellben, az Oracle nem támogatja ezt a konfigurációt. Tekintse meg az engedélyezett felhőkörnyezetekre jogosult Oracle-programokat.

Végül az Exadata-rendszerek esetében használja az OCI-kapcsolatot, és telepítse az Exadata rendszert az OCI-ban. A fenti architektúra előző ábrája egy OCI-ben üzembe helyezett Exadata-rendszert mutat be két alhálózaton.

Éles forgatókönyvek esetén az adatbázis több példányát helyezze üzembe két rendelkezésre állási zónában (ha az Azure-ban helyezi üzembe) vagy két rendelkezésre állási tartományt (az OCI-ben). Az Oracle Active Data Guard használatával szinkronizálhatja az elsődleges és a készenléti adatbázisokat.

Az adatbázisszint csak a középső rétegtől fogad kéréseket. Javasoljuk, hogy állítson be egy hálózati biztonsági csoportot (biztonsági listát, ha az adatbázist az OCI-ben telepíti), hogy rendszergazdai okokból csak az 1521-as porton engedélyezze a kéréseket a középső rétegből, a 22-as portot pedig a megerősített kiszolgálóról.

Az OCI-ben üzembe helyezett adatbázisokhoz külön virtuális felhőhálózatot kell beállítani egy dinamikus útválasztási átjáróval (DRG), amely a Fast Csatlakozás kapcsolatcsoporthoz csatlakozik.

Identitásszint

A Microsoft-Oracle partnerség lehetővé teszi, hogy egységes identitást állítson be az Azure-ban, az OCI-ben és az Oracle-alkalmazásban. JD Edwards EnterpriseOne vagy Kapcsolatok Soft alkalmazáscsomag esetén az Oracle HTTP Server (OHS) egy példányára van szükség az egyszeri bejelentkezés beállításához a Microsoft Entra ID és az Oracle IDCS között.

Az OHS fordított proxyként működik az alkalmazásszinthez, ami azt jelenti, hogy a végfelhasználóknak küldött összes kérés végighalad rajta. Az Oracle Access Manager WebGate egy OHS webkiszolgáló beépülő modul, amely minden, a végfelhasználóhoz érkező kérést elfog. Ha egy elérhető erőforrás védett (hitelesített munkamenetet igényel), a WebGate OIDC hitelesítési folyamatot kezdeményez az Identity Cloud Service szolgáltatással a felhasználó böngészőjén keresztül. Az OpenID Csatlakozás WebGate által támogatott folyamatokról az Oracle Access Manager dokumentációjában talál további információt.

Ezzel a beállítással a Microsoft Entra-azonosítóba már bejelentkezett felhasználók az Oracle Identity Cloud Service-en keresztül anélkül navigálhatnak a JD Edwards EnterpriseOne vagy Kapcsolatok Soft alkalmazáshoz, hogy újra bejelentkeztek. A megoldást üzembe helyező ügyfelek élvezhetik az egyszeri bejelentkezés előnyeit, beleértve egyetlen hitelesítőadat-készletet, továbbfejlesztett bejelentkezési élményt, nagyobb biztonságot és csökkentett ügyfélszolgálati költségeket.

A JD Edwards EnterpriseOne vagy Kapcsolatok Soft egyszeri bejelentkezésének Microsoft Entra-azonosítóval való beállításával kapcsolatos további információkért tekintse meg a kapcsolódó Oracle-tanulmányt.

Kapcsolatok Soft

Az Oracle Kapcsolatok Soft alkalmazáscsomagja emberi erőforrásokhoz és pénzügyi felügyelethez használható szoftvereket tartalmaz. Az alkalmazáscsomag többrétegű, és az alkalmazások közé tartoznak az emberi erőforrás-felügyeleti rendszerek (HRMS), az ügyfélkapcsolat-kezelés (CRM), a pénzügyi és ellátási lánc kezelése (FSCM) és a vállalati teljesítménykezelés (EPM).

Javasoljuk, hogy a szoftvercsomag minden szintjét a saját alhálózatán helyezze üzembe. Az alkalmazás háttéradatbázisaként Oracle-adatbázisra vagy Microsoft SQL Serverre van szükség. Ez a szakasz a Kapcsolatok Soft Oracle-adatbázis háttérrendszerrel való üzembe helyezésének részleteit ismerteti.

Az alábbiakban egy canonical architecture for deploying the Kapcsolatok Soft application suite in a cross-cloud architecture (5. ábra).

5. ábra: Kapcsolatok Soft felhők közötti architektúra

Ebben a mintaarchitektúrában az Azure-beli virtuális hálózat az OCI virtuális felhőhálózatához csatlakozik a többfelhős összekapcsolás használatával. Az alkalmazásszint az Azure-ban van beállítva, míg az adatbázis az OCI-ben van beállítva. Javasoljuk, hogy minden összetevőt a saját alhálózatán helyezzen üzembe hálózati biztonsági csoportokkal, hogy csak adott alhálózatokról érkező forgalmat engedélyezzen adott portokon.

Az architektúra teljes mértékben az Azure-ban való üzembe helyezéshez is alkalmazható, az Oracle Data Guard használatával konfigurált magas rendelkezésre állású Oracle-adatbázisokkal egy régió két rendelkezésre állási zónájában. Az alábbi diagram (6. ábra) erre az architektúramintára mutat példát:

6. ábra: Kapcsolatok Soft Azure-beli architektúra

A következő szakaszok a különböző összetevőket ismertetik magas szinten.

Bastion tier

A megerősített gazdagép egy választható összetevő, amelyet ugrókiszolgálóként használhat az alkalmazás- és adatbázispéldányok eléréséhez. A megerősített gazdagép virtuális gépéhez nyilvános IP-cím rendelhető, bár a biztonságos hozzáférés érdekében ajánlott ExpressRoute-kapcsolatot vagy helyek közötti VPN-t beállítani a helyszíni hálózattal. Emellett csak SSH-t (22-s, Linux-port) vagy RDP-t (3389-s port, Windows Server) kell megnyitni a bejövő forgalom számára. A magas rendelkezésre állás érdekében helyezzen üzembe egy megerősített gazdagépet két rendelkezésre állási zónában vagy egyetlen rendelkezésre állási csoportban.

Emellett engedélyezheti az SSH-ügynökök továbbítását a virtuális gépeken, így a megerősített gazdagép hitelesítő adatainak továbbításával hozzáférhet a virtuális hálózat többi virtuális gépéhez. Vagy használjon SSH-bújtatást más példányok eléréséhez.

Íme egy példa az ügynöktovábbításra:

ssh -A -t user@BASTION_SERVER_IP ssh -A root@TARGET_SERVER_IP`

Ez a parancs csatlakozik a bástyához, majd azonnal újra fut ssh , így kap egy terminált a célpéldányon. Előfordulhat, hogy a célpéldány gyökérétől eltérő felhasználót kell megadnia, ha a fürt másképpen van konfigurálva. Az -A argumentum továbbítja az ügynökkapcsolatot, így a rendszer automatikusan használja a helyi gépen lévő titkos kulcsot. Vegye figyelembe, hogy az ügynöktovábbítás egy lánc, ezért a második ssh parancs is tartalmazza -A , hogy a célpéldányból kezdeményezett további SSH-kapcsolatok a helyi titkos kulcsot is használják.

Alkalmazásréteg

Az alkalmazásszint tartalmazza a Kapcsolatok Soft alkalmazáskiszolgálók, a Kapcsolatok Soft webkiszolgálók, a rugalmas keresés és a Kapcsolatok Soft Folyamatütemező példányait. Egy Azure-terheléselosztó úgy van beállítva, hogy fogadja a felhasználóktól érkező kéréseket, amelyeket az alkalmazásszint megfelelő kiszolgálóra irányít.

A magas rendelkezésre állás érdekében fontolja meg az egyes kiszolgálók redundáns példányainak beállítását az alkalmazásszinten a különböző rendelkezésre állási zónákban. Az Azure-terheléselosztó több háttérkészlettel is beállítható, hogy az egyes kéréseket a megfelelő kiszolgálóra irányítsa.

Kapcsolatok Tools-ügyfél

A Kapcsolatok Tools-ügyfél olyan felügyeleti tevékenységek végrehajtására szolgál, mint a fejlesztés, a migrálás és a frissítés. Mivel a Kapcsolatok Tools-ügyfél nem szükséges az alkalmazás magas rendelkezésre állásának eléréséhez, a Kapcsolatok Tools-ügyfél redundáns kiszolgálóira nincs szükség.

Adatbázisszint

Az adatbázisszint tartalmazza az alkalmazás adatbázispéldányait. Az adatbázis lehet Oracle DB, Oracle RAC vagy Oracle Exadata Database rendszer.

Ha az Oracle DB használata a választás, az adatbázispéldány üzembe helyezhető az Azure-ban az Azure Marketplace-en elérhető Oracle DB-rendszerképeken keresztül. Másik lehetőségként használhatja az Azure és az OCI közötti kapcsolatot az Oracle DB paaS-modellben való üzembe helyezéséhez az OCI-n.

Az Oracle RAC-hez használhatja az OCI-t a PaaS-modellben. Javasoljuk, hogy kétcsomópontos RAC-rendszert használjon. Bár az Oracle RAC üzembe helyezhető az Azure CloudSimple-ben az IaaS-modellben, az Oracle nem támogatja ezt a konfigurációt. Tekintse meg az engedélyezett felhőkörnyezetekre jogosult Oracle-programokat.

Végül az Exadata-rendszerek esetében használja az OCI-kapcsolatot, és telepítse az Exadata rendszert az OCI-ban. A fenti architektúra előző ábrája egy OCI-ben üzembe helyezett Exadata-rendszert mutat be két alhálózaton.

Éles forgatókönyvek esetén az adatbázis több példányát helyezze üzembe két rendelkezésre állási zónában (ha az Azure-ban helyezi üzembe) vagy két rendelkezésre állási tartományt (az OCI-ben). Az Oracle Active Data Guard használatával szinkronizálhatja az elsődleges és a készenléti adatbázisokat.

Az adatbázisszint csak a középső rétegtől fogad kéréseket. Javasoljuk, hogy állítson be egy hálózati biztonsági csoportot (biztonsági listát, ha az adatbázist az OCI-ben telepíti), hogy rendszergazdai okokból csak az 1521-as porton engedélyezze a kéréseket a középső rétegből, a 22-as portot pedig a megerősített kiszolgálóról.

Az OCI-ben üzembe helyezett adatbázisokhoz külön virtuális felhőhálózatot kell beállítani egy dinamikus útválasztási átjáróval (DRG), amely a Fast Csatlakozás kapcsolatcsoporthoz csatlakozik.

Identitásszint

A Microsoft-Oracle partnerség lehetővé teszi, hogy egységes identitást állítson be az Azure-ban, az OCI-ben és az Oracle-alkalmazásban. JD Edwards EnterpriseOne vagy Kapcsolatok Soft alkalmazáscsomag esetén az Oracle HTTP Server (OHS) egy példányára van szükség az egyszeri bejelentkezés beállításához a Microsoft Entra ID és az Oracle IDCS között.

Az OHS fordított proxyként működik az alkalmazásszinthez, ami azt jelenti, hogy a végfelhasználóknak küldött összes kérés végighalad rajta. Az Oracle Access Manager WebGate egy OHS webkiszolgáló beépülő modul, amely minden, a végfelhasználóhoz érkező kérést elfog. Ha egy elérhető erőforrás védett (hitelesített munkamenetet igényel), a WebGate OIDC hitelesítési folyamatot kezdeményez az Identity Cloud Service szolgáltatással a felhasználó böngészőjén keresztül. Az OpenID Csatlakozás WebGate által támogatott folyamatokról az Oracle Access Manager dokumentációjában talál további információt.

Ezzel a beállítással a Microsoft Entra-azonosítóba már bejelentkezett felhasználók az Oracle Identity Cloud Service-en keresztül anélkül navigálhatnak a JD Edwards EnterpriseOne vagy Kapcsolatok Soft alkalmazáshoz, hogy újra bejelentkeztek. A megoldást üzembe helyező ügyfelek élvezhetik az egyszeri bejelentkezés előnyeit, beleértve egyetlen hitelesítőadat-készletet, továbbfejlesztett bejelentkezési élményt, nagyobb biztonságot és csökkentett ügyfélszolgálati költségeket.

A JD Edwards EnterpriseOne vagy Kapcsolatok Soft egyszeri bejelentkezésének Microsoft Entra-azonosítóval való beállításával kapcsolatos további információkért tekintse meg a kapcsolódó Oracle-tanulmányt.

Következő lépések

A Terraform-szkriptekkel oracle-alkalmazásokat állíthat be az Azure-ban, és felhőközi kapcsolatot létesíthet az OCI-vel.

Az OCI-vel kapcsolatos további információkért és tanulmányi információkért tekintse meg az Oracle Cloud dokumentációját.