Configurez une PeopleSoft architecture à haute disponibilité sur AWS - Recommandations AWS

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Configurez une PeopleSoft architecture à haute disponibilité sur AWS

Créée par Ramanathan Muralidhar () AWS

Environnement : Production

Technologies : productivité des entreprises ; infrastructure ; applications Web et mobiles ; bases de données

Charge de travail : Oracle

AWSservices : Amazon EC2 Auto Scaling ; Amazon EFS ; Elastic Load Balancing (ELB) ; Amazon RDS

Récapitulatif

Lorsque vous migrez vos PeopleSoft charges de travail versAWS, la résilience est un objectif important. Cela garantit que votre PeopleSoft application est toujours hautement disponible et capable de se remettre rapidement en cas de panne.

Ce modèle fournit une architecture pour vos PeopleSoft applications AWS afin de garantir la haute disponibilité (HA) au niveau du réseau, de l'application et de la base de données. Il utilise une base de données Amazon Relational Database Service (RDSAmazon) pour Oracle ou RDS Amazon SQL for Server pour le niveau de base de données. Cette architecture inclut également AWS des services tels qu'Amazon Route 53, les instances Linux Amazon Elastic Compute Cloud (AmazonEC2), Amazon Elastic Block Storage (AmazonEBS), Amazon Elastic File System (AmazonEFS) et un Application Load Balancer. Elle est évolutive.

Oracle PeopleSoft fournit une suite d'outils et d'applications pour la gestion des effectifs et d'autres opérations commerciales.

Conditions préalables et limitations

Prérequis

  • Un AWS compte actif

  • Un PeopleSoft environnement doté des licences nécessaires pour le configurer AWS

  • Un cloud privé virtuel (VPC) configuré dans votre AWS compte avec les ressources suivantes :

    • Au moins deux zones de disponibilité

    • Un sous-réseau public et trois sous-réseaux privés dans chaque zone de disponibilité

    • Une NAT passerelle et une passerelle Internet

    • Tables de routage pour chaque sous-réseau afin d'acheminer le trafic

    • Listes de contrôle d'accès réseau (réseauACLs) et groupes de sécurité définis pour garantir la sécurité de l' PeopleSoft application conformément aux normes de votre entreprise

Limites

  • Ce modèle fournit une solution de haute disponibilité (HA). Il ne prend pas en charge les scénarios de reprise après sinistre (DR). Dans les rares cas où l'ensemble de la AWS région pour la mise en œuvre de la HA tombe en panne, l'application deviendra indisponible.

Versions du produit

  • PeopleSoft applications exécutant PeopleTools 8.52 et versions ultérieures

Architecture

Architecture cible

Les interruptions ou pannes de votre application de PeopleSoft production ont un impact sur la disponibilité de l'application et perturbent considérablement votre activité.

Nous vous recommandons de concevoir votre application PeopleSoft de production de manière à ce qu'elle soit toujours hautement disponible. Vous pouvez y parvenir en éliminant les points de défaillance uniques, en ajoutant des points de croisement ou de basculement fiables et en détectant les défaillances. Le schéma suivant illustre une architecture HA pour PeopleSoft onAWS.

Architecture hautement disponible pour PeopleSoft sur AWS

Ce déploiement d'architecture utilise Amazon RDS pour Oracle comme PeopleSoft base de données et EC2 des instances exécutées sur Red Hat Enterprise Linux (RHEL). Vous pouvez également utiliser Amazon RDS for SQL Server comme base de données Peoplesoft.

Cette architecture contient les composants suivants : 

Détails de l'architecture

La PeopleSoft base de données est hébergée dans une base de données Amazon RDS for Oracle (ou Amazon RDS for SQL Server) dans une configuration multi-AZ. La fonctionnalité Amazon RDS Multi-AZ reproduit les mises à jour de base de données sur deux zones de disponibilité afin d'accroître la durabilité et la disponibilité. Amazon RDS bascule automatiquement vers la base de données de secours pour les opérations de maintenance planifiées et les interruptions imprévues.

Le PeopleSoft Web et le niveau intermédiaire sont installés sur les EC2 instances. Ces instances sont réparties sur plusieurs zones de disponibilité et liées par un groupe Auto Scaling. Cela garantit que ces composants sont toujours hautement disponibles. Un nombre minimum d'instances requises est maintenu afin de garantir que l'application est toujours disponible et qu'elle peut évoluer en cas de besoin.

