Delen via


Architecturen voor Oracle-toepassingen met database op Azure Virtual Machines

Dit artikel bevat referentiearchitectuur voor het implementeren van de Oracle-toepassing op Azure IaaS waar de Oracle-database zich ook bevindt of zich op een locatie bevindt.

Oracle-workloads bestaan niet alleen uit Oracle-databases, maar ook uit Eigen Oracle-toepassingen zoals Siebel, PeopleSoft, JD Edwards, E-Business Suite of aangepaste WebLogic-servertoepassingen. Het implementeren van Oracle-toepassingen op Azure Infrastructure as a Service (IaaS) is een veelvoorkomend scenario voor organisaties die de cloud willen gebruiken voor hun Oracle-workloads, samen met de Oracle-database. Microsoft biedt referentiearchitecturen en aanbevolen procedures om dit proces te vereenvoudigen.

Algemene richtlijnen voor toepassingsmigratie

Naarmate Oracle-toepassingen overstappen op Azure IaaS, zijn er algemene ontwerpoverwegingen die moeten worden gevolgd, ongeacht het type toepassingen. Enkele overwegingen zijn specifiek voor toepassingen. In deze sectie vermelden we algemene ontwerpoverwegingen van alle toepassingen en eventuele toepassingsspecifieke overwegingen worden in elke toepassing behandeld.

Netwerk en beveiliging

De opgegeven netwerkinstellingen voor Oracle-toepassingen in Azure hebben betrekking op verschillende aspecten van netwerk- en beveiligingsoverwegingen. Hier volgt een uitsplitsing van de aanbevolen netwerkinstellingen:

  • Eenmalige aanmelding (SSO) met Microsoft Entra ID en SAML: Gebruik Microsoft Entra ID voor eenmalige aanmelding (SSO) met behulp van het SAML-protocol (Security Assertions Markup Language). Met deze eenmalige aanmelding kunnen gebruikers zich eenmaal verifiëren en meerdere services naadloos openen.

  • Microsoft Entra-toepassingsproxy: Overweeg microsoft Entra-toepassingsproxy te gebruiken, met name voor externe gebruikers. Met deze proxy kunt u veilig toegang krijgen tot on-premises toepassingen buiten uw netwerk.

  • Interne gebruikers routeren via ExpressRoute: voor interne gebruikers routeert u verkeer via Azure ExpressRoute voor een toegewezen, privéverbinding met Azure-services, zodat communicatie met lage latentie en veilige communicatie wordt gegarandeerd.

  • Azure Firewall: Indien nodig kunt u Azure Firewall configureren vóór uw toepassing voor extra beveiliging. Azure Firewall helpt uw resources te beschermen tegen onbevoegde toegang en bedreigingen.

  • Application Gateway voor externe gebruikers: wanneer externe gebruikers toegang nodig hebben tot uw toepassing, kunt u overwegen Azure-toepassing Gateway te gebruiken. Het biedt WAF-mogelijkheden (Web Application Firewall) voor het beveiligen van uw webtoepassingen en Laag 7-taakverdeling om verkeer te distribueren.

  • Netwerkbeveiligingsgroepen (NSG): Beveilig uw subnetten met behulp van netwerkbeveiligingsgroepen (NSG).a0> Met NSG's kunt u inkomend en uitgaand verkeer naar netwerkinterfaces, virtuele machines en subnetten beheren door beveiligingsregels te definiëren.

  • Op rollen gebaseerd toegangsbeheer (RBAC): Als u toegang wilt verlenen aan specifieke personen of rollen, gebruikt u Op rollen gebaseerd toegangsbeheer (RBAC) van Azure. RBAC biedt gedetailleerd toegangsbeheer voor Azure-resources op basis van rollen en machtigingen.

  • Bastion-host voor SSH-toegang: gebruik een Bastion-host als jumpbox om de beveiliging voor SSH-toegang te verbeteren. Een Bastion-host fungeert als een beveiligde gateway voor beheerders voor toegang tot virtuele machines in het virtuele netwerk. Deze host biedt een extra beveiligingslaag.

  • Meer overwegingen:

    • Gegevensversleuteling: zorg ervoor dat data-at-rest en in transit zijn versleuteld. Azure biedt hulpprogramma's zoals Azure Disk Encryption en SSL/TLS voor dit doel.
    • Patchbeheer: werk uw EBS-omgeving regelmatig bij en patch deze om te beschermen tegen bekende beveiligingsproblemen.
    • Bewaking en logboekregistratie: Implementeer Azure Monitor en Azure Defender voor beveiliging om uw omgeving continu te controleren op beveiligingsrisico's en afwijkingen. Logboekregistratie instellen voor controle en forensische analyse.
  • Kortom, deze netwerk- en beveiligingsinstellingen zijn bedoeld om een robuuste en veilige omgeving te bieden voor het hosten van Oracle-toepassingen op Azure IaaS. Ze bevatten aanbevolen procedures voor verificatie, toegangsbeheer en netwerkbeveiliging, zowel voor interne als externe gebruikers. Ze overwegen ook de noodzaak van SSH-toegang tot toepassingsservers. Deze aanbevelingen kunnen u helpen bij het instellen van een volwassen beveiligingspostuur voor uw Implementatie van Oracle-toepassingen op Azure IaaS.

