Cluster maintenance | HCL Digital Experience
Maintaining HCL Portal in a cluster typically means applying corrective services (fix packs and interim fixes) or updating the software release level on each node in the cluster.
Fixes are classified as "minor" if they do not update the underlying HCL Portal databases or require version upgrades to other supporting software such as databases servers or IBM® WebSphere® Application Server. Most of the HCL Digital Experience service packs are not considered minor and might require the use of a separate installation procedure to ensure 24x7 availability.
Instructions for applying corrective service to a HCL Portal cluster are provided with the corrective service package. Before you apply any maintenance, analyze any user impact. Ensure that you are able to provide uninterrupted service (also referred to as 24x7 availability), even during the maintenance phase.
Minor fixes
Apply all minor fixes on each cluster node. Use the installation instructions that are supplied with the fix. When you apply minor fixes that might update previously deployed enterprise applications, first turn off the auto-synchronization feature of the deployment manager. After the fix is deployed on all cluster nodes, you can force a manual synchronization with the deployment manager to ensure that all updates are synchronized on the nodes. You can then enable the auto-synchronization feature again.
If the documentation associated with the minor fix requires that you restart HCL Portal or WebSphere® Application Server, apply the minor fix one node at a time. This process enables other nodes to continue to provide service to your users. However, if the fix requires an update to the HCL Portal databases, you might be required to stop the cluster before you apply the fix. If so, use a procedure that ensures 24x7 availability.
Fixes and service packs
There are multiple approaches to installing service packs into an HCL Portal clustered environment. Installing a service pack involves modifying the IP sprayer to remove a cluster from receiving user requests. This process allows time to finish handling existing user sessions and to upgrading that cluster on all nodes. After verification testing assures that the upgraded cluster is operational, it can start receiving production traffic while the next cluster is taken offline and goes through the upgrade process. This approach preserves complete 24x7 availability during the upgrade process.