Meilleures pratiques concernant la commande addNode

La commande addNode permet d'ajouter un noeud autonome dans une cellule.

La commande addNode effectue les opérations suivantes :
  • Elle copie la configuration de base de la cellule WebSphere Application Server dans une nouvelle structure de cellule. Cette dernière est similaire à la structure du gestionnaire de déploiement.
  • Elle crée une définition d'agent de noeud pour le noeud incorporé par la cellule.
  • Elle envoie des commandes au gestionnaire de déploiement pour ajouter les documents du nouveau noeud au référentiel de la cellule.
  • Elle effectue la première synchronisation de la configuration du nouveau noeud et vérifie que ce noeud est synchronisé avec la cellule.
  • Elle lance le processus d'agent de noeud du nouveau noeud.
  • Elle met à jour les fichiers setupCmdLine.bat ou setupCmdline.sh, ainsi que le fichier wsadmin.properties pour faire référence à la nouvelle cellule.
  • Après avoir fédéré le noeud, la commande addNode sauvegarde le fichier plugin-cfg.xml depuis le répertoire racine_serveur_app/config/cells dans le répertoire config/backup/base/cells. La commande addNode re-génère un fichier plugin-cfg.xml au niveau du gestionnaire de déploiement et l'opération nodeSync copie les fichiers au niveau du noeud.

    [AIX Solaris HP-UX Linux Windows]Pour plus d'informations sur les numéros de port, voir la rubrique Paramètres de numéro de port.

