Post-clone configuration

The process of Db2® Mirror cloning uses a copy of the setup source node to create the setup copy node. Some IBM® i products and tools require unique settings on each node and require actions to be performed on the secondary node after the clone is complete.

The post-clone configuration steps must be performed after the Db2 Mirror cloning process is complete. Because this section describes actions to perform after cloning, the setup source node and setup copy node are referred to as the primary node and secondary node, respectively.

The following products and tools require post-clone configuration:
  • Common Information Model (CIM)
  • Digital Certificate Manager (DCM)
  • Domain Name System (DNS)
  • Dynamic Host Configuration Protocol (DHCP)
  • Electronic Service Agent (ESA)
  • IBM Cloud Storage Solutions for i (ICC)
  • Kerberos
  • Lightweight Directory Access Protocol (LDAP)
  • Management Central (MC)
  • NetServer
  • Network File System (NFS) Netgroup
  • OpenSSH Server (SSHD)
  • OptiConnect
  • QFileSvr.400 and IBM i NetClient file system (QNTC)
  • Remote journals
  • Simple Mail Transfer Protocol (SMTP)
  • System Distribution Directory (SDD) entries
  • WebSphere® Application Server (WAS)
Note: There may be host names or IP addresses stored in configuration files, policies, preferences, settings, or other objects (configured sessions, database connections, database requests, saved commands, etc.) for products or tools that are not listed above. You may need to manually change these attributes on the secondary node after cloning.

The post-clone configuration for some products and tools is performed automatically by Administration Runtime Expert (ARE) plug-ins. See Custom plugins for Db2 Mirror using IBM Administration Runtime Expert for i for more information. Other products and tools require you to manually perform the post-clone configuration steps.

Some of these products and tools also require you to perform steps before cloning. See pre-clone configuration for those details.

Note: The system defaults from the primary node before the clone will be copied to the secondary node during the Db2 Mirror cloning process. If you want different system defaults on the secondary node after cloning, you will need to perform manual steps to set them as desired.

Common Information Model (CIM)

After cloning, CIM subscriptions on the secondary node need to be manually deleted and recreated.

For additional information about the cimsub command, see cimsub usage information.

Perform the following steps on the secondary node:
  1. Start PASE by running the following command:
    CALL QP2TERM
  2. List all the CIM subscriptions by running the following command:
    cimsub -ls
  3. Run the following command for each CIM subscription to delete it: 
    cimsub -ra
  4. Run the following commands for each CIM subscription you want to create:
    cimsub -cf
cimsub -ch
cimsub -cs

Digital Certificate Manager (DCM)

A digital certificate assigned to an application that was defined only for the primary node will not work on the secondary node after cloning.

There are two options for generating digital certificates for the secondary node:
  1. Pre-clone: Use multi-domain certificates. This allows you to create the certificate before the clone so that both nodes in the Db2 Mirror pair can use the certificate after the clone is complete. See pre-clone configuration for more details.
  2. Post-clone: Generate new certificates for the secondary node after the clone is complete. Perform the following steps in the DCM GUI on the secondary node:
    1. Click Select a Certificate Store and choose to open the *SYSTEM certificate store.
    2. Click Create Certificate and choose to create a new server or client certificate. Specify the secondary node in the common name field.
    3. After the certificate is successfully created for the secondary node, select the applications that will use the new certificate and click Replace to have the application use the new certificate.
    4. Depending on the application using the certificate, the server application may need to be stopped and restarted for the new certificate to be used.

Domain Name System (DNS)

After cloning, DNS server instances will fail to start on the secondary node if they are still configured to use the IP address and host name of the primary node.

To run a DNS server instance on the secondary node after a clone, the listen-on IP address and host name settings must be changed to be the IP address and host name of the secondary node. This can be done using the IBM Navigator for i web-based console. Open Network-> Servers-> DNS Servers.

The post-clone configuration for DNS server instances can be completed by an ARE plug-in. The plug-in will automatically replace the IP address and/or host name of the primary node with the corresponding IP address and/or host name of the secondary node after cloning.

Dynamic Host Configuration Protocol (DHCP)

After cloning, the DHCP server configuration on the Db2 Mirror nodes will have overlapping IP address ranges and this can result in address conflicts if both DHCP servers are running at the same time.

After the clone, the DHCP server should only run on one node at a time. If you want to have the DHCP server running on both nodes simultaneously, configure the DHCP server on the primary and secondary nodes so the IP address pool ranges do not overlap.

Starting the DHCP server automatically when TCP/IP starts should have been disabled before cloning. See pre-clone configuration for those details. You may re-enable this setting after the Db2 Mirror clone is complete.

IBM Cloud Storage Solutions for i (ICC)

ICC requires a valid digital certificate on the secondary node. Perform the DCM pre-clone or post-clone steps.

Electronic Service Agent (ESA)

After cloning, ESA configuration needs to be reset on the secondary node.

An ARE plug-in will automatically run the following commands on the secondary node after the Db2 Mirror clone is complete:

DLTDTAARA DTAARA(QSRVAGT/QS*) 

CLRPFM FILE(QUSRSYS/QAEDCDBPF)

Kerberos

If Kerberos is used on the primary node and you want to also use it on the secondary node, you will need to manually configure Kerberos on the secondary node after cloning. Kerberos configuration or keytab files contain information unique to the node they were configured on. These need to be re-configured on the secondary node after cloning.

Lightweight Directory Access Protocol (LDAP)

Db2 Mirror cannot be used as a high availability solution for LDAP because the Db2 Mirror environment cannot replicate all of the LDAP data. However, LDAP peer replication can be used to obtain high availability functions similar to those provided by Db2 Mirror. For more information about LDAP peer replication, see Creating a complex topology with peer replication.

Perform the following actions on the secondary node after the clone is complete:

  1. Delete all the LDAP instances on the secondary node that were cloned from the primary node.

    For information on managing LDAP instances, see Managing instances.

  2. Disable Db2 Mirror replication of LDAP data before creating new LDAP instances.

    All LDAP libraries should be excluded from replication by adding EXCLUDE rules to the Replication Criteria List (RCL).

    The following SQL statement can be used to exclude a library from Db2 Mirror replication:
    CALL QSYS2.ADD_REPLICATION_CRITERIA(INCLUSION_STATE => 'EXCLUDE', 
                                    IASP_NAME => '*SYSBAS', 
                                    LIBRARY_NAME => 'XXX')
    There may be two or three libraries for an LDAP instance. The default naming convention for LDAP libraries is:
    • Configuration library: Instance name followed by CF. For example, an LDAP instance named QUSRDIR will have library QUSRDIRCF.
    • User database library: Instance name followed by DB. For example, an LDAP instance named QUSRDIR will have library QUSRDIRDB.
    • Change log library: Instance name followed by CL. For example, an LDAP instance named QUSRDIR will have library QUSRDIRCL. The change log library will only exist when the change log is enabled.

    By default, the libraries for an LDAP instance are created in SYSBAS. However, they can be created in an independent auxiliary storage pool (IASP). If you plan to create the libraries in an IASP, specify the correct IASP name for the IASP_NAME parameter on the QSYS2.ADD_REPLICATION_CRITERIA SQL statement.

  3. Create new LDAP instances.

    For information on managing LDAP instances, see Managing instances.

Starting the LDAP server automatically when TCP/IP starts should have been disabled before cloning. You may re-enable this setting after the Db2 Mirror clone is complete. See pre-clone configuration for the complete list of LDAP configuration steps that must be performed before cloning.

Management Central (MC)

After cloning, the Management Central server needs to be ended and restarted on the secondary node.

An ARE plug-in will automatically run the following commands on the secondary node after the Db2 Mirror clone is complete:
ENDTCPSVR SERVER(*MGTC)

STRTCPSVR SERVER(*MGTC)

NetServer

If a NetServer name is assigned, it cannot be the same on both nodes. For NetServer to be started on both nodes, one of the NetServer names must be changed. For this reason, the NetServer name is automatically updated on the secondary node during the Db2 Mirror cloning process. No manual action is required, but you should be aware that the NetServer name change will occur on the secondary node.

Network File System (NFS) Netgroup

After cloning, the NFS netgroup list may need to be updated on the secondary node. If the local system name is included in the NFS netgroup list, you must update the ROOT-LIST with the system name of the secondary node before NFS will work correctly on the secondary node.

If you are not sure if this applies to you, check the human-readable stream file at /etc/netgroup. If the file does not exist, then no netgroups have been defined and no action is needed.

OpenSSH Server (SSHD)

The SSHD host keys on the secondary node must be updated after a Db2 Mirror clone.

Perform the following steps on the secondary node:
  1. Start PASE by running the following command:
    CALL QP2TERM
  2. Remove the existing keys by running the following commands:
    cd /QOpenSys/QIBM/UserData/SC1/OpenSSH/etc

rm ssh_host_dsa_key ssh_host_ecdsa_key ssh_host_ed25519_key ssh_host_key 
  ssh_host_rsa_key ssh_host_dsa_key.pub ssh_host_ecdsa_key.pub ssh_host_ed25519_key.pub 
  ssh_host_key.pub ssh_host_rsa_key.pub
  3. Start the SSH daemon. This step will create new keys:
    STRTCPSVR SERVER(*SSHD)

