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

Мультиплексор адреса (MUX A) работает следующим образом. Во время инициализации через него передается код для загрузки регистра управления. Затем мультиплексор переходит в свое основное рабочее состояние, соответствующее обмену в пределах одной строки. В этом состоянии он пропускает на выход адреса столбцов активной строки (9 разрядов) и адрес банка. При смене строки во время команды активации мультиплексор на один такт переключается и передает на шину адрес новой строки (12 разрядов) и адрес банка, который также может измениться.

Оконечные каскады шин данных DQ1, DQ2 в исходном состоянии работают на прием и переключаются на передачу только при поступлении команд записи данных. На линиях DQM1, DQM2 установлен уровень логического нуля. Режим маскирования данных не используется.

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

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Каляев А.В., Левин И.И. Модульно-наращиваемые многопроцессорные системы со структурно-процедурной организацией вычислений. М.: Янус-К, 2003. - 380 с.

Э.В. Мельник, И.В. Блуишвили, И.С. Пуха

МУЛЬТИАГЕНТНАЯ СРЕДА ОРГАНИЗАЦИИ РАСПРЕДЕЛЕННЫХ

ВЫЧИСЛЕНИЙ

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

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

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

- задача обработки больших объемов данных;

- задача выполнения расчетов по алгоритмам, имеющим большую вычислительную сложность;

- задача выполнения запросов к распределенным базам данных.

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

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

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

• возможность моделирования выхода из строя заданного агента;

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

• запись результатов исследований в файл.

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

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

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

• организация решения сложных задач;

• оптимизация размещения вычислений на имеющихся аппаратных ресурсах;

• восстановление вычислительного процесса в случае отказов аппаратных и программных средств (своих в том числе).

Решение первых двух задач может быть основано на разработанных ранее децентрализованных методах и алгоритмах [1], [2], [3], основанных на использовании коллективного взаимодействия программных агентов, которые в рамках муль-тиагентной среды совместно решают задачу распределения вычислительной нагрузки по узлам распределенной вычислительной системы с целью уменьшения времени получения результата. При этом программа представляется в виде ориентированного ацикличного графа: вершины отражают подзадачи (программные модули) в рамках общей задачи (программы), а связи - направление движение потоков данных между подзадачами.

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

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

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

• процедурный;

• декларативный;

• гибридный.

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

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

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

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

Мшк - пакет с инициализационными данными задачи;

МсЬа^еТаБкБ - пакет с указанием действий по обмену подзадачами указанными агентами;

МРшЖеБ! - пакет с полученным промежуточным результатом;

МБ1ер - пакет, разрешающий переход на следующую итерацию; MNoAnswer - пакет, сообщающий о проблеме со связью с указанным агентом;

МБ1е - тестовый пакет, отключающий агента;

МЫуе - сигнал «пульс».

К командам относятся сообщения - М1пк, М81ер. При получении пакетов с такими сообщениями агент обязательно выполняет соответствующую типу сообщения команду.

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

Пакет М81ер не содержит данных и является командой перехода к следующему итерационному шагу оптимизации.

К декларативным сообщениям относятся сообщения - MChangeTasks, МБ1М-Best. Это сообщения, служащие для передачи данных, или извещение о наступление определенных событий.

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

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

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

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

Рис. 1. Пример использования коллектива программных агентов при построении децентрализованной распределенной системы

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

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

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

Контроль работоспособности узла происходит на основе передачи остальным агентам пакетов специального вида МЬіуе (сигнал «Пульс») с данными о существование агента на узле. Это данные об идентификаторе агента, сетевого имени вычислительного ресурса и классе решаемых задач. В свою очередь, агент получает аналогичные пакеты от других агентов. При выходе из строя агента, работающего на одном из узлов вся система считает, что вышел из строя узел. Это логично, так как даже если вышел из строя только агент, а модуль продолжает свою работу, то контроль за его функциональностью не выполняется.

Каждый агент содержит два клиента и два сервера (рис. 2) для сетевого взаимодействия - клиент для отправки адресованных пакетов, клиент для отправки широковещательных сигналов «Пульс», сервер для приема адресованных пакетов и сервер

для приема широковещательных «бит» пакетов. Передача направленных пакетов осуществляется по протоколу ТСР, широковещательных - по протоколу ПЭР.

Агент Сервер «бит» пакетов Клиент «бит» пакетов Сервер направл енных пакетов Клиент направл енных пакетов

і к і к

г Г

Агент Клиент «бит» пакетов Сервер «бит» пакетов Клиент направл енных пакетов Сервер направл енных пакетов

Г-Х ш

I Через заданные | интервалы времени

По событию

Рис. 2. Организация сетевого взаимодействия агентов

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

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

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

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

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

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Блуишвили И.В. Децентрализованный алгоритм организации сети распределенных вычислений и сравнительный анализ с передовыми алгоритмами.// Интеллектуальные и многопроцессорные системы. // Материалы международной научной конференции. Т.1. Таганрог: Изд-во ТРТУ, 2004. 496 с.

2. Мельник Э.В., Пуха И.С. Об одном подходе к организации распределенных баз данных.// Интеллектуальные и многопроцессорные системы. // Материалы международной научной конференции. Т.2. Таганрог: Изд-во ТРТУ, 2003. 309 с.

3. Пуха И.С. Мультиагентный подход в системах управления и хранения информации // // Российская Академия Наук, Южный Научный Центр. // Материалы второй ежегодной научной конференции. Ростов-на-Дону: Изд-во ЮНЦ РАН, 2006. 256 с.

В.А. Аграновский, В.И. Баранец, Р.Н. Селин

ОБОБЩЕННЫЙ МЕТОД ПОСТРОЕНИЯ ПРИКЛАДНЫХ И СЕТЕВЫХ ИНТЕРФЕЙСОВ ДЛЯ СУБД-ПРИЛОЖЕНИЙ

Разработка интерфейса - важнейшая составляющая процесса создания СУБД-приложения. Ключевыми требованиями при создании интерфейса СУБД-приложения являются, во-первых, возможность легкой и надежной модификации этого интерфейса, а во-вторых, независимость от инструментальной среды программирования. Для удовлетворения этих требований предлагается следующий подход: интерфейс приложения описывается формально в виде некоторой синтаксической структуры на языке XML [1].

Данный интерфейс является конкретным экземпляром интерфейса приложения (объектом) в рамках некоторой модели. Эта модель определяется так же формально как схема XML структур в виде XSD файла [2].

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

Принципы обработки электронных документов

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

Инструкции программы-анализатора должны определять точное месторасположение элемента XML в дереве, в результате чего появится возможность применять различные стили оформления к одинаковым элементам в зависимости от контекста их использования. На рис. 1 представлена схема, иллюстрирующая процесс обработки программой-анализатором MSXSL XML-документа на основе XSL-правил преобразования для конечной среды HTML.