Nous vous recommandons d'utiliser un type d'EC2instance de génération actuelle pour les OEM EC2 instances. Les types d'instances de la génération actuelle, tels que les instances basées sur le système AWS Nitro, prennent en charge les machines virtuelles matérielles (HVMs). Ils HVM AMIs sont nécessaires pour tirer parti d'une mise en réseau améliorée, et ils offrent également une sécurité accrue. Les EC2 instances qui font partie de chaque groupe Auto Scaling utilisent les leurs AMI lors du remplacement ou de la mise à l'échelle des instances. Nous vous recommandons de sélectionner les types d'EC2instances en fonction de la charge que vous souhaitez que votre PeopleSoft application gère et des valeurs minimales recommandées par Oracle pour votre PeopleSoft application et votre PeopleTools version. Pour plus d'informations sur les exigences matérielles et logicielles, consultez le site Web de support d'Oracle.

Le PeopleSoft Web et le niveau intermédiaire partagent un EFS support Amazon pour partager des rapports, des fichiers de données et (si nécessaire) le PS_HOME répertoire. Amazon EFS est configuré avec des cibles de montage dans chaque zone de disponibilité pour des raisons de performances et de coûts.

Un Application Load Balancer est configuré pour prendre en charge le trafic qui accède à l' PeopleSoft application et pour équilibrer la charge du trafic entre les serveurs Web des différentes zones de disponibilité. Un Application Load Balancer est un périphérique réseau qui fournit une haute disponibilité dans au moins deux zones de disponibilité. Les serveurs Web distribuent le trafic aux différents serveurs d'applications en utilisant une configuration d'équilibrage de charge. L'équilibrage de charge entre le serveur Web et le serveur d'applications garantit une répartition uniforme de la charge entre les instances et permet d'éviter les blocages et les interruptions de service dus à des instances surchargées.

Amazon Route 53 est utilisé comme DNS service pour acheminer le trafic vers l'Application Load Balancer depuis Internet. Route 53 est un service DNS Web hautement disponible et évolutif.

Détails du HA

  • Bases de données : la fonctionnalité Multi-AZ d'Amazon RDS gère deux bases de données dans plusieurs zones de disponibilité avec réplication synchrone. Cela crée un environnement hautement disponible avec basculement automatique. Amazon RDS dispose d'un système de détection des événements de basculement et lance un basculement automatique lorsque ces événements se produisent. Vous pouvez également lancer un basculement manuel via Amazon RDSAPI. Pour une explication détaillée, consultez le billet de blog Amazon RDS Under The Hood : Multi-AZ. Le basculement est fluide et l'application se reconnecte automatiquement à la base de données lorsque cela se produit. Cependant, toute tâche du planificateur de processus pendant le basculement génère des erreurs et doit être soumise à nouveau.

  • PeopleSoft serveurs d'applications : les serveurs d'applications sont répartis sur plusieurs zones de disponibilité et un groupe Auto Scaling est défini pour eux. En cas de défaillance d'une instance, le groupe Auto Scaling la remplace immédiatement par une instance saine clonée à partir du modèle AMI de serveur d'applications. Plus précisément, le jolt pooling est activé. Ainsi, lorsqu'une instance de serveur d'applications tombe en panne, les sessions basculent automatiquement vers un autre serveur d'applications, et le groupe Auto Scaling lance automatiquement une autre instance, ouvre le serveur d'applications et l'enregistre dans le EFS support Amazon. Le serveur d'applications nouvellement créé est automatiquement ajouté aux serveurs Web à l'aide du PSSTRSETUP.SH script sur les serveurs Web. Cela garantit que le serveur d'applications est toujours hautement disponible et qu'il se rétablit rapidement en cas de panne.

  • Planificateurs de processus : les serveurs des planificateurs de processus sont répartis sur plusieurs zones de disponibilité et un groupe Auto Scaling leur est défini. En cas de défaillance d'une instance, le groupe Auto Scaling la remplace immédiatement par une instance saine clonée à partir du modèle AMI de serveur du planificateur de processus. Plus précisément, lorsqu'une instance du planificateur de processus tombe en panne, le groupe Auto Scaling lance automatiquement une autre instance et ouvre le planificateur de processus. Toutes les tâches en cours d'exécution au moment de l'échec de l'instance doivent être soumises à nouveau. Cela garantit que le planificateur de processus est toujours hautement disponible et qu'il se rétablit rapidement en cas de panne.

  • Serveurs Elasticsearch : un groupe Auto Scaling est défini pour les serveurs Elasticsearch. En cas de défaillance d'une instance, le groupe Auto Scaling la remplace immédiatement par une instance saine clonée à partir du modèle AMI du serveur Elasticsearch. Plus précisément, lorsqu'une instance Elasticsearch tombe en panne, l'Application Load Balancer qui répond aux demandes détecte la défaillance et arrête de lui envoyer du trafic. Le groupe Auto Scaling lance automatiquement une autre instance et fait apparaître l'instance Elasticsearch. Lorsque l'instance Elasticsearch est sauvegardée, l'Application Load Balancer détecte qu'elle est saine et recommence à lui envoyer des requêtes. Cela garantit que le serveur Elasticsearch est toujours hautement disponible et qu'il se rétablit rapidement en cas de panne.

  • Serveurs Web : un groupe Auto Scaling est défini pour les serveurs Web. Si une instance échoue, le groupe Auto Scaling la remplace immédiatement par une instance saine clonée à partir AMI du modèle de serveur Web. Plus précisément, lorsqu'une instance de serveur Web tombe en panne, l'Application Load Balancer qui répond aux demandes détecte la défaillance et arrête de lui envoyer du trafic. Le groupe Auto Scaling lance automatiquement une autre instance et fait apparaître l'instance du serveur Web. Lorsque l'instance du serveur Web est sauvegardée, l'Application Load Balancer détecte qu'elle est saine et recommence à lui envoyer des requêtes. Cela garantit que le serveur Web est toujours hautement disponible et qu'il se rétablit rapidement en cas de panne.

