CC BY
28
УДК 004.56:004.65
Р. Ф. Гибадуллин, А. А. Новиков, И. Н. Смирнов, М. Ю. Перухин
РАЗРАБОТКА МОДУЛЯ МОНИТОРИНГА СЕТЕВОЙ АКТИВНОСТИ ПРИ ОБРАЩЕНИИ К ЗАЩИЩЕННОЙ КАРТОГРАФИЧЕСКОЙ БАЗЕ ДАННЫХ
Ключевые слова: система управления базами данных, веб-сервер, мониторинг, сетевая активность.
В статье рассматриваются вопросы удаленной работы с картографической базой данных. Осуществляется предоставление удаленного доступа к БД, организовывается защищенный канал передачи данных, приводится описание разработанного модуля мониторинга сетевой активности при обращении к БД.
Keywords: database management system, web-server, monitoring, network activity.
This paper describes remote network with map database. Remote access for DB is provided, data transfer secured link is organized, a description of network activity module is provided while interacting with DB.
Введение
С каждым годом сфера применения геоинформационных систем становится все шире. В связи с тем, что картографические данные могут содержать конфиденциальную информацию, а работа с ними часто проводится в «полевых условиях», задача организации защищенного удаленного доступа и контроля передаваемой информации является актуальной [1].
В данной работе были исследованы возможности использования двухуровневой архитектуры Front-End + Back-End для организации защищенного удаленного доступа к БД. Также разработан модуль мониторинга сетевой активности при обращении к БД.
Веб-сервер
Веб-приложение это система, в котором сервером выступает веб-сервер, а клиентом - браузер. Сервер принимает запрос от клиента, выполняет вычислительные задачи, генерирует веб-страницу и по сети отправляет ее клиенту посредством протокола HTTP. Клиент обеспечивает пользовательский интерфейс, генерирует запросы к серверу и выполняет обработку ответов от него.
Прежде чем переходить к конфигурированию веб-сервера, необходимо внимательнее изучить схему его работы, а также основные причины, которые могут привести к нестабильной работе или даже к полному отказу в обслуживании. Четкое понимание причин позволит максимально эффективно использовать все имеющиеся у нас аппаратные ресурсы.
HTTP запрос к серверу
Содержимое страницы
-о
Статические файлы
Выполнение PHP скрипта
Статические файлы кэргинки, ess, документы
Рис. 1
Рассмотрим типичную схему работы сервера (рис.1), на примере веб-сервера Apache. При запросе пользователя страницы сайта происходит обращение к веб-серверу, который запускает интерпретатор PHP для выполнения скрипта. Далее программа
взаимодействует с СУБД и отдает результат выполнения клиенту. Кроме того, веб-сервер отдает клиенту сопутствующие файлы - картинки, документы, css файлы и другую статическую информацию.
При открытии каждой страницы клиенту может отправляться несколько десятков файлов - от действительно результата выполнения программы до статических картинок.
Важно отметить, что для отдачи каждого файла используется, как правило, отдельный процесс apache (как минимум поток), который занимает память веб-сервера. В 2012 году средний размер процесса apache в памяти составлял от 64 до 256 Мб, и можно было очень легко занять всю оперативную память процессами веб-сервера.
Можно выделить несколько узких мест в данной схеме:
□ Передача данных клиенту. Проблема медленных каналов;
□ Производительность программы. Уменьшение времени выполнения скрипта;
□ Обмен с базой данных;
□ Отдача статики. Проблема медленных каналов.
Передача данных клиенту
Работа веб-сервера организован таким образом, что его процесс занимает память системы, пока полностью не завершит отдачу файла. Таким образом, в случае если у клиента медленный канал связи, то даже при быстром выполнении программы сервер будет не справляться даже с маленькой нагрузкой.
Дополнительно, при отдаче статических файлов с помощью Apache ценная память веб-сервера используется расточительно - под выдачу статики, для обработки которой не требуется выполнять программы.
В ходе передачи веб-контента клиенту сервер будет хранить в памяти бездействующий процесс, который будет ожидать окончания передачи данных, но не способен освободить память и высвободиться сам для выполнения очередного запроса.
Раскроем эту задачу на основе следующего примера. Допустим, имеется некоторая система, в которой время генерации страницы составляет 1/10 секунды, а время передачи страницы клиенту в составляет 5 секунд.
Выполнение 100 запросов в секунду будет требовать одновременной работы 500 независимых процессов сервера. Обработав запрос за 1/10 секунды, эти процессы не в состоянии выполнять другие запросы и будут занимать память в течение 5 секунд, находясь в ожидании завершения передачи данных пользователю. На последующей секунде сервер получит 100 запросов и вынужден будет запустить 100 процессов. Таким образом, на 5-ой секунде в память должны прогрузиться 500 процессов и только с данного момента процессы 1-ой секунды высвободятся и начнут обрабатывать новые запросы.
Таким образом, для нормальной работы системы требуется запуск примерно 500 процессов, это потребует 32 Гб оперативной памяти. Следует отметить, что если бы время формирования страниц составляло 0.001 секунды, то это не увеличило бы производительность системы, так как процессы ждут передачи данных пользователям по каналам с малой скоростью, а не времени формировании страниц. Так производительность PHP и продукта никак не связана с производительностью системы.
В результате, при значительных нагрузках проект может не функционировать по следующим причинам.
Отсутствие достаточного места в оперативной памяти для одновременной работы процессов сервера и системы управления базами данных. Как правило, на каждый запрос к сайту создается отдельный процесс сервера. По достижении пиковых нагрузок осуществляется одновременный запуск большого количества процессов (превышающих нескольких сотен процессов). Это является причиной свопинга процессов, что неизбежно оказывает влияние на производительности системы управлениями базой данных.
Отсутствие аппаратных ресурсов для исправного выполнения процессов и обеспечения приемлемого для пользователя времени реакции. Такая ситуация может произойти в случае, если в вычислительные ресурсы сервера не справятся с большим числом запросов. При наличии оперативной памяти большого объема первая проблема может не проявиться. Однако возможен исход, что система перестала бесперебойно отвечать на пользовательские запросы, в несколько раз увеличилось время генерации страниц, СУБД перегружена значительным числом запросов. В таком случае возможен исход, что все без исключения пользователи не смогут работать с сервером.
Отсутствие высокопроизводительной СУБД при параллельных конкурентных запросах, не дает возможность полностью использовать аппаратно-программные ресурсы сервера.
Общая несбалансированность веб-системы при пиковых нагрузках и быстрая регрессия производительности даже при незначительных стрессах. При пиковых нагрузках вся система испытывает перегрузки.
В дополнение к перечисленным проблемам возможно возникновение проблем в дисковой подсистеме. В итоге, если под одной из составляющих начинается потеря производительности, то существен-
но падает производительность всей системы, начинается падение производительности в других частях и, в итоге, еще больше снижается работоспособность, производительность системы регрессирует и иногда наступает полная остановка в работе.
Архитектура Front-End + Back-End
Наилучшим способом для устранения вышеописанной проблемы является создание двухуровневой системы Front-End + Back-End для обработки запросов.
Front-End - публичная часть проекта, обеспечивающая прием запросов от пользователей, трансляцию запросов к Back-End и выдачу непосредственного содержимого пользователю.
Back-End - исполнительная часть системы, которая обеспечивает выполнение скриптов и формирование контентных страниц.
Рассмотрим пример конфигурации более детально. После применения оптимизации у нас должна получиться система вида, изображенного на рис.2.
Р ып рос к серверу
Содержимое страницы
Статические файлы
^ С»
Рис. 2
СУБД с настройками на премжпнлятором проимодительноеть
Обмен с БД 6ei
потерь времени
В
Статические файлы: нартинии. си, документы
Формируя архитектуру с двухуровневой структурой, перед пользователем мы выставляем Frontend систему - веб-сервер или прокси-сервер, принимающий все пользовательские запросы, обрабатывает запросы, подвергающиеся самостоятельной обработке без обращения к Back-End. Созданием первого Front-end уровня мы достигаем следующих целей:
□ минимизация количества запросов, поступающих к Back-end серверу. Необходимо достичь того, чтобы Front-end обращался к Back-end процессам исключительно для получения контента PHP-страницы. При этом запросы к статическим объектам должны самостоятельно обрабатываться легкими процессами Front-end.
□ сокращение потребление RAM при обработке статических запросов. Процессы Front-end занимают примерно от 2 до 5 Мб оперативной памяти и незначительно увеличиваются в ходе обработки статических документов. Что позволяет в несколько раз сократить потребление RAM всей системой в целом.
□ обеспечить защитой систему от фактора медленных каналов. Процессы Front-end способны передавать страницу пользователю достаточно долго, потребляя при этом незначительный объем RAM. Это условие применимо как для статических запросов, так и для HTML-страниц, полученных от PHP-процессов Back-end веб-сервера. В результате Frontend получает ответ, транслируя запрос к Back-end, освобождает процессы Back-end для выполнения других запросов, а сам передает пользователю страницу, снимая фактор каналов малой скорости.
Альтернативами Front-End серверу являются:
□ OOPS;
□ SQUID;
□ NGINX;
□ любой аналогичный продукт.
NGINX это быстрый веб-сервер (HTTP-сервер), который имеет малые требования к объему оперативной памяти, умеет обрабатывать статические запросы самостоятельно, а также выполнять функции прокси-сервера без кэширования статических объектов. Так, например, если выполняется запрос графического объекта, NGINX выполняет считывание данных с диска самостоятельно и передает файл пользователю.
OOPS и SQUID - это прокси-сервера, которые выполняют функции прокси-сервера и выполняют кэширование статических запросов с сохранением на диске или в кэше копии статических запрашиваемых объектов в течение фиксированного време-ного интервала.
Каналы защищенной передачи данных [2]
TLS/SSL: Преимущества:
1. Прозрачен для протоколов более высокого уровня;
2. Широко используется в Интернет-соединениях и приложениях;
3. Отсутствие постоянного соединения между клиентом и сервером;
4. Позволяет создать туннель для приложений, использующих TCP/IP.
Недостатки:
1. Невозможно использовать с протоколами UDP и ICMP;
2. Необходимость отслеживания состояния соединения;
3. Наличие дополнительных требований к программному обеспечению для поддержки TLS/SSL.
IPSec:
Преимущества:
1. Безопасность и надёжность защиты данных протокола проверена и доказана, так как протокол был принят как Интернет-стандарт;
2. Работа в верхнем слое сетевого протокола и шифрование данных над уровнем сетевого протокола.
Недостатки:
1. Сложность реализации;
2. Дополнительные требования к оборудованию сети (маршрутизаторы и т. п.);
3. Существует много различных реализаций, не всегда корректно взаимодействующих друг с другом.
SSH
Преимущества:
1. Позволяет создать туннель для приложений, использующих TCP/IP;
2. Слой безопасности невидим для пользователя.
Недостатки:
1. Трудность использования в сетях с большим числом шлюзов, таких как маршрутизаторы или брандмауэры;
2. Большая нагрузка на внутри сетевой трафик;
3. Невозможно использовать с протоколами UDP и
ICMP.
4. Не имеет PKI.
Мониторинг сетевой активности
Ведение логов занимает важное место в отладке и поддержке практически любой информационной системы. Организация удаленного доступа к БД, делает эту задачу еще более актуальной.
В лог должна записываться следующая информация:
□ время поступления запроса к серверу
□ IP адрес откуда поступил запрос
□ имя пользователя (если он прошел авторизацию)
□ SQL запрос (если пользователь обратился к
БД)
□ входящий/исходящий трафик
Для получения всей необходимой информации, необходимо настроить ведение логов на всех узлах системы, и организовать последующий сбор и анализ полученной информации.
Для этого было решено написать специальную программу, которая должна:
1. При запуске загружать необходимую информацию со всех узлов системы;
2. Вести итоговый лог файл, в который будет записываться собранная информация;
3. Позволять удобно и наглядно просматривать собранную информацию;
4. Производить простейший анализ работы системы;
5. Предоставлять пользователям дружественный интерфейс взаимодействия с программой.
Реализация системы [3]
Для работы была выбрана двухуровневая архитектура Front-End + Back-End (рис. 3). В роли BackEnd сервера выступает Windows Server 2012, на котором установлена СУБД PostgreSQL с поддержкой пространственных расширений (PostGIS extension). В качестве БД используется открытый набор данных Geosample (Геосэмпл). Данные отображают четыре субъекта Российской Федерации: Кемеровскую, Новосибирскую область, Алтайский край и Республику Алтай. Данный набор данных является лицензионно чистым: т.е. создан без использования материалов запрещенных для распространения без специальных соглашений и лицензий, в нем не используются материалы, созданные на основе данных Роскартогра-фии и коммерческих компаний. В задачу Back-End сервера входит обработка запросов пользователей к пространственной БД. Взаимодействие происходит не напрямую, а через Front-End сервер.
В роли Front-End сервера выступает веб-сервер Nginx, работающий под управлением операционной системы FreeBSD. Он выступает в качестве обратного прокси-сервера. В его задачу входит:
□ Самостоятельная обработка запросов пользователей к статическим данным;
□ Перенаправление запросов к БД, на Back-End сервер;
□ Отдачу пользователю результатов выполнения запросов, полученных от Back-End сервера;
□ Организация защищенного канала передачи данных;
□ Сжатие данных, перед отправкой пользователю.
□
J <N
O'gs llü Nginx FreeBSD
wo e « « > и о !> S
Рч «в
Рис. 3 Веб-сервер Nginx
Nginx [engine x] — это легкий HTTP-сервер и обратный прокси-сервер, а также TCP прокси-сервер общего назначения. В отличие от обычных веб-серверов, которые для отдачи каждого файла запускают новый процесс, nginx обрабатывает все запросы небольшим количеством процессов (обычно число процессов = числу ядер). Каждый процесс в цикле принимает новые соединения и обрабатывает текущие. При каждом цикле внутри процесса, по сути, выполняются всего две операции: считывание блока данных из начального местоположения, и передаче (запись) его в другое место. Начальным местоположением может выступать файловая система, буфер в памяти или соединение с другим вебсервером или FastCGI-процессом, конечным — соединение с клиентом. Такая модель требует гораздо меньшего количества оперативной памяти и процессорного времени, чем обычная, что позволяет обслуживать большое количество клиентов. Однако, при такой модели, нельзя выполнять длительные операции при обработке запроса (например, самостоятельная обработка php или ASPNet скриптов), т.к. время необходимое для выполнения таких операций, существенно выше, чем nginx выделяет на один цикл, что приведет к резкому возрастанию времени обработки запроса с последующим отказом в обслуживании.
Nginx может работать под управлением следующих ОС:
□ FreeBSD 3 — 10 / i386; FreeBSD 5 — 10 / amd64;
□ Linux 2.2 — 4 / i386; Linux 2.6 — 4 / amd64; Linux 3 — 4 / armv6l, armv7l, aarch64;
□ Solaris 9 / i386, sun4u; Solaris 10 / i386, amd64, sun4v;
□ AIX 7.1 / powerpc;
□ HP-UX 11.31 / ia64;
□ Mac OS X / ppc, i386;
□ ОС семейства Windows.
Однако версия nginx под Windows до сих пор рассматривается, как бета-версия и обладает рядом известных проблем:
□ Хоть и возможен запуск нескольких рабочих процессов, только один из них реально работает.
□ Рабочий процесс может обслуживать не более 1024 одновременных соединений.
□ Кэш и другие модули, требующие поддержки разделяемой памяти, не работают под Windows Vista и более поздними версиями в связи с тем, что на этих версиях Windows включена рандомизация адресного пространства.
□ На данный момент доступна не вся функциональность. Например, модулей SSL и GeolP и нет в сборках под Windows.
□ В качестве метода обработки соединений используется только select(), поэтому не стоит ожидать высокой производительности и масштабируемости.
Поэтому в качестве ОС была выбрана свободная Unix-подобная операционная система FreeBSD. Главным преимуществом Unix системы перед Windows, является более широкий функционал, стабильность и скорость работы.
Литература
1. Бабенко Л.К., Басан А.С., Журкин И.Г., Макаревич О.Б. Защита данных геоинформационных систем: учеб. Пособие для студентов вузов / Под ред. И.Г. Журкина. -М.: Гелиос АРВ, 2010. - 336 c.
2. Вершинин И.С. Стойкость ассоциативной защиты к атаке со знанием открытого текста // Вестник Казан. технол. ун-та. - 2014. - № 11 - С. 218-220.
3. Вершинин И.С., Гибадуллин Р.Ф., Пыстогов С.В., Перухин М.Ю. Импорт/экспорт ассоциативно защищенных картографических данных с их обработкой в системе Security Map Cluster // Вестник технол. ун-та. -2015. - № 10 - С. 174-180.
© Р. Ф. Гибадуллин - к.т.н.; доцент кафедры компьютерных систем КНИТУ им. А.Н. Туполева -КАИ, landwatersun@mail.ru; А. А. Новиков - аспирант; ассистент той же кафедры, novikov.cs@kstu-kai.ru; И. Н. Смирнов- магистрант; ассистент той же кафедры, 1fraer1@mail.ru; М. Ю. Перухин - к.т.н.; доцент кафедры автоматизированных систем сбора и обработки информации КНИТУ, perukhin@inbox.ru.
© R. Gibadullin - PhD associate professor of computer system department of KNRTU named after A.N.Tupolev -KAI, landwatersun@mail.ru; A. Novikov - postgraduate; assistant of the same Department, novikov.cs@kstu-kai.ru; I. Smirnov - master student; assistant of the same Department, 1fraer1@mail.ru; М. Peruhin - PhDassociate professor of automated systems for the collection and processing of information department of KNRTU, perukhin@inbox.ru.
