Add an additional node to an existing dynamic cluster

 

+

Search Tips   |   Advanced Search

 

After creating your dynamic cluster, you can add additional nodes to expand the capacity of the dynamic cluster. Configure the additional node, then add it to the existing dynamic cluster node group, and then add it to the existing WebSphere Virtual Enterprise dynamic cluster.

On all WebSphere Portal nodes, install WebSphere Virtual Enterprise and augment the wp_profile profile. See Installing and configuring the product for information about installing WebSphere Virtual Enterprise.

See Augmenting profiles for information about augmenting the Deployment Manager and wp_profile profiles.


Prerequisites

PK97393 for all WAS Versions prior to 6.1.0.5

Installing and configuring the product:

Augmenting profiles

Add an additional node to an existing WebSphere Virtual Enterprise dynamic cluster:

  1. Perform the following steps on the secondary node to access your database server:

    All properties files are located in...

      profile_root/ConfigEngine/properties

    1. For JDBC Type 2 connections only, ensure that the database client software is installed on the secondary node using the same settings as the primary node and that you can connect to the remote database.

      It is not necessary to create databases or users when configuring secondary nodes.

      DB2 users: When using DB2, catalog the TCP/IP node and all databases used on each secondary node. For more information refer to Preparing DB2.

    2. For JDBC Type 4 connections only, copy the JDBC Type 4 jar files to the secondary node from the DB2 server.

    3. Set all database properties in the wkplc_dbtype.properties and wkplc_comp.properties files with the appropriate values from the primary node.

  2. Validate your database settings:

    1. ./ConfigEngine.sh validate-database-driver -DTransferDomainList=release,customization,community,jcr,feedback,likeminds -DWasPassword=password

    2. ./ConfigEngine.sh validate-database-connection -DWasPassword=password -DTransferDomainList=release,customization,community,jcr,feedback,likeminds

  3. Stop the server1 and WebSphere_Portal servers on the secondary node and ensure that the following parameters are set correctly in

      profile_root/ConfigEngine/properties/wkplc.properties

    of the secondary node:

    WasUserid Deployment manager administrator ID.
    WasPassword Deployment manager administrator password.
    PortalAdminId WebSphere Portal administrator ID.
    PortalAdminPwd WebSphere Portal password.
    WasRemoteHostName Fully qualified host name of the deployment manager.
    WasSoapPort SOAP port that the deployment manager is using; the default value is 8879.
    PrimaryNode False
    ClusterName Primary node's ClusterName.

  4. Run...

      ./ConfigEngine.sh cluster-node-config-pre-federation -DWasPassword=dmgr_password

    ...from...

      profile_root/ConfigEngine

    ...of the secondary node.

  5. Optional: If you configured a database user registry or a property extension database, 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 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.

      If you migrated the primary node from a version prior to v6.1.0 and you 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. Run...

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

      ...to create the variable used to access the VMM database jars.

      Where DbDomain is either la or federated.db depending on whether you are using a property extension database (la) or a database user registry (federated.db). 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.

      The /path/to/DB/jars should be one of the following options:

      DB2 Type 4 driver db2jcc.jar:db2jcc_license_cu.jar
      DB2 for z/OS Type 4 driver db2jcc_license_cisuz.jar;db2jcc_javax.jar
      Oracle 10g Type 4 driver ojdbc14.jar
      Oracle 11g Type 4 driver (WAS V6.1) ojdbc5.jar
      Oracle 11g Type 4 driver (WAS V7) ojdbc6.jar
      SQL Server JDBC driver provided by Microsoft sqljdbc.jar
      SQL Server JDBC driver provided by DataDirect sqlserver.jar;base.jar;util.jar

  6. Run...

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

    To customize the WebSphere Portal server name (WebSphere_Portal) for your additional node, set the ServerName parameter in wkplc.properties after running the cluster-node-config-post-federation task.

  7. Since the WebSphere Portal node is now using security settings from the Deployment Manager cell, update the WebSphere Portal administrative user ID and password to match an administrative user defined in the cell's user registry. Run...

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

    ...from...

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

    Provide the full distinguished name for the newAdminId and newAdminGroupId parameters.

    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.

    Fast path: 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...

      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.

  8. Log on to the deployment manager administrative console.

  9. To 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 your changes to the master configuration.

  10. Wait at least 30 minutes before stopping and restarting the deployment manager because the node agent runs a background thread to expand all EAR files into their target directories.

    Attempting to restart the deployment manager while the expansion is in process can result in an unusable application. Although the time to complete an EAR expansion is environment-dependent, a 30 minute wait is sufficient for a typical environment.

  11. Define or verify the following parameters in wkplc.properties, located in...

      profile_root/ConfigEngine/properties

    1. Set ClusterName to the name of the existing dynamic cluster.

    2. Verify that CellName is set to the deployment manager 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 deployment manager administrative console and click 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.

  12. Run...

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

    to add the new member to the existing dynamic cluster.

    This task may display a warning message since the cluster already exists but it will proceed to create the new dynamic cluster; therefore, the warning can be ignored.

  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 deployment manager administrative console.

  14. Access the Web Content Management content through an external Web server:

    1. Log on to the deployment manager administrative 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 appserver.

    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 deployment manager:

      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 deployment manager administrative console.

  15. Propagate your changes:

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

      cd dmgr_profile_root/bin
      ./stopManager.sh -username admin_userid -password admin_password
      cd profile_root/bin
      ./stopNode.sh -username admin_userid -password admin_password
      ./stopServer.sh WebSphere_Portal_nodename -username admin_userid -password admin_password
      cd dmgr_profile_root/bin
      ./startManager.sh
      ./startNode.sh
      cd profile_root/bin
      ./startServer.sh WebSphere_Portal_nodename


Parent topic:

Choose the type of additional node to create on AIX