This document is intended to provide general guidelines on how to route traffic using an external hardware load-balancer or DNS load balancing service to multiple globally-distributed NoMachine Cloud Servers, and how to dispatch user connections to multi-level servers.
Adopting an external load-balancing device or service enables i) balancing of traffic among multiple NoMachine Cloud Servers, which are all at the same level in the hierarchical infrastructure and independent from one another and ii) the routing of users to a specific Cloud Server according to the user's geographical location.
Each Cloud Server can be parent of a number of NoMachine servers (children) and foreign X servers (Unix-like hosts for which a native NoMachine software package is unavailable) and apply its built-in forward capacities to route the user's connection towards the appropriate child server. All of these servers can be children of multiple Cloud Servers. In this way service uptime can be maintained by switching the point of access to the alternative Cloud Server should the first choice of Cloud Server be unresponsive for whatever reason.
Let's see some examples.
The following infrastructure schema adopts:
- one external load-balancer in charge of routing the user to the most appropriate Cloud Server
- three NoMachine Cloud Server systems: Cloud Server Europe, Cloud Server America and Cloud Server Asia.
They are all at the same level and constitute the front-end servers as access points to the underlying hosts where users will run their NoMachine sessions. Such underlying hosts are children of two (of the 3) Cloud Servers: one is the first choice access point to each subsystem, the other one is the second choice.
The external load balancer is in charge of load-balancing traffic among the front-end servers (Cloud Server Europe, Cloud Server America and Cloud Server Asia) for example by assigning the server according to the client geographical location. I.e., All connections coming from Europe will be routed to Cloud Server Europe.
For redundancy, all children (first-level servers in the hierarchy) of Cloud Server Europe are also children of Cloud Server America. In a similar way, all children of Cloud Server America are also children of Cloud Server Asia, and children of Cloud Server Asia are also children of Cloud Server Europe. So, if parent Cloud Server Europe is no longer reachable on the network for any reason, users can still access its children via Cloud Server America. I.e., if Cloud Server Europe is not reachable, connections from Europe will be routed to Cloud Server America. Both Cloud Server Europe and Cloud Server America are configured to forward European connections to the correct underlying server subsystem.
Each Cloud Server (CS) is parent to its own NoMachine Enterprise Desktop (ED), Workstation (WS) and Enterprise Terminal Server (ETS). Each CS manages the incoming user connection and forwards it to a child server. Profile rules can be applied to each CS for handling user forwarding to the right server.
Each Enterprise Terminal Server is the single point of access to its own subsystem made of Terminal Server Nodes (TSN). ETS controls the profiles used to access its TSN hosts and is able to automatically distribute sessions among them (load-balancing).
This second example shows multiple set-up options, including the possibility to organize multiple Cloud Servers in a hierarchical drill-down fashion.
By considering that each NoMachine server is a subsystem on its own, there are no limits to how the infrastructure can be assembled. Different NoMachine servers can be composed to create a unique hierarchy of NoMachine servers based on specific requirements. This provides a very high degree of flexibility and allows for unlimited scalability.
These are some important considerations when setting-up the infrastructure. You can:
- Place any server type (except NoMachine free) under a Cloud Server.
- Add as many Terminal Server Nodes as you need under an Enteprise Terminal Server, then add the ETS to a Cloud Server
- Use the built-in failover cluster of NoMachine with two Cloud Servers and also two Enterprise Terminal Servers.
- Optionally use an external load-balancer when it's necessary to route the traffic to multiple Cloud Servers which in turn are a single point of access to separate NoMachine infrastructures.