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

Si vous souhaitez provisionner Oracle Siebel CRM 19.x et versions ulté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 multihôte, sécurisée et haute disponibilité pour les environnements de développement et de test.

Remarques concernant le déploiement sur Oracle Cloud Infrastructure

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

Sous-réseau public ou privé

Vous pouvez créer des instances dans un sous-réseau privé ou public selon que vous souhaitez 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 cloud 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 de 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 via la passerelle Internet (IGW). Vous devrez mettre à jour la table de routage pour activer le trafic vers et depuis 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 bastion dans le sous-réseau public et y accéder à partir d'IGW.

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

Description de l'image 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 dans lesquels il n'existe aucune adresse Internet. Ce type de déploiement est utile lorsque vous souhaitez disposer d'un déploiement hybride avec le cloud en tant qu'extension de vos centres de données existants.

Dans ce déploiement, toutes les instances, y compris les serveurs d'applications et de base de données, sont déployées dans un sous-réseau privé. Une adresse IP publique ne peut pas être affectée 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 site dans cette configuration, vous pouvez :

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

• Créez un bastion dans cette configuration, puis accédez à tous les serveurs du sous-réseau privé à partir de l'hôte de 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 inclut des adresses Internet et non 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, il se peut que des instances d'application servent des utilisateurs internes et qu'un autre ensemble d'instances d'application serve 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'applications 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 Internet, au lieu de placer les serveurs d'applications qui desservent le trafic externe dans un sous-réseau public. Si vous placez l'hôte de 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é via le serveur de 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 adresse interne. Ce déploiement est adapté uniquement si vous ne disposez pas de votre propre centre de données ou si vous ne pouvez pas accéder aux instances via VPN et que vous voulez accéder à l'infrastructure sur Internet.

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

Chaque instance du sous-réseau public est associée à une adresse IP publique. Bien que les instances avec des adresses IP publiques soient accessibles sur Internet, vous pouvez 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 bastion dans cette configuration. Dans ce scénario, vous n'ouvrez pas les ports d'administration sur le réseau Internet public, mais plutôt les ports d'administration uniquement sur l'hôte de bastion, et vous configurez des listes de sécurité et des règles de sécurité pour vous assurer que l'instance est accessible uniquement à partir de l'hôte de bastion.

Anti-affinité

Lors de la création de plusieurs instances pour la haute disponibilité dans un domaine de disponibilité sur Oracle Cloud Infrastructure, vous pouvez obtenir la même anti-affinité pour les instances en utilisant des domaines de pannes.

Un domaine de pannes est un regroupement de matériel et d'infrastructures au sein d'un domaine de disponibilité. Chaque domaine de disponibilité contient trois domaines de pannes. Les domaines de pannes vous permettent de répartir les instances de sorte qu'elles ne se trouvent pas sur le même matériel physique au sein d'un seul et même domaine de disponibilité. Par conséquent, une panne matérielle ou une maintenance matérielle Oracle Compute qui affecte un domaine de pannes n'affecte pas les instances dans d'autres domaines de pannes. Grâce aux domaines de pannes, vous pouvez protéger vos instances contre les pannes matérielles inattendues et les pannes planifiées.

Pour 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 de pannes 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 rack physique. Cela protège les instances de base de données contre l'hôte physique sous-jacent et contre les pannes de commutation en rack.