IBM BPM, V8.0.1, All platforms > Install IBM BPM > Plan for IBM BPM
Network deployment configuration for z/OS
An initial ND configuration consists of a dmgr server that has a daemon for the z/OS system on which the dmgr runs. After an ND cell is created, you can add application server nodes by creating and federating new, empty, managed nodes into the ND cell.
To install IBM BPM for z/OS into an ND environment, configure both a dmgr node and an empty managed node before federation. When you federate the empty node to the dmgr, the node becomes a managed node because it is being administered by the dmgr. The managed node contains a node agent, but no application servers. You can use the administrative console to add an application server or cluster to the node.
The dmgr runs the administrative console applications and is used for centralized administration tasks, such as managing the configuration of all of the managed nodes in its cell and deploying applications to selected servers and clusters in the cell. The dmgr runs on one node, and application servers run in different nodes.
A basic ND configuration is made up of the following components:
- A dmgr server running in a separate node that runs the administrative console application, which you can use to deploy applications.
- One or more application server nodes on each z/OS target system that hosts portions of the cell. Each node consists of a node agent and a number of application servers. Each node must be federated into the dmgr cell.
- A single location service daemon on each z/OS system. For each cell, one daemon server must exist. This server runs constantly, checking and distributing server workload.
- A database management system, typically DB2 for z/OS, for storing the database objects.
The following figure shows a WebSphere Application Server for z/OS ND configuration that has been extended with IBM BPM for z/OS functions. The dmgr server has a daemon for the z/OS system on which the dmgr runs. The dmgr is administering four servers, A, B, C, and D, using two node agents.
It is important that you plan your IBM BPM for z/OS configuration before you start, especially when configuring an ND cell. There are many choices and you must understand the factors that influence these choices to make the correct decisions during the installation process. Factors to consider include:
- The hardware resources that you require
- The number of clusters and cluster members required to support your business
- The number of DB2 for z/OS subsystems, data sharing groups, and databases required
- Authentication roles and security considerations
- The method that you will use to implement the deployment environment
- Other supporting resources such as a user registry (for security), one or more HTTP servers (for web content), necessary firewalls, and load balancers
The servers and clusters in an ND environment can support the following application components:
- Process Server
- Performance Data Warehouse
- Business Process Choreographer
- Business rules
- Mediations
- Relationships
Advantages of an ND configuration
- One of the main advantages of an ND configuration is availability. When the configuration contains multiple LPARs, you can reduce single points of failure and maintain availability during planned and unplanned outages.
- You can configure how messages are delivered.
For example, you can specify secure assured delivery, which provides assurance that messages are not lost and are transported securely, or best effort delivery, where it is possible that messages might get lost in case of a system failure.
- You can set up an ND cell to have several servers that host mediation modules. Mediation modules provide scalability (the ability to handle more client connections) and greater message throughput.
- You can create server clusters. With server clusters, you can manage a group of servers together and enable those servers to participate in workload management.
- Your bus environment might be made up of several stand-alone and dmgr profiles, to provide separate administrative domains for different departments, or to separate test and production facilities. Each profile has its own SCA.SYSTEM service integration bus.
Related concepts: