In the Tivoli Storage Manager environment where many nodes attempt to initiate scheduled operations simultaneously, you may have to manage scheduling throughput. For example, 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 when managing the
throughput of scheduled operations.
Task | Required Privilege Class |
---|---|
Modifying the default scheduling mode | System |
Modifying the scheduling period for incremental backup operations | System |
Balancing the scheduled workload for the server | System |
Setting the frequency at which client nodes contact the server | System |
By default, the server supports both scheduling modes: client-polling and server-prompted. The default allows nodes to define either scheduling mode in their client options file. The default is specified as ANY. You can modify this scheduling mode. For more information, see Overview of Scheduling Modes.
By default the server is set to the ANY scheduling mode, but the administrator can modify the default. If you modify the default to support only one scheduling mode for the server, the clients must specify the same scheduling mode in their client options file, or scheduled operations are not processed.
Client Polling Scheduling Mode: To have clients poll the server for scheduled operations, enter:
set schedmodes polling
Server-Prompted Scheduling Mode: To have the server prompt clients for scheduled operations, enter:
set schedmodes prompted
Any Scheduling Mode: To return to the default scheduling mode where the server supports both client-polling and server-promted scheduling modes, enter:
set schedmodes any
Users (root users on UNIX systems) 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 (client system options file on UNIX systems).
For more information, refer to the appropriate Using the Backup-Archive Client.
When you define a backup copy group, you specify the copy frequency, which is the minimum interval between successive backups. See Defining and Updating a Backup Copy Group. When you define a schedule, you specify the length of time between processing of the schedule. Consider the backup copy group frequencies you have defined in each management class in a policy domain when you specify the schedule period for incremental backups. Schedules for incremental backups do not need to be processed more often than the backup copy group frequency.
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 distribute the server's scheduled workload by:
The number of concurrent client/server sessions is defined by the MAXSESSIONS server option for the maximum client sessions, but you can set a maximum percentage of concurrent client/server sessions allowed 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 or retrieving files, or backing up, or archiving 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, and increasing the maximum percentage of scheduled sessions can reduce the server opportunity 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 percent of these sessions to be used by central scheduling, enter:
set maxschedsessions 25
The server allows 20 sessions to be used for scheduled operations.
For information about the MAXSESSIONS option, refer to Administrator's Reference.
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 options | May 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 porcess unscheduled operations |
To randomize start times for schedules means to scatter each schedule's start time across its startup window. A startup window is the start time and duration during which a schedule must be initiated.
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 the server can handle the workload. The maximum percentage of randomization allowed is 50 percent. This limit ensures that half of the startup window is available for retrying scheduled commands that have failed.
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:
To set randomization to 50 percent enter:
set randomize 50
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 (root users on UNIX systems) can also set these values in their client user options files (client system options files for UNIX systems). However, user values are overridden by the values that the administrator specifies.
The client node communication paths to the 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 are (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 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
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 only twice, enter:
set maxcmdretries 2
You can specify the length of time 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 failed attempts to contact the server or to process scheduled commands every 15 minutes, enter:
set retryperiod 15
You can use this number in conjunction with the 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.