Set up a cluster on Solaris

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 Solaris operating system in a clustered environment
  View information on setting up the operating system for IBM WebSphere Portal.
• Prepare the primary node on Solaris
  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 Solaris
  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.
• Prepare to create the cluster on Solaris
  If you installed a IBM WAS Network Deployment, create a static cluster to handle failover requests. If you installed a IBM WebSphere Virtual Enterprise, create a dynamic cluster to balance member workloads.
• Prepare a remote Web server when portal is installed on Solaris 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.
• Configure WebSphere Portal to use a user registry on Solaris 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 Solaris
  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.
• Solaris 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 IBM WebSphere 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 Solaris
  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 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.
• Share database domains between clusters on Solaris
  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 Solaris