CC BY
39
Текст описания на входном языке
Текст описания на языке Java
Байт-код
Мультиагентная система планирования и распределения ресурсов
Подсистема логического вывода
Схема создания базы знаний Grid-системы
компилирует текст на языке Java в исполняемый байт-код. При исполнении байт-кода Java-интер-претатором (Java Virtual Machine) создается БД, которая вместе с подсистемой логического вывода, интерпретирующей правила вывода данных, образует БЗ Grid-системы.
Рассмотренные в данной работе язык и средства его трансляции дают возможность конструировать предметно-ориентированные модели вычислений, включать в них требуемые ограничения и контролировать полноту, корректность и целостность атрибутов и взаимосвязей объектов разрабатываемых моделей. Такие модели обеспечивают детализированное описание инфраструктуры разнородных распределенных вычислительных сред, предоставляя возможность эффективно использо-
вать ресурсы этих сред при решении сложных научных и прикладных задач.
Литература
1. Baker M., Buyya R., Laforenza D. Grids and Grid Technologies for Wide-Area Distributed Computing // Software: Practice and Experience. 2002. Vol. 32. No. 15, pp. 1437-1466.
2. Уилкинсон, Райнш. Справочник алгоритмов на языке АЛГОЛ. Линейная алгебра. М.: Машиностроение, 1976. 389 с.
3. NeoDatis. URL: http://neodatis.wikidot.com (дата обращения: 17.10.2011).
4. Джордан Д. Обработка объектных баз данных в С++. Программирование по стандарту ODMG. М.: Издат. дом «Вильямс», 2001. 384 с.
5. Децентрализованное управление потоками заданий в интегрированной кластерной системе / И.В. Бычков [и др.] // Вестн. НГУ Сер. Информационные технологии. 2011. Т. 9. Вып. 2. С. 42-54.
УДК 004.75
ИНФОРМАЦИОННАЯ СИСТЕМА ГридННС
(Работа выполнена при финансовой поддержке Минобрнауки РФ, контракт № 07.514.11.4022,
и гранта РФФИ Не 11-07-00434-а)
А.П. Крюков, к.ф.-м.н.; Л.В. Шамардин, к.ф.-м.н.; Д.О. Патрикеев
(Научно-исследовательский институт им. Д.В. Скобельцына МГУ им. М.В. Ломоносова (НИИЯФ МГУ), [email protected], [email protected], patrikeev(a}heory. sinp.msu.ru)
Описаны архитектура информационной системы ГридННС, построенная на основе RESTful-веб-сервисов, структура публикуемой информации и используемая модель безопасности. Одним из главных отличий ГридННС от других грид-инфраструктур является использование архитектурного стиля REST для реализации грид-сервисов.
Ключевые слова: высокопроизводительные вычисления, распределенные вычисления, грид, ГридННС, REST, RESTful-веб-сервисы, информационная система, система учета.
Концепция грида была предложена в 90-х годах 20 века К. Кессельманом и Я. Фостером [1]. За
прошедшее время гриды прошли значительный путь развития. На основе успешного опыта ис-
пользования Globus Toolkit версии 2 (GT2) сформулирована открытая архитектура грид-сервисов (Open Grid Services Architecture, OGSA, http://www. ogf.org/documents/GFD.80.pdf), которая в дальнейшем была заменена на WSRF (http://docs.oasis-open.org/ wsrf/wsrf-primer-1. 2-primer-cd-02.pdf). В рамках подхода WSRF объединяются веб-сервис и ресурс, доступ к которому он обеспечивает. Канонической реализацией WSRF является Globus Toolkit версии 4 (GT4).
Следуя спецификациям WSRF, можно создавать универсальные сервисы, использующиеся практически для любых гридов. Однако стандарт WSRF оказался исключительно сложным и, как следствие, трудным в реализации. Даже каноническая реализация в виде GT4 не является полной и содержит ряд ошибок. Все это ставит под угрозу достижение основной цели - создание универсального, динамически изменяющегося грида.
В 2000 г. Р. Филдинг предложил новый, простой в использовании и гибкий подход к созданию веб-сервисов - архитектурный стиль REST [2]. Важным достоинством RESTful-сервисов по сравнению с подходом, основанным на WSRF, является несложная семантика запросов, соответствующая интуитивно ясным методам HTTP-протокола. Кроме того, RESTful-сервисы используют протокол HTTP по его прямому назначению - как протокол запросов, а не просто как транспортный протокол, в отличие от WSRF, где процессы се-риализации и десериализации создают дополнительные проблемы, в том числе и с совместимостью реализаций.
В процессе работы над проектом грид-инфра-структуры Национальной нанотехнологической сети (ГридННС) (http://ngrid.ru/ngrid, 2008) авторы использовали архитектурный стиль REST для реализации грид-сервисов в рамках концепции OGSA. В частности, на этой основе был реализован ключевой сервис ГридННС, управляющий выполнением заданий и названный Pilot [3, 4].
В настоящей работе описывается информационная система ГридННС, построенная на базе RESTful-веб-сервисов.
Структура ГридННС
ГридННС предоставляет возможность унифицированного безопасного удаленного доступа к суперкомпьютерным ресурсам ННС.
Структуру ее можно представить в виде трех слоев (рис. 1): пользовательские интерфейсы, грид-шлюзы к ресурсам и общие инфраструктурные сервисы.
Слой пользовательских интерфейсов предназначен для запуска пользователями своих заданий в ГридННС.
Слой общесистемных сервисов отвечает за функционирование и управление ГридННС. Основными общесистемными сервисами являются информационная система (ИС), система учета, сервис управления и распределения задач, система регистрации сервисов и ресурсов, служба выдачи и управления цифровыми сертификатами, сервис проверки работоспособности ресурсов.
Слой грид-шлюзов обеспечивает доступ к вычислительным ресурсам, подключенным к ГридННС. Грид-шлюз - это комплекс сервисов, обеспечивающий всю функциональность, необходимую для использования кластера или суперкомпьютера из ГридННС.
Важный принцип, положенный в основу проектирования ГридННС, - отказ от установки дополнительного ПО на вычислительном ресурсе. Все промежуточное ПО устанавливается только на специальном сервере - грид-шлюзе. При таком подходе грид-шлюз взаимодействует с системой пакетной обработки вычислительного ресурса как специфический пользователь.
Одним из компонентов грид-шлюзов является сервис ИС. Другой компонент ИС, агрегатор (hub), является частью общесистемных сервисов. Опи-
ИП ИП ИП
Общие сервисы грид-инфраструктуры
Сайт ГридННС
ИП ИП
\ИЛР / \ ИЛР /
Ъресурс i ^bi | [J Ресурс
£
Сайт ГридННС
ИП ИП
ИЛР \ ИЛР /
1Ъресурс i | [J Ресурс
}Слой интерфейсов пользователей
}Слой общих сервисов
Сайт ГридННС
ИП ИП
ИЛР \ ИЛР /
1ЬРесурс i | [J Ресурс
К-
Слой сайтов с грид-шлюзами ресурсами
Рис. 1. Общая структура ГридННС
шем подробнее устройство и особенности функционирования ИС ГридННС.
ИС ГридННС
ИС ГридННС первоначально была построена на базе WS-MDS из инструментального набора Globus Toolkit 4. Однако из-за сложности использования и расширения возможностей WSRF-сер-висов возникла необходимость перехода на более удобные в использовании RESTful-веб-сервисы. Новая реализация ИС для грида стала еще более актуальной после того, как появилась информация о намерении разработчиков Globus Toolkit отказаться от использования WSRF-сервисов в последней версии Globus Toolkit 5, а также из-за отсутствия в его составе собственной ИС и инструментария для ее создания.
Архитектура ИС ГридННС изображена на рисунке 2. Основная задача ИС в том, чтобы обеспечить пользователей и сервисы ГридННС информацией о текущем состоянии ресурсов. Например, сервису управления выполнением заданий Pilot эта информация позволяет выбрать подходящий ресурс для выполнения задач с учетом требований с их стороны и планирования распределения нагрузки. В качестве источников информации о ресурсе выступают файл с его статическим описанием, а также провайдер динамической информации о нем. Статическая информация включает, например, название ресурса, его местоположение. Первоисточник динамической информации - локальный менеджер ресурсов (ЛМР), которым является система управления пакетной обработкой (СУПО) вычислительного ресурса.
Особое внимание при построении ИС уделяется схеме данных. В качестве прототипа схемы
Рис. 2. Архитектура информационной системы ГридННС
данных использовалась GLUE Scheme 2.0 (http:// forge.ogf.org/sf/projects/glue-wg, 2007), а в качестве формата для обмена данными - JSON [5]. Общая структура публикуемой информации по каждому
вычислительному ресурсу имеет следующий вид: {
"Site": {
"Cluster": [
"SubCluster": [ {
"Queue": [...] "Host": [...] "Software"
[...]
>
Таким образом, каждый ресурс (сайт) представляет собой список кластеров, которые, в свою очередь, содержат подкластеры. Современные суперкомпьютеры довольно часто являются неоднородными. Например, суперкомпьютер «Ломоносов», занимающий 18-е место в Тор500 самых мощных суперкомпьютеров мира, имеет ряд рабочих узлов с расширенной оперативной памятью, другая часть использует графические процессоры. Разбиение кластера на подкластеры позволяет учесть неоднородную структуру вычислительного ресурса. Структура подкластера предполагается однородной.
Статическая часть информации о ресурсе содержит его общее описание (наименование, местоположение, административные контакты и т.д.). Приведем пример статической информации:
" metadata" : {
"infosys2_site_version" : "0.5.0"
> ,
"CreationTime": "2011-11-24T09:06:40Z", "Validity": 3600, "Site": {
"Cluster": [ ... ], "Description": "Resource center", "Info": {
"ServiceEndpoint": { "GRAM" : [
"https://rc.ru:8443/wsrf/services/ ManagedJobFactoryService" ] ,
"GridFTP": [
"gsiftp://rc.ru:2 811"
] ,
"IS2": "https://rc.ru:8443/
services/LIS2",
"RFT": [
"https://rc.ru:8443/wsrf/services/
ReliableFileTransferFactoryService" ]
>
> ,
"Latitude": 55.6, "Location": "Moscow, Russia", "Longitude": 37.5, "Name": "xxx",
"SecurityContact": "mailto: [email protected]", "SysAdminContact": "mailto: [email protected]", "UniquelD": "xxx.ru",
"UserSupportContact": "mailto: [email protected]", "Web": "http://www.xxx.ru",
>
>
{
Сведения о кластерах, зарегистрированных на одном ресурсном центре, помещаются в массив «Cluster», содержание которого в примере условно обозначено «[...]». Секция «Cluster» включает следующую информацию: {
"SubCluster": [ {
"Name": "rc.ru/subcluster0", "PhysicalCPUs": 16, "LogicalCPUs": 16, "Queue": [ ... ], "Host": [ ... ], "Software": [ ... ],
> ,
] ...
>
Структура рабочих узлов описывается в секции «Host»:
"Host": [ {
"MainMemory" : {
"RAMSize": 1024, "VirtualSize": 8192
> ,
"Processor": {
"ClockSpeed": 2667, "Model": "E5430", "Vendor": "Intel Xeon", "InstructionSet": "x86"
> ,
"OperatingSystem" : { "Release": "5.3", "Version": "Final", "Name": "CentOS"
> ,
"UniquelD": "subcluster0.rc.ru/
host",
"Architecture": { "SMPSize": 1, "PlatformType": "i686"
>
>
] ...
Следует еще раз подчеркнуть предположение о том, что подкластер имеет однородную структуру. Вся неоднородность учтена на уровне кластера, который может включать разные подкластеры.
Информация о доступном пользователям ПО публикуется в секции «Software»:
"Software": [ {
"LocalID": "hpmpi-2.02.05.01-20070708r", "Version": "2.02.05.01-20070708r", "Name": "hpmpi", "InstalledRoot": "/opt/hpmpi"
> , {
"ModuleName": "lmp", "LocalID": "lammps-25Sep11",
"EnvironmentSetup": [ {
"softenv": "+lammps-2 5sep11"
>
] ,
"ACL" : {
"Rule": [
"VOMS : /sysadmin" , "VOMS:/gridnnn", "VOMS:/education", "VOMS : /abinit"
]
> ,
"Version": "25Sep11", "Name": "lammps",
"InstalledRoot": "/shared/lammps"
>
], •••
В секции, описывающей ПО, важную роль играют права доступа («ACL»), с помощью которых
системный администратор может сообщить о существовании ограничений на использование тех или иных пакетов прикладных программ членами конкретных виртуальных организаций (ВО). Таким образом, публикуется локальная политика использования прикладного ПО в зависимости от принадлежности к ВО. В свою очередь, сервис управления выполнением заданий Pilot при выборе ресурса, на котором может быть выполнена задача, руководствуется этой информацией. Если данный ресурс не публикует сведения о поддержке какой-либо ВО, то он исключается при выборе места выполнения для задач пользователей этой ВО.
Важной частью схемы является секция «EnvironmentSetup», где указываются метки программного окружения «softenv» или другие расширения, по наличию которых ПО грид-шлюза осуществляет специальную настройку среды выполнения для обеспечения доступа к соответствующему ПО некоторым стандартным образом. Например, этой настройкой может быть добавление необходимых путей в переменные PATH и LD_LIBRA-RY_PATH. Данная необходимость связана с тем, что прикладное ПО на ресурсах может быть установлено различными способами. Простейший пример - использование разных корневых директорий для прикладных пакетов. Так как в момент запуска задания пользователь не знает, на каком ресурсе будет выполнена его задача, необходим механизм ее настройки в момент запуска на конкретном ресурсе. Пользователь указывает названия пакетов, требования к их версиям. Сервис Pilot извлекает из ИС список окружений, необходимых для данных пакетов на выбранном ресурсе, и дополняет описание задачи соответствующими расширениями. Таким образом, пользователю не требуются знания особенностей установки ПО на ресурсах грида, что существенно упрощает запуск задач в такой неоднородной среде.
Не менее важным атрибутом ресурса, публикуемым в ИС, является информация о свойствах очереди, в частности, об обслуживаемых ВО. Секция «Queue» содержит динамическую информацию о состоянии очередей СУПО каждого подкла-стера вычислительного ресурса. Публикуемая динамическая информация получается от СУПО.
Структура секции следующая:
"Queue" : [ {
"CEInfo": "example.com/batch-A", "Feature": [ "mpi", "single" ], "ACL" : {
"Rule": [
"VOMS:/nnn-vo-0",
"VOMS:/nnn-vo-1",
"VOMS:/nnn-vo-2/group1",
"VOMS: /nnn-vo-3/Role=VO-Admin"
]
>
"MaxWallTime": 6000, "MaxTotalJobs": 100, "MaxRunningJobs": 50, "RunningJobs": 30,
>
] ...
В приведенном примере динамической информацией является количество запущенных заданий («RunningJobs»).
Следует обратить внимание на то, что данная секция, как и секция «Software», имеет подсекцию «ACL» и позволяет указать права доступа к очереди членам ВО. Возможна и более детальная спецификация доступа на основе ролей и групп пользователей в данной ВО. Параметры очередей СУПО устанавливают политику администрации вычислительного ресурса по отношению к потребленным компьютерным ресурсам, таким как время счета и максимальное количество доступных вычислительных ядер. Таким образом, данная секция позволяет информировать пользователей об ограничениях на возможное количество потребляемых ресурсов.
Секции «Software» и «Queue» совместно обеспечивают эффективный и гибкий механизм управления доступом к вычислительным ресурсам.
Информация с каждого ресурса агрегируется специальным RESTful-сервисом InfoSys2Hub, собирающим информацию с сайтов, опубликованных в сервисе регистрации грид-сервисов Грид-ННС, с учетом их режима работы («работает» или «тестируется»). Такая структура позволяет потребителям информационного сервиса иметь дело с единственной точкой входа в инфраструктуру. Регистрация нового ресурса автоматически приводит к появлению информации о нем в ИС, изменения состояния сайтов также отражаются в общей ИС.
Безопасность ИС построена на использовании цифровых сертификатов стандарта X.509 инфраструктуры публичных ключей (PKI). Доступ к сервису предоставляется конечному набору потребителей в соответствии с конфигурацией сервиса.
В заключение необходимо отметить, что в процессе разработки ГридННС был решен ряд прин-
ципиальных вопросов создания грид-инфраструк-тур на основе RESTful-грид-сервисов.
В частности, реализована ИС как RESTful-сер-вис, обеспечивающий публикацию информации о состоянии ресурсов, ее агрегацию со всех доступных для пользователей ресурсов, предоставление ее потребителям.
В качестве формата обмена информацией был использован JSON. Его гибкость позволила реализовать подмножество публикуемых параметров, которые описаны в GLUE Scheme 2 - стандарте для построения ИС в грид-инфраструктурах.
Использование RESTful-сервисов дало возможность применять HTTP-протокол не только как транспортный, но и по его прямому назначению - как протокол запросов с ясной семантикой. Это обусловило значительное упрощение сериали-зации и десериализации информации, что повысило надежность системы.
В ближайшее время планируется внедрение данной версии ИС в инфраструктуру ГридННС в качестве основной.
Литература
1. Foster I. and Kesselman C. The Globus Project: A Status Report // In Proc. Heterogeneous Computing Workshop, IEEE Press, 1998, pp. 4-18.
2. Fielding R.T. Architectural styles and the design of network-based software architectures // Doctoral dissertation, University of California, Irvine, 2000.
3. Реализация программного интерфейса грид-сервиса Pilot на основе архитектурного стиля REST / Демичев А. [и др.] // Вычислительные методы и программирование. 2010. Т. 11. С. 62-65.
4. Демичев А., Крюков А., Шамардин Л. Принципы построения грид с использованием Restful-веб-сервисов // Программные продукты и системы. 2009. № 4.
5. K.Zyp: A JSON Media Type for Describing the Structure and Meaning of JSON Documents // Technical report, IETF Network Workong Group, draft-zyp-json-schema-02, March 2010.
УДК 519.688
ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА АВТОМАТИЗАЦИИ ПАРАЛЛЕЛЬНОГО РЕШЕНИЯ БУЛЕВЫХ УРАВНЕНИЙ НА МНОГОЯДЕРНЫХ ПРОЦЕССОРАХ
Г.А. Опарин, д.т.н.; В.Г. Богданова, к.т.н.
(Институт динамики систем и теории управления Сибирского отделения РАН, г. Иркутск,
орапп@сс. ги, ^д@£сс ги)
Рассматриваются принципы организации, основные функции и структурные компоненты инструментального комплекса для автоматизации параллельного решения булевых уравнений на многоядерных процессорах, в частности, технология автоматизации булева моделирования.
Ключевые слова: параллельные вычисления, булево моделирование, решение булевых уравнений.
Современный этап развития вычислительной техники характеризуется массовым распростране-
нием параллельных компьютеров. Расширяется круг предметных областей, в которых для реше-
