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

IBM WebSphere Application Server Network Deployment provides the ability to manage many application servers and application server clusters within a single administrative domain, or cell. The single cell has the following advantages:

An administrator's goal is to manage as many WebSphere Portal and portal-based products within the same managed cell as possible, to take advantage of these administrative and run time features.

WebSphere Portal provides the ability to federate multiple, independently configured portals into the same cell. While there are limitations to this support, this allows multiple clusters to be managed together, where one portal may be providing different applications or services than another portal. With a common server identity through the web server, these services and applications can integrate seamlessly at the browser through the latest in Web 2.0 technology (for example through the use of Ajax and REST services).


How multiple clusters work in a single cell

It is important to first understand that a cell’s configuration has the notion of scope, which controls the visibility of that 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 are typically defined as being one of the following:


Cell


Node


Server


Cluster

Resources defined within a circle, in the above diagram, can be seen by all other resources defined within that circle and any other scopes defined within that circle.

Within this concept of scope, an important point is that all enterprise applications are cell-scoped. In other words, there can only be 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.

IBM WebSphere Virtual Enterprise offers the ability manage multiple editions of the same enterprise application, including the mapping of these editions to different servers and clusters, or to different clusters. WebSphere Portal, however, does not currently exploit this feature.

Typically, when installing an enterprise application that will be shared across multiple clusters, the administrator simply installs the enterprise application archive (EAR) into the cell’s management server, Deployment Manager, and then maps the application to the target clusters where it will run. Since WebSphere Portal installs several enterprise applications as part of its basic configuration and typically before any cluster is defined, special steps have to be followed to ensure that these infrastructure applications are appropriately shared when multiple WebSphere Portal clusters are defined within the same cell. And by extension, since these are infrastructure applications, all WebSphere Portal-based 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. See the Portlet deployment best practices section for more details.

Also, the J2EE security configuration for the cell is shared by all servers and clusters managed in the cell. Therefore, each server and cluster must share the same underlying user repository against which users are authenticated when using any application hosted by any server and/or cluster in that same cell.

To summarize at a high level, supporting multiple clusters in the same cell involves:


Limitations


All portal clusters must be at the same maintenance levels


Process Server considerations


WebSphere Virtual Enterprise Static clusters


Parent

Cluster considerations


+

Search Tips   |   Advanced Search