CC BY
32
УДК 004.4'22, 681.324
ИНСТРУМЕНТАЛЬНАЯ ОБОЛОЧКА ПРОЕКТИРОВАНИЯ ВЫСОКОПРОИЗВОДИТЕЛЬНЫХ ПРИЛОЖЕНИЙ В СРЕДЕ ГРИД. ЧАСТЬ II: АРХИТЕКТУРА, РЕАЛИЗАЦИЯ И ПРИМЕНЕНИЕ А.В. Ларченко, А.В. Дунаев, А.В. Бухановский
Описывается архитектура инструментальных оболочек семейства PEG, обеспечивающих поддержку принятия решений разработчика композитных приложений в Грид. Обсуждаются принципы их функционирования, особенности программной реализации и использования. Работоспособность предложенных решений иллюстрируется на примере композитного приложения расчета климатических спектров морского волнения.
Ключевые слова: Грид, проектирование, интеллектуальная система, высокопроизводительные вычисления.
Введение
Математическое и программное обеспечение Грид-вычислений отличается существенным разнообразием, обусловленным независимым развитием технологий распределенных вычислений в рамках различных направлений [1]. С точки зрения процесса разработки приложений оно может быть разделено на следующие иерархические группы:
- промежуточное программное обеспечение Грид, или middleware, обеспечивающее объединение разрозненных ресурсов в единое вычислительное и информационное пространство на основе стандартизированных технологий взаимодействия. К этому классу относятся широко известные пакеты Globus [2], UNICORE [3], gLite [4] и др.;
- инструментальные среды разработки приложений в Грид, предоставляющие разработчику набор типовых компонентов, использующих функциональности middleware. К ним относятся такие разработки, как Intel GPE [5] и SAGA [6];
- системы визуального прототипирования приложений в Грид, обычно использующие нотацию потоков заданий, или workflow (WF). Этот класс включает в себя решения Taverna [7], Triana [8] и пр. Такие системы упрощают процесс создания программного кода за счет интерпретации визуального описания, которое формируется и обосновывается разработчиком на основе собственного опыта и навыков.
Отдельную группу программного обеспечения Грид-вычислений представляют интеллектуальные системы поддержки принятия решений (ИСППР) разработчиков, к которым относятся инструментальные оболочки семейства PEG (Parallel Execution on the Grid) [9, 10], K-WF Grid [13], Pegasus [13]. В отличие от систем визуального прото-типирования, ИСППР обеспечивают автоматизацию самого процесса проектирования, формируя оптимальную по производительности структуру композитного приложения на основе пользовательского описания в терминах предметной области. Пользователю предоставляется возможность создать структуру параллельного композитного приложения (выполнение операций декомпозиции, связывания, агломерации) посредством визуального проектирования с использованием графического языка. Системой выполняется мониторинг среды выполнения с целью выяснения различных ее характеристик, таких как пропускная способность сети, вычислительные мощности отдельных вычислительных узлов и их доступность, права на исполнение приложений и пр. На основании этих данных производится моделирование процесса исполнения приложения с целью прогнозирования его производительности на этапе проектирования и построения оптимального расписания его выполнения. По расписанию выполняется автоматическая генерация композитного приложения, а также сопутствующих файлов, необходимых для выполнения заданного приложения в Грид.
В данной статье описывается архитектура инструментальных оболочек семейства PEG, назначение и принцип действия основных функциональных компонентов, а также иллюстративный пример использования оболочки для разработки композитного приложения расчета климатических спектров морского волнения.
Эволюция архитектуры инструментальных оболочек семейства PEG
Семейство инструментальных оболочек PEG поддержки принятия решений разработчика высокопроизводительных приложений в Грид включает в себя следующие образцы:
- PEG1 - инструментальная оболочка параллельного исполнения приложений в Грид. PEG1 позволяет создавать параллельные приложения из готовых или разрабатываемых прикладных Грид-сервисов (ПГС) и оперативно отслеживать процесс их исполнения;
- PEG2 - инструментальная оболочка информационной и технологической поддержки процесса проектирования приложений; поддерживает визуальную среду прото-типирования композитного приложения в терминах абстрактного описания (абстрактный workflow, или AWF [9]) и предоставляет набор специфичных для Грид инструментов проектирования (монитор Грид, контроллер ресурсов, монитор исполнения и пр.);
- iPEG (Intelligent PEG) - интеллектуальная среда, реализующая всю последовательность операций в рамках концепции [9], от задания пользователем описания задачи в терминах предметной области (мета-workflow, или MWF) до выполнения композитного приложения, созданного на основе квазиоптимального CWF.
Как видно из рис. 1, в оболочке PEG1 реализована основная функциональность работы с инфраструктурой Грид. Для этого используется PEG Grid API, который реализует основные приемы работы с Грид на основе Intel GPE. Для этого он использует библиотеки GPE API версии 1.5, которые, в свою очередь, предоставляют уровень абстракции над Globus. Такая схема позволяет отделить реализацию собственно программного комплекса от реализации подлежащей Грид-архитектуры. PEG Grid API применительно к оболочке PEG2 выполнен таким образом, что позволяет динамически «подменять» промежуточное программное обеспечение Грид, что означает, что на схеме вместо GPE API может появиться, например, UNICORE [3] API. Это достигается абстрактной реализацией основных элементов Грид, таких как задача, сервер, целевая система и пр., конкретные реализации которых могут взаимодействовать с различными Грид-архитектурами. Таким образом, элемент PEG Grid API представляет собой «окно» в Грид, через которое производятся все низкоуровневые операции работы с ним.
Выбор среды GPE сводится к следующим аргументам.
- Среда GPE ориентирована на использование Globus Toolkit: выбор Globus позволяет значительно расширить круг систем, которые можно привлечь к вычислениям. К тому же Globus в своей реализации имеет полную или потенциальную поддержку многих технологий и стандартов, присущих современным Грид-системам.
- Среда GPE поддерживает общепринятые в настоящее время технологии для распределенных информационных систем, которые напрямую не реализованы в Globus: JSDL, BPEL, RandomByteIO. Globus, являясь достаточно низкоуровневым пакетом, предоставляет широкие, но ограниченные возможности, что компенсируется такими объектно-ориентированными продуктами, как GPE (или аналогичное решение - SAGA).
- Среда GPE позволяет осуществлять бесшовное взаимодействие приложений, работающих под разными операционными системами и на различных вычислительных платформах. Интероперабельность и кроссплатформенность обусловлена тем, что
среда GPE разработана с использованием языка Java, реализация виртуальной машины которого существует для большинства современных архитектур.
- Открытость кода: проект GPE реализуется в рамках лицензии GPL, позволяя получать доступ к исходным кодам, тем самым повышая адекватность разрабатываемых моделей, так как учитывается внутренняя реализации приложений и сервисов.
- Клиентские библиотеки: GPE в своем составе имеет хорошо разработанный API для работы со средой из любой программы, что позволяет создавать собственные приложения, непосредственно получающие доступ к Грид-среде.
- Поддержка протокола GridFTP: для более быстрого, надежного и защищенного обмена данными есть возможность использовать протокол GridFTP, что существенно ускоряет работу с данными.
Рис. 1. Эволюция архитектуры оболочек семейства PEG
На рис. 1 представлен процесс эволюции архитектуры оболочек семейства PEG. Элемент исполнения в оболочках PEG отвечает за выполнение пользовательского задания на удаленных целевых системах: он осуществляет вызовы интерпретатора WF, балансировочных алгоритмов, а также производит мониторинг, т.е. является организующим ядром системы.
Элемент балансировки / составления расписаний в различных видах присутствует во всех прототипах семейства PEG, однако предоставляет различную функциональность. В PEG1 он способен лишь произвести декомпозицию данных, используя равномерное разбиение по доступным целевым системам, тогда как в PEG2 он позволяет использовать четыре различных типа расписаний, которые учитывают работу всего WF. В iPEG данный элемент реализуется в виде полнофункционального инструмента составления квазиоптимальных расписаний выполнения композитного приложения с использованием различных эвристик и текущих данных о Грид-среде.
В инструментальной оболочке PEG2, по сравнению с PEG1, вводятся дополнительные функциональные элементы, в частности: визуальная оболочка проектирования, элемент представления WF, элемент мониторинга Грид, элемент прогнозирования времени выполнения приложений в Грид.
Введение визуальной оболочки позволило реализовать одну из ключевых функ-циональностей программного комплекса - возможность визуальной компоновки пользовательских заданий в виде AWF. В соответствии с этим был введен также элемент представления WF, который отвечает за внутреннее представление и интерпретацию заданного пользователем WF, который в дальнейшем может использоваться остальными элементами программного комплекса. Элементы мониторинга Грид и прогнозирования позволили реализовать полнофункциональную оптимизацию эффективности процесса исполнения, основываясь на данных о текущем состоянии Грид и информации о производительности отдельных сервисов. Оба они используются элементом балансировки в своей работе. В PEG2, как было указано, функциональность элемента была расширена, что достигается за счет включения в его работу вызовов функций новых блоков.
В интеллектуальной среде iPEG вводится ряд принципиально новых элементов, главным из которых является элемент управления знаниями. Он предоставляет основной функционал для работы с базами знаний, в том числе инструменты их использования, активизации, извлечения, пополнения и обновления, а также проверки целостности и достоверности.
Для обеспечения работы iPEG как интеллектуальной системы необходимо также введение таких элементов, как элемент пополнения и уточнения знаний и элемент планирования. Элемент планирования необходим в силу того, что в предлагаемой концепции выдвигается требование, заключающееся в возможности задания пользователем нечеткого описания процесса выполнения в виде MWF. При таком задании необходимо введение этапа трансляции пользовательского описания в набор AWF на основании данных, указанных пользователям в блоках действий. Для этого элементу планирования требуется обращаться к элементу управления знаниями за информации о доступных сервисах и их онтологических описаниях. Это обеспечивает соответствие общей архитектуры оболочек семейства PEG основным функциональным характеристикам ИСППР [9].
Основные программные компоненты инструментальных оболочек семейства PEG
На рис. 2 приводятся обобщенные функциональные схемы инструментальных оболочек PEG1 и PEG2. На них отражены основные этапы работы системы (средний ряд), компоненты, ответственные за выполнение этих этапов (нижний ряд) и получающиеся по окончании этапов результаты (верхний ряд).
Этап проектирования композитного приложения в PEG1 состоит в создании пользователем специального файла описания параллельного задания в формате TSDL. Этот файл передается консольному клиенту, который производит интерпретацию задания и создает его внутреннее представление в виде класса Task. Далее происходит разбиение данных, указанных пользователем в файле описания, на части, предназначенные для отправки на доступные целевые системы в Грид. Эта операция выполняется компонентом декомпозиции данных, одновременно осуществляющим простейшую балансировку на основе равномерной декомпозиции. В результате получается набор задач в виде массива объектов класса Job, каждый из которых содержит информацию о данных и целевой системе, на которой планируется производить запуск. На следующем этапе компонент Executor производит запуск получившихся задач в параллельном режиме, после чего система ожидает завершения работы задач, регулярно производя мониторинг их
состояния на целевых системах. По завершении задач результаты передаются с целевых систем на компьютер пользователя (с которого производится управление) и объединяются компонентом Composer. Результат слияния помещается в указанную пользователем директорию.
Процесс работы PEG2 при внешнем сходстве с PEG1 является более сложным за счет использования визуальной оболочки для описания структуры приложения в форме WF и использования набора конкурирующих методов построения расписаний (балансировки).
ЛПредста-вление задачи
Формирование задачи
Абстрактный Workflow
Тип балансировки
Decomposer + Balancier
Расписание выполнения
Результат
Запуск
Ожидание и
Executor
(а)
Execution Monitor
Слияние
Composer
Результат
Формирование задачи
Прогноз времени и
выбор балансировки
Разбиение данных и балансировка
Запуск параллельного исполнения
Ожидание и
мониторинг
Слияние результатов
СЭ +
CL + <
CD СО О
о ®
о о
с с _ CD си
g- О Е 15
Е ^ ^ m
о £
о t
0 о
û û.
о 0 X
ш
0 сп о
Q_
Е о О
(б)
Рис. 2. Функциональные схемы инструментальных оболочек РЕ01 и РЕ02 (нотация элементов приведена по тексту)
На этапе проектирования в РБ02 пользователь, используя визуальную оболочку, компонует структуру процесса вычислений в виде AWF. Для полученного описания система прогнозирования выполняет оценку времени выполнения для набора конкурирующих расписаний, реализуемых различными типами статических балансировок по данным. На основе этой информации пользователь принимает решение и выбирает вариант, наиболее
удовлетворяющий его критериям. На основании пользовательского выбора компонент балансировщик выполняет разбиение данных, используя данные о производительности ПГС, включенных в WF, и текущем состоянии Грид-среды. В результате формируется расписание выполнения и набор файлов, представляющих собой фрагменты исходных данных для отправки на целевые системы.
Компонент Executor производит запуск композитного приложения в параллельном режиме и ожидает завершения всех его задач, регулярно производя мониторинг их состояния на целевых системах. Результаты мониторинга отображаются с помощью визуальной оболочки в реальном времени. По завершении исполнения происходит сбор результатов с целевых систем и их объединение. Пользователь при этом имеет возможность визуализировать полученные данные.
Пользователь
Replica Service
Performance Analyzer
4—►
Grid Monitor «—►
Performance Refinement
I
Визуальная оболочка
Workflow Planner
Workflow Scheduler
Workflow Executor
Конкретный
Workflow
Рис. 3. Функциональная схема инструментальной оболочки iPEG (нотация элементов приведена по тексту)
На рис. 3 представлена схема функционирования инструментальной оболочки iPEG. Пользователь посредством визуальной оболочки создает описание композитного приложения в форме MWF, используя знания о соответствующем наборе доступных ПГС в Грид, предоставляемом системой управления знаниями (Grid Knowledge Manager). Это описание передается планировщику (Workflow Planner), который на основе знаний о сервисах и данных создает набор альтернативных AWF. Каждый AWF представляет собой непротиворечивый процесс вычислений с фиксированными ПГС и данными. Для указания местоположения данных используется компонент Replica Service,
который позволяет осуществлять доступ к распределенным хранилищам данных, включая результаты предыдущего использования ПГС.
По завершении выполнения задач на целевых системах Workflow Executor осуществляет сбор результатов работы; пользователь получает окончательный результат (например, в виде файла данных). Таким образом, интеллектуальная оболочка iPEG позволяет осуществлять полномасштабную информационную поддержку принятия решений разработчика высокопроизводительных приложений в Грид.
Применение инструментальной оболочки iPEG для создания высокопроизводительных композитных приложений в Грид
Проиллюстрируем основные принципы работы системы iPEG на примере создания композитного приложения, осуществляющего расчет климатических спектров морского волнения [11].
Рис. 4. Время выполнения иллюстративного композитного приложения по обработке 8 000 спектров морского волнения в Грид:
1 - равномерная схема; 2 - каскадная схема; 3 - обратная каскадная схема.
А, Б - см. по тексту
В процессе вычислений производится статистическое обобщение массива таблично заданных функций (24x25 значений) распределения энергии волн по частотам и направлениям в фиксированной точке пространства за длительный временной интервал. Каждой из таблиц сопоставляется нелинейная функция двух аргументов, параметры которой определяются методом адаптивного случайного поиска. Обработка таблиц ведется независимо, что позволяет выполнять распараллеливание вычислительного процесса по данным.
На рис. 4 приведены характеристики времени обработки массива из 8 000 спектров, полученные на экспериментальном стенде - корпоративной Грид-системе, состоящей из 24 целевых систем на базе процессоров Intel Pentium D и Intel Core 2 Quad.
По ходу работы в ИСППР, реализуемой инструментальной оболочкой iPEG, рассматривались три конкурирующих расписания: равномерное распределение данных,
прямая и обратная каскадные схемы, реализующие синхронные способы взаимодействия с вычислителями. Видно, что в среднем для небольшого количества вычислителей (p=2-4) каскадные схемы являются более предпочтительными; с увеличением p накладные расходы на осуществление синхронного взаимодействия возрастают, и, как следствие, предпочтительным становится использование равномерной схемы распределения данных по вычислителям.
На рис. 4 также приведены ядерные оценки плотности распределения времени работы для каждой из трех схем распределения данных, полученные путем обобщения априорных измерений. Видно, что с увеличением количества вычислителей разброс времени выполнения возрастает, что связано с ростом влияния стохастических эффектов коммуникаций в Грид. При этом взаимное расположение плотностей распределения определяет правила ранжирования конкурирующих расписаний. Например, в случае А (рис. 4) для p=2 прямая и обратная каскадные схемы приводят в среднем к практически одинаковым оценкам времени работы. Различие между ними существенно меньше соответствующего диапазона изменчивости, что не позволяет автоматически выбрать наилучший способ. Однако разброс времени работы для прямой каскадной схемы в 1,5 раза больше, чем для обратной каскадной схемы. Как следствие, окончательный выбор схемы распараллеливания остается за пользователем, исходя из предпочитаемой им стратегии (меньший риск - меньшая производительность, больший риск -большая производительность).
С другой стороны, существуют ситуации (например, Б при p=24), когда плотности распределения времени работы для разных схем перекрываются, однако различие между средними значениями сопоставимо с диапазоном их изменчивости. Тогда ранжирование конкурирующих расписаний должно вестись с учетом заданного уровня значимости ошибки; в частности, в ситуации Б в 5% случаев обратная каскадная схема будет давать лучший по производительности результат, чем равномерная, несмотря на то, что в среднем равномерная схема работает в 1,5 раза быстрее.
Из рис. 4 также видно, что кривые производительности имеют ярко выраженные минимумы (для каскадных схем - при p=6, для равномерной - при p=12), которые и определяют оптимальный режим выполнения задачи. Для рассмотренного примера максимальное ускорение в среднем составляет около 2,5 раз, а выигрыш по сравнению с конкурирующими каскадными расписаниями - в 2 раза. Столь невысокие показатели ускорения характерны для вычислений в Грид в силу существенного вклада коммуникационной составляющей; однако они являются только одним из определяющих факторов (наравне с объемом доступной памяти, дискового пространства и пр.), которые заставляют пользователей обратиться к технологиям распределенных вычислений и систем.
Таким образом, в ходе работы интеллектуальной системы iPEG рассмотренный выше анализ проводится автоматически, что позволяет обосновать выбор оптимальной схемы распараллеливания композитного приложения применительно к доступным в Грид вычислительным ресурсам и ПГС.
Заключение
Предложенная в [9] концепция ИСПРР, осуществляющая поддержку принятия решений разработчика приложений в Грид, реализуется в рамках семейства инструментальных оболочек PEG. В отличие от традиционных инструментальных средств разработки (например, систем визуального прототипирования WF), ИСППР обеспечивает автоматизацию самого процесса проектирования, формируя оптимальную по производительности архитектуру композитного приложения на основе пользовательского описания в терминах предметной области и знаний о производительности используемых
ПГС. Методы и технологии приобретения соответствующих знаний изложены в работе [12].
Работа выполнена в рамках НИР 2007-4-1.4-20-01-025 «Разработка инструментальной оболочки проектирования высокопроизводительных приложений для Грид-архитектур в целях создания прикладных сервисов компьютерного моделирования и обработки данных».
Литература
1. Stockinger H. Defining the Grid - a snapshot of the current view // Journal of Supercomputing. - Springer Science+Business Media. - 2007.
2. Globus Toolkit Homepage. - Режим доступа: http://globus.org/toolkit/, свободный.
3. UNICORE - Distributed computing and data resources. - Режим доступа: http://www.unicore.eu/, свободный.
4. gLite. - Режим доступа: http://glite.web.cern.ch/glite/, свободный.
5. GPE. - Режим доступа: http://gpe4gtk.sourceforge.net/, свободный.
6. SAGA. - Режим доступа: http://forge.ogf.org/sf/projects/saga-rg/, свободный.
7. Taverna Project Website. - Режим доступа: http://taverna.sourceforge.net/, свободный.
8. Triana Collaboration Projects. - Режим доступа: http://www.trianacode.org/collaborations/index.html, свободный.
9. Ларченко А.В., Дунаев А.В., Бухановский А.В. Иинструментальная оболочка проектирования высокопроизводительных приложений в Грид. Часть I: Базовые положения // Научно-технический вестник СПбГУ ИТМО. - 2008. - Вып. 54.-С. 29-36.
10. Дунаев А.В., Ларченко А.В., Бухановский А.В. Инструментальная оболочка поддержки принятия решений разработчика высокопроизводительных приложений в Грид // Научно-технические ведомости СПбГПУ. - 2008. - № 5. - С. 98-104.
11. Boukhanovsky A.V., Lopatoukhin L.J., Guedes Soares C. Spectral wave climate of the North Sea // Applied Ocean Research. - July 2007. - Vol. 29. - Issue 3. - Р. 146-154.
12. Дунаев А.В., Ларченко А.В., Бухановский А.В. Инструментальная оболочка проектирования высокопроизводительных приложений в Грид. Часть III: Приобретение и формализация знаний // Научно-технический вестник СПбГУ ИТМО. - 2008. - Вып. 47. - С. 46-55.
13. K-Wf Grid - Home. - Режим доступа: http://www.kwfgrid.net/, свободный.
14. Pegasus Homepage. - Режим доступа: http://pegasus.isi.edu/, свободный.
Ларченко Алексей Викторович
Дунаев Антон Валентинович
Бухановский Александр Валерьевич
- Санкт-Петербургский государственный университет информационных технологий, механики и оптики, м.н.с., aleksey.larchenko@gmail.com
- Санкт-Петербургский государственный университет информационных технологий, механики и оптики, м.н.с., anton.dunaev@gmail.com
- Санкт-Петербургский государственный университет информационных технологий, механики и оптики, д.т.н., профессор, boukhanovsky@mail.ifmo.ru
