Informationen zum Deployment von Oracle Siebel CRM auf Oracle Cloud Infrastructure

Wenn Sie Oracle Siebel CRM 19.x und höher auf Oracle Cloud Infrastructure bereitstellen oder Siebel CRM-Umgebungen von Ihrem Data Center zu Oracle Cloud Infrastructure migrieren möchten, können Sie eine Multihost-, sichere und hochverfügbare Topologie für Entwicklungsumgebungen und Testumgebungen planen.

Überlegungen zum Deployment auf Oracle Cloud Infrastructure

Oracle empfiehlt, separate Subnetze für Ihre Instanzen wie Bastionhost-, Datenbank-, Anwendungs- und Load-Balancer-Instanzen zu erstellen, um sicherzustellen, dass die entsprechenden Sicherheitsanforderungen in den verschiedenen Subnetzen implementiert werden können.

Private oder öffentliche Subnetze

Sie können Instanzen in einem privaten oder öffentlichen Subnetz erstellen, je nachdem, ob Sie den Zugriff auf die Instanzen über das Internet zulassen möchten. Instanzen, die Sie in einem öffentlichen Subnetz erstellen, wird eine öffentliche IP-Adresse zugewiesen, und Sie können über das Internet auf diese Instanzen zugreifen. Sie können Instanzen, die in einem privaten Subnetz erstellt wurden, keine öffentliche IP-Adresse zuweisen. Daher können Sie nicht über das Internet auf diese Instanzen zugreifen.

Die folgende Abbildung zeigt ein virtuelles Cloud-Netzwerk (VCN) mit öffentlichen und privaten Subnetzen. Das VCN enthält zwei Availability-Domains, und jede Availability-Domain enthält ein öffentliches und privates Subnetz. Die Webserver werden in diesem Image im öffentlichen Subnetz platziert, sodass jeder Webserverinstanz eine öffentliche IP-Adresse zugeordnet ist. Sie können über das Internet auf diese Oracle Cloud-Instanzen im öffentlichen Subnetz zugreifen, indem Sie die Kommunikation über das Internetgateway (IGW) aktivieren. Sie müssen die Routentabelle aktualisieren, um Traffic zum und vom IGW zu ermöglichen. Um Traffic zu den Webservern aus dem Internet zuzulassen, müssen Sie Load Balancer im öffentlichen Subnetz erstellen. Um über das Internet auf Ihre Instanzen zuzugreifen, müssen Sie auch einen Bastionhost im öffentlichen Subnetz erstellen und von IGW auf den Bastionhost zugreifen.

Die Datenbankserver werden in diesem Image im privaten Subnetz platziert. Sie können von Ihren Data Centern aus über das dynamische Routinggateway (DRG) auf Oracle Cloud-Instanzen im privaten Subnetz zugreifen. Das DRG verbindet Ihre On-Premise-Netzwerke mit Ihrem Cloud-Netzwerk. Um die Kommunikation zwischen dem DRG und den On-Premise-Geräten des Kunden zu ermöglichen, verwenden Sie das IPSec-VPN oder Oracle Cloud Infrastructure FastConnect. Außerdem müssen Sie die Routentabelle aktualisieren, um Traffic zum und vom DRG zu ermöglichen.

Beschreibung der Abbildung public_private_subnets_jde.png

public_private_subnets_jde.zip

Szenario 1: Alle Instanzen in privaten Subnetzen bereitstellen

Oracle empfiehlt, alle Instanzen in privaten Subnetzen für Produktionsumgebungen bereitzustellen, in denen keine internetseitigen Endpunkte vorhanden sind. Diese Art der Bereitstellung ist nützlich, wenn Sie eine hybride Bereitstellung mit der Cloud als Erweiterung für Ihre vorhandenen Data Center wünschen.

In diesem Deployment werden alle Instanzen, einschließlich Anwendungs- und Datenbankserver, in einem privaten Subnetz bereitgestellt. Eine öffentliche IP-Adresse kann Instanzen, die in einem privaten Subnetz erstellt wurden, nicht zugewiesen werden. Daher können Sie nicht über das Internet auf diese Instanzen zugreifen. Um in dieser Konfiguration von Ihrer On-Premise-Umgebung auf Ihre Anwendungsserver zuzugreifen, können Sie:

• Konfigurieren Sie einen IPSec-VPN-Tunnel zwischen Ihrem Data Center und dem Oracle Cloud Infrastructure-DRG, bevor Sie die Anwendungsserver bereitstellen.

