En savoir plus sur le déploiement de JD Edwards EnterpriseOne sur Oracle Cloud Infrastructure

Si vous souhaitez provisionner JD Edwards EnterpriseOne sur Oracle Cloud Infrastructure ou migrer des environnements JD Edwards EnterpriseOne de votre centre de données vers Oracle Cloud Infrastructure, vous pouvez planifier une topologie multihôte, sécurisée et haute disponibilité.

Avant de commencer

Oracle Cloud Infrastructure prend en charge les versions 9.0, 9.1 et 9.2 d'application JD Edwards EnterpriseOne. Avant de commencer à planifier le déploiement ou la migration de votre application JD Edwards EnterpriseOne, identifiez si Oracle Cloud Infrastructure prend en charge la combinaison de la version d'application JD Edwards EnterpriseOne, de la version d'outils JD Edwards EnterpriseOne et du système d'exploitation sur lequel vous souhaitez exécuter vos applications.

• Application JD Edwards EnterpriseOne version 9.2 avec JD Edwards EnterpriseOne Tools version 9.2. x. Il prend en charge l'installation manuelle et automatisée des composants JD Edwards EnterpriseOne sur les systèmes d'exploitation Oracle Linux et Windows.

• JD Edwards EnterpriseOne version 9.1 avec JD Edwards EnterpriseOne Tools version 9.1.x ou 9.2.x. Il prend en charge uniquement l'installation manuelle des composants JD Edwards EnterpriseOne sur les systèmes d'exploitation Oracle Linux et Windows.

Pour plus d'informations sur les versions antérieures de l'application JD Edwards EnterpriseOne, contactez Oracle Advanced Consulting Services.

Pour plus d'informations sur les certifications définitives, reportez-vous à My Oracle Support.

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 les instances 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éseaux privés ou publics

Vous pouvez créer des instances dans un sous-réseau privé ou public en fonction du fait que vous souhaitez autoriser l'accès aux instances à partir d'Internet. Les instances que vous créez dans un sous-réseau public reçoivent une adresse IP publique et vous pouvez accéder à ces instances à partir d'Internet. Vous ne pouvez pas affecter une 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 montre un réseau cloud virtuel (VCN) avec des sous-réseaux publics et privés. 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 les instances de serveur Web ont une adresse IP publique qui lui est attachée. Vous pouvez accéder à ces instances Oracle Cloud du 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 à destination et à partir de l'IGW. Pour permettre 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 de l'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). DRG connecte vos réseaux sur site à votre réseau cloud. Pour activer la communication entre DRG et l'équipement client sur site, utilisez IPSec VPN ou Oracle Cloud Infrastructure FastConnect. Vous devrez également mettre à jour la table de routage pour activer le trafic à destination et à partir de DRG.

Description de l'image public_private_subnets_jde.png

Scénario 1 : Déployer toutes les instances dans les 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 d'adresse Internet. Ce type de déploiement est utile lorsque vous souhaitez avoir un déploiement hybride avec le cloud 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é. Une adresse IP publique ne peut pas être affectée aux instances créées dans un sous-réseau privé, de sorte que vous ne pouvez 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 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 inclut des terminaux orientés sur Internet et non connectés à 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 desservant des utilisateurs internes et un autre ensemble d'instances d'application desservant 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 orientées sur 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 du bastion dans un sous-réseau public, alors l'hôte du bastion reçoit une adresse IP publique, et vous pouvez y accéder sur Internet. Vous pouvez accéder à vos instances dans le sous-réseau privé via le serveur bastion.

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

