Apply maintenance to a shared configuration server farm

In a shared configuration environment, changes made to the shared file system are visible to all farm instances instantaneously. The changes might not be activated until a portal or application instance is restarted. Such changes include IBM WebSphere Application Server configuration changes. These changes are made to the shared configuration profile or updates to shared Java resources, like JAR files in a shared library or a redeployed application. The changes can be made to the original server configuration then activated and tested on a farm server. You take the server out of workload management, restart the portal server, test the change, and then add the server back to the workload management.

When the installed product binary files are shared across multiple servers and profiles through a network-accessible file system, then there is an additional option when applying maintenance or deploying other updates such that each server can be updated independently instead of all at once. This process involves creating a copy of the original binary file system, updating the copy, then systematically switching the original shared binary files for the copy for each server being updated. This allows each server to be updated and tested independently of the other. Special setup is required for a portal farm to make future maintenance easier. These steps apply regardless of the operating system used, and therefore no operating system-specific instructions are provided. General concepts like "network shareable file systems" can be translated to any preferred operating system-specific mechanism to achieving that capability, such as through the use of GPFS, Samba, or NFS for remotely accessing a common file system.

Maintain a portal farm

It is assumed that a portal farm consists of independent portal profiles not belonging to a single cluster. The rule of updating profiles at the cluster boundary still applies: if any of these profiles contribute to a cluster, they must all be updated at the same time. Thus a cluster can be thought of a single maintainable unit within a farm. A farm might include several clusters, all sharing the same set of binary files.

1. On the file server, make a copy of the IBM WebSphere Portal file system. Make this copied file system remotely accessible just like the original.

2. On the original server, stop all appservers; for example, WebSphere_Portal.

3. On the original server, mount the copied file system in place of the original file system, at the same location. WebSphere Portal is now operating off the backup copy created in first step while all remaining servers in the farm are still running off the original file system.

4. Update and test the original server as appropriate.

5. Complete the following steps on each additional server in the farm:

   1. Stop all appservers in the local profile; for example, WebSphere_Portal.

   2. Mount the copied file system in place of the original file system, at the same location. The local profile is now using the updated product binary files.

   3. Apply the updates to the profile only. The interim fix or fix pack documentation covers how to apply updates to the profile only. This option assumes that the product binary files have already been updated.

Parent: Maintain a portal farm