РАЗРАБОТКА  АРХИТЕКТУРЫ  АВТОМАТИЗИРОВАННОЙ  СИСТЕМЫ  ИЗМЕРЕНИЯ

Воротников  Владимир  Сергеевич

аспирант,  Национальный  исследовательский  университет  "МИЭТ",  РФ,  г.  Зеленоград

E-mail: 

ARCHITECTURE  DEVELOPMENT  OF  AUTOMATED  MEASUREMENT  SYSTEM

Vorotnikov  Vladimir

postgraduate,  National  Research  University  of  Electronic  Technology,  Russia,  Zelenograd

АННОТАЦИЯ

Рассмотрен  вопрос  проектирования  системы  автоматизации  и  управления  процессом  измерения  сетевой  производительности.  Разработана  архитектура  системы.  Выделены  основные  модули  и  интерфейсы.

ABSTRACT

Designing  of  the  automated  measurement  system  is  considered.  Architecture  of  the  system  is  developed.  The  basic  modules  and  interfaces  are  distinguished.

Ключевые  слова:  автоматизация;  сетевая  производительность.

Keywords :  automation;  network  performance.

Введение

В  современном  мире  безопасность  информационных  систем  играет  важную  роль.  Её  обеспечивают  множество  сетевых  средств  защиты  информации  (далее  —  ССЗИ):  шлюзы  безопасности,  межсетевые  экраны,  системы  обнаружения  вторжений  и  другие. 

В  течение  всего  процесса  разработки  и  выпуска  новых  версий  ССЗИ  важно  контролировать  их  параметры.  Одним  из  ключевых  параметров  является  производительность  данных  средств.  Ручное  измерение  производительности  является  трудоемкой  задачей.  При  этом  большую  часть  работы  составляют  однотипные  повторяющиеся  операции. 

Таким  образом,  актуальным  является  задача  автоматизации  и  управления  процессом  измерения  и  контроля  производительности  ССЗИ.  Разработаная  система  будет  опробована  на  задаче  измерения  производительности  шлюзов  безопасности  российского  производителя  сетевых  средств  защиты  «С-Терра».  Важно  отметить,  что  результаты,  полученные  в  процессе  решения  данной  задачи  могут  быть  использованы  не  только  для  контроля  производительности  ССЗИ  различных  производителей,  но  и  для  контроля  производительности  других  сетевых  средств,  не  являющихся  средствами  защиты  информации  (например,  маршрутизаторов).

Следует  также  отметить,  что  существующие  на  рынке  системы  автоматизированного  измерения  сетевой  производительности  обладают  функциональностью,  существенно  выше,  чем  необходимо  для  решения  данной  задачи.  Однако  их  практическое  применение  осложнено,  во-первых,  чрезвычайно  высокой  ценой  (от  200  000  $  на  минимальную  лицензию  с  элементами  автоматизации),  а  также  чрезмерной  эксплуатационной  сложностью  для  поставленной  задачи.  Кроме  того,  их  программный  код  закрыт  для  изменений  и  в  них  невозможно  сделать  доработки,  необходимые  для  решения  отдельных  специфичных  задач  конкретного  вендора.  Поэтому  разработка  собственной,  имеющей  все  необходимые  (но  не  более)  функции,  системы  выглядит  оправданным.  Кроме  того,  разработка  данной  системы  позволяет  уменьшить  зависимость  российских  IT-компаний,  разработчиков  сетевых  средств  от  западных  вендоров.  Таким  образом,  решение  задачи  автоматизации  и  управления  процессом  измерения  и  контроля  производительности  представляется  актуальным.

В  данной  статье  приведена  часть  решения  данной  задачи,  связанная  с  разработкой  архитектуры  автоматизированной  системы  измерения  сетевой  производительности. 

Из  опыта  разработки  различных  программных  продуктов  хорошо  известно,  что  ошибки,  совершенные  на  стадии  разработки  архитектуры  —  одни  из  самых  серьезных.  Они  требуют  больших  трудозатрат  на  исправление,  вплоть  до  полной  переделки  разрабатываемой  системы.  Важно  сделать  архитектуру  масштабируемой  и  универсальной.  Это  позволит  в  будущем,  при  изменении  требований  к  системе  —  модернизировать  её  в  относительно  короткие  сроки.  Кроме  того,  это  позволит  адаптировать  её  под  сопутствующие  задачи,  а  также  под  аналогичные  задачи  для  смежных  областей.

Разработка  общей  архитектуры  системы

Основные  обязательные  компоненты  системы  —  это  испытуемые  устройства,  нагрузочные  сервера  и  внешние  хранилища  данных.  Кроме  того,  на  одном  из  устройств  должно  работать  логическое  ядро  системы  —  сервер  управления.  Можно  для  этих  целей  использовать  один  из  нагрузочных  серверов.  Но  это  нарушает  чистоту  эксперимента  и  ухудшает  масштабируемость  системы.  Поэтому  предлагается  вынести  сервер  управления  в  отдельное  устройство.  Это  позволит  четко  логически  разграничить  управляющие  сигналы  и  нагрузочный  трафик.  Кроме  того,  такая  схема  позволяет  одной  системе  управления  контролировать  сразу  несколько  нагрузочных  стендов.  Схожую  общую  архитектуру  имеют  и  существующие  системы  измерения  производительности,  хорошо  зарекомендовавшие  себя  в  отрасли  [1]. 

Рисунок  1.  Общая  архитектура  САУ  ПИКП

Исходя  из  вышесказанного,  общая  архитектура  системы  автоматизации  и  управления  процессом  измерения  и  контроля  производительности  (далее  —  САУ  ПИКП)  представлена  на  рисунке  (Рисунок  1).

Разберем  далее,  основные  выполняемые  функции  каждой  группы  устройств  в  рамках  вышеописанной  архитектуры.

Рабочее  место  оператора.  Представляет  собой  ПК  оператора,  а  также  интерфейс  настройки  и  управления  всей  системой  в  целом.  Кроме  того,  данный  интерфейс  позволяет  просматривать  ход  проведения  измерений  и  их  результаты.  Предполагаемая  ОС  —  Windows,  Linux.

Внешнее  хранилище  данных.  Отдельный  сервер,  содержащий  некоторые,  необходимые  для  проведения  измерений  данные:  различные  версии  средств  сетевой  защиты  информации  (далее  —  ССЗИ),  вспомогательные  инструменты.  Кроме  того,  может  служить  для  хранения  результатов  измерения.  Предполагаемая  ОС  —  Windows,  Linux.

Сервер  управления.  Логическое  ядро  САУ  ПИКП.  Выполняет  и  контролирует  все  необходимые  для  проведения  измерений  действия.  Предоставляет  интерфейсы  для  обмена  данными  с  другими  устройствами  и  первично  обрабатывает  данные.  Предполагаемая  ОС  —  Linux.

Нагрузочные  устройства.  Выступают  в  роли  генераторов  трафика.  Получают  первичные,  необработанные  результаты.  За  синхронность  и  корректное  взаимодействие  нескольких  нагрузочных  серверов  отвечает  сервер  управления.  Предполагаемая  ОС  —  Linux.

Исследуемые  устройства.  Представляют  собой  сервера  с  испытуемым  ССЗИ.  Могут  работать  в  различных  режимах  и  сохраняют  информацию  о  некоторых  параметрах  работы  (таких  как  загруженность  процессора)  во  время  проведения  измерений.  За  последующую  обработку  этих  данных  отвечает  сервер  управления.  Предполагаемая  ОС  —  Linux.

Разберем  далее,  основные  потоки  данных  в  рамках  вышеописанной  архитектуры.

Рабочее  место  оператора  <->  Сервер  управления.  Рабочее  место  оператора  передает  на  сервер  управления  управляющие  команды  и  получает  обратно  обработанные  результаты  измерений.  Возможные  используемые  протоколы:  SSH,  HTTP,  FTP.

