Configuration de clusters avec application des accès pour l'élasticité Liberty

Vous pouvez configurer une collectivité pour la prise en charge de l'élasticité Liberty. Avec l'élasticité Liberty, le contrôleur de mise à l'échelle peut installer les logiciels Liberty sur un hôte enregistré et créer un nouveau serveur. De plus, comme la prise en charge de l'élasticité Liberty inclut la prise en charge de l'élasticité JVM, le contrôleur de mise à l'échelle peut démarrer ou arrêter les serveurs Liberty en fonction de l'utilisation des ressources et de règles de mise à l'échelle en option. Le numéro de serveurs disponibles augmente lorsque la demande d'applications est élevée et il diminue lorsque la demande d'applications est faible.

Avant de commencer

Déterminez les hôtes cible sur lesquels vous souhaitez installer Liberty, ainsi que le logiciel Liberty à installer. Au minimum, vous voudrez le contrôleur de mise à l'échelle pour installer les fichiers installable et de package suivants sur un hôte cible :

  • Un package fournissant un serveur Liberty autonome avec une application. L'étape 5c explique comment créer le package serveur.
  • Un installable fournissant un serveur Liberty qui contient le répertoire wlp mais pas le répertoire usr. L'étape 5a explique comment créer un installable d'archive d'environnement d'exécution Liberty.

Chaque hôte cible doit avoir installé RXA ou SSH et un environnement JRE (Java Runtime Environment) répondant à la configuration minimale requise du serveur Liberty. Reportez-vous aux rubriques Configuration de RXA pour les opérations de collectivité Liberty et Définition de la variable JAVA_HOME pour les membres de collectivité et les contrôleurs Liberty.

Si un hôte cible ne possède pas d'environnement JRE installé avec sa variable JAVA_HOME et la variable système PATH fournissant un accès à l'environnement JRE, le contrôleur de mise à l'échelle peut installer l'environnement JRE sur l'hôte cible. L'étape 5b explique comment créer une archive JRE, un installable.

Multimédia Regarder : La vidéo Configuring an auto-scalable cluster for Liberty elasticity montre comment configurer un cluster avec application des accès. [Retranscription]

