Skip to content
Try Now

Back to Articles

FastX 5 Clustering Guide

FastX is a platform for creating, managing, and connecting to Virtual Display Sessions (sessions) on remote Linux systems.  Multiple systems can be run individually as standalone systems, but the real power comes from when those systems are linked together into a cluster.  Clusters allow administrators to centrally manage multiple systems, create single entry points into the cluster event behind a firewall, Load Balance systems to allow even distribution of work, and many other features simplifying and improving the user experience.

Installation

Recommended

Requirements

  • FastX activation key
  • RHEL 9 or higher (ARM systems require RHEL 10) or Debian Equivalent
  • Each Node needs its own $FX_LOCAL_DIR, and $FX_TEMP_DIR
    • $FX_LOCAL_DIR may be mounted. Default is /var/fastx-local/.
    • $FX_TEMP_DIR must not be mounted. Default is /tmp/.
  • Minimum required packages:
    • RHEL: xauth perl python3 curl nodejs libfontconfig1 libgl1-mesa-dev libglu1-mesa-dev mesa-common-dev libharfbuzz0b
    • Debian: xauth perl python3 curl nodejs fontconfig mesa-libGL-devel mesa-libGLU-devel harfbuzz
  • NodeJS 22 or later
  • FastX Server
  • FastX Transporter
    • Debian: apt-get install fastx-nats
    • RHEL: dnf install -y fastx-nats

Set up the Head Nodes

These are the nodes that your users will connect to. Typically the License server and the transporter are installed on these nodes. Users may or may not be able to launch sessions on these nodes

#  RHEL Systems
sudo dnf install -y fastx5-server fastx-nats

# Debian systems
sudo apt-get install -y fastx5-server fastx-nats

Configure this node to be a Head Node
Copy /etc/fastx/transporter-secret.ini to your compute nodes and restart the server


Set up the FastX Nodess

#  RHEL Systems
sudo dnf install -y fastx5-server

# Debian systems
sudo apt-get install -y fastx5-server

Configure this node to be a Compute Node
Copy the /etc/fastx/transporter-secret.ini from the head node and restart the server

Node Configuration

Each node (head or compute) can be configured for different roles.

  1. Log in to your node as a fastx administrator
  2. Click on the Admin button (gear icon)
  3. Click on Webserver > Settings

You can also configure the roles manually by setting up specific services in the SERVICES variable or /etc/fastx/fastx.env

See Cluster Installation Patterns for more advanced setups

Node Types

The configure server dropdown menu has the typical node configurations

In a typical cluster installation

Head Nodes: Use Head Node
Compute Nodes: Use Compute Node

image
image
  • Standalone Server/All Services — Default Configuration. All Services are installed. Use this on your head nodes if you want to launch sessions on the head nodes
  • Head Node — Users can log in, but not launch sessions (typically for cluster head nodes)
  • Compute Node — Users launch sessions on these nodes
  • Compute Node With Authentication — Users launch sessions on these nodes. (Required if using Gateway Node Without Logins)
  • Manager — Rarely Used.

Notes on Services

FastX is divided into a different services that work together within the cluster. Each cluster MUST contain all services for a cluster to function properly, Here is a description of what each service does

  • webserver — Runs the http server. Users connect to this server
  • manager — Holds the session states and other configuration
  • user — Authenticates users and holds user information
  • launcher — runs the start command to start sessions, and sessions connect back to this system

The socket and forward services are helper services that allow communication. They are automatically configured if webserver or launcher are set

When configuring using /etc/fastx/fastx.env set SERVICES ro a comma separated value as follow

SERVICES=webserver,manager,user,launcher

Mounting /var/fastx

Nodes with the user service need to be synced to keep the user data stable across the cluster. The simplest solution is to simply NFS mount the directory. There are also programs such as syncthing that can solve this issue


NATS Transporter

The transporter uses the NATS protocol for fast and efficient transport.

The /etc/fastx/nats-server.conf file configures the NATS transporter.

The authorization token in /etc/fastx/nats-server.conf MUST MATCH the token in /etc/fastx/transporter-secret.ini

/etc/fastx/nats-server.conf

Here is a typical setup of /etc/fastx/nats-server.conf

authorization {
    token: "$2a$11$PWIFAL8RsWyGI3jVZtO9Nu8.6jOxzxfZo7c/W0eLk017hjgUKWrhy"
}


# Client port of 4222 on all interfaces
port: 4222

authorization {
   token: thisisasecret
}
tls {
  cert_file: /etc/pki/tls/certs/fedora-self.nats.crt
  key_file: /etc/pki/tls/private/fedora-self-key.nats.txt
}
# This is for clustering multiple servers together.
cluster {
  # Route connections to be received on any interface on port 6222
  port: 6222
  # Routes are protected, so need to use them with --routes flag
  authorization {
    user: ruser
    password: T0pS3cr3t
    timeout: 2
  }
  # Routes are actively solicited and connected to from this server.
  routes = [
    nats://10.211.55.9:6222,
    nats://10.211.55.4:6222,
    nats://10.211.55.8:6222
  ]
}

NATS supports clustering and high availability. Edit the /etc/fastx/nats-server.conf to enable clustering according to the configuration documentation.

https://docs.nats.io/running-a-nats-service/configuration/clustering/cluster_config
https://docs.nats.io/running-a-nats-service/configuration/clustering

Cluster nodes

High availability is built in by default. Simply add more cluster nodes that are configured according to the nodes in Cluster Installation Patterns. The services will distribute the load evenly across the HA nodes.

Job Scheduling

Job scheduling is the process of launching a session to be scheduled at a later time by a special job scheduling script. Instead of calling the default start script, the FastX launcher will call a job scheduler template or admin supplied custom script that will use a custom job scheduler to launch the session. The session will show up in a pending state on the user’s UI.

See Job Scheduling

Long Term Storage and Configuration

$FX_CONFIG_DIR: /etc/fastx

The FastX configuration directory is located in /etc/fastx (or set via environment variable $FX_CONFIG_DIR). All files are stored in human readable flat file format. See FastX 5 Configuration

Each cluster member (Cluster Manager or FastX Node) maintains its own configuration directory /etc/fastx. Configuration in this directory is NOT synchronized across the cluster. It is up to the system administrators to maintain configuration.

Typically system admins use configuration management systems like Puppet, Ansible, and Kubernetes ConfigMaps/Secrets to maintain /etc/fastx

$FX_VAR_DIR: /var/fastx

Data that will be made by the FastX Web Server is stored in /var/fastx (or set via environment variable $FX_VAR_DIR). This data include user configuration, logins, and server data.

In a cluster, a FastX Node will write data to both its local /var/fastx as well as upload it to the Cluster Manager to store it in /var/fastx. When reading data, a FastX Node will query the Cluster Manager for the information.

$FX_LOCAL_DIR: /var/fastx-local

Data local to a specific FastX Node is stored in /var/fastx-local This data is private to the system itself and does not need to be shared

$FX_TEMP_DIR: /tmp

Interprocess communication needs a local directory that is available to both the fastx user and the end linux user. Typically this is /tmp.