|
|
| (не показаны 3 промежуточные версии этого же участника) |
| Строка 1: |
Строка 1: |
|
| |
|
| = Минимальные требования = | | === Требования к ОС === |
| Минимальные параметры сервера для работы платформы в односерверном режиме:
| | Требуется ОС (на выбор): |
|
| |
|
| * 4 ядра, | | * Linux Debian 10, 11, 12 |
| * 8 GB RAM, | | * Linux Ubuntu Server 20 |
| * 100 GB HDD. | | * Astra Linux |
| | * RedOS |
| | * Alt Linux (base alt) (нет совместимости с Alt Linux SP |
|
| |
|
| Рекомендуемые параметры сервера для работы платформы в односерверном режиме с БД и файловым хранилищем на сервере:
| | Обязательные пакеты: |
|
| |
|
| * 8+ ядер, | | * rsync - используется при копировании файлов на сервер |
| * 32+ GB RAM, | | * curl, wget - используются в процессе установки |
| * 250+ GB SSD TBW 3500+ TB, | | * docker-ce, docker-ce-cli, containerd.io - пакеты для установки docker |
| * 1+ TB HDD/SSD для БД,
| |
| * 1+ TB HDD/SSD для файлового хранилища,
| |
| * RAID.
| |
|
| |
|
| = Таблица производительности =
| | Для случаев многосерверной конфигурации необходимо синхронизированное время в пределах 1 секунды при помощи NTP. |
| Тестирование нагрузки проводилось на различных процессорах в односерверном и двухсерверном исполнении. Проводились три теста с различным упором: либо на CPS, либо на количество одновременных разговоров, либо на количество одновременных IVR. В каждом них другие два показателя были очевидно ненулевыми, но значительно меньшими, чем пиковые возможные значения.
| |
|
| |
|
| Результат тестирования различных процессоров был обобщен и сведен к 1 ядру.
| | Антивирусы на сервере и рабочих местах должны быть настроены таким образом, чтобы не мешать работе микросервисов платформы. |
|
| |
|
| Усредненная таблица производительности в расчете на 1 ядро 2.5 GHz:
| | === Требования к СУБД === |
| {| class="wikitable"
| | Для односерверных конфигураций допускается установка Платформы вместе с PostgreSQL (версии 12+) в отдельном docker-контейнере или в хосте. |
| !Упор на количество
| |
| !На одно ядро
| |
| !На сервер 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
| |
| |}
| |
|
| |
|
| = Подходы к расчету используемых ресурсов =
| | Для многосерверных конфигураций: |
| Выделяются три подхода:
| |
|
| |
|
| # Расширение. ''Постепенно нагружаем, оцениваем фактическое использование ресурсов. Не хватает - добавляем.''
| | * Один экземпляр на одном из имеющихся серверов в docker-контейнере или в хосте. |
| # Экстраполяция нагрузки. ''Замеряем затраты, полученные на малом объеме исполняемых процессов в полностью функционирующей системе. Например на 10 операторах. Итог экстраполируем до ожидаемого количества одновременно исполняемых процессов. Например до 1000 операторов.''
| | * Несколько экземпляров на имеющихся серверах с потоковой репликацией, [https://vendor.era-platform.ru/docs/era/latest/configuration/roles/mware.html#pg_controller контроллером репликаций] (автоматическое переключение recovery в master и обратно). |
| # Экспертная оценка. ''Опираясь на расчетные показатели для телефонии, применяем коэффициент 3-6 в зависимости от типа резервирования и размера системы.'' | | * Установка с подключением к внешним серверам БД PostgreSQL. |
|
| |
|
| === Подход 1. Расширение === | | === Требования к локальной сети === |
| Устанавливаем на 1 сервере, настраиваем функциональность для полноценной работы в продакшене в 1-серверном исполнении. По мере увеличения нагрузки добавляем серверы, конфигурацию распределяем на большее количество серверов.
| | '''Для односерверных''' конфигураций необходимо обеспечить открытые порты согласно [[Порты используемые системой|статье]]. |
|
| |
|
| Начинаем всегда с 1-2-4 серверов в зависимости от типа резервирования и грубо оцениваемой нагрузки. Если загрузка подбирается к 60-70%, выявляем затратные сервисы и выделяем их на отдельные машины. Либо переконфигурируем систему исходя из увеличенного количества серверов.
| | Пропускная способность не менее 100 Мбит/с (full-duplex). |
|
| |
|
| Преимущественно выделяются наружу:
| | Качественная работа сетевого оборудования и сетевых служб, обеспечивающая стабильные TCP-соединения между сервером и рабочими местами, а также не менее 99% доставки UDP-пакетов между сервером телефонии и оконечными SIP-терминалами (софтфонами или IP-телефонами). Время отклика для пакетов размером 1 кбайт не должно превышать 50 мсек. Мониторинг сети диагностическими утилитами типа Wireshark не должен выявлять проблем на транспортном уровне, таких как нарушение очередности пакетов и дублирования данных. Мониторинг сети утилитой tcpdump не должен выявлять проблем на транспортном уровне. |
|
| |
|
| * базы данных;
| | Особенности использования Virtual IP описаны в [https://vendor.era-platform.ru/docs/era/latest/articles/virtualip.html статье]. |
| * микросервисы, обслуживающие медиа-трафик;
| |
| * микросервисы, обслуживающие SIP-сигнализацию;
| |
| * микросервисы, обслуживающие IVR и другие сценарии;
| |
| * микросервисы, обслуживающие модель данных
| |
| * микросервисы веб-серверов
| |
| * микросервисы продуктового слоя
| |
| * микросервисы обслуживания подписок на изменения
| |
|
| |
|
| Далее, наблюдая за использованием оставшимися микросервисами ресурсов сервера, выявлять лидеров.
| | '''Для многосерверных''' конфигураций дополнительно требуется открытие ряда портов для межсерверного взаимодействия. Перечень портов опписан в [https://vendor.era-platform.ru/docs/era/latest/articles/ports_of_system.html статье]. |
|
| |
|
| === Подход 2. Экстраполяция нагрузки === | | === Требования к доступу в сеть Internet === |
| | Доступ в сеть Internet является опциональным требованием для следующих сервисов: |
|
| |
|
| # Система настраивается на полную функциональность на заведомо необходимом количестве серверов (том количестве, от которого очевидно не придется отказываться, может быть на одном сервере). Создаются все сценарии, настраиваются все процессы, правила, подключения, интеграции.
| | * Периодическое подтверждение лицензии Платформы (<nowiki>https://activate.era-platform.ru</nowiki>) [[Лицензирование|подробнее]]; |
| # На систему переводится часть планируемых процессов или потоков обращений, долю которой можно количественно оценить по отношению к плановой пиковой нагрузке. ''Так, например, 10%. Подключаются не 1000 операторов, а 100, балансировщиком заводится не весь поток звонков, а только 10%, и т.д.''
| | * ACME — протокол автоматического выпуска и продления SSL/TLS-сертификатов при помощи Let's Encrypt; |
| # Замеряется фактическое использование системой ресурсов при обслуживание выделенной части.
| | * Взаимодействия с мессенджерами (Макс, Telegram); |
| # Полученное значение экстраполируется до планового исходя из выделенной доли.
| | * Установка пакетов из официальных репозиториев Debian: |
| # Применяется увеличивающий коэффициент для резервирования. От 1.5 до 2.
| | ** Обязательные пакеты: |
| # Применяется увеличивающий пиковый коэффициент для обеспечения неполной загрузки. Коэффициент 1.5 ''(базовый уровень использования CPU на серверах не должен быть более 70%, без учета возможных точечных пиков)''.
| | *** rsync - используется при копировании файлов на сервер; |
| # Рассчитывается необходимое количество соответствующих серверов.
| | *** curl, wget - используются в процессе установки; |
| # Отдельно рассматривается БД и хранилища архивных данных и файлов.
| | *** docker-ce, docker-ce-cli, containerd.io - пакеты для установки docker; |
| | ** Опциональные пакеты: |
| | *** nfs-kernel-server |
| | *** nfs-common |
| | *** cifs-utils |
| | *** postgresql-14 |
| | *** net-tools |
| | *** tree |
| | *** zip |
| | *** sshpass |
| | *** sysstat |
| | *** htop |
| | *** iotop |
| | *** dstat |
| | *** smartmontools |
| | *** tshark |
| | *** apt-transport-https |
| | *** ca-certificates |
| | *** lsb-release |
| | *** perl-base |
| | *** gnupg-agent |
|
| |
|
| Здесь важно, выделяя часть процессов, адекватно оценить её долю от общего количества. Каждый из процессов полностью нагруженной системы должен исполняться и быть представлен в измеряемой части.
| | === Требования к хранилищу файлов === |
| | '''Для оперативного хранения файлов конфигурации''' и логирования микросервисов требуется около '''500 Гб SSD (IOPS: 2k-10k)''' дискового пространства для каждого сервера. Подробнее про использование дискового пространства микросервисами в [https://vendor.era-platform.ru/docs/era/latest/articles/disk_load.html статье.] |
|
| |
|
| Не должно допускаться квадратичного (экспоненциального) сокращения нагрузки в измеряемой части относительно полной. Например, сокращение коллекции в 10 раз приводит к сокращению кросс-пересечения в 100 раз, и во столько же раз быстрее отрабатывает запрос с JOIN.
| | '''Для хранения записей''' разговоров требуется на выбор: |
|
| |
|
| === Подход 3. Экспертная оценка ===
| | * NFS на внешнем носителе; |
| Оценка для телефония может быть построена исходя из показателей, приведенных в таблице.
| | * VRRP-хранилище (хранилище поверх Virtual Router Redundancy Protocol); |
| | * S3-хранилище (настраивается индивидуально для каждого домена); |
| | * Локальное размещение на тех же серверах (возможно в mount-разделах); |
| | * Локальное размещение на тех же серверах с синхронизацией. |
|
| |
|
| # Грубо оцениваем предполагаемую нагрузку на систему в пике:
| | Для '''многосерверных''' конфигурация рекомендуются использовать NFS, VRRP или S3. |
| #* Сколько одновременных разговоров и каких.
| |
| #* Сколько ожидающих в очередях абонентов (вероятно, не больше чем количество внешних транков).
| |
| #* Сколько телефонных устройств будет зарегистрировано одновременно и с какой периодичностью будут производить перерегистрацию.
| |
| #* Какие процессы обработки данных будут выполняться с какой периодичностью и нагрузкой. Можно перевести в количество компонентов в секунду.
| |
| #* Какое количество пользователей будет одновременно подключено к системе.
| |
| #* Какие отчеты и дашборды будут строиться одновременно с основной работой.
| |
| #* Какой объем разговоров будет записываться и как долго будет храниться.
| |
| #* Какое количество доменов будет в системе.
| |
| # Определяем внешние сервисы.
| |
| #* Будет ли подключено внешнее файловое хранилище.
| |
| #* Будет ли БД вынесена на внешние серверы.
| |
| # Определяем тип резервирования исходя из целей.
| |
| #* Будет ли инсталляция системы, готовая к выпадению одного сервера. Расчетный коэффициент (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 участников, где у всех включено видео и все являются спикерами.
| |
| #* Микширование производится отложенно за счет свободных ресурсов сервера.
| |
|
| |
|
| = Нагрузка на диски =
| | Подробнее про правила записи и архивирования записей разговоров в [https://vendor.era-platform.ru/docs/era/latest/articles/recording.html статье.] |
|
| |
|
| == SSD vs HDD == | | === Системные требования (сайзинг) === |
| У платформы есть 6-7 видов использования ПЗУ (файловой системы). Каждый из них определяет особую интенсивность чтения, интенсивность записи, отношение этих показателей, длительность хранения записанных данных, частоту обращения к ним, критичность скорости доступа на чтение, критичность скорости доступа на запись.
| |
|
| |
|
| Эти виды использования привязаны к определенным (разным) путями в файловой системе. Точнее они привязаны к алиасам, а алиасы в конфигурации привязываются к путям в файловой системе внутри контейнера. При установке системы на сервер для каждого из этих разделов создается docker-volume и присоединяется к контейнеру. Таким образом, каждый из них можно смаунтить на разные разделы.
| | ==== Минимальные требования ==== |
| | Для знакомства и обучения: |
|
| |
|
| Если все диски будут SSD с большим значением TBW - это хорошо. Исключает на корню проблемы задержек из-за "переполненной очереди доступа". Если есть выбор, то SSD.
| | * 4 vCPU @2,5 ГГц, 8 ГБ ОЗУ, 100 ГБ SSD IOPS: 2k-10k |
|
| |
|
| Серверные SSD большого объема довольно дороги (речь конечно не об 1 ТБ, а о большем размере и большем значении TBW), поэтому HDD для некоторых кейсов - компромисс.
| | ==== Односерверная конфигурация ==== |
| | | {| class="wikitable" |
| * На SSD - вся рабочая обвязка, где много чтения, много записи, но небольшие объемы или крутится цикл перезаписи - логи, запись разговоров, микширование, объектная БД, файлы сценариев, автопровижен, временные файлы веб-сервера, и сотня других ,
| | !SC |
| * На HDD - всё то, что накапливается. Архив записей разговоров (если они не отправляются во внешние S3 или NFS хранилище), архив лог-журналов, возможно архивная БД.
| | !Сервер |
| | | !Сеть |
| SSD раздел - под быстрый доступ, интенсивную перезапись (несмотря на то, что жизненный цикл SSD напрямую зависит от интенсивности перезаписи). Статистика использования SSD платформой показывает, что запись осуществляется на порядок интенсивнее, чем чтение. Это надо учитывать при выборе дисков. Каждый интенсивно нагруженный сервер системы в день может писать в районе 100 ГБ лог-журналов, и еще столько же на обвязках. С записями разговоров укладывается в 1 ТБ (грубая оценка). Таким образом нижний сегмент серверных SSD дисков c TBW ~ 7 ПБ - лет на 20, как минимум.
| | !Хранилище файлов |
| | | |- |
| БД постепенно перезаписывает свой объем. БД может размещаться на HDD, но при интенсивной нагрузке на БД - именно этот фактор будет тормозящим дальнейший прогресс производительности системы. Если быть готовым разносить разные домены, и даже коллекции в домене, по разным серверам БД, то HDD может оказаться приемлемым вариантом. Также, можно повысить скорость, если собрать несколько HDD дисков в длинный RAID-5 или его производные.
| | |10 |
| | | |4 vCPU @2,5 ГГц, 16 ГБ ОЗУ |
| === Примеры ===
| | |≥ 100 Мбит, < 50 мс |
| Если БД постгре используется интенсивно, HDD диска загружен на 100% - очередной запрос чтения может задержаться. Если интенсивность работы системы с БД такая, то варианты: БД разделить на части и вынести на разные серверы под разные домены/коллекции, либо организовать RAID-5, либо перенести БД на SSD.
| | |≥ 500 ГБ SSD IOPS: 2k-10k |
| | | |- |
| В момент создания диалога с записью синхронно производится открытие файла для записи. Если диск загружен и даст паузу более 3 секунд, то вызов не состоится. Записью занимаются серверы с экземплярами MG, и диски нагружаются пропорционально размещению экземпляров по серверам. Если запись производится на раздел, относящийся к SSD, то проблему на практике получить невозможно при любом количестве вызовов - вычислительные пределы одного сервера достигаются раньше. А с HDD - наоборот.
| | |100 |
| | | |8 vCPU @2,5 ГГц, 24 ГБ ОЗУ |
| Рабочий каталог системы используется для размещения объектной БД mnesia. Поэтому рабочий каталог - на SSD. Возможность быстрой записи без очереди - почти критична для целостности данных. Если mnesia делит диск с другими процессами, то она может мешать им, хотя сама по себе системе не помешает - запись всегда отложенная, а чтение производится на старте системы целиком в ОЗУ.
| | |≥ 100 Мбит, < 50 мс |
| | | |≥ 1 000 ГБ SSD IOPS: 2k-10k |
| Когда разговор смикшировался - он уносится в подключенное S3, NFS хранилище или распределяется по собственным серверам, если хранилища не подключены. Тут никому не мешает очередь, и доступ на прослушивание разговора, или просмотр лог-журнала в архиве - не критичен ко времени. HDD спокойно справляется.
| | |- |
| | | |200 |
| === Место хранения записанных разговоров ===
| | |12 vCPU @2,5 ГГц, 32 ГБ ОЗУ |
| Для HDD размер в 1 ТБ - это условное минимальное значение для того, чтобы некоторое время отсутствие свободного места не беспокоило, и со статистикой за несколько месяцев можно было сориентироваться: какой реальный объем нужен под перспективу хранения лог-журналов в N недель, и записей разговоров в M лет. Очевидно, что можно и меньше, но надо ориентироваться на планируемую нагрузку.
| | |≥ 100 Мбит, < 50 мс |
| | | |≥ 2 000 ГБ SSD IOPS: 2k-10k |
| Если подключить внешнее хранилище для хранения архивных разговоров - это эффективнее, и лучше управляется в больших системах. При использовании внешних хранилищ можно регулярно создавать новые хранилища, и текущие файлы будут переноситься туда. Если предыдущие хранилища все еще доступны - прежние файлы будут читаться с них.
| | |- |
| | | |300 |
| Если же оставить их по умолчанию на серверах с платформой, то том для хранилища фактически единый (поскольку ограничено докер волюмами; тут можно тоже развивать, но неприоритетно). Можно удалять данные старше N лет. Или если сервер физический, объединить несколько дисков в один том - это делать надо до установки или при переустановке системы на конкретном сервере.
| | |16 vCPU @2,5 ГГц, 48 ГБ ОЗУ |
| | | |≥ 100 Мбит, < 50 мс |
| == Разделы в файловой системе и их минимальные размеры ==
| | |≥ 3 000 ГБ SSD IOPS: 2k-10k |
| Разметка на всех серверах одинаковая, а в реальности нагрузка зависит от конфигурации.
| | |- |
| | | |500 |
| В текущем инсталляторе предусмотрены следующие корневые пути для разделов:
| | |22 vCPU @2,5 ГГц, 64 ГБ ОЗУ |
| | | |≥ 100 Мбит, < 50 мс |
| * /usr/lib/era - файлы компонентов и приложений. Включая архивы обновлений. ~20 GB (SSD или HDD) ОК.
| | |≥ 5 000 ГБ SSD IOPS: 2k-10k |
| * /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.
| |
| [[Категория:Администрирование]] | | [[Категория:Администрирование]] |
| | Подробное описание подхода к сайзингу описано в [https://vendor.era-platform.ru/docs/era/latest/articles/sizing.html статье]. |
