МОДЕЛЬ ИНТЕРАКТИВНЫХ КОМПОЗИТНЫХ ПРИЛОЖЕНИЙ

МОДЕЛЬ ИНТЕРАКТИВНЫХ КОМПОЗИТНЫХ
ПРИЛОЖЕНИЙ
К.В. Князьков, С.В. Ковальчук, А.В. Бухановский
Санкт-Петербургский национальный исследовательский университет информационных
технологий, механики и оптики
Формализм композитных приложений или workflow (WF) широко распространен для
представления сложных научных вычислительных экспериментов. Во многих
существующих системах исполнения композитных приложений WF основывается на модели
запуска в пакетном режиме, когда сам WF и его задания после запуска переходят в режим
непрерывного исполнения без возможности их модификации и взаимодействия с ними [1]. В
то же время существуют классы задач, которые либо сложно адаптировать к пакетному
режиму работы либо, если это возможно, адаптация приводит к значительной потере
эффективности использования ресурсов. Данные классы задач можно в общем
охарактеризовать, как задачи, требующие обработки данных непрерывным потоком,
требующие постоянного взаимодействия с внешним миром (интернет, датчики), задачи, в
которых критически важно время получения результата и требуется возможность изменения
условий эксперимента без перезапуска всего WF. Актуальность таких задач растет на фоне
увеличения вычислительной мощности машин и роста пропускной способности каналов
связи.
Интерактивные WF. Для преодоления ограничений, связанных с пакетным
исполнением, далее вводится расширение модели WF — интерактивные WF (или WF
длительного исполнения) [2]. Предлагаемая модель основана на нескольких ключевых
позициях, которые отличают ее от пакетного WF:
1. Поддержка WF, исполняющихся долгое время. Узлы, время жизни которых не
ограничено, будем называть узлами длительного исполнения.
2. Поддержка механизмов управления поведением исполняющихся заданий и их
жизненным циклом извне.
3. Поддержка коммуникации между узлами WF во время исполнения. Одновременная
работа нескольких (возможно всех) узлов WF, обменивающихся информацией по
каналам связи.
4. Возможность изменения WF во время исполнения за счет сценария WF, а также за
счет внешнего управления. Узлы и дуги такого WF могут быть добавлены или
удалены во время исполнения.
Для удовлетворения всем представленным выше возможностям базовая модель WF
расширяется за счет введения нового типа зависимости в графе WF вдобавок к зависимости
по данным и управлению – коммуникационной зависимости и расширения зависимости по
управлению для обеспечения возможностей изменения WF и управления им извне. Помимо
этого, если в пакетном WF всё взаимодействие с внешним миром сводится к установке
входных параметров и считыванию выходных, то в WF длительного исполнения появляются
дополнительные возможности. Узлы WF во время своей работы могут обращаться к
внешним, по отношению к платформе, ресурсам для получения информации, а также
являться источниками информации для внешних клиентов. На рисунке 1 представлен
пример схемы модельного интерактивного WF. На рисунке заштрихованы узлы длительного
исполнения.
Внешние источники
данных
Входные данные
b
a
Базы
данных
c
Внешние клиенты
A
Датчики,
сенсоры
B
C
http://
Визуализатор
Оператор
web
resource
D
Объект
управления
P
P
f
Выходные данные
Коммуникационная
зависимость
Зависимость по
данным
Зависимость по
управлению
Рис. 1. Пример схемы интерактивного композитного приложения
Формальная модель. Далее приводятся основные положения формальной модели
интерактивного композитного приложения.
Узел композитного приложения – это кортеж вида:
Ins, P, Outs, Type, F , InPorts, OutPorts, protocol, Com, Ev ,
где Ins  {I i : i  0..n, I i  Id } - множество идентификаторов входных параметров блока,
Outs  {Oi : i  0..m, Oi  Id } - множество идентификаторов выходных параметров блока ( Id множество всех идентификаторов параметров, можно представить как множество всех
возможных строк), P : Type( I 0 )  ...  Type( I n )  {true, false} - предикат, определяющий
попадание переданного набора входных значений в область допустимых для пакета (то есть
проверяющий корректность), Type : Id  B - оператор, который определяет для
идентификатора его тип, F - функция узла, переводящая переданные входные значения в
выходные (1), InPorts  {Inpi : i  0..g , Inpi  Pid } - множество идентификаторов входных
портов блока, OutPorts  {Outpi : i  0..r , Outpi  Pid } - множество идентификаторов
выходных портов блока ( Pid - множество всех идентификаторов портов, можно представить
как множество всех возможных строк), protocol : Pid  Protocols - оператор, который
определяет для идентификатора его протокол, Protocols - множество поддерживаемых
протоколов, Com  Commands - множество поддерживаемых блоком команд ( Commands множество всех возможных команд), Ev  Events - множество генерируемых блоком
событий ( Events - множество всех возможных событий).
F : {x : ( x  Type( I 0 )  ...  Type( I n ))  P( x)}  Type(O0 )  ...  Type(Om ) .
(1)
Интерактивное композитное приложение – это кортеж вида:
Ins wf , Outs wf , Sources , ClientPorts, Type, protocol , N , D, C , Q ,
где Ins wf  I i | i  0..n, I i  Id  - множество идентификаторов входных параметров WF,
Outs wf  Oi | i  0..m, Oi  Id  - множество идентификаторов выходных параметров WF,
Type : Id  B - оператор, который определяет для идентификатора его тип,
N  N i | N i : Node, i  0..k  - множество узлов WF (здесь Node - узел WF, см. выше), D множество связей по данным, C - множество зависимостей по управлению,
Sources  {Ipi : i  0..w, Ipi  Pid } - множество идентификаторов портов внешних источников
данных, ClientPorts  {Opi : i  0..u, Opi  Pid } - множество идентификаторов выходных
портов WF, protocol : Pid  Protocols - оператор, для идентификатора порта определят его
протокол.
Для удобства будем считать, что идентификаторы входных и выходных параметров WF,
а также и параметров отдельных шагов уникальны, а оператор Type работает на всем
множестве параметров. Это можно записать как: Ins wf  Outs wf   (b.Ins  b.Outs)   .
bN
Также будем считать, что протокол – это множество конкретных адресов (по аналогии с
типом параметра). Источник данных и внешний порт WF можно представить по аналогии с
параметрами, это параметр, значением которого является конкретный адрес. Выходной порт
Q - множество
WF – это точка для подсоединения клиентских приложений.
коммуникационных зависимостей.
Зависимость по данным – это тройка вида Child D , Parents D , Fconv , где
Child D 
 N .Ins  Outs
