This article applies to a multi-node environment made of a main server (server) and a pool of nodes (node A, node B, ...) where the NoMachine software is installed. If the server is configured to run sessions on localhost, this article applies also to the communication between server and its local node.

It doesn't apply instead to the so called 'foreign nodes', i.e. those Unix-based hosts which are part of a NoMachine multi-node environment but where the NoMachine software is not installed (see also https://www.nomachine.com/FR10K02777).

How the node is selected

When the user connects and authenticates to the server, the node where to start the session may be choosen in three ways:

1) By using the automatic load-balancing algorithm (for Linux nodes supporting virtual desktops only) 

2) By manually selecting the node.

3) By load-balancing or manual node selection.

The client requests the session type (specified by the user) to the server, the server creates a  pool of nodes choosing those nodes where the requested session type is available. Based on its configuration, the server provides to the end-user option 1), 2) or 3).

See also: https://www.nomachine.com/FR12M02988 for further details about this implementation and refer to the server administrator's guide for more instructions to configure the server for providing 1), 2) or 3): https://www.nomachine.com/DT07M00091#10

How the user authenticates on the remote node

User needs to have the same system account (username) on the main server and on the remote node. It's not necessary that the account has the same password on the node or the public key for user's key-based authentication is set there.

Password (or any other authentication method such as private key or Kerberos ticket) is used to authenticate the user on the server. Connection between server and remote node is authenticated by using the public key set during the 'nxserver --nodeadd' procedure. The server always acts as a supervisor of its remote nodes. Note that this happens also when the node is locale to the server.

How the client-remote node connection is established

The client always connects to the server. This connection is then forwarded to the remote node, the client is never connected directly to the remote node.
 

How to configure the virtual desktop on the remote node

The virtual desktop is started on the node based on the configuration set in the node.cfg file of the remote node.

By default it will be started the desktop environment defined in the DefaultDesktopCommand key. This means that on different nodes it is possible to have different desktop environments.

How many nodes a single server can handle

All the client traffic is routed by the NoMachine server to the nodes, increasing the number of nodes and/or the number of concurrent connections requires higher HW resources (RAM and CPU) on the server host.

How to forward users' connections to multiple servers

NoMachine server supports the 'redirect' functionality which allows to redirect the connecting user in base of its client IP or username.
See the server administrator's guide for more details and instructions: https://www.nomachine.com/DT07M00091#16

For larger environments implementing sessions by web, another possibility is to federate multiple Enterprise Servers under a single server which acts as entry point.

In this way each Enterprise Server handles a pool of nodes and it's possible to have separated multi-node environments but still a unique server where users connects. See also: https://www.nomachine.com/DT07M00096

Up to version 5 only the Cloud Server provides web access and can be used to federate Enterprise Servers.
 

Some benchmark results from tests in our labs

These tests refer to a Cloud Server installation.

Case 1
- 1 Enterprise Server with 24 CPU and 400 GB of RAM
- 40 Terminal Server Nodes with 8 CPU and 30 GB of RAM per node

This multi-node environment supports up to 100 virtual desktops for each node for a total of 4000 concurrent virtual desktops.

Case 2
- 1 Enterprise Server with 12 CPU and 200 GB of RAM
- 20 Terminal Server Nodes with 16 CPU and 60 GB of RAM per node

This multi-node environment supports up to 200 virtual desktops for each node for a total of 4000 concurrent virtual desktops.

Case 3
- 1 Cloud Server dual-core CPU, 8 GB RAM
- 10 Enterprise Servers federated under the Cloud Server. Each Enterprise Server has 24 CPU and 400 GB of RAM.
- 40 Terminal Server Nodes are associated to each Enterprise Server (10 separated multi-nodes environments). Each Terminal Server Node has 8 CPU and 30 GB of RAM.

Each node will supports up to 100 virtual desktops. This means that each Enterprise Server (which owns 40 nodes) will handle up to 4000 virtual desktops for a total of 40.000 virtual desktops spread across the 10 multi-node environments ruled by 10 Enterprise Servers.

Users will access the system by a single entry point, the Cloud Server.

NOTE: tests were made with a GNOME 2 desktop environment. Running for example Unity desktops would require more RAM. CPU requirements strictly depends on the applications run in the session.