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.

La fonction
collectiveController-1.0 et ses capacités ne sont
disponibles que dans WebSphere Application Server Network Deployment Liberty et
WebSphere Application Server for z/OS Liberty. Elle n'est pas disponible dans
WebSphere Application Server Liberty, ni
dans WebSphere Application Server Liberty Core. Si vous avez une installation WebSphere Application Server Network Deployment Liberty, vous pouvez utiliser sa fonction
collectiveController-1.0 pour travailler avec les membres de collectivités d'installations WebSphere Application Server Liberty 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.
Les règles suivantes s'appliquent :
- 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 :
wlp/bin/collective create myController --keystorePassword=controllerKSPassword --createConfigFile=c:/wlp/usr/servers/myController/collective-create-include.xml
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 :
<include location="c:\wlp\usr\servers\myController\collective-create-include.xml" />
- Mettez à jour le fichier server.xml
du contrôleur de collectivité.
- 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 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
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.
- 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 :
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é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é.wlp/bin/collective testConnection hostName,usrDirPath,serverName --host=controllerHost
--port=controllerHTTPSPort --user=controllerAdmin
--password=controllerAdminPassword--autoAcceptCertificates
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é.![[18.0.0.1 and later]](../ng_v18001plus.gif)
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