Построение архитектуры сервера распределенных вычислений

К. Ю. Войтиков, П. Н. Тумаев

Филиал Кемеровского государственного университета
в г. Анжеро-Судженске

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

В [1] была сформулирована задача организовать работу объектно-ориентированной системы имитационного моделирования [2], используя для расчетов распределенную компьютерную сеть. Модель системы была дополнена двумя ключевыми в данном контексте компонентами: GRID-Server и GRID-Client. GRID-Client – компонент, агрегирующий в себя компоненты, участвующие в расчетах и обеспечивающий их связь с сервером; GRID-Server – компонент, осуществляющий разделение заданий на сегменты, обеспечивающий координацию Удаленных Калькуляторов (компьютеров, использующихся для расчетов) и клиентов системы, а также хранящий задания и результаты расчетов. Также была представлена общая структура данных компонентов.

Рассмотрим внутреннюю организацию компонента GRID-Server более подробно.

Рис 1. Модель предметной области системы

Задача описать в рамках объектной модели все процессы, связанные с организацией распределенных расчетов, является относительно сложной. Кроме всего прочего, она включает необходимость описать большое количество правил бизнес-логики в отношениях между сущностями системы, не усложняя структуру самой системы без необходимости. Исходя из этого, для создания модели компонента GRID-Server было решено воспользоваться архитектурным решением «Модель предметной области» [3]. Вдобавок это облегчит понимание системы разработчиками дополнительных модулей (о которых будет сказано ниже). Кроме этого в дальнейшем планируется прибегнуть к xml-сериализации объектов системы, для хранения их на диске и возможности работать с ними, как с любыми другими документами (копировать, переносить, отправлять по электронной почте и т. д.). В таком случае наличие в системе объектов, четко соответствующих сущностям предметной области системы в реальном мире, позволит получать логичные, легко воспринимаемые человеком схемы xml-файлов.

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

На основе выделенных сущностей была построена модель классов предметной области системы, представленная на рис. 1.

Помимо классов, представляющих основные сущности предметной области, в данной модели также присутствуют классы TaskRepository, GridTaskRepository и GridClientRepository, являющиеся хранилищами заданий, подзаданий и карточек Grid-клиентов соответственно. Фактически вся связь других компонентов системы с моделью предметной области (например, добавление нового задания, получение списка подзаданий для заданного GRID-клиента и т. д.) будет осуществляться только через эти хранилища.

Для достижения высокой степени повторной используемости компонентов системы, а точнее – для реализации возможности использовать однажды развернутую систему для выполнения любых расчетов, реализован механизм расширения вычислительной функциональности системы при помощи подключаемых модулей. Как видно из диаграммы классов, представленной на рис. 1, класс Task не описывает задание системы сам по себе, на него ложится лишь обязанность хранения самой общей информации о задании, например, такой как, необходимое количество результатов подзадний. Все же логическое описание задания и его численные параметры, хранятся в экземпляре класса TaskContent. Сам по себе класс TaskContent является абстрактным и в чистом виде не может содержать какой-либо информации вообще. Для каждого же конкретного вида заданий требуется создать класс, унаследованный от TaskContent, способный хранить необходимые для описания такого задания данные. Помимо этого в модели присутствует ряд других абстрактных классов, совместно реализующих необходимый интерфейс для системы с одной стороны и предоставляющих платформу для создания собственных самодостаточных моделей описания заданий и их результатов, а также инструментов для их решения – с другой. Такими классами являются: класс Result, описывающий результат задания, необходимый пользователю системы; класс GridResult, описывающий результат подзадания, то есть конкретного экземпляра выполнения задания GRID-клиентом и класс Calculator, непосредственно совершающий расчеты. Пример созданного таким образом модуля представлен на рис. 2.

Рис. 2. Механизм создания модуля системы

Для описания задания с тремя параметрами от класса TaskContent унаследован класс ConcreteTaskContent с соответствующими полями. Для решения такого рода задач от класса Calculator унаследован класс ConcreteCalculator, «знающий» как поступать с экземплярами класса ConcreteTaskContent, передаваемыми ему при использовании. В качестве результата своей работы ConcreteCalculator возвращает экземпляр, также описанного в модуле класса ConcreteGridResult, потомка класса GridResult. И, наконец, для завершающей статистической (или любой другой) обработки результатов подзаданий и представления итогового результата всего задания, от класса Result унаследован класс ConcreteResult, имеющий некие спецефические методы для обработки результатов подзаданий в виде экземпляров класса ConcreteGridResult.

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

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

Литература

1. Тумаев П. Н. Разработка архитектуры системы распределенных вычислений на основе технологии Microsoft WCF // Информационные технологии и математическое моделирование: материалы VIII Всероссийской научно-практической конференции с международным участием (г. Анжеро-Судженск, 12-13 ноября 2009 г.), Ч. 1. – Томск: Изд-во ТГУ, 2009. – С. 213-215.

2. Войтиков К. Ю., Моисеев А. Н. Модель компонентов распределенной системы моделирования процессов массового обслуживания // Информационные технологии и математическое моделирование: материалы VIII Всероссийской научно-практической конференции с международным участием (г. Анжеро-Судженск, 12-13 ноября 2009 г.), Ч. 1. – Томск: Изд-во ТГУ, 2009. – С. 122-123.

3. Фаулер М. Архитектура корпоративных программных приложений: Пер. с англ. – М.: Изд. Дом «Вильямс», 2004. – 544 с.

Работа выполнена в рамках аналитической ведомственной целевой программы «Развитие научного потенциала высшей школы (2009-2010 годы)», проект № 4761