Complete the cluster configuration checklist to ensure
that your environment is prepared properly before you begin to configure
your cluster.
Table 1. TCP/IP configuration
checklist for clusters
| TCP/IP requirements |
| __ |
Start TCP/IP on every node you plan to include in the cluster
using the Start
TCP/IP (STRTCP) Command. |
| __ |
Configure the TCP loopback address (127.0.0.1) and verify that
it shows a status of Active. Verify the TCP/IP loopback address by
using the Work
with TCP/IP Network Status (WRKTCPSTS) Command on
every node in the cluster. |
| __ |
Verify that the IP addresses used for clustering
on a node have a status of Active. Use the Work with TCP/IP Network Status
(WRKTCPSTS) Command to check the status of the IP
addresses. |
| __ |
Verify that the Internet Daemon (INETD) server
is active on all nodes in the cluster. If INETD server is not active,
you need to start the INETD server. For information about how to start
INETD server, see Starting the INETD server. |
| __ |
Verify that user profile for INETD, which is specified in /QIBM/ProdData/OS400/INETD/inetd.conf, does not have more than minimal
authority. If this user profile has more than minimal authority, starting cluster node will fail. By
default, QUSER is specified as the user profile for INETD. |
| __ |
Verify every cluster IP address on every node in the cluster
can route to and send UDP datagrams to every other IP address in the
cluster. If any cluster node uses an IPv4 address, then every node
in the cluster needs to have an active IPv4 address (not necessarily
configured as a Cluster IP address) that can route to and send TCP
packets to that address. Also, if any cluster node uses an IPv6 address,
then every node in the cluster needs to have an active IPv6 address
(not necessarily configured as a Cluster IP address) that can route
to and send TCP packets to that address. Use the PING command,
specifying a local IP address, and the TRACEROUTE command,
specifying UDP messages can be useful in determining if two IP addresses
can communicate. PING and TRACEROUTE do
not work between IPv4 and IPv6 addresses, or if a firewall is blocking PING and TRACEROUTE.
|
| __ |
Verify that ports 5550 and 5551 are not being used by other
applications. These ports are reserved for IBM® clustering. Port usage can be viewed by using
the Work with
TCP/IP Network Status (WRKTCPSTS) command. Port 5550
is opened and is in a Listen state by clustering after INETD is started. |
Table 2. Administrative domain checklist
for clusters
| Cluster resource services cluster
interface considerations |
| |
Install IBM PowerHA® SystemMirror® for i (iHASM licensed program (5770-HAS). A valid license key
must exist on all cluster nodes that will be in the high-availability
solution. |
| __ |
Install Option 41 (IBM i -
HA Switchable Resources). A valid license key must exist on
all cluster nodes that will be in the device domain. |
| __ |
Verify that all host servers are started by using the Start Host Server
(STRHOSTSVR) Command: STRHOSTSVR SERVER(*ALL) |
Table 3. Security configuration
checklist for clusters
| Security requirements |
| __ |
Set the Allow Add to Cluster (ALWADDCLU) network attribute
appropriately on the target node if you are trying to start a remote
node. This should be set to *ANY or *RQSAUT depending on your environment.
If this attribute is set to *RQSAUT, then IBM i option 34 (Digital Certificate
Manager) and the CCA Cryptographic Service Provider (Option 35) must
be installed. See Enable
a node to be added to a cluster for details on setting the
ALWADDCLU network attribute. |
| __ |
Enable the status of the user profile for INETD
specified in /QIBM/ProdData/OS400/INETD/inetd.conf. It must not have
*SECADM or *ALLOBJ special authorities. By default, QUSER is specified
as the user profile for INETD. |
| __ |
Verify that the user profile that calls the cluster resource
services APIs exists on all cluster nodes and has *IOSYSCFG authority. |
| __ |
Verify that the user profile to run the exit program for a
cluster resource group (CRG) exists on all recovery domain nodes. |
Table 4. Job configuration checklist for
clusters
| Job considerations |
| __ |
Jobs can be submitted by the cluster resource services APIs
to process requests. The jobs either run under the user profile to
run the exit program specified when creating a cluster resource group,
or under the user profile that requested the API (for varying on devices
in resilient device CRGs only). Ensure that the subsystem that services
the job queue associated with the user profile is configured as: *NOMAX
for the number of jobs it can run from that job queue. |
| __ |
Jobs are submitted to the job queue specified by the job description
that is obtained from the user profile defined for a CRG. The default
job description causes the jobs to be sent to the QBATCH job queue.
Because this job queue is used for many user jobs, the exit program
job might not run in a timely fashion. Consider a unique job description
with a unique user queue. |
| __ |
When exit program jobs are run, they use routing data from
the job description to choose which main storage pool and run time
attributes to use. The default values result in jobs that are run
in a pool with other batch jobs that have a run priority of 50. Neither
of these may produce the desired performance for exit program jobs.
The subsystem initiating the exit program jobs (the same subsystem
that is using the unique job queue) should assign the exit program
jobs to a pool that is not used by other jobs initiated by the same
subsystem or other subsystems. In addition, the exit program jobs
should be assigned a run priority of 15 so that they run before almost
all other user jobs. |
| __ |
Set the QMLTTHDACN system
value to 1 or 2. |
There are several software interfaces available
for configuring and managing your cluster. One of these interfaces
is PowerHA graphical
interface. If you choose to use PowerHA, the following requirements
must be satisfied.
Table 5. PowerHA configuration checklist
for clusters
| PowerHA graphical interface
considerations |
| __ |
Install IBM PowerHA SystemMirror for i licensed program.
A valid license key must exist on all cluster nodes that will be in
the high-availability solution. |
| __ |
Install Option 41 (HA Switchable
Resources). A valid license key must exist on all cluster nodes
that will be in the device domain. |
| __ |
Verify that all host servers are started by using the Start Host Server
(STRHOSTSVR) command: STRHOSTSVR SERVER(*ALL) |
| __ |
Verify that the Administration Server is started
by using the Start
TCP/IP Server (STRTCPSVR) command: STRTCPSVR SERVER(*HTTP)
HTTPSVR(*ADMIN) |
Table 6. Advanced node failure detection checklist for clusters
| Advanced node failure detection considerations when using a CIM
server or IVM |
| __ |
Determine which cluster nodes are or can be managed with a
Hardware Management Console (HMC) or a Virtual I/O Server (VIOS) partition on an Integrated
Virtualization Manager (IVM) managed server |
| __ |
Determine which cluster node(s) are to receive messages when some other cluster
node fails |
| __ |
On each cluster node that is to receive a message from an HMC or IVM, the
following things must be done. |
| |
Install base operating system option 33 - IBM Portable Application Solutions Environment for i |
| |
Install 5733-SC1 - IBM Portable Utilities for i |
| |
Install 5733-SC1 option 1 - OpenSSH, OpenSSL, zlib |
| |
Install 5770-UME - IBM Universal Manageability Enablement for i. |
| |
Configure the enableAuthentication and sslClientVerificationMode properties
for the 5770-UME product. |
| |
Copy a digital certificate file from the HMC or VIOS and add it to an
IBM i truststore. |
| |
Start the *CIMOM server with STRTCPSVR *CIMOM CL command |
| |
Configure the cluster monitor(s) with the ADDCLUMON CL command |
| Advanced node failure detection considerations when using a
REST server |
| __ |
Determine which cluster nodes are or can be managed with a
Hardware Management Console (HMC) REST server |
| __ |
Determine which cluster node(s) are to receive messages when some other cluster
node fails |
| __ |
On each cluster node that is to receive a message from an HMC, the following
things must be done. |
| |
Install base operating system option 3 - Extended Base Directory
Support. |
| |
Install base operating system option 33 - IBM Portable Application Solutions Environment for i |
| |
Install 5733-SC1 - IBM Portable Utilities for i (Only required for initial
configuration of a cluster monitor.) |
| |
Install 5733-SC1 option 1 - OpenSSH, OpenSSL, zlib (Only
required for initial configuration of a cluster monitor.) |
| |
Copy a digital certificate file from the HMC and add it to an IBM i truststore. |
| |
Configure the cluster monitor(s) with the ADDCLUMON CL command |