Oracle Siebel CRM - Architektur auf Oracle Cloud Infrastructure verstehen

Sie können die Architektur so planen, dass Oracle Siebel CRM über mehrere Availability-Domains hinweg bereitgestellt wird, um High Availability sicherzustellen. High Availability einer Anwendung in einer Availability-Domain kann erreicht werden, indem Anwendungsinstanzen in separaten Faultdomains platziert werden.

Architektur für das Deployment von Siebel 19.x und höher für High Availability in einer Region über mehrere Availability-Domains hinweg

Diese Architektur zeigt, wie Sie Siebel 19.x und höher für High Availability in einer einzelnen Region über mehrere Availability-Domains (ADs) hinweg bereitstellen.

Kunden, die an der Bereitstellung in unseren Regionen mit mehreren Availability-Domains (Phoenix, Ashburn, London, Frankfurt) interessiert sind, haben die Möglichkeit einer Disaster Recovery über ADs hinweg innerhalb einer einzigen Region.

Beschreibung der Abbildung hasing-reg-multi-ad-siebel-19-20-21.png

ha-sing-reg-multi-ad-siebel-19-20-21.zip

• Regionale Subnetze über ADs hinweg (1): Regionale Subnetze erstrecken sich über die gesamte Region und bieten Vorteile wie Schutz vor AD-Netzwerkausfällen, vereinfachtes Deployment und Management des Siebel-Service. In dieser Architektur befinden sich Bastionhosts, Load Balancer und Application Tier Server in beiden ADs im aktiven Status.
• Load Balancing über ADs hinweg (2): Public Load Balancing verteilt Traffic auf die Server über alle konfigurierten ADs und bietet Schutz vor einem AD-Ausfall.
• Aktiv-aktive Siebel AI Server-Komponenten über ADs hinweg (3): Durch das Clustering unterstützter Services über ADs hinweg können Sie Schutz vor unvorhergesehenen Fehlern in einer einzelnen AD erhalten.
• Aktiv-aktive Siebel Server-Komponenten über ADs hinweg (4): Durch das Clustering unterstützter Services über ADs hinweg können Sie Schutz vor unvorhergesehenen Fehlern in einer einzelnen AD erhalten. GWY und Siebel-Dateisystem werden ADsübergreifend als Active/Passive angezeigt.
• Datenbank-DR in allen Availability-Domains (5): Die Verwendung von Data Guard oder Active Data Guard hängt von Ihrem Anwendungsfall und Ihrer Datenbankedition ab. Active Data Guard erfordert Enterprise Edition – Extreme Performance.

Architektur für das Deployment von Siebel 19.x und höher für Disaster Recovery in mehreren Regionen

Diese Architektur zeigt, wie Siebel 19.x und höher für Disaster Recovery (DR) über mehrere Regionen hinweg bereitgestellt werden.

In dem unwahrscheinlichen Fall, dass eine Region ausfällt, können Sie echte DR über mehrere Regionen hinweg erreichen.

Hinweis:

Diese Referenzarchitektur deckt den robustesten Fall mit dem Clustering unterstützter Services über ADs innerhalb der primären Region hinweg ab. DR kann jedoch regionsübergreifend mit einer einzelnen AD erreicht werden. Dies ist wichtig, da die meisten unserer neuen OCI-Regionen, die eingeführt werden, einzelne AD-Regionen sein werden.

Beschreibung der Abbildung dr-multi-reg-19-20-21.png

dr-multi-reg-19-20-21.zip

