Système de fichiers de configuration

Il existe plusieurs décisions de planification que vous devez prendre au moment de la mise en place d'un système de fichiers de configuration WebSphere Application Server for z/OS.

Les paramètres de cellule, de noeud et de serveur ainsi que les applications déployées sont stockés dans le système de fichiers de configuration de WebSphere Application Server for z/OS. Vous pouvez utiliser un système de fichiers zSeries (ZFS) ou un système hiérarchique de fichiers (HFS) pour le système de fichiers de configuration.
Conseil : Dans WebSphere Application Server for z/OS version 7.0, les jeux de données SBBOLOAD et SBBOLD2 n'existent plus. Cette situation est due au fait que les modules de chargement sont maintenant dans le système de fichiers du produit. Si vous voulez qu'une configuration utilisant les modules de chargement contenus dans le système de fichiers du produit utilise ceux d'un jeu de données, vous pouvez utiliser l'outil décrit à la rubrique Commande switchModules. Depuis WebSphere Application Server for z/OS version 8.0, la variable d'environnement server_dlls_in_hfs doit également être définie à 0 pour que le serveur utilise les DLL qui ont été placées dans un jeu de données qui se trouve dans STEPLIB, dans LPA ou dans une liste de liens. Pour que le démon utilise les DLL, WAS_DAEMON_ONLY_server_dlls_in_hfs doit être défini au niveau de la cellule.

Chaque noeud doit avoir un répertoire de base

Chaque noeud WebSphere Application Server for z/OS demande un répertoire personnel accessible en lecture et écriture (souvent nommé RACINE_WAS), qu'il s'agisse d'un serveur d'applications autonome, d'un gestionnaire de déploiement, d'un noeud de serveur d'applications géré ou d'un démon de service de localisation.

Voici la structure d'un système de fichiers de configuration WebSphere Application Server for z/OS, monté sur /WebSphere/V9R0. Il contient un répertoire personnel WebSphere Application Server pour un seul serveur d'applications nommé BBOS001, avec une cellule et un noeud tous deux nommés SYSA.
/WebSphere/V9R0
  /AppServer
    /bin
    /classes
    /java
    /lib
    /logs
    /profiles
      /default -> this is the profile_root directory  
    /temp
    ...
   /Daemon
    /config    
      /SYSA
   SYSA.SYSA.BBODMNB -> /WebSphere/V9R0/Daemon/config/SYSA/SYSA/BBODMNB
   SYSA.SYSA.BBOS001 ->  
/WebSphere/V9R0/AppServer/profiles/default/config/cells/SYSA/nodes/SYSA
   /servers/server1
   SYSA.SYSA.BBOS001.HOME ->  /WebSphere/V9R0/AppServer
Le répertoire de base de WebSphere Application Server for BBOS001 est nommé AppServer. Il renferme des répertoires avec les informations complètes de configuration pour le noeud SYSA et le serveur BBOS001.
Le répertoire /Daemon contient les informations de configuration des démons de service de localisation définis pour des noeuds de ce système de fichiers de configuration.
Remarque : Le sous-répertoire /Daemon/config est divisé par nom de cellule. Si les cellules ont des noms abrégés différents, les informations du démon de service de localisation sont conservées séparément.
Le répertoire de base du démon a été défini selon le nom home Daemon de WebSphere Application Server.

Les liens symboliques sont utilisés pour accéder au paramètres d'initialisation.

Dans les répertoires de base WebSphere Application Server eux-mêmes, le système de fichiers de configuration contient un lien symbolique multipartie pour chaque serveur qui pointe vers les paramètres d'initialisation du serveur. Le lien symbolique est appelé nom_abrégé_cellule.nom_abrégé_noeud.nom_abrégé_serveur.

L'exemple précédent de système de fichiers de configuration contient un lien symbolique SYSA.SYSA.BBODMNB pour démarrer le démon de service de localisation et un lien symbolique SYSA.SYSA.BBOS001 pour démarrer le serveur d'applications BBOS001. Le deuxième lien symbolique est défini dans le paramètre ENV de la commande START au moment où le serveur ou le démon de service de localisation est démarré depuis la console MVS :

