Manage the cluster

After configuring the clustered environment, manage the different parts of the cluster to ensure a highly available production environment. To manage the cluster:

• Enable LDAP security after cluster creation

  If you changed your security configuration after creating the clustered environment, update the security configuration on all secondary nodes by updating wkplc.properties and running the enable-jcr-security task.

• Rename the node

  In a clustered environment, it may be necessary to rename a node because the deployment manager does not permit duplicate node names in a cell.

  You must first change the name in the deployment manager using the IBM WAS command renameNode. WebSphere Portal stores the node name information in the registry so after running the WAS command, you would need to update the information in the registry.

• Determining application sharing between clusters

  If applications are shared between clusters, there are maintenance implications. An application definition is cell-scoped, meaning that a single application can be used by any server running on any node within the cell.

  The relationship between an enterprise application and the server where it runs is called a mapping. For a cluster to run an instance of an application, the application must be mapped to that cluster. An application that is shared between multiple clusters will have multiple mappings.

• Applying updates to custom applications

  For customer-written portlet applications that are pre-deployed as standard EARs and then configured within each cluster using XMLAccess, use the same update procedure as used for portlet applications provided with WebSphere Portal.

• Manage portlets in the cluster

  Because all WebSphere Portal servers in the cluster share the same database, any node can be used to manage portlets. Cluster nodes do not need to be stopped when managing portlets. When you deploy a portlet, WebSphere Portal stores the portlet configuration data in the WebSphere Portal database and then forwards the portlet application's Web module and associated configuration to the deployment manager. The deployment manager is responsible for pushing the Web module to each node in the cluster. Because all WebSphere Portal servers in the cluster share the same database, any node can be used to manage portlets. Cluster nodes do not need to be stopped when managing portlets.

• Manage replication in the cluster

  Replication is a service provided by WAS that transfers data, objects, or events among appservers. Data replication can be used to make data for session manager, dynamic cache, and stateful session beans available across many appservers in a cluster.

• Manage Portal Scripting Interface in the cluster

  The Portal Scripting Interface allows you to create administrative tasks that administrators can run from a command line. Prepare the cluster to manage Portal Scripting Interface.

• Manage Single sign-on settings in the cluster

  If you configured the nodes in the cluster to use single sign-on (SSO), you can change the SSO settings for the cluster.

• Updating Personalization properties in a cluster

  WebSphere Portal provides two property files that you can modify to customize the Portal Personalization feature. These files are not managed by the deployment manager, so if you make any changes to these files on a node in the cluster, those changes are not transferred to other nodes when you perform a synchronization of the cluster members.

• Manage WAS in the cluster

  In some situations you might need to install additional WAS features on the nodes in the cluster.

  For example, this could be necessary if a portlet requires a WAS feature not currently installed on the nodes. When installing additional features in a clustered environment, install the features on every node in the cluster. Also, the WAS Network Deployment node cannot have fewer features than the nodes that it manages. Consequently, if install a new feature on the managed nodes, review the features on the WAS Network Deployment node to determine whether also install the feature on the WAS Network Deployment node.

  For example, if you select the full installation option for WebSphere Portal, the WAS will not have the extended messaging feature installed by default. If any of your portlets use the extended messaging feature, you will have to install this new feature on all nodes before you are able to deploy these portlets.

Parent topic:

Administer WebSphere Portal

---