[17.0.0.1 and later]

Configuration du routage dynamique pour plusieurs collectivités Liberty

Vous pouvez configurer la fonction Dynamic Routing pour router les demandes ciblant une application particulière vers toutes les instances de celle-ci, lorsqu'elle est déployée dans plusieurs collectivités.

Avant de commencer

Effectuez les étapes d'installation du produit décrites dans Configuration de la fonction de routage dynamique pour les collectivités Liberty.

Pourquoi et quand exécuter cette tâche

La fonction Intelligent Management pour les serveurs web permet de router les demandes HTTP vers les membres de collectivités Liberty sans que l'administrateur ait besoin de regénérer le fichier de configuration du plug-in WebSphere lorsque l'environnement change. Lorsque des serveurs, des membres de cluster, des applications ou des hôtes virtuels sont ajoutés, retirés, démarrés, arrêtés ou modifiés, les nouvelles informations sont livrées de façon dynamique au plug-in WebSphere. Les demandes sont routées sur la base d'informations à jour.

Intelligent Management pour les serveurs web route les demandes ciblant une application particulière vers toutes les instances de celle-ci, lorsqu'elle est déployée dans plusieurs collectivités. Auparavant, lorsque les demandes étaient acheminées vers plusieurs collectivités, une application spécifique ne pouvait pas être installée dans plusieurs collectivités.

Si vous voulez utiliser Intelligent Management pour les serveurs web dans le but de router les demandes HTTP vers plusieurs collectivités Liberty, activez la fonction dynamicRouting-1.0 dans tous les contrôleurs des collectivités concernées. dynamicRouting-1.0 fournit un service de routage dynamique, Dynamic Routing, qui communique des informations de routage à Intelligent Management pour les serveurs web. Utilisez ses actions setup, genPluginCfg et genKeystore pour générer les magasins de clés nécessaires à la communication sécurisée entre le plug-in et le service Dynamic Routing, ainsi qu'un fichier de configuration activant Intelligent Management pour les serveurs web dans le plug-in WebSphere plug-in.

Important : Le routage vers la même application dans plusieurs collectivités suppose que chacune de ces dernières ait un nom différent. Le nom unique d'une collectivité peut apparaître sous deux formes :
  • Dans l'attribut connectorClusterName de l'élément XML <dynamicRouting> du fichier server.xml de chaque contrôleur de collectivité. Tous les contrôleurs d'une même collectivité doivent être configurés avec la même valeur d'attribut connectorClusterName. Les contrôleurs de collectivités différentes doivent être configurés avec des valeurs d'attribut connectorClusterName différentes. Dès lors que l'attribut connectorClusterName est spécifié, sa valeur annule et remplace le nom de collectivité qui a été indiqué avec l'option -–collectiveName lorsque la collectivité concernée a été créée.
  • Après l'option --collectiveName, lorsque la collectivité est créée par la commande collective create.

Dans chaque collectivité, les contrôleurs prenant part au routage dynamique informent le plug-in WebSphere de l'état de la collectivité afin qu'il puisse router dynamiquement les demandes ciblant une même application vers les différentes collectivités où cette application est installée. Ils informent aussi le plug-in WebSphere de la disponibilité de chaque application dans leur collectivité. De cette manière, le plug-in WebSphere sait toujours si une application est disponible dans plusieurs collectivités. Sauf indication contraire d'une règle de routage, toutes les demandes ciblant une application particulière sont équitablement réparties sur l'ensemble des serveurs où cette application est installée.

Les règles de routage permettent au plug-in WebSphere de router les demandes qu'il reçoit vers un ensemble spécifique de serveurs. Elles offrent aussi une capacité de rejet ou de redirection sélective des demandes. Cette sélection est réalisée par la confrontation des attributs de la demande entrante aux règles de routage.

