HCL Workload Automation, Version 9.4


About this task

The following questions will help in making decisions about how to set up your enterprise’s HCL Workload Automation network. Some questions involve aspects of your network, and others involve the applications controlled by HCL Workload Automation. You may need to consult with other people in your organization to resolve some issues.
  • How large is your HCL Workload Automation network? How many computers does it hold? How many applications and jobs does it run?

    The size of your network will help you decide whether to use a single domain or the multiple domain architecture. If you have a small number of computers, or a small number of applications to control with HCL Workload Automation, there may not be a need for multiple domains.

  • How many geographic locations will be covered in your HCL Workload Automation network? How reliable and efficient is the communication between locations?

    This is one of the primary reasons for choosing a multiple domain architecture. One domain for each geographical location is a common configuration. If you choose single domain architecture, you will be more reliant on the network to maintain continuous processing.

  • Do you need centralized or decentralized management of HCL Workload Automation?

    A HCL Workload Automation network, with either a single domain or multiple domains, gives you the ability to manage HCL Workload Automation from a single node, the master domain manager. If you want to manage multiple locations separately, you can consider the installation of a separate HCL Workload Automation network at each location. Note that some degree of decentralized management is possible in a stand-alone HCL Workload Automation network by mounting or sharing file systems.

  • Do you have multiple physical or logical entities at a single site? Are there different buildings, and several floors in each building? Are there different departments or business functions? Are there different applications?

    These may be reasons for choosing a multi-domain configuration. For example, a domain for each building, department, business function, or each application (manufacturing, financial, engineering, etc.).

  • Do you run applications, like SAP R/3, that will operate with HCL Workload Automation?

    If they are discrete and separate from other applications, you may choose to put them in a separate HCL Workload Automation domain.

  • Would you like your HCL Workload Automation domains to mirror your Windows domains?

    This is not required, but may be useful.

  • Do you want to isolate or differentiate a set of systems based on performance or other criteria?

    This may provide another reason to define multiple HCL Workload Automation domains to localize systems based on performance or platform type.

  • How much network traffic do you have now?

    If your network traffic is manageable, the need for multiple domains is less important.

  • Do your job dependencies cross system boundaries, geographical boundaries, or application boundaries? For example, does the start of Job1 on CPU3 depend on the completion of Job2 running on CPU4?

    The degree of interdependence between jobs is an important consideration when laying out your HCL Workload Automation network. If you use multiple domains, you should try to keep interdependent objects in the same domain. This will decrease network traffic and take better advantage of the domain architecture.

  • What level of fault-tolerance do you require?

    An obvious 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.