Configuration d'un serveur d'applications, d'un noeud ou d'une cellule pour utiliser une interface réseau unique

Par défaut, les serveurs d'applications sont configurés pour utiliser toutes les interfaces réseau disponibles à leur disposition. Vous pouvez modifier cette configuration de sorte qu'un serveur d'applications n'utilise qu'une interface réseau particulière. Vous ne pouvez toutefois pas le configurer pour utiliser un sous-groupe d'interfaces. Si, par exemple, vous disposez de trois cartes de réseau Ethernet, il est impossible de configurer un serveur d'applications pour qu'il en utilise deux.

Pourquoi et quand exécuter cette tâche

Lorsqu'un serveur d'applications est configuré pour utiliser toutes les interfaces réseau, s'il ouvre une connexion sur le port 9901 d'un poste disposant de deux adresses TCP/IP, il ouvre le port 9901 sur les deux adresses IP.

[Windows]Sous Microsoft Windows, la sortie netstat contient *.9901 dans la zone Local Address, indiquant que le port 9901 est lié à toutes les interfaces réseau du système.

Lorsqu'un serveur d'applications est configuré pour utiliser une interface réseau donnée, il ne communique que sur cette interface réseau. Sous Windows, par exemple, si un serveur d'applications ouvre une connexion sur le port 7842 sur une carte de réseau Ethernet avec une adresse 192.168.1.150, la sortie netstat contient 192.168.1.150.7842 dans la zone Local Address, indiquant que le port 7842 est lié uniquement à l'adresse 192.168.1.150.

Si vous disposez de plusieurs interfaces réseau et que vous voulez les utiliser séparément, vous devez disposer d'un profil de configuration distinct pour chaque interface. Lorsque les interfaces réseau sont utilisées séparément, un agent de noeud distinct est nécessaire pour chaque interface réseau sur laquelle s'exécute un serveur d'applications. Deux serveurs d'applications liés à deux interfaces réseau distinctes sur le même poste ne peuvent appartenir au même noeud car ils disposent d'adresses TCP/IP différentes.

Dans un environnement multihébergé, vous devrez peut-être séparer le trafic http entrant et/ou https en le forçant à utiliser une carte réseau autre que celle liée au nom d'hôte utilisé lors de l'installation. Cette séparation peut être accomplie en indiquant le nom d'hôte ou l'adresse IP à lier à une autre carte réseau pour les ports defaulthost et defaulthost_secure de chaque serveur d'applications qui doit être redirigé. Cette modification configure le serveur d'applications pour qu'il accepte uniquement le trafic http et/ou https reçue sur la carte indiquée. De même, le gestionnaire de déploiement utilise ce nom d'hôte comme transport lors de la génération du plug-in pour ce serveur d'applications. Il n'existe aucune limitation connue pour cette modification tant que seuls les ports defaulthost et defaulthost_secure sont modifiés de cette façon.

Eviter les incidents Eviter les incidents:
  • Si vous souhaitez qu'un serveur d'applications particulier utilise une seule interface réseau, exécutez la procédure suivante pour ce serveur.
  • Si vous souhaitez qu'un noeud entier utilise une seule interface réseau, exécutez la procédure suivante pour l'agent de noeud et tous les serveurs d'applications du noeud.
  • Si vous souhaitez qu'une cellule entière utilise une seule interface réseau, exécutez la procédure suivante pour le gestionnaire de déploiement, l'agent de noeud et tous les serveurs d'applications du noeud.
  • Lorsque vous exécutez la procédure suivante, n'indiquez pas de système hôte local, d'adresse en boucle, telle que 127.0.0.1, ou d'astérisque (*) dans les adresses TCP/IP. Lorsqu'un astérisque (*) est indiqué en guise de nom d'hôte pour l'adresse DCS (Distribution and Consistency Services) et que vous disposez de plusieurs cartes NIC (Network Identification Card), le port DCS peut être relié à plusieurs adresses IP.
  • [Windows]Lorsque l'ORB client établit une connexion TCP à un serveur, deux scénarios sont possibles :
    • Le côté socket local est lié à l'adresse unique, spécifiée soit sur la propriété ORB_LISTENER_ADDRESS dans le fichier serverindex.xml soit sur la propriété personnalisée com.ibm.CORBA.LocalHost.
    • Le côté socket local n'est lié à aucune adresse particulière.

    Ces deux scénarios surviennent car la pile de gestion de réseau Microsoft Windows ne transmet pas les paquets dans différentes zones de portée. Les interfaces publique et de bouclage se trouvent dans des zones de portée différentes.

    Le premier scénario échoue avec une exception SocketException si votre client s'exécute sous Microsoft Windows7 ou Microsoft Windows 2008 R2 et la propriété personnalisée com.ibm.ws.orb.transport.useMultiHome sur le client a la valeur false car :
    • soit la valeur d'hôte ORB_LISTENER_ADDRESS du client, dans le fichier serverindex.xml, ou la propriété personnalisée com.ibm.CORBA.LocalHost, présente l'adresse interne localhost ou 127.0.0.1 et le serveur a un nom d'hôte ou une adresse IP externe du type 147.10.32.117,
    • soit le client a une adresse externe et le serveur une adresse interne.
