En savoir plus sur le déploiement d'Oracle Siebel CRM sur Oracle Cloud Infrastructure

Si vous voulez provisionner Oracle Siebel CRM 19.x et versions supérieures sur Oracle Cloud Infrastructure ou migrer des environnements Siebel CRM de votre centre de données vers Oracle Cloud Infrastructure, vous pouvez planifier une topologie à hôtes multiples, sécurisée et haute disponibilité pour les environnements de développement et de test.

Considérations relatives au déploiement sur Oracle Cloud Infrastructure

Oracle recommande de créer des sous-réseaux distincts pour vos instances, tels que l'hôte bastion, la base de données, l'application et l'équilibreur de charge, afin de garantir que les exigences de sécurité appropriées peuvent être mises en oeuvre dans les différents sous-réseaux.

Sous-réseau privé ou public

Vous pouvez créer des instances dans un sous-réseau privé ou public selon que vous voulez autoriser l'accès aux instances à partir d'Internet. Une adresse IP publique est affectée aux instances que vous créez dans un sous-réseau public et vous pouvez accéder à ces instances à partir d'Internet. Vous ne pouvez pas affecter d'adresse IP publique aux instances créées dans un sous-réseau privé. Par conséquent, vous ne pouvez pas accéder à ces instances sur Internet.

L'image suivante présente un réseau en nuage virtuel (VCN) avec des sous-réseaux publics et privés. Le VCN contient deux domaines de disponibilité, et chaque domaine de disponibilité contient un sous-réseau public et privé. Les serveurs Web sont placés dans le sous-réseau public dans cette image, de sorte que chaque instance de serveur Web est associée à une adresse IP publique. Vous pouvez accéder à ces instances Oracle Cloud dans le sous-réseau public à partir d'Internet en activant la communication au moyen de la passerelle Internet (IGW). Vous devrez mettre à jour la table de routage pour activer le trafic vers et depuis l'IGW. Pour autoriser le trafic vers les serveurs Web à partir d'Internet, vous devez créer des équilibreurs de charge dans le sous-réseau public. Pour accéder à vos instances à partir d'Internet, vous devez également créer un hôte bastion dans le sous-réseau public et accéder à l'hôte bastion à partir d'IGW.

Les serveurs de base de données sont placés dans le sous-réseau privé dans cette image. Vous pouvez accéder aux instances Oracle Cloud dans le sous-réseau privé à partir de vos centres de données en vous connectant au moyen de la passerelle de routage dynamique (DRG). La passerelle DRG connecte vos réseaux sur place à votre réseau en nuage. Pour permettre la communication entre la passerelle de routage dynamique et l'équipement sur place du client, utilisez le RPV IPSec ou Oracle Cloud Infrastructure FastConnect. Vous devrez également mettre à jour la table de routage pour activer le trafic vers et depuis la passerelle DRG.

Description de l'illustration public_private_subnets_jde.png

public_private_subnets_jde.zip

Scénario 1 : Déployer toutes les instances dans des sous-réseaux privés

Oracle recommande de déployer toutes les instances dans des sous-réseaux privés pour les environnements de production où il n'y a pas de points d'extrémité accessibles par Internet. Ce type de déploiement est utile lorsque vous voulez un déploiement hybride avec le nuage en tant qu'extension à vos centres de données existants.

Dans ce déploiement, toutes les instances, y compris les serveurs d'applications et de bases de données, sont déployées dans un sous-réseau privé. Il n'est pas possible d'affecter une adresse IP publique aux instances créées dans un sous-réseau privé. Vous ne pouvez donc pas accéder à ces instances sur Internet. Pour accéder à vos serveurs d'applications à partir de votre environnement sur place dans cette configuration, vous pouvez :

• Configurez un tunnel RPV IPSec entre votre centre de données et la passerelle DRG d'Oracle Cloud Infrastructure avant de provisionner les serveurs d'applications.

