Tivoli Storage Manager for Windows: Administrator's Guide


Setting Up Communications Among Servers

This section describes how to set up communications for enterprise configuration, enterprise event logging, and command routing. Communication setup for server-to-server virtual volumes is described in Setting Up Source and Target Servers for Virtual Volumes.

When you set up communications among servers for any purpose, ensure that servers have unique names. At installation, a TSM server has the same name as that of the machine. You can change the server name if necessary before setting up communication with other servers. For example, enter this command to name the server TUCSON:

set servername tucson

Setting Up Communications for Enterprise Configuration and Enterprise Event Logging

The communication setup for enterprise configuration and enterprise event logging, which is through TCP/IP, is identical. The examples shown here apply to both functions. If you are set up for one, you are set up for the other. However, be aware that the configuration manager and event server are not defined simply by setting up communications. You must identify a server as a configuration manager (SET CONFIGMANAGER command) or an event server (DEFINE EVENTSERVER command). Furthermore, a configuration manager and an event server can be the same server or different servers.

Enterprise configuration
Each managed server must be defined to the configuration manager, and the configuration manager must be defined to each managed server.

Enterprise event logging
Each server sending events to an event server must be defined to the event server, and the event server must be defined to each source server.

The following examples of setting up communications could be used to create these configurations:

For a pair of servers to communicate with each other, each server must be defined to the other. For example, if a configuration manager manages three managed servers, there are three server pairs. You can issue separate definitions from each server in each pair, or you can "cross define" a pair in a single operation. Cross definition can be useful in large or complex networks. The following scenarios and accompanying figures illustrate the two methods.

Using separate definitions -- Follow this sequence:

  1. On MUNICH: Specify the server name and password of MUNICH.

    On STRASBOURG: Specify the server name and password of STRASBOURG.

    On HEADQUARTERS: Specify the server name and password of HEADQUARTERS.

  2. On HEADQUARTERS: Define MUNICH (whose password is BERYL and whose address is 9.115.2.223:1919) and STRASBOURG (whose password is FLUORITE and whose address is 9.115.2.178:1715).

    On MUNICH and STRASBOURG: Define HEADQUARTERS (whose password is AMETHYST and whose address is 9.115.4.177:1823).

Figure 59 shows the servers and the commands issued on each:

Figure 59. Communication Configuration with Separate Server Definitions

Setting Up Communications for Enterprise Configuration and Event Logging

Using Cross Definitions -- Follow this sequence:

  1. On MUNICH: Specify the server name, password, and high and low level addresses of MUNICH. Specify that cross define is permitted.

    On STRASBOURG: Specify the server name, password, and high and low level addresses of STRASBOURG. Specify that cross define is permitted.

    On HEADQUARTERS: Specify the server name, password, and high and low level addresses of HEADQUARTERS.

  2. On HEADQUARTERS: Define MUNICH and STRASBOURG, specifying that cross define should be done.
Figure 60 shows the servers and the commands issued on each:

Figure 60. Communication Configuration with Cross Definition

Setting Up Communications for Enterprise Configuration and Event Logging

Communication Security

Security for this communication configuration is enforced through the exchange of passwords (which are encrypted) and, in the case of enterprise configuration only, verification keys. Communication among servers, which is through TCP/IP, requires that the servers verify server passwords (and verification keys). For example, assume that HEADQUARTERS begins a session with MUNICH:

  1. HEADQUARTERS, the source server, identifies itself by sending its name to MUNICH.
  2. The two servers exchange verification keys (enterprise configuration only).
  3. HEADQUARTERS sends its password to MUNICH, which verifies it against the password stored in its database.
  4. If MUNICH verifies the password, it sends its password to HEADQUARTERS, which, in turn, performs password verification.
Note:
If another server named MUNICH tries to contact HEADQUARTERS for enterprise configuration, the attempt will fail. This is because the verification key will not match. If MUNICH was moved or restored, you can issue the UPDATE SERVER command with the FORCERESYNC parameter to override the condition.

Setting Up Communications for Command Routing

