Проектирование и мониторинг корпоративной сети департамента ситуационного реагирования и аналитики ПАО «Ростелеком»

Вишняков Александр Николаевич

Проектирование и мониторинг корпоративной сети департамента ситуационного реагирования и аналитики ПАО «Ростелеком»

Бакалаврская работа

Связь

Дипломы

Вуз: Мордовский государственный университет имени Н.П. Огарева

ID: 6065e24ae010f800016c944d

UUID: 42044600-752a-0139-ab43-0242ac18000a

Язык: Русский

Опубликовано: больше 3 лет назад

Просмотры: 20

Вишняков Александр Николаевич

Источник: федеральное государственное бюджетное образовательное учреждение высшего образования "Национальный исследовательский Мордовский государственный университет им. Н. П. Огарёва"

Комментировать 0

Рецензировать 0

Скачать - 6,7 МБ

Поделиться работой

ФЕДЕPAЛЬHOЕГOCУДAPCTBЕЕIHOЕБIoДжЕTFIoЕ oБPAЗoBATЕЛЬнoЕ УЧPЕxtДЕHиЕ BЬICШIЕГOoБPAЗoBAHиlI (HAЦи o HAЛЬ HЬItrlwc сЛЕД oBAT Е Ль с киЙ MoPДoB Cк vlЙ гo сУДAP с TBЕ нIIьIЙ УIIиBEP с иTЕ T иM. II. П. oгдpЁBA> ИнститyT эЛекTpoIIики и сBеToTеxники Кaф едpa инф oкoMMyIIикaциoнIIЬIx Tеx}IoЛoгий И cИcTeМ сBяЗи t УTBЕP)ItДAIo Зaв. кaфелpoй кaнlц. Tlxн. нayк' Дoц. tl^ J-Ч (""Д,,ф О& 2020r. кoPПoPATиBHoй свтpп n_ф, БAкAЛABPCI{AЯ IIPOЕкTиPOBAIIиЕ и MoHиToPиЕ{г B. B. HикYлllн PAБOTA ДЕIIA-'"Чъ1T#rf,й""ж.жъ1'HЁft Ьff""BAII4яIд 2!29 A.I{. BишнякoB Aвтop бaкaлaвpскoйpaбoтьl oбoзнaчrrlиr бaкaлaвpскoйpaбoтьlБP.020 69964.11.03.02-02-20 TrxнoJIoгиии сисTrМЬIсBяЗи HaпpaвЛениr 1l.03 .02 vTr'фoкoМMyHИКaЦvIoHЕIЬIr Pyкoвo.циTrJIЬp aбoтьl /но,,/ кaII.ц.кyлЬТypoлoгии, Дoц. fuoдn€ь) HopмoкoIITpoлrp 4t"!t кaн.ц.кyлЬTypoлoгии' Дoц. 0в. с6.4аful. (дaтa) c Е. A. Кoшrевaя О6. О6, ,ЯДiё,,: (дaтa) Е. A. Кoшrевaя (тloлттv#ь) Capaнск 2020

ФЕДЕPAЛЬHOЕГOCУДAPCTBЕHнOЕ' БIoДЖЕTEIoЕ oБPAз oBATЕЛЬнoЕ yЧPЕxtДЕHиЕ BЬICШIЕГOoБPAЗoBAHИlI ((IIAЦи o HAЛ Ь I{ЬIiц llc cЛЕ Дo B A T Е ЛЬ с к уIЙ MoPДoBск ИtrIгo сУДAPс TBЕtIHьlЙ УHиBЕPC иTЕ T иM. I{.fI. oгдpiiBA> ИнcтlцтyT ЭЛекTpotlики и сBеToTеxIIики КaфелPa инфoкoMМyникaциoIIIIЬIx c TеxtloлoтиЙ и сисTrM сBяЗи УTBЕPxtДAЮ ЗaB. кaфедpoй кaн.ц.TехH.нayк, Дoц. I I,'Ь (""Д,"*) B. B. Hикyлин << lL>>nлу tr{ьt20l9r. зAДAIIиЕ I{A БAкAЛABPскУIO PAБOTУ Cтyдент BишrнякoB AлексaIIДp HикoлalBиЧ 1 Tемa фoектиpoBa}Iиr vI MoIIитopиHг кopпop aтvтвъlotrlсrTи .{епapтaMrllтa отеЛrкoм) cиTyaциoЕIlloГo p еaгиp oBaIIия kl aHaIIkITикaIIAO <<Po 9008.с oт 12 нoябpя 2019 г. Утвеpхtдrнa llpикaзoМ J\Гq 2 Cpoк IIpе.цстaBJIrния paбoтЬI к зaщиTr 6 утloня 2020 r. 3 Coдеp)I(aHиr BЬIПyскнoй квaлификaциoннoй paбoтьl 3.1 oбзop сисTrМ MotlиTopингa B 3.2 Bътбop гIpoцpaМMlloгo oбеспе Чe.нИЯ 3.3 Bьlбop oбopyл oв,alнvIЯ 3.4 ПoсTaIIoBкa НaМoIIиTopиtIг сисTrМ сAIIC 3.5 PaсчrT ЭкolloМиЧескoй эффекTиBIIocTуI 4 ГIpилo)E(rIIия vl Бaзa Знaний

4.I IIPиЛoxtЕHиЕ A (oбязaтепьнoе)Tеxничrскиr щебoвaНIlЯ,.цJUI crpBеpoB Мo}IиTopиHгa 4.zlwиЛoxtЕHИЕБ (oбязaтlлЬIloe) Cпеци фикaция oбopyдoBaH|4Я 4.3 tIPиЛoжЕHИЕ B (oбязaтельнoе) Pесypснo.сrpBvIcкaЯ MoдrЛь : сеpBисa CACП 4.4 IIPиJIOжЕHИЕ Г (oбязaтельнoe) Pесypснo-сrpBисIlaя сrpBисa Бaзa Знaний Pyкo вo.циTrJIЬpaбoтьl кaн.ц.IryJlьTypoлoгии, Дoц. к испoлtlоHи,o IIpиII,Iл ЗaДaнуте t rт l3 fu. MoДrЛЬ

PEФЕPAT Tемoй бaкaлaвpскoй сиTyaциoнIloГo сети,{епapтaMеIITa кopпopaTиBlloй И MoIIиTopиIIг paбoтьr яBЛяеTся iTpoекTиpoBaниr p raгиpo BaIIиЯ kI aHaIIИTIL|<I4 IIAO <<PoстеЛекoM). MoнИToPИнГ, КOPПOPATиBHAЯ CИCTЕМA МOHИTOPиFIГA, КOМMУTATOP, CЕ'TЬ, IIPOЕКTИPOBAHИЕ БaкaлaBpскaяpaбoтa сo.цеpxrиT59 сTpaHиЦ,26 pисy}IкoB,1 тaблицy, 8 исIIoЛьЗoBa}IнЬIx исToЧtlикo B, 4 llpиЛoxt онИЯ и 3 фopМyЛЬI. I]еЛЬ .цaннoй paбoтьr сoсToиT B иЗyЧеHvII4 TrxIIиЧескиx и ПpoГpaMМнЬIx и I\лoIIиTopиlIгa IT.сисTеМ и IT-сеpBисoB. сpеДсTB ДЛЯIIoсTpo e:н:r4Я B пpoекTr oсyщrсTBЛен vT apxиTекrypЬI paзбop сyщrсTByroщиx oTДеЛЬIIo IIaЗIIaЧoнvlЯ сисTеM Mo}IиTopуItI'Гa'уI){ кoМПoIIенToB' BзяTЬIХ вьlбop IIo Jloкaльнoй Пpoгpal\dy1loгo и allпapaTнoгo oбеспеЧrния ДЛя IIеpе.цaЧI. ДaHlIЬIx ceT|4' a Taкхtr ,.o''o"rнTog. ДIIЯ ПoсTaнoBки }Ia МoIIиTopиIIг Taкхсе paссMoTpенa TrxlloЛoГия kI prсypcllьIx сrTrBЬIx SМNP.JIoBУIIIек, с IIoМoIщЬIo кoTopЬIx BеДrT cя нaблtoДеI{ие Зa paботoй oбopy,цoBallи,l. B pезyjlЬTaTr paсчrTa Экoнoмичlскoй эффекTиBнoсTи бьlлo yсTaIIoBJIlнo, ЧTo ПporкTнoе prlшениr IIoJIIIoсTЬ}оoкyПиTся Чеpез 8,2 МrсяцrB. БP -020699 64-11,03,02-02-20 B и ш н я к o вA . H . HикyлинB.B. mopuH2 ПpoeкmupoвoHueu ^/|oнu сemu Kopг|opаmuвнoit mуa сu p mo н Me m o п o цuo l1Hozo fle а сtHoлumuкuПАo peazupoвсIHLrя кPoсmелеКo|v|)) ИЭC, ИКTuССеp.4З1 i.

