Cluster
To increase capacity and availability, multiple portal servers can be clustered using IBM WAS Network Deployment. In a cluster the portals share a common configuration and the load is distributed evenly across all cluster instances.
WebSphere Portal comes standard with WAS Network Deployment, a distribution of IBM WAS that provides a Deployment Manager server type for centrally managing and clustering a series of servers. To cluster a series of portal servers means that all portal instances share the same configuration, including database, applications, and portlets, and site design. The cluster provides a domain against which most administrative actions are performed once and synchronized with each server in the cluster. This both simplifies administration as well as ensures that all cluster members are configured and behave identically.
A server cluster also provides a shared domain in which session and cache data can be replicated and kept consistent across all members of the cluster. The cluster also provides an application synchronization mechanism that ensures consistent application management (start, stop, updates, etc.) across the cluster.
WAS provides an HTTP Server plug-in that can balance user traffic across all members of the cluster, and through a feature called “session affinity”, ensure that a user remains bound to a specific cluster instance for the duration of their session, to improve efficiency and performance. Additionally, in the event a cluster member is down, the workload management features of the plug-in will recognize that the instance is no longer available and will route traffic around it.
There are two types of clusters: vertical and horizontal clusters. Most large-scale deployments are mixtures of both cluster types.
It is also possible to deploy multiple portal clusters to improve availability, failover, and disaster recovery.
IBM recommends that you review the cluster guidelines and limitations topics for more information about what is involved in setting up a cluster.
- Guidelines for setting up a cluster
When planning to setup a WebSphere Portal clusters, take into account any cluster planning required for the WAS nodes. If you are not familiar with WAS clustering, find resources here to help you get started.
- Limitations for setting up a cluster
The following limitations apply when setting up a WebSphere Portal cluster:
- HTTP session failover
In a clustered environment, all requests for a particular session are directed to the same server instance in the cluster. In other words, after a user establishes a session (for example, by logging in), the user is served by the same server instance for the duration of the session. To verify which server is handling user requests for a session, you can view the global settings portlet, which displays the node name of the server handling requests. If one of the servers in the cluster fails, the request is rerouted to another server in the cluster.
If distributed sessions support is enabled (either by persistent sessions or memory-to-memory session replication), the new server can access session data from the database or another server instance.
- Set up an i5/OS database in a cluster
To communicate with a database, servers running IBM i5/OS can use either of two JDBC drivers: the IBM Toolbox for Java JDBC driver or the IBM Developer Kit for Java JDBC driver (also referred to as the native JDBC driver). Which JDBC driver use depends on how you are setting up the clustered environment.
- Security options
The security model in IBM WAS and WebSphere Portal affects the planning and implementation of security in a cluster. Security is enabled by default for the deployment manager; WebSphere Portal will not attempt to change the security settings in the deployment manager cell whenever a node is federated. This means that any existing security configuration of a stand-alone WebSphere Portal is replaced with the security settings of the deployment manager cell when it joins that cell. If you remove the node from the deployment manager cell, the original security settings are reinstated.
- Security Scenarios
When setting up a cluster, there are two scenarios that must be considered. There is out-of-box security used when you first set up the cluster environment where the deployment manager has not configured the security settings.
The second scenario is when an existing deployment manager has already configured the security settings prior to a node joining a cell.
- Use external security managers in a cluster
If you are configuring security for WebSphere Portal with an external security manager, review some additional considerations, depending on the external security manager that you are using. Perform any configuration for an external security manager after you have completed all other setup, including ensuring that the WebSphere Portal cluster is functional. In addition, review the "Systems requirement" file to ensure you are using a supported level of the external security manager software.
- Plan for multiple clusters
Get an overview of the concepts associated with setting up multiple clusters. Multiple clusters are sets of servers that are managed together within a single administrative domain known as a cell, and participate in workload management.
- WebSphere Virtual Enterprise Dynamic Clusters
You can create a WebSphere Virtual Enterprise dynamic cluster to run WebSphere Portal.
- Cluster maintenance
Maintaining WebSphere Portal in a cluster typically means applying corrective services (fix packs and interim fixes) or updating the software release level on each node in the cluster. Instructions for applying corrective service to a WebSphere Portal cluster are provided with the corrective service package. Before applying any maintenance, it is always important to analyze any impact to your end users and ensure that you are able to provide uninterrupted service (also referred to as 24x7 availability), even during the maintenance phase.
Parent topic:
Plan for WebSphere Portal
Related concepts
Horizontal cluster topology
Related tasks
Set up a cluster