1. 2 Понятие систем мониторинга 2




Название1. 2 Понятие систем мониторинга 2
страница10/11
Дата конвертации12.12.2012
Размер0.72 Mb.
ТипРеферат
1   2   3   4   5   6   7   8   9   10   11

3.4 Панель управления

3.4.1 Общее описание


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

Панель помогает организовать процесс работы, а если более точно этот инструмент является интерфейсом между пользователем и исполняемой средой [32] (рисунок 3.20). Через этот интерфейс задания доставляются от пользователя к узлу, на котором это задание должно быть выполнено и через него же возвращаются результаты работы.

core-cp-user.png

Рисунок 3.20 – Взаимодействие пользователя с ядром

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

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

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

3.4.2 Архитектура панели управления


Архитектура панели реализует такую концепцию как Модель – Представление – Поведение (рисунок 3.21). Суть этого шаблона проектирования заключается в том, что  модель данных приложения, пользовательский интерфейс и управляющая логика разделены на три отдельных компонента так, что модификация одного из компонентов оказывает минимальное воздействие на остальные.

Важно отметить, что как представление, так и поведение зависят от модели. Однако модель не зависит ни от представления, ни от поведения. Это одно из ключевых достоинств подобного разделения. Оно позволяет строить модель независимо от визуального представления, а также создавать несколько различных представлений для одной модели.
mvc-extended.png

Рисунок 3.21 – Концепция Модель-Представление-Поведение

3.4.3 Модель


Модель в терминах MVC — это не только совокупность кода доступа к данным, но и, как минимум, логика домена и, возможно, некоторые другие части системы.

3.4.3.1 Получение информации от ядра


Ядро информирует панель управления о своем существовании с помощью драйвера Discoverer. Это драйвер через интерфейс Discover() отправляет минимальный набор информации о ядре. Этот набор информации называется контекст. Контекста достаточно чтобы зарегистрировать ядро в панели, а также для того, чтобы установить соединение с ядром. После того как соединение будет установлено, через панель можно будет получить более подробную справочную информацию о ядре и адаптеры для управления ядром.

Таблица 3.3 – Содержимое контекста ядра

Ключ для получения

Значение

Пример

identity

Идентификатор узла

dev/3f759634-59c0-42ae-a923-ad3e61eec769

os

Название операционной системы, на которой запущено ядро

Windows XP

parents

Идентификатор родительского узла

dev/92274582-5a96-47a9-942b-676119702ef6;

rate

Индекс производительности

17

primary

Информация для установления сессии до узла

tcp -h 192.168.0.10 -p 10000

secondary

Дополнительная информация для установления сессии до узла

udp -h 192.168.0.10 -p 10000

state

Состояние узла (статус)

ActiveState

hostname

Имя узла (компьютера) на котором запущено ядро

Work-PC

children

Идентификатор(ы) дочерних узлов

dev/9ea033b6-4a32-4b92-9a70-e57f56bb8d2c; dev/dcee7249-5baa-43c8-a1b2-2f787da599ec;

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

3.4.3.2 Взаимодействие с ядром системы


Используя информацию из контекста, устанавливается пользовательская сессия до удаленного узла. С помощью этой сессии получаются ссылки на драйверы удаленного ядра. Эти драйверы предоставляют интерфейсы, которые можно использовать для управления и конфигурирования узла.

Таблица 3.4 – Драйверы ядра используемые панелью управления

Драйвер

Интерфейсы/методы

Описание

Discoverer

discover()

Периодическое оповещение о состоянии удаленного узла через передаваемую информацию

Configurer

configuration()

Конфигурирование удаленного узла

Hoster

context()

Получение информации об удаленном узле. Отличается от контекста, получаемого с помощью discover().

Sessionier

createUserSession()

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

Moduler

deploy()

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

force()

Принудительный старт модуля с возможностью передать параметры

fetch()

Получение списка модулей узла

Scheduler

schedule()

Установления расписания для модуля удаленного узла

toggle()

Переключение состояний модулей удаленного узла

timetable()

Получения расписания модуля

statetable()

Получения таблицы состояний модулей удаленного узла

Это основные методы для взаимодействия с ядром, но есть еще вспомогательные или, точнее, служебные. Например, такой метод как ice_ping() есть у всех драйверов [16]. Задача его проста: определение достижимости удаленного узла. В случае недостижимости узла метод генерирует исключительную ситуацию, на которую можно соответственно отреагировать.

3.4.3.3 Домен


В панели управления реализацией модели является класс Domain. Имеется еще несколько классов, которые являются вспомогательными для класса Domain. К ним можно отнести такие классы как DomainController, Discoverer, DiscovererAdapter, но они не являются ключевыми в реализации модели.

К функциям домена можно отнести:

  1. Хранение контекста узлов ядра;

  2. Хранение ссылок на драйвера удаленного узла;

  3. Предоставляет информацию по требованию других компонентов приложения;

  4. Информирует пользовательский интерфейс об изменении информации, хранящейся в домене;

  5. Контролирует актуальность информации и обновляет ее при необходимости или по требованию;

  6. Осуществляет первичное взаимодействие с ядром через драйвер Discoverer.

