Add additional nodes to the static cluster on Linux

After installing WebSphere Portal on additional cluster node, add the node to the cluster to create a highly available environment.

Add the additional cluster node to the cluster:

  1. Create a directory to store templates:

    1. Create a directory called profileTemplates under the $PORTAL_HOME directory.

    2. Copy the profileTemplates.zip file from the $PORTAL_HOME/profileTemplates directory on the primary node to the same location on the additional cluster node.

    3. Unzip the profileTemplates.zip file in the same location.

    4. Run the chmod -R 755 $PORTAL_HOME/profileTemplates}}} task to change the permissions of the files/dirs subdirectory, located in the $PORTAL_HOME/profileTemplates directory, because some files are set to read-only after the copy operation.

    5. Run the ./installPortalTemplates.sh WAS_HOME task from the newly created profileTemplates directory to install the copied profile template. This task localizes the profile templates to the current environment and registers them with the Profile Management Tool if it exists on server.

  2. Choose one of the following methods to create a new profile that will be used for additional cluster members:

      If you have a 64-bit environment, only the manageprofiles command is supported when creating profiles.

      Option Steps
      Profile Management Tool To use the Profile Management Tool:

      1. Run the ./pmt.sh command from the WAS_HOME/bin/ProfileManagement directory.

      2. Click Launch Profile Management Tool.

      3. Click Create to create a new profile.

      4. On the Environment Selection panel, select the WebSphere Portal 7.0.0 -> Custom Portal profile, and then click Next.

      5. Select the Advanced profile creation radio button and then click Next.

      6. On the Profile Name and Location panel, provide the name for the new profile and its location in the file system. The name and location must be unique from other existing profiles. Click Next to continue.

      7. On the Node and Host Names panel, provide the node name and TCP/IP host name for the new profile. If you plan to federate this profile, the node name must be unique from other profiles in the same management cell (under Deployment Manager control). The host name must be a valid and reachable over the network. Click Next to continue.

      8. On the Federation panel check the Federate this node later check box to federate the node in the future.

          CAUTION: Do not enter the values for the Dmgr to federate now as this will cause an unusable portal node.

      9. On the Security Certificate (Part 1) panel, do not modify the default values because the security settings are imported from the Portal configuration archive when the profile is created. Click Next to continue.

      10. On the Security Certificate (Part 2) panel, do not modify the default values because the security settings are imported from the Portal configuration archive when the profile is created. Click Next to continue.

      11. If you choose to federate the profile now, the Port Values Assignment panel displays. Change any necessary port values and then click Next.

      12. On the Profile Creation Summary panel, review the information collected by the wizard, and then click Create to create the new profile with WebSphere Portal.

      13. Click Finish to exit PMT.

      manageprofiles command Run the following command from the WAS_HOME/bin directory:

        manageprofiles.sh -create -templatePath /opt/IBM/WebSphere/PortalServer/profileTemplates/managed.portal
        			-profileName testManagedPortal1
        			-profilePath /opt/IBM/WebSphere/PortalServer/profiles/testManagedPortal1
        			-cellName testCell
        			-nodeName testNode
        			-hostName myportal.myco.com

      If you have a long command, use the continuation character "/" to avoid seeing the "not found" error message.

      In this example, the profile template is installed under the /opt/IBM/WebSphere/PortalServer/profileTemplates directory. The new profile is named testManagedPortal1 and is located under the /opt/IBM/WebSphere/PortalServer/profiles/testManagedPortal1 directory.

  3. To ensure database information is correct and to ensure a successful additional node:

    1. Ensure that the wkplc_dbdomain.properties and wkplc_dbtype.properties files have the correct database information in them.

    2. Copy the database drivers on the primary node to the same location on the additional cluster node. You can find the location of database drivers in wkplc_dbtype.properties file.

  4. Run the ./ConfigEngine.sh validate-database -DWasPassword=foo task to validate database settings.

      Add -DTransferDomainList to specify the domains to validate; for example: -DTransferDomainList=jcr.

  5. Open the icm.properties file, located in the WP_PROFILE/PortalServer/jcr/lib/com/ibm/icm/ directory, and set the jcr.textsearch.enabled property to false.

  6. Run the following command from the WP_PROFILE/bin directory to federate the additional cluster node:

      addNode.sh dmgr_hostname dmgr_port
      	-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

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

  7. Ensure that the following parameters are set correctly in wkplc.properties, located in the WP_PROFILE/ConfigEngine/properties directory of the additional cluster node:

      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. Verify that WasUserid is set to dmgr administrator ID.

      2. Verify that WasPassword is set to dmgr administrator password.

      3. Verify that WasRemoteHostName is set to the fully qualified host name of the dmgr.

      4. Verify that WasSoapPort is set to the SOAP port that the dmgr is using; the default value is 8879.

      5. Verify that ServerName is set to the correct server name. The default is WebSphere_Portal but you can change this on additional nodes.

      6. Verify that PrimaryNode is set to false.

      7. Verify that ClusterName is set to the primary node's ClusterName.

  8. Optional. 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:

      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.

          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:

            DB2Type 2 driver: db2java.zip
            DB2 Type 4 driver: db2jcc.jar;db2jcc_license_cu.jar
            DB2 for z/OSType 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=dmgr_password -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.

          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.

  9. 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 task, from the WP_PROFILE/ConfigEngine, to update the WebSphere Portal administrative user ID if the Deployment Manager cell is using a different user registry.

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

    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.

    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.


    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.

  10. Run the ./ConfigEngine.sh cluster-node-config-cluster-setup-additional -DWasPassword=dmgr_password task to add the node to cluster.

  11. Access the Web Content Manager content through an external Web server:

    1. Log on to the dmgr console.

    2. Select Environment -> WebSphere Variables.

    3. From the Scope drop-down menu, select the Node=nodename, Server=servername option to narrow the scope of the listed variables, where Node=nodename is the node that contains the application server.

    4. Update the WCM_HOST variable with the fully qualified host name used to access the WebSphere Portal server through the Web server or On Demand Router.

    5. Update the WCM_PORT variable with the port number used to access the WebSphere Portal server through the Web server or On Demand Router.

    6. To synchronize the node with the dmgr:

      1. Select System Administration -> Nodes.

      2. Select the node that you want to synchronize from the list.

      3. Click Full Resynchronize.

    7. Log off of the dmgr console.

  12. Run the following tasks to propagate changes:

      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

  13. 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.


Parent

Choose the type of additional node to create on Linux


Delete passwords from properties files

  Mar 8, 2011 11:32:12 AM Removed the out of memory step (11) because the information only perta... Put italics around the word WAS_HOME in step 1 d.


+

Search Tips   |   Advanced Search