+

Search Tips   |   Advanced Search


Set up a cluster on i5/OS


Prerequisites

Technotes for installation and configuration issues
To set up your production environment on i5/OS:

  1. Prepare prerequisite and corequisite software on i5/OS

    Before creating your high availability production environment, prepare your database, the user registry, your deployment manager, and your remote Web server.

  2. Prepare your System i5

    View information on setting up your operating system for WebSphere Portal. Other components might require additional steps; see the product documentation for the specific components you want to install.

  3. Prepare the primary node on i5/OS

    Before creating your high availability environment, install WebSphere Portal on the primary node and then configure your database and your network deployment manager.

  4. Creating the cluster on i5/OS

    After installing 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. Prepare the Web server when portal is installed on i5/OS

    Configure the Web server plug-in, bundled with IBM WAS, to set up your Web server to communicate with WebSphere Portal.

  6. Prepare user registries on i5/OS

    Install and setup an LDAP server as a user registry to store user information and authenticate users in your high availability production environment.

  7. Configure WebSphere Portal to use a user registry on i5/OS in a clustered environment

    You can configure a stand-alone LDAP user registry or you can add LDAP and database user registries to the default federated repository. After configuring the 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. Prepare additional nodes on i5/OS

    After installing and configuring the primary node, you can create your secondary nodes. You must install WebSphere Portal on each node and then configure the node to access the database and user registry before adding it to the cluster.

  9. Optional: Rendering documents on i5/OS

    In order to enable document preview functionality for IBM Lotus Web Content Management and the Common Mail portlet, set up an HTML rendering server to work with WebSphere Portal. Because i5/OS does not contain native graphics support, install additional fonts to perform the document conversion required by these functions. Document conversion enables WebSphere Portal to convert documents produced by commonly used office programs into Web pages, so that they can be viewed and searched by users online. The additional fonts include an HTML rendering server known as X virtual frame buffer for the X server.

  10. Tune your servers

    WebSphere Portal is not tuned for a production environment out of the box, so to ensure optimal performance, review and complete the steps in the WebSphere Portal Tuning Guide. Even if a tuning guide is not available for the current release of WebSphere Portal, the tuning guide for the previous product version should be used.

  11. Backing up and restoring profiles

    To prevent loss of data, you can backup and restore WebSphere Portal profiles running scripts from a QShell session or scheduling scripts as part of a comprehensive backup and restore strategy. The scripts are found in the default directory /QIBM/ProdData/PortalExpress/V61/Tools.

  12. Configure search in a cluster on i5/OS

    WebSphere Portal provides two distinct search capabilities. You can utilize both types of search capabilities in a clustered environment.

  13. 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.


Parent topic:

Set up a cluster