[z/OS]

Configuration du module Server Runtime sur plusieurs systèmes d'un sysplex

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

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 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

  1. 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 sysplexArborescence de WebSphere Application Server
  2. Configurez le module Server Runtime pour un environnement sysplex.
    1. 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.
    2. Décidez de la façon dont vous allez partager les fichiers exécutables de l'application dans la cellule.
    3. 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).
    4. 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.
  3. Préparez votre système de sécurité.
  4. 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.
  5. 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.

  6. 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.
    1. 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.

    2. 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.
  7. Définissez de nouveaux clusters de serveurs d'applications dans le sysplex.
  8. Facultatif : Créez des cellules de gestionnaire de déploiement.
    1. Installez le serveur d'applications par défaut sur chaque noeud dans le sysplex.
    2. Installez une cellule de gestionnaire de déploiement sur un noeud du sysplex.
    3. 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.

Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=trun_advsplx
Nom du fichier : trun_advsplx.html