В данном разделе приведено описание этапов первоначальной настройки ECSS перед проверкой базового функционала.

Понятия и определения

• Алиас — совокупность данных об абоненте;
• Бридж — виртуальный шлюз, объединяющий связь между виртуальными АТС. Понятие «бридж» было введено для создания средств контроля соединениями между виртуальными АТС. Вызовы между виртуальными АТС одной системы ECSS-10 маршрутизируются в рамках данной системы через бридж. При этом не задействованы межстанционные соединительные линии. Бридж представлен в виде двух связанных друг с другом интерфейсов. Каждый интерфейс декларирован в своей виртуальной АТС. Для бриджа, как и для классического транка, могут быть заданы различные типы ограничений, например, количество каналов, что дает ограничение на количество одновременно установленных соединений между виртуальными АТС и позволяет нормировать нагрузку;
• Домен (виртуальная АТС) — совокупность, состоящая из множества контекстов маршрутизации, интерфейсов и алиасов. Ближайший эквивалент — описание плана нумерации и маршрутизации в рамках классической телефонной станции для традиционных сетей;
• Кластер — совокупность элементов одного типа, выполняющих, с точки зрения системы, единую функцию. С их помощью описывается вычислительная топология системы. В нашей системе элементом кластера является нода. Кластер существует до тех пор, пока в его состав входит хотя бы одна нода;
• Медиаресурсы — описание параметров медиасервера, необходимых для работы с ним;
• Медиасервер (MSR) — компонент системы ECSS-10, предназначенный для прокcирования речевой и видеоинформации по протоколу RTP, организации конференций, записи разговоров, воспроизведения медиафайлов и различных комбинаций этих режимов. Управление ресурсами медиасервера осуществляется с помощью механизма control channel (RFC 6230 Media Control Channel Framework, RFC 6231 IVR Control Package, RFC 6505 Mixer Control Package);
• Нода — представляет собой виртуальную машину Erlang и является элементом вычислительного кластера ECSS-10. Ноды в ECSS-10 типизируются по выполняемому на них функционалу. Однотипные ноды объединяются в кластеры соответствующего типа. Пример: кластер Core состоит из нод, выполняющих функцию ядра коммутационной системы;
• СОРМ — система технических средств для обеспечения функций оперативно-розыскных мероприятий;
• IVR (англ. Interactive Voice Response), интерактивное голосовое меню — система предварительно записанных голосовых сообщений, выполняющая функцию маршрутизации звонков внутри call-центра или УПАТС с использованием информации, вводимой клиентом на клавиатуре телефона с помощью тонального набора;
• LDAP (англ. Lightweight Directory Access Protocol — «легковесный протокол доступа к каталогам») — протокол прикладного уровня для доступа к службе каталогов;
• RADIUS — протокол, который предоставляет централизованный метод аутентификации пользователей путем обращения к внешнему серверу. Протокол RADIUS используется для аутентификации, авторизации и учета. Сервер RADIUS использует базу данных пользователей, которая содержит данные проверки подлинности для каждого пользователя. Таким образом, использование протокола RADIUS обеспечивает централизованное управление и дополнительную защиту при доступе к ресурсам сети.

Предварительные условия

Перед началом настройки конфигурации необходимо убедиться в следующем:

• установлена операционная система;
• настроен доступ в сеть Интернет;
• установлено необходимое ПО;
• установлены необходимые компоненты ECSS;
• настроен сервис NTP;
• подключен и работает Token;
• все подсистемы ECSS запущены и работают;
• установлены корректные паспорт и лицензия;
• если система в кластере, то дополнительно:
  • настроен и корректно работает keepalived;
  • работает репликация БД MySQL;
  • ноды в работе и "видят" друг друга;
  • настроен и работает GlusterFS.

Порядок начальной настройки конфигурации

В первую очередь необходимо выполнить общие настройки для всей системы:

• кластеры;
• медиасервер;
• маршрутизация, модификация и адаптация;
• пользователи ECSS;
• опционально:
  • СОРМ;
  • RADIUS;
  • LDAP.

Далее необходимо задекларировать и настроить следующие сервисы:

• домены;
• транки;
• бриджи;
• IVR;
• абоненты;
• услуги на транках и абонентах.

В последнюю очередь настраиваются дополнительные сервисы.

Рекомендуется проводить первоначальную настройку в порядке, приведенном ниже.

Конфигурирование кластеров

Классификация кластеров по ролям:

• BUS — кластер интеграционной шины, обеспечивающий надежную передачу сообщений;
• CORE — кластер, выполняющий функции маршрутизации телефонных вызовов и обработки услуг;
• STORAGE — кластер хранения долговременных данных;
• MEDIATOR — кластер, обеспечивающий функции управления комплексом, предоставление статистической информации и аварийной сигнализации;
• ADAPTER — кластер, выполняющий функции взаимодействия со шлюзами, работающими по одному из протоколов: H.248/Megaco, SIP и SIP‐T, PA Sigtran.

Более подробное описание каждого кластера приведено в разделе "Архитектура и принципы работы системы".

Данный этап включает в себя настройку всех кластеров системы (core, ds, mediator, pa_sip, pa_megaco). Каждый кластер может включать в себя одну или несколько нод одного типа. Например, кластер SIP-адаптера (pa_sip) может состоять из нескольких нод SIP-адаптеров.

При установке лицензии автоматически задается стандартная топология подсистемы:

• устанавливается определенный набор кластеров со стандартными именами;
• задается определенный набор нод со стандартными именами в кластерах.

Для управления кластерами системы могут использоваться:

• интерфейс командой строки CLI (описание команд, предназначенных для управления кластерами приведены в разделе /cluster/ );
• приложение Кластеры (Clusters) в web-конфигураторе.

Общие команды для конфигурирования свойств кластера

Данные команды являются основными для задания настроек любого кластера.

Для изменения индивидуальных настроек определенного кластера используется команда:

/cluster/<SOME_ROLE>/<NAME_CLUSTER>/<GROUP>/set <PROPERTY> [<NAME_NODE>|add|remove] <VALUE>

Для просмотра индивидуальных настроек определенного кластера используется команда:

/cluster/<SOME_ROLE>/<NAME_CLUSTER>/<GROUP>/info [<PROPERTY>]

где:

• <SOME_ROLE> — роль кластера: adapter, bus, core, mediator, storage;
• <NAME_CLUSTER> — имя кластера;
• <GROUP> — группа параметров;
• <NAME_NODE> — имя ноды;
• <PROPERTY> — имя свойства;
• <VALUE> — значение свойства.

Настройки кластера хранения данных STORAGE

Кластер storage выполняет функцию распределенного хранилища конфигурационных данных всей системы. Также в рамках этой подсистемы реализован модуль маршрутизации телефонных вызовов.

Настройка через CLI (CoCon)

Для изменения индивидуальных настроек кластера используется команда:

/cluster/storage/<NAME_CLUSTER>/<GROUP>/set <PROPERTY> <VALUE>

Для просмотра установленных значений параметров кластера используется команда:

/cluster/storage/<NAME_CLUSTER>/<GROUP>/info [<PROPERTY>]

где:

• <NAME_CLUSTER> — имя кластера, по умолчанию — ds1;
• <GROUP> — группа параметров;
• <PROPERTY> — имя свойства;
• <VALUE> — значение свойства.

Описание всех команд управления кластерами с ролью storage приведено в справочнике команд CLI.

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

Пример:

admin@mycelium1@ecss1:/$ cluster/storage/ds1/ss/install ds1@ecss1 ss_fax_receiver.xml               
Successfully installed: /var/lib/ecss/ss/ss_fax_receiver.xml

Настройка параметров кластера через web-интерфейс

