приложения для анализа логов web

Разработка
многопроцессного
приложения для анализа логов
web-сервера Apache
Отчет по лабораторной работе
Ревизия: 0.1
Последняя модификация: Vlad Kovtun
Дата последней модификации: 27.04.2016 14:38:00
© NRJETIX 2000 - 2008
История изменений
30.01.2011 – Версия 0.1.
Первичный документ. Влад Ковтун
Содержание
История изменений
2
Содержание
3
Лабораторная работа 2. Разработка многопроцессного приложения для анализа логов
web-сервера
5
Постановка задачи
5
Цель
5
Задачи
5
Вход
5
Пример
6
Вывод
6
Требования
6
Методические указания для самостоятельной работы
Алгоритм
Управляющий процесс
Error! Bookmark not defi
7
9
Обзор
9
Интерфейс
9
Обработка
10
Процесс первичного анализа
12
Обзор
12
Интерфейс
12
Обработка
12
Процесс вторичного анализа
12
Обзор
12
Интерфейс
12
Обработка
13
Процесс формирования результата
13
Обзор
13
Интерфейс
13
Обработка
14
Хранилища данных
14
Обзор
14
Структура хранилища первичных данных
14
Структура хранилища вторичных данных
15
Обработка
15
Программная реализация
15
Обзор
15
Работа с БД
15
Доступ к данным
15
Работа с данными
15
Межпроцессное взаимодействие
Обзор
Тестирование
Эксперимент
16
16
16
16
Описание экспериментальной установки
16
Аппаратное обеспечение
16
Программное обеспечение
17
Результаты эксперимента
17
Выводы
18
Литература
19
Лабораторная
работа 2.
Разработка
многопроцессного
приложения для анализа логов web-сервера
Постановка задачи
Цель
Разработать консольное распределенное приложение, которое анализирует логи webсервера Apache, основываясь на парадигме параллельных вычислений.
Задачи
1. Ознакомиться с понятиями процессов и потоков в ОС.
2. Ознакомиться с понятиями межпроцессного и межпоточного взаимодействия.
3. Разработать консольное распределенное приложение для параллельного анализа
нескольких файлов логов web-сервера Apache.
3.1. На основе
статистику:





файлов
логов
web-сервера,
следует
сформировать
следующую
количество уникальных посетителей за каждый день.
наиболее популярные браузеры.
наиболее популярные ОС.
наиболее популярные страницы (ссылки).
наиболее активные пользователи (IP) за каждый день.
4. Разработать тестовое приложение, которое формирует все возможные тестовые
комбинации ключей командной строки для приложения.
5. Провести исследование разработанного приложения.
5.1. Оценить производительность приложения, при различном количестве процессов
чтения и анализа. Количество процессов следует изменять от 1 до 8.
6. Оформить функциональную спецификацию на приложение. В функциональной
спецификации обязательно указать, каким образом производится тестирование на
корректность.
7. Оформить отчет к лабораторной работе.
Вход
В качестве входных данных предлагается использовать файлы логов web-сервера
Apache, которые сжаты с помощью архиватора ZIP (GZIP). Эти файлы находятся на
общедоступном сетевом хранилище, что позволяет получить к ним доступ любой
рабочей станции данной корпоративной сети.
Для управления приложением предлагается использовать следующие ключи командной
строки:





/id:<filedir> – полный путь к директории, в которой хранятся файлы логов для
анализа. Данный параметр является обязательным, если он не указан, то
происходит вывод на экран соответствующего сообщения и подсказки по
использованию данного приложения. Отметим, что путь является как локальным,
так и сетевым, что позволяет производить к нему доступ одновременно не только
с одной рабочей станции, но и с нескольких рабочих станций в сети.
/if:<filenames> - перечисление имен файлов логов через пробел, которые
необходимо проанализировать. Файлы обязаны, находится в директории
указанной с помощью ключа /id. Данный ключ позволяет осуществлять
выборочный анализ файлов логов.
/o:<filename> – полный путь к файлу, либо имя файла, который будет хранить
отчет. Если данный параметр не указывается, то вывод производится на экран.
/r:<IP_reader1 IP_reader2 IP_reader3:port> - перечисляются, через пробел, IP
адреса компонентов (с указанием портов), которые будут производить чтение
данных из файлов.
/a:<IP_analyser1 IP_analyser2 IP_analyser3:port> - перечисляются, через пробел,
IP адреса компонентов (с указанием портов), которые будут производить анализ
данных из хранилища с результатами первичного анализа.






