Planning domains

A IBM Workload Scheduler network contains at least one master domain manager that acts as a management hub for the product. Additional domains can be used to divide a widely-distributed network into locally-managed groups of workstations.

In a single domain configuration, the master domain manager maintains communications with all of the workstations in the network.

In a multiple domain configuration, the master domain manager communicates with the workstations in its domain and all immediately subordinate domain managers. The subordinate domain managers communicate with the workstations in their domains and their immediately subordinate domain managers, and so on. Domain managers report all of the activities of the domain to the master. Using multiple domains reduces network traffic and the load on the master by reducing the number of direct communications between the master domain manager and workstations. Multiple domains also provide fault-tolerance by limiting the outage caused by losing a domain manager in a single domain. To limit the effects further, you can designate backup domain managers to take over if domain managers fail.

When you define a new domain, you must identify the parent domain and the domain manager. The parent domain is the domain directly above the new domain in the domain hierarchy. All communications to and from a domain are routed through the parent domain manager.

Localized processing in your domain

Localized processing is separating your scheduling needs based on a common set of characteristics, such as geographical locations, business functions, and application groupings.

Group related processing can limit the amount of interdependency information that needs to be communicated between domains. The benefits of localized domains are:

Decreased network traffic: Keeping processing localized to domains eliminates the need for frequent inter-domain communication.
Tighter security and simplified administration: Security and administration can be defined at and limited to the domain level. Instead of network-wide or workstation-specific administration, you can have domain administration.
Optimized network and workstation fault-tolerance: In a multiple domain network, you can define backups for each domain manager so that problems in one domain do not disrupt operations in other domains.

Considerations in planning domains

There are a number of considerations that are to be taken into account when planning domains.

In planning your IBM Workload Scheduler network, consider the following:

Number of workstations, applications, and jobs: Consider the number of workstations that comprise the network and the number of applications and jobs that the network runs. If you have a small number of workstations, or a small number of applications to control, you do not need multiple domains.
Number of geographic locations: Consider the number of geographic locations covered by your network and the reliability and efficiency of communication between the locations. Multiple geographic locations is one of the primary reasons for choosing a multiple domain architecture. One domain for each geographical location is a common configuration. A single domain architecture relies on the network maintaining continuous processing.
Time zones: When your network is spread across multiple geographic locations in different time zones, decide whether to activate the time zone feature. See Time zone considerations.
Centralized or decentralized management: You can manage single or multiple domain networks from a single master domain manager. If you want to manage multiple locations separately, you can consider the installation of a separate IBM Workload Scheduler network at each location. Some decentralized management is possible in a stand-alone IBM Workload Scheduler network by mounting or sharing file systems.
Types of applications: Consider the types of applications that are run by IBM Workload Scheduler. If you have multiple applications that are distinctly separate from each other, you might choose to put them in separate domains.
Windows™ network: When you have a Windows network, you might want your IBM Workload Scheduler domains to mirror your Windows domains.
System performance and other criteria: You can define multiple domains to localize systems based on performance or operating system type.
Amount of network traffic: If your network traffic is manageable, having multiple domains is less important.
Dependencies between jobs: Consider if you need to plan for job dependencies that cross system boundaries, geographical boundaries, or application boundaries. For example, does the start of Job1 on workstation1 depend on the completion of Job2 running on workstation2. The degree of interdependence between jobs is an important consideration when planning your network. If you use multiple domains, try to keep interdependent objects in the same domain to decrease network traffic and improve the use of the domain architecture. See User's Guide and Reference.
Level of fault-tolerance required: A disadvantage of the single domain configuration is the reliance on a single domain manager. In a multi-domain network, the loss of a single domain manager affects only the agents in its domain.
Firewalls: When your network contains firewalls, plan the structure of your domains around the firewalls. See Administration Guide.

Workstation classes

Workstations are organized into domains to make your network management easier and more efficient. However, the domain name is not one of the selection criteria when choosing where to run a job or job stream.

If you want to group workstations together because they have similar job scheduling characteristics, use a workstation class. Any number of workstations can be grouped in a class, and a workstation can be in many classes. Jobs and job streams can be assigned to run on a specific workstation class.

For example, you could set up workstation classes to group workstations according to:

Your internal departmental structure, so that you could define a job that would be run on all the workstations in a department
The software installed on them, so that you could define a job that would be run on all the workstations that had a particular application installed
The role of the user, so that you could define a job that would be run on all the workstations belonging to, for example, managers

In this example, an individual workstation could be in one workstation class for its department, another for its user, and several others for the software installed on it.

Time zone considerations

Time zone support is an optional feature that is enabled by default.

It allows you to manage workloads at a global level. Time zone implementation also enables easy scheduling across multiple time zones.

For a description of how the time zone implementation works, see How IBM Workload Scheduler manages time zones.

For information about how to set the time zone implementation, see Enabling the time zone feature.