Set up a cluster on IBM i
Clusters enable you to scale the IBM WebSphere Portal configuration. Clusters
also enable enterprise applications to be highly available because requests are automatically routed to the running servers in the event of a failure.
The multiple servers configuration reduces single points of failure, but requires more hardware, such as additional servers. The multiple profiles configuration also reduces single points of failure; it requires less additional hardware than the multiple servers configuration but you may still need more hardware such as additional memory. The dmgr manages a cell for horizontal cluster nodes.
To conserve hardware, we can also set up vertical cluster members on a single node. Typically, large portal clusters include both horizontal and vertical scaling;
In response to customer requests, the instructions to setup WebSphere Portal has been improved to provide operating system specific instructions for setting up a production environment. Select the operating system to get started.
- Prepare the IBM i operating system in a clustered environment
View information on setting up the operating system for IBM WebSphere Portal. - Prepare the primary node on IBM i
Before creating your clustered environment, install IBM WebSphere Portal on the primary node and then configure the database and the network dmgr. - Create and augment a new dmgr profile on IBM i
For a production environment you should install the dmgr on a server that is remote from the portal installation. Use the pmt.sh or the manageprofiles.sh to create the remote dmgr profile. In a test or dev environment, we can install the dmgr locally using the Installation Manager. Skip these steps if we are using the Installation Manager to install a local dmgr profile on the primary node. - Create the cluster on IBM i
After installing IBM WebSphere Portal on the primary node, configuring a remote database, and preparing the primary node to communicate with the dmgr, we can create the static cluster to handle failover requests. - Prepare the Web server when portal is installed on IBM i in a clustered environment
Install and configure the Web server plug-in, provided by IBM WAS, to set up your Web server to communicate with IBM WebSphere Portal. - IBM i cluster: Prepare user registries
Install and set up an LDAP server as a user registry to store user information and authenticate users in your clustered environment. - Configure WebSphere Portal to use a user registry on IBM i in a clustered environment
Configure user registry security on IBM WebSphere Portal to protect the server from unauthorized users. Configure a stand-alone LDAP user registry or we can add LDAP user registries and/or database user registries to the default federated repository. After configuring your user registry, we can add realms for Virtual Portals or a lookaside database to store attributes that cannot be stored in the LDAP user registry. - Prepare additional cluster members on IBM i
After installing and configuring the primary node, we can create the additional cluster nodes. Install IBM WebSphere Portal on each node and then configure the node to access the database and user registry before adding it to the cluster. - IBM i cluster: Tune the servers
Tuning the servers is important to the performance of the WebSphere Portal environment. WebSphere Portal is not tuned for a production environment out of the box. To ensure optimal performance, review and complete the steps in the Portal Tuning Guide. If a tuning guide is not available for the current release, the tuning guide for the previous product version should be used. - Configure search in a cluster on IBM i
IBM WebSphere Portal provides two distinct search capabilities. We can use both types of search capabilities in a clustered environment. - Set up multiple clusters on IBM i
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. - Share database domains between clusters on IBM i
To help provide redundancy and failover support in production environments composed of multiple clusters in a single cell and multiple clusters in different cells, we can share database domains between those clusters. IBM 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: Install on IBM i