OptiConnect

To use OptiConnect on the secondary node, you must enable Virtual OptiConnect on the Hardware Management Console (HMC) for the secondary node. The Db2 Mirror cloning process does not copy this HMC setting.

After cloning, advanced program-to-program communications (APPC) controllers must be manually changed on the secondary node:
  • For APPC controllers of type *HPRIP:
    • If the local internet address is not *SYS, you must change the local internet address for the controller on the secondary node to be the IP address of the secondary node:
      CHGCTLAPPC CTLD(controller-name) LCLINTNETA(secondary-node-IP-address)
    • If the controller will be used to communicate between the Db2 Mirror nodes and the primary and secondary nodes use the same network identifier, you must change the remote internet address and remote control point for the controller on the secondary node:
      CHGCTLAPPC CTLD(controller-name) RMTINTNETA(primary-node-IP-address)
  RMTCPNAME(secondary-node-control-point)
    • If the controller will be used to communicate between the Db2 Mirror nodes and the primary and secondary nodes use different network identifiers, you must change the remote internet address, remote network identifier, and remote control point for the controller on the secondary node:
      CHGCTLAPPC CTLD(controller-name) RMTINTNETA(primary-node-IP-address)   
  RMTNETID(primary-node-network-identifier) RMTCPNAME(primary-node-control-point)
  • For APPC controllers of type *OPC:
    • All devices that are attached to *OPC controllers must be deleted and recreated on the secondary node. Location names cannot be updated for existing devices.
    • Any TCP interfaces for *OPC line descriptions must be manually added on the secondary node. These interfaces are used for TCP over OptiConnect.

QFileSvr.400 and IBM i NetClient file system (QNTC)

IBM i file server file system (QFileSvr.400) and QNTC can be used to access data on another server. After cloning, verify that the QFileSvr.400 or QNTC settings are correct on the secondary node. If the primary node was configured to connect to the secondary node before the clone, the secondary node will point to itself after the clone. This must be manually fixed on the secondary node after the clone.

Remote journals

After cloning, any remote journals that exist on the secondary node are not usable and should be deleted. To find and delete all remote journals, the following SQL procedure can be run:
CALL SYSIBMADM.DELETE_REMOTE_JOURNALS();

Simple Mail Transfer Protocol (SMTP)

The secondary node can serve as an SMTP server after cloning. The SMTP configuration settings of the primary node will be copied to the secondary node during the Db2 Mirror cloning process.

After cloning, check the SMTP server configuration on the secondary node. For an SMTP server for directory type *SMTP, make sure the SMTP users are properly configured. For an SMTP server for directory type *SDD, make sure the system distribution directory (SDD) entries are properly configured.

System Distribution Directory (SDD) entries

The SDD entries from the primary node are copied to the secondary node during the Db2 Mirror cloning process. The SDD entries on the secondary node may need to be fixed after the clone.

When performing a Db2 Mirror reclone, you can save the SDD entries on the setup copy node before cloning so they can be restored after cloning. For more information about the reclone process, see Reclone process. See the Importing System Distribution Directory Entries technote that explains how to restore SDD entries from a physical file: https://www-01.ibm.com/support/docview.wss?uid=nas8N1015151.

Websphere Application Server (WAS)

Perform the following steps after cloning to update the host name for WAS on the secondary node:
  1. Launch the wsadmin tool
    wsadmin -lang jython
  2. List the contents of the server configuration file
    AdminConfig.list('ServerIndex')
  3. In the output, find the ServerIndex object for the application server node
    cells/isthmusCell16/nodes/isthmusNode06|serverindex.xml#ServerIndex_1
  4. Modify the host name for the application server node
    AdminConfig.modify('(cells/isthmusCell16/nodes/isthmusNode06|serverindex.xml#ServerIndex_1)', 
   "[[hostName new_host_name]]")
  5. Save the configuration
    AdminConfig.save()
  6. Stop webadmin
    ENDTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)
  7. Wait for all admin jobs to stop
    WRKACTJOB SBS(QHTTPSVR)
  8. Restart webadmin
    STRTCPSVR SERVER(*HTTP HTTPSVR(*ADMIN)

Administration Runtime Expert (ARE) plug-ins

ARE plug-ins can be used during the reclone process to save and restore values for the setup copy node for your products or applications.

For details about creating ARE plug-ins, see Custom plugins for Db2 Mirror using IBM Administration Runtime Expert for i.

For more information about the reclone process, see Reclone process.