+

Search Tips   |   Advanced Search


Create a new dynamic cluster on Solaris using WebSphere Virtual Enterprise

After configuring WebSphere Portal on the primary node and all additional nodes, you can create a new dynamic cluster. A dynamic cluster monitors performance and load information and is able to dynamically create and remove cluster members based on the workload. Before creating your dynamic cluster, install the Deployment Manager and perform all the tasks under “Preparing the primary node.” On the Deployment Manager system, install WebSphere Virtual Enterprise and augment the deployment manager profile. 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
Create a dynamic cluster:

  1. Perform the following steps for on the primary node of the dynamic cluster:

    1. Prepare the node for the dynamic cluster; perform all tasks under Preparing the primary node.

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

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

    4. Run...

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

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

      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. If you configured a database user registry or a property extension database, run the following task for EACH WebSphere Portal node that participates in the cluster to set up access to the database drivers; if multiple nodes share the same database library path you can submit a comma separated list of node names:

      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.

      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.

      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-dynamic-cluster-setup 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.

  2. Log on to the deployment manager administrative console.

  3. Create a node group:

    1. Click System administration > Node groups.

    2. Click New.

    3. Type the node group Name.

    4. Optional: Type any information about the node group in the Description text box.

    5. Click OK.

    6. Click the Save link to save your changes to the master configuration.

  4. 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 primary node and then click Add.

    6. Click the Save link to save your changes to the master configuration.

  5. Create a dynamic cluster in the node group:

    1. Click Servers > Dynamic clusters.

    2. Click New.

    3. Select WAS from the Server Type pull-down menu and then click Next.

    4. Type the cluster name in the Dynamic cluster name text box and then click Next. Type the same value that you provided for the ClusterName parameter in wkplc.properties of the primary node.

    5. Remove all default membership policies and then click Subexpression builder.

    6. Enter the following information in the Subexpression builder window:

      1. Select and from the Logical operator pull-down menu.

      2. Select Nodegroup from the Select operand pull-down menu.

      3. Select Equals (=) from the Operator pull-down menu.

      4. Type the nodegroup name created in the previous step in the Value text box.

      5. Click Generate subexpression.

      6. Click Append.

    7. Click Preview membership to verify that all nodes included in the nodegroup display and then click Next.

    8. Click the Create the cluster member using an existing server as a template radio button and then select the WebSphere_Portal server for the primary node from the pull-down menu.

    9. Click Next.

    10. Specify the dynamic cluster.properties and then click Next.

    11. Review the summary page to verify your actions and then click Finish.

    12. Click the Save link to save your changes to the master configuration.

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

      profile_root/ConfigEngine/properties

    1. Set ClusterName to the name of the new 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 true.

  7. Run...

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

    from...

      profile_root/ConfigEngine

    ...to create the 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.

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

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

  10. For a Web server to connect to the On Demand Router (ODR), configure the web server as a trusted proxy on the ODR. Refer to Configure a Web server as a trusted proxy server for instructions.

    Tip: You can also configure the ODR to dynamically update the Web server configuration when changes occur. Refer to Configure an on demand router to dynamically update the Web server plug-in configuration for instructions.


Parent topic:

Choose the type of cluster to create on Solaris