СОДЕРЖАНИЕ ВВЕДЕНИЕ 7 Обзор систем мониторинга 8 1.1 Системный мониторинг 9 1.1.2 Система мониторинга BMC Proactive NET 9.6 9 1.1.3 Система мониторинга System Center Operations Manager (SCOM) 12 1.1.4 Система мониторинга DynaTrace 14 1.2 Прикладной мониторинг 15 1.3 Функциональный мониторинг 16 1.4 Принцип работы системы мониторинга BMC Proactive NET 9.6 19 1.5 Обзор технологии SNMP-ловушек 23 1.6 Обоснование необходимости мониторинга 24 1 2. Выбор программного обеспечения и оборудования 25 2.1 Выбор программного обеспечения 25 2.1.1 Архитектура системы мониторинга 25 2.2 Выбор оборудования 30 2.2.1 Выбор коммутатора 30 2.2.2 Выбор серверов мониторинга 33 2.2.3 Расчет и выбор источника бесперебойного питания 34 3 Установка компонентов системы и постановка на мониторинг 37 3.1 Создание агента мониторинга 3.2 Подготовка серверов к постановке на мониторинг и установка агентов мониторинга 37 42 3.3 Создание политики проверки 43 3.4 Создание ресурсно-сервисной модели 48 3.5 Мониторинг ошибок в работе оборудования с помощью SMNP-ловушек 51 3.6 Расчет экономической эффективности БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата 52 Лист 5

ЗАКЛЮЧЕНИЕ 54 СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 55 ПРИЛОЖЕНИЕ А (обязательное) Технические требования для серверов мониторинга 56 ПРИЛОЖЕНИЕ Б (обязательное) Спецификация оборудования 57 ПРИЛОЖЕНИЕ В (обязательное) Ресурсно-сервисная модель сервиса САСП 58 ПРИЛОЖЕНИЕ Г (обязательное) Ресурсно-сервисная модель сервиса База Знаний 59 БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 6

ВВЕДЕНИЕ Мониторинг – это совокупность программного и аппаратного обеспечения для сбора информации о работоспособности систем. При помощи нее возможно собирать данные о работе как отдельно взятых элементов системы, так и функционале системы в целом. В дальнейшем собранная информация может быть проанализирована для выявления недопустимой конфигурации оборудования, времени максимальной нагрузки серверных компонентов и так далее. Также, возможно подключение к системе услуги автоматического оповещения ответственных лиц для своевременного оповещения о проблемах, возникающих при работе. Сейчас эта мера необходима в любой бизнес-системе, так как это позволяет повысить работоспособность и отказоустойчивость путем обработки информации об ошибках и авариях. При должной скорости реагирования ответственных лиц возможно устранение неполадок в кратчайшие сроки, что позволяет использовать систему бесперебойно. В данной работе будет рассмотрена замена существующей конфигурации серверного оборудования, а именно – коммутатора и источника бесперебойного питания, добавление серверов мониторинга, а также постановка на мониторинг серверов сервиса САСП и Базы Знаний. Постановка на мониторинг системы обеспечит сбор данных и оповещение ответственных, что увеличит время работы системы без отказов, а значит, позволит использовать ее более эффективно. Замена источника бесперебойного питания даст возможность следить за режимом питания подключенных к нему компонентов, а замена коммутатора – возможность отслеживать его состояние и получать информацию о возможной ошибке. Это будет реализовано с помощью SNMP-ловушек (SNMP trap) – особого широковещательного (UDP) пакета, отправляемого устройством с поддержкой протокола SNMP. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 7

1 Обзор систем мониторинга Мониторинг IT-сервисов – это процесс, цель которого – соблюдение баланса между количеством имеющихся сетевых ресурсов, поддержанием определенного уровня информационных услуг и затратами на эффективное функционирование вычислительных сетей. В первую очередь он необходим, чтобы администраторы узнавали о проблемах в инфраструктуре раньше пользователей. Это, по сути, комплекс быстрой диагностики, который дает своевременное оповещение о проблемах и точную информацию, где и что случилось конкретно. Ключевую роль в этом играет система нотификаций – оповещений ответственных лиц путем e-mail и sms рассылок. В тексте письма содержится вся необходимая информация, чтобы начать устранение неполадки – hostname сервера, на котором произошла авария, название процесса, графика использования ресурса, который превысил критическую отметку, его нынешнее состояние и время, когда произошел сбой. Также системы мониторинга позволяют собирать статистику (метрику) определенных процессов – например, нагрузка на ядра процессора, свободная оперативная память или место на диске и так далее. Следовательно, эти данные пригодны для дальнейшего анализа с целью увеличения эффективности работы сервиса. Так, например, мы можем увеличить объем оперативной памяти или места на диске, если метрики по этим параметрам зачастую превышают допустимое значение. Существует множество различных систем мониторинга IT-сервисов, но в рамках данной работы будут рассмотрены три основных вида, на которые можно условно разделить любую такую систему. Это системный, прикладной и функциональный мониторинг. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 8

1.1 Системный мониторинг Системный мониторинг – самый простой вид мониторинга, который нужен для сбора статистики об использовании физических ресурсов сервера. В них, к примеру, входят: свободное место на диске, процент использования оперативной памяти, загруженность ядер процессора и так далее. Такой вид мониторинга необходим для поддержания сервера в рабочем состоянии. Метрики, собираемые данным видом мониторинга, могут послужить данными для создания различных графиков производительности системы. Кроме того, некоторые из этих метрик могут иметь ключевое значение при анализе работы сервера. К примеру, при недостаточном количестве дискового пространства на сервере базы данных может возникнуть авария. При постановке на мониторинг такие моменты можно исключить, так как система заранее предупредит о приближении к критической точке. В компании ПАО «Ростелеком» для этого используется BMC Proactive NET 9.6, SCOM – System Center Operations Manager, а также DynaTrace. Все эти варианты предлагают свой подход для мониторинга, поэтому остановимся на них более детально. 1.1.2 Система мониторинга BMC Proactive NET 9.6 BMC Proactive NET 9.6 – это интегрированная платформа для управления доступностью услуг и производительностью IT-систем и IT-сервисов. Он объединяет управление событиями, управление воздействием на услуги, мониторинг производительности и анализ данных (включая базовые показатели, обнаружение отклонений и алгоритмы анализа первопричин) в едином бесшовном решении для физических, виртуальных и облачных сред [1]. Мониторинг IT-сервисов системой BMC Proactive NET 9.6 имеет несколько рабочих режимов: пассивный, активный, проактивный. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 9

Отличия между ними следующие: 1) активный режим – это периодические опросы IT сервисов, ожидание/получение ответов и реакция на них; 2) пассивный режим – это постоянный режим ожидания системами мониторинга событий в системе; 3) проактивный режим – это прогнозирование поведения инфраструктуры на основании исторических данных за определенный период времени. BMC Proactive NET 9.6 предоставляет следующие возможности для контроля критических важных IT-систем и IT-сервисов. Управление событиями – предоставляет решение в режиме реального времени для автоматического обнаружения и решения проблем IT, прежде чем они воздействуют на критические системы IT. Проактивно коррелирует, расставляет приоритеты и разрешает события в бизнес-контексте в реальном времени. Управление влиянием на сервисы – отображает бизнес-сервисы и ITинфраструктуру, чтобы помочь управлять приложениями и сервисами, которые важны для управления бизнес-сервисами (BSM), и определять их приоритеты. Управление Service Impact позволяет расставлять приоритеты бизнессервисов на основе бизнес-логики, давая возможность быстро определить, какие проблемы наиболее актуальны. Мониторинг производительности – упреждающее обнаружение, автоматическое прогнозирование и решение проблем производительности IT и неоптимальных конфигураций, прежде чем пользователи и сервисы окажут негативное влияние. Анализ производительности – позволяет BMC ProactiveNet изучать поведение приложений и IT-инфраструктуры в разных географических зонах, прогнозировать проблемы до их возникновения, автоматически определять вероятную причину в технологических блоках и инициировать стандартизированные процессы сортировки и разрешения проблем. Аналитика производительности сопоставляет и анализирует показатели и события, собранные БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 10

