Моніторинг в корпоративних мережах. § Повний опис всіх етапів проектування, розробки і впровадження системи. Продукти для моніторингу та аналізу

27.06.2011 Нейт Мак-Алмонд

Я зупинив свій вибір на трьох кандидатів: WhatsUp Gold Premium компанії Ipswitch, OpManager Professional компанії ManageEngine і ipMonitor компанії SolarWinds. Вартість кожного з цих мережевих сканерів не перевищує 3000 дол. (За 100 пристроїв), і при цьому у кожного з них є пробний період експлуатації, протягом якого ви можете безкоштовно протестувати обраний продукт

Я працюю в компанії середнього розміру, і ми вже близько семи років використовуємо одну і ту ж систему моніторингу мережі. Вона надає нашим адміністраторам базову інформацію про доступність серверів і служб, а також відправляє текстові повідомлення SMS на наші мобільні телефони в разі виникнення проблем. Я прийшов до висновку, що необхідно оновити систему або принаймні додати ефективний засіб, здатне забезпечити більш високу продуктивність і надавати детальну інформацію про стан серверів терміналів, систем Exchange і SQL, розміщених у вашій мережі. . Давайте порівняємо наших кандидатів.

процес виявлення

Для підготовки до тестування в першу чергу необхідно було включити службу SNMP на всіх пристроях, включаючи сервери Windows. Змінивши настройки служби SNMP, я встановив доступ з привілеєм «тільки читання» на всіх пристроях, які повинен охоплювати процес моніторингу. У системах Windows Server 2003/2000 служба SNMP встановлюється за допомогою майстра Windows Components, розміщеного в панелі Add / Remove Programs, а в системі Windows Server 2008 компоненти SNMP додаються за допомогою майстра Server Manager. Після завершення роботи майстра необхідно запустити оснастку Services, розташовану в папці Control Panel, і налаштувати службу SNMP - це нескладно. Керовані мережеві пристрої, такі як міжмережеві екрани, комутатори, маршрутизатори та принтери, також мають засоби управління службою SNMP, і зазвичай процес налаштування являє собою досить просту операцію. Додаткову інформацію про службу SNMP можна отримати з документа «Simple Network Managment Protocol» (technet.microsoft.com/en-us/library/bb726987.aspx).

Далі я встановив все три системи моніторингу на одну з двох своїх робочих систем з Windows XP SP3. Після установки кожна система складалася з двох частин: бази даних і веб-сервера. Управління кожної з обраних систем через веб-інтерфейс може виконуватися декількома адміністраторами, і у вас є можливість налаштувати облікові записи з різними рівнями доступу. Загальним для трьох систем є і те, що кожен користувач має можливість додавати, видаляти і переміщати панелі в своїй робочій області. Панелі відображають однотипні дані, такі як завантаження процесора або використання пам'яті для різних пристроїв в мережі.

Перед тим як почати сканування мережі (так званий процес виявлення), я задав параметри облікового запису, який кожна система повинна використовувати для отримання доступу до пристроїв, виявлених в мережі. Як показано в порівняльній таблиці, система Ipswitch WhatsUp Gold Premium дозволяє налаштувати обліковий запис для роботи зі службами SNMP, WMI, Telnet, SSH, ADO і VMware. Система ManageEngine OpManager Professional дозволяє працювати по протоколах SNMP, WMI, Telnet, SSH і URL, а система SolarWinds ipMonitor - за протоколами SNMP, WMI і URL.

Після настройки служби SNMP на мережевих пристроях і облікових записів (Windows і SNMP) для кожної з систем мережевого моніторингу я запустив процес виявлення для діапазону IP-адрес в своїй локальній мережі. Всі системи виявили близько 70 пристроїв. Використовуючи налаштування сканування, задані за замовчуванням, тестовані системи добре показали себе при ідентифікації типів пристроїв, а також представили детальну інформацію про стан пристроїв. Всі три системи містять сенсори для основних робочих характеристик пристроїв і серверів, таких як: завантаження процесора, використання пам'яті, використання / наповненість диска, втрати / затримки пакетів, стан служб Exchange, Lotus, Active Directory і всіх служб Windows. Кожна з систем мала можливість додавати сенсори як для окремих пристроїв, так і для великих груп пристроїв.

Пакети OpManager і WhatsUp Gold мають інтерфейс для ідентифікації та збору подій служби VMware з серверів і гостьових систем. Крім того, обидва продукти мають у своєму розпорядженні функцією опитування диспетчера портів комутатора, яка показує, які пристрої під'єднані до різних портів керованих комутаторів. Отримана інформація допоможе визначити, через який порт комутатора здійснюється з'єднання з певним бізнес-додатком, при цьому немає необхідності вручну виконувати трасування кабелів в серверних кімнатах. Надалі ви можете налаштувати оповіщення для певних портів комутатора. При роботі з пакетом OpManager для отримання результатів опитування портів досить вибрати комутатор і запустити інструмент Switch Port Mapper - система поверне результати за кілька секунд. Аналогічне засіб, що входить до складу WhatsUp Gold, називається MAC Address, його необхідно запускати з зазначеним параметром Get Connectivity. На отримання результату в системі WhatsUp Gold йде більше часу, так як вона намагається просканувати пристрою і зібрати інформацію про підключення по всій мережі.

Ipswitch WhatsUp Gold Premium

Ipswitch WhatsUp Gold Premium
ЗА: забезпечує найбільш точні результати серед трьох конкурентів, дозволяє створювати власні сенсори, надає комплексні засоби моніторингу систем VMware, інтегрується з AD.
ПРОТИ: меншу кількість вбудованих сенсорів і більш висока вартість в порівнянні з конкурентами (якщо купувати ліцензію менш ніж на 500 пристроїв).
ОЦІНКА: 4,5 з 5.
ЦІНА: 7495 дол. За 500 пристроїв, 2695 дол. За 100 пристроїв, 2195 дол. За 25 пристроїв.
РЕКОМЕНДАЦІЇ: Я рекомендую WhatsUp Gold IT підрозділам, обслуговуючим великі середовища VMware, або бажаючим створювати власні сенсори.
КОНТАКТНА ІНФОРМАЦІЯ: Ipswitch, www.ipswitch.com

При роботі з системами IpMonitor і OpManager я час від часу стикався з незрозумілими показаннями, які ставили мене в глухий кут. В системі IpMonitor в робочих панелях могли відображатися негативні значення, коли рівень завантаження процесора значно знижувався. В іншому випадку при завантаженості процесора близькою до нуля система IpMonitor прислала мені повідомлення, що процесор задіяний на 11,490%! Система OpManager, відстежуючи і надсилаючи мені коректну інформацію про використання дисків контролерів домену, при цьому в деяких випадках не включала жоден з контролерів в список 10 серверів з максимальним використанням дискового простору. При цьому сусідня панель сповіщала про те, що один з моїх контролерів домену повинен бути навіть не в десятці, а в трійці. При використанні WhatsUp Gold я не стикався з подібними ситуаціями. Система WhatsUp Gold відстежує завантаженість ядер процесорів у своїх панелях, і, коли я порівняв результати з панелей WhatsUp Gold з показаннями засоби Windows Performance Monitor, вони в точності збіглися по кожному з ядер. Аналогічно, інформація про використання жорстких дисків коректно передавалася на всі відповідні додатки робочої області.

Система WhatsUp Gold має вбудовану бібліотеку сенсорів, яка дозволяє створювати нові сенсори на основі існуючих. Великі організації можуть знайти цю можливість корисної, так як вона дозволяє створювати єдині набори сенсорів для моніторингу різних типів пристроїв - це найбільш ефективною спосіб налаштовувати сенсори для групи пристроїв.

Система WhatsUp Gold не має сенсорів для пристроїв окремих виробників (за винятком сенсора для джерел живлення APC UPS), на відміну від пакета OpManager, що використовує власні сенсори для пристроїв Dell, HP і IBM, але зате дозволяє створювати сенсори типу Active Script. Даний тип дозволяє розробляти власні процеси моніторингу за допомогою мов програмування VBScript і JScript. Сенсорів Active Script присвячений центр онлайн-підтримки, в якому користувачі системи WhatsUp Gold можуть отримувати і завантажувати готові сценарії.

Єдине поліпшення, яке мені б хотілося додати в систему WhatsUp Gold, стосується інтерфейсу (екран 1), в основному через те, що він занадто лінійний. Наприклад, знадобиться до 5 клацань на кнопках Cancel і Close, щоб повернутися з вікна Active Monitor Library назад до робочої області. Також в системі WhatsUp Gold відсутня сенсор (якщо, звичайно, не написати його вручну), перевіряючий стан сайту, а він може бути необхідний, особливо у випадках, коли сайт розміщений на сторонньому сервері і інші шляхи доступу до нього відсутні.

Екран 1. Інтерфейс WhatsUp Gold Premium

Для обробки ситуацій, коли пристрої знаходяться в неробочому стані протягом деякого часу, можна налаштувати відправку повідомлень кожні 2, 5 і 20 хвилин. Таким чином можна привернути увагу адміністратора до відсутності відгуків від найважливіших вузлів протягом певного часу.

WhatsUp Gold є єдиною з розглянутих систем, яка має можливість інтеграції в оточення LDAP, - даний момент може бути принциповим при виборі рішення для великих мереж.

ManageEngine OpManager

ManageEngine OpManager
ЗА:кращий користувальницький інтерфейс серед трьох продуктів; більше вбудованих сенсорів, ніж в двох інших системах; найнижча ціна при покупці ліцензії на 50 і менше пристроїв.
ПРОТИ: в ході тестів не всі показники пристроїв відображалися коректно; можливо, буде потрібно витратити час на налагодження, щоб зробити систему повністю функціональною.
ОЦІНКА: 4,5 з 5.
ЦІНА: 1 995 дол. За 100 пристроїв, 995 дол. За 50 пристроїв, 595 дол. За 25 пристроїв.
РЕКОМЕНДАЦІЇ: ІТ-підрозділу, які бажають отримати максимальну кількість вбудованих можливостей (за винятком інтеграції в AD), оцінять систему OpManager Professional. При покупці ліцензій в діапазоні 26-50 пристроїв її вартість майже вдвічі нижча за вартість двох інших продуктів.
КОНТАКТНА ІНФОРМАЦІЯ:ManageEngine, www.manageengine.com

Після установки системи OpManager я виявив, що вона відрізняється простотою настройки величезного числа функцій і зручністю переміщення між ними. У OpManager передбачена можливість відправки (поряд з електронними листами і SMS) повідомлень типу Direct Message для облікового запису в системі Twitter - приємна альтернатива електронній пошті. Подібне використання облікових записів Twitter дозволяє мені бути в курсі того, що відбувається в мережі, але, так як мій телефон не дзвонить при доставці повідомлень з системи Twitter, я паралельно хочу отримувати текстові повідомлення про найбільш важливі події. Я можу переглядати інформацію про досягнення порогових значень на будь-якому сервері за допомогою повідомлень Twitter і, таким чином, мати журнал поточних подій в мережі, але не обов'язково використовувати дану схему для передачі попереджень про критичні ситуації.

На додаток до стандартних сенсорам, система OpManager пропонує технології моніторингу продуктивності по протоколу SNMP, розроблені постачальниками для таких пристроїв, як Dell Power-Edge, HP Proliant і IBM Blade Center. OpManager також може бути інтегрований з Google Maps API, завдяки чому ви зможете додавати свої пристрої на карту Google. Однак для цього доведеться придбати обліковий запис Google Maps API Premium (якщо ви не плануєте зробити свою карту мережі загальнодоступної) відповідно до умов ліцензування безкоштовної версії системи Google Maps API.

Для обробки ситуацій, коли адміністратор отримує попередження, але ніяк не реагує на нього протягом певного часу, в системі OpManager можна налаштувати відправку додаткового попередження повністю відмінене. Наприклад, співробітник, зазвичай відповідає за обробку критичних подій для певної групи серверів, може виявитися зайнятий або хворий. На такий випадок має сенс налаштувати додаткове попередження, яке приверне увагу іншого адміністратора, якщо перше попередження не було переглянуто чи скинуто протягом заданої кількості годин / хвилин.

Серед трьох розглянутих продуктів лише система OpManager мала розділ, призначений для моніторингу якості обмінів VoIP в глобальної мережі. Для використання інструментів моніторингу VoIP необхідно, щоб пристрої, як в мережі джерела, так і в мережі призначення, підтримували технологію Cisco IP SLA. Крім того, система OpManager, інтерфейс якої показаний на екрані 2, включає в себе більше сенсорів і робочих панелей, ніж будь-який з конкуруючих продуктів.

Екран 2. Інтерфейс OpManager Professional

SolarWinds ipMonitor

SolarWinds ipMonitor
ЗА: необмежену кількість пристроїв за дуже низькою ціною; простота у використанні.
ПРОТИ:відсутній механізм узгодження дій адміністраторів.
ОЦІНКА: 4 з 5.
ЦІНА: 1995 дол. - кількість пристроїв не обмежена (25 сенсорів безкоштовно).
РЕКОМЕНДАЦІЇ: якщо бюджет обмежений, а вам необхідно організувати моніторинг великої кількості пристроїв, якщо процес моніторингу не потребує складних рішень і вам підходить позасистемний підхід до узгодження дій адміністраторів, система компанії SolarWinds - ваш вибір.
КОНТАКТНА ІНФОРМАЦІЯ: SolarWinds, www.solarwinds.com

Після першого знайомства з системою ipMonitor її інтерфейс, який ви бачите на екрані 3, здався мені дуже заплутаним. Я мало не вічність витратив на те, щоб знайти місце, де налаштовується частота перевірки системою окремих системних сенсорів (за замовчуванням опитування виконувався кожні 300 секунд). Однак після використання ipMonitor протягом декількох тижнів я виявив, що ця система надзвичайно проста в застосуванні і володіє достатніми можливостями для якісного моніторингу мережі. За допомогою ipMonitor можна налаштувати сканування «за замовчуванням» таким чином, що будь-яка служба або параметр продуктивності будуть завжди включені в майбутні процеси сканування. До того ж до стандартних (і названим вище) сенсорам, система ipMonitor пропонує сенсор журналу подій Windows, який можна використовувати для відправки попереджень при виявленні критичних подій.

Екран 3. Інтерфейс SolarWinds ipMonitor

З іншого боку, система ipMonitor не має механізмів відстеження / призначення адресатів попереджень. Це не має значення, якщо в компанії один адміністратор мережі, але більші ІТ-підрозділу, швидше за все, вважатимуть істотним недоліком нездатність системи підтверджувати отримання попереджень, призначати адресатів і скидати попередження. Якщо адміністратори забувають координувати свої дії поза системою, можливі ситуації, коли кілька адміністраторів отримують одне і те ж попередження і починають працювати над однією і тією ж проблемою. Втім, для вирішення подібних конфліктів досить розробити узгоджений алгоритм реагування на попередження - наприклад, якщо розділити відповідальність за мережеві пристрої між адміністраторами, то не виникатиме запитань про те, хто повинен зайнятися вирішенням тієї чи іншої проблеми.

Час приймати рішення

Я вже вирішив для себе, який з трьох продуктів більше підійде до мого оточення. Я зупинився на системі ManageEngine OpManager з ліцензією на 50 пристроїв з кількох причин.

Перш за все, мені потрібна можливість відстежувати максимальну кількість параметрів свого оточення, так як це найкращий спосіб уникнути несподіваних відмов. В даному питанні система OpManager, безумовно, попереду конкурентів. Друга причина - бюджет. Я можу продовжувати використовувати наші старі засоби моніторингу, що працюють за принципом «включено / вимкнено», для робочих станцій і принтерів, і таким чином уникнути витрат на додаткові ліцензії. Нарешті, мені дійсно сподобався підхід, використаний співробітниками ManageEngine при розробці OpManager, що дозволяє задіяти переваги нових технологій, і я вважаю повністю виправданими витрати на придбання річного пакету обслуговування і підтримки, що дозволяє завантажувати оновлення, що з'являються в міру розвитку продукту.

Нейт Мак-Алмонд ( [Email protected]) - директор з інформаційних технологій в агентстві з надання соціальних послуг, має сертифікати MCSE, Security і Network +, спеціалізується на рішеннях з тонкими клієнтами та медичних базах даних

Управління та моніторинг ІТ-інфраструктури - одна з головних задач ІТ-департаменту будь-якої компанії. Рішення HP Software дозволять спростити завдання системних адміністраторів і організувати ефективний контроль мережі організації

Сучасна ІТ-інфраструктура являє собою складну гетерогенну мережу, що включає в себе телекомунікаційні, серверні і програмні рішення різних виробників, що працюють на базі різних стандартів. Її складність і масштабність визначають високий рівень автоматизованих засобів моніторингу та управління, які повинні використовуватися для забезпечення надійної роботи мережі. Програмні продукти HP Software допоможуть вирішити завдання моніторингу на всіх рівнях, від інфраструктури (мережевого обладнання, серверів і систем зберігання) до контролю якості роботи бізнес-сервісів і бізнес-процесів.

Системи моніторингу: якими вони бувають?

В сучасних платформах для моніторингу ІТ існує 3 напрямки для розвитку і виведення моніторингу на новий рівень. Першу називають «Міст» ( «Зонтичная система», «Менеджер менеджерів). Її концепція полягає в утилізації інвестицій в уже наявні системи, які виконують завдання моніторингу окремих частин інфраструктури, і перетворенні самих систем в інформаційні агенти. Такий підхід є логічним розвитком звичайного моніторингу ІТ інфраструктури. Як передумови впровадження системи типу «Міст» може служити прийняття ІТ-відділом рішення консолідувати розрізнені системи моніторингу для переходу до моніторингу ІТ послуг / систем як чогось цілого, розрізнення системи не здатні показати всю картину, випадок не діагностування серйозного збою додатків, а також велика кількість попереджень та аварійних сигналів, відсутність єдиного охоплення, пріоритетності та виявлення причинно-наслідкового зв'язку.

Результатом впровадження стане автоматизований збір всіх доступних подій і метрик ІТ-інфраструктури, зіставлення їх стану і впливу на «здоров'я» сервісу. У разі збою оператор отримає доступ до панелі, що відображає кореневу причину збою з рекомендаціями щодо її усунення. У разі типового збою є можливість призначити скрипт, що автоматизує необхідні дії оператора.

Наступна тенденція називається «Аналітика аномалій». Тут, як і в першому випадку, метрики і події збираються з ряду систем інфраструктурного моніторингу, а крім того, налаштований збір логів ІТ і безпеки. Таким чином, щохвилини накопичується величезна кількість інформації, і компанія хоче отримати переваги від її утилізації. Для впровадження «Аналітики аномалій» існує цілий ряд причин: складність своєчасного збору, зберігання і аналізу всіх даних, потреба реактивно усувати невідомі проблеми, неможливість швидкого визначення важливою для усунення збоїв інформації, складність виконання вручну операцій пошуку окремих журналів, а також необхідність визначення відхилень і повторюваних збоїв.

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

І нарешті - «Управління продуктивністю додатків», або виявлення та усунення несправностей в транзакціях кінцевих користувачів. Таке рішення може бути корисним доповненням, що працюють в тісному контакті з попередніми двома. При цьому така система сама по собі теж може давати швидкий результат від впровадження. В даному випадку в компанії є додатки, важливі для бізнесу. При цьому важливі доступність і якість послуги, одним з ключових елементів якої є додаток (інтернет-банкінг, CRM, біллінг і т. Д.). При падінні доступності та якості надання цього сервісу, як правило, заходить мова про проактивности і швидкому відновленні. Така система зазвичай впроваджується, коли необхідно підвищити доступність сервісів додатків і продуктивність, а також скоротити середній час відновлення працездатності. Крім того, такий підхід гарний для усунення зайвих витрат і зниження ризиків, пов'язаних з угодою про рівень обслуговування (SLA), і для запобігання відходу замовників (захист бізнесу).

Результати впровадження в залежності від головного завдання можуть відрізнятися. У загальному випадку це дозволяє реалізувати виконання типових дій користувача «роботом» з різних регіонів \\ сегментів мережі, розбір «віддзеркалювати» трафіку, перевірку доступності та якості роботи сервісів з виявленням вузьких місць, інформування оператора про необхідність відновити працездатність із зазначенням місця деградації. При необхідності стає можлива глибока діагностика роботи програми для пошуку причин систематичного погіршення роботи сервісів.

Зазначені вище підходи можуть бути реалізовані за допомогою продуктів HP Software, про яких і піде мова далі.

«Міст» від HP

HP Operations Bridge являє новітнє покоління «Зонтичних систем моніторингу». Рішення об'єднує дані моніторингу від власних агентів, різних модулів моніторингу HP Software і засобів моніторингу інших розробників. Потік подій від всіх джерел інформації накладається на ресурсно-сервісну модель, до нього застосовуються кореляційні механізми для визначення того, які події є причинами, симптомами та наслідками.

Окремо слід зупинитися на ресурсно-сервісній моделі, а точені моделях, так як таких моделей може не обмежена кількість для аналізу інформації в різних ракурсах. Від її повноти та актуальності залежить можливість вирішення виконувати кореляцію потоку подій. Для підтримки актуальності моделей використовуються засоби розвідки на базі агентів і безагентних технологій, що дозволяють отримувати детальну інформацію про компоненти сервісу, взаємозв'язках між ними і взаємний вплив один на одного. Також є можливість імпорту даних про топологію сервісу з зовнішніх джерел - систем моніторингу.

Ще один важливий аспект - зручність управління. У складних і динамічно мінливих середовищах важливо забезпечити підстроювання системи моніторингу при зміні структури систем і додаванні нових сервісів. У Operations Bridge входить компонент Monitoring Automation, який дозволяє в автоматичному режимі настроювати системи, що вводяться в периметр моніторингу, для чого використовуються дані про сервісно-ресурсних моделях. Одночасно можливе конфігурація і зміна вже виконаних раніше налаштувань моніторингу.

Якщо раніше адміністратори могли виконувати однакові настройки однотипних компонентів інфраструктури (наприклад, метрик на Windows, Linux або UNIX-серверах), що вимагало чималого часу і зусиль, то тепер можна динамічно і централізовано налаштовувати порогові значення для метрики в розрізі послуги або сервісу.

Аналітика додатків

Використання традиційного підходу до моніторингу має на увазі, що спочатку відомо, які параметри контролювати і які події відстежувати. Зростаюча складність і динаміка розвитку ІТ-інфраструктур змушує шукати інші підходи, так як стає все складніше контролювати всі аспекти роботи системи.

HP Operations Analytics дозволяє зібрати і зберегти всі дані про роботу програми: лог-файли, телеметрію, бізнес-метрики і метрики продуктивності, системні події і т.д., і використовувати аналітичні механізми для виявлення тенденцій і прогнозування. Рішення призводить зібрані дані до єдиного формату і потім, здійснюючи контекстний вибір, на підставі даних лог-файлів відображає на часовій шкалі, що, в який момент і на якій системі відбувалося. Продукт надає кілька форм візуалізації даних (наприклад, інтерактивна «теплова карта» і топологія взаємозв'язків лог-файлів) і використовує функцію помічника для того, щоб в контексті події або по введеному в рядку пошуку запит знайти всю сукупність даних, зібраних за конкретний період. Це допомагає оператору зрозуміти, що призвело до збою (або, при використанні даних HP SHA разом з даними HP OA, зробити відповідний прогноз), а також виявити як винуватця, так і кореневу причину того, що сталося збою. HP Operations Analytics дає можливість відтворити картину роботи сервісу та оточення в момент виникнення збою і ізолювати його в контексті і часу.

Ще один аналітичний інструмент - HP Service Health Analyzer. HP SHA виявляє аномальну поведінку контрольованих елементів інфраструктури з метою попередження можливої \u200b\u200bвідмови в наданні сервісів або порушення заданих параметрів їх надання. У продукті застосовуються спеціальні алгоритми статистичного аналізу даних на основі топологічної сервісно-ресурсної моделі HP BSM. З їх допомогою забезпечується можливість побудови профілю нормальних значень параметрів продуктивності, зібраних як з програмно-апаратних платформ, так і з інших модулів BSM (наприклад, HP RUM, HP BPM), що характеризують стан сервісів. У подібні профілі вводяться типові значення параметрів з урахуванням днів тижня і часу доби. SHA виконує історичний і статистичний аналіз накопичених даних (для розуміння суті виявлених даних), а також здійснює зіставлення з наявними динамічним профілем (baselining).

Контроль продуктивності додатків

Коли мова заходить контролі продуктивності додатків, слід виділити наступні компоненти рішення HP:

• HP Real User Monitoring (HP RUM) - контроль проходження транзакцій реальних користувачів;
• HP Business Process Monitoring (HP BPM) - контроль доступність додатку методом емуляції дій користувачів;
• HP Diagnostics - контроль проходження запитів всередині програми.

HP RUM і HP BPM дозволяють оцінити доступність додатка з точки зору кінцевого користувача.

HP RUM розбирає мережевий трафік, виявляючи в ньому транзакції реальних користувачів. При цьому можна контролювати обмін даними між компонентами програми: клієнтською частиною, сервером додатків і базою даних. Це дає можливість відстежити активність користувачів, час обробки різних транзакцій, а також визначити взаємозв'язку між діями користувачів і бізнес-метриками. Використовуючи HP RUM, оператори служби моніторингу зможуть миттєво отримувати оперативні повідомлення про проблеми в доступності сервісів і інформацію про помилки, з якими зіткнулися користувачі.

HP BPM являє собою засіб активного моніторингу, яке виконує синтетичні користувача транзакції, для контрольованих систем відрізнити від реальних. Дані моніторингу HP BPM зручно використовувати для розрахунку реального SLA, так як «робот» виконує ідентичні перевірки в однакові проміжки часу, забезпечуючи постійний контроль якості обробки типових (або найбільш критичних) запитів. Налаштувавши проби для виконання синтетичних транзакцій з декількох точок (наприклад, з різних офісів компанії), можна також оцінити доступність сервісу для різних користувачів з урахуванням їх розташування і каналів зв'язку. Для емуляції активності HP BPM використовує інструмент Virtual User Generator (VuGen), який також застосовується в популярному продукті навантажувального тестування HP LoadRunner. VuGen підтримує величезний спектр різних протоколів і технологій, завдяки чому можна контролювати доступність практично будь-яких сервісів, а також використовувати єдиний набір скриптів для тестування і моніторингу.
Якщо ж причина збоїв або уповільнення роботи сервісу знаходиться всередині таких технологій, як Java, .NET і т. Д., Допоможе HP Diagnostics.

Рішення забезпечує глибокий контроль Java, .NET, Python на платформах Windows, Linux і Unix. Продукт може використовувати широкий сервера додатків (Tomcat, Jboss, WebLogic, Oracle та ін.), MiddleWare і бази даних. Спеціалізовані агенти HP Diagnostics встановлюються на серверах додатків і збирають дані, специфічні для конкретної технології. Наприклад, для Java-програми можна побачити, які запити виконуються, які методи використовуються і скільки часу витрачається на їх відпрацювання. Автоматично отрісовивается структура додатки, стає зрозуміло, як задіяні його компоненти. HP Diagnostics дозволяє відстежити проходження бізнес-транзакцій всередині комплексних програм, визначити вузькі місця і забезпечити експертів необхідною інформацією для прийняття рішень.

Дистрибуція рішень НР в

РЕФЕРАТ

Цей документ є технічним проектом розробки і впровадження системи моніторингу мережі Верхньопишмінського міської мережі передачі даних загального доступу ТОВ Геркон. У проекті проведено дослідження існуючих систем моніторингу мережі, аналіз поточної ситуації на підприємстві і обгрунтований вибір конкретних компонентів системи моніторингу мережі.

Документ містить опис проектних рішень і специфікації обладнання.

Результатом проектування є розроблені рішення по впровадженню і використанню системи:

§ Повний опис всіх етапів проектування, розробки і впровадження системи;

§ Керівництво системного адміністратора, що включає опис користувальницького інтерфейсу системи.

Цей документ закінчені проектні рішення і може бути використаний для впровадження системи.

ПЕРЕЛІК ЛИСТІВ ГРАФІЧНИХ ДОКУМЕНТІВ

Таблиця 1 - Перелік листів графічних документів

1Сістеми мережевого моніторінга220100 4010002Логіческая структура сеті220100 4010003Алгорітм роботи ядра мережевого моніторингу та оповещеній220100 4010004Структура аналізатора завантаження мережевих інтерфейсов220100 4010005Структура збирача системних журналів собитій220100 4010006Інтерфейс Nagios220100 4010007Обобщенная структура системи мережевого моніторінга220100 401000

ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ І ТЕРМІНІВ

Ethernet - стандарт передачі даних, випущений IEEE. Визначає як передавати або отримувати дані з загального середовища передачі даних. Формує нижній транспортний рівень і використовується різними високорівневими протоколами. Забезпечує швидкість передачі даних 10Мбіт / сек.

Fast Ethernet - технологія передачі даних зі швидкістю 100 Мбіт / сек, що використовує CSMA / CD метод, як і 10Base-T.

FDDI - Fiber Distributed Data Interface - волоконно-оптичний інтерфейс розподіленої передачі даних - технологія передачі даних зі швидкістю 100 Мбіт / сек, що використовує метод маркерного кільця.

IEEE - Institute of Electrical and Electronic Engineers (Інститут інженерів з електротехніки та електроніки) - організація, яка розробляє і публікує стандарти.

LAN - Local Area Network - локальна мережа, ЛВС. адреса - Media Access Control - ідентифікаційний номер мережевого пристрою, який визначається, як правило, виробником.

RFC - Request for Comments - звід документів, що випускаються організацією IEEE, і включають в себе опис стандартів, специфікацій та ін.

TCP / IP - Transmission Control Protocol / Internet Protocol - протокол управління передачею / протокол Internet.

ЛВС - Локальна обчислювальна мережа.

ОС - Операційна система.

ПО - Програмне забезпечення.

СКС - Структурована кабельна система.

СУБД - Система управління базами даних.

Тренд - Довготривала статистика, яка дозволяє побудувати так звану тенденцію.

ЕОМ - Електронно-обчислювальна машина.

ВСТУП

Інформаційна інфраструктура сучасного підприємства представляє собою складний конгломерат різномасштабних і різнорідних мереж і систем. Щоб забезпечити їх злагоджену і ефективну роботу, необхідна керуюча платформа корпоративного масштабу з інтегрованими інструментальними засобами. Однак до недавнього часу сама структура індустрії мережевого управління перешкоджала створенню таких систем - «гравці» цього ринку прагнули до лідерства, випускаючи продукти обмеженою області дії, що використовують засоби і технології, не сумісні з системами інших постачальників.

Сьогодні ситуація змінюється на краще - з'являються продукти, які претендують на універсальність управління усім розмаїттям корпоративних інформаційних ресурсів, від настільних систем до мейнфреймів і від локальних мереж до ресурсів Мережі. Одночасно приходить усвідомлення того, що керуючі додатки повинні бути відкриті для рішень всіх постачальників.

Актуальність даної роботи обумовлена \u200b\u200bтим, що в зв'язку з поширенням персональних комп'ютерів і створенням на їх основі автоматизованих робочих місць (АРМ) зросло значення локальних обчислювальних мереж (ЛВС), діагностика яких, є об'єктом нашого дослідження. Предметом дослідження є основні методи організації і проведення діагностики сучасних комп'ютерних мереж.

"Діагностика локальної мережі" - процес (безперервного) аналізу стану інформаційної мережі. При виникненні несправності мережевих пристроїв фіксується факт несправності, визначається її місце і вид. Повідомлення про несправності передається, пристрій відключається і замінюється резервним.

Адміністратор, на якого найчастіше лягають функції з проведення діагностики, повинен починати вивчати особливості своєї мережі вже на фазі її формування тобто знати схему мережі і докладний опис конфігурації програмного забезпечення із зазначенням всіх параметрів і інтерфейсів. Для оформлення і зберігання цієї інформації підійдуть спеціальні системи документування мережі. Використовуючи їх, системний адміністратор, буде заздалегідь знати всі можливі «приховані дефекти» і «вузькі місця» своєї системи, для того, щоб в разі виникнення нештатної ситуації знати, з чим пов'язана проблема з обладнанням або програмним забезпеченням, пошкоджена програма або до помилки призвели дії оператора.

Адміністратора слід пам'ятати, що з точки зору користувачів якість роботи прикладного програмного забезпечення в мережі виявляється визначальним. Всі інші критерії, такі як число помилок передачі даних, ступінь завантаженості мережевих ресурсів, продуктивність обладнання і т. П., Є вторинними. "Хороша мережа" - це така мережа, користувачі якої не помічають, як вона працює.

підприємство

Переддипломна практика проходила на підприємстві ТОВ «Геркон» у відділі супроводу на посаді системного адміністратора. Підприємство пропонує послуги доступу в Інтернет в містах Верхня Пишма і Среднеуральск за технологією Ethernet і комутованих (dial-up) каналам з 1993 року і є одним з перших постачальників послуг Інтернет в цих містах. Правила надання послуг врегульовані публічною офертою і регламентом.

Наукові та виробничі завдання підрозділу

Відділ супроводу вирішує наступний спектр завдань в межах даного підприємства:

§ технічна і технологічна організація надання доступу в Інтернет по комутованих і виділених каналах;

§ технічна і технологічна організація бездротового доступу в Інтернет;

§ виділення дискового простору для зберігання та забезпечення роботи сайтів (хостинг);

§ підтримка роботи поштових скриньок або віртуального поштового сервера;

§ розміщення обладнання клієнта на майданчику провайдера (колокація);

§ оренда виділених і віртуальних серверів;

§ резервування даних;

§ розгортання і підтримка корпоративних мереж приватних підприємств.

1. СИСТЕМИ мережевої МОНІТОРИНГУ

Незважаючи на безліч прийомів і інструментів виявлення та усунення неполадок в комп'ютерних мережах, «грунт під ногами» мережевих адміністраторів все ще залишається досить хиткою. Комп'ютерні мережі все частіше включають волоконно-оптичні та бездротові компоненти, наявність яких робить безглуздим застосування традиційних технологій і інструментів, призначених для звичайних мідних кабелів. До того ж до нього при швидкостях понад 100 Мбіт / с традиційні підходи до діагностики часто перестають працювати, навіть якщо середовищем передачі є звичайний мідний кабель. Однак, можливо, найбільш серйозною зміною в комп'ютерних мережних технологіях, з яким довелося зіткнутися адміністраторам, став неминучий перехід від мереж Ethernet з розділяється середовищем передачі до комутацією каналів, в яких в якості комутованих сегментів часто виступають окремі сервери або робочі станції.

Правда, у міру здійснення технологічних перетворень деякі старі проблеми вирішилися самі собою. Коаксіальний кабель, в якому виявити електротехнічні несправності завжди було важче, ніж в разі кручений пари, стає рідкістю в корпоративних середовищах. Мережі Token Ring, головною проблемою яких була їх несхожість з Ethernet (а зовсім не слабкість в технічному відношенні), поступово замінюються комутованими мережами Ethernet. Породжують численні повідомлення про помилки протоколів мережевого рівня протоколи, такі, як SNA, DECnet і AppleTalk, заміщуються протоколом IP. Сам же стек протоколів IP став більш стабільним і простим для підтримки, що доводять мільйони клієнтів і мільярди сторінок Web в Internet. Навіть закоренілим противникам Microsoft доводиться визнати, що підключення нового клієнта Windows до Internet істотно простіше і надійніше установки застосовувалися раніше стеків TCP / IP сторонніх постачальників і окремого програмного забезпечення комутованого доступу.

Як би численні сучасні технології ні утрудняли виявлення неполадок і управління продуктивністю мереж, ситуація могла б виявитися ще важче, якби технологія АТМ набула широкого поширення на рівні ПК. Свою позитивну роль зіграло і те, що в кінці 90-х, не встигнувши отримати визнання, були відкинуті і деякі інші високошвидкісні технології обміну даними, включаючи Token Ring з пропускною спроможністю 100 Мбіт / с, 100VG-AnyLAN і вдосконалені мережі ARCnet. Нарешті, в США був відхилений дуже складний стек протоколів OSI (який, правда, узаконений низкою урядів європейських країн).

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

Ієрархічна топологія комп'ютерних мереж з магістральними каналами Gigabit Ethernet і виділеними портами комутаторів на 10 або навіть 100 Мбіт / с для окремих клієнтських систем, дозволила збільшити максимальну пропускну здатність, потенційно доступну користувачам, як мінімум в 10-20 разів. Звичайно, в більшості комп'ютерних мереж існують вузькі місця на рівні серверів або маршрутизаторів доступу, оскільки припадає на окремого користувача пропускна здатність істотно менше 10 Мбіт / с. У зв'язку з цим заміна порту концентратора з пропускною спроможністю 10 Мбіт / с на виділений порт комутатора на 100 Мбіт / с для кінцевого вузла аж ніяк не завжди призводить до значного збільшення швидкості. Однак якщо врахувати, що вартість комутаторів останнім часом знизилася, а на більшості підприємств прокладений кабель Категорії 5, що підтримує технологію Ethernet на 100 Мбіт / с, і встановлено мережеві карти, здатні працювати на швидкості 100 Мбіт / с відразу після перезавантаження системи, то стає ясно, чому так нелегко опиратися спокусі модернізації. У традиційній локальної мережі з розділяється середовищем передачі аналізатор протоколів або монітор може досліджувати весь трафік даного сегмента мережі.

Мал. 1.1 - Традиційна локальна мережа з розділяється середовищем передачі і аналізатором протоколів

Хоча перевага комутованої мережі в продуктивності іноді майже не помітно, поширення комутованих архітектур мало катастрофічні наслідки для традиційних засобів діагностики. У сильно сегментованої мережі аналізатори протоколів здатні бачити тільки одноадресний трафік на окремому порту комутатора, на відміну від мережі колишньої топології, де вони могли ретельно дослідити будь-який пакет в домені колізій. В таких умовах традиційні інструменти моніторингу не можуть зібрати статистику по всіх «діалогів», тому що кожна «перемовляються» пара кінцевих точок користується, по суті, своєю власною мережею.

Мал. 1.2 - Коммутируемая мережу

У комутованої мережі аналізатор протоколів в одній точці може «бачити» тільки єдиний сегмент, якщо комутатор не здатний дзеркально відображати кілька портів одночасно.

Для збереження контролю над сильно сегментованими мережами виробники комутаторів пропонують різноманітні засоби для відновлення повної «видимості» мережі, однак на цьому шляху залишається чимало труднощів. У поставляються зараз комутаторах зазвичай підтримується «дзеркальне відображення» портів, коли трафік одного з них дублюється на раніше незадіяний порт, до якого підключається монітор або аналізатор.

Однак «дзеркальне відображення» має низку недоліків. По-перше, в кожен момент часу видно тільки один порт, тому виявити неполадки, що зачіпають відразу декілька портів, дуже непросто. По-друге, дзеркальне відображення може привести до зниження продуктивності комутатора. По-третє, на дзеркальному порту зазвичай не відтворюються збої фізичного рівня, а іноді навіть губляться позначення віртуальних локальних мереж. Нарешті, у багатьох випадках не можуть в повній мірі дзеркально відображатися повнодуплексні канали Ethernet.

Частковим рішенням при аналізі агрегованих параметрів трафіку є використання можливостей моніторингу агентів mini-RMON, тим більше що вони вбудовані в кожен порт більшості комутаторів Ethernet. Хоча агенти mini-RMON не підтримують групу об'єктів Capture з специфікації RMON II, що забезпечують повнофункціональний аналіз протоколів, вони тим не менш дозволяють оцінити рівень використання ресурсів, кількість помилок і обсяг під LGPL.

Деякі недоліки технології дзеркального відображення портів можуть бути подолані установкою «пасивних ответвителей», вироблених, наприклад, компанією Shomiti. Ці пристрої являють собою заздалегідь встановлюються Y-коннектори і дозволяють відстежувати за допомогою аналізаторів протоколу або іншого пристрою не регенерований, а реальний сигнал.

Наступною актуально проблемою, є проблема з особливостями оптики. Адміністратори комп'ютерних мереж зазвичай використовують спеціалізоване обладнання діагностики оптичних мереж тільки для вирішення проблем з оптичними кабелями. Звичайне стандартне програмне забезпечення управління пристроями на базі SNMP або інтерфейсу командного рядка здатне виявити проблеми на комутаторах і маршрутизаторах з оптичними інтерфейсами. І тільки деякі мережеві адміністратори стикаються з необхідністю проводити діагностику пристроїв SONET.

Що стосується волоконно-оптичних кабелів, то причин для виникнення можливих несправностей в них істотно менше, ніж у випадку мідного кабелю. Оптичні сигнали не викликають перехресних перешкод, що з'являються від того, що сигнал одного провідника індукує сигнал на іншому - цей фактор найбільш ускладнює діагностичне обладнання для мідного кабелю. Оптичні кабелі несприйнятливі до електромагнітних шумів і індукованим сигналам, тому їх не потрібно вирівнювати подалі від електромоторів ліфтів і ламп денного світла, т. Е. З сценарію діагностики всі ці змінні можна виключити.

Сила сигналу, або оптична потужність, в даній точці насправді є єдиною змінною, яку потрібно виміряти при пошуку несправностей в оптичних мережах. Якщо ж можна визначити втрати сигналу на всьому протязі оптичного каналу, то можна буде ідентифікувати практично будь-яку проблему. Недорогі додаткові модулі для тестерів мідного кабелю дозволяють проводити оптичні вимірювання.

Підприємствам, які розгорнули велику оптичну інфраструктуру і самостійно її обслуговуючим, може знадобитися придбати оптичний тимчасовий рефлектометр (Optical Time Domain Reflectometer, OTDR), що виконує ті ж функції для оптичного волокна, що і рефлектометр для мідного кабелю (Time Domain Reflectometer, TDR). Прилад діє подібно радару: він посилає імпульсні сигнали по кабелю і аналізує їх відображення, на підставі яких він виявляє пошкодження в провіднику або будь-яку іншу аномалію, і потім повідомляє експерт, в якому місці кабелю слід шукати джерело проблеми.

Хоча різні постачальники кабельних з'єднувачів і роз'ємів спростили процеси терминирования та розгалуження оптичного волокна, для цього, як і раніше потрібно певний рівень спеціальних навичок, і при розумній політиці підприємство з розвиненою оптичної інфраструктурою змушене буде навчати своїх співробітників. Як би добре не була прокладена кабельна мережа, завжди існує можливість фізичного пошкодження кабелю в результаті якого-небудь несподіваного події.

При діагностиці бездротових локальних мереж стандарту 802.11b також можуть виникнути проблеми. Сама по собі діагностика, настільки ж проста, як і в випадку мереж Ethernet на базі концентраторів, так як бездротова середовище передачі інформації розділяється між всіма власниками клієнтських радіопристроїв. Компанія Sniffer TechНlogies першою запропонувала рішення для аналізу протоколів таких мереж з пропускною спроможністю до 11 Мбіт / с, і згодом більшість лідируючих постачальників аналізаторів представили аналогічні системи.

На відміну від концентратора Ethernet з провідними сполуками, якість бездротових клієнтських з'єднань далеко від стабільного. Мікрохвильові радіосигнали, що використовуються в усіх варіантах локальної передачі, слабкі і часом непередбачувані. Навіть невеликі зміни положення антени можуть серйозно позначитися на якості з'єднань. Канали точок доступу безпроводових мережі забезпечуються консоллю управління пристроями, і це часто більш дієвий метод діагностики, ніж відвідування клієнтів бездротової мережі і спостереження за пропускною спроможністю і умовами виникнення помилок за допомогою портативного аналізатора.

Хоча проблеми синхронізації даних і встановлення пристроїв, що виникають у користувачів персональних цифрових секретарів (PDA), більш природно відповідають завданням групи технічної підтримки, а не обов'язків адміністратора, неважко передбачити, що в недалекому майбутньому багато такі пристрої перетворяться з окремих допоміжних засобів, які доповнюють ПК , в повноправних мережевих клієнтів.

Як правило, оператори корпоративних бездротових мереж будуть (або повинні) перешкоджати розгортанню надмірно відкритих систем, в яких будь-який користувач, що знаходиться в зоні дії мережі і володіє сумісної інтерфейсної картою, отримує доступ до кожного інформаційного кадру системи. Протокол безпеки бездротових мереж WEP (Wired Equivalent Privacy) забезпечує аутентифікацію користувачів, гарантію цілісності та шифрування даних, однак, як це зазвичай трапляється, досконала система безпеки ускладнює аналіз причин мережевих неполадок. У захищених мережах з підтримкою WEP фахівці з діагностики повинні знати ключі або паролі, що захищають інформаційні ресурси і контролюючі доступ в систему. При доступі в режимі прийому всіх пакетів аналізатор протоколів зможе бачити всі заголовки кадрів, але міститься в них інформація без наявності ключів буде безглуздою.

При діагностуванні тунелюватись каналів, які багато виробників називають віртуальними приватними мережами з віддаленим доступом, що виникають проблеми аналогічні мають місце при аналізі бездротових мереж з шифруванням. Якщо трафік не проходить через тунелюватись канал, то причину несправності визначити нелегко. Це може бути помилка аутентифікації, поломка на одній з кінцевих точок або затор в загальнодоступній зоні Internet. Ви намагаєтесь отримати доступ аналізатора протоколів для виявлення високорівневих помилок в тунелюватись трафіку буде марною тратою сил, тому що зміст даних, а також заголовки прикладного, транспортного та мережевого рівнів зашифровані. Взагалі, заходи, що вживаються з метою підвищення рівня безпеки корпоративних мереж, зазвичай утруднюють виявлення несправностей і проблем продуктивності. Міжмережеві екрани, proxy-сервери і системи виявлення вторгнень можуть додатково ускладнити локалізацію несправностей.

Таким чином, проблема діагностики комп'ютерних мереж є актуальною і в кінцевому рахунку, діагностування несправностей є завданням управління. Для більшості критично важливих корпоративних систем, проведення тривалих відновлювальних робіт не допустимо, тому єдиним рішенням буде використання резервних пристроїв і процесів, здатних взяти на себе необхідні функції негайно після виникнення збоїв. На деяких підприємствах мережі завжди мають додатковий резервний компонент на випадок збою основного, т. Е. N х 2 компонентів, де n - кількість основних компонентів, необхідне для забезпечення прийнятної продуктивності. Якщо середній час відновлення (Mean Time To Repair, MTTR) досить велике, то може знадобитися ще більша надмірність. Справа в тому, що час усунення несправності передбачити нелегко, а значні витрати протягом непередбачуваного періоду відновлення є ознакою поганого управління.

Для менш важливих систем резервування може виявитися економічно невиправданим, і в цьому випадку буде доцільно вкладати кошти в найбільш ефективні інструменти (і в навчання персоналу), щоб максимально прискорити процес діагностики і усунення несправностей на підприємстві. Крім того, підтримку певних систем можна довірити стороннім фахівцям, або залучаючи їх на підприємство за контрактом, або користуючись можливостями зовнішніх центрів обробки даних, або звертаючись до провайдерів послуг із супроводу додатків (Application Service Providers, ASP) або провайдерам послуг управління. Крім витрат найбільш значним фактором, що впливає на рішення про звернення до послуг сторонніх організацій, можна вважати рівень компетентності власного персоналу. Мережеві адміністратори повинні вирішити, чи не є деяка конкретна функція настільки тісно пов'язаної зі специфічними завданнями підприємства, що від стороннього фахівця не можна буде очікувати більш якісного виконання роботи, ніж це буде зроблено силами працівників підприємства.

Майже відразу після того, як були розгорнуті перші корпоративні мережі, надійність яких залишала бажати кращого, виробники і розробники висунули концепцію «самовідновлюються мереж». Сучасні мережі, безумовно, надійніше, ніж вони були в 90-х рр., Але не тому, що неполадки стали самоусуватися. Ліквідація збоїв програмного забезпечення і апаратних засобів сучасних мереж все ще вимагають втручання людини, і в найближчій перспективі в такому положенні справ не передбачається ніяких принципових змін. Методи і інструменти діагностики цілком відповідають сучасній практиці і технологій, але вони ще не досягли такого рівня, який дозволив би значно заощадити час мережевих адміністраторів в їх боротьбі з неполадками мереж і дефіцитом продуктивності.

1.1 Програмні засоби діагностики

Серед програмних засобів діагностики комп'ютерних мереж, можна виділити спеціальні системи управління мережею (Network Management Systems) - централізовані програмні системи, які збирають дані про стан вузлів і комунікаційних пристроїв мережі, а також дані про трафік, циркулюючому в мережі. Ці системи не тільки здійснюють моніторинг і аналіз мережі, а й виконують в автоматичному чи напівавтоматичному режимі дії з управління мережею - включення і відключення портів пристроїв, зміна параметрів мостів адресних таблиць мостів, комутаторів і маршрутизаторів і т.п. Прикладами систем управління можуть служити популярні системи HPOpenView, SunNetManager, IBMNetView.

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

Експертні системи. Цей вид систем акумулює людські знання про виявлення причин аномальної роботи мереж і можливі способи приведення мережі в працездатний стан. Експертні системи часто реалізуються у вигляді окремих підсистем різних засобів моніторингу та аналізу мереж: систем управління мережами, аналізаторів протоколів, мережевих аналізаторів. Найпростішим варіантом експертної системи є контекстно-залежна help-система. Більш складні експертні системи являють собою так звані бази знань, що володіють елементами штучного інтелекту. Прикладом такої системи є експертна система, вбудована в систему управління Spectrum компанії Cabletron.

1.1.1 Аналізатори протоколів

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

Для цих цілей можуть бути використані різні засоби і перш за все - кошти моніторингу в системах управління мережею, які вже обговорювалися раніше. Деякі вимірювання на мережі можуть бути виконані і вбудованими в операційну систему програмними вимірювачами, прикладом тому служить компонента ОС Windows Performance Monitor. навіть кабельні тестери в їх сучасному виконанні здатні вести захоплення пакетів і аналіз їх вмісту.

Але найбільш досконалим засобом дослідження мережі є аналізатор протоколів. Процес аналізу протоколів включає захоплення циркулюючих в мережі пакетів, що реалізують той чи інший мережевий протокол, і вивчення вмісту цих пакетів. Грунтуючись на результатах аналізу, можна здійснювати обґрунтоване і зважене зміна будь-яких компонент мережі, оптимізацію її продуктивності, пошук і усунення неполадок. Очевидно, що для того, щоб можна було зробити якісь висновки про вплив деякого зміни на мережу, необхідно виконати аналіз протоколів і до, і після внесення змін.

Аналізатор протоколів є або самостійне спеціалізоване пристрій, або персональний комп'ютер, зазвичай переносний, класу Нtebook, оснащений спеціальною мережевою картою і відповідним програмним забезпеченням. Застосовувані мережева карта і програмне забезпечення повинні відповідати топології мережі (кільце, шина, зірка). Аналізатор підключається до мережі точно також, як і звичайний вузол. Відмінність полягає в тому, що аналізатор може приймати всі пакети даних, що передаються по мережі, в той час як звичайна станція - лише адресовані їй. Програмне забезпечення аналізатора складається з ядра, що підтримує роботу мережного адаптера і декодирующего одержувані дані, і додаткового програмного коду, що залежить від типу топології досліджуваної мережі. Крім того, поставляється ряд процедур декодування, орієнтованих на певний протокол, наприклад, IPX. До складу деяких аналізаторів може входити також експертна система, яка може видавати користувачу рекомендації про те, які експерименти слід проводити в даній ситуації, що можуть означати ті чи інші результати вимірювань, як усунути деякі види несправності мережі.

Незважаючи на відносне різноманіття аналізаторів протоколів, представлених на ринку, можна назвати деякі риси, в тій чи іншій мірі властиві всім їм:

Користувальницький інтерфейс. Більшість аналізаторів мають розвинений дружній інтерфейс, який базується, як правило, на Windows або Motif. Цей інтерфейс дозволяє користувачеві: виводити результати аналізу інтенсивності трафіку; отримувати миттєву і усереднену статистичну оцінку продуктивності мережі; задавати певні події і критичні ситуації для відстеження їх виникнення; виробляти декодування протоколів різного рівня і представляти в зрозумілій формі вміст пакетів.

Буфер захоплення. Буфери різних аналізаторів відрізняються за обсягом. Буфер може розташовуватися на встановлюваної мережевої карти, або для нього може бути відведено місце в оперативній пам'яті одного з комп'ютерів мережі. Якщо буфер розташований на мережевої карти, то управління ним здійснюється апаратно, і за рахунок цього швидкість введення підвищується. Однак це призводить до подорожчання аналізатора. У разі недостатньої продуктивності процедури захоплення, частина інформації буде губитися, і аналіз буде неможливий. Розмір буфера визначає можливості аналізу по більш-менш представницьким вибірках захоплюваних даних. Але яким би великим не був буфер захоплення, рано чи пізно він заповниться. У цьому випадку або припиняється захоплення, або заповнення починається з початку буфера.

Фільтри. Фільтри дозволяють управляти процесом захоплення даних, і, тим самим, дозволяють економити простір буфера. Залежно від значення певних полів пакету, заданих у вигляді умови фільтрації, пакет або ігнорується, або записується в буфер захоплення. Використання фільтрів значно прискорює і спрощує аналіз, так як виключає перегляд непотрібних в даний момент пакетів.

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

Пошук. Деякі аналізатори протоколів дозволяють автоматизувати перегляд інформації, що знаходиться в буфері, і знаходити в ній дані за заданими критеріями. У той час, як фільтри перевіряють вхідний потік на предмет відповідності умовам фільтрації, функції пошуку застосовуються до вже накопиченим в буфері даними.

Методологія проведення аналізу може бути представлена \u200b\u200bу вигляді наступних шести етапів:

Захоплення даних.

Перегляд захоплених даних.

Аналіз даних.

Пошук помилок. (Більшість аналізаторів полегшують цю роботу, визначаючи типи помилок і ідентифікуючи станцію, від якої прийшов пакет з помилкою.)

Дослідження продуктивності. Розраховується коефіцієнт використання пропускної здатності мережі або середній час реакції на запит.

Докладне дослідження окремих ділянок мережі. Зміст цього етапу конкретизується у міру того, як проводиться аналіз.

Зазвичай процес аналізу протоколів займає відносно небагато часу - 1-2 робочих дня.

Більшість сучасних аналізаторів дозволяють аналізувати відразу кілька протоколів глобальних мереж, таких, як X.25, PPP, SLIP, SDLC / SNA, frame relay, SMDS, ISDN, протоколи мостів / маршрутизаторів (3Com, Cisco, Bay Networks та інші). Такі аналізатори дозволяють вимірювати різні параметри протоколів, аналізувати трафік в мережі, перетворення між протоколами локальних і глобальних мереж, затримку на маршрутизаторах при цих перетвореннях і т. П. Більш досконалі прилади передбачають можливість моделювання і декодування протоколів глобальних мереж, "стресового" тестування, вимірювання максимальної пропускної спроможності, тестування якості послуг, що надаються. З метою універсальності майже всі аналізатори протоколів глобальних мереж реалізують функції тестування ЛВС і всіх основних інтерфейсів. Деякі прилади здатні здійснювати аналіз протоколів телефонії. А найсучасніші моделі можуть декодувати і представляти в зручному варіанті все сім рівнів OSI. Поява ATM призвело до того, що виробники стали постачати свої аналізатори засобами тестування цих мереж. Такі прилади можуть проводити повне тестування мереж АТМ рівня E-1 / E-3 з підтримкою моніторингу і моделювання. Дуже важливе значення має набір сервісних функцій аналізатора. Деякі з них, наприклад можливість віддаленого управління приладом, просто незамінні.

Таким чином, сучасні аналізатори протоколів WAN / LAН / ДTM дозволяють виявити помилки в конфігурації маршрутизаторів і мостів; встановити тип трафіку, що пересилається з глобальної мережі; визначити використовуваний діапазон швидкостей, оптимізувати співвідношення між пропускною спроможністю і кількістю каналів; локалізувати джерело неправильного трафіку; виконатитестування послідовних інтерфейсів і повне тестування АТМ; здійснити повний моніторинг і декодування основних протоколів з будь-якого каналу; аналізувати статистику в реальному часі, включаючи аналіз трафіку локальних мереж через глобальні мережі.

1.1.2 Протоколи моніторингу

Протокол SNMP (англ. Simple Network Management Protocol - простий протокол управління мережею) - це протокол управління мережами зв'язку на основі архітектури TCP / IP.

На основі концепції TMN в 1980-1990 рр. різними органами стандартизації був вироблений ряд протоколів управління мережами передачі даних з різним спектром реалізації функцій TMN. До одного з типів таких протоколів управління відноситься SNMP. Протокол SNMP був розроблений з метою перевірки функціонування мережевих маршрутизаторів і мостів. Згодом сфера дії протоколу охопила і інші мережеві пристрої, такі як хаби, шлюзи, термінальні сервера, LAN Manager сервера, машини під управлінням Windows NT і т.д. Крім того, протокол допускає можливість внесення змін у функціонування зазначених пристроїв.

Ця технологія, покликана забезпечити управління і контроль за пристроями і додатками в мережі зв'язку шляхом обміну керуючою інформацією між агентами, що розташовуються на мережевих пристроях, і менеджерами, розташованими на станціях управління. SNMP визначає мережу як сукупність мережевих керуючих станцій і елементів мережі (головні машини, шлюзи і маршрутизатори, термінальні сервери), які спільно забезпечують адміністративні зв'язку між мережевими керуючими станціями і мережевими агентами.

При використанні SNMP присутні керовані та керуючі системи. До складу керованої системи входить компонент, званий агентом, який відправляє звіти керуючої системі. По суті SNMP агенти передають управлінську інформацію на керуючі системи як змінні (такі як «вільна пам'ять», «ім'я системи», «кількість працюючих процесів»).

Агент в протоколі SNMP - це обробляє елемент, який забезпечує менеджерам, розміщеним на керуючих станціях мережі, доступ до значень змінних MIB, і тим самим дає їм можливість реалізовувати функції з управління та нагляду за пристроєм.

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

Апаратний агент - Вбудована апаратура (з процесором і пам'яттю), в якій зберігаються програмні агенти.

Змінні, доступні через SNMP, організовані в ієрархії. Ці ієрархії та інші метадані (такі, як тип і опис змінної) описуються Базами Керуючої Інформації (Management Information Bases (MIBs)).

На сьогодні існує кілька стандартів на бази даних керуючої інформації. Основними є стандарти MIB-I і MIB-II, а також версія бази даних для віддаленого управління RMON MIB. Крім цього, існують стандарти для спеціальних MIB пристроїв конкретного типу (наприклад, MIB для концентраторів або MIB для модемів), а також приватні MIB конкретних фірм-виробників обладнання.

Первісна специфікація MIB-I визначала тільки операції читання значень змінних. Операції зміни або установки значень об'єкта є частиною специфікацій MIB-II.

Версія MIB-I (RFC 1156) визначає до 114 об'єктів, які поділяються на 8 груп:

System - загальні дані про пристрій (наприклад, ідентифікатор постачальника, час останньої ініціалізації системи).

Interfaces - описуються параметри мережевих інтерфейсів пристрою (наприклад, їх кількість, типи, швидкості обміну, максимальний розмір пакета).

AddressTranslationTable - описується відповідність між мережевими і фізичними адресами (наприклад, за протоколом ARP).

InternetProtocol - дані, що відносяться до протоколу IP (адреси IP-шлюзів, хостів, статистика про IP-пакетах).

ICMP - дані, що відносяться до протоколу обміну керуючими повідомленнями ICMP.

TCP - дані, що відносяться до протоколу TCP (наприклад, про TCP-судинних).

UDP - дані, що відносяться до протоколу UDP (число переданих, прийнятих і помилкових UPD-дейтаграмм).

EGP - дані, що відносяться до протоколу обміну маршрутної інформацією ExteriorGatewayProtocol, використовуваному в мережі Internet (число прийнятих з помилками і без помилок повідомлень).

З цього переліку груп змінних видно, що стандарт MIB-I розроблявся з жорсткою орієнтацією на управління маршрутизаторами, що підтримують протоколи стека TCP / IP.

У версії MIB-II (RFC 1213), прийнятої в 1992 році, був істотно (до 185) розширено набір стандартних об'єктів, а число груп збільшилося до 10.

агенти RMON

Новітнім додаванням до функціональними можливостями SNMP яв-ляется специфікація RMON, яка забезпечує віддалене взаємодія з базою MIB.

Стандарт на RMON з'явився в листопаді 1991 року, коли Internet Engineering Task Force випустив документ RFC тисячі двісті сімдесят одна під назвою "Remote Network Monitoring Management Information Base" ( "Інформаційна база дистанційного моніторингу мереж"). Даний документ містив опис RMON для мереж Ethernet.- протокол моніторингу комп'ютерних мереж, розширення SNMP, в основі якого, як і в основі SNMP, лежить збір і аналіз інформації про характер інформації, що передається по мережі. Як і в SNMP, збір інформації здійснюється апаратно-програмними агентами, дані від яких надходять на комп'ютер, де встановлено додаток управління мережею. Відмінність RMON від свого попередника полягає, в першу чергу, в характері збирається - якщо в SNMP ця інформація характеризує тільки події, що відбуваються на тому пристрої, де встановлений агент, то RMON вимагає, щоб ці дані характеризували трафік між мережевими пристроями.

До появи RMON протокол SNMP не міг використовуватися видалений-ним чином, він допускав лише локальне управління пристроями. База RMON MIB володіє поліпшеним набором властивостей для віддаленого управління, так як містить агрегированную інформацію про устрій-стве, що не вимагає передачі по мережі великих обсягів інформації. Об'єкти RMON MIB включають додаткові лічильники помилок в пакетах, гнучкіші засоби аналізу графічних трендів і статистики, більш потужні засоби фільтрації для захоплення і аналізу окремих пакетів, а також більш складні умови встановлення сигналів попередження. Агенти RMON MIB більш інтелектуальні порівняно з агентами MIB-I або MIB-II і виконують значну частину роботи по обробці інформації про пристрій, яку раніше виконували менеджери. Ці агенти можуть розташовуватися всередині різних комунікаційних пристроїв, а також бути виконані у вигляді окремих програмних модулів, що працюють на універсальних ПК і ноутбуках (прикладом може служити LANalyzerНvell).

Інтелект агентів RMON дозволяє їм виконувати прості дей-наслідком з діагностики несправностей і попередження про можливі відмови - наприклад, в рамках технології RMON можна зібрати дані про нормальне функціонування мережі (т. Е. Виконати так званий baselining), а потім виставляти попереджувальні сигнали, коли режим роботи мережі відхилиться від baseline - це може свідчити, зокрема, про неповну справності обладнання. Зібравши воєдино інформацію, що отримується від агентів RMON, додаток управління може допомогти адміністратору мережі (що знаходиться, наприклад, за тисячі кілометрів від аналізованого сегмента мережі) локалізувати несправність і виробити оптимальний план дій для її усунення.

Збір інформації RMON здійснюється апаратно-програмними зондами, що підключаються безпосередньо до мережі. Щоб виконати завдання збору і первинного аналізу даних, зонд повинен мати достатні обчислювальними ресурсами і обсягом оперативної пам'яті. В даний час на ринку є зонди трьох типів: вбудовані, зонди на базі комп'ютера, і автономні. Продукт вважається підтримує RMON, якщо в ньому реалізована хоча б одна група RMON. Зрозуміло, чим більше груп даних RMON реалізовано в даному продукті, тим він, з одного боку, дорожче, а з іншого - тим більш повну інформацію про роботу мережі він надає.

Вбудовані зонди є модулі розширення для мережевих пристроїв. Такі модулі випускаються багатьма виробниками, зокрема, такими великими компаніями, як 3Com, Cabletron, Bay Networks і Cisco. (До речі, 3Com і Bay Networks недавно придбали компанії Axon і ARMON, визнаних лідерів в області розробки і виробництва засобів управління RMON. Такий інтерес до цієї технології з боку найбільших виробників мережевого устаткування зайвий раз показує, наскільки потрібним для користувачів є дистанційний моніторинг.) Найбільш природним виглядає рішення вбудовувати модулі RMON в концентратори, адже саме з спостереження за цими пристроями можна з-ставити собі уявлення про роботу сегмента. Гідність таких зондів очевидно: вони дозволяють отримувати інформацію по всіх основних групах даних RMON при відносно невисокій ціні. Недоліком в першу чергу є не надто висока продуктивність, що проявляється, зокрема, в тому, що вбудовані зонди часто підтримують далеко не всі групи даних RMON. Не так давно 3Com оголосила про намір випустити підтримують RMON драйвери для мережевих адаптерів Etherlink III і Fast Ethernet. В результаті виявиться можливим збирати та аналізувати дані RMON безпосередньо на робочих станціях в мережі.

Зонди на базі комп'ютера - це просто підключені до мережі комп'ютери з встановленим на них програмним агентом RMON. Такі зонди (до числа яких належить, наприклад, продукт Cornerstone Agent 2.5 компанії Network General) мають більш високою продуктивністю, ніж вбудовані зонди, і підтримують, як правило, все групи даних RMON. Вони дорожчі, ніж вбудовані зонди, але набагато дешевше автономних зондів. Крім цього, зонди на базі комп'ютера мають досить великий розмір, що може іноді обмежувати можливості їх застосування.

Автономні зонди мають найвищу продуктивність; як легко зрозуміти, це одночасно і найбільш дорогі продукти з усіх описаних. Як правило, автономний зонд - це процесор (класу i486 або RISC-процесор), оснащений достатнім обсягом оперативної пам'яті і мережним адаптером. Лідерами в цьому секторі ринку є компанії Frontier і Hewlett-Packard. Зонди цього типу невеликі за розміром і дуже мобільні - їх дуже легко підключати до мережі і відключати від неї. При вирішенні задачі управління мережею глобального масштабу це, звичайно, не дуже важлива властивість, однак якщо кошти RMON застосовуються для аналізу роботи корпоративної мережі середніх розмірів, то (з огляду на високу вартість пристроїв) мобільність зондів може зіграти дуже позитивну роль.

Об'єкту RMON присвоєно номер 16 в наборі об'єктів MIB, а сам об'єкт RMON об'єднує відповідно до документа RFC 1271, складається з десяти груп даних.

Statistics - поточні накопичені статистичні дані про характеристики пакетів, кількості колізій і т.п.

History - статистичні дані, збережені через певні проміжки часу для подальшого аналізу тенденцій їх змін.

Alarms - порогові значення статистичних показників, при перевищенні яких агент RMON посилає повідомлення менеджеру. Дозволяє користувачеві визначити ряд порогових рівнів (ці пороги можуть ставитися до самих різних речей - будь-якого параметру з групи статистики, амплітуді або швидкості його зміни і багато чому іншому), по перевищенні яких генерується аварійний сигнал. Користувач може також визначити, за яких умов перевищення порогового значення має супроводжуватися аварійним сигналом - це дозволить уникнути генерації сигналу "по дрібницях", що погано, по-перше, тому, що на постійно палаючу червону лампочку ніхто не звертає уваги, а по-друге , тому, що передача непотрібних аварійних сигналів по мережі призводить до зайвої завантаженні ліній зв'язку. Аварійний сигнал, як правило, передається в групу подій, де і визначається, що з ним робити далі.

Host - даних про хостах мережі, в тому числі і про їх MAC-адресах ..

HostTopN - таблиця найбільш завантажених хостів мережі. Таблиця N головних хостів (HostTopN) містить список N перших хостів, що характеризуються максимальним значенням заданого статистичного параметра для заданого інтервалу. Наприклад, можна зажадати список 10 хостів, для яких спостерігалося максимальну кількість помилок протягом останніх 24 годин. Список цей буде складено самим агентом, а додаток управління отримає тільки адреси цих хостів і значення відповідних статистичних параметрів. Видно, до якої міри такий підхід економить мережеві ресурси

TrafficMatrix - статистика про інтенсивність трафіку між кожною парою хостів мережі, впорядкована у вигляді матриці. Рядки цієї матриці пронумеровані відповідно до MAC-адресами станцій - джерел повідомлень, а стовпці - відповідно до адресами станцій-одержувачів. Матричні елементи характеризують інтенсивність трафіку між відповідними станціями і кількість помилок. Проаналізувавши таку матрицю, користувач легко може з'ясувати, які пари станцій генерують найбільш інтенсивний трафік. Ця матриця, знову-таки, формується самим агентом, тому відпадає необхідність у передачі великих обсягів даних на центральний комп'ютер, який відповідає за управління мережею.

Filter - умови фільтрації пакетів. Ознаки, за якими фільтруються пакети, можуть бути найрізноманітнішими - наприклад, можна зажадати фільтрувати як помилкові всі пакети, довжина яких виявляється менше деякого заданого значення. Можна сказати, що установка фільтра відповідає як би організації каналу для передачі пакета. Куди веде цей канал - визначає користувач. Наприклад, всі помилкові пакети можуть перехоплюватися і направлятися в відповідний буфер. Крім того, поява пакету, відповідного встановленому фільтру, може розглядатися як подія (event), на яке система повинна реагувати заздалегідь обумовленим чином.

PacketCapture - умови захоплення пакетів. До складу групи перехоплення пакетів (packet capture) входять буфера для захоплення, куди направляються пакети, чиї ознаки задовольняють умовам, сформульованим у групі фільтрів. При цьому захоплюватися може не пакет цілком, а, скажімо, тільки перші кілька десятків байт пакету. Вміст буферів перехоплення можна згодом аналізувати за допомогою різних програмних засобів, з'ясовуючи цілий ряд вельми корисних характеристик роботи мережі. Перебудовуючи фільтри на ті чи інші ознаки, можна характеризувати різні параметри роботи мережі.

Event - умови реєстрації і генерації подій. У групі подій (events) визначається, коли слід відправляти аварійний сигнал з додатком управління, коли - перехоплювати пакети, і взагалі - як реагувати на ті чи інші події, що відбуваються в мережі, наприклад, на перевищення заданих в групі alarms порогових значень: чи слід ставити до відома додаток управління, або треба просто запротоколювати дана подія і продовжувати працювати. Події можуть і не бути пов'язані з предачі аварійних сигналів - наприклад, напрямок пакету в буфер перехоплення теж є подія.

Дані групи пронумеровані в зазначеному порядку, тому, наприклад, група Hosts має числове ім'я 1.3.6.1.2.1.16.4.

Десяту групу складають спеціальні об'єкти протоколу TokenRing.

Всього стандарт RMON MIB визначає близько 200 об'єктів в 10 групах, зафіксованих в двох документах - RFC 1271 для мереж Ethernet і RFC 1513 для мереж TokenRing.

Відмінною рисою стандарту RMON MIB є його незалежність від протоколу мережевого рівня (на відміну від стандартів MIB-I і MIB-II, орієнтованих на протоколи TCP / IP). Тому, його зручно використовувати в гетерогенних середовищах, що використовують різні протоколи мережевого рівня.

1.2 Популярні системи управління мережами

Система управління мережею (Network management system) - апаратні і / або програмні засоби для моніторингу та управління вузлами мережі. Програмне забезпечення системи управління мережею складається з агентів, що локалізуються на мережевих пристроях і передають інформацію мережевий керуючої платформі. Метод інформаційного обміну між керуючими додатками і агентами на пристроях визначається протоколами.

Системи управління мережами повинні мати цілу низку якостей:

істинної распределенностью відповідно до концепції клі-ент / сервер,

масштабованість,

відкритістю, що дозволяє впоратися з різнорідним - від настільних комп'ютерів до мейнфреймів - обладнанням.

Перші дві властивості тісно пов'язані. Хороша масштабованість досягається за рахунок распределенности системи управління. Розподіленість означає, що система може включати кілька серверів і клієнтів. Сервери (менеджерами) збирають дані про поточний стан мережі від агентів (SNMP, CMIP або RMON), вбудованих в обладнання мережі, і накопичують їх у своїй базі даних. Клієнти представляють собою графічні консолі, за якими працюють адміністратори мережі. Програмне забезпечення клієнта системи управління приймає запити на виконання будь-яких дій від адміністратора (наприклад, побудова докладної карти частини мережі) і звертається за необхідною інформацією до сервера. Якщо сервер має потрібної інформацією, то він відразу ж передає її клієнту, якщо немає - то намагається зібрати її від агентів.

Ранні версії систем управління поєднували всі функції в одному комп'ютері, за яким працював адміністратор. Для невеликих мереж або мереж з невеликою кількістю керованого устаткування така структура виявляється цілком задовільною, але при великій кількості керованого устаткування єдиний комп'ютер, до якого надходить інформація від усіх пристроїв мережі, стає вузьким місцем. І мережа не справляється з великим потоком даних, і сам комп'ютер не встигає їх обробляти. Крім того, великою мережею керує зазвичай не один адміністратор, тому, крім декількох серверів у великій мережі повинно бути кілька консолей, за якими працюють адміністратори мережі, причому на кожній консолі повинна бути представлена \u200b\u200bспецифічна інформація, відповідна поточним потребам конкретного адміністратора.

Підтримка різнорідного обладнання - скоріше бажане, ніж реально існуюче властивість сьогоднішніх систем управління. До числа найбільш популярних продуктів мережевого управління відносяться чотири системи: Spectrum компанії CabletronSystems, OpenView фірми Hewlett-Packard, NetView корпорації IBM і Solstice виробництва SunSoft - підрозділи SunMicrosystems. Три компанії з чотирьох самі випускають комунікаційне обладнання. Природно, що система Spectrum найкраще управляє обладнанням компанії Cabletron, OpenView - обладнанням компанії Hewlett-Packard, а NetView- обладнанням компанії IBM.

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

Для виправлення цього недоліку розробники систем управління включають підтримку не тільки стандартних баз MIB I, MIB II і RMON MIB, а й численних приватних MIB фірм-виробників. Лідер в цій області - система Spectrum, що підтримує близько 1000 баз MIB різних виробників.

Іншим способом більш якісної підтримки конкретної апаратури є використання на основі будь-якої платформи управління додатки тієї фірми, яка випускає це обладнання. Провідні компанії - виробники комунікаційного обладнання - розробили і поставляють вельми складні і багатофункціональні системи управління для свого обладнання. До найбільш відомих систем цього класу відносяться Optivity компанії BayNetworks, CiscoWorks компанії CiscoSystems, Transcend компанії 3Com. Система Optivity, наприклад, дозволяє робити моніторинг і управляти мережами, що складаються з маршрутизаторів, комутаторів і концентраторів компанії BayNetwork, повністю використовуючи всі їх можливості і властивості. Устаткування інших виробників під-тримувати на рівні базових функцій управління. Система Optivity працює на платформах OpenView компанії Hewlett-Packard і SunNetManager (попередник Solstice) компанії SunSoft. Однак, робота на основі будь-якої платформи управління з декількома системами, такими як Optivity, занадто складна і вимагає, щоб комп'ютери, на яких все це буде працювати, мали дуже потужними процесорами і великий оперативною пам'яттю.

Проте, якщо в мережі переважає обладнання від будь-якого одного виробника, то наявність додатків управління цього виробника для будь-якої популярної платформи управління дозволяє адміністраторам мережі успішно вирішувати багато завдань. Тому розробники платформ управління поставляють разом з ними інструментальні засоби, що спрощують розробку додатків, а наявність таких додатків і їх кількість вважаються дуже важливим фактором при виборі платформи управління.

Відкритість платформи управління залежить також від форми зберігання зібраних даних про стан мережі. Більшість платформ-лідерів дозволяють зберігати дані в комерційних базах даних, таких як Oracle, Ingres або Informix. Використання універсальних СУБД знижує швидкість роботи системи управління в порівнянні зі зберіганням даних в файлах операційної системи, але зате дозволяє обробляти ці дані будь-якими додатками, які вміють працювати з цими СУБД.

2. Постановка задачі

У відповідності зі сформованою ситуацією, було вирішено розробити і впровадити систему моніторингу мережі, яка вирішувала б всі вищевикладені проблеми.

2.1 Технічне завдання

Розробити і впровадити систему моніторингу, що дозволяє проводити спостереження як за комутаторами, маршрутизаторами різних виробників, так і серверів різних платформ. Орієнтуватися на використання відкритих протоколів і систем, з максимальним використанням готових напрацювань з фонду вільного програмного забезпечення.

2.2 Уточнене технічне завдання

В ході подальшої формулювання проблеми і дослідження предметної області, з урахуванням економічних і тимчасових вкладень було проведено уточнення технічного завдання:

Система повинна відповідати таким вимогам:

§ мінімальні вимоги до апаратних ресурсів;

§ відкриті вихідні коди всіх складових комплексу;

§ розширюваність і масштабованість системи;

§ стандартні засоби надання діагностичної інформації;

§ наявність докладної документації на всі використовувані програмні продукти;

§ здатність працювати з обладнанням різних виробників.

3. ПРОПОНОВАНА СИСТЕМА

1 Вибір системи моніторингу мережі

Відповідно до уточненого технічним завданням, найкраще в якості ядра системи моніторингу мережі підходить система Nagios, так як вона володіє такими якостями:

§ є засоби генерування діаграм;

§ є засоби генерування звітностей;

§ є можливість логічного групування;

§ існує вбудована система запису трендів і їх прогнозування;

§ є можливість автоматичного додавання нових пристроїв (Autodiscovery) за допомогою офіційного плагіна;

§ є можливість розширеного моніторингу хоста з використанням агента;

§ підтримка протоколу SNMP через плагін;

§ підтримка протоколу Syslog через плагін;

§ підтримка зовнішніх скриптів;

§ підтримка самописних плагінів і можливість їх швидкого і простого створення;

§ вбудовані тригери і події;

§ повнофункціональний веб-інтерфейс;

§ можливість розподіленого моніторингу;

§ інвентаризація через плагін;

§ можливість зберігання даних як в файлах, так і в базах даних SQL, що дуже важливо при збільшенні обсягів;

§ ліцензія GPL, а отже безкоштовна базова поставка, підтримка і відкриті вихідні коди ядра системи і супроводжуючих компонентів;

§ динамічні і настроюються карти;

§ управління доступом;

§ вбудовану мову опису хостів, сервісів і перевірок;

§ записує реального.

Система моніторингу мережі Zabbix володіє схожим набором параметрів, але на момент впровадження володіла набагато більш меншим функціоналом, ніж Nagios і мала статус beta-версії. Крім того, дослідження тематичних форумів і новинних стрічок показало найбільшу поширеність серед користувачів саме Nagios, що означає наявність написаної користувачами документації і максимально докладно описаних складних моментів у налаштуванні.

Nagios дозволяє робити моніторинг таких мережевих сервісів як SMTP, TELNET, SSH, HTTP, DNS, POP3, IMAP, NNTP і багатьох інших. Крім цього, можна стежити за використанням ресурсів серверів, таких як витрата дискового простору, вільна пам'ять і завантаженість процесора. Існує можливість створювати свої власні обробники подій. Ці обробники виконуватимуться при виникненні тих чи інших подій, ініційованих перевірками сервісів або серверів. Такий підхід дозволить активно реагувати на події, що відбуваються і намагатися автоматично вирішувати виниклі проблеми. Наприклад, можна створити обробник подій, який буде самостійно перезапускати повис сервіс. Ще однією перевагою системи моніторингу Nagios є можливість управляти нею віддалено за допомогою wap інтерфейсу мобільного телефону. Використовуючи концепцію "батьківських" хостів, легко описати ієрархію і залежності між усіма хостами. Такий підхід надзвичайно корисний для великих мереж, тому що дозволяє виробляти складну діагностику. А це якість, в свою чергу, допомагає відрізнити непрацюючі хости, від тих, що недоступні в даний момент з-за неполадок в роботі проміжних ланок. Nagios вміє будувати графіки роботи спостережуваних систем і карти контрольованої мережевої інфраструктури.

Зі своєї практики роботи з Nagios автор може привести приклад, що показує, наскільки корисний він виявився для в його особистій практиці. На зовнішньому мережевому інтерфейсі брандмауера з періодичністю в кілька годин починалася втрата пакетів. Через несправність втрачалося до 20 відсотків трафіку. Після закінчення хвилини - інший інтерфейс знову починав працювати як належить. Унаслідок плаваючого характеру цієї неполадки кілька тижнів не вдавалося з'ясувати, чому при роботі з Інтернет періодично відбуваються короткочасні збої. Без Nagios пошук несправності затягнувся б надовго.

Багатьом з адміністраторів добре знайомий предок Nagios по імені NetSaint. Незважаючи на те, що сайт проекту NetSaint все ще справно функціонує, нові розробки базуються вже на вихідному коді Nagios. Тому всім рекомендується потихеньку перебиратися на Nagios.

У документації, що поставляється з Nagios, йдеться, що він буде стабільно працювати і з багатьма іншими Unix подібними системами. Для відображення web-інтерфейсу Nagios нам знадобиться сервер Apache. Ви вільні, використовувати будь-який інший, але в даній роботі буде розглядатися саме Apache, як найбільш поширений на Unix платформах web-сервер. Можна встановити систему моніторингу взагалі без web-інтерфейсу, але ми так робити не будемо, тому що це істотно зменшує зручність користування.

4. РОЗРОБКА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

В якості апаратної частини системи, що впроваджується можна використовувати звичайний IBM-сумісний комп'ютер, проте з урахуванням можливості подальшого підвищення навантаження і вимог надійності та напрацювання на відмову, а також Госсвязьнадзоре, було придбано сертифіковане серверне обладнання фірми Aquarius.

В існуючій мережі активно використовується операційна система Debian на базі ядра Linux, є великий досвід використання цієї системи, налагоджено більшість операцій з управління, налаштування та забезпечення стабільності її роботи. Крім того, дана ОС поширюється по ліцензії GPL, що говорить про її безкоштовності і відкритості вихідних кодів, що відповідає уточненим технічним завданням на проектування системи моніторингу мережі. (Повна назва GNU / Linux, вимовляється «гну слеш чи ́ нукс », також в деяких мовах« GNU + Linux »,« GNU-Linux »і ін.) - загальна назва UNIX-подібних операційних систем на основі однойменного ядра і зібраних для нього бібліотек і системних програм, розроблених в рамках проекту GNU./ Linux працює на PC-сумісних системах сімейства Intel x86, а також на IA-64, AMD64, PowerPC, ARM і багатьох інших.

До операційній системі GNU / Linux також часто відносять програми, що доповнюють цю операційну систему, і прикладні програми, що роблять її повноцінної багатофункціональної операційним середовищем.

На відміну від більшості інших операційних систем, GNU / Linux не має єдиної «офіційної» комплектації. Замість цього GNU / Linux поставляється у великій кількості так званих дистрибутивів, в яких програми GNU з'єднуються з ядром Linux і іншими програмами. Найбільш відомими збірками GNU / Linux є Ubuntu, Debian GNU / Linux, Red Hat, Fedora, Mandriva, SuSE, Gentoo, Slackware, Archlinux. Російські дистрибутиви - ALT Linux і ASPLinux.

На відміну від Microsoft Windows (Windows NT), Mac OS (Mac OS X) і комерційних UNIX-подібних систем, GNU / Linux не має географічного центру розробки. Немає і організації, яка володіла б цією системою; немає навіть єдиного координаційного центру. Програми для Linux - результат роботи тисяч проектів. Деякі з цих проектів централізовані, деякі зосереджені в фірмах. Багато проектів об'єднують хакерів з усього світу, які знайомі тільки по переписці. Створити свій проект або приєднатися до вже існуючого може будь-хто і, в разі успіху, результати роботи стануть відомі мільйонам користувачів. Користувачі беруть участь в тестуванні вільних програм, спілкуються з розробниками напряму, що дозволяє швидко знаходити і виправляти помилки і реалізовувати нові можливості.

Історія розвитку UNIX-систем. GNU / Linux є UNIX-сумісної, проте ґрунтується на власному вихідному коді

Саме така гнучка і динамічна система розробки, неможлива для проектів з закритим кодом, визначає виняткову економічну ефективність [джерело не вказано 199 днів] GNU / Linux. Низька вартість вільних розробок, налагоджені механізми тестування та поширення, залучення людей з різних країн, що володіють різним баченням проблем, захист коду ліцензією GPL - все це стало причиною успіху вільних програм.

Звичайно, така висока ефективність розробки не могла не зацікавити великі фірми, які стали відкривати свої проекти. Так з'явилися Mozilla (Netscape, AOL), OpenOffice.org (Sun), вільний клон Interbase (Borland) - Firebird, SAP DB (SAP). IBM сприяла перенесенню GNU / Linux на свої мейнфрейми.

З іншого боку, відкритий код значно знижує собівартість розробки закритих систем для GNU / Linux і дозволяє знизити ціну рішення для користувача. Ось чому GNU / Linux стала платформою, часто рекомендованої для таких продуктів, як СУБД Oracle, DB2, Informix, SyBase, SAP R3, Domino.

Спільнота GNU / Linux підтримує зв'язок за допомогою груп користувачів Linux.

Більшість користувачів для установки GNU / Linux використовують дистрибутиви. Дистрибутив - це не просто набір програм, а ряд рішень для різних завдань користувачів, об'єднаних єдиними системами установки, управління і поновлення пакетів, настройки та підтримки.

Найпоширеніші в світі дистрибутиви: - швидко завоював популярність дистрибутив, орієнтований на легкість в освоєнні і іспользованіі.- безкоштовно розповсюджувана версія дистрибутива SuSE, що належить компанії Novell. Відрізняється зручністю в налаштуванні і обслуговуванні завдяки використанню утиліти YaST.- підтримується спільнотою і корпорацією RedHat, передує випусків комерційної версії RHEL.GNU / Linux - міжнародний дистрибутив, що розробляється великим співтовариством розробників в некомерційних цілях. Послужив основою для створення безлічі інших дистрибутивів. Відрізняється строгим підходом до включення невільного ПО.- французько-бразильський дистрибутив, об'єднання колишніх Mandrake і Conectiva (англ.) .- один з найстаріших дистрибутивів, відрізняється консервативним підходом в розробці і іспользованіі.- дистрибутив, що збирається з вихідних кодів. Дозволяє дуже гнучко налаштовувати кінцеву систему і оптимізувати продуктивність, тому часто називає себе мета-дистрибутивом. Орієнтований на експертів і досвідчених пользователей.- орієнтований на застосування найновіших версій програм і постійно оновлюваний, що підтримує однаково як бінарну, так і установку з вихідних кодів і побудований на філософії простоти KISS, цей дистрибутив орієнтований на компетентних користувачів, які хочуть мати всю силу і модифицируемость Linux, але не в жертву часу обслуговування.

Крім перерахованих, існує безліч інших дистрибутивів, як базуються на перерахованих, так і створених з нуля і часто призначених для виконання обмеженої кількості завдань.

Кожен з них має свою концепцію, свій набір пакетів, свої достоїнства і недоліки. Жоден з них не може задовольнити всіх користувачів, а тому поруч з лідерами благополучно існують інші фірми і об'єднання програмістів, що пропонують свої рішення, свої дистрибутиви, свої послуги. Існує безліч LiveCD, побудованих на основі GNU / Linux, наприклад, Knoppix. LiveCD дозволяє запускати GNU / Linux безпосередньо з компакт-диска, без установки на жорсткий диск.

Для бажаючих досконально розібратися з GNU / Linux підійде будь-який з дистрибутивів, проте досить часто для цієї мети використовуються так звані source-based дистрибутиви, тобто передбачають самостійну збірку всіх (або частини) компонентів з вихідних кодів, такі як LFS, Gentoo, ArchLinux або CRUX.

4.1 Установка ядра системи

Nagios можна встановлювати двома способами - з вихідних кодів і з зібраних пакетів. У обох способів є переваги і недоліки, розглянемо їх.

Плюси установки пакета їх вихідних кодів:

§ можливість детального конфігурації системи;

§ висока ступінь оптимізації додатки;

§ найбільш повне уявлення роботи програми.

Мінуси установки пакета їх вихідних кодів:

§ потрібен додатковий час на складання пакету, часто перевищує час на його настройку та налагодження;

§ неможливість видалити пакет разом з файлами;

§ неможливість оновити пакет разом з файлами;

§ неможливість централізованого контролю за встановленими додатками.

При установці Nagios з попередньо складеного пакета, гідності «сирого» методу установки стають недоліками, і навпаки. Однак, як показала практика, зібраний заздалегідь пакет задовольняє всім вимогам, що пред'являються до системи і немає сенсу витрачати час на ручну зборку пакету.

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

4.1.1 Опис установки ядра системи їх вихідних кодів

Необхідні пакети.

Необхідно впевнитися, що такі пакети встановлені до початку розгортання Nagios. Детальний розгляд процесу їх установки виходить за рамки даної роботи.

· Apache 2

· PHP

· GCC компілятор і бібліотеки розробника

· GD бібліотеки розробника

Можна використовувати утиліту apt-get (краще aptitude) для їх установки наступним чином:

% Sudo apt-get install apache2

% Sudo apt-get install libapache2-mod-php5

% Sudo apt-get install build-essential

% Sudo apt-get install libgd2-dev

1) Створення нового користувача непрівілігірованного аккаунта

Новий акаунт створюється для запуску служби Nagios. Можна це робити і з-під облікового запису суперкористувача, що створить серйозну загрозу для безпеки системи.

Станом суперкористувачем:

Створимо новий обліковий запис користувача nagios і дамо їй пароль:

# / Usr / sbin / useradd -m -s / bin / bash nagios

# Passwd nagios

Створимо групу nagios і додамо в неї користувача nagios:

# / Usr / sbin / groupadd nagios

# / Usr / sbin / usermod -G nagios nagios

Створимо групу nagcmd для дозволу виконання зовнішніх команд, переданих через веб-інтерфейс. Додамо в цю групу користувачів nagios і apache:

# / Usr / sbin / groupadd nagcmd

# / Usr / sbin / usermod -a -G nagcmd nagios

# / Usr / sbin / usermod -a -G nagcmd www-data

2) скачати Nagios і плагіни до нього

Створимо директорію для зберігання файлів, що скачали:

# Mkdir ~ / downloads

# Cd ~ / downloads

Качаємо стислі вихідні коди Nagios і його плагінів (# "justify"\u003e # wget # "justify"\u003e # wget # "justify"\u003e 3) Компілюємо і встановлюємо Nagios

Розпакуємо стислі вихідні коди Nagios:

# Cd ~ / downloads

# Tar xzf nagios-3.2.0.tar.gz

# Cd nagios-3.2.0

Запускаємо конфігураційний скрипт Nagios, передавши йому ім'я групи, яку ми створили раніше:

# ./Configure --with-command-group \u003d nagcmd

Повний список параметрів конфігураційного скрипта:

#. / Configure --help

`Configure" configures this package to adapt to many kinds of systems .: ./configure ... ... assign environment variables (eg, CC, CFLAGS ...), specify them as \u003d VALUE. See below for descriptions of some of the useful variables.for the options are specified in brackets .:

h, --help display this help and exit

Help \u003d short display options specific to this package

Help \u003d recursive display the short help of all the included packages

V, --version display version information and exit

q, --quiet, --silent do not print `checking ..." messages

Cache-file \u003d FILE cache test results in FILE

C, --config-cache alias for `--cache-file \u003d config.cache"

n, --no-create do not create output files

Srcdir \u003d DIR find the sources in DIR directories:

Prefix \u003d PREFIX install architecture-independent files in PREFIX

Exec-prefix \u003d EPREFIX install architecture-dependent files in EPREFIXdefault, `make install" will install all the files in `/ usr / local / nagios / bin", `/ usr / local / nagios / lib" etc. You can specify an installation prefix other than `/ usr / local / nagios" using `--prefix", for instance `--prefix \u003d $ HOME" .better control, use the options below.tuning of the installation directories:

Bindir \u003d DIR user executables

Sbindir \u003d DIR system admin executables

Libexecdir \u003d DIR program executables

Datadir \u003d DIR read-only architecture-independent data

Sysconfdir \u003d DIR read-only single-machine data

Sharedstatedir \u003d DIR modifiable architecture-independent data

Localstatedir \u003d DIR modifiable single-machine data

Libdir \u003d DIR object code libraries

Includedir \u003d DIR C header files

Oldincludedir \u003d DIR C header files for non-gcc

Infodir \u003d DIR info documentation

Mandir \u003d DIR man documentation types:

Build \u003d BUILD configure for building on BUILD

Host \u003d HOST cross-compile to build programs to run on HOST Features:

Disable-FEATURE do not include FEATURE (same as --enable-FEATURE \u003d no)

Enable-FEATURE [\u003d ARG] include FEATURE

Disable-statusmap \u003d disables compilation of statusmap CGI

Disable-statuswrl \u003d disables compilation of statuswrl (VRML) CGI

Enable-DEBUG0 shows function entry and exit

Enable-DEBUG1 shows general info messages

Enable-DEBUG2 shows warning messages

Enable-DEBUG3 shows scheduled events (service and host checks ... etc)

Enable-DEBUG4 shows service and host notifications

Enable-DEBUG5 shows SQL queries

Enable-DEBUGALL shows all debugging messages

Enable-nanosleep enables use of nanosleep (instead sleep) in event timing

Enable-event-broker enables integration of event broker routines

Enable-embedded-perl will enable embedded Perl interpreter

Enable-cygwin enables building under the CYGWIN environmentPackages:

With-PACKAGE [\u003d ARG] use PACKAGE

Without-PACKAGE do not use PACKAGE (same as --with-PACKAGE \u003d no)

With-nagios-user \u003d sets user name to run nagios

With-nagios-group \u003d sets group name to run nagios

With-command-user \u003d sets user name for command access

With-command-group \u003d sets group name for command access

With-mail \u003d Sets path to equivalent program to mail

With-init-dir \u003d Sets directory to place init script into

With-lockfile \u003d Sets path and file name for lock file

With-gd-lib \u003d DIR sets location of the gd library

With-gd-inc \u003d DIR sets location of the gd include files

With-cgiurl \u003d sets URL for cgi programs (do not use a trailing slash)

With-htmurl \u003d sets URL for public html

With-perlcache turns on cacheing of internally compiled Perl scriptsinfluential environment variables: C compiler commandC compiler flagslinker flags, e.g. -L if you have libraries in adirectory C / C ++ preprocessor flags, e.g. -I if you havein a nonstandard directory C preprocessorthese variables to override the choices made by `configure" or to helpto find libraries and programs with nonstandard names / locations.

Компілюємо вихідний код Nagios.

Встановимо бінарні файли, скрипт ініціалізації, приклади конфігураційних файлів і встановимо дозволу на директорію зовнішніх команд:

# Make install-init

# Make install-config

# Make install-commandmode

) Змінимо конфігурацію

Приклади конфігураційних файлів встановлені в директорію / usr / local / nagios / etc. Вони повинні відразу бути робочими. Потрібно зробити лише одна зміна перед тим, як продовжити.

Відредагуємо конфігураційний файл /usr/local/nagios/etc/objects/contacts.cfg будь-яким текстовим редактором і змінимо email адреса прив'язаний до визначення контакту nagiosadmin на адресу, на який ми збираємося приймати повідомлення про неполадки.

# Vi /usr/local/nagios/etc/objects/contacts.cfg

5) Налаштування веб-інтерфейсу

Встановимо конфігураційний файл веб-інтерфейсу Nagios в директорію Apache conf.d.

# Make install-webconf

Створимо обліковий запис nagiosadmin для входу в веб-інтерфейс Nagios

# Htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

Перезапустити Apache, щоб зміни вступили в силу.

# /Etc/init.d/apache2 reload

Необхідно вжити заходів щодо посилення безпеки CGI, щоб запобігти крадіжці цього облікового запису, тому що інформація про моніторинг є досить чутливою.

) Компілюємо і встановлюємо плагіни Nagios

Розпакуємо стислі вихідні коди плагінів Nagios:

# Cd ~ / downloads

# Tar xzf nagios-plugins-1.4.11.tar.gz

