There are some products as x2go and FreeNX (which isn’t longer available) that were designed to provide Remote Desktops to users. A month ago I was required to setup NoMachine (the paid version of FreeNX) also known as «!M or NX».  In this document I leave the configuration of the product, administration commands and knowledge I’ve acquired in order to make it work.

NoMachine Terminal Server (cluster and multinode environment)

Basically your remote desktop client will be «NX CLIENT» that can be installed in both, Linux or Windows.

In this infrastructure model we have:

  • Two terminal servers acting as a cluster (One Primary and one Secondary)
    • The NX Clients will be connected to the T.S, in this model you aren’t able to connect to the nodes directly (there are other ways of configuring NoMachine to allow this but not in cluster mode.)
  • Several Nodes were the session of the clients will be created
    • Those nodes are balanced automatically by the NX Terminal Servers (default is round robin)
  • A remote desktop (were the client will be connected and will start a graphical interface)
  • A computer/laptop/RaspberryPi  that acts as client

When a fail-over occurs

When you shutdown, reboot or for some reason your primary server (where your clients are connected in first place) dies, the NX Client will automatically reconnect to the secondary server. It will take sometime to do it (less than a minute or the time you setup in the cluster options) and a new session will be established against our Secondary Server.

In this scenario, because we had enabled the session persistence we were able to recover our previous session with all the applications opened.

Here is the main guide to setup the cluster from the NX Team.

To consider (if you enable the session persistence) this setting must be applied on server.cfg on both NX Terminal Servers:

No Machine Administration commands

NoMachine Cluster multinode environment server.cfg

Be careful, inline comments are not available in this configuration file, that would lead to errors, for example:

Would be an error. The product may not start or act erratically. This is an example of my configuration server.cfg for a Terminal Server in cluster with multinode environment and session persistence, have in mind that cluster configuration isn’t stored in this file, for that refer to this guide.