Outils

AWSservices

Bonnes pratiques

Bonnes pratiques opérationnelles

  • Lorsque vous PeopleSoft roulez dessusAWS, utilisez la Route 53 pour acheminer le trafic depuis Internet et localement. Utilisez l'option failover pour rediriger le trafic vers le site de reprise après sinistre (DR) si l'instance de base de données principale n'est pas disponible.

  • Utilisez toujours un Application Load Balancer devant l' PeopleSoft environnement. Cela garantit l'équilibrage de charge du trafic vers les serveurs Web de manière sécurisée.

  • Dans les paramètres du groupe cible Application Load Balancer, assurez-vous que l'adhérence est activée à l'aide d'un cookie généré par l'équilibreur de charge.

    Remarque : vous devrez peut-être utiliser un cookie basé sur une application si vous utilisez l'authentification unique externe (). SSO Cela garantit la cohérence des connexions entre les serveurs Web et les serveurs d'applications.

  • Pour une application PeopleSoft de production, le délai d'inactivité de l'Application Load Balancer doit correspondre à celui défini dans le profil Web que vous utilisez. Cela empêche les sessions utilisateur d'expirer au niveau de la couche d'équilibrage de charge.

  • Pour une application PeopleSoft de production, définissez le taux de recyclage du serveur d'applications sur une valeur qui minimise les fuites de mémoire.

  • Si vous utilisez une RDS base de données Amazon pour votre application PeopleSoft de production, comme décrit dans ce modèle, exécutez-la au format multi-AZ pour une haute disponibilité.

  • Si votre base de données est exécutée sur une EC2 instance de votre application PeopleSoft de production, assurez-vous qu'une base de données de secours est exécutée sur une autre zone de disponibilité pour garantir une haute disponibilité.

  • Pour la reprise après sinistre, assurez-vous que votre RDS base de données ou EC2 instance Amazon dispose d'une instance de secours configurée dans une AWS région distincte de celle de la base de données de production. Cela garantit qu'en cas de sinistre dans la région, vous pouvez transférer l'application vers une autre région.

  • Pour la reprise après sinistre, utilisez Amazon Elastic Disaster Recovery pour configurer les composants au niveau de l'application dans une région distincte de celle des composants de production. Cela garantit qu'en cas de sinistre dans la région, vous pouvez transférer l'application vers une autre région.

  • Utilisez Amazon EFS (pour les exigences d'E/S modérées) ou Amazon FSx (pour les exigences d'E/S élevées) pour stocker vos PeopleSoft rapports, pièces jointes et fichiers de données. Cela garantit que le contenu est stocké dans un emplacement central et qu'il est accessible depuis n'importe quel endroit de l'infrastructure.

  • Utilisez Amazon CloudWatch (de base et détaillé) pour surveiller les ressources AWS cloud utilisées par votre PeopleSoft application en temps quasi réel. Cela garantit que vous êtes immédiatement alerté des problèmes et que vous pouvez les résoudre rapidement avant qu'ils n'affectent la disponibilité de l'environnement.

  • Si vous utilisez une base de RDS données Amazon comme base de PeopleSoft données, utilisez Enhanced Monitoring. Cette fonctionnalité permet d'accéder à plus de 50 indicateurs, notamment la mémoireCPU, les E/S du système de fichiers et les E/S du disque.

  • AWS CloudTrailÀ utiliser pour surveiller les API appels sur les AWS ressources utilisées par votre PeopleSoft application. Cela vous permet d'effectuer une analyse de sécurité, un suivi des modifications des ressources et un audit de conformité.

Bonnes pratiques de sécurité

  • Pour protéger votre PeopleSoft application contre les exploits courants tels que l'SQLinjection ou le cross-site scripting (XSS), utilisez. AWSWAF Envisagez d'utiliser AWSShield Advanced pour des services de détection et d'atténuation sur mesure.

  • Ajoutez une règle à l'Application Load Balancer pour rediriger HTTPS automatiquement le trafic de HTTP vers afin de sécuriser votre PeopleSoft application.

  • Configurez un groupe de sécurité distinct pour l'Application Load Balancer. Ce groupe de sécurité doit autoriser HTTPS uniquement le trafic HTTP entrant et aucun trafic sortant. Cela garantit que seul le trafic prévu est autorisé et contribue à sécuriser votre application.

  • Utilisez des sous-réseaux privés pour les serveurs d'applications, les serveurs Web et les bases de données, et utilisez des NATpasserelles pour le trafic Internet sortant. Cela garantit que les serveurs qui prennent en charge l'application ne sont pas accessibles au public, tout en fournissant un accès public uniquement aux serveurs qui en ont besoin.

  • Utilisez différents VPCs pour exécuter vos environnements PeopleSoft de production et de non-production. Utilisez AWSTransit Gateway, le VPCpeering, le réseau ACLs et les groupes de sécurité pour contrôler le flux de trafic entre le VPCs et, si nécessaire, votre centre de données sur site.

  • Respectez le principe du moindre privilège. N'accordez l'accès aux AWS ressources utilisées par l' PeopleSoft application qu'aux utilisateurs qui en ont absolument besoin. Accordez uniquement les privilèges minimaux requis pour effectuer une tâche. Pour plus d'informations, consultez le pilier de sécurité du AWS Well-Architected Framework.

  • Dans la mesure du possible, utilisez AWSSystems Manager pour accéder aux EC2 instances utilisées par l' PeopleSoft application.

Bonnes pratiques en matière de fiabilité

  • Lorsque vous utilisez un Application Load Balancer, enregistrez une cible unique pour chaque zone de disponibilité activée. Cela rend l'équilibreur de charge le plus efficace.

  • Nous vous recommandons d'en avoir trois distincts URLs pour chaque environnement de PeopleSoft production : un URL pour accéder à l'application, un pour servir le courtier d'intégration et un pour consulter les rapports. Dans la mesure du possible, chacun URL doit disposer de ses propres serveurs Web et serveurs d'applications dédiés. Cette conception contribue à renforcer la sécurité de votre PeopleSoft application, car chacune URL possède une fonctionnalité distincte et un accès contrôlé. Cela minimise également l'ampleur de l'impact en cas de défaillance des services sous-jacents.

  • Nous vous recommandons de configurer des contrôles de santé sur les groupes cibles de l'équilibreur de charge pour votre PeopleSoft application. Les contrôles de santé doivent être effectués sur les serveurs Web plutôt que sur les EC2 instances qui exécutent ces serveurs. Cela garantit que si le serveur Web tombe en panne ou si l'EC2instance qui héberge le serveur Web tombe en panne, l'Application Load Balancer reflète ces informations avec précision.

  • Pour une application PeopleSoft de production, nous vous recommandons de répartir les serveurs Web sur au moins trois zones de disponibilité. Cela garantit que l' PeopleSoft application est toujours hautement disponible même si l'une des zones de disponibilité tombe en panne.

  • Pour une application PeopleSoft de production, activez jolt pooling (joltPooling=true). Cela garantit que votre application bascule vers un autre serveur d'applications si un serveur est en panne pour des raisons de correction ou en raison d'une défaillance d'une machine virtuelle.

  • Pour une application PeopleSoft de production, définissez cette DynamicConfigReload valeur sur 1. Ce paramètre est pris en charge dans les PeopleTools versions 8.52 et ultérieures. Il ajoute de nouveaux serveurs d'applications au serveur Web de manière dynamique, sans redémarrer les serveurs.

  • Pour minimiser les temps d'arrêt lorsque vous appliquez des PeopleTools correctifs, utilisez la méthode de déploiement bleu/vert pour les configurations de lancement de votre groupe Auto Scaling pour le Web et les serveurs d'applications. Pour plus d'informations, consultez la présentation des options de déploiement dans le AWS livre blanc.

  • Utilisez AWSBackup pour sauvegarder votre PeopleSoft application surAWS. AWSBackup est un service rentable, entièrement géré et basé sur des règles qui simplifie la protection des données à grande échelle.

