Notes on connecting from HULFT in a clustering environment
This section describes some points to be noted for the connection destination (remote host) when you use the following programs from HULFT in a clustering system to connect to HULFT on the remote host.
Program That is Run on HULFT in Clustering Environment |
Processing on Remote Host That Acknowledges Connections |
---|---|
Send File command (utlsend) |
Receive |
Send Request command (utlrecv) |
Observe |
Job Execution Result Notification command (hulsndrc) |
Observe |
Remote Job Execution command (utlrjob) |
Observe |
In HULFT clustering systems, Local Host Name (myhostname) can be set to the host name that corresponds to the virtual IP address of the system. This allows operation of services using the virtual IP address without requiring attention to each node.
However, if an error occurs before the remote host can receive the host name information from HULFT on the local host (in the cluster system), the names or actual IP addresses of the individual nodes on which HULFT is running in the clustering system may be displayed in the log of the remote host or in the console logs of the remote host.
HULFT does not manipulate IP addresses.
<Example>
-
Trace log of the remote host
The actual IP address or node name of the local host (in the clustering system) is output.
-
Observe Log of the remote host
If the remote host acknowledges a service request that is not registered in the Observe Definition file ($HULPATH/service.db) and an error occurs, the node name is output.
Figure 5.1 Points to be Noted When Connecting
Note that the appearance of the node name does not cause abnormal behavior of the HULFT program.
If this incident does not affect your business, you do not have to take action.
You can deal with the exposure in the following ways:
Workaround 1: Editing the 'hosts' file of the remote server by hand
For the actual IP address of each node in the 'hosts' file on the remote server, add the virtual host name (local host name for HULFT) that corresponds to the virtual IP address.
- <Setting example>
-
172.16.10.11 uxcluster 172.16.10.12 uxcluster
Workaround 2: Editing the routing table of the client nodes in the clustering system
Edit the routing table of each node and set the IP address of the connecting side as the virtual IP address.
- <Setting example> Editing the routing table in Linux
-
Set the following command to be run when the nodes are switched.
(When a virtual IP address is allocated to eth0:0)
# route add -host 172.16.20.10 dev eth0:0