This page documents the requirements for the sizing of the host machine which will host the containers for the jtel Stack.

Operating System

Backup Storage

For storage of backups, either an SMB or NFS fileshare must be provided including the following data:

SMB

NFS

Sizing

VM Sizing

Up to 20 Concurrent Agents

Up to 60 Concurrent Agents

Up to 200 Concurrent Agents

Over 200 Concurrent Agents

Bespoke calculation based on exact system requirements.

Backup Storage Sizing and Retention Policy

The backup storage, which should be external to the VM itself, will need to be sized accordingly, and also you will need to implement a rotation and retention strategy. 

WORM

We do highly recommend the usage of WORM storage with appropriately configured policies. Since the backup is content based, 

In all cases you will need to consult your data protection officers to determine what are reasonable retention policies for your business.

Retention Policy

We recommend implementing a retention and rotation scheme. This is an example only, for exact retention policies please discuss with your data protection officer.

• Daily backups, retained for example for 14 days
• Weekly backups, copied from daily backups as required, retained, for example, for 12 weeks
• Monthly backups, copied from weekly backups as required, retained, for example, for 24 months

Sizing

To determine the actual size of the backup storage you require, you should regularly examine your backup storage. In daily, you will find 2 files created each day:

• One sql.gz file - this contains the database backup
• One tar.bz2 file - this contains the data directory files backup

The naming of the files follows the following convention:

• <instance_name>_<version>_<date>_<time>_<machine_name>.sql.gz

• <instance_name>_<version>_<date>_<time>_<machine_name>.tar.bz2

For example:

• cmyacd.jtel.online_3.44.1_2026-05-15-020000+0200_cmyacd-debian-vm.sql.gz

• cmyacd.jtel.online_3.44.1_2026-05-15-020000+0200_cmyacd-debian-vm.tar.bz2

Adding up the size of these two files, and considering some growth thereof, will give you an approximate size of what each day's backup will need.

Use your retention policy to calculate the final sizing of the backup storage.

Here are some examples, using approximate sizes of data observed in the field:

Performance and Benchmarking

CPU Core Count

The CPU core counts above are guidelines based on performance metrics taken by jtel during load testing on dedicated infrastructure.

Depending on your data center environment and / or cloud infrastructure provider and their associated capabilities, the actual CPU core count required may vary.

RAM Sizing

It is very important for overall system performance that the system does not swap RAM to disk during high load situations. Swapping will seriously impact system performance.

Storage Sizing and i/o Performance

Sizing

The system writes a considerable amount of data and logs to disk during high load conditions. It is important, that the underlying disk system on the container host provides enough performance and does not get saturated under load.

It is also important that the disk does not get full during operations as this will inevitably result in some data loss, make sure that the host disk is appropriately sized, particularly if you are storing call recordings for a longer period of time. 

The following formula can be used to calculate the disk requirements for call recordings:

• 1 Hour of Stereo Recording = 32 KB (2 Channels at 8 kHz 16 Bit Stereo) * 60 Seconds * 60 Minutes = 115.2 MB
• Size of storage required = Number of Hours to Store * 115.2 MB

For example, to store 7 working days of recordings for 30 agents on the phone for 6 hours per day you would need a minimum of:

• 7 * 30 * 6 * 115.2 MB = 145152 MB = 145.2 GB of Storage

Performance

You can measure the performance of the host system storage from the command line as follows:

for x in 1 2 3 4 5; do dd if=/dev/zero of=~/testfile.${x} bs=1M count=2048; done

This command writes 5 files 2 GB in size to the storage, and will usually result in the storage system going into saturation. The output of the last iteration is the performance metric you should use for reference. 

Modern hard drives achieve data transfer rates > 500 MB per second, whereas storage that is inadequately connected to a virtual environment achieves significantly less. The effective throughput of a hard drive, even a local one in a virtual environment, can be influenced by many factors:

• Inadequate connection of an iSCSI via LAN, for example, with only a 1 x GB connection.
• Insufficient caching capacity of a storage controller.
• Faulty or uninstalled storage drivers
• Controller unsuitable for use with a virtualisation host.

As a rule of thumb, anywhere between 100 MB to 200 MB per second is OK. If you are seeing figures lower than 100 MB per second, then your attached storage system does not have good performance and you may see issues when running the system at high load.

LAN and QoS

Performance in the LAN is extremely important in a VoIP telephony environment. If the LAN is heavily used, voice data may be lost or delayed without Quality of Service enabled (QoS). Users of the system will notice this immediately due to choppy and broken audio in telephone conversations.

In contrast, data delay or loss is acceptable for normal IT business applications – the action takes a little longer or the data is sent again. 

The correct configuration of the network (switches / routers / DNS) is also very important.

It is always advisable to operate a separate VLAN for telephony. Furthermore, in a virtual environment, the bundling of logical LAN channels on a physical line can also lead to overload. 

Overutilisation of LAN capacity is one of the most commonly overlooked problems in the design of virtual environments. 

If you have even the slightest doubt about the network, it is advisable to carry out a network measurement. This can be offered by jtel or your jtel partner on request.

In summary:

• Make sure QoS is activated end to end (make sure your internet provider supports this!)
• Do not overbook LANs / VLANs in the virtual environment on which the container host will run

Telephony

The keyword "real time" is important for telephony applications. There must be no gaps in the processing of voice data from telephony. If the appropriate CPU, RAM and I/O performance (network and storage) is not available, this can cause problems.

In a virtual environment:

• a business application (CRM / ERP / Ticketing or whatever) may take longer than usual to respond when the environment overloads. When the latency becomes too high, the employee will notice this and complain about the speed of the system. But basically, they can still do their job. It's like surfing a slow website - though annoying it still works.
• a telephony application will experience time delays in the processing of voice data when the environment overloads. This is barely noticeable below 20 ms, but becomes audible above 30 ms. Above a certain delay, audio data will be lost and call quality will suffer. When large delays occur, significant gaps in the telephone conversation can be heard, and the call may even be dropped entirely. Compared to the business application which just slows down, this is of course a much more serious problem and is unacceptable.

In a virtual environment, resources should be reserved for the container host. We recommend:

• reserving 100% of the RAM for the container host
• reserving 50% of the required CPU cores for the container host
• thick provisioning the disk for the container host, so that it exists in it's entirity not withstanding the actual capacity of the storage system in the background