i
wf
- зависимый узел, Parents D 
N i N
 N .Outs  Ins
i
wf
- множество
Ni N
узлов, от которых Child D зависит, Fconv - функция конвертации данных. Зависимость по
данным устанавливается между одним входным параметром и несколькими выходными (2).
Fconv : Type( Parent0D )  ...  Type( Parent zD )  Type(Child D ), z  Parents D ,
(2)
Коммуникационная
Child Q 
зависимость
 N .InPorts  ClientPorts
i
–
–
это
двойка
коммуникационный
вида
порт
Child Q , Parent Q ,
зависимого
узла,
а
Ni N
Parent Q 
 N .OutPorts  Sources – порт от которого Child
i
Q
зависит.
Ni N
Зависимость по управлению расширяется за счет внедрения механизма событийного
взаимодействия и команд. Зависимость по управлению – это тройка вида
Child C , ParentsC , Pcond
, Child C   N i .Com - команда зависимого узла, а
NiN
Parent 
C
 N .Ev
i
- узел, от которого Child C зависит. Pcond : Events*  {true, false} -
Ni N
предикат, который определяет в зависимости от сработавших событий ( Events* - множество
всех возможных множеств событий), выполнять ли команду. Для примера, выполнение
команды может происходить только тогда, когда сработали оба события E1 и E2 , тогда
оператор выдаст true, если в множестве произошедших событий присутствуют и E1 , и E2 .
Можно ввести понятие интерпретации – это функция, которая для конкретного WF
позволяет набор входных значений преобразовать в набор выходных (3):
Interpretion(WF ) : Type( I1 )  ...  Type( I n )  protocol ( Ip0 )  ...  protocol ( Ip w ) 
.
(3)
 Type(O1 )  ...  Type(Om )
