+

Search Tips   |   Advanced Search


Add additional nodes to the static cluster on Linux

After installing WebSphere Portal on your secondary node, add the node to the cluster to create a highly available environment. Add the secondary node to the 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:

    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 PortalAdminId is set to your WebSphere Portal administrator ID.

    4. Verify that PortalAdminPwd is set to your WebSphere Portal password.

    5. Verify that WasRemoteHostName is set to the fully qualified host name of the deployment manager.

    6. Verify that WasSoapPort is set to the SOAP port that the deployment manager is using; the default value is 8879.

    7. Verify that PrimaryNode is set to false.

    8. Verify that ClusterName is set to the 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...

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

      from...

        profile_root/ConfigEngine

      ...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. Optional: Open wkplc.properties and change the ServerName parameter from the default WebSphere_Portal_nodename value to a value that meets your business needs. Do not change the parameter to WebSphere_Portal as this is the primary node value.

  9. Run the ./ConfigEngine.sh cluster-node-config-cluster-setup -DWasPassword=dmgr_password task to add the node to the cluster.

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


Parent topic:

Choose the type of additional node to create on Linux