TSM Server options to efficiently manage the client backup schedules

As the number of client nodes increases, number of client schedules also increases. TSM administrator has to make sure that all the client schedules run successfully by not effecting TSM Server performance. Admins should change/modify some TSM server parameters appropriately depending on their environment to control TSM server performance. You can control the server’s workload and ensure that the server can perform all scheduled operations within the specified window. 

Monitoring Client Schedules

To enable the server to complete all schedules for clients, you may need to use trial and error to control the workload. To estimate how long client operations take, test schedules on several representative client nodes. Keep in mind, for example, that the first incremental backup for a  client node takes longer than subsequent incremental backups. You can balance the server’s scheduled workload by

• Adjusting the number of sessions that the server allocates to scheduled operations.

• Randomizing scheduled start time for client operations (if clients use client-polling scheduling mode).

• Increasing the length of the startup window.

• Setting the number of sessions the server allocates to scheduled operations

The maximum number of concurrent client/server sessions is defined by the MAXSESSIONS server option. Of these sessions, you can set a maximum percentage to be available for processing scheduled operations. Limiting the number of sessions available for scheduled operations ensures that sessions are available when users initiate any unscheduled operations, such as restoring file or retrieving files.

Also Read: How to configure TSM Client Backup & Archive Schedules ?

If the number of sessions for scheduled operations is insufficient, you can increase either the total number of sessions or the maximum percentage of scheduled sessions. However, increasing the total number of sessions can adversely affect server performance. Increasing the maximum percentage of scheduled sessions can reduce the server availability to process unscheduled operations. For example, assume that the maximum number of sessions between client nodes and the server is 80. If you want 25% of these sessions to be used by for scheduled operations, enter

setopt maxschedsessions 25

The server then allows a maximum of 20 sessions to be used for scheduled operations.

Using Randomization option to randomize the schedule startups

To randomize start times for schedules means to scatter each schedule’s start time across its startup window. A startup window is defined by the start time and duration during which a schedule must be initiated. For example, if the start time is 1:00 a.m. and the duration is 4 hours, the startup window is 1:00 a.m. to 5:00 a.m. For the client-polling scheduling mode, you can specify the percentage of the startup window that the server can use to randomize start times for different client nodes associated with a schedule. If you set randomization to 0, no randomization occurs. This process can result in communication errors if many client nodes try to contact the server at the same instant.

The settings for randomization and the maximum percentage of scheduled sessions can affect whether schedules are successfully completed for client nodes. Users  receive a message if all sessions are in use when they attempt to process a schedule. If this happens, you can increase randomization and the percentage of scheduled sessions allowed to make sure that the server can handle the workload. The maximum percentage of randomization allowed is 50%. This limit ensures that half of the startup window is available for retrying scheduled commands that have failed. To set randomization to 50%, enter

set randomize 50

It is possible, especially after a client node or the server has been restarted, that a client node may not poll the server until after the beginning of the startup window in which the next scheduled event is to start. In this case, the starting time is randomized over the specified percentage of the remaining duration of the startup window. Consider the following example

The schedule start time is 8:00 a.m. and its duration is 1 hour. Therefore the startup window for the event is from 8:00 to 9:00 a.m.

• Ten client nodes are associated with the schedule.

• Randomization is set to 50%.

• Nine client nodes poll the server before 8:00 a.m.

• One client node does not poll the server until 8:30 a.m.

The result is that the nine client nodes that polled the server before the beginning of the startup window are assigned randomly selected starting times between 8:00 and 8:30. The client node that polled at 8:30  receives a randomly selected starting time that is between 8:30 and 8:45.

Increasing the size of the startup window (by increasing the schedule’s duration) can also affect whether a schedule completes successfully. A larger startup window gives the client node more time to attempt initiation of a session with the server. This parameter is used when defining client schedule 

Server and Client parameters which can be used to control Schedules

To control how often client nodes contact the server to perform a scheduled operation, an administrator can set the frequency for certain events.

• How often nodes query the server.

• The number of command retry attempts.

• The amount of time between retry attempts

Users can also set these values in their client user options files. Root users on UNIX and Linux systems set the values in client system options files. However, user values are overridden by the values that the administrator specifies on the server. The communication paths from client node to server can vary widely with regard to response time or the number of gateways. In such cases, you can choose not to set these values so that users can tailor them for their own needs.

Setting how often clients query the server (queryschedperiod)

When scheduling client nodes with client-polling scheduling, you can specify how often the nodes query the server for a schedule. If nodes poll frequently for schedules, changes to scheduling information (through administrator commands) are propagated more quickly to the nodes. However, increased polling by client nodes also increases network traffic. 

Also Read: How TSM Server determines the eligibility of files during different types of backup ?

For the client-polling scheduling mode, you can specify the maximum number of hours that the scheduler on a client node waits between attempts to contact the server to obtain a schedule. You can set this period to correspond to the frequency with which the schedule changes are being made. If client nodes poll more frequently for schedules, changes to scheduling information (through administrator commands) are propagated more quickly to client nodes. If you want to have all clients using polling mode contact the server every 24 hours, enter

set queryschedperiod 24

This setting has no effect on clients that use the server-prompted scheduling mode. The clients also have a QUERYSCHEDPERIOD option that can be set on each client. The server value overrides the client value once the client successfully contacts the server.

Setting the number of command retry attempts (maxcmdretries)

You can specify the maximum number of times the scheduler on a client node can retry a scheduled command that fails. The maximum number of command retry attempts does not limit the number of times that the client node can contact the server to obtain a schedule. The client node never gives up when trying to query the server for the next schedule. Be sure not to specify so many retry attempts that the total retry time is longer than the average startup window. If you want to have all client schedulers retry a failed attempt to process a scheduled command up to two times, enter

set maxcmdretries 2

Maximum command retries can also be set on each client with a client option, MAXCMDRETRIES. The server value overrides the client value once the client successfully contacts the server.

Setting the amount of time between retry attempts (retryperiod)

You can specify the length of time that the scheduler waits between command retry attempts. Command retry attempts occur when a client node is unsuccessful in establishing a session with the server or when a scheduled command fails to process.

Also Read: Use these 2 TSM server options to prevent network issues during backup schedules

Typically, this setting is effective when set to half of the estimated time it takes to process an average schedule. If you want to have the client scheduler retry every 15 minutes any failed attempts to either contact the server or process scheduled commands, enter

set retryperiod 15

You can use this setting in conjunction with the SET MAXCMDRETRIES command (number of command retry attempts) to control when a client node contacts the server to process a failed command. The retry period can also be set on each client with a client option, RETRYPERIOD. The server value overrides the client value once the client  successfully contacts the server.