IBM Tivoli Storage Manager, Version 7.1

Setting up communications for enterprise configuration and enterprise event logging

The communication setup for enterprise configuration and enterprise event logging, which is through TCP/IPv4 or IPv6, is identical.

About this task

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:

A server named HEADQUARTERS as a configuration manager and two servers, MUNICH and STRASBOURG, as managed servers.
HEADQUARTERS as an event server and MUNICH and STRASBOURG as source servers.

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:

Procedure

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.
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).

Results

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

Figure 1. Communication configuration with separate server definitions

Setting up communications for Enterprise configuration and event logging using separate definitions. Servers below, MUNICH and STRASBOURG, are defined to server HEADQUARTERS. The server above, HEADQUARTERS, is defined to servers MUNICH and STRASBOURG.

Using Cross Definitions – Follow this sequence:

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.
On HEADQUARTERS: Define MUNICH and STRASBOURG, specifying that cross define should be done.

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

Figure 2. Communication configuration with cross definition

Setting up communications for Enterprise configuration and event logging using cross definitions. Above, server HEADQUARTERS defines servers below, MUNICH and STRASBOURG, and specifies that cross defining be done for each. Cross defining is permitted by servers MUNICH and STRASBOURG.

Note: Issuing the SET SERVERNAME command can affect scheduled backups until a password is re-entered. Windows clients use the server name to identify which passwords belong to which servers. Changing the server name after the clients are connected forces the clients to re-enter the passwords. On a network where clients connect to multiple servers, it is recommended that all of the servers have unique names. See the Administrator's Reference for more details.

Feedback