Restrict TSM to use 1 IP address

[FreudianSlip]

Hi,

I'm currently looking at consolidating a number of TSM servers onto a single system. These old TSM servers have been about for a while and service several hundred nodes between them. The nodes were all configured in a standard way with the only main difference between each group of nodes being the IP address of the server they are to communicate with (note the port numbers are the same across all the nodes).

What I'd like to do is configure the new server with a number of "virtual" ip addresses and then bind different instances of TSM on the server to each of the new virtual IP addresses. This should allow me to have numerous TSM server instances running on the same TCP/IP port number but bound, in effect to different IP's, meaning I dont have to trawl through the client estate...

I guess my big question here is : Is it possible to do this? My server will be a P-Series box running AIX 6.1.

Thanks in advance

 

[moon-buddy]

Hi,

I'm currently looking at consolidating a number of TSM servers onto a single system. These old TSM servers have been about for a while and service several hundred nodes between them. The nodes were all configured in a standard way with the only main difference between each group of nodes being the IP address of the server they are to communicate with (note the port numbers are the same across all the nodes).

What I'd like to do is configure the new server with a number of "virtual" ip addresses and then bind different instances of TSM on the server to each of the new virtual IP addresses. This should allow me to have numerous TSM server instances running on the same TCP/IP port number but bound, in effect to different IP's, meaning I dont have to trawl through the client estate...

I guess my big question here is : Is it possible to do this? My server will be a P-Series box running AIX 6.1.

Thanks in advance

I don't think this is possible from within the TSM Server environment. TSM is a one-to-one IP bound environment.

It maybe possible through routing/NAT wherein a router will redirect IP addresses to the TSM server's IP address. I haven't done this but it may work.

 

[SleeperGTP]

Did you use an IP address in your dsm.opt on your clients or a NetBIOS/DNS name?

 

[heada]

I don't think TSM will bind to an address. When you start the dsmserv process, it binds all addresses on port 1500. For example:

[heada@ridustsm01:/u/heada] netstat -an |grep LISTEN |grep 1500
tcp4       0      0  *.1500                 *.*                    LISTEN
[heada@ridustsm01:/u/heada]

See that it is listening on the * address? That means every IP address on the box and thus only giving you a single instance on that port.

-Aaron

 

[AjithS]

To bind TSM Server to listen on a single IP address, run:

SET SERVERHLA <IP_ADDRESS>
SET SERVERLLA <PORT>

 

[JohanW]

tsm: TSM_BACKUP>help set serverhladdress
3.58.36 SET SERVERHLADDRESS (Set the high-level address of a server)

Use this command to set the high-level address (IP) of a server. IBM
Tivoli Storage Manager uses the address when you issue a DEFINE SERVER
command with CROSSDEFINE=YES.

I don't think that does what you think it does.

May I ask where you got the idea this would do what OP asked for? You seem to be posting misinformation.

 

[AjithS]

Thanks for pointing that out - you're genius.

 

[erwanns]

Hi,

There is no TSM way of doing that. SERVERHLA & SERVLLA are for Server 2 Server communcation only, and TCPPort indicated by SERVERLLA must match TCPPort specified in the dsmserv.opt. Whatever you do with TSM, dsmserv will bind the TCPPort on all the available interfaces.

DNS has nothing to do with TCP port numbers...

A way of doing that could a DNAT way, with port forwarding, but I won't be sure I'll advise such a solution because of possible perfomance impact and because it seems too complicated. I prefer TSM when it's as simple as possible.

If your pSeries box is partionnable (LPAR-Capable), you'll better using partitions. Or use different TCPPort values for the different instances.

 

[hogmaster]

To my knowledge there is no way to restrict the tsm server to a certain ip adress. You may use ip filter or similar. The most common solutin is to use unique tcp port for each server, then you can use virtual ip adresses. This requres you to change the tcpport for all clients.
This change can be done before you move the TSM server to a new server.

/ good luck hogmaster

 

[BBB]

Depending on what your budget it, you could always partition your shiny p-series box with 1 tsm server per lpar. Uncap the cpu/memory and let them all duke it out for resources.

Probably not really the solution you were after though as more overhead and maintenance, but will save you the pain of changing all the clients.

 

[FreudianSlip]

Thanks for the replies,

Apologies for not posting sooner.

Looks like we're going to have to write a script to trawl through the nodes remotley and update the ip addresses that way. Seems a bit of a restriction in TSM though, would have been nice to have this level of granularity.. /me looks sternly at IBM.

 

[xaminmo]

Separate IPs for separate TSMS instances on the same LPAR

Specific IP binding/LISTEN was brought up in alpha discussions, but was not followed up on.

The "supported" procedure is to use a separate LPAR, or to use a separate port on the same LPAR.

Functionally, you can create a WPAR for each TSM instance, and each WPAR would have its own IP address.

Tivoli states WPARs are not supported. This is because of difficulty in guaranteeing CPU resources, and because of complexity of PVU licensing (WLM?).

From a functional standpoint, it's just an AIX instance, so it will work.
From a licensing standpoint, you'll need TSM licenses purchased for the entire LPAR.
From a performance standpoint, they won't help you shoot problems because you'd have to look at all of the WPARs and the root LPAR stats to verify who's eating resources.
This is no problem because Support Line doesn't generally support performance problems anyway.

Expect LPAR and WPAR options to require a separate DB2 instance installed with TSM. No one in support will notice you're in a WPAR, but they would definitely notice if your DB2 instance were not in the same OS partition.