Add an additional node to an existing dynamic cluster on Solaris

After creating dynamic cluster, you can add additional nodes to expand the capacity of the dynamic cluster. Install and configure the additional node, then add it to the existing dynamic cluster node group, and then add it to the existing IBMWebSphereVirtual Enterprise dynamic cluster.


Prerequisites

PK97393; 6.1.1: Utility to generate edition metadata

Add an additional node to an existing WebSphere Virtual Enterprise dynamic 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_HOMEfrom 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 /usr/IBM/WebSphere/PortalServer/profileTemplates/managed.portal
        			-profileName testManagedPortal1
        			-profilePath /usr/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 /usr/IBM/WebSphere/PortalServer/profileTemplates directory. The new profile is named testManagedPortal1 and is located under the /usr/IBM/WebSphere/PortalServer/profiles/testManagedPortal1 directory.

  3. Install WebSphere Virtual Enterprise and augment the newly created profile. See the "Planning the product installation" link in the Related information section for information about installing WebSphere Virtual Enterprise. Profile augmentation is performed using the Profile Management Tool (PMT) graphical interface on systems that support it or through the manageprofiles command that is available on all systems. When using the graphical interface as discussed in the link in the Related information section, make sure you select Operations Optimization when choosing the type of augmentation to perform. When using the manageprofiles command as discussed in the link in the Related information section, be sure to follow the instructions to augment a stand-alone application server profile.

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


    ./ConfigEngine.sh validate-database -DWasPassword=footo validate database settings.

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

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

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

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

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

    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

    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.

  9. Run the ./ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=dmgr_password

  10. Log on to the dmgr console.

  11. Add members to the node group:

    1. Click System administration -> Node groups.

    2. Click on the name of the node group that you want to add members to.

    3. Click Node group members under Additional Properties.

    4. Click Add.

    5. Select the additional node you want to add into the node group and then click Add.

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

  12. Define or verify the following parameters in ...

      WP_PROFILE/ConfigEngine/properties/wkplc.properties

    1. Verify that ClusterName is set to the name of the existing dynamic cluster.

    2. Verify that CellName is set to the dmgr cell.

    3. Verify that NodeName is set to the local WebSphere Portal node.

    4. Set ServerName to the server that will be used for the dynamic cluster member on this node.

        Log on to the dmgr console and click Servers -> Clusters -> Dynamic Clusters -> PortalCluster -> Dynamic cluster members to find the name of the server used for the dynamic cluster.

    5. Verify that PrimaryNode is set to false because this is an additional node.


    ./ConfigEngine.sh dynamic-cluster-setup-additional -DWasPassword=dmgr_password task to tune additional cluster resources.

  13. To start the cluster member:

    1. Log on to the Deployment Manager administrative console.

    2. Navigate to Servers -> Dynamic clusters -> cluster name -> Dynamic cluster members.

    3. Select the cluster member and click Start.

    4. Log off of the dmgr console.

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

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

  16. 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 Solaris


Related tasks

Recommended fixes for WebSphere Extended Deployment

Plan the product installation

Use the graphical user interface to augment profiles

Use the manageprofiles command to augment and unaugment profiles


Delete passwords from properties files

  Put italics around the word WAS_HOME in step 1 e.


+

Search Tips   |   Advanced Search