Network Deployment (Distributed operating systems), v8.0 > Secure applications and their environment > Authenticate users > Select an authentication mechanism > Configure LTPA and working with keys > 2. Generate keys manually or automatically, and control the number of active keys. > Work with nodes - groups of managed servers
Node groups
A node group is a collection of managed nodes. Managed nodes are WAS nodes. A node group defines a boundary for server cluster formation.
Node groups
Nodes that you organize into a node group need to be similar in terms of installed software, available resources, and configuration to enable servers on those nodes to host the same applications as part of a server cluster. The dmgr does no validation to guarantee that nodes in a given node group have anything in common.
Node groups are optional and are established at the discretion of the WAS administrator. However, a node must be a member of a node group. Initially, all Application Server nodes are members of the default DefaultNodeGroup node group.
A node can be a member of more than one node group.
Nodes on distributed platforms and the IBM i platform cannot be members of a node group that contains a node on a z/OS platform. However, nodes on distributed platforms and nodes on the IBM i platform can be members of the same node group.
To delete a node group, the node group must be empty. The default node group cannot be deleted.
Sysplex node groups
A sysplex node group is a node group unique to the z/OS operating system. The sysplex node group includes a sysplex name and a z/OS operating system location service configuration. A sysplex is a collection of z/OS systems that cooperate by using certain hardware and software products to process workloads.
We cannot explicitly create a sysplex node group. The z/OS operating system creates sysplex node groups in the following ways:
- When you configure a dmgr server on the z/OS operating system, the default node group is a sysplex node group. The dmgr is automatically a member of the sysplex node group. Application Server for z/OS nodes that you add to the network deployment cell are automatically members of this node group.
- We can add an Application Server for z/OS node to a network deployment cell whose dmgr is on a distributed platform node. In this case, add the first Application Server for z/OS node for the network deployment cell to an empty node group. The system automatically configures the node group into a sysplex node group by using the sysplex name and the z/OS location service configuration that belongs to the Application Server for z/OS node.
We cannot remove a node from a sysplex node group. However, if a node is the only member of a sysplex node group, you can add that node to an empty node group. The empty node group is converted into a sysplex node group and the former sysplex node group of the node is converted into a regular node group.
We cannot delete a node group that is a sysplex node group.
Example: Using node groups
By organizing nodes that satisfy the application requirements into a node group, you establish an administrative policy that governs which nodes can be used together to form a cluster. The people who define the cell configuration and the people who create server clusters can operate with greater independence from one another, if they are different people.
Example 1
Assume the following information:
- A cell is comprised of nodes one to eight.
- Each node is a managed node, which means that each node is configured with an Application Server.
- Nodes six, seven, and eight are additionally configured as WebSphere Business Integration Server Foundation nodes.
- All nodes are either z/OS system nodes from the same sysplex, or some combination of distributed platform nodes and IBM i platform nodes.
- By default, all the nodes are in the default DefaultNodeGroup node group.
Applications that exploit WebSphere Business Integration Server Foundation functions can run successfully only on nodes six, seven, and eight. Therefore, clusters that host these applications can be formed only on nodes six, seven, and eight.
To define a clustering policy that guides users of your WebSphere cell into building clusters that can span only predetermined nodes, create an additional node group called WBINodeGroup, for example. Add to the node group nodes six, seven, and eight. If you create a cluster on a node from the WBINodeGroup node group, the system allows only nodes from the WBINodeGroup node group to be members of the cluster.
Example 2
Assume the following information:
- A cell is comprised of nodes one to six.
- Each node is a managed node, which means that each node is configured with an Application Server.
- Nodes one to four are some combination of distributed platform nodes and IBM i platform nodes.
- Nodes five and six are nodes on the z/OS operating system and are in the PLEX1 sysplex.
- The dmgr is on a distributed platform node.
- Nodes one to four are members of the DefaultNodeGroup node group by default.
- You created empty PLEX1NodeGroup node group to group the z/OS operating system nodes on the PLEX1 sysplex.
- You joined the nodes on the z/OS operating system to the PLEX1NodeGroup node group when you added them to the cell. Nodes on the z/OS operating system cannot be in the same node group with the distributed platform nodes.
Applications that exploit z/OS functions in the PLEX1 sysplex can run successfully on nodes five and six only. Therefore, clusters that host these applications can be formed only on nodes five and six. The required separation of distributed platform nodes and IBM i platform nodes from z/OS system nodes establishes a natural clustering policy that guides users of your Application Server cell into building clusters that can span only predetermined nodes. If you create a cluster on a node from the PLEX1NodeGroup node group, the system allows only nodes from the PLEX1NodeGroup node group to be members of the cluster.
Related
Example: Using node groups with clusters
Configure node groups
Create clusters