By coordinating client schedules, you can control the workload that scheduled operations place on the server and clients.
The following sections describe:
| Task | Required Privilege Class |
|---|---|
| Set the scheduling mode
Set the maximum percentage of sessions for scheduled operations Randomize schedule start times Set how often clients query the server Set the maximum number of times the client node scheduler can retry a command that failed Set the time between retry attempts | System |
The central scheduler on the server uses the default of both client-polling and server-prompted scheduling modes to process scheduled client operations. This default mode is specified as any. When the scheduling mode is any, the client can choose either scheduling mode. If you specify only one mode for the server, the clients must specify the same mode in their options file. Otherwise, scheduled client work is not processed. The default mode for the clients is polling.
The client-polling mode can be useful when a high percentage of clients may need to start the client scheduler manually on a daily basis, for example when their workstations are powered off nightly. With client-polling mode, you can randomly distribute scheduled start times.
The server-prompted mode can be useful if the administrator changes the schedule start time frequently. The new start time is implemented without any action required from the client node. The server-prompted mode is also useful when you have a high percentage of client nodes that have the client scheduler running and waiting for work. This mode does not allow for randomization of scheduled start times.
You can use the client-polling scheduling mode with all communication methods.
With this mode, the following occurs:
To have clients poll the server for scheduled operations, enter:
set schedmodes polling
| Note: | When the scheduling mode on the server is set to polling, the mode on the client node also must be set to polling for scheduled work to be processed. |
You can use the server-prompted scheduling mode only with client nodes that communicate with the server by using the TCP/IP communication method.
With this mode, the following occurs:
To have the server prompt client nodes when operations need to be performed, enter:
set schedmodes prompted
| Note: | When the scheduling mode on the server is set to prompted, the scheduling mode on the client node also must be set to prompted for scheduled work to be processed. |
To let the server support both client-polling and server-prompted scheduling modes, enter:
set schedmodes any
In this case, the client node may choose the scheduling mode and scheduled work will begin as specified.
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 ADSM 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.
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.
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.
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.
An administrator can:
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 ADSM 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 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 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.
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.
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. However, increased polling by client nodes also increases network traffic.
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 number of minutes the scheduler on a client node waits between retry attempts after a failed attempt to contact the server or after a scheduled command fails to process. 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.
Try setting this period 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