в инфраструктуре, для выявления отклонений, прогнозирования сбоев и предоставления подробной диагностической информации. На рисунке 1 представлен пример коллектора событий системы BMC ProactiveNet 9.6. Рисунок 1 – Коллектор событий Данная система примечательна не только тем, что имеет заранее заготовленные Knowledge module для разных решений мониторинга, но и позволяет интегрировать в систему различные внештатные решения, разработанные под конкретную задачу и события из других систем мониторинга. Также, она имеет коллектор событий, в котором показаны все недавние аварии; встроенное представление состояния системы в реальном времени (далее – dashboard), на котором видно состояния каждого IT- или бизнес-сервиса; ресурсносервисную модель, на которой можно увидеть модель влияния каждого из элементов друг на друга в системе. На рисунке 2 представлен пример dashboard системы BMC ProactiveNet 9.6. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 11

Рисунок 2 – Dashboard BMC 1.1.3 Система мониторинга System Center Operations Manager (SCOM) System Center Operations Manager (SCOM) (ранее Microsoft Operations Manager, MOM) – программа компании Microsoft для управления и мониторинга IT-сервисов, приложений, серверов в гетерогенной среде Windows, UNIX и Linux. Продукт способен консолидировать информацию о функционировании различных компонентов IT-инфраструктуры, обеспечивая её обобщенное представление в единой консоли. Существуют инструменты для мониторинга различного системного и прикладного программного обеспечения, однако логика мониторинга может быть определена только самим администратором системы. SCOM предназначен главным образом для организации с числом компьютеров более 500 и числом серверов более 30. Для меньших организаций существует продукт System Center Essentials [2]. Operations Manager, компонент Microsoft System Center, позволяет отслеживать состояние задач, выполняемых на нескольких компьютерах, в одной консоли. Использование Operations Manager в среде организации упрощает мониторинг большого количества компьютеров, устройств, служб и приложений. Консоль управления, показанная на рисунке 3, позволяет проверить БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 12

работоспособность, производительность и доступность всех отслеживаемых объектов в среде, а также помогает обнаруживать и устранять проблемы. Рисунок 3 – Консоль управления Operations Manager Operations Manager уведомит, какие отслеживаемые объекты не работают, имеет возможность отправить оповещения при обнаружении проблем и предоставить информацию, которая поможет определить причину проблемы и возможные решения. Администратор устанавливает объекты мониторинга, выбирая компьютеры и устройства и импортируя пакеты управления, которые отслеживают определенные компоненты и приложения. На рисунке 4 представлен dashboard системы SCOM. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 13

Рисунок 4 – Dashboard SCOM 1.1.4 Система мониторинга DynaTrace DynaTrace – облачное решение для мониторинга, предназначенное для высокодинамичных сред контейнеров и кластеров. Оно позволяет оптимизировать развертывание контейнеров и выделение памяти с помощью данных об использовании, получаемых в режиме реального времени. Это решение способно автоматически выявлять проблемы приложений и инфраструктуры, обеспечивая автоматизированное задание базовых показателей, обобщение проблем и определение первопричин. Данное программное обеспечение решает следующие проблемы: 1) мониторинг реальных пользовательских данных, производительности приложений, инфраструктуры и облачных сред; 2) DynaTrace автоматически обнаруживает все зависимости приложений и отслеживает транзакции на всех уровнях; 1) решает проблемы с производительностью или доступностью, прежде чем они повлияют на клиентских устройствах. На рисунке 5 представлена работа программы DynaTrace. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 14

Рисунок 5 – Работа программы Dynatrace Программа DynaTrace используется в компании “Ростелеком“ исключительно для программистов (разработчиков). 1.2 Прикладной мониторинг Прикладной мониторинг необходим для сбора статистики о наличии определенных процессов, доступности портов и нескольких других решений. К такому мониторингу, например, относится: проверка наличия процесса, доступность/недоступность порта, проверка отклика сервера по протоколу ICMP (ping), выгрузка данных из баз данных по предоставленным командам SELECT, и последующий их анализ на соответствие. Также этот вид мониторинга позволяет проводить проверки доступности web-страниц, а также поиска контента на них. При невыполнении условий проверки будет создано аварийное событие, которое будет переправлено ответственным лицам. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 15

Этот вид мониторинга примечателен тем, что дает более показательную оценку работоспособности сервиса, и, обычно, события от прикладного мониторинга имеют намного больший приоритет. К примеру, если на сервере базы данных загруженность памяти достигает отметки в 90%, это не означает, что он недоступен. Но, если же этот сервер не будет доступен по ICMP, это даст весомые основания полагать, что в данный момент сервер неработоспособен. Обычно в системах, которые предоставляют системный мониторинг, также предоставляют и прикладной. BMC ProactiveNET 9.6 также может выполнять обе эти функции одновременно, так как имеет множество Knowledge Module, в том числе и для прикладного мониторинга. 1.3 Функциональный мониторинг Функциональный мониторинг – самый сложный для интеграции в системы и постановки их на контроль. При этом, сама разработка метода мониторинга весьма трудоемка, так как для него необходимо написать программу с определенной последовательностью действий. Функциональный мониторинг в общем случае воссоздает действия пользователя в каком-либо сервисе, чтобы проверить работоспособность его функционально – отсюда и пошло название. Такой вид мониторинга очень показателен, так как может засечь ошибки, которые невозможно выявить программно. К примеру, у пользователя может не отображаться кнопка на сайте, либо недоступно для скачивания какое-либо приложение, либо может не прогрузиться элемент. Для такой проверки пишется робот с определенной последовательностью шагов. Каждый шаг проверяет какой-либо элемент, и после положительного результата переходит к следующему этапу. Если на одном из шагов робот не смог выполнить действие, то он возвращает ошибку и появляется уведомление об ошибках в работе сервиса. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 16

Для такого вида мониторинга также есть различные системы, но в данной работе будет рассмотрена система функционального тестирования АТОМ. Она была создана сотрудником Ростелеком для выполнения операций функционального мониторинга, с последующей передачей состояния каждой площадки на dashboard. Рассмотрим принцип ее работы. Имеются площадки тестирования – серверы, на которых установлены клиенты АТОМ. На них запускаются с заданной периодичностью тесты определенного сервиса. Тесты состоят из шагов – упорядоченных действий, каждый из которых формирует «здоровье» сервиса. При невыполненном шаге тестирования остальные шаги пропускаются. «Здоровье» одной площадки тестирования формируется как среднее арифметическое успешно выполненных шагов от количества всех шагов в тесте. Далее идет расчет «здоровья» сервиса в целом. Он также рассчитывается как среднее арифметическое всех площадок тестирования, которые проверяют данный сервис. Далее показатель здоровья в виде цветового индикатора (зеленый – 100% «здоровье», желтый – 50%, красный – 0%, полная недоступность сервиса) выводится на dashboard АТОМ в соответствующий временной промежуток. На рисунке 6 представлен dashboard системы АТОМ. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 17

Рисунок 6 – Dashboard системы АТОМ Также, к преимуществам данной системы можно отнести легкое выяснение причины ошибки в тестировании. При возникновении неполадок, клиент АТОМ на площадке тестирования делает скриншот, и он сохраняется в базу данных системы. Далее это может быть применено для устранения ошибки в работе контролируемой системы, теста или же в работе самой площадки функционального тестирования. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 18

