Terminology

The following terminology is used in the Natural/HA documentation.

Natural/HA

Natural/High Availability. The "/HA" suffix intends to emphasize features only relevant to a high availability (HA) context.

HA Mode

The mode of operation of Natural required to support high availability. This is set in the configuration of the Natural Web I/O (NWO) Interface Daemon responsible for starting Natural processes.

Natural/HA Application

A Natural application running in high availability (HA) mode.

Natural/HA Session

A running instance of a Natural/HA application. Each session has its own unique session ID.

Active Natural/HA Session

A Natural/HA session that is currently processing an operation requested by the user.

Inactive Natural/HA Session

A Natural/HA session that has finished processing the last requested operation and is currently waiting for the next user input.

Saved Natural/HA Session

An object representing the state of an inactive Natural/HA session residing on the state server. These saved objects have a base name containing the session ID and the extension .nssd (Natural saved session data). These objects expire by default, after a user-configurable period determined by the SSTTL parameter. Expired objects are eligible for automatic removal at any time for state servers supporting this functionality. This prevents obsolete (e.g., orphaned) sessions from continually building up on the state server over time.

Natural/HA Session Schema

An object representing the data structure of a saved Natural/HA session. Although the actual data values and their number of occurrences can vary wildly from session to session, the structure of the data is constant for a particular Natural/HA version and fix level.

Storing this information in a separate schema object avoids repeating this information in each saved Natural/HA session object, allowing the latter to become much more compact.

Session schemas are stored in objects of proprietary format with the extension .CXSD (Compiled XML Schema Description). The native session schema (NATURAL.CXSD) is stored in the resource (RES) directory of the FNAT SYSTEM library and is cached and accessed via the buffer pool. For this reason, it should be present in the preload list when setting up a read-only buffer pool for a Natural/HA application.

Note:
Session schemas are also stored on the state server, under a versioned name, depending on the Natural version and fix level to which it corresponds. This allows saved Natural/HA sessions to be taken over by a different version of Natural than the version that created them, facilitating blue-green deployment. Unlike saved Natural/HA sessions, Natural/HA session schemas never expire on the state server.

Natural/HA Process

The operating system's process that is currently hosting an active Natural/HA session for the purpose of processing an operation requested by the user.

After the processing of this operation has completed, the state of the Natural/HA session is saved, and the process terminated after a user definable LINGER time has expired. When the next user operation is requested, the lingering process (if still available) is re-used, or a new process (potentially on a different backend server) is instantiated and the previously saved Natural/HA session restored into it.

Note:
While the Natural/HA session is inactive (see above), it is not being hosted by any process on any backend server. This differs from the traditional non-HA behavior, where a Natural/HA session is hosted by a single process for its entire lifetime.

Backend Server

A single node belonging to a cluster (or pool) of server nodes accessed by a browser-based frontend via a load balancer. Each backend server typically contains an application server hosting the Natural Availability Server, the NWO daemon (used for instantiating Natural/HA processes), and Natural/HA itself. In Natural/HA production environments, at least two backend servers are required to continue to serve the Natural/HA application should one of the servers become unavailable for any reason.

State Server

The configured location where the state of inactive Natural/HA sessions or Natural Availability Server sessions are saved. This location must be accessible to all backend servers. In addition, this location must provide high availability when used in a production environments, so as not to itself become a single point of failure (SPOF). For example, a REDIS© Enterprise database in the Cloud fulfills these requirements.