2.2 Традиционные сервисы распределенных инфраструктур на основе спецификаций WSRF
Традиционным подходом к построению сервисов распределенных инфраструктур является использование спецификации WSRF [2-6] для реализации архитектуры OGSA [2-4,2-5]. Эта спецификация описывает протоколы, позволяющие производить манипуляции с ресурсами, посредством обмена сообщениями по протоколу SOAP. Основной концепцией в архитектуре WSRF является Web Service Resource (WS-Resource) [2-6]. В понимании WSRF ресурсом является логическая сущность, обладающая следующими свойствами: ее можно идентифицировать, она может иметь непустое множество свойств, которые могут быть выражены в виде XML infoset, а также цикл существования. В свою очередь, WS-Resource – это композиция из ресурса и веб-сервиса, через который можно получить доступ к ресурсу. Для каждого WS-Resource указывается End-Point Reference (EPR), содержащий адрес ресурса согласно спецификации WS-Addressing. При этом под веб-сервисом понимается сервис, имеющий интерфейс с доступом по протоколу SOAP, с транспортом по протоколу HTTP [2-8] или HTTPS (RFC 2818). Такой сервис имеет фиксированный URI, через который он обращается к самому сервису независимо от выбранного ресурса. Информация о том, с каким именно ресурсом производится операция, содержится в EPR. Спецификации WSRF также предусматривают стандартные механизмы для управления циклом существования ресурса (создание WS-Resource, присвоение ему идентификатора EPR, уничтожение WS-Resource), получения множества свойств и взаимодействия со свойствами ресурса (с представлением свойств в виде XML infoset).
2.2.1 Спецификации WSRF и WS-Notification
Первоначальная цель, которая преследовалась при создании этих спецификаций [2-6], заключается в сближении OGSA с веб-сервисами и SOA. С помощью средств, соответствующих этим спецификациям, может быть реализован подход к моделированию и управлению состоянием в контексте веб-сервисов. Иными словами, делается попытка реализовать «состояние» — именно то, что отличает грид-сервисы от веб-сервисов. Подобный подход позволяет пользователям, находясь в контексте веб-сервисов, контролировать и изменять состояние доступных им ресурсов.
WSRF (Web Services Resource Framework) включает следующие спецификации:
WS-Resource Lifetime - определяются способы управления жизненным циклом ресурса и специфицируются Web-сервисы для ликвидации ресурса;
WS-Resource Properties - определяются способы запрашивания и модификации ресурсов, описываемых XML-документами Resource Property;
WS-ServiceGroup - определяются способы представления и управления коллекциями Web-сервисов и/или WS-ресурсами;
WS-BaseFaults - определяется базовый XML-тип, используемый при обмене сообщениями в Web-сервисах для информирования о сбоях.
Спецификации WS-Notification не входят непосредственно в состав набора WSRF, но разработаны на его основе. Набор WS-Notification состоит из трех спецификаций:
WS-BaseNotification - данная спецификация определяет интерфейсы производителя (NotificationProducers) и потребителя (NotificationConsumers) асинхронных сообщений, а также основные выполняемые функции при рассылке сообщений и подписке на них, процессов приостановки/возобновления подписок и контроля срока подписки.
WS-BrokeredNotificatiion - данная спецификация позволяет объекту, не относящемуся к Web-сервису создавать асинхронные сообщения и рассылать их через особую посредническую службу (NotificationBroker).
WS-Topics - организация и категоризация тем для подписки.
Этот список дает представление о наборе функциональных возможностей, для которых этими спецификациями определяются стандарты.
Важным преимуществом следования указанным стандартам является возможность развития создаваемой системы за счет интеграции сторонних продуктов (которые также соответствуют этим широко принятым стандартам), а также возможность - если возникнет необходимость - «выхода во внешний мир», то есть включения грид-системы в качестве сегмента во внешнюю грид-среду.
2.2.2 Реализации WSRF-сервисов на примере Globus Toolkit 4
Globus Toolkit - набор программного обеспечения и служб, созданный партнерством Globus Alliance. Является базисом для построения грид и приложений для него. ПО Globus Toolkkit доступно, распространяется свободно. Версия этого пакета Globus Toolkit 4 (GT4) [2-9] включает средства разработки служб в соответствии с группой стандартов WS, среду их функционирования, а также базовый набор служб: управления заданиями, передачи файлов, информационного обслуживания и безопасности. В GT4 имеется три основных функции:
Управление заданиями (Execution Management) для управления, мониторинга и координации удаленного выполнения заданий;
Информационные службы (Information Services) для описания служб и ресурсов;
Управление данными (Data Management), позволяющее пользователям иметь доступ, передавать и управлять распределенными данными.
ПО Globus Toolkit 4 признано ведущими производителями программного обеспечения канонической реализацией WSRF-сервисов для распределенных компьютерных инфраструктур.
В настоящее время ПО Globus в большей степени представляет собой инфраструктуру сервисов и набор инструментов для разработки распределенных приложений, чем замкнутый комплект утилит для пользователей. К основным видам сервисов, включенных в Globus, относятся следующие сервисы:
Связь
Взаимодействие в грид-среде может происходить в самых разных режимах: от передачи сообщений точка-точка до широкого вещания, причем, такие приложения как, например, управление инструментами могут одновременно использовать несколько режимов. Применяемые в Интернет протоколы не вполне удовлетворительны: велики накладные расходы, потоковая модель TCP непригодна для ряда режимов, а интерфейсы не позволяют контролировать все параметры. Идея альтернативных интерфейсов связи (API Nexus) системы Globus состоит в том, чтобы накрыть сверху нижележащие протоколы и методы, оставляя за приложением возможность выбора, одновременно обеспечивая автоматическую селекцию. Nexus вводит понятие коммуникационной связи, понимаемой как совокупность начальной и конечной точки сетевого соединения. Операция передачи инициируется путем запроса на удаленный сервис (RSR) и пересылке данных к ассоциированным конечным точкам и, в конечном счете, к открывшим их процессам. С одной начальной точкой может быть связано несколько конечных и, наоборот, поэтому могут быть сконструированы сложные коммуникационные структуры. В общем контексте грид-среды предполагается наличие базы данных с динамически собираемой информацией о сети, необходимой для правильного выбора, включая: топологию, поддерживаемые протоколы, пропускную способность и задержки. Базовый коммуникационный слой Nexus применяется для реализации высокоуровневых сервисов и средств программирования.
Информационное обслуживание
Функционирование компьютерной среды основано на управлении всевозможными типами ресурсов: компьютеров, сетей, протоколов и алгоритмов. Понятно, что поиск ресурсов возможен, если о них имеется соответствующая информация. Управление информацией в Globus (служба MDS – Metacomputing Directory Service) базируется на протоколе LDAP. LDAP специфицирует иерархическое древовидное пространство имен объектов (информационное дерево каталогов – DIT) и спроектирован как распределенная служба: произвольные поддеревья могут размещаться на различных серверах. Модель данных MDS представляет различные типы ресурсов, использующихся в распределенных вычислениях. В протоколе LDAP ресурсы формализуются понятиями объекта и атрибутов. В MDS это сайты (административные домены), вычислительные хосты вместе со сведениями о платформе, производительности процессоров, объеме памяти и т.д. Начиная с версии Globus 1.3 используется, распределенная модель GRIS-GIIS: на каждом узле работает локальная база данных GRIS, которая может быть связана с сервером организации GIIS, собирающим данные с нескольких GRIS.
Безопасность
Безопасность в грид-среде является многоаспектной проблемой, включающей вопросы аутентификации, авторизации, разграничения прав и пр. В традиционных приложениях клиент – сервер аутентификация происходит между одним клиентом и одним сервером. Сетевые же приложения могут получать ресурсы и запускать процессы на множестве компьютеров, причем их может быть действительно много – несколько сотен. Запущенные процессы взаимодействуют друг с другом, образуя динамически организованное логическое целое. Следовательно, возможное решение должно устанавливать и контролировать доверительные отношения потенциально между любыми двумя процессами. Пользователь аутентифицирует себя всего один раз за сессию, создавая «мандат», по которому процессы получают ресурсы от имени пользователя без какого-либо его дополнительного вмешательства. В Globus схема безопасности реализуется на базе стандарта GSS – Generic Security Services, определяющем процедуры и API получения сертификатов для взаимной аутентификации клиента с сервером, для кодирования/декодирования сообщений и электронной подписи. При этом GSS независим от какого-либо конкретного механизма безопасности и может быть надстроен над различными методами.
Управление ресурсами
Под управлением ресурсами принято понимать круг проблем, связанных в первую очередь с обнаружением и выделением ресурсов, а также аутентификацию, авторизацию, создание процессов и другие действия по подготовке ресурсов к использованию в сетевом приложении. В системе Globus средством заказа ресурсов служит язык спецификации RSL (Resource Specification Language), который определяет унифицированные для всей глобальной среды формы задания ресурсов и служит для реализации связи между компонентами грид-среды, обслуживающими запросы.
Запросы RSL конструируются из спецификаций параметров ресурсов, соединенных логическими операторами &, |, +. Имеется два типа параметров, различающихся по смыслу и по способу обработки:
1) Имена атрибутов MDS используются для задания ограничений на ресурсы (например, memory>=64, network=atm);
2) Локальные параметры выражают информацию относительно задания (count - число запрашиваемых узлов, max_time - время счета и т.д.). Они интерпретируются в локальных системах.
За преобразование RSL в более конкретные спецификации и наоборот ответственен так называемый "брокер", который по строке RSL подбирает соответствующие ресурсы. Реализация этого брокера существенно опирается на информационный сервис, обеспечивающий эффективный доступ к данным о текущем статусе ресурсов. Результатом выполнения поискового запроса становится один или несколько адресов локальных менеджеров ресурсов, подходящих для запускаемого задания.
Локальное управление ресурсами и заданиями
Самый низший уровень в архитектуре Globus – уровень управления ресурсами реализует локальный менеджер GRAM, который выполняет обработку спецификаций RSL (либо отвергая запрос, либо запуская одно или более заданий, указанных в запросе параметром executable), а также осуществляет дистанционный контроль заданий и периодическое обновление информации сервиса MDS. При обработке спецификаций GRAM либо самостоятельно выделяет ресурсы, либо делает это посредством обращения к некоторой локальной системе управления пакетной обработкой (СУПО). В программном интерфейсе GRAM представлены функции запуска, снятия задания и опроса его состояния. На базе этого API (и с помощью API других сервисов) в системе Globus реализован пользовательский интерфейс для управления заданиями.
Таким образом, наиболее существенными компонентами системы Globus являются:
грид-протокол распределения и управления ресурсами (Grid Resource Allocation and Management protocol - GRAM) и его служба, так называемый, “привратник”– gatekeeper, обеспечивающая безопасное, надёжное создание служб и управление;
служба мета каталогов (Meta Directory Service – MDS4, осуществляющая на основе программно выполняемой регистрации обнаружение информации и построение модели данных и ведение локального системного реестра (“GRAM reporter”);
грид-инфраструктура безопасности (Grid Security Infrastructure– GSI), которая поддерживает одноразовую регистрацию (single sign on), делегирование полномочий и отображение сертификатов.
Как показано на рис. 2.4, эти компоненты обеспечивают жизненно важные элементы архитектуры, ориентированной на предоставление услуг.
Рисунок 2.4 - Основные компоненты Globus Toolkit 4
Необходимо отметить, что последняя - пятая - версия Globus Toolkit (GT5) [2-10] существенно отличается от предыдущей (четвертой) версии (GT4). Некоторые компоненты инструментария, входившие в GT4 (например, GT4 Java Core, WS-GRAM4, RFT), не включены в GT5. Они заменены или будут заменены в процессе развития новой версии новыми компонентами, например, Crux, Globus.org Service. Кроме того, улучшена поддержка аудита выполняемых заданий и выдачи кода завершения заданий. В ряде других компонент инструментария устранены важные ошибки, улучшены их функциональные возможности.
Существенно модифицирован важнейший компонент инструментария - GRAM: фактически осуществлен возврат к до-веб-сервисной архитектуре этого компонента, что позволило существенно улучшить его производительность и надежность работы. Это свидетельствует о недостатках набора спецификаций WSRF, которые выявились в процессе эксплуатации GT4, и необходимости перехода на новые базовые принципы построения веб-сервисов для распределенных компьютерных инфраструктур. Весьма перспективным походом в этой связи оказался архитектурный стиль REST. Подробнее это обсуждается в следующих разделах.
|