Для просмотра и изменения свойств кластера используется приложение Кластеры (Clusters), где нужно выбрать кластер с ролью storage.

Для управления услугами в web-конфигураторе существует отдельное приложение — "Управление услугами (SS install)".

Настройка параметров кластера MEDIATOR

Кластер mediator предназначена для сбора и экспорта предупреждений и статистической информации.

Настройка через CLI (CoCon)

Для изменения индивидуальных настроек кластера используется команда:

/cluster/mediator/<NAME_CLUSTER>/<GROUP>/set <PROPERTY> <VALUE>

Для просмотра установленных значений параметров кластера используется команда:

/cluster/mediator/<NAME_CLUSTER>/<GROUP>/info [<PROPERTY>]

где:

• <NAME_CLUSTER> — имя кластера, по умолчанию – md1;
• <GROUP> — группа параметров;
• <PROPERTY> — имя свойства;
• <VALUE> — значение свойства.

Описание всех команд управления кластерами с ролью mediator приведено в справочнике команд CLI.

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

• службы уведомления о предупреждениях системы по электронной почте (email);
• работу с панелью аварий;
• правила маскирования предупреждений;
• параметры сбора статистики;
• параметры SNMP.

Остальные настройки по умолчанию уже готовы к работе и без необходимости их изменять не нужно.

Настройка параметров кластера через web-интерфейс

Для просмотра и изменения свойств используется приложение Кластеры (Clusters), где нужно выбрать кластер с ролью mediator. Для настройки маскирования предупреждений используется приложение "Список предупреждений (Alarm list)".

Для более тонкой настройки кластера смотрите раздел "Тонкая настройка системы".

Настройка параметров кластера CORE

Кластер core реализует логику управления обработкой телефонных вызовов (функции Call Control), предоставления услуг и обеспечение функционала биллинга.

Настройка через CLI (CoCon)

Для изменения индивидуальных настроек кластера используется команда:

/cluster/core/<NAME_CLUSTER>/<GROUP>/set <PROPERTY> <VALUE>

Для просмотра установленных значений параметров кластера используется команда:

/cluster/core/<NAME_CLUSTER>/<GROUP>/info [<PROPERTY>]

где:

• <NAME_CLUSTER> — имя кластера, по умолчанию – core1;
• <GROUP> — группа параметров;
• <PROPERTY> — имя свойства;
• <VALUE> — значение свойства.

Описание всех команд управления кластерами с ролью core приведено в справочнике команд CLI. Для кластеров с ролью core все необходимые для работы значения параметров по умолчанию уже готовы к обработке нагрузки.

Если проектом предусмотрено, то на начальном этапе настраиваются:

• параметры службы нотификации вызовов;
• подсистема TTS для сбора CDR;
• при необходимости изменения значений по умолчанию настраивается сервис автоинформаторов Call Forwarding by Cause (CFC).

Настройка параметров кластера через web-интерфейс

Для просмотра и изменения свойств используется приложение Кластеры (Clusters), где нужно выбрать кластер с ролью core. Настройка CDR производится в приложении "Менеджер CDR". Настройка автоинформаторов (CFC) выполняется в приложении "Автоинформатор (CFC)" в стандартном web-конфигураторе.

Настройка параметров кластеров PA_SIP

Общее описание принципов работы SIP-адаптера приведено в разделе "Описание работы SIP-адаптера".

Настройка через CLI (CoCon)

Для изменения индивидуальных настроек кластера используется команда:

/cluster/core/<NAME_CLUSTER>/<GROUP>/set <PROPERTY> <VALUE>

Для просмотра установленных значений параметров кластера используется команда:

/cluster/core/<NAME_CLUSTER>/<GROUP>/info [<PROPERTY>]

где:

• <NAME_CLUSTER> — имя кластера, по умолчанию — sip1;
• <GROUP> — группа параметров;
• <PROPERTY> — имя свойства;
• <VALUE> — значение свойства.

Описание всех команд управления кластерами с ролью adapter приведено в справочнике команд CLI в разделе "/cluster/adapter/<PA_SIP>/ — команды управления кластером протокола адаптера SIP".

На начальном этапе на адаптере необходимо настроить только SIP-транспорт (ipset) в соответствии с проектом:

• выбрать интерфейсы (node-ip) для работы адаптера. Если система с резервированием, то задаются IP, настроенные в /etc/keepalived.conf;
• добавить транспортные порты для приема сообщений протокола SIP;
• задать требуемое значение QoS DSCP.

Настройка остальных параметров SIP перенесена на уровень виртуальных АТС.

Настройка параметров кластера через web-интерфейс

Параметры SIP-транспорта также можно настроить с помощью web-конфигуратора. Для настройки интерфейса необходимо открыть приложение "Кластеры ("Clusters"), выбрать адаптер и внести параметры транспорта. Подробнее в разделе "Создание IP-set/(sip-транспорта)".

Настройка программного медиасервера

Порядок настройки программного медиасервера (MSR):

• настройка конфигурационного файла медиасервера;
• запуск медиасервера;
• добавление медиаресурсов на ECSS-10:
  • командами CLI (см. раздел "/system/media/resource/ - команды управления медиаресурсами");
  • через приложение web-конфигуратора "Сетевые окончания MSR (MSR registrars)".
• опционально в соответствии с проектом:
  • настройка распределенного медиасервера;
  • замена видеозаставки.

Создание и настройка доменов (виртуальных АТС)

Данный этап включает в себя процесс создания виртуальных АТС, настройку правил маршрутизации вызовов, транков, абонентов, правил обслуживания абонентов.

Декларация доменов

Необходимо создать домен по каждому из запроектированных доменов. При создании нужно добавить администратора ECSS-10 в группу администраторов, а также в группу пользователей данного домена.

Создание домена выполняется одним из двух способов:

• через интерфейс командной строки (CLI);
• через приложение web-конфигуратора "Домены".

После создания доменов в файловой системы автоматически создадутся нужные каталоги уровня домена.

Настройка маршрутизации

Маршрутизация телефонных вызовов — это процесс определения интерфейса назначения для конкретного вызова на основании информации об интерфейсе источника вызова, информации о телефонном номере вызывающего и вызываемого абонента, категории вызывающего абонента, времени суток и дне недели.
Контекст маршрутизации — совокупность правил маршрутизации уникальная в домене маршрутизации, в рамках которого идет определение интерфейса вызываемого абонента.

Описание процесса маршрутизации вызовов в системе ECSS-10 приведено в разделе "Виртуальная АТС. Маршрутизация телефонных вызовов".

Создание контекстов маршрутизации

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

Это можно сделать несколькими способами:

• создать и импортировать контексты вручную в формате, указанном в документации. Контексты в формате xml создаются в каталоге /var/lib/ecss/routing/ctx/src/<DOMAIN>;
• создать и настроить контексты, используя приложение web-конфигуратора "Менеджер маршрутизации (Routing manager)" для каждого домена;
• опционально — настроить RADIUS-маршрутизацию.

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

Создание контекстов модификации и адаптации

Модификаторы номеров — набор правил модификации номеров, которые применяются при звонке с определенного интерфейса или на определенный интерфейс. Модификатор назначается на интерфейс ECSS-10 (транк, абонент), группу интерфейсов.

Адаптация номеров — набор правил модификации номеров для СОРМ, TTS. Технически, это те же модификаторы номеров, но только применимые для адаптации номеров из внутреннего формата к формату СОРМ, TTS.

Описание и синтаксис контекстов адаптации и модификации приведен в разделе Виртуальная АТС. Маршрутизация телефонных вызовов/Модификаторы и адаптация номеров по входу-выходу с интерфейса.

Применение контекстов маршрутизации для системных интерфейсов

Для интерфейсов system:ivr и system:teleconference необходимо назначить контексты маршрутизации. Настройки выполняются с помощью команд CLI. Описание и примеры команд приведены в разделе "/domain/<DOMAIN>/system-iface/ - команды управления системными интерфейсами".

Настройка CDR

CDR (Call Detail Record) — детальная запись о параметрах вызова (номера телефонов, время начала разговора, продолжительность разговора и другое).

Для управления настройками системы CDR используется интерфейс командой строки и web-интерфейс.

Команды, предназначенные для управления настройками CDR, располагаются на виртуальной файловой системе CLI в директории /domain/<DOMAIN>/cdr/. Описание команд приведено в разделе Справочник команд CLI.

Для управления CDR-файлами через web-конфигуратор используется приложение Менеджер cdr (Cdr manager).

Если система в кластере, предварительно должна быть настроена Репликация БД MySQL.

Порядок настройки системы CDR:

1. Настройки TTS;
2. Создание и настройка CDR-группы;
3. Добавление алиаса (абонента) или транка в определенную CDR-группу.

Добавление и настройка прав пользователей

Пользователями являются лица, работающие с системой через СoСon или web-конфигуратор.

Каждый пользователь имеет следующий набор параметров:

• Имя;
• Пароль;
• Группа(ы) пользователей;
• Роль.

По умолчанию в системе создается пользователь admin с правами администратора системы. Пароль по умолчанию — password.

Для разграничения прав нужно создать требуемое количество пользователей и назначить каждому права и роли. Подробнее в разделе "Управление пользователями". Каждый пользователь может настроить себе параметры оболочки CoCon для удобства работы с помощью глобальной команды /shell-options.

Настройка правил ограничения обслуживания абонентов

Для возможности применять различные ограничения уровня абонента необходимо их настроить для каждого домена.

Различаются следующие виды ограничений для абонентов:

• долговременные ограничения, которые вводятся при подключении абонента и прописываются в договоре с абонентом, называются типом доступа (access_type);
• группировка абонентов для возможности выхода абонентов одной группы на абонентов другой группы называется группой доступа (access_group);
• временные ограничения, связанные с неоплатой абонентом счетов, называются режимом обслуживания (regime);
• ограничения, которые задает себе сам абонент, называются баррингами (barring).

Описание и настройка типов доступа, групп доступа, режимов обслуживания и баррингов приведены в разделе "Тип доступа, режим обслуживания, категория доступа и барринги".

Настройка производится:

• через интерфейс командной строки, см. разделы:
  • /domain/<DOMAIN>/access-group - команды управления группами доступа;
  • /domain/<DOMAIN>/access-type - команды управления типами доступа;
  • /domain/<DOMAIN>/regime/ - команды управления режимами обслуживания абонентов.
• через приложение web-конфигуратора "Менеджер доступа (Access manager)".

Создание и настройка абонентов

В соответствии с проектом в доменах нужно создать требуемое количество абонентов. Сделать это можно с помощью команды CLI /domain/<DOMAIN>/sip/user/declare или приложения web-конфигуратора "Карточка абонента (Subscriber card)".

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

Абоненты в домене — условие необязательное, в системе могут быть и чисто транзитные домены, на которых настраиваются соответствующие правила прохождения вызовов.

Создание и настройка транков

• Транк представляет собой совокупность ресурсов для обслуживания телефонных вызовов в заданном направлении (см. раздел "Транки и бриджи");
  
• SIP-Транк представляет собой направление, работающее по протоколу SIP/SIP-Т/SIP-I;
• Динамический транк — транк с обязательной поддержкой регистрации. Для совершения вызова по динамическому транку взаимодействующий шлюз должен быть зарегистрирован по данному транку в системе ECSS-10.

Декларация и настройка транков производится:

• через интерфейс командной строки, см. раздел "/domain/<DOMAIN>/trunk/sip/ - команды управления транками SIP";
• через приложение web-конфигуратора "Менеджер транков (Trunk manager)".

Порядок создания и настройки транков приведен в разделе "Управление SIP-транками".

Далее на транках настраиваются необходимые сервисы.

Создание и настройка bridge-интерфейсов

Бридж  — виртуальный транк, позволяющий соединять между собой две виртуальные АТС в рамках одной системы ECSS-10.

Если в системе имеется более одного домена, то связь между ними осуществляется с помощью бриджей (см. раздел "Транки и бриджи").

Бриджи создаются и настраиваются:

• через интерфейс командной строки, см. раздел "/bridge/ — команды управления bridge-интерфейсами";
• через приложение web-конфигуратора "Менеджер бриджей (Bridge manager)".

Настройка ограничений

Для каждого домена существует возможность задать разного рода ограничения в рамках лицензии.

Таблица 1. Список ограничений уровня домена

Ограничения настраиваются в соответствии с проектом:

• через интерфейс командной строки, см. раздел "/domain/<DOMAIN>/properties/restrictions/ - команды управления ограничениями виртуальной АТС";
• через приложение web-конфигуратора "Домены (Domains)" (Свойства домена -> Системные параметры -> Ограничения).

Сценарии IVR

Для каждой виртуальной АТС можно настроить дополнительные сценарии IVR, если они сразу предусмотрены проектом. Сценарии создаются в приложении web-конфигуратора "IVR-редактор (IVR editor)".  Также управлять сценариями можно с помощью команд CLI. Описание и примеры приведены в разделе "/domain/<DOMAIN>/ivr/ - команды управления IVR-скриптами".

При необходимости для каждого домена можно настроить ограничения для работы IVR:

• через интерфейс командной строки, см. раздел "/system/ivr/script/restrictions/ - команды управления настройками ограничений IVR-скриптов";
• через приложение web-конфигуратора "Редактор IVR ограничений (IVR restrictions manager)".

Настройка дополнительных сервисов

Если предусмотрено проектом, на начальном этапе настраиваются также дополнительные сервисы.

Настройка взаимодействия с серверами RADIUS

Описание и настройка взаимодействия с подсистемой AAA (Authentication, Authorization, Accounting) приведены в разделе "Настройка динамических абонентов и системы RADIUS".

Порядок настройки взаимодействия с серверами ААА:

• настройка параметров виртуальной АТС для взаимодействия с сервером аутентификации/авторизации (RADIUS);
• настройка параметров виртуальной АТС для взаимодействия с сервером аккаунтинга (RADIUS);
• настройка ограничений связи при сбое сервера.

Настройка функции СОРМ

В комплексе ECSS-10 заложены возможности для выполнения требований к системе технических средств по обеспечению функций оперативно-розыскных мероприятий на электронных АТС, утвержденные приказом Госкомсвязи России от 20.04.1999 № 70 и приказом Минкомсвязи России №268 от 19.11.2012.

Порядок настройки функции СОРМ:

• проверка наличия соответствующей лицензии;
• настройка протокола взаимодействия с посредником СОРМ;
• настройка маршрутизации в соответствии с требованиями сотрудников спецслужб.

Описание и настройка системы СОРМ приведены в разделе "Система СОРМ".

Настройка дополнительных приложений

В составе экосистемы ECSS-10 возможно использование дополнительных сервисных приложений, расширяющих функциональные возможности:

• Call-центр;
• инструментарий для проведения селекторных совещаний;
• сервис "Автообзвон";
• сервис автоматического распознавания речи (ASR);
• интеграции с Desktop-ассистент, CRM, Skype for business);
• сервис "Автосекретарь";

• визуализация статистических данных в системе мониторинга "Grafana";

• приложение "Портал абонента";
• система "Autoprovision (AUP)" для автоматического конфигурирования и обновления ПО телефонных аппаратов.

Описание данных приложений приведено в соответствующих разделах документации.

Настройка ECSS-10 для производительных систем

Для производительных систем настройка ECSS-10 состоит из следующих этапов:

Выделение отдельных ядер процессора для MSR

Для того чтобы изолировать MSR-медиасервер от остальной сиcтемы, необходимо выделить под него отдельные ядра процессора. Для выделения отдельных ядер процессора необходимо выполнить следующие действия:

1. Открыть файл:

   /etc/default/grub

   Привести параметр GRUB_CMDLINE_LINUX="" к следующему виду:

   GRUB_CMDLINE_LINUX="isolcpus=8-11"

   Данный пример изолирует ядра с 8 по 11. Также возможен вариант с перечислением 1, 2, 4-6 и т.п.

2. Обновить конфигурацию grub. Для этого выполните команду:

   sudo update-grub

3. Перезапустить систему.

   Если всё сделано правильно, то после перезагрузки на изолированных ядрах htop будет показывать нулевую нагрузку.

Установка scaling_governor в режим perfomance

По умолчанию в Ubuntu есть пять профилей работы процессора.

Описание профилей:

• conservative — медленно повышает частоту процессора в зависимости от нагрузки на систему и резко сбрасывает частоту к минимальной при простое;
• ondemand — быстро повышает частоту процессора при возрастании нагрузки и медленно сбрасывает частоту к минимуму при простое;
• userspace — позволяет указывать частоту вручную;
• powersave — соответствует минимальной допустимой частоте CPU;
• performance — соответствуют максимальной частоте CPU.

Проверить текущее значение для всех ядер можно следующей командой:

sasha@ecss1:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
performance
performance
performance
performance
performance
performance
performance
performance

Режимы, которые поддерживаются процессором можно посмотреть командой cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors. Пример:

sasha@ecss1:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative ondemand userspace powersave performance schedutil 

Ядро в Ubuntu 18.04 собирается с GOVERNOR=performance по умолчанию, но systemd-сервис ondemand.service может менять текущее значение на ondemand или powersave. Сервис запускается при старте системы, выставляет режим powersave запуском скрипта /lib/systemd/set-cpufreq:

sasha@ecss1:~$ cat /lib/systemd/set-cpufreq
#! /bin/sh
# Set the CPU Frequency Scaling governor to "ondemand"/"powersave" where available
set -eu

FIRSTCPU=`cut -f1 -d- /sys/devices/system/cpu/online`
AVAILABLE="/sys/devices/system/cpu/cpu$FIRSTCPU/cpufreq/scaling_available_governors"
DOWN_FACTOR="/sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor"

[ -f $AVAILABLE ] || exit 0

read governors < $AVAILABLE
case $governors in
        *interactive*)
                GOVERNOR="interactive"
                break
                ;;
        *ondemand*)
                GOVERNOR="ondemand"
                case $(uname -m) in
                        ppc64*)
                                SAMPLING=100
                        ;;
                esac
                break
                ;;
        *powersave*)
                GOVERNOR="powersave"
                break
                ;;
        *)
                exit 0
                ;;
esac

[ -n "${GOVERNOR:-}" ] || exit 0

echo "Setting $GOVERNOR scheduler for all CPUs"

for CPUFREQ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
do
        [ -f $CPUFREQ ] || continue
        echo -n $GOVERNOR > $CPUFREQ
done
if [ -n "${SAMPLING:-}" ] && [ -f $DOWN_FACTOR ]; then
        echo -n $SAMPLING > $DOWN_FACTOR
fi

Отключить сервис необходимо командой:

sudo systemctl mask ondemand.service

Перезагрузка сервиса осуществляется командой:

sudo reboot

Система выдерживает большую нагрузку в режиме perfomance. Для того чтобы включить данный режим по умолчанию, необходимо:

Вариант 1

Привести файл /etc/rc.local к следующему виду:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor >/dev/null
exit 0

Установку необходимо совершать через создание дополнительного правила в /etc/udev/rules.d/.

Вариант 2

После маскирования сервиса ondemand.service необходимо принудительно выставить режим performance.

1. Поставьте пакет cpufrequtils:

sudo apt install cpufrequtils

2. В файле /etc/default/cpufrequtils установите переменную GOVERNOR="performance":

echo 'GOVERNOR="performance"' | sudo tee /etc/default/cpufrequtils

3. Перезагрузите сервис:

sudo reboot

4. Проверьте результат:

sasha@ecss1:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
performance
performance
performance
performance
performance
performance
performance
performance

Запуск MSR на изолированных ядрах процессора

Для того чтобы MSR запускался на отдельных ядрах процессора, необходимо привести файл /etc/systemd/system/ecss-media-server.service.d/override.con к следующему виду:

[Service]
CPUAffinity=8-11
CPUSchedulingPolicy=rr

Перед этим нужно включить экземпляр MSR:

systemctl enable ecss-media-server@msr.service
systemctl edit ecss-media-server@msr.service

Для просмотра того, на каких ядрах запустился сервис, можно воспользоваться htop. В нем нужно добавить колонку Processor.

В данном примере MSR запущен на ядрах 8, 9, 10, 11. CPUSchedulingPolicy необходим, только если указан isolcpus.

Настройка MSR более подробно описана на странице Настройка программного медиасервера.

Настройка использования определенных ядер процессора для erlang-based служб

Для того чтобы ядра процессора использовались правильно, необходимо скорректировать параметры запуска erlang-нод на производительных системах.

Для этого разрабатывается схема размещения нод на ядрах.

Схема разрабатывается по следующим правилам:

• использовать более двух ядер;
• необходимо, чтобы одна нода не использовала ядра на разных процессорах;
• для сильно нагруженных нод, таких как core и sip, нужно выделять индивидуальные ядра;
• ноды, которые не загружены, можно размещать на одном ядре;
• для core необходимо выделять большее количество ядер.

Распределения ядер на примере двухпроцессорного сервера HP BL660 c двумя процессорами Intel Xeon E5-4657L c 12 ядрами и поддержкой гипертрединга, которые могут образовать 8 виртуальных ядер:

myc  0-3
ds   4-7
core 8-23
sip  24-31
md   32-35
rest 36-39
sp   40-43
msr  44-47

Для осуществления данного распределения необходимо включить режим использования только необходимого количества ядер на erlang-ноде.

Для этого редактируем файл vm.args каждой ноды, расположенный по пути  /usr/lib/ecss/ECSS-SERVICE-NAME/releases/VERSION/.

Например, для ecss-core необходимо отредактировать файл:

sudo mcedit /usr/lib/ecss/ecss-core/releases/3.14.2.29/vm.args

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

Для 16-ти ядер это:

+sct L0-15c0-15
+sbt db
+S16:16

Для 8-ми ядер:

+sct L0-7c0-7
+sbt db
+S8:8

Для 4-х ядер:

+sct L0-3c0-3
+sbt db
+S4:4

Для 2-х ядер:

+sct L0-1c0-1
+sbt db
+S2:2

Следующая задача — установить сервис на выбранные ядра. Делается это аналогично тому, как описано для MSR.

Необходимо выполнить команду:

sudo systemctl edit ECSS-SERVICE-NAME

Далее добавить параметры:

[Service]
CPUAffinity=0-3

где в значении CPUAffinity указываются те ядра, на которых должны запускаться процессы сервиса.

Пример настройки ecss-core по указанной выше схеме:

> sudo systemctl edit ecss-core.service
[Service]
CPUAffinity=8-23

После настройки параметров CPUAffinity для всех сервисов необходимо перезагрузить конфигурацию услуг командой:

sudo systemctl daemon-reload

Перезапустить сервисы:

sudo systemctl restart ecss.slice

Убедиться в корректной привязке сервисов к ядрам можно утилитой htop, включив отображение колонки PROCESSOR.