This section describes how to set up communications for command routing. You must define the target servers to the source servers, and the same administrator must be registered on all servers. Using enterprise configuration, you can easily distribute the administrator information to all the servers.

Note:
You must be registered as an administrator with the same name and password on the source server and all target servers. The privilege classes do not need to be the same on all servers. However, to successfully route a command to another server, an administrator must have the minimum required privilege class for that command on the server from which the command is being issued.

For command routing in which one server will always be the sender, you would only define the target servers to the source server. If commands can be routed from any server to any other server, each server must be defined to all the others.

Only One Source Server

The example in this section shows how to set up communications for administrator HQ on the server HEADQUARTERS who will route commands to the servers MUNICH and STRASBOURG. Administrator HQ has the password SECRET and has system privilege class. Here is the procedure:

Note:
If your server network is using enterprise configuration, you can automate the preceding operations. You can distribute the administrator and server lists to MUNICH and STRASBOURG. In addition, all server definitions and server groups are distributed by default to a managed server when it first subscribes to any profile on a configuration manager. Therefore, it receives all the server definitions that exist on the configuration manager, thus enabling command routing among the servers.

Multiple Source Servers

The examples in this section show how to set up communications if the administrator, HQ, can route commands from any of the three servers to any of the other servers. You must define all the servers to each other. You can separately define each server to each of the other servers, or you can "cross define" the servers. In cross definition, defining MUNICH to HEADQUARTERS also results in automatically defining HEADQUARTERS to MUNICH.

Separate Definitions

Follow this sequence:

  1. On MUNICH: Specify the server name and password of MUNICH. Register administrator HQ and grant HQ system authority.

    On STRASBOURG: Specify the server name and password of STRASBOURG. Register administrator HQ and grant HQ system authority.

    On HEADQUARTERS: Specify the server name and password of HEADQUARTERS. Register administrator HQ and grant HQ system authority.

  2. On HEADQUARTERS: Define MUNICH (whose password is BERYL and whose address is 9.115.2.223:1919) and STRASBOURG (whose password is FLUORITE and whose address is 9.115.2.178:1715).

    On MUNICH: Define HEADQUARTERS (whose password is AMETHYST and whose address is 9.115.4.177:1823) and STRASBOURG.

    On STRASBOURG: Define HEADQUARTERS and MUNICH.

Figure 61 shows the servers and the commands issued on each:

Figure 61. Communication Configuration with Separate Server Definitions

Setting Up Communications for Command Routing

Cross Definitions

Follow this sequence:

  1. On MUNICH: Specify the server name, password, and high and low level addresses of MUNICH. Specify that cross define is permitted. Register administrator HQ and grant HQ system authority.

    On STRASBOURG: Specify the server name, password, and high and low level addresses of STRASBOURG. Specify that cross define is permitted. Register administrator HQ and grant HQ system authority.

    On HEADQUARTERS: Specify the server name, password, and high and low level addresses of HEADQUARTERS. Register administrator HQ and grant HQ system authority.

  2. On HEADQUARTERS: Define MUNICH and STRASBOURG, specifying that cross define should be done.
  3. On MUNICH: Define STRASBOURG, specifying that cross define should be done.
Note:
If your server network is using enterprise configuration, you can automate the preceding operations. You can distribute the administrator lists and server lists to MUNICH and STRASBOURG. In addition, all server definitions and server groups are distributed by default to a managed server when it first subscribes to any profile on a configuration manager. Therefore, it receives all the server definitions that exist on the configuration manager, thus enabling command routing among the servers.

Figure 62 shows the servers and the commands issued on each:

Figure 62. Communication Configuration with Cross Definitions

Setting Up Communications for Command Routing

Updating and Deleting Servers

You can update a server definition by issuing the UPDATE SERVER command.

You can delete a server definition by issuing the DELETE SERVER command. For example, to delete the server named NEWYORK, enter the following:

delete server newyork

The deleted server is also deleted from any server groups of which it is a member. See Setting Up Server Groups for information about server groups.

You cannot delete a server if either of the following conditions is true:


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]