+

Search Tips   |   Advanced Search

Create the cluster on IBM i


After installing IBM WebSphere Portal on the primary node, configuring a remote database, and preparing the primary node to communicate with the dmgr, we can create the static cluster to handle failover requests.

To create the cluster:

  1. If the dmgr is configured to use a stand-alone LDAP user registry, update wkplc.properties, located in...

      WP_PROFILE/ConfigEngine/properties

    on the primary node with the stand-alone LDAP user registry property values from the dmgr. We can find these settings under the heading...

      VMM Standalone LDAP configuration

    Set WasUserid and WasPassword to the dmgr user ID and password.

  2. Run the following command from the WP_PROFILE/bin directory to federate the primary node: 
    addNode dmgr_hostname dmgr_port -includeapps
 -username wasadmin  -password foo

    The variables are defined as:

    • dmgr_hostname is the TCP/IP host name of the dmgr server

    • dmgr_port is the SOAP port number of the dmgr server

    • wasadmin and foo are the user ID and password for the dmgr administrator

    If the WAS administrator user ID and password for the local node are different from the dmgr, add the following parameters:

    • -localusername local_wasadmin
    • -localpassword local_foo

    See the addNode command file for more information about the addNode command and other optional parameters.

    If addNode.sh fails for any reason before rerunning the task:

    1. If federation succeeded, run removeNode.sh

    2. If items exist, log on to the dmgr and...

      1. Remove all enterprise applications.

      2. Remove the WebSphere_Portal server definition.

      3. Remove the WebSphere Portal JDBC Provider.

  3. Stop the WebSphere_Portal server on the primary node and verify the following parameters are set correctly in wkplc.properties:

    Although we can add these parameters (particularly passwords) directly to any task while creating the cluster, we might want to temporarily add them to the properties file. We can then remove them when we are finished to keep the environment secure.

    1. Set WasSoapPort to the port used to connect remotely to the dmgr.

    2. Set WasRemoteHostName to the full host name of the server used to remotely connect to the dmgr.

    3. Verify that WasUserid is set to the dmgr administrator user ID.

    4. Verify that WasPassword is set to the dmgr administrator password.

    5. Verify that PortalAdminPwd is set to the WebSphere Portal administrator password.

    6. Verify that ClusterName is set.

    7. Verify that PrimaryNode is set to true.

  4. If we configured a database user registry or a property extension database on the dmgr, set up access to the database drivers:

    1. Set the property value for federated.db.DbType if using a database user registry or set the property value for la.DbType if using a property extension database in wkplc.properties.

      If you migrated the primary node from a version prior to Version 6.1.0 and we are not using a database user registry or a property extension database, set the property value for federated.db.DbType to the same value that is in wkplc.properties on the primary node.

    2. To add the library paths to the VMM_JDBC_CLASSPATH variable:

      1. Log on to the WAS WAS admin console.

      2. Click Environment > WebSphere Variables.

      3. Select scope: cell.

      4. Select the VMM_JDBC_CLASSPATH variable. If this variable does not exist, click New to create the variable.

      5. Enter the complete paths to the library files in Value. Separate multiple files with a colon (:); for example, enter...

          SQLLIB/java/db2jcc4.jar:SQLLIB/java/db2jcc_license_cu.jar

      6. Copy files set for the VMM_JDBC_CLASSPATH variable into the appserver/lib directory.

      7. Stop and restart the appropriate servers to propagate the changes.

    3. Run the ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=foo -DDbDomain=la|federated.db -Ddb_type.NodeDbLibrary=/path/to/dmgr/jars -DDmgrNodeName=dmgr_node_name task from the WP_PROFILE\ConfigEngine to create the local dmgr WebSphere variable used to access the database jars.

      Set db_type to your database type, for example db2. The /path/to/db/jars should be one of the following options:

      • DB2 Type 2 driver: db2java.zip
      • DB2 Type 4 driver: db2jcc4.jar;db2jcc_license_cu.jar
      • DB2 for z/OS Type 2 driver: db2java.zip
      • DB2 for z/OS Type 4 driver: db2jcc4.jar;db2jcc_license_cisuz.jar
      • Oracle: ojdbc14.jar
      • SQL Server JDBC driver: sqljdbc.jar

    4. Run the ConfigEngine.sh wp-node-prep-vmm-db-secured-environment -DWasPassword=foo -DDbDomain=la|federated.db -DVmmNodeName=node_name -Ddb_type.NodeDbLibrary=/path/to/db/jars to create the variable used to access the VMM database jars.

      VmmNodeName is a list of one or more nodes names in the cell which share the same database driver paths. The db_type in db_type.NodeDbLibrary should be set to the type of database we are using, for example db2.

      • IBM DB2 for i Type 2 driver: /QIBM/ProdData/Java400/ext/db2_classes.jar
      • IBM DB2 for i Type 4 driver: /QIBM/ProdData/HTTP/Public/jt400/lib/jt400.jar

  5. Run the ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=dmgr_password task.

  6. The node is federated and using the dmgr cell and its user registry. If the admin user ID and group name are different in the WebSphere Portal and dmgr configurations, choose one of the following options depending on your security policies:

    • Add the existing admin user ID and group to the dmgr security configuration

    • To change the values in the WebSphere Portal configuration to match the dmgr values:

    If the dmgr cell is using a stand-alone LDAP user registry, complete these steps after the cluster-node-config-cluster-setup task completes.

    1. Start the WebSphere_Portal server.

    2. Verify the required WebSphere Portal admin user ID and group ID are defined in the dmgr user registry that provides security for the cell.

    3. Run...

        ./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=foo -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid

      If the value for newAdminGroupId contains a space; for example Software Group, open wkplc.properties and add the values for newAdminId, newAdminPw, and newAdminGroupId. Save the changes and then run the ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=dmgr_password task.

      • WasPassword is set to the administrative password for the dmgr cell
      • newAdminId is set to the fully qualified DN of the WebSphere Portal admin user ID in the cell
      • newAdminGroupId is set to the fully qualified DN of the group for the WebSphere Portal admin user ID in the cell

    4. After the task completes, stop the WebSphere_Portal server.

  7. Run the ConfigEngine.sh cluster-node-config-cluster-setup -DWasPassword=dmgr_password task.

  8. If you entered passwords in any of the properties files while creating the cluster, you should remove them for security purposes. See "Deleting passwords from properties files" under Related for information.


Parent: Set up a cluster on IBM i
Previous: Create and augment a new dmgr profile on IBM i
Next: Prepare the Web server when portal is installed on IBM i in a clustered environment
Related:
Delete passwords from properties files