Cluster considerations
To increase capacity and availability, multiple portal servers can be clustered with WAS Network Deployment. In a cluster, the portals share a common configuration, and the load is distributed evenly across all cluster instances.
IBM WebSphere Portal comes standard with WAS ND, a distribution of IBM WebSphere Application Server that provides a dmgr server type for centrally managing and clustering a series of servers. To cluster a series of portal servers means that all portal instances share configuration, including database, applications, and portlets, and site design. The cluster provides a domain against which most administrative actions are done once, and synchronized with each server in the cluster. 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, and so on) 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 during their session to improve efficiency and performance. Additionally, in the event a cluster member is down the workload management features of the plug-in recognizes the instance is no longer available and route traffic around it.
There are two types of clusters: vertical and horizontal clusters.
We can deploy multiple portal clusters to improve availability, failover, and disaster recovery.
- Guidelines for setting up a cluster
- Limitations for setting up a cluster
- HTTP session failover
- Security options
- Security Scenarios
- Use external security managers in a cluster
- Plan for multiple clusters
- Dynamic clusters
- Cluster maintenance