Концепция грида была предложена в 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), является частью общесистемных сервисов. Опишем подробнее устройство и особенности функционирования ИС ГридННС.

  ИС ГридННС

ИС ГридННС первоначально была построена на базе WS-MDS из инструментального набора Globus Toolkit 4. Однако из-за сложности использования и расширения возможностей WSRF-сер­висов возникла необходимость перехода на более удобные в использовании RESTful-веб-сервисы. Новая реализация ИС для грида стала еще более актуальной после того, как появилась информация о намерении разработчиков Globus Toolkit отказаться от использования WSRF-сервисов в последней версии Globus Toolkit 5, а также из-за отсутствия в его составе собственной ИС и инструментария для ее создания.

Архитектура ИС ГридННС изображена на рисунке 2. Основная задача ИС в том, чтобы обеспечить пользователей и сервисы ГридННС информацией о текущем состоянии ресурсов. Например, сервису управления выполнением заданий Pilot эта информация позволяет выбрать подходящий ресурс для выполнения задач с учетом требований с их стороны и планирования распределения нагрузки. В качестве источников информации о ресурсе выступают файл с его статическим описанием, а также провайдер динамической информации о нем. Статическая информация включает, например, название ресурса, его местоположение. Первоисточник динамической информации – локальный менеджер ресурсов (ЛМР), которым является система управления пакетной обработкой (СУПО) вычислительного ресурса.

Особое внимание при построении ИС уделяется схеме данных. В качестве прототипа схемы данных использовалась GLUE Scheme 2.0 (Ошибка! Недопустимый объект гиперссылки., 2007), а в качестве формата для обмена данными – JSON [5]. Общая структура публикуемой информации по каждому вычислительному ресурсу имеет следующий вид:

{

...

   "Site": {

   ...

      "Cluster": [

      ...

         "SubCluster": [

          ...

          {

           ...

           "Queue": [...]

           "Host": [...]

           "Software": [...]

          }

         ]

      ]

   }

...

}

Таким образом, каждый ресурс (сайт) представляет собой список кластеров, которые, в свою очередь, содержат подкластеры. Современные суперкомпьютеры довольно часто являются неоднородными. Например, суперкомпьютер «Ломоносов», занимающий 18-е место в Top500 самых мощных суперкомпьютеров мира, имеет ряд рабочих узлов с расширенной оперативной памятью, другая часть использует графические процессоры. Разбиение кластера на подкластеры позволяет учесть неоднородную структуру вычислительного ресурса. Структура подкластера предполагается однородной.

Статическая часть информации о ресурсе содержит его общее описание (наименование, местоположение, административные контакты и т.д.). Приведем пример статической информации:

{

    "__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:2811"

                ],

                "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: security@rc.ru",

        "SysAdminContact": "mailto: sysadmin@rc.ru",

        "UniqueID": "xxx.ru",

        "UserSupportContact": "mailto: support@rc.ru",

        "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"

           },

           "UniqueID": "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-25sep11"

                }

            ],

            "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 // Doсtoral 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.