Once a Natural/HA application is up and running, one of the most relevant considerations is how to apply updates with minimal impact to end users. We can distinguish between two types of updates:
Natural product updates, i.e., deploying newer versions of Natural
Natural application updates, i.e., deploying new versions of the Natural application
The following subsections offer strategies related to the above topics.
Saved Natural/HA sessions created by older Natural versions/fix levels can be taken over by newer Natural versions/fix levels. The same applies to Natural Availability Server sessions. The NWO daemon is stateless.
Therefore, updates to any of these three principal Natural/HA system components can be applied via a traditional blue-green deployment scenario. In this case, the updates are "hot-swapped", meaning that Natural/HA sessions will pick up the changes without having to be restarted.
Note:
The state server must be the same in the blue and green environments. This ensures
that any sessions saved by the blue version can be found by the green version.
The approach fow system components updates (as described above) can also be used to a limited extent for Natural application (FUSER) updates. A common scenario would be a continuous integration (CI) process, where application updates are applied frequently (e.g., every day). In the cae of a CI process, potentially involving thousands of application objects, only a small fraction is typically modified during any one CI interval.
Only the Natural/HA sessions that happen to use one of the modified objects at precisely the time of being saved are likely to be lost. All other sessions will continue unchanged, which will often be the vast majority. The worst-case scenario would be when one of the objects that is always active (e.g. the main program object) is changed, resulting in the loss of all running sessions. Nevertheless, this approach may represent a good trade-off between ease of deployment and degree of session takeover in many real-world scenarios.
This deployment strategy is a modification of traditional blue-green deployment where data traffic over an existing connection continues to be forwarded to the original ("blue") backend server for a grace period during a blue-green deployment, even though it is no longer part of the new ("green") backend pool.
In addition, and as an exception, subsequent connections for sticky sessions are typically also routed to the original backend server during this grace period. The default value for the grace period is usually long enough to allow any active Natural/HA processes in the blue environment to run to completion without the connection being closed.
The exception for sticky sessions ensures that any sticky sessions closed by the user within the grace period are not affected, even if they would not have been taken over by the green environment.
This, together with a potential improvement in responsiveness via the LINGER parameter, are two
considerations for wanting to use sticky sessions in a Natural/HA environment, despite
this not being strictly necessary.
For non-sticky sessions, connection draining does return any benefits, because a new connection is opened for each subsequent user operation. All of these operations will be directed to the "green" environment, regardless of whether the grace period has expired.