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.
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.
- 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>
- 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>
- Démarrez tous les contrôleurs qui sont activés avec la fonction Dynamic Routing.
- 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.
- 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.
- 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.
- 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/.
- 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>
- Démarrez le serveur Web et commencez le routage vers l'application
installée dans la collectivité.
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.