Create a static cluster on AIX

After installing WebSphere Portal on the primary node, configuring a remote database, and preparing the primary node to communicate with the Deployment Manager, you can create your static cluster to handle failover requests. Create the cluster:

  1. If the Deployment Manager is configured to use a stand-alone LDAP user registry, update wkplc.properties, located in...

      profile_root/ConfigEngine/properties

    on the primary node with the stand-alone LDAP user registry property values from the Deployment Manager. You can find these settings under the VMM Stand-alone LDAP configuration heading.

    Ensure that you set WasUserid and WasPassword to the Deployment Manager user ID and password.

  2. Stop the server1 and WebSphere_Portal servers on the primary node and ensure that the following parameters are set correctly in wkplc.properties, located in...

      profile_root/ConfigEngine/properties

    1. Set WasSoapPort to the port used to connect remotely to the deployment manager.

    2. Set WasRemoteHostName to the full host name of the server used to remotely connect to the deployment manager.

    3. Verify that WasPassword is set to your deployment manager password.

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

    5. Verify that ClusterName is set.

    6. Verify that PrimaryNode is set to true.

  3. Make a backup copy of the profile_root/config/cells/cell_name/wim/config/wimconfig.xml and profile_root/config/cells/cell_name/wim/model/wimxmlextension.xml, if available, files.

  4. Run...

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

    ...from profile_root/ConfigEngine of the primary node.

    To specify custom ports for the nodeagent, add the -DPortPropsFile=full to portsfile parameter to the cluster-node-config-pre-federation task.

    You can use the ports files that are found on the Setup CD for WebSphere_Portal and server1 as a guide.

    You may receive a message about accepting an SSL signer certificate. Failure to accept the SSL signer certificate will cause the script to fail. Alternatively, the com.ibm.ssl.enableSignerExchangePrompt flag can be enabled in the ssl.client.props file for "DefaultSSLSettings" in order to allow acceptance of the signer during the connection attempt. Warning: If the cluster-node-config-pre-federation fails for any reason, perform the following steps before rerunning the task:

    1. Remove the node if the AddNode task succeeded.

    2. Log on to the deployment manager and perform the following steps if the items exist:

      1. Remove all enterprise applications.

      2. Remove the WebSphere_Portal server definition.

      3. Remove the WebSphere Portal JDBC Provider.

    If you are migrating from a version prior to v6.1.0 that contains Lookaside data, read the following technote: Migrating with Lookaside Data.

  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

  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. Run the ./ConfigEngine.sh cluster-node-config-cluster-setup -DWasPassword=dmgr_password task.

  9. Configure the cluster to use an external Web server to take advantage of features such as workload management. Choose one of the following options:

    Start with the step about launching the Plug-ins installation wizard.

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

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

    1. cd dmgr_profile/bin
      ./stopManager.sh-username admin_userid -password admin_password

    2. cd profile_root/bin
      ./stopNode.sh -username admin_userid -password admin_password

    3. ./stopServer.sh WebSphere_Portal_nodename -username admin_userid -password admin_password

    4. cd dmgr_profile/bin
      ./startManager.sh

    5. cd profile_root/bin
      ./startNode.sh

    6. ./startServer.sh WebSphere_Portal_nodename

  12. Change the task list settings to point to the cluster instead of a single server if using Portal business process integration. See one of the following sections in the Information Center for information:

    Option Description
    Cross cell Adding a BPI-enabled portal server to a managed cell in a cross-cell setup
    Single cell Adding a BPI-enabled portal server to a managed cell in a single-cell setup


Parent topic:

Choose the type of cluster to create on AIX


Related tasks


Add a BPI-enabled portal server to a managed cell in a cross-cell setup
Add a BPI-enabled portal server to a managed cell in a single-cell setup