Инсталляция ОС

В этом разделе приведено описание инсталляции операционной системы, а также необходимых и дополнительных пакетов. Система ECSS-10 версии 3.14 работает под управлением ОС Ubuntu Server 18.04.x LTS 64bit.

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

  • Установочный загрузочный носитель с дистрибутивом операционной системы;
  • Подготовленный сервер с обновленным BIOS, ILO (если есть), подключенная сеть для доступа в сеть Интернет;
  • Выставленный первый приоритет загрузки с установочного носителя — USB Flash или CD/DVD в BIOS;
  • Достаточный объем дискового пространства и памяти в соответствии с проектом.

Установка ОС

Для установки ОС необходимо выполнить следующее:

После загрузки с установочного носителя выбрать "Install Ubuntu Server".

Выбрать язык системы и раскладку клавиатуры.

Настройка сетевых интерфейсов

Настроить сетевой интерфейс для подключения к сети Интернет:

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

Выбрать параметр "Custom storage layout":

Далее в LVM-группе создать дополнительные разделы в соответствии с таблицей 1.

Таблица 1 — Вариант размещения информации в файловой системе на физических носителях для серверов

1Загрузочный раздел операционной системы (создается автоматически)bootraid 1:hdd1,hdd2boot/bootext41 GbПервичный
2Корневой раздел операционной системыrootraid 1:hdd1,hdd2root/ext430 GbЛогический
3Информация локальных баз данныхmnesiaraid 1:hdd1, hdd2mnesia/var/lib/ecssext410 GbЛогический
4Распределенная БД для хранения медиаресурсовglusterfsraid 1:hdd1, hdd2 или hdd3glusterfs/var/lib/ecss/glusterfs*ext4Max GbЛогический
5Журналы функционирования подсистем ОСlograid 1:hdd1,hdd2 или hdd3log/var/logext45 GbЛогический
6Журналы функционирования подсистем ECSSecss_lograid 1:hdd1,hdd2 или hdd3ecss_log/var/log/ecssext420 GbЛогический
7Базы данныхecss_dbraid 1:hdd1,hdd2 или hdd3ecss_db/var/lib/ecss-mysqlext4100–400 Gb**Логический
8Файлы пользователяhomeraid 1:hdd1,hdd2 или hdd3home/homeext410 GbЛогический


* Если сервер не будет работать в кластере, то вместо glusterfs создается раздел /var/lib/ecss/restfs.

** Рекомендуемое значение для серий Light, Light+, Midi — 100 Gb. Рекомендуемое значение для серии Heavy — 200 Gb,  Super Heavy — 400 Gb.

Для работы системы необходимо как минимум 200 Gb свободного пространства.

Пример создания разделов диска размером 200 Gb:

Настройка имени пользователя и сервера

На серверах системы необходимо настроить параметр "hostname".

На всех серверах системы желательно указать одинаковое имя пользователя (любое, кроме ssw). Лицензия ECSS-10 привязывается к ключу eToken/ruToken и к имени компьютера (hostname), поэтому необходимо использовать стандартные значения. Системный пользователь ssw создается при инсталляции пакета ecss-user.

Если используется один сервер, рекомендуемое значение hostname — ecss1;

При установке системы в кластере значение для первого сервера — ecss1, для второго — ecss2.


Установка OpenSSH server 

В конце инсталляции ОС будет предложено установить дополнительное программное обеспечение для возможности удаленного подключения — необходимо установить OpenSSH server.

Отключение swap

В Ubuntu 18.04 swap-файл располагается в корневом каталоге — /swap. img.

По завершении инсталляции операционной системы необходимо отключить SWAP: SWAP на серверах с ECSS-10 использовать нельзя!

Для отключения:

sudo swapoff -a

sudo rm /swap.img

Установка часового пояса

При инсталляции Ubuntu-18.04 не предлагается установить часовой пояс. Его можно установить вручную, например:

sudo timedatectl set-timezone Asia/Novosibirsk

Проверка установки ОС

Проверка в основном сводится к правильности создания разделов диска и наличия доступа по ssh.

Для вывода информации о состоянии дискового пространства введите команду df -h. Она покажет общее и занятое место в разделах. Размеры разделов должны соответствовать проекту и введенным значениям при установке.

Для проверки доступа по ssh с машины, находящейся в одной подсети со вновь установленным сервером, нужно выполнить команду:

ssh <user>@<IP_ecss>

где:

  • <user> — имя пользователя, заданного при установке;
  • <IP_ecss> — IP-адрес хоста, заданного при установке.

Настройка /etc/hosts

Доменному имени хоста ecss1 должен соответствовать адрес 127.0.1.1. Также нужно прописать адрес хоста ecss2. Для этого в файле /etc/hosts необходимо прописать IP-адреса хостов ecss.

Например, для кластера: ecss1 имеет адрес 192.168.1.21, ecss2 — 192.168.1.22. Данные адреса нужно прописать в /etc/hosts:

ecss1:

127.0.0.1 localhost
127.0.1.1 ecss1
192.168.1.22 ecss2

ecss2:

127.0.0.1 localhost
127.0.1.1 ecss2
192.168.1.21 ecss1

Настройка сетевых интерфейсов

Получение адресов на сетевых интерфейсах по DHCP недопустимо на серверах ECSS.

Сетевые настройки необходимо выполнять с помощью Netplan.

Пример:

Нужно настроить сервер с 4-мя сетевыми интерфейсами с агрегацией каналов (802.3ad) и необходимыми VLAN. Имеется шлюз для выхода в интернет — 192.168.1.203

  • vlan2 — VoIP VLAN для трафика SIP/RTP;
  • vlan3 — локальная сеть обмена между серверами кластера и локального управления;
  • vlan476 — сеть взаимодействия с внешними корпоративными сервисами, статическая маршрутизация в подсеть 10.16.0.0/16 и маршрутизация в подсеть 10.136.16.0/24(для NTP):


sasha@ecss1:~$ cat /etc/netplan/10-ecss1_netplan.yaml 
# netplan for ecss1
network:
    version: 2
    renderer: networkd
    ethernets:
        enp3s0f0:
            dhcp4: no
        enp3s0f1:
            dhcp4: no
        enp4s0f0:
            dhcp4: no
        enp4s0f1:
            dhcp4: no

    bonds:
        bond1:
            interfaces:
                - enp3s0f0
                - enp3s0f1
                - enp4s0f0
                - enp4s0f1
            parameters:
                mode: 802.3ad
            optional: true

    vlans:
        bond1.2:    # Voip internal vlan 2
            id: 2
            link: bond1
            addresses: [192.168.2.21/24]
        bond1.3:    # mgm internal vlan 3
            id: 3
            link: bond1
            addresses: [192.168.1.21/24]
            gateway4: 192.168.1.203
            nameservers:
                addresses: [192.168.1.203]
        bond1.476:
            id: 476 # mgm techology net vlan 476
            link: bond1
            addresses: [10.16.33.21/24]
            routes:
                - to: 10.16.0.0/16
                  via: 10.16.33.254
                  on-link: true
                - to: 10.136.16.0/24
                  via: 10.16.33.254
                  on-link: true

Для применения новых сетевых настроек необходимо выполнить команду netplan apply. Перезапуск сети или системы не требуется.

Подробнее про настройки netplan см. в Приложении Е. Netplan.


Обновление ОС и инсталляция необходимого ПО

Обновление системы

Добавление репозитория ELTEX:

sudo sh -c "echo 'deb [arch=amd64] http://archive.eltex.org/ssw/bionic/3.14 stable main extras external' > /etc/apt/sources.list.d/eltex-ecss10-stable.list"

Обратите внимание, что требуется указать верную версию операционной системы при добавлении репозитория ELTEX:

  • если установка происходит на Ubuntu 18.04, необходимо указать bionic, как приведено в примере выше.
  • если ECSS-10 устанавливается на Astra Linux, необходимо указать соответствующие репозитории smolensk:
sudo sh -c "echo 'deb [arch=amd64] http://archive.eltex.org/ssw/smolensk/3.14 stable main extras external' > /etc/apt/sources.list.d/eltex-ecss10-stable.list"
sudo sh -c "echo 'http://archive.eltex.org astra smolensk smolensk-extras' > /etc/apt/sources.list.d/eltex-ecss10-stable.list"

Далее необходимо выполнить импорт ключа командой:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 33CB2B750F8BB6A5

Перед началом установки необходимо обновить ОС:

sudo apt update
sudo apt upgrade

Инсталляция необходимого ПО

Список обязательного сервисного программного обеспечения:

sudo apt install ntp tcpdump vlan dnsmasq
ntpNTP-сервер
tcpdumpсниффер пакетов
vlanуправление VLAN
dnsmasqлегковесный DNS/DHCP-сервер

Список рекомендуемого диагностического и вспомогательного программного обеспечения:

