Plan for multiple clusters
Multiple clusters are sets of servers managed together within a single cell.
One portal might be providing different applications or services than another portal. With a common server identity, these services and applications can integrate seamlessly at the browser through the latest in web 2.0 technology. For example, it uses Ajax and REST services.
Scope controls the visibility of a resource to other resources and application server instances. An example of a resource might be a data source definition, or a WebSphere variable definition. Scopes include...
Cell All resources defined in this scope are visible to all other resources defined in the cell. Therefore, they are configured as globally available. Node A cell has one or more nodes, and each node is named and matches with some WAS profile on some physical server. All resources defined at this scope are visible only to other resources defined in this same node, including any server definitions. Server A node has one or more server definitions. All resources defined at this scope are visible only to that server. No other server or node can use these resources. Cluster A resource defined at a cluster scope is visible to all cluster members, or server instances, in this cluster. However, it is not visible to any other servers in the same nodes.
Enterprise applications are cell-scoped. There can be only one enterprise application with a given name in the cell. If multiple servers and clusters, or multiple clusters require the use of that enterprise application, they must share it.
After installing an enterprise application shared across multiple clusters, we map the application to the target clusters where it runs. WebSphere Portal installs several enterprise applications as part of its basic configuration and before any cluster is defined. Special steps must be followed to ensure these infrastructure applications are appropriately shared when multiple clusters are defined within the same cell. And by extension, since they are infrastructure applications, all WebSphere Portal clusters must be at the same version.
Since portlets are enterprise applications of a special type, it is possible, but not always appropriate, to share portlets across multiple clusters. Many portlets (for example WebSphere Portal administration) are considered part of the infrastructure, and as a result can be shared across multiple clusters. Most user application portlets are specific to certain clusters and are installed as such.
The Java EE security configuration for the cell is shared by all servers and clusters managed in the cell. Therefore, each server and cluster must share an underlying user repository.
To summarize at a high level, supporting multiple clusters in the same cell involves:
- A common security model, including user repositories, for every cluster
- Some number of common enterprise applications and portlets that must be made common as part of the federation and clustering process
- Installing portlets into certain clusters, or across clusters, as appropriate
- Understand how to tell if enterprise applications are shared between clusters
- Define other resources at the appropriate scope, depending on the usage goals
Limitations
- All portal clusters must be at the same maintenance levels
- Portal applications are tightly coupled to the underlying services and infrastructure. All portal-based clusters in the same cell must be at the same service level.
- IBM Process Server considerations
- When multiple clusters need access to a common Process Server, centralize the server within its own cluster. Use WebSphere Portal with the client installation of the Process Server to allow remote access to the central process server cluster.
Should multiple Digital Experience Clusters per cell be used or rather Multiple Cells be defined?
IBM recommends to not use multiple Digital Experience clusters in a single cell. While the main saving is to have a single Deployment Manager for all clusters in the cell the disadvantages outweigh this single advantage...'
- Cell wide configuration settings like for instance security configuration limit flexibility
- Dynacache replication in the cell can impact performance
- Challenge to administer since even scoped setting changes need to be done in the right scope
- All portal clusters must be at the same maintenance levels
Health Management with Digital Experience on WebSphere Application Server 8.5.5.x
Starting with WebSphere Application Server 8.5 new Health Monitoring features were introduced - the .
The health monitor uses health policies. A health policy is a combination of health conditions and actions. Health conditions define triggers from which the system can protect itself, for example, a memory leak. Health actions are the specific steps that the system takes when a health condition is triggered. For example, with a memory leak condition, the health action can be to restart the associated servers . A number of predefined health conditions are installed with the product. We can use the predefined health conditions to create default health policies. In addition to these broad default health policies, we can define specific policies that apply for our environment.
The health monitoring happens at the Java Virtual Machine level and can be used with Digital Experience JVMs as well.
Intelligent Routing
Starting with WebSphere Application Server 8.5 in addition to the classic web server plugin and the On Demand Router a new feature was introduced - Intelligent Routing.
In the WebSphere Console we can turn on the Intelligent Routing feature for the web server plugin and from then on the Intelligent features will be enabled.
Among others the Intelligent Routing provides:
- Routing information based on events in WebSphere like stopping a server or starting an application
- Weighted Least Outstanding Requests (WLOR) load balancing
- Honoring health management features like not routing requests to a server that is in maintenance mode
See
Parent Cluster considerations