Oracle recommande ce déploiement pour les démonstrations rapides ou pour les déploiements de niveau production sans adresse interne. Ce déploiement est adapté uniquement si vous n'avez pas votre propre centre de données, ou si vous ne pouvez pas accéder aux instances via VPN, et que vous souhaitez accéder à l'infrastructure via 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 a une adresse IP publique qui lui est jointe. Bien que les instances ayant des adresses IP publiques puissent être consultées sur Internet, vous pouvez restreindre l'accès en utilisant des listes de sécurité et des 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'ouvririez pas de ports d'administration à Internet public, mais vous ouvririez plutôt les ports d'administration uniquement à l'hôte du bastion et configurez des listes de sécurité et des règles de sécurité pour vous assurer que l'instance ne peut être accessible qu'à partir de l'hôte du bastion.

Anti-affinité

Lors de la création de plusieurs instances pour une haute disponibilité dans un domaine de disponibilité sur Oracle Cloud Infrastructure, l'anti-affinité pour les instances peut être obtenue à l'aide de domaines d'erreur.

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é. Ainsi, 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. En utilisant des domaines de pannes, vous pouvez protéger vos instances contre les pannes matérielles inattendues et les pannes planifiées.

Pour une haute disponibilité de bases de données, vous pouvez créer des systèmes de base de données Oracle Real Application Clusters (Oracle RAC) à 2 noeuds. Les deux noeuds d'Oracle RAC sont toujours créés par défaut dans des domaines de pannes distincts. Ainsi, les noeuds de base de données ne sont 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 les pannes du commutateur rack.

Architecture pour le déploiement de JD Edwards EnterpriseOne dans une seule région

Vous pouvez déployer JD Edwards EnterpriseOne dans un domaine de disponibilité unique tout en garantissant une haute disponibilité.

Vous pouvez obtenir une haute disponibilité en plaçant les instances d'application dans plusieurs domaines de pannes. Utilisez cette architecture pour vous assurer que votre application est disponible même lorsqu'une instance d'application est arrêtée dans un domaine en faute. Les autres instances d'application disponibles dans l'autre domaine d'erreur continuent de traiter les demandes. Vous pouvez déployer JD Edwards EnterpriseOne manuellement ou à l'aide des outils d'automatisation JD Edwards EnterpriseOne sur Oracle Cloud Infrastructure.

Cette architecture montre que les instances redondantes sont déployées dans le niveau de présentation et le niveau intermédiaire dans un domaine de disponibilité afin d'assurer une haute disponibilité dans le domaine de disponibilité. Toutes les instances du domaine de disponibilité sont actives. Cette haute disponibilité d'une application dans un domaine de disponibilité peut être obtenue en plaçant les instances d'application dans des domaines de pannes distincts. 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é. Une panne matérielle ou une maintenance matérielle Oracle Cloud Infrastructure Compute qui affecte un domaine d'erreur n'affecte pas les instances dans d'autres domaines d'erreur. Si une instance échoue, le trafic est redirigé vers d'autres instances du domaine de disponibilité qui continuent de traiter les demandes. Toutefois, si votre connexion au domaine de disponibilité échoue ou si l'ensemble du domaine de disponibilité est arrêté, les instances ne sont pas disponibles pour traiter les demandes.

Les instances du sous-réseau privé nécessitent une connexion sortante à Internet pour télécharger des patches ainsi que pour appliquer des mises à jour de système d'exploitation et d'application. À cette fin, utilisez une passerelle NAT (Network Address Translation) dans VCN. Avec une passerelle NAT, les hôtes du sous-réseau privé peuvent initier des connexions à Internet et recevoir des réponses, mais ne recevront pas de connexions entrantes initiées à partir d'Internet.

Oracle recommande que la base de données et les applications déployées sur Oracle Cloud Infrastructure disposent d'une sauvegarde robuste de la stratégie de récupération. Il est recommandé de stocker la sauvegarde des bases de données et des instances d'application dans Oracle Cloud Infrastructure Object Storage. Les bases de données et les instances d'application des sous-réseaux privés peuvent être sauvegardées vers Oracle Cloud Infrastructure Object Storage à l'aide d'une passerelle de service. Une passerelle de service permet d'accéder à Oracle Cloud Infrastructure Object Storage sans passer par Internet.

