Set up multiple clusters on i5/OS
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 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 Deployment Manager 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. Before attempting alternative approaches for building multiple portal-based clusters within a single cell, please contact IBM.
Prerequisites
- Prepare prerequisite and corequisite software on i5/OS
- Prepare your System i5
- Prepare the primary node on i5/OS
- Prepare additional nodes on i5/OS
- Tune your servers
- Installing multiple clusters in a single cell on i5/OS
Create a new, independent WebSphere Portal cluster in a cell where a WebSphere Portal cluster already exists.
- Routing requests across clusters on i5/OS
The HTTP Server plug-in that comes with IBM WAS is typically used to balance requests for applications across members of the cluster. 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.
- Share database domains between clusters
To help provide redundancy and failover support in production environments composed of multiple clusters, you can share database domains between those clusters. WebSphere Portal data is organized into different database domains, with different availability requirements depending on how the production environment is set up. When multiple lines of production are involved and each line of production is implemented as a cluster of servers, sharing database domains ensures that the data is automatically synchronized across the lines of production.
Parent topic:
Set up a cluster on i5/OS
Previous topic:
Configure search in a cluster on i5/OS