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 Deployment Manager, you can create static cluster to handle failover requests.

Prerequisites

Prepare the IBM i OS

Prepare the primary node on IBM i

Prepare the WAS Deployment Manager on IBM i

To create the cluster:

  1. If the Deployment Manager is configured to use a stand-alone LDAP user registry, update ...

      WP_PROFILE/ConfigEngine/properties/wkplc.properties
    on the primary node with the stand-alone LDAP user registry property values from the Deployment Manager. You can find these settings under the VMM Stand-alone LDAP configuration heading.

      Important: Ensure that you set WasUserid and WasPassword to the Deployment Manager user ID and password.

  2. Optional. nbsp;Run the following command from the WP_PROFILE/bin directory to federate the primary node:

      Attention: If you chose the option to automatically federate this new profile to a Deployment Manager as part of the profile creation, then this step is not necessary. If you are not sure, go ahead and run the addNode command as documented below. The task will fail if the node is already federated.

      addNode.sh dmgr_hostname dmgr_port -includeapps -includebuses
      			-username was_admin_user
      			-password was_foo

      The above variables are defined as:

      • dmgr_hostname is the TCP/IP host name of the Deployment Manager server

      • dmgr_port is the SOAP port number of the Deployment Manager server

      • was_admin_user and was_foo are the user ID and password for the Deployment Manager administrator

      If the WAS administrator user ID and password for the local node are different than the Deployment Manager administrator user ID and password, add the following parameters to the addNode task:

      • -localusername local_was_admin_user

      • -localpassword local_was_foo

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

      Warning: If the addNode task fails for any reason, perform the following steps before rerunning the task:

      1. Remove the node if the AddNode task succeeded in creating the node.

      2. Log on to the dmgr and perform the following steps if the items exist:

        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 ensure that the following parameters are set correctly in ...

      WP_PROFILE/ConfigEngine/properties/wkplc.properties

      Note: Although you can add these parameters directly to any task that you run while creating cluster, you may want to add them to the properties file while creating cluster and then remove them when you are finished to keep 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 Deployment Manager administrator user ID.

      4. Verify that WasPassword is set to Deployment Manager administrator password.

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

      6. Verify that ClusterName is set.

      7. Verify that PrimaryNode is set to true.

  4. Optional. nbsp;If you configured a database user registry or a property extension (lookaside) database on the Deployment Manager, run the following task to set up access to the database drivers:

      Note: You will also need to run this task if you migrated the primary node from a release prior to v6.1.0, even if you did not configure a database user registry or a property extension (lookaside) database.

      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.

      2. Add the library paths to the VMM_JDBC_CLASSPATH variable:

        1. Log on to the WAS 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/db2jcc.jar:SQLLIB/java/db2jcc_license_cu.jar.

        6. Copy the files that you entered in 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/DB/jars -DDmgrNodeName=dmgr_node_name task from the WP_PROFILE/ConfigEngine to create the local Deployment Manager WebSphere variable used to access the database jars.

          Note: The db_type in db_type.DmgrDbLibrary should be set to the type of database you are using, for example db2. The local path of the database jars on the Deployment Manager should be one of the following options:

            DB2 Type 2 driver: db2java.zip

            DB2 Type 4 driver: db2jcc.jar;db2jcc_license_cu.jar

            DB2 for z/OS Type 2 driver: db2java.zip

            DB2 for z/OS Type 4 driver: db2jcc.jar;db2jcc_license_cisuz.jar;db2jcc_javax.jar

            Oracle: ojdbc14.jar

            SQL Server JDBC driver provided by Microsoft: sqljdbc.jar

            SQL Server JDBC driver provided by DataDirect: sqlserver.jar;base.jar;util.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 task from the WP_PROFILE/ConfigEngine to create the variable used to access the VMM database jars.

          Note: VmmNodeName is a list of one or more WebSphere Portal 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 you 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

  6. Since the WebSphere Portal node is now using security settings from the Deployment Manager cell, you need to update the WebSphere Portal administrative user ID and password to match an administrative user defined in the cell's user registry. Run the ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=foo -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid from the WP_PROFILE/ConfigEngine, to update the WebSphere Portal administrative user ID if the Deployment Manager cell is using a different user registry.

      Attention: The password value for -DWasPassword is the Deployment Manager administrative password.

      Important: You must provide the full distinguished name (DN) for the newAdminId and newAdminGroupId parameters.

      Additional parameter for stopped servers: This task verifies the user against a running server instance. If the server is stopped, add the -Dskip.ldap.validation=true parameter to the task to skip the validation.

      Fastpath: 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 changes and run the ConfigEngine.bat wp-change-portal-admin-user -DWasPassword=dmgr_password task.

      Important: If standalone LDAP security is already enabled on the Deployment Manager cell, delay running the wp-change-portal-admin-user task until after the cluster-node-config-cluster-setup (static cluster) or cluster-node-config-dynamic-cluster-setup (dynamic cluster) task completes. After running the wp-change-portal-admin-user task, start or restart the WebSphere_Portal server to use the updated administrator user ID.

      Note: The WebSphere Portal administrative user ID and administrative group must exist in the Deployment Manager before running the wp-change-portal-admin-user task. -DnewAdminPw is an optional parameter to update the Administrative password in wkplc.properties if required.

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

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

  9. Add a new JCRSeedBus cluster bus member and remove the previous server bus member:

    1. Log on to the Deployment Manager Administrative Console.

    2. Navigate to Service Integration -> Buses and then click JCRSeedBus.

    3. Under the Topology heading, click Bus members.

    4. Click Add.

    5. Click the Cluster radio button to define the type of new bus member and then select the name of this newly created Portal cluster from the drop-down menu. Click Next to continue.

    6. Ensure that the Enable Messaging Engine Policy Assistance checkbox is checked. Then choose the required messaging engine policy setting; refer to Messaging engine policy assistance for information.

    7. Click Next.

    8. Select the Data store radio button and then click Next.

    9. Click the name of the first messaging engine listed in the table.

    10. Enter the following information on the Specify data store properties panel:

      Field Value
      Data source JNDI name jdbc/data_source_name, where data_source_name is the value for the jcr.DataSourceName property in wkplc_dbdomain.properties file located in the WP_PROFILE/ConfigEngine/properties directory of the primary node.
      Schema name Value of the jcr.DbSchema property in wkplc_dbdomain.properties.
      Authentication alias Choose the entry in the drop-down list whose name contains the JCR data source name.
        Table 1. Data store fields that need information.

    11. Ensure that the Create tables checkbox is checked and then click Next to continue.

    12. The Configure messaging engines panel displays containing the list of messaging engines. If any additional messaging engines are displayed, repeat the steps to configure each additional messaging engine in the table. Then click Next to continue.

    13. Review the heap sizes on the Tune performance parameters panel. Click Next to continue.

        Tip: To change the values, click the Change heap sizes checkbox and enter new values in the Proposed heap sizes text fields.

    14. The Summary panel displays, which allows you to review the messaging engine configuration changes. Click Previous if you need to go back and make additional changes or click Finish to complete the configuration process.

    15. Click Save to save the changes to the master configuration.

    16. The table of bus members displays. Select the Server bus member type with the name of the Portal server from the primary node and click Remove.

    17. Click OK to verify the removal of the server bus member.

    18. Navigate to Resources -> JMS -> Topic Connection Factories-> JCRSeedTCF.

    19. For the Durable Subscription Home property, select the new bus member you created from the drop-down menu; for example, PortalCluster.000-JCRSeedBus.

    20. Click OK to confirm the update to JCRSeedTCF.

    21. Click Save to save the changes to the master configuration.

    22. Synchronize changes to the primary node.

      • NOTE:  If you previously configured a data store type of bus member, you need to remove it first before you recreate it. Also, follow the instructions in this tech note - . The tech note explains how to clean up the tables. If you do not clean up the tables, the bus member does not properly start.

  10. Run the following tasks to propagate changes:

      Note: WebSphere_Portal_servername is the name of the node's WebSphere Portal server; but if you customized the server name, the default name changes. If you are uncertain of the server name, run the serverstatus -all task to get a list of the server names and their status.

      1. stopServer.sh WebSphere_Portal_servername -username admin_userid -password foo

      2. startServer.sh WebSphere_Portal_servername

Parent: Set up a cluster on IBM i


Previous

Prepare the WAS Deployment Manager on IBM i


Previous

Prepare the Web server when portal is installed on IBM i in a clustered environment

Related information

Delete passwords from properties files

February 7, 2012

  Added Hunter's steps back into step 9. 2011/12/15 documentation refresh Nov 4, 2011 10:33:20 AM Added additional steps to Step 9 for configuring the JCRSeedBus member


+

Search Tips   |   Advanced Search