sudo apt install aptitude atop ethtool htop iotop mc minicom mtr-tiny nmap pptpd pv screen ssh tftpd vim sngrep tshark cpanminus gnuplot libgraph-easy-perl debconf-utils
aptitudeустановка программ из репозиториев, рекомендуется использовать вместо программы apt/apt-get
atopмониторинг загрузки хоста с функцией периодического сохранения информации в файлы
ethtoolпросмотр статистики сетевых интерфейсов
htopмониторинг процессов
iotopмониторинг подсистем ввода/вывода
mcфайловый менеджер
minicomтерминал для RS-232
mtr-tinyвыполняет функции ping и traceroute
nmapсканер портов
pptpdVPN-сервер
pvмониторинг межпроцессного обмена
screenмультиплексор терминалов
sshсервер и клиент SSH
tftpdTFTP-сервер
vimтекстовый редактор
sngrepтрассировка sip
tsharkконсольный аналог wireshark
cpanminusпросмотр медиа-трассировок (для просмотра необходимо воспользоваться командой sudo spanm Graph::Easy)
gnuplotвывод графиков статистики
libgraph-easy-perlPerl-модуль для преобразования или рендеринга графиков (в ASCII, HTML, SVG или через Graphviz)
debconf-utilsнабор утилит для работы с базой debconf

Данное программное обеспечение не требуется для работы системы ECSS-10, однако может упростить сервисное обслуживание системы и её отдельных компонентов со стороны инженеров эксплуатации и техподдержки.

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

sudo apt install ifenslave-2.6 keepalived attr
ifenslave-2.6управление BOND-интерфейсами
keepalivedсервис мониторинга серверов/служб в кластере
attrсервис управления атрибутами файловых систем

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

sudo apt install bridge-utils ethtool
bridge-utilsуправление bridge-интерфейсами
ethtoolуправление и мониторинг сетевых интерфейсов

Для просмотра установленных пакетов выполните следующую команду (данный пункт является необязательным: его можно выполнить, если вы не уверены, что какое-то приложение установлено):

sudo dpkg --get-selections

Инсталляция пакетов ECSS

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

  • Установленная и обновленная операционная система (Ubuntu-18.04);
  • Отсутствие в системе пользователя с именем ssw;
  • Разбиение дискового пространства в соответствии с рекомендациями;
  • Настроенная сеть;
  • Установленный набор необходимых пакетов;
  • Доступ к репозиторию ELTEX.


В ходе установки пакетов ECSS нужно будет ответить на ряд вопросов для формирования необходимой конфигурации. Для автоматической загрузки требуемых настроек можно воспользоваться командами из пакета debconf-utils.

Описание и примеры использования при работе с debconf приведены в Приложении В. Debconf.

Для инсталляции системы ECSS-10 необходимо устанавливать пакеты в порядке, в котором они описаны ниже в документации.

Инсталляция обязательных пакетов

Установка ecss-mysql

Первым необходимо установить пакет ecss-mysql.

Перед установкой необходимо убедиться, что в системе не установлен mysql-сервер, и папка /var/lib/mysql/ пуста. При необходимости удалите все ее содержимое командой:

sudo rm -R /var/lib/mysql/

Если система разворачивается в кластере, то установку пакета и настройку репликации баз данных необходимо выполнить по инструкции из раздела "Схема развертывания MySQL master-master replication с использованием keepalive".

Для установки MySQL-сервера выполните команду:

sudo apt install ecss-mysql

При инсталляции пакета устанавливается сервер MySQL с нужными настройками, и создаются необходимые базы данных. В ходе установки будут запрошены следующие данные:

  • IP-маска для прав MySQL-таблиц ("IP pattern for MySQL permission") — маска указывает, для какого пула IP-адресов будет доступен вход в базу данных:
    • если ecss-mysql устанавливается на том же хосте, что и остальная система (ecss-node), используйте адрес 127.0.0.%.
    • если ecss-mysql сервер будет установлен на другом хосте, то укажите пул адресов, в который будет входить адрес сервера, на котором будет установлен ecss-node. К примеру, если ecss-node будет установлен на сервер с IP-адресом 192.168.1.1/24, а ecss-mysql — на сервер с IP-адресом 192.168.1.2/24, то в ответе на этот вопрос нужно указать маску 192.168.1.%. 
  • Логин для администратора mysql ("Login for MySQL root") — данный логин будет установлен для сервера mysql.

    Логин необходимо запомнить, так как он потребуется в ходе установки других нод. Также он используется в процессе создания резервной (backup) копии системы. 

  • Пароль для администратора mysql ("Password for MySQL root") — данный пароль будет установлен для пользователя, указанного в ответе на предыдущий вопрос. 

    Пароль необходимо запомнить, так как он потребуется в ходе установки других нод. Также он используется в процессе создания резервной (backup) копии системы. 

Базы данных MySQL, используемые системой ECSS-10, после установки будут храниться в /var/lib/ecss-mysql. При установке пакета ecss-mysql apt задаст вопрос о разрешении изменения конфигурационного файла /etc/apparmor.d/local/usr.sbin.mysqld, чтобы изменить путь до баз данных MySQL по умолчанию. Для успешной установки ecss-mysql требуется разрешить изменения (введите "Y"). Чтобы избежать ввода ответа на вопрос при установке пакета, допускается использовать дополнительные ключи при вводе команды установки:
sudo apt-get -o Dpkg::Options::="--force-confnew" install ecss-mysql 

Проверка корректности установки

Чтобы убедиться в корректности установки после ее завершения, проверьте, запущен ли MySQL-сервер:

systemctl status mysql
● mysql.service - MySQL Community Server
   Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/mysql.service.d
           └─override.conf
   Active: active (running) since Fri 2021-09-24 20:52:50 +07; 2 weeks 2 days ago
 Main PID: 12374 (mysqld)
    Tasks: 94 (limit: 4915)
   CGroup: /system.slice/mysql.service
           └─12374 /usr/sbin/mysqld --daemonize --pid-file=/run/mysqld/mysqld.pid

Sep 24 20:52:50 ecss1 systemd[1]: Starting MySQL Community Server...
Sep 24 20:52:50 ecss1 systemd[1]: Started MySQL Community Server.

Попробуйте войти в базу данных MySQL под логином (<LOGIN>), с паролем (<PASSWORD>), указанным при установке:

sudo mysql -u<LOGIN> -p<PASSWORD>
mysql>

В случае корректной установки откроется CLI MySQL-сервера. 

Можно сразу посмотреть список созданных БД:

mysql> SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| ecss_address_book  |
| ecss_audit         |
| ecss_calls_db      |
| ecss_dialer_db     |
| ecss_meeting_db    |
| ecss_numbers_db    |
| ecss_statistics    |
| ecss_subscribers   |
| ecss_system        |
| history_db         |
| mysql              |
| performance_schema |
| sys                |
| web_conf           |
+--------------------+

Чтобы выйти из CLI MySQL, выполните команду "exit".

В целях безопасности в версиях mysql-5.7 и выше логин root разрешено использовать только для входа с локального хоста.

Установка ecss-node

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

В системе уже должен быть установлен пакет ecss-mysql

Для установки пакета ecss-node выполните команду:

sudo apt install ecss-node

Во время установки пакета создается пользователь ssw, от имени которого запускаются все сервисы ecss*. Создаются необходимые каталоги, выполняется настройка DNS, идет настройка SSL-сертификатов. В ходе инсталляции будут задаваться вопросы, необходимые для формирования конфигурационных файлов.

Настройка сертификатов

Актуален, только если был сгенерирован самоподписанный сертификат, тогда в систему установится  ecss10root.crt  (при копировании также пытается скачать  ecss10root.crt, либо если при ручной установке был помещён данный файл). Если уже имеются сертификаты, то никаких действий не будет произведено. В конце также проверяется валидность сертификата.

Чтобы сгенерировать новый сертификат, необходимо удалить ecss10.{pem,crt,key} и ecss10root.{crt,key}, после чего сделать dpkg-reconfigure ecss-user.

Если планируется установка системы в кластере, то, как правило, на первом сервере нужно сгенерировать сертификат, а при установке ecss-node на втором сервере выбрать копирование с первого сервера (подробнее см. в разделе "Настройка сертификатов ECSS-10").

При установке будут заданы вопросы по сертификатам.

Способы конфигурирования сертификатов:

Ручной (manual)

При выборе ручного способа конфигурации сертификатов откроется окно с информацией о том, что установка может быть продолжена после помещения файлов ecss10.{pem,crt,key} в /etc/ecss/sll. Также данное окно может открыться по достижении конца установки. Поместите необходимые файлы в требуемую директорию и начните процесс установки заново (перезапустите установку). Если все действия были выполнены верно — установка завершится, и можно будет продолжить установку системы.

Сгенерировать самоподписанный сертификат (generate)

При выборе данного способа будут сгенерированы следующие вопросы:

  • Страна (RU)
  • Область (Novosibirsk)
  • Город (Novosibirsk)
  • Организация (ELTEX)
  • Структурный узел (IMS)
  • Имя сертификата (ecss10)
  • Почта (ssw-team@eltex.loc)
  • Количество дней жизни сертификата
  • Пароль для корневого приватного ключа
  • Алгоритм шифрования для ключа
  • Сложность ключа
  • Сложность для параметров Диффи-Хеллмана
  • Дополнительные имена, за которые отвечает сертификат (на примере офиса — это ssw1.eltex.loc, ssw2.eltex.loc, ssw.eltex.loc), перечисленные через пробел (для последнего уровня можно wildcard)

Чем выше сложность ключа, тем дольше будет установка (dhparam при сложности 8192 на машине средней производительности занимает около часа). При отсутствии особых требований к безопасности можно оставить значение по умолчанию. После чего отобразится уведомление, что необходимо убрать приватный корневой ключ в безопасное место.

Скопировать существующие сертификаты (copy) по ssh
При выборе данного способа будут сгенерированы следующие вопросы:

  • Логин (user)
  • Адрес удалённой машины (ecss1)
  • Порт (22)
  • Способ авторизации (password или identity_file)
  • Пароль (password)
  • Файл с ключом (/home/<user>/.ssh/id_rsa)
  • Путь до папки с сертификатом (/etc/ecss/ssl)

