Portal Express, Version 6.0
Operating systems: i5/OS, Linux, Windows
Multiple Clustering and WebSphere Portal
This section describes how to install IBM® WebSphere® Portal Express and set up a cluster environment. 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:
- A single administration User Interface (Administrative Console)
- A single administrative scripting client (wsadmin)
- Shared resources at the cell, node, or server scope
- Replication domains for sharing application data, state information, and caches
- Work load management at the Web server level providing a single server identity for all applications hosted across the cell, enabling ease of collaboration between applications while building a rich end-user application experience
A portal administrator's goal is to manage as many WebSphere Portal Express and portal-based products within the same managed cell as possible, to take advantage of these administrative and runtime features.
WebSphere Portal Express provides the ability to federate multiple, independently configured portals into the same cell. While there are limitations to this support (see Limitations section), this allows multiple portal 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 datasource definition, or a WebSphere variable definition. Scopes are typically defined as being one of the following:- Cell
- All resources defined at this scope are visible to all other resources defined in the cell, and are thus configured globally available
- Node
- A cell has one or more nodes, and each node is named and matches with some WebSphere Application Server 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 make use of these resources
- Cluster
- A resource defined at a cluster scope is visible to all cluster members, or server instances, in this cluster, but is not visible to any other servers in the same nodes
Note that 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 Express, however, does not currently exploit this feature of .
Typically, when installing an enterprise application that is to 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 is to run. Since WebSphere Portal Express 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 Express clusters are defined within the same cell. And by extension, since these are infrastructure applications, all WebSphere Portal Express-based clusters must be at the same version. See the Limitations and Installing updates for multiple clusters sections for more details on the implications of this.
Since portlets are enterprise applications of a special type, it is possible, but not always desirable, to share portlets across multiple portal clusters. Many portlets (for example WebSphere Portal Express administration) are considered part of the infrastructure, and as a result can be shared across multiple clusters. Most end-user application portlets will be specific to certain clusters and will be 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 (e.g. LDAP) 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 portal-based 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
- Understanding how to tell if enterprise applications are shared between clusters
- Defining other resources at the appropriate scope, depending on the usage goals
Limitations
- All portal clusters must be at the same maintenance levels
Because WebSphere Portal Express is made up of several enterprise applications, and because these applications are tightly coupled to the underlying portal services and infrastructure, all portal-based clusters in the same cell must be at the same service level. For example, if a WebSphere Portal Express Version 6.0 cluster already exists in a cell, and you wish to build a cluster based on WebSphere Portal Express Version 6.0.1, then the existing WebSphere Portal Express V6.0 cluster must be updated to the V6.0.1 level. See the Installing updates for multiple clusters for more details about how to apply maintenance in a multiple portal cluster environment.
- Managed Node install option
Use the managed node installation option in WebSphere Portal Express V6.0 to install WebSphere Portal Express into an existing cell with a managed WebSphere Portal Express server or cluster. However, do not try to use this option to make a newly installed WebSphere Portal Express the basis for forming another cluster within a cell. The steps described in the topic for adding additional WebSphere Portal Express server profiles into the cell must be performed after initial installation, and thus can only operate on a standalone (non-managed) installation.
- Process Server considerations
In the case where multiple portal clusters need access to a common WebSphere Process Server, the server should be centralized within its own cluster, and the client install option of WebSphere Process Server V6.0.2 should be used in conjunction with WebSphere Portal Express V6.0 or higher to allow remote access to the central process server cluster.
- Setting up multiple clusters
This section describes the recommended approach for building multiple portal-based clusters within a single cell.