1.4 Принцип работы системы мониторинга BMC Proactive NET 9.6 Для ознакомления с принципом работы системы ознакомимся с рисунком 7. Рисунок 7 – Принцип работы системы мониторинга BMC ProactiveNet 9.6 Исходя из рисунка 7, мы видим, что существует агентский мониторинг, безагентский мониторинг, синтетический мониторинг. Каждый из этих вариант подразумевает различные подходы к сбору данных, необходимых для составления метрики, которая будет отобрать работоспособность сервиса. Рассмотрим подробнее каждый из подходов. Агентский мониторинг – для такого вида мониторинга необходимо подготовить пакет инсталляции с необходимыми по техническому заданию модулями (агент мониторинга). Агент устанавливается на целевой сервер, где в фоновом режиме собирает данные о всех процессах, которые были указаны модулями. Далее эти данные отправляются на сервер интеграции, после чего переправляются на ProactiveNet сервер. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 19

Безагентский мониторинг – в этом случае в агенте мониторинга нет необходимости, сервер системы мониторинга самостоятельно опрашивает целевой сервер, после чего получает необходимые данные для создания метрики. Синтетический мониторинг – это функциональный мониторинг, предоставленный компанией BMC. Работает по тому же принципу, что и система АТОМ – заранее написанные программы проверок (робот) выполняют ряд действий, который симулируют действия пользователя. По сравнению с описанной ранее системой функционального мониторинга, коррелирует не с таким большим количеством методов проверок, а также имеет более неудобный dashboard. Рассмотрим общий вариант постановки площадки на мониторинг. Вначале идет договоренность между заказчиком мониторинга (администратор сервиса) и отдела мониторинга. На этом этапе обговариваются параметры, которые должны состоять на мониторинге. Также на этом этапе решается, какой из видов мониторинга (или их совокупности) будет инсталлирован. После того, как будут обговорены общие аспекты метрик, которые будут собираться, составляется карточка мониторинга. Карточка мониторинга – техническое задание на постановку IT-сервиса на мониторинг с указанием всей информации об IT-сервисе, объектах мониторинга, контролируемых параметрах, списках оповещений и ресурсно-сервисной моделью. На рисунке 8 представлен пример карточки мониторинга. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 20

Рисунок 8 – Карточка мониторинга Далее идет непосредственно постановка на мониторинг. Для того, чтобы сервер мог отсылать данные серверу-ядру системы мониторинга, на площадку необходимо инсталлировать агента мониторинга. После инсталляции, необходимо создать политику, по которой будет опрашиваться площадка. В этой политике прописаны метрики, которые будут собираться, с какой частотой, а также самая важная часть – threshold и оповещение на ответственных лиц. Threshold – это пороги срабатывания, после пересечения которых метрикой будет вызвано определенное событие: 1) INFO – событие информативное, используется в общем случае для оповещения об успешной итерации, инсталляции и так далее; БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 21

2) Warning – также информативное событие, но оно уже несет в себе предупреждение; 3) Minor – аварийное событие с самым низким приоритетом, означает, что какая-то метрика незначительно превысила допустимый порог, либо произошла какая-то авария, которая возможно затронет сервис; 4) Major – аварийное событие с средним приоритетом, означает частичную недоступность сервиса (зависания, недоступность некоторых элементов); 5) Critical – аварийное событие с высоким приоритетом, означает либо полную недоступность сервиса, либо сильное отклонение метрики от ее заданного параметра. При настройке возможно выбрать любое количество необходимых порогов срабатывания. При этом, каждое событие, открытое превышением графика контролируемого процесса по определенному порогу, будет уникальным, поэтому его можно будет однозначно определить, к примеру, для настройки нотификации. Нотификация – ключевой параметр системы мониторинга, поскольку именно он определяет ее как систему для оповещения ответственных лиц, которые должны следить за ее работоспособностью. У каждого события есть определенный ряд параметров, по которым его можно однозначно определить. Это может быть как критичность события (уровень порога, который превысил график контролируемого процесса), так и название контролируемого сервиса, hostname сервера, название самого контролируемого процесса (загрузка процессора, количество свободного места на диске, к примеру) и многое другое. По ним создается политика нотификации, в которой прописано, кому именно будет отправлено данное событие. Для этого существует специальные конфигурационные файлы, в которые прописываются контакты ответственных лиц. Сначала создаются группы рассылки – e-mail или sms. Далее в эти группы добавляются контакты. После этого в конфигурационном файле политики нотификации прописывается, на какое БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 22

событие должна среагировать политика, и какой группе рассылки переслать сообщение об аварии. 1.5 Обзор технологии SNMP-ловушек SNMP (англ. Simple Network Management Protocol – простой протокол сетевого управления) – это стандартный интернет-протокол для управления устройствами в IP-сетях на основе архитектур TCP/UDP. Устройства с поддержкой SNMP включают в себя маршрутизаторы, коммутаторы, серверы, рабочие станции, принтеры, модемные стойки и другие. Протокол обычно используется в системе управления сетью. SNMP определен Инженерным советом Интернета (IETF) как компонент TCP/IP. Он состоит из набора стандартов для управления сетью, включая протокол прикладного уровня. SNMP-traps (SNMP-ловушки) – это особый широковещательный UDP пакет, отправляемый удаленным устройством с поддержкой протокола SNMP. Подобные сообщения оповещают администратора о ошибке в функционировании устройства. Включает в себя текущее значение sysUpTime, OID, определяющий тип trap (ловушки), и необязательные связанные переменные. Адресация получателя для ловушек определяется с помощью переменных trap-конфигурации. В данной главе были рассмотрены основные виды мониторинга, программы для обеспечения мониторинга IT-систем и IT-сервисов, принцип работы системы мониторинга BMC ProactiveNet 9.6, а также выполнен обзор технологий SNMPловушек. Весь мониторинг можно условно поделить на системный, прикладной, функциональный. Каждый из этих видов контролирует различные области системы, что позволяет в полной мере следить за ее работоспособностью. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 23

1.6 Обоснование необходимости мониторинга Департамент ситуационного реагирования и аналитики состоит из 4 отделов: 1) отдел мониторинга; 2) отдел аналитики; 3) первая линия (техподдержка внутренних пользователей); 4) отдел доступов. В рамках данной работы будет рассмотрено проектное решение для решения проблемы недоступности ключевых сервисов отдела техподдержки. Предложено: 1) добавить серверы, необходимые для реализации мониторинга; 2) заменить текущие коммутатор и источник бесперебойного питания; 3) поставить на мониторинг серверы систем САСП и База Знаний. Работоспособность отдела техподдержки напрямую зависит от функционирования основных программ, необходимых им для выполнения ряда задач. Это САСП – программа, показывающая текущие задачи для выполнения, а также их статус, и База Знаний – это база данных о возможных решениях определенных задач, шаблонов, информации о различных системах и их работе, отделах и так далее. При недоступности хотя бы одного из этих приложений функциональность отдела техподдержки существенно снизится. Мониторинг данных систем позволит не только оперативно реагировать на всевозможные аварии и ошибки, но и собирать статистику об использовании отдельных элементов, графики загруженности серверных компонентов, времени дня, в которое нагрузка наиболее большая. При таком подходе возможно значительное увеличение времени безаварийной работы. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 24

2 Выбор программного обеспечения и оборудования Для предлагаемого проектного решения необходимо выбрать соответствующее оборудование, а именно: программное обеспечение – систему мониторинга, с помощью которой будет производиться отслеживание работы системы и сбор данных, сервер системы мониторинга, на который будет установлено соответствующее программное обеспечение, коммутатор второго уровня для мониторинга UDP пакетов (SNMP-ловушки), а также источник бесперебойного питания для мониторинга состояния питания элементов системы. 2.1 Выбор программного обеспечения В качестве основной системы мониторинга была выбрана BMC Proactive NET 9.6, так как дежурная смена и администраторы системы уже ознакомлены с ней, а также она имеет множество преимуществ, которые были описаны ранее. Эта система уже внедрена в большое количество IT-сервисов компании Ростелеком и собирает статистику о работе ключевых сегментов. Таким образом, постановка на мониторинг систем САСП и Базы Знаний добавит две новые системы в каталог уже существующих, и сложность наблюдения за состояниям данными системами, как и сложность в их обслуживании заметно снизится для дежурной смены, администраторов сети и разработчиков приложений. 2.1.1 Архитектура системы мониторинга Для того, чтобы все компоненты системы мониторинга могли быть использованы, необходимы серверы, выполняющие определенные роли. Архитектура системы представлена на рисунке 9. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 25