Bonnes pratiques en matière de performances

Meilleures pratiques en matière d'optimisation des coûts

  • Marquez toutes les ressources utilisées par votre PeopleSoft environnement et activez les balises de répartition des coûts. Ces balises vous aident à visualiser et à gérer les coûts de vos ressources.

  • Pour une application PeopleSoft de production, configurez des groupes Auto Scaling pour les serveurs Web et les serveurs d'applications. Cela permet de maintenir un nombre minimal de serveurs Web et d'applications pour prendre en charge votre application. Vous pouvez utiliser les politiques de groupe Auto Scaling pour augmenter ou diminuer les serveurs selon les besoins.

  • Utilisez les alarmes de facturation pour recevoir des alertes lorsque les coûts dépassent le seuil budgétaire que vous spécifiez.

Bonnes pratiques en matière de durabilité

  • Utilisez l'infrastructure en tant que code (IaC) pour gérer vos PeopleSoft environnements. Cela vous permet de créer des environnements cohérents et de garder le contrôle des modifications.

Épopées

TâcheDescriptionCompétences requises

Créez un groupe de sous-réseaux de base de données.

Sur la RDSconsole Amazon, dans le volet de navigation, choisissez Subnet groups, puis créez un groupe de sous-réseaux Amazon RDS DB avec des sous-réseaux dans plusieurs zones de disponibilité. Cela est nécessaire pour que la RDS base de données Amazon fonctionne dans une configuration multi-AZ.

Administrateur du cloud

Créez la base de RDS données Amazon.

Créez une RDS base de données Amazon dans une zone de disponibilité de la AWS région que vous avez sélectionnée pour l'environnement PeopleSoft HA. Lorsque vous créez la RDS base de données Amazon, assurez-vous de sélectionner l'option Multi-AZ (Créer une instance de secours) et le groupe de sous-réseaux de base de données que vous avez créé à l'étape précédente. Pour plus d'informations, consultez la RDSdocumentation Amazon.

Administrateur cloud, administrateur de base de données Oracle

Migrez votre PeopleSoft base de données vers AmazonRDS.

Migrez votre PeopleSoft base de données existante vers la RDS base de données Amazon à l'aide AWS de Database Migration Service (AWSDMS). Pour plus d'informations, consultez la AWSDMSdocumentation et le billet de AWS blog Migration des bases de données Oracle avec un temps d'arrêt quasi nul grâce à. AWS DMS

Administrateur du cloud, PeopleSoft DBA
TâcheDescriptionCompétences requises

Créez un système de fichiers.

Sur la EFSconsole Amazon, créez un système de fichiers et montez des cibles pour chaque zone de disponibilité. Pour obtenir des instructions, consultez la EFSdocumentation Amazon. Lorsque le système de fichiers a été créé, notez son DNS nom. Vous utiliserez ces informations lors du montage du système de fichiers.

Administrateur du cloud
TâcheDescriptionCompétences requises

Lancez une instance EC2.

Lancez une EC2 instance pour votre PeopleSoft application. Pour obtenir des instructions, consultez la EC2documentation Amazon.

  • Pour Name (Nom), saisissez APP_TEMPLATE.

  • Pour les images du système d'exploitation, choisissez Red Hat.

  • Dans Type d'instance, choisissez le type d'instance adapté à votre PeopleSoft application. Pour plus d'informations, consultez la section Détails de l'architecture dans la section Architecture.

Administrateur du cloud, PeopleSoft administrateur

Installez PeopleSoft sur l'instance.

Installez votre PeopleSoft application et PeopleTools sur l'EC2instance que vous avez créée. Pour obtenir des instructions, consultez la documentation Oracle.

Administrateur du cloud, PeopleSoft administrateur

Créez le serveur d'applications.

Créez le serveur d'applications pour le AMI modèle et assurez-vous qu'il se connecte correctement à la RDS base de données Amazon.

Administrateur du cloud, PeopleSoft administrateur

Montez le système de EFS fichiers Amazon.

Connectez-vous à l'EC2instance en tant qu'utilisateur root et exécutez les commandes suivantes pour monter le système de EFS fichiers Amazon dans un dossier appelé PSFTMNT sur le serveur.

sudo su – mkdir /psftmnt cat /etc/fstab

Ajoutez la ligne suivante au /etc/fstab fichier. Utilisez le DNS nom que vous avez indiqué lors de la création du système de fichiers.

fs-09e064308f1145388.efs.us-east-1.amazonaws.com:/ /psftmnt nfs4 nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,_netdev 0 0 mount -a
Administrateur du cloud, PeopleSoft administrateur

