Technical specifications for the security server

This article describes the Data Exchange Layer’s technical specifications for the host server based security server (RHEL, Ubuntu).

See also the technical specifications for a containerised security server.

Production environment and server platform

• A physical or a virtualised server environment
• Functional time services (NTP, Network Time Protocol) - Firewall openings for the NTP service must be present: UDP port 123
• Functional name services (DNS, Domain Name System) - Firewall openings for the DNS service must be present: TCP port 53

Operating system

• Ubuntu 20.04 LTS, or Ubuntu 22.04 LTS server installation

OR

• RHEL 7 or RHEL 8 server installation

General instructions for server dimensioning

The following sections list the general dimensioning instructions for the security servers of the Data Exchange Layer for different purposes.

Test use

A light test server for functional testing

• 2 vcores
• 4 GB of memory
• OS partition: 10 GB
• /var partition: 20–40 GB
• one 1 Gb/s network connection

Test server for normal functional testing

• 4–8 vcores
• 8–16 GB of memory
• OS partition: 10 GB
• /var partition: 40–80 GB
• one 1 Gb/s network connection

Test server for heavy load testing

• 8 vcores
• 16 GB of memory
• OS partition: 10 GB
• /var partition: 80–160 GB
• one 1 Gb/s network connection

Production use

Production server, light production use

• 2 vcores
• 4 GB of memory
• OS partition: 10 GB
• /var partition: 20–80 GB
• one 1 Gb/s network connection

A server intended for light production use can

• perform < 50 requests per minute (message sizes ≤ 500 K) at a continuous steady load
• transfer large volumes of data (message sizes 0.5 M–10 M) inside normal SOAP messages at a rate of a few requests per minute.

Production server, normal production use

• 4 vcores
• 4–8 GB of memory
• OS partition: 10 GB
• /var partition: 80–160 GB
• one 1 Gb/s network connection

A server intended for normal production use can

• perform 50–125 requests per minute (message sizes ≤ 500 K) at a continuous steady load
• transfer large volumes of data (message sizes 0.5 M–10 M) inside normal SOAP messages at a rate of approximately a dozen requests per minute.

Production server, heavy production use

• 4–8 vcores
• 8–16 GB of memory
• OS partition: 10 GB
• /var partition: 160–320 GB
• one 1 Gb/s network connection

A server intended for heavy production use can

• perform 150–250 requests per minute (message sizes ≤ 500 K) at a continuous steady load
• transfer large volumes of data (message sizes 0.5 M–10 M) inside normal SOAP messages at a rate several dozens of requests per minute.

Estimating the amount of disk space required by the server

When estimating the amount of disk space the security server requires, take into account the disk space required by log entries since the content of each SOAP request and response message are logged in a database. However, the Data Exchange Layer does not log the body part of the message.

The requests contain 9.5 kB of metadata (SOAP definitions, identifiers and headers) and signatures. The response message contains 11.2 kB of such information. Therefore, for each successful request, the back-and-forth SOAP messages will add 21 kB of internal metadata into the message log. In addition, the security servers contact a timestamp service at a one-minute interval to have the latest recorded messages signed, if messages exist. The fixed size of timestamps is 3.6 kB.

Therefore, the default disk space requirement for an active message log is

3.6 kB + N * (21 kB + R + A) = S

where

N = requests per minute

R = the size of the body of the request in kilobytes (kB), for Finland, this size is 0 kB

A = the size of the body of the response in kilobytes (kB), for Finland, this size is 0 kB

S = disk usage per minute in kilobytes (kB/min).

Example 1

Let us assume that the system receives 100 requests per minute. The body size of a request message is 4 kB and the body size of a response message is 8 kB. However, they are not logged in Finland, so the body size of the messages is 0 kB. In this case, the disk usage of the message log is

3.6 kB + 100 * (21 kB + 0 kB + 0 kB) = 2,103.6 kB/min = 2.1 MB/min.

Therefore, the daily disk space requirement is 2.95 GB. By default, the message logs are stored for 30 days, so the total disk space requirement is 88.5 GB.

The calculations must also include archived messages. Their space requirement is approximately 43% of the log actively stored in the database. Therefore, the additional disk space requirement is:

• 1.3 GB/day
• 39 GB/month
• 468 GB/year.

In total, the disk space requirement is:

• 2.95 + 1.3 GB = 4.25 GB/day
• 88.5 + 39 GB = 127.6 GB/month
• 1,062 + 468 GB = 1,530 GB/year.

Example 2

Let us assume that the system receives 1,000 requests per minute. The body size of a request message is 4 kB and the body size of a response message is 8 kB. However, they are not logged in Finland, so the body size of the messages is 0 kB. In this case, the disk usage of the message log is

3.6 kB + 1,000 * (21 kB + 0 kB + 0 kB) = 21,003.6 kB/min = 20.5 MB/min.

Therefore, the daily disk space requirement is 28.8 GB. By default, the message logs are stored for 30 days, so the total disk space requirement is 864 GB.

The calculations must also include archived messages. Their space requirement is approximately 43% of the log actively stored in the database. Therefore, the additional disk space requirement is:

• 12.4 GB/day
• 371.5 GB/month
• 4.4 TB/year.

In total, the disk space requirement is:

• 28.8 + 12.4 GB = 41.2 GB/day
• 864 + 371.5 GB = 1,235.5 GB/month
• 10.4 TB + 4.4 TB = 14.8 TB/year.

Dimensioning instructions associated with the transfer of large attachments

It is recommended to use attachments for transferring large volumes of data in the Data Exchange Layer. A file is considered large if its size is approximately 10 MB or more.

Read more about transferring large attachments in the Data Exchange Layer.

The amount of disk space should be taken into account especially in the transfer of large attachments. The attachments are stored in the disk cache. Therefore, there must be enough free disk space to allow the attachment to be stored on the disk.