Рисунок 9 – Архитектура BMC Подробнее рассмотрим каждый элемент представленной схемы. Слева представлена серверная составляющая. Она состоит из нескольких частей – сам сервер системы мониторинга, его репозиторий и центральная консоль администрирования, с которой производится управление системой. Репозиторий – это хранилище для набора компонентов мониторинга, которые включены в ProactiveNet-сервер. В репозитории хранятся собранные индивидуально для каждой системы пакеты – агенты мониторинга, которые при последующей инсталляции на целевой сервер начинают собирать данные о его работе. На агента мониторинга можно поставить различные модули мониторинга, то есть указать, какие данные должны собираться: данные производительности операционной системы, данные о каком-либо конкретном программном обеспечении, серверные роли, производить удаленный мониторинг и так далее. Это позволяет подобрать оптимальную сборку для любой задачи, которая встает на стадии планирования наблюдения за работой сервера. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 26

BMC ProactiveNet сервер необходим для сбора пакетов (агентов мониторинга) и дальнейшего их распространения. Также служит web-интерфейсом для операторов и администраторов системы мониторинга. Система имеет три пользовательских консоли: 1) Pw commands – командная консоль; 2) Administration – консоль администрирования системы, ее программное обеспечение подключается к ProactiveNet серверу и служит для его настройки; 3) Operations/LSO – консоль оператора. Она расположена внутри webинтерфейса внутри ProactiveNet сервера. Это консоль, в которой работают операторы системы мониторинга, также в ней приведены все события, влияющие на контролируемые устройства, метрики. Консоль операторов системы мониторинга имеет коллектор событий, в котором отображаются все аварийные события. Также в нем показан статус этих событий – они открыты (проблема актуальна на сервере действительно имеются проблемы), ознакомлены (с проблемой ознакомился оператор и оповестил о ней ответственных лиц, если этого не сделала система нотификаций), закрыты (проблема была решена). На рисунке 10 показана консоль оператора. Рисунок 10 – Консоль оператора БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 27

Также, в этой консоли есть возможность просмотреть активных агентов мониторинга (вкладка Devices), а также ресурсно-сервисные модели всех сервисов, поставленных на мониторинг (вкладка Services). На агентах мониторинга можно увидеть все графики состояния, собираемые ими. Консоль для администраторов позволяет полностью конфигурировать системы сбора информации, пороги критичности, добавлять и удалять агентов мониторинга и многое другое. Доступ к ней предоставляется отдельно, так что у операторов системы нет доступа к конфигурациям сервисов, поставленных на мониторинг. На рисунке 11 представлена консоль администратора. Рисунок 11 – Консоль администратора На рисунке 11 на данный момент показаны групповые политики сервисов, поставленных на мониторинг. Каждая политика по определенным параметрам (соответствие по hostname сервера, тэгу, ip-адресу и так далее) применяется к агентам мониторинга. После этого их можно сконфигурировать по своему усмотрению. Во вкладке «Servers» показаны серверы, на которых в данный момент установлены агенты мониторинга. Также там отображаются их статусы: отключен БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 28

или подключен. При нескольких серверах интеграции возможно переназначать место отправление собранных данных агентами, переустанавливать агентов мониторинга для обновления модулей, по которым собираются данные и тому подобное. Вкладка «Repository» открывает вкладку с репозиторием сервера ProactiveNet. В нем находятся сконфигурированные пакеты инсталляции, которые можно при желании изменить по своему усмотрению. Publishing server – это компонент, осуществляющий публикацию ресурсносервисных моделей систем, поставленных на мониторинг, из других продуктов. В данном случае, это BMC CMDB Atrium. Self-monitoring server является очень важным элементом системы мониторинга. Это сервис самомониторинга, который контролирует свои процессы и сигнализирует о неисправностях, которые возникают в компонентах системы. Без этого элемента, при аварии в самой системе мониторинга невозможно было бы понять ее причину. Также это помогает увеличить время бесперебойной работы системы, так как сервер предупреждает о возможных ошибках, которые могут произойти в будущем, анализируя графики процессов. Administration cell и Server Cell – это программные компоненты, их функция состоит в том, что они позволяют обрабатывать события, которые возникают в системе, хранят динамические данные, политики обработки этих событий, настройки по обработке, ресурсно-сервисные модели и так далее. С правой стороны схемы показана контролируемая системой мониторинга структура. При установке на целевой сервер (Remote Server) агента мониторинга (PATROL Agent), начинают собираться данные, которые были настроены политикой обработки. Название агента PATROL является таким, потому что это отдельный продукт компании BMC, изначально разработанный не для этой системы. Но так как он был многофункционален и предоставлял больше простора для выбора контролируемых процессов, он был добавлен в данную систему. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 29

Исходя из вышесказанного, для обеспечения функциональности необходим сервер, позволяющий интегрировать этот продукт в систему – Integration Server. 2.2 Выбор оборудования Исходя из предлагаемого проектного решения, изложенного ранее, необходимо выбрать коммутатор второго уровня и источник бесперебойного питания для того, чтобы можно было организовать мониторинг. С предыдущим оборудованием нет возможности организовать мониторинг SNMP-ловушек и режима питания оборудования, что может привести к несвоевременному информированию ответственных как о критичных ошибках, так и состояния, предшествующему ему. Также необходимо выбрать серверы для организации системы мониторинга, под заданные технические требования каждого из компонентов. 2.2.1 Выбор коммутатора В рамках текущего технического проекта нужно заменить устаревший коммутатор на более современный. Он должен быть второго уровня, иметь 24 медных порта и 4 1G SFP или 10G SFP+ специальных порта. Коммутатор уровня 2 (Layer2 или L2) предназначен для соединения нескольких устройств локальной вычислительной сети (LAN) или нескольких сегментов данной сети. Коммутатор уровня 2 обрабатывает и регистрирует МАСадреса поступающих фреймов, осуществляет физическую адресацию и управления потоком данных (VLAN, мультикаст фильтрация, QoS). Уровень 2 обеспечивает прямую передачу данных между двумя устройствами в локальной сети. При работе коммутатор уровня 2 сохраняет таблицу MAC-адресов, в которой обрабатываются и регистрируются MAC-адреса поступающих фреймов и запоминается оборудование, подключаемое через порт. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 30

Массивы данных переключаются в MAC-адресах только внутри локальной сети, что позволяет сохранять данные только в пределах сети. При использовании коммутатора уровня 2 возможно выбрать определенные порты коммутатора для управления потоком данных (VLAN). Порты, в свою очередь, находятся в разных подсетях уровня 3. Для решения данной задачи был выбран коммутатор FS S3900-24T4S. Он показан на рисунке 12. Рисунок 12 – Коммутатор FS S3900-24T4S Данный коммутатор – это усовершенствованный гигабитный стекируемый коммутатор Layer 2 Plus (Layer 3 Lite) с восходящей линией связи 1/10Gb, поддерживает возможность стекирования с возможностью подключения 1 и 10 Gigabit и улучшенным QoS на границе сети. Технические характеристики коммутатора FS S3900-24T4S представлены в таблице 1. Таблица 1 – Технические характеристики коммутатора FS S3900-24T4S Интерфейсы 24x 10/100/1000BASE-T RJ45, 4x 10G SFP+ Тип уровня Уровень 2+ БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 31

