The following diagram displays the main components involved in a Natural/HA installation:
Note:
The keen eye may have noticed that Natural is missing on the right hand side of the
diagram ("Datcenter 2"). This illustrates the fact that Natural/HA processes are
created on-demand and only exist temporarily. See below for more information.
A Natural/HA installation consists the following components:
Browser
Load balancer
Two or more backend servers containing the following components:
o Application Server (e.g., Tomcat) / Natural Availability Server (see
Natural Availability
Server)
Natural Web I/O (NWO) Interface Daemon
Natural
State Server (REDIS©)
The browser runs on the user’s client machine and displays the user interface for the Natural application. The user interface is provided by the Natural Availability Server running on the application server (e.g., Tomcat) on one of the backend servers, as chosen by the load balancer.
The Natural Web I/O (NWO) Interface Daemon is responsible for starting Natural processes and must be configured to start in HA mode (see Installing and Configuring the Natural Web I/O Interface Server) in order to create Natural/HA processes (i.e., Natural processes running in HA mode).
Unlike a traditional Natural process, a single Natural/HA process does not exist for the lifetime of the Natural application, but terminates itself whenever it needs to perform any interactive I/O. Before doing this, it saves the state of both the Natural system and Natural application on the state server. sTthe next time a Natural/HA process is created for the same Natural/HA session, and potentially running on a different backend server, it can reload the saved state and continue from where it left off.
As a resource-friendly consequence of this design, no corresponding Natural/HA process is running on any backend server while the browser is waiting for user input.
Once the user submits input, the Natural Availability Server starts a new Natural/HA process via the NWO interface daemon and processes the user request. After the user request is processed and screen data is returned to the Natural Availability Server, the Natural/HA process saves its state and terminates. This process continues until the Natural/HA session is completed.
The previous paragraph describes the basic operation, which can be optimized via the use
of the LINGER parameter. If this
parameter is set to a non-zero value, the Natural/HA process, after having saved its
state, does not terminate itself immediately. Instead, the process waits for any possible
new input from the Natural Availability Server for a specified amount of time before
terminating.
This allows the Natural Availability Server to re-use the lingering Natural/HA process instead of starting a new one via the NWO interface daemon if the lingering process handled the last user request. This is always the case if the same backend server is selected by the load balancer for any particular Natural/HA session.
Lingering implies the use of sticky sessions. As upside of this constraint, lingering processes may improve application responsiveness significantly. Although lingering increases the number of processes running on the server side, in the case of Natural, these lingering processes do not consume significant CPU resources. For the application, the performance advantage may outweigh the penalty on the CPU's resource.
Note:
The state server is used by both Natural and the Natural Availability Server and needs
to be configured separately for both components, although both can refer to the same
location (e.g., REDIS© Enterprise database).