Since Royal Server acts as a gateway for managing servers and tunneling secure connections it plays a vital role in the IT infrastructure. Now a logical question is: how can I configure Royal Server for high availability?
The configuration of Royal Server is by default kept locally to the server, so you need to make sure that the installations are configured in the same way. Here is a list of configuration information that you need to consider.
In general it is recommended to either use machines that are not joined to a domain or use machines that are joined to the same domain. For simplicity, it is also recommended to configure the same Worker Account to all installations.
a) Windows User Groups for accessing Royal Server
The local Windows groups “Royal Server Users”, “Royal Server Gateway Users” and “Royal Server Administrators” are used by Royal Server to grant access to its features. It is best to define Security groups centrally in your Active Directory, add the appropriate users to them and then add the AD group to the local Windows group. This step has to be done for each Royal Server installation once.
b) Local Certificates
Make sure, you install the same certificates on all Royal Server installations, otherwise Royal TS/X clients are constantly showing a warning if the fingerprint changes (when you hit another installation behind the loadbalancer) all the time.
c) Document Store Folder
By default, the Document Store root folder is local (C:\ProgramData\RoyalServer\DocumentStore\). In order to have all installations point to the same Document Store folder, you need to have a shared folder to which all installations have access. Royal Server is serialising access to documents and serialise changes with the method of "last wins" (with the exception of deleted objects)
d) Log entries
By default, Royal Server logs to the Windows Eventlog in the Log "Royal Server". You can import these Windows logs centrally with some tool and look at all entries together. When logging into a file, you have to manually merge multiple files to see log entries of all installations.
e) Changes in the app settings.json
Royal Server stores its settings in a file in C:\ProgramData\RoyalServer\appsettings.json. Any general changes (IPs, ports, security configurations, logging etc) will change the app settings.json. You can logically define one of the Royal Server installations to be your "master" and copy all configurations to the other installations - this can be done via a script. After this change, restart the Royal Server windows service.
f) Changes the Royal Server configuration database
The Royal Server configuration database contains all configuration data that is more volatile:
- User MFA configurations
- Document Store ACLs (access control lists)
The location of this file is C:\ProgramData\RoyalServer\royalserverv4.db. This cannot be changed at the moment. So the only thing you can do to keep the MFA and Document Store ACL configuration in sync is to script it from the "master" installation.
g) License installations
Licenses can be installed via the Configuration Tool or via a PowerShell script.
h) Worker Account
In order to prevent that certain installations might get an ACCESS DENIED for some operations, please use the same Worker Account (in a domain environment this should be a domain user)
The following approaches can be used to make Royal Server installations more resilient to failure:
1) Hardware-Loadbalancing Royal Server
If you have a hardware loadbalancer you can use it to split the load on two or more installations of Royal Server. This scenario also helps you on upgrading Royal Server installations at runtime without going offline. Royal Server at runtime is stateless which means that you can use a classic round robin strategy - no sticky sessions required.
2) Automatic failover from the client to a hot-standby installation
If you do not have a hardware loadbalancer, you can configure Royal TS/X to automatically failover from one Royal Server installation to another if the first is not answering. Simply configure two Computer Names separated with a semicolon. After hitting a timeout from the first Royal Server, Royal TS automatically tries the second, then the third and so on.
Configured like in the screenshot, Royal TS will try to use the Royal Server at the IP 1.2.3.4 and if this does not answer it will try to use 127.0.0.1.
3) Manual failover from the client to a standby installation
You can manually reconfigure your Royal Server object to use a different Royal Server. Use our bulk edit feature to configure this on multiple objects with one click if needed.
And what about a real cluster?
At the moment, we do not have plans to implement a real cluster where you have nodes that know of each other. If you are interested in having cluster features implemented, please introduce a new Idea in our forum so that other customers can also upvote this suggestion here: https://support.royalapps.com/support/discussions/topics/new.
Monitoring Royal Server
Royal Server is technically a Windows Service. The status of this service can be monitored easily. Additionally since Royal Server also is a web server, you also can check if it listenes on the configured port (54899 by default). By default Royal Server logs in the Windows Event Log, but you can also configure a file log and process this log in your monitoring infrastructure (e.g. Splunk).
Which licenses do I need for making Royal Server highly availably?
With the exception of the Personal License (non-commercial) you can have as many installations as you need in your environment (for the Site License the users that use the installations have to be in one site/office).