Weblaag: de load balancer van de weblaag zorgt voor de taakverdeling van de aanvragen en verzendt de aanvragen dienovereenkomstig naar de toepassingslaag, databaselaag en/of back-up.

Toepassingslaag: De toepassingslaag omvat doorgaans toepassingsservers en gedeelde bestandssystemen.

Voor automatisch schalen kunnen virtuele-machineschaalsets een uitstekende keuze zijn voor het uitschalen van meerdere virtuele machines op basis van vraag met aangepaste schaalregels om zich aan uw workload aan te passen.

Werk samen met Azure Subject Matter Experts (KMO's) om een grondige evaluatie van uw architectuur uit te voeren. Ze kunnen u helpen bij het bepalen van de meest geschikte Azure-services op basis van uw specifieke vereisten, waaronder prestaties, beschikbaarheid en schaalbaarheid. Vergeet niet om rekening te houden met factoren zoals kosten, gegevensbeveiliging, naleving en herstel na noodgevallen bij het ontwerpen van uw architectuur.

Het is ook essentieel om uw Azure-resources continu te controleren en te optimaliseren om efficiëntie en kosteneffectiviteit te garanderen.

Taakverdeling en doorvoer: het is belangrijk dat u de workloadkenmerken van toepassingsservers evalueert. Sommige servers verwerken meer taken en maken hogere doorvoer dan andere. Deze informatie is van cruciaal belang bij het ontwerpen van uw virtuele-machineschaalsets en taakverdelingsconfiguratie van Azure om ervoor te zorgen dat resources effectief worden toegewezen

Databaselaag: HA-architecturen worden aanbevolen met Oracle Data Guard voor Oracle op Azure IaaS. Toepassingen vereisen een specifiek type ha-installatie en worden vermeld onder elke toepassing.

Back-up: back-ups worden verzonden vanuit de toepassingslaag en de databaselaag. Het is slechts een van de vele redenen waarom deze twee lagen niet in twee verschillende leveranciers moeten worden gescheiden. Back-ups van de database worden uitgevoerd door Azure Backup Volume Snapshot op Premium Files naar de secundaire regio.

Herstel na noodgevallen: er zijn verschillende oplossingen waaruit u kunt kiezen. Het hangt erg af van uw behoeften. De architectuur is gebouwd om maximaal beschikbaar te zijn. Voor het repliceren van de toepassingslaag kunt u Azure Site Recovery gebruiken. Een andere oplossing die u kunt kiezen, is redundantieopties voor beheerde schijven. Beide oplossingen repliceren uw gegevens. Redundantieopties voor beheerde schijven zijn een oplossing die de architectuur kan vereenvoudigen, maar ook een paar beperkingen heeft.

Siebel in Azure

Oracle Siebel CRM blijft een favoriete CRM-oplossing op ondernemingsniveau voor veel ondernemingen. Het is een van de meest complexe toepassingen in de Oracle-portfolio die een combinatie van transactionele, analytische en afsprakenfuncties biedt voor het beheren van klantgerichte bewerkingen.

Hier volgt de aanbevolen architectuur van een Siebel-toepassingsimplementatie in Azure Virtual Machines for Innovation Pack 16 en eerder:

Diagram met de aanbevolen architectuur van een Siebel-toepassingsimplementatie in Azure Virtual Machines for Innovation Pack 16 en eerder.

Het volgende diagram is architectuur van een Siebel-toepassingsimplementatie op Azure Virtual Machines for Innovation Pack 17 en eerder:

Diagram met de aanbevolen architectuur van een Siebel-toepassingsimplementatie op Azure Virtual Machines for Innovation Pack 17 en eerder.

Ontwerpoverwegingen voor Oracle Siebel

  • Netwerk & beveiliging: de netwerkinstellingen voor Oracle Siebel in Azure zijn vereist om de algemene overwegingen voor netwerk en beveiliging te volgen.

  • Migratie moet worden uitgevoerd met behulp van het subnet Siebel Tool.

Toepassingslaag

  • Versie 17 of hoger: configuraties van bepaalde server en hulpprogramma's in de toepassing en database zijn vereist.

Databaselaag

  • Zorg ervoor dat database- en Siebel-versie overeenkomen.
  • Primair en gerepliceerd naar een secundaire met behulp van op Data Guard gebaseerde aanbevolen Oracle-referentiearchitectuur.

E-Business Suite in Azure

Oracle E-Business Suite (EBS) is een reeks toepassingen, waaronder Supply Chain Management (SCM) en Customer Relationship Management (CRM). Omdat EBS een SCM- en CRM-systeem is, heeft het meestal veel interfaces met systemen van derden. De onderstaande architectuur is gebouwd om maximaal beschikbaar te zijn binnen één regio.

We gaan ervan uit dat externe gebruikers het bedrijfsnetwerk niet kruisen in het volgende diagram.

Diagram met een on-premises netwerk waarin externe gebruikers zich niet in het bedrijfsnetwerk bevinden.

Ontwerpoverwegingen voor Oracle EBS

Databaselaag - Primaire en secundaire database moet zich binnen één datacenter bevinden. De synchrone configuratie moet worden gebruikt. Als u uw toepassing in datacenters installeert, moet u Data Guard configureren in de Asynchrone modus.

JD Edwards in Azure

De JD Edwards van Oracle is een geïntegreerde suite met uitgebreide software voor bedrijfsresourceplanning. We hebben JDE gezien die wordt gebruikt in supply chain, magazijnbeheer, logistiek, productieresourceplanning en meer. Vanwege het gebruik van de toepassing zien we dat interfaces met andere systemen ook belangrijk zijn.

De volgende architectuur is gebouwd om maximaal beschikbaar te zijn. We hebben ervan uitgegaan dat externe gebruikers geen toegang hebben via het bedrijfsnetwerk. Als een externe gebruiker toegang heeft tot de toepassing met behulp van het bedrijfsnetwerk, kan de architectuur als volgt worden vereenvoudigd op netwerken. Diagram met on-premises netwerk en externe gebruikers.

Ontwerpoverwegingen voor JD Edwards

Weblaag: De weblaag van de toepassing bestaat doorgaans uit meerdere toepassingsservers. In JD Edwards worden regels vaak opgeslagen op deze webservers van toepassingen.

  • Presentatielaag: elk exemplaar in de presentatielaag is gekoppeld aan opslag. Het knippen van afhankelijkheden tussen exemplaren kan leiden tot hoge latenties, dus het is van cruciaal belang om ze zorgvuldig te beoordelen.

  • Serverprestatievariatie: sommige servers kunnen meer taken verwerken en hogere doorvoer maken dan andere. Tijdens de ontwerpfase is het essentieel om deze doorvoervariatie te evalueren om ervoor te zorgen dat uw infrastructuur piekworkloads efficiënt kan verwerken.

  • Opnieuw ontwerpen: Voor het gebruik van virtuele-machineschaalsets van Azure voor automatisch schalen is geen herarchitecture van uw JD Edwards-installatie vereist. Het is een schaalbare oplossing die kan worden geïmplementeerd zonder belangrijke wijzigingen in de architectuur van uw toepassing.

Databaselaag: primair en secundair blijven binnen één datacenter. De synchrone configuratie moet worden gebruikt. Als u uw toepassing in datacenters installeert, moet u Data Guard configureren in de Asynchrone modus. Gegevens uit de databaselaag worden rechtstreeks naar een Azure Storage verzonden. De opslag is afhankelijk van de huidige architectuurconfiguratie.

PeopleSoft in Azure

De PeopleSoft-toepassingssuite van Oracle bevat software voor human resources en financieel beheer. De toepassingssuite is meerdere lagen en de toepassingen omvatten HRMS (Human Resource Management Systems), Customer Relationship Management (CRM), financials en supply chain management (FSCM) en EPM (Enterprise Performance Management).

Diagram met on-premises netwerk en interne gebruikers met expressroute.

Overwegingen voor PeopleSoft-ontwerp

Toepassingslaag: De toepassingslaag bevat verschillende taken en servers. Hiermee worden de bedrijfslogica en -processen uitgevoerd, maar blijft ook de verbinding met de database behouden. Zodra deze afhankelijkheid is geknipt, veroorzaakt dit latenties.

  • Afhankelijkheid tussen toepassings- en databaselagen: het is belangrijk om de latentie tussen de toepassings- en databaselagen te minimaliseren. Door de toepassing en databaselaag in dezelfde cloudprovider (Azure in dit geval) te plaatsen, vermindert u de netwerklatentie. Azure biedt verschillende netwerkopties en services zoals VNet-peering (Virtual Network) of ExpressRoute om verbindingen met lage latentie tussen lagen te garanderen.

  • Overwegingen voor het besturingssysteem: als de procesplanner specifiek Windows-besturingssystemen vereist, kunt u deze nog steeds uitvoeren op Azure Virtual Machines. ondersteuning voor Azure verschillende Windows Server-versies, zodat u de versie kunt kiezen die voldoet aan de vereisten van uw toepassing.

  • Architectuurevaluatie: evalueer uw architectuurvereisten zorgvuldig, inclusief schaalbaarheid, beschikbaarheid en prestaties. Overweeg om meerdere toepassingsserverexemplaren in een configuratie met gelijke taakverdeling in te stellen om hoge beschikbaarheid en schaalbaarheid te garanderen.

Databaselaag: de primaire en gerepliceerde naar een secundaire moeten binnen één datacenter blijven, de synchrone configuratie moet worden gebruikt. Als u uw toepassing in datacenters installeert, moet u Data Guard configureren in de Asynchrone modus.

Volgende stappen 

Referentiearchitecturen voor Oracle Database

Oracle-workload migreren naar virtuele Azure-machines