Vérifiez les autorisations.

Assurez-vous que le PSFTMNT dossier dispose des autorisations appropriées afin que l' PeopleSoft utilisateur puisse y accéder correctement.

Administrateur du cloud, PeopleSoft administrateur

Créez des instances supplémentaires.

Répétez les étapes précédentes de cette épopée pour créer des instances de modèles pour le planificateur de processus, le serveur Web et le serveur Elasticsearch. Nommez ces instances PRCS_TEMPLATEWEB_TEMPLATE, etSRCH_TEMPLATE. Pour le serveur Web, définissez joltPooling=true etDynamicConfigReload=1.

Administrateur du cloud, PeopleSoft administrateur
TâcheDescriptionCompétences requises

Créez un script pour installer le serveur d'applications.

Dans l'EC2APP_TEMPLATEinstance Amazon, en tant qu' PeopleSoft utilisateur, créez le script suivant. Nommez-le appstart.sh et placez-le dans le PS_HOME répertoire. Vous allez utiliser ce script pour ouvrir le serveur d'applications et enregistrer le nom du serveur sur le EFS support Amazon.

#!/bin/ksh . /usr/homes/hcmdemo/.profile. psadmin -c configure -d HCMDEMO psadmin -c parallelboot -d HCMDEMO touch /psftmnt/`echo $HOSTNAME`
PeopleSoft administrateur

Créez un script pour installer le serveur du planificateur de processus.

Dans l'EC2PRCS_TEMPLATEinstance Amazon, en tant qu' PeopleSoft utilisateur, créez le script suivant. Nommez-le prcsstart.sh et placez-le dans le PS_HOME répertoire. Vous allez utiliser ce script pour ouvrir le serveur du planificateur de processus.

#!/bin/ksh . /usr/homes/hcmdemo/. profile /* The following line ensures that the process scheduler always has a unique name during replacement or scaling activity. */ sed -i "s/.*PrcsServerName.*/`hostname -I | awk -F. '{print "PrcsServerName=PSUNX"$3$4}'`/" $HOME/appserv/prcs/*/psprcs.cfg psadmin -p configure -d HCMDEMO psadmin -p start -d HCMDEMO
PeopleSoft administrateur

Créez un script pour installer le serveur Elasticsearch.

Dans l'EC2SRCH_TEMPLATEinstance Amazon, en tant qu'utilisateur d'Elasticsearch, créez le script suivant. Nommez-le srchstart.sh et placez-le dans le HOME répertoire.

#!/bin/ksh /* The following line ensures that the correct IP is indicated in the elasticsearch.yaml file. */ sed -i "s/.*network.host.*/`hostname -I | awk '{print "host:"$0}'`/" $ES_HOME_DIR/config/elasticsearch.yaml nohup $ES_HOME_DIR/bin/elasticsearch &
PeopleSoft administrateur

Créez un script pour installer le serveur Web.

Dans l'EC2WEB_TEMPLATEinstance Amazon, en tant qu'utilisateur du serveur Web, créez les scripts suivants dans le HOME répertoire.

renip.sh: Ce script garantit que le serveur Web possède l'adresse IP correcte lorsqu'il est cloné à partir duAMI.

#!/bin/ksh hn=`hostname` /* On the following line, change the IP with the hostname with the hostname of the web template. */ for text_file in `find * -type f -exec grep -l '<hostname-of-the-web-template>' {} \;` do sed -e 's/<hostname-of-the-web-template>/'$hn'/g' $text_file > temp mv -f temp $text_file done

psstrsetup.sh: ce script garantit que le serveur Web utilise le bon serveur IPs d'applications actuellement en cours d'exécution. Il essaie de se connecter à chaque serveur d'applications sur le port jolt et l'ajoute au fichier de configuration.

#!/bin/ksh c2="" for ctr in `ls -1 /psftmnt/*.internal` do c1=`echo $ctr | awk -F "/" '{print $3}'` /* In the following lines, 9000 is the jolt port. Change it if necessary. */ if nc -z $c1 9000 2> /dev/null; then if [[ $c2 = "" ]]; then c2="psserver="`echo $c1`":9000" else c2=`echo $c2`","`echo $c1`":9000" fi fi done

webstart.sh: Ce script exécute les deux scripts précédents et démarre les serveurs Web.

#!/bin/ksh /* Change the path in the following if necessary. */ cd /usr/homes/hcmdemo ./renip.sh ./psstrsetup.sh webserv/peoplesoft/bin/startPIA.sh
PeopleSoft administrateur

Ajoutez une entrée crontab.

