<<
>>

Архитектура системы активного мониторинга

Для разработки системы активного мониторинга пакетов и ресурсов СРП была вы­бранатрехуровневая архитектура (рис. 2.11).

Рисунок 2.11. Архитектура системы

Уровень представления включает все, что имеет отношение к взаимодействию пользователя с системой. К основным функциям этого уровня относятся отображение ин­формации и интерпретация вводимых пользователем данных с преобразованием их в со­ответствующие операции в рамках бизнес-логики и уровня доступа к данным

Уровень доступа к данным обеспечивает допуск приложения к хранилищам дан­ных, а также несет ответственность за взаимодействие с СУБД или файловыми системами и т.п.

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

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

Роль уровня доступа к данным заключается в том, чтобы обеспечить взаимодей­ствие приложения с различными компонентами инфраструктуры. Основной задачей явля­ется взаимодействие с базой данных - реляционной СУБД MySQL, а также с файловой системой (рис. 2.12).

Рисунок 2.12. Уровень доступа к данным

Для абстрагирования и инкапсуляции всех видов допуска к базе данных использу­ется объект доступа к данным (Data Access Object, DAO) [57], реализующий механизм ра­боты с источником данных. Поскольку интерфейс, предлагаемый DAO клиентам (более высоким уровням приложения), не изменяется при смене источника данных, такой подход позволяет адаптировать DAO к различным схемам хранения.

Источником данных DAO является каркас (фреймворк) для отображения использу­емой в системе мониторинга объектно-ориентированной модели данных в традиционную реляционную базу- MySQL. Проблемой является представление объектов в парадигме объектно-ориентированного программирования объектами из реального мира, некоторыми сущностями, например, запись события о завершении сценария в журнале системы мони­торинга. Необходимо преобразовать такие объекты в форму, в которой они могут быть со­хранены в базу данных с последующим извлечением, сохранив при этом свойства объек­тов и отношения между ними. Для решения этой проблемы можно использовать реляци­онные системы управления базами данных. Однако такой подход вынуждает разработчика создавать дополнительное программное обеспечение, способное обрабатывать данные в объектно-ориентированном виде и сохранять их в реляционной форме. Необходимость в

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

Данную проблему позволяет решить объектно-реляционное отображение (Object Relational Mapping, ORM) - технология программирования для преобразования данных между несовместимыми системами (в частности, реляционными СУБД и объектным пред­ставлением) в объектно-ориентированных языках. Система мониторинга использует реа­лизацию ORM-решения NHibernate, являющуюся бесплатной библиотекой с открытым ис­ходным кодом, разработанной компанией JBoss для платформы Microsoft.Net.

Поскольку на взаимодействие с файловой системой приложением накладываются весьма низкие требования - сохранение, получение и удаление файла, использовался бо­лее простой подход. За этот вид взаимодействий отвечает объект-менеджер файловой си­стемы, реализующий вышеуказанные операции.

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

Рисунок 2.13. Уровень бизнес-логики

Рассмотрим компоненты уровня бизнес-логики.

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

2. Компонент разбора сценария. Занимается разбором тестового сценария, выделяя из части входные файлы и имена соответствующих им параметров, из части

- непосредственно EasyFlow скрипт, а из части - имена проверяемых выходных файлов и ожидаемые в них значения.

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

4. Компонент запуска задач - основной компонент системы мониторинга. Взаимодей­ствуя с подсистемой исполнения СРП, запускает задачу, сформированную из скрип­та и входных файлов тестового сценария.

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

6. Компонент почтового оповещения. Отправляет подписчикам сценария оповещения по электронной почте, сообщая о неудачном выполнении сценария и позволяет, та­ким образом, в кратчайшие сроки получать информацию о неисправности пакета или ресурса, на проверку которого направлен сценарий.

Фасад [58] уровня бизнес-логики предоставляет унифицированный интерфейс вме­сто набора интерфейсов всех компонентов, определяет интерфейс более высокого уровня, который упрощает использование уровня, скрывая сложность системы путем сведения всех возможных внешних вызовов к себе, делегируя их соответствующим компонентам уровня.

Уровень представления системы активного мониторинга основан на концепции «модель-представление-контроллер» (Model-View-Controller, MVC) [59], согласно которой при разработке пользовательского интерфейса и выделяются три роли (рис. 2.14):

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

- представление - отображает содержимое модели средствами графического интер­фейса. Функции - отображение информации на экране;

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

Рисунок 2.14. Уровень представления

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

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

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

Таким образом, средства активного мониторинга позволяют существенно повысить надежность СРП, поскольку (а) проверяют доступность самих вычислительных сервисов и (б) дают сигнал к автоматическому развертыванию альтернативных ресурсов (например, образов виртуальных машин), если основные недоступны. Пример использования такой системы приведен в главе 4.

2.5

<< | >>
Источник: Карбовский Владислав Александрович. ТЕХНОЛОГИИ ЭКСТРЕННЫХ ВЫЧИСЛЕНИЙ ДЛЯ ИНДИВИДУАЛЬНОЙ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ В КРИТИЧЕСКИХ СИТУАЦИЯХ. ДИССЕРТАЦИЯ на соискание ученой степени кандидата технических наук. Санкт-Петербург - 2014. 2014

Еще по теме Архитектура системы активного мониторинга:

  1. Индикаторы сбалансированного развития системы персональных финансов
  2. Функции и система персональных финансов[36]
  3. Риски в системе персональных финансов61
  4. 1. Правовые основы системы образования
  5. 2. Система органов внутренних дел
  6. 3.1. Формирование стратегии развития системы персональных финансов
  7. Модернизация системы персональных финансов для обеспечения устойчивого развития российской экономики
  8. Предел прочности на изгиб порошковых алюмокомпозитов системы с наномодификаторами
  9. § 2. Система гарантий обеспечения прав граждан
  10. 3.3 Исследование процесса спекания алюмокомпозитов системы А1- 3масс.%М-1масс.%Си с наномодификаторами
  11. Твердость порошковых алюмокомпозитов системы А1-3масс.%М- 1масс.%Cu, АМмасс^^ и A1-4масс.%Mg с наномодификаторами
  12. Жаростойкость порошковых алюмокомпозитов системы A1-3маcc.%Ni- 1маcc.%Cu с наномодификаторами
  13. ГЛАВА 2. ОЦЕНКА СИСТЕМЫ ПЕРСОНАЛЬНЫХ ФИНАНСОВ РОССИИ
  14. 3.4 Исследование процесса спарк-плазменного спекания порошковых алюмокомпозитов системы Л1-3масс.%М-1масс.%Си с наномодификаторами
  15. Коррозионную стойкость изгиб порошковых алюмокомпозитов системы Al-3масс.%Ni-1масс.%Cu с наномодификаторами
  16. ГЛАВА 3. ОСНОВНЫЕ НАПРАВЛЕНИЯ МОДЕРНИЗАЦИИ СИСТЕМЫ ПЕРСОНАЛЬНЫХ ФИНАНСОВ РОССИИ
  17. ГЛАВА 1. ПЕРЕВОД КАК МЕТОД ОСВОЕНИЯ СМЫСЛОВОЙ СИСТЕМЫ ТЕКСТА
  18. Глава 4. Исследование свойств порошковых алюмокомпозитов системы Al- 3масс.%Ni-1масс.%Cu с наномодификаторами
  19. 3.5 Исследование структуры полученных порошковых алюмокомпозитов системы Л1-3 масс. %Ni-1 масс.0 оСи с наномодификаторами