Set up multiple clusters on Solaris
The majority of the steps to build another cluster are the same as when building the first cluster in the same cell, with a few exceptions. Basically, the new profile will be designated as the primary profile, using IBM WebSphere Portal clustering terminology, and will then be used as the basis for the new cluster definition. This duplicates the build process of the first cluster in the cell. During the federation process, if any applications on this new node already exist in the cell (because they are in use by the first cluster), then dmgr will not allow them to be added. After federation, the applications that already exist in the cell are not mapped to the WebSphere_Portal server on the newly federated node, and thus the existing applications must be remapped to this newly federated server to restore its application list. Therefore, depending on the configuration of the new profile, there will likely be some combination of applications shared with the other existing cluster, and some applications unique to this new profile.
- Prerequisites
- Prepare the Solaris operating system in a clustered environment
- Prepare the primary node on Solaris
- Create and augment a new dmgr profile on Solaris
- Solaris cluster: Tune the servers
Before attempting alternative approaches for building multiple portal-based clusters within a single cell, please contact IBM.
- Prerequisites
- Prepare the Solaris operating system in a clustered environment
- Prepare the primary node on Solaris
- Create and augment a new dmgr profile on Solaris
- Solaris cluster: Tune the servers
- Install multiple clusters in a single cell on Solaris
Create a new, independent IBM WebSphere Portal cluster in a cell where a WebSphere Portal cluster already exists.- Route requests across clusters on Solaris
The HTTP Server plug-is that comes with IBM WAS is typically used to balance requests for applications across members of the cluster. We can also use the On Demand Router (ODR) in dynamic, multicluster environments for routing. While an application can be mapped to more than one cluster, automatic plug-in generation does not provide routing or balancing traffic for the same application across multiple clusters. Multiple cluster environments with shared applications therefore cannot rely solely on WAS automatic plug-in generation to be able to route requests using a web server. One option in this scenario is developing a customized method for defining and maintaining the plug-in configuration file used by the web server to provide for the required routing of user requests.
Parent: Set up a cluster on Solaris
Related:
Prepare to create the cluster on Solaris
Prepare a remote Web server when portal is installed on Solaris in a clustered environment
Configure WebSphere Portal to use a user registry on Solaris in a clustered environment
Prepare additional cluster members on Solaris
Configure search in a cluster on Solaris
Share database domains between clusters on Solaris