Les sauvegardes automatiques et à la demande de base de données vers Oracle Cloud Infrastructure Object Storage peuvent être configurées à l'aide de la console Oracle Cloud Infrastructure. Cela nécessite une connectivité à Oracle Cloud Infrastructure Object Storage à l'aide d'une adresse Swift. Toutes les sauvegardes de base de données sur Oracle Cloud Infrastructure Object Storage sont cryptées avec la même clé maître utilisée pour le cryptage de portefeuille Transparent Data Encryption (TDE). Le service de sauvegarde automatique de base de données utilise une stratégie de sauvegarde incrémentielle hebdomadaire pour sauvegarder les bases de données avec une stratégie de conservation de 30 jours. Il est également possible d'effectuer une sauvegarde complète à la demande des bases de données pour les besoins ad hoc.

La sauvegarde de l'application peut être configurée à l'aide de la fonctionnalité de sauvegarde basée sur des stratégies d'Oracle Cloud Infrastructure Block Volumes. Oracle Cloud Infrastructure Block Volumes vous offre la possibilité d'effectuer automatiquement des sauvegardes de volume en fonction d'une programmation et de les conserver en fonction de la stratégie de sauvegarde sélectionnée. Cela vous permet de respecter vos exigences en matière de conformité et de réglementation des données. Il existe trois stratégies de sauvegarde prédéfinies : Bronze, Argent et Or. Chaque stratégie de sauvegarde a une fréquence de sauvegarde prédéfinie et une période de conservation.

L'architecture se compose d'un réseau cloud virtuel (VCN) avec l'hôte bastion, le niveau d'équilibreur de charge, le niveau de présentation, le niveau intermédiaire, le niveau d'administration et le niveau de base de données. Les niveaux sont placés dans un sous-réseau unique de VCN dans un domaine de disponibilité unique.

Dans le diagramme d'architecture suivant, l'hôte bastion est déployé dans un sous-réseau public, et toutes les autres instances sont placées dans des sous-réseaux privés. Selon vos besoins métier, vous pouvez placer des instances dans des sous-réseaux publics ou privés. Vous pouvez accéder aux instances qui se trouvent dans des sous-réseaux privés via le port 22 via l'hôte bastion ou la passerelle de routage dynamique (DRG). Pour activer la communication entre DRG et l'équipement client sur site, utilisez IPSec VPN ou Oracle Cloud Infrastructure FastConnect.

Le gestionnaire de serveur du niveau Administration communique avec le niveau Présentation, le niveau intermédiaire et le niveau Base de données pour fournir le déploiement de code, la gestion de la configuration, l'accès aux mesures d'exécution et l'accès au journal. Le serveur de déploiement du niveau Administration communique avec le niveau intermédiaire et le niveau de base de données pour créer et déployer du code. Le client Développement communique avec le niveau intermédiaire et la base de données. Application Development Framework (ADF) et Oracle Business Intelligence Publisher communiquent avec le serveur HTML au niveau Présentation.

Description de l'illustration single_availability_domain_jd_edwards_deployment.png

Cette architecture est divisée en ces niveaux :

• Bastion host : l'hôte bastion est un composant facultatif qui peut être utilisé comme serveur saut pour accéder aux instances du sous-réseau privé. Un hôte bastion est une instance Oracle Cloud Infrastructure Compute qui utilise Linux comme système d'exploitation. Placez l'hôte du bastion dans un sous-réseau public et assignez-lui une adresse IP publique pour y accéder à partir d'Internet.

  Pour fournir un niveau de sécurité supplémentaire, vous pouvez configurer des listes de sécurité pour accéder à l'hôte du bastion uniquement à partir de l'adresse IP publique de votre réseau sur site. Vous pouvez accéder aux instances Oracle Cloud Infrastructure dans le sous-réseau privé via l'hôte bastion. Pour ce faire, activez le transfert ssh-agent, qui vous permet de vous connecter à l'hôte bastion, puis d'accéder au serveur suivant en transmettant les informations d'identification à partir de votre ordinateur. Vous pouvez également accéder aux instances du sous-réseau privé à l'aide d'un tunnel SSH dynamique. Le tunnelage SSH est un moyen d'accéder à une application Web ou à un autre service d'écoute. Le tunnel dynamique fournit un proxy SOCKS sur le port local, mais les connexions proviennent de l'hôte distant.