• Erstellen Sie in dieser Konfiguration einen Bastionhost, und greifen Sie dann vom Bastionhost aus auf alle Server im privaten Subnetz zu.

Szenario 2: Instanzen in öffentlichen und privaten Subnetzen bereitstellen

Sie können einige Instanzen in einem öffentlichen Subnetz und einige Instanzen in einem privaten Subnetz bereitstellen. Diese Art des Deployments ist nützlich, wenn das Deployment internet- und nicht-internet-orientierte Endpunkte enthält.

In dieser Konfiguration werden einige Anwendungsinstanzen in einem öffentlichen Subnetz abgelegt, andere in einem privaten Subnetz. Beispiel: Anwendungsinstanzen dienen internen Benutzern und eine weitere Gruppe von Anwendungsinstanzen, die externe Benutzer bedienen. Platzieren Sie in diesem Szenario die Anwendungsinstanzen, die internen Traffic verarbeiten, in einem privaten Subnetz, und platzieren Sie die Anwendungsserver, die externen Traffic verarbeiten, in einem öffentlichen Subnetz. Sie können auch einen öffentlichen Load Balancer auf den internetseitigen Anwendungsinstanzen einrichten, anstatt die Anwendungsserver, die externen Traffic verarbeiten, in einem öffentlichen Subnetz zu platzieren. Wenn Sie den Bastionhost in einem öffentlichen Subnetz platzieren, wird dem Bastionhost eine öffentliche IP-Adresse zugewiesen, und Sie können über das Internet darauf zugreifen. Sie können über den Bastionserver auf Ihre Instanzen im privaten Subnetz zugreifen.

Szenario 3: Alle Instanzen in öffentlichen Subnetzen bereitstellen

Oracle empfiehlt dieses Deployment für schnelle Demos oder für Produktions-Deployments ohne interne Endpunkte. Dieses Deployment ist nur geeignet, wenn Sie kein eigenes Data Center haben oder nicht über VPN auf Instanzen zugreifen können und über das Internet auf die Infrastruktur zugreifen möchten.

In diesem Deployment werden alle Instanzen, einschließlich der Anwendungs- und Datenbankinstanzen, in öffentlichen Subnetzen bereitgestellt.

Jeder Instanz im öffentlichen Subnetz ist eine öffentliche IP-Adresse zugeordnet. Obwohl Instanzen mit öffentlichen IP-Adressen über das Internet aufgerufen werden können, können Sie den Zugriff mithilfe von Sicherheitslisten und Sicherheitsregeln einschränken. Zur Ausführung von Administrationsaufgaben empfiehlt Oracle, dass Sie einen Bastionhost in diese Konfiguration aufnehmen. In diesem Szenario öffnen Sie keine Administrationsports für das öffentliche Internet, sondern öffnen die Administrationsports nur für den Bastionhost und richten Sicherheitslisten und Sicherheitsregeln ein, um sicherzustellen, dass nur vom Bastionhost auf die Instanz zugegriffen werden kann.

Anti-Affinität

Beim Erstellen mehrerer Instanzen für High Availability in einer Availability-Domain auf Oracle Cloud Infrastructure kann die Anti-Affinität für Instanzen mit Faultdomains erreicht werden.

Eine Faultdomain ist eine Gruppierung aus Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain umfasst drei Faultdomains. Mit Faultdomains können Sie Ihre Instanzen so verteilen, dass sie sich nicht auf derselben physischen Hardware innerhalb einer Availability-Domain befinden. Daher hat ein Hardwarefehler oder eine Oracle Compute-Hardwarewartung, die sich auf eine Fehlerdomain auswirken, keine Auswirkungen auf Instanzen in anderen Fehlerdomänen. Mit Faultdomains können Sie Ihre Instanzen vor unerwarteten Hardwareausfällen und geplanten Ausfällen schützen.

Für High Availability von Datenbanken können Sie Oracle Real Application Clusters-(Oracle RAC-)Datenbanksysteme mit 2 Knoten erstellen. Die beiden Knoten von Oracle RAC werden standardmäßig immer in separaten Faultdomains erstellt. Die Datenbankknoten befinden sich also weder auf demselben physischen Host noch auf demselben physischen Rack. Dadurch werden die Datenbankinstanzen vor den zugrunde liegenden physischen Hosts und vor Fehlern der Rack-Switches geschützt.