Pre-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 tools and products require unique settings on each node and require actions to be performed prior to the clone in order to change configuration settings or save data.

The steps to perform pre-clone configuration must be done before beginning the Db2 Mirror cloning process. Many of these products and tools also require additional steps after cloning. See post-clone configuration for those details.

The following products and tools may require pre-clone configuration:

  • Digital Certificate Manager (DCM)
  • Dynamic Host Configuration Protocol (DHCP)
  • IBM Cloud Storage Solutions for i (ICC)
  • Lightweight Directory Access Protocol (LDAP)
  • OptiConnect
  • System Distribution Directory (SDD) entries

Digital Certificate Manager (DCM)

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

There are two options for generating digital certificates for the setup copy node:

  1. Pre-clone: A multi-domain certificate using the Subject Alternative Name (SAN) field lets you specify multiple domain names to be protected in a single certificate. Using a multi-domain certificate 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.
    1. Open the DCM GUI for the setup source node and generate a Certificate Signing Request (CSR) using the steps provided in Managing public Internet certificates for SSL/TLS communications sessions.
    2. Use the CSR text from the DCM GUI when creating a multi-domain certificate from a well known Internet Certificate Authority (CA), such as the DigiCert Secure Site Multi-Domain Certificate (www.digicert.com/secure-site-ssl/multi-domain-ssl).
    3. When creating the multi-domain certificate, specify each domain name for the setup source and copy nodes.
      Figure 1. Creation of multi-domain certificate
      Creation of multi-domain certificate
    4. Import the multi-domain certificate using the steps provided in Managing public Internet certificates for SSL/TLS communications sessions.
    Multi-domain certificates will work on the setup copy node after the clone. No additional post-clone steps are required.
  2. Post-clone: Generate new certificates for the setup copy node after the clone is complete. See post-clone configuration for the details.

Dynamic Host Configuration Protocol (DHCP)

If the DHCP server is enabled to automatically start when TCP/IP starts, this setting should be disabled before a Db2 Mirror clone.

Prior to starting the Db2 Mirror clone process, run the following command on the setup source node: 
CHGDHCPA AUTOSTART(*NO)

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. See post-clone configuration for more information.

IBM Cloud Storage Solutions for i (ICC)

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

Lightweight Directory Access Protocol (LDAP)

If the LDAP server is enabled to automatically start when TCP/IP starts, this setting should be disabled before a Db2 Mirror clone.

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.

Prior to starting the Db2 Mirror clone process, perform the following steps on the setup source node:

  1. Disable the LDAP server from automatically starting when TCP/IP starts.

    Run the following command on the setup source node: 
    CHGTCPSVR SVRSPCVAL(*DIRSRV) SVRNAME(*ALL) AUTOSTART(*NO)

  2. Disable Db2 Mirror replication of LDAP data.

    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 the libraries are in an IASP, specify the correct IASP name for the IASP_NAME parameter on the QSYS2.ADD_REPLICATION_CRITERIA SQL statement. To determine which ASP contains the libraries, find the ibm-slapdDbName attribute in the file /QIBM/UserData/OS400/DirSrv/idsslapd-XXX/etc/ibmslapd.conf. Replace XXX in the path with the LDAP instance name.

    If default library names were not used when creating the LDAP instance, you can find the library names in the file /QIBM/UserData/OS400/DirSrv/idsslapd-XXX/etc/ibmslapd.conf. Replace XXX in the path with the LDAP instance name. Find the ibm-slapdDbInstance attribute to find the names of the user database library and change log library. Both the user database and change log libraries will be specified for the ibm-slapdDbInstance attribute. For example, 
    ibm-slapdDbInstance: /QSYS.LIB/QUSRDIRDB.LIB

See post-clone configuration for instructions to follow after cloning.

OptiConnect

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

It is recommended that any advanced program-to-program communications (APPC) controllers of type *HPRIP be created with local internet address value *SYS. This avoids having to update the local internet address for the controller on the setup copy node after cloning.

See post-clone configuration for the steps to perform after cloning.

System Distribution Directory (SDD) entries

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

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.