Отметим, что функция интерпретации работает только для корректно заданных WF.
Реализация модели. Приведенная модель была реализована в платформе для облачных
вычислений CLAVIRE [3]. В качестве метода коммуникации был выбран механизм обмена
сообщениями между узлами WF по сети. Управление узлами организовано в виде
удаленного вызова процедур (далее – выполнения команд) поверх механизма передачи
сообщений. В ходе реализации было выявлено, что эффективной абстракцией для
коммуникационной связи узлов LRWF является парадигма реактивного программирования,
ориентированная на потоки данных и распространение изменений. В качестве среды
коммуникации и передачи команд был выбран программный сетевой транспортный уровень
ZMQ [4], реализуемый посредством программной библиотеки. В качестве формата упаковки
данных используется формат сериализации BSON.
Эксперимент. Для проверки модели и разработанного прототипа системы исполнения
был реализован WF для решения задачи моделирования эвакуации людей из зоны
затопления. Композитное приложение состоит из нескольких частей: пакет моделирования,
осуществляющий имитационное моделирование людей на местности; пакет визуализации;
узел генерации, предназначенный для периодического обновления данных о положении
людей на карте (при реальном использовании данного приложения в качестве генератора
может служить процесс, периодически получающий данные с видеокамеры, который
распознает положения людей на местности и передает полученные данные процессу
моделирования). Состав приложения может меняться при запуске путем варьирования
количества процессов визуализации. Все части композитного приложения (пакеты)
поддерживают режим длительного исполнения и могут работать неограниченное время,
взаимодействуя по сети (см. рис. 2). При проведении эксперимента варьировался размер
задачи. В том числе был успешно произведен запуск модели на толпе из 50000 человек с
параллельной работой трех визуализаторов.
обновление
положения
людей на
карте
генератор
команда на
получение
карты
Визуализатор 1
Визуализатор 2
модель
Визуализатор 3
обновление
положения
людей в
модели
Рис. 2. Принципиальная схема эксперимента
Итак, в рамках данной работы была предложена модель интерактивных композитных
приложений, которая может быть применена для реализации систем экстренных
вычислений, систем поддержки принятия решений, анализа больших объемов данных, для
задач реального времени, мониторинга и управления сложными объектами. Работа
выполнена в рамках реализации НИОКР по постановлениям Правительства РФ №218 «О
мерах государственной поддержки развития кооперации российских высших учебных
заведений и организаций, реализующих комплексные проекты по созданию
высокотехнологичного производства» и №220 «О мерах по привлечению ведущих учёных в
российские образовательные учреждения высшего профессионального образования».
Источники
1. Workflows and e-science: An overview of workflow system features and capabilities / E.
Deelman, D. Gannon, M. Shields, I. Taylor // Future Generation Computer Systems. —
2009. — Vol. 25, no. 5. — Pp. 528–540.
2. Особенности работы с потоками задач длительного исполнения в рамках концепции
iPSE / К.В. Князьков // Известия высших учебных заведений. Приборостроение. –
2011. – №10. – C. 94-97.
3. CLAVIRE: перспективная технология облачных вычислений второго поколения /
А.В. Бухановский [и др.] // Известия высших учебных заведений. Приборостроение. –
2011. – №10. – С. 7-13.
4. The Intelligent Transport Layer - zeromq [Электронный ресурс]. – Режим доступа:
http://www.zeromq.org/. Дата обращения: 10.05.2012.