Відображення завантаженості мережі

Міністерство освіти і науки України

Чернівецький національний університет

імені Юрія Федьковича

Факультет комп’ютерних наук

Кафедра комп’ютерних систем та мереж

МОДУЛЬ ВІДОБРАЖЕННЯ ЗАВАНТАЖЕНОСТІ МЕРЕЖІ

ДЛЯ СИСТЕМИ ТЕСТУВАННЯ SQL-СЕРВЕРІВ

 

482.362.70915-05 13 51-3

(Дипломна робота)

 

2007

Анотація

 

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

Опис програми займає 22 сторінок друкованого тексту та 12 рисунків.

Зміст

1. Загальні відомості

2. Функціональне призначення

3. Опис логічної структури

3.1 Опис логічної структури складових елементів модуля

3.2 Опис систем моніторингу мережі

3.3 Опис функціонування модуля в системі тестування

3.4 Опис взаємодії класів

4. Використовувані технічні засоби

5. Виклик і завантаження

6. Вхідні дані

7. Вихідні дані

1. Загальні відомості

Дипломна робота “Модуль відображення завантаженості мережі для системи тестування SQL-серверів” призначена для розробки деякої структури класів, які дозволили б проводити графічне відображення кількості даних, що пройшли локальною мережею між SQL та WEB-серверами. Для роботи програми необхідно мати встановлене програмне забезпечення такого типу:

1)         Операційна система типу Windows NT.

2)         Web-сервер додатків.

3)         Сервер баз даних MySQL.

4)         Сервер баз даних MS SQL.

5)         Сервер баз даних Firebird.

6)         Сервер баз даних Oracle.

7)         Програма аналізу трафіку BWMeter.

8)         Пристрої підключення до локальної мережі.

В нашому випадку було використано такий набір програмного забезпечення, як : Web-сервер Jakarta Tomcat 5.0, сервера баз даних MySQL, MS SQL, Firebird, Oracle, операційна система Windows XP, драйвера для вбудованої мереженої карти Realtek 10/100 Мб. Для написання програми було використано мову програмування Java.

2. Функціональне призначення

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

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

3. Опис логічної структури

3.1 Опис логічної структури складових елементів модуля

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

1)         Класи, що забезпечують зв’язок з системою тестування SQL-серверів.

2)         Класи, що забезпечують зв’язок з системою моніторингу мережі.

3)         Класи, які призначені для формування необхідних видів зображень.

4)         Xml-файли конфігурації зображень.

Опишемо принципи функціонування розроблених частин модуля.

3.2 Опис систем моніторингу мережі

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

1.         Дата та час створення запису.

2.         Ім’я хоста (або його ІР-адреса), який пересилає інформацію.

3.         Номер порту, з якого здійснюється передача інформації.

4.         Ім’я хоста (або його ІР-адреса), який отримує інформацію.

5.         Номер порту, в який надсилається інформація.

6.         Кількість байт інформації що передана.

7.         Тип протоколу.

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

Для відображення завантаженості мережі, необхідно було розробити механізм отримання даних про проходження пакетів даних через мережну картку комп’ютера, на якому розміщувався WEB-сервер. В нашому випадку система тестування SQL-серверів була розроблена з використанням технологій сервлетів та JSP-сторінок мови Java.

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

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

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

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

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

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

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

1.         NetLimiter Pro 2.

2.         Bandwithd.

3.         BMExtremt v.2.5.

4.         DUMeter.

5.         Kerio Winroute Firewall 6.3.

6.         Пакет MRTG.

7.         BWMeter та інші.

Основними вимогами при виборі засобу аналізу трафіку було:

1.         Простота встановлення та настроювання.

2.         Безкоштовність.

3.         Використання невеликої кількості ресурсів.

4.         Можливість використання логів.

5.         Можливість запису в логи даних з мінімальним інтервалом 1 секунда.

Програми, які задовольняли вищевказаним вимогам серед наведених було тільки 2: Kerio Winroute Firewall та BWMeter. Однак з огляду першого пункту вимог було обрано програму BWMeter.

3.3 Опис функціонування модуля в системі тестування

Робота модуля в системі розпочинається на етапі виконання будь-якого тесту, а саме при виконанні методу doGet() сервлета NThread. Запуск роботи модуля відбувається під час виклику JSP-сторінки Testing, на якій виводиться вся інформація про проходження тесту. Однак до її виклику відбувається встановлення певних значень атрибутів сесії таких, як:

1.         StratTime – об’єкт Calendar, що містить дані про початок проходження тесту.

2.         EndTime – об’єкт Calendar, що містить дані про кінець проходження тесту.

3.         Додаткові атрибути для відображення графіків

Після завершення виконання тесту, управління передається на початкову сторінку Testing.jsp (див.рис.3.1.), де відбувається обробка параметрів сесії та вивід на екран сторінки з текстовими результатами.

Рис. 3.1. Початкова сторінка запуску тесту.

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

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

1.         Визначення імені класу графіка, для подальшого його генерування.

2.         Виклик додаткового класу ChartEngine, який призначений для аналізу xml-файлу конфігурацій графіків, і отримання з цього файлу за існуючим іменем графіка його параметрів.

3.         Виклик реалізації класу ChartProducer, який призначений для генерації заданого графіку по існуючим даним.

4.         Збереження отриманого зображення графіку в тимчасовій директорії.

5.         Передача графіку сторінці Testing у вигляді малюнку для його відображення.

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

Рис. 3.2 Графічні результати розподілу по типам запитів.

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

1.         Розподіл по типам запитів (показує співвідношення кількості різних видів запитів при заданому тесті).

2.         Розподіл завантаженості мережі вхідним трафіком.

3.         Розподіл завантаженості мережі вихідним трафіком.

4.         Розподіл завантаженості мережі сумарним трафіком (включає в себе вхідний та вихідний трафік).

5.         Розподіл виділення та використання оперативної пам’яті віртуальною машиною Java.

Рис. 3.3. Відображення графіку вхідного трафіку.

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

Рис. 3.4. Графік загальної завантаженості мережі при проходженні тесту.

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

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

Рис. 3.5 Вікно використання оперативної пам’яті віртуальною машиною Java.

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

1.   Тип та розмір шрифтів.

2.   Наявність чи відсутність осей координат.

3.   Наявність чи відсутність проміжних ліній.

4.   Вибір кольорів ліній, графіка, фону тощо.

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

Рис. 3.6 Вікно діалогу збереження графіка у вигляді PNG-малюнка.

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

3.4 Опис взаємодії класів

 

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

1.         Оновлений клас Testing.

2.         Оновлений клас NThread.

3.         Класи різних видів діаграм (MyChart, MyChart2, MyChart3, MyChart4, MyChart5, MemoryUsageDemo).

4.         Клас ChartServlet.

5.         ChartEngine, ChartDescriptor, ChartProducer.

6.         PathTag.

7.         ParseData, StatisticData.

8.         Додаткові класи для зміни вигляду графіків.

9.         Конфігураційні фали та лог-файл.

Загальна структура класів та їх взаємозв’язків показана на плакаті.

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

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

Класи різних видів діаграм побудовані з врахуванням того, що для виводу можуть бути використаний будь-який з них. Тому всі вони повинні реалізовувати інтерфейс ChartProducer. В даному інтерфейсі описано метод createChart(), який повинні реалізувати всі класи діаграм. В даному методі відбувається формування параметрів відображення графіків.

Класи ChartEngine та ChartDescriptor призначені для розбору конфігураційного файлу chart-config.xml. З допомогою цих класів визначаються початкові параметри відображення всіх видів графіків, що реалізовані в системі. Файл chart-config.xml призначений для визначення існуючих типів діаграм, та збереження початкових параметрів розмірів графіків.

Класи ParseData та StatisticData призначені для аналізу лог-файлу, що створюється програмою аналізу трафіку BWMeter. Вони реалізують розбір рядків лог-файлу для визначення типу даних, які були передані (вхідний трафік чи вихідний), а після цього формують часові серії для відображення їх у вигляді графіку з допомогою класів MyChart, MyChart2, MyChart3, MyChart4, MyChart5 тощо.