Host
| Administration Page | Application/Contract | Syracuse/Collaboration | Class | hosts | Representation | host |
|---|
When the Syracuse web platform runs on a customer site, it can be installed on several servers that run in a cluster. On a given server, several instances of node can run (usually one per core used for Syracuse). When the client accesses a server in the cluster, the nanny process associated to this server will perform load balancing between the different node instances on the current server but also on other servers in the cluster.
For every server on which an installation is done, an entry is created in this host entity.
| Principles of Syracuse cluster | Cluster Configuration | Runtime information | Detail information | Client authentication | Additional comments |
Principles of Syracuse cluster
A Syracuse cluster can run on different physical machines, and on every server, several Syracuse processes can run simultaneously.
On every server, the administration of the Syracuse processes is done with a dedicated process called nanny process. This nanny process is performing the following tasks:
- listening to an administration port.
- perform automatic load balancing according to the sessions of each Syracuse process.
- send requests to other nanny processes if several servers are in the Syracuse cluster for this purpose.
Every nanny process can serve as a load balancer, and listen to several ports which may be configured with and without SSL. There must be at least one port which will be used for communication between the nanny processes but may also be reached from outside.
Remark: It is not possible to create a new host in the GUI - this is done from the Syracuse setup.
A host entry will usually be deleted by running the uninstaller setup. If you have to remove a host for other reasons (e. g. physical server cannot be used any more), you have to mark the host as deactivated before you can delete it. The certificate instances which are assigned to that host will be automatically deleted, too.
Cluster Configuration
The following information can be shown/changed for a server within a Syracuse cluster.
Host name
The local host name of the server in lower case letters (read-only).
Connections
This table gives information about the ports in which a nanny process listens. Note that the server will restart when you change or delete active connections (including changes to the certificate data or CA certificates for SSL connection).
- Port: The port in which the server listens when the connection is active.
On an Unix platform, because of system privilege restrictions you must use a port number greater than 1024. If you want to use a port under this limit you can configure the port forwarding using the iptables system command. - Active: When this check box is cleared, this port will not be used.
- SSL: When this check box is selected, an SSL connection will be used. In this case, an instance of the certificate class must be referred for the server certificate.
- Client authentication: When this check box is selected, client authentication will be required for the SSL connection. See below Client authentication for more details.
- Client certificate: When you enter a certificate here, this certificate and its associated CA certificates will be provided as extra CA certificates for this connection. See below Client authentication for more details.
Security recommendations
For security reasons, it is highly recommended to add in all installations a Syracuse port dedicated to:
- internal nanny commands,
- communication between the Load Balancer and different nodes.
This specific port must be set on the first line of the connections' table.
Make sure to have these two ports at the top of the table:
- First row: port 8123 for the communication between the Load Balancer and the nodes. This secured port should only be visible locally and used for internal nanny commands. In a cluster architecture, port 8123 should also be open for other cluster members.
- Second row: port 8124 for the connection to Syracuse. This standard port is available for all users.
Number of child processes
This is the number of Syracuse processes which will run on this server.
Number of web services child processes
Defines how many web services dedicated processes should be set on the administration environment. By default this property is set to 0, so it's necessary to configure it, otherwise, every web service call will raise the HTTP 500 error with the specific message No web services accepted.
Each pool configuration will be duplicated for every host web services child processes.
Deactivated
If the check box is selected, the server is considered inactive, but it will be activated without restarting when the check box is cleared.
Started
When the check box is selected, the program has been explicitly started on that server. When the check box is cleared, the program has been explicitly stopped on that server. When the program has crashed, the check box will remain selected (read-only).
Status
This information is not from the database, but it is obtained at run-time from the cluster. The status can have the following values:
| Status | Explanation |
|---|---|
| Finishing | The server is about to shut down because active connection data has changed and no longer accepts any requests. |
| Finish all | This server (together with all other servers) is about to shut down because of patch integration and no longer accepts any requests. |
| OK | The server is ready to use. |
| Starting | Syracuse processes are being started on that server. The server will be ready soon. |
| Init | Syracuse processes have not yet been started on that server. The server is waiting for responses from other servers. |
| Inactive | The server has been deactivated. |
| Low version | The code version of this server is lower than the highest version of a server according to the database. Therefore, it will not start any Syracuse processes unless its version is updated manually and the server restarted. |
| Wrong version | The code version of this server is different from the version of the first started server. Therefore, it will not start any Syracuse processes unless its version is updated manually and the server restarted. |
| Time difference | The local time of this server differs from the time of another server or the database by more than 10 minutes. Adjust the local time and restart the program. |
| Respawn limit | The Syracuse process has been restarted often. This is usually the case when there are some errors and it cannot be started at all. You should look at the log files. |
| Unknown | No information known about that server, whether it has been started. |
| Unreachable | The program has not answered a request, it may not have started. |
| Not started | The program has not been started (the check box "started" is cleared). |
| No database | Program cannot connect to database and will therefore not work. |
| Not license | There is no license, so that program cannot start |
Code version
This is the actual code version of that server, obtained at run-time (read-only).
TCP host name
This shows the name of that server, how it will be reached from the network. This name is set in the customer-generated server certificate (read-only).
Untrusted hosts
This shows in the detail view the names of the hosts which have not passed the verification test based on the customer generated certificates (read-only).
PID
Process number of the main program on that server. This will change whenever the server is restarted (read-only).
Respawn limit
When the Syracuse process is re-started more than this number of times within the time interval given by respawn time, no more Syracuse processes will be started and the status of the host will be respawn limit.
Return request timeout
This is the number of seconds which a Syracuse process will wait for an internal answer of the nanny process.
Missing certificates
This shows in the detail view the names of the instances of the certificate class which are not OK (for example, missing certificate files). When the local host name appears in that list, the host will not be considered as trustworthy from the others (read-only).
Missing CA certificates
This shows in the detail view the names of the instances of the CA certificate class which are not OK (for example, missing certificate files). When ca appears in that list, the host will not be considered as trustworthy from the others (read-only).
Child process information
This field is filled with the information from the services below.
Security
In the list view: The selection made in this check box tells that all certificates of that server are OK and that it can exchange confidential information with the other servers. It is selected only if the fields are missing certificates, missing CA certificates, and untrusted hosts in the detail view are empty (read-only).
Respawn time
When the Syracuse process is re-started more than the value of respawn limit within this number of seconds, no more Syracuse processes will be started any more and the status of the host will be respawn limit.
Operations available
The following operations are avaiable, through a link present in the right panel:
Runtime information
This will make a request to all servers in the cluster and obtain from them whether they are still reachable. Each Syracuse process will be contacted and the number of milliseconds for this contact will be shown.
Detail information
This will make a request to all servers in the cluster and obtain from them whether they are still reachable. For each Syracuse process, the detailed status of all running requests will be shown.
Client authentication
SSL is a way to encrypt the communication between the browser and the server - here only the server has to authenticate at the browser with a certificate and a private key. It is possible that also the client has to authenticate so that not any browser can open a connection to the server.
When client authentication is switched on for a connection, the browser must have a certificate and private key installed (maybe together with one or more CA certificates). Usually you must have the certificate and private key (and optional CA certificates) as a single file in PKCS#12 format (or convert them into this format and import it into the browser; this must be done for every browser which should use this connection - see the browser documentation for further details).
The server will check whether the certificate has been signed from a certification authority which the server knows. So it is possible to add an optional certificate under "Client certificate" for that connection. This should not be the client certificate itself (unless the client certificate is self signed), but the certificate of at least one certification authorities of the client certificate. In particular, the private key is not necessary. Then the provided client certificate together with its CA certificates will be added as known certification authorities which the server will accept (in addition to the CA certificates of the server certificate).
When the server certificate and client certificate have been issued from generally known certification authorities (e. g. Verisign) or the server certificate and client certificate have identical certification authority, no entry is necessary.
When the array of authentication methods in the session section within nodelocal.js contains "certificate" and a Syracuse user exists whose login name is identical to the common name of the client certificate's subject, an implicit login to the application as this user will be done automatically.
Additional comments
As the SSL enablement has been delivered during the life cycle of the version 7.1 (delivered in patch 7), it is necessary to recreate CA certificate and server certificate and reinstall them if you want to use them for SSL.