• Niveau d'équilibreur de charge : le niveau d'équilibreur de charge contient les instances Oracle Cloud Infrastructure Load Balancing qui équilibrent le trafic vers toutes les instances du niveau de présentation. L'équilibreur de charge reçoit les demandes des utilisateurs, puis achemine ces demandes aux instances du niveau de présentation.

  Utilisez Oracle Cloud Infrastructure Load Balancing pour distribuer le trafic vers vos instances d'application au sein d'un VCN. Ce service fournit une instance principale et une instance de secours de l'équilibreur de charge pour s'assurer que si l'équilibreur de charge principal devient indisponible, l'équilibreur de charge de secours transmet les demandes. L'équilibreur de charge garantit que les demandes sont acheminées vers les instances d'application saines. Si un problème survient dans une instance d'application, l'équilibreur de charge achemine les demandes vers les instances d'application saines restantes.

  En fonction de vos besoins, vous pouvez placer des équilibreurs de charge dans un sous-réseau public ou privé.

  • Pour les adresses internes qui ne sont pas accessibles à partir d'Internet, utilisez un équilibreur de charge privé. Un équilibreur de charge privé possède une adresse IP privée et n'est pas accessible à partir d'Internet. Les instances principales et les instances de secours d'un équilibreur de charge résident dans le même sous-réseau privé. Vous pouvez accéder aux équilibreurs de charge privés dans VCN ou dans votre centre de données via le VPN IPSec via DRG. L'équilibreur de charge privé accepte le trafic à partir de votre centre de données et distribue le trafic aux instances d'application sous-jacentes.

  • Pour les terminaux orientés Internet, utilisez un équilibreur de charge public. Un équilibreur de charge public possède une adresse IP publique et est accessible à partir d'Internet. Vous pouvez accéder aux équilibreurs de charge publics à partir d'Internet via la passerelle Internet.

  • Pour accéder aux terminaux internes et aux terminaux orientés Internet, configurez des équilibreurs de charge privés et des équilibreurs de charge publics. Configurez des équilibreurs de charge privés pour desservir le trafic interne et configurez des équilibreurs de charge publics pour desservir le trafic à partir d'Internet.

  Enregistrez l'adresse IP publique ou privée des instances Oracle Cloud Infrastructure Load Balancing dans votre serveur de noms de domaine sur site ou public (DNS) pour obtenir la résolution de domaine de votre adresse d'application.

  Les ports fournis dans le diagramme d'architecture ne sont qu'un exemple. Vous pouvez utiliser n'importe quel port disponible.

