Configuration d'une collectivité Liberty
Vous pouvez organiser les serveurs Liberty en collectivités pour prendre en charge la mise en cluster, l'administration et les autres opérations qui agissent sur plusieurs serveurs Liberty. L'utilisation de collectivités permet d'offrir des services d'application efficaces et précis.
Avant de commencer
Installation de Liberty avec les fonctions d'administration. Pour obtenir des instructions d'installation, voir la section "Avant de commencer" de Configuration de l'environnement de gestion de serveur pour Liberty à l'aide de collectivités. Les fonctions d'administration de Liberty fournissent des fonctions de gestion de serveurs multiples pour les collectivités, les clusters, la mise à l'échelle, le routage dynamique et Centre d'administration.
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é.
- Tous les membres d'une collectivité doivent se trouver dans le même centre de données. Une collectivité ne doit pas s'étendre sur plusieurs centres de données.
Regarder : La vidéo
Introduction to creating a collective montre cette procédure. Cette vidéo ainsi que d'autres informations sur les collectivités sont disponibles sur le
site Web WASdev. [Retranscription]
Procédure
- Créez et configurez votre contrôleur.
- Créez un serveur qui sera le contrôleur de collectivité.
wlp/bin/server create myController
- Créez la configuration du contrôleur de collectivité.
La configuration du contrôleur de collectivité est principalement la configuration de sécurité du domaine d'administration qui est utilisée pour la communication sécurisée entre les contrôleurs et les membres.
wlp/bin/collective create myController --keystorePassword=controllerKSPassword
Par défaut, cette commande de collectivité écrit toutes les sorties sur un écran de console. Dans l'étape suivante, vous copiez la sortie de configuration dans le fichier server.xml. Pour écrire la configuration dans un fichier au lieu d'un écran de console, spécifiez un paramètre --createConfigFile=outputFilePath, par exemple :
Après exécution de la commande create, l'instruction include à utiliser s'affiche. Pour inclure le fichier de sortie dans la configuration de la collectivité, ajoutez l'instruction include au fichier server.xml, comme illustré dans l'exemple suivant :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 sa sortie sur l'écran de la console, poursuivez avec les étapes suivantes.
- 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 un fichier server.env ou une fenêtre de commande, $WLP_USER_DIR/servers/myController/server.xml. Après édition, ce fichier ressemble à l'exemple suivant :<server description="controller server"> <!-- Enable features --> <featureManager> <feature>jsp-2.2</feature> </featureManager> <httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="9080" httpsPort="9443" /> <featureManager> <feature>collectiveController-1.0</feature> </featureManager> <!-- Define the host name for use by the collective. If the host name needs to be changed, the server should be removed from the collective and re-joined or re-replicated. --> <variable name="defaultHostName" value="controllerHostname" /> <!-- TODO: Set the security configuration for Administrative access --> <quickStartSecurity userName="adminUser" userPassword="adminPassword" /> <!-- 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é. Après cette modification, le contenu du fichier sera similaire à l'exemple suivant :
<server description="controller server"> <!-- 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 myController
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 myMember
- Associez le membre.
Exécutez la commande de collectivité join afin de joindre le serveur à la collectivité en tant que membre. Exécutez la commande join à partir de l'installation Liberty se trouvant sur l'hôte 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é.
wlp/bin/collective join myMember --host=controllerHostname --port=9443 --user=adminUser --password=adminPassword --keystorePassword=memberKSPassword
Le paramètre optionnel --hostname indique le nom d'hôte à utiliser pour le système. Spécifiez-le dans la commande uniquement si le système a plusieurs noms d'hôte ou si son nom d'hôte n'est pas configuré. Si elle est fixée, sa valeur doit être identique à celle de la variable defaultHostName définie dans le fichier server.xml.
Pour réduire le nombre d'options nécessaires, utilisez l'option --controller à la place de --user, --password, --host et --port.
wlp/bin/collective join myMember --controller=user[:password]@host:HttpsPort --keystorePassword=memberKSPassword
Vous pouvez spécifier les variables de déploiement en utilisant le paramètre optionnel genDeployVariable. Pour plus d'informations, voir Génération de variables de déploiement lors du rattachement d'un serveur membre à une collectivité.
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 />
Par défaut, l'opération join laisse des données d'identification RPC indéfinies. Cela signifie que vous devez indiquer des valeurs pour rpcUser et rpcUserPassword, nom d'utilisateur et 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é et que l'hôte membre n'est pas activé pour SSH, 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. Généralement, les hôtes Linux sont activés pour SSH et les hôtes Windows ne sont pas activés pour SSH ; par conséquent, le paramètre --useHostCredentials est utile pour les hôtes membre Windows. 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 plus d'informations sur l'activation de la fonction SSH sur votre ordinateur hôte, voir Configuration de RXA pour les opérations de collectivité Liberty.
Pour plus d'informations sur ces paramètres obligatoires et sur les paramètres optionnels exécutez la commande collective help join en ligne de commande.
- 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 écrit sa sortie sur l'écran de la console, poursuivez avec les étapes suivantes :
- 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" />
Après sa modification, le fichier $WLP_USER_DIR/servers/myMember/server.xml sera similaire à l'exemple suivant :<server description="member server"> <!-- Enable features --> <featureManager> <feature>jsp-2.2</feature> </featureManager> <httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="9081" httpsPort="9444" /> <featureManager> <feature>collectiveMember-1.0</feature> </featureManager> <!-- Define the host name for use by the collective. If the host name needs to be changed, the server should be removed from the collective and re-joined or re-replicated. --> <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 consigné la sortie dans un fichier à l'aide du paramètre --createConfigFile=outputFilePath, ajoutez une instruction include au fichier $WLP_USER_DIR/servers/myMember/server.xml pour inclure le fichier de sortie dans la configuration de la collectivité. Par exemple :
<server description="member server"> <!-- 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 et que l'hôte membre n'est pas activé pour SSH, 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 :
- Pour z/OS uniquement, émettez la commande updateHost pour spécifier le répertoire JAVA_HOME membre du contrôleur.
wlp/bin/collective updateHost controllerHostname --host=controllerHostname --port=9443 --user=adminUser --password=adminPassword --hostWritePath=/dir1 --rpcUser=rpcUser --rpcUserPassword=rpcUserPassword --hostJavaHome=JAVA_HOME
Pour réduire le nombre d'options nécessaires, utilisez l'option --controller au lieu de --user, --password, --host et --port :
wlp/bin/collective updateHost controllerHostname --controller=adminUser:adminPassword@controllerHostname:9443 --hostWritePath=/dir1 --rpcUser=rpcUser --rpcUserPassword=rpcUserPassword --hostJavaHome=JAVA_HOME
Le paramètre hostWritePath spécifie les répertoires dans lesquels le contrôleur de collectivité peut écrire des données. Les chemins spécifiés par le paramètre sont également lisibles.
hostWritePathLe paramètre hostJavaHome spécifie le chemin d'accès absolu correspondant à l'endroit où se trouve la machine virtuelle Java sur le système et où le serveur membre s'exécute, par exemple : /usr/lpp/java/java_1.7_64.
Pour plus d'informations sur la spécification de JAVA_HOME, consultez Définition de la variable JAVA_HOME pour les membres de collectivité et les contrôleurs Liberty.
- Démarrez le serveur membre.
wlp/bin/server start myMember
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é.
- Facultatif :
Utilisez la commande testConnection pour valider la connectivité. La commande valide la connectivité RXA entre le contrôleur et l'hôte sur lequel réside le membre. Elle valide également la connectivité sécurisée JMX entre le contrôleur de collectivité et le membre de collectivité.
Où hostName,usrDirPath,serverName est le bloc de données qui décrit le serveur membre qui vient d'être associé : hostName est le nom de l'hôte sur lequel réside le membre de collectivité. userDirPath est l'annuaire d'utilisateurs du membre de collectivité. serverName est le nom du membre de collectivité.wlp/bin/collective testConnection hostName,usrDirPath,serverName --host=controllerHost --port=controllerHTTPSPort --user=controllerAdmin --password=controllerAdminPassword--autoAcceptCertificates
Sinon, vous pouvez utiliser l'option --controller simplifiée pour fournir des informations spécifiques du contrôleur.
wlp/bin/collective testConnection hostName,usrDirPath,serverName --controller=user[:password]@host:HttpsPort --autoAcceptCertificates
- Créez un serveur membre.
Sous-rubriques
- Configuration d'une collectivité Liberty à l'aide des outils de développement
Le menu Utilitaires des outils de développement Liberty comporte une option permettant de créer un contrôleur de collectivité ou de joindre une collectivité. - Génération de variables de déploiement lors du rattachement d'un serveur membre à une collectivité
Vous pouvez utiliser l'option genDeployVariables de la commande join de la collectivité pour affecter des variables de déploiement (ports) lorsque vous rattachez un serveur membre à une collectivité.

Nom du fichier : tagt_wlp_configure_collective.html