Dans l'EC2WEB_TEMPLATEinstance Amazon, en tant qu'utilisateur du serveur Web, ajoutez la ligne suivante à crontab. Modifiez l'heure et le chemin pour refléter les valeurs dont vous avez besoin. Cette entrée garantit que votre serveur Web dispose toujours des entrées de serveur d'applications correctes dans le configuration.properties fichier.

* * * * * /usr/homes/hcmdemo/psstrsetup.sh
PeopleSoft administrateur
TâcheDescriptionCompétences requises

Créez un modèle AMI pour le serveur d'applications.

Sur la EC2 console Amazon, créez une AMI image de l'EC2APP_TEMPLATEinstance Amazon. Nommez le AMIPSAPPSRV-SCG-VER1. Pour obtenir des instructions, consultez la EC2documentation Amazon.

Administrateur du cloud, PeopleSoft administrateur

Créez AMIs pour les autres serveurs.

Répétez l'étape précédente AMIs pour créer pour le planificateur de processus, le serveur Elasticsearch et le serveur Web.

Administrateur du cloud, PeopleSoft administrateur

Créez un modèle de lancement pour le groupe Auto Scaling du serveur d'applications.

Créez un modèle de lancement pour le groupe Auto Scaling du serveur d'applications. Nommez le modèle PSAPPSRV_TEMPLATE. Dans le modèle, choisissez celui AMI que vous avez créé pour l'APP_TEMPLATEinstance. Pour obtenir des instructions, consultez la EC2documentation Amazon.

  • Dans le modèle de lancement, sélectionnez le type d'instance en fonction de vos besoins.

  • Dans le champ Données utilisateur de la section Détails avancés, ajoutez les entrées suivantes. Assurez-vous que le chemin et les informations utilisateur sont corrects. Vous avez créé le appstart.sh script lors d'une étape précédente.

    #! /bin/ksh su -c “/usr/homes/hcmdemo/appstart.sh” - hcmdemo
Administrateur du cloud, PeopleSoft administrateur

Créez un modèle de lancement pour le groupe Auto Scaling du serveur de planificateur de processus.

Répétez l'étape précédente pour créer un modèle de lancement pour le groupe Auto Scaling du serveur de planificateur de processus. Nommez le modèlePSPRCS_TEMPLATE. Dans le modèle, choisissez celui AMI que vous avez créé pour le planificateur de processus.

  • Dans le champ Données utilisateur de la section Détails avancés, ajoutez les entrées suivantes. Assurez-vous que le chemin et les informations utilisateur sont corrects. Vous avez créé le prcsstart.sh script lors d'une étape précédente.

    #! /bin/ksh su -c “/usr/homes/hcmdemo/prcsstart.sh” - hcmdemo
Administrateur du cloud, PeopleSoft administrateur

Créez un modèle de lancement pour le groupe Auto Scaling du serveur Elasticsearch.

Répétez les étapes précédentes pour créer un modèle de lancement pour le groupe Auto Scaling du serveur Elasticsearch. Nommez le modèleSRCH_TEMPLATE. Dans le modèle, choisissez celui AMI que vous avez créé pour le serveur de recherche.

  • Dans le champ Données utilisateur de la section Détails avancés, ajoutez les entrées suivantes. Assurez-vous que le chemin et les informations utilisateur sont corrects. Vous avez créé le srchstart.sh script lors d'une étape précédente.

    #! /bin/ksh su -c “/usr/homes/essearch/srchstart.sh” - essearch
Administrateur du cloud, PeopleSoft administrateur

Créez un modèle de lancement pour le groupe Auto Scaling du serveur Web.

Répétez les étapes précédentes pour créer un modèle de lancement pour le groupe Auto Scaling du serveur Web. Nommez le modèleWEB_TEMPLATE. Dans le modèle, choisissez celui AMI que vous avez créé pour le serveur Web.

  • Dans le champ Données utilisateur de la section Détails avancés, ajoutez les entrées suivantes. Assurez-vous que le chemin et les informations utilisateur sont corrects. Vous avez créé le webstart.sh script lors d'une étape précédente.

    #! /bin/ksh su -c “/usr/homes/hcmdemo/webstart.sh” - hcmdemo
Administrateur du cloud, PeopleSoft administrateur
TâcheDescriptionCompétences requises

Créez un groupe Auto Scaling pour le serveur d'applications.