/g:<IP_report_generator:port> - указывается IP адрес компонента (с указанием
порта), который будут производить формирование финального отчета, на основе
данных из хранилища результатов первичного анализа.
/s1:<IP_storage:port user pwd> - указывается IP адрес (или имя сервера)
компонента (с указанием порта), который является хранилищем данных –
результатов первичного анализа. Кроме того, через пробел указывается имя
пользователя и его пароль, под которым следует производить подключение. В
случае отсутствия имени пользователя и пароля, подразумевается, что будет
использоваться windows-аутентификация.
/s2:<IP_storage:port user pwd> - указывается IP адрес (или имя сервера)
компонента (с указанием порта), который является хранилищем данных –
результатов вторичного анализа. Кроме того, через пробел указывается имя
пользователя и его пароль, под которым следует производить подключение. В
случае отсутствия имени пользователя и пароля, подразумевается, что будет
использоваться windows-аутентификация.
/start:<date> - указывается дата, с которой интересует информация в логах.
Если дата не указана, то берется самая первая дата из записей логов.
/finish:<date> - указывается дата, до которой интересует информация в логах.
Если дата не указана, то берется самая последняя дата из записей логов.
/? - вывод информации о допустимых ключах командной строки.
Параметры –
компонента.
размеры
буферов,
настраиваются
индивидуально
для
каждого
Пример
Анализ 9 файлов логов web-сервера Apache, которые находятся
хранилище \\file-storage\logs\ результат
анализа выводится в
storage\reports\report.dat.
в публичном
файл
\\file-
C:/>analyser.exe /id:”\\file-storage\logs\” /if:access-www.1.log access-www.2.log accesswww.3.log access-www.4.log access-www.5.log access-www.6.log access-www.7.log
access-www.8.log access-www.9.log /r:192.168.1.20 192.168.1.21 /a:192.168.1.20:8800
192.168.1.22
/g:192.168.1.22:8800
/s1:192.168.1.23
/s2:192.168.1.24
/o:”\\filestorage\reports\report.dat
Вывод
Во время работы приложения, рекомендуется выводить информацию
приложения, а также о корректности его работы на консоль.
о статусе
Другими словами, необходимо анализировать, сколько процентов из каждого файла –
проанализировано.
Допускается перенаправление вывода консоли в текстовый файл, например:
C:/>analyser.exe /id:”\\file-storage\logs\” /if:access-www.1.log access-www.2.log accesswww.3.log access-www.4.log access-www.5.log access-www.6.log access-www.7.log
access-www.8.log access-www.9.log /r:192.168.1.20 192.168.1.21 /a:192.168.1.20:8800
192.168.1.22
/g:192.168.1.22:8800
/s1:192.168.1.23
/s2:192.168.1.24
/o:”\\filestorage\reports\report.dat >console.txt
Требования







Архитектура приложения строится по модульному принципу.
За основу принимается стандартная библиотека С++ (в случае разработки на
C++).
Рекомендуется использовать защищенные ресурсы и указатели.
Обязательным является обработка исключений.
Во время работы приложения обязательным является отображение информации о
статусе приложения, т.е. оно работает, обработано столько-то процентов текста.
Следует предусмотреть возможность работы приложения в отладочном режиме,
когда вся информация заносится в лог приложения. Допускается ведение
персонального лога для каждого из процессов (потоков).
Исходный код обязан быть комментирован. Для C# следует использовать
нотацию Microsoft XML Documentation [1], для C++ следует использовать нотацию
doxygen [2].
Алгоритм
Данное приложение предлагается строить как распределенное
разнесенное на несколько различных рабочих станций (серверов).
приложение,
Предполагается задачу анализа следует разделить на следующие подзадачи:

Управление распределенными приложениями предполагается осуществлять из
единого приложения. Наиболее приемлемым, в данном случае, является
консольное приложение, которое взаимодействует с хранилищами данных и
приложениями, работающими на рабочих станциях.
Отметим, что все подчиненные рабочие станции, по своей сути, являются серверами и
ожидают подключения к себе некоего управляющего клиента, который и будет
формировать им задачи (детально опишем их далее).