• Créez un hôte bastion dans cette configuration, puis accédez à tous les serveurs du sous-réseau privé à partir de l'hôte bastion.

Scénario 2 : Déployer des instances dans des sous-réseaux publics et privés

Vous pouvez déployer quelques instances dans un sous-réseau public et quelques instances dans un sous-réseau privé. Ce type de déploiement est utile lorsque le déploiement comprend des points d'extrémité accessibles par Internet et non accessibles par Internet.

Dans cette configuration, certaines instances d'application sont placées dans un sous-réseau public et d'autres dans un sous-réseau privé. Par exemple, vous pouvez avoir des instances d'application servant des utilisateurs internes et un autre jeu d'instances d'application servant des utilisateurs externes. Dans ce scénario, placez les instances d'application qui desservent le trafic interne dans un sous-réseau privé et placez les serveurs d'application qui desservent le trafic externe dans un sous-réseau public. Vous pouvez également configurer un équilibreur de charge public sur les instances d'application accessibles sur Internet, au lieu de placer les serveurs d'applications qui servent le trafic externe dans un sous-réseau public. Si vous placez l'hôte bastion dans un sous-réseau public, une adresse IP publique lui est affectée et vous pouvez y accéder sur Internet. Vous pouvez accéder à vos instances dans le sous-réseau privé au moyen du serveur d'hôte bastion.

Scénario 3 : Déployer toutes les instances dans des sous-réseaux publics

Oracle recommande ce déploiement pour des démonstrations rapides ou pour des déploiements de niveau production sans point d'extrémité interne. Ce déploiement ne convient que si vous n'avez pas votre propre centre de données ou si vous ne pouvez pas accéder aux instances au moyen d'un RPV et que vous souhaitez accéder à l'infrastructure sur Internet.

Dans ce déploiement, toutes les instances, y compris l'application et la base de données, sont déployées dans des sous-réseaux publics.

Chaque instance du sous-réseau public a une adresse IP publique qui lui est associée. Bien qu'il soit possible d'accéder aux instances avec des adresses IP publiques sur Internet, vous pouvez en restreindre l'accès à l'aide de listes de sécurité et de règles de sécurité. Pour effectuer des tâches d'administration, Oracle recommande de placer un hôte bastion dans cette configuration. Dans ce scénario, vous n'ouvrez pas les ports d'administration sur le réseau Internet public, mais vous ouvrez plutôt les ports d'administration uniquement sur l'hôte bastion et configurez les listes de sécurité et les règles de sécurité pour vous assurer que l'instance n'est accessible qu'à partir de l'hôte bastion.

À tout prix

Lors de la création de plusieurs instances à haute disponibilité dans un domaine de disponibilité sur Oracle Cloud Infrastructure, il est possible d'assurer une anti-affinité pour les instances à l'aide des domaines d'erreur.

Un domaine d'erreur est un regroupement de matériel et d'infrastructure au sein d'un domaine de disponibilité. Chaque domaine de disponibilité contient trois domaines d'erreur. Les domaines d'erreur vous permettent de répartir vos instances afin qu'elles ne soient pas sur le même matériel physique au sein d'un même domaine de disponibilité. Ainsi, une défaillance matérielle ou la maintenance matérielle d'Oracle Compute affectant un domaine d'erreur n'affecte pas les instances des autres domaines d'erreur. Les domaines d'erreur vous permettent de protéger vos instances contre les pannes matérielles inattendues et les pannes planifiées.

Pour assurer la haute disponibilité des bases de données, vous pouvez créer des systèmes de base de données Oracle Real Application Clusters (Oracle RAC) à 2 noeuds. Par défaut, les deux noeuds d'Oracle RAC sont toujours créés dans des domaines d'erreur distincts. Par conséquent, les noeuds de base de données ne se trouvent ni sur le même hôte physique ni sur le même bâti physique. Cela protège les instances de base de données contre les défaillances d'hôte physique sous-jacent et de commutateur en haut du bâti.