Conseils d'utilisation de la commande addNode :
  • Si vous ajoutez un noeud dans une cellule, le nom de cellule du noeud que vous fédérez doit être différent du nom de la cellule dans laquelle le noeud est fédéré. Dans le cas contraire, le message ADMU0027E est émis et la commande addNode n'ajoute pas le noeud dans la cellule.
  • Vérifiez que le gestionnaire de déploiement et les noeuds ont été mis à jour et présentent le même niveau de révision dans WebSphere Application Server. En effet, un gestionnaire de déploiement dont le niveau serait par exemple de 6.0.1 ne pourrait pas fédérer des noeuds de niveau 6.0.2.
  • Ne placez pas les fichiers .jar de WebSphere Application Server sur la variable générique CLASSPATH (chemin d'accès aux classes par défaut) pour l'ensemble du système.
  • [AIX Solaris HP-UX Linux Windows]Si le produit WebSphere Application Server, Network Deployment ne peut pas résoudre le nom d'hôte du serveur, des incidents peuvent se produire lors de l'ajout ou de l'administration des noeuds ou au niveau de l'agent de noeud qui contacte le serveur d'applications. Pour résoudre le nom d'hôte, le produit ouvre un port ou demande une adresse IP. Le produit attend ensuite que le système d'exploitation renvoie les informations correctes. Le système d'exploitation peut rechercher l'adresse IP dans plusieurs emplacements, mais le produit se soucie peu de l'ordre dans lequel le système d'exploitation fait cette recherche, si les informations correctes sont renvoyées. Si le nom d'hôte du serveur ne peut pas être résolu, consultez votre documentation d'administration de réseau pour résoudre l'incident. Les informations supplémentaires ci-dessous peuvent vous aider à vous assurer que le nom d'hôte est résolu.
    • Certains systèmes d'exploitation créent une association entre le nom d'hôte de la machine et l'adresse de bouclage de 127.0.0.1. Par défaut, les installations Red Hat créent l'association. Les installations SuSE créent une association du même type avec l'adresse de bouclage 127.0.0.2. L'association se trouve dans le fichier d'hôtes.

      Si le fichier hosts comporte des mappages de l'adresse IP 127.0.0.1 ou 127.0.0.2 vers un nom d'hôte autre que localhost, supprimez les mappages. L'exemple ci-dessous illustre ce qui peut se produire si les mappages ne sont pas supprimés : lorsqu'un agent de noeud communique avec le gestionnaire de déploiement, il envoie son adresse IP au gestionnaire de déploiement. L'agent de noeud résout le nom d'hôte d'agent de noeud en 127.0.0.1 si le système d'exploitation renvoie un mappage pour le nom d'hôte à partir du fichier d'hôtes. Cette résolution empêche le gestionnaire de déploiement d'envoyer un message à l'agent de noeud car l'adresse IP 127.0.0.1 est également l'adresse IP de la machine locale du gestionnaire de déploiement.

      [AIX][HP-UX][Linux][Solaris]Le fichier hosts se trouve dans le répertoire /etc/hosts.

      [Windows]Le fichier hosts se trouve dans le répertoire \WINDOWS\system32\drivers\etc\hosts.

    • [AIX]L'installation AIX par défaut vérifie en premier le serveur de noms de domaine (DNS) pour renvoyer les informations à un serveur, de sorte que le nom d'hôte de ce serveur ou d'un autre serveur puisse être résolu. Si le nom d'hôte ne peut pas être résolu ou qu'il ne peut pas être résolu dans un délai raisonnable, vous pouvez ajouter l'instruction ci-dessous dans le fichier /etc/netsvc.conf, de sorte que le système d'exploitation AIX recherche d'abord le nom d'hôte dans le fichier d'hôtes locaux.
      hosts=local,bind
  • Par défaut, les applications installées sur le noeud ne seront pas copiées dans la cellule. Si vous installez une application après avoir utilisé la commande addNode, l'application est installée dans la cellule. En spécifiant l'option -includeapps, vous obligez la commande addNode à copier les applications du noeud dans la cellule. Les applications de même noms ne sont pas copiées dans la cellule.
  • Les documents au niveau de la cellule ne sont pas fusionnés. Toutes les modifications que vous apportez aux documents autonomes de niveau cellule avant d'utiliser la commande addNode doivent être répétées dans la nouvelle cellule. Par exemple, les hôtes virtuels.
  • Si vous recevez une exception OutOfMemory alors que vous utilisez la commande addNode, vous devrez peut-être augmenter la taille du segment de mémoire du gestionnaire de déploiement. Pour augmenter la taille de segment de mémoire maximale, réglez le paramètre Taille de segment maximale. Ainsi, dans la console d'administration, accédez à Administration système > Gestionnaire de déploiement > Gestion des processus et Java > Définition des processus > Machine virtuelle Java, puis augmentez la valeur de Taille maximale du segment de mémoire.
    Eviter les incidents Eviter les incidents: sous les systèmes d'exploitation HP-UX ou Solaris, un problème d'espace java.lang.OutOfMemoryError: PermGen peut survenir durant les tâches complexes et de grande taille. Par exemple, vous pouvez rencontrer ce problème lorsque vous exécutez des commandes telles que addNode sur des noeuds avec des applications de grande taille. Lorsque les demandes de ressources dépassent la taille de stockage par défaut, la tâche peut échouer avec une erreur d'espace java.lang.OutOfMemoryError: PermGen. Pour résoudre ce problème, augmentez la taille minimale de la région permanente. Définissez l'option JVM (Java™ virtual machine) -XX:PermSize sur une valeur telle que 128MB, qui est suffisante pour la plupart des cas lorsque le problème survient :
    XX:PermSize=128m
    gotcha
  • Dans certains cas, il se peut que le gestionnaire de déploiement mette plus de temps que prévu pour répondre à la commande addNode. La valeur par défaut du délai d'expiration, qui détermine combien de temps le client attendra une réponse du serveur, convient dans la plupart des cas. Cependant, il se peut que vous ayez besoin de laisser plus de temps à votre serveur pour répondre lorsque les conditions de traitement sont plus chargées. Par exemple, si vous incluez l'option -includeapps et que vous avez un grand nombre d'applications, ou que vos applications sont très volumineuses, la valeur par défaut de 180 peut s'avérer insuffisante. Pour modifier la valeur de délai d'attente par défaut, ouvrez le fichier racine_serveur_app/profiles/nom_profil/properties/soap.client.props dans un éditeur de texte ASCII et recherchez la ligne suivante (présentée ici avec une valeur par défaut de 180 secondes) :
    com.ibm.SOAP.requestTimeout=180
    Si vous devez modifier la valeur par défaut, vous pouvez éditer cette ligne pour définir le délai d'expiration sur une valeur convenant mieux à votre situation.
    Remarque : Si vous définissez la valeur ci-dessus sur 0, vous désactiverez totalement le contrôle du délai d'expiration.

    Si la valeur définie pour le délai d'expiration est trop importante, vous devrez patienter un long moment pour déterminer si la commande addNode exécutera avec succès sa requête auprès du gestionnaire de déploiement. Si cette valeur est trop basse, le gestionnaire de déploiement ne disposera pas de suffisamment de temps pour exécuter la requête avant que la commande addNode ne conclue que le gestionnaire de déploiement ne répond pas et ne réponde par une erreur. D'autres facteurs peuvent affecter les délais d'expiration du serveur, par exemple la charge de traitement ou une pagination excessive sur le gestionnaire de déploiement et le délai d'attente du réseau. Certaines de ces situations peuvent être provisoires.

  • Si la commande addNode génère un message d'erreur indiquant des erreurs de synchronisation des horloges, vérifiez que l'horloge de l'ordinateur contenant le noeud à fédérer est synchronisée avec celle de l'ordinateur du gestionnaire de déploiement avec laquelle le noeud doit être fédéré.
  • Si vous utilisez la commande addNode à partir d'un noeud qui a été fédéré à un gestionnaire de déploiement existant, le gestionnaire de déploiement sera corrompu. Vous ne pourrez pas démarrer le gestionnaire de déploiement après l'avoir arrêté. Cela est dû au fait que la commande addNode crée un répertoire dmgrProfile]/config/cells/dmgrCell/dmgrCell dans la configuration principale. Il s'agit d'un répertoire de configuration de noeud incorrect.

    Vous rencontrerez ce problème si vous disposez d'un noeud fédéré et que vous exécutez de nouveau la commande addNode pour un autre gestionnaire de déploiement. Le gestionnaire de déploiement devient donc corrompu et vous ne pourrez pas le démarrer par la suite en raison d'un répertoire de noeud incomplet.

    Effectuez l'une des opérations suivantes pour résoudre ce problème :
    • Si le gestionnaire de déploiement est en cours d'exécution, vous pouvez utiliser la commande cleanupNode du gestionnaire de déploiement sur lequel réside le noeud incomplet.
    • Supprimez manuellement le répertoire qui a été créé dans la configuration du gestionnaire de déploiement lors d'une opération de commande addNode qui était incomplète. Par exemple : racine_serveur_app/profiles/dmgrProfile/config/cells/dmgrCell/nomNoeud.

Icône indiquant le type de rubrique Rubrique de référence



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=rxml_nodetips
Nom du fichier : rxml_nodetips.html