Руководство администратора wiSLA 5 Community version

• 1. УСТАНОВКА И ОБНОВЛЕНИЕ WISLA
• Программные требования
• Сетевые доступы
• Подготовка операционной системы к запуску программы установки
• Подготовка системы, установка и обновление wisla (ручная)
• Установка wiSLA 5
• Изменение одного или нескольких параметров wiSLA
• Экранные формы хода установки (Работа с программой установки)
• Активация модуля автокорреляции
• Действия при неудачной попытке установки и восстановление работоспособности в случае сбоя
• Восстановление из backup
• Действия по обслуживанию wiSLA
• Установка wiSLA в контейнер podman
• Скрипты для взаимодействия с wiSLA
• Инструкция по полуавтоматическому обновлению wiSLA (alfa-test)
• 2. ЗАПУСК И ОСТАНОВКА
• 3. С ЧЕГО НАЧАТЬ
• 4. АДМИНИСТРИРОВАНИЕ WEB-ПОРТАЛА
• Контрагенты
• Пользователи
• Сессии
• Журнал событий
• Настройки системы
• 5. РАЗГРАНИЧЕНИЕ ПРАВ ДОСТУПА НА WEB-ПОРТАЛЕ
• Роли и права на действия с объектами
• Редактирование владельцев объектов
• 6. РЕЗЕРВНОЕ КОПИРОВАНИЕ И ВОССТАНОВЛЕНИЕ
• 7. ОТКАЗОУСТОЙЧИВЫЙ КЛАСТЕР
• Необходимое окружение и библиотеки
• Подготовительные этапы к установке кластера
• Действия в программе установки wiSLA
• Настройка скриптов для учёта кратковременных обрывов связи
• Действия по восстановлению работы кластера при выходе из строя одного из узлов ЦОД1
• Действия по восстановлению работы кластера при выходе из строя одного из узлов ЦОД2
• Действия по восстановлению работы кластера при выходе из строя третьей точки опоры
• 8. wiSLA  В ИЗОЛИРОВАННОМ КОНТУРЕ
• 9. ОБЛАЧНЫЙ РЕЖИМ
• 10. ПОДГОТОВКА АГЕНТА ДЛЯ АВТОМАТИЧЕСКОГО СКАНИРОВАНИЯ СЕТИ
• 11. ПОДГОТОВКА СЕНСОРА NETFLOW
• 12. РАСЧЕТ АППАРАТНОЙ ЧАСТИ WISLA
• Расчет аппаратной части промышленного контура wiSLA
• 13. ВАЖНАЯ ИНФОРМАЦИЯ

1. УСТАНОВКА И ОБНОВЛЕНИЕ WISLA

Программные требования

1. Операционная система для развёртывания сервера: CentOS 7, Debian 11, Ubuntu 20.04 LTS, Astra Linux Special Edition 1.6 Smolensk, RedOS 7.3. Использование других операционных систем требует анализа возможности применения.
   
2. Архитектура: x86_64.
   
3. Для корректной работы программы установки требуется разрешить зависимости (установить дополнительные пакеты согласно описанию ниже). Для этого сервер, где планируется запуск программы установки, должен иметь доступ к репозиториям или набору пакетов операционной системы на время установки системы wiSLA. Если это невозможно, следует обратиться в службу технической поддержки.
   
4. В ходе подготовки окружения операционной системы к установке потребуется редактировать текстовые файлы настроек. Рекомендуется установить и использовать знакомый администратору пакет для работы с текстовыми файлами, например: nano, mcedit, vim, vi.
   
5. Для корректного заполнения адресов и автоматического определения координат точек доступа серверы wiSLA и рабочие места пользователей должны иметь доступ к сети интернет. Если доступ к сети интернет невозможен, потребуется развернуть локальный сервер карт (обратитесь в службу поддержки за получением инструкций).
   
6. Для возможности рассылки уведомлений по электронной почте серверам wiSLA должен быть доступен корпоративный или внешний сервер электронной почты.
   
7. Для корректной работы механизмов системы требуется обеспечить синхронизацию времени по протоколу NTP на серверах wiSLA, зондах и программных агентах. Настройка NTP не описывается в настоящем документе.
   
8. Для работы с порталом рекомендуются браузеры:
   • Mozilla Firefox v 134.0 и выше
   • Google Chrome v 132.0.6834.83 и выше
   • Yandex browser v 24.12.2.856 и выше

Сетевые доступы

Используемые сетевые доступы представлены в таблице. 

Подготовка операционной системы к запуску программы установки

Программа установки представляет собой консольное псевдографическое приложение с набором скриптов и настроек, работающее в Linux-окружении (bash). Дистрибутив и программа установки, как правило, поставляются как единый самораспаковывающийся run-файл. Шаблоны отчётов и плагины могут поставляться в виде отдельных файлов.

Если система wiSLA устанавливается на несколько серверов, один экземпляр программы установки, запущенный на одном сервере, может управлять процессом установки, настройки и резервного копирования данных на всех серверах. Для этого создаётся пользователь wisla, которому обеспечивается посредством SSH доступ по ключу ко всем серверам контура.

Перед запуском программы установки требуется выполнить следующие шаги:

1. На непосредственном рабочем месте администратора подготовить к работе приложение – SSH-клиент, с помощью которого будет производиться взаимодействие с консолями серверов. Для Windows рекомендуется PuTTY. Для операционных систем семейства Linux можно воспользоваться стандартным эмулятором терминала и утилитой ssh.
2. Назначить уникальные сетевые имена (hostname) серверам (например, добавить запись в /etc/hosts). Этот шаг можно пропустить, если серверы централизовано получают hostname в автоматическом режиме или действие было выполнено ранее (например, в процессе установки операционной системы).

Подготовка системы, установка и обновление wisla (ручная)

Установка системы

Программно-аппаратные требования

Платформа: аппаратный сервер или виртуальная машина (с учетом будущей инфраструктуры рекомендуется не менее 30 Гбайт свободного пространства на диске, минимум 8 Гбайт оперативной памяти без GUI и 10 Гбайт оперативной памяти с GUI).

Операционная система: CentOS 7, Debian 11, Ubuntu 20.04 LTS, Astra Linux Special Edition 1.6 Smolensk, RedOS 7.3, Astra Linux Special Edition 1.7(Орел и Воронеж).

Архитектура: x86_64.

Пакеты: deb.zip | astra.zip | centos.zip | redos.zip

Настройка ОС

Ниже описаны шаги по подготовке окружения операционной системы к выполнению программы установки.

1. Установка и запуск клиента SSH 

Для Linux-совместимых операционных систем можно воспользоваться стандартной консолью и утилитой ssh, авторизоваться можно как Administrator.

2. Настройка hostname

Задайте имя сервера в файлах /etc/hostname и /etc/hosts как указано на примерах ниже.

Пример структуры файла /etc/hostname:

wisla

Пример структуры файла /etc/hosts:

127.0.0.1       localhost
192.168.159.136 wisla

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

Обратите внимание!
В некоторых Linux-дистрибутивах в файле /etc/hosts указанный во время установки системы hostname может ссылаться на 127.0.1.1, для корректной работы сервисов WiSLA эту запись нужно изменить в соответствии с примером выше. 

Если сетевые настройки получены по DHCP, в будущем могут возникнуть проблемы при изменении IP-адреса сервера, так как сервисы будут ссылаться на записи в файле /etc/hosts, который останется без изменений. Рекомендуется использовать статический IP-адрес на сетевом интерфейсе сервера.

В файле /etc/hosts имя хоста должно соответствовать IP-адресу, отличному от 127.0.0.1 и 127.0.1.1.

3. Создание пользователя “wisla”

Если на вашем сервере присутствует только учётная запись суперпользователя Administrator, тогда вам необходимо создать сервисную учётную запись для работы с системой. В данном примере будет создана учётная запись wisla:

sudo useradd -d /home/wisla -m wisla && sudo passwd wisla

В терминале сервера появится запрос на ввод пароля, задайте надёжный пароль для сервисной учётной записи.

4. Изменение привилегий для пользователя “wisla”

Чтобы все сервисы WiSLA работали корректно необходимо предоставить сервисной учётной записи привилегированный доступ без запроса пароля: 

cat << EOF > /etc/sudoers.d/wisla
## Allow wisla to run any commands anywhere
wisla    ALL=(ALL:ALL) NOPASSWD:ALL

EOF

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

5. Создайте подкаталог /opt/wisla5

Для хранения файлов системы WiSLA необходимо создать подкаталог /opt/wisla5:

# Если вы работаете из под учётной записи Administrator переключитесь на ранее созданного пользователя wisla
su -l wisla
# Если вы уже переключились на сервисную учётную запись используйте sudo 
sudo mkdir -p /opt/wisla5 && sudo chown wisla:wisla /opt/wisla5

Скопируйте файлы дистрибутива wisla*.run с помощью программы winSCP или другим доступным способом в подкаталог /home/wisla/:

mv wisla*.run /home/wisla
sudo chown -R wisla:wisla /home/wisla/
chmod +x /home/wisla/wisla*

6. Установка зависимостей

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

sudo yum install ntp lzo dialog rsync uuid zip unzip wget tar python3 fontconfig curl pv uuid python3-paramiko

#Копируем архив на хост удобным способом

# Разархивируем 
unzip redos.zip
cd redos

# Устанавливаем
#Все по очереди:
for i in $(ls *.rpm) 
do
  rpm -i $i || exit
done
#Вручную:
rpm -i libtomcrypt-1.18.2-1.el7.x86_64.rpm libtommath-1.2.0-3.el7.x86_64.rpm dialog-1.3-14.20171209.el7.x86_64.rpm pv-1.6.6-1.x86_64.rpm uuid-1.6.2-26.el7.x86_64.rpm
rpm -i python3-pynacl-1.5.0-1.el7.x86_64.rpm python3-bcrypt-3.2.2-1.el7.x86_64.rpm python3-paramiko-3.2.0-1.el7.noarch.rpm

sudo yum install ntp lzo dialog rsync uuid zip unzip wget tar python3 fontconfig curl
wget https://bootstrap.pypa.io/get-pip.py
python3 get-pip.py
python3 -m pip install --upgrade pip
pip install paramiko
sudo rpm -i http://www.ivarch.com/programs/rpms/pv-1.6.6-1.x86_64.rpm

#Копируем архив на хост удобным способом

# Разархивируем 
unzip centos.zip
cd centos-pgks

# Устанавливаем
#Все по очереди:
for i in $(ls *.rpm) 
do
  rpm -i $i || exit
done
#Вручную:
rpm -i wget-1.14-18.el7_6.1.x86_64.rpm
rpm -i uuid-1.6.2-26.el7.x86_64.rpm
rpm -i rsync-3.1.2-10.el7.x86_64.rpm
rpm -i python-crypto-2.6.1-1.el7.centos.x86_64.rpm
rpm -i python-paramiko-2.1.1-9.el7.noarch.rpm
rpm -i pv-1.6.6-1.x86_64.rpm
rpm -i dialog-1.2-5.20130523.el7.x86_64.rpm

# Возможно потребуется установить дополнительные пакеты из этого архива

sudo apt install -y ntp pv liblzo2-2 dialog rsync uuid zip unzip wget tar python3 python3-paramiko fontconfig curl language-pack-ru

sudo apt install -y ntp liblzo2-2 dialog rsync zip unzip wget tar python3 python3-paramiko fontconfig curl

unzip astra.zip
cd astra-pkgs
#Все по очереди:
ls *.deb > /tmp/packages.list && sudo dpkg -i $(cat /tmp/packages.list) && rm -rf /tmp/packages.list
#Вручную:
sudo dpkg -i pv_1.6.6-1_amd64.deb
sudo dpkg -i rsync_3.1.3-6+ci202302061937+astra1_amd64.deb
sudo dpkg -i libossp-uuid16_1.6.2-1.5+b4_amd64.deb
sudo dpkg -i uuid_1.6.2-1.5+b4_amd64.deb
sudo dpkg -i wget_1.20.1-1.1_amd64.deb
sudo dpkg -i python3-paramiko_2.6.0-1~bpo10+1_all.deb
sudo dpkg -i python3-*
sudo dpkg -i dialog_1.3-20190211-1_amd64.deb

wget https://bootstrap.pypa.io/pip/3.7/get-pip.py

python3 get-pip.py

sudo apt install python3-distutils

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

python -m pip install --upgrade pip

pip install --upgrade paramiko

sudo apt install -y rsync libossp-uuid16 uuid wget python3 python3-paramiko dialog dialog fontconfig liblzo2-2 python3-asn1crypto python3-bcrypt python3-cffi-backend python3-cryptography python3-nacl rsync unzip zip

unzip astra.zip
cd astra-pkgs
#Все по очереди:
ls *.deb > /tmp/packages.list && sudo dpkg -i $(cat /tmp/packages.list) && rm -rf /tmp/packages.list
#Вручную:
sudo dpkg -i pv_1.6.6-1_amd64.deb
sudo dpkg -i rsync_3.1.3-6+ci202302061937+astra1_amd64.deb
sudo dpkg -i libossp-uuid16_1.6.2-1.5+b4_amd64.deb
sudo dpkg -i uuid_1.6.2-1.5+b4_amd64.deb
sudo dpkg -i wget_1.20.1-1.1_amd64.deb
sudo dpkg -i python3-paramiko_2.6.0-1~bpo10+1_all.deb
sudo dpkg -i python3-*
sudo dpkg -i dialog_1.3-20190211-1_amd64.deb

sudo dpkg -i pv_1.6.6-1_amd64.deb

sudo apt-get install -y ntp pv dialog rsync zip unzip wget tar python3 fontconfig curl python3-module-paramiko ossp-uuid

7. Установить python3 по умолчанию

Укажите системе использовать python3 в качестве основной версии:

sudo update-alternatives --install /usr/bin/python python /usr/bin/python3 1

8. Настройка правил firewall

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

sudo firewall-cmd --permanent --zone=public --add-port=8080/tcp
sudo firewall-cmd --reload

# Открываем файл
sudo nano /etc/selinux/config
# Утсанавливаем значение и сохраняем
SELINUX=permissive
# Выключаем на текущий момент чтобы не перезагружаться
setenforce 0

sudo ufw allow 8080/tcp

9. Настройка limits.conf:

Выполните команду ниже или создайте файл вручную как указано на примере ниже:

cat << EOF > /etc/security/limits.d/wisla
wisla   soft      nofile  32768
wisla   hard     nofile  32768
wisla   soft      nproc   32768
wisla   hard     nproc   32768

EOF

10. Настройка locale

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

sudo dnf install glibc-locale-source glibc-langpack-ru 
sudo localectl set-locale LANG=ru_RU.UTF-8

sudo apt install -y locales
sudo sed -i 's|# ru_RU.UTF-8 UTF-8|ru_RU.UTF-8 UTF-8|g' /etc/locale.gen
sudo locale-gen ru_RU
sudo locale-gen ru_RU.UTF-8
sudo update-locale
localectl set-locale LANG=ru_RU.UTF-8

sudo locale-gen ru_RU.UTF-8
sudo dpkg-reconfigure locales

Обратите внимание!
Перед запуском программы установки следует выполнить команду locale и убедиться, что активна ru_RU.UTF-8. При возникновении проблем необходимо обратиться к документации по дистрибутиву для установки нужной локали. Также следует проверить вывод timedatectl, часовой пояс должен иметь буквенное обозначение вместо n/a.

11. Подготовка системы к установке

Сгенерируйте SSH-ключ для беспарольного доступа по SSH для пользователя wisla:

# Переключитесь на пользователя wisla, если вы не сделали этого ранее
su -l wisla
# Сгенерируйте SSH-ключ
ssh-keygen -P ""
# В случае если установка в кластере нужно выполнить следующую команду для каждого сервера, 
# где вместо $(hostname) dns имя или ip адрес в зависимости от того как будут указаны сервера в конфигурации при установки
username=$(whoami)
ssh-copy-id $username@$(hostname)
ssh-copy-id $username@localhost
# Проверьте работу аутентификации по ключам
ssh $username@$(hostname) exit
ssh $username@localhost exit

Обратите внимание!
Запроса пароля быть не должно! Если пароль запрашивается, тогда требуется найти причину и добиться входа без пароля, иначе в процессе установки будут происходить многократные запросы пароля. Причиной может быть неразрешённый тип ключа или несоответствие сетевого (доменного) имени.

Отключите опцию KillUserProcesses:

sudo sed -i 's/#KillUserProcesses=yes/KillUserProcesses=no/g' /etc/systemd/logind.conf

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

sudo reboot

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

12. Запуск программы установки

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

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

Обратите внимание!
Программа установки должна запускаться под сервисной учётной записью в её окружении, в данном примере это пользователь wisla.

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

Если установка системы будет аварийно прервана или завершена с ошибкой, журналы установки можно найти в каталоге с программой (install*.log, runtime.log). Информация о ходе установки также доступна в буфере эмулятора терминала.

Переключитесь на каталог, в который была скопирована программа установки:

cd /home/wisla

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

./wisla*.run

Если программа установки не стартует попробуйте выполнить export TERM=xterm перед её запуском.

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

Навигация в программе установки осуществляется с помощью стрелок управления курсором, клавиш Home, End, Tab, Esc и Enter.
Если требуется аварийно прервать работу программы, можно использовать комбинацию клавиш CTRL+C, для штатного завершения программы установки следует использовать кнопку Exit.

В процессе установки вам также необходимо проверить следующие конфигурации:

Окно 'Installer startup configuration'

Проверьте параметры 'Install master', при установке всех компонентов на один сервер его имя должно быть указано здесь.

Окно 'Select action'

Нажмите 'Install'.

Окно 'JRE* configuration'

Нажмите 'OK'.

Окно 'Postgresql* configuration'

Проверить параметр 'Trust host or network'.

Нужно проверить и заполнить Trusted network/host, иначе будут проблемы с подключением Postgres и патчами.

Окно 'Wildfly* configuration'

Проверить значение memory size.

Окно 'Hadoop* configuration'

Проверить имя hostname в 'HDFS master' и 'Tracker host' fields'.

Окно 'HBase* configuration'

Проверить имя hostname в 'Zookeeper quorum'.

Окно 'wiSLA* data collection configuration'

Если планируется использование зондов wiProbe, нужно прокрутить список и изменить настройку «wiProbe destination». В ней задаётся адрес, который будет использоваться зондом для отправки данных в систему wiSLA, в форме URL. Остальные параметры менять без необходимости не рекомендуется.

Окно 'wiSLA* LDAP configuration'

Если не планируется интегрировать систему с MS Active Directory или OpenLDAP Server, рекомендуется оставить значения по умолчанию.

Окно 'wiSLA* resources configuration'

Убедиться, что имя hostname указано в URL.

Окно 'wiSLA* notification and ASI configuration'

Требуется указать параметры подключения к почтовому серверу. Если этого не сделать, новые пользователи не смогут получать письма о добавлении учётной записи и другие уведомления, отсылаемые на email. Также здесь можно включить отправку SNMP-уведомлений по определённым событиям. 
Настройка email-уведомлений:
1.Необходимо выбрать почту с которой буду отправляться уведомления и выполнить настройку по инструкции.
2.Устанавливаем конфиги:

• Notification enabled: true
• Profile-status notification enabled: false
• Service notification enabled: false
• Wisla notification op_link: wisla
• Wisla notification cp_link: wisla
• Wisla inter-hop master:
• Wisla inter-hop slaves:
• Wisla inter-hop slave: false
• Mail host: smtp.{домен почты}.ru
• Mail from: email  (например: test_push@yandex.ru)
• Mail from alias: email без домена (например: test_push )
• Mail port: 587
• Mail protocol: smtp
• Mail smtp auth: true
• Mail smtp starttls: true
• Mail user: email с которого планируется отправка уведомлений (например: test_push@yandex.ru)
• Mail password: "пароль приложения" сформированный на шаге 1
• ASI notification enabled: false
• ASI hendlers: genericSnmp
• ASI SNMP distation: 
• Events limit for notification: 10
• No data duration: 10
• Reports use en filenames: false

Окно 'wiSLA* operator portal configuration'

Обращаем ваше внимание, если вы получаете доступ к порталу с помощью проброса портов или через прокси сервер, то вам необходимо отредактировать пункт HOST и в Whitelisted domains установить необходимые IP-адреса.

3. Подтверждение настроек

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

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

Во время установки в каталог /opt/wisla5 будут добавлены следующие компоненты:

• Zookeeper;
• Hadoop;
• HBase;
• PostgreSQL;
• Java Runtime Environment;
• WildFly Application Server;
• wiSLA Portal.

Процесс можно прервать, нажав CTRL+C, все настройки будут сброшены.

После завершения установки будет предложено добавить систему в список автозагрузки – нажмите кнопку Нет.

Обратите внимание!
В ходе тестирования выявлено, что на Astra Linux в некоторых сценариях не создается systemd unit, при возникновении данной проблемы нужно создать его руками.

Выполните команду ниже или создайте файл вручную с содержанием как на примере ниже:

cat << EOF > /etc/systemd/system/wisla.service
[Unit]
Description=Starts JBoss process with wiSLA 5 system
After=network-online.target
Requires=network-online.target

[Service]
Type=forking
RemainAfterExit=true
WorkingDirectory=/opt/wisla5
ExecStart=/opt/wisla5/scripts/wisla5.sh start
ExecStop=/opt/wisla5/scripts/wisla5.sh stop

[Install]
WantedBy=multi-user.target

EOF

sudo systemctl daemon-reload
sudo systemctl enable wisla.service

13. Запуск WiSLA

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

less -f /opt/wisla5/wildfly/current/standalone/log/server.log
less -f /opt/wisla5/wildfly/current/standalone/log/communicator.log

Маркером успешного запуска является следующее сообщение в журнале (server.log):

INFO  [com.wellink.wisla.communicator.impl.state.AvailabilitySystemStateSingletonImpl] (http-0.0.0.0-0.0.0.0-8080-1) !***   THE ALL wiSLA
COMPONENTS ARE FULLY DEPLOYED, INTERCONNECTED AND READY TO WORK!   ***!
13:48:30,028 INFO  [com.wellink.wisla.communicator.impl.state.AvailabilitySystemStateSingletonImpl] (http-0.0.0.0-0.0.0.0-8080-1) !********************
**********************************************************************!

Теперь можно запустить веб-браузер и открыть страницу системы указав IP-адрес сервера и порт.

 
В данном примере система будет доступна по адресу http://192.168.159.136:8080.

Обновление wiSLA

Рекомендуется обновляться с предыдущей минорной версии wiSLA (5.1->5.2->5.2.1->5.2.2->5.2.3).

1) Запустить программу установки wiSLA 5.2.3;

2) В основном меню выбрать пункт Update;

2.1) Подтвердить или отклонить создание резервной копии (рекомендуется сделать);

2.2) Подтвердить остановку компонентов wiSLA;

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

2.4) После обновления и запуска всех компонентов системы подтвердить или отклонить добавление wiSLA в автозагрузку;

3) После успешного запуска сервера приложений, выполнить индексацию (Maintenance > wiSLA > Reindex (Не путать со Standalone Reindex!);

4) Открыть портал, проверить работу системы;

5) Очистить кэш браузера на всех рабочих местах.

Возможные ошибки в процессе обновления:

Иногда при обновлении до новой версии может зависнуть сервис wildfly, на это будут указывать следующие записи в журнале server.log:

13:24:21,676 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) 
 WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "wisla-engine-5.2.4-SNAPSHOT.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"wisla-engine-5.2.4-SNAPSHOT.war\".undertow-deployment" => "java.lang.RuntimeException: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'expireSessionSchedulerSingleton': Unsatisfied dependency expressed through field 'eventLoggerService'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'eventLoggerService' defined in class path resource [audit/conf/spring/services.xml]: Cannot resolve reference to bean 'hibernateAuditLogAppender' while setting bean property 'appenders' with key [0]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'hibernateAuditLogAppender' defined in class path resource [audit/conf/spring/services.xml]: Cannot resolve reference to bean 'sessionFactory' while setting bean property 'sessionFactory'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory' defined in class path resource [engine/conf/spring/datasource.xml]: Invocation of init method failed; nested exception is org.hibernate.search.exception.SearchException: HSEARCH000103: Unable to initialize IndexManager named 'sap' 
    Caused by: java.lang.RuntimeException: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'expireSessionSchedulerSingleton': Unsatisfied dependency expressed through field 'eventLoggerService'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'eventLoggerService' defined in class path resource [audit/conf/spring/services.xml]: Cannot resolve reference to bean 'hibernateAuditLogAppender' while setting bean property 'appenders' with key [0]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'hibernateAuditLogAppender' defined in class path resource [audit/conf/spring/services.xml]: Cannot resolve reference to bean 'sessionFactory' while setting bean property 'sessionFactory'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory' defined in class path resource [engine/conf/spring/datasource.xml]: Invocation of init method failed; nested exception is org.hibernate.search.exception.SearchException: HSEARCH000103: Unable to initialize IndexManager named 'sap' 
    Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'expireSessionSchedulerSingleton': Unsatisfied dependency expressed through field 'eventLoggerService'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'eventLoggerService' defined in class path resource [audit/conf/spring/services.xml]: Cannot resolve reference to bean 'hibernateAuditLogAppender' while setting bean property 'appenders' with key [0]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'hibernateAuditLogAppender' defined in class path resource [audit/conf/spring/services.xml]: Cannot resolve reference to bean 'sessionFactory' while setting bean property 'sessionFactory'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory' defined in class path resource [engine/conf/spring/datasource.xml]: Invocation of init method failed; nested exception is org.hibernate.search.exception.SearchException: HSEARCH000103: Unable to initialize IndexManager named 'sap' 
    Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'eventLoggerService' defined in class path resource[audit/conf/spring/services.xml]: Cannot resolve reference to bean 'hibernateAuditLogAppender' while setting bean property 'appenders' with key [0]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'hibernateAuditLogAppender' defined in class path resource [audit/conf/spring/services.xml]: Cannot resolve reference to bean 'sessionFactory' while setting bean property 'sessionFactory'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory' defined in class path resource [engine/conf/spring/datasource.xml]: Invocation of init method failed; nested exception is org.hibernate.search.exception.SearchException: HSEARCH000103: Unable to initialize IndexManager named 'sap' Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'hibernateAuditLogAppender' defined in class path resource [audit/conf/spring/services.xml]: Cannot resolve reference to bean 'sessionFactory' while setting bean property 'sessionFactory'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory' defined in class path resource [engine/conf/spring/datasource.xml]: Invocation of init method failed; nested exception is org.hibernate.search.exception.SearchException: HSEARCH000103: Unable to initialize IndexManager named 'sap' 
    Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory' defined in class path resource [engine/conf/spring/datasource.xml]: Invocation of init method failed; nested exception is org.hibernate.search.exception.SearchException: HSEARCH000103: Unable to initialize IndexManager named 'sap' 
    Caused by: org.hibernate.search.exception.SearchException: HSEARCH000103: Unable to initialize IndexManager named 'sap' 
    Caused by: org.hibernate.search.exception.SearchException: Unable to open Lucene IndexReader for IndexManager sap 
    Caused by: org.apache.lucene.index.CorruptIndexException: file mismatch, expected id=42hlomvwa71vvwwn7vem94t0p, got=7mz5ojw75crmjs1kxhmc322p2 (resource=BufferedChecksumIndexInput(MMapIndexInput(path=\"/opt/wisla5/wildfly/wildfly-14.0.1.Final/bin/searchindexes/engine/sap/_q.si\")))"}}

Чтобы решить эту проблему удалите содержимое каталога /opt/wisla5/wildfly/wildfly-14.0.1.Final/bin/searchindexes/engine/sap/:

sudo rm -rf /opt/wisla5/wildfly/wildfly-14.0.1.Final/bin/searchindexes/engine/sap/*

Затем повторно запустите процесс обновления с помощью инсталлятора wisla, после обновления системы не забудьте запустить индексацию.

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

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

В данной ситуации нужно проделать следующие действия:

1. Сделать резервную копию БД для возможности восстановления данных на другой машине со старой версией приложения;
   
2. Остановите приложения wiSLA;
3. Подключиться к БД используя клиент, например DBviewer;
4. Переключиться на БД wisla и выполнить скрипт wisla_init_schema.sql;
   
5. Затем выполнить скрипт wisla_init_schema.sql;
6. После выполнения скриптов отключитесь от БД и вернитесь к терминалу сервера с инсталлером;
7. Загрузите на сервер пустую БД wiSLA clear1.backup;
8. Перейдите в раздел backup и загрузите пустую БД в базу в режиме восстановления;
9. Загрузив БД перейдите к настройке PostgreSQL (Maintenance > PostrgeSQL) и запустите патч для создания необходимых таблиц;
10. После того как таблицы будут сформированы запустите приложения wiSLA и проверьте работу веб-портала.

Установка wiSLA 5

Оглавление

1. Системные требования;
2. Подготовка операционной системы;
3. Установка системы мониторинга wiSLA 5;
   
4. Запуск wiSLA.

Системные требования

Платформа:

• Физический сервер или виртуальная машина с поддержкой микроархитектуры x86-64;
• Объём накопителя не менее 40 ГБайт;
• Не менее 10 ГБ оперативной памяти;
• Совместимая операционная система.

Список поддерживаемых операционных систем:

• Debian 12;
• Debian 11;
• Debian 10;
• Ubuntu 24.04 LTS;
• Ubuntu 22.04 LTS;
• Ubuntu 20.04 LTS;
• Astra Linux 1.8.1;
• Astra Linux 1.7.7 (начиная с v1.9.6)
• Astra Linux 1.7.6;
• Astra Linux 1.7.5;
• Red OS 8.0.

Файлы программы можно загрузить из GitLab.

Запись встречи с демонстрацией работы программы можно посмотреть на корпоративном облаке.

Подготовка операционной системы 

1. Загрузка файлов на сервер

Подключитесь к серверу через протокол SSH используя учётную запись пользователя с привилегированным доступом. Затем с помощью SFTP или scp скопируйте файлы программы и инсталлятор wiSLA 5 на сервер, например в домашний каталог текущего пользователя.

sudo vim /etc/hosts

127.0.0.1       localhost
192.168.159.136 wisla

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

hostname -i

kreshetnikov@wisla:~$ hostname -i
192.168.159.136

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

sudo chmod +x ./preparing-os.start

После обновления прав доступа запустите программу.

2. Предварительная настройка узла

Запустите программу предварительной настройки:

./preparing-os.start

При запуске программы будет выведена информация о её версии, системе и релизе, затем запустится механизм проверки необходимых файлов и будет создан журнал для записи событий:

wisla-admin@wisla:~$ ./preparing-os.start

WWWWWWWW                           WWWWWWWW                 lllllll  lllllll    iiii                    kkkkkkkk
W::::::W                           W::::::W                 l:::::l  l:::::l   i::::i                   k::::::k
W::::::W                           W::::::W                 l:::::l  l:::::l    iiii                    k::::::k
W::::::W                           W::::::W                 l:::::l  l:::::l                            k::::::k
 W:::::W           WWWWW           W:::::W  eeeeeeeeeeee     l::::l   l::::l  iiiiiii nnnn  nnnnnnnn     k:::::k    kkkkkkk
  W:::::W         W:::::W         W:::::W ee::::::::::::ee   l::::l   l::::l  i:::::i n:::nn::::::::nn   k:::::k   k:::::k
   W:::::W       W:::::::W       W:::::W e::::::eeeee:::::ee l::::l   l::::l   i::::i n::::::::::::::nn  k:::::k  k:::::k
    W:::::W     W:::::::::W     W:::::W e::::::e     e:::::e l::::l   l::::l   i::::i nn:::::::::::::::n k:::::k k:::::k
     W:::::W   W:::::W:::::W   W:::::W  e:::::::eeeee::::::e l::::l   l::::l   i::::i   n:::::nnnn:::::n k::::::k:::::k
      W:::::W W:::::W W:::::W W:::::W   e:::::::::::::::::e  l::::l   l::::l   i::::i   n::::n    n::::n k:::::::::::k
       W:::::W:::::W   W:::::W:::::W    e::::::eeeeeeeeeee   l::::l   l::::l   i::::i   n::::n    n::::n k:::::::::::k
        W:::::::::W     W:::::::::W     e:::::::e            l::::l   l::::l   i::::i   n::::n    n::::n k::::::k:::::k
         W:::::::W       W:::::::W      e::::::::e          l::::::l l::::::l i::::::i  n::::n    n::::n k::::::k k:::::k
          W:::::W         W:::::W        e::::::::eeeeeeee  l::::::l l::::::l i::::::i  n::::n    n::::n k::::::k  k:::::k
           W:::W           W:::W          ee:::::::::::::e  l::::::l l::::::l i::::::i  n::::n    n::::n k::::::k   k:::::k
            WWW             WWW             eeeeeeeeeeeeee  llllllll llllllll iiiiiiii  nnnnnn    nnnnnn kkkkkkkk    kkkkkkk


Привет, wisla-admin!

Данная программа выполнит подготовку сервера для развёртывания системы мониторинга wiSLA.
Автор программы: системный инженер К. Решетников.
Версия программы: 1.9.6.

Информация о системе:
Версия ОС: Astra Linux 1.7.7.
Версия Debian: 10.0.

Информация о релизе:

Distributor ID: AstraLinux
Description:    Astra Linux 1.7 x86-64
Release:        1.7_x86-64
Codename:       1.7_x86-64

Выполняется проверка файлов...

Архив с временными файлами программы существует.
                                                                                                          OK
Файл журнала уже существует.
                                                                                                          OK

Когда программа удостоверится в наличии всех необходимых файлов запустится процесс создания сервисной учётной записи wisla.

Проверка учётной записи wisla...
Создаётся сервисная учётная запись wisla...
Задайте пароль для учётной записи пользователя wisla
Новый пароль :
Повторите ввод нового пароля :
passwd: пароль успешно обновлён
                                                                                                          OK

Если учётной записи wisla не существует в системе, тогда она будет создана и вы увидите запрос на создание пароля.

Информация

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

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

Обновление конфигурации системы...
                                                                                                          OK
Выполняется проверка каталога /home/wisla/.ssh...
Каталог /home/wisla/.ssh уже существует.
                                                                                                          OK
Выполняется проверка каталога /opt/wisla5...
Каталог /opt/wisla5 уже существует.
                                                                                                          OK
Извлечение временных файлов программы...
                                                                                                          OK
Найден файл установки ./wisla-5.2.11-2505210711.run.
Перемещение ./wisla-5.2.11-2505210711.run в каталог /home/wisla...
                                                                                                          OK        
Выполняется изменение прав доступа для каталога "/opt/wisla5"...
Права доступа обновлены успешно!
                                                                                                          OK
Выполняется изменение прав доступа для каталога "/home/wisla"...
Права доступа обновлены успешно!
                                                                                                          OK
Запуск сессии под пользователем wisla...
                                                                                                          OK

На этом этапе программа проверит наличие стандартной записи 127.0.1.1 в /etc/hosts,

Выполняется проверка сетевого адреса для wisla...
                                                                                                          OK

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

Когда на сервере несколько активных сетевых интерфейсов будет предложено выбрать нужный:

Выполняется проверка сетевого адреса для wisla...
Выберите сетевой интерфейс из списка:
1) eth0 | 10.0.0.45/26
2) eth1 | 10.0.0.46/26
#? 1
                                                                                                          WARNING
IP-адрес для wisla изменён на 10.0.0.45.

На шаге с настройкой имени узла будет выведено текущее имя сервера и основной IP-адрес, который будет использоваться системой мониторинга wiSLA 5:

Пожалуйста проверьте имя узла перед тем как продолжить!

Если имя узла задано верно, тогда укажите значение "н" и нажмите на клавишу Enter чтобы продолжить настройку.
В ином случае укажите значение "д" и задайте верное имя узла (hostname).

При смене имени узла будьте предельно внимательны!
Если вы допустили ошибку нажмите сочетание клавиш CTRL + C чтобы прервать работу программы, затем запустите
её заново и повторите процесс настройки!

Текущее имя узла:

wisla | 192.168.159.136

Вы хотите изменить имя узла? (д/н):
н

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

Вы хотите изменить имя узла? (д/н):
н

Сохранено текущее имя узла wisla.

В ином случае передайте значение д, затем нажмите клавишу Enter и укажите нужное имя узла как показано на примере ниже.

При смене имени узла будьте предельно внимательны!
Если вы допустили ошибку нажмите сочетание клавиш CTRL + C чтобы прервать работу программы, затем запустите её 
заново и повторите процесс настройки!

Текущее имя узла:

astra | 192.168.159.136

Вы хотите изменить имя узла? (д/н):
д
Задайте новое имя узла: wisla
Выполняется настройка...
                                                                                                                 OK
Новое имя узла wisla сохранено.
                                                                                                                 OK

На следующем шаге вам необходимо выбрать вариант установки пакетов.

Возможные варианты:

1. С доступом к сети интернет;
2. Без доступа к сети интернет (установка из бинарных файлов).

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

Перед тем как продолжить пожалуйста ознакомтесь с официальной документацией!

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

    1) С доступом к сети интернет;
    2) Без доступа к сети интернет.

Чтобы выйти из программы нажмите сочетание клавиш CTRL + C.

Укажите нужное значение (1/2) и нажмите на клавишу Enter:
1

Обратите внимание!

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

Укажите нужное значение и нажмите клавишу Enter, в данном примере был выбран вариант с доступом к сети интернет.

Выбран вариант установки с подключением к сети интернет.
Обновление кэша репозиториев...
Системе отправлена команда:
sudo apt-get update
Игн:1 http://download.astralinux.ru/astra/stable/1.7_x86-64/repository-main 1.7_x86-64 InRelease
Сущ:2 http://download.astralinux.ru/astra/stable/1.7_x86-64/repository-update 1.7_x86-64 InRelease
Сущ:3 http://download.astralinux.ru/astra/stable/1.7_x86-64/repository-base 1.7_x86-64 InRelease
Сущ:4 http://download.astralinux.ru/astra/stable/1.7_x86-64/repository-extended 1.7_x86-64 InRelease
Сущ:5 http://download.astralinux.ru/astra/stable/1.7_x86-64/uu/last/repository-update 1.7_x86-64 InRelease
Сущ:6 http://download.astralinux.ru/astra/stable/1.7_x86-64/repository-main 1.7_x86-64 Release
Чтение списков пакетов…
Кэш репозиториев обновлён успешно.
                                                                                                                 OK

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

Проверка на наличие неудовлетворённых зависимости...
Системе отправлена команда:
sudo apt-get --fix-broken install -y
Чтение списков пакетов…
Построение дерева зависимостей…
Чтение информации о состоянии…
Обновлено 0 пакетов, установлено 0 новых пакетов, для удаления отмечено 0 пакетов, и 0 пакетов не обновлено.
Зависимости успешно исправлены.
                                                                                                                 OK

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

Информация

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

Обратите внимание на этап, связанный с установкой обновлений системы!
Вывод программы в терминале:

Выполняется установка обновлений...
Системе отправлена команда: sudo apt-get dist-upgrade -y
Чтение списков пакетов…
Построение дерева зависимостей…
Чтение информации о состоянии…
Расчёт обновлений…

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

В частности, в терминале не будет отображаться строка прогресс-бара и символы введённые с клавиатуры, когда высокоуровневый пакетный менеджер APT будет запрашивать варианты изменения файлов конфигурации.
Ниже представлен пример для файла /etc/pam.d/login:

Файл настройки «/etc/pam.d/login»
 ==> Изменён с момента установки (вами или сценарием).
 ==> Автор пакета предоставил обновлённую версию.
  Что нужно сделать? Есть следующие варианты:
   Y или I : установить версию, предлагаемую сопровождающим пакета
   N или O : оставить установленную на данный момент версию
      D    : показать различия между версиями
      Z    : запустить оболочку командной строки для проверки ситуации
 По умолчанию сохраняется текущая версия файла настройки.

Как правило, параметры остаются неизменными, поэтому просто нажмите клавишу Enter, чтобы пропустить этот шаг. Если вам необходимо ввести другое значение, убедитесь, что у вас включена английская раскладка клавиатуры и выключен CapsLock. Затем укажите нужный вариант и нажмите клавишу Enter, чтобы продолжить.

Указанное вами значение отобразится в терминале после того как программа продолжит установку обновлений:

Файл настройки «/etc/astra-syslog.conf»
 ==> Изменён с момента установки (вами или сценарием).
 ==> Автор пакета предоставил обновлённую версию.
  Что нужно сделать? Есть следующие варианты:
   Y или I : установить версию, предлагаемую сопровождающим пакета
   N или O : оставить установленную на данный момент версию
      D    : показать различия между версиями
      Z    : запустить оболочку командной строки для проверки ситуации
 По умолчанию сохраняется текущая версия файла настройки.
*** astra-syslog.conf (Y/I/N/O/D/Z) [по умолчанию N] ? N

Обратите внимание!

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

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

Удаление неиспользуемых пакетов...
Системе отправлена команда:
sudo apt-get autoremove -y
Чтение списков пакетов…
Построение дерева зависимостей…
Чтение информации о состоянии…
Следующие пакеты будут УДАЛЕНЫ:
  libgdk-pixbuf-xlib-2.0-0 libgdk-pixbuf2.0-0 libllvm11 libmariadb3 libsnmp30
  libxcb-util0 mariadb-common mysql-common
Обновлено 0 пакетов, установлено 0 новых пакетов, для удаления отмечено 8 пакетов, и 0 пакетов не обновлено.
После данной операции объём занятого дискового пространства уменьшится на 90,4 MB.
(Чтение базы данных … на данный момент установлено 129684 файла и каталога.)
Удаляется libgdk-pixbuf2.0-0:amd64 (2.40.2-2+b1) …
Удаляется libgdk-pixbuf-xlib-2.0-0:amd64 (2.40.2-2+b1) …
Удаляется libllvm11:amd64 (1:11.0.1-2+b1) …
Удаляется libsnmp30:amd64 (5.7.3+dfsg-5+deb10u4) …
Удаляется libmariadb3:amd64 (1:10.3.39-0+deb10u2) …
Удаляется libxcb-util0:amd64 (0.3.8-3) …
Удаляется mariadb-common (1:10.3.39-0+deb10u2) …
update-alternatives: используется /etc/mysql/my.cnf.fallback для предоставления /etc/mysql/my.cnf (my.cnf) в
автоматическом режиме
Удаляется mysql-common (5.8+1.0.5) …
Обрабатываются триггеры для libc-bin (2.28-10+deb10u3+ci202406111043+astra10) …
Неиспользуемые пакеты успешно удалены.
                                                                                                                 OK

Затем будут установлены утилиты необходимые для работы системы wiSLA 5:

Выполняется установка необходимых пакетов...
Выполняется установка пакета: ntp
Системе отправлена команда:
sudo apt-get install -y ntp
Чтение списков пакетов…
Построение дерева зависимостей…
Чтение информации о состоянии…
Уже установлен пакет ntp самой новой версии (1:4.2.8p15+dfsg-1+ci202401221606+astra2).
Обновлено 0 пакетов, установлено 0 новых пакетов, для удаления отмечено 0 пакетов, и 0 пакетов не обновлено.
Пакет ntp установлен успешно.
                                                                                                                 OK
...

Выполняется установка пакета: iperf
Системе отправлена команда:
sudo apt-get install -y iperf
Чтение списков пакетов…
Построение дерева зависимостей…
Чтение информации о состоянии…
Уже установлен пакет iperf самой новой версии (2.0.12+dfsg1-2+b1).
Обновлено 0 пакетов, установлено 0 новых пакетов, для удаления отмечено 0 пакетов, и 0 пакетов не обновлено.
Пакет iperf установлен успешно.
                                                                                                                 OK

Выполняется изменение прав доступа для каталога "/home/wisla"...
Права доступа обновлены успешно!
                                                                                                                 OK
Извлечение временных файлов из архива...
                                                                                                                 OK
Выполняется установка необходимых пакетов из "./wisla-pkgs/astra-1-7/onlinst"...

Системе отправлена команда:
sudo dpkg -i --force-all ./wisla-pkgs/astra-1-7/onlinst/lnav_0.8.4-5_amd64.deb
(Чтение базы данных … на данный момент установлено 122453 файла и каталога.)
Подготовка к распаковке …/onlinst/lnav_0.8.4-5_amd64.deb …
Распаковывается lnav (0.8.4-5) на замену (0.8.4-5) …
Настраивается пакет lnav (0.8.4-5) …
Обрабатываются триггеры для man-db (2.8.5-2+b1) …

Системе отправлена команда:
sudo dpkg -i --force-all ./wisla-pkgs/astra-1-7/onlinst/pv_1.6.6-1_amd64.deb
(Чтение базы данных … на данный момент установлено 122453 файла и каталога.)
Подготовка к распаковке …/onlinst/pv_1.6.6-1_amd64.deb …
Распаковывается pv (1.6.6-1) на замену (1.6.6-1) …
Настраивается пакет pv (1.6.6-1) …
Обрабатываются триггеры для man-db (2.8.5-2+b1) …
                                                                                                                 WARNING
Выполняется попытка исправления зависимостей...
Чтение списков пакетов…
Построение дерева зависимостей…
Чтение информации о состоянии…
Обновлено 0 пакетов, установлено 0 новых пакетов, для удаления отмечено 0 пакетов, и 0 пакетов не обновлено.
Необходимые пакеты были успешно установлены.
                                                                                                                 OK
Программа выполняет удаление временных файлов, пожалуйста подождите...
Временные файлы были удалены.
                                                                                                                 OK

На следующем этапе программа проверит статус сетевого фильтра ufw или firewalld и добавит правила необходимые для корректной работы системы мониторинга:

Выполняется добавление правил для фильтрации пакетов...
Сетевой фильтр UFW установлен.
                                                                                                                 OK
Сетевой фильтр UFW неактивен!
                                                                                                                 WARNING
Правила фильтрации успешно добавлены.
                                                                                                                 OK

Обратите внимание!

Программа добавит правила, даже если сетевой фильтр отключен. Данный подход должен обеспечить бесперебойную работы системы wiSLA 5 при включении сетевого фильтра в будущем.

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

1. 22/TCP — OpenSSH-сервер;

2. 8080/TCP — HTTP-порт сервера Wildfly;
3. 8443/TCP — HTTPS-порт сервера Wildfly;
4. 8787/UDP и 10862/UDP — для работы программного агента Slamon.

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

Проверка состояния службы openssh-server...
Служба openssh-server уже запущена.
                                                                                                                 OK
Добавление службы openssh-server в автозагрузку...
Служба openssh-server добавлена в автозагрузку.
                                                                                                                 OK

Обновив конфигурацию автозагрузки службы ssh программа сгенерирует SSH-ключ для пользователя wisla и запросит пароль.

Выполняется генерация SSH-ключа...
Generating public/private rsa key pair.
Your identification has been saved in /home/wisla/.ssh/id_rsa
Your public key has been saved in /home/wisla/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:CkwRXSK/K1EkRDKUakPcynkZM3ATT02Mk9/xgZpjfFU wisla@wisla
The key's randomart image is:
+---[RSA 3072]----+
|.o*BO+Oo. . .E   |
| ooB+X.+ o o     |
|o.o *.* + + .    |
|.* = . O o .     |
|. o + o S        |
|     o o         |
|    . o          |
|     .           |
|                 |
+----[SHA256]-----+

Сгенерирован SSH-ключ для пользователя wisla, узел wisla.
                                                                                                                 OK
Введите пароль для пользователя wisla чтобы продолжить.
Введите пароль:

Укажите пароль от учётной записи wisla, заданный ранее на этапе создания данного пользователя и нажмите на клавишу Enter, чтобы записать его на сервер.

Обратите внимание!

Если вы ранее вручную сгенерировали SSH-ключ для пользователя wisla он будет удалён и записан на сервер заново. Данный подход используется для предотвращения возможных проблем с уже существующими записями в файле known_hosts.

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

Настройка беспарольного подключения по SSH...

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh -o 'StrictHostKeyChecking=no' 'wisla@localhost'"
and check to make sure that only the key(s) you wanted were added.

                                                                                                                 OK
Проверка подключения к localhost...
Подключение к localhost выполнено успешно.
                                                                                                                 OK

/usr/bin/ssh-copy-id: WARNING: All keys were skipped because they already exist on the remote system.
                (if you think this is a mistake, you may want to use -f option)

                                                                                                                 OK
Проверка подключения к wisla...
Подключение к wisla выполнено успешно.
                                                                                                                 OK

После настройки беспарольного подключения программа изменит основную версию языка программирования python3 для корректной работы инсталлятора wiSLA 5 и проверит его наличие в домашнем каталоге пользователя wisla.

Изменение основной версии python3...
Основная версия python3 успешно изменена.
                                                                                                                 OK

Если вы загрузили на сервер все три файла (архив с файлами программы, программу и инсталлятор wiSLA 5) будет произведено обновление прав доступа на инсталлятор для сервисной учётной записи wisla.

Найден файл установки ./wisla-5.2.11-2505210711.run.
Добавление прав на выполнение...
                                                                                                                 OK

Следующий шаг будет отличаться в зависимости от ОС, где была запущена программа.

Нажмите на блок с вашей ОС чтобы ознакомится с информацией:

Выполняется настройка локализации...
Generating locales (this might take a while)...
  ru_RU.UTF-8... done
Generation complete.
Параметры локализации были обновлены.
                                                                                                                 OK
Generating locales (this might take a while)...
  ru_RU.UTF-8... done
Generation complete.
                                                                                                                 OK
Вы хотите ознакомиться с журналом программы? (д/н): д
Выберите программу для чтения журнала:
1) tail
2) less
3) lnav
Укажите подходящий вариант (1/2/3): 1

Выполняется чтение журнала с помощью tail...

16:02:51 [INFO] Ср 13 ноя 2024 16:02:51 MSK
16:02:51 [INFO] Запущена программа предварительной настройки узла wisla.
16:02:51 [INFO] Версия программы: 1.8.1.
16:02:51 [INFO] Версия ОС: Debian 12.7
16:02:51 [INFO] Файл /home/wisla/wisla-pkgs.zip существует.
16:03:12 [INFO] Выбран вариант установки с подключением к сети интернет.
16:03:16 [INFO] Кэш репозиториев обновлён успешно.
16:03:16 [INFO] Зависимости успешно исправлены.
16:04:40 [INFO] Обновление пакетов выполнено успешно.
16:04:41 [INFO] Неиспользуемые пакеты успешно удалены.
16:04:41 [INFO] Запущен механизм установки необходимых пакетов.
16:04:47 [INFO] Пакет ntp установлен успешно.
16:04:49 [INFO] Пакет pv установлен успешно.
16:04:52 [INFO] Пакет uuid установлен успешно.
16:04:56 [INFO] Пакет ntpdate установлен успешно.
16:04:56 [INFO] Пакет libsodium23 установлен успешно.
16:04:57 [INFO] Пакет liblzo2-2 установлен успешно.
16:05:00 [INFO] Пакет dialog установлен успешно.
16:05:03 [INFO] Пакет rsync установлен успешно.
16:05:03 [INFO] Пакет zip установлен успешно.
16:05:04 [INFO] Пакет unzip установлен успешно.
16:05:04 [INFO] Пакет wget установлен успешно.
16:05:04 [INFO] Пакет tar установлен успешно.
16:05:04 [INFO] Пакет python3 установлен успешно.
16:05:11 [INFO] Пакет python3-paramiko установлен успешно.
16:05:13 [INFO] Пакет python3-asn1crypto установлен успешно.
16:05:13 [INFO] Пакет python3-bcrypt установлен успешно.
16:05:14 [INFO] Пакет python3-cffi-backend установлен успешно.
16:05:14 [INFO] Пакет python3-cryptography установлен успешно.
16:05:14 [INFO] Пакет python3-nacl установлен успешно.
16:05:15 [INFO] Пакет fontconfig установлен успешно.
16:05:15 [INFO] Пакет curl установлен успешно.
16:05:46 [INFO] Пакет glusterfs-client установлен успешно.
16:05:59 [INFO] Пакет glusterfs-server установлен успешно.
16:06:01 [INFO] Пакет sshpass установлен успешно.
16:06:05 [INFO] Пакет ncat установлен успешно.
16:06:07 [INFO] Пакет net-tools установлен успешно.
16:06:10 [INFO] Пакет libpcrecpp0v5 установлен успешно.
16:06:12 [INFO] Пакет iperf установлен успешно.
16:06:13 [INFO] Пакет neofetch установлен успешно.
16:06:13 [INFO] Пакет lnav установлен успешно.
16:06:13 [INFO] Основная версия python3 была изменена.
16:06:13 [INFO] Сетевой фильтр UFW уже установлен в системе.
16:06:13 [INFO] Текущее состояние сетевого фильтра UFW: active
16:06:13 [INFO] Сетевой фильтр UFW активен.
16:06:13 [INFO] Добавлено правило для порта 8443 с протоколом tcp.
16:06:13 [INFO] Добавлено правило для порта 8080 с протоколом tcp.
16:06:14 [INFO] Добавлено правило для порта 443 с протоколом tcp.
16:06:14 [INFO] Добавлено правило для порта 22 с протоколом tcp.
16:06:14 [INFO] Добавлено правило для порта 8787 с протоколом udp.
16:06:14 [INFO] Добавлено правило для порта 10862 с протоколом udp.
16:06:14 [WARNING] Каталог /opt/wisla5 не найден!
16:06:14 [INFO] Создан общий каталог /opt/wisla5.
16:06:14 [INFO] Обновлены права доступа на каталог "/opt/wisla5" для пользователя "wisla".
16:06:14 [WARNING] Каталог /home/wisla/.ssh не найден!
16:06:14 [INFO] Создан общий каталог /home/wisla/.ssh.
16:06:14 [INFO] Обновлены права доступа на каталог "/home/wisla/.ssh" для пользователя "wisla".
16:06:15 [INFO] Сгенерирован SSH-ключ для пользователя wisla, узел wisla.
16:06:28 [INFO] Ключ успешно скопирован на узел wisla.
16:06:28 [INFO] Файл /etc/sudoers.d/wisla был обновлён.
16:06:28 [INFO] Файл /etc/security/limits.d/wisla был обновлён.
16:06:29 [INFO] Параметры локализации были обновлены.

Работа программы завершена.

Выполняется настройка локализации...
Generating locales (this might take a while)...
  ru_RU.ISO-8859-5... done
Generation complete.
                                                                                                                 OK
Generating locales (this might take a while)...
  ru_RU.UTF-8... done
Generation complete.
Параметры локализации были обновлены.
                                                                                                                 OK

Вы хотите ознакомиться с журналом программы? (д/н): д
Выберите программу для чтения журнала:
1) tail
2) less
3) lnav
Укажите подходящий вариант (1/2/3): 1

Выполняется чтение журнала с помощью tail...

13:31:12 [INFO] Ср 13 ноя 2024 13:31:12 UTC
13:31:12 [INFO] Запущена программа предварительной настройки узла template-ubuntu.
13:31:12 [INFO] Версия программы: 1.8.1.
13:31:12 [INFO] Версия ОС: Ubuntu 24.04.1 LTS
13:31:12 [INFO] Файл /home/wisla/wisla-pkgs.zip существует.
13:31:15 [INFO] Выбран вариант установки с подключением к сети интернет.
13:31:24 [INFO] Кэш репозиториев обновлён успешно.
13:31:24 [INFO] Зависимости успешно исправлены.
13:35:03 [INFO] Обновление пакетов выполнено успешно.
13:36:36 [INFO] Неиспользуемые пакеты успешно удалены.
13:36:36 [INFO] Запущен механизм установки необходимых пакетов.
13:36:41 [INFO] Пакет sntp установлен успешно.
13:36:44 [INFO] Пакет pv установлен успешно.
13:36:49 [INFO] Пакет uuid установлен успешно.
13:36:54 [INFO] Пакет ntpdate установлен успешно.
13:36:54 [INFO] Пакет libsodium23 установлен успешно.
13:36:54 [INFO] Пакет liblzo2-2 установлен успешно.
13:36:58 [INFO] Пакет dialog установлен успешно.
13:36:59 [INFO] Пакет rsync установлен успешно.
13:36:59 [INFO] Пакет zip установлен успешно.
13:37:00 [INFO] Пакет unzip установлен успешно.
13:37:00 [INFO] Пакет wget установлен успешно.
13:37:00 [INFO] Пакет tar установлен успешно.
13:37:01 [INFO] Пакет python3 установлен успешно.
13:37:04 [INFO] Пакет python3-paramiko установлен успешно.
13:37:07 [INFO] Пакет python3-asn1crypto установлен успешно.
13:37:07 [INFO] Пакет python3-bcrypt установлен успешно.
13:37:08 [INFO] Пакет python3-cffi-backend установлен успешно.
13:37:08 [INFO] Пакет python3-cryptography установлен успешно.
13:37:09 [INFO] Пакет python3-nacl установлен успешно.
13:37:09 [INFO] Пакет fontconfig установлен успешно.
13:37:09 [INFO] Пакет curl установлен успешно.
13:37:21 [INFO] Пакет glusterfs-client установлен успешно.
13:37:33 [INFO] Пакет glusterfs-server установлен успешно.
13:37:37 [INFO] Пакет sshpass установлен успешно.
13:37:45 [INFO] Пакет ncat установлен успешно.
13:37:49 [INFO] Пакет net-tools установлен успешно.
13:37:54 [INFO] Пакет libpcrecpp0v5 установлен успешно.
13:37:58 [INFO] Пакет iperf установлен успешно.
13:37:58 [INFO] Пакет neofetch установлен успешно.
13:37:58 [INFO] Пакет lnav установлен успешно.
13:37:59 [INFO] Пакет locales установлен успешно.
13:37:59 [INFO] Основная версия python3 была изменена.
13:37:59 [INFO] Сетевой фильтр UFW уже установлен в системе.
13:37:59 [INFO] Текущее состояние сетевого фильтра UFW: inactive
13:37:59 [INFO] Сетевой фильтр UFW неактивен.
13:37:59 [INFO] Добавлено правило для порта 8443 с протоколом tcp.
13:37:59 [INFO] Добавлено правило для порта 8080 с протоколом tcp.
13:37:59 [INFO] Добавлено правило для порта 443 с протоколом tcp.
13:37:59 [INFO] Добавлено правило для порта 22 с протоколом tcp.
13:37:59 [INFO] Добавлено правило для порта 8787 с протоколом udp.
13:37:59 [INFO] Добавлено правило для порта 10862 с протоколом udp.
13:37:59 [WARNING] Каталог /opt/wisla5 не найден!
13:37:59 [INFO] Создан общий каталог /opt/wisla5.
13:37:59 [INFO] Обновлены права доступа на каталог "/opt/wisla5" для пользователя "wisla".
13:37:59 [INFO] Каталог /home/wisla/.ssh существует.
13:37:59 [INFO] Обновлены права доступа на каталог "/home/wisla/.ssh" для пользователя "wisla".
13:38:01 [INFO] Сгенерирован SSH-ключ для пользователя schipper, узел template-ubuntu.
13:40:35 [INFO] Ключ успешно скопирован на узел template-ubuntu.
13:40:35 [INFO] Файл /etc/sudoers.d/wisla был обновлён.
13:40:35 [INFO] Файл /etc/security/limits.d/wisla был обновлён.
13:40:36 [INFO] Параметры локализации были обновлены.

Работа программы завершена.

Отключение опции KillUserProcesses...
Опция KillUserProcesses отключена.
                                                                                                          OK
Отключение мандатного контроля...
Мандатный контроль отключен.
                                                                                                          OK
Создаётся unit systemd для wiSLA 5...
Обновление конфигурации демонов...
                                                                                                          OK
Systemd unit создан успешно.
                                                                                                          OK

Вы хотите ознакомиться с журналом программы? (д/н): д
Выберите программу для чтения журнала:
1) tail
2) less
3) lnav
Укажите подходящий вариант (1/2/3): 1

Выполняется чтение журнала с помощью tail...

14:14:45 [INFO] Пн мая 26 14:14:45 MSK 2025
14:14:45 [INFO] Запущена программа предварительной настройки узла wisla.
14:14:45 [INFO] Версия ОС: Astra Linux 1.7.7
14:14:45 [INFO] Версия Debian: 10.0
14:14:45 [WARNING] Файл /etc/sudoers.d/wisla был удалён.
14:14:46 [INFO] Создан файл конфигурации /etc/sudoers.d/wisla.
14:14:46 [INFO] Файл "/etc/sudoers.d/wisla" был обновлён.
14:14:46 [WARNING] Файл /etc/security/limits.d/wisla был удалён.
14:14:46 [INFO] Создан файл конфигурации /etc/security/limits.d/wisla.
14:14:46 [INFO] Файл "/etc/security/limits.d/wisla" был обновлён.
14:14:46 [WARNING] Файл /etc/logrotate.d/wisla был удалён.
14:14:46 [INFO] Создан файл конфигурации /etc/logrotate.d/wisla.
14:14:46 [INFO] Файл "/etc/logrotate.d/wisla" был обновлён.
14:14:46 [WARNING] Файл /etc/logrotate.d/zookeeper был удалён.
14:14:46 [INFO] Создан файл конфигурации /etc/logrotate.d/zookeeper.
14:14:46 [INFO] Файл "/etc/logrotate.d/zookeeper" был обновлён.
14:14:46 [WARNING] Файл /etc/logrotate.d/hadoop был удалён.
14:14:46 [INFO] Создан файл конфигурации /etc/logrotate.d/hadoop.
14:14:46 [INFO] Файл "/etc/logrotate.d/hadoop" был обновлён.
14:14:46 [WARNING] Файл /etc/logrotate.d/hbase был удалён.
14:14:46 [INFO] Создан файл конфигурации /etc/logrotate.d/hbase.
14:14:46 [INFO] Файл "/etc/logrotate.d/hbase" был обновлён.
14:14:46 [WARNING] Файл /etc/logrotate.d/postgres был удалён.
14:14:46 [INFO] Создан файл конфигурации /etc/logrotate.d/postgres.
14:14:46 [INFO] Файл "/etc/logrotate.d/postgres" был обновлён.
14:14:46 [WARNING] Файл /etc/logrotate.d/wildfly был удалён.
14:14:46 [INFO] Создан файл конфигурации /etc/logrotate.d/wildfly.
14:14:46 [INFO] Файл "/etc/logrotate.d/wildfly" был обновлён.
14:14:46 [INFO] Каталог /home/wisla/.ssh существует.
14:14:46 [INFO] Каталог /opt/wisla5 существует.
14:14:47 [INFO] Файл установки ./wisla-5.2.11-2505210711.run перемещён в каталог /home/wisla..
14:14:47 [INFO] Обновлены права доступа на каталог "/opt/wisla5" для пользователя "wisla".
14:14:47 [INFO] Обновлены права доступа на каталог "/home/wisla" для пользователя "wisla".
14:18:39 [INFO] Выбран вариант установки с подключением к сети интернет.
14:18:40 [INFO] Кэш репозиториев обновлён успешно.
14:18:40 [INFO] Зависимости успешно исправлены.
14:18:40 [INFO] Обновление пакетов выполнено успешно.
14:18:40 [INFO] Неиспользуемые пакеты успешно удалены.
14:18:40 [INFO] Запущен механизм установки необходимых пакетов.
14:18:40 [INFO] Пакет ntp установлен успешно.
14:18:41 [INFO] Пакет uuid установлен успешно.
14:18:41 [INFO] Пакет ntpdate установлен успешно.
14:18:41 [INFO] Пакет libsodium23 установлен успешно.
14:18:41 [INFO] Пакет liblzo2-2 установлен успешно.
14:18:41 [INFO] Пакет dialog установлен успешно.
14:18:41 [INFO] Пакет rsync установлен успешно.
14:18:41 [INFO] Пакет zip установлен успешно.
14:18:41 [INFO] Пакет unzip установлен успешно.
14:18:42 [INFO] Пакет wget установлен успешно.
14:18:42 [INFO] Пакет tar установлен успешно.
14:18:42 [INFO] Пакет python3 установлен успешно.
14:18:42 [INFO] Пакет python3-paramiko установлен успешно.
14:18:42 [INFO] Пакет python3-asn1crypto установлен успешно.
14:18:42 [INFO] Пакет python3-bcrypt установлен успешно.
14:18:42 [INFO] Пакет python3-cffi-backend установлен успешно.
14:18:42 [INFO] Пакет python3-cryptography установлен успешно.
14:18:42 [INFO] Пакет python3-nacl установлен успешно.
14:18:43 [INFO] Пакет fontconfig установлен успешно.
14:18:43 [INFO] Пакет curl установлен успешно.
14:18:43 [INFO] Пакет sshpass установлен успешно.
14:18:43 [INFO] Пакет ncat установлен успешно.
14:18:43 [INFO] Пакет netcat установлен успешно.
14:18:43 [INFO] Пакет libpcrecpp0v5 установлен успешно.
14:18:43 [INFO] Запущен механизм установки пакетов для Astra Linux.
14:18:45 [INFO] Сетевой фильтр UFW уже установлен в системе.
14:18:45 [INFO] Текущее состояние сетевого фильтра UFW: inactive
14:18:45 [INFO] Сетевой фильтр UFW неактивен.
14:18:45 [INFO] Добавлено правило для порта 22 с протоколом tcp.
14:18:45 [INFO] Добавлено правило для порта 8080 с протоколом tcp.
14:18:46 [INFO] Добавлено правило для порта 8443 с протоколом tcp.
14:18:46 [INFO] Добавлено правило для порта 8787 с протоколом udp.
14:18:46 [INFO] Добавлено правило для порта 10862 с протоколом udp.
14:18:46 [INFO] Сервис openssh-server уже активен.
14:18:47 [INFO] systemd unit для сервиса openssh-server создан успешно.
14:18:47 [INFO] Сгенерирован SSH-ключ для пользователя wisla, узел wisla.
14:18:58 [INFO] Ключ успешно скопирован на узел localhost.
14:18:59 [INFO] Ключ успешно скопирован на узел wisla.
14:18:59 [INFO] Основная версия python3 была изменена.
14:18:59 [INFO] Опция KillUserProcesses была отключена.
14:19:05 [INFO] Мандатный контроль отключен.
14:19:05 [WARNING] Файл /etc/systemd/system/wisla.service был удалён.
14:19:05 [INFO] Создан файл конфигурации /etc/systemd/system/wisla.service.
14:19:05 [INFO] Файл "/etc/systemd/system/wisla.service" был обновлён.
14:19:15 [INFO] Перезагрузка сервера не выполнена.
14:19:15 [INFO] Файл установки ./wisla-5.2.11-2505210711.run сделан исполняемым.
14:19:18 [INFO] Временные файлы были успешно удалены.
14:19:18 [INFO] Предварительная настройка узла wisla завершена.

Вы хотите перезагрузить сервер? (д/н): д
Отправлена команда на перезагрузку сервера...
                                                                                                          OK
Программа выполняет удаление временных файлов, пожалуйста подождите...
Временные файлы были удалены.
                                                                                                          OK
Работа программы завершена.

Remote side unexpectedly closed network connection

Выполняется настройка SELinux...
Конфигурация SELinux обновлена успешно.
                                                                                                                 OK
Отключение SELinux...
SELinux отключен.
                                                                                                                 OK

Вы хотите ознакомиться с журналом программы? (д/н): д
Выберите программу для чтения журнала:
1) tail
2) less
3) lnav
Укажите подходящий вариант (1/2/3): 1

Выполняется чтение журнала с помощью tail...

21:01:27 [INFO] Пн 18 ноя 2024 21:01:27 MSK
21:01:27 [INFO] Запущена программа предварительной настройки узла wisla.
21:01:27 [INFO] Версия программы: 1.8.6.
21:01:27 [INFO] Версия ОС: RED OS release (8.0) DESKTOP
21:01:27 [INFO] Файл /home/wisla/wisla-pkgs.zip существует.
21:01:27 [INFO] Файл /home/wisla/servers.list существует.
21:01:30 [INFO] localhost доступен.
21:01:34 [INFO] wisla доступен.
21:01:40 [INFO] Выбран вариант установки без подключения к сети интернет.
21:01:40 [INFO] Обновлены права доступа на каталог "/home/wisla" для пользователя "wisla".
21:01:42 [INFO] Запущен механизм установки необходимых библиотек из бинарных файлов.
21:01:52 [INFO] Запущен механизм установки пакетов языка программирования python3 из бинарных файлов.
21:01:53 [INFO] Запущен механизм установки необходимых утилит из бинарных файлов.
21:02:00 [INFO] Временные файлы были успешно удалены.
21:02:00 [INFO] Основная версия python3 была изменена.
21:02:00 [ERROR] Сетевой фильтр firewalld не установлен или не активен!
21:02:00 [INFO] Каталог /opt/wisla5 существует.
21:02:00 [INFO] Обновлены права доступа на каталог "/opt/wisla5" для пользователя "wisla".
21:02:00 [INFO] Сервис openssh-server уже активен.
21:02:00 [INFO] systemd unit для сервиса openssh-server создан успешно.
21:02:00 [INFO] Каталог /home/wisla/.ssh существует.
21:02:00 [INFO] Обновлены права доступа на каталог "/home/wisla/.ssh" для пользователя "wisla".
21:02:03 [INFO] Сгенерирован SSH-ключ для пользователя wisla, узел wisla.
21:02:06 [INFO] Ключ успешно скопирован на localhost.
21:02:06 [INFO] Выполнено подключение к localhost с использованием ключа.
21:02:06 [INFO] Ключ успешно скопирован на wisla.
21:02:06 [INFO] Выполнено подключение к wisla с использованием ключа.
21:02:06 [INFO] Файл /etc/sudoers.d/wisla был обновлён.
21:02:07 [INFO] Файл /etc/security/limits.d/wisla был обновлён.
21:02:08 [INFO] Запущен процесс настройки арбитра GlusterFS.
21:02:08 [INFO] Каталог /mnt/gluster/namenode существует.
21:02:08 [INFO] Каталог /mnt/gfs/brick существует.
21:02:08 [INFO] Обновлены права доступа на каталог "/mnt/gluster/namenode" для пользователя "wisla".
21:02:08 [ERROR] Сетевой фильтр firewalld не установлен или не активен!
21:02:08 [INFO] Сервис glusterd запущен.
21:02:09 [INFO] systemd unit для сервиса glusterd создан успешно.
21:02:09 [INFO] Узел wisla добавлен в кластер GlusterFS в качестве свидетеля!
21:02:09 [INFO] Обновлена конфигурация SELinux.
21:02:09 [INFO] SELinux отключен.

Работа программы завершена.

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

Программа выполняет удаление временных файлов, пожалуйста подождите...
Временные файлы были удалены.
                                                                                                          OK
Работа программы завершена.

Завершив настройку узла можно удалить файлы программы предварительной настройки:

sudo rm -rf ./preparing-os.start ./preparing.tar /tmp/preparing-os.log

Удалив файлы программы можно перейти к установке системы мониторинга wiSLA 5.

Установка системы мониторинга wiSLA 5

1. Запуск программы установки

Завершив предварительную подготовку системы переключитесь на сервисную учётную запись wisla:

sudo su - wisla

sudo chmod +x ./wisla-5.2.*.run

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

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

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

Обратите внимание!

Программа установки должна запускаться под сервисной учётной записью и в её окружении, в данном примере это пользователь wisla.

Информация

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

Если установка системы будет аварийно прервана или завершена с ошибкой, журналы установки можно найти в каталоге с программой (install*.log, runtime.log). Информация о ходе установки также доступна в буфере эмулятора терминала.

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

./wisla-5.2.*.run

Если программа установки не стартует попробуйте выполнить export TERM=xterm перед её запуском.

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

Информация

Навигация в программе установки осуществляется с помощью стрелок управления курсором, клавиш Home, End, Tab, Esc и Enter.
Если требуется аварийно прервать работу программы, можно использовать комбинацию клавиш CTRL+C, для штатного завершения программы установки следует использовать кнопку Exit.

2. Работа с программой установки wiSLA 5

Во время установки в каталог /opt/wisla5 будут добавлены следующие компоненты:

• Zookeeper;
• Hadoop;
• HBase;
• PostgreSQL;
• Java Runtime Environment;
• WildFly Application Server;
• wiSLA Portal.

Процесс можно прервать, нажав CTRL+C, все настройки будут сброшены.

1. Окно "Installer startup configuration"

Проверьте параметры "Install master", при установке всех компонентов на один сервер его имя должно быть указано здесь.

2. Окно "Old installation was not found. Select an action"

Выберете вариант "Install" чтобы перейти к дальнейшей настройке. 

3. Окно "Topology configuration"

При установке на сервер в одном экземпляре необходимо указать его hostname для всех модулей системы, при работе в кластере необходимо указать полную топологию.

Задав топологию запустится процесс инициализации модулей.

4. Окно "Versions select"

Выберете нужную версию чтобы продолжить.

5. Окно "Zookeeper Configuration"

6. Окно "Hadoop configuration"

Проверьте имя hostname в "Hadoop cluster name" и порт, при развёртывании одного экземпляра укажите localhost.

7. Окно "HBase configuration"

Проверьте имя hostname в "Zookeeper quorum".

8. Окно "Postgresql configuration"

Нужно проверить и заполнить "Trusted network/host", иначе будут проблемы с подключением Postgresql и патчами.

* Чтобы принимать все подключения укажите значение all или 0.0.0.0/0.

9. Окно "Wildfly configuration"

Проверьте значение "Heap size", для локальной установки хватит стандартного значения 2048, при мониторинге инфраструктуры с большим числом устройств рекомендуется увеличить данное значение. При работе в кластере минимальное значение должно быть 8192.

10. Окно "wiSLA Topology Configuration"

11. Окно "wiSLA Data Collection Configuration"

Если планируется использование зондов wiProbe, нужно прокрутить список и изменить настройку «wiProbe destination». В ней задаётся адрес, который будет использоваться зондом для отправки данных в систему wiSLA, в форме URL. Остальные параметры менять без необходимости не рекомендуется.

12. Окно "wiSLA Resources Configuration"

Убедитесь, что имя hostname указано в URL.

13. Окно "wiSLA Notification and ASI Configuration"

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

Также здесь можно включить отправку SNMP-уведомлений по определённым событиям. 

14. Окно "wiSLA Cloud System"

15. Окно "Operator Portal Configuration"

Обратите внимание!

Если вы получаете доступ к порталу с помощью проброса портов или через прокси сервер, тогда вам необходимо отредактировать пункт HOST и в Whitelisted domains установить необходимые IP-адреса.

16. Окно "Confirm the installation"

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

17. Окно "Add wiSLA to the autorun list"

После установки системы будет предложено добавить службу в список автозагрузки, нажмите кнопку Yes, если вы установили её на Debian или Ubuntu.

sudo systemctl enable wisla.service

Система мониторинга wiSLA 5 установлена на ваш сервер.

3. Запуск wiSLA

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

less -f /opt/wisla5/wildfly/current/standalone/log/server.log
less -f /opt/wisla5/wildfly/current/standalone/log/communicator.log

Маркером успешного запуска является следующее сообщение в журнале (server.log):

INFO  [com.wellink.wisla.communicator.impl.state.AvailabilitySystemStateSingletonImpl] (http-0.0.0.0-0.0.0.0-8080-1) !***   THE ALL wiSLA
COMPONENTS ARE FULLY DEPLOYED, INTERCONNECTED AND READY TO WORK!   ***!
13:48:30,028 INFO  [com.wellink.wisla.communicator.impl.state.AvailabilitySystemStateSingletonImpl] (http-0.0.0.0-0.0.0.0-8080-1) !********************
**********************************************************************!

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

 
В данном примере система будет доступна по адресу https://wisla.it-superman.keenetic.pro.

Изменение одного или нескольких параметров wiSLA

Если требуется внести изменения в настройки уже установленной системы wiSLA, следует:

1. Запустить программу установки. Перейти в основное меню. Внешний вид основного меню показан на рисунке 27. 

   

   Рис. 27 Главное меню программы установки в случае обнаружения установленной wiSLA                                                                                                                                                

2. Выбрать пункт меню «Config update». Если этого пункта меню нет в списке, установка была
   выполнена некорректно или на первом экране при запуске программы установки были
   указаны ошибочные данные.
   
3. Найти, изменить требуемый параметр.
   
4. Выполнить перезапуск wiSLA.

Экранные формы хода установки (Работа с программой установки)

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

Внесение изменений в настройки работающей системы должно производиться через интерфейс программы установки. В этом случае они будут корректно внесены в соответствующие конфигурационные файлы системы и сохранены при обновлении системы. Программа установки должна выполняться от имени пользователя wisla и в его окружении. Для корректной работы программы не рекомендуется разворачивать окно на весь экран. Если установка wiSLA будет аварийно прервана или завершена с ошибкой, журналы установки можно найти в рабочем каталоге (install*.log, runtime.log). Информация о ходе установки также доступна в буфере эмулятора терминала.

Запуск программы установки

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

su -l wisla

2. Войти в каталог, куда была скопирована программа установки, и выполнить команду
запуска:

./wisla*.run

Должно открыться окно, показанное на рисунке 9

Рис. 9 Интерфейс программы установки: окно предварительных настроек

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

Навигация в программе установки осуществляется с помощью стрелок управления курсором, клавиш Home, End, Tab, Esc и Enter. Если требуется аварийно прервать работу программы, можно использовать комбинацию клавиш CTRL+C. Для штатного завершения программы установки следует использовать кнопку Exit. После выхода из программы установки экраны с историей выполнения доступны в буфере терминала.

Перечень действий для установки wiSLA

Ниже будут описаны действия для установки wiSLA на один сервер. В примере сервер будет назван VM1.

1. Запустить программу установки.

2. На первом экране принять предложенные настройки, нажав Enter. Программа установки проанализирует окружение. Если это первый запуск, откроется меню, показанное на рисунке 10.

Рис. 10 Интерфейс программы установки: меню при первом запуске

Из заголовка окна видно, что система не обнаружила установленной wiSLA на данном сервере. В описании к действию Install отображается версия, которая будет установлена, и номер сборки. Номер сборки на рисунке (цифры после «build») приведён на момент написания документа и может отличаться, так как любое изменение программного кода сопровождается пересборкой дистрибутива. Для перехода к следующему шагу нужно нажать Enter (выполнив тем самым действие «Next»), на выделенной строке «Install».

3. На следующем экране задаётся топология будущего контура wiSLA. В примере, показанном на рисунке 11, установка всех компонентов проводится на один сервер VM1. В зависимости от размера окна некоторые настройки могут оказаться вне области видимости. Для доступа к ним нужно последовательно нажимать кнопку «вниз». По достижении самой нижней строки настройки на уровне границы окна под настройкой появляется отметка «100%».

Настройка топологии выполняется один раз при первой установке системы. Впоследствии смена топологии через настройки программы установки не приведёт к желаемому результату (потребуется скорректировать ряд настроек вручную или выполнить установку «с нуля» с восстановлением данных из резервной копии), поэтому рекомендуется внимательно проверять введённые данные на данном этапе установки. После выполнения настроек переход к следующему экрану осуществляется кнопкой Next.

Если требуется распределить компоненты по разным серверам, нужно указать соответствующие доменные или сетевые имена серверов. В этом случае нужно, чтобы между серверами был организован беспарольный доступ по ключу (SSH) для пользователя wisla.

 ноды для апп серверов(сбор данных c slamon агентов)  можно сделать 6 штук + op,cont по 2 штуки 

Рис. 11 Интерфейс программы установки: топология

4. После задания топологии система может запросить пароль пользователя wisla. Это нужно для выполнения команды создания рабочего каталога в /opt, что требует привилегий sudo.
5. После создания рабочего каталога будет выполнена инициализация необходимых модулей и распаковка дистрибутива во временный каталог. Время ожидания зависит от производительности дисковой подсистемы сервера.
6. На следующем экране (рисунок 12) требуется выбрать версию и архитектуру Java Runtime Environment (как правило, используется архитектура x86_64, а версия представлена одна).

Рис.12 Интерфейс программы установки: выбор версии JRE

7. После распаковки и выбора версии JRE программа установки оценит параметры сервера и автоматически рассчитает значения по распределению оперативной памяти для различных компонентов системы. Впоследствии их можно будет изменить, однако это стоит делать только в том случае, когда администратору точно известно, что предложенные значения неоптимальны или ошибочны.
8. Настройка компонента Zookeper (рисунок 13). Рекомендуется оставить настройки, предложенные по умолчанию.

Рис.13 Интерфейс программы установки: настройки компонента Zookeeper

9. Настройка компонента Hadoop (рисунок 14). Рекомендуется оставить настройки, предложенные по умолчанию

Рис.14 Интерфейс программы установки: настройки компонента Hadoop

10. Настройка компонента HBase (рисунок 15). Рекомендуется оставить настройки, предложенные по умолчанию.

Рис.15 Интерфейс программы установки: настройки компонента HBase

11. Настройка компонента PostgreSQL (рисунок 16). Требуется прокрутить список настроек и изменить параметр «Trusted network/host». В примере сервер БД будет принимать все подключения от адресов 10.0.2.x. В случае неудачной настройки параметра установка wiSLA завершится ошибкой, так как сервер БД не сможет инициализировать БД.

Рис. 16 Интерфейс программы установки: настройки компонента PostgreSQL

12. Настройка компонента Wildfly (рисунок 17). Рекомендуется оставить настройки, предложенные по умолчанию.

Рис.17 Интерфейс программы установки: настройки сервера приложений Wildfly

13. Настройка топологии wiSLA. В примере все компоненты устанавливаются на сервер с именем VM1 (рисунок 18).

Рис. 18 Интерфейс программы установки: настройки топологии wiSLA

14. Настройки модуля сбора данных. Если планируется использование зондов wiProbe, нужно прокрутить список и изменить настройку «wiProbe destination». В ней задаётся адрес, который будет использоваться зондом для отправки данных в систему wiSLA, в форме URL (рисунок 19). Остальные параметры менять без необходимости не рекомендуется.

Рис. 19 Интерфейс программы установки: настройки модуля сбора данных

15. Настройки интеграции LDAP (в том числе, Active Directory), рисунок 20. Если LDAP не планируется использовать, рекомендуется оставить значения по умолчанию.

Рис. 20 Интерфейс программы установки: настройки интеграции LDAP

16. Настройки дополнительных ресурсов wiSLA. Рекомендуется оставить значения по умолчанию (рисунок 21).

При необходимости ограничения исторических данных рекомендуется изучить рисунок 21.1

Рис. 21 Интерфейс программы установки: настройки дополнительных ресурсов

a. "Store metrics data only for this period" - Данный параметр отвечает за период в течении которого будет осуществляться хранение данных. Указывается в днях. Стандартное значение не указано. Минимально возможное значение 0 дней. Дробные значения и значения <0 недопустимы.

Не рекомендуется устанавливать параметр "Store metrics data only for this period" = 0, в таком случае будут удалены все исторические данные показателей.

b. "Metrics eraser schedule period" - Данный параметр отвечает за периодичность запуска механизма удаления данных из нереляционной базы Hbase. Указывается в днях. Стандартное значение - 7 дней. Минимально возможное значение 1 день. Дробные значения и значения <0 недопустимы.

Не рекомендуется устанавливать параметр "Metrics eraser schedule period" = 0, в таком случае механизм удаления данных не будет запускаться.

*Реализована возможность гибкой настройки параметров удаления данных. Например, можно удалять данные раз в год, оставляя при этом данные за последний месяц (Значение для первого параметра = 30, для второго параметра = 365)  

Рис. 21.1. Экран инсталлятора wiSLA (Вкладка wiSLA Resources Configuration)

17. Настройка рассылки уведомлений (рисунок 22). На этом экране, как минимум, требуется указать параметры подключения к почтовому серверу. Если этого не сделать, новые пользователи не смогут получать письма о добавлении учётной записи и другие уведомления, отсылаемые на адрес электронной почты. Также здесь можно включить отправку SNMP-уведомлений по определённым событиям. Обязательные для настройки параметры перечислены в таблице 3.

Рис.22 Интерфейс программы установки: настройка рассылки уведомлений

Таблица 3 – Параметры подключения к почтовому серверу.

18. Настройки wiSLA.Cloud (рисунок 23) позволяют включить или выключить облачный режим системы wiSLA и выполнить его настройку. Подробно данный режим работы рассмотрен в разделе «Облачный режим wiSLA».

Рис. 23 Интерфейс программы установки: настройки wiSLA.Cloud

19. Настройки портала оператора (Рис. 24) позволяют настроить URL для работы системы и задать, сколько дней актуален сохранённый профиль пользователя (имеется в виду сохранение, которое проводится флажком «Запомнить меня» на портале).

Обращаем ваше внимание, если вы получаете доступ к порталу с помощью проброса портов или через прокси сервер, то вам необходимо отредактировать пункт HOST и в Whitelisted domains установить необходимые IP-адреса.

Рис. 24 Настройки портала оператора

20. Подтверждение настроек (рисунок 25). Программа установки отображает топологию. На этом этапе можно вернуться назад и внести забытые настройки. После подтверждения начинается процесс установки.

Рис.25 Интерфейс программы установки: просмотр топологии и подтверждение настроек

21. Если установка прошла удачно, программа выведет запрос на добавление сервиса wisla в автозагрузку. Данное действие возможно только в том случае, если пользователь wisla был добавлен в sudoers. В противном случае требуется отказаться от действия.

22. После установки система автоматически запускается. Ход запуска можно отслеживать в журналах работы (Logs viewer – wiSLA logs) и статусах (Status). Признаком успешного запуска является сообщение в журнале server.log, выделенное на рисунке 26. Для полного запуска новой системе без инфраструктуры обычно требуется до 5 минут.

Рис.26 Сообщение об успешном запуске системы wiSLA в communicator.log

23. После запуска сервера приложений можно начинать работу с порталом. По умолчанию в системе присутствует пользователь Administrator с паролем Admin@123. Зайдя с этими учётными данными, можно создать пользователя с ролью «Системный администратор», который сможет далее создавать инфраструктуру. Необходимо сменить пароль Administrator при первом входе в целях безопасности.
24. Если система в ходе установки добавлялась в список автозагрузки, рекомендуется выполнить пробный перезапуск сервера с целью проверки механизма автоматического запуска wiSLA.

Активация модуля автокорреляции

Для активации модуля автокорреляции необходимо:

Автокоррелятор wiCore должен быть установлен и запущен (см. Руководство администратора wiCore).

1. Запустить программу установки. Перейти в основное меню. Внешний вид основного меню показан на рисунке 1.

Рис. 1 Главное меню программы установки в случае обнаружения установленной wiSLA

2. Выбрать пункт меню «Config update». Если этого пункта меню нет в списке, установка была
выполнена некорректно или на первом экране при запуске программы установки были
указаны ошибочные данные.
3. Перейти на экран wiSLA Resources Configuration. 

За активацию автокоррелятора отвечают два параметра:

• Auto correlator url (по умолчанию значение locahost:8083),
• Enabling auto correlator (по умолчанию значение false).

Для активации:

• указать ссылку модуля автокорреляции "Auto correlator url" (доменное имя + порт, если в наличии),
• указать значение "Enabling auto correlator" как true.

4. Подтвердить настройки.

5. Выполнить перезапуск wiSLA.

Действия при неудачной попытке установки и восстановление работоспособности в случае сбоя

Действия при неудачной попытке установки wiSLA

В случае если установка wiSLA завершилась c ошибкой, требуется:

1. Проанализировать причину сбоя установки. Для этого можно использовать log-файлы программы установки в текущем каталоге, а также прокрутку в окне для просмотра хода установки.
2. Завершить все процессы, связанные с java.
3. Выйти из программы установки и удалить новые каталоги в /home/wisla (hadoop, hbase, postgresql, zookeeper).

Повторить попытку установки с исправленными настройками.

Регламент по восстановлению работоспособности системы wiSLA в случае сбоя

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

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

При возникновении одного или нескольких проявлений требуется провести первичную диагностику для установления причины сбоя (таблица 5).

Таблица 5 – Первичная диагностика и устранение проблемы.

Восстановление из backup

Система wisla использует 2 СУБД - Postgresql и Hbase.

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

Backup HBase DB - создает backup-файл hb_2024-01-09.tar.gz - в нем содержится информация о данных в HBase.

Restore HBase DB было переименовано в Restore HBase DB  into existing tables в версии 72115

Clear HBase DB tables and restore dump было переименовано в Restore HBase DB: clear and insert new tables в версии 72115

Restore HBase DB: clear and insert new tables / Clear HBase DB tables and restore dump(старое название) - очищает таблицы HBase и загружает данные из указанного backup-файла

Clear HBase DB tables - Очистить HBase таблицы и не восстанавливать backup

Restore HBase DB  into existing tables / Restore HBase DB(старое название) - восстанавливает данные в те же таблицы хранилища, не удаляя предыдущие данные. Этот режим нужен для восстановления из инкрементальных резервных копий, когда несколько файлов за разные периоды времени загружаются в одно хранилище.

Если использовать "Restore HBase DB  [into existing tables]" для разных наборов данных (например, при замене БД на alfa-test на базу заказчика), получаем испорченное хранилище и проблему запуска wiSLA. Для данных из разных источников нужно использовать режим "Restore HBase DB: clear and insert new tables": существующие таблицы будут переименованы и созданы новые, в них будут восстановлены данные.

Backup Postgres DB - создает backup-файл wisla_backup_2024_01_09.backup - в нем содержится информация о данных в Postgres.

Restore Postgres DB - загружает данные из указанного backup-файла

После успешного Restore Postgres рекомендуется выполнить пункт patch database из подменю Maintenance/Postgres

Backup installation info - создает архив INSTALLER_CONFIG_2024_01_09.tar с файлами CONFIG, APPLICATIONS,TOPOLOGY из папки конфигураций /opt/wisla5/current_version/

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

Действия по обслуживанию wiSLA

Основные действия по обслуживанию wiSLA перечислены в таблице 4.

Таблица 4 – Действия по обслуживанию системы wiSLA.

Установка wiSLA в контейнер podman

Установка wiSLA может быть произведена с помощью самораспаковывающегося архива.

Необходимо создать не root пользователя и настроить использование sudo без пароля 

Необходимые действия:

1)Установить podman и zstd

2)Скачать executable tarball

3)Задать  права для исполняемого файла 

chmod +x podmanizedWisla.sh

4)Запустить 

./podmanizedWisla.sh

5)Будет создан и запущен podman контейнер wisla-app

Имеется возможность управлять wiSLA с помощью systemd сервиса:

Проверить статус сервиса

systemctl --user status wisla-podman

Запустить сервис

systemctl --user start wisla-podman

Остановить сервис

systemctl --user stop wisla-podman

Дополнительно имеется возможность управлять wiSLA с помощью скрипта tool.sh (устанавливается в домашнюю папку пользователя)

изменить внешний хост с портом

./tool.sh change-external-host 10.9.0.1 80 443

изменить адрес для подключения зонда к wisla

./tool.sh change-wiprobe-dst 10.9.0.1 80

запустить скрипт wisla5.sh для остановки и запуска wisla (необходимо остановить перед остановкой контейнера)

./tool.sh wisla-script start

открыть логи application server и дождаться следующего сообщения

./tool.sh wisla-wildfly-log

запустить скрипт wisla5.sh для остановки и запуска wisla (необходимо остановить перед остановкой контейнера)

./tool.sh wisla-script stop

остановить контейнер

./tool.sh stop-container

запустить контейнер

./tool.sh start-container

Скрипты для взаимодействия с wiSLA

Поддерживаемые параметры установщика Wisla

Чтобы узнать доступные параметры установщика Wisla, выполнить команду:

./wisla-5.2.9-2502251017.run --help

Будет следующий вывод:

wiSLA 5.2.9 build 2502251017 installer
usage: ./wisla-5.2.9-2502251017.run <options>
This script installs the wiSLA system cluster.
OPTIONS:
    Installer options
    -h      Show this message
    -t      Text mode only
    --hadoop-install                        Install hadoop system only
    --silent-install                        Silent install
    --silent-update                         Silent update
    --silent-fast-update                    Silent update without backup stage
    --silent-fast-update-with-new-db <Postrgres DB dump path>  Silent update without backup stage with new database restoring
    --silent-fast-update-replace-db-n-hbase <Postgres DB dump path> <HBase data dump path>  Silent update without backup stage with complete data overwrite
    
    Package options
    -x      Unpack distribution from self
    -v      Display version information

ENVIRONMENT:
    INSTALL_TEMP - directory used to store temporary files. Default: /tmp/
    INSTALL_LOG  - installation log name. Default: install.YYYY-MM-dd_HH:mm:ss.log
    EXTERNAL_DISTRIBUTION_FILE - used to specify external distribution file
    SCENARIO - used to switch default scenario

Варианты обновления системы

1. Установка wisla с нуля

Убедиться что в системе отсутствуют установленные ранее папки : hadoop, postgresql, zookeeper, hbase. Иначе будет полуавтоматический режим установки, где необходимо будет подтверждать очистку каталогов, а при попытке нажать No процесс установки будет прерван.

./wisla-5.2.9-xxxxxxxx.run --silent-install

2. Стандартное обновление (с резервным копированием)

./wisla-5.2.9-xxxxxxxx.run --silent-update

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

3. Быстрое обновление без резервного копирования

./wisla-5.2.9-xxxxxxxx.run --silent-fast-update

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

4. Быстрое обновление с восстановлением новой базы данных PostgreSQL

./wisla-5.2.9-xxxxxxxx.run --silent-fast-update-with-new-db /path/to/postgres_dump.sql

Здесь /path/to/postgres_dump.sql — путь к файлу дампа PostgreSQL, который будет использован для восстановления данных.

5. Полная замена базы данных и HBase

./wisla-5.2.9-xxxxxxxx.run --silent-fast-update-replace-db-n-hbase /path/to/postgres_dump.sql /path/to/hbase_data

Где:

• /path/to/postgres_dump.sql — путь к дампу PostgreSQL.
• /path/to/hbase_data — путь к данным HBase.

6. Установка только Hadoop

./wisla-5.2.9-xxxxxxxx.run --hadoop-install

Дополнительно:

• Просмотр логов

По умолчанию логи установки сохраняются в файл install.YYYY-MM-dd_HH:mm:ss.log. Изменить имя лога можно так:

export INSTALL_LOG=my_install_log.txt

• Изменение временной директории

export INSTALL_TEMP=/custom/temp/dir

• Режим текстового интерфейса

./wisla-5.2.9-xxxxxxxx.run -t

Управление всеми сервисами Wisla

• Проверка статуса запущенных сервисов

/opt/wisla5/scripts/wisla5.sh status

• Остановка всех сервисов

/opt/wisla5/scripts/wisla5.sh stop

• Запуск всех сервисов

/opt/wisla5/scripts/wisla5.sh start

• Перезапуск всех сервисов

/opt/wisla5/scripts/wisla5.sh restart

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

• Проверка статуса запущенных сервисов

/opt/wisla5/scripts/wisla.sh status

• Остановка всех сервисов

/opt/wisla5/scripts/wisla.sh stop

• Запуск всех сервисов

/opt/wisla5/scripts/wisla.sh start

• Перезапуск сервиса Wisla

/opt/wisla5/scripts/wisla.sh restart

Скрипт:

#!/bin/bash

# Source function library.
WILDFLY_WORK=/opt/wisla5/wildfly/current
wildfly_pid_calc=$(pgrep -u wisla -f "jboss.home.dir=${WILDFLY_WORK}" | wc -l)

keyphrase_blank_wildfly_started="WildFly .* started in"

function start_blank_wildfly() {
	# анализ log-файла
	[ -r $WILDFLY_WORK/standalone/log/server.log ] && basic_blank_wildfly_started_counter=$(egrep -c "keyphrase_blank_wildfly_started" $WILDFLY_WORK/standalone/log/server.log)
	[ -z "basic_blank_wildfly_started_counter" ] && basic_blank_wildfly_started_counter=0
	# запуск пустого Wildfly
	cd $WILDFLY_WORK/bin
	nohup ./standalone.sh > /dev/null 2>&1&
}

function start_deploy() {
	cd $WILDFLY_WORK/standalone/deployments
	for file in *.?ar;
	do
		touch "$file".dodeploy
	done
}

function wait_for_blank_wildfly() {
    timeout=300
    blank_wildfly_counter_started=0
    blank_wildfly_current_counter_started=0
    if [ ! -e "$WILDFLY_WORK/standalone/log/server.log" ] ; then
        touch "$WILDFLY_WORK/standalone/log/server.log"
    fi
    basic_blank_wildfly_started_counter=$(egrep -c "$keyphrase_blank_wildfly_started" $WILDFLY_WORK/standalone/log/server.log)
    for i in $(seq 1 $timeout);
    do
	blank_wildfly_started_counter=$(egrep -c "$keyphrase_blank_wildfly_started" $WILDFLY_WORK/standalone/log/server.log)
	((total_wildfly_start_time = total_wildfly_start_time + 1))
	if [ $blank_wildfly_started_counter -eq $((basic_blank_wildfly_started_counter+1)) ]
	then
	    echo "Starting blank Wildfly..."
	    return
	fi
    sleep 1
    done
    echo "Error during blank Wildfly start!"
}

function start() {
	wildfly_pid_calc=$(pgrep -u wisla -f "jboss.home.dir=${WILDFLY_WORK}" | wc -l)
	if [ "$wildfly_pid_calc" -eq 0 ]
	then
		total_wildfly_start_time=0
		# очистка каталогов deployments (кроме war, ear) и tmp перед запуском
		find $WILDFLY_WORK/standalone/deployments -regextype posix-egrep ! -regex ".*(ear|war)" -type f -exec rm -f {} \;
		rm -rf $WILDFLY_WORK/standalone/tmp/*
		rm -rf /tmp/workspace_*-*-*-*-*
		cd $WILDFLY_WORK/standalone
		# запуск пустого wildfly
		echo "Waiting for the blank Wildfly application server to start (up to 5 minutes)... "
		start_blank_wildfly
		# ожидание запуска пустого Wildfly
		wait_for_blank_wildfly
		# начало деплоя артефактов (в порядке, выбранном Wildfly)
		start_deploy
	else
        echo "Error. Wildfly is already running!"
		return 1
	fi
}


function stop() {
    echo "wiSLA is stopping..."
    kill `pgrep -f "jboss.home.dir=${WILDFLY_WORK}"` &> /dev/null
    ATTEMPTS=0
    while [[ ! -z `pgrep -f "jboss.home.dir=${WILDFLY_WORK}"` ]]; do
        echo "Waiting for the Wildfly application server to stop..."
        (( ATTEMPTS = ATTEMPTS + 1 ))
        if [ $ATTEMPTS -gt 10 ]
            then
            echo "60 seconds is elapsed, trying to stop the process with -9 signal"
            kill -9 `pgrep -f "jboss.home.dir=${WILDFLY_WORK}"`
        fi
        sleep 5
    done
}

function status() {
    PID=`pgrep -f "jboss.home.dir=${WILDFLY_WORK}"`
    [[ ! -z $PID ]] && echo "Started with PID : $PID" || echo "Stopped"
}

case "$1" in
    start)
        start
        ;;
    stop)
        stop
        ;;
    restart)
        stop
        start
        ;;
    try-restart)
        stop
        start
        ;;
    status)
        status
        ;;
    *) exit 1
esac

exit 0

Реиндексация

• Стандартная реиндексация (требует запущенной системы)

/opt/wisla5/scripts/wi-reindex.sh

Скрипт:

#!/bin/bash
# Source function library.
JRE_WORK="/opt/wisla5/jre/current"

echo "Reindexing wisla engine lucene database..."
${JRE_WORK}/bin/java -jar /opt/wisla5/util/jmx/cmdline-jmxclient-0.10.3.jar - localhost:1090 "wisla-engine:name=nodeReindexer" reindexFullTextSearch

exit 0

• Независимая реиндексация (не зависит от состояния деплоя)

/opt/wisla5/scripts/wi-reindex-standalone.sh

Скрипт:

#!/bin/bash
# Source function library.
JRE_WORK="/opt/wisla5/jre/current"
POSTGRES_HOST="alfa-test"
DB_NAME="wisla"
USER="wisla"

echo "Reindexing database"
${JRE_WORK}/bin/java -jar -Dhibernate.connection.username="${USER}" \
-Dhibernate.search.base_indexes_directory="/opt/wisla5/wildfly/current/bin/searchindexes/engine/" \
-Dhibernate.connection.url="jdbc:postgresql://${POSTGRES_HOST}:5462/${DB_NAME}" \
-Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true \
/opt/wisla5/util/reindexer/wisla-reindexer.jar
echo "Reindex finished"
exit 0

Создание резервных копий баз данных

• PostgreSQL

Файл шаблона скрипта: /opt/wisla5/backup_scripts/postgres_backup_template.sh

Пример запуска резервного копирования:

pg_dump --host "wisla" --port 5432 --username "wisla" --format custom --blobs --no-owner --encoding UTF8 --verbose --file /home/wisla/backup/wisla.backup

Альтернативный способ через шаблонный скрипт:

sed "s|{{FILE-NAME}}|/home/wisla/backup/wisla.backup|" /opt/wisla5/backup_scripts/postgres_backup_template.sh | bash

Скрипт:

#!/bin/bash
pg_dump --host "alfa-test" --port 5432 --username "wisla" --format custom --blobs --no-owner --encoding UTF8 --verbose --file {{FILE-NAME}} wisla
ssh {{LOGIN}}@{{BACKUP-SERVER}} "mkdir -p {{DESTINATION}}"
scp ./{{FILE-NAME}} {{LOGIN}}@{{BACKUP-SERVER}}:{{DESTINATION}}
rm -f ./{{FILE-NAME}}

• HBase

Файл шаблона скрипта: /opt/wisla5/backup_scripts/hbase_backup_template.sh, но корректность работы проверить не удалось, пробовал  переписать скрипт, но возникает проблема при выполнении команды импорта снимков в папку.

#!/bin/bash

BACKUP_DIR=$(mktemp -d -t -p ~/ hbase_backup.XXXXXXXX)
mkdir ${BACKUP_DIR}/backup
BACKUP_PARRENT_DIR=${BACKUP_DIR}
BACKUP_DIR=${BACKUP_DIR}/backup

hbase org.apache.hadoop.hbase.mapreduce.Export -D mapred.output.compress=true {{TABLE-PREFIX}}-tsdb {{TABLE-PREFIX}}-tsdb-backup 1 {{START-TIMESTAMP}} {{END-TIMESTAMP}}
hbase org.apache.hadoop.hbase.mapreduce.Export -D mapred.output.compress=true {{TABLE-PREFIX}}-tsdb-uid {{TABLE-PREFIX}}-tsdb-uid-backup 1 {{START-TIMESTAMP}} {{END-TIMESTAMP}}
hbase org.apache.hadoop.hbase.mapreduce.Export -D mapred.output.compress=true {{TABLE-PREFIX}}-tsdb-nf {{TABLE-PREFIX}}-tsdb-nf-backup 1 {{START-TIMESTAMP}} {{END-TIMESTAMP}}
hbase org.apache.hadoop.hbase.mapreduce.Export -D mapred.output.compress=true {{TABLE-PREFIX}}-tsdb-uid-nf {{TABLE-PREFIX}}-tsdb-uid-nf-backup 1 {{START-TIMESTAMP}} {{END-TIMESTAMP}}
hbase org.apache.hadoop.hbase.mapreduce.Export -D mapred.output.compress=true {{TABLE-PREFIX}}-tsdb-lts {{TABLE-PREFIX}}-tsdb-lts-backup 1 {{START-TIMESTAMP}} {{END-TIMESTAMP}}

hdfs dfs -copyToLocal /user/wisla/{{TABLE-PREFIX}}-tsdb-backup ${BACKUP_DIR}/{{TABLE-PREFIX}}-tsdb
hdfs dfs -copyToLocal /user/wisla/{{TABLE-PREFIX}}-tsdb-uid-backup ${BACKUP_DIR}/{{TABLE-PREFIX}}-tsdb-uid
hdfs dfs -copyToLocal /user/wisla/{{TABLE-PREFIX}}-tsdb-nf-backup ${BACKUP_DIR}/{{TABLE-PREFIX}}-tsdb-nf
hdfs dfs -copyToLocal /user/wisla/{{TABLE-PREFIX}}-tsdb-uid-nf-backup ${BACKUP_DIR}/{{TABLE-PREFIX}}-tsdb-uid-nf
hdfs dfs -copyToLocal /user/wisla/{{TABLE-PREFIX}}-tsdb-lts-backup ${BACKUP_DIR}/{{TABLE-PREFIX}}-tsdb-lts

cd ${BACKUP_DIR}/..
tar -czvf {{FILE-NAME}} backup
hdfs dfs -rm -r /user/wisla/{{TABLE-PREFIX}}-tsdb-backup
hdfs dfs -rm -r /user/wisla/{{TABLE-PREFIX}}-tsdb-uid-backup
hdfs dfs -rm -r /user/wisla/{{TABLE-PREFIX}}-tsdb-nf-backup
hdfs dfs -rm -r /user/wisla/{{TABLE-PREFIX}}-tsdb-uid-nf-backup
hdfs dfs -rm -r /user/wisla/{{TABLE-PREFIX}}-tsdb-lts-backup

ssh {{LOGIN}}@{{BACKUP-SERVER}} "mkdir -p {{DESTINATION}}"
scp ./{{FILE-NAME}} {{LOGIN}}@{{BACKUP-SERVER}}:{{DESTINATION}}

rm -f ./{{FILE-NAME}}
cd ../
rm -r ${BACKUP_PARRENT_DIR}

!!!Но для выполнения скрипта надо настраивать hbase и hadoop

Дополнительно:

• Перезагрузка плагинов в приложении wiSLA

/opt/wisla5/scripts/reload-plugins.sh

Скрипт:

#!/bin/bash
# Source function library.
JRE_WORK=/opt/wisla5/jre/current

${JRE_WORK}/bin/java -jar /opt/wisla5/util/jmx/cmdline-jmxclient-0.10.3.jar - localhost:1090 "wisla-engine:name=pluginManager" reloadPlugins

exit 0

• Удаление старых лог файлов

/opt/wisla5/scripts/remove-old-logs.sh

Скрипт:

#!/bin/bash
DAYS=10
LOG_DIR=/opt/wisla5/wildfly/current/standalone/log
for file in "$( find ${LOG_DIR}/ -maxdepth 1 -type f -mtime +${DAYS} )"
do
    rm -f ${file}
done

Инструкция по полуавтоматическому обновлению wiSLA (alfa-test)

1. Подготовка к обновлению

1.1 - Альфа запущена (либо остановлена)

1.2 - Для структурирования папок, необходимо проверить наличие актуальной папки общей версии в каталоге /home/wisla/wisla_distr (например, 5210).

1.3 - Если папки нет, создать новую, иначе перейти в существующую (/home/wisla/wisla_distr/5210).

1.4 - Внутри создать папку с наименованием версии дистрибутива wisla (/home/wisla/wisla_distr/5210/2503121748). Возможен вариант создания по порядку (1,2,3...), учитывая пропуски.

1.5 - Если в каталоге /home/wisla/wisla_distr/5210/ больше 15 папок, удалить старые до 7 штук (можно вручную).(Для этого написан скрипт, если количество папок накопилось от 15 шт, то удалять ранее созданные папки, фильтруя по дате изменений, оставляя только 7 последних обновленных)

#!/bin/bash

# Перейти в каталог /home/wisla/529/111
cd /home/wisla/529/111

# Получить количество папок в каталоге
folder_count=$(find . -maxdepth 1 -type d | wc -l)

# Если количество папок больше 15, удалить старые 8 папок
if [ $folder_count -gt 15 ]; then
    old_folders=$(ls -dt */ | tail -n +8)
    echo "$old_folders" | xargs rm -rf
    remaining_folders=$(ls -dt */ | head -n 7)
    echo "Оставлены следующие папки:"
    echo "$remaining_folders"
fi

1.6 - В созданную папку, с наименованием версии, загрузить актуальную версию дистрибутива (например, wisla-5.2.10-2503121748.run). Перейти в данную папку.

Проверить процесс загрузки файла по наименованию файла, об этом сигнализирует изменение имени wisla-5.2.10-2503121748.run.filepart на wisla-5.2.10-2503121748.run).

1.7 - Далее дать разрешение на запуск файла, выполнив команду: 

chmod +x wisla-5.2.10-2503121748.run

2. Запуск обновления

1. Запустить автоматическое обновление:

./wisla-5.2.10-2503121748.run --silent-update

Обновление включает формирование дампов PostgreSQL, HBase и конфигурационных файлов. Перед окончанием выполнения скрипта обновления, система выполнит реиндекс, в консоли будет соответствующее сообщение  «Reindexing wisla engine lucene database..». 

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

В каталоге ожидается наличие всех дампов:

 2. Проверить статус обновления возможно выполнив API-запрос:

GET https://alfa-test.wellink.ru/engine/api/v1/system/state

Обновление завершено, когда:

1) статус сменится с 404 на 200 ,

2) в server.log  будет строка указывающая что реиндекс завершен:

INFO  [com.wellink.wisla.core.model.NodeReindexerImpl] (RMI TCP Connection(2)-10.11.11.20) slaOpFullTextReindexer reindex procedure complete.

3) в install....log завершение строкой:

Update complete!

Ссылки на дополнительную документацию:

- Ручная установка и обновление wisla

- Скрипты для взаимодействия с wiSLA

2. ЗАПУСК И ОСТАНОВКА

Запуск WiSLA

Для управления запуском следует получить доступ к консоли сервера wiSLA, пользователь “wisla".
Запуск всех компонентов:

sudo systemctl start wisla5
или
sudo /opt/wisla5/scripts/wisla5.sh start

Запуск только сервера приложений:

sudo /opt/wisla5/scripts/wisla5.sh start-wildfly

Маркером успешного запуска является следующее сообщение в журнале (server.log):

INFO  [com.wellink.wisla.communicator.impl.state.AvailabilitySystemStateSingletonImpl] (http-0.0.0.0-0.0.0.0-8080-1) !***   THE ALL wiSLA
COMPONENTS ARE FULLY DEPLOYED, INTERCONNECTED AND READY TO WORK!   ***!
13:48:30,028 INFO  [com.wellink.wisla.communicator.impl.state.AvailabilitySystemStateSingletonImpl] (http-0.0.0.0-0.0.0.0-8080-1) !********************
**********************************************************************!

Теперь можно запустить веб браузер и открыть страницу системы (http://xxx.xxx.xxx.xxx:8080).

Остановка WiSLA

Остановка всех компонентов:

sudo systemctl stop wisla5
или
sudo /opt/wisla5/scripts/wisla5.sh stop

Остановка только сервера приложений:

sudo /opt/wisla5/scripts/wisla5.sh stop-wildfly

Проверка и перезапуск WiSLA

Проверка статусов всех компонентов:

sudo systemctl status wisla5
или
sudo /opt/wisla5/scripts/wisla5.sh status

Проверка состояния сервера приложений:

sudo /opt/wisla5/scripts/wisla5.sh status-wildfly

Перезапуск только сервера приложений:

sudo /opt/wisla5/scripts/wisla5.sh restart-wildfly

Показать лог портала:

less /opt/wisla5/wildfly/current/standalone/log/server.log

less /opt/wisla5/wildfly/current/standalone/log/communicator.log

3. С ЧЕГО НАЧАТЬ

Стартовые действия

После установки wiSLA - необходимо авторизоваться на портале. Для этого воспользуйтесь суперпользователем, который создается при развертывании системы, по умолчанию это "Administrator". 

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

Данные первого пользователя:

Полное имя: Administrator

Эл. почта: Administrator

Пароль: Admin@123

Роль: Системный администратор.

Особенности:

• Роль Системный администратор для этой учетной записи не может быть снята самостоятельно.
• Данная учетная запись активирована при установке системы.
• Пароль для этой учетной записи может быть всегда изменен с портала wiSLA. (даже если в настройках системы указана смена пароля только через email)
• Данный пользователь может снимать/добавлять роль Системный администратор для других УЗ. 

После авторизации на портале, откроется страница с картой сервисов.

Далее необходимо создать контрагента в системе.

В форме создания контрагента можно создавать пользователей, также пользователей можно создать на странице "Пользователи".

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

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

4. АДМИНИСТРИРОВАНИЕ WEB-ПОРТАЛА

Контрагенты

В разделе «Контрагенты» отображается перечень всех контрагентов, которые доступны пользователю согласно правам доступа. Он может выполнять добавление, изменение и просмотр записей, добавление их в архив, удаление из архива, просмотр истории изменений атрибутов выбранной записи. Система может отображать список контрагентов в одноуровневом виде (по умолчанию) и в виде иерархического списка – дерева. Дерево строится по принципу: родительский – дочерний контрагент согласно корпоративной организационной структуре. Переключение режима можно выполнить на панели фильтрации. Важным параметром, определяющим назначение контрагента в системе, является его роль.
Предусмотрены следующие роли:

• «Потребитель сервиса» – присваивается контрагенту, который получает сервисы с установленными качественными показателями;
• «Провайдер сервиса» – присваивается контрагенту, который предоставляет сервисы с установленными качественными параметрами;
• «Провайдер SLA» – присваивается контрагенту, который контролирует качественные параметры сервиса

Система предоставляет возможность фильтрации списка контрагентов по роли контрагента (Потребитель сервиса, Провайдер сервиса, Провайдер SLA), статусу контрагента (Активный, Архивный), и тегам (пользовательским и системным). Доступна сортировка списка контрагентов по имени, роли, владельцу и статусу. На странице работает поиск. Для сохранения изменений, выполненных в рабочей области, используется кнопка «Сохранить» в правом верхнем углу страницы. Если пользователь внёс изменения в настройки объекта и покидает страницу, не нажав кнопку «Сохранить», система предлагает пользователю сохранить внесённые изменения или покинуть страницу без сохранения.

«Панель фильтрации» и «Панель поиска» соответственно. Панель фильтрации страницы «Контрагенты» показана на рисунке 47.

Рис. 47 Страница «Контрагенты» с включенной панелью фильтрации

Создание контрагента

Пояснения к сценарию.

• «Автоматическая публикация отчётов SLA» - отвечает за состояние признака публикации отчёта SLA после формирования и за отправку уведомления по электронной почте о формировании отчёта SLA заинтересованным лицам. Если опция отмечена, пользователи контрагента (а также пользователи, связанные с контрактом, где участвует данный контрагент в роли «Потребитель сервиса») получат уведомление о сформированном отчёте SLA. Это произойдет автоматически после формирования отчёта, а отчёт после формирования будет опубликован. Если опция не отмечена, отчёт SLA сформируется как «Не опубликован», будет доступен на портале всем заинтересованным лицам, но уведомление о формировании будет разослано только после публикации отчёта оператором SLA. Флажок появляется только при отметке роли контрагента «Потребитель сервиса»;
• Если пользователь, создающий контрагента, не был ранее закреплён ни за одним контрагентом, он будет выбран в этом поле автоматически (с возможностью открепления.
• Пользователь портала с ролью «Оператор SLA» может быть связан только с одним контрагентом, при попытке нарушения данного правила будет появляться предупреждение с возможностью удаления предыдущих связей;
  
• Пользователи портала без роли «Оператор SLA» могут быть связаны с неограниченным числом контрагентов;
  
• С одним контрагентом может быть связано несколько учётных записей пользователей портала;

Редактирование контрагента

Для изменения атрибутов контрагента нужно:

• нажать на запись в списке контрагентов. Откроется форма редактирования контрагента;
  
• выполнить редактирование атрибутов;
  
• нажать кнопку «aСохранить»;
  
• при сохранении данные проходят проверку. Если будут выявлены ошибки, форма останется открытой. Потребуется исправить ошибки и повторить сохранение

Отправка контрагента в архив

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

• убедиться, что контрагент не связан с объектами инфраструктуры;
  
• нажать на искомую запись в списке контрагентов. Откроется форма редактирования контрагента;
  
• нажать кнопку «Ещё», в выпадающем меню кнопки нажать «Архивировать». Произойдёт проверка возможности архивации контрагента. Если проверка выполнена успешно, запись перейдёт в статус «Архивный». После этого можно воспользоваться меню для ухода с формы или выполнить другие действия с выбранной записью (рисунок 50);

Рис. 50 Отправка контрагента в архив

• если контрагент ещё связан с активными объектами инфраструктуры, будет выдано предупреждение, блокирующее отправку в архив (рисунок 51):

Рис. 51 Запрет на архивацию объекта

Извлечение контрагента из архива

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

• открыть список архивных контрагентов. Для этого открыть панель фильтрации и выполнить фильтрацию по статусу «Архивный». Извлечение из архива также доступно сразу после отправки учётной записи в архив;
  
• нажать на искомую запись в списке архивных записей. Откроется форма редактирования контрагента (рисунок 52);

Рис. 52 Форма редактирования контрагента с кнопкой «Восстановить»

• нажать кнопку «Восстановить». Статус записи изменится на «Активный». После этого можно воспользоваться меню для ухода с формы или выполнить другие действия с выбранной записью. Если требуется поправить один или несколько атрибутов, можно выполнить редактирование в этой же форме и нажать кнопку «Сохранить».

Удаление контрагента

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

открыть архивную запись на редактирование (путём фильтрации списка по статусу «Архивный» или оставшись на форме редактирования после архивации контрагента, рисунок 53);

Рис. 53 Кнопка удаления контрагента в списке дополнительных действий

• нажать кнопку «Ещё», в появившемся списке действий – «Удалить». Появится запрос на подтверждение удаления;
  
• после подтверждения выполнится удаление записи и переход на список контрагентов.

Пользователи

На странице «Пользователи» (рисунок 57) выполняется управление учётными записями пользователей портала: создание, редактирование, изменение пароля, изменение ролей, настройка уведомлений, привязка учётных записей к IP, связь с контрагентами, архивация, блокировка, отправка в архив, восстановление из архива, удаление, просмотр истории изменений учётной записи. Для работы со списком пользователей предусмотрены: поиск, фильтрация по роли и статусу, сортировка по имени, электронной почте и статусу.

Статусы пользователей

• активный – пользователь был удачно добавлен, имеет свой пароль, может полноценно работать с порталом;
  
• блокированный – пользователь был заблокирован администратором системы или самой системой;
  
• зарегистрированный – пользователь был добавлен администратором системы, получил одноразовый пароль для прохождения регистрации, однако не выполнил вход на портал и смену пароля. Если система работает в облачном режиме, то возможен также иной вариант: пользователь прошёл регистрацию, но не выполнил процедуру подтверждения регистрации;
  
• архивный – пользователь был добавлен в архив администратором системы и не имеет доступа на портал.

Рис. 57 Страница «Пользователи» с включенной панелью фильтрации

Создание нового пользователя

Создание нового пользователя доступно пользователям с ролью «Системный администратор». До создания новой учётной записи нужно убедиться в работоспособности рассылки уведомлений по электронной почте с портала и (по возможности) в готовности к работе и корректности адреса электронной почты нового пользователя, так как учётные данные будут отправлены на адрес электронной почты нового пользователя.

Сценарий создания пользователя.

Роли пользователей 

• Роль «Системный администратор» открывает доступ к разделу «Администрирование» для управления контрагентами, пользователями и сессиями на портале. Позволяет сбрасывать пароли, настраивать дополнительные поля, создавать системные теги;
  
• Роль «Оператор SLA» добавляет возможности по созданию и изменению инфраструктуры, но не дает доступ в раздел «Администрирование» для управления контрагентами, пользователями и сессиями на портале;
  
• по умолчанию все добавляемые учётные записи включают роль «Пользователь», её снятие невозможно, она добавлена для наглядности.
• Если выбрана роль «Оператор SLA», то можно добавить только одного контрагента в список. В противном случае число связанных контрагентов не ограничено;

Уведомления

• «Всплывающие уведомления на портале» – для включения всплывающих уведомлений об открытии, закрытии и изменении уровня критичности паспортов неисправности, а также о публикациях отчётов SLA;
  
• «Уведомления» (по электронной почте) – для включения рассылки электронных писем об открытии, закрытии и изменении уровня критичности паспортов неисправности, писем о плановых работах, проблемах нагрузочного тестирования, а также о публикациях отчётов SLA. При отметке флажком «Отказ», «Деградация», «Не определено» важно не забыть отметить и тип события, по наступлению которого должно отправляться электронное письмо;

Прочее

• При нажатии «aСохранить». Система выполнит проверку данных. Если ошибок нет, откроется список пользователей. Новая учётная запись будет иметь статус «Зарегистрированный». Иначе система сообщит об ошибке, предложит её исправить, и далее понадобится выполнить сохранение повторно;
  
• Если есть возможность, убедиться в получении регистрационного письма пользователем. Пользователь получает письмо со ссылкой на портал и одноразовым паролем. У него есть 24 часа на активацию учётной записи (вход на портал со сменой пароля). Если пользователь просрочил активацию, учётная запись будет заблокирована.
  

Интеграция Active Directory и wiSLA

В wiSLA есть возможность создания пользователя и авторизации с помощью службы каталогов Active Directory.

Службы каталогов корпорации Microsoft для операционных систем семейства Windows Server. Основной задачей Active Directory является хранение информации обо всех объектах в сети и предоставление её внешним системам.

Хранение паролей, критерии их стойкости, периоды действия и прочий функционал управления учетными данными AD будет управляться на стороне AD.

Пользователь не сможет изменить учетные данные, если он добавлен с помощью AD. 

Настройки со стороны администратора производятся в инсталлере (рисунок 58.1).

Рис. 58.1 Страница настройки Active Directory в инсталлере

Перечень настроек:

Авторизация в wiSLA с помощью данных Active Directory

• Перейти на страницу авторизации в систему
• Указать данные авторизации AD
• Нажать кнопку "Войти"

Создание пользователя с помощью учетной записи Active Directory

Для создания нового пользователя с помощью AD нужно: 

• нажать кнопку «+ Создать». Откроется форма добавления новой учётной записи портала, по умолчанию открыта вкладка «Основные параметры»
• Нажать кнопку "Загрузить из ACTIVE DIRECTORY"
• Выбрать учетную запись AD в списке
• Нажать кнопку "Сохранить"

Регистрация пользователя wiSLA.Cloud по запросу

В режиме wiSLA.Cloud предусмотрена возможность автоматической регистрации пользователей. В случае если пользователь регистрирует себя и компанию впервые, участие системного администратора не предусмотрено. В этом случае создаётся учётная запись с правами «Оператор SLA» и «Пользователь», она получает статус «Зарегистрированный», затем при подтверждении регистрации статус учётной записи изменяется на «Активный». Помощь системного администратора может понадобиться только при регистрации программного агента для его корректной привязки к компании (контрагенту), если пользователь не указал свои учётные данные при установке агента (например, в целях безопасности). Однако есть один сценарий, когда без системного администратора регистрация пользователя невозможна. Пользователь при регистрации вводит полное имя, адрес электронной почты и название компании. Если название компании не уникально (то есть сотрудники этого пользователя уже зарегистрированы в системе), в целях безопасности система предлагает запросить доступ у системного администратора. В этом случае система отправляет письмо на адрес электронной почты системного администратора. Далее следует:

• выяснить соответствие сотрудника компании;
  
• если соответствие установлено, перейти по ссылке в письме (при необходимости авторизоваться на портале). Из письма будут переданы: адрес электронной почты, полное имя, набор ролей, принадлежность к контрагенту (в простейшем случае останется просто сохранить настройки). Если же установлен факт попытки получения несанкционированного доступа к инфраструктуре – уведомить ответственного представителя контрагента, игнорировать письмо о регистрации, не переходить по ссылке – в этом случае учётная запись не будет создана и злоумышленник не получит доступа к порталу этим способом;
  
• если в предыдущем пункте было принято решение о добавлении пользователя – заполнить необязательные поля (если требуется) и сохранить настройки. Пользователю будет отправлено письмо с данными для авторизации.

Если пользователь не получил письмо, можно открыть настройки учётной записи, уточнить адрес электронной почты и повторно нажать кнопку «Сохранить». Пользователю будет повторно отправлено письмо с новыми данными для авторизации.

Принудительная смена пароля

Системный администратор может выполнить смену пароля другому пользователю (кроме учётной записи с ролью системного администратора).

Для смены пароля нужно:

1. Найти в списке и открыть на редактирование учётную запись пользователя.
   
2. Если учётная запись в статусе «Зарегистрированный», можно повторно сгенерировать и выслать случайный пароль пользователю. Это может быть полезно в случае когда после создания учётной записи пользователь не получил письмо с одноразовым паролем. Системному администратору следует нажать кнопку «Сохранить», письмо с новым паролем будет отправлено.
   
3. Если учётная запись в статусе «Активный», и пользователь имеет набор ролей ниже системного администратора, то ему можно установить известный системному администратору пароль путём заполнения полей «Новый пароль» и «Подтверждение».
   
4. Смена пароля другим системным администраторам невозможна. Системные администраторы могут воспользоваться стандартной процедурой восстановления пароля на странице авторизации.

Блокировка учётной записи

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

1. найти в списке и открыть на редактирование учётную запись пользователя;
   
2. нажать «Ещё», «Заблокировать». Возможна блокировка учётных записей с набором ролей
   ниже системного администратора.

Блокировка других системных администраторов невозможна. Для снятия блокировки системный администратор должен выбрать заблокированную учётную запись, открыть её на редактирование и выбрать «Ещё», «Разблокировать».

Изменение настроек рассылки уведомлений

Настройки рассылки в чужой учётной записи могут быть изменены системным администратором независимо от роли редактируемой записи. На рисунке 59 показан пример настройки.

Рис. 59 Настройка рассылки уведомлений

В приведённом примере пользователь будет получать уведомления:

• на всех страницах портала – о паспортах неисправности и о публикации отчётов SLA;
  
• на адрес его электронной почты будут приходить письма об открытии, закрытии, изменении уровня и добавлении комментариев к паспортам неисправности уровней «Отказ», «Деградация» и «Не определено». Также он будет получать уведомления о планово-профилактических работах и провале нагрузочного тестирования.

Как было указано ранее, при отметке флажком «Отказ», «Деградация», «Не определено» важно не забыть отметить и тип события, по наступлению которого должно отправляться электронное письмо.

Сессии

Страница «Сессии» (рисунок 60) доступна системным администраторам. Она позволяет увидеть, кто в данный момент находится в системе, с какого IP-адреса произведён вход, время последней активности и ожидаемое время окончания сессии (длительность сессии по умолчанию составляет 30 минут). Для нежелательных сессий предусмотрены завершение сессии и блокировка пользователя.

Рис. 60 Страница управления сессиями

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

Журнал событий

Журнал событий (рисунок 61) предоставляет системному администратору доступ к записи действий, связанных с редактированием или созданием новых элементов инфраструктуры, входа на портал, публикации и перерасчёта отчётов SLA. Функционал страницы по работе с журналом событий позволяет:

• осуществлять полнотекстовый поиск (подробнее поиск описан в разделе «Панель поиска»);
  
• выполнять сортировку по дате, типу, длительности выполнения;
• выполнять фильтрацию по источнику системных событий и по типу событий

Рис. 61 Страница журнала событий

• при нажатии на интересующую запись в журнале получить окно с расширенной информацией о действиях пользователя с объектами (рисунок 62).

Рис. 62 Просмотр детальной информации о событии

Помимо страницы «Журнал событий» для пользователей с ролью системного администратора доступна кнопка «История изменений» на странице редактирования каждого объекта инфраструктуры, а также на странице редактирования контрагента и теста. После нажатия на нее во всплывающем окне отображается расширенная история по последним действиям из журнала событий, отфильтрованная по данному объекту.

Настройки системы

Почтовые уведомления

Раздел "Почтовые уведомления" предназначен для настройки отправки email-уведомлений системой. Здесь можно включить или отключить различные типы уведомлений, задать параметры SMTP-сервера, а также настроить безопасность соединения.

Основные настройки:

1. Общие параметры уведомлений:

   • Включение уведомлений на почту.
   • Уведомления о статусе профиля.
   • Уведомления об активации сервиса.
   • Уведомления о смене статуса сервиса.

2. Настройки соединения:

   • Адреса уведомлений:
     • wiSLA notification cp_link: https://alfa-test.wellink.ru
     • wiSLA notification op_link: https://alfa-test.wellink.ru
   • Почтовый сервер: smtp.yandex.ru
   • Протокол: SMTP
   • Порт: 465
   • Используемые версии TLS: TLSv1.2, TLSv1.3

3. Безопасность соединения:

   • Включение SSL.
   • Аутентификация SMTP.
   • Включение или отключение STARTTLS.
   • Возможность отключить аутентификацию SMTP.
   • Поле SSL Trust.

4. Дополнительные параметры:

   • Таймаут чтения: 5000
   • Таймаут соединения: 5000
   • Таймаут записи: 5000
   • Включение режима отладки.
   • Пароль (скрыт звездочками).
   • Псевдоним отправителя: wisla-alfa-test
   • Пользователь: alfa-test@wellink.ru
   • Отправитель: alfa-test@wellink.ru
   • Лимит уведомлений о событиях: 10
   • Опция "Использовать английские имена файлов".

Назначение и использование

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

Авторизация LDAP

Описание раздела "Авторизация LDAP" в настройках системы

Раздел "Авторизация LDAP" предназначен для настройки интеграции системы с сервисом каталогов LDAP (Lightweight Directory Access Protocol). Это позволяет централизованно управлять аутентификацией и авторизацией пользователей через LDAP-сервер.

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

1. Включение авторизации LDAP

   • Позволяет включить или отключить механизм аутентификации через LDAP.

2. Параметры подключения к LDAP-серверу

   • Адрес сервера LDAP: ldap://10.11.11.42:389/ – указывает на сервер и порт для соединения.
   • База поиска LDAP: ou=well-users,dc=wellink,dc=local – определяет, где в каталоге производить поиск учетных записей.
   • Логин: cn=explorer,dc=wellink,dc=local – учетная запись, используемая для подключения к серверу.
   • Пароль (скрыт звездочками) – аутентификационные данные для связи с сервером.

3. Настройки идентификации пользователей

   • Аутентификатор LDAP: ldapBindAuthenticator – механизм проверки учетных данных пользователей.
   • Идентификатор пользователя: objectGUID – уникальный идентификатор учетной записи в каталоге.
   • Атрибут для логина: sAMAccountName – поле, используемое для аутентификации пользователей.
   • Атрибут полного имени: displayname – поле, содержащее полное имя пользователя.
   • Имя группы: memberof – параметр, определяющий, к какой группе принадлежит пользователь.
   • Имя объектного класса (человек): user – объектный класс, к которому относятся учетные записи пользователей.
   • Почта: mail – атрибут LDAP, хранящий email-адрес пользователя.
   • Телефон: telephonenumber – атрибут, содержащий телефонный номер.

Назначение и использование

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

Обновление агентов

Описание раздела "Обновление агентов" в настройках системы

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

Основные возможности:

1. Действия с агентами

   • Начать обновление – запуск обновления для выбранных агентов.
   • Указать источник – выбор источника для загрузки обновлений.

2. Список агентов (таблица с параметрами):

   • Название – имя агента в системе.
   • Тип – категория агента (например, Linux, Windows, Sheeva).
   • Версия прошивки – текущая установленная версия.
   • IP-адрес – сетевой адрес устройства, на котором работает агент.
   • Расположение – регион или площадка, где находится агент.
   • Доступность – индикатор доступности агента (зелёный – доступен, красный – недоступен).
   • Статус – состояние агента (значки показывают, обновляется ли он, требует ли внимания и т. д.).
   • Ссылка для обновления – путь к файлу обновления, например, ftp://192.168.176.92/update.
   • Последнее обновление – дата и время последнего обновления агента.

3. Фильтрация и сортировка данных

   • Поиск по названию агента.
   • Настройка отображаемых столбцов.

Назначение и использование

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

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

Описание функционала

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

1. Ролевые ограничения

Функция очистки доступна только следующим пользователям:

• Administrator (id2)

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

2. Возможности очистки

Функция позволяет удалять:

Сырые данные по конкретному сервису
Статусы сервиса
Созданные ПН (паспорта неисправности)
Запланированные ППР (плановые предупредительные работы)
Исключения

3. Процесс очистки данных

1. Запуск очистки

   • Перейдите во вкладку "Хранение данных".
   • Нажмите кнопку "Принудительная очистка исторических данных".
   • Появится окно подтверждения с предупреждением:

     "Вы собираетесь очистить все исторические данные по сервису. Паспорта неисправности, статусы сервиса и результаты тестов будут безвозвратно удалены. Продолжить?"

   • В окне доступны две кнопки:
     • "Да" – подтверждение операции.
     • "Отменить" – отмена действия.

2. Определение времени очистки

   • После подтверждения система определяет ближайший "Системный временной промежуток".
   • Пользователь получает уведомление:

     "Очистка данных будет произведена: TT:TT, DD/MM/YY"

3. Постановка в очередь

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

4. Исключение дублирующихся задач

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

4. Логирование

• Все действия по очистке фиксируются в "Журнале событий", включая:
  • Время постановки задачи
  • ID пользователя, инициировавшего очистку
  • ID сервиса
  • Удаленные категории данных

5. Важные примечания

Очистка данных выполняется только в начале следующего "Системного временного промежутка".
Удаленные данные не подлежат восстановлению!
При наличии уже поставленной задачи на очистку повторные запросы не регистрируются.

6. Ожидаемое поведение системы

7. Заключение

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

5. РАЗГРАНИЧЕНИЕ ПРАВ ДОСТУПА НА WEB-ПОРТАЛЕ

Роли и права на действия с объектами

Роли

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

• «Системный администратор»;
  
• «Оператор SLA»;
  
• «Пользователь» (роль по умолчанию, которая назначена всем пользователям). Чтобы избежать путаницы с абстрактным пользователем портала, далее для обозначения учётных записей с этой единственной ролью будет использовано словосочетание «учётная запись с ролью «пользователь».

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

Права на действия с объектами

Права доступа к объектам системы основаны на двух типах связи: «пользователь – контрагент» и «пользователь – контракт». Если учётная запись имеет связь с контрагентом, пользователь получает доступ к объектам инфраструктуры всех контрактов этого контрагента, а также всех объектов, владельцем которых является данный контрагент. Если пользователь портала перечислен в списке ответственных пользователей в контракте, ему доступны объекты инфраструктуры этого контракта.

Разграничение прав доступа по принадлежности к контракту подразумевает видимость объектов, связанных с контрактом (от сервисов — до зондов). В зависимости от набора ролей в настройках учётной записи пользователь может не только просматривать объекты системы, но и редактировать их (например, редактировать пользователей), а также использовать доступные ему объекты при создании новых (например, доступные зонды и сервисы – при создании новых контрактов).

При создании пользователем контрагента «Б», создаваемый объект приобретает иерархическую связь с контрагентом «А», за которым закреплён этот пользователь. Далее такой контрагент «Б» будет называться «дочерним контрагентом» по отношению к «А». Соответственно, контрагент «А» является «родительским контрагентом» по отношению к «Б».

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

Разграничение прав доступа к контрактам и дочерним объектам контракта (сервисам, зондам) осуществляется на основе связи между контрактом и пользователем (одним или несколькими), которые несут ответственность и контролируют соблюдение SLA в рамках этого контракта.

Все пользователи, которые закреплены за определёнными контрактами, имеют возможность мониторинга состояния этих контрактов и всего, что с ними связано:

• получают уведомления по электронной почте о событиях, связанных с сервисами контракта;
  
• просматривают паспорта неисправности, исключения и плановые работы по сервисам контракта;
  
• просматривают текущие показатели качества по сервисам контракта;
  
• просматривают отчёты SLA по контракту и получают отчёты по электронной почте;
  
• просматривают связанную с контрактом инфраструктуру (сервисы и зонды).

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

Пользователь с ролью «Системный администратор»:

• работает с блоком «Администрирование» в главном меню;
  
• ведёт работу с учётными записями портала: создаёт пользователей; редактирует, блокирует, снимает блокировку всем, кроме других системных администраторов и Administrator; подтверждает регистрацию пользователей wiSLA.Cloud;
  
• просматривает контракты, не может добавлять и удалять пользователя из контракта;
  
• просматривает настройки зондов;
  
• просматривает и изменяет настройки зондов в статусе "На складе";
• просматривает настройки точек доступа;
  
• изменяет контрагентов в настройках всех объектов системы, кроме контрактов и учётных записей других системных администраторов и Administrator;
  
• создаёт и редактирует показатели;
  
• создаёт и редактирует SLA (только созданные пользователем с ролью «Системный администратор»);
  
• создаёт и редактирует всех контрагентов. Если системный администратор не закреплён за контрагентом, созданный им контрагент не будет иметь иерархической связи с контрагентом системного администратора;
  
• создаёт и редактирует тесты (только созданные пользователем с ролью «Системный администратор»);
  
• управляет сессиями;
  
• просматривает журнал событий;
• управляет доступом к разделу «Топология сети» и взаимодействует с иерархией контрагентов: имеет доступ к топологии всех контрагентов системы и возможность перехода между схемами топологии родительских и дочерних контрагентов;
• работает с элементами управления на схеме топологии: имеет доступ к фильтрации, поиску, масштабированию, а также кнопкам сохранения и информации об объектах топологии;
• редактирует схему топологии: изменяет расположение объектов на уровнях топологии, добавляет и удаляет объекты, перемещает объекты между уровнями, объединяет в группы и создает связи между объектами, добавляет каналы связи и внешние связи между объектами;
• управляет режимами сохранения топологии: выбирает режим ручного сохранения через кнопку «Сохранить» или режим автоматического сохранения после изменений, задаваемый в настройках;
• управляет настройками топологии сети: изменяет параметры сканирования, добавляет и удаляет подсети, редактирует настройки IP-адресов, портов, логинов и паролей, и других технических параметров для всех контрагентов;
• работает со списком контрагентов: выполняет поиск, сортировку и настройку отображения столбцов в таблице контрагентов, может изменять порядок столбцов и настраивать видимость столбцов;
• выполняет поиск и настройку видимости объектов инфраструктуры, имея доступ ко всем объектам, связанным с контрагентами в системе, включая объекты на уровнях дочерних контрагентов.

Мастер-пользователь

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

Полное имя: Administrator

Эл. почта: Administrator

Пароль: Admin@123

Роль: Системный администратор.

Особенности:

• Роль Системный администратор для этой учетная запись не может быть снята самостоятельно.
• Данная учетная запись активирована при установке системы.
  
• Пароль для этой учетная запись может быть всегда изменен с портала wiSLA. (даже если в настройках системы указана смена пароля только через email)
• Данный пользователь может снимать/добавлять роль Системный администратор для других учетных записей. 

Пользователь с ролью «Оператор SLA»:

• работает с блоками «Мониторинг», «Отчёты», «Инфраструктура» в главном меню портала;
  
• не имеет доступа в разделы блока «Администрирование», но может работать с контрагентами (изменять роли и создавать новых со страницы контракта) и тестами (со страницы сервиса);
  
• может быть прикреплён только к одному контрагенту;
  
• создаёт объекты инфраструктуры, которые наследуют его связь с контрагентом;
  
• создаёт и редактирует сервисы, контракты, зонды, точки доступа. Для редактирования доступны любые объекты инфраструктуры, принадлежащие контрагенту, к которому он прикреплён, а также объекты, видимые через контракты, в которые он добавлен как ответственный пользователь;
  
• создаёт и редактирует показатели, при этом для редактирования доступны показатели, созданные только пользователем с ролью «Оператор SLA» и принадлежащие его контрагенту;
  
• создаёт и редактирует SLA, при этом для редактирования доступны SLA, созданные только пользователем с ролью «Оператор SLA», принадлежащие родительскому или дочерним контрагентам;
  
• создаёт и редактирует тесты (через настройки сервиса). Для редактирования доступны также тесты, созданные пользователем с ролью «Системный администратор»;
  
• создаёт новых контрагентов (через настройки контракта), которые наследуют его связь с контрагентом и становятся по отношению к этому контрагенту дочерними;
  
• меняет набор ролей контрагента (через настройки контракта);
  
• не может изменять владельца в настройках объектов инфраструктуры, включая настройки своего профиля;
  
• использует и редактирует объекты инфраструктуры дочерних контрагентов: сервисы, контракты, зонды, точки доступа, SLA, тесты (через сервисы);
  
• только оператор SLA создаёт плановые работы, а также создаёт, редактирует и удаляет ручные исключения;
  
• только оператор SLA изменяет статус паспорта неисправности (приостанавливает и возобновляет);
  
• только оператор SLA добавляет в контракт шаблоны отчётов SLA, формирует отчёты, публикует их и перерассчитывает;
• управляет доступом к разделу «Топология сети» для своего контрагента и дочерних контрагентов, к которым он прикреплён, с возможностью перехода к схемам топологии выбранного контрагента;
• работает с элементами управления на схеме топологии: имеет доступ к базовым элементам интерфейса, включая масштабирование, поиск, фильтрацию, добавление объектов и редактирование доступных объектов инфраструктуры контрагента;
• редактирует схему топологии: перемещает объекты, добавляет новые объекты, создаёт и удаляет связи между объектами, добавляет каналы связи и внешние связи между объектами контрагента и дочерних контрагентов;
• управляет режимом сохранения топологии для своих объектов: может выбирать между ручным и автоматическим режимами сохранения через настройки топологии;
• управляет настройками топологии для своего контрагента: добавляет и удаляет подсети, настраивает IP-адреса, порты, логины, пароли и другие технические параметры, доступные для его инфраструктуры;
• работает со списком контрагентов, видимых ему по иерархии: имеет доступ к фильтрации, сортировке и настройке отображения столбцов для контрагентов, связанных с его контрагентом;
• выполняет поиск по именам и владельцам контрагентов, видимых в иерархии, и видит все объекты инфраструктуры дочерних контрагентов, связанных с его контрагентом.

Учётная запись с ролью «Пользователь»:

• работает с блоками «Мониторинг», «Отчёты», «Инфраструктура» в главном меню портала;
  
• не имеет доступа в разделы блока «Администрирование»;
  
• не может создавать и редактировать объекты инфраструктуры;
  
• видит объекты только в рамках своего контракта и контрагента;
  
• изменяет настройки своего профиля;
• имеет ограниченный доступ к разделу «Топология сети»: видит только топологию, связанную с его контрагентом, без возможности перехода к другим контрагентам или схемам топологии;
• взаимодействует с элементами управления на схеме топологии в режиме просмотра: доступ к масштабированию и просмотру объектов, но без возможности добавления, редактирования или удаления объектов;
• не имеет права редактировать схему топологии: объекты и их расположение доступны только для просмотра;
• не имеет доступа к настройкам топологии сети: окно настроек топологии скрыто, параметры сканирования и управления подсетями недоступны;
• видит список контрагентов, к которым он прикреплён, в одноуровневом формате, без возможности сортировки, фильтрации или настройки столбцов;
• выполняет поиск только в рамках своего контрагента и контракта, видя объекты инфраструктуры, которые относятся исключительно к его контрагенту.

Настройка видимости объектов инфраструктуры разными контрагентами

1. Оператор SLA может добавлять в новые контракты уже созданные и действующие в других контрактах сервисы, при этом не происходит дублирование сервисов в общем перечне.
   
2. Для каждого партнёра потребителя услуги SLA (оператора связи для корпоративных клиентов, потребителя связи для операторов связи) должен быть создан свой контракт, чтобы его пользователи могли видеть только свои сервисы.
   
3. Операторы SLA родительского контрагента могут видеть и использовать все объекты инфраструктуры дочерних контрагентов.
   
4. Для мониторинга магистральных сервисов региональных отделений клиента требуется:
   • добавить все магистральные региональные сервисы клиента в один контракт федерального отделения клиента. – Пользователям федерального отделения становятся доступны все магистральные сервисы;
   • прикрепить магистральные региональные сервисы к контрактам соответствующих региональных отделений клиента. – Пользователям каждого регионального отделения клиента становится доступен магистральный сервис их региона и не видны другие магистральные сервисы.

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

Таблица 6 – Права на действия с объектами для разных ролей пользователей.

Объединение ролей пользователя

Пользователю можно назначить несколько ролей одновременно.
Совмещение двух ролей «Системный администратор» и «Оператор SLA» даёт пользователю дополнительные возможности:

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

При этом появляются ограничения:

• пользователь может быть прикреплён только к одному контрагенту (обусловлено наличием роли «Оператор SLA»);
  
• пользователь может создавать объекты инфраструктуры только для того контрагента, к которому он прикреплён

Редактирование владельцев объектов

В процессе реорганизации структуры предприятия, изменения топологии сети и других случаях может появиться необходимость в редактировании владельца объекта (рисунок 63). Эта функция доступна только пользователям с ролью «Системный администратор» и пользователям с объединённой ролью «Системный администратор» + «Оператор SLA». Следует отметить, что редактирование владельцев объектов инфраструктуры должно применяться только в исключительных случаях. Для пользователя «Оператор SLA» поле «Владелец» отображается в режиме чтения.

Рис. 63 Редактирование поля «Владелец» на странице редактирования сервиса

6. РЕЗЕРВНОЕ КОПИРОВАНИЕ И ВОССТАНОВЛЕНИЕ

Резервное копирование системы wiSLA осуществляется путём регулярного запуска исполняемого файла при помощи cron — планировщика задач в UNIX-подобных операционных системах. Интерфейс для настройки резервного копирования представлен в программе установки wiSLA. Программа установки позволяет выполнять резервное копирование баз данных Postgres, HBase и системных настроек.

Резервное копирование данных хранилища HBase может быть выполнено двумя способами:

1. Полное резервное копирование системы. При каждом выполнении в архив будет попадать вся информация из хранилища. Это предпочтительный вариант, позволяет произвести восстановление без обращения в службу поддержки. Однако на большом объёме данных он избыточный и длительный;
   
2. Частичное, или инкрементальное, резервное копирование. При частичном копировании системы первый раз выполняется полное резервное копирование данных, после этого – резервное копирование данных за прошедшие сутки. Это более быстрый, компактный и рациональный способ резервного копирования данных HBase, однако восстановление данных в этом случае значительно усложняется и выходит за рамки настоящего Руководства.

Управление резервными копиями проводится в разделе «Backup Management» (пункт меню «Backup»).
Программа установки предоставляет следующие возможности (рисунок 64):

Рис. 64 Раздел «Backup Management»

• «Backup HBase DB» – создать резервную копию текущего состояния всей базы данных HBase. Файл создаётся в одном каталоге с программой установки;
  
• «Restore HBase DB» – восстановить базу данных HBase из файла резервной копии;
  
• «Clear HBase DB tables and restore dump» – восстановить базу данных HBase из файла резервной копии с очисткой таблиц. Текущие таблицы будут переименованы, а впоследствии замещены при следующем восстановлении данных;
  
• «Clear HBase DB tables» – очистить текущие таблицы с данными HBase (выполняется путём их переименования);
  
• «Backup Postgres DB» – выполнить резервное копирование базы данных Postgres с копированием файла резервной копии в текущий каталог, откуда запущена программа установки;
  
• «Restore Postgres DB» – восстановить базу данных Postgres из резервной копии. При восстановлении текущие данные будут утрачены;
  
• «Backup installation info» – создать резервную копию реестра настроек программы установки;
  
• «Autobackup configuration» – настроить расписание для создания резервных копий.

Настройка резервного копирования

Пример настройки автоматического резервного копирования показан на рисунке 65:

Рис. 65 Меню «Autobackup configuration»

• «Backup destination» – путь к каталогу, в котором будут храниться файлы резервных копий на хосте, указанном в следующей настройке;
  
• «Server for backup files» – сетевое название хоста для хранения резервных копий;
  
• «User login at the backup server» – имя пользователя на хосте для хранения резервных копий, под которым будет выполняться вход для копирования файла;
  
• «Make full HBase DB backup» – определяет, как будут создаваться резервные копии базы данных HBase. Принимает значения true и false. В случае true каждые сутки будет создаваться полная копия данных HBase, false включает инкрементальное копирование данных из HBase.

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

Восстановление баз данных из резервной копии

Восстановление базы данных Postgres

1. Найти наиболее актуальный файл резервной копии и скопировать его в каталог с программой установки. Запомнить или скопировать в буфер обмена название файла.
   
2. Запустить программу установки.
   
3. Выполнить выключение сервера приложений и web-сервера wiSLA (Stop wiSLA).
   
4. Выполнить операцию «Restore Postgres». В окно запроса ввести название файла резервной копии.
   
5. Дождаться выполнения операции и проанализировать результат.
   
6. При необходимости применить патчи к базе данных (если были обновления wiSLA за промежуток времени от создания резервной копии до восстановления). Это можно сделать в разделе Maintenance – Postgresql management – Patch database.
   
7. Запустить сервер приложений и web-сервер wiSLA (Start wiSLA). 

Восстановление неинкрементальной базы данных HBase

1. Найти наиболее актуальный файл резервной копии и скопировать его в каталог с программой установки. Запомнить имя файла.
   
2. Запустить программу установки.
   
3. Выполнить выключение сервера приложений и web-сервера wiSLA (Stop wiSLA).
   
4. Выполнить операцию «Restore HBase». В ответ на запрос системы ввести имя файла (архива) резервной копии.
   
5. Дождаться выполнения операции. Длительность зависит от объёма данных и производительности дисковой подсистемы. Процесс может занимать более 2 часов.
   
6. Запустить сервер приложений и web-сервер wiSLA (Start wiSLA).
   
7. Для восстановления инкрементальной базы данных HBase обратитесь в службу технической поддержки. Если требуется восстановить как базу данных Postgres, так и HBase, рекомендуется выполнять восстановление последовательно, запускать сервер приложений после первого восстановления в этом случае не нужно.

7. ОТКАЗОУСТОЙЧИВЫЙ КЛАСТЕР

Необходимое окружение и библиотеки

Необходимые пакеты для установщика на oracle linux 8

autogen-libopts-5.18.12-8.el8.x86_64.rpm           ntpdate-4.2.6p5-29.el7.centos.2.x86_64.rpm
compat-openssl10-1.0.2o-4.el8.x86_64.rpm           pv-1.6.6-7.el8.x86_64.rpm
dialog-1.3-13.20171209.el8.x86_64.rpm              python3-bcrypt-3.1.6-2.el8.1.x86_64.rpm
glibc-langpack-ru-2.28-225.0.4.el8_8.6.x86_64.rpm  python3-paramiko-2.12.0-1.el8.noarch.rpm
libsodium-1.0.18-2.el8.x86_64.rpm                  python3-pynacl-1.3.0-5.el8.x86_64.rpm
ntp-4.2.6p5-29.el7.centos.2.x86_64.rpm             uuid-1.6.2-43.el8.x86_64.rpm

• libnsl-2.28-225.0.4.el8_8.6.x86_64.rpm - пакет который ставился на 1-й и 4-й сервера 
• compat-openssl10-1.0.2o-4.el8.x86_64.rpm - для pgpool
• uuid-1.6.2-43.el8.x86_64.rpm glibc-langpack-ru-2.28-225.0.4.el8_8.6.x86_64.rpm -Postgresql требует пакеты glibc-langpack-ru и uuid

На узлах 2,5(hadoop) должна быть организована "общая папка" , при создании файла в примонтированном gluster на одном узле, он должен появляться на другом

Скрипт для чистки всего(кроме pgpool), следует запускать перед установкой и после удаления из установщика. 

Установщик не чистит папки в home директории. И установщик может не убрать процессы java, postgres, pgpool, если возникают проблемы при установке, запуске, остановки - проверить наличие процессов

for i in $(seq 1 7);
do
ssh 0001wislatest0$i sudo killall java
ssh 0001wislatest0$i sudo killall postgres 
ssh 0001wislatest0$i 'rm -rf /opt/wisla5/* /home/wisla/{hadoop,zookeeper,hbase,postgresql}'
done
ssh 0001wislatest02 rm -rf /mnt/glusterVol/* #где glusterVol - куда примонтировали gluster.

Подготовительные этапы к установке кластера

Преимущества кластера

Настройка отказоустойчивого кластера wiSLA позволяет решить 2 задачи:

• в случае отказа одного из ЦОД система сохраняет работоспособность;
  
• в кластере работает балансировка нагрузки, что позволяет более эффективно использовать
  аппаратные ресурсы серверов.

В примере будет показана установка системы wiSLA на отказоустойчивый контур, который включает в себя семь серверов, распределённых между двумя ЦОД (по три в каждом) и одним дополнительным сервером – «третьей точкой опоры» (см. рисунок 66). Для взаимодействия между серверами выделена подсеть «межсерверного взаимодействия».

Рис. 66 Логическая группировка серверов в отказоустойчивом контуре wiSLA

Дополнительно могут быть развернуты wisla contactor portals (но не на 3 и 6 ноде, где уже есть портал оператора)

Отказоустойчивый контур должен состоять минимум из двух блоков (ЦОД), которые включают в себя сервера с основными компонентами, и дополнительного сервера (третей точки опоры), с помощью которого контролируется доступность основных ЦОД и целостность кластера. Всего для отказоустойчивого контура должно быть выделено не менее пяти отдельных серверов. Желательно, чтобы аппаратная конфигурация серверов была одинаковой. В этом случае можно производить установку и обновление системы с помощью программы установки без ручного изменения параметров распределения оперативной памяти по компонентам.

В таблице приведён пример настройки отказоустойчивого контура, который содержит два ЦОД (по три сервера на каждом) и один дополнительный сервер (третья точки опоры).

Таблица 8 – Топология кластера (пример).

Предварительно для каждого сервера контура требуется базовая настройка, которая описана в разделе «Подготовка операционной системы к запуску программы установки». Для серверов с Hadoop NameNode (wislaserver02 и wislaserver05) потребуется дополнительно примонтировать блочное устройство, объем диска на обоих серверах должен быть одинаковым. Для серверов с Pgpool (wislaserver01 и wislaserver04) должен быть выделен IP-адрес в подсети межсерверного взаимодействия, который будет использовать Pgpool. Далее в примерах настройки используется «192.168.1.110».

На серверах с Pgpool (wislaserver01 и wislaserver04) также требуется убедиться в отсутствии alias-интерфейса

 «eth0:10», где eth0 – корневой интерфейс, на котором настроена подсеть межсерверного взаимодействия, фактически может отличаться.

Настройка беспарольного доступа по SSH для межсерверного взаимодействия

Для корректной установки системы wiSLA и взаимодействия серверов контура должен быть организован беспарольный доступ по SSH под пользователем wisla по принципу «каждый с каждым». Также требуется беспарольный доступ под пользователем root между серверами с Pgpool и третей точкой опоры. При этом для доступа с сервера на сервер используется hostname. Для этого требуется выполнить следующие шаги:

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

!Внимание, при изменении топологии, возможно корректирование предлагаемых комманд

1. На 7-й сервере добавить хосты в /etc/hosts

mkdir installDir; pushd installDir
host_prefix=0001wislatest0
echo 192.168.1.101 "$host_prefix"1 >> hostsForALL
echo 192.168.1.102 "$host_prefix"2>> hostsForALL
echo 192.168.1.103 "$host_prefix"3>> hostsForALL
echo 192.168.1.104 "$host_prefix"4>> hostsForALL
echo 192.168.1.105 "$host_prefix"5>> hostsForALL
echo 192.168.1.106 "$host_prefix"6>> hostsForALL
echo 192.168.1.107 "$host_prefix"7>> hostsForALL
cat hostsForALL | sudo tee -a /etc/hosts
hostnames="0001wislatest01 0001wislatest02 0001wislatest03 0001wislatest04 0001wislatest05 0001wislatest06 0001wislatest07"
hostnames_1_6="0001wislatest01 0001wislatest02 0001wislatest03 0001wislatest04 0001wislatest05 0001wislatest06"
hostnames_1_4_7="0001wislatest01 0001wislatest04 0001wislatest07"

2. На каждом сервере контура под пользователем wisla выполнить генерацию ключей, пароль оставить пустым (можно вообще 1 ключ создать и скопировать его везде): 

su -l wisla
cd /home/wisla
ssh-keygen -t rsa -N "" -f ~/.ssh/id_rsa # или ssh-keygen -t rsa

Если не известен пароль, то необходимо:

зайти на хост на который нужно подключиться 
скопировать содержимое ~/.ssh/*.pub #ssh-keygen -t rsa если нет файла
добавить в конец файла ~/.ssh/authorized_keys

4. Скопировать /etc/hosts на каждый хост

for i in $hostnames_1_6; do cat hostsForALL | ssh "$i" 'sudo tee -a /etc/hosts';done 
for i in $hostnames_1_6; do ssh "$i" "sudo hostnamectl set-hostname $i";done 

5. С каждого сервера контура под пользователем wisla выполнить копирование ключа на все остальные сервера для пользователя wisla и для пользователя root для части серверов(На серверах с Pgpool и дополнительном сервере под пользователем wisla выполнить копирование ключа на другие сервера с Pgpool или дополнительный сервер для пользователя root): 

host_keys="$(for i in $hostnames;do ssh \"$i\" 'cat /home/wisla/.ssh/*.pub'; done)"

for i in $hostnames;do echo "$host_keys" | ssh "$i" tee -a /home/wisla/.ssh/authorized_keys; done

host_keys="$(for i in $hostnames_1_4_7;do ssh "$i" 'cat /home/wisla/.ssh/*.pub'; done)"

for i in $hostnames_1_4_7;do echo "$host_keys"| ssh "$i" 'sudo mkdir -p /root/.ssh; sudo tee -a /root/.ssh/authorized_keys'; done

6. Выполнить разовое подключение по SSH под пользователем wisla с каждого сервера на другие сервера, чтобы подтвердить добавление ключей удалённых серверов (по умолчанию отпечаток ключа будет храниться в файле /home/wisla/.ssh/known_hosts). При этом на вопрос «Are you sure you want to continue connecting (yes/no)?» требуется отвечать «yes». При подключении пароль удалённого сервера запрашиваться не должен.

Выполнить команду на каждом сервере под пользователем wisla:

for i in $hostnames; do ssh "$i" exit; done

Выполнить команду на 1 4 7 серверах под пользователем wisla:

for i in $hostnames_1_4_7; do ssh root@"$i" exit; done

В некоторых случаях доступ по root из ssh невозможен: следует проверить файл /etc/security/access.conf(ROOT:ALL) и файл /etc/ssh/sshd_config (PermitRootLogin yes)

Установка GlusterFS

GlusterFS – распределённая, параллельная, линейно масштабируемая файловая система с возможностью защиты от сбоев. Предварительно на серверах wislaserver02 и wislaserver05 должны быть созданы lvm-разделы абсолютно одинакового размера. Далее в примере используется «/dev/sdb1», фактически название раздела может отличаться. 

Действия по установке и настройке GlusterFS выполняются под пользователем root.

Для установки GlusterFS на серверах wislaserver02 и wislaserver05 требуется выполнить следующие шаги:
1. Загрузить установочные пакеты GlusterFS по ссылке ftp://ftp.wellink.ru/Deploies/Centos/cluster/glusterfs.tar.gz ;
2. Подключиться к серверу по SSH под пользователем root;
3. Перейти в каталог с архивом, распаковать архив, установить необходимые пакеты glusterfs, glusterfs-server, glusterfs-cli,:

tar zxvf glusterfs.tar.gz
yum install glusterfs-3.5.2-1.el6.x86_64.rpm glusterfs-api-3.5.2-1.el6.x86_64.rpm
glusterfs-cli-3.5.2-1.el6.x86_64.rpm glusterfs-fuse-3.5.2-1.el6.x86_64.rpm glusterfs-georeplication-3.5.2-1.el6.x86_64.rpm glusterfs-libs-3.5.2-1.el6.x86_64.rpm glusterfsserver-3.5.2-1.el6.x86_64.rpm

Настройка GlusterFS

Для настройки работы GlusterFS требуется выполнить следующие шаги:

1. Рекомендовано на серверах wislaserver02 и wislaserver05 отформатировать раздел для glusterfs в файловую систему xfs:

mkfs.xfs /dev/sdb1

2. Смонтировать раздел, добавить в автозапуск и запустить glusterfs на wislaserver02 и wislaserver05:

mkdir -p /mnt/gluster && mount /dev/sdb1 /mnt/gluster && mkdir -p /mnt/gluster/brick
echo "/dev/sdb1 /mnt/gluster xfs defaults 0 0" >> /etc/fstab
systemctl start glusterd # /etc/init.d/glusterd start

3. На сервере wislaserver02 выполнить команды:

gluster peer probe "$host_prefix"5
gluster volume create namenodevol rep 2 transport tcp "$host_prefix"2:/mnt/gluster/brick
"$host_prefix"5:/mnt/gluster/brick
gluster volume start namenodevol
mkdir /mnt/glusterVol; mount -t glusterfs "$host_prefix"2:/namenodevol /mnt/glusterVol/
chown wisla:wisla -R /mnt/glusterVol

4. На сервере wislaserver05 выполнить команды:

mkdir /mnt/glusterVol; mount -t glusterfs "$host_prefix"5:/namenodevol /mnt/glusterVol/ 
chown wisla:wisla -R /mnt/glusterVol

Внимание, следует протестировать что файл созданный на одном узле в /mnt/glusterVol ,должен появиться в том же месте на другом узле

5. На сервере wislaserver02 выполнить команды:

touch /mnt/glusterVol/test_file.txt

6. На сервере wislaserver05 проверить наличие файла и затем файл можно удалить

ls /mnt/glusterVol/test_file.txt
rm -f /mnt/glusterVol/test_file.txt

Действия в программе установки wiSLA

Шаги для установки wiSLA описаны в разделе «Работа с программой установки». Но есть ряд отличий в процессе, они будут приведены ниже.
Программа установки предварительно должна быть скопирована на сервер wislaserver07 в домашний каталог пользователя wisla. Права на файл должны быть у пользователя wisla, и файл должен быть исполняемым. Далее требуется выполнить действия, которые перечислены в блоке «Перечень действий для установки wiSLA», с учётом отличий в настройках, которые описаны ниже:

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

1. Запуск программы установки.

2. Запуск установки системы.

3. Топология. Потребуется указать топологию, описанную выше в таблице 8:

Application servers: wislaserver03 wislaserver06
Operator Web servers: wislaserver03 wislaserver06
Contractor Web servers: wislaserver03 wislaserver06
Postgres main (single server): wislaserver01
Postgres slaves: wislaserver04
Pgpool servers: wislaserver01 wislaserver04
Zookeeper quorum: wislaserver01 wislaserver02 wislaserver03 wislaserver04 wislaserver05 wislaserver06
wislaserver07
Hadoop/HBase masters: wislaserver02 wislaserver05
Hadoop/HBase workers: wislaserver01 wislaserver02 wislaserver03 wislaserver04 wislaserver05 wislaserver06

4. Ожидание инициализации модулей .

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

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

6. Выбор версии и архитектуры Java Runtime Environment.

7. Настройка компонента Zookeper.

8. Настройка компонента Hadoop:

Name directory: /mnt/glusterVol
Zookeeper quorum: wislaserver01:2181 wislaserver02:2181 wislaserver03:2181 wislaserver04:2181
wislaserver05:2181 wislaserver06:2181 wislaserver07:2181
Replication count: 4

Для настройки «Replication count» используется число, которое высчитывается по формуле:
(HadoopWorkersCount / 2) + 1, где HadoopWorkersCount – количество серверов, заданное в топологии в строке «Hadoop/HBase workers». 

Также стоит отметить, что путь hdfs://wisla. Надо в hosts прописать на 1,3,4,6 сервере 127.0.0.1 wisla. Что-то где-то прибито гвоздями и порт должен быть 8020. wisla:8020 или - wisla не имеет разницы, так как это порт по умолчанию.

9. Настройка компонента HBase, стоит проверить путь к хадупу hdfs://wisla.

10. Настройка компонента PostgreSQL (без изменений). Возможно стоит взять более широкую маску сети(/24) причем раз это сеть, можно адрес сети написать
После шага 10 «Настройка компонента PostgreSQL» появится дополнительный шаг для конфигурирования Pgpool, на котором потребуется задать настройки:

Trust host or network: 192.168.1.0/24
Specifies the virtual IP address: 192.168.1.110
Specifies the netmask for virtual IP address: 255.255.255.0
Virtual interface: eth0

• Trust host or network – подсеть межсерверного взаимодействия.
  
• Specifies the virtual IP address – IP-адрес, который выделен для работы pgpool в подсети межсерверного взаимодействия.
  
• Specifies the netmask for virtual IP address – маска подсети межсерверного взаимодействия.
  
• Virtual interface – корневой интерфейс, на котором настроена подсеть межсерверного взаимодействия на серверах wislaserver01 и wislaserver04. 

Указываем сеть в которой работает СУЩЕСТВУЮЩИЙ интерфейс, и указываем IP который НЕ используется. Также указываем СУЩЕСТВУЮЩИЙ интерфейс. pgpool на него навесит ip (причем ip уже должен быть назначен на всех хостах которые подключены в сеть, куда смотрит интерфейс). возможно стоит взять более широкую маску сети(/24)

a) для корректной работы pgpool желателен отдельный сетевой интерфейс. К примеру он может быть вланом. 
b) pgpool назначает на интерфейс ip, а :10 это номер псевдонима.
c) в сети, на которую смотрит интерфейс должны быть назначены ip в той же подсети.
d) активный pgpool назначает на этот интерфейс ip.
e) если вы обращаетесь к PostgreSQL то должны быть подключены к сети, в которой есть pgpool

11. Настройка компонента WildFly:

• app host for portal ... - пишем соответствующие ip для данных хостов

12. Настройка топологии wiSLA.

13. Настройки модуля сбора данных:

•  wiProbe destination - указываем, куда будут программные или аппаратные зонды стучаться

14. Настройки интеграции LDAP.

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

16. Настройка рассылки уведомлений.

17. Настройка оператора портала.

Обращаем ваше внимание, если вы получаете доступ к порталу с помощью проброса портов или через прокси сервер, то вам необходимо отредактировать пункт HOST и в Whitelisted domains установить необходимые IP-адреса.

18. Подтверждение настроек.

19. Автоматический запуск после установки.

20. Реиндексация wildfly (не бд).

21. Начало работы с порталом.

Настройка скриптов для учёта кратковременных обрывов связи

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

1. Предварительно следует создать каталог /opt/wisla5/scripts/ на серверах ЦОД1 и ЦОД2. Владельцем каталогов должен быть пользователь wisla. На серверах wislaserver03 и wislaserver06 эти каталоги будут созданы автоматически после установки wiSLA. Далее приведена команда для создания каталога:
   

   mkdir -p /opt/wisla5/scripts

   Архив со скриптами можно загрузить по ссылке ftp://ftp.wellink.ru/Deploies/Centos/cluster/failover_scripts.tar.gz, скопировать на любой из серверов кластера для пользователя wisla и распаковать с помощью команды:
   

   tar zxvf failover_scripts.tar.gz

   Владельцем скриптов и конфигурационных файлов должен быть пользователь wisla.
   
2. На сервере wislaserver04 в каталоге /opt/wisla5/pgpool/current/sbin/ переименовать файл ifconfig на ifconfig1 с помощью команды:
   

   sudo mv /opt/wisla5/pgpool/current/sbin/ifconfig /opt/wisla5/pgpool/current/sbin/ifconfig1

   
   
3. Скопировать скрипты на сервера контура.
   Для копирования рекомендуется использовать консольную утилиту scp. Пример команды копирования:
   

   scp TRUSTED_SERVERS wisla@wislaserver01:/opt/wisla5/scripts/

   В примере администратор находится в каталоге с распакованными скриптами, копирует файл
   TRUSTED_SERVERS на сервер wislaserver01 в каталог /opt/wisla5/scripts/.
   Таблица 7 – Размещение скриптов для учёта кратковременных обрывов связи.
   

   Сервер	Файл	Путь
   wislaserver01	TRUSTED_SERVERS	/opt/wisla5/scripts/
   	isolation_test.sh	/opt/wisla5/scripts/
   	pgpool_connect.sh	/opt/wisla5/scripts/
   	DATA_PROCESSING_CENTER_SERVERS	/opt/wisla5/pgpool/current/
   	TRUSTED_SERVERS	/opt/wisla5/pgpool/current/
   	failover.sh	/opt/wisla5/pgpool/current/
   wislaserver02	TRUSTED_SERVERS	/opt/wisla5/scripts/
   	isolation_test.sh	/opt/wisla5/scripts/
   wislaserver03	TRUSTED_SERVERS	/opt/wisla5/scripts/
   	isolation_test.sh	/opt/wisla5/scripts/
   wislaserver04	TRUSTED_SERVERS	/opt/wisla5/scripts/
   	isolation_test.sh	/opt/wisla5/scripts/
   	pgpool_connect.sh	/opt/wisla5/scripts/
   	DATA_PROCESSING_CENTER_SERVERS	/opt/wisla5/pgpool/current/
   	TRUSTED_SERVERS	/opt/wisla5/pgpool/current/
   	failover.sh	/opt/wisla5/pgpool/current/
   	ifconfig	/opt/wisla5/pgpool/current/sbin/
   wislaserver05	TRUSTED_SERVERS	/opt/wisla5/scripts/
   	isolation_test.sh	/opt/wisla5/scripts/
   wislaserver06	TRUSTED_SERVERS	/opt/wisla5/scripts/
   	isolation_test.sh	/opt/wisla5/scripts/

   
   
4. Сконфигурировать файлы со списком серверов и скрипты. Файл должен завершаться пустой строкой. Редакторы vi (vim) и nano делают это автоматически при сохранении файла.
   wislaserver01:
   В файле /opt/wisla5/scripts/TRUSTED_SERVERS указать список серверов ЦОД2 и третью точку опоры:
   

   wislaserver04
   wislaserver05
   wislaserver06
   wislaserver07

   В файле /opt/wisla5/pgpool/current/DATA_PROCESSING_CENTER_SERVERS указать список
   серверов ЦОД1:
   

   wislaserver01
   wislaserver02
   wislaserver03

   В файле /opt/wisla5/pgpool/current/TRUSTED_SERVERS указать третью точку опоры:
   

   wislaserver07

   В конфигурационном файле /opt/wisla5/pgpool/current/etc/pgpool.conf в опции trusted_servers (по умолчанию строка 442) указать сервер с pgpool ЦОД2 и третью точку опоры:
   

   trusted_servers = 'wislaserver04,wislaserver07'

   wislaserver02:
   В файле /opt/wisla5/scripts/TRUSTED_SERVERS указать список серверов ЦОД2 и третью точку опоры:
   

   wislaserver04
   wislaserver05
   wislaserver06
   wislaserver07

   wislaserver03:
   В файле /opt/wisla5/scripts/TRUSTED_SERVERS указать список серверов ЦОД2 и третью точку опоры:
   

   wislaserver04
   wislaserver05
   wislaserver06
   wislaserver07

   wislaserver04:
   В файле /opt/wisla5/scripts/TRUSTED_SERVERS указать список серверов ЦОД1 и третью точку опоры:
   

   wislaserver01
   wislaserver02
   wislaserver03
   wislaserver07

   В файле /opt/wisla5/pgpool/current/DATA_PROCESSING_CENTER_SERVERS указать список серверов ЦОД2:
   

   wislaserver04
   wislaserver05
   wislaserver06

   В файле /opt/wisla5/pgpool/current/TRUSTED_SERVERS указать третью точку опоры:
   

   wislaserver07

   В скрипте /opt/wisla5/pgpool/current/sbin/ifconfig указать (отредактировать) дополнительный IPадрес, который был зарезервирован для работы pgpool:
   

   PGPOOL_ALIAS="192.168.1.110"

   В конфигурационном файле /opt/wisla5/pgpool/current/etc/pgpool.conf в опции trusted_servers (строка 442) указать сервер с pgpool ЦОД1 и третью точку опоры:
   

   trusted_servers = 'wislaserver01,wislaserver07'

   wislaserver05:
   В файле /opt/wisla5/scripts/TRUSTED_SERVERS указать список серверов ЦОД1 и третью точку опоры:
   

   wislaserver01
   wislaserver02
   wislaserver03
   wislaserver07

   wislaserver06:
   В файле /opt/wisla5/scripts/TRUSTED_SERVERS указать список серверов ЦОД1 и третью точку опоры:
   

   wislaserver01
   wislaserver02
   wislaserver03
   wislaserver07

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

   crontab -e

   
   Открывается конфигурация cron для пользователя wisla в редакторе vim.
   wislaserver01:
   

   */1 * * * * /opt/wisla5/scripts/isolation_test.sh
   */1 * * * * /opt/wisla5/scripts/pgpool_connect.sh

   wislaserver02:
   

   */1 * * * * /opt/wisla5/scripts/isolation_test.sh

   wislaserver03:
   

   */1 * * * * /opt/wisla5/scripts/isolation_test.sh

   wislaserver04:
   

   */1 * * * * /opt/wisla5/scripts/isolation_test.sh
   */1 * * * * /opt/wisla5/scripts/pgpool_connect.sh

   wislaserver05:
   

   */1 * * * * /opt/wisla5/scripts/isolation_test.sh

   wislaserver06:
   

   */1 * * * * /opt/wisla5/scripts/isolation_test.sh

   Перезапустить систему, используя программу установки wiSLA – в разделе Maintenance вначале выполнить «Stop all», затем «Start all».

Действия по восстановлению работы кластера при выходе из строя одного из узлов ЦОД1

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

при статусе:

psql -p 19999 -c "show pool_nodes"

node_id | hostname | port | status | lb_weight | role
---------+---------------+------+--------+-----------+---------
0 | wislaserver01 | 5432 | 3 | 0.500000 | standby
1 | wislaserver04 | 5432 | 2 | 0.500000 | primary

1)стопнуть вторую ноду из инсталлера
2)запустить вторую ноду из инсталлера

/opt/wisla5/pgpool/current/bin/pcp_recovery_node -p 9898 -h 10.198.2.17 -U wisla 1
#Password:  wisla

Дождаться выполнения -> все ок

Выход из строя ЦОД1

При выходе из строя ЦОД1 все компоненты переходят в активный режим на ЦОД2:

• Pgpool на сервере wislaserver04 переводит PostgreSQL в режим master и активирует alias на интерфейс на сервере;
  
• Hadoop и HBase на сервере wislaserver05 переходят в режим active;
  
• wiSLA на сервере wislaserver06 забирает себе все задачи, которые ранее были распределены
  между двумя серверами.
  

В данном случае требуется восстановить согласованность данных и перенести активные модули на ЦОД1. Потребуется полная остановка и запуск системы на обоих ЦОД. Для этого нужно выполнить следующие действия:
1. Восстановить связь между узлами кластера.
2. В отдельной сессии SSH на сервере wislaserver07 под пользователем wisla запустить программу установки.
3. В разделе «Maintenance» -> «wiSLA management» остановить wiSLA на всех серверах:

Stop_all

4. В разделе «Maintenance» -> «Pgpool management» запустить Pgpool на сервере wislaserver01:

Start on wislaserver01

5. Убедиться в том, что Pgpool на сервере wislaserver01 активирован. Для этого в разделе «Statuses» выбрать «Pgpool status».
6. В отдельной сессии SSH открыть shell сервера wislaserver04 под пользователем wisla.
7. На сервере wislaserver04 выполнить команду для просмотра состояния узлов PostgreSQL:

psql -p 19999 -c "show pool_nodes"

8. Убедиться в том, что сервер wislaserver04 имеет status «2» (активен) и role «primary», а wislaserver01 имеет status «3» (неактивен) и role «standby»:

node_id | hostname | port | status | lb_weight | role
---------+---------------+------+--------+-----------+---------
0 | wislaserver01 | 5432 | 3 | 0.500000 | standby
1 | wislaserver04 | 5432 | 2 | 0.500000 | primary

9. На сервере wislaserver04 выполнить команду:

ip a

и убедиться в наличии alias «eth0:10» на интерфейсе «eth0» .
10. В отдельной сессии SSH открыть командную строку сервера wislaserver01 под пользователем wisla.
11. На сервере wislaserver01 выполнить команду:

ip a

и убедиться в отсутствии alias «eth0:10» на интерфейсе «eth0».
12. На сервере wislaserver04 выполнить команду:

LD_LIBRARY_PATH=/opt/wisla5/pgpool/current/lib/ pcp_recovery_node -d 0 127.0.0.1 9898 wisla wisla 0

13. Дождаться выполнения команды, должно снова появиться приглашение для ввода.
14. Снова выполнить команду для просмотра состояния узлов PostgreSQL и убедиться в том, что сервер wislaserver01 уже имеет status «2» (активен) и role «primary», а wislaserver04 сохранил status «2» (активен), но изменил role на «standby».

[wisla@wislaserver04 ~]$ psql -p 19999 -c "show pool_nodes"
node_id | hostname | port | status | lb_weight | role
---------+---------------+------+--------+-----------+---------
0 | wislaserver01 | 5432 | 2 | 0.500000 | primary
1 | wislaserver04 | 5432 | 2 | 0.500000 | standby

15. В открытой программе установки остановить Pgpool на сервере wislaserver04. Для этого в разделе «Maintenance» -> «Pgpool management» выполнить:

Stop on wislaserver04

16. В открытой программе установки остановить PostgreSQL на сервере wislaserver04. Для этого в разделе «Maintenance» -> «Postgresql management» выполнить:

Stop on wislaserver04

17. В открытой программе установки запустить Pgpool на сервере wislaserver04. Для этого в разделе «Maintenance» -> «Pgpool management» выполнить:

Start on wislaserver04

18. Убедиться в том, что Pgpool на сервере wislaserver04 активирован. Для этого в разделе «Statuses» выбрать «Pgpool status».
19. На сервере wislaserver04 выполнить команду:

ip a

и убедиться в отсутствии alias «eth0:10» на интерфейсе «eth0».
20. На сервере wislaserver01 выполнить команду:

ip a

и убедиться в наличии alias «eth0:10» на интерфейсе «eth0».
21. На сервере wislaserver01 выполнить команду для просмотра состояния узлов PostgreSQL и убедиться в том, что сервер wislaserver01 имеет status «2» (активен) и role «primary», а wislaserver04 имеет status «3» (неактивен) и role «standby».

[wisla@wislaserver01 ~]$ psql -p 19999 -c "show pool_nodes"
node_id | hostname | port | status | lb_weight | role
---------+---------------+------+--------+-----------+---------
0 | wislaserver01 | 5432 | 2 | 0.500000 | primary
1 | wislaserver04 | 5432 | 3 | 0.500000 | standby

22. На сервере wislaserver01 выполнить команду (обратить внимание на замену числа 0 на 1 в конце команды):

LD_LIBRARY_PATH=/opt/wisla5/pgpool/current/lib/ pcp_recovery_node -d 0 127.0.0.1 9898 wisla wisla 1

23. Дождаться выполнения команды, должно снова появиться приглашение для ввода.
24. На сервере wislaserver01 повторно выполнить команду для просмотра состояния узлов PostgreSQL и убедиться в том, что сервер wislaserver01 сохранил status «2» (активен) и role «primary», а wislaserver04 изменил status на «2» (активен), role осталась «standby».

[wisla@wislaserver01 ~]$ psql -p 19999 -c "show pool_nodes"
node_id | hostname | port | status | lb_weight | role
---------+---------------+------+--------+-----------+---------
0 | wislaserver01 | 5432 | 2 | 0.500000 | primary
1 | wislaserver04 | 5432 | 2 | 0.500000 | standby

25. На сервере wislaserver04 выполнить команду:

tail -n 10 /home/wisla/postgresql/postgres.log

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

database system is ready to accept read only connections

26. В отдельной сессии SSH открыть командную строку сервера wislaserver02 под пользователем root.
27. На сервере wislaserver02 выполнить команды:

systemctl start glusterd  #/etc/init.d/glusterd start
mount -t glusterfs wislaserver05:/namenodevol /mnt/glusterVol/

28. На сервере wislaserver02 убедиться в наличии непустого каталога /mnt/glusterVol/current/ 

ls /mnt/glusterVol/current/

29. В открытой программе установки в разделе «Maintenance» -> «HBase management» выполнить остановку HBase на всех серверах:

Stop_all

30. В открытой программе установки в разделе «Maintenance» -> «Hadoop management» выполнить остановку Hadoop на всех серверах:

Stop_all

31. В открытой программе установки в разделе «Maintenance» -> «Zookeeper management» выполнить остановку Zookeeper на всех серверах:

Stop_all

32. В открытой программе установки в разделе «Maintenance» -> «Zookeeper management» выполнить запуск Zookeeper на всех серверах:

Start_all

33. В открытой программе установки в разделе «Maintenance» -> «Hadoop management» выполнить запуск Hadoop на всех серверах:

Start_all

34. В открытой программе установки в разделе «Maintenance» -> «HBase management» выполнить запуск HBase на всех серверах:

Start_all

35. В открытой программе установки в разделе «Maintenance» -> «wiSLA management» выполнить запуск wiSLA на всех серверах:

Start_all

36. После запуска wiSLA проверить состояние компонентов системы в разделе «Statuses» -> «All statuses» и убедиться в работоспособности портала wiSLA.

Действия по восстановлению работы кластера при выходе из строя одного из узлов ЦОД2

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

Выход из строя ЦОД2

При выходе из строя ЦОД2 все компоненты остаются в активном режиме работы на ЦОД1. В данном случае требуется восстановить согласованность данных и восстановить работу системы на ЦОД2. Потребуется полная остановка и запуск системы на обоих ЦОД. Для этого нужно выполнить следующие действия:
1. Восстановить связь между узлами кластера.
2. В отдельной сессии SSH на сервере wislaserver07 под пользователем wisla запустить программу установки.
3. В разделе «Maintenance» -> «wiSLA management» остановить wiSLA на всех серверах:

Stop_all

4. В разделе «Maintenance» -> «Pgpool management» запустить Pgpool на сервере wislaserver04:

 Start on wislaserver04

5. Убедиться в том, что Pgpool на сервере wislaserver04 активирован. Для этого в разделе «Statuses» выбрать «Pgpool status».
6. В отдельной сессии SSH открыть командную строку сервера wislaserver01 под пользователем wisla.
7. На сервере wislaserver01 выполнить команду для просмотра состояния узлов PostgreSQL:

psql -p 19999 -c "show pool_nodes"

8. Убедиться в том, что сервер wislaserver01 имеет status «2» (активен) и role «primary», а wislaserver04 имеет status «3» (неактивен) и role «standby»:

node_id | hostname | port | status | lb_weight | role
---------+---------------+------+--------+-----------+---------
0 | wislaserver01 | 5432 | 2 | 0.500000 | primary
1 | wislaserver04 | 5432 | 3 | 0.500000 | standby

9. На сервере wislaserver01 выполнить команду:

ip a

и убедиться в наличии alias «eth0:10» на интерфейсе «eth0» .
10. В отдельной сессии SSH открыть командную строку сервера wislaserver04 под пользователем wisla.
11. На сервере wislaserver04 выполнить команду:

ip a

и убедиться в отсутствии alias «eth0:10» на интерфейсе «eth0».
12. На сервере wislaserver01 выполнить команду:

LD_LIBRARY_PATH=/opt/wisla5/pgpool/current/lib/ pcp_recovery_node -d 0 127.0.0.1 9898 wisla wisla 1

13. Дождаться выполнения команды, должно снова появиться приглашение для ввода.
14. На сервере wislaserver01 снова выполнить команду для просмотра состояния узлов PostgreSQL и убедиться в том, что сервер wislaserver01 сохранил status «2» (активен) и role «primary», а wislaserver04 изменил status на «2» (активен), role осталась «standby».

[wisla@wislaserver01 ~]$ psql -p 19999 -c "show pool_nodes"
node_id | hostname | port | status | lb_weight | role
---------+---------------+------+--------+-----------+---------
0 | wislaserver01 | 5432 | 2 | 0.500000 | primary
1 | wislaserver04 | 5432 | 2 | 0.500000 | standby

15. На сервере wislaserver04 выполнить команду:

ip a

и убедиться в отсутствии alias «eth0:10» на интерфейсе «eth0».
16. На сервере wislaserver01 выполнить команду:

ip a

и убедиться вналичии alias «eth0:10» на интерфейсе «eth0» .
17. На сервере wislaserver04 выполнить команду:

tail -n 10 /home/wisla/postgresql/postgres.log

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

database system is ready to accept read only connections

18. В отдельной сессии SSH открыть командную строку сервера wislaserver05 под пользователем root.
19. На сервере wislaserver05 выполнить команды:

systemctl start glusterd #/etc/init.d/glusterd start
mount -t glusterfs wislaserver02:/namenodevol /mnt/glusterVol/

20. На сервере wislaserver05 убедиться в наличии непустого каталога /mnt/glusterVol/current/

ls /mnt/glusterVol/current/

21. В открытой программе установки в разделе «Maintenance» -> «HBase management» выполнить остановку HBase на всех серверах:

Stop_all

22. В открытой программе установки в разделе «Maintenance» -> «Hadoop management» выполнить остановку Hadoop на всех серверах:

Stop_all

23. В открытой программе установки в разделе «Maintenance» -> «Zookeeper management» выполнить остановку Zookeeper на всех серверах:

Stop_all

24. В открытой программе установки в разделе «Maintenance» -> «Zookeeper management» выполнить запуск Zookeeper на всех серверах:

Start_all

25. В открытой программе установки в разделе «Maintenance» -> «Hadoop management» выполнить запуск Hadoop на всех серверах:

Start_all

26. В открытой программе установки в разделе «Maintenance» -> «HBase management» выполнить запуск HBase на всех серверах:

Start_all

27. В открытой программе установки в разделе «Maintenance» -> «wiSLA management» выполнить запуск wiSLA на всех серверах:

Start_all

28. После запуска wiSLA проверить состояние компонентов системы в разделе «Statuses» -> «All statuses» и убедиться в работоспособности портала wiSLA.

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

Данная ситуация не влияет на работоспособность контура, но грозит отказом системы в случае выхода из строя одного из ЦОД. Для восстановления работы третьей точки опоры требуется выполнить следующие действия:
1. Восстановить связь между узлами кластера.
2. На сервере wislaserver07 запустить программу установки.
3. В разделе «Maintenance» -> «Zookeeper management» запустить Zookeeper на сервере wislaserver07: 

Start on wislaserver07

4. Проверить состояние компонентов системы в разделе «Statuses» -> «All statuses» и работоспособность wiSLA.

8. wiSLA  В ИЗОЛИРОВАННОМ КОНТУРЕ

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

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

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

Настройки могут быть выполнены при первичной установке wiSLA или в процессе эксплуатации. Они задаются в программе установки wiSLA. Перед выполнением настроек следует:

• принять решение, будет ли использоваться локальный геокодер. Если да – выполнить его
  установку и настройку;
  
• принять решение, будет ли использоваться локальный карт-сервер. Если да – выполнить его
  установку и настройку.

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

Переключение wiSLA в изолированный режим

Все связанные с облачным режимом настройки находятся в программе установки на вкладке «wiSla
resources configuration».

Параметр «Local geo services» определяет тип контура:

• true – для закрытого контура,
  
• false – для открытого контура.
  

Параметр «Nominatim service URL» предоставляет возможность работы с произвольным Nominatimсервером. Используется для определения координат по адресу в изолированном контуре. Данная настройка игнорируется для открытого контура, если значение задано. Пример значения: «http://map.wellink.ru/nominatim/».

Параметр «URL to tiles for map» – путь к изображениям карты. Например, «http://map.wellink.ru/osm_tiles/».

Для переключения wiSLA в изолированный режим требуется:

• запустить программу установки (подробно запуск рассматривается в разделе «Работа с программой установки», а внесение изменений – в «Изменение одного или нескольких параметров wiSLA»);
  
• в режиме «Config Update» перейти на вкладку «wiSLA Resources Configuration»;
  
• изменить значения параметров «Local geo services», «Nominatim service URL», «URL to tiles for map»;
  
• выполнить остановку и запуск wiSLA.
  

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

• авторизоваться на портале оператора с учётной записью системного администратора;
  
• перейти в раздел «Точки доступа»;
  
• нажать «+ Точка доступа». Вместо поля «Адрес» должны быть доступны для ввода «Область», «Город», «Улица», «Дом»;
  
• заполнить поля корректными тестовыми данными. Проверить получение координат в случае если был настроен локальный геокодер или ввести координаты вручную – в противном случае;
  
• сохранить настройки точки доступа. Проверить факт появления новой точки доступа в общем списке;
  
• если был настроен локальный карт-сервер, перейти в раздел «Карта сервисов», изменить масштаб карты.
  

При успешном появлении точки доступа в общем списке на странице «Точки доступа» переключение
wiSLA в изолированный режим считается выполненным корректно.

При успешном открытии карты сервисов после изменения в настройках адреса карт-сервера на локальный настройка карт-сервера считается выполненной успешно. Если же карта сервисов не открывается, на странице возникают ошибки, или масштаб невозможно изменить следует проверить корректность значения параметра «URL to tiles for map», доступность и работоспособность самого картсервера на рабочем месте администратора.

При успешном получении координат в настройках точки доступа после изменения адреса геосервиса настройка геосервиса считается выполненной успешно. Если введённый адрес корректен, а координаты не определяются, следует повторить попытку с другим адресом. Если в обоих случаях система не смогла определить координаты, следует проверить корректность значения параметра «Local geo services», доступность и работоспособность локального геосервиса на рабочем месте администратора.

Внимание, если не устанавливать URL для Nominatim - то можно задавать адрес вручную, но поиск не будет работать.

9. ОБЛАЧНЫЙ РЕЖИМ

Особенности облачного режима

ПАК wiSLA может работать как облачная платформа, предоставляющая услуги мониторинга малому и среднему бизнесу (SME).

Если портал развёрнут в режиме wiSLA.Cloud:

• у новых пользователей есть возможность пройти регистрацию самостоятельно;
  
• при регистрации нового пользователя в случае совпадения названия компании с существующей в базе пользователь может запросить доступ на портал у системного администратора;
  
• число действий системного администратора по добавлению пользователя по запросу сведено к минимуму;
  
• новые пользователи, которые прошли регистрацию, создаются с ролями «Пользователь» + «Оператор SLA»;
  
• учётные записи и контрагенты с неподтверждённой в течение 48 часов регистрацией удаляются. Периодичность поиска таких записей настраивается;
  
• на странице «Зонды» есть кнопка для загрузки программного агента;
  
• администратор может изменять набор программных агентов для загрузки;
  
• сервис может быть добавлен со страницы зонда, если зонд не в архиве, и его настройки были сохранены ранее;
  
• возможна интеграция с внешними системами веб-аналитики (например, Яндекс-метрикой, Convead);
  
• функционал топологии сети недоступен.
  

Включение и настройка облачного режима

Все связанные с облачным режимом настройки находятся в программе установки на вкладке «wiSLA Cloud System».

За активацию режима облачной системы отвечает параметр «Enable wiSLA cloud». Принимает значения: true (облачный режим) или false (стандартный режим).

Интервал запуска процедуры поиска учётных записей и контрагентов, не завершивших регистрацию в течение 48 часов, определяется параметром «Registrations attempts check interval» на вкладке «wiSLA Cloud System», принимает целое значение в минутах.

Адрес электронной почты администратора, на который будут приходить письма о запросе доступа, задаётся параметром «Support email». Значением может быть один адрес электронной почты.

Интеграцию с внешним сервисом веб-аналитики можно включить в «Third-party scripts enabled» (true – включена, false – выключена), указать путь к xml-файлу настроек интеграции (скрипту) – в «Path to thirdparty scripts xml». Скрипт можно получить в службе технической поддержки.

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

• запустить программу установки (подробно запуск рассматривается в разделе «Работа с программой установки», а внесение изменений – в «Изменение одного или нескольких параметров wiSLA»);
  
• в режиме «Config Update» перейти на вкладку «wiSLA Cloud System»;
  
• задать параметры;
  
• продолжить процедуру обновления;
  
• выполнить перезапуск wiSLA.
  

На рисунке 67 показан пример настройки wiSLA Cloud.

Рис. 67 Пример заполнения параметров на вкладке wiSLA Cloud System

В примере после применения настроек:

• будет включен режим wiSLA Cloud;
  
• пользователи и контрагенты, не подтвердившие регистрацию в течение 48 часов, будут удаляться. Интервал проверки составит 30 минут;
• запросы на добавление учётных записей будут отсылаться на адрес admin@thecompany.com;
  
• статистика посещения страниц будет отслеживаться;
  
• параметры интеграции с внешним сервисом веб-аналитики для отслеживания статистики заданы в файле /home/wiSLA/CloudServices.xml.

Подготовка ссылок на программные агенты

Как было отмечено, пользователи в облачном режиме wiSLA могут загружать программные агенты для создания собственной инфраструктуры без помощи системного администратора. Загрузка проводится на странице «Справка», для этого предусмотрена кнопка «Загрузить Агент». Или на вкладке "Зонды", по кнопке "Скчать зонд". Список агентов, который получит пользователь портала после нажатия этой кнопки, зависит от настроек, выполненных на сервере wiSLA.

Для корректного формирования этого списка требуется:

• получить и подготовить к копированию актуальные файлы программных агентов wiProbe;
  
• скопировать файлы на сервер wiSLA;
  
• изменить владельца файлов на «wisla», группа «wisla»;
  
• проследить, чтобы у владельца были права на чтение;
  
• для linux-агентов снять разрешение на исполнение, если оно появилось при копировании;
  
• находясь на сервере, файлы следует перенести в каталог /opt/wisla5/wildfly/current/wisla_program_agents;
  
• в каталоге создать текстовый файл index со ссылками на файлы. Пример файла показан ниже;
  
• сохранить файл index. Перезапуск wiSLA не требуется. Если изменения не применились, выполнить выход и вход на портал;
  
• рекомендуется проверить работоспособность ссылок и загруженных файлов после применения настроек.

Пример файла index:

{
"Windows":"alfa-test2-win_slamon-agent-win-1.12.62271.exe",
"Linux":"",
"Fedora 19 | x32":"",
"Fedora 19 | x64":"",
"Debian 6 | x32":"",
"Debian 6 | x64":"alfa-test2_slamon_1.12.62271_x86_64.deb",
"CentOS 6.4 | x32":"",
"CentOS 6.4 | x64":"alfa-test2_slamon-1.12.62271.x86_64.rpm",
"Ubuntu 12.04 | x32":"",
"Ubuntu 12.04 | x64":"alfa-test2_slamon_1.12.62271_x86_64.deb"
}

В примере сделаны записи для появления ссылок на программные агенты для Windows, Linux rpm, RedOS, Astra Linux, Debian. На рисунке 68 показан результат настройки на портале.

Рис. 68 Список агентов на портале оператора после настройки

10. ПОДГОТОВКА АГЕНТА ДЛЯ АВТОМАТИЧЕСКОГО СКАНИРОВАНИЯ СЕТИ

Сканирование сети выполняется для получения списка устройств с их IP-адресами для топологии сети, чтобы не создавать устройства вручную. Агентом для сканирования сети может быть любой сервер, виртуальная машина, зонд или иное устройство, работающее под управлением Unix-совместимой операционной системы, на которое можно установить пакеты, которые обеспечат сканирование. Устройство должно иметь возможность приёма команд с удалённого сервера по протоколу SSH.

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

• zmap (https://github.com/zmap/zmap, требует отдельной загрузки и установки, на Red Hat-подобных ОС входит в состав EPEL – epel-release). Получает список IP-адресов;
  
• arp (в составе пакета net-tools, обычно входит в состав дистрибутива ОС). Позволяет сопоставить списку IP-адресов MAC-адреса;
  
• nmblookup (в составе пакета samba4-client, обычно входит в состав дистрибутива ОС). Получает сетевые идентификаторы NetBIOS.
  

Установка проводится в соответствии с руководством администратора соответствующей операционной системы.

Задания на сканирование подсетей поступают с сервера приложений wiSLA на агент в виде команд по протоколу SSH, выполняются с sudo и требуют привилегий администратора. Пользователь, под которым будет происходить подключение для запуска сканирования, должен входить в sudoers и иметь возможность выполнения команд с повышенными привилегиями без ввода пароля.

После установки требуется настроить утилиту zmap. Обычно по умолчанию в ней отключено сканирование локальных подсетей. Для включения достаточно найти файл настроек zmap (как правило, это /etc/zmap/blacklist.conf), закомментировать строки, по которым планируется сканирование или добавить собственные правила. В случае проблем с установкой или настройкой zmap обратитесь в
службу технической поддержки.

В сети может работать несколько таких агентов. Администратор может проводить сканирование, последовательно меняя настройки сканирования на портале оператора в разделе «Топология сети».

11. ПОДГОТОВКА СЕНСОРА NETFLOW

Сенсор Netflow используется в работе теста Netflow, который предоставляет возможность анализа сетевого трафика на уровне сеансов, делая запись о каждой транзакции TCP/IP. Сенсор представляет собой устройство, собирающее статистику по проходящему через него трафику. Собранные данные отправляются в формате Netflow 5 на коллектор Netflow.

Сенсор может быть развёрнут на оборудовании под управлением Unix-совместимой операционной системы, через которое проходит трафик, и которое позволяет установить пакеты fprobe и tcpdump. Брандмауэр должен позволять исходящие соединения на порт UDP 9996. Пользователь должен входить в sudoers и иметь возможность выполнения команд с повышенными привилегиями без ввода пароля.

Подготовка сенсора к работе

1) Выяснить IP-адрес коллектора Netflow

 Адрес такой же, как у сервера приложений wiSLA. Запуск коллектора описан в разделе «Действия по обслуживанию wiSLA»;

2) Установить пакет fprobe.

Для установки рекомендуется обратиться к руководству администратора соответствующей операционной системы. Примеры команды для rpm-совместимых дистрибутивов Linux:

2.1 Для Debian/Ubuntu/Astra, deb-совместимых дистрибутивов Linux:

 2.1.1 Обновите список пакетов: 

$ sudo apt update

2.1.2 Установите fprobe (для Debian/Ubuntu, deb-совместимых дистрибутивов Linux):

$ sudo apt install fprobe

2.2 Для CentOS/RHEL:

2.2.1 Установите EPEL-репозиторий (если еще не установлен):

$ sudo yum install epel-release

2.2.2 Установите fprobe:

$ sudo yum install fprobe

или

$ sudo dnf install fprobe

3) Настройка ftprobe

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

3.1 Для Debian/Ubuntu/Astra

3.1.1 Откройте файл конфигурации:

$ sudo nano /etc/default/fprobe

3.1.2 Приведите файл к следующему виду:

# fprobe default configuration file

INTERFACE="eth0"                     # Интерфейс для мониторинга (например, eth0)
FLOW_COLLECTOR="192.168.1.100:9996"  # Адрес коллектора (IP и порт-9996)

# Дополнительные параметры (опционально)
OTHER_ARGS="-fip"

где:

• INTERFACE: Укажите интерфейс, который нужно мониторить. Если нужно мониторить все интерфейсы, укажите any.
• FLOW_COLLECTOR: Укажите IP-адрес и порт коллектора (сервер wiSLA).
• OTHER_ARGS указывает прочие опции.
  • Например, можно перехватывать только IP-пакеты, указав "-fip";

3.1.3 Сохраните файл и выйдите из редактора (в nano: Ctrl+O, затем Ctrl+X).

3.1.4 В случае внесении корректировок в файл при запущенном ftprobe, чтобы применить настройки, необходимо перезапустить fprobe.

3.2 Для CentOS/RHEL:

3.2.1 Откройте файл конфигурации:

$ sudo nano /etc/sysconfig/fprobe

3.2.2 Приведите файл к следующему виду:

OPTIONS="-ieth0 -B4096 -r2 -q10000 -t10000:10000000 192.168.1.100:9996"

где:

• -ieth0: Интерфейс для мониторинга (например, eth0).

• 192.168.1.100:9996: Адрес коллектора (IP и порт).

3.2.3 Сохраните файл и выйдите из редактора.

4) Запуск и управление ftprobe

• Для Debian/Ubuntu/Astra:

  sudo systemctl start fprobe

• Для CentOS/RHEL:

  sudo service fprobe start

5) Автозапуск при загрузке системы:

• Для Debian/Ubuntu/Astra:

  sudo systemctl enable fprobe

• Для CentOS/RHEL:

  sudo chkconfig fprobe on

5) Проверка статуса fprobe:

• Для Debian/Ubuntu/Astra:

  sudo systemctl status fprobe

• Для CentOS/RHEL:

  sudo service fprobe status

Дополнительно:

Остановка fprobe:

• Для Debian/Ubuntu/Astra:

  sudo systemctl stop fprobe

• Для CentOS/RHEL:

  sudo service fprobe stop

Перезапуск fprobe:

• Для Debian/Ubuntu/Astra:

  sudo systemctl restart fprobe

• Для CentOS/RHEL:

  sudo service fprobe restart

Проверка что fprobe установлен:

which fprobe

Если команда возвращает путь (например, /usr/sbin/fprobe), значит, fprobe установлен. 

Иные команды для управления службой fpobe

Запуск сенсора:

$ /etc/init.d/fprobe start

Остановка сенсора:

$ /etc/init.d/fprobe stop

Перезапуск сенсора:

$ /etc/init.d/fprobe restart

Пример файла настройки fprobe:

• В deb-совместимых дистрибутивах Linux
  

Расположение: /etc/default/fprobe

#fprobe default configuration file
INTERFACE="eth0"
FLOW_COLLECTOR="192.168.1.10:9996"
#fprobe can't distinguish IP packet from other (e.g. ARP)
OTHER_ARGS="-fip"

• В rpm-совместимых дистрибутивах Linux
  

Расположение: /etc/sysconfig/fprobe

OPTIONS="-ieth0 -B4096 -r2 -q10000 -t10000:10000000 192.168.1.10:9996 -fip"

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

Проверка отправки данных на коллектор:

1. На сервере коллектора (wiSLA), с помощью утилиты tcpdump, выполните команду:

   $ sudo tcpdump -nni any udp and port 9996

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

   18:57:41.010226 IP 192.168.1.10.52861 > 192.168.1.100.9996: UDP, length 120

2. На сервере с fprobe проверьте, отправляются ли данные:

   $ sudo netstat -tunap | grep fprobe

   Или:

   $ sudo ss -tunap | grep fprobe

Полное удаление fprobe на линукс: sudo apt-get purge fprobe

По итогу

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

12. РАСЧЕТ АППАРАТНОЙ ЧАСТИ WISLA

Расчет аппаратной части промышленного контура wiSLA

РАСЧЕТ АППАРАТНОЙ ЧАСТИ ПРОМЫШЛЕННОГО КОНТУРА WISLA БЕЗ УЧЁТА ОТКАЗОУСТОЙЧИВОСТИ

Сервера для контура различаются по своему функциональному назначению:

1. Demo Server (демонстрационный сервер). Для тестово-демонстрационных целей на новых площадках. Не более 50 сервисов (~600 тестов, ~3000 метрик).

     2. Standalone Server Base (сервер «Всё в одном» для средних нагрузок) + NoSQL Server (Hbase) + SQL Server (PostgreSQL). Полный набор необходимых приложений для «не кластерной» установки. Не более 300 сервисов (~1800 тестов, ~18000 метрик).

     3. Standalone Server High-Performance (сервер «Всё в одном» для высоких нагрузок) + NoSQL Server (Hbase) + SQL Server (PostgreSQL). Полный набор необходимых приложений для «не кластерной» установки. Не более 1000 сервисов (~6000 тестов, ~60000 метрик).

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

Опционально: Backup server. Рекомендуется предусмотреть сервер для хранения резервных копий. От 1 ТБ до ~2 ТБ в зависимости от срока хранения, частоты съема резервных копий, глубины хранения данных.

Аппаратные конфигурации на каждый тип сервера:

• Тип 1: Demo Server:
  • CPU: 4 core;
  • RAM: 16 Гбайт;
  • HDD: 500 Гбайт (no RAID);
  • OS: Astra Linux 1.7+ (Или на архитектуре Debian, RHEL).
• Тип 2: Standalone Server Base:
  • CPU: 6 core;
  • RAM: 20 Гбайт;
  • HDD: 1 Тбайт (no RAID);
  • OS: Astra Linux 1.7+ (Или на архитектуре Debian, RHEL).
• Тип 3: Standalone Server High-Performance:
  • CPU: 12 core;
  • RAM: 64 Гбайт;
  • HDD: 2 Тбайт (no RAID);
  • OS: Astra Linux 1.7+ (Или на архитектуре Debian, RHEL).

РАСЧЕТ АППАРАТНОЙ ЧАСТИ ПРОМЫШЛЕННОГО КОНТУРА WISLA С УЧЁТОМ ОТКАЗОУСТОЙЧИВОСТИ

1. Кластерное решение для средних нагрузок (4 сервера для развертывания (2+2))
   

• 2 сервера для развертывания: (Application Server (сервера приложений JBoss) + NoSQL Server (Hbase. (Включает в себя HBase Master и Region Server))
  APP. Выполняет основную бизнес-логику системы, от сбора данных до расчета отчетов SLA. Обрабатывает запросы пользователей.     
  NoSQL. Сервер выполняет функции контроллера и хранилища для больших объемов данных, поступающих от измерительных устройств, представленных значениями метрик.
  
• 2 сервера для развертывания: (Application Server (сервера приложений JBoss) + SQL Server (PostgreSQL))
  APP. Выполняет основную бизнес-логику системы, от сбора данных до расчета отчетов SLA. Обрабатывает запросы пользователей.     
  SQL. Сервер осуществляет хранение инфраструктуры системы, а также некоторых рассчитываемых данных (статусы сервисов, состояние паспорта неисправности, отчеты SLA).
  Не более 5 000 сервисов (~30 000 тестов, ~300 000 метрик).

     2. Кластерное решение для высоких нагрузок (6 серверов для развертывания (4+2))

• 4 сервера для развертывания: (Application Server (сервера приложений JBoss) + NoSQL Server (Hbase. Включает в себя HBase Master и Region Server))
  APP. Выполняет основную бизнес-логику системы, от сбора данных до расчета отчетов SLA. Обрабатывает запросы пользователей.     
  NoSQL. Сервер выполняет функции контроллера и хранилища для больших объемов данных, поступающих от измерительных устройств, представленных значениями метрик.
  
• 2 сервера для развертывания: (Application Server (сервера приложений JBoss) + SQL Server (PostgreSQL))
  APP. Выполняет основную бизнес-логику системы, от сбора данных до расчета отчетов SLA. Обрабатывает запросы пользователей.     
  SQL. Сервер осуществляет хранение инфраструктуры системы, а также некоторых рассчитываемых данных (статусы сервисов, состояние паспорта неисправности, отчеты SLA).
  Не более 10 000 сервисов (~60 000 тестов, ~600 000 метрик).
  Конфигурации более 10 000 сервисов подлежат дополнительному проектированию. В зависимости от типа производимых измерений, оптимальные аппаратные конфигурации могут быть изменены.

Опционально: Backup server. Рекомендуется предусмотреть сервер для хранения резервных копий.
От 1 ТБ до ~10 ТБ в зависимости от срока хранения, частоты съема резервных копий, глубины хранения данных. 

Аппаратные конфигурации на каждый тип сервера:

• Тип 4: Кластерное решение для средних нагрузок (4 сервера для развертывания (2+2))
  • 2 сервера: APP + NoSQL:
    • CPU: 16 core;
    • RAM: 32 Гбайт;
    • HDD: 3 Тбайт (RAID 10);
    • OS: Astra Linux 1.7+ (Или на архитектуре Debian, RHEL).
  • 2 сервера: APP + SQL:
    • CPU: 16 core;
    • RAM: 64 Гбайт;
    • HDD: 2 Тбайт (RAID 10);
    • OS: Astra Linux 1.7+ (Или на архитектуре Debian, RHEL).
      

• Тип 5: Кластерное решение для высоких нагрузок (6 серверов для развертывания (4+2))
  • 4 сервера: APP + NoSQL:
    • CPU: 16 core;
    • RAM: 32 Гбайт;
    • HDD: 3 Тбайт (RAID 10);
    • OS: Astra Linux 1.7+ (Или на архитектуре Debian, RHEL).
  • 2 сервера: APP + SQL:
    • CPU: 16 core;
    • RAM: 64 Гбайт;
    • HDD: 2 Тбайт (RAID 10);
    • OS: Astra Linux 1.7+ (Или на архитектуре Debian, RHEL).
      

ЗАКЛЮЧЕНИЕ
Приведенные выше расчеты являются рекомендуемыми и носят справочный характер. В рамках отдельных проектов параметры и конфигурация промышленного контура могут отличаться.
Аппаратные конфигурации приводятся исходя из рекомендаций руководств по эксплуатации, используемых в системе продуктов (Java, JBoss, PostgreSQL, Hbase).

13. ВАЖНАЯ ИНФОРМАЦИЯ

О документе

© 2025 ООО “НТЦ Веллинк”. Все права защищены.

Компания ООО “НТЦ Веллинк” оставляет за собой право в одностороннем порядке без какого-либо специального уведомления, без согласия Пользователя в любое время вносить улучшения и/или изменения в продукты и/или программное обеспечение, дополнять и/или изменять настоящий документ. Новая редакция документа вступает в силу с момента ее размещения в Базе знаний компании ООО “НТЦ Веллинк” по адресу info.wellink.ru. Убедитесь, что Вы читаете последнюю актуальную версию настоящего документа.

Были предприняты максимальные усилия для того, чтобы гарантировать полноту и точность представленной в документе информации. ООО “НТЦ Веллинк” не несет ответственности за возможные описки и неточности.
Использование Пользователем продукта и/или программного обеспечение после любых изменений и/или улучшений означает его согласие с такими изменениями и/или улучшениями.

Если у вас есть замечания, касающиеся данного документа или продуктов, которые он описывает, направляйте их по адресу support@wellink.ru.

О компании

ООО “НТЦ Веллинк” (www.wellink.ru) разрабатывает инновационные продукты и решения в области автоматизации и управления качеством информационных и телекоммуникационных услуг для операторов связи, государственного и корпоративного сегментов.

wiSLA, wiProbe, wiTest — являются официально зарегистрированными торговыми марками компании ООО “НТЦ Веллинк”, имеют все необходимые сертификаты и защищены авторским правом.

ООО “НТЦ Веллинк” оказывает услуги по внедрению, сопровождению и улучшению своих продуктов согласно требованиям заказчика. При внедрении своих продуктов ООО “НТЦ Веллинк” опирается на обширную партнерскую сеть, которая непрерывно развивается на территории Российской Федерации и за ее пределами. Сервисный центр компании ООО “НТЦ Веллинк” готов оказывать услуги технической поддержки высокого качества в режиме 24х7.

Девиз ООО “НТЦ Веллинк”: Гибкость в отношениях, Инновации в разработке, Простота в использовании. Мы открыты для партнерства и интеграции. Мы делаем услуги измеримыми не только по цене, но и по качеству!
Головной офис компании находится по адресу: 127322, Москва, ул. Яблочкова, д.21, корп.3 тел./факс: +7 (495) 374-66-78

Интернет-сайт: www.wellink.ru