Configuration de jeux de serveurs secondaires de collectivité Liberty

Vous pouvez configurer des jeux de serveurs secondaires de collectivité. Un jeu de serveurs secondaires fournit des fonctions de gestion hautement disponibles pour un domaine d'administration Liberty.

Pourquoi et quand exécuter cette tâche

Un jeu de serveurs secondaires est un jeu de contrôleurs de collectivité qui sont configurés pour fonctionner ensemble. Chaque serveur secondaire contient toutes les mises à jour de référentiel que les autres serveurs secondaires du jeu ont traitées. Par conséquent, il n'est pas nécessaire pour un membre ou un client de se connecter avec un contrôleur de collectivité particulier à chaque fois qu'il interagit avec la collectivité ; tout contrôleur de collectivité configuré dans le jeu de serveurs secondaires peut fournir les mêmes données.

Pour des instructions détaillées de création et de configuration d'un contrôleur de collectivité, voir Configuration d'une collectivité Liberty.

Vous pouvez suivre des procédures différentes pour configurer un jeu de serveurs secondaires de collectivité :

  1. Ajoutez un serveur secondaire à un jeu de serveurs secondaires existant.
  2. Modifiez la configuration par défaut du jeu de serveurs secondaires initial.

Voir Example: Create and activate a replica set pour un exemple de création d'un jeu de serveurs secondaires composé de trois contrôleurs de collectivité sur le même hôte.

Un jeu de serveurs secondaires requiert un nombre impair de serveurs secondaires.