• Niveau d'administration : le niveau d'administration contient une instance unique des serveurs suivants. Vous n'avez pas besoin d'une instance redondante de ces serveurs pour garantir une haute disponibilité.

  • Serveur de provisionnement : utilisez ce serveur pour automatiser le déploiement de bout en bout des composants JD Edwards EnterpriseOne sur Oracle Cloud Infrastructure. Il communique avec toutes les instances des autres niveaux, y compris les instances du niveau de base de données, sur le port 22. Il héberge la console JD Edwards EnterpriseOne One-Click Provisioning Console et la console JD Edwards EnterpriseOne Server Manager.

  • Serveur de déploiement : au cours du processus d'installation, ce serveur agit en tant que référentiel central de tous les fichiers et packages d'installation requis. Le logiciel est distribué ou déployé sur tous les autres serveurs et clients à partir de ce serveur.

  • Client de développement : le client JD Edwards EnterpriseOne Development contient des composants exécutés en tant qu'applications Microsoft Windows standard (par exemple, Active Console, Forms Design Aid (FDA) et Report Design Aid (RDA)) et des composants exécutés dans un navigateur Web.

  • Serveur ADF (Application Development Framework) : le serveur ADF JD Edwards EnterpriseOne est une application Web déployée sur un serveur Oracle WebLogic avec l'exécution ADF. Il est utilisé pour exécuter des applications JD Edwards EnterpriseOne développées avec Oracle ADF.

  • Oracle Business Intelligence Publisher : Oracle Business Intelligence Publisher présente les données collectées par JD Edwards EnterpriseOne sous forme d'états. Utilisez Oracle Business Intelligence Publisher pour présenter des états à l'aide de différents modèles en fonction de vos besoins métier. Vous pouvez concevoir et contrôler la présentation des sorties d'état à l'aide de fichiers modèles.

• Niveau de présentation : le niveau de présentation contient des instances redondantes des services d'interface d'application et des serveurs d'applications Java pour fournir une haute disponibilité. Ces serveurs communiquent avec les serveurs du niveau intermédiaire. Toutes les instances sont actives et reçoivent du trafic de l'équilibreur de charge. Chaque instance est associée à un volume de stockage de blocs. Ce niveau contient également des composants que vous pouvez utiliser pour créer une intégration entre JD Edwards EnterpriseOne et un système externe. Votre implémentation peut inclure un ou plusieurs de ces composants.

  Ce niveau contient les serveurs suivants :

  • Serveur AIS (Application Interface Services) : Le serveur Application Interface Service fournit l'interface de communication entre les applications JD Edwards EnterpriseOne Mobile Enterprise et JD Edwards EnterpriseOne.

  • Serveurs d'applications Java standard (JAS standard) : il reçoit des demandes de l'équilibreur de charge et exécute une logique métier simple. Pour les tâches nécessitant une logique métier compliquée, Standard JAS transmet les demandes au serveur logique. Il transmet également des demandes au serveur AIS dans certains cas. Toutefois, il n'est pas configuré avec le serveur AIS pour l'exécution AIS.

  • Serveurs d'applications Java dédiés (JAS dédié) : il reçoit des demandes du serveur AIS. Il transmet des demandes au serveur logique pour exécuter des tâches nécessitant une logique métier compliquée. Il est configuré avec le serveur AIS pour l'exécution AIS.

  Pour garantir une haute disponibilité dans un domaine de disponibilité, déployez des instances redondantes de chaque composant. Toutes les instances sont actives et reçoivent du trafic de l'équilibreur de charge et du niveau intermédiaire.

• Niveau intermédiaire : le niveau intermédiaire contient des serveurs logiques et des serveurs par lots. Ils ne sont pas directement équilibrés de charge, mais ils ont un mapping individuel avec des serveurs au niveau de la présentation. Vous pouvez héberger le serveur logique et le serveur de batch sur la même instance de serveur Enterprise. Cependant, il est recommandé de configurer le serveur logique et le serveur de batch sur des instances de serveur Enterprise distinctes.

  Le niveau intermédiaire reçoit les demandes du niveau de présentation. Après traitement des demandes, il transmet les demandes aux serveurs de base de données. Toutes les instances des serveurs sont actives et traitent les demandes.

  Ce niveau contient les serveurs suivants :

  • Serveurs logiques ou serveurs Enterprise : ces serveurs contiennent la logique métier ou les fonctions métier.

  • Serveurs par lots : ces serveurs sont utilisés pour le traitement par lots.

• Niveau de base de données : le niveau de base de données contient des instances de serveur de base de données JD Edwards EnterpriseOne. Pour les exigences de haute disponibilité, Oracle recommande d'utiliser des systèmes de base de données Oracle Real Application Clusters (Oracle RAC) à deux noeuds ou un système Oracle Database Exadata Cloud Service dans Oracle Cloud Infrastructure pour configurer les instances de serveur de base de données JD Edwards EnterpriseOne.

  Vous pouvez configurer des instances de base de données redondantes pour fournir une haute disponibilité. Pour les systèmes de base de données Oracle RAC et Oracle Database Exadata Cloud Service, les demandes reçues du sous-réseau d'applications sont équilibrées entre les serveurs de base de données. Si une instance de base de données devient indisponible, l'autre instance de base de données traite les demandes. Vous pouvez utiliser Oracle Cloud Infrastructure Object Storage pour sauvegarder la base de données JD Edwards EnterpriseOne à l'aide d'Oracle Recovery Manager (RMAN). Pour sauvegarder ou patcher la base de données JD Edwards EnterpriseOne vers Oracle Cloud Infrastructure Object Storage, VCN du système de base de données doit être configuré avec une passerelle de service ou une passerelle Internet. Il est recommandé d'utiliser une passerelle de service plutôt qu'une passerelle Internet pour la sauvegarde et l'application de patches.

  Utilisez des listes de sécurité pour restreindre l'accès aux serveurs de base de données uniquement à partir de l'hôte du bastion, du niveau d'application et des serveurs sur site. Vous pouvez configurer des listes de sécurité pour vous assurer que la communication n'a lieu que sur le port 22, via l'hôte bastion et sur le port 1521. Assurez-vous également que les systèmes de base de données ne peuvent pas être consultés sur Internet.

Vous pouvez utiliser Oracle Cloud Infrastructure Object Storage pour sauvegarder les instances du niveau de présentation et du niveau intermédiaire.

Architecture pour le déploiement de JD Edwards EnterpriseOne avec récupération après sinistre

Cette architecture affiche le déploiement des serveurs d'applications JD Edwards EnterpriseOne avec récupération après sinistre. Il affiche un VCN avec le bastion dans un sous-réseau public et tous les autres serveurs d'un sous-réseau privé.

Les serveurs de production sont placés dans deux régions différentes. Les serveurs d'une région sont en mode actif et les serveurs de la deuxième région (région Récupération après sinistre) sont en mode veille.

Dans le diagramme d'architecture, l'hôte bastion est déployé dans un sous-réseau public, et toutes les autres instances sont déployées dans des sous-réseaux privés. Vous pouvez placer les instances dans des sous-réseaux publics ou privés en fonction de vos besoins métier. Vous pouvez accéder aux instances dans des sous-réseaux privés sur le port 22 via l'hôte bastion ou DRG. Pour activer la communication entre DRG et l'équipement client, utilisez IPSec VPN ou Oracle Cloud Infrastructure FastConnect.

Dans cette architecture, plusieurs instances d'application sont déployées dans plusieurs domaines d'erreur afin d'assurer une haute disponibilité. Cela garantit que votre application est disponible même si l'un des domaines de disponibilité n'est pas disponible. Les instances d'application disponibles dans un autre domaine de disponibilité continuent de traiter les demandes.

Les hôtes du bastion dans les deux régions sont actifs et peuvent répondre aux demandes SSH aux deux régions à tout moment. Le service DNS sur site ou DNS externe reçoit une demande pour l'application JD Edwards EnterpriseOne. Ces demandes sont équilibrées par la charge de la corbeille ronde dans l'équilibreur de charge de la région active. L'équilibreur de charge achemine ensuite la demande vers les instances du niveau de présentation et du niveau intermédiaire. Les instances du niveau intermédiaire acheminent la demande vers des instances de base de données actives pour traitement. Le client de développement au niveau de l'administration communique également avec la base de données. Le serveur de provisionnement du niveau d'administration communique avec les instances de tous les niveaux.

