Why use Natural/HA?

#### Search Results

Search

# Why use Natural/HA?

Previous versions of Natural (prior to version 9.3.1), and in conjunction with Software AG's ApplinX, were able to offer high availability to a certain extent.

This has been improved significantly by Natural/HA in the following areas:

- Natural/HA provides failover capability.

  In case the backend server that is hosting the application fails, with Natural/HA it is possible to transfer the application to a different backend server.

  In previous versions, users received an error in this situation and had to restart the application.

  In contrast, a Natural/HA application supports failover by virtue of being able to implicitly save its state and reload it into a different process that could even run on a different backend server.

- Previous versions of Natural running on a backend server required a permanent connection for the duration of the user session, which could easily be for hours or more in typical real-world scenarios. This meant that if a backend server needed to be removed from the cluster, for example for maintenance reasons, the Natural processes running on the backend server would simply not drain in any reasonable amount of time. As a consequence, the server would go down and take most of the Natural processes with it.

  In contrast, a Natural/HA process for a particular user session only exists on the backend server while it performs an application's function that is triggered by the user (e.g., in response to <Enter> or any function key). Since these requests typically return to the user within a few seconds at most, connections can drain very quickly. Once this happens, the backend server can be taken down without any users being impacted.

- Natural/HA processes only exist briefly, to carry out a function requested by the user. This means that comparatively few Natural/HA processes are active at any given time.

  In real-world scenarios of interactive applications, most of the time is spent waiting for user input. Having fewer processes running on the server not only reduces resource demand, but also results in less potential for negative side-effects, in the event of a system failure with processes not terminated gracefully.

- Because previous versions of Natural did not provide any failover capability, sessions previously had to be "sticky". The load balancer forwarded the requests for a particular user session to the same backend server. With Natural/HA, this is no longer mandatory.

  Furthermore, even when sticky sessions are optionally used with Natural/HA (e.g., to increase application responsiveness), these are sticky sessions with failover, rather than (as in previous versions) sticky sessions without failover. A huge advantage should the backend server become unavailable.

- Natural/HA provides a high degree of flexibility for performing blue-green deployment:

  This version of Natural/HA can take over user sessions from older versions. See the section Blue-Green Deployment of Natural/HA System Component Updates for more information.

- In addition to blue-green deployment, Natural/HA allows to modify Natural application libraries (FUSER) in place, while leaving the processing of most user sessions unaffected. See the section Blue-Green Deployment of Natural/HA Application Updates for more information.