Création de serveurs d'applications

Pendant le processus d'installation, le produit crée un serveur d'applications par défaut, appelé server1. La plupart des installations exigent plusieurs serveurs d'applications pour servir les applications et répondre à la demande de leur environnement de production. Vous pouvez utiliser l'outil de ligne de commande ou la console d'administration pour créer des serveurs d'applications supplémentaires.

A propos de cette tâche

Pour créer un nouveau serveur d'applications qui ne fait pas partie d'un cluster, vous pouvez soit utiliser le createApplicationServer, createWebServer, ou createGenericServer wsadmin ou vous pouvez utiliser la console d'administration.

Pour créer un serveur d'applications qui ne fasse pas partie d'un cluster, vous pouvez utiliser l'outil de gestion des profils ou la commande createApplicationServer, createWebServer ou createGenericServer. Vous pouvez également utiliser la console d'administration.

Si vous migrez d'une version antérieure du produit, vous pouvez mettre à niveau une partie des noeuds dans une cellule et laisser les autres au niveau de produit antérieur. Dans ce cas, pendant une période donnée, vous pouvez gérer des serveurs s'exécutant à deux niveaux différents dans la même cellule. Toutefois, lorsque vous créez une définition de serveur, vous devez utiliser un modèle de configuration de serveur qui doit être créé à partir d'une instance de serveur de la même version que le noeud du serveur pour lequel elle a été créée.

Il n'existe en revanche aucune limitation pour les serveurs de la version la plus à jour.

Évitez les ennuis : Si vous utilisez un anneau de sérialisation des ressources globales (GRS) pour attacher un ou plusieurs monoplex à un environnement sysplex, le nom de cellule de tout serveur exécuté dans l'un des monoplex doit être unique dans l'ensemble de 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.

S'il existe des serveurs possédant des noms de cellule en double dans l'environnement GRS, WebSphere Application Server ne peut pas faire la différence entre la cellule du sysplex et la cellule du monoplex et traite les deux serveurs comme s'ils appartenaient à la même cellule. Cette association de cellules incorrecte génère généralement des résultats de traitement imprévisibles.

Évitez les ennuis : Si vous utilisez des serveurs supplémentaires avec des ports uniques, WebSphere® Application Server ne configure pas automatiquement l'hôte virtuel pour le serveur. Spécifiquement, WebSphere Application Server n'ajoute pas automatiquement les ports d'alias d'hôte à un hôte virtuel. Vous pouvez cependant utiliser la console d'administration pour ajouter un nouvel alias d'hôte pour chacun des ports utilisés par le nouveau serveur. Pour plus d'informations, voir la documentation sur la configuration des hôtes virtuels.

Procédez comme suit pour utiliser la console d'administration pour créer un nouveau serveur d'application qui ne fasse pas partie d'un cluster.

1. Dans la console d'administration, cliquez sur Serveurs > Types de serveurs > WebSphere serveurs d'applications > Nouveau.

   L'assistant Créer un nouveau serveur d'application se lance.

2. Sélectionnez un noeud du serveur d'applications.
3. Entrez un nom pour le serveur d'applications. Ce nom doit être unique sur le noeud.
4. Cliquez sur Suivant.
5. Sélectionnez un modèle pour le nouveau serveur.

   Vous pouvez utiliser un modèle de serveur d'applications par défaut pour le nouveau serveur ou utiliser le modèle optimisé pour le développement. Le nouveau serveur d'applications hérite de tous les paramètres de configuration du serveur ayant servi de modèle.

6. Cliquez sur Suivant.

   Par défaut, cette option est activée. Si vous activez cette option, vous pouvez être amené à mettre à jour la liste des alias de l'hôte virtuel que vous avez l'intention d'utiliser avec ce serveur pour contenir ces nouvelles valeurs de port. Si vous désactivez cette option, assurez-vous que les valeurs de port par défaut sont compatibles avec d'autres serveurs installés sur la même machine physique.

7. Sélectionner Générez des ports HTTP uniques si vous souhaitez que l'assistant génère des ports uniques pour le serveur d'applications.
8. Facultatif: Cliquez sur Suivant et spécifiez un nom court pour le serveur.

   Ce nom abrégé est également utilisé comme nom de travail pour le serveur. Si vous ne spécifiez pas de valeur pour le nom abrégé, la valeur par défaut est BBOSnnn, où nnn représente le premier numéro disponible dans la cellule qui puisse être utilisé pour former un nom abrégé unique. Par exemple, si un nom abrégé par défaut est déjà attribué à deux autres serveurs de la cellule, le nom abrégé BBOS003 est attribué à ce serveur si vous n'en indiquez pas lors de la création de ce serveur

   Évitez les ennuis : Assurez-vous de configurer un RACF® Profil de classe SERVER qui inclut ce nom court.
9. Facultatif: Spécifiez un nom court générique pour le serveur.

   Le nom abrégé générique du serveur devient le nom de transition du cluster. Si vous n'indiquez pas de valeur pour la zone nom abrégé générique, la valeur par défaut est BBOCnnn où nnn correspond aux trois premiers chiffres dans la cellule pouvant être utilisés pour créer un nom abrégé générique unique. Par exemple, si un nom abrégé par défaut est déjà attribué à trois autres serveurs de la cellule, le nom abrégé BBOC004 est attribué à ce serveur si vous n'en indiquez pas lors de la création de ce serveur.

   Évitez les ennuis : Assurez-vous de configurer un RACF Profil de classe SERVER qui inclut ce nom court générique.
10. Cliquez sur Suivant. Vérifiez les paramètres du nouveau serveur.
11. Si vous souhaitez modifier l'un des paramètres, cliquez sur Précédent jusqu'à ce que vous reveniez à une page où vous pouvez modifier ce paramètre.
12. Cliquez sur Finition lorsque vous ne souhaitez apporter aucune modification supplémentaire.
13. Cliquez sur Revoir, sélectionner Synchroniser les modifications avec les nœuds, puis cliquez sur Sauvegarder pour enregistrer vos modifications.
14. Facultatif: Exécutez le updateZOSStartArgs script pour permettre à un serveur d'applications d'utiliser le z/OS fonction ASID réutilisable, si elle n'est pas déjà activée pour le nœud associé à ce serveur d'applications.

    Cette fonction permet à un serveur d'applications de réutiliser tous les ASID, y compris ceux qui sont associés aux services inter-processus.

    Évitez les ennuis : Avant d'exécuter ce script, vérifiez que vous l'exécutez sur z/OS Version 1.9 ou supérieur, et que la fonction de réutilisation ASID est activée pendant le z/OS processus de démarrage. Si la fonction n'est pas activée sur z/OS, l'exécution de ce script n'a aucun effet sur la manière dont les ASID sont gérés.