Setting up a cluster on IBM i

Clusters enable you to scale your 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. There are numerous cluster configuration, such as horizontal, vertical, multiple, and dynamic.

About this task

The following illustration depicts a horizontal cluster configuration where WebSphere Portal is installed on multiple servers or on multiple profiles within the same physical server. 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 deployment manager manages a cell for horizontal cluster nodes.

The browser client and web server are on the front-end while the LDAP server and database server are on the back-end.

To conserve hardware, you can also set up vertical cluster members on a single node. Typically, large portal clusters include both horizontal and vertical scaling; for instance, you may have four portal nodes and each of those nodes may contain five cluster members for a total of twenty cluster members.

The browser client and web server are on the front-end while the LDAP server and database server are on the back-end.

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 your operating system to get started.

  1. Preparing your IBM i operating system in a clustered environment
    View information on setting up your operating system for IBM WebSphere Portal. Other components might require more steps; see the product documentation for the specific components you want to install for information.
  2. Preparing the primary node on IBM i
    Before creating your clustered environment, you must install IBM WebSphere Portal on your primary node and then configure your database and your network deployment manager.
  3. Creating and augmenting a new Deployment Manager profile on IBM i
    For a production environment you should install your Deployment Manager on a server that is remote from your IBM WebSphere Portal installation. Use the Profile Management Tool or the manageprofiles command to create the remote Deployment Manager profile. In a test or development environment, you can install your Deployment Manager locally using the IBM Installation Manager. Complete the steps to creating and augmenting a new Deployment Manager profile if you are installing a remote Deployment Manager profile. Skip these steps if you are using the Installation Manager to install a local Deployment Manager profile on your primary node. A remote Deployment Manager profile is on a server that does not contain a WebSphere Portal installation.
  4. Creating 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 Deployment Manager, you can create your static cluster to handle failover requests.
  5. Preparing 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 WebSphere Application Server to set up your web server to communicate with IBM WebSphere Portal.
  6. IBM i cluster: Preparing user registries
    Install and set up an LDAP server as a user registry to store user information and authenticate users in your clustered environment.
  7. Configuring WebSphere Portal to use a user registry on IBM i in a clustered environment
    Configure user registry security on IBM WebSphere Portal to protect your server from unauthorized users. You can configure a stand-alone LDAP user registry or you can add both LDAP user registries and database user registries or database user registries to the default federated repository. After you configure your user registry, you can add realms for Virtual Portals or a lookaside database to store attributes that cannot be stored in the LDAP user registry.
  8. Preparing additional cluster members on IBM i
    After installing and configuring your primary node, you can create your additional cluster nodes. You must 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.
  9. Configuring search in a cluster on IBM i
    IBM WebSphere Portal provides two distinct search capabilities. You can use both types of search capabilities in a clustered environment.
  10. Setting 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 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.
  11. Sharing 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, you 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 topic: Installing on IBM i
    • Related tasks:
  • Secondary node fails to start after being added to the cluster with javax.jcr.RepositoryException exception

    • Related information