Introduction / FirstSpirit ServerManager / Server properties / Clustering / Master server configuration
FirstSpirit master server configuration
| Table of contents |
To register a conventional FirstSpirit Server as a master server in a cluster group, the “FirstSpirit master server” radio button is activated.
A FirstSpirit master server manages all FirstSpirit projects centrally and whenever possible distributes tasks to other FirstSpirit Servers. The available servers (e.g., generation slaves) are displayed in the “Registered slaves” area:
The Unregister slave button is used to remove a “Registered slave” from the selection list.
Accessing the file system of the master server
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.
 |
Note on the order: Configuring the slave server and accessing the master server directories has to be carried out in a certain order (see Slave configuration steps). |
|
After the initial changeover of a FirstSpirit Server to a FirstSpirit master server, the server must be restarted. |
Updating the slave servers
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).
|
The master server contains all of the functions of a standard FirstSpirit Server and should be set up using fail-safe hardware, since all FirstSpirit Clients use the master server as the endpoint in network connections.The slave servers are not self-contained and cannot be used on their own. However, all FirstSpirit functions are provided by the master server without any need for changes to the configuration should the slave servers fail. The generation schedule entries are then automatically executed on the master instead of the slave, which only results in a higher load for the master. |
Error analysis and monitoring
The following master server log files are used for error analyses when problems arise during and after configuration:
- <FirstSpirit_ROOT (Master)>/log/fs-wrapper.log
- <FirstSpirit_ROOT (Master)>/log/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 Server Monitoring – FirstSpirit – Clustering).