En savoir plus sur le déploiement de PeopleSoft sur Oracle Cloud Infrastructure

Si vous souhaitez provisionner les applications PeopleSoft d'Oracle sur Oracle Cloud Infrastructure ou migrer des environnements PeopleSoft de votre centre de données vers Oracle Cloud Infrastructure, vous pouvez planifier une topologie multihôte, sécurisée et à haute disponibilité.

Remarques concernant le déploiement dans Oracle Cloud Infrastructure

Oracle recommande de créer des sous-réseaux distincts pour vos instances, tels que l'hôte de base, 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 sur 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 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 y accéder à partir d'Internet. Vous ne pouvez pas affecter une adresse IP publique aux instances créées dans un sous-réseau privé. Vous ne pouvez donc pas accéder à ces instances via Internet.

L'image suivante montre un réseau cloud virtuel (VCN) avec des sous-réseaux publics et privés. VCN comprend deux domaines de disponibilité, chacun d'entre eux étant 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 possèdent une adresse IP publique associée. 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 d'acheminement afin d'activer le trafic vers et depuis 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 de base dans un sous-réseau public et accéder à l'hôte de base à 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 d'Oracle Cloud dans le sous-réseau privé à partir de vos centres de données en vous connectant via la passerelle de routage dynamique (DRG). DRG est la passerelle qui connecte votre réseau on-premise à votre réseau cloud. Pour permettre la communication entre l'équipement de DRG et de l'équipement sur site client, utilisez le VPN IPSec ou Oracle Cloud Infrastructure FastConnect. Vous devrez également mettre à jour la table de routage afin d'activer le trafic vers et depuis DRG.

Description de l'illustration 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 les sous-réseaux privés pour les environnements de production, sans adresse Internet. Ce type de déploiement est utile lorsque vous voulez disposer d'un déploiement hybride avec le cloud sous forme d'extension de vos centres de données existants.

Dans ce déploiement, toutes les instances, y compris les serveurs d'application 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 à des instances créées dans un sous-réseau privé, vous ne pouvez donc pas accéder à ces instances via Internet. Pour accéder aux 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 de base dans cette configuration, puis accédez à tous les serveurs du sous-réseau privé à partir de l'hôte de base.

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 certaines dans un sous-réseau privé. Ce type de déploiement est utile lorsque le déploiement inclut des adresses Internet et non orientées message.

Dans cette configuration, certaines instances d'application sont placées dans un sous-réseau public, tandis que d'autres sont placées dans un sous-réseau privé. Par exemple, vous pouvez disposer d'instances d'application traitant des utilisateurs internes et d'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 les serveurs d'applications qui traitent 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 traitent le trafic externe dans un sous-réseau public. Si vous placez l'hôte de base dans un sous-réseau public, une adresse IP publique est affectée à l'hôte de base et vous pouvez y accéder via Internet. Vous pouvez accéder à vos instances dans le sous-réseau privé via le serveur de base.

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 productions sans adresse interne. Ce déploiement est adapté uniquement si vous ne disposez pas de votre propre centre de données, ou que vous ne pouvez pas accéder aux instances sur VPN et que vous souhaitez 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 les sous-réseaux publics.

Chaque instance du sous-réseau public dispose d'une adresse IP publique associée. Bien que les instances dotées d'adresses IP publiques soient accessibles via Internet, vous pouvez restreindre l'accès à l'aide de listes de sécurité et de règles de sécurité. Pour effectuer les tâches d'administration, Oracle recommande de placer un hôte de base dans cette configuration. Dans ce scénario, vous n'ouvrirez pas les ports d'administration sur le réseau Internet public, mais vous ne pourrez ouvrir les ports d'administration que sur les listes bastion et configurer la sécurité, ni vérifier que l'instance est accessible uniquement à partir de l'hôte de base.

Anti-affinité

Lors de la création de plusieurs instances pour la haute disponibilité dans un domaine de disponibilité sur Oracle Cloud Infrastructure, les anti-affinités pour les instances peuvent être obtenues à l'aide de domaines de pannes.

Un domaine de pannes est un regroupement de matériel et d'infrastructure au sein d'un domaine de disponibilité. Chaque domaine de disponibilité contient trois domaines de pannes. Les domaines de pannes vous permettent de distribuer vos instances de sorte qu'elles ne soient pas sur le même matériel physique au sein d'un seul domaine de disponibilité. Une panne matérielle ou la maintenance matérielle Oracle Compute affectant un domaine de pannes n'affecte donc pas les instances des autres domaines de pannes. L'utilisation de domaines de pannes vous permet de protéger vos instances contre les pannes matérielles inattendues et les interruptions de service planifiées.

Pour une 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-node. Les deux noeuds d'Oracle RAC sont toujours créés dans des domaines de pannes distincts par défaut. 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 les défaillances de commutateur du rack.

Architecture

Découvrez les concepts clés que vous pouvez utiliser pour planifier ces options de déploiement pour PeopleSoft :

Architecture permettant de déployer PeopleSoft dans un domaine de disponibilité unique, tout en garantissant une haute disponibilité. Utilisez cette architecture pour vous assurer que votre application est disponible même lorsqu'une instance d'application s'arrête. Les autres instances d'application disponibles du domaine de disponibilité continuent à traiter les demandes.
Architecture permettant de déployer PeopleSoft dans plusieurs domaines de disponibilité tout en garantissant une haute disponibilité. Utilisez cette architecture pour vous assurer que votre application est disponible même lorsqu'un domaine de disponibilité tombe en panne. Vous pouvez toujours accéder aux instances d'application dans un autre domaine de disponibilité.
Architecture permettant de déployer PeopleSoft tout en garantissant une haute disponibilité et une récupération après sinistre. Utilisez cette architecture lorsque vous voulez configurer un site de récupération après sinistre pour votre application dans une autre région.

L'architecture est valide pour les déploiements PeopleSoft effectués manuellement ou à l'aide d'outils d'automatisation PeopleSoft sur Oracle Cloud Infrastructure.

Tous les diagrammes d'architecture sont recommandés, car vous ne souhaitez pas accéder à vos hôtes de base de données et d'application sur Internet.

Architecture pour le déploiement de PeopleSoft dans un domaine de disponibilité unique

Cette architecture montre le déploiement d'une application PeopleSoft dans un domaine de disponibilité unique, tout en garantissant une haute disponibilité.

L'architecture est composée d'un annuaire VCN avec les hôtes de base, d'équilibreur de charge, d'application et de base de données placés dans des sous-réseaux distincts de VCN dans un domaine de disponibilité unique. L'hôte de base 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 différentes instances dans des sous-réseaux publics ou privés en fonction des exigences de votre entreprise. Vous pouvez accéder aux instances dans les sous-réseaux privés sur le port 22 via l'hôte de base ou DRG si vous avez configuré un tunnel VPN IPSec entre votre centre de données et Oracle Cloud Infrastructure DRG.

Dans cette architecture, les instances redondantes sont déployées dans le niveau application et le niveau base de données afin d'assurer une haute disponibilité dans le domaine de disponibilité. Cela garantit que votre application est disponible même lorsqu'une instance d'application s'arrête. Les autres instances d'application disponibles du domaine de disponibilité continuent à traiter les demandes. Toutes les instances d'application du domaine de disponibilité sont actives. Les instances d'équilibreur de charge reçoivent des demandes et les envoie aux serveurs d'applications. 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 permettent de distribuer vos instances de sorte qu'elles ne se trouvent pas sur le même matériel physique au sein d'un seul domaine de disponibilité. Une panne matérielle ou une maintenance matérielle affectant un domaine de pannes n'affecte donc pas les instances des autres domaines de pannes.

Les instances du sous-réseau privé exigent une connexion sortante à Internet pour télécharger les patches, ainsi que pour appliquer les mises à jour de système d'exploitation et d'application. Pour ce faire, utilisez une passerelle NAT (Network Address Translation) dans VCN. Avec une passerelle NAT, les hôtes du sous-réseau privé peuvent lancer 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 fiable 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 sur 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 exige 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 à l'aide de la même clé maître que celle employé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 30-day. Vous pouvez également effectuer une sauvegarde complète à la demande des bases de données pour répondre aux exigences 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 permet d'effectuer des sauvegardes de volume automatiquement en fonction d'un planning et de les conserver en fonction de la stratégie de sauvegarde sélectionnée. Vous pouvez ainsi respecter les exigences réglementaires et de conformité des données. Il existe trois stratégies de sauvegarde prédéfinies : Bronze, Silver et Gold. Chaque stratégie de sauvegarde comporte une fréquence de sauvegarde et une durée de conservation prédéfinies.

Description de l'illustration peoplesoft_single_availability_domain_ha_topology.png

Cette architecture est divisée en plusieurs niveaux :

Hôte de base : l'hôte de base est un composant facultatif que vous pouvez utiliser en tant que serveur jump pour accéder aux instances dans le sous-réseau privé.
Niveau d'équilibreur de charge : ce niveau contient les instances Oracle Cloud Infrastructure Load Balancing qui équilibrent la charge du trafic sur les serveurs Web PeopleSoft. L'équilibreur de charge reçoit les demandes des utilisateurs, puis les achemine vers le niveau Applications.
Niveau Applications : ce niveau contient des instances redondantes des serveurs d'applications PeopleSoft, des serveurs Web PeopleSoft, des serveurs ElasticSearch et PeopleSoft Process Scheduler pour une haute disponibilité. Configurez des instances redondantes de tous les serveurs dans le niveau Applications pour pouvoir accéder à l'application même si une instance s'arrête.
Client PeopleTools : utilisez le client PeopleTools pour effectuer des activités d'administration, telles que le développement, la migration et la mise à niveau.
Niveau base de données : ce niveau contient les instances système de base de données Oracle Cloud Infrastructure. Pour répondre aux 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 de Oracle Cloud Infrastructure.

Architecture pour le déploiement de PeopleSoft dans plusieurs domaines de disponibilité

Cette architecture affiche le déploiement de serveurs d'applications PeopleSoft dans plusieurs domaines de disponibilité. Il affiche un annuaire VCN avec les hôtes de base, d'équilibreur de charge, d'application et de base de données placés dans des sous-réseaux distincts sur deux domaines de disponibilité.

Dans le diagramme de l'architecture, l'hôte de base 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 exigences métier. Vous pouvez accéder aux instances dans les sous-réseaux privés sur le port 22 via l'hôte de base ou DRG si vous avez configuré un tunnel VPN IPSec entre votre centre de données et Oracle Cloud Infrastructure DRG. Toutes les instances sont actives dans les deux domaines de disponibilité. Les seuls composants passifs de l'architecture sont les hôtes de base de données du domaine de disponibilité 2.

Les hôtes de base du domaine de disponibilité 1 et du domaine de disponibilité 2 sont actifs et peuvent traiter simultanément des demandes SSH aux instances dans les deux domaines de disponibilité. Le service DNS sur site ou le service DNS externe reçoit la demande pour l'application PeopleSoft. Ces demandes sont équilibrées avec équilibrage de charge circulaire sur l'un des équilibreurs de charge dans le domaine de disponibilité 1 ou 2. Le programme d'équilibrage de charge achemine ensuite la demande vers l'un des serveurs Web PeopleSoft sous-jacents dans le domaine de disponibilité 1 ou 2. Le serveur Web PeopleSoft achemine ensuite sa demande vers l'un des serveurs d'applications PeopleSoft, puis enfin le serveur d'applications retransmet les demandes aux instances de base de données actives dans le domaine de disponibilité 1 pour traitement.

Si le domaine de disponibilité 1 n'est pas disponible, vous devez enlever manuellement l'entrée du programme d'équilibrage de charge du domaine de disponibilité 1 du service DNS, et basculer vers les instances de base de données du domaine de disponibilité 2. Les demandes reçues du service DNS sont désormais acheminées vers le programme d'équilibrage de charge dans le domaine de disponibilité 2, puis vers la base de données dans le domaine de disponibilité 2 pour traitement.

Description de peoplesoft_multiple_availability_domain_ha_topology.png

Description de l'illustration peoplesoft_multiple_availability_domain_ha_topology.png

