Содержание к диссертации
Введение
1 Грид и веб-сервисные технологии 9
1.1 Концепция грид 9
1.2 Первое поколение гридов 12
1.3 Открытая архитектура грид-сервисов 14
1.4 Веб-сервисы 15
1.5 Инфраструктура ресурсов веб-сервисов 17
1.6 Современные гриды 18
1.7 Постановка задачи 23
2 Использование REST для построения грид-сервисов . 25
2.1 Архитектурный стиль REST 25
2.1.1 Ресурсно-ориентированная архитектура 27
2.1.2 RESTful-грид-сервисы 31
2.2 Простые манипуляций с ресурсами 33
2.2.1 Создание ресурсов 33
2.2.2 Свойства ресурсов 34
2.3 Индикация ошибок 37
2.4 Цикл существования ресурсов 40
2.5 Безопасность и идемпотентность 42
2.6 Аутентификация запросов 45
2.7 Принципы построения RESTful-грид-сервисов 49
3 Разработка грид-сервиса запуска композитных заданий 51
3.1 Композитные задания 53
3.1.1 Синтаксис описания заданий и задач 55
3.1.2 Требования к ресурсам 59
3.2 Интерфейс прикладного программирования сервиса Pilot . 60
3.2.1 Задания и задачи 63
3.2.2 Выполнение сложных операций 65
3.2.3 Учетная информация 66
4 Реализация грид-сервиса Pilot 67
4.1 База данных сервиса 68
4.2 Программа внешнего интерфейса 70
4.2.1 Контейнер WSGI-приложений и модуль аутентификации запросов 71
4.2.2 Модуль интерфейса прикладного программирования 73
4.3 Программа обработки задач 73
5 Использование грид-сервиса Pilot 75
5.1 Интеграция в ГридННС 75
5.2 Анализ функциональных характеристик Pilot 80
5.3 Сравнительное тестирование производительности сервиса . 83
Заключение 86
Литература
- Открытая архитектура грид-сервисов
- Инфраструктура ресурсов веб-сервисов
- Простые манипуляций с ресурсами
- Интерфейс прикладного программирования сервиса Pilot
Введение к работе
Актуальность работы
В настоящее время все большее распространение приобретает использование суперкомпьютеров и вычислительных кластеров для расчетов, связанных с решением задач моделирования в различных научных областях: исследование свойств новых материалов, моделирование погодных явлений, исследования процессов термоядерного синтеза и формирования галактик, моделирование в областях биофизики и биохимии, поиск новых лекарств, анализ экспериментальных данных в физике элементарных частиц. Массовое использование технологий высокопроизводительной обработки данных радикально сокращает затраты на реализацию самых передовых и самых сложных проектов. Суперкомпьютеры позволяют ускорить расчеты, делая возможным практическое применение более точных и всесторонних математических моделей. Развитие суперкомпьютерных технологий и организация их эффективного использования является одним из приоритетных научных направлений Российской Федерации.
Проведение расчетов на суперкомпьютерах связано с решением большого количества технических и организационных задач, связанных с обеспечением доступа к ресурсам и повышением эффективности их использования. В настоящее время получили развитие концепции грида и грид-вычислений, направленные на обеспечение удаленного доступа к географически распределенным вычислительным ресурсам и услугам, поэтому представляется перспективным их использование для организации удаленной работы на суперкомпьютерах. С помощью грида от конечного пользователя скрываются подробности внутреннего устройства вычислительных ресурсов, предоставляя ему унифицированный способ доступа к этим ресурсам. Существующие в настоящее время стандарты и методы в области грид-вычислений на основе спецификации WSRF используют достаточно сложные в реализации программные интерфейсы веб-сервисов, требующие, как правило, специальных библиотек или средств автоматической генерации программного кода. В последнее время активно развиваются альтернативные подходы к созданию веб-сервисов, основанные на архитектурном стиле REST («RESTful-веб-сервисы»). Разработка методов создания грид-сервисов на основе таких подходов позволяет упростить интерфейсы грид-сервисов, тем самым расширяя возможности их прямого использования прикладными программами.
Важными проблемами, связанными с использованием гридов, являются распределение выполняемых задач между узлами сети, а также автоматизация сложных вычислений, состоящих из отдельных независимых шагов, являющихся, обычно, самостоятельными вычислительными задачами. Для их выполнения используются грид-сервисы, обеспечивающие «оркестровку»,
то есть последовательный или одновременный запуск отдельных шагов композитной задачи в соответствии с заданной логикой и отслеживание процесса их выполнения. Такие грид-сервисы выполняют центральную роль во многих существующих грид-проектах. Разработка грид-сервиса, обеспечивающего запуск задач, и имеющего простой и надежный программный интерфейс, построенный на основе новых методов, базирующихся на архитектурном стиле REST является важной прикладной задачей и хорошей проверкой практической ценности и эффективности предложенных методов.
Цель и задачи исследования
Основными целями данной диссертационной работы являются:
разработать подход к созданию грид-сервисов, позволяющий создавать простые для проектирования, удобные для реализации и надежные в использовании интерфейсы прикладного программирования, не требующие специальных средств для разработки клиентских программ;
реализовать грид-сервис запуска композитных заданий, имеющий удобный интерфейс прикладного программирования, построенный на разработанном подходе, обеспечивающий эффективное управление потоками заданий в гриде Национальной Нанотехнологической Сети (ГридННС);
провести практические испытания разработанных программных средств на полигоне грид-инфраструктуры.
Положения, выносимые на защиту
Разработан новый подход к созданию грид-сервисов с использованием архитектурного стиля REST, который позволяет создавать простые для реализации интерфейсы прикладного программирования, не требующие использования специальных средств для разработки клиентских и серверных программ. Важными свойством нового подхода является универсальность форматов представлений ресурсов, упрощенная модель восстановления при сбоях и концептуальная простота. Впервые рассмотрен вопрос управления циклом существования ресурсов для сервисов такого типа.
Реализован грид-сервис запуска композитных заданий Pilot, имеющий интерфейс прикладного программирования, следующий разработанному подходу, предназначенный для управления потоками композитных заданий, имеющих структуру направленных ациклических графов.
3. Проведены тестовые испытания грид-сервиса запуска композитных заданий Pilot в рамках полигона ГридННС, подтверждающие правильность предложенного подхода. В процессе опытной эксплуатации на полигоне ГридННС грид-сервис Pilot продемонстрировал высокую производительность. Грид-сервис Pilot является законченным программным продуктом, использующимся в настоящее время на полигоне ГридННС.
Научная новизна
В диссертации впервые сформулированы методы разработки грид-сервисов с использованием архитектурного стиля REST, в том числе универсальные методы управления временем жизни ресурсов RESTful-веб-сервисов. Обобщены существующие лучшие методики и на их основе даны строгие формулировки принципов построения грид-сервисов с использованием RESTful-веб-сервисов. Предложенный подход позволяет обеспечить универсальность форматов представлений ресурсов, упрощенную модель восстановления при сбоях и концептуальную простоту реализации. Таким образом, становится возможным создание удобных и надежных интерфейсов прикладного программирования, не требующих использования специальных средств или библиотек как для разработки клиентских программ так и самих грид-сервисов.
Практическая значимость работы
В работе сформулированы методы, применяемые при разработке нового грид сервиса, обеспечивающие концептуальную простоту его интерфейса прикладного программирования.
На основе предложенных методов разработан новый грид-сервис запуска композитных заданий, названный «Pilot», который используется в существующем гриде национальной нанотехнологической сети для запуска композитных заданий и контроля за их выполнением. Реализованный грид-сервис является модульным решением, которое позволяет применять его не только в инфраструктуре ГридННС, но и в других гридах и е-инфраструктурах, поддерживающих совместимые интерфейсы грид-шлюзов суперкомпьютеров. Кроме того, имеющаяся реализация может быть легко расширена для использования альтернативных интерфейсов грид-шлюзов, что обеспечивает ее интеграцию в другие гриды.
Разработка данного сервиса была выполнена в связи с потребностью в надежном грид-сервисе запуска композитных заданий, который имел бы достаточно удобный для использования интерфейс прикладного программирования, не привязанный к конкретным средствам разработки программного обеспечения или библиотекам. Работоспособность предложенных решений проверялась на практике на полигоне проекта ГридННС. Реализованный в
рамках работы грид-сервис прошел испытания и используется в инфраструктуре проекта ГридННС.
Личный вклад автора
Личный вклад автора состоит в формулировке предлагаемых в диссертации оригинальных методов построения грид-сервисов, разработке форматов описания композитных заданий и задач, разработке интерфейса прикладного программирования грид-сервиса Pilot и последующей реализации грид-сервиса Pilot.
Основное содержание диссертационной работы и ее результатов полностью отражено в четырех научных публикациях автора. В материалах совместных публикаций, за исключением публикации [4], личный вклад автора является определяющим. В публикации [4] личный вклад автора заключается в разработке технологических требований к регистрационным центрам инфраструктуры публичных ключей, используемой для надежной аутентификации запросов к грид-сервисам, а также практической проверке всех требований, приведенных в разделе 3 публикации.
Апробация работы
Работа обсуждалась и получила положительную оценку на следующих научных семинарах:
на научном семинаре отделения Программирования Института Прикладной Математики имени М.В. Келдыша Российской Академии Наук (16 февраля 2010 г.);
на научном семинаре Научно-Исследовательского Вычислительного Центра Московского Государственного Университета имени М.В. Ломоносова (15 марта 2010 г.);
на научном семинаре «Проблемы современных информационно-вычислительных систем» Механико-Математического Факультета Московского Государственного Университета имени М.В. Ломоносова под руководством д.ф.-м.н., проф. В. А. Васенина (16 ноября 2010 г.).
Основные результаты работы, разработанный подход к построению грид-сервисов, описание реализации грид-сервиса Pilot были доложены автором на следующих международных научных конференциях:
— на Четвертой международной конференции «Распределенные вычисле
ния и Грид-технологии в науке и образовании» (GRID'2010) (28 июня-3
июля 2010 г., Дубна);
на симпозиуме летней школы XtreemOS 2010 (XtreemOS Summer School 2010, doctoral symposium) (5-9 июля 2010 г., Гюнзбург), доклад был отмечен дипломом «best presentation award»;
на 18-й Международной конференции по вычислениям в физике высоких энергий и ядерной физике (18th International Conference on Computing in High Energy and Nuclear Physics, CHEP 2010) (18-22 октября 2010 г., Тайней).
Структура и объем работы
Открытая архитектура грид-сервисов
Основной постулат OGSA — все что угодно является сервисом: сущностью, имеющей доступ к сети, которая обеспечивает доступ к определенным ресурсам или услугам путем обмена сообщениями. Вычислительные ресурсы, ресурсы хранения данных, сети, программы, базы данных и так далее являются ресурсами, доступ к которым предоставляется посредством сервисов. Принятие такой однородной модели сервисов так же означает, что все компоненты являются виртуальными.
Более точно, в OGSA все что угодно представляется грид-сервисом, являющимся Веб-Сервисом, следующим стандартным соглашениям (о контроле доступа, способах вызова и так далее) и поддерживающим стандартные интерфейсы для управления временем жизни сервисов. Этот базисный набор соглашений, которому следуют все без исключения грид-сервисы облегчает создание сервисов более высокого уровня, которые можно рассматривать как более высокий уровень абстракции над базовыми соглашениями.
Существует два понятия, имеющие одно и то же название: веб-сервис. В тексте настоящей работы для избежания путаницы термин «веб-сервис», написанный с маленькой буквы, будет обозначать более широкое понятие: это сервис, использующий для реализации интерфейса прикладного программирования, открытые стандарты веб-технологий: протокол HTTP и другие связанные стандарты (URI, Mime Types и прочие).
Второе более узкое значение будет писаться с большой буквы, «Веб-Сервис»: это сервис, использующий для реализации интерфейса прикладного программирования протокол SOAP поверх HTTP, язык XML для обмена данными и обычно предоставляющий машинно-читаемое описание интерфейса на языке описания Веб-Сервисов (Web Service Description Lan-guage, WSDL). В кругах разработчиков приложений, веб-сервисы, описываемые вторым значением этого термина, так же известны как «Большие Веб-Сервисы» (Big web services, WS- 2).
Своим появлением веб-сервисы обязаны во многом простоте протокола HTTP, лежащего в основании современной всемирной паутины (World Wide Web). Прототипом веб-сервисов можно считать обычные веб-сайты, содержащие материалы в форматах, хорошо подходящих для машинного разбора (обычно XML). Позже появились библиотеки, реализующие удаленный вызов процедур, использующие протокол HTTP для транспорта, и протоколы типа общего интерфейса шлюза (Common Gateway Interface, CGI) на стороне сервера: XmlRPC [8], SOAP [9]. Поскольку эти протоколы опирались на удаленный вызов процедур и удаленный вызов объектов в качестве базовых концепций, их реализация сделана по аналогии с другими средствами, реализующими удаленный вызов процедур: интерфейсы описываются на специальном языке описания интерфейсов; на основании этих описаний генерируется программный код (статически или динамически), реализующий сериализацию и передачу соответствующих структур данных.
Такой подход обладает рядом существенных недостатков: реализация клиентских и серверных программ во многом зависит от наличия и качества инструментов, работающих с описаниями интерфейсов, реализация программ без использования этих инструментов становится достаточно трудоемкой и чреватой ошибками; стандарты, описываемые взаимодействие сервисов достаточно сложны, их реализации в разных библиотеках не всегда полные, и не всегда хороню совместимые друг с другом; не используются многие возможности, заложенные в сам протокол HTTP: кешируемость, идемпотентность и отсутствие побочных эффектов у разных видов запросов; адресация сервисов и ресурсов переносится внутрь описаний интерфейсов.
Достоинствами такого подхода является наличие строгих описаний интерфейсов сервисов на языке, предназначенном для автоматического понимания и интерпретации различными программными компонентами. Это позволяет производить автоматическое обнаружение и классификацию сервисов, а в некоторых случаях даже автоматическую стыковку сервисов.
В настоящее время появилась новая концепция реализации веб-сервисов, использующая более полно возможности протокола HTTP для реализации интерфейсов прикладных программ, основанная на архитектурном стиле передачи состояния представлениями (Representational State Transfer, REST), предложенном P. Филдингом [10]. Этот стиль также лежит в основе современной редакции протокола HTTP 1.1 [11]. Веб-сервисы, построенные с использованием этого архитектурного стиля используют адреса HTTP-ресурсов для адресации ресурсов, с которыми работают, а так же используют методы HTTP для манипуляций с ресурсами и сервисами. Такие веб-сервисы получили название RESTful-веб-сервисов. Более подробно концепция REST и RESTful-веб-сервисы описаны в главе 2.
Инфраструктура ресурсов веб-сервисов (Web Service Resource Framework, -WSRF) появилась как реализация концепций открытой архитектуры грид сервисов при помощи существующих технологий «Больших Веб-Сервисов». Основной концепцией в архитектуре WSRF является Web Service Resource (WS-Resource) [12]. В понимании WSRF, ресурсом является логическая сущность, которую можно отделить от других, возможно аналогичных, сущностей (то есть идентифицировать). Эта сущность может иметь не пустое множество свойств, представимых в виде информационного набора XML (XML infoset, [13]). Кроме того, эта сущность может иметь цикл существования: она, возможно, может быть создана по запросу, а так же может иметь ограниченное время жизни.
Инфраструктура ресурсов веб-сервисов
Концепция архитектурного стиля передачи состояния представлениями (Representational State Transfer, REST) была предложена Р. Филдингом в 2000 году в его докторской диссертации «Архитектурные стили и дизайн современных архитектур программного обеспечения, основанных на компьютерных сетях» [10]. Данный архитектурный стиль был выведен и формализован исходя из принципов, которые в той или иной степени были заложены в существующую на тот момент реализацию Всемирной паутины, World Wide Web.
В качестве начальной предпосылки был выбран следующий набор ограничений: использование клиент-серверной модели взаимодействия, отсутствие состояния на стороне сервера в коммуникациях между клиентом и сервером, возможность существования промежуточных узлов кеширова-ния, однородный интерфейс между всеми участниками сети, возможность построения многоуровневых сетей. Исходя из этого набора ограничений был сформулирован архитектурный стиль для программного обеспечения, названный автором Representational State Transfer, или REST.
Ключевой абстракцией информации в REST является ресурс, которым является любая информация, которая может быть поименована: документ, изображение, сервис, изменяющийся во времени (например «сегодняшняя погода в Мурманске»), коллекция других ресурсов, объект из реального мира (например, конкретный человек) и так далее. Ресурс является концептуальным отображением на множестве сущностей (но не самой сущностью, которая соответствует этому отображению в любой конкретный момент времени). Более строго, ресурс R — это изменяющаяся во времени функция членства Mn(t), которая в момент времени t отображается на множество сущностей или значений, эквивалентных в этот момент времени. Значения в этом множестве могут быть представлениями ресурса, и/или идентификаторами ресурса. В определенные моменты времени ресурс может отображаться на пустое множество, что позволяет делать ссылки на сущности до появления их реализаций. Некоторые ресурсы могут быть статическими, в том смысле, что их набор значений никогда не меняется после создания ресурса, другие ресурсы могут часто менять свое значение с течением времени. Единственное свойство ресурса, которое никогда не должно меняться — это семантика самого отображения, поскольку именно она отличает ресурсы друг от друга.
Например, ресурс «последняя задача, запущенная пользователем» является отображением, которое меняет свое значение с течением времени. С другой стороны, отображение «задача с идентификатором 1234» является статичным.
Сторона, присваивающая идентификатор конкретному ресурсу в рамках отведенного ей пространства имен, принимает на себя обязательство поддерживать семантическую правильность отображения с течением времени (не изменять функцию членства).
Взаимодействие компонентов, использующих архитектурный стиль REST, происходит путем отправки клиентом запросов-к серверу и получения ответов. При этом коммуникации не имеют собственного состояния, то есть каждый запрос содержит в себе всю информацию, необходимую для его понимания, независимо от того, какие запросы поступали до него. Таким образом забота о поддержании состояния сервиса является полностью ответственностью клиента, но не сервиса.
Каждый запрос содержит управляющих данные, идентификатор ресур са, являющегося целью запроса и, возможно, представление ресурса (или несколько представлений).
Представление ресурса состоит из данных (являющихся просто неко- торой последовательностью байтов), метаданных, описывающих данные, и, иногда, метаданных, описывающих метаданные (обычно используются для проверки целостности сообщения). Данные представляют собой произвольную последовательность байтов. Для метаданных предусматриваются стандартные способы описания. Существуют более распространенные, но менее точные термины соответствующие представлению ресурса, например: «документ», «файл».
Ответ содержит управляющие данные, а так же может содержать представление ресурса (включая метаданные представления), а так же метаданные самого ресурса, которые не специфичны для данного представления, но содержат дополнительную информацией о ресурсе.
Архитектурный стиль REST может быть применен для построения сервисов, работающих по протоколу HTTP [24]. Сервисы, разработанные с использованием такого подхода, называют RESTful-веб-сервисами.
RESTful-веб-сервис представляет собой коллекцию ресурсов, взаимодействие с которыми происходит посредством HTTP-методов (чаще всего GET, PUT, POST и DELETE) и допустимых представлений ресурсов, которые согласованы между потребителем сервиса и самим сервисом. Кроме того, используемые для взаимодействия с сервисом HTTP-методы логически соответствует операциям, производимым с ресурсами. Однородные по типу ресурсы объединяются в коллекции.
В настоящее время для RESTful-веб-сервисов не существует однозначной «официальной» спецификации. Л. Ричардсон и С. Руби проводят одну из первых попыток стандартизации RESTful-веб-сервисов путем введения концепции ресурсно-ориентированной архитектуры (Resource-Oriented Architecture, ROA) [24]. Авторы книги подчеркивают тот факт,.что по сути не существует четких стандартов, описывающих RESTful-веб-сервисы, есть общие подходы и принципы для создания таких сервисов. Они рассматривают вопросы понимания сущности ресурсов, методы использования структуры идентификаторов ресурсов, как средств адресации ресурсов, обсуждается применение HTTP-методов и использование кодов состояния HTTP. Другая книга, изданная недавно, «REST на практике» [25], фокусируется в основном на практических аспектах разработки веб-сервисов, не приводя достаточно формальных определений.
В настоящей работе на основе методов, предложенных в [24], формулируется ряд определений, характеризующих принципы построения RESTful-веб-сервисов. Кроме того, вводятся дополнительные требования и рекомендации, необходимые для реализации грид-сервисов как RESTful-веб-сервисов.
Ресурс — это сущность, обладающая достаточной информационной ценностью для того, чтобы ссылка на нее имела практический смысл.
Обычно ресурсом является документ, строка в базе данных, результат выполнения какого-либо алгоритма. Ресурсом также может являться и абстрактная концепция: например, список программ, установленных на вычислительном кластере.
Унифицированный идентификатор ресурса (Uniform Resource Identifier, URI) — это строка, определяющая имя и адрес ресурса или его представления.
Каждому ресурсу соответствует по крайней мере один идентификатор ресурса. Формальная структура идентификаторов ресурсов определяется в [26]. Иногда вместо термина идентификатор ресурса употребляется термин адрес ресурса, который в контексте RESTful-веб-сервисов и грид-сервисов имеет то же значение.
Простые манипуляций с ресурсами
Требования к ресурсам и среде выполнения задач могут указываться как в описании задач, так и в описании заданий. Пункты требований, указанные в описании задачи, имеют приоритет над требованиями из описания задания. Грид-сервис Pilot поддерживает следующие группы требований:
Вычислительные ресурсы ГридННС могут публиковать информацию о программном обеспечении, предустановленном на вычислительных узлах администраторами ресурсов и обслуживаемых виртуальных организаций. Эта информация включает в себя названия и версии программных пакетов. Сервис Pilot поддерживает указание в требованиях списки необходимого программного обеспечения, в которых возможно использовать операции сравнения версий программ. Например, требования к программному обеспечению вида «mvapich, abinit 6, gcc == 3.5.5» будут удовлетворены любым вычислительным элементом, на котором предустановлена любая версия пакета mvapich, пакет abinit любой версии старше 6 а так же пакет gcc строго определенной версии 3.5.5.
Кроме того, для запуска задач на грид-шлюзах от имени пользователя, сервис должен иметь доступ к прокси-сертификатам пользователей и соответствующим ключам. Совокупность из ключа, соответствующего прокси-сертификата, и цепочки сертификатов до корневого сертификата инфраструктуры публичных ключей далее называется делегацией.
Все запросы к грид-сервису запуска заданий Pilot должны быть аутен-тифицированными при помощи сертификатах.509 или прокси-сертифика-та, поэтому в любых запросах в качестве неявного параметра всегда присутствуют данные об имени пользователя (точнее, о субъекте сертификата), расширениях сертификата и атрибутном сертификате с информацией о виртуальной организации (при наличии атрибутного сертификата в расширениях прокси-сертификата, или где-либо в цепочке сертификатов).
В дальнейшем тексте выражение «данный пользователь» и подобные используется для обозначения пользователя, сертификат которого использовался для аутентификации запроса. При описании структуры ресурсов сервиса предполагается, что базовый адрес всего сервиса имеет вид https://pilot/. Для того, чтобы адреса ресурсов обладали описательными свойствами, организуем коллекции ресурсов и сами ресурсы следующим образом: протоколы выполняемых операций организованы коллекцию блоков записей журналов за заданный период времени, ресурсы в которой формируются динамически и имеют адреса вида https://pilot/ accouning/{tsl}-{ts2}. Здесь {tsl} и {ts2} соответствуют дате и времени начала и конца временного периода блока записей. Содержание блоков записей определяется правами доступа пользователя, посылающего запрос.
Общие сведения о структуре ресурсов и используемых операциях сервиса сведены в таблицу 3.1. Ресурс GET PUT POST DELETE /jobs список заданий пользователя - создание заданий (не идемпотентный интерфейс) /jobs/{jobid} информация состоянии задания и его структуре создание заданий (идемпотентный интерфейс), изменение описания задания, выполнение операций сзаданием прекращение и/или удаление задания operations самостоятельные ресурсы описания задания, информации о состоянии задания и операциях изменение описания задания, выполнение операций с заданием /jobs/{jobid}/tasks список задач задания - - Общие сведения о структуре ресурсов и используемых операциях сервиса запуска заданий Pi (Знак «-» означает, что данная комбинация не используется).
Все запуски заданий и задач, производимые сервисом протоколируются. Внешние сервисы мониторинга и учета, либо администраторы виртуальных организаций могут обращаться к сервису выполнения композитных заданий за учетной информацией о выполнении заданий и задач.
Полная спецификация интерфейса прикладного программирования грид-сервиса Pilot приведена в приложении Б. Основные результаты данной главы опубликованы в [46].
Задания пользователя объединяются в коллекцию pi lot /jobs/. Запросы GET к этой коллекции возвращают списки заданий пользователя. При этом каждое задание получает URI вида pilot/jobs/ jobid . Сервис поддерживает два режима создания новых заданий: идемпотентный интерфейс через HTTP/1.1 с использованием метода PUT (подробное описание в разделе 2.5, страница 44), а также стандартный не идемпотентный интерфейс с использованием метода POST. В случае использования метода POST новые описания заданий необходимо отправлять в коллекцию pilot/ jobs/, в случае успеха клиент получает идентификатор нового задания в заголовке Location в ответе сервиса. При использовании идемпотентного интерфейса, клиент генерирует идентификатор задания newid и выполняет запрос PUT, используя предполагаемый идентификатор нового задания по адресу pilot/ jobs/ newid , устанавливая в запросе заголовки If -None-Mat ch и Expect. В случае, если идентификатор задания не является уникальным, сервис возвращает клиенту код ошибки 412 Precondition Failed. Для восстановления после такой ошибки клиент может повторить попытку создать задание, сгенерировав новый идентификатор. Для генерации идентификаторов используется алгоритм, подобный time-based UUID из раздела 4.2 в [47]. Такой порядок создания задания гарантирует идемпотентность операции и позволяет использовать простой механизм восстановления после сбоев. Ответ сервиса содержит URI созданного задания.
Интерфейс прикладного программирования сервиса Pilot
Для оценки производительности грид-сервиса Pilot было проведено сравнение типичных расходов времени, связанных с собственной работой грид-среды, частью которой является сервис запуска заданий, с программным обеспечением gLite. Выбор gLite для сравнения вызван тем, что это решение используется в одной из крупнейших на данный момент грид-инфраструктур WLCG.
Тестовый стенд был собран на виртуальных машинах, с использованием средства виртуализации KVM. Каждой виртуальной машине было доступно 512Mb оперативной памяти, одно ядро процессора, виртуальный жесткий диск объемом 64Gb. При этом host-система имела 16Gb оперативной памяти, два четырехъядерных процессора Intel Xeon Е5430 (2.66GHz) и дисковый массив RAID-6 (software, Linux md).
Стенд для замера собственных расходов времени грид-среды ГридННС и грид-сервиса Pilot имел следующую структуру. Был собран макет вычислительного кластера с системой пакетной обработки
Средние длительности цикла запуска задачи. ящий из одного вычислительного узла и одного главного узла, конфигурация машин в этом состоянии была заморожена. Далее на главном узле было установлено ПО Грид-шлюза ГридННС. На еще одном узле был установлен грид-сервис Pilot и эмулятор сервиса регистрации ресурсов и грид-сервисов ГридННС (статичный файл с информацией о «гриде», доступный через веб-сервер Apache). На этом стенде производилось измерение среднего времени обработки задания, состоящего из одной задачи, от запуска задания на выполнение до его завершения. Производились измерения времени запуска непосредственно на счетном узле (используется как эталонное собственное время работы задачи), на счетном узле через средства запуска Torque (для оценки расходов времени в системе пакетной обработки), через ПО Грид-шлюза (для оценки расходов времени в стыке грид-шлюза), и через тестовый сервис Pilot. Каждый замер был повторен 100 раз.
Затем на виртуальных машинах такой же конфигурации было установлено ПО CREAM Computing Element gLite (CREAM СЕ), Worker Node (WN), Workload Management System (WMS) и User Interface (UI). После тестовых запусков объем оперативной памяти на машинах с CREAM СЕ и WMS был увеличен до 1024Mb, чтобы исключить использование раздела подкачки. Были произведены запуски задачи аналогично грид-сервису Pilot.
Результаты измерений показаны на рисунках 5.6 и 5.7, а также в таблице 5.2. Время, необходимое на локальный запуск и работу задачи на вычислительном узле было одинаковым в обоих случаях и равно 5,4 секунды. Запуск через систему пакетной обработки, настроенную для использования в ГридННС оказался быстрее, чем в случае gLite не смотря на то, что использовалась одна и та же версия системы пакетной обработки
Расходы времени на запуск задачи: локальный запуск, запуск через Torque, запуск через gLite CREAM СЕ, запуск через gLite WMS. Гистограмма для запуска через WMS изображена на врезке, так как ее пик находится в районе 120 секунд. из-за отличий в конфигурации системы: для ГридННС стандартной конфигурацией является использование общих пользовательских директорий по NFS, а для gLite — использование ssh для передачи входных-выходных файлов. Таким образом собственные накладные расходы системы пакетной обработки,составили 0,5 секунды для. конфигурации ГридННС и 1,8 секунды для конфигурации gLite.
Скорость работы грид-шлюза ГридННС, использующего Globus WS-GRAM также оказалась выше, чем скорость работы грид-шлюза gLite CREAM СЕ: собственные накладные расходы времени в среднем составили 3,3 секунды и 13,4 секунд соответственно.
Из измерений следует, что собственные расходы сервиса на запуск задачи через Pilot составляют в среднем 7,5 секунд, что в несколько раз лучше аналогичного показателя для gLite, равного в среднем 99 секундам. Одним из механизмов, позволившим достигнуть такого результата является использование сервисом Pilot механизма уведомлений об изменении состоянии задач от грид-шлюзов, что существенно повышает эффективность слежения за выполнением задач и позволяет избегать дополнительных задержек и простоев.
Также в рамках инфраструктуры ГридННС было проведено тестирование сервиса В режиме запуска в режиме длительной эксплуатации при запуске в среднем 480 заданий в час па протяжении нескольких суток (блоками по 7-13 задач, через каждые 10 минут, от 8 различных пользователей). Сервис продемонстрировал устойчивую работу и отсутствие отказов в обслуживании при такой нагрузке.
Таким образом, данная реализация грид-сервиса Pilot имеет достаточно высокую производительность и стабильность работы при различных режимах работы и является пригодной для эксплуатации в среде ГридННС. Заключение
Основные результаты диссертационной работы В работе сформулированы основные методы построения грид-сервисов с использованием архитектурного стиля REST, и решены следующие теоретические и практические задачи:
1. Разработан новый подход к созданию грид-сервисов с использованием архитектурного стиля REST, который позволяет создавать простые для реализации интерфейсы прикладного программирования, не требующие использования специальных средств для разработки клиентских и серверных программ. Важными свойством нового подхода является универсальность форматов представлений ресурсов, упрощенная модель восстановления при сбоях и концептуальная простота. Впервые рассмотрен вопрос управления циклом существования ресурсов для сервисов такого типа.
2. Реализован грид-сервис запуска композитных заданий Pilot, имеющий интерфейс прикладного программирования, следующий разработанному подходу, предназначенный для управления потоками композитных заданий, имеющих структуру направленных ациклических графов.
3. Проведены тестовые испытания грид-сервиса запуска композитных заданий Pilot в рамках полигона ГридННС, подтверждающие пра - вильность предложенного подхода. В процессе опытной эксплуатации на полигоне ГридННС грид-сервис Pilot продемонстрировал высокую производительность. Грид-сервис Pilot является законченным