Компілюємо і встановлюємо плагіни:

# ./Configure --with-nagios-user \u003d nagios --with-nagios-group \u003d nagios

#make install

) Запускаємо службу Nagios

Налаштуємо Nagios на автоматичне завантаження при включенні операційної системи:

# Ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios

Перевіримо синтаксичну правильність зразкових конфігураційних файлів:

# / Usr / local / nagios / bin / nagios -v /usr/local/nagios/etc/nagios.cfg

Якщо помилок немає, то запускаємо Nagios:

# /Etc/init.d/nagios start

) Входимо на веб-інтерфейс

Тепер можна увійти в веб-інтерфейс Nagios, використовуючи наступний URL. Буде виданий запит на введення імені користувача (nagiosadmin) і пароля, які ми поставили раніше.

# "Justify"\u003e) Інші настройки

Для отримання нагадувань по email про події Nagios, необхідно встановити пакет mailx (Postfix):

% Sudo apt-get install mailx

% Sudo apt-get install postfix

Необхідно відредагувати команди нагадувань Nagios файлі /usr/local/nagios/etc/objects/commands.cfg і змінити всі посилання з "/ bin / mail" на "/ usr / bin / mail". Після цього необхідно перезапустити службу Nagios:

# Sudo /etc/init.d/nagios restart

Детальна конфігурація поштового модуля описана в Додатку Г.

4.1.2 Опис установки ядра системи з репозитария

Як було показано вище, установка Nagios з вихідних текстів займає чимало часу і має сенс тільки при вимозі ретельної оптимізації додатки або бажанні досконально розібратися з механізмом роботи системи. У робочих умовах більшість програмного забезпечення встановлюється з репозитаріїв у вигляді предкомпілірованних пакетів. У цьому випадку установка зводиться до введення однієї команди:

% Sudo aptitude install nagios

Менеджер пакетів самостійно задовольнить всі залежності та встановить необхідні пакети.

4.2 Конфігурація ядра системи

Перед детальної налаштуванням слід розуміти те, як працює ядро \u200b\u200bNagios. Його графічне опис наведено нижче в ілюстрації 6.2.

4.2.1 Опис роботи ядра системи

На наступному малюнку показана спрощена схема роботи служби Nagios.

Мал. 4.1 - Ядро системи

Служба Nagios читає основний конфігураційний файл, в якому крім основних параметрів роботи служби є посилання на файли ресурсів, файли опису об'єктів і конфігураційні файли CGI.

Алгоритм і логіка роботи ядра мережевого моніторингу показані нижче.

Мал. 4.2 - Алгоритм сповіщень Nagios

2.2 Опис взаємодії конфігураційних файлів

В директорії /etc/apache2/conf.d/ знаходиться файл nagios3.conf, з якого веб-сервер apache бере настройки для nagios.

Файли nagios знаходяться в директорії / etc / nagios3.

Файл /etc/nagios3/htpasswd.users містить паролі для користувачів nagios. Команда для створення файлу та установки пароля для користувача nagios за замовчуванням наведена вище. Надалі, необхідно буде опустити аргумент "-c" при завданні пароля для нового користувача, інакше новий файл затре старий.

Файл /etc/nagios3/nagios.cfg містить основну конфігурацію самого nagios. Наприклад, файли журналів подій або шлях до решти конфігураційним файлів, які nagios зачитує при старті.

В директорії / etc / nagios / objects задаються нові хости і сервіси.

4.2.3 Заповнення описів хостів і служб

Як було показано вище, налаштовувати ядро \u200b\u200bсистеми можна використовуючи один файл опису для хостів і служб, однак цей спосіб не буде зручний з ростом кількості відслідковується обладнання, тому необхідно створити якусь структуру каталогів і файлів з описами хостів і служб.

Створена структура показана в Додатку З.

файл hosts.cfg

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

Тут описаний хост це не справжній хост, а шаблон, на якому грунтуються опису всіх інших хостів. Такий же механізм можна зустріти і в інших конфігураційних файлах, коли конфігурація ґрунтується на попередньо визначеному безлічі значень за замовчуванням.

файл hostgroups.cfg

Тут додаються хости в групу хостів (hostgroup). Навіть в простій конфігурації, коли хост один, все одно потрібно додавати його в групу, щоб Nagios знав яку контактну групу (contact group) потрібно використовувати для відправки повідомлень. Про контактній групі докладніше нижче.

файл contactgroups.cfg

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

Наступним кроком потрібно вказати контактну інформацію та налаштування сповіщень.

файл contacts.cfg

Крім того, що в цьому файлі наводиться додаткова контактна інформація користувачів, одне з полів, contact_name, має ще одне призначення. CGI-cкриптов використовують імена, задані в цих полях для того щоб визначити, чи має користувач право доступу до якогось ресурсу чи ні. Ви повинні налаштувати аутентифікацію, що грунтується на.htaccess, але крім цього потрібно використовувати ті ж імена, які використані вище, для того щоб користувачі могли працювати через Web-інтерфейс.

Тепер, коли хости і контакти налагоджені, можна переходити до налаштування моніторингу окремих сервісів, за якими має проводитися спостереження.

файл services.cfg

Тут ми як і в файлі hosts.cfg для хостів, задали лише загальні параметри для всіх служб.

Доступна величезна кількість додаткових модулів Nagios, але якщо якийсь перевірки все ж немає, її можна завжди написати самостійно. Наприклад, немає модуля, який перевіряє працює чи ні Tomcat. Можна написати скрипт, який завантажує jsp сторінку з віддаленого Tomcat-сервера і повертає результат в залежності від того, якщо в завантаженої сторінці якийсь текст на сторінці чи ні. (При додаванні нової команди потрібно обов'язково згадати її в файлі checkcommand.cfg, який ми не чіпали).

Далі по кожному окремому хосту ми створюємо свій файл-опис, в цьому ж файлі ми будемо зберігати опису служб, за якими ми будемо проводити моніторинг для цього хоста. Зроблено це для зручності і логічної організації.

Варто відзначити, що Windows хости проходять моніторинг за допомогою протоколу SNMP і NSClient a, що поставляється з Nagios. Нижче представлена \u200b\u200bсхема його роботи

Мал. 4.3 - Схема моніторингу Windows хостів

У той же час * nix хости проходять моніторинг також за допомогою SNMP, а також NRPE плагіна. Схема його роботи показана на малюнку

Мал. 4.4 - Схема моніторингу * nix хостів

2.4 Написання плагінів

Крім написання скриптів ініціалізації, визначення хостів і служб, були використані наступні плагіни:

├── check_disk

├── check_dns

├── check_http

├── check_icmp

├── check_ifoperstatus

├── check_ifstatus

├── check_imap -\u003e check_tcp

├── check_linux_raid

├── check_load

├── check_mrtg

├── check_mrtgtraf

├── check_nrpe

├── check_nt

├── check_ping

├── check_pop -\u003e check_tcp

├── check_sensors

├── check_simap -\u003e check_tcp

├── check_smtp

├── check_snmp

├── check_snmp_load.pl

├── check_snmp_mem.pl

├── check_spop -\u003e check_tcp

├── check_ssh

├── check_ssmtp -\u003e check_tcp

├── check_swap

├── check_tcp

├── check_time

Велика частина з них поставляється разом з пакетом Nagios. Вихідні тексти плагінів, що не входять в комплект поставки і використаних в системі, представлені в Додатку І.

4.2.5 Встановлення SNMP на віддалених хостах

Щоб мати можливість проводити моніторинг по протоколу SNMP, на мережевому обладнанні необхідно попередньо налаштувати агентів цього протоколу. Схема роботи SNMP в зв'язці з ядром системи моніторингу мережі показана на малюнку нижче.

Мал. 4.5 - Схема моніторингу за допомогою протоколу SNMP

Конфігураційні параметри хостів представлені в Додатку З. Безпека здійснюється шляхом індивідуальної настройки пакетного фільтра на кожному з вузлів окремо і за допомогою організації захищених системних підмереж, в які має доступ тільки авторизований персонал підприємства. Крім того настройка проведена таким чином, що за допомогою SNMP протоколу можна робити тільки читання параметрів, а не їх запис.

4.2.6 Налаштування агента на віддалених хостах

Для отримання можливостей розширеного моніторингу хостів і служб, необхідно встановити на них агента Nagios, який називається nagios-nrpe-server:

# Aptitude install nagios-nrpe-server

Конфігурація агента представлена \u200b\u200bв Додатку Л. Схема роботи агента показана на рисунку 4.5 вище.

4.4 Установка і настройка модуля відстеження завантаження

MRTG (Multi Router Traffic Grapher) - сервіс, що дозволяє за допомогою протоколу SNMP отримувати з декількох пристроїв інформацію і відображати у вікні вашого браузера графіки завантаженості каналу (вхідний трафік, що виходить, максимальний, середній) з кроком в хвилини, години, дні і за рік.

Вимоги до установки

Для роботи MRTG потрібні такі бібліотеки:

§ gd - graph drawing library. Бібліотека, відповідальна за формування графіки (# "justify"\u003e § libpng - потрібно gd для створення графіки в форматі png (# "justify"\u003e У нашому випадку установка зводиться до виконання однієї команди, тому що обраний спосіб установки предкомпіленного пакета зі сховищ:

# Aptitude install mrtg

Створювати конфігураційні файли можна вручну, а можна скористатися йдуть в складі пакету генераторами конфігурацій:

# cfgmaker @ >

Після генерації конфігураційного файлу рекомендується перевірити його, тому що в ньому можуть знаходиться опису інтерфейсів, які нам не потрібно аналізувати на завантаженість. В такому випадку певні рядки у файлі коментуються або видаляються. Приклад конфігураційного файлу MRTG наведено в Додатку М. Через великий обсяг цих файлів наведено лише приклад одного файлу.

# indexmaker >

Індексні сторінки являють собою звичайні html файли і їх вміст особливого інтересу не представляє, тому наводити їх приклади не має сенс. У Додатку Н показаний приклад відображення графіків завантаження інтерфейсів.

На завершення необхідно організувати перевірку завантаженості інтерфейсів за розкладом. Досягти цього найпростіше засобами операційної системи, а саме параметрами crontab.

4.5 Установка і настройка модуля збору системних журналів подій

Як модуля збору системних журналів подій був обраний пакет syslog-ng.ng (syslog next generation) - це багатофункціональна служба протоколювання системних повідомлень. У порівнянні зі стандартною службою syslogd, він має ряд відмінностей:

§ вдосконалена схема конфігурації

§ фільтрація повідомлень не тільки по пріоритетам, а й за їх змістом

§ підтримка regexps (regular expressions)

§ більш гнучке маніпулювання і організація логів

§ можливість шифрування каналу передачі даних за допомогою IPSec / Stunnel

У наступній таблиці представлені підтримувані апаратні платформи.

Таблиця 4.1 - Підтримувані апаратні платформи

x86x86_64SUN SPARCppc32ppc64PA-RISCAIX 5.2 & 5.3НетНетНетДаПо запросуНетDebian etchДаДаНетНетНетНетFreeBSD 6.1 * ДаПо запросуПо запросуНетНетНетHP-UНет 11iНетНетНетНетНетДаIBM System iНетНетНетДаНетНетRed Hat ES 4 / CentOS 4ДаДаНетНетНетНетRed Hat ES 5 / CentOS 5ДаДаНетНетНетНетSLES 10 / openSUSE 10.0ДаПо запросуНетНетНетНетSLES 10 SP1 / openSUSE 10.1ДаДаНетНетНетНетSolaris 8НетНетДаНетНетНетSolaris 9По запросуНетДаНетНетНетSolaris 10По запросуДаДаНетНетНетWindowsДаДаНетНетНетНет Прімеченіе: * Доступ до бази даних Oracle не підтримує

Детальний порівняння технічних особливостей наведено в Додатку П.

Файли опису правил і фільтрів, а також конфігурація віддалених хостів наведені в Додатку Р.

Існує документ RFC, детально описує протокол syslog, в загальному вигляді роботу модуля збирача системних журналів можна представити наступною схемою

Мал. 4.6 - Схема роботи модуля збору системних журналів

На клієнтському хості кожне окреме додаток пише свій журнал подій, утворюючи тим самим джерело. Далі потік повідомлень для журналів проходить через визначення місця для зберігання, далі через фільтри визначається його мережеве напрямок, після чого, потрапляючи на сервер логування, для кожного повідомлення знову визначається місце зберігання. Обраний модуль має великі можливості масштабування і ускладненою конфігурації, наприклад фільтри можуть розгалужуватися, таким чином, що повідомлення про системні події будуть відправлятися в кілька напрямків залежно від кількох умов, як показано на малюнку нижче.

Мал. 4.7 - Галуження фільтрів

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

Мал. 4.8 - Масштабування і розподіл навантаження

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

Мал. 4.9 - Узагальнена схема роботи модуля

У нашому випадку потік даних не настільки великий щоб розгортати систему розвантажують серверів, тому було вирішено використовувати спрощену схему роботи клієнт - сервер.

Мал. 4.10 - Прийнята схема роботи

5. КЕРІВНИЦТВО СИСТЕМНОЇ АДМИНИСТРАТОРА

В цілому системному адміністратору рекомендується дотримуватися існуючої ієрархії розташування конфігураційних файлів і каталогів. Додавання в систему моніторингу нових хостів і служб зводиться до створення нових конфігураційних файлів і сценарій запуску, як було показано в розділі 5 - Розробка програмного забезпечення, тому повторно описувати параметри і принципи конфігурації системи в цій роботі сенсу немає, проте варто більш детально зупинитися на описі інтерфейсів окремих модулів системи.

5.1 Опис веб-інтерфейсу системи

Для того щоб виконувати інтерактивне спостереження за службами було зручніше в систему інтегрований web-інтерфейс. Web-інтерфейс ще хороший тим, що дає повну картину системи завдяки вмілому застосуванню графічних засобів і надання додаткової статистичної інформації.

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

Мал. 5.1 - Стартова сторінка веб-інтерфейсу системи

Зліва знаходиться навігаційна панель, праворуч результати різного представлення даних про стан мережі, хостів і служб. Нас буде цікавити в першу чергу розділ Monitoring. Подивимося на сторінку Tactical Overview.

Мал. 5.2 - Стартова сторінка веб-інтерфейсу системи

На цій сторінці розташовується підсумовує інформація по всім параметрам моніторингу і станом хостів і служб, при цьому ніяких подробиць не наводиться, однак, якщо виникають будь-які проблеми, то вони виділяються особливим кольором і стають гіперпосиланням, що веде до докладного опису проблеми, що виникла. У нашому випадку на поточний момент серед усіх хостів і служб є одна невирішена проблема, перейдемо за цим посиланням (1 Unhandled Problems).

Мал. 5.3 - Виявлена \u200b\u200bпроблема служби

Тут ми в таблично вигляді спостерігаємо на якому саме хості виникла проблема, що за служба її викликала (в нашому випадку це велике завантаження процесора на маршрутизаторі), статус помилки (може бути нормальний, граничний і критичний), час останньої перевірки, тривалість присутності проблеми, номер перевірки за рахунком в циклі і докладна інформація з конкретними значеннями, що повертаються використовуваним плагіном.

Мал. 5.4 - Детальний опис стану служби

Тут ми бачимо повний опис проблеми, ця сторінка корисною при глибокому аналізі проблеми, коли не зовсім ясна причина її виникнення, наприклад вона може бути в занадто жорстко заданих порогових значеннях критичності стану або неправильно заданих параметрах запуску плагіна, що також буде оцінюватися системою як критичне стан . Крім опису, з цієї сторінки можливе виконання команд над службою, наприклад відключити перевірки, призначити інший час наступної перевірки, прийняти дані пасивно, прийняти проблему на розгляд, відключити оповіщення, відправити оповіщення вручну, запланувати відключення служби, відключити виявлення нестабільного стану і написати коментар.

Перейдемо на сторінку Service Detail.

Мал. 5.5 - Детальний уявлення всіх служб

Тут ми бачимо список всіх хостів і служб, незалежно від їх поточного стану. Ця можливість може бути і корисна, але переглядати довгий список хостів і служб не зовсім зручно і потрібна вона швидше щоб час від часу візуально уявити обсяг роботи, що виконується системою. Тут кожен хост і служба, як і на малюнку 6.3 є посиланням, що веде до більш докладного опису параметра.

Мал. 5.6 - Повний докладний список хостів

У даній таблиці представлено повний детальний список хостів, їх статуси, час останньої перевірки, тривалість поточного статусу і додаткова інформація. У нашій системі прийнято, що статус хоста перевіряється за допомогою перевірки доступності хоста по протоколу ICMP (8), тобто командою ping, проте в загальному випадку перевірка можна бути якою завгодно. Значки в колонці праворуч від імені хоста говорять про групу, до якої він належить, зроблено це для зручності сприйняття інформації. Значок світлофора це посилання, що веде до докладного списку служб даного хоста, описувати цю таблицю окремо не має сенсу, вона точно така ж, як і на малюнку 10.4, тільки інформація представлена \u200b\u200bпро єдиному хост.

Наступні за списком посилання є різними модифікаціями попередніх таблиць і розібратися з їх змістом не складе труднощів. Найцікавішою можливістю веб-інтерфейсу є можливість побудови карти мережі в напівавтоматичному режимі.

Мал. 5.7 - Повна кругова карта мережі

За допомогою параметра parent кожного хоста і служби ми можемо створювати структуру або ієрархію нашої мережі, що визначить логіку роботи ядра мережевого моніторингу та подання хостів і служб на карті мережі. Є кілька режимів відображення, крім кругового, найбільш зручним є режим збалансованого дерева і кулястий.

Мал. 5.8 - Карта мережі - режим збалансованого дерева

Мал. 5.9 - Карта мережі - кулястий режим

У всіх режимах зображення кожного хоста є посиланням на його таблицю служб і їх станів.

Наступною важливою частиною інтерфейсу ядра моніторингу є будівник трендів. З його допомогою можна планувати заміну обладнання на більш продуктивно, наведемо приклад. Клацаємо по посиланню Trends. Вибираємо тип звіту - службу.

Step 1: Select Report Type: Service

Третім кроком вибираємо період підрахунку і генеруємо звіт.

Мал. 5.10 - Тренд

Ми згенерували тренд завантаженості процесора на маршрутизації. З нього можна зробити висновок, що протягом місяця цей параметр постійно погіршується і необхідно вже зараз вживати заходів або по оптимізації роботи хоста або готуватися до його заміни на більш продуктивний.

5.2 Опис веб-інтерфейсу модуля відстеження завантаження інтерфейсів

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

Мал. 5.11 - Стартова сторінка модуля відстеження завантаження інтерфейсів

Перейшовши по кожній із посилань, отримаємо графіки завантаження. Кожен графік є посиланням, що веде до статистики за тиждень, місяць і рік.

5.3 Опис модуля збору системних журналів подій

В даний момент не потрібна покращена фільтрація системних журналів і можливість пошуку по ним через єдиний веб-інтерфейс, тому що проблеми, що вимагають перегляду цих журналів виникають досить рідко. Тому розробка бази даних під ці журнали і веб-інтерфейсу відкладена. В даний час доступ до них здійснюється за допомогою ssh і перегляду директорій в файловому менеджері mc.

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

├── apache2

├── asterix

├── bgp_router

├── dbconfig-common

├── installer

│ └── cdebconf

├── len58a_3lvl

├── monitoring

├── nagios3

│ └── archives

├── ocsinventory-client

├── ocsinventory-server

├── quagga

├── router_krivous36b

├── router_lenina58a

├── router_su

├── router_ur39a

├── shaper

├── ub13_router

├── univer11_router

└── voip

Кожен каталог є сховищем журналів подій для кожного окремого хоста.

Мал. 5.13 - Перегляд даних, зібраних модулем збору системних журналів подій

6. ТЕСТУВАННЯ РОБОТИ

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

) Установка і налагодження ядра на базі Nagios;

) Налагодження моніторингу віддалених хостів базовим функціоналом Nagios;

) Налагодження модуля відстеження завантаження мережевих інтерфейсів за допомогою MRTG;

) Розширення функціоналу ядра системи та інтеграція її з модулем MRTG;

) Налагодження модуля збору системних журналів;

) Написання скрипта ініціалізації пакетного фільтра системи моніторингу з метою забезпечення безпеки системи.

7. Інформаційна безпека

1 Характеристика робочого місця

До шкідливих факторів, що впливає на роботу при використанні ПЕОМ відносяться:

· підвищене значення напруги електричного струму;

· шум;

· електромагнітне випромінювання;

· електростатичне поле.

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

7.2 Безпека праці

2.1 Електробезпека

Проектована програмний засіб створюється в розрахунку на роботу на наявному сервері, розташованому в спеціально обладнаному технічному приміщенні. Воно обладнане кабельними коробами для прокладки кабелів. До кожного серверу підведено електроживлення ~ 220В, частотою 50 Гц, з робочим заземленням. Перед введенням електроживлення в приміщення встановлені автомати, що відключають електроживлення в разі короткого замикання. Окремо проведено захисне заземлення.

При підключенні ЕОМ необхідно з'єднати корпус апаратури з житловою захисного заземлення для того, щоб в разі виходу з ладу ізоляції або з яких-небудь інших причин небезпечна напруга електроживлення, при дотику людиною корпусу апаратури, не змогло створити струм небезпечної величини через тіло людини.

Для цього використовується третій контакт в електричних розетках, який підключений до жили захисного заземлення. Корпуси апаратури заземлюються через кабель електроживлення по спеціально виділеному провіднику.

Застосовуються технічні заходи, що забезпечують захист від ураження електричним струмом при дотику до корпусу електроустановки в разі пробою ізоляції струмоведучих частин, до яких відносяться:

· захисне заземлення;

· захисне занулення;

· захисне відключення.

7.2.2 Захист від шуму

Дослідження показують, що в умовах шуму, перш за все, страждають слухові функції. Але дія шуму не обмежується впливом тільки на слух. Він викликає помітні зрушення ряду фізіологічних психічних функцій. Шум шкідливо впливає на нервову систему і знижує швидкість і точність сенсомоторних процесів, зростає кількість помилок при вирішенні інтелектуальних завдань. Шум справляє помітний вплив на увагу людини і викликає негативні емоції.

Основним джерелом шуму в приміщеннях, де знаходяться ЕОМ, є обладнання для кондиціонування повітря, друкована та копіювальна техніка, а в самих ЕОМ вентилятори систем охолодження.

У виробничому приміщенні активно використовуються такі заходи боротьби з шумом:

· застосування безшумних охолоджуючих механізмів;

· ізоляція джерел шуму від навколишнього середовища засобами звукоізоляції і звукопоглинання;

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

У приміщенні на робочому місці присутні наступні джерела шуму:

· системний блок (кулер (25дБ), жорсткий диск (29дБ), блок живлення (20дБ));

· принтер (49дБ).

Загальний шум L, що випускається цими пристроями, визначається за формулою:

де Li - рівень шуму одного пристрою, дБ \u003d 10 * lg (316,23 + 794,33 + 100 + 79432,82) \u003d 10 * 4,91 \u003d 49,1дБ

За СН 2.2.4 / 2.1.8.562-96 рівень шуму на робочому місці математиків-програмістів і операторів відеоматеріалів не повинен перевищувати 50 дБ.

7.2.3 Захист від електромагнітного випромінювання

Захист від електромагнітного впливу забезпечується екранами з електропровідного поверхнею і використанням моніторів, забезпечених системою Low Radiation, яка зводить до мінімуму рівень шкідливих випромінювань, а також рідкокристалічних моніторів, в яких електромагнітне випромінювання повністю відсутня.

7.2.4 Захист від електростатичного поля

Для захисту від впливу електростатичного заряду застосовується заземлений захисний фільтр, зволожувачі повітря, а підлоги покриті антистатичним покриттям. Для підтримки нормованих значень концентрації позитивних і негативних іонів в приміщеннях з ЕОМ встановлені кондиціонери, пристрої іонізації повітря і проводиться природне провітрювання тривалістю не менше 10 хвилин після кожні 2 годин роботи.

З метою запобігання шкідливому впливу на організм працюючих людей пилинок з аероіноамі щодня проводиться вологе прибирання приміщень і не рідше 1 разу за зміну видаляється пил з екранів при вимкненому моніторі.

7.3 Умови праці

3.1 Мікроклімат виробничого приміщення

Ця у даному дипломному проекті обладнання в процесі роботи не виробляє ніяких шкідливих речовин. Таким чином, повітряне середовище в приміщенні, де вони використовуються, шкідливих впливів на організм людини не робить і задовольняє вимогам I категорії робіт, відповідно до ГОСТ 12.1.005-88.

Оптимальні норми температури, відносної вологості та швидкості руху повітря в робочій зоні виробничих приміщень нормуються ГОСТ 12.1.005-88 і приведені в таблиці 7.1.

Таблиця 7.1 -Параметри мікроклімату

Критичний параметрЗначеніеОптімальноеДопустімоеФактіческоеТемпература повітря, С20 - 2218 - 2020Влажность,% 40 - 60Не більш 8045Скорость руху повітря, м / с0,20,30..0,3

Мікроклімат відповідає оптимальним умовам.

3.2 Виробниче освітлення

Для розрахунку вибираємо відділ супроводу в ТОВ Геркон в місті Верхня Пишма, де відбувалася розробка даного проекту:

· площа приміщення дорівнює 60м2;

· площа світлових прорізів 10 м2;

· встановлено 4 автоматизованих робочих місць.

Розрахунок природного освітлення проводиться за формулою СНиП 23.05-95:

S0 \u003d Sп * eн * Кз * N0 * КЗД / 100% * Т0 * Т1 (7.2)

Де S0 - площа світлових прорізів, м2;

Sп - площа підлоги приміщення, м2, 60;

eн - коефіцієнт природної освітленості, 1,6;

Кз - коефіцієнт запасу, 1,5;

N0 - світлова характеристика вікон, 1;

КЗД - коефіцієнт, що враховує затемнення вікон ворогуючими будинками, 1,2;

Т0 - загальний коефіцієнт світлопропускання, 0,48;

Т1 - коефіцієнт відбиття від поверхні приміщення, 1,2.

Значення всіх коефіцієнтів взяті в СНиП 23.05.-95.

В результаті розрахунку одержуємо: необхідна площа світлових прорізів вікон S0 \u003d 3,4м2. Реальна площа прорізів дорівнює 10м2, що перевищує мінімальну допустиму площу світлових прорізів для приміщень такого типу і є достатнім в світлий час доби.

Розрахунок штучного освітлення для кімнати, що освітлюється 15 люмінесцентними лампами типу ЛДЦ-60 потужністю по 60 Вт кожна.

Згідно СНиП 23.05-95, величина освітленості люмінесцентними лампами повинна бути в горизонтальній площині не нижче 300лм - для системи загального освітлення. З урахуванням зорової роботи високої точності величина освітленості може бути збільшена до 1000лм.

Світловий потік люмінесцентної лампи розраховується за формулою з СНиП 23.05.-95:

Фі \u003d Ен * S * Z * K / N * η (7.3)

де Ен - нормована освітленість приміщення, лк, 200;

S - площа підлоги приміщення, м2, 60;

Z - коефіцієнт, що враховує відношення середньої освітленості до мінімальної, 1,1;

К - коефіцієнт запасу з урахуванням забруднення повітря, 1,3;

N - кількість світильників, 15;

η - коефіцієнт використання світлового потоку, 0,8.

В результаті отримуємо Фі \u003d 1340лм, сумарний світловий потік всіх ламп дорівнює 3740лм, отже, освітленість лабораторії вище мінімально допустимої.

7.4 Ергономіка робочого місця

4.1 Організація робочого місця

Відповідно до СанПіН 2.2.2 / 4.2.1340-03, ВДТ (відеодисплейний термінал) повинен відповідати наступним технічним вимогам:

· яскравість освітлення не менше 100кд / м2;

· мінімальний розмір світловий точки не більше 0,1 мм для кольорового дисплея;

· контрастність зображення знака не менше 0,8;

· частота кадрової розгортки не менше 7кГц

· кількість точок не менше 640;

· антиблікове покриття екрану;

· розмір екрану не менше 31см по діагоналі;

· висота символів на екрані не менше 3,8 мм;

· відстань від очей оператора до екрану має бути близько 40-80см;

ВДТ повинен обладнаний поворотною майданчиком, що дозволяє переміщати його в горизонтальній і вертикальній площинах в межах 130-220мм і змінювати кут нахилу екрану на 10-15градусов.

Дипломний проект виконувався на комп'ютері з ВДТ ViewSonic діагоналлю 39см. Даний монітор виконаний відповідно до світових стандартів і відповідаємо всім перерахованим вище технічним вимогам.

До клавіатури ставляться такі вимоги:

· забарвлення корпусу в спокійні м'які тони з дифузним розсіюванням світла;

· матова поверхня з коефіцієнтом відображення 0,4 - 0,6 і не має блискучих деталей, здатних створювати відблиски;

Проект виконувався на клавіатурі марки Logitech, яка відповідає всім перерахованим вище вимогам.

Системні блоки встановлюються на робочому місці з урахуванням легкої досяжності до накопичувачів на гнучких магнітних дисках і зручного доступу до роз'ємів і органам управління на тильній стороні. Часто використовувані дискети зберігаються поблизу системного блоку в пило-та електромагнітозащіщенной осередку. Принтер, розміщений праворуч від користувача. Друкується текст видно оператору під час перебування їх в основний робочої позі. Поблизу від принтера в спеціальних відсіках зберігається чистий папір і інші необхідні приналежності.

Сполучні кабелі прокладаються в спеціальних каналах. Облаштування каналів має таке, що сполучні роз'єми не перешкоджають вилученню кабелів.

Для маніпулятора типу «миша» праворуч від користувача на стільниці передбачена вільна площадка, яка за формою і розміром мусить ідентична поверхні екрану.

Робоче місце оператора відповідає вимогам ГОСТ 12.2.032-78 ССБТ.

Просторова організація робочого місця забезпечує оптимальну робочу позу:

· голова нахилена вперед на 10 - 20 градусів;

· спина має упор, співвідношення між плечем і передпліччям, а також між стегном і гомілкою - прямий кут.

Основні параметри робочого місця повинні регульовані. Цим забезпечується можливість створення сприятливих умов праці окремої людини з урахуванням геоантропометріческіх характеристик.

Основні параметри робочого місця і меблів, оснащеного персональним комп'ютером (рис. 7.1)

Мал. 7.1 - Робоче місце оператора ЕОМ

· висота сидіння 42 - 45 см;

· висота клавіатури від статі 70 - 85см;

· кут нахилу клавіатури від горизонталі 7 - 15градусов;

· віддаленість клавіатури від краю столу 10 - 26см;

· відстань від центру екрану до статі 90 - 115см;

· кут нахилу екрану від вертикалі 0 - 30градусов (оптимальний 15);

· віддаленість екрану від краю столу 50 - 75см;

· висота робочої поверхні для записів 74 - 78см;

На робочому місці передбачена підставка для ніг, рекомендовану для всіх видів робіт, пов'язаних з тривалим збереженням в положенні сидячи

За СанПіН 2.2.2.542-96 характер праці оператора ЕОМ вважається легким і відноситься до категорії 1А.

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

7.5 Пожежна безпека

Приміщення, де проводилася робота над даним проектом, встановлена \u200b\u200bкатегорія пожежної небезпеки У НПБ 105-03 - горючі і негорючі рідини, тверді горючі і негорючі речовини і матеріали, в тому числі пил та волокна, речовини і матеріали, здатні при взаємодії з водою, киснем повітря або один з одним тільки горіти за умови, що приміщення, в яких вони є в наявності або утворюються, не належать до категорій А або Б. Будівля для приміщення I ступеня вогнестійкості за СНиП 21-01-97.

У виробничому приміщенні дотримані наступні правила безпеки:

· проходи, виходи з приміщення, доступи до засобів пожежогасіння вільні;

· устаткування, що знаходиться в експлуатації, справно і перевіряється кожен раз перед початком роботи;

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

Число евакуаційних виходів з будівель з приміщення два. Ширина евакуаційного виходу (дверей) становить 2м. На шляхах евакуації використовуються звичайні сходи і розсувні двері. На сходових клітинах відсутні будь-які приміщення, технологічні комунікації, виходи підйомників і вантажних ліфтів. На евакуаційних шляхах влаштовано як природне, так і штучне аварійне освітлення.

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

Для виявлення початкової стадії загоряння та оповіщення служби пожежної охорони використовується система автоматичної і пожежної сигналізації (АПС). Вона самостійно приводить в дію установки пожежогасіння, поки пожежа не досяг великих розмірів і оповіщає міську службу пожежної охорони.

Об'єкти ВЦ крім АПС необхідно обладнано установками стаціонарного автопожаротушенія. Прийміть установки газового гасіння пожеж, дія яких заснована на швидкому заповненні приміщення вогнегасною газовим речовиною, в результаті чого знижується вміст кисню в повітрі.

7.6 Надзвичайні ситуації

В умовах даного приміщення найбільш імовірною надзвичайною ситуацією може бути пожежа. При виникненні пожежі необхідно евакуювати персонал і повідомити про те, що трапилося в службу пожежної охорони. План евакуації представлений на малюнку 7.2.

Мал. 7.2 - План евакуації при пожежі

8. ЕКОНОМІЧНА ЧАСТИНА

У цьому розділі розглядаються витрати на розробку системи моніторингу мережі, її впровадження і супровід, а також супутні матеріали та обладнання.

У вартості проекту знаходять собі відображення вартість споживаних в процесі розробки і виробництва засобів і предметів праці (амортизація, вартість обладнання, матеріалів, палива, енергії і т.д.), частина вартості живої праці (оплата праці), вартість покупних модулів системи.

В процесі діяльності та збільшення обсягів поставок послуг виникла проблема попереджувального виявлення несправних і слабких місць в організації мережі, тобто ставилося завдання впровадження рішення, що дозволяє прогнозувати необхідність заміни або модернізації ділянок мережі до того, як несправності позначаться на роботі абонентських вузлів.

З ростом клієнтської бази, а як наслідок і числа активного обладнання, виникла необхідність оперативного відстеження стану мережі в цілому і окремих її елементів в подробиці. До впровадження системи моніторингу мережі адміністратора доводилося підключатися посредствам протоколів telnet, http, snmp, ssh і т.п. до кожного питання, що цікавить вузлу мережі і користуватися вбудованими засобами моніторингу та діагностики. На даний момент ємність мережі становить 5000 портів, 300 комутаторів 2-го рівня, 15 маршрутизаторів і 20 серверів внутрішнього користування.

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

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

У відповідності зі сформованою ситуацією, було вирішено розробити і впровадити систему моніторингу мережі, яка вирішувала б всі вищевикладені проблеми, які, узагальнивши можна виразити таким чином:

Необхідно розробити і впровадити систему моніторингу, що дозволяє проводити спостереження як за комутаторами, маршрутизаторами різних виробників, так і серверів різних платформ. Орієнтуватися на використання відкритих протоколів і систем, з максимальним використанням готових напрацювань з фонду вільного програмного забезпечення, що з економічної точки зору знижує витрати на ліцензування кінцевої системи до нуля.

Система повинна відповідати таким вимогам в економічному плані:

· мінімальні вимоги до апаратних ресурсів (веде до зниження витрат на апаратну частину проекту);

· відкриті вихідні коди всіх складових комплексу (дозволяє самостійно змінювати принцип роботи системи, не вдаючись до допомоги сторонніх пропрієтарних розробок і знижує вартість ліцензування продукту);

· розширюваність і масштабованість системи (дозволяє розширити сферу застосування додатки, не вдаючись до допомоги побічних і пропрієтарних розробок і знижує вартість ліцензування продукту);

· стандартні засоби надання діагностичної інформації (дозволяє знизити витрати на супровід системи);

· наявність докладної документації на всі використовувані програмні продукти (дає можливість швидко навчити нового співробітника);

· здатність працювати з обладнанням різних виробників (дає можливість використовувати один програмний продукт). (Повний список устаткування наведено у Додатку В).

В цілому розробка проекту зайняла 112 годин (2 тижні). На впровадження цього проекту буде потрібно 56 годин (1 тиждень).

1 Розрахунок витрат на розробку проекту

Витрати на розробку проекту складаються з:

· витрат на заробітну плату;

· витрат на амортизацію обладнання і програмних продуктів;

· витрат на оплату електроенергії;

· накладних витрат.

Витрати на заробітну плату.

При розрахунку витрат на заробітну плату враховуємо, що даний проект розробляв один чоловік: системний інженер.

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

Розрахуємо вартість 1 години роботи інженера, спираючись на наступні дані:

· премія 25%;

· районний коефіцієнт 15%;

· фонд робочого часу в 2010 році, відповідно до виробничого календаря, становить 1 988 годину;

Таким чином, розцінка з урахуванням районного коефіцієнта складе:

РЧ \u003d 30000 * 1,25 * 1,15 * 12/1988 \u003d 260 руб

У розрахунку витрат на заробітну плату враховуються відрахування, що сплачуються з нарахованої заробітної плати, тобто загальна величина тарифу страхових внесків дорівнюватиме максимальній ставці ЄСП - 26%, в тому числі:

· ПФР - 20%;

· ФССР - 2,9%

· ФФОМС - 1,1%;

· ГФОМС - 2%;

· Обов'язкове соціальне страхування від нещасних випадків - 0,2%.

В сумі відрахування складуть:

СО \u003d РЧ * 0,262 \u003d 260 * 0,262 \u003d 68 руб

З урахуванням часу роботи інженера (112 годин на розробку і 56 годин на впровадження), розрахуємо витрати на заробітну плату:

ЗП \u003d (112 + 56) * (РЧ + СО) \u003d 168 * 328 \u003d 55104 руб

Витрати на амортизацію обладнання і програмних продуктів.

В якості основного обладнання на етапі розробки проекту мережі використовувалися персональний комп'ютер і сервер AQUARIUS SERVER T40 S41. Вартість комп'ютера на даний момент складає приблизно 17000 руб, тоді як сервера 30000 руб.

Таким чином вартість разових вкладень в апаратуру складе:

РВА \u003d 47000 руб

Протягом терміну експлуатації комп'ютера та сервера допускається їх модернізація, даний вид витрат також враховується при розрахунку. Закладаємо 50% від РВ на модернізацію:

РМА \u003d РВ * 0,5 \u003d 23500 руб

Комп'ютер використовувався на наступних етапах:

· пошук літератури;

· пошук рішень проектування системи моніторингу мережі;

· розробка структур і підсистем;

· проектування системи моніторингу мережі;

· оформлення документа.

Сервер використовувався під час впровадження системи і безпосередньої роботи з системою.

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

Таким чином загальні витрати на апаратуру з урахуванням амортизації складуть:

ОЗА \u003d РВА + РМА \u003d 47000 + 23500 \u003d 70500 руб

Строк корисного використання приймаємо 2 роки. Вартість однієї години роботи становить (прийнявши число робочих днів у місяці 22 і при 8-годинному робочому дні):

СОЧР \u003d ОЗА / ВР \u003d 70500/4224 \u003d 16,69 руб

На час розробки і впровадження вартість амортизаційних відрахувань відповідно складе:

САЧРВ \u003d СОЧР * ТРВ \u003d 16,69 * 168 \u003d 2803,92 руб

Витрати на електроенергію.

Витрати на електроенергію складаються з споживаної комп'ютером і витрачається на освітлення. Вартість електроенергії:

СЕН \u003d 0,80 руб / кВт * год (За договором з власником приміщення)

Рк, з \u003d 200 Вт - потужність, споживана комп'ютером або сервером.

Трк \u003d 168 ч - час роботи комп'ютера на етапі розробки і впровадження системи.

ТРС \u003d 52 год - час роботи сервера на етапі розробки і впровадження системи.

Таким чином вартість електроенергії на етапі розробки і впровадження проекту складе:

СЕНК \u003d Рк * Трк * СЕН + Рк * ТРС * СЕН \u003d (200 * 168 * 0,80 + 200 * 52 * 0,80) / 1000 \u003d (26880 + 8320) / 1000 \u003d 35,2 руб

Робоче місце, на якому було здійснено дана робота, оснащено світильником потужністю 100 Вт. Розрахуємо вартість електроенергії, витраченої освітлювальним приладом на час розробки та впровадження системи:

СЕНО \u003d 100 * Трк * СЕН \u003d (100 * 168 * 0,80) / 1000 \u003d 13,44 руб

Загальні витрати на електроенергію склали:

ОЗЕН \u003d СЕНК + СЕНО \u003d 35,2 + 13,44 \u003d 48,64 руб

8.2 Розрахунок накладних витрат

Даний пункт витрат охоплює витрати на інше обладнання та витратні матеріали, також непередбачені витрати.

Накладні витрати в бюджеті підприємства складають 400% від нарахованої заробітної плати:

НР \u003d ЗП * 4 \u003d 55104 * 4 \u003d 220416 руб.

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

СРВ \u003d ЗП + САЧРВ + ОЗЕН + НР \u003d 55104 + 2803,92 + 48,64 + 220416 \u003d 278372,56 руб

3 Ефективність

В результаті виконання економічних розрахунків була призначена мінімальна ціна розробки і впровадження системи моніторингу мережі 278372,56 руб.

Як видно з розрахунків, переважна частина вартості витрат припадає на матеріали і обладнання. Це пояснюється тим, що виробники основного устаткування це закордонні компанії і відповідно ціни на дану продукцію наводяться в американських доларах за курсом ЦБРФ + 3%. А підвищення митних зборів на ввезену продукцію також негативно позначається на ціні для кінцевих замовників.

Для обґрунтування самостійної розробки системи порівняємо її вартість з готовими рішеннями, присутніми на ринку:

· D-Link D-View - 360 000 руб

Вступ

В останні роки інформаційні технології зазнають значних і постійні зміни. За деякими оцінками, за останні п'ять років обсяг мережевого трафіку локальних мереж виріс в десять разів. Таким чином, локальні мережі повинні забезпечувати все більшу пропускну здатність і необхідний рівень якості обслуговування. Однак які б ресурси не мала мережу, вони все-таки кінцеві, тому для мережі необхідна можливість управління трафіком.

А для того щоб управління було максимально ефективним, потрібно можливість контролю над пакетами, що передаються між пристроями вашої мережі. Також у адміністратора існує безліч обов'язкових для виконання щоденних операцій. Це, наприклад, перевірка правильності функціонування електронної пошти, перегляд реєстраційних файлів на предмет виявлення ранніх ознак несправностей, контроль за підключенням локальних мереж і за наявністю системних ресурсів. І тут на допомогу можуть прийти засоби, що застосовуються для моніторингу та аналізу обчислювальних мереж.

Щоб не заплутатися в різноманітті методик, засобів і продуктів, створених для моніторингу, почнемо з короткого опису декількох великих класів цих продуктів.

Системи управління мережею (Network Management Systems). Це централізовані програмні системи, які збирають дані про стан вузлів і комунікаційних пристроїв мережі, а також про трафік, циркулюючому в мережі. Ці системи не тільки здійснюють моніторинг і аналіз мережі, а й виконують в автоматичному чи напівавтоматичному режимі дії з управління мережею - включення і відключення портів пристроїв, зміна параметрів мостів адресних таблиць мостів, комутаторів і маршрутизаторів і т.п. Прикладами систем управління можуть служити популярні системи HPOpenView, SunNetManager, IBMNetView.

Засоби управління системою (System Management). Засоби управління системою часто виконують функції, аналогічні функціям систем управління, але по відношенню до інших об'єктів. У першому випадку об'єктом управління є програмне і апаратне забезпечення комп'ютерів мережі, а в другому - комунікаційне обладнання. Разом з тим деякі функції цих двох видів систем управління можуть дублюватися, наприклад засоби управління системою можуть виконувати найпростіший аналіз мережевого трафіку.

Вбудовані системи діагностики і управління (Embedded systems). Ці системи виконуються у вигляді програмно-апаратних модулів, що встановлюються в комунікаційне обладнання, а також у вигляді програмних модулів, вбудованих в операційні системи. Вони виконують функції діагностики і управління тільки одним пристроєм, і в цьому їх основна відмінність від централізованих систем управління. Прикладом засобів цього класу може служити модуль управління концентратором Distrebuted 5000, який реалізує функції автосегментацією портів при виявленні несправностей, приписування портів внутрішнім сегментам концентратора і деякі інші. Як правило, вбудовані модулі управління «за сумісництвом» виконують роль SNMP-агентів, що поставляють дані про стан пристрою для систем управління.

Аналізатори протоколів (Protocol analyzers). Являють собою програмні або апаратно-програмні системи, які обмежуються, на відміну від систем управління, лише функціями моніторингу і аналізу трафіку в мережах. Хороший аналізатор протоколів може захоплювати і декодувати пакети великої кількості застосовуваних у мережах протоколів - зазвичай кілька десятків. Аналізатори протоколів дозволяють встановити деякі логічні умови для захоплення окремих пакетів і виконують повне декодування захоплених пакетів, тобто показують в зручній для фахівця формі вкладеність пакетів протоколів різних рівнів один в одного з розшифровкою змісту окремих полів кожного пакета.

Експертні системи. Системи цього виду акумулюють людські знання про виявлення причин аномальної роботи мереж і можливі способи приведення мережі в працездатний стан. Експертні системи часто реалізуються у вигляді окремих підсистем різних засобів моніторингу та аналізу мереж: систем управління мережами, аналізаторів протоколів, мережевих аналізаторів. Найпростішим варіантом експертної системи є контекстно-залежна help-система. Більш складні експертні системи являють собою так звані бази знань, що володіють елементами штучного інтелекту. Прикладом такої системи є експертна система, вбудована в систему управління Spectrum компанії Cabletron.

Багатофункціональні пристрої аналізу і діагностики. В останні роки в зв'язку з повсюдним поширенням локальних мереж виникла необхідність розробки недорогих портативних приладів, які суміщають функції декількох пристроїв: аналізаторів протоколів, кабельних сканерів і навіть деяких можливостей ПЗ мережевого управління. Як приклад такого роду пристроїв можна привести Compas компанії Microtest, Inc. або 675 LANMeter компанії FlukeCorp.

Системи управління

Останнім часом в області систем управління спостерігаються дві досить чітко виражені тенденції:

1. Інтеграція в одному продукті функцій управління мережами і системами. (Безсумнівна перевага цього підходу - єдина точка керування системою. Недолік полягає в тому, що при великому навантаженні на мережу сервер з встановленою програмою моніторингу може не справлятися з обробкою всіх пакетів і, в залежності від продукту, або ігнорувати частина пакетів, або ставати «вузьким місцем »системи.).
2. распределенность системи управління, при якій в системі існує кілька консолей, які збирають інформацію про стан пристроїв і систем і видають керуючі дії. (Тут все навпаки: завдання моніторингу розподілені між кількома пристроями, але можливі дублювання одних і тих самих функцій і неузгодженість між керуючими впливами різних консолей.)

Найчастіше системи управління виконують не тільки функції моніторингу та аналізу роботи мережі, але і включають функції активного впливу на мережу - управління конфігурацією і безпекою (див. Врізку).

Протокол управління мережами SNMP

Більшості фахівців, що займаються побудовою мереж і їх управлінням, подобається концепція стандартів. Це цілком зрозуміло, адже стандарти дозволяють їм вибирати постачальника мережевої продукції на підставі таких критеріїв, як рівень сервісу, ціна і експлуатаційні характеристики продукції, замість того щоб бути «прикутими» до фірмового рішенням одного виробника. Найбільша на сьогодні мережа - Інтернет - заснована на стандартах. З метою координації зусиль по їх розробці для цієї та інших використовують протоколи TCP / IP мереж була створена Інженерна проблемна група Інтернет (IETF).

Найбільш поширеним протоколом управління мережами є протокол SNMP (SimpleNetworkManagementProtocol), який підтримують сотні виробників. Головні переваги протоколу SNMP - простота, доступність, незалежність від виробників. Протокол SNMP розроблений для управління маршрутизаторами в мережі Інтернет і є частиною стека TCP / IP.

What is MIB - Man In Black?

Якщо мова йде про інструменти моніторингу корпоративної мережі, то за цією абревіатурою ховається термін Management Information Base. Для чого потрібна ця база даних?

SNMP - це протокол, який використовується для отримання від мережевих пристроїв інформації про їх статус, продуктивності і характеристиках, які зберігаються в спеціальній базі даних мережевих пристроїв, що називається MIB. Існують стандарти, що визначають структуру MIB, в тому числі набір типів її змінних (об'єктів в термінології ISO), їх імена і допустимі операції з цими змінними (наприклад, читати). Поряд з іншою інформацією в MIB можуть зберігатися мережевий і / або MAC-адреси пристроїв, значення лічильників оброблених пакетів і помилок, номери, пріоритети та інформація про стан портів. Деревоподібна структура MIB містить обов'язкові (стандартні) піддерева; крім того, в ній можуть знаходитися приватні (private) піддерева, що дозволяють виробнику інтелектуальних пристроїв реалізувати будь-які специфічні функції на основі його специфічних змінних.

Агент в протоколі SNMP - це обробляє елемент, який забезпечує менеджерам, розміщеним на керуючих станціях мережі, доступ до значень змінних MIB і таким чином надає їм можливість реалізувати функції з управління та нагляду за пристроєм.

Корисним додаванням до функціональних можливостей SNMP є специфікація RMON, що забезпечує віддалене взаємодія з базою MIB. До появи RMON протокол SNMP не міг використовуватися віддаленим чином, він допускав лише локальне управління пристроями. Однак RMON найкраще діє в поділюваних мережах, де він здатний контролювати весь трафік. Але якщо в мережі присутній комутатор, фільтруючий трафік таким чином, що він стає невидимим для порту, якщо не призначений для пристрою, пов'язаного з цим портом, або не походить з цього пристрою, то дані вашого зонда постраждають.

Щоб уникнути цього виробники забезпечили деякими функціями RMON кожен порт комутатора. Це більш масштабируемая система, ніж система постійного опитування всіх портів комутатора.

аналізатори протоколів

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

У цій непростій ситуації ви можете використовувати різні засоби і перш за все - кошти моніторингу в системах управління мережею, які вже обговорювалися в попередніх розділах статті. Деякі вимірювання на мережі можуть бути виконані і вбудованими в операційну систему програмними вимірювачами, прикладом тому служить компонент ОС WindowsNTPerformanceMonitor. Ця утиліта була розроблена для фіксації активності комп'ютера в реальному масштабі часу. З її допомогою можна визначити більшу частину «вузьких місць», що знижують продуктивність.

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

Але найбільш досконалим засобом дослідження мережі є аналізатор протоколів. Процес аналізу протоколів включає захоплення циркулюючих в мережі пакетів, що реалізують той чи інший мережевий протокол, і вивчення вмісту цих пакетів. Грунтуючись на результатах аналізу, можна здійснювати обґрунтоване і зважене зміна будь-яких компонентів мережі, оптимізацію її продуктивності, пошук і усунення неполадок. Очевидно, що для того, щоб можна було зробити якісь висновки про вплив деякого зміни на мережу, необхідно виконати аналіз протоколів до і після внесення змін.

Зазвичай процес аналізу протоколів займає досить багато часу (до декількох робочих днів) і включає в себе наступні етапи:

1. Захоплення даних.
2. Перегляд захоплених даних.
3. Аналіз даних.
4. Пошук помилок.
5. Дослідження продуктивності. Розрахунок коефіцієнта використання пропускної здатності мережі або середнього часу реакції на запит.
6. Докладне дослідження окремих ділянок мережі. Зміст робіт на цьому етапі залежить від результатів, отриманих при аналізі мережі.

На цьому можна закінчити розгляд теоретичних моментів, які необхідно враховувати при побудові системи моніторингу вашої мережі, і перейти до розгляду програмних продуктів, створених для аналізу роботи корпоративної мережі і контролю за нею.

Продукти для моніторингу та аналізу

Порівняльний огляд систем управління HPOpenView і CabletronSpectrum

Кожен комплект розглянутих в цьому розділі додатків розбиває управління мережею приблизно на чотири області. Перша - це інтеграція комплекту в загальну інфраструктуру управління мережею, що має на увазі підтримку різних типів пристроїв того ж виробника.

Наступна функціональна область - це кошти конфігурації і управління окремими мережевими пристроями, такими як концентратор, комутатор або зонд.

Третя область - це кошти глобального управління, які відповідають вже за групування пристроїв і організацію зв'язків між ними, наприклад додатки генерації схеми мережевої топології.

Темою цієї статті є четверта функціональна область - моніторинг трафіку. І хоча кошти конфігурації ВЛВС і глобальне управління є досить важливими аспектами мережевого адміністрування, в окремій мережі Ethernet формальні процедури управління мережею впроваджувати, як правило, недоцільно. Досить провести ретельне тестування мережі після інсталяції і час від часу перевіряти рівень навантаження.

Хороша платформа для систем управління корпоративними мережами повинна володіти такими якостями:

• масштабованість;
• істинної распределенностью відповідно до концепції «клієнт / сервер»;
• відкритістю, що дозволяє впоратися з різнорідним - від настільних комп'ютерів до мейнфреймів - обладнанням.

Перші дві властивості тісно пов'язані. Хороша масштабованість досягається за рахунок распределенности системи управління. Розподіленість тут означає, що система може включати кілька серверів і клієнтів.

Підтримка різнорідного обладнання - скоріше бажане, ніж реально існуюче властивість сьогоднішніх систем управління. Ми розглянемо два популярних продукту мережевого управління: Spectrum компанії CabletronSystems і OpenView фірми Hewlett-Packard. Обидві ці компанії самі випускають комунікаційне обладнання. Природно, система Spectrum найкраще управляє обладнанням компанії Cabletron, а OpenView - обладнанням компанії Hewlett-Packard.

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

Щоб уникнути такої ситуації розробники систем управління включають підтримку не тільки стандартних баз MIBI, MIBII і RMONMIB, а й численних приватних фірм - виробників MIB. Лідер в цій області - система Spectrum, що підтримує більше 1000 баз MIB різних виробників.

Однак безперечною перевагою OpenView є її здатність розпізнавати мережеві технології будь-яких мереж, що працюють по TCP / IP. У Spectrum ця здатність обмежується мережами Ethernet, TokenRing, FDDI, ATM, розподіленими мережами, мережами з комутацією. При збільшенні пристроїв в мережі більш масштабованої виявляється Spectrum, де кількість обслуговуваних вузлів нічим не обмежена.

Очевидно, що, незважаючи на наявність слабких і сильних місць у тієї й іншої системи, якщо в мережі переважає обладнання від будь-якого одного виробника, наявність додатків управління цього виробника для будь-якої популярної платформи управління дозволяє адміністраторам мережі успішно вирішувати багато завдань. Тому розробники платформ управління поставляють разом з ними інструментальні засоби, що спрощують розробку додатків, а наявність таких додатків і їх кількість вважаються дуже важливим фактором при виборі платформи управління.

Системи для мереж широкого класу

Це сектор недорогих систем для не дуже критичних до збоїв мереж, в нього входять FoundationAgentMulti-Port, Foundation Probe, Foundation Manager виробництва NetworkGeneral. Вони являють собою закінчену систему мережевого моніторингу на базі RMON і включають два типи агентів-моніторів - FoundationAgent і FoundationProbe, а також консоль оператора FoundationManager.

FoundationAgentMulti-Port підтримує всі можливості стандартного SNMP-агента і розвинену систему збору та фільтрації даних, а також дозволяє за допомогою одного комп'ютера збирати інформацію з сегментів Ethernet або TokenRing.

FoundationProbe - сертифікований комп'ютер з сертифікованої мережевою платою і встановленим програмним забезпеченням FoundationAgent відповідного типу. FoundationAgent і FoundationProbe зазвичай функціонують в безмоніторном і безклавіатурного режимі, оскільки управляються програмним забезпеченням FoundationManager.

Програмне забезпечення консолі FoundationManager поставляється в двох варіантах - для Windows-систем і для UNIX.

Консоль FoundationManager дозволяє відображати в графічному вигляді статистику по всіх контрольованих сегментам мережі, автоматично визначати усереднені параметри мережі і реагувати на перевищення допустимих меж параметрів (наприклад, запускати програму-оброблювач, ініціювати SNMP-trap і SNA-alarm), будувати за зібраними даними RMON графічну динамічну карту трафіку між станціями.

Системи для розподілених мереж

Це сектор дорогих систем вищого класу, призначених для аналізу та моніторингу мереж, що пред'являють максимально можливі вимоги щодо забезпечення надійності і продуктивності. У нього входить продукт DistributedSnifferSystem (DSS), який являє собою систему, що складається з декількох розподілених по мережі апаратних компонентів і програмного забезпечення, необхідного для безперервного аналізу всіх, включаючи віддалені, сегментів мережі.

Система DSS будується з компонентів двох типів - SnifferServer (SS) і SniffMasterConsole (SM). Як інтерфейсів для взаємодії з консоллю можуть бути використані карти Ethernet, TokenRing або послідовний порт. Таким чином, є можливість контролювати сегмент практично будь-який мережевий топології і використовувати різні середовища взаємодії з консоллю, включаючи з'єднання по модему.

Програмне забезпечення SnifferServer складається з трьох підсистем - моніторингу, інтерпретації протоколів і експертного аналізу. Підсистема моніторингу являє собою систему відображення поточного стану мережі, що дозволяє отримувати статистику по кожній зі станцій і сегментів мереж по кожному з використовуваних протоколів. Дві інші підсистеми заслуговують окремого обговорення.

У функції підсистеми інтерпретації протоколів входить аналіз захоплених пакетів і як можна більш повна інтерпретація кожного з полів заголовків пакетів і його вмісту. Компанія NetworkGeneral створила найпотужнішу підсистему подібного типу - ProtocolInterpreter здатний повністю декодувати більше 200 протоколів всіх семи рівнів моделі ISO / OSI (TCP / IP, IPX / SPX, NCP, DECnetSunNFS, X-Windows, сімейство протоколів SNAIBM, AppleTalk, BanyanVINES, OSI, XNS, Х.25, різні протоколи міжмережевоговзаємодії). При цьому відображення інформації можливо в одному з трьох режимів - Загалом, детальному і шістнадцятковому.

Основне призначення системи експертного аналізу (ExpertAnalysis) - скорочення часу простою мережі і ліквідація «вузьких місць» мережі за допомогою автоматичної ідентифікації аномальних явищ і автоматичної генерації методів їх вирішення.

Система ExpertAnalysis забезпечує те, що компанія NetworkGeneral називає активним аналізом. Для розуміння цієї концепції розглянемо обробку одного і того ж помилкового події в мережі системами традиційного пасивного аналізу і системою активного аналізу.

Припустимо, в мережі о 3:00 ночі стався широкомовний шторм, який викликав о 3:05 збій системи створення архівних копій баз даних. До 4:00 шторм припиняється і параметри системи входять в норму. У разі роботи в мережі системи пасивного аналізу трафіку прийшли на роботу до 8:00 адміністратори не мають для аналізу нічого, крім інформації про другий збої і, в кращому випадку, загальної статистики по трафіку за ніч - розмір будь-якого буфера захоплення не дозволить зберігати весь трафік , що пройшов за ніч по мережі. Імовірність ліквідації причини, що призвела до широковещательному шторму, в такій ситуації вкрай мала.

А тепер розглянемо реакцію на ті ж події системи активного аналізу. О 3:00, відразу після початку широковещательного шторму, система активного аналізу фіксує настання нестандартної ситуації, активує відповідний експерт і фіксує видану їм інформацію про подію і його причини в базі даних. О 3:05 фіксується нова нестандартна ситуація, пов'язана зі збоєм системи архівування, і фіксується відповідна інформація. В результаті о 8:00 адміністратори отримують повний опис проблем, що виникли, їх причин і рекомендації щодо усунення цих причин.

Переносні системи аналізу та моніторингу

Портативний варіант аналізатора, майже аналогічний за своїми можливостями DSS, реалізований в продуктах серії ExpertSnifferAnalyzer (ESA), відомий також як TurboSnifferAnalyzer. При значно меншій, ніж продукти серії DSS, вартості ESA надають адміністратору ті ж можливості, що і повномасштабна DSS, але тільки для того сегмента мережі, до якої ESA підключений в даний момент. Існуючі версії забезпечують повний аналіз, інтерпретацію протоколів, а також моніторинг підключеного сегмента мережі або лінії межсегментной зв'язку. При цьому підтримуються ті ж мережеві топології, що і для систем DSS. Як правило, ESA використовуються для періодичної перевірки некритичних сегментів мережі, на яких недоцільно постійно використовувати агент-аналізатор.

Аналізатор протоколів LANalyser компанії Novell

LANalyser поставляється у вигляді мережевої плати та програмного забезпечення, які необхідно встановлювати на персональному комп'ютері, або у вигляді ПК - з уже встановленими платою і програмним забезпеченням.

LANalyser має розвинений зручний призначений для користувача інтерфейс, за допомогою якого встановлюється обраний режим роботи. Меню ApplicationLANalyser є основним засобом настройки режиму перехоплення і пропонує на вибір варіанти набору протоколів, фільтрів, ініціаторів, аварійних сигналів і т.д. Даний аналізатор може працювати з протоколами NetBIOS, SMB, NCP, NCPBurst, TCP / IP, DECnet, BanyanVINES, AppleTalk, XNS, SunNFS, ISO, EGP, NIS, SNA і деякими іншими.

Крім цього в LANalyser включена експертна система, що надає користувачеві допомогу в пошуку несправностей.

висновок

Всі перераховані вище системи, безумовно, необхідні в мережі великої корпорації, однак занадто громіздкі для організацій, в яких число користувачів мережі не перевищує 200-300 осіб. Половина функцій системи залишаться незатребуваними, а рахунок за дистрибутив злякає головного бухгалтера і керівника компанії. Тим більше що контроль за апаратними несправностями і «вузькими місцями» системи в невеликої мережі в більшості випадків цілком під силу одному-двом адміністраторам і не потребує автоматизації.

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

КомпьютерПресс 7 "2001

Оригінальна назва: A Summary of Network Traffic Monitoring and Analysis Techniques

Посилання на оригінальний текст: http://www.cse.wustl.edu/~jain/cse567-06/ftp/net_monitoring/index.html

рекомендації: представлений переклад не є професійним. Можливі відступи від тексту, неправильне трактування тих чи інших термінів і понять, суб'єктивна думка перекладача. Всі ілюстрації внесені в переклад без зміни.

Аліша сесії

Огляд методів аналізу і моніторингу мережевого трафіку

Так як продовжують рости приватні внутрішні мережі компаній, надзвичайно важливо, щоб мережеві адміністратори знали і вміли керувати вручну різними типами трафіку, який подорожує по їх мережі. Моніторинг і аналіз трафіку необхідні для того, щоб більш ефективно діагностувати та вирішувати проблеми, коли вони відбуваються, таким чином не доводячи мережеві сервіси до простою протягом тривалого часу. Доступно багато різних інструментів, які дозволяють допомогти адміністраторам з моніторингом та аналізом мережевого трафіку. Дана стаття обговорює методи моніторингу орієнтовані на маршрутизатори і методи моніторингу не орієнтовані на маршрутизатори (активні і пасивні методи). Стаття дає огляд трьох доступних і найбільш широко використовуваних методів моніторингу мережі, вбудованих в маршрутизатори (SNMP, RMON і Cisco Netflow) і надає інформацію про двох нових методах моніторингу, які використовують поєднання пасивного і активного методів моніторингу (WREN і SCNM).

1. Важливість моніторингу та аналізу мережі

Мережевий моніторинг (моніторинг мережі) - це складне завдання, що вимагає великих витрат сил, яка є життєво важливою частиною роботи мережевих адміністраторів. Адміністратори постійно прагнуть підтримати безперебійну роботу своєї мережі. Якщо мережа «впаде» хоча б на невеликий період часу, продуктивність в компанії скоротиться і (в разі організацій надають державні послуги) сама можливість надання основних послуг буде поставлена \u200b\u200bпід загрозу. У зв'язку з цим адміністраторам необхідно стежити за рухом мережевого трафіку і продуктивністю на всій мережі і перевіряти, чи з'явилися в ній проломи в безпеці.

2. Способи моніторингу та аналізу

«Аналіз мережі - це процес захоплення мережевого трафіку і його швидкого перегляду для визначення того, що сталося з мережею» - Анжелла Оребаух. У наступних розділах обговорюються два способи моніторингу мережі: перший - маршрутизатор-орієнтований, другий - не орієнтований на маршрутизатори. Функціональність моніторингу, який вбудований в самі маршрутизатори і не вимагає додаткової установки програмного або апаратного забезпечення, Називають методами, заснованими на маршрутизаторі. Які базуються на маршрутизаторах методи вимагають установки апаратного і програмного забезпечення і надають велику гнучкість. Обидві техніки обговорюються нижче у відповідних розділах.

2.1. Методи моніторингу засновані на маршрутизаторі

Методи моніторингу засновані на маршрутизаторі - вшиті (вшиті) в маршрутизаторах і, отже, мають низьку гнучкість. Короткий опис найбільш часто використовуваних методів такого моніторингу наведені нижче. Кожен метод розвивався багато років перш ніж стати стандартизованим способом моніторингу.

2.1.1. Протокол простого мережевого моніторингу (SNMP), RFC 1157

SNMP - протокол прикладного рівня, який є частиною протоколу TCP / IP. Він дозволяє адміністраторам керувати продуктивністю мережі, знаходити й усувати проблеми, планувати зростання мережі. Він збирає статистику по трафіку до кінцевого хоста через пасивні датчики, які реалізуються разом з маршрутизатором. У той час, як існують дві версії (SNMPv1 і SNMPv2), даний розділ описує тільки SNMPv1. SNMPv2 побудований на SNMPv1 і пропонує ряд удосконалень, таких як додавання операцій з протоколами. Стандартизується ще один варіант версії SNMP. Версія 3 (SNMPv3) знаходиться на стадії розгляду.

для протоколу SNMP притаманні три ключові компоненти: керовані пристрої (Managed Devices), агенти (Agents ) І системи управління мережею (Network Management Systems - NMSs). Вони показані на рис. 1.

Мал. 1. Компоненти SNMP

Керовані пристрої включають в себе SNMP-агента і можуть складатися з маршрутизаторів, перемикачів, комутаторів, концентраторів, персональних комп'ютерів, принтерів і інших елементів, подібних до цих. Вони несуть відповідальність за збір інформації та роблять її доступною для системи управління мережею (NMS).

Агенти включають в себе програмне забезпечення, яке володіє інформацією з управління, і переводять цю інформацію в форму, сумісну з SNMP. Вони закриті для пристрою управління.

Системи управління мережею (NMS) виконують додатки, які займаються моніторингом і контролем пристроїв управління. Ресурси процесора і пам'яті, які необхідні для управління мережею, надаються NMS. Для будь-якої керованої мережі повинна бути створена хоча б одна система управління. SNMP може діяти виключно як NMS, або агент, або може виконувати свої обов'язки або ін.

Існує 4 основних команди, що використовуються SNMP NMS для моніторингу і контролю керованих пристроїв: читання, запис, переривання і операції перетину. Операція читання розглядає змінні, які зберігаються керованими пристроями. Команда записи змінює значення змінних, які зберігаються керованими пристроями. Операції перетину володіють інформацією про те, які змінні керованих пристроїв підтримують, і збирають інформацію з підтримуваних таблиць змінних. Операція переривання використовується керованими пристроями для того, щоб повідомити NMS про настання певних подій.

SNMP використовує 4 протокольні операції в порядку дії: Get, GetNext, Set і Trap. Команда Get використовується, коли NMS видає запит на інформацію для керованих пристроїв. SNMPv1-запит складається з заголовка повідомлення і одиниці даних протоколу (PDU). PDU-повідомлення містить інформацію, яка необхідна для успішного виконання запиту, який буде або отримувати інформацію від агента, або ставити значення в агента. Керований пристрій використовує SNMP агентів, розташованих в ньому, для отримання необхідної інформації і потім посилає повідомлення NMS "у, з відповіддю на запит. Якщо агент не володіє будь якою інформацією стосовно запиту, він нічого не повертає. Команда GetNext буде отримувати значення наступного примірника об'єкта. Для NMS також можливо надсилати запит (операція Set), коли встановлюється значення елементів без агентів. коли агент повинен повідомити NMS-події, він буде використовувати операцію Trap.

Як говорилося раніше, SNMP - протокол рівня додатків, який використовує пасивні сенсори, щоб допомогти адміністратору простежити за мережевим трафіком і продуктивністю мережі. Хоча, SNMP може бути корисним інструментом для мережевого адміністратора, він створює можливість для загрози безпеки, тому що він позбавлений можливості аутентифікації. Він відрізняється від віддаленого моніторингу (RMON), який обговорюється в наступному розділі, тим, що RMON працює на мережевому рівні і нижче, а не на прикладному.

2.1.2. Віддалений моніторинг (RMON), RFS 1757

RMON включає в себе різні мережеві монітори і консольні системи для зміни даних, отриманих в ході моніторингу мережі. Це розширення для SNMP інформаційної бази даних з управління (MIB). На відміну від SNMP, який повинен посилати запити про надання інформації, RMON може настроювати тони, які будуть «моніторити» мережу, засновану на певному критерії. RMON надає адміністраторам можливості управляти локальними мережами також добре, як віддаленими від однієї певної локації / точки. Його монітори для мережевого рівня наведені нижче. RMON має дві версії RMON і RMON2. Однак у цій статті йдеться тільки про RMON. RMON2 дозволяє проводити моніторинг на всіх мережевих рівнях. Він фокусується на IP-трафіку і трафіку прикладного рівня.

Хоча існує 3 ключові компоненти моніторингової середовища RMON, тут наводяться тільки два з них. Вони показані на рис. 2 нижче.

Мал. 2. Компоненти RMON

Два компонента RMON це датчик, також відомий як агент або монітор, і клієнт, також відомий як керуюча станція (станція управління). На відміну від SNMP датчик або агент RMON збирає і зберігає мережеву інформацію. Датчик - це вбудоване в мережеве пристрій (наприклад маршрутизатор або перемикач) програмне забезпечення. Датчик може запускатися також і на персональному комп'ютері. Датчик повинен поміщатися для кожного різного сегмента локальної або глобальної мережі, так як вони здатні бачити трафік, який проходить тільки через їхні канали, але вони не знають про трафік за їх межами. Клієнт - це зазвичай керуюча станція, яка пов'язана з датчиком, що використовують SNMP для отримання і корекції RMON-даних.

RMON використовує 9 різних груп моніторингу для отримання інформації про мережу.

• Statistics - статистика виміряна датчиком для кожного інтерфейсу моніторингу для даного пристрою.
• History - облік періодичних статистичних вибірок з мережі і зберігання їх для пошуку.
• Alarm - періодично бере статистичні зразки і порівнює їх з набором порогових значень для генерації події.
• Host - містить статистичні дані, пов'язані з кожним хостом, виявленим в мережі.
• HostTopN - готує таблиці, які описують вершину хостів (головний хост).
• Filters - включає фільтрацію пакетів, грунтуючись на фільтровому рівнянні для захоплення подій.
• Packet capture - захоплення пакетів після їх проходження через канал.
• Events - контроль генерації і реєстрація подій від пристрою.
• Token ring - підтримка кільцевих лексем.

Як встановлено вище, RMON, будується на протоколі SNMP. Хоча моніторинг трафіку може бути виконаний за допомогою цього методу, аналітичні дані про інформацію, отримані SNMP і RMON мають низьку продуктивність. Утиліта Netflow, яка обговорюється в наступному розділі, працює успішно з багатьма пакетами аналітичного програмного забезпечення, щоб зробити роботу адміністратора набагато простіше.

2.1.3. Netflow, RFS 3954

Netflow - це розширення, яке було представлено в маршрутизаторах Cisco, які надають можливість збирати IP мережевий трафік, якщо це задано в інтерфейсі. Аналізуючи дані, які надаються Netflow, мережевий адміністратор може визначити такі речі як: джерело і приймач трафіку, клас сервісу, причини переповненості. Netflow включає в себе 3 компоненти: FlowCaching (кешируєтся потік), FlowCollector (збирач інформації про потоках) і Data Analyzer (аналізатор даних). Мал. 3 показує інфраструктуру Netflow. Кожен компонент, показаний на малюнку, пояснюється нижче.

Мал. 3. Інфраструктура NetFlow

FlowCaching аналізує і збирає дані про IP потоках, які входять в інтерфейс, і перетворює дані для експорту.

З Netflow-пакетів може бути отримана наступна інформація:

• Адреса джерела і одержувача.
• Номер входить і виходить пристрою.
• Номер порту джерела і приймача.
• Протокол 4 рівня.
• Кількість пакетів в потоці.
• Кількість байтів в потоці.
• Тимчасової штамп в потоці.
• Номер автономної системи (AS) джерела і приймача.
• Тип сервісу (ToS) і прапор TCP.

Перший пакет потоку, що проходить через стандартний шлях перемикання, обробляється для створення кешу. Пакети з подібними характеристиками потоку використовуються для створення запису про потоці, яка поміщається в кеш для всіх активних потоків. Ця запис зазначає кількість пакетів і кількість байт в кожному потоці. Кешувального інформація потім періодично експортується в Flow Collector (складальник потоків).

Flow Collector - відповідальний за збір, фільтрування та зберігання даних. Він включає в себе історію про інформацію про потоках, які були підключені за допомогою інтерфейсу. Зниження обсягу даних також відбувається за допомогою Flow Collector "а за допомогою обраних фільтрів і агрегації.

Data Analyzer (аналізатор даних) необхідний, коли потрібно представити дані. Як показано на малюнку, зібрані дані можуть використовуватися для різних цілей, навіть відмінних від моніторингу мережі, таких як планування, облік і побудова мережі.

Перевага Netflow над іншими способами моніторингу, такими як SNMP і RMON, в тому, що в ній існує програмні пакети, призначені для різного аналізу трафіку, які існують для отримання даних від Netflow-пакетів та подання їх в більш доброзичливому для користувача вигляді.

При використанні інструментів, таких як Netflow Analyzer (це тільки один інструмент, який доступний для аналізування Netflow-пакетів), інформація, наведена вище, може бути отримана від Netflow-пакетів для створення діаграм і звичайних графіків, які адміністратор може вивчити для більшого розуміння про його мережі. Найбільша перевага використання Netflow на відміну від доступних аналітичних пакетів в тому, що в даному випадку можуть бути побудовані численні графіки, що описують активність мережі в будь-який момент часу.

2.2. Технології не засновані на маршрутизаторах

Хоча технології, які не вбудовані в маршрутизатор все ж обмежені в своїх можливостях, вони пропонують велику гнучкість, ніж технології вбудовані в маршрутизатори. Ці методи класифікуються як активні і пасивні.

2.2.1. активний моніторинг

Активний моніторинг повідомляє проблеми в мережі, збираючи вимірювання між двома кінцевими точками. Система активного виміру має справу з такими метриками, як: корисність, маршрутизатори / маршрути, затримка пакетів, повтор пакетів, втрати пакетів, нестійка синхронізація між прибуттям, вимір пропускної здатності.

Головним чином використання інструментів, такі як команда ping, яка вимірює затримку і втрати пакетів, і traceroute, яка допомагає визначити топологію мережі, є прикладом основних активних інструментів вимірювання. Обидва ці інструменту посилають пробні ICMP-пакети до точки призначення і чекають, коли ця точка відповість відправнику. Мал. 4 - приклад команди ping, яка використовує активний спосіб вимірювання, посилаючи Echo-запит від джерела через мережу в встановлену точку. Потім одержувач посилає Echo-запит назад джерела від якого прийшов запит.

Мал. 4. Команда ping (Акстівное вимір)

Даний метод може не тільки збирати одиничні метрики про активний вимірі, а й може визначати топологію мережі. Ще один важливий приклад активного виміру - утиліта iperf. Iperf - це утиліта, яка вимірює якість пропускної здатності TCP і UDP протоколів. Вона повідомляє пропускну здатність каналу, існуючу затримку і втрати пакетів.

Проблема, яка існує з активним моніторингом, - це те, що представлені проби в мережі можуть втручатися в нормальний трафік. Часто час активних проб обробляється інакше, ніж нормальний трафік, що ставить під питання важливість наданої інформації від цих проб.

згідно загальної інформації, Описаної вище, активний моніторинг - це надзвичайно рідкісний метод моніторингу, взятий окремо. Пасивний моніторинг навпаки не вимагає великих мережевих витрат.

2.2.2. пасивний моніторинг

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

Мал. 5. Установка пасивного моніторингу

Пасивні вимірювання мають справу з такою інформацією, як: трафік і суміш протоколів, кількість бітів (швидкість), синхронізація пакетів і час між прибуттям. Пасивний моніторинг може бути здійснений, за допомогою будь-якої програми, витягаючої пакети.

Хоча пасивний моніторинг не має витрат, які має активний моніторинг, він має свої недоліки. З пасивним моніторингом, вимірювання можуть бути проаналізовані тільки оф-лайн і вони не представляють колекцію. Це створює проблему, пов'язану з обробкою великих наборів даних, які зібрані під час вимірювання.

Пасивний моніторинг може бути краще активного в тому, що дані службових сигналів не додаються в мережу, але пост-обробка може викликати велику кількість тимчасових витрат. Ось чому існує комбінація цих двох методів моніторингу.

2.2.3. комбінований моніторинг

Після прочитання розділів вище, можна благополучно переходити до висновку про те, що комбінування активного і пасивного моніторингу - кращий спосіб, ніж використання першого або другого окремо. Комбіновані технології використовують кращі сторони і пасивного, і активного моніторингу середовищ. Дві нові технології, що представляють комбіновані технології моніторингу, описуються нижче. Це «Перегляд ресурсів на кінцях мережі» (WREN) і «Монітор мережі з власної конфігурацією» (SCNM).

2.2.3.1. Перегляд ресурсів на кінцях мережі (WREN)

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

Основний рівень швидкої обробки пакетів відповідає за отримання інформації, пов'язаної з вхідними та вихідними пакетами. Мал. 6 показує список інформації, яка збирається для кожного пакета. До Web100 додається буфер для збору цих характеристик. Доступ до буферу здійснюється за допомогою двох системних викликів. Один виклик починає трасування і надає необхідну інформацію для її збору, поки другий виклик повертає трасування з ядра.

Мал. 6. Інформація, зібрана на головному рівні трассіровок пакетів

Об'єкт трасування пакетів- здатний координувати обчислення між різними машинами. Одна машина буде активувати роботу іншої машини, задаючи прапор в заголовку, що минає пакета для початку обробки деякого діапазону пакетів, які вона трассирует. Інша машина буде в свою чергу трассіровать все пакети, для яких вона бачить, що в заголовку встановлений схожий прапор. Така координація забезпечує те, що інформація про схожих пакетах зберігається в кожній кінцевій точці незалежно від зв'язку і того, що відбувається між ними.

Аналізатор трассіровок призначеного для користувача рівня - інший рівень в середовищі WREN. Це компонент, який починає трасування будь-якого пакета, збирає і обробляє повернуті дані на рівні ядра оператора. Згідно проектування, компоненти користувальницького рівня не мають потреби в читанні інформації від об'єкта трасування пакетоввсё час. Вони можуть бути проаналізовані негайно після того, як трасування буде завершена, щоб зробити висновок в реальному часі, або дані можуть бути збережені для подальшого аналізу.

Коли трафік малий, WREN буде активно вводити трафік в мережу зберігаючи порядок проходження потоків вимірювання. Після численних досліджень, знайдено, що WREN представляє схожі вимірювання в перенасичених і в не-перенасичених середовищах.

У поточній реалізації WREN, користувачі партія не тільки до захоплення трассіровок, які були ініційовані ними. Хоча будь-який користувач може стежити за трафіком додатків інших користувачів, вони обмежені в інформації, яка може бути отримана від трассіровок інших користувачів. Вони можуть тільки отримати послідовність і підтвердження чисел, але не можуть отримати актуальні сегменти даних з пакетів.

Загалом, WREN - це дуже корисна установка, яка використовує переваги і активного, і пасивного моніторингу. Хоча ця технологія знаходиться на ранньому етапі розвитку, WREN може надати адміністраторам корисні ресурси в моніторингу та аналізу їх мереж. Монітор Власного конфігурації мережі (SCNM) - інший інструментарій, який використовує технології та активного, і пасивного моніторингу.

2.2.3.2. Монітор з власної конфігурацією (SCNM)

SCNM - це інструмент моніторингу, який використовує зв'язок пасивних і активних вимірювань для збору інформації на 3 рівні проникнення, що виходять маршрутизаторів, і інших важливих точок моніторингу мережі. Середа SCNM включає і апаратний, і програмний компонент.

Апаратний засіб встановлюється в критичних точках мережі. Воно відповідає за пасивний збір заголовків пакетів. Програмне забезпечення запускається на кінцевій точці мережі. Мал. 7, наведений нижче, показує програмний компонент SCNM середовища.

Мал. 7. Програмний компонент SCNM

Програмне забезпечення відповідає за створення і посилку активованих пакетів, Які використовуються для старту моніторингу мережі. Користувачі будуть посилати в мережу пакети активації, що містять деталі про пакетах, які вони хочуть отримати для моніторингу та збору. Його користувачі не потребують знання місця розташування SCNM-хоста, приймаючи за істину те, що всі хости відкриті для «прослушки» пакетів. На основі інформації, яка існує в рамках активационного пакета, фільтр поміщається в потік збору даних, який також працює в кінцевій точці. Збираються заголовки пакетів мережевого і транспортного рівня, які відповідають фільтру. Фільтр буде автоматично введений в тайм аут, після точно заданого часу, якщо він отримує інші пакети додатки. Служба вибірки пакетів, яка запускається на SCNM-хості, використовує команду tcpdump (подібно програмі вибірки пакетів) в порядку отриманих запитів і записи трафіку, який відповідає запиту.

Коли інструментами пасивного моніторингу визначається проблема, трафік може бути сгенерірованни за допомогою інструментів активного моніторингу, дозволяючи збирати додаються дані для більш детального вивчення проблеми. При розгортанні цього монітора в мережі на кожному маршрутизаторі на протязі шляху, ми може вивчати тільки секції мережі, які мають проблеми.

SCNM призначений для установки і використання, головним чином, адміністраторами. Проте звичайні користувачі можуть використовувати деяку частину цієї функціональності. Хоча звичайні користувачі здатні використовувати частини середовища SCNM моніторингу, їм дозволено дивитися тільки свої власні дані.

На закінчення скажемо, що SCNM - це ще один спосіб комбінованого моніторингу, який використовує і активний, і пасивний методи, щоб допомогти адміністраторам моніторити і аналізувати їх мережі.

3. Висновок

Підбираючи приватні інструменти для використання їх в моніторингу мережі, адміністратор повинен спочатку вирішити, чи хоче він використовувати добре зарекомендували себе системи, які вже використовувалися багато років, або нові. якщо існуючі системи більш відповідне рішення, тоді NetFlow - найбільш корисний інструмент для використання, так як в зв'язки з цією програмою можуть використовуватися аналізує пакети даних для представлення даних в більш доброзичливому користувачеві вигляді. Проте, якщо адміністратор готовий спробувати нову систему, рішення комбінованого моніторингу, такі як WREN або SCNM, - кращий напрямок для подальшої роботи.

Стеження і аналіз мережі - життєво необхідні в роботі системного адміністратора. Адміністратори повинні намагатися утримувати свою мережу в порядку, як для НЕ розрізненої продуктивності всередині компанії, так і для зв'язку з будь-якими існуючими суспільними сервісами. Згідно вищеописаної інформації, деяке число маршрутизаторів-орієнтованих технологій і не засновані на маршрутизаторах, придатні для допомоги мережевим адміністраторам в щоденному моніторингу та аналізі їх мереж. Тут коротко описуються SNMP, RMON, і Cisco "s NetFlow - приклад декількох технологій, заснованих на маршрутизаторах. Приклади які не грунтуються на маршрутизаторах технологій, які обговорювалися в статті, - це активний, пасивний моніторинг і їх поєднання.