Si la région principale n'est pas disponible, vous devez basculer manuellement vers le serveur de base de données en cours d'exécution dans la région Récupération après sinistre et commencer à utiliser l'hôte bastion ou l'équilibreur de charge en cours d'exécution dans la région Récupération après sinistre.

Les bases de données et les instances d'application des sous-réseaux privés peuvent être sauvegardées jusqu'au stockage d'objets Oracle Cloud Infrastructure à l'aide d'une passerelle de service. Une passerelle de service permet d'accéder au stockage d'objet sans passer par Internet.

Description de l'illustration jde2.png

• Hôte de bastion : un hôte bastion est un composant facultatif que vous pouvez provisionner dans chaque région pour agir en tant qu'hôte de saut pour accéder aux instances d'application et de base de données. Les hôtes de Bastion dans les deux régions sont en état actif.

• Instance d'équilibreur de charge : les instances Oracle Cloud Infrastructure Load Balancing distribuent le trafic sur les serveurs d'applications. L'instance d'équilibreur de charge dans la région active/principale est active. Les demandes reçues à l'URL JD Edwards EnterpriseOne sont envoyées à l'équilibreur de charge dans la région active par un service sur site ou un service DNS externe.

• Niveau de présentation : le niveau de présentation contient des instances redondantes de Services d'interface d'application (AIS) et de Serveurs d'applications Java (JAS) pour fournir une haute disponibilité. Ces serveurs communiquent avec les serveurs du niveau intermédiaire. Toutes les instances sont actives et reçoivent du trafic de l'équilibreur de charge. Chaque instance est associée à un volume de stockage de blocs. Ce niveau contient également des composants que vous pouvez utiliser pour créer une intégration entre JD Edwards EnterpriseOne et un système externe. Votre implémentation peut inclure un ou plusieurs de ces composants.

• Niveau intermédiaire : le niveau intermédiaire contient des serveurs logiques et des serveurs par lots. Ils ne sont pas directement équilibrés de charge, mais ils ont un mapping individuel avec des serveurs dans le niveau de présentation.

• Niveau de base de données : configurez les instances de base de données hautement disponibles dans les deux régions. Le serveur de base de données exécuté dans la région active/principale a l'état Actif. Dans chaque région, au moins deux instances de base de données sont configurées pour garantir une haute disponibilité au sein d'une région. Si aucune instance de base de données n'est disponible dans la région active/principale, passez à l'instance de base de données dans la région Récupération après sinistre et commencez à utiliser l'équilibreur de charge dans la région Récupération après sinistre pour accéder à l'environnement.

  Utilisez Oracle Active Data Guard en mode synchrone pour répliquer la base de données entre les 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 bastion et les hôtes externes. Les règles de sécurité contiennent des règles d'entrée et d'évacuation pour filtrer le trafic au niveau du niveau du niveau. Elles 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 nécessitant des 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 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 faisant l'objet d'un suivi). Outre le 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 aux instances d'application et de base de données à partir d'Internet. Utilisez un groupe de sécurité réseau personnalisé pour empêcher l'accès aux instances d'application et de base de données à partir d'Internet et permettre l'accès aux hôtes de base de données et d'application via le port 22 à partir de l'hôte 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 bastion.

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

Groupe de sécurité réseau pour l'hôte Bastion

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

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

  Entrée avec statut : autorisez 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).

  Type de source = CIDR, Source CIDR = 0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination Port Range = 22

  Vous pouvez également restreindre l'accès de l'hôte bastion sur Internet sur le port 22 uniquement à partir de votre centre de données au lieu d'Internet public (0.0.0.0/0). Pour ce faire, utilisez votre adresse IP de routeur de bordure au lieu de CIDR source comme 0.0.0.0/0 dans la règle d'entrée avec statut.

• Pour autoriser tout le trafic à partir de l'hôte bastion vers Oracle Cloud Infrastructure, procédez comme suit :

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

  Type de destination = CIDR, Destination CIDR = < Bloc CIDR de VCN>, Protocole IP = TCP, Plage de ports source = Tous, Plage de ports de destination = Tous

