Create Cluster (CRTCLU)
Where allowed to run: All environments (*ALL) Threadsafe: Yes |
Parameters Examples Error messages |
The Create Cluster (CRTCLU) command is used to create a new cluster of one or more nodes. Each node specified on the Node parameter will be placed in the cluster membership list.
If the Start indicator (START) parameter value is *NO, each node that is being added will have a status of New and Cluster Resource Services will not be started on any node. In order to start Cluster Resource Services, the Start Cluster Node (STRCLUNOD) command must be invoked on a node that ran the CRTCLU command. The STRCLUNOD command may be used to start nodes in the cluster membership list.
If the START parameter value is *YES, the cluster can contain only one node. Cluster Resource Services will be started on the node being defined. If the START parameter value is *YES and more than one cluster node is specified, the START parameter will be ignored. Cluster Resource Services will not be started on any node being defined. If Cluster Resource Services is not successfully started, the status of the node remains New.
After Cluster Resource Services has been started on the original node, additional nodes can only be started by calling the Start Cluster Node (STRCLUNOD) command on the original node. If Cluster Resource Services is active on more than one node, additional nodes may be started by invoking the Start Cluster Node (STRCLUNOD) command on any node that has a status of Active.
Once the cluster has been created, the Add Cluster Node Entry (ADDCLUNODE) command can be used to add additional nodes to the cluster membership list. The ADDCLUNODE command can be invoked on any node in the cluster that has a status of Active or from the node on which the cluster was originally created.
Prior to cluster version 6, a failover message queue could be defined for a cluster resource group. If the failover message queue was defined, a message was enqueued during the failover of the cluster resource group, allowing the user to cancel or continue the failover. If a cluster node ended or failed and there were multiple cluster resource groups with that node as a primary recovery domain node, the user would have needed to respond to a message for each cluster resource group.
In cluster version 6 and above, the user has the option of receiving and responding to one message for all cluster resource groups which are failing over to the same node when the primary node for the cluster resource groups ends or fails. A cluster message queue, failover wait time, and failover default action may be specified on this command or it can also be specified on the CHGCLU (Change Cluster) command. If a failure occurs on a node, that node is the primary recovery domain node for any active cluster resource groups, and the cluster message queue is defined, then one message will be enqueued on the cluster message queue. This gives the user the option of continuing all cluster resource group failovers to the new primary, or cancelling all cluster resource group failovers. No message will be enqueued if the primary node is removed from the cluster because that node can not remain the primary node of the cluster resource group. If a cluster resource group is failing over individually, one message will be sent which will control the failover of that cluster resource group. The message will be placed on the message queue on the new primary node before the cluster resource groups call their exit programs. If the failovers are cancelled, the primary node of the cluster resource groups will not be changed, and the cluster resource groups will become Inactive. The exit programs will be called with an action code of Failover Cancelled.
If the user wants to specify failover actions for a specific cluster resource group, the failover message queue fields on the CRTCRG (Create CRG) or CHGCRG (Change CRG) commands should be used instead of the cluster message queue fields. If the failover fields are set at a cluster level, they will override any cluster resource group failover parameters. If the cluster message queue is set to *NONE, then the failover of each individual cluster resource group will be controlled via the cluster resource group failover parameters.
Restrictions:
- You must have input/output system configuration (*IOSYSCFG) special authority on all nodes in the cluster to run this command.
- This command cannot be called from a cluster resource group exit program.
- A node can be a member of only one cluster.
- You must include the system on which the command is issued in the cluster membership list.
- If a cluster message queue is specified, it must exist on each node in the cluster. This will be verified on the requesting node as part of the CRTCLU (Create Cluster) command, and will be verified on each additional cluster node when that node is started.
Top |
Parameters
Keyword | Description | Choices | Notes |
---|---|---|---|
CLUSTER | Cluster | Name | Required, Positional 1 |
NODE | Node list | Values (up to 128 repetitions): Element list | Required, Positional 2 |
Element 1: Node identifier | Name | ||
Element 2: IP address | Values (up to 2 repetitions): Character value | ||
START | Start indicator | *YES, *NO | Optional |
VERSION | Target cluster version | *CUR, *PRV | Optional |
HAVERSION | Target PowerHA version | *CUR, *PRV | Optional |
CLUMSGQ | Cluster message queue | Single values: *NONE Other values: Qualified object name |
Optional |
Qualifier 1: Cluster message queue | Name | ||
Qualifier 2: Library | Name | ||
FLVWAITTIM | Failover wait time | Integer, *NOWAIT, *NOMAX | Optional |
FLVDFTACN | Failover default action | *PROCEED, *CANCEL | Optional |
Top |
Cluster (CLUSTER)
Specifies the cluster which will be created.
This is a required parameter.
- name
- Specify the name of the cluster to be created.
Top |
Node identifier (NODE)
Specifies information about the cluster and the list of nodes which will be placed in the cluster membership list. A maximum of 128 nodes can be in a cluster.
This is a required parameter.
Element 1: Node identifier
- name
- Specify the name for the system that uniquely identifies a node.
Element 2: IP address
The cluster interface address is an IP address that is used by Cluster Resource Services to communicate with other nodes in the cluster. A maximum of 2 interface addresses per node can be specified.
- character-value
- Specify the IP address to be used to communicate with other nodes in the cluster. The IP address may be an IPv4 address (for any cluster version) or IPv6 address (if current cluster version is 7 or greater).
An IPv4 internet address is specified in the form nnn.nnn.nnn.nnn, where nnn is a decimal number ranging from 0 through 255. An IPv4 internet address is not valid if it has a value of all binary ones or all binary zeros for the network identifier (ID) portion or the host portion of the address.
An IPv6 internet address must be a unicast address and must not contain an imbedded IPv4 address (compatibility or mapped). An IPv6 internet address is specified in the form x:x:x:x:x:x:x:x, where x is a hexadecimal number ranging from 0 through X'FFFF'. The "::" may be used once in the IPv6 address to indicate one or more groups of 16 bits of zeros. The "::" may be used to compress leading, imbedded, or trailing zeros in the address.
If the IP address is entered from the command line, the address must be enclosed in apostrophes.
Top |
Start indicator (START)
Specifies whether or not Cluster Resource Services is to be started on the node being defined. If more than one cluster node is specified, the START parameter will be ignored. Cluster Resource Services will not be started on any node being defined.
- *YES
- Cluster Resource Services will be started on the node.
- *NO
- Cluster Resource Services will not be started on any node.
Top |
Target cluster version (VERSION)
Specifies the version the cluster will use in conversation with other nodes in the cluster. This also determines the potential node version of the nodes allowed to join the cluster. The following possible values are based on the node originating the request.
- *CUR
- The cluster will communicate at the requesting node's potential node version. In addition, nodes with a potential node version less than the requesting node will not be allowed to join the cluster.
- *PRV
- The cluster will communicate at the requesting node's potential node version minus 1. This allows nodes at a previous potential node version to join the cluster. However, no new cluster function can be used until all nodes have the latest cluster version.
Top |
Target PowerHA version (HAVERSION)
Specifies the PowerHA version the cluster will use in conversation with other nodes in the cluster. This also determines the potential PowerHA node version of the nodes allowed to join the cluster. The following possible values are based on the node originating the request.
- *CUR
- The cluster will communicate at the requesting node's potential PowerHA node version. In addition, nodes with a potential HA node version less than the requesting node will not be allowed to join the cluster.
- *PRV
- The cluster will communicate at the requesting node's potential PowerHA node version minus 1. This allows nodes at a previous potential PowerHA node version to join the cluster. However, no new PowerHA licensed program product function can be used until all nodes have the latest PowerHA version.
Top |
Cluster message queue (CLUMSGQ)
Specifies the message queue to receive messages relating to cluster or node level events. For cluster version 6, messages relating to failover will be sent to this queue. For node level failovers, one message will be sent which will control the failover of all cluster resource groups with the same new primary node. If a cluster resource group is failing over individually, one message will be sent which will control the failover of that cluster resource group. The message will be sent on the new primary node. If this field is set, the individual cluster resource group failover message queue fields will not be used. If this field is set, the specified message queue must exist on all nodes in the cluster. This will be verified on the requesting node as part of the CRTCLU command and will be verified on each additional cluster node when that node is started. The message queue cannot be in an independent auxiliary storage pool.
Single values
- *NONE
- No cluster message queue has been defined.
Qualifier 1: Cluster message queue
- name
- Specify the name of the cluster message queue.
Qualifier 2: Library
- name
- Specify the name of the library that contains the message queue to receive cluster messages. The library name cannot be *CURLIB, QTEMP, *LIBL, *USRLIBL, *ALL, or *ALLUSR.
Top |
Failover wait time (FLVWAITTIM)
Specifies the number of minutes to wait for a reply to the failover message that was enqueued on the cluster message queue.
- *NOWAIT
- Failover proceeds without user intervention. Acts the same as V5R4M0 and prior.
- *NOMAX
- Wait forever until a response is given to the failover inquiry message.
- integer
- Specify the number of minutes to wait for a response to the failover inquiry message. If no response is received in the specified number of minutes, the failover default action field will be looked at to decide how to proceed.
Top |
Failover default action (FLVDFTACN )
Specifies the default action to be taken if a response to the failover message on the cluster message queue is not received in the failover wait time limit.
- *PROCEED
- Proceed with failover.
- *CANCEL
- Do not attempt failover.
Top |
![Start of change](delta.gif)
Examples for CRTCLU
![End of change](deltaend.gif)
CRTCLU CLUSTER(MYCLUSTER) NODE((NODE01 ('9.5.13.187')) (NODE02 ('2001:0DB8:101::0230:D9FF'))) START(*NO) VERSION(*CUR) HAVERSION(*CUR) CLUMSGQ(MYLIB/MYQUEUE) FLVWAITTIM(5) FLVDFTACN(*PROCEED)
This command creates cluster MYCLUSTER. The cluster membership list is NODE01 and NODE02. Interface address 9.5.13.187 will be used to communicate with node NODE01. Interface address 2001:0DB8:101::0230:D9FF will be used to communicate with node NODE02. Cluster communications will use the cluster and PowerHA version equal to the requesting nodes potential version level. Cluster Resource Services is not started on the nodes. A cluster message queue called MYQUEUE in library MYLIB is defined. If a failover message is enqueued on the cluster message queue, the failover will proceed after waiting 5 minutes for a message reply.
Top |
![Start of change](delta.gif)
Top |