NoMachine - Usecases

There are 3 major usecases for NX / nomachine at PSI (usecase details see below):

Desktop Access
Terminal Server (e.g. Ra, Merlin, nomachine-proxy)
Remote Access (nx.psi.ch)

Desktop Access

NX is used to connect to and/or create physical/virtual desktop session(s) on a machine. The access is always from a node within the PSI network (PSI intranet, nodes connected via VPN, ...) The two major usecases are:

create a new session
connect to existing session (e.g. to support users)

An advantage of nx is that it can be used for Windows and Linux systems alike. It provides a consistent way to connect to the remote desktop.

Terminal Server

In the terminal server usecase people want to create private virtual sessions on a terminal server (cluster). These sessions are persistent unless they are intentionally closed by the user.

This usecase covers:

CAD Workstations (Jens Ehler)
nomachine-proxy
ra-nx
merlin-nx

nomachine-proxy

nomachine-proxy is a service for whole PSI. It is usually used as a bridge between Windows consoles and Linux world. The main user (historically and by need) is GFA. They usually use this service to ssh to other computers to open applications for monitoring/steering the GFA accelerators.

nomachine-proxy was a replacement of gfa-nx service, the main purpose was as a bridge between Windwows desktops and the Linux world. From the beginning it was postulated that nomachine-proxy nodes will be small virtual machines, that users shouldn't use for computational intensive purposes. The amount of software on the nodes will be "reasonable" for purpose of interactive work (editing small files, browsing internal pages, jumping to other hosts etc..). We added few software on user requests: https://gitea.psi.ch/puppet/data-lx

Since user can't choose which node to login via nomachine, user home is shared on all these nodes(from netapp), with a very small quota (this is usually a problem for users, since they use firefox on that nodes and cache occupies that quota):

$ quota -s
Disk quotas for user ozerov_d (uid 36871):
     Filesystem   space   quota   limit   grace   files   quota   limit   grace
nmh01.psi.ch:/nomachine/home
                   217M    750M   1500M            2363   4295m   4295m

Dimas idea was to merge nomachine-proxy with the llc "cluster". But llc was replaced by login cluster, which runs without graphical access.

nodes provide a minimal desktop with a browser but no additional tools

merlin-nx

merlin-nx is used by internal and external users. The main usecase is for preparing jobs, submitting jobs, post-processing and visualization to the merlin cluster. Some applications are pretty heavy if they have to open it through SSH with X11 forwarding, NoMachine is mainly used for such use cases instead. But also there are users using the Merlin desktop as their daily way of working (even for submitting command line based jobs). 3D acceleration is a common use case for visualization, therefore, GPU card is in general preferred.

Typical X-based software used in NoMachine are ANSYS, Relion, Paraview, Matlab and Gothic. Using NoMachine for submitting jobs (allocations) with X11 forwarding to the cluster it's also commonly used (ANSYS, Paraview).

Sometimes, users use it to transfer files. Users are told to avoid this for massive transfers or for doing it in a regular basis, but despide that some use it anyway for transferring a few files from time to time.

Some users are using the nodes to transfer files between Merlin and Windows shares.

The commonest access to merlin-nx is from within PSI network but remote access is increasing and important.

NoMachine is a service used daily by many users.

ra-nx

ra-nx is use by both, external and internal users. For some users it is just a replacement of ssh (not everybody feels comfortable over a terminal) but in general it is for visual tools (Matlab, fiji, Paraview and other visual tools). Login nodes have a pretty decent accelerated video card to support on this.

Sessions are accessed from both, within PSI and through the remote access service (nx.psi.ch)

Users always expect it to be up and running.

Remote Access (nx.psi.ch)

The stakeholders of the remote access service can be found in https://gitea.psi.ch/nomachine/nomachine_ansible

This service is typically used by beamline users to conduct their experiment from remote. Also it is used by beamline staff to help at (support experiment), monitor and work at the beamline .

The most critical usecase is the access to beamline consoles. A lot of experiments at SLS are running remotely, so users steering/running experiment from the outside. It's extremely critical and time-to-solve issue is certainly within the hours (some experiments(MX) has only one shift to take data (8 hours), so if users can't access consoles at all - it's 100% failed). Most important users to complain/to listen too - are beamline scientists/managers, who usually calls in case of problems.

The remote access server serves as a single point of entry for remote desktop sessions. Beamline staff can (dynamically) grant remote access to people on demand by the rama service. No VPN, Tunneling and jumping over firewalls is needed to access the desktop sessions.

5.2 KiB Raw Permalink Blame History