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




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

3.1.3 Ядро системы

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


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

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

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

kernel_arch.png

Рисунок 3.2 – Ядро службы мониторинга

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

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

Помимо модели «Цикл событий», ядро реализует парадигму «Конечный автомат» (Finit State Machine) [27]. Проще говоря, ядро характеризуется своим внутренним состоянием и может переходить из состояния в состояние при обработке некоторого внутрисистемного события.

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

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

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

3.1.3.2 Архитектура ядра


Ядро представляет собой автономный поток исполнения, реализующий модель «Цикла событий». Ядро содержит базовые механизмы и примитивы, необходимые для работы системы, такие как обработка событий, изменение состояния системы, управление драйверами/адаптерами и управление сетевой подсистемой.

Ядро также содержит основные таблицы и КЭШи системы:

  1. пул событий ядра;

  2. таблица подключенных дочерних узлов;

  3. таблица подключенных родительских узлов;

  4. кэш исследованных узлов;

  5. таблица драйверов ядра;

  6. таблица адаптеров ядра;

  7. таблица фильтров ядра;

  8. таблица наблюдателей ядра.

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

Ядро управляет двумя основными сетевыми адаптерами системы – первичным и вторичным. Сетевые адаптеры ядра используются для реализации транспортного уровня системы – механизма удаленного вызова процедур (RPC).

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

  1. идентификатор ядра – 32-х байтовая последовательность, однозначно идентифицирующая ядро в гетерогенной среде (раздел 3.1.3.4 «Уникальный идентификатор узла»);

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

  3. индекс производительности узла – целое положительное число, определяющее текущую производительность узла по некоторой шкале;

  4. состояние ядра – текущее состояние ядра;

  5. список дочерних подключенных узлов, используемый системой для адекватной оценки производительности всей распределенной системы в целом;

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

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

3.1.3.3 Исключения ядра


Для соблюдения парадигмы защищенного программирования [28] авторами была разработана модель исключений ядра.

В предлагаемой архитектуре ядра распределенной службы мониторинга существует два вида внутрисистемных исключений:

  1. нативные исключения ядра;

  2. внешние исключения, генерируемые драйверами.

Нативные исключения ядра генерируются самим ядром при следующих ситуациях:

  1. ошибка инициализации и деинициализации ядра;

  2. некорректная обработка события ядра;

  3. ошибка загрузки и выгрузки драйвера ядра;

  4. недетерминированный переход между состояниями ядра;

  5. обработка внешних системных исключений виртуальной машины или операционной системы.

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

  1. некорректная работа локального или удаленного драйвера ядра;

  2. ошибка в транспортной подсистеме;

  3. ошибка в исполнительной подсистеме службы.

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

3.1.3.4 Пул ядра


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

Это позволяет экономить ресурсы системы в сетях с небольшой нагрузкой.

Перед непосредственной обработкой события происходит этап фильтрации событий ядра (раздел 3.1.3.4 «Фильтры пула ядра»). С практической точки зрения фильтрация представляет собой последовательное применение цепочки фильтров на каждое событие. В результате – событие может быть отфильтровано либо пропущено.

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

event_loop.png

Рисунок 3.3 – Псевдокод потока ядра

3.1.3.5 Фильтры пула ядра


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

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

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

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

В текущей реализации доступно два фильтра ядра:

  1. фильтр переходов (ToogleFilter);

  2. фильтр UDP сообщений (UDPFilter).

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

Фильтр UDP сообщений исключает системные сообщения от удаленных служб, если ядро находится в активном состоянии (раздел 3.1.3.5 «Состояния и обработчики ядра»).

Архитектурно, фильтры пула ядра представляют собой реализацию шаблона «Посетитель/Visitor» [28] (диаграмма классов на рисунке 3.4).

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

Рисунок 3.4 – Диаграмма классов пакета фильтров ядра

3.1.3.6 Состояния и обработчики ядра


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

  1. активное (active state);

  2. пассивное (passive state);

  3. сетевое (online state);

  4. автономное (offline state);

  5. неопределенное (suspense state).

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

С точки зрения реализации, и состояние и обработчик ядра представляются шаблоном проектирования «Состояние/State» [28] (рисунок 3.5). При этом оба интерфейса содержат лишь по одному публичному методу. В случае с состоянием – это метод получения текущего обработчика, в случае с обработчиком – это метод обработки следующего события ядра.
handlers_cd.png

Рисунок 3. – Диаграмма классов обработчиков и состояний

Переход из состояния в состояние осуществляется только при обработке определенного класса событий. На рисунке 3.6 рассмотрены основные циклы смены состояний у ядра. Более детально про переходы между состояниями рассмотрены в разделах 3.1.3.1 «События ядра» и 3.1.3.12 «Поведение ядра».

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

Реализация модели поведения ядра в терминах конечных автоматов оказалась хорошей практикой. Отладка, тестирование и разработка распределенной системы становится более очевидной и понятной для программиста при применении данного подхода.
fsm.png

Рисунок 3.5 – Состояния ядра

3.1.3.7 Наблюдатели ядра


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

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

Можно выделить следующие особенности, которыми характеризуется драйвер, реализующий интерфейс наблюдателя:

  1. отложенный (lazy) запуск/останов или активация/деактивация;

  2. зависящее от состояния ядра специфичное поведение.

С точки зрения реализации наблюдатель ядра представляет собой шаблон проектирования «Наблюдатель/Observer» [28]. Тогда драйверы, реализующие интерфейс наблюдателя, в терминах шаблон являются подписчиками.

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

3.1.3.8 Драйверы ядра


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

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

Драйверы транспортной подсистемы реализуют следующие функциональные особенности ядра:

  1. обнаружение в сети вычислительных узлов с запущенными службами мониторинга;

  2. управление удаленными сессиями;

  3. мониторинг доступности сетевой подсистемы узла.

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

  1. планирование процесса запуска моделей мониторинга;

  2. запуск модулей мониторинга;

  3. получение и обработка результатов запуска модулей мониторинга;

  4. управление модулями мониторинга, развернутыми на данном узле.

В свою очередь, функциональные драйверы реализуют следующие особенности:

  1. получение системной информации о вычислительном узле;

  2. конфигурирование службы мониторинга;

  3. удаленное управление службой мониторинга.

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

  1. специфичным поведением, реализующим некоторую часть общего функционала системы;

  2. наличием самостоятельного потока исполнения;

  3. возможностью запуска/останова;

  4. возможностью активации/деактивации;

  5. возможностью загрузки/выгрузки из памяти платформы;

  6. возможностью реагировать на изменение ядром своего состояния.

Рассмотрим общий интерфейс драйвера службы мониторинга на рисунке 3.7.
driver_interface.png

Рисунок 3.6 – Интерфейс драйвера ядра

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

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

Кроме того, существуют дополнительные интерфейсы драйверов, которые могут быть реализованы опционально:

  1. загружаемый драйвер (рисунок 3.7);

  2. активируемый драйвер (рисунок 3.8);

  3. запускаемый драйвер (рисунок 3.9).

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

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

Рисунок 3.7 – Интерфейс загружаемого драйвера

Следующим этапом после загрузки драйвера является его активация. Активация драйверов ядра происходит после полной загрузки ядра, инициализации всех структур и активации подсистем. Если требуется переопределить поведение драйвера в момент активации, он должен реализовывать соответствующий интерфейс.
activable_interface.png

Рисунок 3.8 – Интерфейс активируемого драйвера
Наконец запускаемые драйверы характеризуются собственным потоком исполнения и могут быть запущены или остановлены в любой момент эксплуатации системы. Запуск и остановка драйверов тесно связанны с понятием наблюдателя ядра. Как правило, драйверы останавливаются и запускаются только при переходе ядра в определенное ожидаемое состояние.
startable_interface.png

Рисунок 3.9 - Интерфейс запускаемого драйвера

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

Диаграмма классов реализованных не текущий момент в системе драйверов ядра приведена на рисунке 3.10.
drivers_cd.png

Рисунок 3.10 – Диаграмма классов драйверов

Краткое описание реализованных драйверов приведено в таблице 3.1.

Таблица 3.1 – Драйверы ядра

Драйвер

Интерфейсы

Основные функции

«Scheduler»

«наблюдатель»; «запускаемый»;

«активируемый»;

планирование запусков модулей;

управление персональным расписанием;

синхронизация удаленных расписаний;

«Resulter»

«наблюдатель»;

«запускаемый»;

«активируемый»;

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

обработка результатов;

пересылка результатов в постоянное хранилище;

«Networker»

«активируемый»;

мониторинг сетевой подсистемы узла;

оповещение ядра о сбоях в работе сети;

«Aliver»

«запускаемый»;

«наблюдатель»;

