Нагрузка на диски

У платформы есть 6-7 видов использования ПЗУ (файловой системы). Каждый из них определяет особую интенсивность чтения, интенсивность записи, отношение этих показателей, длительность хранения записанных данных, частоту обращения к ним, критичность скорости доступа на чтение, критичность скорости доступа на запись.

Эти виды использования привязаны к определенным (разным) путями в файловой системе. Точнее они привязаны к алиасам, а алиасы в конфигурации привязываются к путям в файловой системе внутри контейнера. При установке системы на сервер для каждого из этих разделов создается docker-volume и присоединяется к контейнеру. Таким образом, каждый из них можно смаунтить на разные разделы.

Если все диски будут SSD с большим значением TBW - это хорошо. Исключает на корню проблемы задержек из-за "переполненной очереди доступа". Если есть выбор, то SSD.

Серверные SSD большого объема довольно дороги (речь конечно не об 1 ТБ, а о большем размере и большем значении TBW), поэтому HDD для некоторых кейсов - компромисс.

SSD раздел - под быстрый доступ, интенсивную перезапись (несмотря на то, что жизненный цикл SSD напрямую зависит от интенсивности перезаписи). Статистика использования SSD платформой показывает, что запись осуществляется на порядок интенсивнее, чем чтение. Это надо учитывать при выборе дисков. Каждый интенсивно нагруженный сервер системы в день может писать в районе 100 ГБ лог-журналов, и еще столько же на обвязках. С записями разговоров укладывается в 1 ТБ (грубая оценка). Таким образом нижний сегмент серверных SSD дисков c TBW ~ 7 ПБ - лет на 20, как минимум.

БД постепенно перезаписывает свой объем. БД может размещаться на HDD, но при интенсивной нагрузке на БД - именно этот фактор будет тормозящим дальнейший прогресс производительности системы. Если быть готовым разносить разные домены, и даже коллекции в домене, по разным серверам БД, то HDD может оказаться приемлемым вариантом. Также, можно повысить скорость, если собрать несколько HDD дисков в длинный RAID-5 или его производные.

Разметка на всех серверах одинаковая, а в реальности нагрузка зависит от конфигурации.

В текущем инсталляторе предусмотрены следующие корневые пути для разделов:

Разделение на такие небольшие разделы несет потенциальные сложности, исключая возможность перераспределения места. Например где-то совсем нет ролей с объектными БД, но зато пишется много лог-журналов (например трафик сигнального протокола SIP).

Эти пути - внутри контейнера. В хосте они все замыкаются на волюмы во время установки, по умолчанию пути в хосте внутри /opt. Каталог /usr/lib/era не выносится в волюм, и остается внутри контейнера, который где-то в системных папках хоста (/var/lib вероятнее всего)

К слову, логи реального времени можно писать на хдд, но ТОЛЬКО если хдд выделен под эту задачу. Если ее начать объединять с БД, или с записью - сразу вредные кросс зависимости по очереди доступа пойдут.

Асинхронная запись у логов реального времени, у архива записей, у архива лог журналов, у объектной БД, у микшера. Синхронная запись - у БД postgresql, у вложений динамической объектной модели. Синхронное чтение - у медиафайлов, у объектов динамической модели.

При стандартной разметке, например в ext4, необходимо помнить про ограничение количества inode. Если на диск размещается много мелких файлов, то inode могут завершиться раньше, чем свободное место. Каждый каталог, каждый файл занимает одну единицу. Например, если на диске хранится история почтовых сообщений - то вне зависимости от объема каждого отдельного письма, фактически будет потребляться более 100 кб на каждое из-за наличия нескольких каталогов и файла raw-данных письма.

Платформа включает слежение за inode на дисках, где располагаются ее разделы. При отслеживаемых пороговых значениях администратор получит сообщение в рамках system_state.