Внешнее  хранилище  данных  <->  Сервер  управления.  Сервер  управления  скачивает  с  внешнего  хранилища  данных  необходимые  для  проведения  измерений  данные  (новые  версии  ССЗИ,  новые  версии  скриптов  тестирования)  и  загружает  на  внешнее  хранилище  данных  обработанные  результаты  проведенных  измерений.  Возможные  используемые  протоколы:  FTP,  SCP.

Нагрузочные  устройства  <->  Сервер  управления.  Нагрузочные  устройства  получают  от  сервера  управления  управляющие  сигналы,  содержащие  все  необходимые  параметры  для  генерации  тестового  трафика.  Нагрузочные  устройства  сообщают  на  сервер  управления  результаты  генерации  трафика  в  необработанной  форме.  Возможные  используемые  протоколы:  SSH.

Исследуемые  устройства  <->  Сервер  управления.  Исследуемые  устройства  получают  от  сервера  управления  актуальные  версии  ССЗИ,  конфигурации  и  другие  необходимые  параметры,  которые  должны  быть  применены  в  процессе  проведения  измерений.  Исследуемые  устройства  сообщают  серверу  управления  сведения  о  своих  диагностических  показателях  в  процессе  выполнения  измерения.  Возможные  используемые  протоколы:  SSH.

Нагрузочные  устройства  <->  Исследуемые  устройства.  Нагрузочное  устройство  передает  на  исследуемые  устройства  тестовый  трафик  в  соответствие  с  заданными  параметрами.  После  его  обработки  исследуемые  устройства  передают  его  в  соответствие  со  своей  таблицей  маршрутизации  (обычно  на  другое  нагрузочное  устройство). 

Детальное  проектирование  программных  модулей.  Ключевые  моменты  процедуры  разработки.

Выделение  основных  программных  модулей

На  основе  разработанной  архитектуры,  которая  по  своей  сути  представляет  собой  проект  верхнего  уровня,  можно  составить  проект  нижнего  уровня  (детализированный  проект). 

В  разрабатываемой  системе  потребуются  следующие  программные  модули,  выполняющиеся  на  сервере  управления:

·     Модуль  интерпретации  и  представления  данных.

·     Модуль  для  удаленного  выполнения  команд  на  нагрузочных  и  исследуемых  устройствах.

·     Модуль  для  сбора  данных  с  нагрузочных  и  исследуемых  устройств.

·     Модуль  для  связи  с  рабочим  местом  оператора.

·     Модуль  для  связи  с  внешним  хранилищем  данных.

·     Центральный  логический  модуль.

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

Рассмотрим  подробнее  каждый  из  вышеуказанных  программных  модулей.

Модуль  интерпретации  и  представления  данных

Данный  модуль  предназначен  для  интерпретации  и  представления  в  различных  формах  данных,  получаемых  от  нагрузочных  и  исследуемых  устройств. 

В  качестве  входных  данных  модуль  получает  следующие  данные:

·     информацию  о  текущем  проводимом  тесте.

·     Вывод  результата  работы  утилит  iperf,  netperf,  nuttcp  в  необработанном  виде  с  нагрузочных  устройств.  Данные  утилиты  выполняют  отдельные  элементарные  измерения  производительности,  на  основе  которых  в  дальнейшем  формируется  итоговый  результат  измерения.

·     Вывод  результатов  работы  утилит  vmstat,  klogview,  sa_mgr,  в  необработанном  виде  с  испытуемых  устройств.  Данные  утилиты  позволяют  получить  информацию  о  состоянии  системы  (память,  состояние  сетевых  соединений  и  др.).

·     Результаты  выполнения  команды  cat  /proc/cpuinfo,  dmesg,  ip  address  show,  ip  route  show,  в  необработанном  виде  с  испытуемых  устройств.  Данные  утилиты  позволяют  получить  информацию  о  аппаратной  составляющей  устройства,  а  также  его  сетевых  настройках.

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

Архитектурно  модуль  представляет  собой  набор  функций  разбора  текста,  каждая  из  которых  получает  в  качестве  входных  данных  вывод  одной  из  вышеперечисленных  команд  и  разбирает  их  в  соответствие  с  их  синтаксисом.  Все  полученные  данные  заносятся  в  объект  специально  созданного  класса.  После  того,  как  объект  класса  заполняется,  функция  вывода  данных  в  табличную  форму  создает  xls-файл.  Общая  схема  работы  данного  модуля  представлена  на  рисунке  (Рисунок  2).

Рисунок  2.  Модуль  интерпретации  и  представление  данных

Модуль  для  удаленного  выполнения  команд  на  нагрузочных  и  исследуемых  устройствах

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

В  качестве  входных  данных  модуль  получает  следующие  данные:

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

·     идентификатор  устройства,  на  котором  должны  быть  выполнены  указанные  команды;

Выходными  данными  модуля  являются  необработанный  вывод  выполняемых  команд.

Архитектурно  модуль  представляет  собой  набор  функций,  которые  выполняют  определенные  команды.  Функции  выдают  необработанную  строку:  результат  выполнения  команды.  Общая  схема  работы  данного  модуля  представлена  на  рисунке  (Рисунок  3). 

Рисунок  3.  Модуль  для  удаленного  выполнения  команд  на  нагрузочных  и  исследуемых  устройствах

Модуль  для  сбора  данных  с  нагрузочных  и  исследуемых  устройств

Данный  модуль  предназначен  для  сбора  данных  с  нагрузочных  и  исследуемых  устройств.  Все  собираемые  данные  можно  условно  разделить  на  три  группы:

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

·     данные,  которые  реже  меняются  в  процессе  измерения  и  остаются  доступными  и  после  проведения  измерения  (например,  логи);

·     постоянные  данные,  не  меняющиеся  в  процессе  измерения  (например,  параметры  аппаратной  платформы).

Соответственно  подход  к  сбору  различных  групп  данных  —  также  разный.  Если  данные  третьей  группы  достаточно  собрать  один  раз  за  все  время  проведения  всех  измерений,  то  данные  второй  группы  следует  собирать  после  каждого  измерения  (однако,  если  этого  не  будет  сделано,  информация  не  потеряется,  а  только  усложнится  её  разбор  в  дальнейшем).  В  случае  же  первой  группы,  проводить  сбор  данных  непосредственно  в  процессе  измерения  —  является  критически  важным,  в  противном  случае  эти  данные  будут  потеряны  без  возможности  восстановления.

В  качестве  входных  данных  модуль  получает  следующие  данные:

·     список  собираемых  данных  первой  группы  и  параметры  частоты  их  сбора  в  формате  произвольных  команд,  служащих  для  сбора  соответствующих  данных;

·    список  собираемых  данных  второй  и  третьей  группы  в  формате  списка  файлов  в  которых  хранится  данная  информация  или  произвольных  команд,  служащих  для  сора  соответствующих  данных;

Выходными  данными  модуля  являются  необработанный  вывод  выполняемых  команд  и  необработанное  содержание  указанных  файлов.

Архитектурно  модуль  представляет  собой  набор  функций,  которые  обращаются  по  необходимости  к  функциям  модуля  для  сбора  данных  с  нагрузочных  и  исследуемых  устройств  и  складывают  полученную  информацию  в  определенную  структуру  данных.  Общая  схема  работы  данного  модуля  представлена  на  рисунке  (Рисунок  4).

Рисунок  4.  Модуль  для  сбора  данных  с  нагрузочных  и  исследуемых  устройств

Модуль  для  связи  с  рабочим  местом  оператора

Данный  модуль  предназначен  для  связи  с  рабочим  местом  оператора.  Он  предоставляет  оператору  интерфейс  для  управления  и  получения  данных  с  сервера  управления.  Важной  особенностью  данного  модуля  является  его  высокий  уровень  абстракции  и  возможность  отчуждения  и  замены.  То  есть,  возможно  переписать  данный  модуль,  предоставив  оператору  другой  интерфейс  управления  (например  другой  текстовый  или  графический  интерфейс),  дающий  те  же  возможности,  но  в  другой  форме,  при  этом  не  переписывая  ядро  системы. 

В  качестве  входных  данных  модуль  получает  следующие  данные:

·     управляющие  команды  от  оператора;

·     запросы  на  получение  информации  от  оператора.

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

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

Рисунок  5.  Модуль  для  связи  с  рабочим  местом  оператора

Модуль  для  связи  с  внешним  хранилищем  данных

Данный  модуль  предназначен  для  связи  с  внешним  хранилищем  данных.  Он  позволяет,  как  скачивать  данные  с  внешнего  хранилища,  так  и  загружать  их  туда.  Хранилище  данных  доступно  по  протоколу  FTP. 

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

В  качестве  выходных  данных  модуля  выступает  информация  о  совершенной  операции  (отчет  о  выполнении  или  отчет  о  возникшей  в  процессе  выполнения  ошибке).

Архитектурно  модуль  представляет  собой  функции  для  загрузки  и  получения  файлов  с  внешнего  хранилища  данных.  Общая  схема  работы  данного  модуля  представлена  на  рисунке  (Рисунок  6).

Рисунок  6.  Модуль  для  связи  с  внешним  хранилищем  данных

Центральный  логический  модуль

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

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

При  своей  работе  центральный  модуль  опирается  на  данные,  записанные  в  конфигурационном  файле,  а  также,  команды  передаваемые  оператором. 

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

Модуль,  выполняющийся  на  рабочем  месте  оператора.

Данный  модуль  предназначен  для  предоставления  оператору  удобного  интерфейса  управления  и  связи  рабочего  места  оператора  с  сервером  управления.  Он  предоставляет  оператору  клиентскую  часть  интерфейса  для  управления  САУ  ПИКП  и  получения  данных  с  сервера  управления. 

В  качестве  входных  данных  модуль  получает  следующие  данные:

·     управляющие  команды  от  оператора;

·     запросы  на  получение  информации  от  оператора.

Далее,  модуль  передает  их  на  сервер  управления  в  модуль  для  связи  с  рабочим  местом  оператора.

Архитектурно  модуль  представляет  собой  набор  клиентскую  часть  интерфейса  управления  и  сетевой  протокол,  обеспечивающий  двустороннюю  передачу  данных  между  рабочим  местом  оператора  и  сервером  управления.  Общая  схема  работы  данного  модуля  представлена  на  рисунке  (Рисунок  7).

Рисунок  7.  Модуль,  выполняющийся  на  рабочем  месте  оператора

Взаимодействие  модулей

Выше  был  рассмотрен  каждый  из  модулей  в  отдельности.  Далее  следует  рассмотреть  архитектуру  взаимосвязи  между  модулями.  Как  уже  было  сказано  выше  —  центральным  является  модуль  формирования  и  исполнения  измерительных  тестов.  Взаимодействие  модулей  показано  на  рисунке.

Рисунок  8.  Взаимодействие  модулей

Выводы

В  данной  статье  была  описана  разработка  общей  архитектуры  системы  автоматизации  и  управления  процессом  измерения  и  контроля  сетевой  производительности,  выделены  основные  компоненты  системы.  Выделены  основные  информационные  потоки  и  выбраны  протоколы  взаимодействия.  Рассмотрено  детальное  разбиение  на  программные  модули.  Для  каждого  из  программных  модулей  рассмотрены  входные  и  выходные  данные,  а  также  основные  функции.  Описано  взаимодействие  программных  модулей.  Вопрос  непосредственного  написания  программного  кода  в  соответствие  с  разработанной  архитектурой  и  испытания  разработанной  системы  выходит  за  пределы  данной  публикации.

Список  литературы:

1.[Электронный  ресурс]  —  Режим  доступа.  —  URL:  http://www.ixiacom.com/solutions/network-infrastructure-test/