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.

Pour plateformes répartiesPour plateformes IBM i

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.

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é.

Multimédia 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

  1. Créez et configurez votre contrôleur.
    1. Créez un serveur qui sera le contrôleur de collectivité.
      wlp/bin/server create monContrôleur
    2. 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
      [8.5.5.2 ou ultérieure]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 :
      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 le fichier de sortie dans la configuration de la collectivité, ajouytez l'instruction include dans le fichier server.xml, par exemple :
      <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 la sortie sur écran de console :

        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 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>
      • [8.5.5.2 ou ultérieure]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" />
    4. Démarrez le serveur du contrôleur de collectivité.
      wlp/bin/server start monContrôleur
      Figure 1. Collectivité comportant un membre
      Collectivité comportant un 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 monMembre
    2. 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

      [8.5.5.4 ou ultérieure]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.

      [8.5.5.2 ou ultérieure]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 />
    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 affiché la sortie dans un écran de console :

        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.
        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" />
        
        [8.5.5.4 ou ultérieure]<!-- 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>
      • [8.5.5.2 ou ultérieure]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>
    5. [8.5.5.4 ou ultérieure]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.

    6. Démarrez le serveur membre.
      wlp/bin/server start monMembre
      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

Dispositions pour les centres de documentation | Commentaires


Icône d'horodatage Dernière mise à jour: Wednesday, 2 September 2015
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