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

Продукт: wiSLA
Версия: 5.2.17
Дата обновления документа: 10.07.26 г.

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

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

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

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

Предварительные условия
Аппаратные требования (минимальные/рекомендуемые)

Минимальные:

Рекомендуемые:

Поддерживаемые операционные системы

Система wiSLA поддерживает развертывание на серверах со следующими 64-битными (x86_64) операционными системами:

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

Зависимости
Требования к браузерам для работы с веб-порталом

Для корректной работы с веб-интерфейсом (порталом) wiSLA используйте актуальные версии браузеров:

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

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

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

Описание Адреса источников Адрес назначения Протокол Порт назначения
web portal access clients (lan) wisla-01 TCP 8080,8443,80,443
Utest agent agent UDP 8787
TWAMP agent agent UDP 10862
telnet wisla-01 agent TCP 5555
UDP agent-server agent-client UDP 5001
MTU agent-server agent-client UDP 5002
SNMP wisla-01 snmp UDP 161
agent-to-wisla agent wisla-01 TCP 8080,8443,80,443
1. УСТАНОВКА И ОБНОВЛЕНИЕ WISLA

Инструкция по ручному развертыванию Kafka для Wisla

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

Этап 1. Переход под пользователя wisla:

На первом этапе  необходимо перейти под пользователя Wisla используя команду:

sudo su - wisla
Если пользователь wisla еще не существует в системе его необходимо создать используя следующие команды пошагово.

1.Команда создания пользователя:

sudo useradd -d /home/wisla -m -s /bin/bash wisla

2.Команда установки пароля:

sudo passwd wisla

3.Добавление пользователя в файлы sudoers:

echo "wisla    ALL=(ALL:ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/wisla

4.Настройка системных лимитов для пользователя wisla:

# Создаем файл лимитов
cat > /etc/security/limits.d/wisla << 'EOF'
wisla   soft      nofile  32768
wisla   hard     nofile  32768
wisla   soft      nproc   32768
wisla   hard     nproc   32768
EOF

5. Добавляем в PAM (если нет):

echo "session required pam_limits.so" >> /etc/pam.d/common-session

 

Этап 2. Подготовка каталога kafka.

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


1.Создание директории в /opt/:

sudo mkdir -p /opt/kafka

 2.Проверить кому принадлежит каталог kafka:

ls -l /opt/

3.Сменить пользователя для каталога kafka если принадлежит не wisla используя следующую команду:

sudo chown wisla:wisla /opt/kafka

Этап 3. Копирование архива Java:

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

1.Скопируем его в домашнюю директорию wisla используя следующую команду:

cp OpenJDK17U-jdk_x64_linux_hotspot_17.0.17_10.tar.gz /home/wisla/

2.Переходим в каталог kafka используя следующую команду:

cd /opt/kafka

3.Распаковка Java:

tar -xzf ~/OpenJDK17U-jdk_x64_linux_hotspot_17.0.17_10.tar.gz

4.Проверяем результат распаковки Java:

ls -la /opt/kafka/

5.Устанавливаем переменную окружения:

export JAVA_HOME="/opt/kafka/jdk-17.0.17+10"
export PATH="$JAVA_HOME/bin:$PATH"

6.Проверяем версию Java:

java -version

Этап 4. Копирование архива Kafka:

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

1.Копируем архив Kafka в домашнюю директорию:

cp kafka_2.13-4.1.1.tgz /opt/kafka/

2.Переходим в каталог kafka используя следующую команду:

cd /opt/kafka

3.Распаковываем Kafka в /opt/kafka:

tar -xzf ~/kafka_2.13-4.1.1.tgz --strip-components=1 -C /opt/kafka

4.Проверяем результат распаковки Kafka:

ls -la /opt/kafka/bin/kafka-server-start.sh

5.Создаем дополнительные рабочие директории для Kafka:

mkdir -p /opt/kafka/logs
mkdir -p /opt/kafka/config
mkdir -p /opt/kafka/config/kraft

sudo mkdir -p /var/lib/kafka
sudo chown wisla:wisla /var/lib/kafka

Этап 5. Конфигурация Kafka:
Теперь нам необходимо сконфигурировать Kafka.

1.Для начала определим IP адрес который будем использовать для конфигурации Kafka:

IP_ADDRESS=$(ip route get 1 2>/dev/null | awk '{print $7; exit}')

2.Генерируем Cluster ID:

CLUSTER_ID=$(/opt/kafka/bin/kafka-storage.sh random-uuid)
echo "Сгенерированный Cluster ID: $CLUSTER_ID"

ЗАПИШИТЕ ЭТОТ ID - он понадобится позже! (Пример моего ID : IdLVHil7RvCVrR9U2DEvKQ)

3.Создание конфигурационного файла: 

sudo cat > /opt/kafka/config/kraft/server.properties << EOF
process.roles=broker,controller
node.id=1
controller.quorum.voters=1@${IP_ADDRESS}:9093
listeners=PLAINTEXT://${IP_ADDRESS}:9092,CONTROLLER://${IP_ADDRESS}:9093
advertised.listeners=PLAINTEXT://${IP_ADDRESS}:9092
log.dirs=/var/lib/kafka
num.partitions=1
num.recovery.threads.per.data.dir=1
offsets.topic.replication.factor=1
transaction.state.log.replication.factor=1
transaction.state.log.min.isr=1
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
controller.listener.names=CONTROLLER
sasl.mechanism.controller.protocol=PLAINTEXT
auto.create.topics.enable=true
EOF

4.Проверяем созданный файл:

cat /opt/kafka/config/kraft/server.properties

5.Форматирование хранилища

if [ ! -f /var/lib/kafka/meta.properties ]; then
    echo "Инициализируем хранилище Kafka..."
    /opt/kafka/bin/kafka-storage.sh format \
        -t $CLUSTER_ID \
        -c /opt/kafka/config/kraft/server.properties
    
    echo "Хранилище инициализировано с Cluster ID: $CLUSTER_ID"
else
    echo "Хранилище уже инициализировано"
    cat /var/lib/kafka/meta.properties
fi

6.Создание файла службы:

Создаем файл службы

sudo cat > /etc/systemd/system/kafka.service << EOF
[Unit]
Description=Apache Kafka Service (KRaft mode)
After=network.target

[Service]
Type=simple
User=wisla
Group=wisla
WorkingDirectory=/opt/kafka
Environment="JAVA_HOME=/opt/kafka/jdk-17.0.17+10"
Environment="PATH=/opt/kafka/jdk-17.0.17+10/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
ExecStartPre=/bin/bash -c "if [ ! -f /var/lib/kafka/meta.properties ]; then /opt/kafka/bin/kafka-storage.sh format -t $CLUSTER_ID -c /opt/kafka/config/kraft/server.properties; fi"
ExecStart=/opt/kafka/bin/kafka-server-start.sh /opt/kafka/config/kraft/server.properties
SuccessExitStatus=143
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target
EOF

Создание скрипта запуска:

sudo cat > /usr/local/bin/kafka-start << 'EOF'
#!/bin/bash
KAFKA_DIR="/opt/kafka"
KAFKA_LOG_DIR="/var/lib/kafka"
CLUSTER_ID="$CLUSTER_ID"  # ВСТАВЬТЕ ВАШ Cluster ID!

if [ ! -f $KAFKA_LOG_DIR/meta.properties ]; then
    $KAFKA_DIR/bin/kafka-storage.sh format -t $CLUSTER_ID -c $KAFKA_DIR/config/kraft/server.properties
fi
systemctl start kafka
echo "Kafka запущен в режиме KRaft"
EOF

Создаем скрипт остановки:

sudo cat > /usr/local/bin/kafka-stop << 'EOF'
#!/bin/bash
systemctl stop kafka
echo "Kafka остановлен"
EOF

Создаем скрипт статуса:

sudo cat > /usr/local/bin/kafka-status << 'EOF'
#!/bin/bash
echo "Kafka статус:"
systemctl status kafka --no-pager
EOF

Создаем скрипт сброса:

sudo cat > /usr/local/bin/kafka-reset << 'EOF'
#!/bin/bash
echo "Сброс Kafka хранилища..."
systemctl stop kafka
KAFKA_DIR="/opt/kafka"
KAFKA_LOG_DIR="/var/lib/kafka"
CLUSTER_ID="$CLUSTER_ID"  # ВСТАВЬТЕ ВАШ Cluster ID!

rm -rf $KAFKA_LOG_DIR/*
$KAFKA_DIR/bin/kafka-storage.sh format -t $CLUSTER_ID -c $KAFKA_DIR/config/kraft/server.properties
echo "Хранилище сброшено. Запустите: systemctl start kafka"
EOF

Выдача прав на исполнение:

chmod +x /usr/local/bin/kafka-*

Этап 6. Запуск и проверка Kafka:

Обновляем systemd:

sudo systemctl daemon-reload

Включаем автозагрузку:

sudo systemctl enable kafka

Запускаем Kafka

sudo systemctl start kafka

Проверяем статус

sudo systemctl status kafka

Смотрим логи:

sudo journalctl -u kafka -f

Проверяем, что порты открыты

netstat -tlnp | grep -E "9092|9093"

Проверяем метаданные

ls -la /var/lib/kafka/

Установка завершена! Kafka готова к использованию.

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

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

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

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

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

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

Подготовка системы, установка и обновление 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”

Если на вашем сервере присутствует только учётная запись суперпользователя Admin, тогда вам необходимо создать сервисную учётную запись для работы с системой. В данном примере будет создана учётная запись 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. Установка зависимостей

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

RedOS
С доступом к сети или внутреннему репозиторию:
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

 

    CentOS
    С доступом к сети:
    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

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

     

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

     

    Astra Linux 1.6 и 1.7
    С доступом к сети:
    sudo apt install -y ntp liblzo2-2 dialog rsync zip unzip wget tar python3 python3-paramiko fontconfig curl

    Обратите внимание!
    В репозиториях Astra Linux нет пакетов pv, paramiko и uuid, поэтому их необходимо установить из исходников используя .deb-пакеты.
    Следуйте приведённой ниже инструкции в секции "Без доступа к сети".

    Без доступа к сети:
    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
    Установка и настройка pip для Python

    Обязательно для работы Paramiko на Astra Linux 1.7

    Скачайте установочный скрипт get-pip.py(Версии могут отличатся от обновления Astra Linux, сравнивать с версией Python в системе ):

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

    Запустите скрипт для установки pip:

    python3 get-pip.py

    Установите необходимые зависимости:

    sudo apt install python3-distutils

    Добавьте путь к локальным бинарным файлам в переменную PATH:

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

    Обновите pip до последней версии:

    python -m pip install --upgrade pip

    Обновите библиотеку Paramiko:

    pip install --upgrade paramiko

     

     

    Astra Linux 1.8
    С доступом к сети:
    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

    Обратите внимание!
    В репозиториях Astra Linux нет пакета pv, поэтому его необходимо установить из исходников используя .deb-пакет.
    Следуйте приведённой ниже инструкции в секции "Без доступа к сети".

    Без доступа к сети:
    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

    Ручная установка пакета pv:

    sudo dpkg -i pv_1.6.6-1_amd64.deb
    Alt Linux (Simply Linux)
    С доступом к сети:
    sudo apt-get install -y ntp pv dialog rsync zip unzip wget tar python3 fontconfig curl python3-module-paramiko ossp-uuid

    В ходе тестирования было замечено, что для установки WiSLA в altLinux необходимо подключаться по ssh, либо используйте sudo su $(whoami)), иначе будет возникать окно с авторизацией. Также необходимо увеличить размер /tmp в /etc/fstab, добавьте через запятую size=4G (4G указаны в качестве примера) и mount -o remount, rw /tmp.

     

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

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

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

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

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

    CentOS
    Правила для firewalld:
    sudo firewall-cmd --permanent --zone=public --add-port=8080/tcp
sudo firewall-cmd --reload
    Наcтройка SELinux:

    Настройки SELinux по умолчанию могут блокировать доступ к серверу с системой WiSLA, рекомендуется настроить режим Permissive.

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


    Debian, Ubuntu и Astra Linux
    Правила для UFW:
    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

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

    CentOS
    Выполните команды приведённые ниже:
    sudo dnf install glibc-locale-source glibc-langpack-ru 
sudo localectl set-locale LANG=ru_RU.UTF-8
    Затем заново авторизуйтесь на сервере. 
    Ubuntu
    Выполните команды приведённые ниже:
    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
    Затем заново авторизуйтесь на сервере. 

    Debian
    Выполните команды приведённые ниже:
    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.Устанавливаем конфиги:

    Окно 'wiSLA* operator portal configuration'

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

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

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

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

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

    Процесс можно прервать, нажав 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-адрес сервера и порт.

    image.png

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

    Обновление wiSLA

    Важно: После обновления на версию wiSLA 5.2.13 необходимо пересохранить пароль для доступа к серверу LDAP и пароль приложений для почтовых уведомлений. Необходимо зайти под учетной записью "Admin" и в настройках системы поменять пароль Email & Ldap на тот же, что и был и сохранить. Это необходимо, т.к. начиная с версии 5.2.13 был изменен алгоритм шифрования паролей.

    image.png

    image.png

    Рекомендуется обновляться с предыдущей минорной версии 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 и проверьте работу веб-портала.
    1. УСТАНОВКА И ОБНОВЛЕНИЕ WISLA

    Установка wiSLA 5

    Оглавление

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

    Платформа:

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


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

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

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

    2. Подготовка к запуску. 

    1. Перенесите архив в домашний каталог пользователя на целевом компьютере или сервере.
    Пример архива расположенного в каталоге пользователя:

    image.png

    2. Распакуйте архив:

    unzip wisla-pre-installation-program-2.1.zip -d wisla-pre-installation-program-2.1

    3. Перейди в каталог программы:

    cd wisla-pre-installation-program-2.1

    4. Предоставьте программе права на выполнение:

    sudo chmod +x preparing-os.start
    3. Запуск программы.

    Запустите программу с правами суперпользователя:

    sudo ./preparing-os.start

    После запуска откроется меню:

    image.png

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

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

    image.png

    3. При появлении запроса на изменение Hostname:
    Если имя устраивает, введите Н
    Если хотите изменить, введите Д , затем введите wisla.

    image.png

    4. Выберите тип обновления:
    1 - с доступом в Интернет
    2 - без доступа в Интернет

    image.png

    5. После завершения настройки введите пароль для генерации SSH-ключа.

    image.png

    6. Согласитесь на перезагрузку системы.

    image.png

    5. Установка Kafka

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

    cd wish-pre-installation-program-2.1

    2. Запустите программу

    sudo ./preparing-os.start

    3. В главном меню выберите пункт 2.

    image.png

    4. Выберите операционную систему (например, 1 для Astra Linux 1.7).

    image.png

    5. Дождитесь завершения установки.

    image.png

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

    6. Установка Wisla WIProbe Aggregator

    1. В главном меню выберите пункт 3.

    2. Введите адрес сервера Kafka в формате:
    IP:PORT, например: 10.0.2.15:9092

    3. Введите адрес Wisla в формате:
    http://IP:PORT, например: http://10.0.2.15:8080/

    image.png

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

    image.png

    7. Завершение работы

    После успешной установки всех компонентов вы можете закрыть программу, нажав CTRL+C.

    Ваша система полностью готова к работе с WISLA.

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

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

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

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

    sudo su - wisla

    2. Загрузите на сервер программу установки wiSLA 5 нужной версии с помощью утилиты scp или любым другим удобным для вас способом.

    3. Затем добавьте права на выполнение:

    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 будут добавлены следующие компоненты:

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

    1. Окно "Installer startup configuration"

    image.png

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

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

    image.png

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

    3. Окно "Topology configuration"

    image.png

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

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

    4. Окно "Versions select"

    image.png

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

    5. Окно "Zookeeper Configuration"

    image.png

    6. Окно "Hadoop configuration"

    image.png

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

    7. Окно "HBase configuration"

    image.png

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

    8. Окно "Postgresql configuration"

    image.png

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

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

    9. Окно "Wildfly configuration"

    image.png

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

    10. Окно "wiSLA Topology Configuration"

    image.png

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

    image.png

    Нужно проверить и заполнить wiProbe destination, указать адрес агрегатора

    wiProbe destination = http://IP_СЕРВЕРА:18080/aggregator

    12. Окно "wiSLA Resources Configuration"

    Укажите адрес и порт службы Kafka

    image.png

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

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

    Если по умолчанию параметр "wiSLA notification enabled" принимает значение "false" измените на "true"

    image.png

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

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

    14. Окно "wiSLA Cloud System"

    image.png

    15. Окно "Operator Portal Configuration"

    image.png

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

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

    16. Окно "Confirm the installation"

    image.png

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

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

    image.png

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

    Astra Linux

    Если вы используете Astra Linux нажмите кнопку No, т.к. systemd unit для wiSLA 5 был создан ранее программой предварительной настройки узла.

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

    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-адрес сервера и порт.

    image.png

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

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

    Инструкция по ручному развертыванию Kafka в кластерном режиме для Wisla

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

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

    1.Архив OpenJDK 17 ()
    2.Архив Kafka 2.13-4.1.1

    3.Как минимум 3 сервера для развертывания

    4.Пользователь wisla

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

    1.Команда создания пользователя:

    sudo useradd -d /home/wisla -m -s /bin/bash wisla

    2.Команда установки пароля:

    sudo passwd wisla

    3.Добавление пользователя в файлы sudoers:

    echo "wisla    ALL=(ALL:ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/wisla

    4.Настройка системных лимитов для пользователя wisla:

    # Создаем файл лимитов
cat > /etc/security/limits.d/wisla << 'EOF'
wisla   soft      nofile  32768
wisla   hard     nofile  32768
wisla   soft      nproc   32768
wisla   hard     nproc   32768
EOF

    5. Добавляем в PAM (если нет):

    echo "session required pam_limits.so" >> /etc/pam.d/common-session

     

    Этап 1. Подготовка  каталогов на всех узлах

    1.Создание каталогов:

    sudo mkdir -p /opt/kafka
sudo mkdir -p /var/lib/kafka
sudo mkdir -p /var/log/kafka

    2.Выдача прав:

    sudo chown -R wisla:wisla /opt/kafka
sudo chown -R wisla:wisla /var/lib/kafka
sudo chown -R wisla:wisla /var/log/kafka

    3.Проверка прав:

    ls -ld /opt/kafka /var/lib/kafka /var/log/kafka
    Этап 2. Копирование и распаковка Java на всех узлах

    1.Скопируем архив Java в домашнюю директорию wisla используя следующую команду:

    cp OpenJDK17U-jdk_x64_linux_hotspot_17.0.17_10.tar.gz /home/wisla/

    2.Смена пользователя у архива:

    sudo chown wisla:wisla /home/wisla/OpenJDK17U-jdk_x64_linux_hotspot_17.0.17_10.tar.gz

    3.Распаковка архива в /opt/kafka:

    4.Настройка переменных окружения:

    export JAVA_HOME="/opt/kafka/jdk-17.0.17+10"
export PATH="$JAVA_HOME/bin:$PATH"
export KAFKA_HOME="/opt/kafka"

    5.Применение изменений:

    source ~/.bashrc

    6.Проверка:

    java -version

    Этап 3. Копирование и распаковка Kafka на всех узлах

    1.Скопируем архив Kafka в домашнюю директорию wisla используя следующую команду:

    cp kafka_2.13-4.1.1.tgz /opt/kafka/

    2.Смена пользователя у архива:

    sudo chown wisla:wisla /opt/kafka/kafka_2.13-4.1.1.tgz

    3.Распаковка архива в /opt/kafka:

    Этап 4. Генерация уникального ID кластера (только на 1 сервере)

    1.Переходим в каталог kafka используя следующую команду:

    cd /opt/kafka

    2.Запускаем скрипт генерации ID:

    ./bin/kafka-storage.sh random-uuid

    Записать полученный ID, например: 

    Этап 5. Конфигурация кластера на всех узлах

    1.Настройка конфигурации на сервере 1:

    cat > /opt/kafka/config/kraft/server.properties << 'EOF'
# Базовые настройки
process.roles=broker,controller
node.id=1

# Кворум контроллеров (3 узла для отказоустойчивости)
controller.quorum.voters=1@wisla01:9093,2@wisla02:9093,3@wisla03:9093

# Сетевые настройки wisla01
listeners=PLAINTEXT://:9092,CONTROLLER://:9093
advertised.listeners=PLAINTEXT://wisla01:9092
advertised.controller.listener.name=CONTROLLER

# Директории данных
log.dirs=/var/lib/kafka

# Настройки репликации для 3 узлов
num.partitions=3
default.replication.factor=3
min.insync.replicas=2

# Системные топики (репликация на все узлы)
offsets.topic.replication.factor=3
transaction.state.log.replication.factor=3
transaction.state.log.min.isr=2

# Настройки отказоустойчивости контроллеров
controller.listener.names=CONTROLLER
controller.quorum.election.timeout.ms=1000
controller.quorum.fetch.timeout.ms=2000
controller.quorum.request.timeout.ms=2000

# Настройки брокера
num.io.threads=8
num.network.threads=3
num.replica.fetchers=2

# Настройки логов
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
log.flush.interval.messages=10000
log.flush.interval.ms=1000

# Настройки безопасности (опционально)
# ssl.client.auth=required
# ssl.keystore.location=/path/to/keystore.jks
# ssl.keystore.password=password
# ssl.truststore.location=/path/to/truststore.jks
# ssl.truststore.password=password
EOF

    2.Настройка конфигурации на сервере 2:

    cat > /opt/kafka/config/kraft/server.properties << 'EOF'
# Базовые настройки
process.roles=broker,controller
node.id=2

# Кворум контроллеров
controller.quorum.voters=1@node1:9093,2@node2:9093,3@node3:9093

# Сетевые настройки node2
listeners=PLAINTEXT://:9092,CONTROLLER://:9093
advertised.listeners=PLAINTEXT://node2:9092
advertised.controller.listener.name=CONTROLLER

# Директории данных
log.dirs=/var/lib/kafka

# Настройки репликации
num.partitions=3
default.replication.factor=3
min.insync.replicas=2

# Системные топики
offsets.topic.replication.factor=3
transaction.state.log.replication.factor=3
transaction.state.log.min.isr=2

# Настройки контроллеров
controller.listener.names=CONTROLLER
controller.quorum.election.timeout.ms=1000
controller.quorum.fetch.timeout.ms=2000
controller.quorum.request.timeout.ms=2000

# Настройки брокера
num.io.threads=8
num.network.threads=3
num.replica.fetchers=2

# Настройки логов
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
log.flush.interval.messages=10000
log.flush.interval.ms=1000
EOF

    3.Настройка конфигурации на сервере 3:

    cat > /opt/kafka/config/kraft/server.properties << 'EOF'
# Базовые настройки
process.roles=broker,controller
node.id=3

# Кворум контроллеров
controller.quorum.voters=1@wisla01:9093,2@wisla02:9093,3@wisla03:9093

# Сетевые настройки wisla03
listeners=PLAINTEXT://:9092,CONTROLLER://:9093
advertised.listeners=PLAINTEXT://wisla03:9092
advertised.controller.listener.name=CONTROLLER

# Директории данных
log.dirs=/var/lib/kafka

# Настройки репликации
num.partitions=3
default.replication.factor=3
min.insync.replicas=2

# Системные топики
offsets.topic.replication.factor=3
transaction.state.log.replication.factor=3
transaction.state.log.min.isr=2

# Настройки контроллеров
controller.listener.names=CONTROLLER
controller.quorum.election.timeout.ms=1000
controller.quorum.fetch.timeout.ms=2000
controller.quorum.request.timeout.ms=2000

# Настройки брокера
num.io.threads=8
num.network.threads=3
num.replica.fetchers=2

# Настройки логов
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
log.flush.interval.messages=10000
log.flush.interval.ms=1000
EOF

    4.Проверка конфигураций:

    cat /opt/kafka/config/kraft/server.properties
    Этап 6. Инициализация хранилищ на всех узлах

    1.На каждом сервере по очереди

    Этап 7. Создаем сервис службы Kafka на всех узлах

    1.Создаем Unit:

    sudo cat > /etc/systemd/system/kafka.service << 'EOF'
[Unit]
Description=Apache Kafka Service (Kraft mode) - Wisla 3-Node Cluster
After=network.target
Wants=network.target

[Service]
Type=simple
User=wisla
Group=wisla
WorkingDirectory=/opt/kafka
Environment="JAVA_HOME=/opt/kafka/jdk-17.0.17+10"
Environment="PATH=/opt/kafka/jdk-17.0.17+10/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Environment="CLUSTER_ID=wisla-3node-cluster-12345"
Environment="KAFKA_HEAP_OPTS=-Xmx4G -Xms4G"
Environment="KAFKA_JVM_PERFORMANCE_OPTS=-server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+ExplicitGCInvokesConcurrent -Djava.awt.headless=true"
Environment="KAFKA_OPTS=-Dlog4j.configuration=file:/opt/kafka/config/log4j.properties"

# Инициализация хранилища при первом запуске
ExecStartPre=/bin/bash -c "if [ ! -f /var/lib/kafka/meta.properties ]; then echo 'Инициализация хранилища для кластера...' && /opt/kafka/bin/kafka-storage.sh format -t $CLUSTER_ID -c /opt/kafka/config/kraft/server.properties; fi"

# Запуск Kafka
ExecStart=/opt/kafka/bin/kafka-server-start.sh /opt/kafka/config/kraft/server.properties

# Остановка
ExecStop=/opt/kafka/bin/kafka-server-stop.sh

# Логи
StandardOutput=journal
StandardError=journal
SuccessExitStatus=0 143

# Перезапуск при сбоях
Restart=on-failure
RestartSec=10

# Ограничения
LimitNOFILE=65536
LimitNPROC=65536

[Install]
WantedBy=multi-user.target
EOF

    2.Создание конфигурации log4j:

    cat > /opt/kafka/config/log4j.properties << 'EOF'
log4j.rootLogger=INFO, stdout, kafkaAppender

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=[%d] %p %m (%c)%n

log4j.appender.kafkaAppender=org.apache.log4j.DailyRollingFileAppender
log4j.appender.kafkaAppender.DatePattern='.'yyyy-MM-dd-HH
log4j.appender.kafkaAppender.File=/var/log/kafka/kafka.log
log4j.appender.kafkaAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.kafkaAppender.layout.ConversionPattern=[%d] %p %m (%c)%n

log4j.logger.kafka=INFO
log4j.logger.kafka.network.RequestChannel$=WARN
log4j.logger.kafka.server.KafkaApis=WARN
log4j.logger.org.apache.zookeeper=WARN
log4j.logger.org.I0Itec.zkclient=WARN
EOF
    Этап 8. Создание скриптов управления кластером

    1. Создаем скрипт запуска кластера на первом сервере:

    sudo cat > /usr/local/bin/kafka-cluster-start << 'EOF'
#!/bin/bash
echo "Запуск кластера Kafka на всех узлах..."

# Запуск на локальном узле
systemctl start kafka
echo "Node $(hostname): Kafka запущен"

# Если настроен SSH-доступ к другим узлам, можно добавить:
# ssh wisla@wisla02 "systemctl start kafka"
# ssh wisla@wisla03 "systemctl start kafka"
# echo "wisla02: Kafka запущен"
# echo "wisla03: Kafka запущен"

echo "Кластер Kafka (3 узла) запущен"
echo "Для проверки выполните: kafka-cluster-status"
EOF

    2.Создаем скрипт остановки кластера на первом сервере:

    sudo cat > /usr/local/bin/kafka-cluster-stop << 'EOF'
#!/bin/bash
echo "Остановка кластера Kafka..."

# Остановка в правильном порядке (сначала реплики, потом лидеры)
systemctl stop kafka
echo "Node $(hostname): Kafka остановлен"

echo "Кластер Kafka остановлен"
EOF

    3.Создание скрипта проверки статуса на первом сервере:

    sudo cat > /usr/local/bin/kafka-cluster-status << 'EOF'
#!/bin/bash
echo "=== Статус кластера Kafka (3 узла) ==="
echo ""
echo "Локальный узел ($(hostname)):"
systemctl status kafka --no-pager | grep -A 3 "Active:"

echo ""
echo "Для проверки репликации выполните на любом узле:"
echo "  cd /opt/kafka && ./bin/kafka-topics.sh --describe --bootstrap-server wisla01:9092"
echo ""
echo "Для просмотра логов: sudo journalctl -u kafka -f"
EOF

    4.Создание скрипта управления топиками:

    sudo cat > /usr/local/bin/kafka-topic-manage << 'EOF'
#!/bin/bash
KAFKA_HOME="/opt/kafka"
BOOTSTRAP_SERVER="wisla01:9092,wisla02:9092,wisla03:9092"

case $1 in
    create)
        echo "Создание топика: $2"
        $KAFKA_HOME/bin/kafka-topics.sh --create \
            --bootstrap-server $BOOTSTRAP_SERVER \
            --replication-factor 3 \
            --partitions 3 \
            --topic $2
        ;;
    list)
        echo "Список топиков:"
        $KAFKA_HOME/bin/kafka-topics.sh --list \
            --bootstrap-server $BOOTSTRAP_SERVER
        ;;
    describe)
        echo "Описание топика: $2"
        $KAFKA_HOME/bin/kafka-topics.sh --describe \
            --bootstrap-server $BOOTSTRAP_SERVER \
            --topic $2
        ;;
    delete)
        echo "Удаление топика: $2"
        $KAFKA_HOME/bin/kafka-topics.sh --delete \
            --bootstrap-server $BOOTSTRAP_SERVER \
            --topic $2
        ;;
    *)
        echo "Использование: $0 {create|list|describe|delete} [topic-name]"
        echo "Пример:"
        echo "  $0 create wisla-topic"
        echo "  $0 list"
        echo "  $0 describe wisla-topic"
        echo "  $0 delete wisla-topic"
        ;;
esac
EOF

    5.Предоставление прав на исполнение:

    sudo chmod +x /usr/local/bin/kafka-*

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

    sudo cat >> /etc/hosts << 'EOF'
# Kafka Cluster Nodes
192.168.1.101 Wisla01
192.168.1.102 Wisla02
192.168.1.103 Wisla03
EOF

    7.Настройка брандмауэра (Опционально):

    sudo ufw allow 9092/tcp  # Client connections
sudo ufw allow 9093/tcp  # Controller connections
sudo ufw allow 9094/tcp  # Inter-broker connections (если настроены)
    Этап 9. Запуск кластера

    1.Перезагрузка systemd на всех узлах:

    sudo systemctl daemon-reload

    2.Добавление в автозапуск на всех узлах:

    sudo systemctl enable kafka

    3.Запуск кластера (ВАЖНО: запускать на всех узлах в течение 30 секунд):

    # На wisla01:
sudo systemctl start kafka

# На wisla02 (в течение 30 секунд после wisla01):
sudo systemctl start kafka

# На wisla03 (в течение 30 секунд после wisla02):
sudo systemctl start kafka

    4.Проверка статуса службы:

    sudo systemctl status kafka

     

    Дополнительная проверка:
    Так же после установки и запуска службы Kafka можно создать скрипт проверки статусов работы кластера Kafka.
    1.Создать файл скрипта командой:

    sudo nano /usr/local/bin/kafka-cluster-monitor

    2.Предоставить права на исполнение:

    sudo chmod +x /usr/local/bin/kafka-cluster-monitor

    3.Добавить скрипт в файл

    #!/bin/bash
echo "========================================="
echo "   Мониторинг кластера Kafka (3 узла)   "
echo "========================================="
echo ""

echo "1. СТАТУС СЛУЖБ:"
for node in cluster01 cluster02 cluster03; do
    if [ "$node" = "cluster01" ]; then
        status=$(sudo systemctl is-active kafka 2>/dev/null || echo "unknown")
    else
        status=$(ssh wisla@$node "sudo systemctl is-active kafka 2>/dev/null" 2>/dev/null || echo "unknown")
    fi
    
    case $status in
        active) color="\e[32m" ;;  
        inactive|failed) color="\e[31m" ;; 
        unknown) color="\e[33m" ;; 
        *) color="\e[33m" ;;      
    esac
    echo -e "   $node: ${color}${status}\e[0m"
done

echo -e "\n2. СПИСОК БРОКЕРОВ:"
cd /opt/kafka 2>/dev/null 
if [ -f /opt/kafka/bin/kafka-broker-api-versions.sh ]; then
    /opt/kafka/bin/kafka-broker-api-versions.sh \
      --bootstrap-server cluster01:9092 2>/dev/null | grep -E "^cluster" | head -3
else
    echo "   Kafka не установлен локально"
fi

echo -e "\n3. СПИСОК ТОПИКОВ:"
cd /opt/kafka 2>/dev/null 
if [ -f /opt/kafka/bin/kafka-topics.sh ]; then
    /opt/kafka/bin/kafka-topics.sh \
      --list --bootstrap-server cluster01:9092 2>/dev/null | head -10
else
    echo "   Kafka не установлен локально"
fi

echo -e "\n4. ПРОВЕРКА РЕПЛИКАЦИИ:"
cd /opt/kafka 2>/dev/null 
if [ -f /opt/kafka/bin/kafka-topics.sh ]; then
    result=$(/opt/kafka/bin/kafka-topics.sh \
      --describe --bootstrap-server cluster01:9092 \
      --under-replicated-partitions 2>/dev/null)
    if echo "$result" | grep -q "Topic"; then
        echo "     Есть недореплицированные партиции"
    else
        echo "    Все партиции реплицированы"
    fi
else
    echo "   Kafka не установлен локально"
fi

echo -e "\n5. ПОСЛЕДНИЕ СОБЫТИЯ:"
for node in cluster01 cluster02 cluster03; do
    if [ "$node" = "cluster01" ]; then
        errors=$(sudo journalctl -u kafka --since '5 minutes ago' 2>/dev/null | grep -E 'ERROR|WARN' | tail -2)
    else
        errors=$(ssh wisla@$node "sudo journalctl -u kafka --since '5 minutes ago' 2>/dev/null | grep -E 'ERROR|WARN' | tail -2" 2>/dev/null)
    fi
    
    if [ -n "$errors" ]; then
        echo "   $node:"
        echo "$errors" | sed 's/^/     /'
    fi
done

echo -e "\n========================================="
echo "   Кластер готов к работе!"
echo "========================================="

    4.Запустить скрипт для проверки

    ./kafka-cluster-monitor



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

    Настройка Kafka для работы с wiSLA (и с wiProbe Aggregator)

    1. Установка Docker

    Перед началом работы необходимо убедиться, что Docker установлен и работает.

    Для систем без выхода в интернет
    Скачайте архив Docker.zip и распакуйте из него нужные версии deb-пакетов.

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

    Загрузив файлы на сервер установите Docker-engine из бинарных файлов выполнив следующую команду:

    sudo dpkg -i ./containerd.io_1.6.9-1_amd64.deb  ./docker-ce_23.0.6-1~debian.10~buster_amd64.deb \
./docker-ce-cli_24.0.2-1~debian.10~buster_amd64.deb ./docker-buildx-plugin_0.10.5-1~debian.10~buster_amd64.deb

    Проверка наличия Docker:

    docker --version

    Установка Docker (для Ubuntu/Debian):

    Если Docker не установлен, выполните следующие команды:

    sudo apt-get update
sudo apt-get install docker.io docker-compose
sudo systemctl enable docker
sudo systemctl start docker

    Добавление пользователя в группу docker:

    Чтобы избежать необходимости использовать sudo при каждом вызове Docker:

    sudo usermod -aG docker $USER
newgrp docker

    Примечание для Astra Linux:
    В Astra Linux установка Docker имеет специфические особенности, особенно в изолированных средах без доступа к интернету. Рекомендуется ознакомиться с инструкцией: Установка wiCore без доступа к сети интернет

    2. Развертывание Kafka через Docker Compose

    2.1 Создайте файл docker-compose.yml  со следующим содержимым и замените в KAFKA_CFG_ADVERTISED_LISTENERS адрес 127.0.0.1 на актуальный IP-адрес сервера wiSLA:

    Пути к докер манифестам bitnami обновлены в связи с недоступностью новых, Bitnami объявила о переходе многих своих Docker-образов в статус "legacy".

    Актуальные данные файла docker-compose.yml на 01.10.2025:

    version: '3.8'

services:
  zookeeper:
    image: docker.io/bitnamilegacy/zookeeper:3.9
    container_name: zookeeper
    ports:
      - "2187:2181"
    environment:
      - ALLOW_ANONYMOUS_LOGIN=yes
    volumes:
      - "zookeeper_data:/bitnami/zookeeper"
    restart: unless-stopped

  kafka:
    image: docker.io/bitnamilegacy/kafka:3.7
    container_name: kafka
    ports:
      - "9092:9092"
      - "29092:29092"
    environment:
      - KAFKA_CFG_ZOOKEEPER_CONNECT=zookeeper:2181
      - ALLOW_PLAINTEXT_LISTENER=yes
      - KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,INTERNAL://:29092
      - KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://192.168.110.128:9092,INTERNAL://kafka:29092
      - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=PLAINTEXT:PLAINTEXT,INTERNAL:PLAINTEXT
      - KAFKA_CFG_INTER_BROKER_LISTENER_NAME=INTERNAL
      - KAFKA_CFG_AUTO_CREATE_TOPICS_ENABLE=true
      - KAFKA_CFG_NUM_PARTITIONS=1
      - KAFKA_CFG_DELETE_TOPIC_ENABLE=true
      - KAFKA_CFG_LOG_RETENTION_HOURS=24
      - KAFKA_CFG_LOG_SEGMENT_BYTES=5242880
      - KAFKA_CFG_MESSAGE_MAX_BYTES=1048576
      - KAFKA_CFG_SOCKET_REQUEST_MAX_BYTES=10485760
      - KAFKA_CFG_LOG_RETENTION_BYTES=53687091
    volumes:
      - "kafka_data:/bitnami/kafka"
    depends_on:
      - zookeeper
    restart: unless-stopped

  kafka-console:
    image: docker.redpanda.com/redpandadata/console:latest
    container_name: kafka-console
    ports:
      - "8085:8080"
    environment:
      KAFKA_BROKERS: kafka:29092
      SERVER_PORT: 8080
      CONSOLE_LOG_LEVEL: info
      CONSOLE_FEATURES_TOPIC_INSPECTOR: "true"
    depends_on:
      - kafka
    restart: unless-stopped

volumes:
  zookeeper_data:
    driver: local
  kafka_data:
    driver: local

    Необходимо прописать конфиг:

    KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://{hostname}:9092

     Данный параметр определяет адрес (listeners), по которым клиенты могут подключаться к брокеру Kafka. 

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

    2.2 Запустите Kafka:

    sudo docker-compose up -d

    2.3 Проверьте работоспособности 

    Убедитесь, что запущены три контейнера: zookeeper, kafka, kafka-console:

    sudo docker ps

    image.png

     Проверьте логи Kafka-контейнера (замените CONTAINER_ID_KAFKA на реальный ID):

    sudo docker logs CONTAINER_ID_KAFKA

    3. Установка и настройка wiProbe Aggregator (не обязательно)

    3.1.Скачивание архива

    Скачайте файл wisla-wiprobe-aggregator.jar с GitLab.
    Подробная инструкция: Установка wiProbe Aggregator .

    Примечание: Установка Nginx (который упоминался в статье) не обязательна, если не требуется балансировка нагрузки между несколькими агрегаторами.

    3.2. Создайте каталог для логов (желательно рядом с агрегатором), иначе при запуске агрегатора будут ошибки, что нет прав для записи логов):

    mkdir -p /home/wisla/aggrlog
chown wisla:wisla /home/wisla/aggrlog

    3.3. Настройка конфигурации JAR-файла

    Откройте JAR-архив с помощью архиватора (например, 7-Zip, WinRAR) и отредактируйте:

    server.servlet.context-path=/aggregator
server.port=18080
aggregator.kafka-enabled=true
aggregator.wisla-kafka.bootstrap.servers=ВАШ_IP:9092  # Например: 10.11.11.52:9092
aggregator.wisla-kafka.consumer-threads-count=4
aggregator.wisla.dc-nodes=http://ВАШ_DC_УЗЕЛ:8080  # Например: http://10.11.11.51:8080
    <property name="LOG_FILE" value="/home/wisla/aggrlog/aggregator.log" />
.....
  <fileNamePattern>/home/wisla/aggrlog/aggregator.%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern>

    image.png

    3.4. Настройка автозапуска через systemd

    sudo nano /etc/systemd/system/aggr-jar.service
    [Unit]
Description=WiProbeAggregator

[Service]
ExecStart=/usr/bin/java -jar /home/smpsadmin/wisla-wiprobe-aggregator.jar
Restart=always
User=wisla

[Install]
WantedBy=multi-user.target

    3.5. Запуск и проверка:

    # Обновить конфигурацию
sudo systemctl daemon-reload

# Включить автозагрузку
sudo systemctl enable aggr-jar.service

# Запустить службу
sudo systemctl start aggr-jar.service

# Проверить статус
sudo systemctl status aggr-jar.service

# Просмотр логов (реальный режим)
journalctl -u aggr-jar.service -f

    4. Настройка wiSLA для работы с Kafka и Aggregator

    4.1. В wiSLA Data Collection Configuration укажите адрес агрегатора:

    wtProbe destination = http://ВАШ_IP_АГРЕГАТОРА:18080/aggregator

    image.png

    4.2. В wiSLA Resources Configuration укажите адрес Kafka:

    Kafka bootstrap servers = ВАШ_IP_КАФКА:9092

    image.png

    5. Особенности работы с Kafka и агрегатором

    5.1. Варианты конфигурации системы

    Standalone-режим (один сервер wiSLA):

    Рекомендуется для новых установок

    Кластерный режим:

    5.2. Важные замечания

    Примечание: Даже для standalone необходимо развернуть Kafka и агрегатор – это обеспечит единый подход к логированию и упростит переход на кластерную архитектуру в будущем.

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

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

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

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

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

    2. Выбрать пункт меню «Config update». Если этого пункта меню нет в списке, установка была
      выполнена некорректно или на первом экране при запуске программы установки были
      указаны ошибочные данные.
    3. Найти, изменить требуемый параметр.
    4. Выполнить перезапуск wiSLA.
    1. УСТАНОВКА И ОБНОВЛЕНИЕ 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)  

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

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

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

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

    Параметр

    Назначение

    Пример значения

    Notification enabled

    Включает рассылку по электронной почте

    true

    Mail host

    IP или DNS-адрес почтового сервера

    smtp.gmail.com

    Mail port

    Порт, прослушиваемый почтовым сервером

    587

    Mail protocol

    Протокол, используемый почтовым сервером

    smtps

    Mail SMTP auth

    Включается, если почтовый сервер поддерживает smtp-авторизацию

    true

    Mail SMTP STARTTLS

    Включается, если почтовый сервер поддерживает SMTP STARTTLS

    true

    Mail user

    Имя пользователя, от имени которого выполняется рассылка

    wisla.vm1

    Mail password

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

    пароль

    Tickets per notification

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

    1

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

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

    Инструкция по ручному развертыванию Wisla-wiprobe-agregator для Wisla

    В данной инструкции описано как установить Wisla WiProbe Aggregator в ручном режиме без использования скрипта предварительной настройки системы.

    Этап 1. Переход под пользователя wisla:

    На первом этапе  необходимо перейти под пользователя Wisla используя команду:

    sudo su - wisla
    Если пользователь wisla еще не существует в системе его необходимо создать используя следующие команды пошагово.

    1.Команда создания пользователя:

    sudo useradd -d /home/wisla -m -s /bin/bash wisla

    2.Команда установки пароля:

    sudo passwd wisla

    3.Добавление пользователя в файлы sudoers:

    echo "wisla    ALL=(ALL:ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/wisla

    4.Настройка системных лимитов для пользователя wisla:

    # Создаем файл лимитов
cat > /etc/security/limits.d/wisla << 'EOF'
wisla   soft      nofile  32768
wisla   hard     nofile  32768
wisla   soft      nproc   32768
wisla   hard     nproc   32768
EOF

    5. Добавляем в PAM (если нет):

    echo "session required pam_limits.so" >> /etc/pam.d/common-session

     

    Этап 2. Подготовка каталога Wisla-wiprobe-agregator.

    После перехода под пользователя wisla вам необходимо создать каталог где будет располагаться Wisla-wiprobe-agregator, использую следующие команды:

    1.Создание директории в /opt/:

    sudo mkdir -p /opt/aggr-wisla
sudo mkdir -p /opt/aggr-wisla/config
sudo mkdir -p /opt/aggr-wisla/logs

     2.Проверить кому принадлежит каталог kafka:

    ls -l /opt/

    3.Сменить пользователя для каталога agg-wisla если принадлежит не wisla используя следующую команду:

    sudo chown -R wisla:wisla /opt/aggr-wisla

    4.Переходим в каталог:

    cd /opt/aggr-wisla

    Этап 3. Копирование архива Java:
    Предполагается, что архив OpenJDK11U-jdk_x64_linux_hotspot_11.0.28_6.tar.gz уже передан или скачан с корпоративного файла обменника.  

    1.Скопируем его из домашней директории wisla используя следующую команду:

    sudo cp ~/OpenJDK11U-jdk_x64_linux_hotspot_11.0.28_6.tar.gz /opt/aggr-wisla/

    2.Распаковка архива Java:

    sudo tar -xzf OpenJDK11U-jdk_x64_linux_hotspot_11.0.28_6.tar.gz

    3.Добавление в переменные среды:

    JAVA_HOME="/opt/aggr-wisla/$(ls -d jdk-11* 2>/dev/null | head -1)"
echo "Java Home: $JAVA_HOME"

    4.Проверка java:

    $JAVA_HOME/bin/java -version

    Этап 4. Настройка переменного окружения:

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

    sudo -u wisla bash -c "echo 'export JAVA_HOME=\"$JAVA_HOME\"' >> /home/wisla/.bashrc"
    sudo -u wisla bash -c "echo 'export PATH=\"\$JAVA_HOME/bin:\$PATH\"' >> /home/wisla/.bashrc"

    Этап 5. Копирование JAR файла:

    Предполагается, что архив wisla-wiprobe-aggregator.jar уже передан или скачан с корпоративного файла обменника.

    1.Скопируем его из домашней директории wisla используя следующую команду:  

    sudo cp ~/wisla-wiprobe-aggregator.jar /opt/aggr-wisla/

    2.Выдача прав на исполнение и изменение владельца:

    sudo chmod +x /opt/aggr-wisla/wisla-wiprobe-aggregator.jar
    sudo chown wisla:wisla /opt/aggr-wisla/wisla-wiprobe-aggregator.jar

    3.Создаем конфигурационный файл

    sudo cat > /opt/aggr-wisla/config/application.properties << EOF
server.servlet.context-path=/aggregator
server.port=18080
aggregator.kafka-enabled=true
aggregator.wisla-kafka.bootstrap.servers="Указать Ip Адресс сервера кафка :9092"
aggregator.wisla-kafka.consumer-threads-count=4
aggregator.id=1
aggregator.buffered-data-processing.interval=5000
aggregator.refresh-data-senders.interval=30000
aggregator.data-batch-length.limit=1000000
aggregator.buffer-size.limit=1500
aggregator.wisla.dc-nodes="Указать Ip Адресс сервера кафка :8080"
aggregator.round.robbin.algorithm=true
spring.servlet.multipart.enabled=true
spring.application.name=wisla-wiprobe-aggregator
logging.level.root=WARN
logging.level.com.wisla=INFO
logging.file.name=/opt/aggr-wisla/logs/aggregator.log
logging.pattern.console=
logging.pattern.file=%d{yyyy-MM-dd HH:mm:ss} - %msg%n
management.endpoints.web.exposure.include=health,info,metrics
management.endpoint.health.show-details=always
EOF

    4.Изменение пользователя:

    sudo chown wisla:wisla /opt/aggr-wisla/config/application.properties

    5.Создать юнит для wisla-wiprobe-aggregator:

    sudo cat > /etc/systemd/system/wisla-wiprobe-aggregator.service << EOF
[Unit]
Description=Wisla WiProbe Aggregator Service
After=network.target kafka.service

[Service]
Type=simple
User=wisla
Group=wisla
WorkingDirectory=/opt/aggr-wisla
Environment="JAVA_HOME=$JAVA_HOME"
Environment="PATH=$JAVA_HOME/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
ExecStart=$JAVA_HOME/bin/java -jar /opt/aggr-wisla/wisla-wiprobe-aggregator.jar
SuccessExitStatus=143
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target
EOF

    Этап 6. Запуск и проверка:

    Обновляем systemd:

    sudo systemctl daemon-reload

    Включаем автозагрузку:

    sudo systemctl enable wisla-wiprobe-aggregator

    Запускаем Kafka:

    sudo systemctl start wisla-wiprobe-aggregator

    Проверяем статус:

    sudo systemctl status wisla-wiprobe-aggregator
    1. УСТАНОВКА И ОБНОВЛЕНИЕ WISLA

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

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

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

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

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

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

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

    image-1680716978406.png

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

    image-1680717866828.png


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

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

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

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

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

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

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

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

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

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

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

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

    Возможная причина сбоя

    Действия по выявлению

    Устранение проблемы

    1. Отказ одного из компонентов wiSLA (не является самостоятельной причиной, требует продолжения диагностики)

    Просмотр статусов компонентов wiSLA в программе установки

    Поиск основной причины сбоя, перезапуск всех компонентов wiSLA

    2. Резкий скачок времени на сервере

    Проверка времени на каждом из узлов, где установлена wiSLA.

    Проверка работоспособности службы NTP

    Установка корректных даты и времени, запуск NTP, перезапуск всех компонентов wiSLA. Если база данных испорчена некорректными данными, потребуется выполнить восстановление из резервной копии (обратитесь в службу технической поддержки)

    3. Продолжительный разрыв связи между узлами wiSLA

    Определение доступности серверов, изучение журналов работы системы, опрос системных администраторов

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

    4. Аварийная перезагрузка одного или нескольких узлов

    Сравнение времени непрерывной работы серверов wiSLA, изучение журналов работы операционной системы сервера с наименьшим временем непрерывной работы

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

    5. Исчерпано свободное место на одном из дисков

    Получение информации об использовании дискового пространства на всех серверах wiSLA

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

    6. Вмешательство в работу сервера (изменение настроек сети, файловой системы и т.п. при работающей wiSLA)

    Опрос системных администраторов

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

    7. Неудачное обновление wiSLA

    Чтение журнальных файлов после обновления

    Обратитесь в службу технической поддержки

    8. Аппаратные проблемы на сервере

    Определение проблемного сервера, перезагрузка, просмотр данных POST, изучение журналов операционной системы, проверка диска, тестирование ОЗУ, замена компонентов на заведомо исправные и т.д. Выходит за рамки настоящего Руководства

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

    Если в ходе перезапуска возникли проблемы или требуется восстановить программные файлы, обратитесь в службу технической поддержки
    1. УСТАНОВКА И ОБНОВЛЕНИЕ WISLA

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

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

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

    Что требуется сделать?

    Последовательность действий

    1. Просмотреть информацию о статусах всех компонентов wiSLA

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

    2. Выбрать и открыть "Status".

    3. Выбрать "All ".

    Незапущенные компоненты можно определить по наличию "[FAIL]" и "NOT STARTED" в строке.

    2. Остановить все компоненты wiSLA с помощью программы установки

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

    2. В программе установки wiSLA выбрать "Maintenance" - "Stop All". 

    3. Проверить результат. Посмотреть информацию по статусам всех компонентов wiSLA.

    3. Управление запуском wiSLA с помощью скрипта запуска (для варианта установки всех компонентов на 1 сервер)

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

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

    $    sudo systemctl start wisla5

    или

    $    sudo /opt/wisla5/scripts/wisla5.sh start

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

    $    sudo systemctl stop wisla5

    или

    $    sudo /opt/wisla5/scripts/wisla5.sh stop

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

    $    sudo systemctl status wisla5

    или

    $    sudo /opt/wisla5/scripts/wisla5.sh status

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

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

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

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

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

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

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

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

    4. Перезапустить все компоненты wiSLA

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

    2. В программе установки wiSLA выбрать "Maintenance" - "Stop All", дождаться завершения выполнения команды.

    3. Выбрать в меню "Start All".

    4. Дождаться полного запуска системы.

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

    5. Узнать, что система полностью запущена

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

    2. Выбрать в меню программы установки раздел "Log viewer" - "wiSLA” – “Server.log at..."

    3. Нажать SHIFT+F для автоматического обновления файла.

    Запись об удачном запуске:

    wiSLA COMPONENTS ARE FULLY DEPLOYED, INTERCONNECTED AND READY TO WORK.

    4. Завершить просмотр файла: CTRL+C, затем q.

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

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

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

    2. В программе установки wiSLA выбрать "Maintenance" – “wiSLA” – "Stop All", дождаться завершения выполнения команды.

    3. Выбрать в меню "Start All", выполнить команду.

    4. Дождаться полного запуска системы.

    5. Проверить статус wiSLA.

    7. Получить информацию о свободном месте на диске

    В ssh-сессии выполнить команду:

    $    df -h

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

    В ssh-сессии выполнить команду:

    $    uptime

    9. Просмотреть журналы работы операционной системы

    В SSH-сессии выполнить команду:

    $    less /var/log/messages

    10. Просмотреть журналы работы системы wiSLA

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

    2. Открыть "Logs viewer".

    3. Выбрать компонент системы.

    4. Выбрать журнал для просмотра.

    11. Проверить время и дату в операционной системе

    В ssh-сессии выполнить команду:

    $    date

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

    12. Проверить работу службы NTP

    В SSH-сессии выполнить команду:

    $    sudo systemctl status ntpd

    Если служба запущена, проверить доступность NTP-серверов для синхронизации и статус синхронизации:

    $    ntpq –npcrv

    13. Добавить новый плагин

    Для добавления нового плагина требуется:

    1. Скопировать файл плагина в каталог /opt/wisla5/wildfly/current/wisla_plugins/.

    2. Выдать пользователю wisla права на файл:

    $    chown wisla.wisla *.jar

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

    4. Перейти в меню «Maintenance» - «wiSLA» и выполнить «Reload_plugins».

    14. Загрузить модуль коллектора Netflow

    Для загрузки коллектора Netflow требуется:

    1. Получить в службе поддержки или найти в комплекте поставки файл модуля коллектора wisla-netflow-collector-web-5.1-SNAPSHOT.war.

    2. Скопировать файл в каталог

    /opt/wisla5/wildfly/current/standalone/deployments

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

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

    $    touch /opt/wisla5/wildfly/current/standalone/deployments/wisla-netflow-collector-web-5.1-SNAPSHOT.war.dodeploy

    После получения доступа на портал оператора потребуется добавить коллектор в качестве зонда «Netflow collector» с IP-адресом 127.0.0.1 (раздел «Зонды», кнопка «+ Создать», тип «Netflow collector»).

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

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

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

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

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

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

    image.png

    image.png

    2)Скачать executable tarball

    image.png

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

    image.png

    chmod +x podmanizedWisla.sh

    4)Запустить 

    image.png

    image.png

    image.png

    ./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 и дождаться следующего сообщения

    image.png

    ./tool.sh wisla-wildfly-log

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

    ./tool.sh wisla-script stop

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

    ./tool.sh stop-container

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

    ./tool.sh start-container

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

    Скрипты для взаимодействия с 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

    Где:

     

    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
    /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

     

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

    Файл шаблона скрипта: /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}}


    Файл шаблона скрипта: /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


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

    /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

     


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

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

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

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

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

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

          image.png

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

            image.png

    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). Перейти в данную папку.

          image.png

    Проверить процесс загрузки файла по наименованию файла, об этом сигнализирует изменение имени 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..». 

    image.png

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

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

    image.png

     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 выполните первый вход на портал с помощью учётной записи суперпользователя, которая создаётся при развёртывании системы. По умолчанию используется пользователь Admin.

    Данные по умолчанию:

    Учётная запись Admin предназначена для первоначальной настройки системы и управления правами пользователей.

    Важно

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

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

    Пароль суперпользователя можно изменить через портал wiSLA в любое время.

    Особенности учётной записи Admin

    image.png

    Первый вход в систему

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

    image.png

    Первичная настройка

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

    image.png

    image.png

    Также пользователей можно создать отдельно на странице "Пользователи".

    image.png

    Следующий шаг

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

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

    Раздел «Администрирование» включает следующие компоненты:

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

    КОНТРАГЕНТЫ

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

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

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

    image.png

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

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

    № шага

    Действие пользователя

    Реакция Системы

    UI

    1.

    Перейти на страницу Контрагенты

    1.1

    Открывает раздел "Контрагенты" в функциональном блоке "АДМИНИСТРИРОВАНИЕ"

    Открывает страницу раздела Контрагенты. Показывает список контрагентов.

    image.png

    2.

    		 Перейти на страницу создания Контрагента

    2.1

    		 Нажимает кнопку 

    image.png

    		 Открывает страницу создания Контрагента

    image.png


    image.png


     

    3.

    		 Заполнить параметры

    3.1

    Заполняет название контрагента

     

     

    		 Отображает заполненное поле "Название". 

    image.png

    3.2

    Заполняет контактные данные

    (Необязательный шаг)

    		 При заполнении данных отображает их в целевом поле.

    image.png
     3.3  Выбирает роли, отмечает их чекбоксом

    image.png

    Чекбокс роли "Потребитель сервиса" и "Автоматическая публикация отчетов SLA" отмечены по умолчанию

    чекбоксы остальных ролей отмечаются.

    image.png


     

    4.

    		 Перейти на вкладку "Пользователи Контрагента"
    4.1

    Нажимает выбрать пользователя или создать его.

    image.png

    При нажатии "Выбрать",

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

    При нажатии "Создать",

    Открывает страницу редактирования профиля пользователя.

    image.png


    image.png


    image.png

    image.png


    image.png

    5.

    		 Перейти на вкладку "Данные для отчетов"
     5.1

    Настраивает данные для печатной формы отчетов SLA.

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

    Необязательный шаг.

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

    При заполнении полей "Согласовано" и "Утверждено"  - отображает данные в целевых полях.

    image.png

    image.png
    5.2

    Нажимает кнопку "Сохранить"

    image.png

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

    image.png

    image.png


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

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

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

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

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

    image.png

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

    image.png

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

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

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

    image.png

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

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

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

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

    image.png

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

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

    ПОЛЬЗОВАТЕЛИ

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

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

    image.png

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

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

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

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

    № шага

    Действие пользователя

    Реакция Системы

    UI

    1.

    Перейти на страницу Пользователи

    1.1

    Открывает раздел "Пользователи" в функциональном блоке "АДМИНИСТРИРОВАНИЕ"

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

    image.png

    2.

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

    2.1

    		 Нажимает кнопку 

    image.png

    		 Открывает страницу создания пользователя

    image.png

    image.png

     

    3.

    		 Заполнить основные параметры

    3.1

    Заполняет ФИО пользователя и электронную почту.

    Данные можно заполнить нажатием кнопки:image.png
    при наличии учетной записи в AD.

    При необходимости заполняет должность.

     

    		 Отображает заполненные данные в целевых полях. При использовании загрузки из Active Directory - отображает выпадающий список доступных пользователей. После выбора пользователя вносит его данные в целевые поля. И отображает привязанную учетную запись из Active Directory.


    image.png

    image.png

    image.png

    image.png

    3.2

     Нажимает кнопку 

    image.png

     Нажимает кнопку

    image.png

     Заполняет дополнительный   адрес электронной почты.

    (Необязательный шаг)

    		 Отображает поле ввода дополнительной электронной почты. При заполнении данных отображает их в целевом поле.

     

    image.png

    image.png

    image.png

    image.png

    3.3

    Задает новый пароль пользователю, вводит подтверждение нового пароля.

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

    image.png

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

    При нажатии кнопки "Глаз" - отображает скрытые значения полей.

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

    При несоответствии пароля и подтверждения - выводит предупреждение о разнице значений в полях.

    image.png

    image.png

     

    image.png

     

    image.png

    3.4

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

    image.png

    Чекбокс роли "Пользователь" отмечен по умолчанию, недоступен для редактирования.

    Чекбоксы остальных ролей отмечаются.

    image.png

    3.5

    Выбирает контрагента, 

    нажимает кнопку

    image.png

    (Обязательный шаг, если выбрана роль "Оператор SLA")

    Открывает выпадающий список доступных для выбора контрагентов.

    image.png

    image.png

    image.png

    3.6

    Настраивает уведомления на портале и отправку на почту.

    Отмечает чекбоксы нужных уведомлений

    image.png

    (Необязательный шаг)

    Отображает отмеченные чекбоксы пользователю.

    image.png

    4.

    		 Выбрать контракт

    4.1

    Переходит на страницу "Контракты"


    		 Отображает страницу добавления контрактов

    image.png

    image.png

    4.2

    Нажимает кнопку "Выбрать контракт"

    image.png

    (Необязательный шаг)

    		 Отображает выпадающий список доступных контрактов. После выбора контракта, он отображается на странице, доступно добавление нескольких контрактов. Доступно редактирование и удаление контракта.

    image.png

    image.png

    image.png

    5.

    		 Заполнить дополнительные данные (Необязательные шаги)

    5.1

    Переходит на страницу "Дополнительно"

    Открывает страницу с дополнительными данными

    image.png

    image.png


     

    5.2

    Заполняет дополнительные поля

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

    image.png

    5.3

    Выбирает запрещенные/разрешенные IP-адреса для пользователя. Добавляет IP-адреса, нажимая кнопку 

    image.png

    При нажатии кнопки "Добавить IP-Адрес", отображает поле ввода IP-адреса, после заполнения поля есть возможность его удаления и добавления других адресов.

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

    image.png

    6.

    		 Сохранить пользователя

    6.1

    		 Нажимает кнопку 

    image.png

    Сохраняет пользователя в системе. 

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

    image.png

    image.png


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

    Уведомления

    Прочее

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

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

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

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

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

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

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

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

    • ldap_server.enabled
    		 По умолчанию "false"
    • ldap_server.url

    Необходимо указать (например "Ldap://DEVWIN.local:38922/")
    • ldap_server.base

    Необходимо указать (например "CN=Users, DC=DEVWIN, DC=local")
    • ldap_server.authenticator_name

    По умолчанию ("ldapBindAuthenticator")
    • ldap_server.login

    Необходимо указать (например "login")
    • ldap_server.password

    Необходимо указать (например "11112222")
    • ldap_server.person_class_name

    По умолчанию ("user")
    • ldap_server.vid_attribute_name

    По умолчанию ("objectquid")
    • ldap_server.login_attribute_name

    По умолчанию ("samaccountname")
    • ldap_server.memberof_attribute_name

    По умолчанию ("memberof")
    • ldap_server.display_name_attribute_name

    По умолчанию ("displayname")
    • ldap_server.email_attribute_name

    По умолчанию ("mail")
    • ldap_server.phone_attribute_name

    По умолчанию ("telephonenumber")

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

    image.png

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

    СЕССИИ

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

    image.png

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

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

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

    ЖУРНАЛ СОБЫТИЙ

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

    image.png

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

    image.png


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


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

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

    НАСТРОЙКИ СИСТЕМЫ

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

    1. ОБНОВЛЕНИЕ АГЕНТОВ

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

    Возможности

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

    Как использовать?

    1. Авторизуйтесь под учётной записью с ролью «Системный администратор»
    2. Перейдите: Администрирование → Настройка системы → вкладка «Обновление агентов»
    3. Просмотрите список агентов и их статусы
    4. Для обновления:
      • Выберите необходимые агенты
      • Нажмите «Начать обновление»
      • Или укажите источник обновлений через кнопку «Указать источник»
    5. Используйте фильтрацию и поиск для работы с большим количеством агентов
    6. Настройте отображаемые столбцы через настройки таблицы

    Важно:

    2 ПОЧТОВЫЕ УВЕДОМЛЕНИЯ

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

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

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

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

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

      • Адреса уведомлений:
      • Почтовый сервер: 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
      • Опция "Использовать английские имена файлов".

    Как настроить?

    1. Авторизуйтесь под пользователем Admin (id-2)
    2. Перейдите: Администрирование → Настройка системы → вкладка Почтовые уведомления
    3. Установите Notification enabled = true для активации рассылок
    4. Заполните параметры SMTP-сервера:
      • Укажите адрес и порт вашего почтового сервера
      • Введите учётные данные для аутентификации
      • Выберите протокол и параметры безопасности
    5. Настройте ссылки на портал (op_link и cp_link)
    6. При необходимости настройте дополнительные параметры
    7. Нажмите «Сохранить»

    Важно:

    3 АВТОРИЗАЦИЯ LDAP

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

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

    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 – атрибут, содержащий телефонный номер.

    Как настроить?

    1. Авторизуйтесь под пользователем Admin (id-2)
    2. Перейдите: Администрирование → Настройка системы → вкладка Авторизация LDAP
    3. Установите ldap_server.enabled = true
    4. Заполните параметры подключения:
      • Укажите URL вашего LDAP/AD сервера
      • Введите базовый DN для поиска пользователей
      • Укажите учётные данные сервисной учётной записи
    5. При необходимости скорректируйте атрибуты (для нестандартных схем AD)
    6. Нажмите «Сохранить»
    7. Протестируйте подключение, создав тестового пользователя из LDAP

    Важно:


    4 ТЕХОБСЛУЖИВАНИЕ

    Раздел доступен только для системного пользователя Admin

    Включение скалирования метрик

    Автоматическое преобразование единиц измерения метрик в удобный для восприятия вид (например: байты → КБ → МБ → ГБ).
    Принцип работы
    Система автоматически масштабирует значения метрик по трём формулам:
    Формат отображения
    Примеры:
    Где применяется?

    Все сервисы мониторинга, в режимах отображения: "График коррелятор" (и в тултипах), "Таблицы", "Круговые диаграммы"

    Не применяется: "Отчёты SLA", "Автокоррелятор", другие разделы системы (значения остаются в исходных единицах)

    Как включить/отключить
    1. Авторизуйтесь под пользователем Admin (id-2)
    2. Перейдите: Администрирование → Настройка системы → вкладка Техобслуживание
    3. Найдите блок «Скалирование метрик»
    4. Переключите свитч:
      • Включено — метрики отображаются в скалированных единицах
      • Выключено — метрики отображаются в исходных единицах
    5. Нажмите «Сохранить»
    Важно:

    5. ПОЛНАЯ ОЧИСТКА ДАННЫХ ПО СЕРВИСУ

    Принудительное удаление всей накопленной исторической информации по сервису для начала сбора данных «с чистого листа» (например, перед финальной настройкой или после изменений инфраструктуры).
    Что удаляется?
    Ролевые ограничения
    Функция доступна только пользователю Admin (ID-2). Для всех остальных пользователей кнопка очистки скрыта, доступна только системная бессрочная или настраиваемая очистка за определенный период.
    Как выполнить очистку?
    1. Перейдите: Инфраструктура → Сервисы
    2. Откройте необходимый сервис для редактирования
    3. Перейдите на вкладку «Хранение данных»
    4. Нажмите кнопку «Принудительная очистка исторических данных»
    5. Подтвердите действие в появившемся окне:
      «Вы собираетесь очистить все исторические данные по сервису. Паспорта неисправности, статусы сервиса и результаты тестов будут безвозвратно удалены. Продолжить?»
      • «Да» — подтвердить очистку
      • «Отменить» — отменить операцию
    6. Система определит ближайший «Системный временной промежуток»
    7. Вы получите уведомление:
      «Очистка данных будет произведена: TT:TT, DD/MM/YY»
    Как это работает?
    Логирование
    Все действия фиксируются в «Журнале событий»:
    Важно:
    Удалённые данные не подлежат восстановлению!

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


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

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

    Роли


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

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

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

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

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

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

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

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

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

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

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

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

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

    Полное имя: Admin

    Эл. почта: Admin

    Пароль: Admin@123

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

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

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

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

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

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

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

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

     

    Действие

    Системный администратор

    Оператор SLA

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

     

     

    Без роли Оператор SLA и контрагента

    +Контрагент

    +Оператор SLA +Контрагент

    Контрагент без контракта

    + Контракт

    Без контрагентов и контрактов

    + Контракт

    + Контрагент

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

    Возможность видеть пользователей

    Все

    Все

    Все

    Только свой профиль

    Только свой профиль

    Только свой профиль

    Только свой профиль

    Только свой профиль

    Создание новых пользователей портала

    Да

    Да

    Да

    Нет

    Нет

    Нет

    Нет

    Нет

    Редактирование пользователей портала

    Да, пользователей и операторов SLA

    Да, пользователей и операторов SLA

    Да, пользователей и операторов SLA

    Только свой профиль

    Только свой профиль

    Только свой профиль

    Только свой профиль

    Только свой профиль

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

    Все

    Все

    Все

    Да, если доступны

    Да, если доступны

    Нет

    Нет

    Нет

    Возможность добавлять пользователей к контракту

    Нет

    Нет

    Да

    Да, если доступны

    Да, если доступны

    Нет

    Нет

    Нет

    Контрагенты

    Возможность видеть контрагентов

    Все

    Все

    Все

    Нет

    Да, только в настройках контракта

    Нет

    Да, только в настройках контрактов

    Да, только в настройках контрактов

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

    Да

    Да

    Да

    Да, только через настройки контракта

    Да, только через настройки контракта

    Нет

    Нет

    Нет

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

    Все

    Все

    Все

    Нет

    Нет, только добавление ролей через настройки контракта

    Нет

    Нет

    Нет

    Инфраструктура

    Возможность видеть объекты инфраструктуры

    Все

    Все

    Все

    Своего контрагента и его дочерних контрагентов

    Своего контрагента и его дочерних контрагентов, этого контракта.

    Нет

    Этого контракта

    Своего контрагента

    Создание объектов инфраструктуры

    Только показатели и SLA

    Только показатели и SLA

    Да

    Да

    Да

    Нет

    Нет

    Нет

    Редактирование и использование в других контрактах объектов инфраструктуры

    Только редактирование показателей и SLA, созданных системным администратором

    Только редактирование показателей и SLA, созданных системным администратором

    Да

    Да, редактирование показателей и SLA, созданных только оператором SLA

    Да, редактирование показателей и SLA, созданных только оператором SLA, этого контракта

    Нет

    Нет

    Нет

    Тесты

    Доступ к списку тестов

    Да

    Да

    Да

    Нет

    Нет

    Нет

    Нет

    Нет

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

    Да, редактирование тестов, созданных только системным администратором

    Да, редактирование тестов, созданных только системным администратором

    Да

    Да, через настройки сервиса (включая созданные системным администратором)

    Да, через настройки сервиса (включая созданные системным администратором)

    Нет

    Нет

    Нет

    Отчёты

    Просмотр отчётов SLA, паспортов неисправности, плановых работ, исключений

    Все

    Все

    Все

    Своего контрагента, его дочерних контрагентов

    Своего контрагента, его дочерних контрагентов, этого контракта

    Нет

    Этого контракта

    Своего контрагента

    Приостановка и продолжение паспортов неисправности, создание плановых работ и исключений

    Нет

    Нет

    Все

    Своего контрагента, его дочерних контрагентов

    Своего контрагента, его дочерних контрагентов, этого контракта

    Нет

    Нет

    Нет

    Загрузка шаблонов, формирование и публикация отчётов SLA

    Нет

    Нет

    Да

    Своего контрагента, его дочерних контрагентов

    Своего контрагента, его дочерних контрагентов, этого контракта

    Нет

    Нет

    Нет

    Перерасчёт отчётов SLA

    Нет

    Нет

    Да

    Своего контрагента, его дочерних контрагентов, только при наличии изменений по исключениям

    Своего контрагента, его дочерних контрагентов, этого контракта только при наличии изменений по исключениям

    Нет

    Нет

    Нет

    Аналитика

    Текущие показатели и виджеты

    Все

    Все

    Все

    Своего контрагента, его дочерних контрагентов

    Своего контрагента, его дочерних контрагентов

    Нет

    Этого контракта

    Своего контрагента

    Администрирование

    Доступ к разделу «Администрирование»

    Да

    Да

    Да

    Нет

    Нет

    Нет

    Нет

    Нет

    Топология сети

    Доступ к разделу «Топология сети»

    Нет доступа

    Доступ к топологии контрагента

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

    Доступ к топологии контрагента

    Доступ к топологии контракта

    Нет доступа

    Доступ к топологии контракта

    Доступ к топологии контрагента


    Просмотр объектов топологии

    Нет доступа

    Просмотр объектов контрагента

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

    Просмотр объектов контрагента

    Просмотр объектов контракта

    Ограниченный просмотр только объектов контракта

    Просмотр объектов контракта

    Просмотр объектов контрагента


    Масштабирование и фильтрация

    Нет доступа

    Базовое масштабирование и фильтрация

    Полный доступ к масштабированию и фильтрации

    Масштабирование и фильтрация

    Базовое масштабирование

    Нет доступа

    Базовое масштабирование

    Базовое масштабирование


    Добавление и удаление объектов

    Нет доступа

    Ограниченное добавление в контрагента

    Полный доступ к добавлению и удалению объектов

    Ограниченное добавление

    Добавление объектов по контракту

    Нет доступа

    Ограниченное добавление

    Ограниченное добавление


    Редактирование и перемещение объектов

    Нет доступа

    Ограниченное редактирование

    Полный доступ к редактированию и перемещению

    Ограниченное редактирование

    Ограниченное редактирование

    Нет доступа

    Ограниченное редактирование

    Ограниченное редактирование


    Сохранение топологии

    Нет доступа

    Ручное сохранение

    Выбор между ручным и автоматическим режимом

    Ограниченное сохранение

    Ограниченное сохранение

    Нет доступа

    Ограниченное сохранение

    Ограниченное сохранение


    Настройки топологии

    Нет доступа

    Ограниченный доступ к настройкам

    Полный доступ к настройкам топологии

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

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

    Нет доступа

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

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


    Поиск объектов в топологии

    Нет доступа

    Поиск по объектам контрагента

    Полный доступ к поиску по объектам

    Поиск по объектам контрагента

    Поиск по объектам контракта

    Нет доступа

    Поиск по объектам контракта

    Поиск по объектам контрагента


    Управление связями и каналами

    Нет доступа

    Ограниченное управление связями

    Полный доступ к созданию и редактированию связей и каналов

    Управление связями в пределах контракта

    Ограниченное управление

    Нет доступа

    Ограниченное управление

    Ограниченное управление


    Создание и редактирование групп объектов

    Нет доступа

    Ограниченное создание групп

    Полный доступ к созданию и редактированию групп объектов

    Ограниченное создание групп

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

    Нет доступа

    Ограниченное создание групп

    Ограниченное создание групп


    Просмотр и управление дочерними контрагентами

    Нет доступа

    Доступ к дочерним контрагентам

    Полный доступ к дочерним контрагентам

    Доступ к дочерним контрагентам

    Ограниченный доступ к дочерним контрагентам

    Нет доступа

    Ограниченный доступ

    Ограниченный доступ

     

    Специальные функции

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

    Создание контрактов и объектов инфраструктуры

     

     

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

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

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

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

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

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

    image.png

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

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

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

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

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

    В средствах установки, управления и конфигурации системы присутствует ряд возможностей по резервному копированию (backup) и восстановлению резервных копий (Рис.1)

    image_2026-01-23_13-57-32.png

    (Рис.1.) Изображения меню резервного копирования из средства установки, управления и конфигурации системы

    Восстановление базы данных HBase

    Backup HBase DB (Создание резервной копии) - при выборе данного пункта будет создан файл резервной копии backup-файл hb_2024-01-09.tar.gz - в нем будут содержится данные из NoSQL СУБД HBase.

    Restore HBase DB: clear and insert new tables (Полная замена данных) - при выборе данного пункта система запустит процесс очистки таблиц в NoSQL СУБД HBase. После завершения очистки система автоматически приступит к загрузке данных из резервной копии (backup-файла).

    Пример работы пункта Restore HBase DB: clear and insert new tables:

    При выборе пункта "NO" вы вернетесь в меню резервного копирования.

    image.png

    Рис.2 Предупреждение "All metric table will be renamed - Переименовать все метрики в таблицах"

    image.png

    Рис.3 Окно ввода пути до файла резервной копии

    Clear HBase DB tables (очистка данных) - при выборе данного пункта будет произведена полная очистка таблиц в NoSQL СУБД HBase.

    Восстановление базы данных PostgreSQL

    Backup Postgres DB (Создание резервной копии) - при выборе данного пункта будет создан файл резервной копии базы данных wisla в домашнем каталоге wisla.
    wisla_backup_2024_01_09.backup - в нем будут содержится данные из СУБД PostgreSQL.

    Restore Postgres DB(Полное восстановление) - при выборе данного пункта будет произведена процедура полного восстановления резервной копии данных в PostgreSQL.

    Перед выполнением пункта "Restore Postgres DB (Полное восстановление)" необходимо убедиться, что в целевой базе данных wisla в СУБД PostgreSQL нет данных. Если база wisla уже существует и содержит данные, их необходимо УДАЛИТЬ перед началом восстановления. В противном случае процесс может завершиться ошибкой или привести к повреждению данных.


    Удаление базы данных wisla в СУБД PostgreSql перед восстановлением.

    Рис. 4 Изображения меню резервного копирования из средства установки, управления и конфигурации системы

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

    Backup installation info - при выборе данного пункта будет создан файл резервной копии конфигураций приложения wisla в домашнем каталоге wisla.

    В архив попадают ключевые конфигурационные файлы из /opt/wisla5/current_version/:

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

    Автоматическое резервное копирование по расписанию.

    image.png

    Рис 6. Изображения меню резервного копирования из средства установки, управления и конфигурации системы

    Autobackup configuration  - при выборе данного пункта появится окно настройки автоматического резервного копирования.

    image.png

    Рис 7. Окно настройки автоматического резервного копирования

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

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

    image.pngРис 8. Окно с установкой времени выполнения автоматического резервного копирования

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

    8. ОТКАЗОУСТОЙЧИВЫЙ КЛАСТЕР

    Раздел «Отказоустойчивый кластер» включает следующие компоненты:
    «Необходимое окружение и библиотеки»,
    «Подготовительные этапы к установке кластера»,
    «Действия в программе установке wiSLA»,
    «Настройка скриптов для учёта кратковременных обрывов связи»,
    «Действия по восстановлению работы кластера при выходе из строя одного из узлов ЦОД1»,
    «Действия по восстановлению работы кластера при выходе из строя одного из узлов ЦОД2»,
    «Действия по восстановлению работы кластера при выходе из строя третьей точки опоры».

    8. ОТКАЗОУСТОЙЧИВЫЙ КЛАСТЕР

    Необходимое окружение и библиотеки

    Необходимые пакеты для установщика на 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

    На узлах 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.
    На самом деле установщик при установке видит что папки в home есть и на glusterVol есть папка hadoop, установщик предлагает на каждую папку запрос об удалении. Однако лучшим вариантом будет "почистить скриптом", т.к. это упростит работу.
    8. ОТКАЗОУСТОЙЧИВЫЙ КЛАСТЕР

    Подготовительные этапы к установке кластера

    Преимущества кластера

    Настройка отказоустойчивого кластера wiSLA позволяет решить 2 задачи:


    В примере будет показана установка системы wiSLA на отказоустойчивый контур, который включает в себя семь серверов, распределённых между двумя ЦОД (по три в каждом) и одним дополнительным сервером – «третьей точкой опоры» (см. рисунок 66). Для взаимодействия между серверами выделена подсеть «межсерверного взаимодействия».


    zzz.png

    Рис. 66 Логическая группировка серверов в отказоустойчивом контуре wiSLA

    Дополнительно могут быть развернуты wisla contactor portals (но не на 3 и 6 ноде, где уже есть портал оператора)

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

    В таблице приведён пример настройки отказоустойчивого контура, который содержит два ЦОД (по три сервера на каждом) и один дополнительный сервер (третья точки опоры).

    Таблица 8 – Топология кластера (пример).

    ЦОД / сервер

    Имя сервера (hostname) / IP-адрес

    Компоненты

    ЦОД1

    wislaserver01 / 192.168.1.101

    PostgreSQL: Master

    Pgpool

    HBase: HRegionServer

    Hadoop: DataNode

    Zookeeper

    wislaserver02 / 192.168.1.102

    HBase: HMaster, HRegionServer

    Hadoop: NameNode, DataNode

    Zookeeper

    wislaserver03 / 192.168.1.103

    APP-server

    WEB-server

    HBase: HRegionServer

    Hadoop: DataNode

    Zookeeper

    ЦОД2

    wislaserver04 / 192.168.1.104

    PostgreSQL: Slave

    Pgpool

    HBase: HRegionServer

    Hadoop: DataNode

    Zookeeper

    wislaserver05 / 192.168.1.105

    HBase: HMaster, HRegionServer

    Hadoop: NameNode, DataNode

    Zookeeper

    wislaserver06 / 192.168.1.106

    APP-server

    WEB-server

    HBase: HRegionServer

    Hadoop: DataNode

    Zookeeper

    Дополнительный сервер

    wislaserver07 / 192.168.1.107

    Zookeeper, wiSLA-Installer

    Предварительно для каждого сервера контура требуется базовая настройка, которая описана в разделе «Подготовка операционной системы к запуску программы установки». Для серверов с 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

    8. ОТКАЗОУСТОЙЧИВЫЙ КЛАСТЕР

    Действия в программе установки 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

    Указываем сеть в которой работает СУЩЕСТВУЮЩИЙ интерфейс, и указываем IP который НЕ используется. Также указываем СУЩЕСТВУЮЩИЙ интерфейс. pgpool на него навесит ip (причем ip уже должен быть назначен на всех хостах которые подключены в сеть, куда смотрит интерфейс). возможно стоит взять более широкую маску сети(/24)

    a) для корректной работы pgpool желателен отдельный сетевой интерфейс. К примеру он может быть вланом. 
    b) pgpool назначает на интерфейс ip, а :10 это номер псевдонима.
    c) в сети, на которую смотрит интерфейс должны быть назначены ip в той же подсети.
    d) активный pgpool назначает на этот интерфейс ip.
    e) если вы обращаетесь к PostgreSQL то должны быть подключены к сети, в которой есть pgpool

    11. Настройка компонента WildFly:

    12. Настройка топологии wiSLA.

    13. Настройки модуля сбора данных:

    14. Настройки интеграции LDAP.

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

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

    17. Настройка оператора портала.

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

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

    19. Автоматический запуск после установки.

    20. Реиндексация wildfly (не бд).

    21. Начало работы с порталом.

    8. ОТКАЗОУСТОЙЧИВЫЙ КЛАСТЕР

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

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

    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».
    8. ОТКАЗОУСТОЙЧИВЫЙ КЛАСТЕР

    Действия по восстановлению работы кластера при выходе из строя одного из узлов ЦОД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:

    В данном случае требуется восстановить согласованность данных и перенести активные модули на ЦОД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.

    8. ОТКАЗОУСТОЙЧИВЫЙ КЛАСТЕР

    Действия по восстановлению работы кластера при выходе из строя одного из узлов ЦОД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.

    8. ОТКАЗОУСТОЙЧИВЫЙ КЛАСТЕР

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

    Данная ситуация не влияет на работоспособность контура, но грозит отказом системы в случае выхода из строя одного из ЦОД. Для восстановления работы третьей точки опоры требуется выполнить следующие действия:
    1. Восстановить связь между узлами кластера.
    2. На сервере wislaserver07 запустить программу установки.
    3. В разделе «Maintenance» -> «Zookeeper management» запустить Zookeeper на сервере wislaserver07: 

    Start on wislaserver07

    4. Проверить состояние компонентов системы в разделе «Statuses» -> «All statuses» и работоспособность wiSLA.

    9. WISLA В ИЗОЛИРОВАННОМ КОНТУРЕ

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

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

    Настройки могут быть выполнены при первичной установке wiSLA или в процессе эксплуатации. Они задаются в программе установки wiSLA. Перед выполнением настроек следует:

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

    Переключение wiSLA в изолированный режим

    Все связанные с облачным режимом настройки находятся в программе установки на вкладке «wiSla
    resources configuration».

    Параметр «Local geo services» определяет тип контура:

    image.png

    Параметр «Nominatim service URL» предоставляет возможность работы с произвольным Nominatimсервером. Используется для определения координат по адресу в изолированном контуре. Данная настройка игнорируется для открытого контура, если значение задано. Пример значения: «http://map.wellink.ru/nominatim/».

    Параметр «URL to tiles for map» – путь к изображениям карты. Например, «http://map.wellink.ru/osm_tiles/».

    Для переключения wiSLA в изолированный режим требуется:

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

    При успешном появлении точки доступа в общем списке на странице «Точки доступа» переключение
    wiSLA в изолированный режим считается выполненным корректно.

    При успешном открытии карты сервисов после изменения в настройках адреса карт-сервера на локальный настройка карт-сервера считается выполненной успешно. Если же карта сервисов не открывается, на странице возникают ошибки, или масштаб невозможно изменить следует проверить корректность значения параметра «URL to tiles for map», доступность и работоспособность самого картсервера на рабочем месте администратора.

    При успешном получении координат в настройках точки доступа после изменения адреса геосервиса настройка геосервиса считается выполненной успешно. Если введённый адрес корректен, а координаты не определяются, следует повторить попытку с другим адресом. Если в обоих случаях система не смогла определить координаты, следует проверить корректность значения параметра «Local geo services», доступность и работоспособность локального геосервиса на рабочем месте администратора.

    Внимание, если не устанавливать URL для Nominatim - то можно задавать адрес вручную, но поиск не будет работать.

    10. ОБЛАЧНЫЙ РЕЖИМ

    Особенности облачного режима

    ПАК wiSLA может работать как облачная платформа, предоставляющая услуги мониторинга малому и среднему бизнесу (SME).

    Если портал развёрнут в режиме wiSLA.Cloud:

    Включение и настройка облачного режима

    Все связанные с облачным режимом настройки находятся в программе установки на вкладке «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:

    На рисунке 67 показан пример настройки wiSLA Cloud.

    image.png

    Рис. 67 Пример заполнения параметров на вкладке wiSLA Cloud System

    В примере после применения настроек:

    Подготовка ссылок на программные агенты

    Как было отмечено, пользователи в облачном режиме wiSLA могут загружать программные агенты для создания собственной инфраструктуры без помощи системного администратора. Загрузка проводится на странице «Справка», для этого предусмотрена кнопка «Загрузить Агент». Или на вкладке "Зонды", по кнопке "Скчать зонд". Список агентов, который получит пользователь портала после нажатия этой кнопки, зависит от настроек, выполненных на сервере 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 показан результат настройки на портале.

    image.png

    Рис. 68 Список агентов на портале оператора после настройки

    11. ПОДГОТОВКА АГЕНТА ДЛЯ АВТОМАТИЧЕСКОГО СКАНИРОВАНИЯ СЕТИ

    Сканирование сети выполняется для получения списка устройств с их IP-адресами для топологии сети, чтобы не создавать устройства вручную. Агентом для сканирования сети может быть любой сервер, виртуальная машина, зонд или иное устройство, работающее под управлением Unix-совместимой операционной системы, на которое можно установить пакеты, которые обеспечат сканирование. Устройство должно иметь возможность приёма команд с удалённого сервера по протоколу SSH.

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

    Установка проводится в соответствии с руководством администратора соответствующей операционной системы.

    Задания на сканирование подсетей поступают с сервера приложений wiSLA на агент в виде команд по протоколу SSH, выполняются с sudo и требуют привилегий администратора. Пользователь, под которым будет происходить подключение для запуска сканирования, должен входить в sudoers и иметь возможность выполнения команд с повышенными привилегиями без ввода пароля.

    После установки требуется настроить утилиту zmap. Обычно по умолчанию в ней отключено сканирование локальных подсетей. Для включения достаточно найти файл настроек zmap (как правило, это /etc/zmap/blacklist.conf), закомментировать строки, по которым планируется сканирование или добавить собственные правила. В случае проблем с установкой или настройкой zmap обратитесь в
    службу технической поддержки.

    В сети может работать несколько таких агентов. Администратор может проводить сканирование, последовательно меняя настройки сканирования на портале оператора в разделе «Топология сети».

    12. ПОДГОТОВКА СЕНСОРА 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"

    где:

    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"

    где:

    3.2.3 Сохраните файл и выйдите из редактора.

    4) Запуск и управление ftprobe
    5) Автозапуск при загрузке системы:
    5) Проверка статуса fprobe:

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

    Остановка fprobe:

    Перезапуск fprobe:

    Проверка что fprobe установлен:

    which fprobe

    Если команда возвращает путь (например, /usr/sbin/fprobe), значит, fprobe установлен. 

    Иные команды для управления службой fpobe

    Запуск сенсора:

    $ /etc/init.d/fprobe start

    Остановка сенсора:

    $ /etc/init.d/fprobe stop

    Перезапуск сенсора:

    $ /etc/init.d/fprobe restart
    Пример файла настройки fprobe:

    Расположение: /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"

    Расположение: /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. 

    13. РАСЧЕТ АППАРАТНОЙ ЧАСТИ WISLA


    13. РАСЧЕТ АППАРАТНОЙ ЧАСТИ 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 ТБ в зависимости от срока хранения, частоты съема резервных копий, глубины хранения данных.

    Аппаратные конфигурации на каждый тип сервера:


    РАСЧЕТ АППАРАТНОЙ ЧАСТИ ПРОМЫШЛЕННОГО КОНТУРА WISLA С УЧЁТОМ ОТКАЗОУСТОЙЧИВОСТИ

    1. Кластерное решение для средних нагрузок (4 сервера для развертывания (2+2))

         2. Кластерное решение для высоких нагрузок (6 серверов для развертывания (4+2))

    Опционально: Backup server. Рекомендуется предусмотреть сервер для хранения резервных копий.
    От 1 ТБ до ~10 ТБ в зависимости от срока хранения, частоты съема резервных копий, глубины хранения данных. 

    Аппаратные конфигурации на каждый тип сервера:

    ЗАКЛЮЧЕНИЕ
    Приведенные выше расчеты являются рекомендуемыми и носят справочный характер. В рамках отдельных проектов параметры и конфигурация промышленного контура могут отличаться.
    Аппаратные конфигурации приводятся исходя из рекомендаций руководств по эксплуатации, используемых в системе продуктов (Java, JBoss, PostgreSQL, Hbase).

    14. ПРОДЛЕНИЕ ЛИЦЕНЗИИ

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

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

    Кто может продлевать лицензию?

    Продление лицензии доступно только для системного пользователя Admin. Учетные данные для него передаются при оформлении лицензии на ПО.

    Порядок продления лицензии
    1. Авторизуйтесь в системе под учетной записью Admin.
    2. Перейдите в раздел Администрирование → Настройка системы.
    3. Откройте вкладку Техобслуживание. В блоке отображается текущая дата окончания лицензии.
    4. В поле Лицензионный ключ введите новый ключ, полученный от вендора или менеджера.
    5. Нажмите кнопку "Обновить ключ".
    6. Убедитесь, что в интерфейсе отобразилась новая дата окончания срока действия.

    image.png

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

    15. ВАЖНАЯ ИНФОРМАЦИЯ

    О документе

    © 2025 ООО “НТЦ Веллинк”. Все права защищены.

    Компания ООО “НТЦ Веллинк” оставляет за собой право в одностороннем порядке без какого-либо специального уведомления, без согласия Пользователя в любое время вносить улучшения и/или изменения в продукты и/или программное обеспечение, дополнять и/или изменять настоящий документ. Новая редакция документа вступает в силу с момента ее размещения в Базе знаний компании ООО “НТЦ Веллинк” по адресу info.wellink.ru. Убедитесь, что Вы читаете последнюю актуальную версию настоящего документа.

    Были предприняты максимальные усилия для того, чтобы гарантировать полноту и точность представленной в документе информации. ООО “НТЦ Веллинк” не несет ответственности за возможные описки и неточности.
    Использование Пользователем продукта и/или программного обеспечение после любых изменений и/или улучшений означает его согласие с такими изменениями и/или улучшениями.

    Если у вас есть замечания, касающиеся данного документа или продуктов, которые он описывает, направляйте их по адресу support@wellink.ru.

    О компании

    ООО “НТЦ Веллинк” (www.wellink.ru) разрабатывает инновационные продукты и решения в области автоматизации и управления качеством информационных и телекоммуникационных услуг для операторов связи, государственного и корпоративного сегментов.

    wiSLA, wiProbe, wiTest — являются официально зарегистрированными торговыми марками компании ООО “НТЦ Веллинк”, имеют все необходимые сертификаты и защищены авторским правом.

    ООО “НТЦ Веллинк” оказывает услуги по внедрению, сопровождению и улучшению своих продуктов согласно требованиям заказчика. При внедрении своих продуктов ООО “НТЦ Веллинк” опирается на обширную партнерскую сеть, которая непрерывно развивается на территории Российской Федерации и за ее пределами. Сервисный центр компании ООО “НТЦ Веллинк” готов оказывать услуги технической поддержки высокого качества в режиме 24х7.

    Девиз ООО “НТЦ Веллинк”: Гибкость в отношениях, Инновации в разработке, Простота в использовании. Мы открыты для партнерства и интеграции. Мы делаем услуги измеримыми не только по цене, но и по качеству!
    Головной офис компании находится по адресу: 127322, Москва, ул. Яблочкова, д.21, корп.3 тел./факс: +7(495)665-92-63

    Интернет-сайт: www.wellink.ru

    image.png

     

     

    127322, г. Москва,

    ул. Яблочкова, д.21, корп.3
    Тел.: +7(495)665-92-63