START procname,JOBNAME=BBOS001,ENV=SYSA.SYSA.BBOS001

Chaque lien symbolique pointe vers le sous-répertoire contenant le fichier was.env du serveur. Ce fichier renferme les informations nécessaire au démarrage du serveur.

Remarque : Au cours du traitement post installation, décrit ci-après, le JCL serveur doit préciser le répertoire de base WebSphere Application Server lui-même, au lieu de l'emplacement du fichier was.env. C'est l'objectif du lien symbolique SYSA.SYSA.BBOS001.HOME présenté ci-dessus.

Partage du système de fichiers de configuration entre cellules

Au moins deux cellules WebSphere Application Server for z/OS (serveur d'applications autonome, Network Deployment, ou les deux) peuvent partager un système de fichiers de configuration WebSphere Application Server for z/OS si les conditions suivantes sont réunies :
  • Toutes les cellules utilisant le système de fichiers de configuration doivent être installées à l'aide des mêmes groupes et utilisateurs communs. Plus particulièrement, chacune d'entre elles doit disposer du même ID utilisateur d'administrateur et du même groupe de configuration.
  • Les noms abrégés attribués aux cellules doivent être différents les uns des autres.
  • Chaque noeud doit posséder son propre répertoire de base WAS_HOME qui n'est partagé avec aucun autre noeud ni aucune cellule.
Tel que cela a été mentionné auparavant, vous pouvez partager le répertoire de base du démon (/Daemon) entre des cellules. En effet, il renferme suffisamment de sous-répertoires pour chaque cellule du système de fichiers de configuration.
Remarque : Soyez conscient que le partage du système de fichiers de configuration entre plusieurs cellules augmente la probabilité pour qu'un incident se produisant sur une cellule affecte les autres cellules du même système de fichiers de configuration.

Partage du système de fichiers de configuration entre systèmes

Deux systèmes z/OS ou plus peuvent partager un système de fichiers de configuration, à condition que les systèmes z/OS disposent d'un système de fichiers de configuration partagé et que ce dernier soit monté avec un accès en lecture/écriture. Toutes les mises à jour sont effectuées par le système z/OS qui possède le point de montage. Pour une cellule de déploiement réseau, c'est généralement le système z/OS sur lequel le gestionnaire de déploiement de la cellule est configuré.

Choix d'un point de montage de système de fichiers de configuration WebSphere Application Server for z/OS

Le choix des points de montage du système de fichiers de configuration WebSphere Application Server for z/OS dépend de l'agencement de votre système z/OS, de la nature de l'environnement de serveur d'applications impliqué et de l'importance relative de divers facteurs : facilité d'installation, facilité de maintenance, performance, capacité de récupération et besoin d'une disponibilité permanente.

  • Dans un système z/OS simple :

    Si vous exécutez WebSphere Application Server for z/OS sur un système z/OS simple, vous disposez d'un vaste choix de points de montage pour le système de fichiers de configuration z/OS. Il se peut que vous souhaitiez placer plusieurs serveurs d'applications autonomes dans un seul système de fichiers de configuration, avec un système de fichiers de configuration distinct pour un serveur de production ou pour une cellule Network Deployment. L'utilisation de fichiers de systèmes de fichiers de configuration distincts améliore la performance et la fiabilité, alors que l'utilisation d'un système de fichiers de configuration partagé réduit le nombre de serveurs d'applications dont vous avez besoin.

    Vous pouvez avoir un système de fichiers de configuration avec vos serveurs de développement, de test et d'assurance qualité, tous dans les mêmes groupes communs et utilisés comme suit :
    /WebSphere/V9R0_test
      /DevServer - home to standalone server DVCELL, with server DVSR01A 
      /TestServer1 - home to standalone server cell T1CELL, with server T1SR01A 
      /TestServer2 - home to standalone server cell T2CELL, with server T2SR01A
      /QAServer - home to Network Deployment cell QACELL, with deployment 
        manager QADMGR and server QVSR01A
    et un système de fichiers de configuration distinct pour votre cellule de production :
    /WebSphere/V9R0_prod
      /CorpServer1 - home to Network Deployment cell CSCELL, with deployment 
        manager CSDMGR and server CSSR01A
  • Dans un sysplex z/OS multisystème sans système de fichiers partagé :

    Dans un sysplex multisystème sans système de fichiers partagé, chaque système z/OS doit disposer de ses propres fichiers de système de fichiers de configuration. Pour les serveurs d'applications et pour les cellules Network Deployment qui ne couvrent pas les systèmes, les options sont identiques à celles d'un système z/OS simple.

  • Pour les cellules de déploiement réseau qui couvrent les systèmes :
    Vous disposez ici de deux possibilités :
    • Vous pouvez utiliser un point de montage différent pour les fichiers du système de fichiers de configuration de la cellule sur chaque système. Cela vous permet de déplacer facilement des noeuds d'un système à un autre (si un système ne fonctionne plus ou est mis à jour, par exemple), dans la mesure où le point de montage n'est pas utilisé sur les autres systèmes du sysplex, ce qui vous permet de monter les fichiers du système de fichiers de configuration du système en panne sur un autre système du sysplex.
      Sur LPAR1 système, par exemple, vous pouvez avoir un système de fichiers de configuration pour une partie d'une cellule :
      /var/WebSphere/V9R0config1
        /DeploymentManager - home to deployment manager F1DMGR in cell F1CELL
        /AppServer1 - home to node F1NODEA and servers F1SR01A and F1SR02A
      avec un deuxième système de fichiers de configuration sur LPAR2 :
      /var/WebSphere/V9R0config2
        /AppServer2 - home to node F1NODEB and servers F1SR02B (clustered) 
          and F1SR03B
      Cette configuration présente l'avantage de pouvoir déplacer le gestionnaire de déploiement et le noeud F1NODEA vers LPAR2 ou de déplacer le noeud F1NODEB vers LPAR1. L'inconvénient de cette configuration réside dans le fait que F1NODEA et F1NODEB nécessiteront des ensembles distincts de procédures cataloguées.
    • Ou vous pouvez utiliser le même point de montage pour tous les fichiers de système de fichiers de configuration d'une cellule donnée. Cela vous permet d'utiliser des procédures cataloguées communes et de rendre les systèmes très similaires les uns par rapport aux autres.
      En utilisant une configuration de cellule identique à la précédente, le noeud LPAR1 aurait un système de fichiers de configuration :
       /var/WebSphere/V9R0F1
        /DeploymentManager - home to deployment manager F1DMGR in cell F1CELL
        /AppServer1 - home to node F1NODEA and servers F1SR01A and F1SR02A
      et LPAR2 aurait un système de fichiers distinct au même point de montage :
      /var/WebSphere/V9R0F1
        /AppServer2 - home to node F1NODEB and servers F1SR02B (clustered) 
          and F1SR03B
      Néanmoins, le déplacement de l'un des noeuds LPAR vers l'autre système exigerait la fusion d'une copie d'uns des systèmes de fichiers de configuration dans un autre.
  • Dans un sysplex z/OS multisystème avec un système de fichiers partagé :

    Si votre sysplex comporte un système hiérarchique de fichiers de configuration partagé, vous pouvez simplement monter un grand système de fichiers de configuration pour l'intégralité de la cellule. Lorsque vous utilisez l'outil de gestion de profil, précisez le point de montage du système de fichiers de configuration de chaque système. Comme cela a été indiqué auparavant, il est recommandé de mettre le système de fichiers de configuration à jour depuis le système z/OS hébergeant le gestionnaire de déploiement. Les performances dépendent de la fréquence de modification de la configuration. Si cette option est retenue, prêtez une attention toute particulière aux optimisations.

    D'une autre manière, vous pouvez monter un système de fichiers de configuration sur chaque système, peut-être en utilisant un système de fichiers propre au système, monté sur /&SYSNAME de chaque système :
    /LPAR1/WebSphere/V9R0F1
      /DeploymentManager - home to deployment manager F1DMGR in cell F1CELL
      /AppServer1 - home to node F1NODEA and servers F1SR01A and F1SR02A
    
    /LPAR2/WebSphere/V9R0F1
      /AppServer2 - home to node F1NODEB and servers F1SR02B (clustered) 
        and F1SR03B
    Chaque système (LPAR1 et LPAR2) monte son système de fichiers de configuration sur un point de montage qui lui est propre. Lorsque vous utilisez l'outil de gestion de profil ou la commande zpmt, indiquez ce qui suit :
    • /LPAR1/WebSphere/V9R0F1 sur LPAR1
    • /LPAR2/WebSphere/V9R0F1 sur LPAR2
    Les performances sont meilleures avec cette option plutôt qu'avec un sysplex partagé et, selon le choix du point de montage, il peut s'avérer possible de monter un système de fichiers de configuration temporairement sur un autre LPAR si le propriétaire original est en panne. Vous pouvez rendre des procédures cataloguées spécifiques au système ou utiliser &SYSNAME pour sélectionner le point de montage du système de fichiers de configuration.
    Si vous souhaitez réellement utiliser le même point de montage apparent pour tous les fichiers de système de fichiers de configuration, vous pouvez utiliser des liens symboliques pour réacheminer un point de montage commun vers un système de fichier différent sur chaque système :
    • ln -s $SYSNAME/WebSphere WebSphere
    • Montez le système de fichiers de configuration de LPAR1 sur /LPAR1/WebSphere/V9R0F1.
    • Montez le système de fichiers de configuration de LPAR2 sur /LPAR2/WebSphere/V9R0F1.
    Si cette étape est réalisée correctement, vous pouvez spécifier un point de montage de configuration /WebSphere/V9R0F1 pour chaque système dans l'outil de gestion de profil ou la commande zpmt et continuer de profiter des avantages des fichiers du système de fichiers de personnalisation spécifique au système. Cependant, lorsque cette configuration est utilisée, il n'est pas possible de déplacer facilement les fichiers du système de fichiers de configuration d'un système à un autre. Tous les noeuds s'attendent à trouver leurs données dans /WebSphere/V9R0F1 et vous ne pouvez monter sur chaque système qu'un seul système de fichiers de configuration sur ce point de montage.
  • Recommandations :
    • Sur un système z/OS unique, créez un système de fichiers accessible en lecture-écriture sur /wasv90config, puis utilisez les valeurs par défaut de l'outil de gestion de profil pour monter chaque système de fichiers de configuration sur /wasv90config/nom_cellule/nom_noeud.
    • Sur un sysplex multisystème sans système de fichiers partagé, appliquez les recommandations précédentes pour un système z/OS simple. Cela vous permettra d'utiliser des procédures cataloguées communes pour chaque cellule. Etablissez des points de montage indépendants sur chaque système pour toute cellule qui pourrait exiger une récupération sur un autre système du sysplex.
    • Sur un sysplex multisystème avec un système de fichiers partagé, utilisez un système de fichiers de configuration partagé lorsque la performance n'est pas un problème ou lorsqu'un système de fichiers partagé est nécessaire à la prise en charge de fonctions spécifiques de WebSphere Application Server for z/OS. Utilisez des fichiers de système de fichiers de configuration non partagés lorsque la performance est un point essentiel ou dès lors que vous devez éviter un point de défaillance unique.

Choix des noms de répertoire de base pour WebSphere Application Server

Le répertoire de base de WebSphere Application Server est toujours relatif au système de fichiers de configuration dans lequel il se trouve. Dans l'outil de gestion de profil ou la commande zpmt, vous choisissez le point de montage du système de fichiers de configuration sur un écran et vous renseignez simplement le nom unique du répertoire de base sur un autre. Mais lorsqu'il vous est demandé de vous rendre dans le répertoire WAS_HOME d'un serveur, ce dernier désigne le chemin entier, le système de fichiers de configuration et le nom du répertoire de base combinés (/WebSphere/V9R0/AppServer par exemple).

Vous pouvez choisir librement un nom pour le répertoire de base, à condition que celui-ci soit unique dans le système de fichiers de configuration. Si vous créez un serveur d'applications autonome ou un nouveau noeud de serveur géré pour fédérer une cellule Network Deployment, prenez soin de choisir un nom qui ne soit pas utilisé par le système de fichiers de configuration de la cellule Network Deployment.

Si vous avez un noeud par système, il se peut que vous souhaitiez utiliser la même forme de nom de noeud ou de système. D'une autre manière, vous pouvez utiliser DeploymentManager pour le gestionnaire de déploiement et AppServern pour chaque noeud de serveur d'applications.

Relations entre le système de fichiers de configuration et le système de fichiers du produit

Le système de fichiers de configuration inclut un nombre important de liens symboliques vers des fichiers dans le système de fichiers du produit (par défaut, /usr/lpp/WebSphere/AppServer/V9R0). Cela permet aux processus serveur, à l'administrateur et aux clients d'accéder à un code WebSphere Application Server for z/OS cohérent.

Il est à noter que ces liens symboliques sont définis au moment de la création du répertoire de base de WebSphere Application Server et sont difficiles à modifier. Par conséquent, les systèmes qui exigent une haute disponibilité doivent conserver une copie indépendante des ensembles de données du produit et du système de fichiers du produit WebSphere Application Server for z/OS pour chaque niveau de maintenance ou de service en cours d'utilisation (test, assurance, production, etc.) afin de rendre la maintenance système possible. Ils doivent également utiliser des liens symboliques pour relier chaque système de fichiers à son système de fichiers du produit.

Conseil : Si vous configurez votre environnement de déploiement réseau en utilisant la valeur par défaut pour le chemin du système de fichiers du produit dans l'outil de gestion de profil ou la commande zpmt, tous les noeuds pointeront directement vers le point de montage du système de fichiers du produit. La maintenance ne nécessitant pas d'interruption est, de ce fait, presque impossible. Si une cellule est ainsi configurée, l'application d'un service au fichier système du produit affecte tous les noeuds en même temps ; et si des cellules multiples sont ainsi configurées, l'application d'un service au fichier système affecte toutes les cellules en même temps. Vous pouvez vouloir spécifier ce qu'on appelle un lien intermédiaire symbolique entre le fichier système de configuration de chaque noeud et l'actuel point de montage du fichier système du produit. Cette stratégie fait l'objet d'une description dans le livre blancWebSphere Application Server for z/OS V5 - Planning for Test, Production and Maintenance. Reportez-vous au livre blanc WebSphere z/OSV6 -- WSC Sample ND Configuration pour plus d'informations sur cette question et sur son lien avec les opérations de maintenance. Reportez-vous aux instructions WebSphere for z/OS: Updating an Existing Configuration HFS to Use Intermediate Symbolic Links sur l'obtention et l'utilisation d'un utilitaire qui vous permettrait de mettre à jour un système de fichiers de configuration existant à jour pour utiliser des liens symboliques intermédiaires.

Lorsqu'un noeud WebSphere Application Server for z/OS est démarré, le niveau de service de la configuration est comparé à celui du système de fichiers produit. Si le niveau de service du système de fichiers de configuration est supérieur à celui du système de fichiers produit (ce qui signifie probablement qu'un ancien système de fichiers produit est monté), les serveurs du noeud s'arrêteront en affichant un message d'erreur. Si le niveau de service du système de fichiers de configuration est inférieur à celui du système de fichiers produit (ce qui signifie que le service a été appliqué au code produit depuis le dernier démarrage du noeud), une tâche nommée post installateur vérifie toutes les actions qui doivent être réalisées sur le système de fichiers de configuration pour le maintenir à jour.


Icône indiquant le type de rubrique Rubrique de concept



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