Adding horizontal nodes to the static cluster on AIX®

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

About this task

Complete the following steps to add the horizontal cluster node to the cluster:

Procedure

  1. Complete the following steps to create a directory to store templates:
    1. Copy the profileTemplates.zip file from the PortalServer_root/profileTemplates directory 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 your profileTemplates directory, overwrite them.
    3. Run the chmod -R 755 PortalServer_root/profileTemplates task to change the permissions of the files and directories, located in the PortalServer_root/profileTemplates directory, because some files are set to read-only after the copy operation.
    4. Run the ./installPortalTemplates.sh AppServer_root 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 your server.
  2. Choose one of the following methods to create a profile that is used for additional cluster members:
    Important: Choose a Node Name that is different from what you entered for the primary node.
    Table 1. Choose between the Profile Management tool and the manageprofiles task to create a profile that is used for additional cluster members.
    Option Steps
    Profile Management Tool Complete the following steps to use the Profile Management Tool:
    1. Run the ./pmt.sh command from the AppServer_root/bin/ProfileManagement directory.
    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, 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 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 Deployment Manager to federate now as this will cause an unusable portal node.
    9. On the Profile Creation Summary panel, 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 command Run the following command from the AppServer_root/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
    Tip: 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. Complete the following steps to ensure that your 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.
      Tip: 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. You can find the location of your database drivers in the wkplc_dbtype.properties file.
  4. Run the ./ConfigEngine.sh validate-database -DWasPassword=password task to validate your database settings.
    Tip: Add the -DTransferDomainList parameter to the validate-database task to specify the domains you want to validate; for example: -DTransferDomainList=jcr. If you want to validate all domains, you do not need to specify this parameter on the command line.
  5. Open the icm.properties file, located in the wp_profile_root/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_root/bin directory to federate the additional cluster node: 
    ./addNode.sh dmgr_hostname dmgr_port
	-username was_admin_user
	-password was_admin_password
    The 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

      To locate the SOAP port for the Deployment Manager, complete the following steps:

      • Log into the Deployment Manager Integrated Solutions Console.
      • Go to System Administration > Deployment Manager.
      • Expand Ports in Additional Properties.
      • Locate the entry for SOAP_CONNECTOR_ADDRESS.
    • was_admin_user and was_admin_password are the user ID and password for the Deployment Manager administrator
    If the WebSphere Application Server administrator user ID and password for the local node are different from the Deployment Manager, add the following parameters to the addNode task:
    • -localusername local_was_admin_user
    • -localpassword local_was_admin_password
    Tip: 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 the wkplc.properties file, located in the wp_profile_root\ConfigEngine\properties directory of the additional cluster node:
    Note: Although you can add these parameters (particularly passwords) directly to any task while creating your cluster, you might want to temporarily add them to the properties file. You can then remove them when you are finished to keep your environment secure.
    1. Verify that WasUserid is set to your deployment manager administrator ID.
    2. Verify that WasPassword is set to your deployment manager administrator password.
    3. Verify that WasRemoteHostName is set to the fully qualified host name of the deployment manager.
    4. Verify that WasSoapPort is set to the SOAP port that the deployment manager 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 your 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:
    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 the wkplc.properties file.
      Note: If you migrated the primary node from a version prior to Version 6.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 the wkplc.properties file on the primary node.
    2. Complete the following steps to add the library paths to the VMM_JDBC_CLASSPATH variable:
      1. Log on to the WebSphere Application Server WebSphere Integrated Solutions 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 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. wp_profile_root/ConfigEngine/ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=password -DDbDomain=la|federated.db -Ddb_type.DmgrDbLibrary=local full path of the database jars on the Deployment Manager -DDmgrNodeName=dmgr_node_name
      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: 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 that is provided by Microsoft: sqljdbc.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=local full path of the database jars task from the wp_profile_root/ConfigEngine directory 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 database driver paths. The db_type in db_type.NodeDbLibrary must be set to the type of database you are using, for example db2.
  9. The WebSphere Portal node is federated and using the Deployment Manager cell and its user registry. If the administrative user ID and group name are different in the WebSphere Portal and Deployment Manager configurations, choose one of the following options depending on your security policies:
    • Add the existing administrative user ID and group to the Deployment Manager security configuration
    • Complete the following steps to change the values in the WebSphere Portal configuration to match the Deployment Manager values:
    Restriction: If your Deployment Manager 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. If necessary, start the WebSphere_Portal server.
    2. Verify that the required WebSphere Portal administrative user ID and group ID are defined in the Deployment Manager user registry that provides security for the cell.
    3. Run the ./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=password -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid task, from the wp_profile_root/ConfigEngine directory, where:
      Important: If the value for newAdminGroupId contains a space; for example Software Group, open the wkplc.properties file and add the values for newAdminId, newAdminPw, and newAdminGroupId. Save your changes and then run the ./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=dmgr_password task.
      • WasPassword is set to the administrative password for the Deployment Manager cell
      • newAdminId is set to the fully qualified distinguished name (DN) of the WebSphere Portal administrative user ID in the cell
      • newAdminGroupId is set to the fully qualified DN of the group for the WebSphere Portal administrative user ID in the cell
    4. After the task completes, stop the WebSphere_Portal server.
  10. Run the ./ConfigEngine.sh cluster-node-config-cluster-setup-additional -DWasPassword=dmgr_password task to add the node to your cluster.
  11. If the profile templates were copied from a server with a different profile directory, complete the following steps:
    1. Log on to the Deployment Manager 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. Open a command prompt and change to the wp_profile_root/ConfigEngine directory.
    7. Run the ./ConfigEngine.sh profile-update-entries task to update these entries with the correct profile paths.
  12. Complete the following steps to access the Web Content Manager content through an external web server:
    1. Log on to the deployment manager WebSphere Integrated Solutions 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 WebSphere Portal 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. Update the WCM_HOST and WCM_PORT variable for each additional WebSphere Portal application server that already exists in the cluster.
    7. Complete the following steps 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.
    8. Log off of the deployment manager WebSphere Integrated Solutions Console.
  13. If you transferred your databases after you created the cluster, complete the following steps on each horizontal cluster member:
    1. Copy the wp_profile_rootPortalServer/jcr/lib/com/ibm/icm.properties file from the primary node to the new node.
    2. Log on to the deployment manager WebSphere Integrated Solutions Console.
    3. Go to Environment > WebSphere Variables.
    4. From the Scope menu, select the Node=nodename, Server=servername option to narrow the scope of the listed variables. Node=nodename is the node that contains the WebSphere Portal application server.
    5. Update the WCM_DATASOURCE variable with the JCR data source name. Create the variable in the jdbc/jcr.DataSourceName format. For example, jdbc/wpdbds_jcr.
    6. Save all changes and synchronize the nodes.
  14. Run the following tasks to propagate your 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 admin_password
    2. ./startServer.sh WebSphere_Portal_servername
  15. If you entered passwords in any of the properties files while creating your cluster, you should remove them for security purposes. See "Deleting passwords from properties files" under Related tasks for information.