How do I move my SLC Hub installation from one server to a new (replacement) server?
Altair EmployeeI am drafting some notes on this topic…"How do I move my SLC Hub installation from one server to a new (replacement) server?"
The biggest consideration is: Can existing client-side references to your SLC Hub be preserved? e.g. Is the hostname going to be different. The Hub hostname, port, and TLS certificates are stored in each end-user's Workbench configuration, and potentially stored in browser bookmarks, saved API URLs, and in Windows certificate stores. Your IT department may be able to help you re-use the same hostname for the replacement hub server, or to introduce a DNS alias, to avoid affecting these client-side references. (If you are also replacing the worker nodes, you do not need to be so concerned about keeping the same hostnames for worker nodes.)
Make sure your new servers are ready to use, with a supported version of the operating system, and with any additional packages that you require to use with the new hub. On worker machines, you may need to install database drivers and of course you will need to install and license SLC.
Firstly, arrange for the end-users to stop using the SLC Hub while the replacement server is being prepared. Then follow the hub documentation instructions for shutting down the services as you would for an upgrade:
Essentially, the overall procedure will be like backing up and then restoring a Hub.
- Backup the DB ("hubctl backup internaldb" if using internal DB)
- Backup the object store
- Backup the config (yaml files)
If the DB and the object store are 'internal' then they need to be backed up and restored to the new server. Note that our recommendation is that internal stores are not used for production sites, only for development/test installations.
If you are also replacing the workers then remember to migrate any configuration files from the old workers to the new.
Follow the hub documentation to Install SLC Hub on the new server, and install SLC Hub Worker on the worker machines, along with SLC.
After the 'dnf' command on linux or the MSI install on Windows, you can unpack the config (yaml files) into the new config location on the new server. Edit any hostnames mentioned in your _custom yaml files that may need changing.
Use the usual 'hubctl bootstrap' command to prepare the new hub server and then 'hubctl service start'.
If internaldb has been used, then use "hubctl restore internaldb". Similarly for the object store.
If the hostname has changed then TLS certificates will need to be regenerated and distributed to client machines. Information on the new SLC Hub connection details should be made available to users.