мониторинг доступности удаленных сессий ядра;

Продолжение таблицы 3.1

Драйвер

Интерфейсы

Основные функции

«Configurer»

«загружаемый»

конфигурирование свойств ядра;

«Discoverer»

«запускаемый»;

«наблюдатель»;

обнаружение удаленных служб в сети;

генерация событий обновления кеша ядра;

«Hoster»

«загружаемый»;

получение информации о вычислительном узле;

«Controller»

«загружаемый»;

удаленно управлением поведением ядра;

«Sessionier»

«загружаемый»;

создание сессий режима ядра и режима пользователя;

управление удаленными сессиями;

«Moduler»

«загружаемый»;

запуск модулей мониторинга;

развертывание модулей мониторинга;

управление доступными модулями;

3.1.3.9 Адаптеры ядра


Для взаимодействия между драйверами, загруженными в различные адресные пространства, применяются специальные Ice-объекты - адаптеры ядра. При этом для использования удаленного драйвера достаточно в локальном адресном пространстве создать для его адаптера Ice-прокси. Такая связь называется «объект-прокси» и присутствует в архитектуре службы в качестве списков дочерних и родительских узлов (раздел 3.1.3.2 «Архитектура ядра»).

Рассмотрим на примере реализацию интерфейса адаптера драйвера Discoverer на языке описания спецификаций Slice (рисунок 3.11). Более подробно про семантику работы драйвера Discoverer можно прочитать в разделе 3.1.3.2 «Исследователь».

adapter_code.png

Рисунок 3.11 – Пример реализации интерфейса адаптера ядра

Можно условно разделить адаптеры ядра на две группы:

  1. стационарные адаптеры;

  2. динамические адаптеры;

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

В текущей реализации доступно два стационарных адаптера – адаптеры для драйверов Discoverer и Sessionier (раздел 3.1.3.7 «Драйверы ядра»).

Динамические адаптеры генерируются автоматически на основании текущих подключённых к ядру сессий. Динамические адаптеры могут быть доступны только в рамках сессий – сессии режима ядра или сессии режима пользователя (раздел 3.1.3.10 «Сессии ядра»).

3.1.3.10 События ядра


События ядра наряду с его состояниями являются основополагающими компонентами всей программной платформы службы мониторинга. Внедрение в программную архитектуру модели генерации и обработки событий позволило исключить прямые взаимодействия между драйверами системы, тем самым придерживаются шаблоны «Низкая связность» и «Высокое зацепление» [28] в процессе разработки.

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

  1. типом случившейся ситуации;

  2. списком параметров;

  3. наличием соответствующего обработчика.

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

ecent_code.png

Рисунок 3.12 – Интерфейс события ядра

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

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

events_cd.png

Рисунок 3.13 – Диаграмма классов событий ядра

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

В таблице 3.2 кратко рассмотрены все события, поддерживаемые системой в текущей реализации.
Таблица 3.2 – События ядра

Событие

Источник

Описание

InvokationEvent

Scheduler

Абстрактное событие для инкапсулирования запуска модуля мониторинга, для которого сработало расписание (раздел 3.1.4.2 «Планировщик подсистемы исполнения»);

KernelReconfiguredEvent

Configurer

Событие, генерируемое при переконфигурации ядра;

ExceptionEvent



Событие, инкапсулирующее внешнее исключение драйвера, передаваемое на обработку ядру;

ChildSessionSendedEvent

Kernel

Событие, генерируемое ядром при посылке собственной сессии внешнему клиенту в качестве дочерней;

ChildSessionRecievedEvent

Kernel

Событие, генерируемое ядром при получении удаленной дочерней сессии узла;

ParentSessionSendedEvent

Kernel

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

ParentSessionRecivedEvent

Kernel

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

KernelStateChangedEvent

Kernel

Событие, генерируемое ядром при изменении своего состояния;

Продолжение таблицы 3.2

Событие

Источник

Описание

ForceStartEvent

Moduler

Событие, генерируемое при принудительном запуске модуля;

ChildNodeDiedEvent

Aliver

Событие, генерируемое при обнаружении «мертвой» дочерней сессии;

ParentNodeDiedEvent

Aliver

Событие, генерируемое при обнаружении «мертвой» родительской сессии;

DiscoverRecievedEvent

Discoverer

Событие, генерируемое при получении пакета обнаружения узлов;

ResultRecievedEvent

Scheduler

