![]() |
![]() |
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 |
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.
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 28 and Table 27.
How the mode works | Advantages and disadvantages |
---|---|
|
|
Table 28. Server-Prompted Mode
How the mode works | Advantages and disadvantages |
---|---|
|
|
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.
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.
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.
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:
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.
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 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.
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.
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.
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.
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.