Application servers, by default, are configured to use
all of the network interfaces that are available for them to use.
You can change this configuration such that an application server
only uses a specific network interface. However, you cannot configure
it to use a subgroup of interfaces. For example, if you have three
ethernet adapters, you cannot configure an application server to use
two of the three adapters.
About this task
When an application server is configured to use all network
interfaces, if it opens a socket on port 9901 on a machine with two
TCP/IP addresses, it opens port 9901 on both IP addresses.
When an application
server is configured to use a specific network interface, it only
communicates on that one network interface. For example, on a Windows
operating system, if an application server opens a socket on port
7842 on an ethernet adapter with an address of 192.168.1.150, the
netstat output displays 192.168.1.150.7842 in the Local Address field,
indicating that port 7842 is only bound to 192.168.1.150.
If
you have more than one network interface and you want to use each
one separately, you must have a separate configuration profile for
each interface. When network interfaces are used separately, a separate
node agent is required for each network interface that has an application
server running on it. Two application servers bound to two separate
network interfaces on the same machine cannot be in the same node
because they have different TCP/IP addresses.
Avoid trouble:
- If you want a specific application server to use a single network
interface, perform the following steps for that application server.
- If you want an entire node
to use a single network interface, perform the following steps for
your node agent and all the application servers in that node.
- If you want an entire cell
to use a single network interface, perform the following steps for
the deployment manager, node agent, and all the application servers
in the node.
- When performing the following steps, do not specify localhost,
a loop back address, such as 127.0.0.1, or an * (asterisk) for the
TCP/IP addresses.
gotcha
Procedure
- Update the com.ibm.CORBA.LocalHost and com.ibm.ws.orb.transport.useMultiHome
Object Request Broker (ORB) custom properties.
- In the administrative console, navigate to the indicated
panel.
- For an application server, click . Then in the Additional
Properties section, click Custom properties.
- For a deployment manager, click . In the Additional Properties section, click ORB
Service. Then, under Additional properties on the ORB
Service panel, click .
- For a node agent, click . In the Additional Properties section, click . Then, under Additional
properties on the panel, click Custom properties.
- Select the com.ibm.CORBA.LocalHost custom property and
specify an IP address or hostname in the Value field. Do
not set this property to either localhost or *.
If the com.ibm.CORBA.LocalHost
property is not in the list of already defined custom properties,
click New and then enter com.ibm.CORBA.LocalHost in
the Name field and specify an IP address or hostname in the Value
field.
- Select the com.ibm.ws.orb.transport.useMultiHome custom
property and specify false in the Value field.
If the com.ibm.ws.orb.transport.useMultiHome property is not
in the list of already defined custom properties, click New,
and then enter com.ibm.ws.orb.transport.useMultiHome in
the Name field and specify false in the Value field.
- Update the daemon_protocol_iiop_listenIPAddress WebSphere® variable to indicate the IP addresses
to which you want the location service daemon to bind.
- In the administrative console, click .
- Select the DAEMON_protocol_iiop_listenIPAddress variable
and specify * to specify bind all, or specify a
specific IP address in the Value field. If the DAEMON_protocol_iiop_listenIPAddress
variable is not in the list of already defined variables, click New,
and then enter DAEMON_protocol_iiop_listenIPAddress in
the Name field and specify the appropriate value in the Value field.
- Update the Java virtual
machine (JVM) com.ibm.websphere.network.useMultiHome custom property
for discovery and SOAP connections.
- In the administrative console, navigate to the indicated
page.
- For an application server, click .
- For a deployment manager, click .
- For a node agent, click .
- Select the com.ibm.websphere.network.useMultiHome custom
property and specify false in the Value field.
If the com.ibm.websphere.network.useMultiHome property is not
in the list of already defined custom properties, click and then enter com.ibm.websphere.network.useMultiHome in
the Name field and specify false in the Value field.
- Update the host name for TCP/IP connections.
- In the administrative console, navigate to the indicated
page.
- For an application server, click , and then, in the Additional Properties section, click Ports.
- For a deployment manager, click , and then, in the Additional Properties section, click Ports.
- For a node agent, click , and then, in the Additional Properties section, click .
- Update the Host field for each of the listed ports to
the value specified for the com.ibm.CORBA.LocalHost ORB custom property
in the first step. When you finish, none of the entries
listed in the Host column should contain an * (asterisk).
- Change the Initial State setting for each
of the Version 5 JMS servers to Stopped .
- In the administrative console, click .
- Click one of the listed JMS servers, and change the
value specified for the Initial State field to Stopped.
- Repeat the previous step until the Initial State setting
for all of the listed JMS servers is Stopped.
- Change the Initial State setting for each of the listener
ports to Stopped .
- In the administrative console, click .
- Under Communications, click .
- Click one of the listed listener ports and change the
value specified for the Initial State field to Stopped.
- Repeat the previous step until the Initial State setting
for all of the listed listener ports is Stopped.
- Save your changes.
- In the administrative console, click .
- Select Synchronize
changes with nodes, and then click Save.
- Stop and restart
all the affected servers, node agents, and the deployment manager.
Results
You have configured an installation of WebSphere Application Server to communicate
on one, and only one network interface on a machine that has more
than one network interface.
Example
This example creates
two nodes, each using a separate network interface, on a machine that
has at least two network interfaces:
- Use the Profile Management tool to create an application server
and federate it into the desired cell.
- Use the Profile Management tool to create an application server
profile, specifying a host name that is different than the host name
used for the previously created application server. Federate this
application server into the desired cell.
- Start the node agent and application server that are configured
to the first network interface. Follow the preceding steps for the
node agent and application server to prepare this node to communicate
on the network interface you specified when you configured this application
server.
- Start the second node agent and application server. Follow the
preceding steps for the node agent and application server to prepare
this node to communicate only on the network interface that you specified
when you configured the second application server.
- Stop all of the node agents and application servers that you created
in this example.
- Restart all of these node agents and application servers.
You have two separate nodes running on two different network
interfaces.
What to do next
If you are using a stand-alone Java client or server to communicate
with
WebSphere Application Server, and
you are using the
WebSphere Application Server Software
Development Kit (SDK), add the following properties to your Java command
to enable the ORB for your application to communicate with a specific
network interface.
-Dcom.ibm.ws.orb.transport.useMultiHome=false
-Dcom.ibm.CORBA.LocalHost=host_name
host_name is
the TCP/IP address or hostname of the network interface for
the ORB to use.
Avoid trouble: Do not set
host_name to
localhost, a loop back address, such as 127.0.0.1, or an * (asterisk).
gotcha