Скопировать по http

При выборе данного способа будут сгенерированы следующие вопросы:

  • url (https://system.restfs.ecss:9993/certs)
  • Логин (если используется авторизация basic)
  • Пароль
  • Скопировать с другого сервера ecss10

Используется API http_terminal

При выборе данного способа будут сгенерированы следующие вопросы:

  • url до http_terminal (https://ecss1:9999)
  • Логин (admin)
  • Пароль (password)
  • Нода с сертификатами (core1@ecss1)

Настройка epmd

Сервис epmd требует наличия IPv6-адреса на IO-интерфейсе. Для отключения (если в этом возникнет реальная потребность) IPv6 на отличных от IO интерфейсах используйте следующие настройки в sysctl:

net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 0

DNS

В ходе установки пакета ecss-node выполняется конфигурирование внутренних DNS-адресов. При установке, в зависимости от текущей конфигурации системы, может отобразиться сообщение:

See "systemctl status dnsmasq.service" and "journalctl -xe" for details.
invoke-rc.d: initscript dnsmasq, action "start" failed.
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server

Такой вывод в ходе установки является нормальным и не свидетельствует о проблемах. Главное, чтобы после окончания установки ecss-node dnsmasq.service был активен.

Пример:

sasha@ecss1:~$ systemctl status dnsmasq.service 
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
   Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2021-09-24 20:52:03 +07; 2 weeks 3 days ago
 Main PID: 10914 (dnsmasq)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/dnsmasq.service
           └─10914 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service --trust-anchor=.,19036,8,2,49aac11d7b6f6446702e54a1607371607a1a41

Sep 24 20:52:03 ecss1 systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server...
Sep 24 20:52:03 ecss1 dnsmasq[10890]: dnsmasq: syntax check OK.
Sep 24 20:52:03 ecss1 systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server.

Установка ecss-media-server

Пакет ecss-media-server — обязательный компонент для обработки VoIP-трафика. Медиасервер предназначен для прокcирования речевой и видеоинформации по протоколу RTP, организации конференций, записи разговоров, воспроизведения медиафайлов и различных комбинаций этих режимов.

Для установки выполните:

sudo apt install ecss-media-server

Назначение, описание и настройка ecss-media-server приведены в разделе "Настройка программного медиасервера". В ходе установки нужно будет ответить на ряд вопросов для создания необходимых конфигурационных файлов.

Установка ecss-restfs

RestFS — компонент, обеспечивающий HTTP API для работы с файлами. Описание и методика настройки компонента приведены в разделе "Настройка RestFS". Для установки выполните:

sudo apt install ecss-restfs

В ходе установки нужно будет ответить на ряд вопросов для создания необходимых конфигурационных файлов. Также инсталлятор предложит установить и настроить пакет Text2speech от Yandex. Подробнее в разделе Настройка сервиса tts для работы с Yandex-Speechkit.

Установка ecss-media-resources

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

Для установки выполните:

sudo apt install ecss-media-resources

Установка ecss-web-conf

Web-конфигуратор позволяет сделать управление системой более наглядным и комфортным. Установка web-конфигуратора не является обязательной, но рекомендуется.

С помощью web-конфигуратора выполняется настройка, мониторинг и отладка системы с удаленного рабочего места через web-браузер.  Описание компонентов приложения приведено в разделе "Web-интерфейс". Описание вопросов, задаваемых при инсталляции пакета, приведено в Приложении Д.

Также при установке пакета ecss-web-conf автоматически устанавливается пакет ecss-subsriber-portal-ui. Приложение "Портал абонента" системы ECSS-10 позволяет абонентам системы самостоятельно управлять услугами, просматривать информацию по совершенным вызовам, активным конференциям, а также настраивать собственные IVR-скрипты для входящих вызовов. Описание работы веб-конфигуратора приведено в разделе "Портал абонента".

Для установки выполните:

sudo apt install ecss-web-conf

Если требуется отключить порт 80, сделайте это после установки пакета, убрав соответствующую секцию из файла /etc/nginx/sites-available/ecss-web-conf.

Инсталляция дополнительных необязательных пакетов

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

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

sudo apt install <имя пакета 1> <имя пакета 2> ... <имя пакета N>

Список доступных дополнительных пакетов:

Проверка доступности интерфейсов по dns-именам

Проверить работу dnsmasq можно простыми ping:

ping -c1 cocon.mysql.ecss
ping -c1 dialer.mysql.ecss
ping -c1 statistics.mysql.ecss
ping -c1 tc.mysql.ecss
ping -c1 tts.mysql.ecss
ping -c1 controlchannel.zmq.ecss
ping -c1 system.restfs.ecss

Все интерфейсы должны быть доступны.

Синхронизация времени на серверах

Перед настройкой NTP нужно убедиться, что в системе установлен пакет ntp.

Пример:

sasha@ecss1:~$ dpkg -l | grep ntp
ii  ntp                                   1:4.2.8p10+dfsg-5ubuntu7.3                      amd64        Network Time Protocol daemon and utility programs
ii  sntp                                  1:4.2.8p10+dfsg-5ubuntu7.3                      amd64        Network Time Protocol - sntp client

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

Пример для установки времени с сервера ntp.ubuntu.com:

sudo ntpdate ntp.ubuntu.com

Команда date без параметров выводит на экран текущее системное время.

Установка и настройка NTP

Конфигурация NTP настраивается при установке пакета ecss-node.

Рассмотрим настройку NTP для кластера из 2-х серверов ecss со следующими параметрами:

ПараметрЗначение
Адреса внешних NTP-серверов
  • ntp5.stratum1.ru
  • 10.136.16.100
Локальная синхронизация серверов кластера между собой (orphan mode)

Да, для следующих адресов:

  • ecss1 - 192.168.1.21
  • ecss2 - 192.168.1.22
Подсети, с которых разрешено другим устройствам синхронизироваться с данным сервером
  • 192.168.1.0/24
  • 10.16.0.0/16

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

Ниже приведен пример ответа на вопросы:

Необходимо ввести внешние сервера через пробел (по умолчанию ntp.ubuntu.com):

Необходимо разрешить (Yes) или запретить (No) активацию режима tos orphan (режим для кластера, в котором серверы самостоятельно регулируют синхронизацию). Если система устанавливается в кластере, то серверы ECSS должны иметь одинаковое время, даже если внешние NTP-серверы недоступны. Поэтому необходимо выбрать "Yes".

Точность времени кластера по Strаtum. По умолчанию — 7:

Предлагается ввести адреса соседних серверов кластера для их синхронизации между собой. В данном примере настраиваем ecss1, поэтому вводим адрес ecss2. При настройке ecss2 соответственно вводится адрес ecss1. Если серверов несколько, необходимо перечислить их через пробел.

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

Указываются сети, которые могут иметь доступ до данного сервера, чтобы другие ноды, а также прочие устройства  могли синхронизировать время с данным сервером. Формат указания сетей: <адрес_сети|маска_сети>. Если сетей несколько, необходимо перечислить их через пробел.

После инсталляции настройки сохраняются в файле /etc/ecss/ecss-ntp.conf. Пример получившегося файла для сервера ecss1

# /etc/ntp.conf

# http://www.k-max.name/linux/ntp-server-na-linux/
# В preinst делаем резервную копию старого и устанавливаем текущий
# В postrm загружаем из резервной копии

# Смещение системных часов
driftfile       /var/lib/ntp/ntp.drift
# Логи
logfile /var/log/ntp
# Статистика синхронизации времени
statsdir /var/log/ntpstats/

# Разрешает записывать статистику:
# loopstats - статистика для петли (loopback)
# peerstats - статистика пиров
# clockstats - статистика драйвера времени
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

# Активация Orphan mode — режима синхронизации времени для кластеров. Устанавливаем для него stratum (уровень точности: число от 1 до 16)
# tos orphan <stratum>
# TOS
tos orphan 7 ### INSTALLED AUTOMAT BY ECSS10


# Сервера локальной сети
# peer <ip|domain>
# LOCAL_SERVERS
peer 192.168.1.22 ### INSTALLED AUTOMAT BY ECSS10



# Интернет-сервера
# server xx.xx.xx.xx iburst
# restrict xx.xx.xx.xx
# INTERNET_SERVERS
server ntp5.stratum1.ru iburst ### INSTALLED AUTOMAT BY ECSS10
restrict ntp5.stratum1.ru ### INSTALLED AUTOMAT BY ECSS10
server 10.136.16.100 iburst ### INSTALLED AUTOMAT BY ECSS10
restrict 10.136.16.100 ### INSTALLED AUTOMAT BY ECSS10

# Ограничение доступа к конфигурируемому серверу:
# По умолчанию игнорируем все
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited
restrict source notrap nomodify noquery

# Localhost без параметров — значит разрешено все. Параметры идут только на запреты.
restrict 127.0.0.1
restrict ::1

Для ecss2 файл будет аналогичным, за исключением строки пира к соседнему серверу (192.168.1.21):

peer 192.168.1.21 ### INSTALLED AUTOMAT BY ECSS10

В режиме Orphan серверы в кластере синхронизируются друг от друга, сами определяют мастера и следят, чтобы в рамках кластера часы шли синхронно.
Если появляется мастер-сервер NTP со значением stratum меньше заданного для кластера, то кластер автоматически перенастраивается на синхронизацию от него. Таким образом выполняется условие постоянного наличия единственной точки синхронизации времени.

Все зависимые устройства в системе ECSS-10 должны синхронизироваться от серверов кластера. Если используется схема без резервирования, от настройки режима для кластера можно отказаться: тогда в конфигурационном файле будет отсутствовать секция настройки локальных серверов для синхронизации между собой.

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

Правильный способ — использовать команду dpkg-reconfigure:

sudo dpkg-reconfigure ecss-node

Если в файл конфигурации все же были вручную внесены какие-либо изменения, то для применения команды dpkg-reconfigure нужно перезапустить сервис NTP:

sudo systemctl restart ntp.service

Для просмотра информации о состоянии синхронизации используется команда  ntpq –p . Если использовать дополнительный ключ –n, вместо имени сервера будет указан IP-адрес:

Пример:

sasha@ecss1:~$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ecss2           88.147.254.229   2 s   11   64  377    0.099   -1.169   0.357
+10.136.16.100   194.58.204.148   2 u   56  128  377    4.008   -2.482   0.339
*88.147.254.229  .PPS.            1 u  124  128  377   60.440    0.691   0.098

Описание параметров:

  • remote — имя удаленного NTP-сервера;
  • refid — IP-адрес сервера, с которым производит синхронизацию удаленный сервер NTP;
  • st — stratum (уровень): число от 1 до 16, отражающее точность сервера;
  • t — тип удаленного сервера:
    • u — unicast,
    • l — local,
    • m — multicast,
    • s –  symmetric (peer),
    • b — broadcst;
  • when — интервал времени (в секундах), прошедший с момента получения последнего пакета от данного сервера;
  • poll — интервал между опросами (в секундах), значение варьируется;
  • reach — состояние доступности сервера. Восьмеричное представление массива из 8 бит, отражающего результаты последних восьми попыток соединения с сервером. Если последние 8 попыток синхронизации с удаленным сервером были успешны, то параметр принимает значение 377;
  • delay — вычисленная задержка ответов от сервера (RTT) в миллисекундах;
  • offset — разница между временем локального и удаленного серверов;
  • jitter — джиттер, мера статистических отклонений от значения смещения (поле offset) по нескольким успешным параметрам запрос-ответ.

Значение символов перед именами серверов

x — фальшивый источник по алгоритму пересечения;
. — исключён из списка кандидатов из-за большого расстояния;
- — удален из списка кандидатов алгоритмом кластеризации;
+ — входит в конечный список кандидатов;
# — выбран для синхронизации, но есть 6 лучших кандидатов;
* — выбран для синхронизации;
o — выбран для синхронизации, но используется PPS;
пробел — слишком большой уровень, цикл или явная ошибка;

После старта сервиса может потребоваться около 10 минут для установления синхронизации времени с базовым NTP-сервером.

Проверить состояние настроенного сервера NTP можно с помощью команды ntpdate:

sasha@ecss1:~$ sudo ntpdate -q localhost
server 127.0.0.1, stratum 2, offset -0.000032, delay 0.02573
28 Sep 15:00:57 ntpdate[19002]: adjust time server 127.0.0.1 offset -0.000032 sec

Как видно, значение stratum сервера стало равно 2.

Настройка Token

Token (токен) — это USB-ключ лицензионной защиты. Его наличие необходимо для корректной работы системы лицензирования и SSW в целом. Раньше при покупке лицензии серверы ECSS поставлялись с ключами eToken, в последнее время новые инсталляции комплектуются USB-ключами Рутокен.

Установка ПО и подключение Token

Все необходимые для работы RuToken библиотеки устанавливаются из репозитория ELTEX вместе с пакетом ecss-node.

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

sudo apt install safenetauthenticationclient-core 

Вставьте токен в USB-разъем на сервере.

Для проверки подключения USB-ключа к серверу выполните команду:

lsusb

Если ключ обнаружен, будет выведена строка:

  • для eToken:

    Bus 003 Device 002: ID 0529:0620 Aladdin Knowledge Systems
  • для Рутокен:

    Bus 005 Device 002: ID 0a89:0030


    Если ключ не определяется, то выполните следующие команды в указанной последовательности ( *для Рутокен перезапуск сервиса SACSrv не требуется, т.к. данный сервис — только для eToken):

    sudo service SACSrv stop
    sudo service pcscd stop
    sudo service pcscd start
    sudo service SACSrv start
    sudo ldconfig

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

Проверка работы Token

Для проверки работы токена можно использовать приложение pkcs11-tool. Возможно проверить следующее:

Вывести общую информацию для ключа:

  • для eToken

    pkcs11-tool --module /usr/lib/libeToken.so -I
    
    Cryptoki version 2.1
    Manufacturer     SafeNet, Inc.
    Library          eToken PKCS#11 (ver 8.1)
    Using slot 0 with a present token (0x0)
  • для Рутокен:

    pkcs11-tool --module /usr/lib/ecss/ecss-ds/lib/lpm_storage-<VERSION>/priv/x64/librtpkcs11ecp.so -I
    
    Cryptoki version 2.20
    Manufacturer     Aktiv Co.
    Library          Rutoken ECP PKCS #11 library (ver 1.5)
    Using slot 0 with a present token (0x0)

Отобразить доступные слоты с ключами:

  • для eToken

    pkcs11-tool --module /usr/lib/libeToken.so -L
    
    Available slots:
    Slot 0 (0x0): Aladdin eToken PRO USB 72K Java [Main Interface] 00 00
      token label:   ECSS 000001
      token manuf:   SafeNet Inc.
      token model:   eToken
      token flags:   rng, login required, PIN initialized, token initialized, other flags=0x200
      serial num  :  123456789
    Slot 1 (0x1): 
      (empty)
    Slot 2 (0x2): 
      (empty)
    Slot 3 (0x3): 
      (empty)
    Slot 4 (0x4): 
      (empty)
    Slot 5 (0x5): 
      (empty)
  • для Рутокен:

    pkcs11-tool --module /usr/lib/ecss/ecss-ds/lib/lpm_storage-<VERSION>/priv/x64/librtpkcs11ecp.so -L
    Available slots:
    Slot 0 (0x0): Aktiv Rutoken ECP 00 00
      token label        : ECSS 000001
      token manufacturer : Aktiv Co.
      token model        : Rutoken ECP
      token flags        : rng, login required, PIN initialized, token initialized
      hardware version   : 54.1
      firmware version   : 18.0
      serial num         : 123456789
    Slot 1 (0x1): 
      (empty)
    Slot 2 (0x2): 
      (empty)
    Slot 3 (0x3): 
      (empty)
    Slot 4 (0x4): 
      (empty)
    Slot 5 (0x5): 
      (empty)
    Slot 6 (0x6): 
      (empty)
    Slot 7 (0x7): 
      (empty)
    Slot 8 (0x8): 
      (empty)
    Slot 9 (0x9): 
      (empty)
    Slot 10 (0xa): 
      (empty)
    Slot 11 (0xb): 
      (empty)
    Slot 12 (0xc): 
      (empty)
    Slot 13 (0xd): 
      (empty)
    Slot 14 (0xe): 
      (empty)

Расположение модуля для Рутокен может отличаться в зависимости от версии подсистемы DS. В общем случае файл располагается в /usr/lib/ecss/ecss-ds/lib/lpm_storage-<ВЕРСИЯ ПОДСИСТЕМЫ>/priv/x64/librtpkcs11ecp.so

Для проверки можно использовать общую команду pkcs11-tool --module $(find /usr/lib/ecss/ecss-ds/lib/ -name librtpkcs11ecp.so | head -n1) -L


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

Перезагрузка Token по SSH в случае его зависания

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

  1. Установить утилиту usb-reset:

    sudo snap install usb-reset
    sudo snap connect usb-reset:hardware-observe core:hardware-observe
    sudo snap connect usb-reset:raw-usb core:raw-usb
    Slot 0 (0x0): Aktiv Rutoke
  2. Проверить, что USB-токен действительно завис. Пример:

    pkcs11-tool --module /usr/lib/ecss/ecss-ds/lib/lpm_storage-3.14.8.70203.423017/priv/x64/librtpkcs11ecp.so -L

    Вывод должен либо вообще ничего не показать, либо показать все слоты пустыми.

  3. Узнать idVendor, idProduct USB-токена. Для Рутокен команда будет выглядеть следующим образом:

    sudo lsusb -v  | grep -C 10 "Rutoken ECP" 

    В указанном выводе найти параметры idVendor, idProduct:

    lsusb -v  | grep -C 10 "Rutoken ECP" 
    FIXME: alloc bigger buffer for device capability descriptors
      bDescriptorType         1
      bcdUSB               2.00
      bDeviceClass            0 (Defined at Interface level)
      bDeviceSubClass         0 
      bDeviceProtocol         0 
      bMaxPacketSize0        16
      idVendor           0x0a89 
      idProduct          0x0030 
      bcdDevice            1.00
      iManufacturer           1 Aktiv
      iProduct                2 Rutoken ECP
      iSerial                 0 
      bNumConfigurations      1
      Configuration Descriptor:
        bLength                 9
        bDescriptorType         2
        wTotalLength           93
        bNumInterfaces          1
        bConfigurationValue     1
        iConfiguration          0 
        bmAttributes         0x80
  4. Перезапустить USB-устройство:

    sudo usb-reset <idVendor>:<idProduct>
    Пример:
    sudo usb-reset 0a89:0030
  5. Проверить, что слот(ы) появились:

    pkcs11-tool --module /usr/lib/ecss/ecss-ds/lib/lpm_storage-<VERSION>/priv/x64/librtpkcs11ecp.so -L
    
    Available slots:
    Slot 0 (0x0): Aktiv Rutoken ECP 00 00
    ...

Проблема с работой Token на серверах DEPO

Если периодически фиксируется отключение токенов от серверов DEPO, то следует в syslog проверить наличие ошибок драйвера EHCI. Если ошибки присутствуют, то необходимо зайти в BIOS сервера и включить режим XHCI (путь в BIOS: Advanced/USB Configuration: XHCI Pre-Boot Driver — Enabled, XHCI — enabled).

Настройка listen-интерфейса для сервиса epmd

Пример настройки listen-интерфейса для сервиса epmd в соответствии с конфигурацией сети, приведённой в разделе "Подготовка сервера для инсталляции ECSS-10".

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

Выполните команду:

sudo systemctl edit epmd.service

Откроется окно текстового редактора. Добавить в файл следующую секцию (в соответствии с сетевым интерфейсом, на котором работает epmd: например для ecss1 — 192.168.1.1):

[Service]
Environment="ERL_EPMD_ADDRESS=127.0.1.1,192.168.1.1"

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

sudo systemctl daemon-reload

Далее требуется перезапустить сервисы:

sudo systemctl restart epmd.service

Для есss2 выполняется такая же последовательность действий, только вместо 192.168.1.1 указывается 192.168.1.2.

В качестве ERL_EPMD_ADDRESS нельзя использовать адреса, которые были сконфигурированы в keepalived.conf.

Запуск и активация системы

ВАЖНО

Перед началом работы проверьте наличие Token в системе.

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

Запустить подсистемы mycelium и ds:

sudo systemctl start ecss-mycelium.service 
sudo systemctl start ecss-ds.service

Проверить, что сервисы стартовали. Пример для mycelium:

sasha@ecss1:~$ sudo systemctl status ecss-mycelium.service
[sudo] password for sasha: 
● ecss-mycelium.service - daemon ecss-mycelium-14.10.44 of ecss-10
   Loaded: loaded (/lib/systemd/system/ecss-mycelium.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2021-10-12 12:11:48 +07; 21h ago
 Main PID: 22921 (beam.smp)
    Tasks: 29 (limit: 4915)
   CGroup: /ecss.slice/ecss-mycelium.service
           ├─22921 ecss-mycelium -pc unicode -e 65536 -- -root /usr/lib/ecss/ecss-mycelium -progname erl -- -home /var/lib/ecss/home -- -noshell -noinput -mode embedded -config /tmp/mycelium1.config -boot_v
           ├─23023 erl_child_setup 1024
           ├─23052 inet_gethost 4
           ├─23053 inet_gethost 4
           ├─23054 sh -s disksup
           └─23055 /usr/lib/erlang/lib/os_mon-2.4.7/priv/bin/memsup

Oct 12 12:12:27 ecss1 ecss-mycelium[22921]: 12:12:27 I <0.1613.0> rps_tring:50 Alarm clear: node appear - "md1" - md1@ecss1
Oct 12 12:12:27 ecss1 ecss-mycelium[22921]: 12:12:27 I <0.1615.0> tring_client_em:50 Tring ecss10: "md1" - appear ([{role,mediator},{generation,<<"066203cba3d72206">>}])
Oct 12 12:12:27 ecss1 ecss-mycelium[22921]: 12:12:27 I <0.1615.0> tring_client_em:50 Tring ecss10: "md1"/md1@ecss1 - appear ([{tring_token_nodes,[{"ds1",ds1@ecss1},{"mycelium-testnew",mycelium1@ecss1}]},{ro
Oct 12 12:12:32 ecss1 ecss-mycelium[22921]: 12:12:32 I <0.1615.0> tring_client_em:50 Tring ecss10: "sip1" - appear ([{role,adapter},{generation,<<"066203cbf848a618">>}])
Oct 12 12:12:32 ecss1 ecss-mycelium[22921]: 12:12:32 I <0.1615.0> tring_client_em:50 Tring ecss10: "sip1"/sip1@ecss1 - appear ([{tring_token_nodes,[{"ds1",ds1@ecss1},{"md1",md1@ecss1},{"mycelium-testnew",my
Oct 12 12:12:35 ecss1 ecss-mycelium[22921]: 12:12:35 I <0.1613.0> rps_tring:50 Alarm clear: group appear - "core1"
Oct 12 12:12:35 ecss1 ecss-mycelium[22921]: 12:12:35 I <0.1615.0> tring_client_em:50 Tring ecss10: "core1" - appear ([{role,core},{generation,<<"066203cc23ebbd1d">>}])
Oct 12 12:12:35 ecss1 ecss-mycelium[22921]: 12:12:35 I <0.1615.0> tring_client_em:50 Tring ecss10: "core1"/core1@ecss1 - appear ([{tring_token_nodes,[{"mycelium-testnew",mycelium1@ecss1},{"md1",md1@ecss1},{
Oct 13 09:09:56 ecss1 ecss-mycelium[22921]: 09:09:56 I <0.6428.0> mysql_au:50 Cleaned 0 audit sessions
Oct 13 09:09:56 ecss1 ecss-mycelium[22921]: 09:09:56 I <0.6428.0> mysql_au:50 Cleaned 28 audit commands

Пример для ds:

sasha@ecss1:~$ sudo systemctl status ecss-ds.service
● ecss-ds.service - daemon ecss-ds-14.10.44 of ecss-10
   Loaded: loaded (/lib/systemd/system/ecss-ds.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2021-10-12 12:11:59 +07; 21h ago
 Main PID: 23111 (beam.smp)
    Tasks: 38 (limit: 4915)
   CGroup: /ecss.slice/ecss-ds.service
           ├─23111 ecss-ds -pc unicode -K true -A 8 -t 2097152 -e 100000 -- -root /usr/lib/ecss/ecss-ds -progname erl -- -home /var/lib/ecss/home -- -noshell -noinput -mode embedded -config /tmp/ds1.config 
           ├─23222 erl_child_setup 1024
           ├─23293 inet_gethost 4
           ├─23294 inet_gethost 4
           ├─23309 inet_gethost 4
           ├─23310 inet_gethost 4
           ├─23311 sh -s disksup
           └─23312 /usr/lib/erlang/lib/os_mon-2.4.7/priv/bin/memsup

Oct 12 12:11:59 ecss1 systemd[1]: Started daemon ecss-ds-14.10.44 of ecss-10.
Oct 12 12:11:59 ecss1 ecss-ds[23111]: release: ds1 3.14.10.44
Oct 12 12:11:59 ecss1 ecss-ds[23111]: ****
Oct 12 12:11:59 ecss1 ecss-ds[23111]: exec /usr/lib/erlang/erts-10.3.5.10/bin/erlexec     -noinput     -mode embedded     -config /tmp/ds1.config     -env ERL_CRASH_DUMP /var/log/ecss/ds/crashdumps/erl_cras
Oct 12 12:12:00 ecss1 ecss-ds[23111]: Starting Chronica...
Oct 12 12:12:00 ecss1 ecss-ds[23111]: Starting error_logger...
Oct 12 12:12:01 ecss1 ecss-ds[23111]: ok
Oct 12 12:12:01 ecss1 ecss-ds[23111]: starting OASYS {check boot env.}                                      ...done
Oct 12 12:12:01 ecss1 ecss-ds[23111]: starting OASYS {data control engine}                                  ...done
Oct 12 12:12:20 ecss1 systemd[1]: ecss-ds.service: Current command vanished from the unit file, execution of the command list won't be resumed.

Подключиться к распределенной консоли управления CoCon:

ssh admin@localhost -p8023

Пароль по умолчанию для подключения к консоли управления CoCoN — password.

Далее установить паспорт и лицензию. Процесс установки лицензионных ограничений включает в себя занесение в базу данных ECSS-10 кодовой последовательности лицензии и паспорта USB-ключа Token.

Важно

Сначала устанавливается паспорт, затем лицензия.

Введите данные паспорта и лицензии (описание и примеры команд приведены в справочнике):

/cluster/storage/<CLUSTER>/licence/set-passport <PASSPORT>

/cluster/storage/<CLUSTER>/licence/add [--force|--no-diff] <LICENCE>

где:

  • <CLUSTER> — имя кластера хранения долговременных данных (ds);
По умолчанию в системе присутствует кластер хранения долговременных данных с именем ds1.
  • <PASSPORT> — последовательность цифр, букв и других символов в файле паспорта (ECSS xxxxxx.pas);
  • <LICENCE> — последовательность цифр, букв и других символов в файле лицензии (ECSS xxxxxx yyyy-mm-dd.lic);
  • [--force] — пропустить утверждение команды;
  • [--no-diff] — не выводить таблицу сравнения текущих и предлагаемых условий лицензии.

Если данные лицензии и паспорта будут введены корректно, то система выдаст подтверждение: ОК.

Сразу можно проверить, что применились правильные лицензионные ограничения:

/cluster/storage/<CLUSTER>/licence/current-limits

Далее необходимо отключиться от консоли CoCon, выполнив команду:

exit

Запустите остальные ноды:

sudo systemctl start ecss-mycelium.service
sudo systemctl start ecss-ds.service
sudo systemctl start ecss-core.service
sudo systemctl start ecss-pa-sip.service
sudo systemctl start ecss-mediator.service
sudo systemctl start ecss-restfs.service
sudo systemctl start ecss-web-conf.service
sudo systemctl start ecss-media-server.service
sudo systemctl start ecss-cc-ui.service
sudo systemctl start ecss-teleconference-ui
CODE

Также запустите ecss-pa-megaco (в случае, если он используется):

sudo systemctl start ecss-pa-megaco.service

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

sudo systemctl status <SERVICE>

где <SERVICE> — имя сервиса. В статусе должно отображаться состояние active.

На данном этапе система считается полностью установленной и готовой к настройке.

Особенности установки системы в кластере

Установка ECSS-10 в кластере

Подготовка хостов

При установке системы ECSS-10 в кластере необходимо на обоих серверах в соответствии с проектом выполнить:

Установка имени кластера

Для работы системы нужно на обоих серверах указать одинаковое имя кластера. Для этого откройте файл mycelium1.config в текстовом редакторе:

sudo nano /etc/ecss/ecss-mycelium/mycelium1.config

Если в поле "cluster_name" указано "undefined", то необходимо задать произвольное имя для данного параметра, например:

{cluster_name, my_cluster}

Далее следует проверить в файле /etc/dnsmasq.d/ecss-broker, что адреса primary и secondary broker соответствуют указанным при инсталляции пакета ecss-node.

Пример содержания файла на ecss1 и ecss2 (содержимое файлов должно быть одинаковым на обоих серверах):

address=/primary.broker.ecss/192.168.1.1
address=/secondary.broker.ecss/192.168.1.2


В качестве primary.broker.ecss и secondary.broker.ecss нельзя использовать адреса, которые были сконфигурированы в keepalived.conf.

Настройка RestFS для кластера

Для работы в кластере необходимо настроить работу RestFS на базе GlusterFS-сервера.

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

В качестве примера приведена система ECSS-10, работающая в кластере, со следующими настройками:

  • IP-адрес ecss1 — 192.168.118.222;

  • IP-адрес ecss2 — 192.168.118.224.

  1. Установите gluster-сервер и пакет attr на оба хоста:

    sudo aptitude install glusterfs-server attr
  2. Для добавления сервера в пул файловых хранилищ выполните команду на ecss1:

    sudo gluster peer probe 192.168.118.224

    После этого на ecss2 при выполнении команды  sudo gluster peer status должна появиться информация о ecss1:

    Number of Peers: 1 Hostname: 192.168.118.222 Uuid: 569c4730-a3a7-4d29-a132-b1bcdad792d8 State: Peer in Cluster (Connected)
  3. Для создания кластера на ecss1 выполните команду:

    sudo gluster volume create ecss_volume replica 2 transport tcp 192.168.118.222:/var/lib/ecss/glusterfs 192.168.118.224:/var/lib/ecss/glusterfs force
  4. Запустите созданный кластер, для этого на ecss1 выполните команду:

    sudo gluster volume start ecss_volume
  5. Для проверки статуса кластера на ecss1 выполните команду:

    sudo gluster volume info

    Необходимо обратить внимание на поля "Status" и "Bricks" — они должны иметь следующий вид:

    Volume Name: ecss_volume 
    Type: Replicate 
    Volume ID: 60774e49-d2f1-4b06-bb4a-3f39ccf1ea73 
    Status: Started Number of Bricks: 1 x 2 = 2 
    Transport-type: tcp 
    Bricks: 
    Brick1: 192.168.118.222:/restfs 
    Brick2: 192.168.118.224:/restfs
  6. Чтобы смонтировать glusterfs раздел, выполните на обоих хостах ecss1 и ecss2 следующие действия:

    • Создайте новый systemd unit:

      /etc/systemd/system/ecss-glusterfs-mount.service

      и добавьте туда следующие параметры:

      [Unit] 
      Description=mount glusterfs 
      After=network.target 
      Requires=network.target 
      
      [Service] 
      RemainAfterExit=no 
      Type=forking 
      RestartSec=10s 
      Restart=always 
      ExecStart=/sbin/mount.glusterfs localhost:/ecss_volume /var/lib/ecss/restfs -o fetch-attempts=10 
      ExecStop=/bin/umount /var/lib/ecss/restfs 
      
      [Install] 
      WantedBy=multi-user.target
    • Добавить unit в автозагрузку.

      Unit добавить в автозагрузку следующей командой:

      sudo systemctl enable ecss-glusterfs-mount.service
    • Перезагрузить хост:

      sudo reboot

      Если хост не может быть перезагружен, то можно выполнить следующие команды:

      sudo systemctl daemon-reload
      sudo systemctl restart ecss-glusterfs-mount.service

      После монтирования на обоих хостах выполните команду:

      df -h

      При просмотре информации должен появиться подмонтированный раздел:

      /dev/sda10                     19G  6,5G   11G  38% /var/lib/mysql
      /dev/sda8                     4,5G  213M  4,1G   5% /var/log
      /dev/sda5                      37G   48M   35G   1% /var/lib/ecss/ecss-media-server/records
      /dev/sda6                      19G   44M   18G   1% /var/lib/ecss/cdr
      /dev/sda7                      19G   44M   18G   1% /var/lib/ecss/statistics
      /dev/sda9                      19G  7,6G  9,7G  44% /var/log/ecss
      localhost:/ecss_volume   	 46G   59M   44G   1% /var/lib/ecss/restfs*

Запуск RestFS в режиме кластера

Для запуска RestFS в режиме кластера достаточно, чтобы пакет ecss-restfs был установлен и запущен сразу на двух нодах. Команда для запуска сервиса ecss-restfs: 

sudo systemctl start ecss-restfs.service

Запуск RestFS в случае недоступности других участников кластера

В применяемой концепции glusterfs все сервера равнозначны. Однако раздел volume не активируется при отсутствии кворума (кластер имеет кворум при наличии и активности достаточного количества голосующих элементов кластера с одинаковым согласованным представлением кластера). Это защитный механизм, который характерен для всех распределенных отказоустойчивых систем и призван защитить систему от split-brain — ситуация, когда каждая система считает, что другая нода вышла из строя.
Такая ситуация может возникнуть когда загружается только один из серверов, а второй при этом выключен или недоступен. На первом сервере volume не будет автоматически активирован до появления второго сервера для исключения расхождения данных.

Если включение второго сервера невозможно либо затягивается на длительное время, то можно вручную перевести volume в рабочий режим, выполнив команду:

sudo gluster volume ecss_volume start force

Проблемы связанные с возникновением split-brain

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

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

Включение данного параметра производится командой:

sudo gluster volume set ecss_volume cluster.favorite-child-policy size

Правка настроек glusterfs-server.service unit

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

sudo systemctl edit glusterfs-server.service

Должно открыться окно текстового редактора. Внесите туда следующие параметры:

[Service] 
KillMode=control-group 
RemainAfterExit=no

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

sudo systemctl daemon-reload

Инсталляция и настройка snmpd

Установите Net-SNMP агент:

sudo aptitude install snmpd

Стандартный порт, который использует snmpd — udp/161. Встроенный агент ECSS использует по умолчанию порт udp/1610, поэтому конфликтовать с snmpd они не будут.

Убедитесь, что сервис snmpd успешно запустился на порту 161, а ECSS — на порту 1610:

sudo netstat -tulpan | grep 161
udp        0      0 127.0.0.1:161           0.0.0.0:*                            7723/snmpd      
udp        0      0 0.0.0.0:1610             0.0.0.0:*                           8245/ecss-mediator

Если нужно изменить стандартный порт snmpd, отредактируйте файл конфигурации /etc/snmp/snmpd.conf. Например:

agentAddress udp:127.0.0.1:3161

Сохраните внесенные изменения.

Далее перезапустите сервис snmpd:

sudo systemctl restart snmpd.service

Убедитесь, что сервис snmpd успешно запустился на новом порту:

sudo netstat -tulpan | grep snmpd
udp        0      0 127.0.0.1:3161          0.0.0.0:*                           7723/snmpd      

Настройка VRRP

Настройка демона keepalived для управления виртуальными адресами

Одним из способов повысить отказоустойчивость ECSS-10 является использование виртуальных IP-адресов. Виртуальный IP-адрес не принадлежит постоянно конкретной ноде кластера ECSS-10, а автоматически поднимается на той ноде, которая в данный момент времени способна обслуживать запросы. Таким образом, получаем:

  • Независимость конфигурации от IP-адресов конкретных нод кластера. Нет необходимости перечислять на встречном оборудовании все возможные адреса нод ECSS-10 — достаточно указать один виртуальный IP-адрес, и запрос будет обслужен любой нодой кластера. которая в текущий момент способна его обработать.
  • Возможность работать с оборудованием, которое не поддерживает указания нескольких адресов для взаимодействия. Для такого оборудования весь кластер ECSS-10 будет представлен одним виртуальным IP-адресом.
  • Повышение отказоустойчивости. В случае отказа одной из нод кластера другая нода получит виртуальный IP-адрес и будет предоставлять сервис взамен отказавшей.

Для управления виртуальными адресами используется демон keepalived, который реализует функции:

  • Мониторинга доступности нод ECSS-10.
  • Выбор активной (master) ноды по протоколу VRRP (Virtual Router Redundancy Protocol, RFC3768/RFC5798) на основе доступности нод.
  • Перенос виртуального IP-адреса на активную ноду.

Общая настройка keepalived

Для работы рекомендуется использовать протокол VRRP версии 3, так как он обеспечивает меньшую задержку перед переносом адреса в случае потери текущей активной ноды. При использовании на сети протокола IPNET протокол VRRP версии 3 следует использовать обязательно. Для обеспечения оперативного переключения между рабочими нодами следует использовать именно протокол VRRP версии 3, так как он позволяет осуществлять рассылку сообщений VRRP advertisements с интервалом в 1/100 секунды (сантисекунда), в отличие от протокола VRRP версии 2, который оперирует секундными интервалами. Тем не менее, VRRP версии 2 также работоспособен в 3.14 версии ECSS-10. Версию 3 протокола VRRP в конфигурационном файле нужно задавать явно, по умолчанию используется версия 2:

man keepalived

# Set the default VRRP version to use
vrrp_version <2 or 3>        # default version 2

Также рекомендуется сконфигурировать запуск скриптов проверки от пользователя nobody (системный пользователь без прав) и включить безопасный запуск скриптов, которые запускаются от пользователя root.

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

Примечание. Можно встретить множество примеров, в которых при настройке VRRP используется опция authentication. Однако в документации keepalived упоминается о том, что authentication была удалена из VRRPv2 в спецификации RFC3768 (см. https://tools.ietf.org/html/rfc3768) в 2004 году, так как не обеспечивала безопасности и могла приводить к появлению двух "мастеров". Рекомендуется избегать использования этой опции (в VRRP_v3 отключена).

Основная конфигурация демона хранится в файле /etc/keepalived/keepalived.conf.

Основная конфигурация (одинаковая для всех нод кластера):

global_defs {
    vrrp_version 3          # версия протокола VRRP (2 или 3)
    script_user nobody      # ограниченный в правах системный пользователь, от которого будут запускаться скрипты проверки доступности
    enable_script_security  # не запускать скрипты от root, если часть пути к ним доступна на запись для обычных пользователей
}

include /etc/keepalived/sip.conf
include /etc/keepalived/mysql.conf
include /etc/keepalived/ipnet.conf
CODE

Настройка виртуального адреса для SIP-адаптера

В приведённой схеме используются два виртуальных адреса для SIP-адаптеров. Это позволяет распределить нагрузку между нодами, конфигурируя встречные устройства таким образом, чтобы часть из них работала с одним виртуальным адресом, а часть с другим. При условии неполной загрузки нод сохраняется отказоустойчивость, то есть, в случае отказа одной из нод виртуальный адрес будет подхвачен другой нодой.

Конфигурация строится таким образом, чтобы первая нода была мастером для первого виртуального адреса SIP-адаптера. Вторая нода будет резервировать этот адрес. Конфигурация для основного адреса SIP-адаптера второй ноды настраивается зеркально: вторая нода — мастер, первая нода — резерв. Конфигурацию виртуальных адресов для SIP-адаптера рекомендуется поместить в отдельный файл — /etc/keepalived/pa-sip.conf.

Изменён скрипт проверки доступности контрольного SIP-порта. Теперь скрипт из keepalive нужно вызывать следующим образом: /usr/bin/ecss_pa_sip_port 65535, где <65535> — значение по умолчанию порта, который адаптер открывает, когда он готов принимать нагрузку. Для того чтобы изменить порт, необходимо в конфигурационном файле SIP-адаптера /etc/ecss/ecss_pa_sip/sip1.config в секции ip_ssw_intercom изменить в параметрe keepalive значение порта, после чего перезапустить адаптер.

Конфигурация первой ноды:

vrrp_script check_sip {
    script "/usr/bin/ecss_pa_sip_port 65535"
    interval 2
    timeout 2
}

# Конфигурация адреса для первого виртуального адреса SIP-адаптера
vrrp_instance SIP1 {
    state MASTER                  # Исходное состояние при старте
    interface <network_interface> # Имя сетевого интерфейса, на котором будет работать протокол VRRP
    virtual_router_id <ID>        # Уникальный идентификатор роутера (0..255)
    priority 100                  # Приоритет (0..255) чем выше — тем больше
    advert_int 1                  # Интервал рассылки уведомлений (с)
    preempt_delay 60              # Интервал ожидания мастера при старте демона (с) при исходном состоянии BACKUP

    unicast_src_ip <src_real IP>  # Собственный реальный IP-адрес
    unicast_peer {
        <real_remote IP>          # Реальный IP-адрес соседа
    }

    virtual_ipaddress {
        # Виртуальный IP-адрес и маска
        # dev — сетевой интерфейс, на котором будет поднят виртуальный адрес
        # label — метка виртуального интерфейса (для удобства идентификации)
        <virtual_sip_IP>/<netmask> dev <>  label <label>
    }

    track_script {
        check_sip
    }
}

# Конфигурация для второго виртуального адреса SIP-адаптера

vrrp_instance SIP2 {
    state BACKUP                      # Исходное состояние при старте
    interface <network_interface>     # Имя сетевого интерфейса, на котором будет работать протокол VRRP
    virtual_router_id <ID>            # Уникальный идентификатор роутера (0..255)
    priority 50 					  # Приоритет (0..255) чем выше — тем больше
    advert_int 1                      # Интервал рассылки уведомлений (с)
    preempt_delay 60                  # Интервал ожидания мастера при старте демона (с) при исходном состоянии BACKUP

    unicast_src_ip  <src_real IP>     # Собственный реальный IP-адрес
    unicast_peer {
         <real_remote IP>             # Реальный IP-адрес соседа
    }

    virtual_ipaddress {
        # Виртуальный IP-адрес и маска
        # dev — сетевой интерфейс, на котором будет поднят виртуальный адрес
        # label — метка виртуального интерфейса (для удобства идентификации)
        <virtual_sip_IP>/<netmask> dev <>  label <label>
    }

    track_script {
        check_sip
    }
}

Конфигурация второй ноды:

vrrp_script check_sip {
    script "/usr/bin/ecss_pa_sip_port 65535"
    interval 2
    timeout 2
}

# Конфигурация для первого виртуального адреса SIP-адаптера
vrrp_instance SIP1 {
    state BACKUP                  # Исходное состояние при старте
    interface <network_interface> # Имя сетевого интерфейса, на котором будет работать протокол VRRP
    virtual_router_id <ID>        # Уникальный идентификатор роутера (0..255)
    priority 50                   # Приоритет (0..255) чем выше — тем больше
    advert_int 1                  # Интервал рассылки уведомлений (с)
    preempt_delay 60              # Интервал ожидания мастера при старте демона (с) при исходном состоянии BACKUP

    unicast_src_ip <src_real IP>  # Собственный реальный IP-адрес
    unicast_peer {
        <real_remote IP>          # Реальный IP-адрес соседа
    }

    virtual_ipaddress {
        # Виртуальный IP-адрес и маска
        # dev — сетевой интерфейс, на котором будет поднят виртуальный адрес
        # label — метка виртуального интерфейса (для удобства идентификации)
        <virtual_sip_IP>/<netmask> dev <>  label <label>
    }

track_script {
        check_sip
    }
}

# Конфигурация для второго виртуального адреса SIP-адаптера

vrrp_instance SIP2 {
    state MASTER                      # Исходное состояние при старте
    interface <network_interface>     # Имя сетевого интерфейса, на котором будет работать протокол VRRP
    virtual_router_id <ID>            # Уникальный идентификатор роутера (0..255)
    priority 100 					  # Приоритет (0..255) чем выше — тем больше
    advert_int 1                      # Интервал рассылки уведомлений (с)
    preempt_delay 60                  # Интервал ожидания мастера при старте демона (с) при исходном состоянии BACKUP

    unicast_src_ip  <src_real IP>     # Собственный реальный IP-адрес
    unicast_peer {
         <real_remote IP>             # Реальный IP-адрес соседа
    }

    virtual_ipaddress {
        # Виртуальный IP-адрес и маска
        # dev — сетевой интерфейс, на котором будет поднят виртуальный адрес
        # label — метка виртуального интерфейса (для удобства идентификации)
        <virtual_sip_IP>/<netmask> dev <>  label <label>
    }

    track_script {
        check_sip
    }
}

Настройка виртуального адреса для MySQL

Для отказоустойчивости в кластере ECSS-10 используется режим репликации MySQL мастер-мастер. Это позволяет корректно переносить данные в любом направлении. Однако одновременная запись на оба сервера MySQL с одновременной репликацией во встречном направлении повышает вероятность коллизий, что снижает отказоустойчивость. Поэтому рекомендуется настроить выделенный виртуальный адрес для кластера MySQL, чтобы запись данных в один момент времени производилась на одну ноду.

Если создавать файлы /etc/keepalived/mysql.conf вручную, то при запуске скрипта создания репликации нужно отказаться от автоматической настройки при вопросе "Нужна ли настройка keepalive? ("DO YOU WANT TO SET REST OF keepalive CONFIG").

Конфигурацию виртуальных адресов для MySQL рекомендуется поместить в отдельный файл /etc/keepalived/mysql.conf.

# Конфигурация mysql первой ноды:

vrrp_script check_mysql {
    script "/usr/bin/mysql --defaults-file=/etc/mysql/debian.cnf -e 'SELECT 1;'"
    user root
    interval 2
    fall 1
    timeout 2
}

vrrp_instance MySQL {
    state MASTER                     # Исходное состояние при старте
    interface <network_interface>    # Имя сетевого интерфейса, на котором будет работать протокол VRRP
    virtual_router_id <ID>           # Уникальный идентификатор роутера (0..255)
    priority 100                     # Приоритет (0..255) чем выше — тем больше
    advert_int 1                     # Интервал рассылки уведомлений (c)
    preempt_delay 60                 # Интервал ожидания мастера при старте демона (с) при исходном состоянии BACKUP

    unicast_src_ip  <src_real IP>    # Собственный реальный IP-адрес
    unicast_peer {
         <real_remote IP>            # Реальный IP-адрес соседа
    }

    virtual_ipaddress {
        # Виртуальный IP-адрес и маска
        # dev — сетевой интерфейс, на котором будет поднят виртуальный адрес
        # label — метка виртуального интерфейса (для удобства идентификации)
        <virtual_sip_IP>/<netmask> dev <>  label <label>
   }

    track_script {
        check_mysql
    }
}
# Конфигурация mysql второй ноды:

vrrp_script check_mysql {
    script "/usr/bin/mysql --defaults-file=/etc/mysql/debian.cnf -e 'SELECT 1;'"
    user root
    interval 2
    fall 1
    timeout 2
}

vrrp_instance MySQL {
    state BACKUP
    interface <network_interface>    # Имя сетевого интерфейса, на котором будет работать протокол VRRP
    virtual_router_id <ID>           # Уникальный идентификатор роутера (0..255)
    priority 50                      # Приоритет (0..255) чем выше — тем больше
    advert_int 1                     # Интервал рассылки уведомлений (с)
    preempt_delay 60                 # Интервал ожидания мастера при старте демона (с) при исходном состоянии BACKUP

    unicast_src_ip  <src_real IP>    # Собственный реальный IP-адрес
    unicast_peer {
         <real_remote IP>            # Реальный IP-адрес соседа
    }

    virtual_ipaddress {
        # Виртуальный IP-адрес и маска
        # dev — сетевой интерфейс, на котором будет поднят виртуальный адрес
        # label — метка виртуального интерфейса (для удобства идентификации)
        <virtual_sip_IP>/<netmask> dev <>  label <label>
   }

    track_script {
        check_mysql
    }
}

Настройка репликации БД MySQL приведена в разделе "Схема развертывания MySQL master-master replication с использованием keepalive".

Пример создания типовой конфигурации приведен в разделе "Примеры пошаговой первоначальной настройки ECSS-10".

Настройка виртуального адреса для IPNET

Поскольку через IPNET не поддерживается работа с несколькими адресами встречной стороны, при работе ECSS-10 в кластере требуется выделить виртуальный IP-адрес.

Для обеспечения оперативного переключения между рабочими нодами следует использовать протокол VRRP версии 3, так как он позволяет осуществлять рассылку сообщений VRRP advertisements с интервалом в 1/100 секунды (сантисекунда) в отличие от протокола VRRP версии 2, который оперирует секундными интервалами. С точки зрения протокола IPNET это важно, так как протокол IPNET реализует свои собственные keepalive-сообщения. При использовании протокола VRRP версии 2 худшее время переключения виртуального IP-адреса составит 4 секунды при минимально допустимом по протоколу времени рассылки VRRP advertisements в одну секунду, что может быть недопустимо долго с точки зрения механизма IPNET keepalive и приведёт к разрушению вызова со стороны встречной станции.

В предлагаемой конфигурации обмен VRRP advertisements между нодами происходит каждые 50 мс. Интервал VRRP advertisements следует выбирать исходя из величины сетевой задержки между нодами. Выбранный интервал в 50 мс позволяет оперативно переключаться при сбое нод, а также пережить без ложного срабатывания возрастание сетевой задержки до 150-200 мс. В случае, если ноды сильно разнесены географически, может потребоваться увеличить этот интервал, исходя из реальных характеристик сети. Однако делать слишком большим интервал не следует, так как это может повлиять на стабильность сохранения активных вызовов при переключении адреса на резерв. Худшее время переключения при отказе мастера или потере пакетов VRRP advertisements в случае проблем на сети составит advert_int x 4.

Конфигурацию виртуальных адресов для IPNET рекомендуется поместить в отдельный файл /etc/keepalived/ipnet.conf.

# Конфигурация первой ноды:

vrrp_script check_ipnet {
    script "/usr/bin/ecss_ipnet_port 65531"
    interval 1
    fall 1
    rise 1
}

vrrp_instance IPNET {
    state MASTER                   # Исходное состояние при старте
    interface <network_interface>  # Имя сетевого интерфейса, на котором будет работать протокол VRRP
    virtual_router_id <ID>         # Уникальный идентификатор роутера (0..255)
    priority 100                   # Приоритет (0..255) чем выше — тем больше
    advert_int 0.05                # Интервал рассылки уведомлений (с)
    preempt_delay 60               # Интервал ожидания мастера при старте демона (с) при исходном состоянии BACKUP

    unicast_src_ip  <src_real IP>  # Собственный реальный IP-адрес
    unicast_peer {
         <real_remote IP>          # Реальный IP-адрес соседа
    }

    virtual_ipaddress {
        # Виртуальный IP-адрес и маска
        # dev — сетевой интерфейс, на котором будет поднят виртуальный адрес
        # label — метка виртуального интерфейса (для удобства идентификации)
        <virtual_sip_IP>/<netmask> dev <>  label <label>
    }

    track_script {
        check_ipnet
    }
}
# Конфигурация второй ноды

vrrp_script check_ipnet {
    script "/usr/bin/ecss_ipnet_port 65531"
    interval 1
    fall 1
    rise 1
}

vrrp_instance IPNET {
    state BACKUP
    interface <network_interface>
    virtual_router_id <ID>
    priority 50
    advert_int 0.05
    preempt_delay 60

    unicast_src_ip  <src_real IP>
    unicast_peer {
         <real_remote IP>
    }

    virtual_ipaddress {
        <virtual_sip_IP>/<netmask> dev <>  label <label>
    }

    track_script {
        check_ipnet
    }
}


Более подробная информация о приложении keepalived и его настройке приведена здесь.

Запуск системы

После того как все настроено, можно приступать к запуску и активации системы.

На ecss1:

  • Установить паспорт, лицензию и запуск сервисов ecss;
  • Проверить статус сервисов;
  • Проверить доступность подсистем по DNS-именам;
  • Проверить статус нод из CoCon (node/check-services).

После того как на ecss1 успешно запустились подсистемы и была активирована лицензия, можно запускать все сервисы ecss2.

Проверка установки и вхождения системы в кластер

Для проверки статуса работы нод в кластере нужно войти в командную консоль (CoCon) на любом из серверов:

ssh admin@<IP_ECSS> -p8023

где <IP_ECSS> — IP-адрес или доменное имя сервера ecss.

Пароль по умолчанию — password. После входа введите команду node/check-services. Должны отобразиться ноды обоих серверов.

Пример:

admin@mycelium1@ecss1:/$ node/check-services 
Nodes:
    core1@ecss1     core1@ecss2
      ds1@ecss1       ds1@ecss2
      md1@ecss1       md1@ecss2
mycelium1@ecss1 mycelium1@ecss2
     sip1@ecss1      sip1@ecss2

All services are started

Также необходимо проверить, что ноды "видят" друг друга, командой node/nodes-info, пример:

admin@mycelium1@ecss1:/$ node/nodes-info   
┌───────────────┬───────────────────────────────┬─────────────────────┐
│     Node      │            Erlang             │       Mnesia        │
├───────────────┼───────────────────────────────┼─────────────────────┤
│core1@ecss1    │core1@ecss1,core1@ecss2        │not running          │
│core1@ecss2    │core1@ecss1,core1@ecss2        │not running          │
│ds1@ecss1      │ds1@ecss1,ds1@ecss2            │ds1@ecss1,ds1@ecss2  │
│ds1@ecss2      │ds1@ecss1,ds1@ecss2            │ds1@ecss1,ds1@ecss2  │
│md1@ecss1      │md1@ecss1,md1@ecss2            │md1@ecss1,md1@ecss2  │
│md1@ecss2      │md1@ecss1,md1@ecss2            │md1@ecss1,md1@ecss2  │
│mycelium1@ecss1│mycelium1@ecss1,mycelium1@ecss2│not running          │
│mycelium1@ecss2│mycelium1@ecss1,mycelium1@ecss2│not running          │
│sip1@ecss1     │sip1@ecss1,sip1@ecss2          │sip1@ecss1,sip1@ecss2│
│sip1@ecss2     │sip1@ecss1,sip1@ecss2          │sip1@ecss1,sip1@ecss2│
└───────────────┴───────────────────────────────┴─────────────────────┘

На этом этап инсталляции закончен. После проверки можно приступить к настройке.

Вывод из обслуживания одного сервера

Если по каким-то причинам требуется вывести из обслуживания первый сервер кластера ecss1, то на втором сервере ecss2 необходимо выполнить следующее:

Открыть файл /etc/hosts:

sudo nano /etc/hosts
CODE

Назначить для хоста ecss1 адрес, соответствующий хосту ecss2:

127.0.0.1    localhost
127.0.1.1    ecss2
192.168.1.2    ecss1

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
CODE

Также данное действие можно произвести при помощи утилиты ecss-control.

Проверка корректности инсталляционных процедур

После выполнения всех инсталляционных процедур следует проверить правильность и полноту выполненных действий. Для этого используется чек-лист, приведенный в разделе "Чек-лист по установке ECSS-10 версии 3.14.10".