Examples for creating a peer domain definition

Edit online

The mkrpdomain command can be used with different flags depending on your requirements to create a peer domain definition.

The following list of examples describe the various ways of creating a peer domain definition in different scenarios:

To create a peer domain with multiple nodes:
Scenario: You want to establish a peer domain with three nodes and the nodes are identified by the DNS names nodeA, nodeB, and nodeC. When you issued the preprpnode command from the nodes that make up your peer domain, you determined that nodeA is the originator node. In this case, to create a peer domain named ApplDomain, run the following command from nodeA:
```
mkrpdomain ApplDomain nodeA nodeB nodeC
```
This command creates the peer domain definition ApplDomain that consists the nodes nodeA, nodeB, and nodeC.
To create a peer domain by specifying a file that contains the list of all the node names:
Scenario: You want to create a peer domain with many nodes. Instead of manually listing the node names on the command line, you want to specify the name of a file that contains the list of node names. To do so, run the following command:
```
mkrpdomain -f node.list ApplDomain
```
This command creates the peer domain definition ApplDomain that consists of the nodes that are listed in the node.list file.
To use the IPv6 addresses as resources for heartbeating and internal peer domain operations:
Scenario: The nodes in your peer domain (ApplDomain) use IPv4 addresses. IPv6 addresses are also configured on the network interfaces of the nodes. To see these IPv6 addresses being represented as resources in the IBM.NetworkInterface class and to use them for heartbeating and internal peer domain operations, run the following command:
```
mkrpdomain -6 ApplDomain
```
This command establishes a peer domain in which the IPv6 addresses that are configured on the nodes' network interfaces are visible as resources in the IBM.NetworkInterface class. They are formed into their own communication groups for use in heartbeating and internal peer domain operations. If the -6 flag is not specified, no IPv6 addresses are visible as resource in the IBM.NetworkInterface class or used in this way.
To prevent the mkrpdomain command to fail for all the nodes that are based on a single node failure:
Scenario: You are creating a large peer domain configuration, in which the node.list file contains many nodes. In such a case, the chances of the mkrpdomain command failure on any one node is greater. By default, if the mkrpdomain command fails on any node, it fails for all nodes. You want to override this default behavior such that the mkrpdomain command does not fail for all nodes that are based on a single node failure. You can do so by running the following command:
```
mkrpdomain -c -f node.list ApplDomain
```
To create a peer domain definition with Quick quorum type:
Scenario: You are creating a large peer domain configuration. You want to specify the quick startup mode that is helpful in creating such large clusters. You can do so by running the following command:
```
mkrpdomain -Q 1 ApplDomain nodeA nodeB nodeC
```
Or,
```
mkrpdomain -Q Quick ApplDomain nodeA nodeB nodeC
```
To specify port 1200 for Topology Services and port 2400 for Group Services:
Scenario: You want to override the default ports with the value of 1200 for the Topology Services and 2400 for the Group Services. You can do so by running the following command:
```
mkrpdomain -t 1200 -g 2400 ApplDomain nodeA nodeB nodeC
```
To specify a fanout value:
Scenario: You are creating a large peer domain configuration. You want to specify a larger fanout value of 900 to improve performance. You can do so by running the following command:
```
mkrpdomain -m 900 -f node.list ApplDomain
```
To reset the fanout value:
Scenario: You want to reset the fanout value to 1000 so that the earlier fanout value is not applied to all the subsequent operations in the peer domain. You can do so by running the following commands from a node that is online in the peer domain:
1. Set the management scope to the RSCT peer domain scope:
```
export CT_MANAGEMENT_SCOPE=2
```
2. Issue the following chrsrc command:
```
chrsrc -c IBM.PeerNode Fanout=1000
```
To enable a shared secret key type of CSSKTYPE_DES_MD5:
Scenario: You want to use the CSSKTYPE_DES_MD5 shared secret key in your peer domain so that the RSCT component can verify the authenticity of the control messages that they receive. You can do so by running the following command:
```
mkrpdomain -k CSSKTYPE_DES_MD5 ApplDomain nodeA nodeB nodeC
```
To specify a shared secret key refresh interval:
Scenario: You want the shared secret key to be refreshed more frequently than the default 24 hours. So, you want to specify a refresh interval of 12 hours. You can do so by running the following command:
```
mkrpdomain -k CSSKTYPE_DES_MD5 -r 12:00:00 ApplDomain nodeA nodeB nodeC
```
To specify the policy information:
Scenario: You are creating a peer domain ApplDomain in a CAA environment and you want to specify the policy information such that the Name (NodeA) and HostName (host_nameA) attributes must not be in sync with each other. You can do so by running the following command:
```
mkrpdomain -p 0 ApplDomain nodeA@host_nameA
```