+

Search Tips   |   Advanced Search

Add horizontal nodes to the static cluster on Solaris


After installing IBM WebSphere Portal for the horizontal cluster node, add the node to the cluster to create a highly available environment.


Add the horizontal cluster node to the cluster

  1. To create a directory to store templates:

    1. Copy...

        PORTAL_HOME/profileTemplates/profileTemplates.zip

      ...on the primary node to the same location on the additional cluster node.

    2. Extract the profileTemplates.zip file in the same location. If any of the templates already exist in the profileTemplates directory, overwrite them.

    3. Because some files are set to read-only after the copy operation, open permissions...

        chmod -R 755 PORTAL_HOME/profileTemplates

    4. To install the copied profile template...

        cd PORTAL_HOME/profileTemplates
        ./installPortalTemplates.sh

      This task localizes the profile templates to the current environment and registers them with the pmt.sh if it exists on the server.

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

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

    Choose a Node Name that is different from what you entered for the primary node.

    Option Steps
    pmt.sh

    1. Run...

        cd WAS_HOME/bin/ProfileManagement
        ./pmt.sh

    2. Click Launch Profile Management Tool

    3. Click Create to create a profile.

    4. On the Environment Selection panel, select the...

        WebSphere Portal 8.0.0 | Custom Portal profile

    5. Select the button...

        Advanced profile creation

    6. On the panel...

        Profile Name and Location

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

        Node and Host Names

      ...provide the node name and TCP/IP host name for the new profile.

      To federate this profile, the node name must be unique from other profiles in the same management cell (under dmgr control). The host name must be 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 panel...

        Profile Creation Summary

      ...review the information collected by the wizard, and then click Create to create the profile with WebSphere Portal.

    10. Click Finish to exit PMT.
    manageprofiles.sh cd WAS_HOME/bin 
    ./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

    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 that the 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.

      The wkplc_dbdomain.properties and wkplc_dbtype.properties files should match the database information defined in the primary node.

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

  4. Validate the database settings...

      ./ConfigEngine.sh validate-database -DWasPassword=foo

    Add -DTransferDomainList to the validate-database task to specify the domains to validate; for example...

      -DTransferDomainList=jcr

    To validate all domains, you do not need to specify this parameter on the command line.

  5. Edit...

      WP_PROFILE/PortalServer/jcr/lib/com/ibm/icm/icm.properties

    ...and set...

      jcr.textsearch.enabled = false

  6. Federate the additional cluster node: 
    ./addNode.sh dmgr_hostname dmgr_port  -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.

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

    2. Verify that WasPassword is set to the 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 we can change this on the additional nodes.

    6. Verify that PrimaryNode is set to false.

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

  8. 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. Create the local dmgr WebSphere variable used to access the database jars...

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

      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. Create the variable used to access the VMM database jars...

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

      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.

  9. 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-additional (static cluster) or cluster-node-config-dynamic-cluster-setup-additional (dynamic cluster) 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...

        ./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=dmgr_password

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

  10. Add the node to your cluster...

      ./ConfigEngine.sh cluster-node-config-cluster-setup-additional -DWasPassword=dmgr_password

  11. If the profile templates were copied from a server with a different profile directory:

    1. Log on to the dmgr integrative console.

    2. Go to Servers > Server Types > Application servers.

    3. Select the additional cluster member server.

    4. Go to Java and Process Management > Process definition > Environment Entries.

    5. Delete the following environment entries:

      • LD_LIBRARY_PATH
      • LIBPATH
      • PATH
      • SHLIB_PATH

    6. cd WP_PROFILE/ConfigEngine

    7. Update these entries with the correct profile paths...

        ./ConfigEngine.sh profile-update-entries

  12. To prevent Out of Memory errors to set the MaxPermSize:

    If Maximum Heap Size is set to 2048 M or higher, set the MaxPermSize to a quarter of the value entered for the Maximum Heap Size; for example, if the Maximum Heap Size is 3000 M, set MaxPermSize to 750 M. If the Maximum Heap Size is less than 2048 M, set MaxPermSize to 512 M.

    1. Log in to the WAS admin console.

    2. Go to Servers > Server Types > WebSphere appservers > WebSphere_Portal.

    3. Under Server Infrastructure, click Java and Process Management > Process Definitions > Additional Properties > Java Virtual Machine.

    4. In the Generic JVM arguments field, change the MaxPermSize value to -XX:MaxPermSize=numeric value, where numeric value is a quarter of the value entered for the Maximum Heap Size.

      If MaxPermSize does not exist in the Generic JVM arguments field, add it to the field but do not replace existing information in the Generic JVM arguments field with the MaxPermSize information.

    5. Click OK to save the changes.

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

    7. Log out of the WAS admin console.

    8. Restart the WebSphere_Portal server.

  13. To access the WCM 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 option...

        Node=nodename, Server=servername

      ...where Node=nodename is the node containing the portal application server.

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

    5. Update the WCM_PORT variable with the port number used to access the portal server through the web server or On Demand Router.

    6. Update the WCM_HOST and WCM_PORT variable for each additional portal server that already exists in the cluster.

    7. Synchronize the node with the dmgr:

      1. Select System Administration > Nodes.

      2. Select the node to synchronize from the list.

      3. Click Full Resynchronize.

    8. Log off of the dmgr console.

  14. Propagate changes:

    WebSphere_Portal is the name of the node's WebSphere Portal server; but if you customized the server name, the default name changes. If we are uncertain of the server name, run the task...

      serverstatus -all

    ...to get a list of the server names and their status.

      ./stopServer.sh WebSphere_Portal -username wpadmin -password foo

      ./startServer.sh WebSphere_Portal

  15. 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: Choose the type of horizontal cluster to create on Solaris
Related:
Delete passwords from properties files