Окончание таблицы 1 Макс. 10G Интерфейсы Коммутационная способность 4 Макс. 1G Интерфейсы Таблица MACадресов Скорость переадресации Количество VLAN 28 16K 128 Gbps 95 Mpps 4K Jumbo-фреймы 9KB MTBF (Часы) >100,000 Flash-память Память пакетного буфера 64MB RAM 128MB 1.5MB Емкость DDRIII 512MB Штабелирования До 6 Единиц (Те же модели) Макс. потребляемая мощность 21W Устройство питания 2x Источники питания - Внутренние Входное напряжение 100-240VAC, 50-60Hz, 0.8A Воздушный поток Безвентиляторный Акустический шум 0dB Методы аутентификации 802.1X, AAA Протокол удаленного управления SNMP, RMON, HTTP, Telnet, SSH Размеры (Ш х Г х В) 1.73''x11.02''x17.05'' (44x280x440mm) Вес 9.41 lbs (4.27кг) 32°F ~ 122°F (0º ~ 50ºC) Температура хранения -40°F ~ 158°F (-40º ~ 70ºC) 5% ~ 90% (Без конденсата) Влажность Хранения 10% ~ 90% (Без конденсата) Индикаторы состояния System, LINK activity, PWR Гарантия 4 Года Тип корпуса Монтируемые в стойку Монтажный комплект Включены Диапазон рабочих температур Диапазон рабочей влажности БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 32

2.2.2 Выбор серверов мониторинга Как было написано ранее, для организации системы мониторинга необходимо выбрать серверы согласно их рекомендуемым техническим требованиям. Всего необходимо подобрать 4 сервера согласно их ролям, а именно: 1) ProactiveNet server; 2) Integration server; 3) Publishing server; 4) Database server. Исходя из приложения А, и того, что система мониторинга будет развернута для не более чем 100 агентов мониторинга, будет выбрана Минимальная» конфигурация. Используя данные из приложения А, выберем соответствующие серверы для каждого элемента системы мониторинга. За основу будет взят сервер HPE ProLiant dl20 Gen10 (1U). Он показан на рисунке 13. Для разных серверов системы мониторинга он будет сконфигурирован различно. Рисунок 13 – Сервер HPE ProLiant dl20 Gen10 (1U) Так, для ProactiveNet сервера необходим четырехъядерный процессор, 8 Gb оперативной памяти и 100 Gb дискового пространства. Для Integration сервера необходим двухъядерный процессор, 2 Gb оперативной памяти и 30 Gb дискового пространства. Для Publishing сервера (Atrium CMDB) необходим четырехъядерный процессор, 8 Gb оперативной памяти и 100 Gb дискового пространства. Для БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 33

Database сервера необходим четырехъядерный процессор, 16 Gb оперативной памяти и 170 Gb дискового пространства. 2.2.3 Расчет и выбор источника бесперебойного питания Для бесперебойного питания оборудования шкафа необходим источник бесперебойного питания, который будет поддерживать систему в рабочем состоянии в случае аварии не менее чем на 15 минут. Также необходимо, чтобы в комплект источника бесперебойного питания входила SNMP-карта – это необходимо для того, чтобы он мог отправлять ошибки в режиме питания устройств. Для того, чтобы рассчитать необходимую емкость источника бесперебойного питания, воспользуемся следующей формулой: 𝐴ℎ = 100 ∗ 𝑡 ∗ 𝑊, (1) где Ah – емкость источника бесперебойного питания, t – расчетное время бесперебойной работы, W – максимальное потребление. Время автономной работы выражается в часах, емкость источника бесперебойного питания измеряется в А ∙ ч, а мощность нагрузки в киловаттах. Суммарная мощность всех устройств составляет 350 Вт, то есть 0,35 кВт. Необходимое минимальное время работы – 15 минут, то есть 0,25 часа. Подставим данные значения в формулу 1: 100 ∗ 0,25 ∗ 0,35 = 8,75 А ∙ ч Значит, нам необходим источник бесперебойного питания с емкостью не менее 8,75 А ∙ ч. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 34

Тогда в качестве источника бесперебойного питания выбираем ИБП APC Smart-UPS SMT1500RMI2U, 1500ВA. Имеет аккумулятор емкостью 9 А ∙ ч, типоразмер 2U. Он представлен на рисунке 14. Рисунок 14 – ИБП APC Smart-UPS SMT1500RMI2U, 1500ВA Для расчета времени, которое проработает данный источник бесперебойного питания, воспользуемся формулой 1. Подставляя значение емкости источника бесперебойного питания в формулу 2, получим: 𝑡= 𝐴ℎ , 100 ∗ 𝑊 (2) 9А∙ч = 0,26 ч. 100 ∗ 0,35 кВт В результате работа источника бесперебойного питания в автономном режиме будет 0,26 часа, что равно 15,6 минутам. В данной главе был выполнен выбор оборудования и программного обеспечения для проектирования мониторинга для систем САСП и База Знаний, а также представлена архитектура системы мониторинга BMC ProactiveNet 9.6, БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 35

которая была выбрана как основная программа для контроля работоспособности систем. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 36

3 Установка компонентов системы и постановка на мониторинг Для постановки сервисов САСП и База Знаний на системный мониторинг необходимо добавить серверы системы мониторинга в шкаф, а также заменить коммутатор и источник бесперебойного питания в шкафу. Изначально заменим источник бесперебойного питания на ИБП APC SmartUPS SMT1500RMI2U, 1500ВA. Он имеет типоразмер 2U, элементы для крепления в стойку приложены в комплекте. Устанавливаем его в нижнюю часть шкафа для повышения его устойчивости. Далее добавляем четыре сервера мониторинга, которые были заранее сконфигурированы под цели компонентов мониторинга. Они имеют типоразмер 1U, элементы для крепления в стойку поставляются в комплекте. Устанавливаем их в свободные места в шкафу. После этого заменяем устаревший коммутатор и заменяем его на коммутатор FS S3900-24T4S. Предыдущие подключения к коммутатору подключаем в нынешний, также в него будут подключены серверы мониторинга. Непосредственно постановка на мониторинг режима питания источника бесперебойного питания, SNMP-ловушек, а также серверов систем САСП и База Знаний. Она проходит в несколько этапов. 3.1 Создание агента мониторинга Изначально, исходя из требуемых по карточке мониторинга параметров, которые будут состоять на мониторинге, создадим агента мониторинга. Для этого заходим на web-страницу ProactiveNet сервера. Она показана на рисунке 15. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 37

Рисунок 15 – Web-страница ProactiveNet сервера Далее создаем непосредственно агента мониторинга. Для этого переходим в «Создать новый пакет инсталляции». По техническому заданию, взятому из карточки мониторинга, нам необходимы модули для контроля системных ресурсов сервера, таких как: процент использования процессора, процент использования оперативной памяти, количество свободного дискового пространства. За это отвечает модуль «Unix and Linux – HP-UX and Linux». Также необходим модуль для мониторинга доступности по команде ping. За это отвечает модуль «Light weight protocol». Модуль «Patrol agent for Unix» необходим для того, чтобы программа сбора метрик (агент мониторинга) была постоянно запущена в фоновом режиме. Эти модули будут добавлены в пакет инсталляции, впоследствии установленный на целевые серверы. На рисунке 16 показаны выбранные модули. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 38

Рисунок 16 – Список выбранных модулей, необходимых для агента мониторинга После этого необходимо указать директорию, в которую будет установлен агент мониторинга. По умолчанию это /opt/bmc/. Необходимо учитывать, что при инсталляции данная папка не создается автоматически. Для корректной работы агента мониторинга ему необходим пользователь, под учетной записью которого он будет посылать данные на сервер интеграции. Далее открывается диалоговое окно, в котором предлагается ввести логин и пароль, под которым будет работать агент мониторинга. Ему необходим пользователь с администраторскими правами. Следующим шагом необходимо выбрать номер порта, который будет использовать агент мониторинга для коммуникации с консолью. Здесь следует указать порт, на который была настроена конфигурация оборудования ранее. На рисунке 17 показано окно выбора порта. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 39

Рисунок 17 – Выбор порта для коммуникации с консолью Далее следует настройка коммуникации с Integration сервером. В первом поле, «INTEGRATIONSERVICES Variable» указывается действующий адрес Integration сервера. В следующем поле «Central Monitoring Administration Tag(s)» указывается тег, который будет присвоен установленному на сервер агенту мониторинга. С помощью него можно сделать агента мониторинга специально для отельной системы, и, позже, по нему легко собрать их в единую ресурсносервисную модель. На рисунке 18 – настройка коммутации с Integration сервером. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 40

