Comprendre l'architecture Oracle Siebel CRM sur Oracle Cloud Infrastructure

Vous pouvez planifier l'architecture pour déployer Oracle Siebel CRM sur plusieurs domaines de disponibilité afin de garantir la haute disponibilité. La haute disponibilité d'une application dans un domaine de disponibilité peut être obtenue en plaçant des instances d'application dans des domaines de pannes distincts.

Architecture de déploiement de Siebel 19.x et versions supérieures pour la haute disponibilité dans une seule région sur plusieurs domaines de disponibilité

Cette architecture montre comment déployer Siebel 19.x et versions supérieures pour la haute disponibilité dans une seule région sur plusieurs domaines de disponibilité.

Les clients souhaitant effectuer un déploiement dans nos régions à domaines de disponibilité multiples (Phoenix, Ashburn, Londres, Francfort) ont la possibilité d'effectuer une récupération après sinistre sur l'ensemble des domaines de disponibilité d'une même région.

Description de l'image hasing-reg-multi-ad-siebel-19-20-21.png

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

Sous-réseaux régionaux dans les domaines de disponibilité (1) : les sous-réseaux régionaux couvrent l'ensemble de la région, ce qui offre des avantages tels que la protection contre les pannes de réseau AD, le déploiement et la gestion simplifiés des services Siebel. Dans ce bastion d'architecture, les équilibreurs de charge et les serveurs de niveau application dans les deux domaines de disponibilité sont à l'état actif.
Equilibrage de charge entre les domaines de disponibilité (2) : l'équilibrage de charge public répartit le trafic entre les serveurs sur tous les domaines de disponibilité configurés, ce qui assure la protection contre les pannes de domaine de disponibilité.
Composants actifs-actifs du serveur Siebel AI Server dans les domaines de disponibilité (3) : en clusterisant les services pris en charge dans les domaines de disponibilité, vous pouvez obtenir une protection contre toute défaillance imprévue dans un seul domaine de disponibilité.
Composants actifs-actifs du serveur Siebel Server dans les domaines de disponibilité (4) : en regroupant les services pris en charge dans les domaines de disponibilité, vous pouvez obtenir une protection contre toute défaillance imprévue dans un seul domaine de disponibilité. Les systèmes de fichiers GWY et Siebel sont affichés comme actifs-passifs sur les AD.
Demande de récupération après sinistre sur l'ensemble des domaines de disponibilité (5) : l'utilisation de Data Guard ou d'Active Data Guard dépend du cas d'emploi et de l'édition de la base de données. Active Data Guard requiert Enterprise Edition – Extreme Performance.

Architecture de déploiement de Siebel 19.x et versions supérieures pour la récupération après sinistre dans plusieurs régions

Cette architecture montre comment déployer Siebel 19.x et versions supérieures pour la récupération après sinistre dans plusieurs régions.

Vous pouvez réaliser une véritable récupération après sinistre dans plusieurs régions en cas de panne d'une région.

Remarques :

Cette architecture de référence couvre le cas le plus robuste avec le clustering de services pris en charge dans les domaines de disponibilité de la région principale, mais la récupération après sinistre peut être réalisée dans toutes les régions avec un seul domaine de disponibilité. Cela est important à noter, car la plupart de nos nouvelles régions OCI seront lancées dans des régions à domaine de disponibilité unique.

Description de l'image dr-multi-reg-19-20-21.png

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

