System requirements for a dedicated server

This article describes the requirements and recommendations for deploying PILOT on your organisation’s dedicated infrastructure.
It is intended for system administrators, engineers, and integrators responsible for preparing the infrastructure and maintaining the system.
 

Choosing a server configuration

The configuration depends on the expected workload:
  • the number of connected devices and their message frequency;
  • the number of concurrent users;
  • the reports and integrations in use;
  • data retention periods;
  • enabled modules.
The baseline specifications provide a starting point for production deployment. They do not guarantee performance under every workload.
 

Baseline configuration

The recommended starting configuration is intended for a system with up to 30,000 connected devices without the video module:
  Component
  Recommendation
  Processor
  At least 8 physical cores or dedicated server-class vCPUs
  Memory
  At least 64 GB
  System partition
  At least 100 GB SSD
  Database storage
  At least 2 TB NVMe or enterprise SSD; RAID 10 for a physical server
  Backups
  Separate storage, with capacity calculated according to the retention policy
  Network
  A stable connection with guaranteed bandwidth and low packet loss
If devices transmit data every 1–5 seconds, the load on the processor, database, and storage increases significantly. For this operating mode, perform load testing in advance and allow for additional capacity.
RAID improves resilience to disk failures but does not replace backups.
 

Data storage

Raw events received from devices are stored in the database. Their retention period depends on system settings and available disk space. It should generally not exceed three months.
When calculating storage capacity, account for:
  • the number of devices and their average message frequency
  • the retention period for raw events
  • the volume of historical data, tracks, and report data
  • attachments, photos, and media files
  • backup size and retention periods
Calculate backup storage capacity based on the size of a full database backup, the number of retained copies, and the compression used. Allow at least 20% additional capacity. A fixed allocation of 1 TB is not suitable for every deployment.
 

Separating components

For high workloads, deploying system components on separate servers is recommended.
  Server role
  When required
  Minimum recommended configuration
  Application server
 Base installation
  8 vCPU, 64 ГБ RAM
  Database server
  Generally recommended for 5,000 or more devices, or intensive telemetry transmission
  8 vCPU, 64 ГБ RAM, от 2 ТБ NVMe/SSD
  PTM and Logistics
  When handling large numbers of tasks, routes, or calculations
  The need for a separate server and its configuration are determined after assessing the workload
  Video server
  When using the video module
  At least 16 vCPU, 128 GB RAM, separate storage
The database server must be on the same protected local network as the application server. PostgreSQL, Redis, and Memcached must not be accessible from the Internet.

Video storage

Video archive capacity depends on the number of cameras, average bitrate, recording duration, and retention period.
Use the following formula for an initial estimate:
Capacity in TB = number of cameras × average bitrate in Mbps × recording hours per day × retention days × 0.00045 × 1.3
Choose the video server’s operating system according to the requirements of the hardware and its drivers.
For new installations, use a supported edition of Windows Server 2019 or later. Extended support for Windows Server 2019 runs until January 2029. Support dates are published on the Microsoft Lifecycle page.
 

Operating system and software components

The supported platform is Oracle Linux 8 x86_64, or an operating system image agreed with Technical support.
The installation includes:
  • Nginx
  • PHP-FPM and the required PHP extensions
  • PostgreSQL
  • Redis
  • Memcached
  • SocketProxy and device message handlers
  • background jobs and monitoring tools
The installation package for each PILOT release determines the exact component versions. Do not update them manually without checking compatibility and agreeing on a maintenance window.

Virtual environments

Deployment in a virtual environment is supported if the following resource requirements are met:
  • CPU resources and memory must be reserved
  • the storage subsystem must provide the required input/output operations per second (IOPS)
  • significant resource overcommitment is not permitted: the physical infrastructure must be able to provide the allocated resources

Test environment

The following configuration is sufficient for a test environment with up to 100 devices:
  Component
  Specification
  Processor
  4 vCPU
  Memory
  8 GB RAM
  Storage
  200 GB SSD
This environment is not intended for production use or load testing.
 

Network requirements

Allow inbound connections only where necessary.
  Purpose
  Protocol and port
  Connection source
  Web interface and API
  HTTPS, TCP 443
  User workstations and authorised integrations
  Redirect to HTTPS
  HTTP, TCP 80
  As required
  Receiving device messages
  TCP/UDP ports used by the enabled protocols
  Devices and trusted networks
  Administration
  SSH, TCP 22
  VPN, bastion host, or approved IP addresses only
 Monitoring
According to the monitoring system configuration
  Authorised addresses only
PostgreSQL, Redis, and Memcached ports must be accessible only within the server network segment.
The server may require the following outbound connections:
  • DNS and NTP time synchronisation
  • HTTPS access to operating system repositories and external services
  • SSH access to gitlab.pilot-gps.com over TCP port 22122 for installation and updates
  • access to the geocoding, routing, map, and integration services enabled in the system
Configure access rules for external services using domain names and agreed ports rather than static IP addresses, as service addresses may change.
If a local map tile server is not deployed, user workstations also need access to map resources.
During installation, provide the server with controlled access to the required repositories and services. Unrestricted Internet access is not required.
 

Backup and recovery

Define a backup policy before putting the system into production. It must include:
  • database backups
  • backups of configuration, certificates, and integration settings
  • separate backups of media files and the video archive, if used
  • storage of backups outside the primary server
  • backup encryption and restricted access
  • regular recovery testing
Backup frequency and retention periods are determined according to the system owner’s requirements:
  • RPO (Recovery Point Objective) — the maximum acceptable period of data loss following a failure
  • RTO (Recovery Time Objective) — the maximum acceptable time to restore system operation
A successfully created backup does not confirm that it can be restored. Perform test restores periodically and verify the results.
 

Preparing for production

Before launching the system:
1. Configure a TLS certificate for the production domain name
2. Restrict access using a firewall, allowing only necessary connections
3. Block direct Internet access to internal service components
4. Configure individual SSH accounts with key-based authentication
5. Ensure time synchronisation
6. Configure monitoring for service availability, free disk space, system load, processing queues, and backup results
7. Agree on maintenance windows for updates and assign responsible staff
 

Technical support access

Remote Technical support requires secure SSH access through a VPN or bastion host.
Grant access only to authorised specialists, for a limited period, with activity logging enabled.
 

What to prepare before installation

To coordinate the installation, prepare:
  • the domain name, static IP address, and TLS certificate
  • expected workload details and a list of modules to be used
  • a list of device protocols and ports
  • network rules and addresses permitted for administration
  • details of the storage allocated for the database, backups, and media files
  • RPO, RTO, and data retention requirements
  • contact details for staff responsible for infrastructure and access
  • monitoring settings and the notification channel
     

Post-installation checks

After installation, system acceptance checks are performed to verify:
  • receipt of data from devices
  • report generation
  • integration operation
  • monitoring operation
  • successful restoration from a backup