Load on disks

The platform has 6-7 uses of the ROM (file system). Each defines a specific read rate, write rate, the ratio of these rates, the length of time the written data is retained, the frequency of accessing it, the criticality of the read access rate, and the criticality of the write access rate.

These uses are tied to specific (different) paths in the file system. More precisely they are bound to aliases, and the aliases in the configuration are bound to paths in the file system inside the container. When the system is installed on the server, a docker-volume is created for each of these partitions and attached to the container. This way, each one can be smartened to a different partition.

If all disks are SSDs with a high TBW value, that’s a good thing. Eliminates the problems of delays due to "overflow access queue" at the root. If you have a choice, then SSD.

Large capacity server SSDs are quite expensive (we are not talking about 1TB of course, but about larger size and higher TBW value), so HDD is a compromise for some cases.

SSD partition - for fast access, intensive overwriting (despite the fact that SSD lifecycle directly depends on the intensity of overwriting). SSD platform utilization statistics show that writes are an order of magnitude more intensive than reads. This should be taken into account when choosing disks. Each heavily loaded system server can write around 100 GB of logs per day, and a similar amount on the straps. With conversation recordings it is 1 TB (rough estimate). Thus, the lower segment of server SSD disks with TBW ~ 7 PB is at least 20 years away.

The database gradually overwrites its volume. The database can be placed on HDD, but under intensive load on the database - this very factor will inhibit further progress of the system performance. If you are ready to spread different domains, and even collections in a domain, across different database servers, HDD may be an acceptable option. Also, you can increase the speed if you gather several HDD disks into a long RAID-5 or its derivatives.

The partitioning is the same on all servers, and in reality the load depends on the configuration.

The current installer provides the following root paths for partitions:

Splitting into such small sections carries potential complications, precluding the possibility of reallocating space. For example, somewhere there are no roles with object databases at all, but a lot of logs are written (for example, signaling protocol traffic SIP).

These paths are inside the container. In the host, they are all locked to volums during installation, the default paths in the host are inside the /opt. The /usr/lib/era directory is not moved to the volum, and remains inside the container, which is somewhere in the system folders of the host (/var/lib most likely)

By the way, real-time logs can be written to xdd, but ONLY if xdd is dedicated to this task. If you start merging it with the database, or with recording - harmful cross-dependencies on the access queue will immediately follow.

Asynchronous recording at real-time logs, at the records archive, at the log archive, at the object database, at the mixer. Synchronous writing - at postgresql database, at dynamic object model attachments. Synchronous reading - for media files, for dynamic model objects.

For standard partitioning, e.g. ext4, it is important to keep in mind the limit on the number of inode. If many small files are placed on disk, inodes may terminate before free space is available. Each directory, each file occupies one unit. For example, if the disk stores the history of email messages - then regardless of the size of each individual email, it will actually consume more than 100kb per email due to multiple directories and the email’s raw data file.

The platform includes inode tracking on the disks where its partitions reside. When thresholds are monitored, the administrator will receive a message as part of the system_state.