Adding additional nodes to the static cluster on HP-UXAdded by IBM | Edited by IBM on June 23, 2012 | Version 2 (Show original)
|After installing IBM® WebSphere® Portal Enable for z/OS® on your additional cluster node, you must add the node to the cluster to create a highly available environment.
After installing IBM
® Portal Enable for z/OS
® on your additional cluster node, you must add the node to the cluster to create a highly available environment.
Perform the following steps to add the additional cluster node to the cluster:
Deleting passwords from properties files
- Perform the following steps to create a directory to store templates:
- Create a directory called profileTemplates under the PortalServer_root directory.
- Copy the profileTemplates.zip file from the PortalServer_root/profileTemplates directory on the primary node to the same location on the additional cluster node.
- Unzip the profileTemplates.zip file in the same location.
- Run the chmod -R 755 PortalServer_root/profileTemplates}}} task to change the permissions of the files/dirs subdirectory, located in the PortalServer_root/profileTemplates directory, because some files are set to read-only after the copy operation.
- 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.
- 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.
Table 1. Choose between the Profile Management tool and the manageprofiles task to create a new profile that will be used for additional cluster members.
|Profile Management Tool||Perform the following steps to use the Profile Management Tool:
- Run the ./pmt.sh command from the AppServer_root/bin/ProfileManagement directory.
- Click Launch Profile Management Tool.
- Click Create to create a new profile.
- On the Environment Selection panel, select the WebSphere Portal 7.0.0 -> Custom Portal profile, and then click Next.
- Select the Advanced profile creation radio button and then click Next.
- 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.
- 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.
- 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.
- 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.
- 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.
- If you choose to federate the profile now, the Port Values Assignment panel displays. Change any necessary port values and then click Next.
- 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.
- Click Finish to exit PMT.
|manageprofiles command||Run the following command from the AppServer_root/bin directory:|
Tip: If you have a long command, use the continuation character "\" to avoid seeing the "not found" error message.
manageprofiles.sh -create -templatePath /opt/IBM/WebSphere/PortalServer/profileTemplates/managed.portal
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.
- Perform the following steps to ensure your database information is correct and to ensure a successful additional node:
- Ensure that the wkplc_dbdomain.properties and wkplc_dbtype.properties files have the correct database information in them.
- 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 your wkplc_dbtype.properties file.
- Run the ./ConfigEngine.sh validate-database -DWasPassword=password task to validate your database settings.
Tip: Add the -DTransferDomainList parameter to the above validating 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.
- 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.
- Run the following command from the wp_profile_root/bin directory to federate the additional cluster node:
addNode.sh dmgr_hostname dmgr_port
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_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 than the Deployment Manager administrator user ID and password, add the following parameters to the addNode
- -localusername local_was_admin_user
- -localpassword local_was_admin_password
See the addNode command
file for more information about the addNode command and other optional parameters.
- 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:
Although you can add these parameters directly to any task that you run while creating your cluster, you may want to add them to the properties file while creating your cluster and then remove them when you are finished to keep your environment secure.
- Verify that WasUserid is set to your deployment manager administrator ID.
- Verify that WasPassword is set to your deployment manager administrator password.
- Verify that WasRemoteHostName is set to the fully qualified host name of the deployment manager.
- Verify that WasSoapPort is set to the SOAP port that the deployment manager is using; the default value is 8879.
- Verify that ServerName is set to the correct server name. The default is WebSphere_Portal but you can change this on your additional nodes.
- Verify that PrimaryNode is set to false.
- Verify that ClusterName is set to the primary node's ClusterName.
- 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 Version 6.1.0, even if you did not configure a database user registry or a property extension (lookaside) database.
- 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.
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.
- Complete the following steps to add the library paths to the VMM_JDBC_CLASSPATH variable:
- Log on to the WebSphere Application Server Administrative Console.
- Click Environment -> WebSphere Variables.
- Select scope: cell.
- Select the VMM_JDBC_CLASSPATH variable. If this variable does not exist, click New to create the variable.
- 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.
- Copy the files that you entered in for the VMM_JDBC_CLASSPATH variable into the appserver/lib directory.
- Stop and restart the appropriate servers to propagate the changes.
- Run the ./ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=password -DDbDomain=la|federated.db -Ddb_type.NodeDbLibrary=local full path of the database jars on the Deployment Manager -DDmgrNodeName=dmgr_node_name task from the wp_profile_root\ConfigEngine directory to create the local Deployment Manager WebSphere variable used to access the database jars.
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® for z/OS Type 4 driver: db2jcc.jar;db2jcc_license_cisuz.jar;db2jcc_javax.jar
- 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.
is a list of one or more WebSphere
Portal nodes names in the cell which share the same database driver paths. The db_type
should be set to the type of database you are using, for example db2
- 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=password -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid task, from the wp_profile_root/ConfigEngine directory, to update the WebSphere Portal administrative user ID if the Deployment Manager cell is using a different user registry.
Attention: The password value for -DWasPassword is the Deployment Manager administrative password.
Important: 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 the wkplc.properties file and add the values for newAdminId, newAdminPw, and newAdminGroupId. Save your changes and run the ConfigEngine.bat wp-change-portal-admin-user -DWasPassword=dmgr_password task.
Important: 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.
Note: 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 the wkplc.properties file if required.
- Run the task to add the node to your cluster.
- To prevent Out of Memory errors, perform the following steps 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 your Maximum Heap Size
is 3000 M, set MaxPermSize
to 750 M. If your Maximum Heap Size
is less than 2048 M, set MaxPermSize
to 512 M.
- Log in to the WebSphere Application Server Administration Console.
- Click Servers -> Server Types -> WebSphere application servers -> WebSphere_Portal.
- Under Server Infrastructure, click Java and Process Management -> Process Definitions -> Additional Properties -> Java Virtual Machine.
- 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.
Important: 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.
- Click OK to save your changes.
- Click Save to save your changes to the master configuration.
- Log out of the WebSphere Application Server Administration Console.
- Restart the server1 and WebSphere_Portal servers.
- Perform the following steps to access the Web Content Manager content through an external Web server:
- Log on to the deployment manager administrative console.
- Select Environment -> WebSphere Variables.
- 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.
- 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.
- Update the WCM_PORT variable with the port number used to access the WebSphere Portal server through the Web server or On Demand Router.
- Perform the following steps to synchronize the node with the deployment manager:
- Select System Administration -> Nodes.
- Select the node that you want to synchronize from the list.
- Click Full Resynchronize.
- Log off of the deployment manager administrative console.
- Run the following tasks to propagate your changes:
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.
- ./stopServer.sh WebSphere_Portal_servername -username admin_userid -password admin_password
- ./startServer.sh WebSphere_Portal_servername
- 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.