Рисунок 18 – Настройка коммутации с Integration сервером Заключительным этапом является название для агента мониторинга, выбор его расширения, а также выбора – сохранить его в память рабочего компьютера, с которого был осуществлен доступ к web-странице ProactiveNet сервера, либо сохранить его в репозиторий системы мониторинга. При выборе опции «Сохранить», пакет инсталляции невозможно будет в дальнейшем конфигурировать и он будет удален из памяти ProactiveNet сервера. При выборе опции «Сохранить в репозиторий», возможно будет изменять его параметры, к примеру, можно будет добавить дополнительные модули мониторинга для сбора метрик, изменить назначенный тэг и так далее. На рисунке 19 мы можем наблюдать заключительный этап создания агента мониторинга. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 41

Рисунок 19 – Заключительный этап создания агента мониторинга 3.2 Подготовка серверов к постановке на мониторинг и установка агентов мониторинга Для корректной работы агента мониторинга на целевом сервере необходимо произвести подготовительные мероприятия. Они будут разниться от выбора портов, имен серверов мониторинга, выбора оборудования для серверов мониторинга. Рассмотрим общий случай: 1) на сервере должен быть создан пользователь с администраторскими правами, логин и пароль должны совпадать с таковыми в конфигурации пакета инсталляции; 2) должны быть открыты порты, по которым агент обращается к Integration серверу и ProactiveNet серверу; БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 42

3) необходимо вручную создать папку «/opt/bmc/», в нее агент будет устанавливать свои компоненты; 4) пользователь должен получить права на запись, чтение и редактирование данной папки; 5) в файл «/etc/hosts/» необходимо прописать соответствие ip-адреса и hostname сервера, так как агент берет информацию именно оттуда. После выполнения всех предшествующих условий, можно приступать к инсталляции агента мониторинга. Порядок действий следующий: 1) загружается пакет инсталляции с репозитория либо с памяти устройства (в зависимости от того, куда он был сохранен); 2) пакет инсталляции копируется в папку пользователя, созданного ранее; 3) запускается приложение инсталляции. После завершения установки агент будет показан в администраторской консоли как активный. Если этого не произошло, возможно, были совершены ошибки в предыдущих шагах – конфигурировании инсталляционного пакета либо в подготовительных мероприятиях. 3.3 Создание политики проверки После того, как агенты были успешно установлены на целевые серверы, можно приступать к созданию политики проверки. Для этого заходим в консоль администратора и нажимаем «Создать новую политику». На рисунке 20 показано начальное окно создания политики проверки. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 43

Рисунок 20 – Создание политики В этом окне есть поле «Name» – имя политики, «Description» – описание политики, а также поле «Precedence» – это порядок политики в иерархии. Политика с числом ниже будет обрабатываться в первую очередь по сравнению с политикой с высшим числом. Также сразу нажимаем «Enable policy» – если этого не сделать, то политика будет неактивной. Следующим шагом необходимо указать политике, на какие серверы она должна распространяться. Это можно сделать в следующем окне, которое представлено на рисунке 21. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 44

Рисунок 21 – Окно выбора серверов В данном окне необходимо указать параметр, по которому будут отбираться серверы, на которые будет действовать политика. Если при создании пакета инсталляции был указан тэг, то есть возможность по отобрать серверы только лишь по нему. Намного труднее дело обстоит, когда тэг не был указан – тогда собрать все серверы в одну политику можно лишь по hostname. Так как при создании пакета инсталляции был указан тэг, вводим его в поле «Condition Editor». Далее необходимо выбрать, какие данные будут собираться. Для этого в следующем окне выбираем модули, которые были указаны при конфигурировании пакета инсталляции. На рисунке 22 показано окно для настройки модулей. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 45

Рисунок 22 – Выбор собираемых данных На рисунке 22 видно, что на данный момент выбран модуль «Unix and Linux – HP-UX and Linux». Он включает в себя необходимые проверки процессора, дискового пространства, оперативной памяти, а также Swap. Также нам понадобится добавить модуль «Light Weight Protocols», чтобы организовать проверку по команде ping. Следующим шагом будет установка порогов срабатывания для метрик, которые будут собираться с помощью политики. Для этого, в следующем окне, БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 46

выберем интересующий нас модуль, в нем выберем проверку, и настроим вид критичности: MINOR, MAJOR или CRITICAL. Это можно увидеть на рисунке 23. Рисунок 23 – Выбор порогов срабатывания аварийных событий В данный момент на рисунке 24 можно увидеть, что выбран параметр «CPU Usage» – использование процессора. Установлена критичность Minor, длительность – 5 минут. Длительность – важный параметр системы, так как она работает по следующему принципу: один раз в заданную длительность выполняется проверка указанного параметра. При провале проверки аварийное событие не генерируется. Оно создается только после второй проваленной подряд проверки. Также это работает и с закрытием события – после двух успешных проверок система считает работоспособность восстановленной. «Comparsion» – это параметр, который определяет, будет ли событие генерироваться при превышении заданной линии на графике, или же, наоборот, при ее снижении. Выставим условие как «больше». «Threshold» – это значение, после превышения или понижения которого сработает аварийное событие. После настройки данного параметра БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 47

настроим остальные согласно техническому заданию, взятому из карточки мониторинга. После этого достаточно проверить окно подключенных агентов к политике, чтобы убедиться, что политика успешно на них применилась. Для того, чтобы убедиться, что данные настройки – модули проверок и пороги срабатывания настроены правильно, зайдем в консоль оператора. Введем в поисковую строку название сервера, который находится под влиянием политики. Это показано на рисунке 24. Рисунок 24 – Параметры проверок на сервере Как видно на рисунке 24, сервер виден в списке устройств, и политика применилась к нему корректно. Все необходимы модули состоят на мониторинге. 3.4 Создание ресурсно-сервисной модели Для того, чтобы операторы системы мониторинга всегда имели представление о состоянии сервиса в режиме реального времени, а также, чтобы видеть иерархию серверов, необходимо создать ресурсно-сервисную модель. В БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 48

общем случае это логическая схема системы, в которой видно их влияния друг на друга. Для этого воспользуемся BMC CMDB Atrium. Это программное обеспечение как раз для того, чтобы создавать ресурсно-сервисные модели для системы BMC ProactiveNet, с последующей их выгрузкой на Publishing сервер. На рисунке 25 показаны элементы ресурсно-сервисной модели. Рисунок 25 – Логические элементы BMC CMDB Atrium Откроем BMC CMDB Atrium. В нем представлено пространство для создания ресурсно-сервисной модели – «Impact Model Designer». Это пространство предлагает нам создание из логических элементов, каждый из которых отвечает за свою роль. Рассмотрим некоторые из них, которые будут задействованы в данной работе: БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 49

1) Business service – это элемент, создание которого добавит эту ресурсносервисную модель в консоль оператора, является высшим в иерархии; 2) Computer – физический сервер, на нем будут указано состояние сервера согласно системному мониторингу; 3) Logical Component – логический компонент, который не привязан ни к какому из серверов. Может служить перенаправляющим звеном – с помощью переназначения событий, вместо того, чтобы создаваться на сервере, они будут указываться как события на логической единице. Это очень полезно при создании сложных схем, либо переназначения более критичного события на логический элемент, который выше по иерархии, чтобы он имел большее влияние на сервис. Следующим шагом будет создание из данных элементов ресурсно-сервисной модели. Для этого необходимо создать столько же элементов «Computer», сколько серверов в системе. После этого их необходимо настроить, чтобы агент мониторинга мог присоединиться к логическому элементу по заданным параметрам. Такие параметры называются «Alias» – когда агент успешно устанавливается на сервер, он создается Alias, название которого он берет из файла «/etc/hosts/». Таким образом, связать сервер и логический компонент легче всего по hostname сервера, хотя это и не единственный способ. К примеру, можно указать Alias при инсталляции агента мониторинга, и точно такой же на логическом компоненте. На рисунке 26 показана настройка параметров логического компонента ресурсно-сервисной модели. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 50

