Master/Slave Synchronization and Clusters
In Bitvise SSH Server versions 6.xx and higher, the SSH server can be run in master/slave mode, which facilitates its use in a cluster.
The scope of the master/slave feature is to automate synchronization of SSH server settings between SSH servers. It is intended for use in environments where administrators would like to apply settings changes on one server (the master), and have the changes automatically propagate to others (slaves). The master/slave feature does not interact with solutions for server monitoring or load balancing. If your deployment requires e.g. load balancing, you will need an external solution for that.
To cause some or all aspects of the SSH server's configuration to be automatically reproduced from a primary installation to one or more secondary installations, use the Instance type feature in Bitvise SSH Server Control Panel to configure the primary installation as the master. Then, configure secondary installations to run as slaves, and retrieve configuration changes from the master.
A typical cluster installation may wish a secondary server to appear identical to a primary server to its users. To achieve this, a slave would reproduce all aspects of the SSH server's configuration: settings, host keys, and password cache. The aspects of SSH server configuration that will be copied from the master are configured in the Instance Type dialog for each slave installation.
Configuring Master/Slave SynchronizationMaster/slave synchronization is configured through the Instance type setting in the Bitvise SSH Server Control Panel (top right corner of the Server tab). The following steps are required:
- On the master server:
- Set instance type to Master, and configure a password which slave SSH servers will be required to present in order to synchronize settings from the master. We highly recommend configuring a long, secure, randomly generated password as described on this page.
- Use the Manage host keys interface to export the public keys of all host keys used by the SSH server. Alternately, write down the master's employed host key fingerprints so that you can enter them manually into slave configuration.
- On slave servers:
- Set instance type to Slave.
- Import the master's host keys through the Host and fingerprints setting. Alternately, use Add Fp to add a master's host key fingerprint, without importing the key.
- Enter the master's network address and port, and set the synchronization password to match the one configured on the master.
- In the remaining slave settings, configure which aspects of SSH server settings to synchronize from the master. Host keys can be synchronized from the master only if this is permitted in master settings.
- If you enable Auto-manage trusted host keys, the slave server will automatically add to its "Host keys and fingerprints" setting any new host keys generated on the master, assuming they haven't yet been employed. If the host key is already employed when it is first seen by the slave, the slave will not be able to connect regardless of this setting, because it has no previous knowledge of the key.
Upgrading Servers in a Master/Slave Configuration
For a master/slave arrangement to function, servers that receive synchronization data must use an SSH Server version equal to, or greater than, the server from which they obtain the data.
Servers in a master/slave configuration should therefore be upgraded in the following order:
- Slave servers first.
- Secondary masters second.
- Master server last.
If a master server is upgraded to an SSH Server version that uses a settings format newer than some of the slaves, those slaves will no longer be able to synchronize with that master. However, newer versions of slaves will continue to recognize settings from an older master.