Configuration de clusters à mise à l'échelle automatique pour l'élasticité JVM

Vous pouvez configurer une collectivité pour la prise en charge de l'élasticité JVM. Avec 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. Seuls les serveurs figurant déjà dans la collectivité sont admissibles pour une mise à l'échelle. Il n'existe pas d'application des accès pour les nouveaux serveurs.

Avant de commencer

Les types d'informations d'utilisation des ressources collectées diffèrent entre les différentes versions de JDK. IBM JDK 1.7 pour Windows et Linux fournit toutes les informations d'utilisation nécessaires pour une mise à l'échelle automatique et il s'agit de la version JDK préférée. Les autres versions de JDK ne fournissent peut-être pas toutes les informations d'utilisation nécessaires pour une mise à l'échelle automatique basée sur une utilisation des ressources JVM individuelles.
Eviter les incidents : La console d'administration permet de démarrer et d'arrêter un serveur Liberty membre d'un cluster auto-évolutif, mais uniquement lorsque le serveur se trouve en mode maintenance. Le démarrage ou l'arrêt d'un serveur Liberty à partir de la ligne de commande lorsque le serveur Liberty est membre d'un cluster auto-évolutif peut entraîner des résultats imprévisibles.

Procédure

  1. Créez une collectivité.

    Pour plus de détails sur la création d'un contrôleur de collectivité et d'un serveur membre, voir Configuration d'une collectivité Liberty.

    Remarque : Il est recommandé de terminer la première étape avant de continuer avec la procédure. La première étape indique à l'utilisateur de créer la collectivité, d'ajouter des membres et de démarrer les contrôleurs et les membres.
  2. Ajoutez la fonction scalingController-1.0 dans le fichier server.xml d'un ou de plusieurs contrôleurs de collectivité. Lorsque vous sauvegardez le fichier server.xml, les règles par défaut sont imposées, sauf indication contraire.
    <featureManager>
     <feature>jsp-2.2</feature>
     <feature>collectiveController-1.0</feature>
     <feature>scalingController-1.0</feature>
    </featureManager>

    Après avoir ajouté la fonction, les messages suivants s'affichent dans n'importe quel ordre dans le fichier messages.log du contrôleur de collectivité, à condition que se dernier soit exécuté :

    CWWKV0300I: Le service StackManager est démarré.
    CWWKV0302I: Les piles existantes sont les suivantes : []
    CWWKV0100I: La fonction ScalingController a été activée.
    CWWKX1002I: Service singleton ScalingControllerSingletonService pour la portée 
    CWWKV0102I: This server is elected to be the primary scaling
    controller.
    CWWKF0012I: Le serveur a installé les fonctions suivantes : [scalingController-1.0].
    Remarque : La configuration Liberty étant dynamique, lorsque vous ajoutez le contrôleur de mise à l'échelle, la règle de mise à l'échelle par défaut du contrôleur entre en vigueur et vous pourriez obtenir des résultats inattendus. Par exemple, la règle par défaut indique min=2 servers, de sorte que lorsque vous sauvegardez le fichier server.xml du contrôleur de mise à l'échelle, ce dernier essaie de démarrer deux serveurs. Si vous ne souhaitez pas ce comportement, vous pouvez définir une règle pour le contrôleur en même temps.
    Remarque : L'enregistrement du membre et l'affichage du message CWWKV0121I peuvent demander un certain temps au contrôleur de mise à l'échelle.
  3. Facultatif : Modifiez la valeur par défaut des règles de mise à l'échelle afin de les adapter aux besoins de votre environnement. Pour plus d'informations, voir Définition de règles de mise à l'échelle.
  4. Ajoutez la fonction scalingMember-1.0 à tous les membres de collectivités que vous souhaitez faire contrôler par le contrôleur de mise à l'échelle. Définissez un élément hostSingleton avec un port dans les fichiers server.xml du membre. Chaque membre de mise à l'échelle doit définir un élément hostSingleton avec un port dans le fichier server.xml. Tous les membres de mise à l'échelle sur le même hôte doivent utiliser le même port. Vous pouvez indiquer n'importe quel numéro de port, mais ce numéro de port doit être unique sur l'ordinateur hôte. L'exemple suivant utilise le numéro de port 20020 :
    <featureManager>
     <feature>jsp-2.2</feature>
     <feature>scalingMember-1.0</feature>
    </featureManager>
    
    <hostSingleton name="ScalingMemberSingletonService" port="20020" />

    Si le serveur n'est pas démarré lorsque vous ajoutez les fonctions et l'élément hostSingleton, vous devez le démarrer manuellement une fois pour que le serveur de mise à l'échelle reconnaisse les fonctions ajoutées. Les messages suivants s'affichent dans n'importe quel autre dans le fichier messages.log du membre de collectivité :

    CWWKX1000I: Le bean géré SingletonMessenger est disponible.
    CWWKX7400I: Le bean géré ClusterMember est disponible.
    CWWKX1002I: Le service Singleton ScalingMemberSingletonService pour l'hôte de portée est créé.
    CWWKV0200I: The ScalingMember feature is activated.
    CWWKX1004I: La connexion Messenger est connectée à hôte=nom_hôte_contrôleur, port=numéro_port_contrôleur.

    Un seul membre de mise à l'échelle par hôte communique avec le contrôleur de mise à l'échelle. Le premier membre de mise à l'échelle à se connecter au service ScalingMemberSingletonService est désigné comme hôte leader. Si l'hôte principal s'arrête, un autre membre de mise à l'échelle prend le relais en tant qu'hôte principal via un processus d'élection arbitré par scalingMemberSingletonService. Tous les membres de mise à l'échelle sur le même hôte et cluster doivent utiliser le même port ScalingMemberSingletonService.

    Remarque : Lorsqu'un membre de mise à l'échelle est designé comme hôte principal, vous voyez le message suivant dans le fichier messages.log du membre de collectivité :
    CWWKV0203I: Server host=host_name;
    userdir=path_to_usr_directory;
    server=member_name;
    port=member_port_number;
    service=ScalingMemberSingletonService; scope=host a été désigné comme hôte leader.
    Remarque : Si vous n'ajoutez pas l'élément hostSingleton dans le fichier server.xml du membre de mise à l'échelle ou si vous vous utilisez des ports différents sur chaque membre de mise à l'échelle sur le même hôte, plusieurs hôtes leaders pourraient être désignés. Cela peut entraîner des décisions incorrectes concernant la mise à l'échelle. Vous voyez alors le message suivant dans le fichier messages.log du contrôleur :
    CWWKV0123E: Des doublons d'hôte leader ont été détectés sur l'hôte host_name.  Cette situation peut dégrader les décisions du contrôleur de mise à
    l'échelle.  L'identité du leader du serveur server_name1 est
    leader_id1.  L'identité du leader du serveur server_name2 est
    leader_id2.

    Pour plus d'informations sur l'élément hostSingleton, consultez Membre de collectivité.

    Multimédia Regarder : La vidéo Configuration d'un cluster Liberty à mise à l'échelle automatique pour l'élasticité JVM illustre cette procédure. [Retranscription]


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

Nom du fichier : twlp_wve_configjvmelast.html