Add additional nodes to the static cluster on AIX


Overview

After installing WebSphere Portal on additional cluster node, add the node to the cluster to create a highly available environment.


Add the additional cluster node to the cluster

  1. Create directory:

      PORTAL_HOME/profileTemplates

  2. Copy...

      PORTAL_HOME/profileTemplates/profileTemplates.zip

    .on the primary node to the same location on the additional cluster node.

  3. Unzip the profileTemplates.zip file in the same location.

  4. Change the permissions of the files/dirs subdirectory, located in PORTAL_HOME/profileTemplates, because some files are set to read-only after the copy operation.

      chmod -R 755 PORTAL_HOME/profileTemplates

  5. Install the copied profile template.

      cd PORTAL_HOME/profileTemplates
      ./installPortalTemplates.sh $WAS_HOME

    This task localizes the profile templates to the current environment and registers them with the Profile Management Tool if it exists on server.

  6. Create a new profile

    If you have a 64-bit environment, only the manageprofiles command is supported when creating profiles.

    Use Profile Management Tool

    1. Run the ./pmt.sh command from the WAS_HOME/bin/ProfileManagement directory.

    2. Click Launch Profile Management Tool and click

      Create | Environment Selection panel | WebSphere Portal 7.0.0 | Custom Portal profile | Next | Advanced profile creation radio button | Next

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

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

    5. On the Federation panel check the Federate this node later check box to federate the node in the future.

        Do not enter the values for the Dmgr to federate now as this will cause an unusable portal node.

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

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

    8. If you choose to federate the profile now, the Port Values Assignment panel displays. Change any necessary port values and then click Next.

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

    10. Click Finish to exit PMT.

    cd WAS_HOME/bin manageprofiles.sh -create \ -templatePath $PORTAL_HOME/profileTemplates/managed.portal -profileName underwriting \ -profilePath /csapps/websphere/appserver/AppServer/uw_profile \ -cellName cut1-network-portal -nodeName uwNode -hostName sch1h691.cna.com

    Use manageprofiles command

      cd WAS_HOME/bin 
      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

    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.

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

    2. Copy the database drivers on the primary node to the same location on the additional cluster node. You can find the location of database drivers in wkplc_dbtype.properties file.

  8. Run the ./ConfigEngine.sh validate-database -DWasPassword=foo task to validate database settings.

      Add -DTransferDomainList to specify the domains to validate; for example: -DTransferDomainList=jcr.

    Open the icm.properties file, located in the WP_PROFILEjcr.textsearch.enabled property to false.

  9. Run the following command from the WP_PROFILE
      addNode.sh dmgr_hostname dmgr_port -username was_admin_user -password was_foo

    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_foo are the user ID and password for the Deployment Manager administrator

    If the WAS 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 task:

    • -localusername local_was_admin_user

    • -localpassword local_was_foo

    See the addNode command file for more information about the addNode command and other optional parameters.

  10. Ensure that the following parameters are set correctly in wkplc.properties, located in...

      WP_PROFILE

      .of the additional cluster node:

        Although you can add these parameters directly to any task that you run while creating cluster, you may want to add them to the properties file while creating cluster and then remove them when you are finished to keep environment secure.

        1. Verify that WasUserid is set to dmgr administrator ID.

        2. Verify that WasPassword is set to dmgr administrator password.

        3. Verify that WasRemoteHostName is set to the fully qualified host name of the dmgr.

        4. Verify that WasSoapPort is set to the SOAP port that the dmgr 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 additional nodes.

        6. Verify that PrimaryNode is set to false.

        7. 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 v6.1.0, even if you did not configure a database user registry or a property extension (lookaside) 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. Add the library paths to the VMM_JDBC_CLASSPATH variable:

          1. Log on to the WAS 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/db2jcc.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. Run the ./ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=foo -DDbDomain=la|federated.db -Ddb_type.NodeDbLibrary=/path/to/DB/jars -DDmgrNodeName=dmgr_node_name task from the WP_PROFILE
            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:

              DB2Type 2 driver: db2java.zip
              DB2 Type 4 driver: db2jcc.jar;db2jcc_license_cu.jar
              DB2 for z/OSType 2 driver: db2java.zip
              DB2 for z/OS Type 4 driver: db2jcc.jar;db2jcc_license_cisuz.jar;db2jcc_javax.jar
              Oracle: ojdbc14.jar
              SQL Server JDBC driver provided by Microsoft: sqljdbc.jar
              SQL Server JDBC driver provided by DataDirect: sqlserver.jar;base.jar;util.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=/path/to/DB/jars task from the WP_PROFILEVMM database jars.

            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.

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

    • Update the WebSphere Portal administrative user ID if the Deployment Manager cell is using a different user registry.

      cd WP_PROFILE ./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=foo -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid

      The password value for -DWasPassword is the Deployment Manager administrative password.

      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 wkplc.properties and add the values for newAdminId, newAdminPw, and newAdminGroupId. Save changes and run the ConfigEngine.bat wp-change-portal-admin-user -DWasPassword=dmgr_password task.

      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.

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

  12. Access the Web Content Manager content through an external Web server:

    1. Log on to the dmgr 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 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. To synchronize the node with the dmgr:

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

  13. Run the following tasks to propagate changes:

      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 foo

      2. ./startServer.sh WebSphere_Portal_servername

  14. If you entered passwords in any of the properties files while creating cluster, you should remove them for security purposes. See "Deleting passwords from properties files" under Related tasks for information.


Parent

Choose the type of additional node to create on AIX


Delete passwords from properties files

  Mar 8, 2011 11:34:57 AM Removed out of memory step (11) because it only pertains to Solaris. Put italics around the word WAS_HOME in step 1 d.


+

Search Tips   |   Advanced Search