1.1 IBM Tivoli Workload Scheduler architectural overview

< Day Day Up >

IBM Tivoli Workload Scheduler Version 8.2 is the IBM strategic scheduling product that runs on many different platforms, including the mainframe. This redbook covers installing ITWS Version 8.2 in a high availability (HA) environment and configuring it to meet high availability requirements. The focus is on the IBM Tivoli Workload Scheduler Version 8.2 Distributed product, although some issues specific to Version 8.1 and IBM Tivoli Workload Scheduler for z/OS are also briefly covered.

Understanding specific aspects of IBM Tivoli Workload Scheduler's architecture is key to a successful high availability implementation. In-depth knowledge of the architecture is necessary for resolving some problems that might present themselves during the deployment of IBM Tivoli Workload Scheduler in an HA environment. We will only identify those aspects of the architecture that are directly involved with an high availability deployment. For a detailed discussion of IBM Tivoli Workload Scheduler's architecture, refer to Chapter 2, "Overview", in IBM Tivoli Workload Scheduling Suite Version 8.2, General Information, SC32-1256.

IBM Tivoli Workload Scheduler uses the TCP/IP-based network connecting an enterprise's servers to accomplish its mission of scheduling jobs. A job is an executable file, program, or command that is scheduled and launched by IBM Tivoli Workload Scheduler. All servers that run jobs using IBM Tivoli Workload Scheduler make up the scheduling network.

A scheduling network contains at least one domain, the master domain, in which a server designated as the Master Domain Manager (MDM) is the management hub. This server contains the definitions of all scheduling objects that define the batch schedule, stored in a database. Additional domains can be used to divide a widely distributed network into smaller, locally managed groups. The management hubs for these additional domains are called Domain Manager servers.

Each server in the scheduling network is called a workstation, or by the interchangeable term CPU. There are different types of workstations that serve different roles. For the purposes of this publication, it is sufficient to understand that a workstation can be one of the following types. You have already been introduced to one of them, the Master Domain Manager. The other types of workstations are Domain Manager (DM) and Fault Tolerant Agent (FTA).

Figure 1-1 on page 3 shows the relationship between these architectural elements in a sample scheduling network.

Figure 1-1: Main architectural elements of IBM Tivoli Workload Scheduler relevant to high availability

The lines between the workstations show how IBM Tivoli Workload Scheduler communicates between them. For example, if the MDM needs to send a command to FTA2, it would pass the command via DM_A. In this example scheduling network, the Master Domain Manager is the management hub for two Domain Managers, DM_A and DM_B. Each Domain Manager in turn is the management hub for two Fault Tolerant Agents. DM_A is the hub for FTA1 and FTA2, and DM_B is the hub for FTA3 and FTA4.

IBM Tivoli Workload Scheduler operations revolve around a production day, a 24-hour cycle initiated by a job called Jnextday that runs on the Master Domain Manager. Interrupting or delaying this process presents serious ramifications for the proper functioning of the scheduling network.

Based upon this architecture, we determined that making IBM Tivoli Workload Scheduler highly available requires configuring at least the Master Domain Manager server for high availability. This delivers high availability of the scheduling object definitions. In some sites, even the Domain Manager and Fault Tolerant Agent servers are configured for high availability, depending upon specific business requirements.

< Day Day Up >