gotcha

Procédure

  1. Mettez à jour les propriétés personnalisées ORB (Object Request Broker) com.ibm.CORBA.LocalHost et com.ibm.ws.orb.transport.useMultiHome.
    1. Dans la console d'administration, accédez au panneau indiqué.
      • Pour un serveur d'applications, cliquez sur Serveurs > Types de serveur > Serveurs d'applications WebSphere > nom_serveur > Paramètres du conteneur > Services du conteneur > Service ORB. Puis, dans la section Propriétés supplémentaires, cliquez sur Propriétés personnalisées.
      • Pour un gestionnaire de déploiement, cliquez sur Administration du système > Gestionnaire de déploiement. Dans la section Propriétés supplémentaires, cliquez sur Service ORB. Puis dans Propriétés supplémentaires, dans le panneau Service ORB, cliquez sur Propriétés personnalisées.
      • Pour un agent de noeud, cliquez sur Administration du système > Agents de noeud > agent_noeud. Dans la section Propriétés supplémentaires, cliquez sur Service ORB. Puis dans Propriétés supplémentaires, dans le panneau Service ORB, cliquez sur Propriétés personnalisées.
    2. Sélectionnez la propriété personnalisée com.ibm.CORBA.LocalHost et indiquez une adresse IP ou un nom d'hôte dans la zone Valeur. N'associez pas la valeur de l'hôte local ou * à cette propriété.

      Si la propriété com.ibm.CORBA.LocalHost ne figure pas dans la liste des propriétés personnalisées déjà définies, cliquez sur Nouveau et entrez com.ibm.CORBA.LocalHost dans la zone Nom et définissez l'adresse IP ou le nom d'hôte dans la zone Valeur.

    3. Sélectionnez la propriété personnalisée com.ibm.ws.orb.transport.useMultiHome et entrez false dans la zone Valeur. Si la propriété com.ibm.ws.orb.transport.useMultiHome ne figure pas dans la liste des propriétés personnalisées définies, cliquez sur Nouveau et entrez ensuite com.ibm.ws.orb.transport.useMultiHome dans la zone Nom, puis false dans la zone Valeur.
  2. [z/OS]Mettez à jour la variable WebSphere vdaemon_protocol_iiop_listenIPAddress pour indiquer les adresses IP auxquelles vous voulez lier le démon du service de localisation.
    1. Dans la console d'administration, cliquez sur Environnement > Variables WebSphere.
    2. Sélectionnez la variable DAEMON_protocol_iiop_listenIPAddress et spécifiez * pour indiquer que le démon doit se lier à toutes les adresses, ou entrez une adresse IP spécifique dans la zone Valeur. Si la variable DAEMON_protocol_iiop_listenIPAddress n'est pas dans la liste des variables déjà définies, cliquez sur Nouveau et entrez DAEMON_protocol_iiop_listenIPAddress dans la zone Nom, puis spécifiez la valeur appropriée dans la zone Valeur.
  3. Mettez à jour la propriété personnalisée com.ibm.websphere.network.useMultiHome de la machine virtuelle Java™ pour l'exploration et les connexions SOAP.
    1. Dans la console d'administration, accédez à la page indiquée.
      [AIX Solaris HP-UX Linux Windows][IBM i]
      • Pour un serveur d'applications, cliquez sur Serveurs > Types de serveur > Serveurs d'applications WebSphere > nom_serveur > Gestion des processus Java > Définition des processus > Machine virtuelle Java > Propriétés personnalisées.
      • Pour un gestionnaire de déploiement, cliquez sur Administration du système > Gestionnaire de déploiement > Gestion des processus Java > Définition des processus > Machine virtuelle Java > Propriétés personnalisées.
      • Pour un agent de noeud, cliquez sur Administration du système > Agent de noeud > agent_noeud > Gestion des processus Java > Définition des processus > Machine virtuelle Java > Propriétés personnalisées.
      [z/OS]
      • Pour un serveur d'applications, cliquez sur Serveurs > Types de serveur > Serveurs d'applications WebSphere > nom_serveur > Gestion des processus Java > Définition des processus > type_processus > Machine virtuelle Java > Propriétés personnalisées.
      • Pour un gestionnaire de déploiement, cliquez sur Administration du système > Gestionnaire de déploiement > Gestion des processus Java > Définition des processus > type_processus > Machine virtuelle Java > Propriétés personnalisées.
      • Pour un agent de noeud, cliquez sur Administration du système > Agents de noeud > agent_noeud > Gestion des processus Java > Définition des processus > Contrôle > Machine virtuelle Java > Propriétés personnalisées.
    2. Sélectionnez la propriété personnalisée com.ibm.websphere.network.useMultiHome et entrez false dans la zone Valeur. Si la propriété com.ibm.websphere.network.useMultiHome ne figure pas dans la liste des propriétés personnalisées définies, cliquez sur Nouveau et entrez com.ibm.websphere.network.useMultiHome dans la zone Nom et false dans la zone Valeur.
  4. Mettez à jour le nom d'hôte pour les connexions TCP/IP.
    1. Dans la console d'administration, accédez à la page indiquée.
      • Pour un serveur d'applications, cliquez sur Serveurs > Types de serveur > Serveurs d'applications WebSphere > nom_serveur et dans la section Propriétés supplémentaires, cliquez sur Ports.
      • Pour un gestionnaire de déploiement, cliquez sur Administration du système > Gestionnaire de déploiement puis, dans la section Propriétés supplémentaires, cliquez sur Ports.
      • Pour un agent de noeud, cliquez sur Administration du système > Agents de noeud > agent_noeud puis, dans la section Propriétés supplémentaires, cliquez sur Ports.
    2. Mettez à jour la zone Hôte pour chacun des ports de la liste avec la valeur associée à la propriété personnalisée ORB com.ibm.CORBA.LocalHost à la première étape. Lorsque vous avez terminé, aucune des entrées de la liste de la colonne Hôte ne doit contenir d'astérisque (*).
  5. Remplacez le paramètre d'état initial de chaque serveur JMS version 5 par Arrêté.
    1. Dans le console d'administration, cliquez sur Serveurs > Types de serveurs > Serveurs JMS version 5.
    2. Cliquez sur l'un des serveurs JMS de la liste et remplacez la valeur associée à la zone Etat initial par Arrêté.
    3. Répétez l'étape précédente jusqu'à ce que le paramètre Etat initial de tous les serveurs JMS de la liste soit Arrêté.
  6. Sauvegardez les modifications.
    1. Dans la console d'administration, cliquez sur Administration du système > Enregistrement des modifications dans le référentiel maître.
    2. Sélectionnez Synchroniser les modifications avec les noeuds et cliquez sur Sauvegarder.
  7. Arrêtez et relancez tous les serveurs affectés, les agents de noeud et le gestionnaire de déploiement.

Résultats

Vous avez configuré une installation de WebSphere Application Server pour communiquer sur une et une seule interface réseau sur un poste disposant de plusieurs interfaces réseau.

Exemple

Cet exemple permet de créer deux noeuds, chacun utilisant une interface réseau distincte sur un poste disposant d'au moins deux interfaces réseau :

  1. Utilisez l'outil de gestion de profil pour créer un serveur d'applications et le fédérer dans la cellule souhaitée.
  2. Utilisez l'outil de gestion de profil pour créer un profil de serveur d'applications, définissant un nom d'hôte différent de celui utilisé pour le serveur d'applications créé. Fédérez ce serveur d'applications dans la cellule souhaitée.
  3. Lancez l'agent de noeud et le serveur d'applications qui sont configurés avec la première interface réseau. Suivez la procédure précédente pour l'agent de noeud et le serveur d'applications afin de préparer ce noeud pour communiquer sur l'interface réseau spécifiée lors de la configuration de ce serveur d'applications.
  4. Lancez le deuxième agent de noeud et le serveur d'applications. Suivez la procédure précédente pour l'agent de noeud et le serveur d'applications afin de préparer ce noeud pour communiquer uniquement sur l'interface réseau spécifiée lors de la configuration du deuxième serveur d'applications.
  5. Arrêtez tous les agents de noeud et les serveurs d'applications créés dans cet exemple.
  6. Redémarrez tous ces agents de noeud et ces serveurs d'applications.

Deux noeuds distincts s'exécutent sur deux interfaces réseau séparées.

Que faire ensuite

Si vous utilisez un serveur ou un client Java autonome pour communiquer avec WebSphere Application Server, et que vous utilisez WebSphere Application Server Software Development Kit (SDK), ajoutez les propriétés suivantes à la commande Java pour activer ORB pour permettre à l'application de communiquer avec une interface réseau donnée.
-Dcom.ibm.ws.orb.transport.useMultiHome=false 
-Dcom.ibm.CORBA.LocalHost=nom_hôte

nom_hôte est l'adresse TCP/IP ou le nom_hôte de l'interface réseau que ORB doit utiliser.

Eviter les incidents Eviter les incidents: N'associez pas l'hôte local, une adresse en boucle telle que 127.0.0.1 ou un astérisque (*) au nom_hôte. gotcha

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



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=trun_multiplenic
Nom du fichier : trun_multiplenic.html