Vous pouvez ajouter ou supprimer des règles à partir du groupe de sécurité réseau en fonction de vos besoins. En outre, indiquez les ports sur lesquels vous souhaitez accéder aux serveurs d'applications Java et aux serveurs Application Interface Services.

Groupe de sécurité réseau pour le niveau d'administration

• Entrée avec statut : autorise le trafic TCP sur le port de destination 22 (SSH) à partir du bloc CIDR source de VCN et de tout port source.

• Entrée avec statut : bloc CIDR source de VCN sur TCP, port source = tout, port de destination = 445, 5985, 14501-14510, 3000, 8998–8999, 5150

• Sortie avec état : Autoriser tout le trafic.

Groupe de sécurité réseau pour le niveau d'équilibreur de charge

L'architecture contient des équilibreurs de charge privés 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 depuis Internet vers les instances d'équilibreur de charge.

• Entrée avec statut : bloc CIDR source de VCN et du réseau sur site sur TCP, port source = tous, port de destination = ports sur lesquels vous avez créé un processus d'écoute dans les instances d'équilibreur de charge

• Sortie avec état : Autoriser tout le trafic.

Groupe de sécurité réseau pour le niveau de présentation

• Pour autoriser le trafic à partir de l'environnement sur site et de VCN vers le sous-réseau de niveau présentation, procédez comme suit :

  Entrée avec statut : bloc CIDR source du réseau VCN et sur site sur TCP, port source = all, port de destination = 14501–14510, 5150, port serveur d'administration Weblogic, ports serveur Web

• Entrée avec statut : bloc CIDR source de VCN sur TCP, port source = all, port de destination = 22 (SSH)

• Pour autoriser le trafic à partir du sous-réseau de niveau présentation vers le sous-réseau de niveau intermédiaire, procédez comme suit :

  Sortie avec conservation de statut : source 0.0.0.0/0 sur TCP, port source = all, port de destination = all

En outre, indiquez les ports sur lesquels vous souhaitez accéder aux serveurs Java Application et Application Interface Services, ainsi que les ports sur lesquels vous souhaitez accéder aux serveurs Oracle Business Intelligence Publisher.

Groupe de sécurité réseau pour le niveau intermédiaire

• Pour autoriser le trafic à partir de l'environnement sur site et de VCN vers le sous-réseau de niveau intermédiaire, procédez comme suit :

  Entrée avec statut : bloc CIDR source de VCN et sur site sur TCP, port source = all, port de destination = 6017-6023, 14502-14510, 5150

• Entrée avec statut : bloc CIDR source de VCN sur TCP, port source = all, port de destination = 22 (SSH)

• Pour autoriser le trafic du sous-réseau de niveau intermédiaire vers le sous-réseau de niveau présentation :

  Sortie avec conservation de statut : source 0.0.0.0/0 sur TCP, port source = all, port de destination = all

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

• Pour autoriser le trafic de l'hôte bastion au niveau de la base de données :

  Entrée avec statut : bloc CIDR source de l'hôte bastion sur TCP, port source = all, port de destination = 22

• Pour autoriser le trafic du niveau intermédiaire au niveau de base de données, procédez comme suit :

  Entrée avec statut : bloc CIDR source des niveaux intermédiaires sur TCP, port source = all, port de destination = 1521

• Pour autoriser le trafic à partir de l'environnement sur site et de VCN vers le sous-réseau de niveau présentation :

  Entrée avec statut : bloc CIDR source de VCN sur TCP, port source = all, port de destination = 14502–14510, 5150

• Pour autoriser le trafic du niveau de base de données au niveau intermédiaire, procédez comme suit :

  Sortie avec conservation de statut : Destination 0.0.0.0/0 sur TCP, port source = all, port de destination = all