Событие, генерируемое при получении результат исполнения модуля мониторинга;

NetworkEnabledEvent

Networker

Событие, генерируемое при отсутствии сетевой подсистемы узла;

NetworkDisabledEvent

Networker

Событие, генерируемое при доступности сетевой подсистемы узла;

SchedulerUpdatedEvent

Scheduler

Событие, генерируемое планировщиком, при изменении внутреннего расписания службы;

ScheduleTimeComeEvent

Scheduler

Событие, генерируемое планировщиком, при наступлении времени исполнения модуля;

SnoopydStartedEvent

Kernel

Событие, генерируемое ядром при запуске службы;

SnoopydTerminatedEvent

Kernel

Событие, генерируемое ядром при завершении работы службы;

С точки зрения авторов, рассмотренный выше набор событий является абсолютно полными и позволяет описать любой сценарий использования.

3.1.3.11 Сессии ядра


Для удаленного взаимодействия между службами мониторинга нами были спроектированы и реализованы так называемые сессии ядра. Сессия ядра представляет собой Ice-прокси удаленного ядра и характеризуется:

  1. типом или классом сессии;

  2. методом вызовов удалённых процедур;

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

  4. параметрами сетевого соединения (протокол, адрес, шифрование).

Можно выделить два вида сессий, доступных в текущей реализации: сессии режима ядра и сессии режима пользователя (рисунок 3.14).
sessions_cd.png

Рисунок 3.14 –Диаграмма классов сессий ядра

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

Исходный код описаний интерфейсов на языке Slice для сессии ядра приведен на рисунке 3.15.

session_code.png

Рисунок 3.15 – Исходный код спецификаций сессий ядра

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


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

Основная идея предлагаемой шкалы заключается в нормировании результатов оценки по некоторому базовому значению. В данном случае мы использовали абсолютный показатель производительности системы с процессором Intel™ CoreDuo™ T2300 (1.66 ГГц), доступной оперативной памятью 1 Гб и свободным дисковым пространством 80 Гб. Абсолютная оценка для этой системы составляет 812.

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

Любая оценка производительности узла нормируется на это значение. Фактически индекс производительности отражает во сколько раз исследуемая система производительней базовой.

Аналогичный подход используется в тестах оценки производительности компиляторов, виртуальных машин и баз данных SPEC [29].

3.1.3.13 Поведение ядра


При запуске ядро системы находится в «неопределенном состоянии», это длится до тех пор, пока ядро не получит одно из двух типов событий – «сеть доступна» или «сеть не доступна». Эти события переводят ядро в сетевое и автономное состояния соответственно.

Находясь в сетевом состоянии, ядро запускает драйвер Discoverer, который начинает «исследовать» среду на предмет наличия запущенных узлов.

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

Под подключением в данном контексте понимается обмен удаленными сессиями ядер. При этом одно ядро/узел становится родительским, другое - дочерним.

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

Автономное состояние ядра характеризуется отсутствием физического соединения с сетевой средой. В этом режиме ядро функционирует с некоторыми ограничениями. Однако при обнаружении сетевого соединения ядро переходит в сетевое состояние.

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

3.1.4 Транспортная подсистема

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


Транспортная подсистема (рисунок 3.16) службы мониторинга реализует основную часть механизмов и примитивов модели распределенного взаимодействия между узлами. Транспортная подсистема представляет собой совокупность следующих логических компонент:

  1. ядра;

  2. драйверов транспортного уровня;

  3. менеджера сессий;

  4. многопоточных распределенных алгоритмов.

Транспортная подсистема реализует следующий функционал службы мониторинга:

  1. управление удаленными сессиями;

  2. мониторинг сетевой активности;

  3. именование объектов;

  4. адресация;

  5. балансировка нагрузки;

  6. выбор лидера.


transport.png

Рисунок 3.16 – Транспортная подсистема

3.1.4.2 Универсальный уникальный идентификатор (UUID)


Для однозначной идентификации объектов в рамках системы авторами использовалось понятие универсального уникального идентификатора (UUID). UUID представляет собой строку из 36-ти символов в формате Unicode (например такую — «5029a22c-e333-4f87-86b1-cd5e0fcce509»).

Стандартная библиотека классов Java уже содержит реализацию UUID в классе java.util.UUID [17].

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

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

3.1.4.3 Уникальный идентификатор узла


Для эффективной работы транспортного уровня системы каждый узел идентифицируется не локальным или физическим адресом, а так называемым уникальным идентификатором узла (NUID). Идентификатор NUID состоит из двух частей — домена и идентификатора в домене. Под доменом распределенной системы мониторинга здесь и далее будем понимать объединенную группу узлов, с запущенными службами мониторинга, способными без каких-либо ограничений взаимодействовать между собой. В некотором смысле домен распределенной системы можно представлять как домен Windows, а узлы распределенной системы как компьютеры в домене [26].

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

3.1.4.4 Алгоритм выбора лидера


За основу алгоритма выбора лидера в предлагаемой архитектуре был взят классический алгоритм Чанди-Робертса [31], который основывается на кольцевой топологии сети с односторонней передачей данных. На его базе нами был разработан алгоритм выбора лидера, основанный на широковещательных запросах.

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

Рассмотрим алгоритм выбора лидера:

  1. каждый узел отправляет широковещательный запрос в распределенную систему, содержащий свой индекс производительности;

  2. каждый узел получает широковещательные запросы от других узлов, содержащие их индексы производительности и сохраняет их в кеш;

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

  4. выбор лидера представляет собой циклический алгоритм, состоящий из:

    1. выбора узла из кеша (с удалением) с максимальным индексом производительности;

    2. попытки подсоединения к выбранному узлу;

    3. если попытка оказалась неудачной, из кеша будет взят следующий узел с максимальный индексом;

    4. цикл повторяется до тех пор, пока состояние узла не изменится (пока лидер не будет выбран).

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

3.1.4.5 Обнаружение узлов


Каждый узел (ядро) характеризуется своим внутренним состоянием, которое состоит из:

  1. идентификатора узла;

  2. имени узла в сети;

  3. типом операционной системы, в которой запущен узел;

  4. строковыми представлениями адаптеров узла;

  5. индексом производительности узла;

  6. списком дочерних узлов (идентификаторов);

  7. списком родительских узлов (идентификаторов).

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

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

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

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

3.1.4.5 Сессии транспортной подсистемы


Сессии режима ядра и сессии режима пользователя (раздел «3.1.3.11 Сессии ядра») образуют множество сессий транспортной подсистемы, которые хранятся в так называемых таблицах дочерних и родительских узлов ядра службы.

Для обеспечения отказоустойчивости системы, а также для реализации поддержки механизмов автоматической балансировки нагрузки авторами был спроектирован специальный драйвер ядра – «Aliver» (раздел «3.1.3.8 Драйверы ядра»), который характеризуется самостоятельным потоком исполнения.

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

При обнаружении сессии, фактическое соединение через которую стало недоступным, драйвер «Aliver» генерирует ядру события «ParentNodeDied» или «ChildNodeDied», в зависимости от типа сессии. Обработка ядром этого события приводит либо к смене его внутреннего состояния (раздел «3.1.3.6 Состояния и обработчики ядра») либо к балансировке нагрузки.

3.1.4.7 Балансировка нагрузки


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

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

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

3.1.5 Подсистема исполнения

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


Подсистема исполнения службы мониторинга (рисунок 3.17) реализует основные механизмы исполнения модулей мониторинга. Можно выделить следующие компоненты подсистемы исполнения:

  1. ядра;

  2. драйверов подсистемы исполнения;

  3. менеджера модулей.

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

execution-subsystem.png

Рисунок 3.17 – Подсистема исполнения

Подсисистема исполнения реализует следующий функционал службы мониторинга:

  1. планирование запусков и запуск модулей мониторинга;

  2. обработка результатов исполнения модулей;

  3. развертывание модулей мониторинга на удаленных узлах.

3.1.5.2 Расписание запусков модулей


В текущей реализации доступно два вида запусков модулей мониторинга:

  1. по расписанию;

  2. принудительно;

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

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

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

3.1.5.3 Планировщик подсистемы исполнения


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

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

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

3.1.5.4 Развертывание модулей


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

Процесс развертывания осуществляется посредством широковещательных запросов в следующей последовательности:

  1. передача исходного текста модуля мониторинга;

  2. передача списка его параметров;

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

Модули мониторинга сохранятся в локальном кеше узла именованные своими уникальными идентификаторами.

3.1.5.5 Обработчик результатов подсистемы исполнения


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

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

В текущей реализации службы мониторинга нет предварительной обработки и анализа результата.
1   ...   4   5   6   7   8   9   10   11   ...   35

Похожие:

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


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