На правах рекламы:
ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Авторитетность издания

ВАК - К1
RSCI, ядро РИНЦ

Добавить в закладки

Следующий номер на сайте

2
Ожидается:
17 Июня 2024

Информационная система ГридННС

GridNNN information system
Статья опубликована в выпуске журнала № 1 за 2012 год. [ на стр. 6 - 10 ]
Аннотация:Описаны архитектура информационной системы ГридННС, построенная на основе RESTful-веб-сервисов, структура публикуемой информации и используемая модель безопасности. Одним из главных отличий ГридННС от других грид-инфраструктур является использование архитектурного стиля REST для реализации грид-сервисов.
Abstract:Russian National Nanotechnology Network grid infrastructure (GridNNN) is developed to provide access to supercomputer resources to scientists, engineers and students working in the area of nanotechnology sciences. It should enable unified transparent and secure access to computational resources connected to the NNN. One of the distinguishing key features of GridNNN is its design based on REST architectural style for grid services. This work describes the GridNNN Information System based on RESTful web services, the structure of the published information and the access security model.
Авторы: Крюков А.П. (kryukov@theory.sinp.msu.ru) - Научно-исследовательский институт ядерной физики им. Д.В. Скобельцына Московского государственного университета им. М.В. Ломоносова, кандидат физико-математических наук, Шамардин Л.В. (shamardin@theory.sinp.msu.ru) - Научно-исследовательский институт ядерной физики им. Д.В. Скобельцына Московского государственного университета им. М.В. Ломоносова, Патрикеев Д.О. (patrikeev@theory.sinp.msu.ru) - Научно-исследовательский институт им. Д.В. Скобельцына МГУ им. М.В. Ломоносова
Ключевые слова: система учета, информационная система, restful-веб-сервисы, rest, гридннс, грид, распределенные вычисления, высокопроизводительные вычисления
Keywords: accounting system, information system, RESTful web services, rest, GridNNN, grid, distributed computing, high-performance computing
Количество просмотров: 10133
Версия для печати
Выпуск в формате PDF (5.33Мб)
Скачать обложку в формате PDF (1.08Мб)

Размер шрифта:       Шрифт:

Концепция грида была предложена в 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.


Постоянный адрес статьи:
http://swsys.ru/index.php?page=article&id=3001&lang=&lang=&like=1
Версия для печати
Выпуск в формате PDF (5.33Мб)
Скачать обложку в формате PDF (1.08Мб)
Статья опубликована в выпуске журнала № 1 за 2012 год. [ на стр. 6 - 10 ]

Возможно, Вас заинтересуют следующие статьи схожих тематик: