Минимальные требования

Минимальные параметры сервера для работы платформы в односерверном режиме:

4 ядра,
8 GB RAM,
100 GB HDD.

Рекомендуемые параметры сервера для работы платформы в односерверном режиме с БД и файловым хранилищем на сервере:

8+ ядер,
32+ GB RAM,
250+ GB SSD TBW 3500+ TB,
1+ TB HDD/SSD для БД,
1+ TB HDD/SSD для файлового хранилища,
RAID.

Таблица производительности

Тестирование нагрузки проводилось на различных процессорах в односерверном и двухсерверном исполнении. Проводились три теста с различным упором: либо на CPS, либо на количество одновременных разговоров, либо на количество одновременных IVR. В каждом них другие два показателя были очевидно ненулевыми, но значительно меньшими, чем пиковые возможные значения.

Результат тестирования различных процессоров был обобщен и сведен к 1 ядру.

Усредненная таблица производительности в расчете на 1 ядро 2.5 GHz:

Упор на количество	На одно ядро	На сервер 12 ядер по 2.5 GHz
CPS	cps - 6, calls - 25, ivr - 25	cps - 72, calls - 300, ivr - 300
Calls	cps - 0.5, calls - 180, ivr - 0	cps - 6, calls - 2000, ivr - 0
IVR	cps - 0.5, calls - 125, ivr - 125	cps - 6, calls - 1500, ivr - 1500

Подходы к расчету используемых ресурсов

Выделяются три подхода:

Расширение. Постепенно нагружаем, оцениваем фактическое использование ресурсов. Не хватает - добавляем.
Экстраполяция нагрузки. Замеряем затраты, полученные на малом объеме исполняемых процессов в полностью функционирующей системе. Например на 10 операторах. Итог экстраполируем до ожидаемого количества одновременно исполняемых процессов. Например до 1000 операторов.
Экспертная оценка. Опираясь на расчетные показатели для телефонии, применяем коэффициент 3-6 в зависимости от типа резервирования и размера системы.

Подход 1. Расширение

Устанавливаем на 1 сервере, настраиваем функциональность для полноценной работы в продакшене в 1-серверном исполнении. По мере увеличения нагрузки добавляем серверы, конфигурацию распределяем на большее количество серверов.

Начинаем всегда с 1-2-4 серверов в зависимости от типа резервирования и грубо оцениваемой нагрузки. Если загрузка подбирается к 60-70%, выявляем затратные сервисы и выделяем их на отдельные машины. Либо переконфигурируем систему исходя из увеличенного количества серверов.

Преимущественно выделяются наружу:

базы данных;
микросервисы, обслуживающие медиа-трафик;
микросервисы, обслуживающие SIP-сигнализацию;
микросервисы, обслуживающие IVR и другие сценарии;
микросервисы, обслуживающие модель данных
микросервисы веб-серверов
микросервисы продуктового слоя
микросервисы обслуживания подписок на изменения

Далее, наблюдая за использованием оставшимися микросервисами ресурсов сервера, выявлять лидеров.

Подход 2. Экстраполяция нагрузки

Система настраивается на полную функциональность на заведомо необходимом количестве серверов (том количестве, от которого очевидно не придется отказываться, может быть на одном сервере). Создаются все сценарии, настраиваются все процессы, правила, подключения, интеграции.
На систему переводится часть планируемых процессов или потоков обращений, долю которой можно количественно оценить по отношению к плановой пиковой нагрузке. Так, например, 10%. Подключаются не 1000 операторов, а 100, балансировщиком заводится не весь поток звонков, а только 10%, и т.д.
Замеряется фактическое использование системой ресурсов при обслуживание выделенной части.
Полученное значение экстраполируется до планового исходя из выделенной доли.
Применяется увеличивающий коэффициент для резервирования. От 1.5 до 2.
Применяется увеличивающий пиковый коэффициент для обеспечения неполной загрузки. Коэффициент 1.5 (базовый уровень использования CPU на серверах не должен быть более 70%, без учета возможных точечных пиков).
Рассчитывается необходимое количество соответствующих серверов.
Отдельно рассматривается БД и хранилища архивных данных и файлов.

Здесь важно, выделяя часть процессов, адекватно оценить её долю от общего количества. Каждый из процессов полностью нагруженной системы должен исполняться и быть представлен в измеряемой части.

Не должно допускаться квадратичного (экспоненциального) сокращения нагрузки в измеряемой части относительно полной. Например, сокращение коллекции в 10 раз приводит к сокращению кросс-пересечения в 100 раз, и во столько же раз быстрее отрабатывает запрос с JOIN.

Подход 3. Экспертная оценка

Оценка для телефония может быть построена исходя из показателей, приведенных в таблице.

Грубо оцениваем предполагаемую нагрузку на систему в пике:
- Сколько одновременных разговоров и каких.
- Сколько ожидающих в очередях абонентов (вероятно, не больше чем количество внешних транков).
- Сколько телефонных устройств будет зарегистрировано одновременно и с какой периодичностью будут производить перерегистрацию.
- Какие процессы обработки данных будут выполняться с какой периодичностью и нагрузкой. Можно перевести в количество компонентов в секунду.
- Какое количество пользователей будет одновременно подключено к системе.
- Какие отчеты и дашборды будут строиться одновременно с основной работой.
- Какой объем разговоров будет записываться и как долго будет храниться.
- Какое количество доменов будет в системе.
Определяем внешние сервисы.
- Будет ли подключено внешнее файловое хранилище.
- Будет ли БД вынесена на внешние серверы.
Определяем тип резервирования исходя из целей.
- Будет ли инсталляция системы, готовая к выпадению одного сервера. Расчетный коэффициент (N+1)/N, но практически от 1.5 до 2 в зависимости от конфигурации.
- Будет ли резервирование датацентров (установка на два датацентра). Коэффициент 2.
- Будут ли формироваться зоны, готовые к выводу из эксплуатации. Коэффициент зависит от числа и размера зон. Грубый коэффициент 2.
Оценка требуемого количества ядер.
- Исходя из приведенной выше таблицы на основании оцененных показателей по ожидаемой пиковой нагрузке, оценивается необходимое количество ядер.
- На основании количества ядер оценивается количество соответствующих серверов.
Оценка требуемой дисковой системы.
- Дисковая подсистема рассмотрена в статье Нагрузка на диски
Оценка требуемой оперативной памяти.
- Базовая память 32 GB на один сервер используется стандартными процессами телефонии любого масштаба и коллцентром до 100 человек с размещением БД на сервере.
- На увеличение требований к размеру оперативной памяти работают:
  - Большие БД, сохранящие историю в течение нескольких лет - на тех серверах, где исполняется БД;
  - Наличие процессов построения отчетности по длительным периодам дат - на тех серверах, где исполняется БД;
  - Наличие в модели данных продуктового слоя емких коллекций с кэшированием.
Добавляем запас, уменьшающий загрузку в пиках.
- усредненная нагрузка на процессор не должна быть более 70%. Коэффициент 1.5. (базовый уровень использования CPU на серверах не должен быть более 70%, без учета возможных точечных пиков).
- Диски SSD/HDD не должны быть заполнены более чем на 50% (bytes, inodes).
- Загрузка очереди чтения/записи на HDD диске не должна наблюдаться периодами более 1 секунды, и в общем объеме не должна превышать 1% (неактуально при использовании SSD).
Добавляем запас на схему резервирования. Расчетный коэффициент (N+1/N), где N - расчетное количество серверов, на практике от 1.5 до 2.
При установке БД на серверах кластера добавляем ресурсы на работу БД. (от 2 ядер и 100 GB до 24+ ядер и 1+ TB + RAID)
- Примерный размер для расчета - 150 MB каждый месяц хранения для домена, содержащего 100 пользователей и 30 тысяч соединений в месяц.
При использовании локального хранилища добавляем ресурсы (SSD/HDD) для его обеспечения.
- Примерный размер для расчета - 1 минута стерео MP3 - 180 КБ.
- Дополнительно необходимо оценить и учесть другие коллекции с вложениями:
  - сохраняют ли сценарии что нибудь.
  - настроены ли почтовые ящики и как долго хранятся сообщения.
  - есть ли другие исторические данные с вложениями.
  - производится ли резервное копирование БД средствами системы (даже если на внешнее хранилище).
Применяем коэффициент для продуктового слоя по работе с проектной моделью данных (от 1.1 до 2).
- коэффициент 1.1 - если продуктовый слой установлен в единственном домене и используется только для просмотра журнала звонков.
- коэффициент 1.5 - если продуктовый слой установлен во всех доменах при их общем количестве более 20.
- коэффициент 2.0 - если пользователи массово работают в приложениях, исполняются процессы неголосового обслуживания.
ВКС. Примеры:
- 1 сервер 8 cores и каналом 1 Gbit/s справляется с обслуживанием:
  - 1 комната на 200 человек, где у всех включены камеры, и до 10 спикеров.
  - 1 комната на 500 человек, где видео/экран и звук транслирует 1 спикер, остальные без камер и микрофонов.
  - 10 комнат по 300 человек, где транслируется только аудио.
  - 100 комнат из 3-5 участников, где у всех включено видео и все являются спикерами.
- Микширование производится отложенно за счет свободных ресурсов сервера.

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

SSD vs HDD

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

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

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

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

На SSD - вся рабочая обвязка, где много чтения, много записи, но небольшие объемы или крутится цикл перезаписи - логи, запись разговоров, микширование, объектная БД, файлы сценариев, автопровижен, временные файлы веб-сервера, и сотня других ,
На HDD - всё то, что накапливается. Архив записей разговоров (если они не отправляются во внешние S3 или NFS хранилище), архив лог-журналов, возможно архивная БД.

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

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

Примеры

Если БД постгре используется интенсивно, HDD диска загружен на 100% - очередной запрос чтения может задержаться. Если интенсивность работы системы с БД такая, то варианты: БД разделить на части и вынести на разные серверы под разные домены/коллекции, либо организовать RAID-5, либо перенести БД на SSD.

В момент создания диалога с записью синхронно производится открытие файла для записи. Если диск загружен и даст паузу более 3 секунд, то вызов не состоится. Записью занимаются серверы с экземплярами MG, и диски нагружаются пропорционально размещению экземпляров по серверам. Если запись производится на раздел, относящийся к SSD, то проблему на практике получить невозможно при любом количестве вызовов - вычислительные пределы одного сервера достигаются раньше. А с HDD - наоборот.

Рабочий каталог системы используется для размещения объектной БД mnesia. Поэтому рабочий каталог - на SSD. Возможность быстрой записи без очереди - почти критична для целостности данных. Если mnesia делит диск с другими процессами, то она может мешать им, хотя сама по себе системе не помешает - запись всегда отложенная, а чтение производится на старте системы целиком в ОЗУ.

Когда разговор смикшировался - он уносится в подключенное S3, NFS хранилище или распределяется по собственным серверам, если хранилища не подключены. Тут никому не мешает очередь, и доступ на прослушивание разговора, или просмотр лог-журнала в архиве - не критичен ко времени. HDD спокойно справляется.

Место хранения записанных разговоров

Для HDD размер в 1 ТБ - это условное минимальное значение для того, чтобы некоторое время отсутствие свободного места не беспокоило, и со статистикой за несколько месяцев можно было сориентироваться: какой реальный объем нужен под перспективу хранения лог-журналов в N недель, и записей разговоров в M лет. Очевидно, что можно и меньше, но надо ориентироваться на планируемую нагрузку.

Если подключить внешнее хранилище для хранения архивных разговоров - это эффективнее, и лучше управляется в больших системах. При использовании внешних хранилищ можно регулярно создавать новые хранилища, и текущие файлы будут переноситься туда. Если предыдущие хранилища все еще доступны - прежние файлы будут читаться с них.

Если же оставить их по умолчанию на серверах с платформой, то том для хранилища фактически единый (поскольку ограничено докер волюмами; тут можно тоже развивать, но неприоритетно). Можно удалять данные старше N лет. Или если сервер физический, объединить несколько дисков в один том - это делать надо до установки или при переустановке системы на конкретном сервере.

Разделы в файловой системе и их минимальные размеры

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

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

/usr/lib/era - файлы компонентов и приложений. Включая архивы обновлений. ~20 GB (SSD или HDD) ОК.
/var/lib/era - рабочий каталог: объектная БД, микширование. ~80 GB OK.
/var/log/era - лог журналы реального времени. ~100 GB.
/var/lib/era_files/rectemp - записи реального времени - хранятся 6 часов. ~20 GB SSD.
/var/lib/era_files/recpath - результаты микширования, хранилище локальное по доменам (если не настроено внешнее) - предполагается использование NFS хранилища. Но в одно-двух серверых системах NFS не используется, и это собственный диск. Он под долговременное хранение записей в этом случае. ~20 GB если уносим во внешние хранилища. Или ~1 ТB если храним архивы здесь же, без подключения NFS.
/var/lib/era_files/local - локальный каталог для хранилищ. Временные файлы - их обширно использует вебсервер. Там по умолчанию располагается каталог для вложений всех коллекций продуктовой модели данных (в частности, письма email). Достаточно HDD, до тех пор, пока он справляется с нагрузкой. Если систему обширно нагружать по всем направлениям, то временные файлы надо на SSD (потому что интенсивность большая), а вложения коллекций уводить на другие диски (потому что объем большой).
/var/lib/era_files/syncroot - 20 GB SSD. В реальности 1-2 GB. Это данные автоматического синхронизатора между серверами. Там лежат медийные файлы сценариев, публичные веб-страницы, сертификаты, патчи, шаблоны автопровижена, медифайлы статики (для конференций, холда, парковки, голосовой почты, озвучки числительных), файлы вложений к сущностям доменов (пользовательские приложения продуктового слоя, микросервисы продуктового слоя), и проектные всякие файлы - если специально созданы хранилища здесь, или в сценариях размещение сюда производится.
/var/lib/era_files/logstore - * HDD - архивное хранилище лог журналов. Его размер настраивается в конфигурации. 500 Гигов условно на 1 неделю при средней интенсивности.
/var/lib/era_files/siteshare - NFS. Используется в проектных настройках как единое хранилище между серверами одного сайта. Например в сценариях - в одном сценарии разместили, в другом воспользовались.
/var/lib/era_files/globalshare - NFS. То же, но в многосайтовых системах между всеми сайтами.
/var/lib/era_files/a - дополнительно примаунченные разделы на разных носителях, для того чтобы можно было налету изменяя конфигурацию переносить нагрузку с одного диска на другой. То есть они своих данных не имеют, но могут принять на себя вместо других вышеприведенных.
/var/lib/era_files/b - то же
/var/lib/era_files/c - то же

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

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

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

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

Файловая система и inode

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

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