Міністерство освіти і науки України
Чернівецький національний університет
імені Юрія Федьковича
Факультет комп’ютерних наук
Кафедра комп’ютерних систем та мереж
МОДУЛЬ ВІДОБРАЖЕННЯ ЗАВАНТАЖЕНОСТІ МЕРЕЖІ
ДЛЯ СИСТЕМИ ТЕСТУВАННЯ
SQL
-СЕРВЕРІВ
482.362.70915-
0
5 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) Операційна систематипу WindowsNT.
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. Опис логічної структури
Логічну структуру модуля можна поділити на наступні складові елементи:
1) Класи, що забезпечують зв’язок з системою тестування SQL-серверів.
2) Класи, що забезпечують зв’язок з системою моніторингу мережі.
3) Класи, які призначені для формування необхідних видів зображень.
4) Xml-файли конфігурації зображень.
Опишемо принципи функціонування розроблених частин модуля.
Суть аналізу трафіку полягає в тому, що деяка програма перехоплює пакети, що надсилаються в мережу, і робить записи про їх проходження. Після створення запису, вона пересилає пакет далі в мережу. Запис про проходження пакету повинен включати в себе наступну інформацію:
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 тощо.
4. Використовувані технічні засоби
При роботі Web-додатків до технічних засобів, що використовуються відносяться комп’ютер, на якому встановлений Web-сервер додатків Jakarta Tomcat 5.0. Технічні характеристики комп’ютера наступні:
1) Процесор Celeron 2000MHz.
2) Об’єм оперативної пам’яті: 512 Мб.
3) Об’єм жорсткого диску: 40 Гб.
4) Мережна карта стандарту Ethernet/Fast Ethernet.
Для роботи сервера баз даних при розробці використовувались наступні параметри комп’ютера:
1) Процесор Celeron 2000 MHz.
2) Об’єм оперативної пам’яті 1 Гб.
3) Об’єм жорсткого диску 40 Гб.
4) Мережна карта стандарту Ethernet/Fast Ethernet.
Для більшого уточнення технічних параметрів комп’ютера необхідно вказати повну конфігурацію ПК. В даній роботі всі використані комп’ютери мали марку Medio 80 фірми PrimePC. Однак дані комп’ютери поставляються з кількість оперативної пам’яті 256 Мб. Тому, ми змушені були додати кількість оперативної пам’яті до необхідної. Технічні характеристики добавленої оперативної пам’яті відповідали параметрам вже встановленій на таких ПК.
5. Виклик і завантаження
Для роботи системи необхідно виконати наступну послідовність дій:
1. Встановити на один з комп’ютерів СКБД, які підлягають тестуванню. Додатково для сервера MS SQL створити пусту базу даних testing та користувача з правами зовнішнього доступу до бази даних. Для сервера Oracle необхідно створити також пусту базу даних та користувача.
2. Перевірити, чи визначені номера портів СКБД співпадають з номерами, які записані в спеціальних файлах системи.
3. На іншому комп’ютері встановити Web-сервер Jakarta Tomcat 5.0.
4. Встановити на цьому розроблені веб-додатки згідно правил, які визначені цим сервером.
5. Встановити на комп’ютері Web-сервера J2SE Development Kit Update 2та J2SE Runtime Environment Update 2.
6. Встановити змінні оточення: path, classpath, java_home, catalina_home.
7. Запустити на виконання Web-сервер шляхом запуску файла startup.bat.
8. На комп'ютері користувача звернутися до основної сторінки системи тестування, наприклад http://10.30.60.3:8080/Kyzuk.
9. Почати роботу з системою.
6. Вхідні дані
При виконанні програми, класи використовують певні вхідні дані, які в основному розміщені в спеціалізованих файлах. Опис та призначення цих файлів наведено нижче.
Загальний опис вхідних даних для проведення тестування наведемо на прикладі організації вхідних даних для SQL-сервера MySQL. Для роботи модуля також необхідні додаткові файли конфігурації та лог-файли програми аналізатора мереженого трафіку.
Всі дані, які необхідні для роботи сервера, розміщуються в теці, назва якої співпадає з назвою SQL-сервера. В нашому випадку – MySQL. В цій теці розміщені наступні файли: MySQL.txt, title.txt, data.txt, clear.txt, select.txt, insert.txt, update.txt та delete.txt. Тека також містить підтеку Generators, в якій знаходяться файли та класи, які призначені для автоматичної генерації запитів типу INSERT для даного SQL-сервера.
Рис. 6.1 Розміщення та назви спеціалізованих файлів даних.
Опишемо призначення та структури кожного з наведених файлів. Перш ніж розпочати опис даних файлів необхідно сказати, що всі дані в цих файлах знаходяться в простому текстовому вигляді і можуть бути змінені будь-яким текстовим редактором.
Файл MySQL.txt – це файл, що містить основні дані для роботи з базою даних. Він включає в себе:
1. Логін та пароль користувача для доступу до SQL-сервера.
2. URL-рядок для зв’язку з сервером баз даних.
3. Рядок драйвера.
4. Адресу комп’ютера, на якому розміщено СКБД.
5. Номер порта для підключення до СКБД.
6. Локальне розміщення бази даних на комп’ютері з СКБД.
Приклад такого файла для MySQL.
Рис. 6.2. Приклад файла MySQL.txt.
Файл title.txt призначений для розміщення SQL-запитів генерації структури таблиць та їх взаємозв’язків. Він містить запити на створення бази даних та запити на створення таблиць.
Рис. 6.3. Приклад файла title.txt.
Файл data.txt призначений для розміщення SQL-запитів типу insert для внесення початкових даних в таблиці бази даних testing.
Рис. 6.4. Приклад файла data.txt.
Файл clear.txt призначений для розміщення запитів видалення тестової бази зі складу СКБД. До них може відноситися запити типу drop table та drop database.
Наступні файли select.txt, insert.txt, update.txt та delete.txt містять тестові запити відповідних типів до таблиць бази даних testing. При написанні тестових запитів необхідно враховувати, яку саме частину SQL-сервера ви хочете тестувати.
Для правильного відображення графіків необхідно змінити значення конфігураційного файлу діаграм – chart-config.xml. Приклад вказання параметрів для діаграми MyChartнаведено нижче.
Рис. 6.5. Приклад вхідних параметрів для діаграми MyChart.
Нижче наведено приклад вмісту лог-файлу, який генерується програмою аналізу мереженого трафіку BWMeter.
Рис. 6.6. Приклад вмісту лог-файлу.
7.
Вихідні дані
Опис організації вихідних даних включає в себе опис результатів тестування та сервісних повідомлень. Результати тестування відображаються користувачу в наступному вигляді:
1. Назва сервера, для якого проводилось тестування.
2. Тип виконаного тесту.
3. Кількість потоків.
4. Середній час обробки одного запиту (в мілісекундах).
5. Загальний час проходження тесту (в секундах).
Приклад результатів роботи системи Web-додатків зображений на рис. 3.2-3.4. Як бачимо, після отримання результатів роботи програми, можна одразу продовжити наступний етап тестування, якщо заданий тест не змінює значень в тестовій базі даних (тест select). Для правильності проведення інших видів тестів необхідно провести повну очистку тестової бази, та внесення початкових даних. Для цього необхідно перейти на головну сторінку системи тестування. скориставшись посиланням, яке розміщено внизу сторінки результатів.
Вихідними даними являються також згенеровані графіки та діаграми завантаженості мережі, використання оперативної пам’яті та кількісне входження запитів у тест. Дані графіків можна зберегти у файли, використовуючи кнопки, які розміщені внизу сторінки виводу результатів.
|
