Saminnet-Search Article Wiki Forum Blog SNS Cloud
TSM server conf

  • Data-Articles
    • Slower CKD stage (3) Wed12,16:41pm

      Having your kidneys work 窶 even a little 窶 can help you feel better and live longer. If you can slow your CKD, you can delay the need for treatment of kidney failure. The types of changes you might make to help your heart or the rest of your body will help your kidneys, too. Here are some things you can do 窶 or avoid 窶 to protect your kidneys: r Blood Sugar In The Target Range.…

      Read More...

TSM server conf


Setting Up Communications Among Servers

This section describes how to set up communications for enterprise configuration, enterprise event logging, and command routing. Communication set up 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 name "TSM". Change the server name to a unique name 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:

  • 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:

  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.797:1823).

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



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 54 shows the servers and the commands issued on each:



Setting Up Communications for Enterprise Configuration and Event Logging

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.

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:

  • On HEADQUARTERS: register administrator HQ and specify the server names and addresses of MUNICH and STRASBOURG:
    register admin hq secret
    grant authority hq classes=system
     
    define server munich hladdress=9.115.2.223 lladdress=1919
    define server strasbourg hladdress=9.115.2.178 lladdress=1715 
    
  • On MUNICH and STRASBOURG Register administrator HQ with the required privilege class on each server:
    register admin hq secret
    grant authority hq classes=system
    
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.

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.

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.797:1823) and STRASBOURG.

    On STRASBOURG: Define HEADQUARTERS and MUNICH.

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



Setting Up Communications for Command Routing

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 56 shows the servers and the commands issued on each:



Setting Up Communications for Command Routing

Updating and Deleting Servers

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

  • For Server-to-server Virtual Volumes:
    • If you update the node name, you must also update the password.
    • If you update the password but not the node name, the node name defaults to the server name specified by the SET SERVERNAME command.
  • For enterprise configuration and enterprise event logging: If you update the server password, it must match the password specified by the SET SERVERPASSWORD command at the target server.
  • For enterprise configuration: When a server is first defined at a managed server, that definition cannot be replaced by a server definition from a configuration manager. This prevents the definition at the managed server from being inadvertently replaced. Such a replacement could disrupt functions that require communication among servers, for example command routing or virtual volumes.

    To allow replacement, update the definition at the managed server by issuing the UPDATE SERVER command with the ALLOWREPLACE=YES parameter. When a configuration manager distributes a server definition, the definition always includes the ALLOWREPLACE=YES parameter.

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:

  • The server is defined as an event server.

    You must first issue the DELETE EVENTSERVER command.

  • The server is a target server for virtual volumes.

    A target server is named in a DEFINE DEVCLASS (DEVTYPE=SERVER) command. You must first change the server name in the device class or delete the device class.

Comments   

 
0 #1 Guest 2016-04-01 01:36
Electrical Deals specialize in graded consumer electronics products, compare
our prices on the Toshiba DR18DT DVD recorder at We also have a
large range of discounted Toshiba televisions now in stock at.

Also every company is trying to deliver even additional benefits to the customers,
attracting them and ensuring wonderful benefits.
Some of the not-so-popular ones can also be watched,
since some channels put them up online, in an attempt of them gaining a fan base on this platform.


Here is my web site - Submit your site URL
Quote
 

Articles by Date

TweetTweet Share on LinkedInShare on LinkedIn Share on Google+Google+ Submit to RedditReddit Publish on WordPress WordPress Send emailSend email