Configuration d'une collectivité Liberty
Vous pouvez organiser les serveurs Liberty en collectivités en vue de la prise en charge de la mise en cluster, de l'administration et d'autres opérations qui agissent sur plusieurs serveurs Liberty simultanément afin de distribuer efficacement et précisément des services d'application à votre organisation.


Avant de commencer
La fonction collectiveController-1.0 et ses capacités sont disponibles dans WebSphere Application Server Liberty Network Deployment et WebSphere Application Server Liberty pour z/OS seulement. La fonction n'est pas disponible dans WebSphere Application Server Liberty, WebSphere Application Server Liberty - Express ni WebSphere Application Server Liberty Core. Si vous disposez d'une installation WebSphere Application Server Liberty Network Deployment, vous pouvez utiliser sa fonction collectiveController-1.0 pour travailler avec des membres de collectivité d'installations WebSphere Application Server Liberty, WebSphere Application Server Liberty - Express ou WebSphere Application Server Liberty Core.
Pourquoi et quand exécuter cette tâche
Une collectivité Liberty est un ensemble de serveurs Liberty qui sont configurés dans le même domaine d'exploitation et d'administration.
Les données de configuration et d'état concernant une collectivité Liberty sont hébergées dans un référentiel d'exploitation actif.
L'appartenance à une collectivité Liberty est facultative. Les serveurs Liberty rejoignent une collectivité en s'enregistrant auprès d'un contrôleur de collectivité pour devenir membres. Les membres partagent des informations sur eux-mêmes via le référentiel d'exploitation du contrôleur.
- Un serveur Liberty ne peut être membre que d'une seule collectivité.
- Différents serveurs Liberty sur le même hôte peuvent appartenir à différentes collectivités.
- Les serveurs Liberty qui se trouvent sur le même hôte et qui sont membres d'une collectivité peuvent coexister avec des serveurs Liberty qui ne sont pas membres d'une collectivité.
Regardez : La vidéo Introduction to creating a collective illustre la procédure. Cette vidéo ainsi que d'autres informations sur les collectivités sont disponibles sur le
site Web WASdev. [Transcription]
Procédure
- Créez et configurez votre contrôleur.
- Créez un serveur qui sera le contrôleur de collectivité.
wlp/bin/server create monContrôleur
- Créez la configuration du contrôleur de collectivité.
Il s'agit principalement de la configuration de sécurité du domaine d'administration utilisée pour la communication sécurisée entre les contrôleurs et les membres.
wlp/bin/collective create monContrôleur --keystorePassword=motdepasseFichierClésContrôleur
Par défaut, cette commande de collectivité affiche la sortie dans un écran de console. A l'étape suivante, vous copiez la sortie dans le fichier server.xml. Pour écrire la sortie dans un fichier au lieu de l'afficher dans un écran de console, spécifiez le paramètre facultatif --createConfigFile=cheminFichierSortie, par exemple :
Après exécution de la commande create, l'instruction include à utiliser s'affiche. Pour inclure le le fichier de sortie dans la configuration de la collectivité, ajouytez l'instruction include dans le fichier server.xml, par exemple :wlp/bin/collective create myController --keystorePassword=controllerKSPassword --createConfigFile=c:/wlp/usr/servers/myController/collective-create-include.xml
<include location="c:\wlp\usr\servers\myController\collective-create-include.xml" />
- Mettez à jour le fichier server.xml
du contrôleur de collectivité.
- Copiez et collez la sortie.
Si la commande a écrit la sortie sur écran de console :
- Copiez la sortie depuis la commande de collectivité et collez-la dans le fichier server.xml.
- Indiquez les valeurs d'ID administrateur et de mot de passe
pour la collectivité.
Par exemple, remplacez :
par :<quickStartSecurity userName="" userPassword="" />
<quickStartSecurity userName="adminUser" userPassword="adminPassword" />
Le chemin par défaut pour le fichier server.xml du contrôleur de collectivité est ${wlp.install.dir}/usr/servers/myController/server.xml ou, si la variable $WLP_USER_DIR st définie dans une fichier server.env ou une fenêtre de commande, $WLP_USER_DIR/servers/myController/server.xml. Après édition, ce fichier ressemble à ceci :<server description="serveur de contrôleur"> <!-- Enable features --> <featureManager> <feature>jsp-2.2</feature> </featureManager> <httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="9080" httpsPort="9443" /> <featureManager> <feature>collectiveController-1.0</feature> </featureManager> <!-- Définissez le nom d'hôte à utiliser par la collectivité. Si le nom d'hôte doit être modifié, le serveur doit être supprimé de la collectivité et joint ou répliqué à nouveau. --> <variable name="defaultHostName" value="controllerHostname" /> <!-- TODO : Définissez la configuration de sécurité pour l'accès administratif --> <quickStartSecurity userName="utilisateurAdmin" userPassword="motdepasseAdmin" /> <!-- clientAuthenticationSupported set to enable bidirectional trust --> <ssl id="defaultSSLConfig" keyStoreRef="defaultKeyStore" trustStoreRef="defaultTrustStore" clientAuthenticationSupported="true" /> <!-- inbound (HTTPS) keystore --> <keyStore id="defaultKeyStore" password="yourPassword" location="${server.config.dir}/resources/security/key.jks" /> <!-- inbound (HTTPS) truststore --> <keyStore id="defaultTrustStore" password="yourPassword" location="${server.config.dir}/resources/security/trust.jks" /> <!-- server identity keystore --> <keyStore id="serverIdentity" password="yourPassword" location="${server.config.dir}/resources/collective/serverIdentity.jks" /> <!-- collective trust keystore --> <keyStore id="collectiveTrust" password="yourPassword" location="${server.config.dir}/resources/collective/collectiveTrust.jks" /> <!-- collective root signers keystore --> <keyStore id="collectiveRootKeys" password="yourPassword" location="${server.config.dir}/resources/collective/rootKeys.jks" /> </server>
Ajoutez une instruction include.
Si vous avez écrit la sortie dans un fichier à l'aide du paramètre --createConfigFile=outputFilePath, ajoutez une instruction include au fichier $WLP_USER_DIR/servers/myController/server.xml pour inclure le fichier de sortie dans la configuration de la collectivité, par exemple :<server description="serveur de contrôleur"> <!-- Enable features --> <featureManager> <feature>jsp-2.2</feature> </featureManager> <httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="9080" httpsPort="9443" /> <include location="c:\wlp\usr\servers\myController\collective-create-include.xml" /> </server>
Assurez-vous que fichier de sortie définit les valeurs d'ID administrateur et de mot de passe pour la collectivité, par exemple :<quickStartSecurity userName="adminUser" userPassword="adminPassword" />
- Copiez et collez la sortie.
- Démarrez le serveur du contrôleur de collectivité.
wlp/bin/server start monContrôleur
Figure 1. Collectivité comportant un membre - Vérifiez que le serveur du contrôleur de collectivité est
correctement démarré et qu'il est prêt à recevoir des membres.
- Ouvrez un éditeur dans le journal des messages du contrôleur, $WLP_USER_DIR/servers/myController/logs/messages.log.
- Recherchez le message :
CWWKX9003I: Le bean géré CollectiveRegistration MBean est disponible.
- Créez un serveur qui sera le contrôleur de collectivité.
- Créez et configurez un membre pour joindre la collectivité.
Le contrôleur et les membres peuvent être sur des hôtes distincts. Dans cet exemple, le contrôleur et les membres figurent sur le même hôte.
- Créez un serveur membre.
wlp/bin/server create monMembre
- Associez le membre.
Exécutez la commande de collectivité join afin de joindre le serveur à la collectivité en tant que membre. La commande join requiert une connexion réseau sur le contrôleur de collectivité et un ID utilisateur d'administration et mot de passe pour effectuer des opérations MBean sur le contrôleur. Consultez le fichier server.xml du contrôleur de collectivité pour trouver les valeurs des paramètres --host, --port, --user et --password. Pour le paramètre --keystorePassword, définissez une valeur à utiliser pour le mot de passe de fichier de clés du membre, par exemple memberKSPassword. Vous pouvez indiquer différentes valeurs --keystorePassword pour chaque serveur qui a rejoint la collectivité. Pour plus d'informations sur ces paramètres obligatoires et sur les paramètres facultatifs, exécutez la commande collective help join en ligne de commande.
wlp/bin/collective join myMember --host=controllerHostname --port=9443 --user=adminUser --password=adminPassword --keystorePassword=memberKSPassword
Par défaut, l'opération join laisse des données d'identification RPC indéfinies, ce qui implique que vous indiquiez des valeurs pour rpcUser et rpcUserPassword, le nom d'utilisateur et le mot de passe de connexion au système d'exploitation pour l'hôte sur lequel réside le serveur membre. Si l'hôte membre est enregistré auprès du contrôleur de collectivité, indiquez un paramètre --useHostCredentials facultatif afin de permettre au membre d'hériter de données d'identification RPC de son enregistrement hôte sur le contrôleur. L'indication de --useHostCredentials ajoute <hostAuthInfo useHostCredentials="true" /> dans le fichier server.xml du membre. Vous pouvez ensuite exécuter des commandes de membre de collectivité, telles que start ou stop, sans indiquer de données d'identification RPC car le membre hérite des données d'identification de son hôte. Pour plus d'informations sur hostAuthInfo, le paramètre --useHostCredentials et la connexion du contrôleur de collectivité au serveur, voir Remplacement des informations sur l'hôte de serveur Liberty.
Pour écrire la sortie de cette commande de collectivité dans un fichier au lieu de l'afficher dans un écran de console, spécifiez le paramètre facultatif --createConfigFile=cheminFichierSortie. Ensuite, incluez le fichier de sortie dans la configuration de la collectivité en ajoutant une instruction include au fichier server.xml du membre :
<include location=outputFilePath />
- Si vous êtes invité à accepter la chaîne de certificats, entrez y (oui).
- Mettez à jour le fichier server.xml du
membre.
- Copiez et collez la sortie.
Si la commande a affiché la sortie dans un écran de console :
- Copiez la sortie de la commande de collectivité et collez-la dans le fichier server.xml du membre.
- Modifiez les ports pour que le serveur puisse ouvrir ses ports HTTP. Assurez-vous
que le membre server.xml définit des
numéros de port HTTP uniques sur son hôte. Par exemple, si le membre
se trouve sur le même hôte que le contrôleur de collectivité,
modifiez les numéros de port HTTP :
Vous pouvez aussi, pour accéder au serveur membre depuis un client distant, définir host="*" dans l'élément httpEndpoint.<httpEndpoint id="defaultHttpEndpoint" httpPort="9081" httpsPort="9444" />
Dans $WLP_USER_DIR/servers/myMember/server.xml, par exemple :<server description="serveur de membre"> <!-- Enable features --> <featureManager> <feature>jsp-2.2</feature> </featureManager> <httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="9081" httpsPort="9444" /> <featureManager> <feature>collectiveMember-1.0</feature> </featureManager> <!-- Définissez le nom d'hôte à utiliser par la collectivité. Si le nom d'hôte doit être modifié, le serveur doit être supprimé de la collectivité et joint ou répliqué à nouveau. --> <variable name="defaultHostName" value="memberHostname" />
<!-- Remote host authentication configuration --> <hostAuthInfo rpcUser="admin_user_id" rpcUserPassword="admin_user_password" /> <!-- Connection to the collective controller --> <collectiveMember controllerHost="controllerHostname" controllerPort="9443" /> <!-- clientAuthenticationSupported set to enable bidirectional trust --> <ssl id="defaultSSLConfig" keyStoreRef="defaultKeyStore" trustStoreRef="defaultTrustStore" clientAuthenticationSupported="true" /> <!-- inbound (HTTPS) keystore --> <keyStore id="defaultKeyStore" password="yourPassword" location="${server.config.dir}/resources/security/key.jks" /> <!-- inbound (HTTPS) truststore --> <keyStore id="defaultTrustStore" password="yourPassword" location="${server.config.dir}/resources/security/trust.jks" /> <!-- server identity keystore --> <keyStore id="serverIdentity" password="yourPassword" location="${server.config.dir}/resources/collective/serverIdentity.jks" /> <!-- collective truststore --> <keyStore id="collectiveTrust" password="yourPassword" location="${server.config.dir}/resources/collective/collectiveTrust.jks" /> </server>
Ajoutez une instruction include.
Si vous avez écrit la sortie dans un fichier à l'aide du paramètre --createConfigFile=outputFilePath, ajoutez une instruction include dans $WLP_USER_DIR/servers/myMember/server.xml afin d'inclure le fichier en sortie, par exemple :<server description="serveur de membre"> <!-- Enable features --> <featureManager> <feature>jsp-2.2</feature> </featureManager> <httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="9081" httpsPort="9444" /> <include location="c:\wlp\usr\servers\myMember\collective-join-include.xml" /> </server>
- Copiez et collez la sortie.
Si vous n'avez pas indiqué --useHostCredentials dans la commande join, définissez des données d'identification RPC pour hostAuthInfo dans le fichier server.xml ou le fichier de sortie du membre. Vous pouvez définir les données d'identification RPC pour le serveur membre de deux manières :
- Définissez les utilisateur et mot de passe RPC de
hostAuthInfo.
Définissez rpcUser sur un ID utilisateur de
connexion du système d'exploitation pour l'hôte sur lequel réside le
serveur membre et définissez
rpcUserPassword
sur le mot de passe de connexion du système d'exploitation pour l'ID
utilisateur. Par exemple, si vous vous connectez à l'ordinateur
membre avec le nom d'utilisateur test1
et le mot de passe test1pwd, modifiez l'élément
hostAuthInfo comme suit :
<hostAuthInfo rpcUser="test1" rpcUserPassword="test1pwd" />
- Si l'hôte membre est enregistré auprès du
contrôleur de collectivité, définissez hostAuthInfo
useHostCredentials sur true afin
que le serveur membre hérite des données d'identification
RPC de
son hôte.
<hostAuthInfo useHostCredentials="true" />
Pour plus d'informations sur les paramètres hostAuthInfo et pour afficher un exemple indiquant comment enregistrer un hôte membre et exécuter la commande join avec --useHostCredentials, voir Remplacement des informations sur l'hôte de serveur Liberty.
- Définissez les utilisateur et mot de passe RPC de
hostAuthInfo.
Définissez rpcUser sur un ID utilisateur de
connexion du système d'exploitation pour l'hôte sur lequel réside le
serveur membre et définissez
rpcUserPassword
sur le mot de passe de connexion du système d'exploitation pour l'ID
utilisateur. Par exemple, si vous vous connectez à l'ordinateur
membre avec le nom d'utilisateur test1
et le mot de passe test1pwd, modifiez l'élément
hostAuthInfo comme suit :
- Démarrez le serveur membre.
wlp/bin/server start monMembre
Figure 2. Collectivité simple - Vérifiez que le serveur membre est correctement démarré et
qu'il publie des informations sur le contrôleur.
- Ouvrez dans un éditeur le journal des messages du membre, $WLP_USER_DIR/servers/myMember/logs/messages.log.
- Recherchez le messages suivant dans n'importe quel ordre :
CWWKX8112I: Les informations hôte du serveur ont été publiées sur le référentiel de collectivité. CWWKX8114I: Les chemins du serveur ont été publiés sur le référentiel de collectivité. CWWKX8116I: L'état du serveur DEMARRE a été publié sur le référentiel de collectivité.
- Créez un serveur membre.
Sous-rubriques
Configuration d'une collectivité Liberty à l'aide d'outils de développement
Le menu Utilitaires des outils de développement du profil Liberty comporte une option permettant de créer un contrôleur de collectivité ou de joindre une collectivité.

Dispositions pour les centres de documentation | Commentaires

http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=tagt_wlp_configure_collective
Nom du fichier : tagt_wlp_configure_collective.html