Redundancy

Introduction

Since N3uron's version 1.21, users can now easily deploy a redundant architecture. N3uron redundancy supports a 2-node system, meaning there are two copies of therunning node. One node is the Primary Node and the other is the Backup Node.

One important thing to remember about redundancy is that nodes do not have to be installed on the same type of operating system. This means that users can run the primary node on a Windows machine and install the backup node on a Linux machine.

The only precaution that users must take for redundancy to work properly is to ensure that the same versions of both the modules and bootstrap are used on both nodes.

  

Node Communication

Primary and backup nodes communicate over TCP/IP. Therefore, they must be able to see each other over the network through any firewalls that might be in place.

Configuration

As shown in the image below, the Redundancy configuration is applied in the corresponding section under This node.

Figure 1. Redundancy settings

Configuration parameters are as follows:

• Mode: 
  • Stand-alone: Redundancy is disabled and this node runs in stand-alone mode.
  • Redundant primary node: Activates the redundancy. This node is always active when available.
  • Redundant backup node: Activates the redundancy. This node stays in standby mode while the primary is available. This node switches to active when the primary is unavailable. Once the primary is available again, it switches back to standby automatically.

Redundant Primary Node

Figure 2. Redundant primary node settings

• Own certificate: Redundant nodes use encrypted communications. Own certificate is the certificate generated by this node to encrypt and authenticate these communications. Copy and paste this certificate into the redundant node's Remote certificate field.
• Remote certificate: Redundant nodes use encrypted communications. This node generates a remote certificate to encrypt and authenticate these communications. Paste here the Own certificate generated by the other node.
• Agent:
  • Server:
    • TCP port: TCP port used to listen for incoming connections from the backup node. The default value is 3002. The valid range is 1 to 65535. Make sure the port is not used by any other application on the same machine.
    • Network interface:
      • All interfaces: The server listens for connections on all network interfaces available on the host machine.
      • Localhost only: The server only listens for localhost connections.
      • It's also possible to use a custom IP address corresponding to a specific network interface.
    • Initial standby time: When the primary node is unavailable, the backup node becomes active. Once the primary node is available again, it waits for the backup node to connect and synchronize all the data generated while the primary node was down. Initial standby time is the time the primary node waits for the backup node to connect before switching to active without data synchronization with the backup node, displayed in milliseconds. The default value is 1,0000ms.

Redundant Backup Node

Figure 3. Redundant backup node settings

• Own certificate: Redundant nodes use encrypted communications. Own certificate is the certificate generated by this node to encrypt and authenticate these communications. Copy and paste this certificate into the redundant node's Remote certificate entry.
• Remote certificate: Redundant nodes use encrypted communications. This node generates a remote certificate to encrypt and authenticate these communications. Paste here the Own certificate generated by the other node.
• Agent:
  • Connection:
    • Host: Hostname or IP address to connect to the primary node.
    • TCP port: TCP port to connect to the primary node. The default value is 3002. 
    • Connection timeout: Time to get a valid response from the primary node, displayed in milliseconds. The default value is 5000.
    • Reconnect delay: Time to reconnect after disconnection or a failed connection, in milliseconds. The default value is 1000.

Historian Database Considerations

In N3uron, whenever you create a Historian module instance, it will default to pointing to the MongoDB database embedded in the N3uron installer. However, internal databases are not synchronized, therefore an external database must be used for historical data storage. 

Figure 4. Configure an external database

Links Considerations

When connecting a remote node to a redundant pair of nodes via Links, it is necessary to utilize the Redundancy Agent for configuring communications, as depicted in the images below. In this example, port 301 has been used.

The Redundancy Agent module listens on a local port and forwards the incoming traffic to the redundant connections. Therefore, we must configure the Link to point at the localhost address and port we previously configured.