Procédure

  1. Activez Dynamic Routing sur un contrôleur en ajoutant le code suivant à la balise featureManager dans le fichier server.xml du contrôleur.
    <feature>dynamicRouting-1.0</feature>
  2. Facultatif : Ajoutez l'élément <dynamicRouting> au fichier server.xml du contrôleur pour spécifier les propriétés de routage dynamique.

    La propriété connectorClusterName spécifie le nom que le routage dynamique associe à la collectivité. Si la propriété connectorClusterName n'est pas spécifiée, le nom de la collectivité est utilisé.

    Par exemple, dans la première collectivité, spécifiez le nom suivant sur tous les contrôleurs :
    <dynamicRouting connectorClusterName="collective1"/>
    Par exemple, dans la deuxième collectivité, spécifiez le nom suivant sur tous les contrôleurs :
    <dynamicRouting connectorClusterName="collective2"/>
    Si une connexion échoue, une autre connexion à un contrôleur est tentée après un temps d'attente indiqué par la propriété retryInterval. La propriété maxRetries indique combien de fois la reconnexion à un contrôleur de collectivité peut être tentée. Examinez l'exemple suivant :
    <dynamicRouting maxRetries="4" retryInterval="20" 
    connectorClusterName="collective1"/>
     <TraceSpecification name="default" specification=":DEBUG"/>
    </dynamicRouting>
    Le fichier plugin-cfg.xml généré contient les propriétés suivantes dans sa section ConnectorCluster> : Examinez l'exemple suivant :
    <IntelligentMangement>
     …
      <ConnectorCluster enabled="true" maxRetries="4" name="collective1" retryInterval="20">
      <Property name="uri" value="/ibm/api/dynamicRouting"/>
      <Connector host="controller1.acme.com" port="9444" protocol="https">
      <Property name="keyring" value="/opt/HTTPServer_Plugins/config/webServer1/plugin-key.kdb"/>
      </Connector>
     </ConnectorCluster>
     …
    </IntelligentManagement>
  3. Démarrez tous les contrôleurs qui sont activés avec la fonction Dynamic Routing.
  4. Exécutez la commande dynamicRouting setup sur l'un des contrôleurs afin de générer le magasin de clés et les fichiers de configuration de plug-in.
    Pour créer les artefacts nécessaires au routage dynamique couvrant plusieurs collectivités, utilisez l'option --collectives plutôt que les options --port, --host, --user et --password. Spécifiez les collectivités au format utilisateur_collectivité:motdepasse_collectivité@hôte_collectivité:port en les séparant les unes des autres par une virgule (,). Examinez l'exemple suivant :
    ./dynamicRouting setup --collectives user1:password1@host1:port1,user2:password2@host2:port2,...
    --keystorePassword=webAS --pluginInstallRoot=/opt/HTTPServer_Plugins/ --webServerNames=webserver1

    Assurez-vous que chaque collectivité porte un nom différent. Veillez aussi à ce que chaque utilisateur spécifié existe réellement dans l'annuaire d'utilisateurs de sa collectivité et qu'il ait un rôle administratif. Si vous ne spécifiez pas de mot de passe, il vous en sera demandé un.

    Consultez les conditions à remplir pour l'option --collectives.

    Pour plus d'informations sur la commande dynamicRouting setup, consultez Commande de routage dynamique.

  5. Copiez tous les fichiers plugin-key*.jks générés ainsi que le fichier plugin-cfg.xml dans un répertoire temporaire sur l'hôte du serveur web.

    Pour l'option --collectives, plusieurs fichiers magasin de clés sont créés :

    • Le fichier plugin-key.jks permet aux serveurs membres de toutes les collectivités d'accepter les demandes "proxifiées" par l'intermédiaire du serveur web.
    • Le fichier plugin-key-nom_collectivité.jks fournit un fichier de clés pour chaque collectivité spécifiée avec l'option --collectives.

    Ces fichiers permettent au plug-in WebSphere de communiquer en sécurité avec les contrôleurs de la collectivité concernée.

  6. Sur l'hôte du serveur Web, exécutez la commande gskcmd (incluse dans le package IHS) pour convertir le format cms de clés et certificat personnel par défaut. Le format CMS est le format pris en charge du plug-in WebSphere. Examinez l'exemple suivant :
    gskcmd -keydb -convert -pw <password> -db /tmp/plugin-key.jks -old_format jks -target /tmp/plugin-key.kdb -new_format cms -stash
    gskcmd -cert -setdefault -pw <password> -db /tmp/plugin-key.kdb -label default

    Exécutez la commande gskcmd sur tous les fichiers plugin-key*.jks générés. Adaptez les options –db et –target pour spécifier chaque fichier.

    Pour z/OS, reportez-vous à la rubrique Conversion du magasin de clés au format CMS sur z/OS.

  7. Copiez tous les fichiers plugin-key.kdb, plugin-key.rdb et plugin-key.sth qui sont créés par gskcmd du répertoire temporaire vers le répertoire --pluginInstallRootargument_value/config/web_server_name/.
  8. Copiez le fichier plugin-cfg.xml dans le répertoire spécifié dans la directive WebSpherePluginConfig dans le fichier httpd.conf du serveur web.

    Le fichier plugin-cfg.xml est généré avec la section <IntelligentManagement>. Lorsque la fonction Dynamic Routing est activée dans une collectivité, le fichier contient une section <Connector> pour chaque contrôleur de collectivité. Dans le cas d'un routage multi-collectivité, à chaque collectivité correspond une section <ConnectorCluster>. Examinez l'exemple suivant :

    <Property Name="Keyfile" Value="/opt/IBM/WebSphere/Plugins/config/webserver1/plugin-key.kdb"/>
    <Property Name="Stashfile" Value="/opt/IBM/WebSphere/Plugins/config/webserver1/plugin-key.sth"/>
    <IntelligentMangement>
     <Property name="webserverName" value="webserver1"/>
     <Property name="RoutingRulesConnectorClusterName" value="collective1"/>
     <ConnectorCluster enabled="true" maxRetries="-1" name="collective1" retryInterval="60">
      <Property name="uri" value="/ibm/api/dynamicRouting"/>
      <Connector host="controller1.acme.com" port="9444" protocol="https">
       <Property name="keyring" value="/opt/HTTPServer_Plugins/config/webserver1/plugin-key-collective1.kdb"/>
      </Connector>
     </ConnectorCluster>
    <ConnectorCluster enabled="true" maxRetries="-1" name="collective2" retryInterval="60">
      <Property name="uri" value="/ibm/api/dynamicRouting"/>
      <Connector host="controller2.acme.com" port="9444" protocol="https">
       <Property name="keyring" value="/opt/HTTPServer_Plugins/config/webserver1/plugin-key-collective2.kdb"/>
      </Connector>
     </ConnectorCluster>
    </IntelligentManagement>
  9. Démarrez le serveur Web et commencez le routage vers l'application installée dans la collectivité.
  10. [17.0.0.1 and later]Optionnel : créez des règles de routage pour spécifier comment certaines demandes doivent être traitées.

    Les règles de routage peuvent spécifier les actions suivantes :

    • Rejeter des demandes spécifiques.
    • Rediriger des demandes spécifiques.
    • Autoriser certaines demandes à être routées vers un sous-ensemble des serveurs disponibles.
    • Basculer des demandes spécifiques d'un ensemble de serveur à un autre en cas de défaillance du premier.

    Reportez-vous aux rubriques Règles de routage pour le routage dynamique Liberty et Configuration des règles de routage pour le routage dynamique Liberty.

Résultats

Avec la fonction dynamicRouting-1.0 activée, Intelligent Management peut désormais router dynamiquement les demandes HTTP vers les collectivités Liberty.


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

Nom du fichier : twlp_wve_enabledynrout_multiple.html