Procédure

  1. Configurez une collectivité pour la prise en charge de l'élasticité JVM. Vérifiez que la collectivité possède au moins un membre de cluster dynamique.

    Pour plus de détails sur la configuration des contrôleurs de mise à l'échelle avec des membres de cluster dynamique, voir Configuration de clusters à mise à l'échelle automatique pour l'élasticité JVM.

  2. Vérifiez que chaque membre de cluster dynamique existant appartient à un cluster nommé en respectant la convention d'attribution de nom NomGroupePile.NomPackage.

    Les membres de cluster dynamiques et serveurs existants auquel le contrôleur de mise à l'échelle va donner accès seront des membres beexist de ce cluster. NomGroupePile est le nom d'un répertoire partagé contenant les installables et packages auxquels un contrôleur de mise à l'échelle va donner les accès sur des hôtes cible en fonction de règles de mise à l'échelle. NomPackage est le nom du package serveur auquel le contrôleur de mise à l'échelle va donner les accès sur les hôtes cible.

    Pour un cluster nommé myStackGroup.cluster1, placez l'instruction suivante dans le fichier server.xml de chaque membre de cluster dynamique existant :

    <clusterMember name="myStackGroup.cluster1"/>

    Vous utiliserez le nom de cluster pour les étapes 5c et 7 de cette rubrique. A l'étape 5c, utilisez cluster1.zip pour le nom de package serveur. A l'étape 7, créez le répertoire myStackGroup pour le déploiement des installables et packages.

  3. Facultatif : Ajoutez des règles de mise à l'échelle sur le contrôleur de mise à l'échelle. Voir Définition de règles de mise à l'échelle.
  4. Enregistrez chaque hôte cible auprès d'un contrôleur de mise à l'échelle.

    L'enregistrement d'un hôte permet au contrôleur de mise à l'échelle de transférer les fichiers sur cet hôte, mais aussi d'accéder aux fichiers, aux commandes et à d'autres ressources sur l'hôte. Utilisez la commande registerHost pour enregistrer un hôte cible. Consultez le fichier server.xml du contrôleur de mise à l'échelle pour trouver les valeurs des paramètres --host, --port, --user et --password. Pour ne pas utiliser un fichier de clé privée, comme pour les hôtes cible sous Linux ou Windows, incluez un nom d'utilisateur et un mot de passe de système d'exploitation Windows en définissant les paramètres --rpcUser et --rpcUserPassword. L'utilisateur spécifié par --rpcUser doit disposer de droits de système d'exploitation sur l'emplacement de déploiement cible.

    wlp/bin/collective registerHost targetHost --host=controllerHost --port=controllerHTTPSPort --user=controllerAdmin --password=controllerAdminPassword --rpcUser=osUser --rpcUserPassword=osUserPassword

    Pour transférer des fichiers sur des hôtes cible, vous n'avez pas besoin d'inclure un paramètre --hostWritePath dans la commande; le code d'application des accès de pile définit les chemins d'écriture pour vous. Si un hôte est déjà enregistré, vous pouvez utiliser la commande updateHost pour réinitialiser les informations d'enregistrement. Pour plus d'informations, voir Enregistrement des ordinateurs hôte auprès d'une collectivité Liberty.

    Si l'hôte cible se trouve sur le même ordinateur que l'hôte contrôleur, vous devez également exécuter la commande updateHost pour l'hôte contrôleur.

  5. Créez et configurez des packages installables et des packages qu'un contrôleur de mise à l'échelle peut déployer sur un hôte enregistré.

    Un installable est un fichier binaire que l'application que vous souhaitez installer sur un hôte enregistré doit exécuter, par exemple un environnement d'exécution Java (JRE) ou Liberty. Un package correspond à cette application conditionnée sous forme de fichier compressé.

    1. Créez une archive d'exécution Liberty contenant le répertoire wlp, mais ne contenant pas le répertoire usr. La convention de dénomination pour ce package installable est type.name.zip ; par exemple, wlp.855.zip. Pour créer une archive d'exécution Liberty, vous disposez des options suivantes :
      • Exécutez la commande de serveur Liberty package avec l'option --include=wlp. Exemple :
        wlp/bin/server package --include=wlp

        Pour indiquer un nom de fichier et un emplacement cible, ajoutez l'option --archive=archive_path_name ; par exemple :

        wlp/bin/server package --include=wlp --archive=c:\temp\wlp.855.zip

        Si vous n'indiquez pas un nom de fichier ou un emplacement cible valide avec l'option --archive, la commande crée l'archive d'exécution wlp.zip dans l'emplacement $WLP_OUTPUT_DIR, qui est le répertoire ${wlp.install.dir}/usr/servers par défaut. L'emplacement cible doit exister préalablement à l'exécution de la commande. Par conséquent, si l'emplacement cible est c:\temp, le répertoire C:\temp doit exister et disposer de droits d'écriture pour que la commande puisse écrire l'archive dans le répertoire C:\temp.

      • Exécutez la commande package avec l'option --include=all, puis supprimez le répertoire usr. Voici un exemple de commande package :
        wlp/bin/server package myServer --include=all --archive=myArchive.zip
      • Créez un fichier compressé (.zip) contenant le répertoire wlp, sans le répertoire usr.

      Après que vous avez créé l'archive d'exécution Liberty, assurez-vous que le nom de cette archive respecte la convention de dénomination suivante : wlp.nom.zip.

    2. Créez ou obtenez des archives pour le kit Java Development Kit (JDK) et tout autre package installable requis. Le convention de dénomination pour un package installable est type.nom.zip ; par exemple, jre.17.zip. Les valeurs de type valides pour les packages sont les suivantes :
      • wlp pour une exécution Liberty.
      • jre pour un environnement d'exécution Java.
      • other pour un type de fichier différent. Il s'agit de la valeur par défaut.

      Ainsi, pour créer une archive pour un environnement d'exécution Java, créez un fichier compressé (.zip) avec le contenu du répertoire java de votre installation IBM JRE. N'incluez pas le répertoire java, mais seulement l'ensemble des fichiers et dossiers contenus dans le répertoire java. Respectez la convention de dénomination jre.nom.zip lorsque vous donnez un nom à l'archive.

    3. Pour déployer des applications et un serveur Liberty, créez un fichier ZIP de package serveur contenant les applications et le serveur Liberty. La convention de dénomination d'un package serveur est nom_package.zip ; par exemple, cluster1.zip. Il existe plusieurs façons de créer un package serveur :
      • Exécutez la commande package :
        wlp/bin/server package cluster1 --include=usr
        La commande crée un package serveur nommé, par exemple, C:\wlp\usr\servers\cluster1\cluster1.zip.
      • Exécutez la commande package avec l'option --include=all, puis supprimez le répertoire wlp. Voici un exemple de commande package :
        wlp/bin/server package cluster1 --include=all --archive=cluster1.zip
      • Créez un fichier compressé (.zip) contenant le répertoire usr, sans le répertoire wlp.

      Ainsi, pour créer un package serveur nommé cluster1.zip composé d'un serveur Liberty autonome avec une application, procédez comme suit :

      1. Créez un serveur :
        wlp/bin/server create cluster1
      2. Copiez une application dans le répertoire dropins du serveur cluster1.
      3. Conditionnez le serveur :
        wlp/bin/server package cluster1 --include=usr
      Le fichier wlp/usr/servers/cluster1/cluster1.zip est créé.
      Important : Vérifiez si un fichier server.env du package possède des paramètres d'environnement qui sont valides sur les hôtes cible. Si JAVA_HOME est défini, il doit être défini sur un emplacement qui existe sur les hôtes cibles afin d'éviter les échecs de déploiements.
  6. Définissez un nom d'utilisateur et un mot de passe pour le contrôleur de collectivité ou le gestionnaire de pile dans le fichier server.xml du contrôleur de mise à l'échelle.
    <collectiveController user="adminUser" password="adminPassword" />
    ou
    <stackManager controllerUser="adminUser" controllerUserPassword="adminPassword" />
  7. Placez les packages installables et les packages dans l'emplacement WLP_STACK_GROUPS_DIR, qui est par défaut $WLP_USER_DIR/shared/stackGroups.

    Les contrôleurs de mise à l'échelle contrôlent les emplacements par défaut des packages installable et des packages sur le système de fichiers et réagissent de façon dynamique aux mises à jour. Si vous placez les packages installables et les packages dans les emplacements par défaut, vous ne devez modifier aucun des attributs par défaut.

    Vous pouvez utiliser le groupe de pile par défaut, defaultStackGroup. Vous pouvez aussi créer votre propre sous-répertoire de stackGroups, par exemple myStackGroup, et l'ajouter aux sous-répertoires installables et packages.

    wlp/usr
          /servers
          /shared
             ...
             /stackGroups
                /defaultStackGroup
                   /installables
                   /packages
                /myStackGroup
                   /installables
                   /packages

    Les contrôleurs de mise à l'échelle déploient les packages installables et les packages sur l'hôte enregistré et créent un nouveau serveur.

    Conseil : Un nouveau serveur est créé uniquement si la règle de mise à l'échelle est activée et requiert un nouveau serveur. Pour forcer un contrôleur de mise à l'échelle à créer un serveur, ajustez la valeur min et éventuellement la valeur max de la règle de mise à l'échelle pour le contrôleur de mise à l'échelle. Par exemple, si votre contrôleur de mise à l'échelle ne comporte pas de règle de mise à l'échelle et que votre collectivité comporte trois membres de mise à l'échelle, ajoutez au fichier server.xml du contrôleur de mise à l'échelle un règle forçant le contrôleur de mise à l'échelle à avoir au moins quatre membres en cours d'exécution :
    <scalingDefinitions>
       <defaultScalingPolicy enabled="true" min="4" max="6"/>
    </scalingDefinitions>

    La convention de dénomination de cluster pour l'élasticité Liberty est StackGroupName.PackageName. Lorsqu'une pile est déployée, <clusterMember name="StackGroupname.PackageName" est automatiquement défini dans le fichier server.xml du serveur déployé. L'élément <scalingPolicy> correspondant inclut une instruction <bind clusters="StackGroupName.Packagename"/>.

    Tableau 1. Emplacements par défaut des packages installables et des packages. Les variables d'environnement Liberty définissent les répertoires d'installation par défaut. Pour plus de détails sur la substitution des emplacements par défaut, voir Personnalisation de l'environnement Liberty.
    Fichier Répertoire d'installation par défaut
    Type de package installable wlp /wlp
    Type de package installable jre /wlp/jre
    Type de package installable other /wlp/other
    Package /wlp/usr
  8. Examinez les attributs de configuration pour groupes de piles et les packages installables, puis modifiez les configurations de vos groupes de piles et packages installables comme il convient afin de définir le moment et l'emplacement d'exécution d'application des accès Liberty. Vous devrez peut-être remplacer les configurations par défaut.

    Pour remplacer les configurations par défaut, définissez de nouvelles valeurs dans les éléments stackGroup et installable dans le fichier server.xml du contrôleur de mise à l'échelle. Voir Contrôleur de mise à l'échelle pour plus d'informations sur les éléments stackGroup et installable.

    Conseils pour substituer les valeurs par défaut de certains éléments :

    • L'élément installable définit un package installable pour un groupe de pile. L'élément installable peut être un élément enfant de l'élément stackGroup ou un élément apparenté référencé par un élément enfant installableRef de l'élément stackGroup.
      Les exemples suivants montrent comment changer les paramètres dans le fichier server.xml du contrôleur de mise à l'échelle pour remplacer la valeur par défaut de l'attribut installable d'un groupe de pile.
      <stackGroup name="myStackGroup">
         <installable name="wlp.v8555.zip" sourceDir="c:\myStackGroup\installables"/>
      </stackGroup>
      ou
      <stackGroup name="myStackGroup" installDir="/myInstallDir" installableRef="myInstallable1, myInstallable2"/>
      <installable name="wlp.v8555.zip" id="myInstallable1" sourceDir="c:\myStackGroup\installablesOne" />
      <installable name="jre.v1.6.zip" id="myInstallable2" sourceDir="c:\myStackGroup\installablesTwo"/>
    • L'élément enfant deployVariable spécifie une variable de substitution qui est injectée dans la pile déployée. Vous pouvez indiquer que la variable de substitution s'incrémente automatiquement à chaque déploiement de la pile. Par exemple, utilisez un attribut deployVariable afin d'indiquer une valeur de numéro de port initiale et incrémenter cette valeur à chaque déploiement. L'objectif de l'attribut deployVariable dans cette situation est d'éviter des conflits de port sur l'hôte cible. L'élément deployVariable utilise l'arithmétique dans le fichier server.xml du serveur déployé pour dériver le numéro de port d'exécution.

      Par exemple, pour définir une valeur de port de début et une quantité pour l'incrément.

      1. Définissez httpPort="${http.port}" dans l'élément httpEndpoint du fichier server.xml du serveur conditionné :
        <httpEndpoint ... httpPort="${http.port}" />
      2. ajoutez une définition deployVariable qui définit les valeurs de port de début et d'incrément dans le fichier server.xml du contrôleur de mise à l'échelle.
        <stackGroup name="DefaultStackGroup" installDir="">
          <deployVariable name="http.port" value="9080" increment="1"/>
        </stackGroup>

      Ensuite, à chaque déploiement de la pile sur l'hôte, la valeur httpPort s'incrémente de 1. Par conséquent, la première fois que la pile est déployée sur host1, l'élément de noeud final HTTP est :

      <httpEndpoint ... httpPort="9080" />

      et la deuxième fois que la pile est déployée sur host1, l'élément est :

      <httpEndpoint ... httpPort="9081" />

      Comme pour l'attribut deployVariable, la valeur par défaut de value est null. La valeur par défaut de increment est 0 (zero).

      Si l'attribut deployVariable est spécifié dans le fichier server.xml du contrôleur de mise à l'échelle, le numéro de port d'exécution d'un serveur déployé est la chaîne value du port initial augmentée de l'entier increment.

    • Si le contrôleur de mise à l'échelle server.xml définit le groupe de pile comme suit, ne définissez pas à nouveau httpPort dans le fichier bootstrap.properties pour le répertoire serveur avec lequel vous créez un package serveur. Si vous le faite, la valeur httpPort définie dans bootstrap.properties est utilisée, et non celle générée par l'élément de configuration deployVariable.
      <stackGroup name="DefaultStackGroup" installDir="">
        <deployVariable name="http.port" value="9080" increment="1"/>
      </stackGroup>
  9. Facultatif : Modifiez l'intervalle auquel le contrôleur de mise à l'échelle recherche des ajouts et des suppressions de groupe de pile sur le système de fichiers.

    Le contrôleur de mise à l'échelle analyse le contenu du répertoire stackGroups et ses sous-répertoires à la recherche de modifications. En cas de modifications de contenu, il est possible que le contrôleur mette à disposition des clusters qui précédemment ne comportaient pas de packages disponibles. La mise à jour de packages n'entraîne pas de type de comportement.

    Par défaut, le contrôleur examine l'emplacement WLP_STACK_GROUPS_DIR location toutes les 5000 millisecondes (cinq secondes). Pour modifier l'intervalle d'examen ou désactiver cet examen, définissez de nouvelles valeurs pour les attributs scanningInterval et scanningEnable dans le fichier server.xml du contrôleur de mise à l'échelle. Par exemple, pour définir l'intervalle d'examen sur six secondes et activer l'examen, ajoutez une instruction semblable à la suivante dans le fichier server.xml du contrôleur de mise à l'échelle :

    <stackManager groupsDir="${wlp.install.dir}/usr/shared/stackGroups/"
                  controllerUser="adminUser" controllerUserPassword="adminPassword"
                  scanningInterval="6000" scanningEnable="true">
    </stackManager>

    Pour désactiver l'examen, définissez scanningEnable sur false.

  10. Facultatif : Demandez au contrôleur de mise à l'échelle de rechercher les ajouts, mises à jour et suppressions de groupe de pile sur le système de fichiers.

    Exécutez une opération de bean géré StackManager afin de forcer le contrôleur de mise à l'échelle à rechercher des ajouts, mises à jour et suppressions à l'emplacement WLP_STACK_GROUPS_DIR. Même si le contrôleur de mise à l'échelle server.xml comporte la valeur scanningEnable="false", vous pouvez exécuter une opération de bean géré StackManager MBean afin de forcer la recherche des ajouts, mises à jour et suppressions.

    Pour plus de détails sur le bean géré StackManager, voir List of provided MBeans.

  11. Facultatif : Démarrez IHS pour activer le routage vers des serveurs.

    Pour qu'IBM HTTP Server (IHS) effectue une reconnaissance et un routage vers des applications Web sur des clusters mis à disposition de façon dynamique, activez le routage dynamique sur l'hôte sur lequel doit résider le contrôleur de mise à l'échelle. IHS extraie les informations de routage pour les serveurs mis à disposition depuis le service de routage dynamique. Si le statut du serveur est activé, vous pouvez afficher les informations de routage.

    Si vous n'avez pas installé IHS, voir Configuration de la fonction de routage dynamique pour les collectivités Liberty. En outre, la vidéo suivante montre comment installer le support du routage dynamique à l'aide d'IBM Installation Manager:

    Multimédia Regarder : La vidéo Enabling IHS for Liberty Dynamic Routing montre comment installer IHS, comment installer Web Server Plug-in for WebSphere Application Server et comment appliquer le correctif temporaire pour le routage dynamique. [Retranscription]


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

Nom du fichier : twlp_autoscale_configlibertyelast.html