Redundancy
  • 12 Jul 2024
  • 4 Minutes to read
  • PDF

Redundancy

  • PDF

Article summary

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.

Note:
To ensure proper redundancy, users must take the precaution of using the same versions of both the modules and bootstrap on both nodes.

Additionally, it is recommended to set up redundancy with a dedicated connection between the two nodes exclusively for this purpose. For physical nodes, use a direct physical cable; for virtual machines, use a virtual switch.


 

Your browser does not support SVG.click here to download

 


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.

01-Redundancy-configuration

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.
Warning     
The next time the nodes reconnect after the redundancy mode changes, the primary node will overwrite the backup node configuration and stored data.

Redundant Primary Node02-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.
Note
If the primary node fails to connect to the backup node before the configured standby time has elapsed, the primary node will automatically switch to active mode without carrying out data synchronization with the backup node. This could result in the loss of stored data, as well as any configuration changes that were made during the time the backup node was active.

Redundant Backup Node03-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. 

04-Database-ConsiderationsFigure 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.

 

Warning     
Once the connection with the Primary node is established, it will be necessary to force a failover in order to manually trust the certificates for the Backup node.




Was this article helpful?

What's Next