Si vos applications exigent un équilibrage de charge, une haute disponibilité et que vous souhaitez y ajouter facilement de nouveaux systèmes pour répondre à la demande au fur et à mesure que la charge de travail croît, vous pouvez migrer votre environnement d'exécution et les serveurs d'applications qui y sont associés depuis une configuration monoplex vers une configuration sysplex.
Avant de commencer
Une fois que vous aurez installé l'environnement d'exécution du serveur et les applications de gestion associées sur un monoplex, vous devrez évaluer s'il
convient de migrer l'environnement d'exécution du serveur et les serveurs d'applications associés
sur une configuration sysplex. Si vous décidez de configurer un environnement sysplex comprenant plusieurs
images z/OS et la gestion de la charge de travail (WLM), vous devez exécuter
le travail BBOWWPFA dans l'image z/OS sur laquelle vous lancez
WebSphere
Application Server.
Le travail BBOWWPFA est l'un des travaux
automatiquement générés lorsque vous configurez et personnalisez
WebSphere
Application Server pour la première fois. Vous exécutez ce lot de travaux
pour configurer votre environnement z/OS. Généralement, ces travaux JCL sont
exécutés un par un dans la première image z/OS disponible sur le sysplex. Toutefois, le travail BBOWWPFA, qui configure le système de fichiers de
l'environnement d'exécution (configuration) du produit, doit être exécuté dans
la même image z/OS que celle où vous avez l'intention de lancer le produit. Pour que le travail BBOWWPFA soit bien exécuté dans l'image appropriée, ajoutez
l'instruction JCL ci-après, après l'instruction du travail BBOWWPFA, dans le
lot des instructions JCL générées automatiquement, avant d'exécuter le travail
BBOWWPFA.
/*JOBPARM SYSAFF=sxx
où
sxx correspond au nom de l'image z/OS dans laquelle vous
allez exécuter le produit.
Pourquoi et quand exécuter cette tâche
Grâce à un environnement sysplex vous pouvez :
- Equilibrer la charge de travail sur plusieurs systèmes, ce qui permet de gérer plus efficacement les performances de vos applications.
- Ajouter de nouveaux systèmes au fur et à mesure que votre charge de travail s'accroît. Cette fonction constitue une solution évolutive pour répondre à vos besoins en traitement.
- Répliquer l'environnement d'exécution et les serveurs d'applications de gestion associés.
Cette fonction apporte la garantie qu'en cas de défaillance d'un système, les autres systèmes peuvent prendre en charge les requêtes des utilisateurs.
- Mettre à niveau le serveur d'applications d'une édition ou d'un niveau de service à un autre sans interrompre le service fourni aux utilisateurs.
Eviter les incidents: Si vous utilisez un anneau
de sérialisation d'accès des ressources partagées (GRS) pour connecter un ou
plusieurs monoplex à un environnement sysplex, le nom de cellule des serveurs
exécutés dans l'un des monoplex doit être unique dans l'environnement GRS.
Cette exigence signifie que le nom de cellule d'un serveur exécuté dans l'un
des monoplexes :
- doit être différent du nom de cellule d'un serveur s'exécutant dans le sysplex
- Doit être différent du nom de cellule des serveurs exécutés dans un autre monoplex
connecté au sysplex.
Si des serveurs possèdent des noms de cellule en double au sein de l'environnement GRS,
WebSphere
Application Server ne peut pas faire la différence entre la cellule sysplex et la cellule monoplex, et traite les deux serveurs comme faisant partie de la même cellule. Cette association de cellules inadéquate provoque généralement des résultats imprévisibles au niveau du traitement.
gotcha
Réaliser les tâches suivantes pour configurer le serveur d'applications dans une configuration sysplex.
Procédure
- Configuration d'un environnement sysplex lorsqu'il n'en existe pas encore.
La publication z/OS z/OS
MVS Setting Up a Sysplex explique comment configurer un sysplex z/OS. Le répertoire que vous configurez devra être similaire à l'arborescence suivante :
Figure 1. Arborescence de deux serveurs d'applications fonctionnant sur un sysplex
- Configurez le module Server Runtime pour un environnement sysplex.
- Décidez si vous souhaitez une vue d'un seul système du journal des erreurs. Si vous souhaitez une vue d'un seul système du journal des erreurs et qu'initialement vous
avez configuré le journal des erreurs dans le consignateur du système et utilisé DASD pour la
consignation, configurez maintenant le journal des erreurs dans l'unité de couplage.
- Décidez de la façon dont vous allez partager les fichiers exécutables de l'application
dans la cellule.
- Configurez ARM. Cette version ne prend pas en charge le redémarrage entre
systèmes et vous devez configurer la règle ARM en conséquence.
Assurez-vous que vous définissez
TARGET_SYSTEM pour le système sur lequel chaque élément s'exécute (avec la configuration par défaut
TARGET_SYSTEM=*, vous obtenez un redémarrage entre systèmes).
- Choisissez si vous voulez exécuter tous les serveurs d'exécution sur chaque système de la cellule.
Recommandations :
Le tableau suivant répertorie les recommandations et les exigences pour l'exécution des serveurs
dans une cellule.
Tableau 1. Exécution des serveurs dans une
cellule. Le tableau suivant répertorie les recommandations et les exigences pour l'exécution des serveurs
dans une cellule. Serveur |
Recommandations
et exigences pour l'exécution de serveurs dans une cellule |
démon du service de
localisation et agent de noeud |
- Vous devez exécuter le démon du service de localisation et l'agent de noeud sur chaque
système de le sysplex dans lequel doit s'exécuter le travail du module Server Runtime. Lorsque le module Server Runtime n'est pas installé sur certains des systèmes de votre sysplex, il ne vous est pas nécessaire d'exécuter un démon de service de localisation et un agent de noeud sur ces systèmes.
- Si un serveur indique que des PassTickets sont souhaitables pour l'interaction avec un
client, vous devez exécuter le démon du service de localisation et l'agent de noeud sur le système
sur lequel réside le client z/OS.
|
gestionnaire de déploiement |
Prenez soin de suivre la
procédure qui convient pour configurer une cellule du gestionnaire de déploiement. |
- Préparez votre système de sécurité.
- Configurez le partage des données. Voir le document DB2 Data Sharing:
Planning and Administration associé à la version de DB2 utilisée sur votre
système z/OS.
- Personnalisez les fonctions z/OS des autres systèmes du sysplex conformément à la personnalisation réalisée dans le cadre de l'installation initiale du module Server Runtime.
Les informations complètes sur la personnalisation des systèmes supplémentaires se trouvent dans les instructions de personnalisation générées.
- Modifiez la configuration du protocole TCP/IP. Chaque système d'un sysplex contient un démon du service de localisation, un agent de noeud et des serveurs d'applications métier. Le démon du service de localisation agit en tant qu'agent du service de localisation et accepte les requêtes de localisation contenant des clés d'objets. Par conséquent, il est essentiel que les entrées DNS (domain name server) du protocole TCP/IP, et que le profil TCP/IP de chaque système de la cellule mentionne le port du démon du service de localisation et que ce port soit associé au nouveau serveur du démon du service de localisation.
- Modification des entrées DNS.
Si vous utilisez l'implémentation DNS qui permet d'utiliser des noms IP génériques pointant de manière dynamique vers des serveurs configurés à l'identique, vous devez ajuster les noms IP de votre DNS.
Vous devez conserver le nom IP générique du démon du service de localisation. Mais vous devez ajouter un nouveau nom IP pour le deuxième démon du service de localisation et pour les autres. Les noms IP supplémentaires permettent au système de nom de domaine de diriger le travail vers d'autres serveurs en cas de défaillance.
- Dans le profil TCP/IP de chaque système supplémentaire de la cellule, ajoutez un port pour le démon du service de localisation et associez-le à un nouveau nom de serveur de démon de service de localisation.
Par défaut, le module Server Runtime utilise le port 5655 pour le démon du service de localisation. Le module Server Runtime nomme également le premier serveur du démon du service de localisation DAEMON01 et augmente le suffixe pour chaque nouveau serveur de démon du service de localisation, par exemple DAEMON02, DAEMON03, etc. Par conséquent, pour le second système du sysplex, vous devez ajouter un port et l'associer à DAEMON02.
Exemple :
5655
TCP DAEMON02
Reproduisez le même schéma pour le troisième sysplex et pour les suivants.
- Définissez de nouveaux clusters de serveurs d'applications dans le sysplex.
- Facultatif : Créez des cellules de gestionnaire de déploiement.
- Installez le serveur d'applications par défaut sur chaque noeud dans le sysplex.
- Installez une cellule de gestionnaire de déploiement sur un noeud du sysplex.
- Ajoutez les noeuds de serveur par défaut à la cellule du gestionnaire de déploiement.
Résultats
Vous pouvez tirer profit de tous les avantages que représente l'exécution de vos applications sur plusieurs systèmes d'un sysplex.
Que faire ensuite
Migrez vos applications vers le sysplex.