Открытие файла лога, разархивирование его «на лету» чтение строки.
Результаты первичного анализа заносятся в хранилище. Как правило, данные
накапливаются во внутреннем буфере процесса чтения и заносятся в хранилище
порциями. Размер порции определяется пропускной способностью сетевого
соединения и производительностью (загруженностью) хранилища данных. По
завершению исходных данных (достигнут конец файла)
Т.к. дальнейший анализ является достаточно сложной задачей, предполагается
вынести ее на другую рабочую станцию. Однако промежуточный результат (уже
разархивированный и подверженный первичному анализу) необходимо хранить. Для
этого предлагается создать отдельное хранилище промежуточных результатов
(хранилище
данных-результатов
первичного
анализа).
Данное
хранилище
подразумевается быть публичным, т.е. доступным всем рабочим станциям сети.

Хранение данных-результатов первичного анализа.
Т.к. результатами первичного анализа будет пользоваться множество рабочих станций
вторичного анализа, то наиболее приемлемым вариантом хранилищем данных,
является сервер БД, например Microsoft SQL Server. Данные следует хранить в единой
таблице. Отметим, что данная таблица будет постоянно модифицироваться, в нее будут
добавляться записи (после первичного анализа) и удаляться записи (после вторичного
анализа). Тонкая настройка сервера БД для решения задачи активной модификации и
активной выборки, выходит за рамки данной работы.

Вторичный анализ данных-результатов первичного анализа. Производится
разбор строки-записи лога и результаты разбора заносятся в хранилище
результирующих данных. Как правило, исходные данные накапливаются во
внутреннем буфере процесса анализа, после чего происходит их окончательные
анализ. Результаты вторичного анализа хранятся во внутреннем хранилище и
заносятся в результирующее хранилище порциями. Размер обеих порций
определяется
пропускной
способностью
сетевого
соединения,
производительностью (загруженностью) хранилищ данных, производительностью
и доступным объемом памяти рабочей станции анализа.
Т.к. результатами вторичного анализа будет пользоваться несколько рабочих станций
формирования результатов, то наиболее приемлемым вариантом хранилищем данных,
является сервер БД, например Microsoft SQL Server. В него интегрирован сервис
интеллектуального анализа данных. Отметим, что данная БД будет постоянно
модифицироваться, в нее будут добавляться записи (после вторичного анализа).
Тонкая настройка сервера БД для решения задачи активной модификации, выходит за
рамки данной работы.

Формирование заданного результата по результатам вторичного анализа.
Что касается задачи получения
поставленной задачи, возможна:


заданного
результата,
то
в
зависимости
от
постепенная работа с постоянно добавляющимися данными (результат
формируется постепенно, по мере поступления данных);
работа уже с полностью добавленными данными (результат формируется лишь
тогда, когда имеются все данные).
Становится понятно, что решение каждой задачи, можно поставить перед отдельной
рабочей станцией (сервером), что позволит выполнять их параллельно. Кроме того, на
одной рабочей станции, в зависимости от ее производительности, можно запустить
несколько идентичных процессов (например, первичного анализа), так и различных
процессов (например, первичного анализа и вторичного).
Остановимся
процесс:






процессе.
Задачи, которые решает управляющий
Где находится файловое хранилище.
Какие файлы следует проанализировать.
Где находится хранилище промежуточных данных.
Для приложения вторичного анализа указывать:



управляющем
Взаимодействие с пользователями.
Общая координация (синхронизация), всех распределенных процессов.
Отслеживание статуса обработки первичных и вторичных данных, в процентах.
Подготовка хранилища первичного анализа данных. Например, произвести его
полную очистку.
Подготовку хранилища вторичного анализа данных. Например, произвести его
полную очистку.
Для приложения первичного анализа указывать:




на
Где находится хранилище промежуточных данных.
Где находится хранилище результирующих данных.
Для приложения формирования результатов:




Где находится хранилище результирующих данных.
Какие именно результаты интересны.
В каком виде их следует представить.
Куда положить необходимые результаты.
На рис. 1 представлена упрощенная UML диаграмма последовательностей, которая
демонстрирует, на примере, параллельный анализ 3-х файлов логов.
Управляющий
процесс
Процесс
чтения 1
Процесс
чтения 2
Процесс
чтения 3
Процесс
управления
очередью 1
Процесс
анализа 1
Процесс
анализа 2
Процесс
управления
очередью 2
access-www.1.log
access-www.2.log
access-www.3.log
Рис. 1. Диаграмма последовательностей
На рис. 2, приведем упрощенную UML диаграмму развертывания для случая:






управляющее приложение;
2-х рабочих станций чтения и первичного анализа;
2-х рабочих станций вторичного (окончательного) анализа;
хранилища данных-результатов первичного анализа;
хранилище данных-результатов вторичного анализа;
приложение формирование результатов.
Процесс
формирования
результата
Рабочая
станция 1
Файловое
хранилище
Управляющий
процесс
Файловое
Файловое
хранилище
1
хранилище 1
Файловое
хранилище N
Рабочая
станция 2
Рабочая
станция 3
Процесс чтения и
первичной
обработки
данных
Процесс чтения и
первичной
обработки
данных
Хранилище
промежуточных
данных
Сервер БД
Хранилище
результирующи
х данных
Сервер БД
Высокоскоростное сетевое соединение (Gigabit/Terabit Ethernet)
Процесс
вторичной
обработки
данных
Процесс
вторичной
обработки
данных
Рабочая
станция 4
Рабочая
станция 5
Рис. 2. Диаграмма развертывания распределенного приложения
Далее, более детально, остановимся на алгоритме каждого приложения.
Управляющий процесс
Обзор
Управляющий процесс производит:





Взаимодействие с пользователями.
Общая координация (синхронизация), всех распределенных процессов.
Подготовка хранилища первичного анализа данных. Например, произвести его
полную очистку.
Подготовку хранилища вторичного анализа данных. Например, произвести его
полную очистку.
Для приложения первичного анализа указывать:




Для приложения вторичного анализа указывать:



Где находится файловое хранилище.
Какие файлы следует проанализировать.
Где находится хранилище промежуточных данных.
Где находится хранилище промежуточных данных.
Где находится хранилище результирующих данных.
Для приложения формирования результатов:




Где находится хранилище результирующих данных.
Какие именно результаты интересны.
В каком виде их следует представить.
Куда положить необходимые результаты.
Интерфейс
В качестве входных данных поступает:


Адрес сетевого ресурса, где расположены файлы логов для последующего
анализа. Например, «\\file-server\logs». В качестве развития данного подхода,
возможно использование FTP сервера в качестве файлового хранилища.
Массив со списком имен файлов логов. Например, «access-www.1.log» или же
сжатые «access-www.1.gz».





Массив со списком IP адресов процессов-читателей. Например, «192.1681.22»
или же с указанием порта «192.168.1.22:8800».
Массив со списком IP адресов процессов-анализаторов. Например, «192.1681.22»
или же с указанием порта «192.168.1.22:9000».
Строка подключения к серверу БД – хранилища первичного анализа.
Строка подключения к серверу БД – хранилища вторичного анализа.
Начальная и конечная дата, за которые интересны результаты анализа.
Для проверки состояния выполняющейся
проверки текущего статуса:





задачи,
предполагается
возможность
Ожидание задания.
Выполняется анализ.
Завершено выполнение задания.
Инициализируется задание.
Кроме того, на данный сервис можно возложить задачу инициализации БД.
Обработка
Опишем алгоритм функционирования управляющего процесса в виде блок-схемы на
рис. 4.
Начало
Ввод исходных
данных
Проверка
параметров
командной строки
Проверка на
существование всех
файлов анализа, проверка
доступности всех рабочих
станций анализа и
хранения данных
Параметры
корректны
Очистка БД
первичного анализа
Инициализация и
запуск процессов
чтения и первичного
анализа
Очистка БД
вторичного анализа
Инициализация и
запуск процессов
вторичного анализа
Вывод информации об
ошибке и справки
1
Процесс
формирования
результата анализа
Конец
1
Рис. 3. Блок-схема алгоритма управляющего процесса
Подпрограмма проверки параметров командной строки проверяет:




Корректность указанных параметров.
Существование указанных файлов.
Доступность выбранных хранилищ данных для результатов первичного и
вторичного анализа.
Доступность выбранных рабочих станций первичного и вторичного анализа
данных, а также формирования результата.
Подпрограмма очистки (инициализации) БД для результатов первичного анализа, ровно
как и вторичного анализа, занимается подготовкой БД к занесению в них результатов
анализа.
Распределение файлов-логов между процессами чтения и анализа осуществляется
следующим образом: существует общая очередь, куда обращаются, по очереди,
каждый процесс. После завершения обработки указанного файла-лога, происходит
обращение к следующему и т.д., до тех пора в очереди не останется больше ни одного
файла анализа.
Следует обратить внимание, что процессы вторичного анализа запускаются лишь после
того, как будет прочитано и обработано (например, для самого простого случая) 100%
хотя бы одного файла-лога.
Процесс первичного анализа
Обзор
Данный процесс производит чтение строки из файла-лога. Отметим, что задача может
усложниться, если данному процессу потребуется читать содержимое сжатого
текстового лог-файла с помощью архиватора ZIP (GZIP). Прочитанная строка заносится
во внутренний буфер и по достижению граничного числа записей, например 256 строк,
происходит их занесение в БД первичного анализа.
Интерфейс
В качестве входных данных поступает:



Адрес сетевого ресурса, где расположены файлы логов для последующего
анализа. Например, «\\file-server\logs». В качестве развития данного подхода,
возможно использование FTP сервера в качестве файлового хранилища.
Массив со списком имен файлов логов. Например, «access-www.1.log» или же
сжатые «access-www.1.gz».
Строка подключения к серверу БД – хранилища первичного анализа.
Для проверки состояния выполняющейся
проверки текущего статуса:





задачи,
предполагается
возможность
Ожидание задания.
Выполняется анализ.
Завершено выполнение задания.
Инициализируется задание.
Кроме того, на данный сервис можно возложить задачу инициализации БД.
Обработка
Во время первичного анализа предполагается:





Для всех файлов, указанных в задании необходимо выполнить их полное чтение
и занесение в БД первичного анализа.
Каждую прочитанную строку сохраняют во временном хранилище (очереди или
массиве).
По достижении гранично-допустимого значения количества элементов в очереди,
либо по прочтении всех данных из всех файлов, происходит их занесение в БД
первичного анализа.
Отметим, что задача синхронизации множественного доступа к хранилищу,
возлагается непосредственно на сам сервер БД.
Здесь же, следует описать алгоритмы (блок-схемы) программы в целом и всех
подпрограмм.
Процесс вторичного анализа
Обзор
Данный процесс производит чтение данных из хранилища результатов первичного
анализа. Отметим, что предполагается чтение сразу до 256 записей (строки из файлалога) за один раз, что позволит сэкономить время на блокировках БД в результате
множественного доступа. Прочитанный результат первичного анализа разбирается
построчно (разбивается на составляющие подстроки, согласно описания формата
записи лог-файла). Результаты разбора строк, также заносятся во временный буфер, и
по достижении 256 записей в буфере, заносятся в БД вторичного анализа.
Интерфейс
В качестве входных данных поступает:


Строка подключения к серверу БД – хранилища результатов первичного анализа.
Строка подключения к серверу БД – хранилища результатов вторичного анализа.
Кстати, в зависимости от производительности сервера БД, возможно совмещение
хранилища первичного и вторичного на одном сервере БД.
Для проверки состояния выполняющейся
проверки текущего статуса:





задачи,
предполагается
возможность
Ожидание задания.
Выполняется анализ.
Завершено выполнение задания.
Инициализируется задание.
Кроме того, на данный сервис можно возложить задачу инициализации БД
вторичного анализа.
Обработка
Во время вторичного анализа предполагается:





Для всех выбранных записей их первичного хранилища данных, необходимо
выполнить их полное разбиение на составные части, согласно описания логзаписи.
Результаты разбора следует занести во временный структурированный массив.
По достижении массивом заданного граничного размера, например 256, следует
произвести перенос его содержимого в БД вторичного анализа.
Разобранные записи следует удалить из БД первичного анализа (Опционально,
зависит от объема данных, которые следует хранить на данном сервере. Отметим,
что производительность сервера БД резко падает в случае большого количества
запросов на создание и удаление записей. Допускается хранение данных
первичного анализа до окончания анализа всех файлов-логов в рамках задания).
Отметим, что задача синхронизации множественного доступа к хранилищам
(первичному и вторичному), возлагается непосредственно на сам сервер БД.
Здесь же, следует описать алгоритмы (блок-схемы) программы в целом и всех
подпрограмм.
Процесс формирования результата
Обзор
Данный процесс формирует запросы к серверу БД содержащему результаты вторичного
анализа, по его окончанию, что бы:





Определить количество уникальных посетителей за каждый день. Уникальность
посетителей определяется по уникальности их IP. Другими словами посчитать
количество различных IP адресов.
Отранжировать все типы браузеров, которые встречались в файлах-логов, по
убыванию количества их пользователей.
Отранжировать все типы ОС, которые встречались в файлах-логов, по убыванию
количества их пользователей.
Отранжировать все ссылки, которые встречались в файлах-логов, по убыванию
количества их посетителей. С целью оптимизации нагрузки на сервер БД,
предполагается возле каждой строки – адреса хранить ее целочисленный образ
(хеш-образ). Дальнейшее ранжирование допускается выполнять непосредственно
по образу строки. С другой стороны, имеет смысл показывать лишь первых 100
записей, что также позволит снизить нагрузку на сервер БД.
Отранжировать все IP, которые встречались в файлах-логов, по убыванию
количества их появления. С другой стороны, имеет смысл показывать лишь
первых 100 записей, что также позволит снизить нагрузку на сервер БД.
Интерфейс
В качестве входных данных выступает:




Строка подключения к серверу БД – хранилища результатов вторичного анализа.
Запрос на количество уникальных посетителей. Указывается, за какой период
времени следует формировать результат.
Запрос на дату и время первой и последней записей во всех анализируемых
записях лог-файлов.
Наиболее популярные браузеры на заданный промежуток времени.



Наиболее популярные ОС на заданный промежуток времени.
Наиболее популярные страницы (ссылки) на заданный промежуток времени.
Наиболее активные пользователи (IP) на заданный промежуток времени.
В качестве выходных данных выступает:





Количество уникальных посетителей на заданный промежуток времени.
Наиболее популярные браузеры на заданный промежуток времени.
Наиболее популярные ОС на заданный промежуток времени.
Наиболее популярные страницы (ссылки) на заданный промежуток времени.
Наиболее активные пользователи (IP) на заданный промежуток времени.
Для проверки состояния выполняющейся
проверки текущего статуса:




задачи,
предполагается
возможность
Ожидание задания.
Выполняется анализ.
Завершено выполнение задания.
Инициализируется задание.
Кроме того, на данный сервис можно возложить задачу инициализации БД.
Обработка

Здесь же, следует описать алгоритмы (блок-схемы) программы в целом и всех
подпрограмм.
Хранилища данных
Обзор
В качестве
реализует:




хранилища
данных
предполагается
использовать
сервис,
который
Транзакционность работы с данными.
Целостность данных.
Синхронизацию множественных подключений при работе с общими данными.
Поддерживает большие объемы хранимых данных.
Как правило, такие
управления) БД.
задачи
эффективно
могут
решаться
серверами
(системами
Структура хранилища первичных данных
На рис. 4 приведена ER-диаграмма первичного хранилища данных.
LogsTbl
Id-TblId
Id
Name
LinesTbl
Id
TblId
Line
Рис. 4. ER-диаграмма БД первичного хранилища
В таблице 1 представлено описание таблицы LogsTbl, в которой перечисляются имена
всех файлов-логов, которые были прочитаны и проанализированы.
Таблица 1. Описание полей таблицы LogsTbl
Поле
Тип
Описание
Id
int
Уникальный,
автоинкрементный,
данной записи.
Name
String(256)
Имя файла лога
идентификатор
В таблице 2 представлено описание таблицы LinesTbl, которой перечисляются все стоки
записей лог-файлов, а также хранится их принадлежность к файлу-логу.
Таблица 2. Описание полей таблицы LinesTbl
Поле
Тип
Описание
Id
int
Уникальный,
автоинкрементный,
данной записи.
TblId
int
Идентификатор
строка.
Line
String(4096)
Строка из файла-лога.
файла-лога,
из
идентификатор
какого
прочитана
Структура хранилища вторичных данных
Аналогичным образом следует описать структуру хранилища вторичных данных.
Обработка
Здесь же, можно описать логику (алгоритмы) всех хранимых процедур, если уже
принято решение об их применении.
Программная реализация
Обзор
При разработке приложения, предполагается использовать среду разработки Microsoft
Visual Studio 2005, а также язык программирования высокого уровня Microsoft C#/C++.
За основу следует взять Microsoft .Net Framework 2.0. В качестве сервера БД
предполагается использовать Microsoft SQL Server 2005.
Кроме того, за основу реализации распределенных вычислений предлагается взять
вызовы RPC реализованные посредством:




Microsoft Web Service [5].
gSOAP [4].
И т.д.
Другими словами, все приложения первичного, вторичного анализа и
формирования результатов, будут представлять собой web service, доступный в
рамках локальной сети (отметим, что данное распределенное приложение может
быть эффективно реализовано и в рамках сети Internet).
Работа с БД
Доступ к данным
Доступ к данным предполагается производить посредством Microsoft ADO.NET, а точнее
через Microsoft .Net Framework Provider, что позволит легко реализовать быстрый
доступ к данным и обеспечить целостность.
За основу будет взята надстройка над ADO.NET, которая позволит использовать классы
Connection для подключения к источнику данных и Command для работы с данными
(добавление, удаление и модификация).
Отметим, что взаимодействие с сервером БД следует производить через сетевой
протокол TCP/IP, в качестве исключения можно использовать именованные каналы.
Работа с данными
Для поддержания целостности БД, следует воспользоваться транзакциями при
добавлении/удалении/модификации
данных
из
нескольких
таблиц.
Наиболее
приемлемым способом поддержки транзакций, является использование хранимых
процедур.
Межпроцессное взаимодействие
Обзор
За основу межпроцессного взаимодействия следует взять сетевое взаимодействие по
протоколу TCP/IP через протокол HTTP посредством технологии Web-сервисов. Данный
подход позволит достаточно гибко добавлять рабочие станции первичного, вторичного
и конечного анализа (формирования результатов), в случае увеличения объемов
данные (файлов логов), а также усложнения процедур анализа и формирования
результатов.
Если же объемы данных незначительны или существуют ограничения по используемому
оборудованию, то допускается размещение нескольких процессов обработки на одной
рабочей станции, кроме того использование единого хранилища для результатов
первичного и вторичного анализа. В этом случае межпроцессное взаимодействие через
Web-сервисы приведет к лишним накладным расходам, и следует воспользоваться
обычными каналами либо общей памятью.
Тестирование
Тестирование приложения осуществляется в несколько этапов:




Разработка Unit Test (NUnit Test) в рамках каждого проекта (приложения).
Данный подход позволит проверить корректность реализации алгоритмов.
Проведение функционального тестирования.
Проведение системного тестирования, что позволит проверить корректность
функционирования всей системы в целом.
Проведение нагрузочного тестирования, что позволит проверить: какие нагрузки
(мощность процессора, объем оперативной памяти, объем постоянной памяти,
пропускная способность сетевых соединений) способны выдерживать узлы
системы. Что в свою очередь позволит четко сформировать требования к
аппаратному обеспечению реальной системы, а также выявить узкие места и
более точно построить диаграмму развертывания.
Эксперимент
Описание экспериментальной установки
Аппаратное обеспечение
Компьютер
Описание
Управляющий компьютер
CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz
RAM: DDR2 2Gb
HDD: Seagate 500 Gb SATA II ST9500420AS
LAN: Gigabit Ethernet Marvell Yukon 88E8055
Сервер БД (первичные результаты)
CPU:
RAM:
HDD:
LAN:
Сервер БД (вторичные результаты)
CPU:
RAM:
HDD:
LAN:
Сервер первичного анализа
CPU:
RAM:
HDD:
LAN:
Сервер вторичного анализа
CPU:
RAM:
HDD:
LAN:
Сервер формирования результатов
Является Управляющий компьютер
Коммутатор
Gigabit Ethernet D-Link 000
Программное обеспечение
Компьютер
Описание
Управляющий компьютер
OS: Microsoft Windows XP Professional Server Service Pack
3
Platforms/Frameworks: .NET Framework v2.0
Components: Microsoft Information Server v6.0
Сервер
БД
результаты)
(первичные
OS: Microsoft Windows 2003 Server Service Pack 3
Platforms/Frameworks: .NET Framework v2.0
Components: Microsoft SQL Server 2005 Standard Edition
Сервер
БД
результаты)
(вторичные
OS: Microsoft Windows 2003 Server Service Pack 3
Platforms/Frameworks: .NET Framework v2.0
Components: Microsoft SQL Server 2005 Standard Edition
Сервер первичного анализа
OS: Microsoft Windows 2003 Server Service Pack 3
Platforms/Frameworks: .NET Framework v2.0
Components: Microsoft Information Server v6.0
Сервер вторичного анализа
OS: Microsoft Windows 2003 Server Service Pack 3
Platforms/Frameworks: .NET Framework v2.0
Components: Microsoft Information Server v6.0
Сервер
результатов
формирования
Является Управляющий компьютер
Результаты эксперимента
Для проведения эксперимента была развернута Gigabit Ethernet сеть
компьютеров с описанной конфигурацией и программным обеспечением.
на
базе
Во время проведения эксперимента, на каждом компьютере были активизированы
счетчики производительности, с помощью которых отслеживались следующие
параметры работы вычислительной системы:






Количество процессов.
Количество потоков.
% загрузки каждого процессора.
% загрузки оперативной памяти.
Общая нагрузка на компьютер.
Активность дисковой подсистемы.
Кроме того, при разработке приложений была заложена возможность отслеживания:


Времени выполнения каждого задания.
Времени выполнения задания в целом.

В таблице 3 приведены результаты эксперимента для конфигурации:
управляющий
компьютер(1)-читатель(2)[2]-хранилище1(1)-анализатор(2)[4]хранилище2(1), где читатель(2)[2] – используется 2 компьютера, на каждом из
которых запущено 2 процесса для чтения данных из лог-файлов;
анализатор(2)[4] – используется 2 компьютера, на каждом из которых запущено
по 4 процесса для анализа данных из хранилища1.
Таблица 3. Время выполнения задания для конфигурации управляющий компьютер(1)читатель(2)[2]-хранилище1(1)-анализатор(2)[4]-хранилище2(1)
№
Параметр
ы
Управляю
щий
Читатель
Ws1
1
Время, с
2
Память,
Мб
Хранилище1
Ws2
Анализатор
Ws3
Хранилище2
Всего
Ws4
Изменим конфигурацию приложения – увеличим (уменьшим) число параллельных
процессов для компонента читатель и анализатор, результаты приведем в таблице 4.
Таблица 4. Время выполнения задания для различных конфигураций управляющий
компьютер(1)-читатель(2)[M]-хранилище1(1)-анализатор(2)[N]-хранилище2(1)
Время, с
M
1
2
3
4
5
6
7
8
1
2
3
4
5
6
7
N
8
Из таблицы 4 видно, что наибольшая производительность распределенного приложения
достигается при: необходимо указать значения M и N. Дальнейшее увеличение числа
процессов чтения и анализа не приводит к росту производительности приложения в
целом, потому что здесь следует указать почему (например, пропускная способность
сети не позволяет оперировать объемами данных, недостаточное количество памяти на
рабочих станциях … таких-то компонентов, недостаточная производительность
хранилищ данных, и т.д.)
Кроме того, следует показать, что изменение размера
промежуточных результатов, позволяет также варьировать
приложения в целом.
буферов хранения
производительность
Выводы
В результате выполнения лабораторной работы можно сделать следующие выводы:
1. Предложена архитектура распределенного приложения для анализа лог-файлов
Apache
в
виде
web-сервисов:
управляющий
компьютер(1)-читатель(2)[2]хранилище1(1)-анализатор(2)[4]-хранилище2(1).
Для
компонентов
чтения
и
первичного анализа, а также приложения вторичного анализа распределенного
приложения,
предложена
архитектура
распараллеливания
посредством
многопроцессного выполнения заданий.
2. Разработаны архитектуры для:








Управляющее приложение и формирующее финальный отчет.
Приложение чтения и первичного анализа.
Приложение вторичного анализа.
В каждом из указанных приложений, используются буферы для хранения:
Результатов чтения из файла.
Промежуточных результатов первичного анализа перед занесением в БД.
Результатов выборки из БД хранилища первичных результатов.
Промежуточных результатов вторичного анализа перед занесением в БД.
3. Предложена ER-модель обеих хранилищ промежуточных данных, а также
разработаны хранимые процедуры для работы с данными. При добавлении и
модификации данных используется транзакционная модель, что позволило обеспечить
целостность хранилища.
4. Исследована производительность распределенного приложения и его компонентов
для
конфигурации:
управляющий
компьютер(1)-читатель(2)[M]-хранилище1(1)анализатор(2)[N]-хранилище2(1). Оптимальным, по производительности, является
такое соотношение M и N. Отметим, что данное значение подбиралось эмпирически,
для выбранных конфигураций рабочих станций и сетевого оборудования.
5. Изменение объемов буферов для хранения промежуточных данных, позволил
добиться оптимальной производительности распределенного приложения при
следующих значениях буферов:




Процесс чтения и первичного анализа. Размер буфера для хранения прочитанных
строк из файла.
Процесс чтения и первичного анализа. Количество записей, готовых к занесению
в БД (хранилище первичных результатов анализа).
Процесс вторичного анализа. Число записей, считываемых из БД (хранилище
первичных результатов анализа).
Процесс вторичного анализа. Число записей, заносимых в БД (хранилище
вторичных результатов анализа).
6. и т.д.
Литература
1. Microsoft Developer Network. URL: http://www.msdn.com
2. Формирование документации к исходному коду с помощью средства doxygen. URL:
www.nrjetix.com/r-and-d/lectures
3. Описание формата лога web-сервера URL: http://www.oglib.ru/apman/logs.html
4. gSOAP. URL: http://gsoap2.sourceforge.net/
5. Your
furst
C#
Web
http://www.codeproject.com/KB/webservices/myservice.aspx
6. Другие источники литературы …
Service.
URL: