High Availability

Use multiple RPort servers for high availability

Client-side failover

Inside the RPort client configuration, you can specify a primary and a list of secondary rport servers. If the client loses the connection to the primary server, it automatically connects to the first secondary server from the list, going through the list until a connection to one secondary is established.

While the client is connected to a secondary server, a background process is constantly probing the primary server. If the primary server is available again, the client switches back.

Below an excerpt of the rport client configuration showing the fallback options.

[client]
  ## rportd server address.
  ## Mandatory IP address and port divided by a colon.
  server = "0.0.0.0:8080"

  ## list of fallback rportd servers to which the clients tries to connect
  ## if the above "main" server is not reachable.
  #fallback_servers = ["fallback-a.example.com:9090","fallback-b.example.com:80"]
  ## if connected to a fallback server, try every interval to switch back to the main server.
  #server_switchback_interval = '2m'

Setting up a secondary server

Currently, the rport server has no built-in clustering or data replication mechanism. To set up a secondary RPort server, you need to replicate the server data manually or with third-party software. The minimal data that must be replicated is the client authentication source. This can be either a JSON file or a SQLite database.

JSON and SQLite database files can be replicated on filesystem level. The client authentication tables or files are usually written very rarely. You can give a simple rsync approach a try.

Having the client authentication source replicated to one or many secondary RPort servers, your clients can connect to those.

Replicating only the client authentication data ensures you can always access and manage your remote machines. But for a larger setup, this is too minimalistic. User accounts, group memberships, scripts, and all other data is missing on the secondary server.

So it's better to replicate all databases from the primary to the secondary servers. While SQLite doesn't have replication built-in, you can try an open-source third-party solution called Litestream.

Using replicated SQLite databases is currently not officially supported and not covered by the RPort support.

Keep in mind that while clients are connected to a secondary RPort server, data is not synchronized back to the primary. This is a manual step.

Active-Active server scenario

Scenarios where two RPort servers are active and clients can connect to either one of them is not supported. Not with built-in features nor with third-party software. Therefore, load balancing over multiple RPort servers is also not supported.

Hypervisor HA

Using high availability solution provided by hypervisors is also an option. Your hypervisor will ensure your virtual machine with the RPort server is always up. This scenario doesn't require special configuration on the server nor on the rport clients.