Procédure

  1. Ajoutez un serveur secondaire à un jeu de serveurs secondaires existant.

    Au cours de l'existence d'un jeu de serveurs secondaires, il peut devenir nécessaire d'ajouter un ou plusieurs serveurs secondaires à un jeu existant, afin d'augmenter la capacité par exemple.

    La configuration des serveurs secondaires existants dans le jeu de serveurs secondaires n'exige pas de mise à jour. Vous pouvez décider de les mettre à jour pour que leurs configuration dans les fichiers server.xml reflètent plus précisément les serveurs secondaires qui constituent le jeu de serveurs secondaires, mais cette mise à jour est inutile et n'a pas d'impact sur leurs comportements.

    Remarque : Il n'est pas nécessaire de changer la valeur replicaSet dans le fichier server.xml d'un serveur secondaire existant du jeu. Aucune modification de la configuration d'un serveur secondaire existant n'est requise. Si vous voulez mettre à jour les valeurs replicaSet dans les configurations de serveurs secondaires existants dans le jeu pour que les valeurs de la configuration soient cohérentes pour tous les serveurs secondaires du jeu, vous devez définir la valeur false pour le paramètre isInitialReplicaSet dans les configurations des serveurs secondaires existants. Une fois la valeur replicaSet modifiée, celle-ci ne décrit plus l'ensemble de serveurs secondaires initial mais un ensemble modifié.
    Remarque : Lorsque vous faites référence à un serveur secondaire, vous devez être cohérent et utiliser la même valeur hôte:port. Si un nom d'hôte est utilisé, il doit toujours être utilisé. Ou, si une adresse IP est utilisée, elle doit toujours être utilisée.

    Pour ajouter un serveur secondaire, procédez comme suit :

    1. Assurez-vous que le jeu de serveurs secondaires existant est en cours d'exécution et que la plupart des serveurs secondaires sont disponibles.
    2. Créez un serveur qui sera le nouveau contrôleur de collectivité.
      wlp/bin/server create MyNewController
    3. Procédez à la réplication afin de transformer le nouveau serveur en contrôleur de collectivité.
      wlp/bin/collective replicate MyNewController 
         --host=host_of_running_controller  
         --port=https_port_of_running_controller 
         --user=userName_for_running_controller 
         --password=userPassword_for_running_controller 
         --keystorePassword=keystore_password_for_new_controller

      [18.0.0.1 and later]Pour réduire le nombre d'options nécessaires, utilisez l'option --controller à la place de --user, --password, --host et --port.

      wlp/bin/collective replicate MyNewController 
      --controller=userName_for_running_controller:userPassword_for_running_controller@host_of_running_controller:https_port_of_running_controller 
      --keystorePassword=keystore_password_for_new_controller

      La commande replicate affiche une sortie XML dans un écran de console. Vous copiez la sortie dans le fichier server.xml.

      Pour écrire la sortie de la commande dans un fichier au lieu de l'afficher dans un écran de console, spécifiez le paramètre --createConfigFile=chemin_fichier_sortie. Ensuite, incluez le fichier de sortie dans la configuration de la collectivité en ajoutant une instruction include au fichier server.xml :
      <include location=output_file_path />
    4. Configurez le fichier server.xml du nouveau serveur secondaire avec la sortie de la commande replicate.
      Copiez la sortie XML de la commande replicate dans le fichier server.xml. Vous pouvez modifier la configuration du serveur secondaire comme suit :
      • Paramètres obligatoires :
        Les valeurs doivent être définies de manière explicite. La sortie XML affichée par la commande replicate contient cette configuration et est suffisante pour ces paramètres.
        hostAuthInfo
        Informations d'authentification hôte contenant les propriétés nécessaires à un client distant pour démarrer le serveur. Ce paramètre n'est obligatoire que lorsque l'hôte du nouveau serveur secondaire n'est pas activé pour SSH. 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, il se peut que ce paramètre ne soit requis que sur les hôtes Windows. Définissez les données d'identification RPC pour le serveur secondaire de deux manières :
        • Définissez rpcUser sur un ID utilisateur de connexion du système d'exploitation pour l'hôte sur lequel réside le serveur secondaire 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 de serveur secondaire 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 de serveur secondaire est enregistré auprès du contrôleur de collectivité, définissez hostAuthInfo useHostCredentials sur true afin que le serveur secondaire hérite des données d'identification RPC de son hôte.
          <hostAuthInfo useHostCredentials="true" />

        Voir Remplacement des informations sur l'hôte de serveur Liberty pour plus d'informations sur les paramètres hostAuthInfo.

        replicaSet
        Liste séparée par des virgules qui contient hôte:port pour chaque paramètre replicaHosts et replicaPorts du jeu de serveurs secondaires, sans les valeurs du contrôleur de collectivité en cours d'ajout au jeu.
        Par exemple,
        original.host.com:10001 some.other.host.com:10003
        Au moins l'une des valeurs de ce jeu doit déjà être un serveur secondaire du jeu de serveurs secondaires existant.
      • Paramètres facultatifs :
        Ils prennent les valeurs par défaut, qui peuvent être modifiées.
        isInitialReplicaSet
        False
        replicaHost
        Nom d'hôte de chaque serveur secondaire individuel
        replicaPort
        Port de chaque serveur secondaire individuel

        Ce port n'est pas le port http ou https du contrôleur de collectivité, mais un port unique utilisé pour la communication entre les serveurs secondaires du jeu de serveurs secondaires.

        repositoryDir
        Répertoire utilisé pour stocker les données de référentiel.
      Voici un exemple d'ajout au fichier server.xml d'un nouveau serveur secondaire :
      <collectiveController replicaHost="localhost" 
         replicaPort="10012" 
         replicaSet="localhost:10010 localhost:10011" 
         isInitialReplicaSet="false"/> 
      La sortie XML affichée par la commande replicate requiert la mise à jour de la configuration de sécurité du serveur ainsi que la spécification du mot de passe du magasin de clés collectiveRootKeys. La configuration de sécurité du serveur doit être identique à la configuration du contrôleur de collectivité d'origine, et le mot de passe du magasin de clés collectiveRootKeys doit être celui qui est utilisé pour le magasin de clés collectiveRootKeys du contrôleur de collectivité d'origine. Si le serveur secondaire a été créé depuis le contrôleur qui est créé dans Configuration d'une collectivité Liberty, la configuration du nouveau contrôleur doit contenir le code suivant :
      <quickStartSecurity userName="adminUser" userPassword="adminPassword" />
        <!-- collective root signers keystore -->
        <keyStore id="collectiveRootKeys" password="yourPassword"
          location="${server.config.dir}/resources/collective/rootKeys.jks" />
    5. Démarrez le nouveau serveur secondaire en démarrant le nouveau contrôleur de collectivité.
    6. Confirmez que le contrôleur de collectivité d'origine s'est connecté au nouveau serveur secondaire. Recherchez le message CWWKX6009I dans le fichier messages.log du contrôleur de collectivité d'origine et du serveur secondaire.
      Conseil : Pour les scripts qui exécutent les commandes replicate et addReplica, ajoutez une pause de 10 secondes après exécution de la commande replicate afin de permettre au contrôleur de collectivité d'origine et au serveur secondaire de se connecter avant l'exécution de la commande addReplica.
    7. Appelez l'opération addReplica sur l'utilitaire collectif pour activer le nouveau serveur secondaire. L'argument de addReplica doit être le noeud final du serveur secondaire sous la forme "replicaHost:replicaPort") du serveur secondaire à ajouter.
      wlp/bin/collective addReplica localhost:10012 
        --host=host_of_running_controller
        --port=port_of_running_controller
        --user=user_for_running_controller
        --password=user_password

      [18.0.0.1 and later]Pour réduire le nombre d'options nécessaires, utilisez l'option --controller à la place de --user, --password, --host et --port.

      wlp/bin/collective addReplica localhost:10012 --controller=user_for_running_controller:user_password@host_of_running_controller:port_of_running_controller
  2. Facultatif : Si nécessaire, vous pouvez modifier la configuration par défaut du jeu de serveurs secondaires initial. Cette étape est recommandée mais pas obligatoire.

    La configuration du jeu de serveurs secondaires initial a lieu lorsque le contrôleur de collectivité initial est créé. S'il est nécessaire de modifier la configuration du serveur secondaire par défaut, les propriétés suivantes peuvent être modifiées dans le fichier server.xml :

    Paramètres facultatifs : ces valeurs sont les valeurs par défaut, mais vous pouvez les modifier.
    replicaHost
    Nom d'hôte de chaque serveur secondaire individuel
    replicaPort
    Port de chaque serveur secondaire individuel

    Ce port n'est pas le port http ou https du contrôleur de collectivité, mais un port unique utilisé pour la communication entre les serveurs secondaires du jeu de serveurs secondaires.

    repositoryDir
    Répertoire utilisé pour stocker les données de référentiel.

Exemple : Création et activation d'un jeu de serveurs secondaires

Cet exemple explique comment créer un jeu de serveurs secondaires et l'activer. Un jeu de serveurs secondaires doit comporter au moins trois serveurs secondaires, de préférence sur des hôtes différent, pour la haute disponibilité. Dans cet exemple, les serveurs secondaires se trouvent sur le même hôte, ce qui implique que vous affectiez des numéros de port uniques pour les serveurs secondaires. Lorsque les serveurs secondaires se trouvent sur différents hôtes, ils peuvent utiliser les mêmes numéros de port.

  1. Créez un jeu de serveurs secondaires.

    Pour créer un jeu de serveurs secondaires, vous augmentez le nombre de contrôleurs de collectivité et vous les configurez pour qu'ils puissent communiquer entre eux. Chaque nouveau contrôleur de collectivité est appelé serveur secondaire car les contrôleurs de collectivité ajoutés ont la même configuration de sécurité que le contrôleur d'origine et car toutes les informations écrites sur un contrôleur sont automatiquement répliquées sur tous les autres contrôleurs actifs. Une fois configurés, tous les contrôleurs de collectivité définis dans le jeu de serveurs secondaires peuvent effectuer les mêmes opérations que le contrôleur d'origine.

    1. Si vous ne disposez pas d'un contrôleur de collectivité, créez-en un. Voir l'étape 1 de la section Configuration d'une collectivité Liberty.
    2. Assurez-vous que le contrôleur de collectivité existant est en cours d'exécution. Pour un contrôleur existant nommé myController, exécutez la commande status :
      wlp/bin/server status myController
      Si le contrôleur de collectivité n'est pas en cours d'exécution, démarrez-le à l'aide de la commande start ou run :
      wlp/bin/server start myController
    3. Créez un serveur qui sera le nouveau contrôleur de collectivité.
      wlp/bin/server create myController2
    4. Répliquez la configuration du contrôleur de collectivité existant sur le nouveau contrôleur de collectivité. Le nouveau contrôleur de collectivité est appelé serveur secondaire.

      Exécutez une commande replicate qui utilise la configuration de domaine de sécurité administrative du contrôleur de collectivité existant et définissez un nouveau mot de passe de fichier de clés pour le serveur secondaire. Consultez le fichier server.xml du contrôleur de collectivité existant pour trouver les valeurs des paramètres --host, --port, --user et --password. Pour le paramètre --keystorePassword, définissez une valeur à utiliser pour le magasin de clés, par exemple myController2. Pour plus d'informations sur ces paramètres obligatoires et sur les paramètres facultatifs, exécutez la commande collective help replicate en ligne de commande.

      wlp/bin/collective replicate myController2 --host=host_of_existing_controller --port=https_port_of_existing_controller --user=userName_for_existing_controller --password=userPassword_for_existing_controller --keystorePassword=keystore_password_for_new_controller

      [18.0.0.1 and later]Pour réduire le nombre d'options nécessaires, utilisez l'option --controller à la place de --user, --password, --host et --port.

      wlp/bin/collective replicate myController2 --controller=userName_for_existing_controller:userPassword_for_existing_controller@host_of_existing_controller:https_port_of_existing_controller --keystorePassword=keystore_password_for_new_controller

      Si vous êtes invité à accepter la chaîne de certificats, entrez y (oui).

      La commande replicate affiche une sortie XML dans un écran de console. Vous copiez la sortie dans le fichier server.xml.

      Pour écrire la sortie de la commande dans un fichier au lieu de l'afficher dans un écran de console, spécifiez le paramètre --createConfigFile=chemin_fichier_sortie. Ensuite, incluez le fichier de sortie dans la configuration de la collectivité en ajoutant une instruction include au fichier server.xml :
      <include location=output_file_path />
    5. Ajoutez la sortie XML de la commande replicate dans le fichier server.xml du serveur secondaire et éditez les valeurs de paramètre comme il convient.
      • Assurez-vous que l'élément httpEndpoint définit les valeurs de serveur secondaire httpPort et httpsPort qui sont des numéros de port uniques sur l'hôte. Supposons, par exemple, que le contrôleur d'origine nommé myController et le serveur secondaire figurent sur le même système hôte local et que myController comporte l'élément httpEndpoint suivant :
        <httpEndpoint id="defaultHttpEndpoint"
                      host="*"
                      httpPort="9080"
                      httpsPort="9443" />
        Remplacez les valeurs de myController2 par :
        <httpEndpoint id="defaultHttpEndpoint"
                      host="*"
                      httpPort="9085"
                      httpsPort="9448" />
      • Définissez les données d'identification pour hostAuthInfo. Vous pouvez définir les données d'identification RPC pour le serveur secondaire 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 secondaire 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 de serveur secondaire 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 de serveur secondaire est enregistré auprès du contrôleur de collectivité, définissez hostAuthInfo useHostCredentials sur true afin que le serveur secondaire hérite des données d'identification RPC de son hôte.
          <hostAuthInfo useHostCredentials="true" />

        Voir Remplacement des informations sur l'hôte de serveur Liberty pour plus d'informations sur les paramètres hostAuthInfo.

      • Assurez-vous que replicaPort définit un numéro de port pour le serveur secondaire qui est unique au sein du jeu de serveurs secondaires et que replicaSet définit les valeurs host:port qui identifient le jeu de serveurs secondaires. Par exemple, si le contrôleur d'origine nommé myController et le serveur secondaire figurent tous deux sur le même système hôte local, remplacez la valeur null de myController2 :
        <collectiveController replicaPort="null"
                              replicaSet="localhost:null"
                              isInitialReplicaSet="false" />
        par 10011 pour le port du serveur secondaire et par 10010 pour le port du jeu de serveurs secondaires :
        <collectiveController replicaPort="10011"
                              replicaSet="localhost:10010"
                              isInitialReplicaSet="false" />
      • Assurez-vous que la configuration définit les mêmes valeurs que celles utilisées par le contrôleur d'origine. Par exemple, les serveurs secondaires myController et myController2 utilisent :
        <quickStartSecurity userName="adminUser" userPassword="adminPassword" />
      • Assurez-vous que l'élément du magasin de clés des signataires racine de collectivité définit le même mot de passe que celui utilisé par le contrôleur d'origine. Par exemple, copiez le mot de passe de fichier de clés collectiveRootKeys du fichier myController server.xml et collez-le dans le fichier myController2 replica server.xml. Cet exemple illustre un mot de passe généré :
        <!-- collective root signers keystore -->
        <keyStore id="collectiveRootKeys" password="{xor}Lz4sLCgwLTs="
                  location="${server.config.dir}/resources/collective/rootKeys.jks"/>
    6. Démarrez le nouveau serveur secondaire en démarrant le nouveau contrôleur de collectivité.
      wlp/bin/server start myController2
    7. Vérifiez que le contrôleur de collectivité d'origine peut communiquer avec le nouveau serveur secondaire.
      1. Ouvrez un éditeur dans le journal des messages du contrôleur d'origine, $WLP_USER_DIR/servers/myController/logs/messages.log.
      2. Recherchez le message suivant, qui peut avoir des adresses IP différentes dans votre environnement :
        CWWKX6009I: Le contrôleur de collectivité a réussi à se connecter au serveur secondaire 127.0.0.1:10011. Le jeu de serveurs secondaires
        actuellement actif est [127.0.0.1:10010]. Le jeu de serveurs secondaires configuré est [127.0.0.1:10010]. Les serveurs secondaires en veille connectés sont [127.0.0.1:10011].
    8. Vérifiez que le nouveau serveur secondaire peut communiquer avec le contrôleur de collectivité d'origine.
      1. Ouvrez un éditeur dans le journal des messages de serveur secondaire, €WLP_USER_DIR/serveurs/myController2/journaux/de journal des messages,.
      2. Recherchez le message suivant, qui peut avoir des adresses IP différentes dans votre environnement :
        CWWKX6009I: Le contrôleur de collectivité a réussi à se connecter au serveur secondaire 127.0.0.1:10010. Le jeu de serveurs secondaires actif en cours est []. Le jeu de serveurs secondaires configuré est []. Les serveurs secondaires de secours connectés sont
        [127.0.0.1:10011, 127.0.0.1:10010].
        En outre, le message suivant s'affichera car le contrôleur n'est pas actif à ce moment. Vous pouvez ignorer le message.
        CWWKX6008E: Le contrôleur de collectivité n'est pas disponible,
        probablement en raison d'une perte de la majorité du jeu de serveurs secondaires, ou d'un incident de communication.  Le jeu de serveurs secondaires
        actuellement actif est [127.0.0.1:10010]. Le
        jeu de serveurs secondaires configuré est [127.0.0.1:10010]. Les serveurs secondaires de secours connectés sont [127.0.0.1:10011]
  2. Activez le nouveau serveur secondaire.

    Exécutez une commande addReplica qui utilise la configuration de domaine de sécurité administrative du contrôleur de collectivité et indique le point final du serveur secondaire que vous voulez activer sous la forme replicaHost:replicaPort. Consultez le fichier server.xml du contrôleur de collectivité pour trouver les valeurs des paramètres --host, --port, --user et --password. Consultez le fichier server.xml du serveur secondaire pour trouver les valeurs de replicaHost:replicaPort. Pour plus d'informations sur ces paramètres, exécutez collective help addReplica en ligne de commande.

    wlp/bin/collective addReplica replicaHost:replicaPort --host=host_of_existing_controller --port=port_of_existing_controller --user=user_for_existing_controller --password=user_password

    [18.0.0.1 and later]Pour réduire le nombre d'options nécessaires, utilisez l'option --controller à la place de --user, --password, --host et --port.

    wlp/bin/collective addReplica replicaHost:replicaPort --controller=user_for_existing_controller:user_password@host_of_existing_controller:port_of_existing_controller

    Pour cet exemple, dans lequel le contrôleur de collectivité existant et le serveur secondaire figurent sur le même hôte, localhost, exécutez la commande suivante :

    wlp/bin/collective addReplica localhost:10011 --host=localhost --port=9443 --user=adminUser --password=adminPassword

    [18.0.0.1 and later]Pour réduire le nombre d'options nécessaires, utilisez l'option --controller à la place de --user, --password, --host et --port.

    wlp/bin/collective addReplica localhost:10011 --controller=adminUser:adminPassword@localhost:9443

    Si vous êtes invité à accepter la chaîne de certificats, entrez y (oui).

  3. Répétez les étapes 1 et 2 pour les autres serveurs secondaires. Par exemple, ajoutez un troisième serveur secondaire au jeu de serveurs secondaires. Nommez le nouveau serveur secondaire myController3 et indiquez replicaPort="10012". Un jeu de serveurs secondaires doit comporter au moins trois serveurs secondaires, pour la haute disponibilité.
    Une fois le serveur secondaire ajouté au jeu de serveurs secondaires, vous pouvez vérifier que le contrôleur de collectivité d'origine et les nouveaux serveurs secondaires sont synchronisés.
    • Consultez les messages suivants dans le journal des messages du contrôleur d'origine. Les messages peuvent avoir des adresses IP différentes dans votre environnement :
      CWWKX6015I: Une demande de modification du serveur secondaire de contrôleur de collectivité a été reçue et est en cours de traitement. Le jeu de serveurs secondaires actif est
      {127.0.0.1:10010,127.0.0.1:10011}. Le nouveau jeu de serveurs secondaires actif demandé est
      {127.0.0.1:10010,127.0.0.1:10011,127.0.0.1:10012}.
      
      CWWKX6016I: La modification du jeu de serveurs secondaires de contrôleur de collectivité actif a été effectuée. Le jeu de serveurs secondaires actif est {127.0.0.1:10010,127.0.0.1:10011,127.0.0.1:10012}. Le jeu de serveurs secondaires actif précédent était {127.0.0.1:10010,127.0.0.1:10011}.
      
      CWWKX6011I: Le contrôleur de collectivité est prêt ; il peut accepter des demandes. Le principal est 127.0.0.1:10010. Le jeu de serveurs secondaires actif en cours est [127.0.0.1:10012, 127.0.0.1:10011, 127.0.0.1:10010]. Le jeu de serveurs secondaires configuré est [127.0.0.1:10010, 127.0.0.1:10011, 127.0.0.1:10012].
      
      CWWKX6014I: Ce serveur secondaire de contrôleur de collectivité a terminé la synchronisation des données avec les autres serveurs secondaires.
    • Consultez les messages suivants dans les journaux des messages des serveurs secondaires ajoutés. Les messages peuvent avoir des adresses IP différentes dans votre environnement :
      CWWKX6016I: La modification du jeu de serveurs secondaires de contrôleur de collectivité actif a été effectuée. Le jeu de serveurs secondaires actif est {127.0.0.1:10010,127.0.0.1:10011,127.0.0.1:10012}. Le jeu de serveurs secondaires actif précédent était {127.0.0.1:10010,127.0.0.1:10011}.
      
      CWWKX6011I: Le contrôleur de collectivité est prêt ; il peut accepter des demandes. Le principal est 127.0.0.1:10010. Le jeu de serveurs secondaires actif en cours est [127.0.0.1:10012, 127.0.0.1:10011, 127.0.0.1:10010]. Le jeu de serveurs secondaires configuré est [127.0.0.1:10010, 127.0.0.1:10011, 127.0.0.1:10012].
      
      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_replicas.html