Configuring Nodes (Legacy)

We refer to each separate instance of NXRM in a high availability cluster as a node. Nodes can run on physical or virtual servers, containers, or cloud services like Amazon Web Services EC2 instances. While multiple nodes can exist on the same physical or virtual server, each bound to different ports for testing purposes, but such a setup is discouraged in production as it does not provide for a redundant clustered environment.

Each node needs its own local storage for the $data-dirfolder. This folder must not be shared by any other node in the cluster. Within the local storage, a node will store:

In addition, all nodes need shared storage for blob stores.

NXRM HA-C is intended for use with 3 nodes. It will not work properly with less than 3.

Any node can accept a write, but for the write to be committed it must be replicated to a 'majority' of available running nodes. OrientDB calculates a majority using the following formula: (number of expected running nodes / 2) + 1

A write (e.g. publishing assets, changing system configuration) will fail if nodes in your cluster unexpectedly lose connectivity or die and fewer than the calculated majority are running. However you can still write to your NXRM HA-C environment with only 1 running node as long as the other members of the cluster have either a) not started yet or b) were shutdown cleanly. The NXRM HA-C feature includes monitoring for this condition and controls to help you get your cluster running again.

NXRM HA-C uses Hazelcast to keep the OrientDB databases completely in sync in an "Active-Active" configuration.

The ElasticSearch indices on the running nodes operate independently and do not share data; they do automatically index all content replicated in OrientDB.

Blobs, the assets (.jar, .xml, .tar.gz, docker images, etc.) in your repositories, are not replicated. They are stored in your blob stores.