• VCN-Peering über Regionen hinweg: VCNs können Verbindungen zwischen Regionen in einem Mandanten oder sogar zwischen Mandanten herstellen. Die Konnektivität wird über das interne Backbone von Oracle zwischen Regionen erreicht. Wenn zwei Anwendungen in zwei verschiedenen ADs ausgeführt werden, können sie mit VCN-Peering intern kommunizieren.
• Aktiv-aktive Komponenten über ADs hinweg: Das Clustering unterstützter Services über ADs hinweg bietet Schutz vor einem AD-Ausfall.
• Load Balancing über ADs: Das öffentliche Load Balancing verteilt den Traffic auf die Siebel-Server auf alle konfigurierten ADs und bietet Schutz vor einer AD
• Aktiv-Passiv-Anwendungsserverkomponenten regionsübergreifend verteilen: Wenn Sie Active/Passive verwenden, um Anwendungsserver über ADs hinweg zu synchronisieren, verwenden Sie rsync.
• Regionale Subnetze über ADs hinweg: Regionale Subnetze erstrecken sich über die gesamte Region und bieten Resilienz gegen AD-Netzwerkfehler sowie vereinfachte Bereitstellung und Verwaltung von Siebel-Services.
• Datenbank-DR über ADs hinweg: Die Verwendung von Data Guard oder Active Data Guard hängt von Ihrem Anwendungsfall und Ihrer Datenbankedition ab. Active Data Guard erfordert Enterprise Edition – Extreme Performance.
• Speichersynchronisierung über ADs hinweg: Block-Volume-Backups zwischen Regionen können mit der Konsole, der CLI, den SDKs oder den REST-APIs durchgeführt werden. Wenn Sie Block-Volume-Backups in eine andere Region in regelmäßigen Abständen kopieren, können Sie Anwendungen und Daten in der Zielregion einfacher neu erstellen, wenn es in der Quellregion zu einer regionsweiten Katastrophe kommt. Sie können Anwendungen auch problemlos in eine andere Region migrieren und erweitern. Beim regionsübergreifenden Kopieren in Object Storage kopieren Daten Objekte asynchron zwischen Buckets in derselben Region oder in Buckets in anderen Regionen.

Informationen zu Netzwerksicherheitsgruppen

In Oracle Cloud Infrastructure werden Firewallregeln über Netzwerksicherheitsgruppen konfiguriert. Für jede Tier wird eine separate Netzwerksicherheitsgruppe erstellt.

Verwenden Sie Sicherheitslisten, um Datenverkehr zwischen verschiedenen Ebenen und zwischen dem Bastionhost und externen Hosts zuzulassen. Sicherheitsregeln enthalten Ingress- und Egress-Regeln zum Filtern des Traffics auf Tier-Ebene. Sie enthalten auch Informationen über Kommunikationsports, über die eine Datenübertragung zulässig ist. Diese Ports (oder in einigen Fällen die Protokolle, die offene Ports in den Sicherheitsregeln benötigen) werden in den Architekturdiagrammen in jeder Netzwerksicherheitsgruppenzeile angezeigt.

Jede Netzwerksicherheitsgruppe wird auf VNIC-Ebene durchgesetzt. Die Übertragung eines Datenpakets ist zulässig, wenn eine Regel in einer der Listen Traffic zulässt (oder wenn der Traffic Teil einer vorhandenen Verbindung ist, die verfolgt wird). Verwenden Sie neben der Netzwerksicherheitsgruppe iptables, um eine weitere Sicherheitsebene auf Instanzebene zu implementieren.

Für Deployments in einem öffentlichen Subnetz können Sie eine zusätzliche Sicherheitsebene bereitstellen, indem Sie den Zugriff auf die Anwendungs- und Datenbankinstanzen über das Internet verhindern. Verwenden Sie eine benutzerdefinierte Netzwerksicherheitsgruppe, um den Zugriff auf die Anwendungs- und Datenbankinstanzen über das Internet zu verhindern, und gestatten Sie den Zugriff auf die Datenbank- und Anwendungshosts über Port 22 vom Bastionhost zu Administrationszwecken. Aktivieren Sie keinen SSH-Zugriff auf die Anwendungs- und Datenbankinstanzen über das Internet. Sie können jedoch SSH-Zugriff auf diese Instanzen über das Subnetz zulassen, das den Bastionhost enthält.

Sie können über den Bastionserver auf Ihre Instanzen im privaten Subnetz zugreifen.

Sicherheitsliste für den Bastionhost

Die Bastion-Sicherheitsliste ermöglicht es dem Bastion-Host, über Port 22 über das öffentliche Internet zugänglich zu sein.

• So lassen Sie SSH-Traffic vom On-Premise-Netzwerk zum Bastionhost über das Internet zu:

  Zustandsbehafteter Ingress: TCP-Traffic von dem Quell-CIDR 0.0.0.0/0 und allen Quellports zum Zielport 22 (SSH) zulassen.

  Source Type = CIDR, Source CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = 22

  Sie können auch den Zugriff des Bastionhosts über das Internet auf Port 22 nur über Ihr Data Center und nicht über das öffentliche Internet (0.0.0.0/0) einschränken. Um dies zu erreichen, verwenden Sie die Edge-Router-IP anstelle des Quell-CIDR als 0.0.0.0/0 in der Regel für zustandsbehafteten Ingress.

• So lassen Sie SSH-Traffic vom Bastionhost zu Oracle Cloud Infrastructure Compute-Instanzen zu:

  Zustandsbehafteter Egress: TCP-Traffic von allen Quellports zum Ziel-CIDR 0.0.0.0/0 zum Zielport 22 (SSH).

  Destination Type = CIDR, Destination CIDR = <CIDR block of VCN>, IP Protocol = TCP, Source Port Range = All, Destination port range = 22

Sicherheitsliste für die Oracle Cloud Infrastructure Load Balancing-Instanzen

Die Architektur enthält private Load Balancer, die in privaten Subnetzen platziert werden. Wenn Sie die Load-Balancer-Instanzen in einem öffentlichen Subnetz ablegen, lassen Sie Traffic vom Internet (0.0.0.0/0) zu den Load-Balancer-Instanzen zu.

• So lassen Sie Traffic vom Internet zum Load Balancer zu:

  Statusmäßiger Ingress: Zulassen von TCP-Traffic vom Quell-CIDR (Internet) 0.0.0.0/0 und allen Quellports zum Zielport 80 (HTTP) oder 443 (HTTPS).

  Source Type = CIDR, Source CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = 80 or 443

• So lassen Sie Traffic vom On-Premise-Netzwerk zum Load Balancer zu:

  Zustandsbehafteter Ingress: TCP-Traffic vom On-Premise-Netzwerk-CIDR-Block und allen Quellports zum Zielport 80 (HTTP) oder 443 (HTTPS) zulassen

  Source Type = CIDR, Source CIDR = <CIDR block for onpremises network>, IP Protocol = TCP, Source Port Range = All, Destination port range = 80 or 443

• So lassen Sie Traffic von den Load Balancer Tiers zu den Anwendungsservern zu:

  Zustandsbehafteter Egress: TCP-Traffic zum Ziel-CIDR 0.0.0.0/0 von allen Quellports zu allen Zielports zulassen.

  Destination Type = CIDR, Destination CIDR = <CIDR block for application subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = All

Sicherheitsliste für Siebel-Webserver

Erstellen Sie die folgenden Sicherheitslisten, um Traffic von den Load Balancer-Instanzen und dem Bastionserver zu den Siebel-Webservern zuzulassen. Von den Load Balancer-Instanzen empfangener Traffic wird an die Siebel-Anwendungsserver in der Anwendungsebene weitergeleitet.

• So lassen Sie Traffic vom Bastionhost zur Anwendungsebene zu:

  Zuständige Ingress: Source Type = CIDR, Source CIDR = <CIDR block of bastion subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 22

• So lassen Sie Traffic von der Load Balancer-Ebene zur Anwendungsebene zu:

  Zustandsbehafteter Ingress: Source Type = CIDR, Source CIDR = <CIDR block of load balancer subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 80 or 443

• So erlauben Sie Traffic von Siebel-Webservern zu den Siebel-Servern in der Anwendungsebene:

  Zustandsbehafteter Egress: Destination Type = CIDR, Destination CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = All

Sicherheitsliste für die Anwendungsebene

• So lassen Sie Traffic vom Bastionhost zur Anwendungsebene zu:

  Zuständige Ingress: Source Type = CIDR, Source CIDR = <CIDR block of bastion subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 22

• So lassen Sie Datenverkehr von Siebel-Servern zum Siebel Gateway Name Server zu:

  Zustandsbehafteter Ingress: Source Type = CIDR, Source CIDR = <CIDR block of Siebel application subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 2320

• So lassen Sie Traffic von Siebel-Webservern zu den Siebel-Anwendungsservern zu:

  Zustandsbehafteter Ingress: Source Type = CIDR, Source CIDR = <CIDR block of Siebel web subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 2321

• So erlauben Sie Egress-Traffic:

  Zustandsbehafteter Egress: Destination Type = CIDR, Destination CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = All

Sicherheitsliste für die Datenbankebene

• So lassen Sie Traffic vom Bastionhost zur Datenbankebene zu:

  Zuständige Ingress: Source Type = CIDR, Source CIDR = <CIDR block of bastion subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 22

• So lassen Sie Traffic von Siebel-Anwendungsservern zur Datenbankebene zu:

  Zuständige Ingress: Source Type = CIDR, Source CIDR = <CIDR block of siebel application subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 1521

• So erlauben Sie Egress-Traffic:

  Zustandsbehafteter Egress: Destination Type = CIDR, Destination CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = All