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.

Pour plateformes répartiesPour plateformes IBM iLa 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.

Multimédia Regardez : 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. [Retranscription]

Procédure

  1. Créez et configurez votre contrôleur.
    1. Créez un serveur qui sera le contrôleur de collectivité.
      wlp/bin/server create myController
    2. 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" />
    3. 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.

        1. Copiez la sortie depuis la commande de collectivité et collez-la dans le fichier server.xml.
        2. Indiquez les valeurs d'ID administrateur et de mot de passe pour la collectivité. Par exemple, remplacez :
          <quickStartSecurity userName="" userPassword="" />
          par :
          <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" />
    4. Démarrez le serveur du contrôleur de collectivité.
      wlp/bin/server start myController
      Figure 1. Collectivité comportant un membre
      Collectivité d'un seul membre
    5. Vérifiez que le serveur du contrôleur de collectivité est correctement démarré et qu'il est prêt à recevoir des membres.
      1. Ouvrez un éditeur dans le journal des messages du contrôleur, $WLP_USER_DIR/servers/myController/logs/messages.log.
      2. Recherchez le message :
        CWWKX9003I:
        Le bean géré CollectiveRegistration MBean est disponible.
  2. 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.

    1. Créez un serveur membre.
      wlp/bin/server create myMember
    2. 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 é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.

    3. Si vous êtes invité à accepter la chaîne de certificats, entrez y (oui).
    4. 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 :

        1. Copiez la sortie de la commande de collectivité et collez-la dans le fichier server.xml du membre.
        2. 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 :
          <httpEndpoint id="defaultHttpEndpoint" httpPort="9081" httpsPort="9444" />
          Vous pouvez aussi, pour accéder au serveur membre depuis un client distant, définir host="*" dans l'élément httpEndpoint.
        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>
    5. 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.

    6. Démarrez le serveur membre.
      wlp/bin/server start myMember
      Figure 2. Collectivité simple
      Collectivité simple
    7. Vérifiez que le serveur membre est correctement démarré et qu'il publie des informations sur le contrôleur.
      1. Ouvrez dans un éditeur le journal des messages du membre, $WLP_USER_DIR/servers/myMember/logs/messages.log.
      2. 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é.

Icône indiquant le type de rubrique Rubrique Tâche

Nom du fichier : tagt_wlp_configure_collective.html