Appairage VCN entre régions : les réseaux cloud virtuels peuvent se connecter entre les régions d'une location ou même entre les locations. La connectivité est assurée par l'épine dorsale interne d'Oracle entre les régions. Si deux applications s'exécutent dans deux domaines de disponibilité différents, l'appairage VCN leur permettra de communiquer en interne.
Composants actifs-actifs dans les domaines de disponibilité : le clustering des services pris en charge dans les domaines de disponibilité assure la protection contre l'échec d'un domaine de disponibilité.
Equilibrage de charge entre les domaines de disponibilité : l'équilibrage de charge public répartit le trafic entre les serveurs Siebel sur tous les domaines de disponibilité configurés, offrant ainsi une protection contre un domaine de disponibilité
Distribution des composants de serveur d'applications actif-passif entre les régions : si vous utilisez Active-passif pour synchroniser les serveurs d'applications entre les domaines de disponibilité, utilisez rsync.
Sous-réseaux régionaux dans les domaines de disponibilité : les sous-réseaux régionaux couvrent l'ensemble de la région, assurent la résilience en cas de panne du réseau AD, et simplifient le déploiement et la gestion des services Siebel.
Demande de récupération après sinistre de base de données dans les domaines de disponibilité : l'utilisation de Data Guard ou d'Active Data Guard dépend du cas d'emploi et de l'édition de la base de données. Active Data Guard requiert Enterprise Edition – Extreme Performance.
Synchronisation du stockage entre les domaines de disponibilité : les sauvegardes de volume de blocs entre les régions peuvent être effectuées à l'aide de la console, de l'interface de ligne de commande, des kits SDK ou des API REST. La copie de sauvegardes de volume de blocs vers une autre région à intervalles réguliers permet de reconstruire plus facilement les applications et les données dans la région de destination en cas de sinistre à l'échelle de la région source. Vous pouvez également facilement migrer et développer des applications vers une autre région. Avec la copie inter-région d'Object Storage, les données copient les objets de manière asynchrone entre les buckets de la même région ou vers les buckets d'autres régions.

A propos des groupes de sécurité réseau

Dans Oracle Cloud Infrastructure, les règles de pare-feu sont configurées via des groupes de sécurité réseau. Un groupe de sécurité réseau distinct est créé pour chaque niveau.

Utilisez des listes de sécurité pour autoriser le trafic entre différents niveaux et entre l'hôte de bastion et les hôtes externes. Les règles de sécurité contiennent des règles entrantes et sortantes pour filtrer le trafic au niveau du niveau. Ils contiennent également des informations sur les ports de communication par lesquels le transfert de données est autorisé. Ces ports (ou, dans certains cas, les protocoles qui auront besoin de ports ouverts dans les règles de sécurité) sont affichés sur chaque ligne de groupe de sécurité réseau dans les diagrammes d'architecture.