Hôte de base : un hôte de base est un composant facultatif que vous pouvez provisionner dans chaque domaine de disponibilité pour agir en tant qu'hôte de jump afin d'accéder aux instances d'application et de base de données. Les hôtes de base du domaine de disponibilité 1 et du domaine de disponibilité 2 sont actifs.
Instances d'équilibreur de charge : les instances Oracle Cloud Infrastructure Load Balancing distribuent le trafic sur les serveurs d'applications dans les deux domaines de disponibilité. Les instances d'équilibreur de charge des domaines de disponibilité 1 et 2 sont actives. Les demandes reçues à l'URL PeopleSoft sont équilibrées avec une charge circulaire sur un équilibreur de charge dans le domaine de disponibilité 1 ou 2 par un service DNS externe ou sur site.
Niveau application : le domaine de disponibilité 1 et le domaine de disponibilité 2 contiennent des instances redondantes du serveur d'applications PeopleSoft, du serveur Web PeopleSoft, des serveurs ElasticSearch et de PeopleSoft Process Scheduler. Toutes les instances du niveau d'application des deux domaines de disponibilité ont l'état Actif.
Client PeopleTools : utilisez le client PeopleTools pour effectuer des activités d'administration, telles que le développement, la migration et la mise à niveau.
Niveau base de données : nombre d'instances de base de données hautement disponibles dans les deux domaines de disponibilité. Le domaine de disponibilité 1 héberge les instances de base de données principale. Le domaine de disponibilité 2 héberge les instances de base de données de secours. Dans chaque domaine de disponibilité, au moins deux instances de base de données sont configurées pour garantir la haute disponibilité. Si une instance de base de données n'est pas disponible dans le domaine de disponibilité 1, la seconde instance de base de données du domaine de disponibilité 1 poursuit le traitement des demandes.

Utilisez Oracle Active Data Guard en mode synchrone pour répliquer la base de données entre les domaines de disponibilité d'une région.

Architecture pour le déploiement de PeopleSoft dans plusieurs régions

Cette architecture montre le déploiement des serveurs d'applications PeopleSoft dans plusieurs régions, tout en garantissant une haute disponibilité et une récupération après sinistre. Il montre un annuaire VCN avec les instances de base, d'équilibreur de charge, d'application et de base de données placées dans des sous-réseaux distincts sur deux régions. Pour vous assurer que vous pouvez accéder aux instances d'application PeopleSoft, même lorsque tous les domaines de disponibilité d'une région sont arrêtés, déployez PeopleSoft sur plusieurs régions.

Le diagramme d'architecture affiche deux régions. Dans la région 1, PeopleSoft est déployé dans plusieurs domaines de disponibilité afin d'assurer la haute disponibilité des domaines de disponibilité au sein d'une région. La région 2 est la région de récupération après sinistre. Toutes les instances sont actives dans les deux domaines de disponibilité de la région 1. Les composants passifs de l'architecture sont les hôtes de base de données du domaine de disponibilité 2 et toutes les instances de la région 2. Oracle recommande que le nombre d'instances déployées pour chaque niveau du domaine de disponibilité de la région 2 soit identique au nombre d'instances déployées dans un domaine de disponibilité de la région 1. Cela garantit que les instances d'application peuvent prendre la charge entière après l'appel de la récupération après sinistre.

Cette architecture peut également être déployée dans un seul domaine de disponibilité de la région 1 et un domaine de disponibilité dans la région 2 pour la récupération après sinistre. Toutefois, cette architecture ne fournit pas de tolérance aux pannes pour le domaine de disponibilité dans la région 1. Si le seul domaine de disponibilité où l'application a été déployée n'est pas disponible, vous devrez appeler la récupération après sinistre pour basculer votre application vers la région 2.

