Documentation for Administrators

Introduction / FirstSpirit ServerManager / Server properties / Clustering / Slave server configuration

FirstSpirit slave server configuration

Step 1) Configure access to the master server directories

In order to copy data to the slave servers and to write log files to the master server from the slave servers, access via a load-balanced file system must be possible and the necessary read and write permissions must be granted for selected directories of the master server.

There are therefore at least three different directory trees within the cluster environment.

In the file system of the master:

The root directory of the FirstSpirit master server (placeholder: <FirstSpirit_ROOT (Master)>)

In the file system of the slave:

The root directory of the FirstSpirit slave server (placeholder: <FirstSpirit_ROOT (Slave)>)
The mapping of the selected directories of the master server in the FirstSpirit slave server file system (placeholder: <FS_ROOT_MASTER (Mapping)>)

Note: These placeholders must be replaced with the individual path to the relevant directory (e.g., /opt/firstspirit5/).

The following directories of the FirstSpirit master server are integrated in such a way that they can be accessed from the slave server (or mapped to the file system of the slave server). The path to this directory will be required later when registering the slave (placeholder here: <FS_ROOT_MASTER (Mapping)>) (see Slave configuration – Path to FirstSpirit).

<FirstSpirit_ROOT (Master)>/conf to <FS_ROOT_MASTER (Mapping)>/conf
(configuration files)
Access is required so that the master's configuration settings are available on the slave; read-only
<FirstSpirit_ROOT (Master)>/data/projects to <FS_ROOT_MASTER (Mapping)>/data/projects
(project content)
Access is required in order to make the relevant project data available to the slave; read-only
<FirstSpirit_ROOT (Master)>/data/schedule to <FS_ROOT_MASTER (Mapping)>/data/schedule
(schedule management)
Access is required in order to write the relevant log information to the master server when executing schedules via the slave server; read-write
<FirstSpirit_ROOT (Master)>/export to <FS_ROOT_MASTER (Mapping)>/export
(project exports)
Access is only required when the cluster nodes are running in legacy mode (access not required in isolated mode); read-only
<FirstSpirit_ROOT (Master)>/log to <FS_ROOT_MASTER (Mapping)>/log
(log files)
Access is required in order to write relevant log information to the master server; read-write
<FirstSpirit_ROOT (Master)/ Staging directory of the Jetty Web Server> to <FS_ROOT_MASTER (Mapping)/ Staging directory of the Jetty Web Server
(generation results)
Access is required in order to write the generation results to the master (default behavior); read-write

The distinction made between read-only and read/write access directories serves to increase the operating security and data throughput. The central repository data on the master server is distributed for read access only.

If the security requirements are higher, access should be limited to exclusive access for FirstSpirit slaves by using the authentication procedure (IP address, Kerberos, etc.) supported by the operating system.

Step 2) Configure FirstSpirit Server as a slave server

The FirstSpirit Server can then be configured as a slave server.

To register a conventional FirstSpirit Server as a slave server in a cluster group, the “FirstSpirit slave server” radio button is activated.

Slave server name: Name of the FirstSpirit slave server

Change path to FirstSpirit / master server: The “Change master server” button is used to specify the path to the “mapped” FirstSpirit master server directories (i.e., path to the directory <FS_ROOT_MASTER (Mapping)>). Clicking on the button opens a dialog in which the directory path is entered manually.

When the “Change master server” dialog is confirmed, the system checks whether the expected directories can be reached by following the path that has been entered. These directories (of the master server) must not correspond to those of the server that is currently being configured (slave server). If an additional FirstSpirit Server has been identified, the parameters “Master server host” and “Master server port” are populated automatically. The parameters of the configuration file fs-server.conf (of the FirstSpirit master server) are used for this purpose.

Note: So long as the slave server remains unregistered (“Register slave” button), the master server configured here can be changed using the “Change master server” button if necessary.

Master server host: Host name of the FirstSpirit master server. The field is populated automatically after a valid path to the FirstSpirit Server is entered.

Master server port Port number of the FirstSpirit master server. The field is populated automatically after a valid path to the FirstSpirit Server is entered.

FirstSpirit Read-Only Repository Server / FirstSpirit Generation Slave: These checkboxes are selected automatically.The FirstSpirit Server is added to the cluster group as a generation server. A generation server contains a RORS (Read-Only Repository Server). The “FirstSpirit Read-Only Repository Server” checkbox is therefore also selected automatically.

Slave server port: A free port on the slave server must be specified here. The slave server communicates with the master server via this port.

The “Register slave” button opens a security warning:

Confirming the dialog by clicking on Yes copies the configuration settings to the corresponding configuration files. The server is then shut down and restarted in “slave” mode. The new slave server's ServerManager is also closed automatically.

After a successful restart, the FirstSpirit Server is available as a member of a cluster group.

A slave that is already registered can only be unregistered via the server properties of the FirstSpirit master server.

To ensure that a slave server is used during project generation, the “Execute on cluster” option must be selected under the properties of the particular schedule entry configuration (see Clustering – configuration of the generation schedule).

Step 3) Further configuration of the slave server

To enable subsequent updating to a new version of FirstSpirit, some JAR files and start scripts are used by the master server directly via the load-balanced file system. The following directories must be integrated in such a way that they replace the corresponding directories of the slave servers (see figure above):

<FirstSpirit_ROOT (Master)>/bin replaces <FirstSpirit_ROOT (Slave)>/bin
(Startup environment, incl. required system binary files)
Access: Optional; read-only.
<FirstSpirit_ROOT (Master)>/server replaces <FirstSpirit_ROOT (Slave)>/server
(Java environment incl. all libraries)
Access: Optional; read-write.
<FirstSpirit_ROOT (Master)>/shared replaces <FirstSpirit_ROOT (Slave)>/shared
(Resources, libraries, classes)
Access: Optional; read-only.

After the master servers are updated, the slave servers are restarted and are then updated as well without having to replace files manually (see also Updating in a cluster group).

Error analysis and monitoring

The following slave server log files are used for error analyses when problems arise during and after configuration:

<FirstSpirit_ROOT (Slave)>/log/fs-wrapper.log
<FirstSpirit_ROOT (Master)>/log/[slave_server_name]/fs-server.log or
<FS_ROOT_MASTER (Mapping)>/log/[slave_server_name]/fs-server.log

The slave server availability and load can be monitored on the FirstSpirit start page by way of FirstSpirit Server Monitoring in the “Clustering” area (see ServerMonitoring – FirstSpirit – Clustering).

Print version | Page start