(ZOS) Application update procedure in a high availability environment
Application update involves distributing new application binaries to each of the servers in a cluster during configuration synchronization.
Figure 1. Application steady state - configuration view. This figure illustrates the configuration view of an application in steady state.
This distribution occurs via HTTP and happens even if the servers and the deployment manager are all located on the same LPAR. If the synchronize with nodes option is checked when the application update is saved, the synchronization request is sent to each node.
Normally, upon receiving the request, each node asynchronously orchestrates the synchronization process with the deployment manager. During this synchronization process, the application's binaries are downloaded from the deployment manager and stored on the node in the designated location (for example, installedApps).
The act of storing the new binaries triggers a configuration change event listener which then stops and restarts the application. Depending on such variables as dispatcher behavior, LPAR weighting, etc., a variance in the order and pace at which each server makes the new application available may be observed.
Because of the concurrent, asynchronous nature of node synchronization, continuous availability of the application being updated is not guaranteed. This is because there is no correspondence between the actual state of the application and the workload routing mechanisms. Client requests may be routed to a server even if that particular application is temporarily unavailable.
In a high availability environment, an application must remain available even during an update process. Therefore, application rollout to each cluster member, as well as workload routing to the cluster members must be carefully controlled to prevent workload from being routed to a cluster member that is undergoing the update process. When these two aspects are carefully controlled, an update can be installed on each cluster member without client requests arriving at a cluster member during the update process.
Related: