IBM Sterling Order Management-Software in einem Oracle Cloud Infrastructure Kubernetes Engine-Cluster bereitstellen
Die IBM Sterling Order Management Software ist eine Omnichannel-Software zur Auftragsabwicklung. Ab Softwareversion 10.0 ist die Software auf IBM-zertifizierten Containern verfügbar. IBM-zertifizierte Container werden mit der containerisierten IBM Sterling Order Management-Software verpackt und für das Cloud-Deployment validiert, sodass Kunden die Container in jeder öffentlichen oder privaten Cloud, einschließlich Oracle Cloud Infrastructure (OCI), mit Oracle Cloud Infrastructure Kubernetes Engine-(OCI Kubernetes Engine- oder OKE-)Clustern bereitstellen können.
Diese Referenzarchitektur bietet einen Überblick über die Bereitstellung der IBM Sterling Order Management-Software in einem OKE-Cluster. OKE stellt ein hochverfügbares und skalierbares, produktionsfähiges Kubernetes-Cluster für die Bereitstellung containerisierter Anwendungen in der Cloud bereit. Durch die Bereitstellung der IBM Sterling Order Management-Software in einem OKE-Cluster kann die Anwendung problemlos in andere OCI-verwaltete Services integriert werden, um die Bereitstellung weiter zu vereinfachen.
Architektur
IBM Sterling Order Management Software erfordert eine Datenbank und einen Java Message Service-(JMS-)Server als Voraussetzungen für die Bereitstellung der Anwendung. Darüber hinaus muss der für IBM Sterling Order Management Software zertifizierte Container angepasst werden, um die ausgewählte Datenbank und JMS für das Deployment zu verwenden.
- IBM Db2-Datenbank V11.x oder höher ODER Oracle-Datenbank v19c
- IBM MQ JMS-Server V9.x oder höher ODER WebLogic JMS
- IBM Sterling Order Management Software zertifizierte Container V10
Das folgende Diagramm veranschaulicht diese Referenzarchitektur.
oci-oke-ibm-sterling-arch-oracle.zip
In dieser Referenzarchitektur stellt der Oracle Autonomous Database-Service die Anwendungsdatenbank der IBM Sterling Order Management Software bereit. Oracle Autonomous Database ist eine vollständig verwaltete, vorkonfigurierte Datenbankumgebung mit vier verfügbaren Workload-Typen: Oracle Autonomous Transaction Processing,Oracle Autonomous Data Warehouse Oracle APEX Application Development und Oracle Autonomous JSON Database. Für dieses Deployment wird Autonomous Transaction Processing mit der Oracle-Datenbankversion v19c verwendet.
Für den JMS-Server wird IBM MQ Messaging Server mit der IBM Sterling Order Management Software in einem OKE-Cluster bereitgestellt. IBM-zertifizierte Images und Helm-Charts sind für die Bereitstellung des IBM MQ-Servers verfügbar. Der IBM MQ-Server muss mit dem Warteschlangenmanager und den erforderlichen Warteschlangen für die IBM Sterling Order Management Software konfiguriert sein.
- File Storage
Die Anwendungs- und Agent-Services erfordern persistente NFS-Shares, um gemeinsam verwendete Daten (Suchindex, CDT-Import oder -Export) zu speichern, die von den Anwendungsserver- und Agent-Servercontainern verwendet werden. Für den IBM MQ-Service ist außerdem netzwerkgebundener Speicher zum Speichern von MQ-Konfigurationsdaten und -nachrichten erforderlich. Der OCI File Storage-Service wird bereitgestellt, um den Anwendungen, Agents und IBM MQ-Services ein persistentes Volume bereitzustellen.
- Container Registry
Die Containerimages für diese Lösung müssen in einem Repository gespeichert werden, auf das über das OKE-Cluster zugegriffen werden kann. OCI Container Registry wird zum Speichern der Images verwendet. OCI Container Registry kann auch als Helm-Repository verwendet werden, wenn Kunden über eigene Helm-Diagramme verfügen. Das OKE-Cluster stellt über ein Servicegateway eine Verbindung zur OCI Container Registry her, sodass der Traffic nicht das Internet durchläuft.
- API Gateway
Das API Gateway stellt Benutzern den IBM Sterling Order Management Software-Endpunkt zur Verfügung. Es bietet Authentifizierung und Autorisierung für Benutzer, die auf die IBM Sterling Order Management Software-Anwendung zugreifen.
- Load Balancer
Der Load Balancer bietet Zugriff auf den Ingress-Controller im OKE-Cluster. Der Ingress leitet den Datenverkehr an angeforderte Services von Benutzern der IBM Sterling Order Management Software-Anwendung weiter.
- Certificate Authority
Der Certificate Authority-Service verwaltet die TLS-Zertifikate für den öffentlichen Endpunkt der IBM Sterling Order Management Software.
- Key Management
Der Key Management-Service verwaltet die Schlüssel, die vom Certificate Authority-Service verwendet werden.
Die Architektur umfasst die folgenden Komponenten:
- Region
Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Center enthält, das als Availability-Domain bezeichnet wird. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie trennen (über Länder oder sogar Kontinente).
- Availability-Domains
Availability-Domains sind eigenständige, unabhängige Data Center innerhalb einer Region. Die physischen Ressourcen in jeder Availability-Domain sind von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz sicherstellt. Availability-Domains haben keine gemeinsame Infrastruktur wie Stromversorgung oder Kühlung oder das interne Availability-Domainnetzwerk. Daher sollte ein Fehler in einer Availability-Domain sich nicht auf die anderen Availability-Domains in der Region auswirken.
- Faultdomains
Eine Faultdomain ist eine Gruppierung aus Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain umfasst drei Faultdomains mit unabhängiger Stromversorgung und Hardware. Wenn Sie Ressourcen auf mehrere Faultdomains verteilen, können Ihre Anwendungen physische Serverausfälle, Systemwartungen und Stromausfälle innerhalb einer Faultdomain tolerieren.
- Virtuelles Cloud-Netzwerk (VCN) und Subnetze
Ein VCN ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten können. Wie herkömmliche Data Center-Netzwerke erhalten Sie mit VCNs die Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere sich nicht überschneidende CIDR-Blöcke aufweisen, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die sich auf eine Region oder eine Availability-Domain beschränken. Jedes Subnetz besteht aus einem Bereich zusammenhängender Adressen, die sich nicht mit anderen Subnetzen im VCN überschneiden. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.
- Kubernetes Engine
Oracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes Engine oder OKE) ist ein vollständig verwalteter, skalierbarer und hoch verfügbarer Service, mit dem Sie Ihre Containeranwendungen in der Cloud bereitstellen können. Sie geben die Compute-Ressourcen an, die Ihre Anwendungen benötigen, und Kubernetes Engine stellt sie in Oracle Cloud Infrastructure in einem vorhandenen Mandanten bereit. OKE automatisiert mit Kubernetes das Deployment, die Skalierung und die Verwaltung containerisierter Anwendungen über Cluster von Hosts hinweg.
- Autonomous Database
Oracle Autonomous Database ist eine vollständig verwaltete, vorkonfigurierte Datenbankumgebung, die Sie für Transaktionsverarbeitungs- und Data Warehousing-Workloads verwenden können. Sie müssen keine Hardware konfigurieren oder verwalten oder Software installieren. Mit Oracle Cloud Infrastructure können Sie die Datenbank erstellen, sichern, patchen, aktualisieren und optimieren.
- Network Address Translation-(NAT-)Gateway
Ein NAT-Gateway ermöglicht privaten Ressourcen in einem VCN den Zugriff auf Hosts im Internet, ohne dass diese Ressourcen für eingehende Internetverbindungen freigegeben werden.
- Routentabelle
Virtuelle Routentabellen enthalten Regeln zum Weiterleiten von Traffic von Subnetzen an Ziele außerhalb eines VCN, in der Regel über Gateways.
- Sicherheitsliste
Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die Quelle, Ziel und Typ des Traffics angeben, der im Subnetz und aus dem Subnetz zugelassen werden muss.
Empfehlungen
- VCN
Wenn Sie ein VCN erstellen, bestimmen Sie die Anzahl der erforderlichen CIDR-Blöcke und die Größe jedes Blocks basierend auf der Anzahl der Ressourcen, die Sie an Subnetze im VCN anhängen möchten. Verwenden Sie CIDR-Blöcke, die sich innerhalb des privaten IP-Standardadressraums befinden.
Wählen Sie CIDR-Blöcke aus, die sich nicht mit einem anderen Netzwerk (in Oracle Cloud Infrastructure, Ihrem On-Premise-Data Center oder einem anderen Cloud-Provider) überschneiden, zu dem Sie private Verbindungen einrichten möchten.
Nachdem Sie ein VCN erstellt haben, können Sie die CIDR-Blöcke ändern, hinzufügen und entfernen.
Berücksichtigen Sie beim Entwerfen der Subnetze Ihren Trafficfluss und Ihre Sicherheitsanforderungen. Hängen Sie alle Ressourcen innerhalb einer bestimmten Ebene oder Rolle an dasselbe Subnetz an, das als Sicherheitsgrenze dienen kann.
- Load-Balancer-Bandbreite
Beim Erstellen des Load Balancers können Sie entweder eine vordefinierte Ausprägung auswählen, die eine feste Bandbreite bereitstellt, oder eine benutzerdefinierte (flexible) Ausprägung angeben, in der Sie einen Bandbreitenbereich festlegen und den Service die Bandbreite automatisch basierend auf Trafficmustern skalieren lassen. Bei beiden Verfahren können Sie die Ausprägung nach dem Erstellen des Load Balancers jederzeit ändern.
- Sicherheitslisten
Mit Sicherheitslisten können Sie Ingress- und Egress-Regeln definieren, die für das gesamte Subnetz gelten.
- Version der autonomen Datenbank
Verwenden Sie die neueste verfügbare Version für Autonomous Database.
Hinweise
Berücksichtigen Sie bei der Bereitstellung von IBM Sterling Order Management Software in einem OKE-Cluster Folgendes hinsichtlich Skalierbarkeit und Verfügbarkeit:
- Anwendungsverfügbarkeit
Die IBM Sterling Order Management Software-Anwendung wird mit mehreren Pods im Deployment bereitgestellt, um eine hohe Verfügbarkeit zu gewährleisten.
Faultdomains bieten die beste Resilienz innerhalb einer Availability-Domain. Wenn Sie eine höhere Verfügbarkeit benötigen, sollten Sie nach Möglichkeit mehrere Availability-Domains oder mehrere Regionen verwenden.
- Skalierbarkeit
Sie können die Anzahl der CPU-Cores der Datenbank jederzeit manuell vertikal oder horizontal skalieren. Mit dem Autoscaling-Feature von Autonomous Database kann Ihre Datenbank jederzeit die bis zu dreifache aktuelle Basisanzahl von CPU-Cores verwenden. Wenn der Bedarf steigt, erhöht das automatische Skalieren automatisch die Anzahl der verwendeten Cores. Mit Autonomous Database können Sie die Speicherkapazität jederzeit skalieren, ohne dass sich dies auf Verfügbarkeit oder Performance auswirkt.