Architekturen für Oracle-Anwendungen mit Datenbank auf Azure Virtual Machines
Dieser Artikel enthält Referenzarchitektur für die Bereitstellung von Oracle-Anwendungen auf Azure IaaS, in denen sich auch die Oracle-Datenbank befindet oder colocated ist.
Oracle-Workloads umfassen nicht nur Oracle-Datenbanken, sondern auch Oracle-Erstanbieteranwendungen wie Siebel, PeopleSoft, JD Edwards, E-Business Suite oder angepasste WebLogic-Serveranwendungen. Die Bereitstellung von Oracle-Anwendungen in Azure Infrastructure-as-a-Service (IaaS) ist ein gängiges Szenario für Organisationen, welche die Cloud für ihre Oracle-Workloads zusammen mit Oracle-Datenbank verwenden möchten. Microsoft bietet Referenzarchitekturen und bewährte Methoden, um diesen Prozess zu vereinfachen.
Allgemeine Richtlinien für die Anwendungsmigration
Da Oracle-Anwendungen sich auf Azure IaaS bewegen, gibt es häufige Designüberlegungen, die unabhängig von der Art der Anwendungen befolgt werden müssen. Einige Erwägungen sind für Anwendungen spezifisch. In diesem Abschnitt werden allgemeine Entwurfsüberlegungen aller Anwendungen aufgeführt, und alle anwendungsspezifischen Erwägungen werden in den einzelnen Abschnitten zu den Anwendungen behandelt.
Netzwerk und Sicherheit
Die bereitgestellten Netzwerkeinstellungen für Oracle-Anwendungen in Azure decken verschiedene Aspekte von Netzwerk- und Sicherheitsaspekten ab. Hier ist eine Aufschlüsselung der empfohlenen Netzwerkeinstellungen:
Einmaliges Anmelden (Single Sign-On, SSO) mit Microsoft Entra ID und SAML: Verwenden Sie Microsoft Entra ID für einmaliges Anmelden (SSO) mithilfe des SAML-Protokolls (Security Assertions Markup Language). Dieser SSO ermöglicht es Benutzern, sich einmal zu authentifizieren und nahtlos auf mehrere Dienste zuzugreifen.
Microsoft Entra-Anwendungsproxy: Erwägen Sie die Verwendung des Microsoft Entra-Anwendungsproxys, insbesondere für Remotebenutzer. Mit diesem Proxy können Sie sicher von außerhalb Ihres Netzwerks auf lokale Anwendungen zugreifen.
Routing interner Benutzer über ExpressRoute: Leiten Sie den Datenverkehr für interne Benutzer über Azure ExpressRoute für eine dedizierte private Verbindung mit Azure-Diensten weiter, um eine niedrige Latenz und sichere Kommunikation sicherzustellen.
Azure Firewall: Bei Bedarf können Sie für zusätzliche Sicherheit vor Ihrer Anwendung die Azure-Firewall konfigurieren. Azure Firewall schützt Ihre Ressourcen vor unbefugtem Zugriff und Bedrohungen.
Anwendungsgateway für externe Benutzer: Wenn externe Benutzer auf Ihre Anwendung zugreifen müssen, erwägen Sie die Verwendung des Azure-Anwendungsgateways. Es stellt Funktionen der Webanwendungsfirewall (WAF) zum Schutz Ihrer Webanwendungen und des Lastenausgleichs von Layer 7 bereit, um Datenverkehr zu verteilen.
Netzwerksicherheitsgruppen (Network Security Groups, NSG): Sichern Sie Ihre Subnetze mithilfe von Netzwerksicherheitsgruppen (NSG). Mit NSGs können Sie eingehenden und ausgehenden Datenverkehr an Netzwerkschnittstellen, virtuelle Computer und Subnetze steuern, indem Sie Sicherheitsregeln definieren.
Rollenbasierte Zugriffssteuerung (RBAC): Verwenden Sie Azure RBAC, um Zugriff auf bestimmte Personen oder Rollen zu gewähren. RBAC bietet eine differenzierte Zugriffssteuerung für Azure-Ressourcen basierend auf Rollen und Berechtigungen.
Bastion Host für SSH-Zugriff: Verwenden Sie einen Bastion-Host als Sprungfeld, um die Sicherheit für den SSH-Zugriff zu verbessern. Ein Bastion-Host fungiert als sicheres Gateway für Administratoren für den Zugriff auf virtuelle Computer im virtuellen Netzwerk. Dieser Host bietet eine zusätzliche Sicherheitsebene.
Weitere Erwägungen:
- Datenverschlüsselung: Stellen Sie sicher, dass ruhende und übertragene Daten verschlüsselt sind. Azure bietet für diesen Zweck Tools wie Azure Disk Encryption und SSL/TLS.
- Patchverwaltung: Aktualisieren und patchen Sie Ihre EBS-Umgebung regelmäßig, um vor bekannten Sicherheitsrisiken zu schützen.
- Überwachung und Protokollierung: Implementieren Sie Azure Monitor und Azure Defender für Sicherheit, um Ihre Umgebung kontinuierlich auf Sicherheitsbedrohungen und Anomalien zu überprüfen. Richten Sie die Protokollierung für die Überwachung und forensische Analyse ein.
Zusammenfassend sollen diese Netzwerk- und Sicherheitseinstellungen eine stabile und sichere Umgebung für das Hosten von Oracle-Anwendungen auf Azure IaaS bereitstellen. Sie enthalten bewährte Methoden für Authentifizierung, Zugriffssteuerung und Netzwerksicherheit sowohl für interne als auch für externe Benutzer. Sie berücksichtigen auch die Notwendigkeit des SSH-Zugriffs auf Anwendungsserver. Diese Empfehlungen können Ihnen dabei helfen, einen ausgereiften Sicherheitsstatus für Ihre Oracle-Anwendungsbereitstellung in Azure IaaS einzurichten.
Webebene: Die Webebene stellt den Lastenausgleich für die Anforderungen dar und sendet die Anforderungen entsprechend an die Anwendungsebene, die Datenbankebene und/oder die Sicherung.
Anwendungsebene: Die Anwendungsebene umfasst in der Regel Anwendungsserver und freigegebene Dateisysteme.
Für die automatische Skalierung können Skalierungssätze für virtuelle Computer eine großartige Wahl sein, um mehrere virtuelle Computer basierend auf Bedarf mit benutzerdefinierten horizontalen Skalierungsregeln an Ihre Workload anzupassen.
Arbeiten Sie mit Azure Subject Matter Experts (SMEs) zusammen, um eine gründliche Bewertung Ihrer Architektur durchzuführen. Sie können Ihnen helfen, die am besten geeigneten Azure-Dienste basierend auf Ihren spezifischen Anforderungen zu ermitteln, einschließlich Leistung, Verfügbarkeit und Skalierbarkeit. Denken Sie daran, Faktoren wie Kosten, Datensicherheit, Compliance und Notfallwiederherstellung beim Entwerfen Ihrer Architektur zu berücksichtigen.
Es ist auch wichtig, Ihre Azure-Ressourcen kontinuierlich zu überprüfen und zu optimieren, um Effizienz und Kosteneffizienz sicherzustellen.
Lastenausgleich und Durchsatz: Es ist wichtig, die Workloadmerkmale von Anwendungsservern zu bewerten. Einige Server verarbeiten mehr Aufgaben und erstellen einen höheren Durchsatz als andere. Diese Informationen sind entscheidend, wenn Sie Ihre Skalierungssätze und Lastenausgleichskonfigurationen für Virtuelle Azure-Computer entwerfen, um sicherzustellen, dass Ressourcen effektiv zugeordnet werden
Datenbankebene: HA-Architekturen werden mit Oracle Data Guard für Oracle auf Azure IaaS empfohlen. Anwendungen erfordern eine bestimmte Art von HA-Setup und werden unter jeder Anwendung aufgeführt.
Sicherung: Sicherungen werden von der Anwendungsebene und der Datenbankebene gesendet. Es ist nur einer von vielen Gründen, warum diese beiden Ebenen nicht in zwei verschiedene Anbieter aufgeteilt werden sollten. Sicherungen der Datenbank werden von Azure Backup Volume Snapshot auf Premium-Dateien in der sekundären Region ausgeführt.
Notfallwiederherstellung: Es gibt verschiedene Lösungen, aus denen Sie wählen können. Es hängt sehr stark von Ihren Anforderungen ab. Die Architektur ist so aufgebaut, dass sie hochverfügbar ist. Zum Replizieren der Anwendungsebene können Sie Azure Site Recovery verwenden. Eine andere Lösung, die Sie auswählen können, ist Redundanzoptionen für verwaltete Datenträger. Beide Lösungen replizieren Ihre Daten. Redundanzoptionen für verwaltete Datenträger sind eine Lösung, welche die Architektur vereinfachen kann, aber auch einige Einschränkungen aufweist.
Siebel auf Azure
Oracle Siebel CRM ist weiterhin eine bevorzugte CRM-Lösung auf Unternehmensniveau von vielen Unternehmen. Es ist eine der komplexesten Anwendungen in Oracles Portfolio, die eine Kombination aus transaktionsorientierten, analytischen und Engagements-Features zum Verwalten von kundenorientierten Vorgängen bietet.
Dies ist die empfohlene Architektur einer Siebel-Anwendungsbereitstellung auf Azure Virtual Machines for Innovation Pack bis Version 16:
Das folgende Diagramm ist die Architektur einer Siebel-Anwendungsbereitstellung auf Azure Virtual Machines for Innovation Pack bis Version 17:
Erwägungen zum Oracle Siebel-Design
Netzwerksicherheit: Die Netzwerkeinstellungen für Oracle Siebel in Azure, die erforderlich sind, um zusätzlich die allgemeinen Überlegungen zu Netzwerksicherheit zu beachten.
Die Migration muss mit dem Siebel-Tool-Subnetz erfolgen.
Anwendungsebene
- Ab Version 17: Konfigurationen bestimmter Server und Dienstprogramme für die Anwendung und Datenbank sind erforderlich.
Datenbankebene
- Stellen Sie sicher, dass Datenbank- und Siebel-Versionen übereinstimmen.
- Stellen Sie sicher, dass primäre und replizierte Datenbanken mithilfe der Oracle-Referenzarchitektur von Oracle Data Guard in eine sekundäre Datenbank kopiert werden.
E-Business-Suite in Azure
Bei Oracle E-Business Suite (EBS) handelt es sich um eine Suite mit Anwendungen, z. B. für Lieferkettenverwaltung (Supply Chain Management, SCM) und Customer Relationship Management (CRM). Da EBS ein SCM- und CRM-System ist, verfügt es in der Regel über viele Schnittstellen zu Drittanbietersystemen. Die folgende Architektur ist so aufgebaut, dass sie innerhalb einer Region hochverfügbar ist.
Es wird davon ausgegangen, dass externe Benutzer das Unternehmensnetzwerk nicht im folgenden Diagramm überschreiten.
Überlegungen zur Entwicklung von Oracle EBS
Datenbankebene: Primäre und sekundäre Datenbank sollten sich innerhalb desselben Rechenzentrums befinden. Verwenden Sie die synchrone Konfiguration. Wenn Sie Ihre Anwendung rechenzentrenübergreifend installieren, sollten Sie Data Guard im asynchronen Modus konfigurieren.
JD Edwards auf Azure
JD Edwards EnterpriseOne von Oracle ist eine integrierte Suite mit Anwendungen für umfassendes Enterprise Resource Planning (ERP). Aktuell wird JD Edwards in Lieferkette, Lagerverwaltung, Logistik, Fertigungsressourcenplanung und mehr verwendet. Aufgrund der Verwendung der Anwendung stellen wir fest, dass Schnittstellen zu anderen Systemen ebenfalls wichtig sind.
Die folgende Architektur ist darauf ausgelegt, hochverfügbar zu sein. Es wird davon ausgegangen, dass externe Benutzer nicht über das Unternehmensnetzwerk zugreifen. Wenn ein externer Benutzer über das Unternehmensnetzwerk auf die Anwendung zugreift, kann die Architektur wie folgt in Netzwerken vereinfacht werden.
Überlegungen zum Entwurf von JD Edwards
Webebene: Die Anwendungswebebene besteht in der Regel aus mehreren Anwendungsservern. In JD Edwards werden Regeln häufig auf diesen Anwendungswebservern gespeichert.
Präsentationsebene: Jede Instanz in der Präsentationsebene ist dem Speicher zugeordnet. Das Entfernen von Abhängigkeiten zwischen Instanzen kann zu hohen Latenzen führen, daher ist es wichtig, sie sorgfältig zu prüfen.
Serverleistungsvariation: Einige Server können mehr Aufgaben verarbeiten und einen höheren Durchsatz erstellen als andere. Während der Entwurfsphase ist es wichtig, diese Durchsatzvariation einzukalkulieren, um sicherzustellen, dass Ihre Infrastruktur Spitzenlasten effizient verarbeiten kann.
Rückbau: Die Verwendung von Skalierungssätzen für virtuelle Azure-Computer für die automatische Skalierung erfordert keine Neukonfiguration Ihres JD Edwards-Setups. Es ist eine skalierbare Lösung, die ohne erhebliche Änderungen an der Architektur Ihrer Anwendung implementiert werden kann.
Datenbankebene: Primärer und sekundärer Aufenthalt innerhalb eines Rechenzentrums und die synchrone Konfiguration sollte verwendet werden. Wenn Sie Ihre Anwendung rechenzentrenübergreifend installieren, sollten Sie Data Guard im asynchronen Modus konfigurieren. Daten aus der Datenbankebene werden direkt an einen Azure Storage gesendet. Der Speicher hängt von Ihrem aktuellen Architektursetup ab.
PeopleSoft auf Azure
Die PeopleSoft-Anwendungssuite von Oracle enthält Software für das Personalwesen und das Finanzmanagement. Die Anwendungssuite hat mehrere Ebenen und verfügt über Anwendungen für unter anderem die Bereiche Personalwesensmanagement (HRMS), Kundenbeziehungsmanagement (CRM), Finanzen und Lieferkettenverwaltung (FSCM) und Enterprise-Leistungsverwaltung (EPM).
Überlegungen zum Design von PeopleSoft
Anwendungsebene: Die Anwendungsebene enthält mehrere Aufgaben und Server. Sie führt die Geschäftslogik und -prozesse aus, verwaltet aber auch die Verbindung mit der Datenbank. Sobald diese Abhängigkeit entfernt wird, verursacht sie Latenzen.
Abhängigkeit zwischen Anwendungs- und Datenbankebenen: Es ist wichtig, die Latenz zwischen der Anwendung und den Datenbankebenen zu minimieren. Indem Sie die Anwendung und die Datenbankebene in demselben Cloudanbieter (in diesem Fall Azure) platzieren, verringern Sie die Netzwerklatenz. Azure bietet verschiedene Netzwerkoptionen und Dienste wie VNet-Peering oder ExpressRoute, um Verbindungen mit geringer Latenz zwischen Ebenen sicherzustellen.
Erwägungen zum Betriebssystem: Wenn der Prozessplaner speziell Windows-Betriebssysteme erfordert, können Sie es weiterhin auf virtuellen Azure-Computern ausführen. Azure unterstützt verschiedene Windows Server-Versionen, sodass Sie auswählen können, welche die Anforderungen Ihrer Anwendung erfüllt.
Architekturbewertung: Bewerten Sie Ihre Architekturanforderungen sorgfältig, einschließlich Skalierbarkeit, Verfügbarkeit und Leistung. Erwägen Sie das Einrichten mehrerer Anwendungsserverinstanzen in einer Konfiguration mit Lastenausgleich, um Hochverfügbarkeit und Skalierbarkeit sicherzustellen.
Datenbankebene: Die primäre und die zur sekundären replizierte Ebene sollte innerhalb desselben Rechenzentrums verbleiben. Verwenden Sie die synchrone Konfiguration. Wenn Sie Ihre Anwendung rechenzentrenübergreifend installieren, sollten Sie Data Guard im asynchronen Modus konfigurieren.
Nächste Schritte