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, but may not be activated until a portal or application instance is restarted. Such changes include IBM WebSphere Application Server configuration changes that are made to the shared configuration profile or updates to shared Java resources, like JAR files in a shared library or a redeployed application. In such cases, the changes can be made to the original server configuration then activated and tested on a farm server by taking a server out of workload management, restarting the portal server, testing the change, and re-adding the server back to the workload management.
In the event that the installed product binaries are shared across multiple machines 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 binaries 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 OS used, and therefore no OS specific instructions are provided. General concepts like "network sharable file systems" can be translated to any preferred OS specific mechanism to achieving that capability, such as through the use of Samba or NFS for remotely accessing a common file system.
To 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 should all be updated at the same time. Thus a cluster can be thought of a single maintainable unit within a farm, and a farm may include several clusters, all sharing the same set of binaries.
- 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.
- On the original server, stop all application servers; for example, WebSphere_Portal and server1.
- 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.
- Update and test the original server as appropriate.
- Perform the following steps on each additional server in the farm:
- Stop all application servers in the local profile; for example, WebSphere_Portal and server1.
- 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 binaries.
- Apply the updates to the profile only. For product maintenance, the Portal Update Installer documentation covers how to apply updates to the profile only, assuming the product binaries have already been updated.
Parent
Maintain a portal farm