Tivoli Header

Administrator's Guide


Managing the Throughput of Scheduled Operations

In the Tivoli Storage Manager environment where many nodes attempt to initiate scheduled operations simultaneously, you may have to manage scheduling throughput. You can choose a scheduling mode, and you can control how often client nodes contact the server to perform a scheduled operation.

Administrators can perform the following activities to manage the throughput of scheduled operations.

Task Required Privilege Class
Modify the default scheduling mode System
Modify the scheduling period for incremental backup operations System
Balance the scheduled workload for the server System
Set the frequency at which client nodes contact the server System

Modifying the Default Scheduling Mode

Tivoli Storage Manager provides two scheduling modes: client-polling and server-prompted. The mode indicates how client nodes interact with the server for scheduling operations. With client-polling mode, client nodes poll the server for the next scheduled event. With server-prompted mode, the server contacts the nodes at the scheduled start time.

By default, the server permits both scheduling modes. The default (ANY) allows nodes to specify either scheduling mode in their client options files. You can modify this scheduling mode.

If you modify the default server setting to permit only one scheduling mode, all client nodes must specify the same scheduling mode in their client options file. Clients that do not have a matching scheduling mode will not process the scheduled operations. The default mode for client nodes is client-polling.

The scheduler must be started on the client node's machine before a schedule can run in either scheduling mode.

For more information about modes, see Overview of Scheduling Modes.

Overview of Scheduling Modes

With client-polling mode, client nodes poll the server for the next scheduled event. With server-prompted mode, the server contacts the nodes at the scheduled start time. See Table 23 and Table 22.

Table 22. Client-Polling Mode

How the mode works Advantages and disadvantages
  1. A client node queries the server at prescribed time intervals to obtain a schedule. This interval is set with a client option, QUERYSCHEDPERIOD. For information about client options, refer to the appropriate Backup-Archive Installation and User's Guide.
  2. At the scheduled start time, the client node performs the scheduled operation.
  3. When the operation completes, the client sends the results to the server.
  4. The client node queries the server for its next scheduled operation.

  • Useful when a high percentage of clients start the scheduler manually on a daily basis, for example when their workstations are powered off nightly.
  • Supports randomization, which is the random distribution of scheduled start times. The administrator can control randomization. By randomizing the start times, Tivoli Storage Manager prevents all clients from attempting to start the schedule at the same time, which could overwhelm server resources.
  • Valid with all communication methods.


Table 23. Server-Prompted Mode

How the mode works Advantages and disadvantages
  1. The server contacts the client node when scheduled operations need to be performed and a server session is available.
  2. When contacted, the client node queries the server for the operation, performs the operation, and sends the results to the server.

  • Useful if you change the schedule start time frequently. The new start time is implemented without any action required from the client node.
  • Useful when a high percentage of clients are running the scheduler and are waiting for work.
  • Does not allow for randomization of scheduled start times.
  • Valid only with client nodes that use TCP/IP to communicate with the server.

Modifying the Scheduling Mode on the Server

If you modify the default so that the server permits only one scheduling mode for the server, all clients must specify the same scheduling mode in their client options file. Clients that do not have a matching scheduling mode do not process scheduled operations.

Client-Polling Scheduling Mode: To have clients poll the server for scheduled operations, enter:

set schedmodes polling

Ensure that client nodes specify the same mode in their client options files.

Server-Prompted Scheduling Mode: To have the server prompt clients for scheduled operations, enter:

set schedmodes prompted

Ensure that client nodes specify the same mode in their client options files.

Any Scheduling Mode: To return to the default scheduling mode so that the server supports both client-polling and server-prompted scheduling modes, enter:

set schedmodes any

Client nodes can then specify either polling or prompted mode.

Modifying the Default Scheduling Mode on Client Nodes

Users set the scheduling mode on client nodes. They specify either the client-polling or the server-prompted scheduling mode on the command line or in the client user options file. (On UNIX systems, root users set the scheduling mode in the client system options file.)

For more information, refer to the appropriate Backup-Archive Installation and User's Guide.

Specifying the Schedule Period for Incremental Backup Operations

When you define a backup copy group, you specify the copy frequency, which is the minimum interval between successive backups of a file. When you define a schedule, you specify the length of time between processing of the schedule. Consider how these interact to ensure that the clients get the backup coverage that you intend.

See Defining and Updating a Backup Copy Group.

Balancing the Scheduled Workload for the Server

You can control the server's workload and ensure that the server can perform all scheduled operations within the specified window. 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:

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.

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:

set maxschedsessions 25

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

The following table shows the tradeoffs of using either the SET MAXSCHEDSESSIONS command or the MAXSESSIONS server option.

An administrator can... Using... With the result
Increase the total number of sessions MAXSESSIONS server option May adversely affect the server's performance
Increase the total number of sessions allocated to scheduled operations SET MAXSCHEDSESSIONS command May reduce the server's ability to process unscheduled operations

For information about the MAXSESSIONS option and the SET MAXSCHEDSESSIONS command, refer to Administrator's Reference.

Randomizing Schedule Start Times

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

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 Length of the Schedule Startup Window

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.

Controlling How Often Client Nodes Contact the Server

To control how often client nodes contact the server to perform a scheduled operation, an administrator can set:

Users can also set these values in their client user options files. (Root users on UNIX 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

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.

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

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

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. 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. See Setting the Number of Command Retry Attempts.

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.


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