Sur la EC2 console Amazon, créez un groupe Auto Scaling appelé PSAPPSRV_ASG pour le serveur d'applications en utilisant le PSAPPSRV_TEMPLATE modèle. Pour obtenir des instructions, consultez la EC2documentation Amazon.

  • Sur la page Choisir les options de lancement d'une instance, sélectionnez la bonne, VPC puis sélectionnez plusieurs sous-réseaux provenant de différentes zones de disponibilité.

  • Sur la page Configurer les options avancées, ne sélectionnez pas d'équilibreur de charge.

  • Sur la page Configurer la taille du groupe et les politiques de dimensionnement, choisissez les paramètres en fonction de la charge pour laquelle vous souhaitez concevoir votre système et de l'utilisation ou non d'une politique de dimensionnement. Nous vous recommandons de définir la capacité minimale souhaitée sur 2 au minimum afin qu'au moins une instance soit disponible pour traiter le trafic à tout moment. Pour plus d'informations sur les politiques d'Auto Scaling, consultez la EC2documentation Amazon.

Administrateur du cloud, PeopleSoft administrateur

Créez des groupes Auto Scaling pour les autres serveurs.

Répétez l'étape précédente pour créer des groupes Auto Scaling pour le planificateur de processus, le serveur Elasticsearch et le serveur Web.

Administrateur du cloud, PeopleSoft administrateur
TâcheDescriptionCompétences requises

Créez un groupe cible pour le serveur Web.

Sur la EC2 console Amazon, créez un groupe cible pour le serveur Web. Pour obtenir des instructions, consultez la documentation d'Elastic Load Balancing. Définissez le port sur le port sur lequel le serveur Web écoute.

Administrateur du cloud

Configurez les contrôles de santé.

Vérifiez que les valeurs des bilans de santé correspondent aux exigences de votre entreprise. Pour de plus amples informations, veuillez consulter la documentation relative à Elastic Load Balancing.

Administrateur du cloud

Créez un groupe cible pour le serveur Elasticsearch.

Répétez les étapes précédentes pour créer un groupe cible appelé PSFTSRCH pour le serveur Elasticsearch et définissez le port Elasticsearch approprié.

Administrateur du cloud

Ajoutez des groupes cibles aux groupes Auto Scaling.

Ouvrez le groupe Auto Scaling du serveur Web appelé PSPIA_ASG que vous avez créé précédemment. Dans l'onglet Load balancing, choisissez Edit, puis ajoutez le groupe PSFTWEB cible au groupe Auto Scaling.

Répétez cette étape pour que le groupe Elasticsearch Auto Scaling ajoute le groupe PSSRCH_ASG cible PSFTSRCH que vous avez créé précédemment.

Administrateur du cloud

Définissez le caractère collant de la session.

Dans le groupe ciblePSFTWEB, choisissez l'onglet Attributs, choisissez Modifier et définissez le caractère permanent de la session. Pour le type d'adhérence, choisissez le cookie généré par l'équilibreur de charge et définissez la durée sur 1. Pour de plus amples informations, veuillez consulter la documentation relative à Elastic Load Balancing.

Répétez cette étape pour le groupe ciblePSFTSRCH.

Administrateur du cloud
TâcheDescriptionCompétences requises

Créez un équilibreur de charge pour les serveurs Web.

Créez un Application Load Balancer nommé PSFTLB pour équilibrer la charge du trafic vers les serveurs Web. Pour obtenir des instructions, consultez la documentation d'Elastic Load Balancing.

  • Indiquez le nom de l'équilibreur de charge.

  • Pour Méthodes, choisissez Accessible sur Internet.

  • Dans la section Cartographie du réseau, sélectionnez le sous-réseau correct VPC et au moins deux sous-réseaux publics provenant de zones de disponibilité différentes.

  • Dans la section Écouteurs et routage, sélectionnez le groupe cible PSFTWEB et spécifiez le protocole et le numéro de port appropriés.

Administrateur du cloud

Créez un équilibreur de charge pour les serveurs Elasticsearch.

Créez un Application Load Balancer nommé PSFTSCH pour équilibrer la charge du trafic vers les serveurs Elasticsearch.

  • Indiquez le nom de l'équilibreur de charge.

  • Pour Schéma, choisissez Internal.

  • Dans la section Cartographie du réseau, sélectionnez les sous-réseaux appropriés VPC et privés.

  • Dans la section Écouteurs et routage, sélectionnez le groupe cible PSFTSRCH et spécifiez le protocole et le numéro de port appropriés.

Administrateur du cloud

Configurez la Route 53.

Sur la console Amazon Route 53, créez un enregistrement dans la zone hébergée qui servira l' PeopleSoft application. Pour obtenir des instructions, consultez la documentation Amazon Route 53. Cela garantit que tout le trafic passe par l'équilibreur PSFTLB de charge.

Administrateur du cloud

Ressources connexes