Chaque groupe de sécurité réseau est appliqué au niveau de la VNIC. Le transfert d'un paquet de données est autorisé si une règle de l'une des listes autorise le trafic (ou si le trafic fait partie d'une connexion existante suivie). En plus du groupe de sécurité réseau, utilisez iptables pour implémenter une autre couche de sécurité au niveau de l'instance.

Pour les déploiements dans un sous-réseau public, vous pouvez fournir un niveau de sécurité supplémentaire en empêchant l'accès à l'application et aux instances de base de données à partir d'Internet. Utilisez un groupe de sécurité réseau personnalisé pour empêcher l'accès à l'application et aux instances de base de données à partir d'Internet, et autoriser l'accès à la base de données et aux hôtes d'application sur le port 22 à partir de l'hôte de bastion à des fins d'administration. N'activez pas l'accès SSH à l'application et aux instances de base de données à partir d'Internet, mais vous pouvez autoriser l'accès SSH à ces instances à partir du sous-réseau contenant l'hôte de bastion.

Vous pouvez accéder à vos instances dans le sous-réseau privé via le serveur de bastion.

Liste de sécurité pour l'hôte Bastion

La liste de sécurité du bastion permet d'accéder à l'hôte du bastion à partir du réseau Internet public via le port 22.

Pour autoriser le trafic SSH du réseau sur site vers l'hôte de bastion sur Internet, procédez comme suit :

Entrée avec conservation de statut : autorise le trafic TCP à partir du CIDR source 0.0.0.0/0 et de tous les ports source vers le port de destination 22 (SSH).

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

Vous pouvez également restreindre l'accès à l'hôte de bastion sur Internet sur le port 22 uniquement à partir de votre centre de données au lieu de l'accès Internet public (0.0.0.0/0). Pour ce faire, utilisez l'adresse IP de votre routeur en périphérie au lieu du CIDR source en tant que 0.0.0.0/0 dans la règle entrante avec conservation de statut.
Pour autoriser le trafic SSH de l'hôte de bastion vers les instances Oracle Cloud Infrastructure Compute, procédez comme suit :

Sortie avec conservation de statut : autorise le trafic TCP vers le CIDR de destination 0.0.0.0/0 à partir de tous les ports source vers le port de destination 22 (SSH).

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

Liste de sécurité pour les instances Oracle Cloud Infrastructure Load Balancing

L'architecture contient des équilibreurs de charge privés, qui sont placés dans des sous-réseaux privés. Si vous placez les instances d'équilibreur de charge dans un sous-réseau public, vous autorisez le trafic Internet (0.0.0.0/0) vers les instances d'équilibreur de charge.

Pour autoriser le trafic d'Internet vers l'équilibreur de charge, procédez comme suit :

Entrante avec conservation de statut : autorise le trafic TCP à partir du CIDR (Internet) 0.0.0.0/0 source et de tous les ports source vers le port de destination 80 (HTTP) ou 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
Pour autoriser le trafic du réseau sur site vers l'équilibreur de charge, procédez comme suit :

Entrante avec conservation de statut : autorise le trafic TCP à partir du bloc CIDR de réseau sur site et de tous les ports source vers le port de destination 80 (HTTP) ou 443 (HTTPS)

Source Type = CIDR, Source CIDR = <CIDR block for onpremises network>, IP Protocol = TCP, Source Port Range = All, Destination port range = 80 or 443
Pour autoriser le trafic des niveaux d'équilibreur de charge vers les serveurs d'applications, procédez comme suit :

Sortie avec conservation de statut : autorise le trafic TCP vers le CIDR de destination 0.0.0.0/0 à partir de tous les ports source vers tous les ports de destination.

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

Liste de sécurité pour les serveurs Web Siebel Server

Créez les listes de sécurité suivantes pour autoriser le trafic des instances d'équilibreur de charge et du serveur de bastion vers les serveurs Web Siebel. Le trafic reçu des instances d'équilibreur de charge est transmis aux serveurs d'applications Siebel au niveau de l'application.

Pour autoriser le trafic de l'hôte de bastion vers le niveau application :

Entrante avec conservation de statut : Source Type = CIDR, Source CIDR = <CIDR block of bastion subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 22
Pour autoriser le trafic du niveau d'équilibreur de charge vers le niveau d'application, procédez comme suit :

Entrante avec conservation de statut : Source Type = CIDR, Source CIDR = <CIDR block of load balancer subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 80 or 443
Pour autoriser le trafic des serveurs Web Siebel vers les serveurs Siebel au niveau de l'application :

Sortie avec état : Destination Type = CIDR, Destination CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = All

Liste de sécurité pour le niveau Application

Pour autoriser le trafic de l'hôte de bastion vers le niveau application :

Entrante avec conservation de statut : Source Type = CIDR, Source CIDR = <CIDR block of bastion subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 22
Pour autoriser le trafic des serveurs Siebel Server vers le serveur Siebel Gateway Name Server :

Entrante avec conservation de statut : Source Type = CIDR, Source CIDR = <CIDR block of Siebel application subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 2320
Pour autoriser le trafic des serveurs Web Siebel vers les serveurs d'applications Siebel :

Entrante avec conservation de statut : Source Type = CIDR, Source CIDR = <CIDR block of Siebel web subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 2321
Pour autoriser le trafic sortant :

Sortie avec état : Destination Type = CIDR, Destination CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = All

Liste de sécurité pour le niveau base de données

Pour autoriser le trafic de l'hôte de bastion vers le niveau de base de données, procédez comme suit :

Entrante avec conservation de statut : Source Type = CIDR, Source CIDR = <CIDR block of bastion subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 22
Pour autoriser le trafic des serveurs d'applications Siebel vers le niveau base de données :

Entrante avec conservation de statut : Source Type = CIDR, Source CIDR = <CIDR block of siebel application subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 1521
Pour autoriser le trafic sortant :

Sortie avec état : Destination Type = CIDR, Destination CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = All