wiSLA.Руководство администратора 4.2

Wellink R&D LLC
127322, Москва,
ул. Яблочкова, 21к3
Тел.: +7 (495) 374-66-78
www.wellink.ru
wiSLA (well integrated SLA)

Руководство администратора
Версия: 4.2
Статус: Для клиентов
Автор: Юрий Комиссаров
© Wellink, 2018 1 All rights reserved

ИСТОРИЯ ИЗМЕНЕНИЙ ДОКУМЕНТА
Версия Дата Описание Автор
0.1 15.07.2017 Обновлено до 4.0 Ю. Комиссаров
0.2 16.03.2018 Обновлено до 4.1 Д. Дякив
0.3 09.07.2018 Обновлено до 4.1.1 Ю. Комиссаров
0.4 14.11.2018 Обновлено до 4.2 Е. Семёнова

ОГЛАВЛЕНИЕ
ИСТОРИЯ ИЗМЕНЕНИЙ ДОКУМЕНТА 2
ОГЛАВЛЕНИЕ 3
ЗНАКОМСТВО С WISLA 5
НАЗНАЧЕНИЕ СИСТЕМЫ 5
ЗАДАЧИ, РЕШАЕМЫЕ СИСТЕМОЙ 5
АРХИТЕКТУРА И СОСТАВ ПЛАТФОРМЫ WISLA 7
УСТАНОВКА WISLA 14
АППАРАТНЫЕ ТРЕБОВАНИЯ 14
ПРОГРАММНЫЕ ТРЕБОВАНИЯ 16
РАБОТА С ПРОГРАММОЙ УСТАНОВКИ 22
НАЧАЛО РАБОТЫ С ПОРТАЛОМ 38
ПОЛУЧЕНИЕ ДОСТУПА НА ПОРТАЛ 38
ПОЛУЧЕНИЕ ДОСТУПА НА ОБЛАЧНУЮ ВЕРСИЮ ПОРТАЛА 39
ВОССТАНОВЛЕНИЕ ПАРОЛЯ 40
ОПИСАНИЕ ЭЛЕМЕНТОВ ПОРТАЛА 41
АДМИНИСТРИРОВАНИЕ 50
КОНТРАГЕНТЫ 50
SLA 54
ТОЧКИ ДОСТУПА 62
ТЕСТЫ 65
ИМПОРТ И ЭКСПОРТ СПИСКОВ ОБЪЕКТОВ 70
УЧЕТНЫЕ ЗАПИСИ 73

СЕССИИ 78
ЖУРНАЛ СОБЫТИЙ 79
РАЗГРАНИЧЕНИЕ ПРАВ ДОСТУПА 81
РОЛИ 81
ПРАВА НА ДЕЙСТВИЯ С ОБЪЕКТАМИ 81
РЕДАКТИРОВАНИЕ ВЛАДЕЛЬЦЕВ СУЩНОСТЕЙ 86
РЕЗЕРВНОЕ КОПИРОВАНИЕ СИСТЕМЫ 87
ОТКАЗОУСТОЙЧИВЫЙ КЛАСТЕР WISLA 90
WISLA В ИЗОЛИРОВАННОМ КОНТУРЕ 112
ОСОБЕННОСТИ РАБОТЫ WISLA В ИЗОЛИРОВАННОМ КОНТУРЕ 112
ПЕРЕКЛЮЧЕНИЕ WISLA В ИЗОЛИРОВАННЫЙ РЕЖИМ 112
ОБЛАЧНЫЙ РЕЖИМ WISLA 114
ОСОБЕННОСТИ ОБЛАЧНОГО РЕЖИМА 114
ВКЛЮЧЕНИЕ И НАСТРОЙКА ОБЛАЧНОГО РЕЖИМА 114
ПОДГОТОВКА ССЫЛОК НА ПРОГРАММНЫЕ АГЕНТЫ 115
ВАЖНАЯ ИНФОРМАЦИЯ 118

ЗНАКОМСТВО С WISLA
Назначение системы
wiSLA 4.2 (well integrated SLA) – это новое поколение платформы автоматизации и обеспечения
качества услуг связи, сервисов ИТ, информационных систем и облачных сервисов для операторов
связи, государственных учреждений и крупного корпоративного сегмента рынка.
Программно-аппаратная платформа wiSLA позволяет урегулировать конфликты между

поставщиками и потребителями услуг связи на основе мониторинга и управления процессами
обеспечения качества в рамках жизненного цикла услуги (PLM).
В основу платформы wiSLA заложена следующая идеология:
управление конфликтами (Conflict Management) – решения на базе платформы wiSLA

являются пограничными и предоставляют информацию, как провайдеру услуги, так и ее
потребителю;
мониторинг качества сервисов (Service Quality Management – SQM) – проактивный
мониторинг позволяет оперативно реагировать на случаи ухудшения качества
контролируемых услуг и быстро локализовать проблему;
управление соглашением об уровне обслуживания (Service Level Management –
SLA/SLM) – платформа обеспечивает формирование периодических детальных отчетов
SLA для анализа соответствия уровня услуг ожиданиям клиента и расчета компенсаций за
его нарушение;
управление восприятием пользователей (Customer Experience Management – CEM) –

в платформу заложена гибкая модель формирования цепочки показателей KPI-KQI,
которая позволяет формировать агрегированные верхнеуровневые секторальные отчеты о
качестве услуг.
Задачи, решаемые системой
Мониторинг качества L2/L3 VPN и услуг широкополосного доступа в Интернет
Одной из основных задач, решаемых с помощью платформы wiSLA, является мониторинг и

управление качеством VPN L2/L3 уровня и услуг широкополосного доступа в Интернет.
Мониторинг осуществляется проактивно, путем активного измерения ключевых параметров
качества услуги (процент потери пакетов, задержка передачи пакета, джиттер) с применением
аппаратных зондов (wiProbe, Berkut M716) или встроенных в сетевое оборудование механизмов
оценки качества IP-соединения (например, Cisco IP SLA). Данные измерений поступают на
центральный сервер и анализируются на соответствие пороговым значениям, определенным
требованиям SLA к качеству контролируемой услуги. Результаты отображаются на порталах
платформы в виде графиков и диаграмм.

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

циклам поставщика услуги. Отчеты формируются по заранее согласованным и определенным SLA
правилам: набор показателей качества услуги, правила определения нарушений и расчета
верхнеуровневых показателей качества (готовность, скидка). Платформа позволяет
контролировать весь процесс SLA от согласования набора метрик и их пороговых значений до
учета версий контракта и его изменений, исключения согласованных нарушений из отчета и
расчета размера компенсаций за итоговое нарушение уровня обслуживания согласно SLA.
Сформированный отчет SLA доступен как поставщику услуги, так и клиенту, что позволяет им
урегулировать возникающие спорные ситуации на основе единых релевантных данных.
Мониторинг доступности и производительности сервисов L7 и приложений

(Application Performance Management)
Мониторинг доступности и производительности корпоративных облачных информационных систем

(CRM, Order Manegement, Trouble Ticketing, базы данных и т.д.) – одна из центральных задач
wiSLA. Платформа позволяет не только контролировать доступность информационных систем из
каждой точки доступа (магистральные узлы сети интернет, офисы конечных пользователей), но и
осуществляет глубокий мониторинг программной и аппаратной части инфраструктуры (сервера,
виртуальной машины), что обеспечивает разграничение ответственности между каналом связи до
ЦОД, неисправностью сервера и проблемами с самим корпоративным приложением.
wiSLA обеспечивает многоуровневый мониторинг пользовательских сервисов L7 (WEB-порталы,

базы данных, WEB-сервисы (REST, SOAP и т.д.) путем имитации действий реальных
пользователей (авторизация на портале, введение и анализ поисковых запросов, выполнение
SQL-транзакций и т.д.).
Мониторинг видеоконференцсвязи
Платформа wiSLA позволяет производить мониторинг видеоконференцсвязи (ВКС),

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

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

Архитектура и состав платформы wiSLA
Общее описание архитектуры
ПАК wiSLA относится к разряду крупных корпоративных приложений, архитектура которого

построена по многослойной модели и соответствует Java Platform, Enterprise Edition (Java EE).
Программное обеспечение ПАК wiSLA представляет собой систему распределенных компонентов,
взаимодействующих через внутренние интерфейсы.
Все составляющие ПО ПАК wiSLA поддерживают спецификацию Java EE. Это позволяет легче
обеспечивать высокое качество и надежность взаимодействия компонентов, полную
согласованность с применяемыми технологиями, такими как Hibernate, Spring, JSF и др.
Это означает, что элементами архитектуры ПАК wiSLA являются компоненты, каждый из которых
предоставляет необходимые сервисы, т.е. наборы выполняемых функций. Каждый компонент
инкапсулирован, его интерфейсы обеспечивают доступ к бизнес-правилам, данным и операциям.
Компоненты, как и сервисы, разделены на три типа: служебные, бизнес-компоненты/сервисы и
управляющие.
Взаимодействие между компонентами осуществляется с помощью общей коммуникационной

среды – обобщенной шины для обмена информацией (Common Communication Vehicle, CCV).
Подсистема медиации (Mediation)
Подсистема медиации (Mediation), рисунок 1, обеспечивает двустороннее взаимодействие

системы с аппаратными и программными измерительными зондами, базами данных.
Рис. 1 Подсистема медиации (Mediation)
Сбор данных подсистемы спроектирован на базе многопоточной архитектуры с возможностью

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

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

различных сегментах сети по географическому или функциональному признаку могут быть
выделены специальные коллекторы, выполняющие функции агрегации операций по сбору
данных и оптимизации нагрузки на центральные компоненты подсистемы;
независимые адаптеры. Сбор данных с каждого конкретного типа устройств
осуществляется единым внутренним интерфейсом с помощью специально разработанных
адаптеров, выполняющих набор устройство-специфичных действий. Это позволяет
разработчикам в «горячем режиме» вносить изменения в каждый адаптер по отдельности
и легче поддерживать новые версии прошивок устройств;
поддержка устройств за NAT. Подсистема сбора данных может работать не только в
классическом активном режиме (SNMP-запросы, выполнение CLI-команд в Telnet/SSH), но
и принимать SNMP Trap, HTTP Get/Post запросы от измерительных средств и внешних
систем.
Подсистема управления SLA (SLM)
Центром платформы wiSLA является подсистема управления SLA (Service Level Management),
рисунок 2, которая обеспечивает выполнение набора ключевых функций в рамках процесса
управления качеством услуг: формирование периодических отчетов SLA, расчет компенсаций за
нарушение уровня обслуживания и учет времени согласованных перерывов работы (отключение
электропитания в офисе клиента, планово-профилактические работы, форс-мажоры и т.д.).
Рис. 2 Подсистема управления SLA (SLM)

гибкий конструктор параметров SLA. Заложенная в систему модель вложенности
шаблонов SLA (набор показателей качества услуги и их пороговые значения) и классов
обслуживания, описывающая уровень реагирования на проблемы клиента (время на
устранение аварий, уровни эскалации SLA), позволяет отвечать любым запросам
различных групп клиентов, сохраняя при этом индивидуальный подход;
настраиваемые правила расчета. Анализ и оценка уровня обслуживания основана на
гибко настраиваемом механизме расчета ключевых показателей качества: готовность
услуги, суммарное время не обслуживания, среднее время между авариями и др. Т.е.,
например, для расчета суммарного времени неготовности услуги могут браться только
интервалы, которые не обслуживались более 15 минут, игнорируя при этом более
короткие.
Подсистема мониторинга качества сервиса (SQM)
Подсистема мониторинга качества сервиса (SQM), рисунок 3 обеспечивает непрерывный

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

Рис. 3 Подсистема мониторинга качества сервиса (SQM)
Важной частью SQM является SQM-монитор, который реализован на базе Java Message Service. В
каждом цикле сбора данных SQM-монитор сравнивает показатели качества услуги со значениями
в договорах SLA и определяет статус сервиса.
К функциям, реализуемым подсистемой, относятся:

анализ поступающей от подсистемы сбора данных информации:
• сравнение значений показателей качества с установленными SLA порогами,
• частота обновления информации от 10 секунд до 1 часа;

инициация нагрузочного тестирования контролируемых услуг;
формирование оперативных отчетов показателей производительности услуг (KPI);

мониторинг группы каналов в момент проведения видеоконференции.

обработка BigData. Для повышения производительности и обработки массивного потока
данных, поступающих от измерительных зондов, используется нереляционная
распределённая база данных HBase, которая обеспечивает отказоустойчивый способ
хранения больших объёмов разреженных данных;
многогранный мониторинг. Архитектура и объектная модель подсистемы SQM
обеспечивает возможность мониторинга одной услуги в различных срезах, например,
оценить качество канала связи между Москвой и Новосибирском в разрезе прохождения
различных типов трафика (данные, голос, видео и др.).
Подсистема учета неисправностей (Service Desk)
Подсистема учета неисправностей (Service Desk), рисунок 4, отвечает за регистрацию

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

Рис. 4 Подсистема учета неисправностей (Service Desk)
Высокое время реакции на аварийное событие достигается за счет взаимодействия с подсистемой

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

встроенный FM-engine. В подсистему учета неисправностей заложены все базовые
функции управления жизненным циклом аварии (открытие, обработка, приостановка,
закрытие), а также корреляция аварийных событий по времени открытия, точкам доступа и
классам трафика;
гибкая настройка времени реакции. Подсистема учета неисправностей позволяет гибко
настраивать время реакции системы на аварийные сигналы. Паспорт неисправности может
быть открыт мгновенно или через заданное время, в течение которого услуга находится в
аварийном состоянии. Это позволяет избегать шквалов уведомлений о кратковременных
проблемах.
Подсистема учета (SMDB)
Подсистема учета (SMDB), рисунок 5, обеспечивает учет и управление инфраструктурой

контролируемых услуг и измерительного оборудования. Подсистема обеспечивает управление
взаимосвязями между такими сущностями, как контрагент, контракт, сервисы, профили, точки
доступа, измерительное оборудование и тесты в соответствии в SID (Shared Information and Data
Model). Согласно TAM (Telecom Operations Map), подсистема учета выполняет функции Resource
Inventory, Service Inventory, Customer Inventory (CRM). В подсистеме учета также хранятся цепочки
показателей качества и производительности KPI/KQI в привязке к сервисам.

Рис. 5 Подсистема учета (SMBD)
Интеграционная платформа (Integration Framework)
Интеграция wiSLA с внешними системами OSS/BSS выполняется посредством интеграционной

платформы (Integration Framework), показанной на рисунке 6. В основу платформы заложены
сервисно-ориентированная архитектура (SOA) и открытые интерфейсы (WSDL/SOAP/XML). wiSLA
содержит прединтегрированные модули к существующим системам Trouble Ticketing, Fault
Management, Order Management, а также модули к внешним Web-порталам Заказчика.
Дополнительно в рамках интеграционной платформы может поставляться модуль управления
бизнес-процессами (BPM).
Рис. 6 Интеграционная платформа (Integration Framework)
Портал оператора (Operator Portal)
Портал оператора ПАК wiSLA (рисунок 7) предназначен для управления системой: постановка
услуг на мониторинг, настройкой параметров SLA, управления правами доступа пользователей,

журналирование системных событий. Портал оператора реализован с использованием последних
технологий WEB2.0, AJAX.
Рис. 7 Портал оператора (Operator Portal) ПАК wiSLA
Мобильные приложения wiSLA
Мобильные приложения wiSLA (рисунок 8) предназначены для тех, кто хочет быть всегда в курсе
состояния контролируемых услуг, и обеспечивают оперативный удаленный доступ к наиболее
важным функциям системы. Приложения доступны для мобильных операционных систем Android и
iOS. Взаимодействие с wiSLA осуществляется через открытый интерфейс REST API с
использованием средств шифрования канала SSL.
Рис. 8 Мобильное приложение wiSLA для платформы iOS
Функциональное назначение серверов wiSLA
Сервера wiSLA для контура различаются по своему функциональному назначению:
1. Demo Server (демонстрационный сервер).
2. Application Server (сервера приложений JBoss).

3. SQL Server (СУБД PostgreSQL).
4. NoSQL Server (HBase) – включает в себя HBase Master и Region Server.
5. DB Controller Server (HBase Master + pgpool II).
6. NoSQL Data Server (HBase Region Server).

УСТАНОВКА WISLA
Аппаратные требования
Без учета отказоустойчивости
Аппаратные конфигурации для каждого типа сервера:
1. Demo Server для тестово-демонстрационных целей на новых площадках.

CPU: 4 core;
RAM: 8 GB;
HDD: 50+ GB (no RAID).
2. Application Server. Выполняет основную бизнес-логику системы, от сбора данных до расчета

отчетов SLA. Обрабатывает запросы пользователей.
CPU: 8 core;
RAM: 16 GB;
HDD: 1TB (no RAID).
3. SQL Server. Сервер, управляющий работой базы данных, в которой находится инфраструктура
системы и некоторые рассчитываемые данные: статусы сервисов, паспорта неисправности,
отчеты SLA.
CPU: 8 core;
RAM: 32 GB;
HDD: 4 x 1TB (RAID 0+1).
4. NoSQL Server. Сервер-контроллер и хранилище для больших объемов данных, представленных

значениями метрик.
CPU: 8 core;
RAM: 24 GB;
5. DB Controller Server. Сервер-контроллер, управляющий одним или несколькими серверами

типов 2 и 5.
CPU: 8 core;
RAM: 24 GB;

6. NoSQL Data Server. Сервер-хранилище для больших объемов данных, представленных
значениями метрик. Используется в количестве трех и более.
CPU: 8 core;
RAM: 24 GB;
HDD: 1 TB (no RAID).
В зависимости от объема инфраструктуры некоторые сервера могут сливаться в один с

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

тестов приведена в таблице 1.
Таблица 1 – Расчет конфигурации системы без учета отказоустойчивости, исходя из количества

тестов.
Приблизительное Конфигурация
число тестов
0 – 100 Один сервер типа 1
101 – 1 000 Один сервер типа 3, включает в себя все остальные
1 001 – 10 000 Один сервер типа 2, один сервер типа 3 (включает в себя все остальные)
10 001 – 30 000 Один сервер типа 2, один сервер типа 3, один типа 4 (включает в себя 4, 5)
30 001 – 50 000 Два сервера типа 2, два сервера типа 3, один типа 4 (включает в себя 4, 5)
50 001 – 70 000 Два сервера типа 2, два сервера типа 3, один типа 5, три типа 6
70 001 – 100 000 Три сервера типа 2, два-три сервера типа 3, один типа 5, три типа 6
100 001 и более Более трех серверов типа 2, более трех типа 3, один типа 5, более трех
типа 6 (частичная отказоустойчивость)
Приведенные расчеты являются теоретическими.
Аппаратные конфигурации приводятся исходя из рекомендаций руководств по эксплуатации,

используемых в системе продуктов (Java, JBoss, PostgreSQL, HBase).
Более точные расчеты требуют проведения экспериментов с длительным наблюдением и

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

есть дублированию узлов на всех уровнях системы: приложение, SQL-хранилище, NoSQL-
хранилище. Благодаря такому разделению на уровни, кластеризацию можно организовать на
каждом уровне по индивидуальным правилам и критериям. Такой подход оправдан в случае
больших инфраструктур: 30 тысяч тестов и более. В случае инфраструктур до 10 тысяч тестов, в
целях упрощения требований, возможны варианты организации единого кластера для всех
уровней.
Рекомендованная конфигурация сервера:

CPU: 8 core;

RAM: 32 GB;
Расчет конфигурации, исходя из количества тестов, приведен в таблице 2:
Таблица 2 – Расчет конфигурации для отказоустойчивого контура, исходя из количества тестов.
Приблизительное число Конфигурация

тестов
1 000 – 30 000 5 серверов
30 001 – 100 000 7 серверов
Для организации резервного копирования необходимо предусмотреть отдельный сервер, по

характеристикам не превышающий рекомендованный, но с большим количеством и объемом HDD,
например 4 x 1 TB (RAID 1).
Приведенные расчеты являются теоретическими и приводятся исходя из рекомендаций

руководств по эксплуатации, используемых в системе продуктов (Java, JBoss, PostgreSQL, HBase).
Более точные расчеты требуют проведения экспериментов с длительным наблюдением и

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

размером 1Гб, объем диска на обоих серверах должен быть одинаковым.
Программные требования
1. Для работы wiSLA на сервере должна быть установлена операционная система CentOS
версии не ниже 6 (архитектура x86_64).
2. Для возможности запуска программы установки потребуется дополнительная установка
зависимостей. Для этого ОС должна иметь доступ к репозиториям на время настройки
системы. Если это невозможно, следует обратиться в службу технической поддержки.
3. Для корректного определения координат точек доступа сервера wiSLA и рабочие места
пользователей должны иметь доступ к сети интернет. Если доступ к интернет невозможен,
потребуется развернуть локальный карт-сервер (обратитесь в службу поддержки за
получением инструкций).
4. Для корректной работы email-рассылки серверам wiSLA должен быть доступен
корпоративный или внешний mail-сервер.
Подготовка операционной системы к запуску программы установки
Перед запуском программы установки требуется выполнить следующие шаги.
1. Установить, запустить и настроить приложение – SSH-клиент. Для Windows рекомендуется

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

2. Добавление hostname в /etc/hosts (ххх.ххх.ххх.ххх – IP-адрес сервера wiSLA, wisla – имя
сервера). Выполняется на всех серверах.
ххх.ххх.ххх.ххх wisla
3. Проверка имени хоста в /etc/sysconfig/network, должна присутствовать строка с hostname.

Выполняется на всех серверах.
HOSTNAME=wisla
4. Создание пользователя wiSLA. Выполняется на всех серверах.
adduser wisla
5. Создание пароля для пользователя wisla. Выполняется на всех серверах.
passwd wisla
6. Добавление пользователя wisla в sudoers. Выполняется на всех серверах.
Добавление пользователя в sudoers нужно только для возможности добавления wisla в автозапуск
в конце установки. Если добавлять wisla в автозапуск не требуется, этот шаг можно пропустить.
visudo
## Allow root to run any commands anywhere
root ALL=(ALL) ALL
wisla ALL=(ALL) ALL
7. Создание каталога /opt/wisla3. Выполняется на всех серверах.
mkdir /opt/wisla3
8. Выдача прав пользователю wisla на каталог /opt/wisla3. Выполняется на всех серверах.
chown wisla.wisla /opt/wisla3 -R
9. Копирование дистрибутива wisla*.run. Можно выполнить с помощью программы winSCP

или другим доступным способом в папку /home/wisla/ после создания пользователя wisla.
Достаточно скопировать дистрибутив на один сервер, на котором планируется выполнять
централизованный процесс установки.
10. Выдача прав пользователю wisla на файл установки.
chown wisla.wisla /home/wisla/wisla*.run -R
11. Сделать файл установки исполняемым.

chmod +x /home/wisla/wisla*.run
12. Установка зависимостей: lzo, pipe viewer, dialog, rsync, uuid, zip, unzip, sudo. Выполняется
только на сервере с дистрибутивом.
yum install lzo dialog rsync uuid zip unzip sudo python-crypto python-paramiko wget
wget http://www.ivarch.com/programs/rpms/pv-1.4.12-1.x86_64.rpm
rpm -ivh pv-1.4.12-1.x86_64.rpm
13. Настройка iptables. Выполняется на всех серверах.
su
vi /etc/sysconfig/iptables
Ниже приведён пример настройки:
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [75:7424]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -j ACCEPT
# wiSLA portal
-A INPUT -m state --state NEW -m tcp -p tcp --dport 8443 -j ACCEPT
# Netflow statistic
-A INPUT -m state --state NEW -m udp -p udp --dport 9996 -j ACCEPT

# NTP
-A INPUT -m state --state NEW -m udp -p udp --dport 123 -j ACCEPT
# wiSLA clusterization
-A INPUT -m pkttype --pkt-type multicast -j ACCEPT
### start hadoop&hbase configuration
## Hadoop configuration
## HTTP status web services
# Jobtracker http
# Tasktracker http
# Name node http
# Data node http
## Hadoop primary
# Hadoop Name Node

# Hadoop MapReduce
# Hadoop Data Node
# Hazelcast
# Hadoop Data Node IPC
## HBase configuration
# HBase primary
# HBase master
# HBase regional
## HTTP status web services
# Master http
# Regional http

# ZooKeeper
# Postgres
### end hadoop&hbase configuration
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
14. Перезапуск iptables. Выполняется на всех серверах.
service iptables restart
15. Настройка limits.conf. Выполняется на всех серверах.
su
vi /etc/security/limits.conf
wisla soft nofile 32768
wisla hard nofile 32768
wisla soft nproc 32768
wisla hard nproc 32768
16. Генерация ключа для беспарольного доступа по SSH для пользователя wisla. Требуется
сгенерировать ключ для каждого сервера и выполнить обмен ключами между серверами
так, чтобы с сервера с дистрибутивом wiSLA был организован беспарольный SSH-доступ
по ключу к любому из серверов.

su wisla
cd
ssh-keygen -t dsa -P ""
17. Обмен открытыми ключами. В примере показан обмен ключами в рамках одного сервера.
Если требуется выполнить обмен по сети, рекомендуется воспользоваться стандартной
утилитой ssh-copy-id.
cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
18. Проверка работы ключа.
ssh wisla@`hostname`
Запроса пароля не должно быть.
После выполнения всех перечисленных действий операционная система подготовлена к запуску

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

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

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

утилиты PuTTY для корректной работы программы не рекомендуется разворачивать окно на весь
экран.
Если установка wiSLA будет аварийно прервана или завершена с ошибкой, выполненные
настройки будут утеряны.
Запуск программы установки
Для запуска программы установки требуется:
1. Выполнить вход от имени пользователя wisla с подгрузкой переменных окружения:
su –l wisla

2. Войти в каталог, куда была скопирована программа установки.
3. Выполнить команду для запуска:
./wisla*.run
Должно открыться окно, показанное на рисунке 9.
Рис. 9 Интерфейс программы установки: окно предварительных настроек
Если показанное на рисунке 9 окно не открылось, следует проанализировать сообщения об

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

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

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

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

сервере. В описании к действию Install отображается версия, которая будет
установлена, и номер сборки (номер сборки на рисунке может не совпадать с
реальным). Нужно нажать Enter (выполнив тем самым действие «Next») на строке
«Install».
3. На следующем экране настраивается топология. В примере, показанном на рисунке 11,
установка производится на сервер VM1. Все компоненты размещаются на одном
сервере. Зелёная стрелка вниз сигнализирует о наличии настроек вне области
видимости. Для доступа к ним нужно последовательно нажимать кнопку «вниз». После
выполнения настроек переход к следующему экрану осуществляется кнопкой Next.
Если требуется распределить компоненты по разным серверам, нужно указать здесь
имена хостов, соответствующие предполагаемым серверам. В этом случае нужно,
чтобы между серверами был организован беспарольный доступ по ключу (SSH) под
пользователем wisla.
Рис. 11 Интерфейс программы установки: топология

4. После задания топологии нужно немного подождать. Будет выполнена инициализация
необходимых модулей и распаковка дистрибутива во временный каталог. Время
ожидания зависит от производительности дисковой подсистемы.
5. После распаковки программа установки оценит параметры сервера и автоматически
рассчитает значения по распределению оперативной памяти для различных
компонентов системы. Впоследствии их можно будет изменить, однако это стоит
делать только в том случае, когда администратору точно известно, что предложенные
значения неоптимальны или ошибочны.
6. На следующем экране (рисунок 12) требуется выбрать версию и архитектуру Java
Runtime Environment (как правило, используется архитектура x86_64, а версия
представлена одна).
Рис. 12 Интерфейс программы установки: выбор версии JRE
7. Настройка компонента Zookeper (рисунок 13). Рекомендуется оставить настройки,

предложенные по умолчанию.
Рис. 13 Интерфейс программы установки: настройки компонента Zookeeper
8. Настройка компонента Hadoop (рисунок 14). Рекомендуется оставить настройки,


Рис. 14 Интерфейс программы установки: настройки компонента Hadoop
9. Настройка компонента HBase (рисунок 15). Рекомендуется оставить настройки,

Рис. 15 Интерфейс программы установки: настройки компонента HBase
10. Настройка компонента PostgreSQL (рисунок 16). Требуется прокрутить список настроек
и изменить параметр «Trusted network/host». В примере сервер БД будет принимать
все подключения от адресов 192.168.2.x. В случае неудачной настройки параметра
установка wiSLA завершится ошибкой, так как сервер БД не сможет инициализировать
БД.

Рис. 16 Интерфейс программы установки: настройки компонента PostgreSQL
11. Настройка компонента JBoss (рисунок 17). Рекомендуется оставить настройки,

Рис. 17 Интерфейс программы установки: настройки компонента JBoss
12. Настройка топологии wiSLA. В примере все компоненты устанавливаются на сервер с

именем VM1 (рисунок 18).

Рис. 18 Интерфейс программы установки: настройки топологии wiSLA
13. Настройки модуля сбора данных. Если планируется использование зондов wiProbe,
нужно прокрутить список и изменить настройку «wiProbe destination». В ней задаётся
адрес, который будет использоваться зондом для отправки данных в систему wiSLA, в
форме URL (рисунок 19). Остальные параметры менять без необходимости не
рекомендуется.
Рис. 19 Интерфейс программы установки: настройки модуля сбора данных
14. Настройки интеграции LDAP (в том числе, Active Directory), рисунок 20. Если LDAP не
планируется использовать, рекомендуется оставить значения по умолчанию.

Рис. 20 Интерфейс программы установки: настройки интеграции LDAP
15. Настройки дополнительных ресурсов wiSLA. Рекомендуется оставить значения по

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

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

Notification enabled Включает email- true
рассылку
Mail host IP или DNS-адрес smtp.gmail.com
почтового сервера
Mail port Порт, 587
прослушиваемый
почтовым сервером
Mail protocol Протокол, smtps
используемый
почтовым сервером
Mail SMTP auth Включается, если true
почтовый сервер
поддерживает smtp-
авторизацию
Mail SMTP Включается, если true
STARTTLS почтовый сервер
поддерживает SMTP
STARTTLS
Mail user Имя пользователя, wisla.vm1
от имени которого
выполняется
рассылка
Mail password Пароль пароль
пользователя, от
имени которого
выполняется
рассылка
Tickets per Используется для 1
notification группировки писем
по инцидентам в
блоки по N штук.
Если установлена
единица, на каждый
инцидент
отправляется по
одному письму

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

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

Рис. 24 Интерфейс программы установки: просмотр топологии и подтверждение настроек
19. Если установка прошла удачно, программа выведет запрос на добавление сервиса
wisla в автозагрузку. Данное действие возможно только в том случае, если
пользователь wisla был добавлен в sudoers. В противном случае требуется отказаться
от действия.
20. После установки система автоматически запускается. Ход запуска можно отслеживать
в журналах работы (Logs viewer – wiSLA logs) и статусах (Statuses). Маркером запуска
является сообщение в журнале communicator.log, выделенное на рисунке 25.
Рис. 25 Сообщение об успешном запуске системы wiSLA в communicator.log

21. После успешного запуска требуется выполнить реиндексацию. Для этого нужно войти в
пункт меню «Maintenance» программы установки и выбрать «wiSLA Reindex».
22. После реиндексации можно начинать работу с порталом. По умолчанию в системе
будет пользователь root с паролем root. Зайдя с этими учётными данными, можно
создать пользователя с ролью «Системный администратор», который сможет далее
создавать инфраструктуру. Необходимо сменить пароль root при первом входе в целях
безопасности.
23. Если система в ходе установки добавлялась в список автозагрузки, рекомендуется
выполнить пробный перезапуск сервера с целью проверки механизма автоматического
запуска wiSLA.
Действия при неудачной попытке установки wiSLA
В случае если установка wiSLA завершилась c ошибкой, требуется:
1. Проанализировать причину сбоя установки. Для этого можно использовать log-файлы

программы установки в текущем каталоге, а также прокрутку в окне для просмотра хода
установки.
2. Завершить все процессы, связанные с java.
3. Выйти из программы установки и удалить новые каталоги в /home/wisla.
4. Повторить попытку установки с исправленными настройками.
Изменение одного или нескольких параметров wiSLA
Если требуется внести изменения в настройки уже установленной системы wiSLA, требуется:
1. Запустить программу установки. Перейти в основное меню. Внешний вид основного меню
показан на рисунке 26.
Рис. 26 Главное меню программы установки в случае обнаружения установленной wiSLA

2. Выбрать пункт меню «Config update». Если этого пункта меню нет в списке, установка была
выполнена некорректно или на первом экране при запуске программы установки были
указаны ошибочные данные.
3. Найти, изменить требуемый параметр.
4. Выполнить перезапуск wiSLA.
Действия по обслуживанию wiSLA
Основные действия по обслуживанию wiSLA перечислены в таблице 4.
Таблица 4 – Действия по обслуживанию системы wiSLA.
Что требуется сделать? Последовательность действий

1. Запустить программу установки wiSLA.
2. Выбрать и открыть "Statuses".

1. Просмотреть
информацию по статусам
3. Выбрать "All Statuses".
всех компонентов wiSLA
Незапущенные компоненты можно определить по наличию "[FAIL]"

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

2. Остановить все
All".
компоненты wiSLA
3. Проверить результат. Посмотреть информацию по статусам

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

дождаться завершения выполнения команды.
3. Перезапустить все
компоненты wiSLA 3. Выбрать в меню "Start All".
4. Дождаться полного запуска системы.
5. Проверить статусы компонентов.

1. Запустить программу установки.
2. Выбрать в меню программы установки раздел "Logs Viewer" -

"wiSLA Logs - Communicator log on..."
4. Узнать, что система

3. Нажать SHIFT+F для автоматического обновления файла.
полностью запущена
Запись об удачном запуске выглядит как:
wiSLA COMPONENTS ARE FULLY DEPLOYED,

INTERCONNECTED AND READY TO WORK.

Что требуется сделать? Последовательность действий
4. Завершить просмотр файла: CTRL+C, затем q.
5. Проверить статусы всех компонентов.

В ssh-сессии выполнить команду:
5. Получить информацию о
свободном месте на диске
df -h
6. Получить информацию о В ssh-сессии выполнить команду:
времени непрерывной
работы сервера uptime
7. Просмотреть журналы В ssh-сессии выполнить команду:
работы операционной
системы less /var/log/messages
2. Открыть "Logs viewer".

8. Просмотреть журналы
работы системы wiSLA
3. Выбрать компонент системы.
4. Выбрать журнал для просмотра.

9. Проверить время и дату date

в операционной системе
Обратить внимание не только на год, месяц, день, часы, минуты и
секунды, но и на часовой пояс
/etc/init.d/ntpd status
10. Проверить работу
службы NTP Если служба запущена, проверить доступность NTP-серверов для
синхронизации и статус синхронизации:
ntpq –np
Для добавления нового плагина требуется:
Скопировать файл плагина в каталог

/opt/wisla3/jboss/current/wisla_plugins/.
Выдать пользователю wisla права на файл:

11. Добавить новый плагин
chown wisla.wisla *.jar
Запустить программу установки wiSLA.
Перейти в меню «Maintenance» - «wiSLA management» и

выполнить «Reload_plugins».

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

ошибочные даты на календарях;
ошибочные дата и время в событиях;
недоступный портал.
При возникновении одного или нескольких проявлений требуется провести первичную диагностику
для установления причины сбоя (таблица 5).
Таблица 5 – Первичная диагностика и устранение проблемы.
Возможная причина Действия по выявлению Устранение проблемы

сбоя
1. Отказ одного из Просмотр статусов компонентов Поиск основной причины сбоя,
компонентов wiSLA (не wiSLA в программе установки перезапуск всех компонентов wiSLA
является
самостоятельной
причиной, требует
продолжения
диагностики)
2. Резкий скачок Проверка времени на каждом из Установка корректных даты и
времени на сервере узлов, где установлена wiSLA. времени, запуск NTP, перезапуск
всех компонентов wiSLA. Если база
Проверка работоспособности данных испорчена некорректными
службы NTP данными, потребуется выполнить
восстановление из резервной копии
(обратитесь в службу технической
поддержки НТЦ «Веллинк»)
3. Продолжительный Определение доступности Перезапуск всех компонентов wiSLA
разрыв связи между серверов, изучение журналов
узлами wiSLA работы системы, опрос
системных администраторов
4. Аварийная Сравнение времени непрерывной Перезапуск всех компонентов wiSLA
перезагрузка одного или работы серверов wiSLA, изучение
нескольких узлов журналов работы операционной
системы сервера с наименьшим
временем непрерывной работы
5. Исчерпано свободное Получение информации об Очистка дисков, добавление дисков,
место на одном из использовании дискового перезапуск всех компонентов wiSLA.

Возможная причина Действия по выявлению Устранение проблемы
сбоя
дисков пространства на всех серверах Если перезапуск не решает
wiSLA проблему, возможно, повреждена
база данных или программные
файлы. В этом случае потребуется
восстановить систему из резервной
копии или выполнить полную
переустановку системы (обратитесь
в службу технической поддержки
НТЦ «Веллинк»)
6. Вмешательство в Опрос системных Перезапуск всех компонентов wiSLA
работу сервера администраторов
(изменение настроек
сети, файловой системы
и т.п. при работающей
wiSLA)
7. Неудачное Чтение журнальных файлов Обратитесь в службу технической
обновление wiSLA после обновления поддержки НТЦ «Веллинк»
8. Аппаратные Определение проблемного Действия зависят от характера
проблемы на сервере сервера, перезагрузка, просмотр сбоя. Если потери данных не было,
данных POST, изучение журналов будет достаточно перезапустить все
операционной системы, проверка компоненты wiSLA.
диска, тестирование ОЗУ, замена
компонентов на заведомо Если в ходе перезапуска возникли
исправные и т.д. Выходит за проблемы или требуется
рамки настоящего Руководства восстановить программные файлы,
обратитесь в службу технической
поддержки НТЦ «Веллинк»

НАЧАЛО РАБОТЫ С ПОРТАЛОМ
Этот раздел описывает порядок действий для доступа к порталу оператора wiSLA, основные
элементы системы и особенности работы с ними.
Получение доступа на портал

Для получения доступа к системе wiSLA необходимо запросить у другого системного
администратора учетную запись для портала. После создания администратором учетной записи
на указанный адрес электронной почты придет письмо со ссылкой на портал wiSLA и реквизитами
доступа к нему (рисунок 27).
Рис. 27 Письмо с реквизитами доступа к порталу оператора wiSLA
Портал wiSLA совместим со следующими браузерами:
Mozilla Firefox (последняя актуальная на момент выхода wiSLA версия);

Google Chrome (последняя актуальная на момент выхода wiSLA версия).
При переходе по ссылке из письма (или при первой авторизации) пользователю будет предложено
сменить пароль, дважды указав новый пароль в полях ввода в появившемся всплывающем окне
(рисунок 28).
Рис. 28 Интерфейс задания нового пароля

Сразу после смены пароля (а также при последующих авторизациях) происходит переход на карту
сервисов.
Для удобства пользования системой wiSLA рекомендуется добавить адрес портала в закладки
браузера.
Получение доступа на облачную версию портала

Начиная с версии 4.1.1, ПАК wiSLA может работать как облачная платформа, предоставляющая
услуги мониторинга малому и среднему бизнесу (SME).
Если портал развёрнут в режиме wiSLA.Cloud, то у новых пользователей есть возможность пройти
регистрацию самостоятельно. Для прохождения регистрации новому пользователю следует:
нажать кнопку "Регистрация" на странице авторизации (рисунок 29);
Рис. 29 Кнопка и форма регистрации пользователя
ввести полное имя, адрес электронной почты (существующий в действительности) и

название компании;
нажать кнопку «Зарегистрировать». Система произведёт проверку введенных данных.
Далее возможны 3 варианта:
• если данные введены корректно, и введенное название компании не встречается

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

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

Пользователь может повторить попытку ввода данных;

для завершения регистрации пользователь должен перейти по ссылке в письме для
подтверждения регистрации и выполнить смену пароля для работы с порталом (рисунок
30).
Рис. 30 Пример письма о создании учётной записи в результате самостоятельной регистрации
Восстановление пароля
В случае потери логина и/или пароля есть возможность восстановить доступ к системе. При
создании нового пользователя портала, указывается адрес электронной почты, который
привязывается к логину и паролю пользователя.
Для восстановления пароля следует:
1. Открыть страницу авторизации портала оператора.

2. Перейти по ссылке «Забыли пароль» (рисунок 31).
Рис. 31 Восстановление пароля
3. Ввести адрес электронной почты, который указывался при создании учётной записи
пользователя портала оператора, и нажать «ОК». По электронной почте будет отправлено
письмо со ссылкой на страницу задания нового пароля.
4. Принять электронное письмо.
5. При переходе по ссылке из письма пользователю будет предложено дважды ввести новый
пароль. В случае успеха сразу после изменения пароля будет осуществлен переход на
информационную панель оператора портала.

Описание элементов портала
Портал wiSLA представляет собой мощный инструмент для анализа и контроля качественных
характеристик каналов связи, который позволяет осуществлять постоянный (круглосуточный) и
регламентированный по времени мониторинг трафика связи, фиксировать сбои и неисправности
оборудования и программных средств связи.
Меню
Через меню осуществляется переход к основным функциональным блокам портала:
«Мониторинг»:
• «Аналитика» – детальный анализ статистики и количественных показателей

состояния сервисов;
• «Карта сервисов» – визуализация состояния отслеживаемых сервисов в

разрезе географических местоположений;
• «События» – создание, просмотр и редактирование паспортов неисправности,

исключений и профилактических работ;
«Отчеты»:
• «Отчеты SLA» – просмотр отчетов SLA;

«Инфраструктура»:
• «Сервисы» – просмотр, добавление и удаление сервисов;
• «Контракты» – просмотр, добавление и удаление контрактов;
• «Зонды» – просмотр, добавление и удаление зондов;

«Администрирование» – раздел доступен только пользователям с ролью «Системный
администратор». Включает:
• «Контрагенты» – просмотр, добавление и удаление контрагентов, см. раздел

«Контрагенты»;
• «SLA» – просмотр, добавление и удаление SLA, см. раздел «SLA»;
• «Точки доступа» – просмотр, добавление и удаление точек доступа, см. раздел

«Точки доступа»;
«Тесты» – просмотр, добавление и удаление тестов, см. раздел «
• Тесты»;
«Учетныезаписи»–управлениеучетнымизаписямипользователейпортала,
см. раздел «Импорт и экспорт списков объектов
Начиная с версии wiSLA 4.2, пользователю доступен импорт и экспорт списков объектов. Эта
возможность позволяет сократить время на массовое добавление простых объектов,
обеспечивает обмен данными с внешними системами.
Возможность импорта/экспорта для определённых объектов представлена в таблице 6:

Таблица 6 – Импорт/экспорт объектов инфраструктуры.
Объект Импорт Экспорт

События Нет Да
Отчёты SLA Нет Да
Сервисы Нет Да
Контракты Да Да
Зонды Да Да
Контрагенты Да Да
SLA Нет Да
Точки доступа Да Да
Тесты Нет Да
Импорт
Функция импорта позволяет загрузить данные из внешнего файла в систему wiSLA.

Поддерживаются следующие форматы файлов: .xls, .xlsx, .csv. Структура импортируемого файла
должна строго соответствовать структуре (набору и названию полей) соответствующего списка.
Для облегчения этой процедуры в системе предусмотрена загрузка файла-шаблона для
последующего заполнения, с примером во второй строке. В случае импорта из csv (RFC 4180)
кириллица должна передаваться в кодировке Windows-1251, разделителем полей служит точка с
запятой, значения заключаются в кавычки.
В первой строке файла импорта не должно быть лишних (не перечисленных в файле-шаблоне)
полей.
Обязательные поля должны быть заполнены. Информация в пределах одной записи не должна
быть противоречивой. Необязательные поля можно оставлять пустыми. К пустым необязательным
полям будут применены значения по умолчанию (если они предусмотрены, в противном случае
будет импортировано пустое значение). Обязательность заполнения поля можно посмотреть в
интерфейсе создания новой сущности выбранного типа (отметка звёздочкой).
Первым полем в шаблоне импорта является идентификатор записи в базе данных системы (ID).
Если оно заполнено в файле импорта, система попытается обновить записи с указанными ID, если
не заполнено – запись будет добавлена как новая. Получить ID можно в файле экспорта. В рамках
одного файла импорта можно использовать как записи с ID, так и без.
Для выполнения импорта следует:

нажать «Ещё» – «Импорт» (рисунок 61). Откроется модальное окно, показанное на рисунке
62;
Рис. 61 Кнопка «Импорт»

Рис. 62 Импорт списка контрактов
нажать «Скачать пример XLSX» или «Скачать пример CSV» для загрузки шаблонного
файла;
сохранить файл в рабочий каталог для его редактирования;

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

записей. Записи, которые не прошли проверку, автоматически отбраковываются, при этом импорт
продолжается. Система сообщает номера строк, которые не прошли проверку. Пример показан на
рисунке 63.

Рис. 63 Пример импорта с ошибками
Экспорт
Функция экспорта позволяет выгрузить записи из системы wiSLA во внешний файл.

Поддерживаются форматы: .xlsx и .csv. Кнопка запуска экспорта показана на рисунке 64,
модальное окно выбора формата – на рисунке 65.
Рис. 64 Кнопка «Экспорт»
Рис. 65 Экспорт списка отчетов
Особенности экспорта:
экспорт выполняется в пределах доступных пользователю сущностей;

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

«Сессии»;
• «Журнал событий» – просмотр журнала событий, вызванных действиями

пользователей портала оператора wiSLA, см. раздел «Журнал событий».
Рабочая область
На рабочей области справа от меню доступны информационные панели и элементы управления

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

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

для создания системного тега следует первым символом набрать «#»;
создание и удаление новых системных тегов доступно только пользователям с ролью
системного администратора;
если системный тег создан, его могут использовать для фильтрации сущностей все
пользователи системы, независимо от роли;
отмечать другие записи в списке существующим тегом могут пользователи с ролью
«Оператор SLA». Для этого следует при нажатии тега раскрыть список (кнопка «вниз» на
клавиатуре) или ввести # и первые буквы тега. Должен появиться список доступных тегов;
при попытке создания системного тега пользователем без прав системного
администратора система преобразует ввод в пользовательский тег.
На рисунке 32 показаны примеры работы с тегами. Теги могут быть добавлены двумя способами:
в общем списке записей (п. 1 на рисунке 32 – выделена кнопка добавления тега). Следует
нажать кнопку добавления тега «+», ввести текст, нажать Enter. Появится поле ввода для
второго тега. Если ввод завершён, следует щёлкнуть мышью в свободное от тегов
пространство или нажать Esc;

на странице редактирования записи (пп. 2, 3, 4 на рисунке 32). Следует навести курсор на
пиктограмму тега (п.2 на рисунке 32) – отобразится ссылка «добавить теги» (п.3 на рисунке
32), при нажатии появится поле ввода. Далее ввод производится так же, как в списке
записей (п. 4 на рисунке 32).
Для удаления тега нужно нажать на пиктограмму удаления в правом верхнем углу тега.
Редактирование тега не предусмотрено. Операция редактирования может быть выполнена как

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

инфраструктуры (контрактов, сервисов, зондов и т.д.). wiSLA предоставляет инструмент поиска и
фильтрации элементов этих списков (рисунок 33).

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

по параметрам из выпадающего списка (например, по значениям параметров «Статус
сервиса», «Состояние сервиса» в компоненте «Сервисы» (см. рисунок 34);

Рис. 34 – Фильтрация списков объектов инфраструктуры по параметрам из выпадающего списка.
выбор с поиском по пользовательским и системным тегам и контрактам – пользователь

выбирает теги, заданные на искомом объекте инфраструктуры и контракт/контракты, с
которыми он связан (рисунок 35). Фильтрация по тегам также может быть включена
щелчком по тегу в общем списке объектов (даже с выключенной панелью фильтрации).
Рис. 35 Фильтрация сервисов по тегам и контрактам
После включения фильтрации кнопка включения фильтрации меняет внешний вид – над ней
появляется число, означающее количество применённых условий. Например, означает, что

применено 4 условия фильтрации.

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

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

возможность выполнять в списке поиск элементов:
1. «По странице» означает поиск по отображаемой в текущем списке информации.

2. По наименованию элементов, связанных с элементами текущего списка (контрактов,
зондов, сервисов и т.д.) – для этого необходимо выбрать тип соответствующего связанного
элемента в выпадающем меню панели поиска (рисунок Error! Reference source not
found.).
Рис. 36 Работа с панелью поиска
Поиск осуществляется по вхождению введенной пользователем строки в любое слово,

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

поискового запроса:
двойные кавычки – поиск по фразе целиком, в строгом соответствии с запросом.
Например, для поиска сервиса «Доступность slamon.net» потребуется ввести в строке
поиска на странице сервисов:
«Доступность slamon.net»

плюс – условие «И», выводятся записи, включающие все перечисленные критерии. Знак
«+» указывается перед каждым словом, включая первое. Например, для поиска сервиса
«Доступность slamon.net» потребуется ввести в строке поиска на странице сервисов:
+Доступность+slamon.net
пробел – условие «ИЛИ», сначала выводятся записи, полностью удовлетворяющие

поисковому запросу, затем записи, удовлетворяющие запросу частично, в порядке
полноты. Например, если в системе есть 3 сервиса: «Доступность slamon.net»,
«Доступность для TheCompany», «ping wellink.ru» (с типом сервиса «Доступность услуги)
поиск по строке:
Доступность slamon.net
выдаст результаты в следующем порядке:
• «Доступность slamon.net» – как наиболее полно соответствующий запросу.
• «Доступность для TheCompany» – в названии сервиса встречается одно из

ключевых слов.
• ping wellink.ru – в поле «тип сервиса» встречается одно из ключевых слов.
Настройка списка
Пользователь может настраивать внешний вид списка объектов: редактировать ширину столбцов
(полей), менять их местами, добавлять и скрывать столбцы. Страница настройки отображения
списка объектов открывается путем нажатия кнопки «Настройка списка» выпадающего списка
«Ещё».
Рис. 37 Кнопка «Настройка списка»
Общий вид страницы настроек списка представлен на Error! Reference source not found..

Рис. 38 Общий вид страницы настройки списка объектов
Страница настроек списка содержит несколько элементов.
Раздел «Поля списка» – набор доступных к добавлению полей, показанных в виде плиток. Если он
пуст, все поля уже включены и отображаются, скрытых полей нет.
Компонент управления столбцами – схематическое отображение «шапки» будущей таблицы с

возможностью настройки: добавления, скрытия поля и выбора его позиции (путем перемещения
соответствующей плитки в нужное место), изменения ширины столбца. Перемещение плитки
осуществляется с нажатой левой кнопкой мыши. Изменение ширины столбца – путем наведения
указателя мыши на границу плитки и изменения её ширины в нужную сторону. Скрытие столбца –
путем нажатия на крестик в правой части плитки или перетаскиванием плитки в раздел «Поля
списка». В случае если на странице настройки списка ширина компонента управления больше, чем
доступная ширина экрана, включается горизонтальная прокрутка.
Настройка «Отображать колонку действий над объектами» отвечает за появление в первом

столбце элемента для возможности отметки нескольких записей (см. подраздел «Error! Reference
source not found.»).
Настройка «Использовать адаптивную ширину таблицы» переключает механизм выбора ширины

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

исходному виду, заданному разработчиками системы.
Действия над объектами списков
Начиная с версии wiSLA 4.2, пользователю доступны действия над объектами списков –
возможность применения операции к нескольким записям. На рисунке 39 показана панель

действий, для её появления нужно отметить в первом столбце хотя бы один элемент. Если
столбец для отметки записей, показанный на рисунке, отсутствует, нужно включить его
отображение в настройках списка (см. подраздел «Error! Reference source not found.»).
Рис. 39 Панель действий над объектами списка
После выбора одного объекта перечень доступных действий отображается на его записи.
После выбора нескольких объектов перечень доступных действий отображается в заголовке

таблицы.
Если действие требует выбора связи с другими объектами системы, например, прикрепления
сервиса к контракту, то перед выполнением действия в модальном окне потребуется выполнить
дополнительные настройки.
Настройка учётной записи оператора портала
Для перехода на страницу настройки учетной записи оператора портала необходимо щелкнуть на
адрес электронной почты в левом верхнем углу (рисунок 40).
Рис. 40 Страница настройки учетной записи оператора портала

На этой странице пользователю доступны следующие действия:
смена пароля;
смена полного имени пользователя;
настройка дополнительных адресов электронной почты (для рассылки уведомлений);
настройка всплывающих уведомлений на портале и уведомлений, рассылаемых по

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

АДМИНИСТРИРОВАНИЕ
Раздел «Администрирование» включает следующие компоненты:
«Контрагенты»;
«SLA»;
«Точки доступа»;
Тесты»;
«Импорт и экспорт списков объектов


SLA Нет Да
Импорт

полей.


62;
файла;



рисунке 63.
Экспорт


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

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

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

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

нажать кнопку «+ Контрагент». Откроется форма создания нового контрагента (рисунок 43);

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

следует выбрать опцию «Создать пользователя»;
• если пользователь, создающий контрагента, не был ранее закреплен ни за одним

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

• пользователь портала с ролью «Оператор SLA» может быть связан только с
одним контрагентом, при попытке нарушения данного правила будет появляться
предупреждение с возможностью разрушения предыдущих связей;
• пользователи портала без роли «Оператор SLA» могут быть связаны с

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

пользователей портала;
нажать кнопку «+ Сохранить». Произойдет проверка введенных данных. Если проверка
пройдёт успешно, форма закроется, и новая запись появится в общем списке контрагентов;
при сохранении данные проходят проверку. Если будут выявлены ошибки, форма
останется открытой. Требуется исправить ошибки и повторить сохранение.
Редактирование контрагента
Для изменения атрибутов контрагента нужно:

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

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

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

Рис. 44 Фрагмент формы редактирования контрагента с кнопкой «Из архива»
нажать кнопку «Из архива». Статус записи изменится на «Активный». После этого можно
воспользоваться меню для ухода с формы или выполнить другие действия с выбранной
записью. Если требуется поправить один или несколько атрибутов, можно выполнить
редактирование в этой же форме и нажать кнопку «+ Сохранить».
Удаление контрагента
Удаление контрагента – это необратимая операция, в результате которой запись удаляется из

архива без возможности восстановления. Удаление можно выполнить только после отправки
контрагента в архив. Удаление может быть полезно для записей, которые были добавлены в
систему по ошибке. Для удаления контрагента следует:
открыть архивную запись на редактирование (путём фильтрации списка по статусу
«Архивный» или оставшись на форме редактирования после архивации контрагента,
рисунок 45);
Рис. 45 Кнопка удаления контрагента в списке дополнительных действий
нажать кнопку «Еще», в появившемся списке действий – «Удалить». Появится запрос на

подтверждение удаления;
после подтверждения выполнится удаление записи и переход на список контрагентов.
SLA
Список SLA
Для просмотра списка SLA следует выбрать раздел «SLA» в главном меню (рисунок 46).

Рис. 46 Список SLA
Для каждой записи в списке SLA отображается следующая информация:

название SLA, которое задаётся при его создании;
автор – имя создавшего SLA пользователя;
владелец;
статус SLA: активный, архивный.
На странице списка SLA работает поиск, фильтрация (подробности – в разделах «Панель

фильтрации», «Панель поиска» соответственно) и сортировка. Отличительных особенностей от
аналогичных элементов на других страницах они не имеют. По умолчанию SLA в статусе
«Архивный» скрыты.
Создание SLA
В настройках SLA задаются правила, на основании которых система будет принимать решение о:
пороговых значениях показателей качества;
статусе сервисов;
готовности;
открытии, закрытии, изменении статуса паспорта неисправности;
наборе доступных профилей при создании сервиса;
наборе метрик на графиках и диаграммах;

расчёте компенсации (скидки);
создании автоматических исключений.
Перед созданием SLA следует определиться:

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

то какой тип скидки будет применён (система позволяет настроить линейную и
прогрессирующую скидку);
будет ли использоваться механизм автоматических исключений при превышении загрузки
канала;
какой период мониторинга нужен потребителю сервиса (24х7 или настраиваемый). Если
период настраиваемый, в какие дни и в какое время должен обслуживаться сервис.
SLA доступен к редактированию, поэтому не обязательно задавать все параметры сразу, это
можно сделать поэтапно. Минимальный набор, необходимый для сохранения SLA:
название SLA;
название профиля;
показатель качества и его целевые значения.
Весь минимальный набор параметров находится на вкладке «Мониторинг», при попытке
сохранения такой SLA система примет остальные параметры со значениями по умолчанию. Эти
значения можно просмотреть (и отредактировать) на вкладках «Неисправности», «Скидки»,
«Исключения».
Для создания SLA требуется:

открыть раздел «SLA» в главном меню;
нажать кнопку «+ Добавить»;
ввести название SLA;
на вкладке «Мониторинг» добавить профиль, нажав кнопку (рисунок 47);
Рис. 47 Заполнение названия SLA, кнопка добавления профиля

назвать профиль. Для этого щёлкнуть по надписи «Добавить профиль» и ввести в
появившееся поле название профиля, завершить ввод нажатием Enter. При
необходимости профиль можно удалить кнопкой , которая появляется при наведении
курсора на название профиля;
задать параметры QoS. Для этого нажать «+ Добавить показатель», последовательно

выбрать в выпадающем списке нужные показатели качества (рисунок 48). При этом снизу,
в строке «Доступные типы тестов, можно контролировать совместимость набора
показателей с типами тестов, для которых они предназначены. При необходимости
показатель можно удалить, нажав кнопку , которая появляется при наведении курсора
на название показателя. После добавления одного или нескольких показателей можно
задать условия и числовые значения для «Деградации» и «Отказа» нажатием на . Если
знак неравенства, предложенный системой по умолчанию, не подходит для решения
бизнес-сценария, следует удалить его, ввести новый и добавить числовое значение.
Интервал оценки не изменяется и составляет 15 минут;
Рис. 48 Добавление показателя на странице создания SLA
изменить значение готовности, если требуется. Для изменения нужно щёлкнуть по числу,
ввести новое значение, нажать Enter;
минимальный набор параметров задан, с этого момента система разрешает сохранение
SLA (для сохранения предназначена кнопка «+ Сохранить») и навигацию по другим
вкладкам. В случае принятия пользователем решения сохранить такой SLA рекомендуется
ознакомиться со значениями остальных настроек, предложенными системой. В противном
случае можно продолжить добавление профилей, ввод целевых значений параметров и
т.д. (пример заполнения показан на рисунке 49). Далее будут рассмотрены отдельные
настройки SLA.

Рис. 49 Пример заполнения параметров мониторинга SLA
Вкладка «Неисправности» (рисунок 50) позволяет просмотреть и настроить задержки на

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

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

Без задержки – минимальная задержка на открытие или закрытие паспорта неисправности.
Следует учесть, что в действительности работа внутренних механизмов системы не
позволит выполнить открытие паспорта неисправности в режиме реального времени,
однако, дополнительной задержки в этом случае не будет. На рисунке 51 показано 2
примера работы системных механизмов и отображения времени неисправности в
зависимости от этой настройки;
5 минут;
10 минут;
15 минут;
20 минут;
30 минут;
45 минут;
1 час.
Рис. 51 Пример реакции системы на «Отказ» в случае 10-минутной задержки и при ее отсутствии в
настройках SLA
Вкладка «Скидки» позволяет включить и настроить расчет компенсации потребителю сервиса за

нарушения. Размер компенсации не может превышать 100%. По умолчанию скидки не
рассчитываются. Для включения требуется:
нажать «Укажите тип скидки» и выбрать из выпадающего списка тип скидки:
• «Линейная скидка» (рисунок 52) – для указания правила для расчета скидки для
отказа и деградации за каждый полный период, продолжительность которого
можно выбрать;

Рис. 52 Пример настройки линейной скидки
• «Прогрессирующая скидка» (рисунок 53) – позволяет задать несколько правил

как для деградации, так и для отказа, варьируя размер скидки в зависимости от
продолжительности неисправности;
Рис. 53 Пример настройки прогрессирующей скидки
заполнить правила, щёлкая по ссылкам (текст, выделенный синим цветом).
Вкладка «Исключения» содержит правило, при выполнении которого система будет игнорировать
все аварийные состояния контролируемых сервисов. В таком состоянии не будут открываться
паспорта неисправности, и они будут исключаться из периодов отчетов SLA (см. рисунок 54). Для
корректной работы сервиса с такой настройкой требуется убедиться, что измерительные
устройства собирают данные о загрузке канала, wiSLA может их обработать, и параметр «Процент
загрузки» выбран на вкладке «Мониторинг» для профилей. Настройка правила для исключения
выполняется по аналогии с настройкой целевых значений параметров качества на вкладке
«Мониторинг».

Рис. 54 Настройка исключения в SLA
На этой же вкладке можно настроить расписание мониторинга (рисунок 55). При задании
расписания есть следующие особенности:
следует перевести переключатель в положение «Произвольно». Появятся полосы,
соответствующие дням недели с редактируемым отрезком мониторинга;
дополнительный отрезок «Интервал контроля» позволяет выполнить настройку для всех
перечисленных дней недели одновременно;
кнопка позволяет исключить день недели из расписания;

регулируется как положение отрезка на оси времени, так и его длина. Для изменения
положения отрезка следует захватить отрезок (но не его границу) мышью, потянуть,
отпустить кнопку мыши. Для изменения длины нужно подвести курсор к границе отрезка,
захватить границу мышью, потянуть, затем отпустить кнопку мыши.
Рис. 55 Настройка периода мониторинга в SLA
Блок «Дополнительные параметры» позволяет сменить владельца SLA.
Просмотр настроек SLA
Для просмотра данных SLA следует:

открыть раздел «SLA» в главном меню;
найти требуемый SLA в списке. Доступен поиск и сортировка;
нажать на название SLA – откроются настройки.

Создание SLA на основе
Система предоставляет возможность создания SLA на основе уже сохраненного в системе.

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

нажать «Создать на основе» или «Еще» – «Создать на основе»;
назвать SLA, внести правки;
сохранить.
Отправка SLA в архив
Архивация SLA позволяет скрыть неиспользуемый SLA из общего списка SLA. Добавить в архив
можно SLA, который не связан с активными сущностями.
Для архивации SLA следует:

открыть настройки SLA, который необходимо отправить в архив;

нажать кнопку «Еще» – «В архив».
Извлечение SLA из архива
Для извлечения SLA из архива следует:

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

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

архива, удаление точки доступа, просмотр изменений настроек точки доступа.
Редактирование точки доступа, добавление в архив, восстановление из архива и удаление

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

использования дополнительных свойств (полей), расширяющих возможности системы. Системный
администратор может добавлять такие поля на форме редактирования точки доступа, выбирая их
название и тип (текст или дата).
Для возможности определения координат точки доступа система должна быть корректно
настроена в части подключения к серверу-геокодеру для получения координат и иметь доступ к
нему в момент создания точки доступа.
Создание точки доступа
В зависимости от варианта развёртывания wiSLA по отношению к сети Интернет (открытый контур,

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

автоматически. В случае отсутствия интернет-соединения у пользователей системы
создать точку доступа не удастся;

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

нажать кнопку «+ Точка доступа». Откроется форма добавления точки доступа (рисунок
57);
Рис. 57 Форма добавления точки доступа
ввести название точки доступа в поле с текстом «Новая точка доступа»;

если контур открытый – ввести текст в поле «Адрес» в произвольном виде, например:
«Москва Большая Почтовая 5». Откроется список из одного или нескольких объектов,
соответствующих введённому тексту. Из этого списка нужно выбрать объект со строгим
соответствием адреса. При необходимости запрос следует уточнить. После выбора строки
с адресом нужно проследить за заполнением полей «Область», «Город», «Улица», «Дом»,
«Широта», «Долгота» и индикатором нахождения координат (при наведении на «мишень»
должна быть подсказка «координаты найдены»). Рекомендуется также перепроверить
координаты объекта вручную. Далее они будут использованы для построения точки на
карте сервисов;
если контур изолированный – выбрать из списка область, ввести город, улицу, дом. Если
географические координаты не определены или определены неверно – ввести или
исправить широту и долготу (в градусах в виде десятичной дроби). При работе wiSLA в
режиме изолированного контура ввод координат не является обязательным, но в случае их
отсутствия точка доступа не появится на карте сервисов;
заполнить поле «Пропускная способность, кбит/с» (не является обязательным). В случае

заполнения данное значение будет использоваться для всех SNMP Utilization Test,
связанных с этой точкой доступа;

заполнить поле «IP-адрес оборудования CE» (не является обязательным). Данный IP-
адрес будет использован для проверки доступности зонда «справа» в случае получения
потерь пакетов 100% от «левого» зонда. Если зонд «справа» доступен, то отказ сервиса не
будет зафиксирован. Вместо этого сервис перейдет в статус «Не определено». Данная
особенность работает с зондами типов Cisco (только если корректно заданы настройки
подключения по Telnet) и wiProbe;
заполнить дополнительные поля, если требуется;
под ссылкой «Подробнее» скрыты поля «Владелец», «Этаж», «Квартира», «Почтовый
индекс», «Описание». Поле «Владелец» заполняется автоматически и может быть
изменено. Остальные поля могут быть заполнены, но технически не являются
обязательными;
выбрать или создать зонд (этот шаг может быть пропущен);
добавить теги для расширения возможностей фильтрации точки доступа (этот шаг не
является обязательным). Кнопка добавления тегов находится над ссылкой

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

Рис. 58 Страница «Тесты» с включенной панелью фильтрации
Для теста предусмотрено 3 статуса:
«Активный» – тест участвует в измерениях;
«Неактивный» – тест не участвует в измерениях;

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

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

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

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

Типы тестов:
Cisco IP SLA – измерение качественных показателей сети, проводится с использованием
двух зондов. Возможные комбинации: Cisco – Cisco, Cisco – wiProbe;
SNMP Utilization test – не использует созданные зонды, настройки подключения к
оборудованию задаются прямо в тесте. Позволяет получить данные по загрузке канала
(текущая загрузка канала за 5 минут, коэффициент загрузки канала);
TWAMP – измерение качественных показателей сети устройствами wiProbe в соответствии
с RFC 5357 (по TWAMP-протоколу). Выполняется путём посылки последовательности
тестовых UDP-пакетов. Позволяет выполнять измерение потерь, задержки (времени
односторонней задержки пакетов), круговой задержки (времени двусторонней задержки
пакетов), джиттера (времени односторонней вариации задержки пакетов), кругового
джиттера (времени двусторонней вариации задержки пакетов), пакетов вне очереди и
повторов пакетов;
wiProbe Custom Scenario – группа тестов для зондов wiProbe, возвращающих результат
выполнения сценария и время выполнения, позволяющая выполнять широкий спектр
проверок: мониторинг баз данных, авторизацию на FTP, подключение и поиск в LDAP,
отправку писем по SMTP, подключение к почтовому и Samba-серверу, Health-мониторинг,
SOAP-мониторинг, проверку доступности WEB-страниц и другие проверки. Подключается к
сервисам типа «Сценарий пользователя». Не требует «зонда справа»;
wiProbe DNS – проверка доступности DNS-сервера зондами wiProbe (позволяет выполнять

измерение потерь, отклика и кругового джиттера), а также измерение времени разрешения
имени узла. Не требует «зонда справа»;
wiProbe L2-Test – выполняет тестирование качественных показателей передачи данных
на канальном уровне зондами wiProbe. Для тестирования требуются 2 зонда wiProbe.
Позволяет выполнять измерение потерь, задержки (времени односторонней задержки
пакетов), круговой задержки (времени двусторонней задержки пакетов), джиттера (времени
односторонней вариации задержки пакетов), кругового джиттера (времени двусторонней
вариации задержки пакетов);
wiProbe L7-HTTP-Test – проверяет доступность ресурса и измеряет время, необходимое
для прохождения запроса по протоколу HTTP. Не требует «зонда справа». Позволяет
выполнять измерение потерь, отклика и кругового джиттера;
wiProbe L7-TCP-Test – проверяет доступность портов приложения по протоколу TCP. Не
требует «зонда справа». Позволяет выполнять измерение потерь, отклика и кругового
джиттера;
wiProbe OnlineDPI – собирает статистику по пользовательскому трафику. Может быть
применен только с использованием wiProbe зонда;
wiProbe P-Test – выполняется путём посылки последовательности тестовых ICMP-
пакетов. Позволяет выполнять измерение потерь, отклика и кругового джиттера;
wiProbe U-Test – проводится с использованием двух зондов. Master-зондом всегда
выступает зонд wiProbe. Возможные комбинации зондов: wiProbe – wiProbe, wiProbe –
Cisco, wiProbe – Network Device. Выполняется путём посылки последовательности
тестовых UDP-пакетов. Позволяет выполнять измерение потерь, задержки (времени
односторонней задержки пакетов), круговой задержки (времени двусторонней задержки
пакетов), джиттера (времени односторонней вариации задержки пакетов), кругового
джиттера (времени двусторонней вариации задержки пакетов), пакетов вне очереди и
повторов пакетов;

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

на первом этапе (рисунок 59) указывается название теста (обязательное поле),
добавляются метки (если необходимо) и указывается тип теста (обязательное поле).
После выбора типа теста открывается набор других параметров, соответствующих
выбранному типу;
Рис. 59 Первый этап создания теста
на втором этапе (рисунок 60) заполняются все необходимые для выбранного типа теста
параметры;

Рис. 60 Второй этап создания теста
как правило, это выбор одного или двух зондов, участвующих в тесте (зонды фильтруются
согласно выбранному типу теста по критерию возможности использования), указание
пропускной способности и выбор интерфейса и идентификатора теста на зонде в том или
ином виде. Все доступные поля в настройках тестов являются обязательными для
заполнения;
для отдельных типов тестов доступны также дополнительные настройки в модальных
окнах (например, выбор шаблона и заполнение полей для теста Custom Scenario);
после заполнения полей требуется нажать кнопку «+ Сохранить»;
система предложит запуск теста. Во многих случаях он не нужен: тест будет создан и
запущен, в то время как не вся инфраструктура добавлена для полноценного мониторинга.
Однако для тестов с зондами wiProbe предварительный запуск теста даст возможность
ускорить процесс получения результатов мониторинга после активации связанного сервиса
или контракта.
При создании теста OnlineDPI настраиваются следующие параметры:

«Зонд», источник данных о статистике трафика;
«Параметры захвата трафика»:
• «Фильтр локальной сети» – IP-адрес или подсеть, определяющая, что пакеты с

IP источника из этой сети являются исходящими;
• «Набор критериев захвата» (IP-адреса источника/назначения, Протоколы,

порты). Количество критериев не ограничено. Их можно добавлять путем
нажатия на «+» в строке критерия. При нажатии на «+» появляется модальное
окно с выбором типа критерия: IP-адреса источника/назначения, протоколы,
порты. По умолчанию при создании теста вместо первой строки критерия должна
отображаться ссылка «Добавить критерий», при нажатии на которую должно
появляться модальное окно с выбором типа критерия.

Параметры захвата трафика можно получить из другого уже созданного теста Online DPI. Для
этого необходимо нажать кнопку «Получить из теста». Откроется модальное окно со стандартным
компонентом поиска и выбора тестов OnlineDPI. При выборе одного или нескольких тестов из них в
текущий создаваемый тест копируются настройки. Если тестов несколько, настройки агрегируют.
Импорт и экспорт списков объектов


SLA Нет Да
Импорт

полей.

62;
файла;

рисунке 63.

Экспорт


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

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

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

доступа на портал.

Рис. 66 Страница «Учетные записи» с включенной панелью фильтрации
Создание нового пользователя
Создание нового пользователя доступно пользователям с ролью «Системный администратор». До

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

нажать кнопку «+ Пользователь». Откроется форма добавления новой учетной записи
портала (рисунок 61);
ввести полное имя пользователя. Это обязательное поле;
ввести адрес электронной почты пользователя. Он будет использоваться и в качестве
логина. Это обязательное поле;
при необходимости добавить дополнительные адреса электронной почты. На них будет
дублироваться информация, отсылаемая на основной адрес. Перечисленные здесь адреса
не могут быть использованы для авторизации вместо основного. Настройка
дополнительных адресов электронной почты необязательна;
выбрать одну или несколько ролей пользователя:
• роль «Системный администратор» открывает доступ к разделу

«Администрирование» для полноценного управления контрагентами, SLA,
точками доступа, учетными записями и сессиями на портале. Позволяет
сбрасывать пароли, настраивать дополнительные поля, создавать системные
теги;
• роль «Оператор SLA» добавляет возможности по созданию и изменению

инфраструктуры, но не дает доступ в раздел «Администрирование» для
полноценного управления контрагентами, SLA, точками доступа, учетными
записями и сессиями на портале;

• по умолчанию все добавляемые учётные записи имеют роль «Пользователь»,
её снятие невозможно, она добавлена для наглядности.
настроить уведомления. Этот шаг является необязательным. Настройки уведомлений
состоят из двух подразделов:
• «Всплывающие уведомления на портале» – для включения всплывающих

сообщений на странице портала «События» при открытии, закрытии и изменении
уровня критичности паспортов неисправности;
• «Уведомления» (по электронной почте). При отметке флажком «Отказ»,

«Деградация», «Не определено» важно не забыть отметить и тип события, по
наступлению которого должно отправляться электронное письмо;
Рис. 67 Страница добавления учетной записи
раскрыть вкладку «Дополнительные настройки». Все поля здесь необязательные, но их

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

Регистрация пользователя wiSLA.Cloud по запросу
В режиме wiSLA.Cloud предусмотрена возможность автоматической регистрации пользователей. В

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

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

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

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

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

запись, открыть ей на редактирование и выбрать «Еще», «Разблокировать».
Изменение настроек рассылки уведомлений
Настройки рассылки в чужой учетной записи могут быть изменены системным администратором
независимо от роли редактируемой записи. На рисунке 68 показан пример настройки.
Рис. 68 Настройка рассылки уведомлений
В приведённом примере пользователь будет получать уведомления:

на странице «Аналитика» – о паспортах неисправности;

на адрес его электронной почты будут приходить письма об открытии, изменении,
закрытии и добавлении комментариев к паспортам неисправности уровней «Отказ»,
«Деградация», «Не определено». Также он будет получать уведомления о планово-
профилактических работах и публикации отчетов SLA.
Как было указано ранее, при отметке флажком «Отказ», «Деградация», «Не определено»
важно не забыть отметить и тип события, по наступлению которого должно отправляться
электронное письмо.
Сессии
Страница «Сессии» (рисунок 69) доступна системным администраторам. Она позволяет увидеть,
кто в данный момент находится в системе, с какого IP-адреса произведен вход, время последней
активности и ожидаемое время окончания сессии (время жизни сессии составляет по умолчанию
30 минут). Для нежелательных сессий предусмотрены завершение сессии и блокировка
пользователя.
Рис. 69 Страница управления сессиями
При завершении сессии происходит освобождение памяти, выделенной для данной сессии,
пользователь не получает никаких уведомлений. В случае если он продолжает работу с порталом,
происходит его автоматический вход, и он может ничего не заметить. Такой функционал может
быть полезен для аварийного завершения подвисших сессий, но не для блокировки нарушителя.
При выборе блокировки пользователя системному администратору предлагается выбрать, на

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

Журнал событий
Журнал событий (рисунок 70) предоставляет системному администратору доступ к записи
действий, связанных с редактированием или созданием новых элементов инфраструктуры, входа
на портал, публикации и перерасчета отчетов SLA. Функционал страницы по работе с журналом
событий позволяет:
осуществлять полнотекстовый поиск (подробнее поиск описан в разделе «Панель поиска»);
выполнять сортировку по дате, типу, длительности выполнения;
выполнять фильтрацию по источнику системных событий и по типу событий (подробнее
фильтрация описана в разделе «Панель фильтрации»);
подсвечивать изменённое поле (если это возможно);
Рис. 70 Страница журнала событий
при нажатии на интересующую запись в журнале получить окно с расширенной

информацией о действиях пользователя с объектами (рисунок 71).

Рис. 71 Просмотр детальной информации о событии
Помимо страницы «Журнал событий» для пользователей с ролью системного администратора

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

РАЗГРАНИЧЕНИЕ ПРАВ ДОСТУПА
Роли
Всем пользователям системы могут быть присвоены роли:
«Системный администратор»;
«Оператор SLA»;
«Пользователь» (роль по умолчанию, которую имеют все пользователи).
Один пользователь может иметь несколько ролей. Каждая роль содержит определенный набор
прав.
Права на действия с объектами

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

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

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

использовать их (редактировать пользователей, использовать видимые ему зонды, сервисы – при
создании новых контрактов).
При создании сервиса пользователь может запретить его дальнейшее редактирование

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

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

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

получение email-уведомлений и просмотр отчетов SLA по контракту;
просмотр связанной с контрактом инфраструктуры (сервисы и зонды).

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

контрагентов. Чтобы ограничить видимость таким пользователям, достаточно прикрепить их к
конкретным контрактам.
Пользователь с ролью «Системный администратор» имеет право:

работать с разделом «Администрирование» в главном меню;
создавать и редактировать всех пользователей (есть ограничение по изменению настроек
других системных администраторов);
создавать и редактировать всех контрагентов. Если системный администратор не

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

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

оператор SLA может быть прикреплён только к одному контрагенту;
создаваемые оператором SLA объекты инфраструктуры автоматически прикрепляются к

тому контрагенту, к которому прикреплен оператор SLA;

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

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

федерального отделения клиента (пользователям федерального отделения
становятся доступны все магистральные сервисы);
o прикрепить магистральные региональные сервисы к контрактам соответствующих
региональных отделений клиента (пользователям каждого регионально отделения
клиента становится виден магистральный сервис их региона и не видны другие
магистральные сервисы).
2. Оператор SLA может добавлять в новые контракты уже созданные и действующие в других
контрактах сервисы, при этом не происходит дублирования сервисов в общем перечне.
3. Для каждого партнера потребителя услуги SLA (оператора связи для корпоративных
клиентов/потребителя связи для операторов связи) должен быть создан свой контракт,
чтобы его пользователи могли видеть только свои сервисы.
4. Операторы SLA родительского контрагента могут видеть и использовать все сущности
дочерних контрагентов.
Информация о правах доступа пользователей с разным набором ролей и настроек сведена в

таблицу 7.

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

+Оператор
Без роли +Оператор Без контрагентов и Без контрагентов и
SLA + + Контракт + Контрагент + Контракт + Контрагент
Оператор SLA SLA контрактов контрактов
Контрагент
Возможность видеть Только свой Только свой Только свой Только свой Только свой
Все Все Все Только свой профиль
пользователей профиль профиль профиль профиль профиль
Создание новых
пользователей Да Да Да Нет Нет Нет Нет Нет Нет
портала
Да, Да,
Да,
Редактирование пользовате пользовате
пользователей Только свой Только свой Только свой Только свой Только свой
Пользователи
пользователей лей и лей и Только свой профиль

и операторов профиль профиль профиль профиль профиль
портала операторо операторо
SLA
в SLA в SLA
Возможность видеть
ответственных Да, если
Все Все Все Нет Нет Нет Нет Нет
пользователей доступны
контракта
Возможность
добавлять Да, если
Да Да Да Нет Нет Нет Нет Нет
пользователей к доступны
контракту
Да, только в Да, только в Да, только в Да, только в
Все Все Все Нет настройках настройках Нет настройках настройках
контрагентов
контракта контрактов контрактов контрактов
Да, только Да, только
Контрагенты
Создание Да (только через через через

Да Да Да Нет Нет Нет
контрагентов настройки контракта) настройки настройки
контракта контракта
Да, только Да, только
добавление добавление
Редактирование
Все Все Все Нет ролей через ролей через Нет Нет Нет
настройки настройки
контракта контракта
Своего
Этого контрагента и
контракта. его дочерних
Сущности в контрагентов.
блоке меню Сущности в
Инфраструктура
«Инфраструкту блоке меню Своего
объекты Все Все Все Нет Нет Этого контракта
ра», а также «Инфраструкту контрагента
инфраструктуры
сущности, ра», а также
связанные с сущности,
доступными связанные с
сервисами доступными
сервисами
Создание объектов Только Только
Нет Да Только контракты Да Нет Нет Нет
инфраструктуры контракты контракты

Действие Системный администратор Оператор SLA Пользователь
+Оператор
Без роли +Оператор Без контрагентов и Без контрагентов и
SLA + + Контракт + Контрагент + Контракт + Контрагент
Оператор SLA SLA контрактов контрактов
Контрагент
Редактирование и
использование в
других контрактах Нет Да Да Нет Да Да Нет Нет Нет
объектов
инфраструктуры
Просмотр отчётов Своего
SLA, паспортов Этого контрагента, Своего
Все Все Все Нет Нет Этого контракта
неисправности, контракта его дочерних контрагента
плановых работ контрагентов
Своего
Публикация отчётов Этого контрагента,
Да Да Да Нет Нет Нет Нет
SLA контракта его дочерних
Отчеты
Своего
Этого контрагента,
контракта, его дочерних
Перерасчёт отчётов только при контрагентов,
Да Да Да Нет Нет Нет Нет
SLA наличии только при
изменений по наличии
исключениям изменений по
исключениям
Своего
Аналитика
Текущие показатели Этого контрагента, Своего

Все Все Все Нет Нет Этого контракта
и дашборд контракта его дочерних контрагента
Администриро
Доступ к разделу
«Администрировани Да Да Да Нет Нет Нет Нет Нет Нет
е»
вание
Может создавать пользователей с любым

Специальные набором ролей. Может сбрасывать пароли
Создание контрактов и объектов инфраструктуры.
функции всех пользователей, кроме системных
администраторов.

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

дополнительные возможности:
создание контрактов, в которых можно выбрать любых контрагентов и любые сервисы, которые
есть в системе;
создание плановых работ и исключений, в которые можно включить любые сервисы в системе;
редактирование всех сущностей в системе для любого контрагента или контракта.
Важно для пользователей с двумя ролями «Системный администратор» и «Оператор SLA»:

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

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

РЕЗЕРВНОЕ КОПИРОВАНИЕ СИСТЕМЫ
Резервное копирование системы wiSLA осуществляется путём регулярного запуска исполняемого файла
при помощи cron — планировщика задач в UNIX-подобных операционных системах. Интерфейс для
настройки резервного копирования представлен в программе установки wiSLA. Программа установки
позволяет выполнить резервное копирование баз данных Postgres, HBase и системных настроек.
Резервное копирование данных хранилища HBase может быть выполнено двумя способами:
полное резервное копирование системы. При каждом выполнении в архив будет попадать вся
информация из хранилища. Это предпочтительный вариант, позволяет произвести
восстановление без обращения в службу поддержки НТЦ «Веллинк». Однако, на большом объёме
данных он избыточный и длительный;
частичное, или инкрементальное, резервное копирование. При частичном копировании системы
первый раз выполняется полное резервное копирование данных, после этого выполняется
резервное копирование данных каждый раз за прошедшие сутки. Это более быстрый, компактный
и рациональный способ резервного копирования данных HBase, однако восстановление данных в
этом случае значительно усложняется и выходит за рамки настоящего Руководства.
Управление резервными копиями производится в разделе «Backup management» (пункт меню «Backups»).
Программа установки предоставляет следующие возможности (рисунок 73):
Рис. 73 Меню «Backup management»
«Backup HBase» – создать резервную копию текущего состояния всей базы данных HBase. Файл
создаётся в одном каталоге с программой установки;
«Restore HBase» – восстановить базу данных HBase из файла резервной копии;

«Clear HBase table and restore dump» – восстановить базу данных HBase из файла резервной
копии с очисткой таблиц. Текущие таблицы будут переименованы, а впоследствии замещены при
следующем восстановлении данных;
«Clear HBase table» – очистить текущие таблицы с данными HBase (выполняется путём их
переименования);
«Backup Postgres» – выполнить резервное копирование базы данных Postgres с копированием
файла резервной копии в текущий каталог, откуда запущена программа установки;
«Restore Postgres» – восстановить базу данных Postgres из резервной копии. При восстановлении
текущие данные будут утрачены;
«Backup installation info» – создать резервную копию реестра настроек программы установки;
«Config autobackup» – настроить расписание для создания резервных копий.
Настройка резервного копирования
Пример настройки автоматического резервного копирования показан на рисунке 74:
Рис. 74 Меню «Autobackup configuration»
«Backup destination» – путь к каталогу, в котором будут храниться файлы

резервных копий на хосте, указанном в следующей настройке;
«Server where backups will be stored» – имя хоста для хранения резервных копий;
«User on backup server» – имя пользователя на хосте для хранения резервных
копий, под которым будет выполняться вход для копирования файла;
«Do full hbase backup» – определяет, как будут создаваться резервные копии базы
данных HBase. Принимает значения true и false. В случае true каждые сутки будет

создаваться полная копия данных HBase, false включает инкрементальное
копирование данных из HBase.
После настройки рекомендуется выполнить цикл создания резервной копии, восстановления и проверки
работоспособности восстановленной системы на тестовом сервере.
Восстановление баз данных из резервной копии
Для восстановления базы данных Postgres требуется:
1. Найти наиболее актуальный файл резервной копии и скопировать его в каталог с

программой установки. Запомнить имя файла.
3. Выполнить выключение сервера приложений и web-сервера wiSLA (Stop wiSLA).
4. Выполнить операцию «Restore Postgres». В окно запроса ввести имя файла
резервной копии.
5. Дождаться выполнения операции и проанализировать результат.
6. При необходимости применить патчи к базе данных (если были обновления wiSLA
за промежуток времени от создания резервной копии до восстановления). Это
можно сделать в разделе Maintenance – Postgresql management – Patch database.
7. Запустить сервер приложений и web-сервер wiSLA (Start wiSLA).
Для восстановления неинкрементальной базы данных HBase требуется:
1. Найти наиболее актуальный файл резервной копии и скопировать его в каталог с

программой установки. Запомнить имя файла.
3. Выполнить выключение сервера приложений и web-сервера wiSLA (Stop wiSLA).
4. Выполнить операцию «Restore HBase». В ответ на запрос системы ввести имя
файла (архива) резервной копии.
5. Дождаться выполнения операции. Длительность зависит от объёма данных и
производительности дисковой подсистемы. Процесс может занимать более 2
часов.
6. Запустить сервер приложений и web-сервер wiSLA (Start wiSLA).
Для восстановления инкрементальной базы данных HBase обратитесь в службу технической поддержки
НТЦ «Веллинк».
Можно выполнять восстановление баз данных Postgres и HBase последовательно между остановкой и
запуском сервера приложений и web-сервера wiSLA.

ОТКАЗОУСТОЙЧИВЫЙ КЛАСТЕР WISLA
Настройка отказоустойчивого кластера wiSLA позволяет решить 2 задачи:
в случае отказа одного из ЦОД система сохраняет работоспособность;
в кластере работает балансировка нагрузки, что позволяет более эффективно использовать
аппаратные ресурсы серверов.
В примере будет показана установка системы wiSLA на отказоустойчивый контур, который включает в
себя семь серверов, распределённых между двумя ЦОД (по три в каждом) и одним дополнительным
сервером – «третьей точкой опоры» (см. рисунок 75). Для взаимодействия между серверами выделена
подсеть «межсерверного взаимодействия».
Рис. 75 Логическая группировка серверов в отказоустойчивом контуре wiSLA
Отказоустойчивый контур должен состоять минимум из двух блоков (ЦОД), которые включают в себя
сервера с основными компонентами, и дополнительного сервера (третей точки опоры), с помощью
которого контролируется доступность основных ЦОД и целостность кластера. Всего для
отказоустойчивого контура должно быть выделено не менее пяти отдельных серверов.
Желательно, чтобы аппаратная конфигурация серверов была одинаковой. В этом случае можно
производить установку и обновление системы с помощью программы установки без ручного изменения
параметров распределения оперативной памяти по компонентам.

В таблице 8 приведён пример настройки отказоустойчивого контура, который содержит два ЦОД (по три
сервера на каждом) и один дополнительный сервер (третья точки опоры).
Таблица 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
Hadoop: DataNode
Zookeeper
ЦОД2 wislaserver04 / 192.168.1.104 PostgreSQL: Slave
Pgpool
Hadoop: DataNode
Zookeeper
wislaserver05 / 192.168.1.105 HBase: HMaster, HRegionServer
Hadoop: NameNode, DataNode
Zookeeper
wislaserver06 / 192.168.1.106 APP-server
WEB-server
Hadoop: DataNode
Zookeeper
Дополнительный сервер wislaserver07 / 192.168.1.107 Zookeeper, wiSLA-Installer
Предварительно для каждого сервера контура требуется базовая настройка, которая описана в разделе
«Подготовка операционной системы к запуску программы установки».
Для серверов с Hadoop NameNode (wislaserver02 и wislaserver05) потребуется дополнительно

примонтировать диск размером 1Гб, объем диска на обоих серверах должен быть одинаковым.
Для серверов с Pgpool (wislaserver01 и wislaserver04) должен быть выделен IP-адрес в подсети
межсерверного взаимодействия, который будет использовать Pgpool. Далее в примерах настройки
используется «192.168.1.110».
На серверах с Pgpool (wislaserver01 и wislaserver04) также требуется убедиться в отсутствии alias-

интерфейса «eth0:10», где eth0 – корневой интерфейс, на котором настроена подсеть межсерверного
взаимодействия, фактически может отличаться.

Настройка беспарольного доступа по SSH для межсерверного взаимодействия
Для корректной установки системы wiSLA и взаимодействия серверов контура должен быть организован
беспарольный доступ по SSH под пользователем wisla по принципу «каждый с каждым». Также требуется
беспарольный доступ под пользователем root между серверами с Pgpool и третей точкой опоры. При этом
для доступа с сервера на сервер используется hostname. Для этого требуется выполнить следующие
шаги:
1. На каждом сервере контура в файле /etc/hosts указать IP-адреса и hostname всех серверов
контура:
192.168.1.101 wislaserver01
2. На каждом сервере контура под пользователем wisla выполнить генерацию ключей, пароль
оставить пустым:
su -l wisla
cd /home/wisla
ssh-keygen -t rsa
3. С каждого сервера контура под пользователем wisla выполнить копирование ключа на все
остальные сервера для пользователя wisla.
wislaserver01:
ssh-copy-id -i ~/.ssh/id_rsa wisla@wislaserver02
wislaserver02:

wislaserver03:
wislaserver04:
wislaserver05:

wislaserver06:
wislaserver07:
4. Выполнить разовое подключение по SSH под пользователем wisla с каждого сервера на другие
сервера, чтобы подтвердить добавление ключей удалённых серверов (по умолчанию отпечаток
ключа будет храниться в файле /home/wisla/.ssh/known_hosts). При этом на вопрос «Are you sure
you want to continue connecting (yes/no)?» требуется отвечать «yes». При подключении пароль
удалённого сервера запрашиваться не должен.
wislaserver01:
ssh wisla@wislaserver02
wislaserver02:

wislaserver03:
wislaserver04:
wislaserver05:

wislaserver06:
wislaserver07:
5. На серверах с Pgpool и дополнительном сервере под пользователем wisla выполнить копирование

ключа на другие сервера с Pgpool или дополнительный сервер для пользователя root.
wislaserver01:
ssh-copy-id -i ~/.ssh/id_rsa root@wislaserver04
wislaserver04:
wislaserver07:
Выполнить разовое подключение по SSH для проверки работы беспарольного доступа.

6. На серверах с Pgpool и дополнительном сервере (wislaserver01, wislaserver04, wislaserver07) под
пользователем root выполнить генерацию ключей, пароль оставить пустым:
cd /root/
ssh-keygen -t rsa
7. На серверах с Pgpool и дополнительном сервере под пользователем root выполнить копирование

ключа на другие сервера с Pgpool или дополнительный сервер для пользователей root и wisla.
wislaserver01:
wislaserver04:
wislaserver07:
Выполнить разовое подключение по SSH для проверки работы беспарольного доступа.
Установка 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. Перейти в каталог с архивом и распаковать архив:
tar zxvf glusterfs.tar.gz
4. Выполнить установку с помощью yum:
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-geo-replication-3.5.2-1.el6.x86_64.rpm
glusterfs-libs-3.5.2-1.el6.x86_64.rpm glusterfs-server-3.5.2-1.el6.x86_64.rpm
Настройка GlusterFS
Для настройки работы GlusterFS требуется выполнить следующие шаги:
1. На серверах wislaserver02 и wislaserver05 выполнить команды:
mkfs.xfs /dev/sdb1
(файловая система может быть не xfs, в этом случае нужно скорректировать тип файловой системы)
mkdir -p /export/sdb1 && mount /dev/sdb1 /export/sdb1 && mkdir -p /export/sdb1/brick
echo "/dev/sdb1 /export/sdb1 xfs defaults 0 0" >> /etc/fstab
/etc/init.d/glusterd start
2. На сервере wislaserver02 выполнить команды:
gluster peer probe wislaserver02
gluster peer probe wislaserver05
3. На серверах wislaserver02 и wislaserver05 выполнить команды:
gluster volume create namenodevol rep 2 transport tcp wislaserver02:/export/sdb1/brick

wislaserver05:/export/sdb1/brick
gluster volume start namenodevol
mkdir /mnt/gluster; mount -t glusterfs wislaserver02:/namenodevol /mnt/gluster/
chown wisla.wisla -R /mnt/gluster/namenode
Для проверки работы можно на сервере wislaserver02 создать тестовый файл с помощью команды touch:
touch /mnt/gluster/namenode/test_file.txt

и на сервере wislaserver05 проверить наличие файла:
ls /mnt/gluster/namenode/test_file.txt
Затем файл можно удалить:
rm -f /mnt/gluster/namenode/test_file.txt
Действия в программе установки wiSLA
Шаги для установки wiSLA описаны в разделе «Работа с программой установки». Но есть ряд отличий в
процессе, они будут приведены ниже.
Программа установки предварительно должна быть скопирована на сервер wislaserver07 в домашний

каталог пользователя wisla. Права на файл должны быть у пользователя wisla, и файл должен быть
исполняемым. Далее требуется выполнить действия, которые перечислены в блоке «Перечень действий
для установки wiSLA», с учетом отличий в настройках, которые описаны ниже:
1. Запуск программы установки (без изменений).

2. Запуск установки системы (без изменений).
3. Топология. Потребуется указать топологию, описанную выше в таблице 5:
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/gluster/namenode

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».
9. Настройка компонента HBase:
Zookeeper quorum: wislaserver01:2181 wislaserver02:2181 wislaserver03:2181 wislaserver04:2181

wislaserver05:2181 wislaserver06:2181 wislaserver07:2181
10. Настройка компонента PostgreSQL (без изменений).

После шага 10 «Настройка компонента PostgreSQL» появится дополнительный шаг для
конфигурирования Pgpool, на котором потребуется задать настройки:
Trust host or network: 192.168.1.0/24
Specifies the virtual IP address: 192.168.1.110
Specifies the netmask for virtual IP address: 255.255.255.0
Virtual interface: eth0
Trust host or network – подсеть межсерверного взаимодействия.

Specifies the virtual IP address – IP-адрес, который выделен для работы pgpool в подсети
межсерверного взаимодействия.
Specifies the netmask for virtual IP address – маска подсети межсерверного взаимодействия.
Virtual interface – корневой интерфейс, на котором настроена подсеть межсерверного
взаимодействия на серверах wislaserver01 и wislaserver04.
11. Настройка компонента JBoss (без изменений).

12. Настройка топологии wiSLA (без изменений).
13. Настройки модуля сбора данных (без изменений).
14. Настройки интеграции LDAP (без изменений).
15. Настройки дополнительных ресурсов wiSLA (без изменений).
16. Настройка рассылки уведомлений (без изменений).
17. Подтверждение настроек (без изменений).
18. Запрос на добавление сервиса wisla в автозагрузку. В случае с кластером данный запрос не
появляется.
19. Автоматический запуск после установки (без изменений).
20. Реиндексация (без изменений).
21. Начало работы с порталом (без изменений).
Настройка скриптов для учета кратковременных обрывов связи
Для настройки учета кратковременных обрывов связи необходимо выполнить следующие шаги:
1. Предварительно следует создать каталог /opt/wisla3/scripts/ на серверах ЦОД1 и ЦОД2.

Владельцем каталогов должен быть пользователь wisla. На серверах wislaserver03 и wislaserver06

эти каталоги будут созданы автоматически после установки wiSLA. Далее приведена команда для
создания каталога с проверкой его наличия перед созданием:
[ -d /opt/wisla3/scripts ] || mkdir /opt/wisla3/scripts
2. Архив со скриптами можно загрузить по ссылке

ftp://ftp.wellink.ru/Deploies/Centos/cluster/failover_scripts.tar.gz, скопировать на любой из серверов
кластера для пользователя wisla и распаковать с помощью команды:
tar zxvf failover_scripts.tar.gz
Владельцем скриптов и конфигурационных файлов должен быть пользователь wisla.
3. На сервере wislaserver04 в каталоге /opt/wisla3/pgpool/current/sbin/ переименовать файл ifconfig на

ifconfig1 с помощью команды:
sudo mv /opt/wisla3/pgpool/current/sbin/ifconfig /opt/wisla3/pgpool/current/sbin/ifconfig1
4. Скопировать скрипты на сервера контура согласно Error! Reference source not found..
Для копирования рекомендуется использовать консольную утилиту scp. Пример команды
копирования:
scp TRUSTED_SERVERS wisla@wislaserver01:/opt/wisla3/scripts/.
В примере администратор находится в каталоге с распакованными скриптами, копирует файл

TRUSTED_SERVERS на сервер wislaserver01 в каталог /opt/wisla3/scripts/.
Таблица 9 – Размещение скриптов для учета кратковременных обрывов связи.
Сервер Файл Путь

wislaserver01 TRUSTED_SERVERS /opt/wisla3/scripts/
isolation_test.sh /opt/wisla3/scripts/
pgpool_connect.sh /opt/wisla3/scripts/
DATA_PROCESSING_CENTER_SERVERS /opt/wisla3/pgpool/current/
TRUSTED_SERVERS /opt/wisla3/pgpool/current/
failover.sh /opt/wisla3/pgpool/current/
pgpool_connect.sh /opt/wisla3/scripts/
DATA_PROCESSING_CENTER_SERVERS /opt/wisla3/pgpool/current/
TRUSTED_SERVERS /opt/wisla3/pgpool/current/
failover.sh /opt/wisla3/pgpool/current/
ifconfig /opt/wisla3/pgpool/current/sbin/

5. Сконфигурировать файлы со списком серверов и скрипты. Файл должен завершаться пустой
строкой. Редакторы vi (vim) и nano делают это автоматически при сохранении файла.
wislaserver01:
В файле /opt/wisla3/scripts/TRUSTED_SERVERS указать список серверов ЦОД2 и третью точку
опоры:
wislaserver04
wislaserver05
wislaserver06
wislaserver07
В файле /opt/wisla3/pgpool/current/DATA_PROCESSING_CENTER_SERVERS указать список

серверов ЦОД1:
wislaserver01
wislaserver02
wislaserver03
В файле /opt/wisla3/pgpool/current/TRUSTED_SERVERS указать третью точку опоры:
wislaserver07
В конфигурационном файле /opt/wisla3/pgpool/current/etc/pgpool.conf в опции trusted_servers (по

умолчанию строка 442) указать сервер с pgpool ЦОД2 и третью точку опоры:
trusted_servers = 'wislaserver04,wislaserver07'
wislaserver02:
опоры:
wislaserver04
wislaserver05
wislaserver06
wislaserver07

wislaserver03:
опоры:
wislaserver04
wislaserver05
wislaserver06
wislaserver07
wislaserver04:
опоры:
wislaserver01
wislaserver02
wislaserver03
wislaserver07
В файле /opt/wisla3/pgpool/current/DATA_PROCESSING_CENTER_SERVERS указать список

серверов ЦОД2:
wislaserver04
wislaserver05
wislaserver06
В файле /opt/wisla3/pgpool/current/TRUSTED_SERVERS указать третью точку опоры:
wislaserver07
В скрипте /opt/wisla3/pgpool/current/sbin/ifconfig указать (отредактировать) дополнительный IP-

адрес, который был зарезервирован для работы pgpool:
PGPOOL_ALIAS="192.168.1.110"

В конфигурационном файле /opt/wisla3/pgpool/current/etc/pgpool.conf в опции trusted_servers (строка
442) указать сервер с pgpool ЦОД1 и третью точку опоры:
trusted_servers = 'wislaserver01,wislaserver07'
wislaserver05:
опоры:
wislaserver01
wislaserver02
wislaserver03
wislaserver07
wislaserver06:
опоры:
wislaserver01
wislaserver02
wislaserver03
wislaserver07
6. Добавить в crontab задачи на запуск скриптов. Для этого под пользователем wisla нужно
выполнить команду:
crontab -e
Открывается конфигурация cron для пользователя wisla в редакторе vim.
wislaserver01:
*/1 * * * * /opt/wisla3/scripts/isolation_test.sh
*/1 * * * * /opt/wisla3/scripts/pgpool_connect.sh
wislaserver02:

wislaserver03:
wislaserver04:
*/1 * * * * /opt/wisla3/scripts/pgpool_connect.sh
wislaserver05:
wislaserver06:
7. Перезапустить систему, используя программу установки wiSLA – в разделе Maintenance вначале

выполнить «Stop all», затем «Start all».
Действия по восстановлению работы кластера при выходе из строя одного из узлов
Отказоустойчивый кластер фактически рассчитан только на один отказ одного из узлов кластера, после
которого требуется восстановление его работы. В случае выхода из строя двух узлов система перестаёт
функционировать.
Выход из строя ЦОД1
При выходе из строя ЦОД1 все компоненты переходят в активный режим на ЦОД2:
• Pgpool на сервере wislaserver04 переводит PostgreSQL в режим master и активирует alias-

интерфейс на сервере;
• Hadoop и HBase на сервере wislaserver05 переходят в режим active;
• wiSLA на сервере wislaserver06 забирает себе все задачи, которые ранее были распределены
между двумя серверами.
В данном случае требуется восстановить согласованность данных и перенести активные модули на

ЦОД1. Потребуется полная остановка и запуск системы на обоих ЦОД. Для этого нужно выполнить
следующие действия:
1. Восстановить связь между узлами кластера.

2. В отдельной сессии SSH на сервере wislaserver07 под пользователем wisla запустить программу
установки.
3. В разделе «Maintenance» -> «wiSLA management» остановить wiSLA на всех серверах:
Stop_all
4. В разделе «Maintenance» -> «Pgpool management» запустить Pgpool на сервере wislaserver01:
Start on wislaserver01

5. Убедиться в том, что Pgpool на сервере wislaserver01 активирован. Для этого в разделе «Statuses»
выбрать «Pgpool status».
6. В отдельной сессии SSH открыть командную строку сервера wislaserver04 под пользователем
wisla.
7. На сервере wislaserver04 выполнить команду для просмотра состояния узлов PostgreSQL:
psql -p 19999 -c "show pool_nodes"
8. Убедиться в том, что сервер wislaserver04 имеет status «2» (активен) и role «primary», а
wislaserver01 имеет status «3» (неактивен) и role «standby»:
[wisla@wislaserver04 ~]$ 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
(2 rows)
9. На сервере wislaserver04 выполнить команду:
ifconfig
и убедиться в наличии интерфейса «eth0:10».

wisla.
ifconfig
и убедиться в отсутствии интерфейса «eth0:10».

LD_LIBRARY_PATH=/opt/wisla3/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».
---------+---------------+------+--------+-----------+---------
(2 rows)
15. В открытой программе установки остановить Pgpool на сервере wislaserver04. Для этого в разделе
«Maintenance» -> «Pgpool management» выполнить:
Stop on wislaserver04
16. В открытой программе установки остановить PostgreSQL на сервере wislaserver04. Для этого в
разделе «Maintenance» -> «Postgresql management» выполнить:
Stop on wislaserver04

17. В открытой программе установки запустить Pgpool на сервере wislaserver04. Для этого в разделе
«Maintenance» -> «Pgpool management» выполнить:
ifconfig

ifconfig

21. На сервере wislaserver01 выполнить команду для просмотра состояния узлов PostgreSQL и
убедиться в том, что сервер wislaserver01 имеет status «2» (активен) и role «primary», а
wislaserver04 имеет status «3» (неактивен) и role «standby».
---------+---------------+------+--------+-----------+---------
(2 rows)
22. На сервере wislaserver01 выполнить команду (обратить внимание на замену числа 0 на 1 в конце
команды):
24. На сервере wislaserver01 повторно выполнить команду для просмотра состояния узлов PostgreSQL
и убедиться в том, что сервер wislaserver01 сохранил status «2» (активен) и role «primary», а
wislaserver04 изменил status на «2» (активен), role осталась «standby».
---------+---------------+------+--------+-----------+---------
(2 rows)
tail -n 10 /home/wisla/postgresql/postgres.log
и убедиться в наличии строки:
database system is ready to accept read only connections
26. В отдельной сессии SSH открыть командную строку сервера wislaserver02 под пользователем root.

mount -t glusterfs wislaserver05:/namenodevol /mnt/gluster/
28. На сервере wislaserver02 убедиться в наличии непустого каталога /mnt/gluster/namenode/current/
ls /mnt/gluster/namenode/current/
29. В открытой программе установки в разделе «Maintenance» -> «HBase management» выполнить
остановку HBase на всех серверах:
Stop_all
30. В открытой программе установки в разделе «Maintenance» -> «Hadoop management» выполнить
остановку Hadoop на всех серверах:
Stop_all
31. В открытой программе установки в разделе «Maintenance» -> «Zookeeper management» выполнить
остановку Zookeeper на всех серверах:
Stop_all
запуск Zookeeper на всех серверах:
Start_all
запуск Hadoop на всех серверах:
Start _all
запуск HBase на всех серверах:
Start _all
35. В открытой программе установки в разделе «Maintenance» -> «wiSLA management» выполнить
запуск wiSLA на всех серверах:
Start _all
36. После запуска wiSLA проверить состояние компонентов системы в разделе «Statuses» -> «All
statuses» и убедиться в работоспособности портала wiSLA.
Выход из строя ЦОД2
При выходе из строя ЦОД2 все компоненты остаются в активном режиме работы на ЦОД1.

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

2. В отдельной сессии SSH на сервере wislaserver07 под пользователем wisla запустить программу
установки.
3. В разделе «Maintenance» -> «wiSLA management» остановить wiSLA на всех серверах:
Stop_all
4. В разделе «Maintenance» -> «Pgpool management» запустить Pgpool на сервере wislaserver04:
wisla.
7. На сервере wislaserver01 выполнить команду для просмотра состояния узлов PostgreSQL:
psql -p 19999 -c "show pool_nodes"
8. Убедиться в том, что сервер wislaserver01 имеет status «2» (активен) и role «primary», а
wislaserver04 имеет status «3» (неактивен) и role «standby»:
---------+---------------+------+--------+-----------+---------
(2 rows)
ifconfig

wisla.
ifconfig

14. На сервере wislaserver01 снова выполнить команду для просмотра состояния узлов PostgreSQL и
убедиться в том, что сервер wislaserver01 сохранил status «2» (активен) и role «primary», а
wislaserver04 изменил status на «2» (активен), role осталась «standby».

---------+---------------+------+--------+-----------+---------
(2 rows)
ifconfig

ifconfig

tail -n 10 /home/wisla/postgresql/postgres.log
и убедиться в наличии строки:
database system is ready to accept read only connections
18. В отдельной сессии SSH открыть командную строку сервера wislaserver05 под пользователем root.
mount -t glusterfs wislaserver02:/namenodevol /mnt/gluster/
20. На сервере wislaserver05 убедиться в наличии непустого каталога /mnt/gluster/namenode/current/
ls /mnt/gluster/namenode/current/
остановку HBase на всех серверах:
Stop_all
остановку Hadoop на всех серверах:
Stop_all
остановку Zookeeper на всех серверах:
Stop_all
запуск Zookeeper на всех серверах:

Start_all
запуск Hadoop на всех серверах:
Start _all
запуск HBase на всех серверах:
Start _all
27. В открытой программе установки в разделе «Maintenance» -> «wiSLA management» выполнить
запуск wiSLA на всех серверах:
Start _all
28. После запуска wiSLA проверить состояние компонентов системы в разделе «Statuses» -> «All
statuses» и убедиться в работоспособности портала wiSLA.
Выход из строя третьей точки опоры
Данная ситуация не влияет на работоспособность контура, но грозит отказом системы в случае выхода из
строя одного из ЦОД. Для восстановления работы третьей точки опоры требуется выполнить следующие
действия:

2. На сервере wislaserver07 запустить программу установки.
3. В разделе «Maintenance» -> «Zookeeper management» запустить Zookeeper на сервере
wislaserver07:
4. Проверить состояние компонентов системы в разделе «Statuses» -> «All statuses» и

работоспособность портала wiSLA wiSLA.

WISLA В ИЗОЛИРОВАННОМ КОНТУРЕ
Особенности работы wiSLA в изолированном контуре

В случаях, когда требуется обеспечить дополнительную безопасность сетевой инфраструктуры, часто
принимается решение развернуть wiSLA в изолированном по отношению к сети Интернет контуре. ПАК
wiSLA может корректно работать в этом режиме. Основные отличия касаются добавления и отображения
точек доступа на карте, так как для работы этого функционала требуется доступ к внешнему геокодеру и
карт-серверу как серверов wiSLA, так и рабочих станций пользователей:
в открытом контуре адрес вводится в одну строку, а координаты определяются автоматически. В
случае отсутствия интернет-соединения у пользователей системы создать точку доступа не
удастся;
в изолированном контуре с локальным геокодером адрес вводится в несколько полей ввода,
предпринимается попытка автоматического получения координат. В случае неудачи или при
ошибочном определении координаты могут быть введены вручную или изменены;
в изолированном контуре без геокодера адрес вводится в несколько полей, координаты вводятся
вручную;
в изолированном контуре без локального карт-сервера точки доступа не смогут быть отображены
на карте сервисов;
в случае отсутствия координат в настройках точки доступа последние не смогут быть отображены
на карте сервисов.
Настройки могут быть выполнены при первичной установке wiSLA или в процессе эксплуатации. Они
задаются в программе установки wiSLA. Перед выполнением настроек следует:
принять решение, будет ли использоваться локальный геокодер. Если да – выполнить его
установку и настройку;
принять решение, будет ли использоваться локальный карт-сервер. Если да – выполнить его
установку и настройку.
Вопрос настройки локального геокодера и карт-сервера выходит за рамки настоящего Руководства. При
необходимости можно обратиться в службу технической поддержки НТЦ «Веллинк» для получения
консультации.
Переключение wiSLA в изолированный режим

Все связанные с облачным режимом настройки находятся в программе установки на вкладке «wiSla
resources configuration».
Параметр «Local geo services» определяет тип контура. Для закрытых контуров принимает значение
«true», для открытых – «false».
Параметр «Nominatim service URL» предоставляет возможность работы с произвольным Nominatim-

сервером. Используется для определения координат по адресу в изолированном контуре. Данная
настройка игнорируется для открытого контура. Например, «http://map.wellink.ru/nominatim/».

Параметр «URL to tiles for map» – путь к изображениям карты. Например,
«http://map.wellink.ru/osm_tiles/».
Для переключения wiSLA в изолированный режим требуется:

запустить программу установки (подробно запуск рассматривается в разделе «Работа с
программой установки», а внесение изменений – в «Изменение одного или нескольких параметров
wiSLA»);
в режиме «Config Update» перейти на вкладку «wiSla resources configuration»;
изменить значения параметров «Local geo services», «Nominatim service URL», «URL to tiles for
map»;
выполнить остановку и запуск wiSLA.

Для проверки успешности настройки следует:
авторизоваться на портале оператора;
перейти в раздел «Точки доступа»;
нажать «+ Точка доступа». Вместо поля «Адрес» должны быть доступны для ввода «Область»,
«Город», «Улица», «Дом»;
заполнить поля корректными тестовыми данными. Проверить получение координат в случае, если
был настроен локальный геокодер или ввести координаты вручную в противном случае;
сохранить настройки точки доступа. Проверить факт появления новой точки доступа в общем
списке;
если был настроен локальный карт-сервер, перейти в раздел «Карта сервисов», изменить
масштаб карты.
При успешном появлении точки доступа в общем списке на странице «Точки доступа» переключение
wiSLA в изолированный режим считается выполненным корректно.
При успешном открытии карты сервисов после изменения в настройках адреса карт-сервера на
локальный настройка карт-сервера считается выполненной успешно. Если же карта сервисов не
открывается, на странице возникают ошибки или масштаб невозможно изменить следует проверить
корректность значения параметра «URL to tiles for map», доступность и работоспособность самого карт-
сервера на рабочем месте администратора.
При успешном получении координат в настройках точки доступа после изменения адреса геосервиса
настройка геосервиса считается выполненной успешно. Если введённый адрес корректен, а координаты
не определяются, следует повторить попытку с другим адресом. Если в обоих случаях система не смогла
определить координаты, следует проверить корректность значения параметра «Local geo services»,
доступность и работоспособность локального геосервиса на рабочем месте администратора.

ОБЛАЧНЫЙ РЕЖИМ WISLA
Особенности облачного режима

Начиная с версии 4.1.1, ПАК wiSLA может работать как облачная платформа, предоставляющая услуги
мониторинга малому и среднему бизнесу (SME).
Если портал развёрнут в режиме wiSLA.Cloud:

у новых пользователей есть возможность пройти регистрацию самостоятельно;
при регистрации нового пользователя в случае совпадения названия компании с существующей в
базе пользователь может запросить доступ к порталу у системного администратора;
число действий системного администратора по добавлению пользователя по запросу сведено к
минимуму;
новые пользователи, которые прошли регистрацию, создаются с ролями «Пользователь» +
«Оператор SLA»;
учётные записи и контрагенты с неподтверждённой в течение 48 часов регистрацией удаляются.
Периодичность поиска таких записей настраивается;
на странице «Зонды» есть кнопка для загрузки программного агента;

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

Все связанные с облачным режимом настройки находятся в программе установки на вкладке «wiSla Cloud
System».
За активацию режима облачной системы отвечает параметр «Enable wisla cloud». Принимает значения:
true (облачный режим) или false (стандартный режим).
Интервал запуска процедуры поиска учётных записей и контрагентов, не завершивших регистрацию в

течение 48 часов, определяется параметром «Registrations attempts check interval» на вкладке «wiSla
Cloud System», принимает целое значение в минутах.
Адрес электронной почты администратора, на который будут приходить письма о запросе доступа,
задаётся параметром «Support email». Значением может быть один email-адрес.
Интеграцию с внешним сервисом веб-аналитики можно включить в «Third-party scripts enabled» (true –
включена, false – выключена), указать путь к xml-файлу настроек интеграции (скрипту) – в «Path to third-
party scripts xml». Скрипт можно получить в службе технической поддержки НТЦ «Веллинк».

Эти параметры могут быть заданы при первичной установке wiSLA или позже. Для изменения параметров
следует использовать программу установки wiSLA:
запустить программу установки (подробно запуск рассматривается в разделе «Работа с
программой установки», а внесение изменений – в «Изменение одного или нескольких параметров
wiSLA»);
в режиме «Config Update» перейти на вкладку «wiSla Cloud System»;
задать параметры;
продолжить процедуру обновления;
выполнить перезапуск wiSLA.
На рисунке 76 показан пример настройки wiSLA Cloud.
Рис. 76 Пример заполнения параметров на вкладке wiSLA Cloud System
В примере после применения настроек:

будет включен режим wiSLA Cloud;
пользователи и контрагенты, не подтвердившие регистрацию в течение 48 часов, будут удаляться.
Интервал проверки составит 30 минут;
запросы на добавление учётных записей будут отсылаться на адрес admin@thecompany.com;
статистика посещения страниц будет отслеживаться;

параметры интеграции с внешним сервисом веб-аналитики для отслеживания статистики заданы в
файле /home/wiSLA/CloudServices.xml.
Подготовка ссылок на программные агенты

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

получить и подготовить к копированию актуальные файлы программных агентов wiProbe;
скопировать файлы на сервер wiSLA;

изменить владельца файлов на «wisla», группа «wisla»;

проследить, чтобы у владельца были права на чтение;
для linux-агентов снять разрешение на исполнение, если оно появилось при копировании;
находясь на сервере, файлы следует перенести в каталог
/opt/wisla3/jboss/current/wisla_program_agents;
в каталоге создать текстовый файл index со ссылками на файлы. Пример файла показан ниже;
сохранить файл index. Перезапуск wiSLA не требуется. Если изменения не применились,
выполнить выход и вход на портал;
рекомендуется проверить работоспособность ссылок и загруженных файлов после применения
настроек.
Пример файла index:
"Windows":"alfa-test2-win_slamon-agent-win-1.12.62271.exe",
"Linux":"",
"Fedora 19 | x32":"",
"Fedora 19 | x64":"",
"Debian 6 | x32":"",
"Debian 6 | x64":"alfa-test2_slamon_1.12.62271_x86_64.deb",
"CentOS 6.4 | x32":"",
"CentOS 6.4 | x64":"alfa-test2_slamon-1.12.62271.x86_64.rpm",
"Ubuntu 12.04 | x32":"",
"Ubuntu 12.04 | x64":"alfa-test2_slamon_1.12.62271_x86_64.deb"
В примере сделаны записи для появления ссылок на программные агенты для Windows, Debian 6 x64,
CentOS 6.4 x64, Ubuntu 12.04 x64. На рисунке 77 показан результат настройки на портале.

Рис. 77 Список агентов на портале оператора после настройки

ВАЖНАЯ ИНФОРМАЦИЯ
О документе
© 2018 Wellink R&D LLC. Все права защищены.
Компания Wellink оставляет за собой право в одностороннем порядке без какого-либо специального
уведомления, без согласия Пользователя в любое время вносить улучшения и/или изменения в продукты
и/или программное обеспечение, дополнять и/или изменять настоящий документ. Новая редакция
документа вступает в силу с момента ее размещения в Базе знаний компании Wellink по адресу
info.wellink.ru. Убедитесь, что Вы читаете последнюю актуальную версию настоящего документа.
Были предприняты максимальные усилия для того, чтобы гарантировать полноту и точность
представленной в документе информации. Wellink не несет ответственности за возможные описки и
неточности.
Использование Пользователем продукта и/или программного обеспечение после любых изменений и/или
улучшений означает его согласие с такими изменениями и/или улучшениями.
Если у вас есть замечания, касающиеся данного документа или продуктов, которые он описывает,
направляйте их по адресу support@wellink.ru.
О компании
Wellink (www.wellink.ru) разрабатывает инновационные продукты и решения в области автоматизации и

управления качеством информационных и телекоммуникационных услуг для операторов связи,
государственного и корпоративного сегментов.
wiSLA, wiProbe, wiTest – являются официально зарегистрированными торговыми марками компании

Wellink, имеют все необходимые сертификаты и защищены авторским правом.
Wellink оказывает услуги по внедрению, сопровождению и улучшению своих продуктов согласно

требованиям заказчика. При внедрении своих продуктов Wellink опирается на обширную партнерскую
сеть, которая непрерывно развивается на территории Российской Федерации и за ее пределами.
Сервисный центр компании Wellink готов оказывать услуги технической поддержки высокого качества в
режиме 24х7.
Девиз Wellink: Гибкость в отношениях, Инновации в разработке. Простота в использовании. Мы открыты

для партнерства и интеграции. Мы делаем услуги измеримыми не только по цене, но и по качеству!
Головной офис компании находится по адресу: 127322, Москва, ул. Яблочкова, д.21, корп.3
тел./факс: +7 (495) 374-66-78.
Интернет-сайт: www.wellink.ru
127322, г. Москва,
ул. Яблочкова, д.21, корп.3
Тел.: +7 (495) 374-66-78

wiSLA.Руководство администратора 4.2

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

wiSLA.Руководство администратора 4.2

Загружено:

Авторское право:

Доступные форматы

Wellink R&D LLC

wiSLA (well integrated SLA)

© Wellink, 2018 1 All rights reserved

© Wellink, 2018 2 All rights reserved

ЗАДАЧИ, РЕШАЕМЫЕ СИСТЕМОЙ 5

АРХИТЕКТУРА И СОСТАВ ПЛАТФОРМЫ WISLA 7

РАБОТА С ПРОГРАММОЙ УСТАНОВКИ 22

НАЧАЛО РАБОТЫ С ПОРТАЛОМ 38

ПОЛУЧЕНИЕ ДОСТУПА НА ПОРТАЛ 38

ПОЛУЧЕНИЕ ДОСТУПА НА ОБЛАЧНУЮ ВЕРСИЮ ПОРТАЛА 39

ОПИСАНИЕ ЭЛЕМЕНТОВ ПОРТАЛА 41

ИМПОРТ И ЭКСПОРТ СПИСКОВ ОБЪЕКТОВ 70

© Wellink, 2018 3 All rights reserved

РАЗГРАНИЧЕНИЕ ПРАВ ДОСТУПА 81

ПРАВА НА ДЕЙСТВИЯ С ОБЪЕКТАМИ 81

РЕДАКТИРОВАНИЕ ВЛАДЕЛЬЦЕВ СУЩНОСТЕЙ 86

РЕЗЕРВНОЕ КОПИРОВАНИЕ СИСТЕМЫ 87

ОТКАЗОУСТОЙЧИВЫЙ КЛАСТЕР WISLA 90

WISLA В ИЗОЛИРОВАННОМ КОНТУРЕ 112

ОСОБЕННОСТИ РАБОТЫ WISLA В ИЗОЛИРОВАННОМ КОНТУРЕ 112

ПЕРЕКЛЮЧЕНИЕ WISLA В ИЗОЛИРОВАННЫЙ РЕЖИМ 112

ОБЛАЧНЫЙ РЕЖИМ WISLA 114

ОСОБЕННОСТИ ОБЛАЧНОГО РЕЖИМА 114

ВКЛЮЧЕНИЕ И НАСТРОЙКА ОБЛАЧНОГО РЕЖИМА 114

ПОДГОТОВКА ССЫЛОК НА ПРОГРАММНЫЕ АГЕНТЫ 115

ВАЖНАЯ ИНФОРМАЦИЯ 118

© Wellink, 2018 4 All rights reserved

Программно-аппаратная платформа wiSLA позволяет урегулировать конфликты между

В основу платформы wiSLA заложена следующая идеология:

управление конфликтами (Conflict Management) – решения на базе платформы wiSLA

управление восприятием пользователей (Customer Experience Management – CEM) –

Задачи, решаемые системой

Мониторинг качества L2/L3 VPN и услуг широкополосного доступа в Интернет

Одной из основных задач, решаемых с помощью платформы wiSLA, является мониторинг и

© Wellink, 2018 5 All rights reserved

Платформа wiSLA позволяет формировать периодические отчеты SLA в привязке к биллинговым

Мониторинг доступности и производительности сервисов L7 и приложений

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

wiSLA обеспечивает многоуровневый мониторинг пользовательских сервисов L7 (WEB-порталы,

Платформа wiSLA позволяет производить мониторинг видеоконференцсвязи (ВКС),

В платформу заложены встроенные шаблоны SLA, разработанные для контроля качества

© Wellink, 2018 6 All rights reserved

Общее описание архитектуры

ПАК wiSLA относится к разряду крупных корпоративных приложений, архитектура которого

Взаимодействие между компонентами осуществляется с помощью общей коммуникационной

Подсистема медиации (Mediation)

Подсистема медиации (Mediation), рисунок 1, обеспечивает двустороннее взаимодействие

Рис. 1 Подсистема медиации (Mediation)

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

Ключевые особенности подсистемы:

© Wellink, 2018 7 All rights reserved

Подсистема управления SLA (SLM)

Рис. 2 Подсистема управления SLA (SLM)

Ключевые особенности подсистемы:

Подсистема мониторинга качества сервиса (SQM)

Подсистема мониторинга качества сервиса (SQM), рисунок 3 обеспечивает непрерывный

© Wellink, 2018 8 All rights reserved

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

• сравнение значений показателей качества с установленными SLA порогами,

• частота обновления информации от 10 секунд до 1 часа;

формирование оперативных отчетов показателей производительности услуг (KPI);

Ключевые особенности подсистемы:

Подсистема учета неисправностей (Service Desk)

Подсистема учета неисправностей (Service Desk), рисунок 4, отвечает за регистрацию