Dans la région 1, les hôtes de base du domaine de disponibilité 1 et du domaine de disponibilité 2 sont actifs et peuvent traiter en permanence des demandes SSH aux instances dans les deux domaines de disponibilité. Le service DNS sur site ou le service DNS externe reçoit la demande pour l'application PeopleSoft. Ces demandes sont équilibrées avec équilibrage de charge circulaire sur l'un des équilibreurs de charge dans le domaine de disponibilité 1 ou 2. Le programme d'équilibrage de charge achemine ensuite la demande vers l'un des serveurs Web PeopleSoft sous-jacents dans le domaine de disponibilité 1 ou 2. Le serveur Web PeopleSoft achemine ensuite sa demande vers l'un des serveurs d'applications PeopleSoft, puis enfin le serveur d'applications retransmet les demandes aux instances de base de données actives dans le domaine de disponibilité 1 pour traitement.

Si les instances de la région 1 ne sont pas disponibles, vous devez basculer manuellement vers les instances de la région 2. Dans ce scénario, l'équilibreur de charge et les instances de base de données de la région 2 agissent en tant qu'équilibreur de charge principal et d'instances de base de données. Les demandes reçues à l'URL PeopleSoft sont acheminées vers le programme d'équilibrage de charge de la région 2, qui achemine ensuite le trafic vers le serveur Web PeopleSoft sous-jacent dans la région 2. Les serveurs Web PeopleSoft acheminent la demande vers les instances d'application PeopleSoft, puis les serveurs d'applications PeopleSoft transmettent les demandes aux instances de base de données dans la région 2 pour traitement.

Dans le diagramme d'architecture, l'hôte de base et l'équilibreur de charge sont déployés dans les sous-réseaux publics et toutes les autres instances sont déployées dans les sous-réseaux privés. Vous pouvez placer les instances dans des sous-réseaux publics ou privés en fonction de vos exigences métier. Vous pouvez accéder aux instances dans les sous-réseaux privés sur le port 22 via l'hôte de base ou DRG si vous avez configuré un tunnel VPN IPSec entre votre centre de données et Oracle Cloud Infrastructure DRG.

Description de peoplesoft_multiple_regions_ha_topology.png

Description de l'illustration peoplesoft_multiple_regions_ha_topology.png

Cette architecture prend en charge les composants suivants :

Hôte de base : un hôte de base est un composant facultatif que vous pouvez provisionner dans chaque domaine de disponibilité pour agir en tant qu'hôte de jump afin d'accéder aux instances d'application et de base de données. Les hôtes de base du domaine de disponibilité 1 et du domaine de disponibilité 2 sont actifs.
Instances d'équilibreur de charge : les instances Oracle Cloud Infrastructure Load Balancing distribuent le trafic sur les serveurs d'applications dans les deux domaines de disponibilité. Le domaine de disponibilité 1 et 2 de la région 1 héberge les instances du programme d'équilibrage de charge principal.
Niveau Applications : le domaine de disponibilité 1 et le domaine de disponibilité 2 de la région 1 contiennent au moins une instance du serveur d'applications PeopleSoft, du serveur Web PeopleSoft, des serveurs ElasticSearch et de PeopleSoft Process Scheduler. Toutes les instances dans les deux domaines de disponibilité de la région 1 sont à l'état actif. Les instances de niveau application de la région 2 sont dans l'état passif. Pour synchroniser les serveurs d'applications entre les domaines de disponibilité et les différentes régions, utilisez rsync.
Client PeopleTools : utilisez le client PeopleTools pour effectuer des activités d'administration, telles que le développement, la migration et la mise à niveau.
Niveau base de données : le domaine de disponibilité 1 de la région 1 héberge les instances de base de données principale. Le domaine de disponibilité 2 dans la région 1 et la région 2 hébergent les instances de base de données de secours. Dans chaque domaine de disponibilité, au moins deux instances de base de données sont configurées pour garantir la haute disponibilité. Si une instance de base de données est arrêtée dans le domaine de disponibilité 1, la seconde instance de base de données du domaine de disponibilité 1 poursuit le traitement des demandes. Si la région 1 n'est pas disponible, les instances de base de données de la région 2 traitent les demandes.

Oracle recommande d'utiliser Oracle Active Data Guard en mode synchrone pour répliquer la base de données entre les domaines de disponibilité dans une région. Pour répliquer une base de données entre différentes régions, utilisez Oracle Active Data Guard en mode asynchrone.