Вся информация о ядре системы и отдельных узлах, которая визуализируется пользователю, хранится локально в ОЗУ на узле, где запущена панель управления. При этом она не сохраняется в ПЗУ, а в случае перезапуска панели запрашивается у ядра повторно.

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

Полученная информация хранится в динамических массивах, списках, которые в свою очередь содержатся в контейнере Domain (рисунок 3.22).

domain.png

Рисунок 3.22 – Структура домена

Информация кэшируется и если она требуется, то берется из этого кэша, а не запрашивается у ядра каждый раз за исключением ситуаций, когда необходимо принудительно обновить информацию. Имеется два вида обновления информации. Первый вид - это ситуации, когда изменилось состоянии ядра, а точнее его узлов. Тогда ядро через драйвер Discoverer оповещает об этом, рассылая новую информацию в контексте. Используя механизм хэшей, можно определить, изменилась ли информация, и если это произошло, то она обновляется в локальном кэше. Второй вид – ситуации, когда пользователь панели управления изменяет состояния ядра или отдельных его компонентов. И для того, чтобы узнать удачно ли прошли изменения, информация кэша также обновляется, но уже принудительным запросом. Примером второго вида является ситуация запроса пользователем результатов выполнения поставленного задания.

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

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

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

  • домен должен передавать сообщения интерфейсу, но при этом он не должен знать об его внутреннем устройстве;

  • для предотвращения сильных связей между моделью и представлением.

Используемый шаблон полностью справляется с предъявленными требованиями.

3.4.4 Контроллер


Контроллер не должен содержать логики приложения (бизнес-логики). Таким образом Контроллер должен выполнять исключительно функцию связующего звена между отдельными компонентами системы.

3.4.4.1 Координатор


В панели управления реализацией контроллера или поведения является класс Coordinator.

Координатор:

  1. Устанавливает соответствие между действиями пользователя и изменением информации в домене;

  2. Согласовывает информацию из домена и ее отображение в пользовательском интерфейсе

  3. Определяет основные действия, определяющие поведение панели вцелом.

Первая заявленная функция координатора является основной.

3.4.5 Представление


В реализации представления нет какого-то конкретного класса. Оно реализуется целой группой классов, такие как окна приложения, модели таблиц, деревьев и вспомогательные классов. Но можно выделить основной класс, с которым взаимодействует координатор. Это класс главного окна приложения - MainFrame.

Поскольку панель управления написана на языке Java, то в качестве библиотеки для создания графического интерфейса использовался Swing[29]. Swing предоставляет более гибкие интерфейсные компоненты, чем более ранняя библиотека AWT. Также выбранная библиотека является более кросс-платформенной[30].

3.4.5.1 Структура графического интерфейса


В качестве основы для графического интерфейса авторами была концепция многодокументного интерфейса (MDI) [35]. Это одна из стандартных архитектур пользовательского интерфейса Windows-приложений. MDI позволяет работать в приложении не с одним, а сразу с несколькими окнами или документами. Каждое окно показывается в пределах клиентской области основного окна приложения. Это правило не распространяется на модальные окна.

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

3.4.5.2 Дерево узлов


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

tree.png

Рисунок 3.23 – Дерево узлов

В дереве можно встретить три вида узлов:

  • домен;

  • узел;

  • модуль узла.

Как было сказано в разделе 3.1.3.2 узел в сети идентифицируется доменом и идентификатором (NUID). Первый вид узлов обозначает домены в сети. Как правило, количество доменов в подсети редко превышает одного.

Ко второму виду относятся вычислительные узлы, которые были описаны в базовой теоретической модели в разделе 2.2. Это дерево не представляет физической структуры узлов, потому что на одном программно-аппаратном устройстве, которое в большинстве случаев является персональный компьютер, можно запустить несколько сущностей ядра. Большая часть информации для дерева берется из контекста ядра, полученного через Discoverer. В качестве имени узла выбирается имя компьютера, а точнее то, что находится под значение hostname. Иконка для узла выбирается в зависимости от значения по ключу OS. Следует заметить, что круг устройств, на котором может использоваться ядро, не ограничивается персональными компьютерами, поэтому определение семейства операционной системы не всегда корректно, если вообще возможно. Если узел перестал информировать о своем существовании, то он помечается как dead. Поскольку узел недоступен, то и нет возможности получить список модулей.

У каждого узла может быть любое количество модулей, в том числе и ни одного. Список модулей можно получить через драйвер Moduler. Через интерфейс fetch() можно получить список, состоящий из MUID и названия модуля. В дереве у каждого узла отображается список всех его модулей. У каждого модуля есть два состояния: активный и неактивный. Это состояние показывает индикатор модуля. Если индикатор зеленый, значит модуль активный, а если серый – неактивный. Статусы модулей получают через драйвер Scheduler через интерфейс statetable(), возвращающий список MUID и статус модуля.

С каждым узлом можно совершать определенный действия. Исключением является узел домена.

Действия доступные для узлов:

  • Shutdown – прекратить выполнения ядра на удаленном узле;

  • Host Results – вывести список результатов работы всех модулей узла;

  • Node Properties – вывести свойства узла, позволяющие просмотреть системные свойства узла и провести конфигурацию ядра.

Действия доступные для модулей узла:

  • Force Start – принудительный запуск модуля с параметрами;

  • Module Results – вывести список результатов работы конкретного модуля;

  • Module Properties – вывести свойства модуля, которые содержат статус модуля, расписание и список параметров.

3.4.5.3 Карта узлов


Карта узлов представляет собой связанный граф [36]. Для удобства карта открывается в отдельном окне (рисунок 3.24).

Важно понимать, что граф отображает не физическую топологию сети и узлов. Здесь связи в графе показывают иерархическую связь, а не физическое соединение. Связь от узла MainNode к Node3 означает, что MainNode является родительским узлом по отношению к Node3. У любого узла должен быть родительский узел, поэтому MainNode связан сам с собой.

netmap.png

Рисунок 3.24 - Карта узлов с установленными родительскими связями

Цвет узлов на графе тоже имеет значение:

  • красный – узел в активном состоянии;

  • синий – в пассивном;

  • желтый – в сетевом;

  • серый – узел перестал отвечать (dead)

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

Граф нарисован с помощью сторонней свободной библиотеки JUNG. Вся информация для отображения графа берется из контекста ядра.

3.4.5.4 Редактор


В панели управления имеется встроенный текстовый редактор. Он необходим для написания исходного кода модуля на языке Python. В редактор можно загрузить уже готовый файл и наоборот сохранить написанный. Из окна редактора можно сразу развернуть командой Deploy написанный или загруженный модуль на удаленный узел. Панель поддерживает множественно развертывание. Команда Deploy вызывает диалоговое окно, в котором предлагается из списка доступных узлов выбрать то или те, на которые необходимо развернуть модуль. В этом же окне сразу можно указать начальный статус модуля, параметры и расписание.

Развертывание модуля происходит через интерфейс deploy(), а выставление расписания и начальных параметров через schedule().

3.4.5.6 Результаты выполнения задач


Результаты выполнения задач узел сохраняет в базе данных, адрес которой указан в его настройках. От туда же их получает панель управления но своими средствами, использую jdbc-драйвера [38].

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

1   2   3   4   5   6   7   8   9   10   11

Похожие:

1. 2 Понятие систем мониторинга 2 icon1. 2 Понятие систем мониторинга 3
Сравнительный анализ затрат в ходе эксплуатации программного продукта и аналога 85
1. 2 Понятие систем мониторинга 2 icon1. 2 Понятие систем мониторинга 3
Сравнительный анализ затрат в ходе эксплуатации программного продукта и аналога 85
1. 2 Понятие систем мониторинга 2 icon1. Цель мониторинга Мониторинг слово, вошедшее в педагогический лексикон относительно недавно. Современный словарь иностранных слов определяет это понятие как
Мониторинг процесса воспитания в школе Начнем, по­жалуй, с трех простых вопросов: нужно ли это, кому это нужно и зачем это нужно?...
1. 2 Понятие систем мониторинга 2 iconСистемы IP мониторинга ip pdu панели   ■ Контроль объектов   ■ ip мониторинг   ■ Управление электропитанием Системы Мониторинга / Распределитель Электропитания Системы мониторинга sc2100
Резервирование питания: 12В, встроенный датчик напряжения питания, можно подключить 
1. 2 Понятие систем мониторинга 2 iconОценочный доклад
Бляхарчук Т. А. д б н., с н с., лаб мониторинга лесных экосистем, Институт мониторинга 
1. 2 Понятие систем мониторинга 2 iconПрограмма fos (Fundamentals of Operating Systems) «Основы операционных систем»
Характеристики сетевой операционной системы. Многопользовательские, многозадачные и многопроцессорные системы. Структура операционной...
1. 2 Понятие систем мониторинга 2 iconПравовые основы  мониторинга и сохранения 
Брошюра-справочник участника Украинской сети мониторинга  и  сохранения  китообразных  может  быть  интересна  также 
1. 2 Понятие систем мониторинга 2 iconПлан отчета I. Методические рекомендации для администрации по проведению мониторинга и оценки индивидуального прогресса учащихся образовательного учреждения а) какие условия нужно учесть при организации регулярного тестирования (мониторинга) в школе?
А) какие условия нужно учесть при организации регулярного тестирования (мониторинга) в школе?
1. 2 Понятие систем мониторинга 2 iconКонспект урока 8 класс Тема: «Графический интерфейс операционных систем и приложений»
Цель: дать понятие графического интерфейса, основных элементов окон, научить детей пользоваться графическим интерфейсом, работать...
1. 2 Понятие систем мониторинга 2 iconСистема электронного мониторинга комплексного проекта модернизации образования
Работа на сайте электронного мониторинга и размещение данных на закрытой части сайта не вызывает трудностей у пользователей, т к...
Разместите кнопку на своём сайте:
kak.znate.ru


База данных защищена авторским правом ©kak.znate.ru 2012
обратиться к администрации
KakZnate
Главная страница