Рисунок 26 – Настройка параметров логического компонента После настройки всех элементов, их необходимо соединить с логическим компонентом «Business Service». Таким образом, они преобразуются в ресурсносервисную модель, которая при выполнении публикации выгрузится в ProactiveNet сервер и будет доступна для просмотра в консоли оператора. Выполненные ресурсно-сервисные модели представлены в приложении В и приложении Г. 3.5 Мониторинг ошибок в работе оборудования с помощью SMNPловушек Для бесперебойной работы оборудования, в частности, коммутатора и источника бесперебойного питания, необходимо своевременно получить от них оповещения об ошибках в их работе. Для этого воспользуемся SMNP-ловушками, которые будут отправляться на ProactiveNet сервер. После получения SNMPловушки генерируется аварийное событие, в котором содержится информация об БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 51

ошибке. Это событие поступает в коллектор событий и пересылается на группы рассылки ответственных лиц. 3.6 Расчет экономической эффективности Для того, чтобы рассчитать экономическую эффективность от данного проектного решения, воспользуемся формулой 3: 𝑀= 𝑃 , 𝐸∙𝐴∙ℎ (3) где M – количество месяцев до полной окупаемости проектного решения, P – полная стоимость, затраченная на оборудование, E – количество сотрудников, которых затронет данное проектное решение, А – расчетная почасовая ставка сотрудника, h – количество часов в месяц, которое сэкономит данное проектное решение для каждого сотрудника. На данный момент в отделе технической поддержки внутренних пользователей работает 15 человек. Расчетная ставка равна 130 рублей в час. Чтобы получить количество часов в месяц, которое сэкономит данное проектное решение для каждого сотрудника, необходимо перевести расчетное увеличение доступности сервисов, ожидаемое от проектного решения, в часы. Расчетное увеличение доступности сервисов – 15%. Расчет будем вести от рабочего времени в часах за месяц. За апрель 2020 года было отработано 176 часов. Значит, количество сэкономленных часов будет составлять: 176 ∙ 0,15 = 26,4 БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 52

Постановка на мониторинг сервисов Базы Знаний и САСП расчетно увеличит время их безотказной работы на 26,4 часов рабочего времени в месяц. Подставляя эти значения в формулу 3, получим: 420522 = 8,2 15 ∙ 130 ∙ 26,4 Из данной формулы мы можем сделать вывод, что данное проектное решение полностью окупится через 8,2 месяцев. В данной главе была выполнена замена коммутатора и источника бесперебойного питания, установка серверов для системы мониторинга BMC ProactiveNet 9.6, постановка на мониторинг систем САСП и База Знаний, а также расчет экономической эффективности введения проектного решения. В результате было выявлено, что полная окупаемость составляет 8,2 месяцев. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 53

ЗАКЛЮЧЕНИЕ Результатом выполнения дипломной работы является проектирование и постановка на мониторинг корпоративной сети Департамента ситуационного реагирования и аналитики ПАО «Ростелеком». Потребность в замене оборудования и постановке серверов сервисов Базы Знаний и САСП была обусловлена следующими причинами: 1) необходимость в замене устаревшего оборудования; 2) потребность в увеличении пропускной способности коммутатора; 3) потребность в контроле состояния оборудования; 4) потребность в увеличении емкости источника бесперебойного питания; 5) потребность в увеличении времени бесперебойной работы сервисов, критичных для работы отдела технической поддержки. Были изучены основные виды мониторинга, системы мониторинга, технология SNMP-ловушек. Также был получен опыт в проектировании корпоративной сети, системы мониторинга, постановки важных для бизнеса систем на мониторинг. Был осуществлен анализ оборудования, программного обеспечения для постановки на контроль серверов IT-систем и IT-сервисов. В результате расчета экономической эффективности данного проектного решения было выяснено, что оно полностью окупится спустя 8,2 месяцев. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 54

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 1 BMC ProactiveNet 9.6 документация [Электронный ресурс]. – Режим доступа: https://docs.bmc.com/docs/display/public/proactivenet96/Home?key=proactivenet96. – Загл. с экрана. 2 SCOM [Электронный ресурс]. – Режим доступа: https://ru.wikipedia.org/wiki/System_Center_Operations_Manager. – Загл. с экрана. 3 Потемкин С. А. Формирование системы финансового мониторинга в кредитных организациях. Учебное пособие / Потемкин С. А. – М.: Кнорус. 2010. 4 Гаранин М.В. Системы и сети передачи информации / М.В. Гаранин и др. – М.: Радио и связь, 2001. 5 Построение СКС [Электронный ресурс]. – Режим доступа: http://www.xnets.ru/plugins/content/content.php?content.96.2. – Загл. с экрана. 6 Электронный каталог HP Proliant [Электронный ресурс]. – Режим доступа: https://www.proliant.ru/catalog/. – Загл. с экрана. 7 Прокимнов Н. Н. Моделирование мониторинговых процессов. Прикладная информатика / Прокимнов Н. Н. – М. : Издательство «Синергия», 2010. 8 Бариленко В.И. Информационно-аналитические методы оценки и мониторинга эффективности инновационных проектов / Под ред. проф. В.И. Бариленко ; В.И. Бариленко, В.В. Бердников, О.Ю. Гавель, Ч.В. Керимова. – М. : Издательство «Русайнс», 2015. БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 55

ПРИЛОЖЕНИЕ А (обязательное) Технические требования для серверов мониторинга Таблица А.1 – Технические требования для серверов мониторинга Оперативная память Процессор Элементы системы мониторинга Жесткий диск min med max min med max min med max ProactiveNet Server 4 4 8(16) 8 32 48 100 200 400 Remedy SSO 2 2 2 2 2 2 10 10 10 TS Presentation Server 4 4 8(16) 8 32 48 100 200 400 4 4 8 16 32 48 200 300 600 4 4 8 16 24 40 30 50 100 2 4 8 2 8 40 30 Oracle DB for TSIM Server 4 4 8 16 32 32 170 250 500 Atrium ARS + CMDB 4 4 8(16) 8 32 48 100 200 400 TS Infrastructure Management Server with SAP SQL Anywhere EBF TS Infrastructure Management Server with Oracle TS Integration Service Server (Proxy) на 500 и 900 агентов БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 56

ПРИЛОЖЕНИЕ Б (обязательное) Спецификация оборудования Таблица Б.1 – Спецификация оборудования Наименование Тип, марка Завод Ед. измер-я Кол-во изготовитель 1 1. Коммутатор FS S390024T4S 2. ИБП APC Smart-UPS SMT1500RMI2U, 1500ВA Цена за Сумма шт 2 3 4 5 6 7 Коммутатор FS шт. 1 26 785 26 785 APC шт. 1 69 399 69 399 Сервер HP шт. 3 77 975 233 925 Сервер HP шт. 1 90 413 90 413 Источник бесперебойного питания 3. Сервер HPE ProLiant dl20 Gen10 (1U), процессор Intel Xeon E-2124 (3.3GHz/4core/71W), оперативная память 8GB (1x8GB) Single Rank x8 DDR42666,жесткий диск 1TB 3,5'' (LFF) SATA 7.2K 6G NonHP 4. Сервер HPE ProLiant dl20 Gen10 (1U), процессор Intel Xeon E-2124 (3.3GHz/4core/71W), оперативная память 2x8GB (1x8GB) Single Rank x8 DDR42666,жесткий диск 1TB 3,5'' (LFF) SATA 7.2K 6G NonHP Итого БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата 420 522 Лист 57

ПРИЛОЖЕНИЕ В (обязательное) Ресурсно-сервисная модель сервиса САСП Рисунок В.1 – Ресурсно-сервисная модель сервиса САСП БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 58

ПРИЛОЖЕНИЕ Г (обязательное) Ресурсно-сервисная модель сервиса База Знаний Рисунок Г.1 – Ресурсно-сервисная модель сервиса База Знаний БР-02069964-11.03.02-02-20 Изм. Лист № докум. Подпись Дата Лист 59

Рецензии:

Авторизуйтесь, чтобы добавить рецензию

- у работы пока нет рецензий -

Отзывы:

Авторизуйтесь, чтобы оставить отзыв