«Научно-исследовательский институт ядерной физики имени Д.В. Скобельцына А.П. Демичев, В.А. Ильин, А.П. Крюков Введение в грид-технологии Препринт НИИЯФ МГУ - 2007 - 11/832 Москва 2007 А.П. Демичев, В.А. Ильин, А.П. ...»

Московский Государственный Университет

имени М.В. Ломоносова

Научно-исследовательский институт ядерной физики

имени Д.В. Скобельцына

А.П. Демичев, В.А. Ильин, А.П. Крюков

Введение в грид-технологии

Препринт НИИЯФ МГУ - 2007 - 11/832

Москва 2007

А.П. Демичев, В.А. Ильин, А.П. Крюков

[email protected] Введение в грид-технологии Препринт НИИЯФ МГУ - 2007 - 11/832 Аннотация В статье дается введение в распределенные вычисления (distributed computing) — способ решения трудоемких задач (вычислительных и задач обработки данных) с привлечением большого числа территориально удаленных друг от друга вычислительных ресурсов, а также ресурсов хранения и передачи данных. Вообще говоря, термин "распределенные вычисления" объединяет большое число различных подходов и конкретных технологий для решения такого рода задач. Основное внимание в данной статье уделяется одному из таких подходов, а именно, технологии создания и использования больших грид-систем.

Работа выполнена при поддержке Европейской Комиссии (в рамках проекта EGEE), фонда РФФИ (грант № 05-07-90292) и Федерального агентства по науке и инновациям (грант NS1685.2003.2).

A.P.Demichev, V.A.Ilyin, A.P.Kryukov Introduction to Grid Technology Препринт НИИЯФ МГУ - 2007 - 11/ Аннотация In this paper we give an introduction into distributed computing, a way of solving complicated computational and data processing problems by means of using large number of computing and data storage resources which are remote from each other. In general, the term "distributed computing" includes large number of various approaches and specific technologies for solving such problems.

The main attention in this paper is devoted to a specific approach, namely, to technologies of creation and exploitation of large grid systems.

This work was supported by European Commission (in the framework of EGEE project), Russian Foundation for Basic Research (grant No. 05-07-90292) and The Russian Federal Agency for Science and Innovations (grant No. NS1685.2003.2).

©А.П. Демичев, В.А. Ильин, А.П. Крюков, ©НИИЯФ МГУ, 2007, http://www.sinp.msu.ru Содержание 1 ЧТО ТАКОЕ ГРИД, ЗАЧЕМ НУЖЕН, КАК ОН ПОЯВИЛСЯ И КАК УСТРОЕН

1.1 ЧТО ТАКОЕ ГРИД

1.1.1 Терминология и определение грида

1.2 ЗАЧЕМ НУЖЕН ГРИД

1.2.1 Общие задачи грида

1.2.1.1 Обеспечение распределенных вычислений и обработки данных (удаленный доступ к вычислительным ресурсам)

1.2.1.2 Повышение эффективности компьютерных ресурсов

1.2.2 Типы грид-систем с точки зрения решаемых задач

1.2.3 Задачи грида и задачи суперкомпьютеров (сходство и различие)

1.3 КАК ПОЯВИЛСЯ ГРИД

1.3.1 От WWW к гриду (через веб-сервисы)

1.3.2 Еще немного истории: пионеры грид-движения

1.3.3 Кто занимается стандартизацией веб/грид-технологий

1.4 КАК ГРИД УСТРОЕН

1.4.1 Каким он должен быть

1.4.2 Что является, и что не является гридом: грид, кластеры и распределенные вычисления............. 1.4.3 Общие принципы архитектуры грид-систем

1.4.3.1 Структура (стек) протоколов глобального грида

1.4.3.1.1 Аппаратный уровень: управление локальными ресурсами

1.4.3.1.2 Связывающий уровень: коммуникации и безопасность

1.4.3.1.3 Ресурсный уровень: совместное использование ресурсов

1.4.3.1.4 Коллективный уровень: координация ресурсов

1.4.3.1.5 Прикладной уровень: запуск приложений в грид-среду

1.4.3.2 Архитектура сервисов распределенных систем и технологии ее реализации

1.4.3.2.1 Сервисно-ориентированная архитектура (SOA) распределенных систем

1.4.3.2.2 Принцип слабой связи

1.4.3.2.3 Понятие состояния сервисов и сервисы без состояний

1.4.3.2.4 Веб-сервисы

1.4.3.2.5 Веб-сервисы и SOA

1.4.3.2.6 Веб-сервисы и виртуализация

1.4.3.2.7 Сервисно-ориентированный грид

1.4.3.2.8 Open Grid Services Architecture (OGSA)

1.4.3.2.9 Грид-спецификации WSRF (Web Services Resource Framework) и WS-Notification

1.4.3.2.10 Другие грид-стандарты

1.4.3.2.11 Сервисно-ориентированные и объектно-ориентированные системы: сходство и различия, преимущества и недостатки

1.4.3.2.12 Разработка систем на основе SOA

1.5 ЗАКЛЮЧЕНИЕ К ПЕРВОЙ ЧАСТИ

2 ОСНОВНЫЕ ФУНКЦИОНАЛЬНЫЕ ПОДСИСТЕМЫ ГЛОБАЛЬНОГО ГРИДА

2.1 КРАТКОЕ ОПИСАНИЕ ФУНКЦИОНАЛЬНОГО НАЗНАЧЕНИЯ БАЗОВЫХ ПОДСИСТЕМ

2.2 ПОДСИСТЕМА УПРАВЛЕНИЯ ЗАГРУЗКОЙ

2.2.1 Компоненты подсистемы управления загрузкой

2.2.2 Взаимодействие подсистемы управления загрузкой с другими грид-службами

2.2.3 Вычислительный элемент

2.3 ПОДСИСТЕМА УПРАВЛЕНИЯ ДАННЫМИ

2.3.1 Наименование файлов в глобальном гриде

2.3.2 Ресурсы хранения данных

2.3.3 Каталоги

2.4 ПОДСИСТЕМА ИНФОРМАЦИОННОГО ОБСЛУЖИВАНИЯ И МОНИТОРИНГА ГРИДА

2.4.1 Архитектура и реализация

2.4.2 Структура поставщиков и потребителей подсистемы информационного обслуживания и мониторинга на основе R-GMA

2.4.3 Период хранения кортежей

2.5 ПОДСИСТЕМА БЕЗОПАСНОСТИ И КОНТРОЛЯ ПРАВ ДОСТУПА

2.5.1 Некоторые термины и общие принципы алгоритмов шифрования

2.5.2 Идентификация пользователей и узлов грида

2.5.3 Делегирование прав и использование доверенностей

2.5.4 Сервис управления виртуальными организациями и авторизация пользователей

2.6 ПОДСИСТЕМА ПРОТОКОЛИРОВАНИЯ

2.6.1 Типы запросов к подсистеме протоколирования

2.6.2 Безопасность и управление доступом к информации подсистемы протоколирования.................. 2.6.3 Источники извещений о событиях

2.7 ПОДСИСТЕМА УЧЕТА

2.7.1 Подсистема учета ППО gLite

3 РЕАЛИЗАЦИЯ ГРИД-ТЕХНОЛОГИЙ В ПРОЕКТЕ EGEE/LCG/RDIG

3.1 ОСНОВНЫЕ ЦЕЛИ И СТРУКТУРА ПРОЕКТА EGEE

3.1.1 Направления работ по проекту

3.1.2 Критерии успеха проекта

3.2 КОМПОНЕНТЫ ГРИДА EGEE

3.2.1 Технологии и стандарты: промежуточное программное обеспечение грида EGEE

3.3 ИНФРАСТРУКТУРА

3.3.1 Базовая компьютерная сеть: GEANT

3.3.2 Инфраструктура безопасной работы в грид-среде

3.3.3 Основная организационная единица для пользователей грида – виртуальная организация............ 3.4 RDIG: РОССИЙСКИЕ УЧЕНЫЕ В ПРОЕКТЕ EGEE

3.4.1 Региональные российские виртуальные организации

3.5 ГРИД-СРЕДА EGEE ГЛАЗАМИ ПОЛЬЗОВАТЕЛЕЙ И ПРОВАЙДЕРОВ РЕСУРСОВ

3.5.1 Грид-среда глазами провайдера ресурсов

3.5.2 Грид-среда глазами пользователя

3.6 ПРИКЛАДНЫЕ ЗАДАЧИ В ПРОЕКТЕ EGEE

3.6.1 Физика высоких энергий: проект LCG

3.6.2 Астрофизические приложения

3.6.3 Приложения в области ядерного синтеза

3.6.4 Решение задач биомедицины с помощью грид-среды EGEE

3.6.4.1 Drug Discovery: борьба с массовыми болезнями с помощью грида

3.6.5 Приложения в области вычислительной химии

3.6.6 Приложения для наук о Земле и геофизики

3.6.6.1 Грид для предсказания извержений вулканов

3.6.7 Финансы и мультимедиа

3.6.8 Грид-приложение в области археологии

4 ЗАКЛЮЧЕНИЕ

КРАТКИЙ ГЛОССАРИЙ ТЕРМИНОВ, СВЯЗАННЫХ С ВЕБ/ГРИД-ТЕХНОЛОГИЯМИ

СПИСОК ЛИТЕРАТУРЫ

1 Что такое грид, зачем нужен, как он появился и как устроен 1.1 Что такое грид 1.1.1 Терминология и определение грида В широком смысле, предметом этой статьи являются распределенные вычисления (distributed computing) — способ решения трудоемких задач (вычислительных и задач обработки данных) с привлечением большого числа исполнителей (вычислительных ресурсов, а также ресурсов хранения и передачи данных), работающих одновременно над разными частями задачи. Вообще говоря, этот термин объединяет большое число различных подходов и конкретных технологий для решения такого рода задач. Мы, однако, сосредоточимся на одном из подходов, а именно, на технологии создания и использования больших грид-систем.

Для начала определим более точно – что такое грид и чем грид-технологии отличаются от других типов распределенных вычислений. В основополагающей книге [1] пионеры гридтехнологий – Ян Фостер (Ian Foster) из Аргоннской Национальной лаборатории и Чикагского университета и Карл Кессельман из Института информационных наук Университета Южной Калифорнии (США) дают следующее определение: "Грид согласованная, открытая и стандартизованная среда, которая обеспечивает гибкое, безопасное, скоординированное разделение (общий доступ) ресурсов в рамках виртуальной организации".

Прежде, чем более подробно объяснить смысл этого определения – поясним происхождение самого названия такой среды, которое несет вполне определенную смысловую нагрузку. Термин грид (в смысле одной из технологий распределенных вычислений - возник в середине 90-х годов) происходит от английского слова «grid» и его буквальным переводом на русский язык является «решетка». В русскоязычной литературе зачастую и используется этот буквальный перевод. В частности, мы использовали его в названии нашей статьи – для того, чтобы подчеркнуть процесс эволюции современных компьютерных технологий. Однако надо понимать, что такой буквальный перевод не вполне отражает смысл термина. Дело в том, что англоязычный термин grid произошел от «power grid», что соответствует русскому «электросеть» или «энергосистема». В этом и заключается смысл этого названия: подобно тому, как при использовании энергосистем мы не интересуемся – какой конкретный электрогенератор выработал ток, который мы потребляем (а просто платим за потребленное электричество энергетической компании, с которой мы заключили договор), при использовании компьютерного грида мы можем не заботиться о том - какой конкретно компьютер (или устройство хранения/передачи данных) в грид-системе выполнил нашу задачу (при этом, возможно, придется тем или иным способом платить соответствующему провайдеру за использованные ресурсы).

Эту аналогию можно продолжить. Современный статус компьютерных инфраструктур можно сравнить с состоянием электрических систем в 1910 году. Тогда необходимость для каждого пользователя иметь свой генератор тормозила развитие отрасли. Революционным шагом было возникновение электросетей, создание технологий передачи и распределения электроэнергии, создание стандартизованной службы универсального и гарантированного доступа к электроэнергии. В результате не только резко повысилась эффективность использования ресурсов, но и стали возможны принципиально новые направления развития. Теперь, купив электрический чайник, мы просто втыкаем вилку в электрическую розетку и начинаем им пользоваться: электросеть избавляет нас от необходимости вместе с чайником покупать и источник энергии – электрогенератор.

Аналогично, грид призван обеспечить возможность делать компьютерные вычисления «по требованию» - просто подключившись к «решетке» вычислительных ресурсов.

Также как и электрические сети, грид это соединение технологии, инфраструктуры и стандартов. Технология – это специальное программное обеспечение, которое позволяет организациям или частным лицам предоставлять ресурсы (компьютеры, хранилища данных, сети и другие) в общее пользование, а потребителям – использовать их, когда необходимо. Инфраструктура состоит из аппаратных средств и служб (на основе людских и программных ресурсов), которые должны быть организованы, и постоянно поддерживаться для того, чтобы ресурсы могли совместно использоваться. Наконец, стандарты должны определять формат и протоколы обмена сообщениями, как между службами, так и между службами и пользователями, а также правила работы грида.

Важность этих составляющих грида можно пояснить, опять обращаясь к аналогии с энергосетями, в которых определяющую роль играют:

технологии передачи и (пере)распределения электроэнергии на большие инфраструктура - аппаратные средства (повышающие/понижающие подстанции, линии электропередач, другое электрооборудование, позволяющее электростанциям предоставлять энергию потребителям) и соответствующие службы (ремонта, контроля и т.д.);

стандарты – параметры электрического тока (напряжение в сети, частота), типы и размеры вилок/розеток, позволяющие без проблем подключать любой электроприбор к единой сети.

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

повышению производительности микропроцессоров массового производства современный персональный компьютер сравним по производительности с суперкомпьютерами десятилетней давности;

появлению быстрых линий связи - сейчас осуществляется перевод основных магистралей на уровень нескольких Гигабит/сек;

глобализации обмена информацией (Интернет/Веб);

развитию методов метакомпьютинга - научной дисциплины по организации массовых и распределенных вычислительных процессов.

Поскольку грид-инфраструктура основана на предоставлении ресурсов в общее пользование, с одной стороны, и на использовании публично доступных ресурсов, с другой, одним из ее ключевых понятий (вспомните общее определение грида в начале этого раздела) является виртуальная организация (ВО). Подробнее это понятие обсуждается в разделе 3.3. Здесь лишь отметим, что ВО является сообществом людей, которые совместно используют грид-ресурсы в соответствии с согласованными между ними и собственниками ресурсов правилами. Фактически, виртуальная организация заключает договор с владельцами ресурсов об их использовании и является представителем членов данной ВО во взаимоотношениях с владельцами ресурсов. В существующих грид-системах виртуальные организации образуют специалисты из некоторой прикладной области, которые объединяются для достижения общей цели.

Любая ВО имеет доступ к определенному набору ресурсов, которые предоставляются зарегистрированным в ней пользователям. С другой стороны, каждый ресурс может одновременно предоставляться нескольким ВО. Каждая ВО самостоятельно устанавливает правила работы для своих участников, исходя из соблюдения баланса между потребностями пользователей и наличным объемом ресурсов, поэтому пользователь должен обосновать свое желание работать с грид-системой и получить согласие управляющих органов ВО.

1.2 Зачем нужен грид 1.2.1 Общие задачи грида Концепция грида появилась не как абстрактная идея, а как ответ на появляющиеся потребности в крупных информационно-вычислительных ресурсах, динамически выделяемых для решения громоздких задач, в научной, индустриальной, административной и коммерческой областях деятельности. Создание грид-среды подразумевает распределение вычислительных ресурсов по территориально разделенным сайтам, на которых установлено специализированное программное обеспечение для того, чтобы распределять задания по сайтам и принимать их там, возвращать результаты пользователю, контролировать права пользователей на доступ к тем или иным ресурсам, осуществлять мониторинг ресурсов, и так далее. Общедоступные ресурсы на основе сайта могут включать вычислительные узлы и/или узлы хранения и передачи данных, собственно данные, прикладное программное обеспечение.

Вычислительные ресурсы предоставляют пользователю грид-системы (точнее говоря, задаче пользователя) процессорные мощности. Вычислительными ресурсами могут быть как кластеры, так и отдельные рабочие станции. При всем разнообразии архитектур любая вычислительная система может рассматриваться как потенциальный вычислительный ресурс грид-системы. Необходимым условием для этого является наличие ППО, реализующего стандартный внешний интерфейс с ресурсом и позволяющего сделать ресурс доступным для грид-системы. Основной характеристикой вычислительного ресурса является производительность (см., например, http://www.spec.org).

Ресурсы хранения также используют ППО, реализующее унифицированный интерфейс управления и передачи данных. Как и в случае вычислительных ресурсов, физическая архитектура ресурса памяти не принципиальна для грид-системы, будь то жесткий диск на рабочей станции или система массового хранения данных на сотни терабайт. Основной характеристикой ресурсов хранения данных является их объем. В настоящее время характерный объем ресурсов хранения измеряется в Терабайтах (Тб).

Информационные ресурсы и каталоги являются особым видом ресурсов хранения данных. Они служат для хранения и предоставления метаданных и информации о других ресурсах грид-системы. Информационные ресурсы позволяют структурировано хранить огромный объем информации о текущем состоянии грид-системы и эффективно выполнять задачи поиска ресурсов.

Сетевой ресурс является связующим звеном между распределенными ресурсами гридсистемы. Основной характеристикой сетевого ресурса является скорость передачи данных.

Важнейшим является междисциплинарный характер работ по развитию грид-вычислений – уже сегодня эти технологии применяются в самых разных прикладных областях. В мире возникли сотни грид-форумов (например, [2]) и проектов [3] - в физике высоких энергий, космофизике, микробиологии, экологии, метеорологии, различных инженерных приложениях (например, в самолетостроении).

Основными общими задачами грида являются:

создание из серийно выпускаемого оборудования широкомасштабных распределенных вычислительных систем и систем обработки, комплексного анализа и мониторинга данных, источники которых также могут быть (глобально) распределены;

повышение эффективности вычислительной техники путем предоставления в грид временно простаивающих ресурсов.

Приоритет той или иной общей задачи, которая решается с помощью грида, определяется типом грида и характером прикладных областей, в которых он используется.

1.2.1.1 Обеспечение распределенных вычислений и обработки данных (удаленный доступ к вычислительным ресурсам) Как уже отмечалось, компьютеры совершенствуются невероятно быстро: процессорная мощность удваивается приблизительно каждые 18 месяцев. Но и такой прогресс не всегда обеспечивает потребности ученых и инженеров - часто для вычислений недостаточно одного компьютера или даже кластера персональных компьютеров. В результате достижение научных или инженерных целей может оказаться чрезвычайно сложной, очень дорогой, а иногда совершенно невыполнимой задачей. Если же на время выполнения задачи или проекта есть возможность использовать ресурсы множества персональных компьютеров, рабочих станций, кластеров, может быть даже и суперкомпьютеров, а также хранилищ данных, размещенных в разных точках мира и принадлежащих разным людям и учреждениям, то проблема может стать разрешимой.

Такую возможность – распределения отдельных частей большой задачи по географически удаленным ресурсам (если сам характер задачи позволяет разделить ее на части) и предоставляет грид-среда.

Особенно эффективным такой подход оказывается, когда в рамках какого-либо проекта (исследования или прикладной проблемы) надо выполнить огромный поток или набор однотипных задач. Типичным примером может служить обработка большого объема данных.

1.2.1.2 Повышение эффективности компьютерных ресурсов Другая общая задача, которую решают системы распределенных вычислений, является вполне традиционной для любого производственного процесса: это повышение эффективности использования оборудования (средств производства). Эта задача становится особенно актуальной, когда производительность средств производства становится выше, чем требуется для удовлетворения локальных потребностей. Например, пока землю пахали с помощью лошади и сохи, каждый крестьянин имел свои орудия труда (производительность была так низка, что делиться с другими было просто невозможно: необходимый объем работ едва можно было выполнить за сезон). Трактор и плуг, напротив, очень часто используются совместно (колхозы, МТС, объединения фермеров и т.п.) – это возможно благодаря их высокой производительности и экономически выгодно. Аналогично и в случае компьютеров: пока их производительность была невелика, они едва справлялись с локальными задачами в однопользовательском режиме. Современные же мощные ПК зачастую реально используются не более, чем на несколько процентов свой мощности, и естественной становится задача предоставления неиспользуемых ресурсов для общественных нужд. Аналогичная ситуация характерна и для компьютерных центров, поскольку большие вычислительные задачи появляются у пользователей не постоянно, то есть потребность в выполнении вычислительной работы имеет пиковый по времени характер. Грид-технологии позволяют объединять эти мощности в единую, хотя и географически распределенную вычислительную среду. В результате пользователь получает возможность запуска своих задач на таком «глобальном кластере», имеющем мощность, существенно превосходящую его собственные ресурсы.

При этом и его компьютер (или компьютеры) может быть включен в состав этого глобального кластера, и будет выполнять задачи других пользователей. Результат же вычислений будет получен существенно быстрее, чем при последовательном запуске задач на своем персональном компьютере. Следует подчеркнуть, что временной эффект будет связан не только с пиковым характером появления задач у данного пользователя, что может иметь периодичность в дни и даже месяцы. Эффект может быть получен и просто из-за неравномерного запуска задач в течение дня, в силу чего пики загрузки не совпадают для географически разделенных по временным поясам районов (такой эффект очень хорошо известен и в электрических сетях).

1.2.2 Типы грид-систем с точки зрения решаемых задач Анализируя существующие проекты по построению грид-систем можно сделать вывод о трех направлениях развития грид-технологии:

1. вычислительный грид (Computational Grid), 2. грид для интенсивной обработки данных(Data Grid), 3. семантический Грид для оперирования данными из различных баз данных (Semantic Grid).

Целью первого направления является достижение максимальной скорости вычислений за счет глобального распределения этих вычислений между тысячами компьютеров, а также, возможно, серверами и суперкомпьютерами.

Целью второго направления является обработка огромных объемов данных относительно несложными программами. Поэтому вычислительные ресурсы грид-инфраструктуры в этом случае зачастую представляют собой кластеры персональных компьютеров. А вот доставка данных для обработки и пересылка результатов в этом случае представляют собой достаточно сложную задачу. Одним из крупнейших проектов, целью которого является создание грид-системы для обработки научных данных, является проект EGEE (Enabling Grids for E-sciencE) [13]. О нем мы будем подробно рассказывать в части 3 и в контексте этого рассказа обсудим вопросы, связанные с хранением и (своевременной) передачей больших объемов данных.

Грид-системы третьего направления - семантические - предоставляют инфраструктуру для выполнения вычислительных задач на основе распределенного мета-информационного окружения, позволяющего оперировать данными из разнотипных баз, различных форматов, представляя результат в формате, определяемом приложением. В этом обзоре мы совсем не будем осуждать этот тип грид-систем и просто отсылаем читателя к соответствующему веб-сайту [27].

1.2.3 Задачи грида и задачи суперкомпьютеров (сходство и различие) Не все проблемы лучше всего решать, используя распределенные кластеры на основе грид-технологий. Суперкомпьютеры незаменимы для некоторых научных проблем, типа составления прогноза погоды, когда множество процессоров должны часто общаться друг с другом. Очевидно, что такое частое общение невозможно обеспечит для географически распределенных и, возможно, аппаратно-неоднородных ресурсов в грид-среде. Другими словами, грид не слишком подходит для параллельных вычислений с интенсивным межпроцессорным обменом [4].

Поясним чуть более подробно почему не следует смешивать грид-технологию с технологией параллельных вычислений. Основными препятствиями для осуществления нетривиальных параллельных вычислений в грид-среде является нестабильность, плохая предсказуемость времени отклика на запрос. Причем это связано не только с тем, что в компьютерных сетях информационные пакеты проходят через множество сетевых устройств, но и с различиями в протоколах связи используемых во "внешних" компьютерных сетях и для межпроцессорного обмена внутри суперкомпьютеров. Это не позволяет эффективно организовать параллельные вычисления с интенсивным обменом информацией между процессорами, выполняющими отдельные подзадачи, в грид-среде.

Грид-технология не является технологией параллельных вычислений, она предназначена для удаленного запуска отдельных задач на территориально распределенные ресурсы.

Поэтому если громоздкая задача, которую необходимо решить, может быть разбита на большое количество маленьких, независимых (не обменивающихся никакими данными) частей, - грид-технология оказывается особенно эффективным и относительно дешевым решением. Напротив, суперкомпьютеры оказываются для таких вычислений неоправданно дорогим и неэффективным решением. В англоязычной литературе такие прикладные задачи иногда называют «bag-of-tasks» - сумка/мешок задач: вычисления для каждой выполняются независимо, а в конце пользователь или программное обеспечение просто должны соединить результаты индивидуальных вычислений. Типичными примерами таких задач являются:

массовая обработка потоков экспериментальных данных большого объема (зачастую изучаемое явление можно разделить на отдельные независимые события и экспериментальные результаты по каждому событию обрабатывать независимо визуализация больших наборов данных (отдельные области визуального представления обрабатываются независимо, а потом «склеиваются»);

сложные бизнес-приложения с большими объемами вычислений (разбиение на части зависит от конкретного характера задачи).

Ради справедливости, надо отметить, что ПО промежуточного слоя нового поколения для грид-систем (в частности, gLite, о котором мы еще будем говорить ниже) позволяет управлять некоторым классом нетривиальных параллельных вычислений – таких, зависимость подзадач в которых может быть представлена направленным графом без циклов (Direct Acyclic Graph (DAG); на Рис. 1 приведен пример такого графа). Но насколько эффективной на практике окажется эта возможность – еще предстоит выяснить.

Необходимо отметить, что существуют гибридные проекты, целью которых является достижение максимальной скорости вычислений за счет глобального распределения этих вычислений между суперкомпьютерами – при этом грид координирует использование различных суперкомпьютеров, а собственно нетривиальное распараллеливание происходит внутри суперкомпьютера. Проект DEISA [31] может служить примером этого направления, в котором предпринимается попытка объединения суперкомпьютерных центров.

1.3 Как появился грид 1.3.1 От WWW к гриду (через веб-сервисы) До сих пор мы говорили об аналогии с энергосетями и соотношении задач для грида и суперкомпьютеров. Но, естественно, идея грид-вычислений не могла бы возникнуть без предварительного развития Интернет-технологий.

Интернет, Всемирная паутина (World Wide Web (WWW), веб) и грид – связанные между собой, но различные технологии. Интернет это глобальная система сетей, соединяющая множество компьютеров и локальных (сравнительно небольших) сетей и позволяющая им взаимодействовать друг с другом. Веб это способ доступа к информации находящейся на удаленном, но включенном в Интернет компьютере. Грид – способ совместного использования ресурсов, распределенных по разным, географически удаленным друг от друга, точкам планеты.

Когда в 1991 Тим Бернерс-Ли (Tim Berners-Lee) разрабатывал в Европейском Центре Ядерных Исследований (ЦЕРН, расположен в Женеве) основы технологии Всемирной паутины, он имел побудительные мотивы, сходные с основоположниками гридкомпьютинга: в случае веба – потребность в обеспечении универсального и стандартизированного доступа к информационным ресурсам; в случае грида - потребность в обеспечении универсального и стандартизированного доступа к вычислительным ресурсам и ресурсам хранения данных. Интересно, что и в случае грида одним из основных центров разработки новой технологии тоже является ЦЕРН – он вносит определяющий вклад в создание крупнейшего научного грида в рамках проекта “Enabling Grid for EsciencE” (ниже мы расскажем об этом подробнее).

Конечно, с технической точки зрения статические вебовские страницы (а такие только и существовали в начале эпохи WWW) и грид имеют не очень много общего – пожалуй, только то, что основой для передачи информации в обоих случаях являются интернетовские транспортные протоколы TCP/IP.

Однако сейчас многие веб-сайты предоставляют динамические веб-страницы: содержание таких страниц может меняться в зависимости от запросов, которые делают пользователи (например, через веб-формы). Это уже несколько ближе к гриду - удаленные компьютеры предоставляют некоторые услуги (например, перевод фрагмента текста с одного языка на другой: это ни что иное, как частный случай обработки данных – прямая аналогия с задачами грида). Намного интереснее и ближе к грид-технологиям то, что зачастую происходит «позади» динамических веб-страниц. Например, вы делаете заказ какого-либо товара на (динамической) странице интернет-магазина. После этого начинается обработка заказа: информация о заказе и клиенте заносятся в базу данных, через банковскую систему проверяется действительность кредитной карты клиента, запрос на товар передается на склад магазина или поставщику, и так далее. Если в компьютерном отношении этот магазин достаточно «продвинутый», эти действия выполняются не людьми, а специальными компонентами программного обеспечения – веб-сервисами, которые взаимодействуют друг с другом по стандартизованным протоколам. Точное определение веб-сервисов мы откладываем до раздела 1.4. Отметим, что в русскоязычной литературе и в случае WWW, и в случае грида используют два варианта перевода англоязычных терминов web/grid services: веб-/грид-сервисы и веб-/грид-службы. Мы будем также использовать оба этих варианта - как полностью эквивалентные.

Итак, веб-страницы служат для обмена информацией между людьми, веб-сервисы – для взаимодействия компьютеров (точнее – прикладных программ на различных компьютерах) друг с другом. Отсюда – один шаг до создания системы (грид-)служб для запуска заданий на удаленных ресурсах, обработки и передачи данных, их (задач и данных) мониторинга и сбора результатов. С общей функциональной точки зрения, от веб-сервисов грид отличается только тем, что каждая система веб-сервисов настроена на решение узкого набора конкретных задач (например, обработки заказа в интернетмагазине), а грид – на решение широкого круга вычислительных задач и задач обработки и передачи данных на удаленных ресурсах. Но программные компоненты грид-среды, которые обеспечивают распределение вычислительных заданий, контроль их выполнения, передачу данных и т.д., могут быть созданы на основе веб-сервисных технологий – правда, с некоторыми расширениями и дополнительными стандартами. Более подробно мы рассмотрим этот вопрос в разделе 1.4.

Необходимо отметить, что хотя в качестве предпосылки к появления грида мы упомянули только WWW, в действительности были и другие достижения 90-х годов, ставшие как важными вехами развития компьютерных технологий в целом, так важными предпосылками для появления грид-технологий. Среди них нужно упомянуть Linux ( год) и кластеры типа Beowulf (1994 год), которые инициировали широкое распространение централизованных систем с разделяемым доступом. Следующим естественным шагом – на основе Интернета и WWW – стало развитие децентрализованных распределенных систем.

1.3.2 Еще немного истории: пионеры грид-движения Основной теоретической предшественницей современных грид-проектов считается инициатива Metacomputing, предложенная в середине 80-х годов исследователями из Национального центра суперкомпьютерных приложений США (см., например, [30]). Ее главная идея состояла в объединении нескольких суперкомпьютеров для достижения большей производительности. Одной из первых инфраструктур, реализующих эту идею, стала в 1995 году Wide Area Year (I-WAY). Йан Фостер и Карл Кессельман, участвовавшие в разработке проекта, в том же году опубликовали первые материалы, а в 1997 году провели первый семинар на эту тему (Построение вычислительного грида - Building a Computational Grid). Это и было рождением концепции грида. Позднее они стали редакторами знаменитых книг [1], заложивших основы построения грид-систем.

Необходимо отметить, однако, что Metacomputing была не единственной инициативой такого рода. Среди схожих по концепции проектов конца 80-х – начала 90-х можно отметить:

Condor (университета штата Висконсин, США);

CODINE (Computing for Distributed Network Environments, немецкая компания Genias Software - позднее переименована в Gridware, в 1992 году куплена корпорацией Sun Microsystems);

Legion (университет штата Вирджиния, позднее рабочая группа проекта выделилась в компанию Avaki).

В 1998-2002 годах были разработаны общие основы создания сетевых структур для использования географически разнесенных и находящихся в разном подчинении вычислительных мощностей. Эти результаты были суммированы в [1], а термин «грид»

стал общепринятым. Вскоре группа исследователей из Чикагского университета, возглавляемая Йаном Фостером, поддерживаемая IBM и Национальной арагонской лабораторией, разработала Открытую архитектуру грид-сервисов (Open Grid Services Architecture, OGSA), основанную на специализированных грид-сервисах.

Для создания базовой (reference) модели грида разработчиками OGSA была организована рабочая группа Open Grid Service Infrastructure (Инфраструктура открытого грида, OGSI). В 2003 году она выпустила спецификацию OGSI, в которой определены механизмы создания, управления и обмена данными между грид-сервисами. Однако, из-за ряда недостатков (в частности, чрезвычайной громоздкости) эта спецификация не была хорошо воспринята ни практиками-разработчиками грид-систем, ни Веб-сообществом. Поэтому естественным стало появление набора спецификаций Web Service Resource Framework (WSRF), где еще точнее отражено сходство грид- и веб-сервисов. Важно, что новый стандарт влияет не на всю концепцию OGSA — на верхнем уровне все остается неизменным. Как и веб-сервисы, OGSA/WSRF-сервисы могут быть определены в терминах языка WSDL, что позволяет использовать преимущества известных стандартов SOAP, XML и WS-Security (подробнее об этом – в разделе 1.4).

В 2004 году компании BEA Systems, Microsoft и Tibco опубликовали свою спецификацию для веб-сервисов - WS-Eventing, основанную на принципах публикации/подписки. Она не привязана непосредственно к гриду, а предназначена для описания взаимодействия между веб-сервисами (подробнее – также в разделе 1.4). Цели этой спецификации весьма близки к целям WSRF, но достигаются другими средствами. Почти одновременно компании Akamai, Globus Alliance, Hewlett-Packard, IBM, Sonic Software и все та же Tibco предложили спецификацию WS-Notification, входящую в состав WS-Resource Framework и опять-таки реализующую принцип публикации/подписки.

Наконец весной 2006 года компании HP, IBM, Intel и Microsoft объявили о своем намерении участвовать в разработке общего стандартного набора спецификаций вебслужб и выработали «дорожную карту» общей схемы этих спецификаций [33]. Эта дорожная карта предлагает способ согласования этих двух подходов: семейства спецификаций Web Services Distributed Management (WSDM) (включающих WSRF и WSNotification; поддерживается IBM, HP и рядом других организаций) и семейство спецификаций WS-Management (включающих WS-Eventing, WS-Transfer и WSEnumeration; поддерживается Microsoft, Intel и другими). Опубликованная дорожная карта предлагает, чтобы новые разрабатываемые спецификации в окончательном виде включали все базовые концепции, введенные сначала в OGSI и реализованные впоследствии в WSRF/WS-N.

Таким образом, сейчас появилась реальная надежда получить всеобъемлющие стандарты управления системами, базирующимися на веб-службах – в том числе, управления гридсистемами.

1.3.3 Кто занимается стандартизацией веб/грид-технологий До недавнего времени основной организацией по стандартизации грид-технологий являлся Global Grid Forum (GGF). Это общественная организация, включающая более тыс. специалистов, работающих в области распределенных вычислений и технологий грид. Основная цель GGF - содействие развитию, реализации технологий грид и развертыванию приложений путем создания основополагающих документов (технические спецификации, описания опытов создания приложений, руководства и т.п.).

Помимо Global Grid Forum вопросами стандартизации занимался и созданный в 2004 году Enterprise Grid Alliance (EGA) - консорциум ИТ-производителей (EMC, Fujitsu Siemens, HP, Intel, NEC, Network Appliance, Oracle, Sun Microsystems и целый ряд меньших по размеру компаний), заинтересованных в развитии идей грид. Создавая свой альянс, они руководствовались стремлением применять грид-технологии главным в бизнесприложениях, а не для решения научных или технических задач, требующих большой вычислительной мощности. Поэтому в центре внимания альянса оказались статические grid-структуры, расположенные в одном географическом месте и являющиеся составляющей корпоративного центра обработки данных.

Однако летом 2006 года эти две ведущие грид-организации объявили о своем объединении. Образована новая организация под названием Open Grid Forum (OGF) [2], объединившая эти две ведущие организации для ускорения внедрения грид-технологий во всем мире. Во главе новой организации будет стоять прежний председатель GGF Марк Линеш (Mark Linesch).

OGF унаследует от EGA все достижения этого альянса в области промышленной экспертизы и ориентацию на быстрые практические результаты, а от GGF - богатый опыт открытого сотрудничества в области исследований грид-систем и в разработке стандартов.

OGF является открытым форумом для всех ключевых фигур и организаций гридсообщества с целью обнаружения потенциальных проблем и их решения на основе обсуждений в рабочих группах, а также разработки спецификаций для ускорения внедрения грида.

Как открытая организация по стандартизации, OGF развивает сотрудничество с другими разрабатывающими стандарты организациями по согласованию существующих промышленных стандартов и разработке новых спецификаций. В число таких организаций входят: Organization for the Advancement of Structured Information Standards (OASIS, www.oasis.org), World Wide Web Consortium (W3C, www.w3c.org), Distributed Management Task Force (DMTF, www.dmtf.prg), Web Services Interoperability Organization (WS-I, www.ws-i.org), Internet2 (www.internet2.edu) и Liberty Alliance (www.projectliberty.org).

1.4 Как грид устроен 1.4.1 Каким он должен быть Правильно разработанная и хорошо реализованная грид-среда характеризуется следующими основными функциональными возможностями [30]:

доступ к вычислительным ресурсам, данным, устройствам, измерительным инструментам должен быть простым, прозрачным, удаленным, и безопасным;

доступ должен быть виртуальным (нужен доступ не к серверам, а к сервисам, поставляющим данные или вычислительные ресурсы — причем без необходимости знания аппаратной структуры, обеспечивающей эти сервисы);

доступ должен осуществлять по требованию (с заданным качеством), а ресурсы должны предоставляться тогда, когда в них возникает нужда;

доступ должен быть распределенным, обеспечивая возможность совместной коллективной работы виртуальных команд;

доступ должен быть устойчив к сбоям, а при выходе из строя серверов приложения должны автоматически мигрировать на резервные серверы;

доступ должен обеспечивать возможность работы в гетерогенной среде – с различными платформами.

Необходимо отметить, что не все из этих требований в должной мере реализованы в настоящее время.

1.4.2 Что является, и что не является гридом: грид, кластеры и распределенные вычисления Мы выяснили - в чем сходство и различия задач грида и суперкомпьютеров, технологий Интернета, WWW и грида. Теперь давайте обсудим - как соотносится термин «грид» с терминами «кластер» и «распределенные вычисления». Дело в том, что термин «грид»

зачастую используется в разных значениях. Особенно сильно, такая тенденция проявилась после 2002 года, когда сотрудниками компании Sun Microsystems, была опубликована привлекшая большое внимание статья [32], в которой термин «грид» использовался для кластерных конфигураций разных масштабов. После этого началась, - и по сей день продолжается - дискуссия о том, что такое кластер, а что — грид. Теперь так иногда называют и небольшую кластерную конфигурацию, собранную в одной стойке, и классические конструкции, объединяющие географически распределенные кластеры и другие ресурсы. Мы будем использовать термин «грид» только в этом последнем, «классическом» значении.

Три критерия того, что распределенная система является гридом, приведены в [6]: грид это такая система, которая координирует использование ресурсов при отсутствии централизованного управления этими ресурсами;

использует стандартные, открытые, универсальные протоколы и интерфейсы;

обеспечивает высококачественное обслуживание, с точки зрения таких, в частности, характеристик как время отклика, пропускная способность, доступность Пользуясь определением грида, приведенным в самом начале статьи, и этими критериями можно сразу сказать, что такие известные системы управления кластерами, как Sun Grid Engine или Portable Batch System (PBS) нельзя рассматривать как полномасштабный грид поскольку, среди прочего, они полностью контролируют отдельные компоненты системы (более подробное обсуждение см. в [6]).

Строго говоря, нельзя отнести к гриду и многие системы распределенных вычислений или удаленного запуска заданий даже, если они охватывают географически обширные области. Понятие «системы распределенных вычислений» более широкое и включает, в частности, более простые, чем грид системы запуска заданий на удаленных компьютерах и сбора результатов. Чтобы не утомлять читателя детальным анализом, обратимся опять к аналогии с энергосетями. Помимо крупных объединенных национальных и интернациональных энергосистем, с развитой инфраструктурой и строгой стандартизацией, существуют и другие производители электроэнергии, например:

солнечные электростанции (раскиданы по многим регионам мира, слабо связаны друг с другом, конструкция каждой очень индивидуальна, никаких общих стандартов);

локальные электросети на основе использования энергии ветра, приливов, рек и т.п. (унификация параметров только в пределах этой небольшой сети, упрощенная система подключения пользователей, оплаты за потребление энергии).

Упрощенно говоря, и многие системы распределенных вычислений аналогичны таким специфическим и/или локальным энергосетям и потому не являются гридом в точном смысле этого термина. Необходимо подчеркнуть, что сам по себе факт несоответствия таких систем критериям принадлежности к гриду, не означает, что они хуже (или лучше) грид-систем – просто они отвечают другим потребностям и в разных ситуациях могут оказаться более или менее подходящими для решения конкретных задач. Хорошее обсуждение этого вопроса можно найти в статье [7]. Приведем несколько примеров таких систем:

SETI@home (Search for Extra-Terrestrial Intelligence At Home - поиск внеземного разума на дому) — научный некоммерческий проект [8] распределённых вычислений, использующий свободные ресурсы на компьютерах добровольцев для поиска радиосигналов внеземного разума. Каждый пользователь персонального компьютера, подключённого к сети Интернет, может помочь проекту. Для этого на своем ПК требуется установить ПО, которое во время простоя (точнее, когда работает экранная заставка – screen saver) предоставляет ресурсы компьютера для анализа данных радиотелескопа Аресибо с целью поиска сигналов, которые можно интерпретировать как искусственные.

При этом компьютер запрашивает через Интернет у центрального сервера некоторую порцию данных, обрабатывает их с помощью установленного ПО и отсылает результаты серверу.

Важной особенностью проектов типа SETI@home является некритичность к времени, за которое может быть получен результат.

X-Com - система организации распределенных вычислений [7], построенная на основе модели ”ведущий/ведомые” и клиент-серверной архитектуры с двумя типами базовых компонентов:

сервер X-Com - центральная часть системы, отвечающая за разделение исходного набора данных на блоки, распределение заданий между узлами, координацию работы подчиненных узлов, контроль целостности результата расчета, сбор результата в единое целое.

узел X-Com - любая вычислительная единица (рабочая станция, узел кластера, виртуальная машина), на которой происходит расчет прикладной программы.

Отдельные блоки входных данных передаются от сервера на узлы, где и происходит расчет, а полученные на узлах результаты передаются обратно на сервер. Узлы отвечают за обработку блоков входных данных, запрос новых заданий для расчета от сервера, передачу результатов расчета на сервер. Взаимодействие между узлами и сервером в XCom происходят по протоколу HTTP, что позволяет подключать к системе практически любые вычислительные мощности, имеющие доступ к сети. Отметим, что для использования системы необходимо иметь учетные записи на всех узлах X-Com (но не требуется прав привилегированных пользователей). Любая прикладная программа, работающая в рамках системы X-Com, разбивается на две части: серверную и вычислительную. Серверная часть прикладной программы управляет формированием наборов данных для расчета на узлах; вычислительная часть представляет собой основной расчетный модуль для обработки наборов данных.

В отличие от проектов типа SETI@home, задания, запущенные посредством X-Com, выполняются не во время простоя компьютерного ресурса, а в соответствии с приоритетами учетной записи на данном ресурсе, от имени которой работает программное обеспечение этого узла X-Com.

OurGrid/MyGrid - система распределенных вычислений [9], принципы построения которой сходны с предыдущей. Основным отличием этой системы от XCom является то, что ПО, соответствующее и серверу, и узлу XCom, устанавливается на каждый компьютер. Таким образом, все компьютеры, входящие в систему, оказываются равноправными – каждый может работать и как сервер и как рабочий узел. Такие системы называются одноранговым (peer-to-peer) гридом. Мы не будем здесь подробно обсуждать эту весьма важную тему; интересующиеся могут ознакомиться со статьей, посвященной одноранговым системам распределенных вычислений в сборнике [10], и с подборкой статей на сайте проекта [9]. Этот пример показывает условность и классификаций, и названий – хотя эта система вряд ли удовлетворяет выше приведенным критериям грида (сформулированным одним из основоположников грид-технологий), однако это слово присутствует уже в самом названии системы.

Конечно, приведенные примеры далеко не исчерпывают множество типов систем распределенных вычислений – даже краткое рассмотрение всех типов и проектов в этой области увел бы нас далеко за рамки данного обзора. Для предварительного знакомства с разными проектами и тенденциями развития распределенных вычислений можно использовать, например, сайты [3].

В заключение этого обсуждения – что является и что не является гридом, - хочется сделать следующее замечание. Грид-технология справедливо имеет репутацию одной из важнейших технологий будущего. Поэтому исследовательские группы с весьма неопределенным и слабым отношением к собственно грид-технологиям имеют тенденцию добавлять это слово в названия своих проектов. Естественно, такая ситуация делает более трудной задачу точного определения и разграничения различных технологий и подходов.

Сложность ситуации усугубляется и тем, что коммерческие грид-решения зачастую называются совсем по-разному: в IBM и Computer Associates — вычислениями по требованию (On-demand Computing), в Hewlett-Packard — адаптивным предприятием (Adaptive Enterprise), в Sun Microsystems — стратегией N1, в Microsoft — Dynamic Systems Initiative. При всем различии этих названий цель решений примерно одинакова - создание условий для динамического распределения вычислительных ресурсов и ресурсов хранения. Общность между перечисленными подходами заключается еще и в том, что соответствующие им решения так или иначе реализуют архитектуры, ориентированные на сервисы (Service-Oriented Architecture, SOA). Об этой архитектуре мы подробнее поговорим в разделе 1.4. Но сначала остановимся на некоторых общих принципах архитектуры грид-систем.

1.4.3 Общие принципы архитектуры грид-систем В дальнейшем мы сосредоточимся на случае глобального грида (в соответствии с классификацией, приведенной в предыдущем разделе). Для такой системы важнейшим условием эффективной работы является обеспечение взаимодействия (интероперабельности) между различными платформами, языками и программными средами. В сетевой среде интероперабельность подразумевает работу по общим протоколам. Протоколы регламентируют взаимодействие элементов распределенной системы, а также структуру передаваемой информации.

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

Образно говоря, архитектура грид-систем имеет две «проекции» - протокольную и сервисную.

1.4.3.1 Структура (стек) протоколов глобального грида Общая структура глобального грида описывается в виде стека (набора уровней или слоев) протоколов [1]. В такой модели каждый уровень предназначен для решения узкого круга задач и используется для предоставления услуг для более высоких уровней. Верхние уровни ближе к пользователю и работают с наиболее абстрактными объектами, тогда как нижние уровни сильно зависят от физической реализации грид-ресурсов. Полезно иметь в виду, что эта структура аналогична сетевой модели OSI (Open Systems Interconnection Reference Model; модель взаимодействия открытых систем), - абстрактной модели для сетевых коммуникаций и разработки сетевых протоколов (см., например, [38]). В левой части рис. 2 показаны уровни стека грид-протоколов, а справа - четыре аналогичных им уровней модели OSI (всего в стеке OSI семь уровней). Итак, стек грид-протоколов включает:

1. аппаратный уровень (Fabric Layer) составляют протоколы, по которым соответствующие службы непосредственно работают с ресурсами;

2. связывающий уровень (Connectivity Layer) составляют протоколы, которые обеспечивают обмен данными между компонентами базового уровня и протоколы аутентификации;

3. ресурсный уровень (Resource Layer) – это ядро многоуровневой системы, протоколы которого взаимодействуют с ресурсами, используя унифицированный интерфейс и не различая архитектурные особенности конкретного ресурса;

4. коллективный (Collective Layer) уровень отвечает за координацию использования имеющихся ресурсов;

5. прикладной уровень (Application Layer) описывает пользовательские приложения, работающие в среде виртуальной организации; приложения функционируют, используя протоколы, определенные на нижележащих уровнях.

Рис.2 Стеки протоколов грид-системы и сетевой модели.

1.4.3.1.1 Аппаратный уровень: управление локальными ресурсами Аппаратный уровень обеспечивает доступ к распределенным ресурсам, необходимый протоколам более высокого уровня. Как уже неоднократно отмечалось, спектр возможных ресурсов весьма широк - это могут быть компьютеры, устройства массовой хранения данных, каталоги, сетевые ресурсы и т. п.

При этом ресурс может быть логической сущностью (например, распределенной файловой системой) или физической (например, кластером компьютеров). Реализация такого ресурса может включать внутренние протоколы (например, NFS (Network File System) или протокол управления кластером), однако подобные протоколы не включаются в стек грида. Компоненты аппаратного уровня реализуют локальные операции, специфические для каждого данного ресурса (логического или физического). Этот уровень по своим функциям аналогичен канальному уровню модели OSI и, по существу, представляет собой набор интерфейсов для управления локальными ресурсами.

1.4.3.1.2 Связывающий уровень: коммуникации и безопасность Коммуникационные протоколы связывающего уровня (Connectivity) должны обеспечивать надежный транспорт и маршрутизацию сообщений, а также присвоение имен объектам сети, а протоколы аутентификации этого уровня, основываясь на коммуникационных, предоставляют криптографические механизмы для идентификации и проверки подлинности пользователей и ресурсов. Инфраструктура поддержки включает централизованную выдачу сертификатов, управление сертификатами и ключами и т. д.

1.4.3.1.3 Ресурсный уровень: совместное использование ресурсов Ресурсный уровень с помощью коммуникационных и аутентификационных протоколов, входящих в нижележащий связывающий уровень, проводит согласование методов безопасности, инициализацию и мониторинг ресурсов, и управление ими. Для доступа к локальным ресурсам и дальнейшего управления ресурсный уровень вызывает соответствующие функции аппаратного уровня. Заметим, что протоколы ресурсного уровня предназначены исключительно для работы с локальными ресурсами, они не учитывают глобальное состояние системы. Этим занимается коллективный уровень, располагающийся выше.

Ресурсный уровень включает два основных класса протоколов:

информационные протоколы, предназначенные для получения информации о структуре и состоянии ресурса, его конфигурации, текущей загрузке и политике (то есть, условиях) предоставления ресурсов (например, стоимости их использования);

протоколы управления, обеспечивающие согласованность доступа к разделяемому ресурсу и определяющие необходимые операции, которые ресурс должен выполнить (скажем, инициализация процесса или доступ к данным).

1.4.3.1.4 Коллективный уровень: координация ресурсов Протоколы коллективного уровня отвечают за взаимодействие всех элементов пула ресурсов, что и отражено в самом названии. В качестве примера глобальных функций и сервисов, реализуемых протоколами этого уровня, можно назвать службу каталогов, распределение ресурсов, планирование и брокерские услуги, службы мониторинга, диагностики, репликации данных, коллективной авторизации.

1.4.3.1.5 Прикладной уровень: запуск приложений в грид-среду Этот высший уровень грид-архитектуры включает пользовательские приложения, которые исполняются в среде объединенных ресурсов. В процессе исполнения приложения используют протоколы нижележащих уровней, обеспечивающие доступ к необходимым службам, а также прикладные программные интерфейсы (Application Programming Interface – API), соответствующие данным протоколам.

Приложения могут вызываться через достаточно сложные оболочки и библиотеки. Эти оболочки сами могут определять протоколы, сервисы и прикладные программные интерфейсы, однако подобные надстройки не относятся к фундаментальным протоколам и сервисам, определяющим архитектуру грид-систем.

1.4.3.2 Архитектура сервисов распределенных систем и технологии ее На начальном этапе своего развития распределенные приложения взаимодействовали с помощью частных, специально разработанных (проприетарных) протоколов, а системные администраторы использовали оригинальные методы, чтобы ими управлять. Как уже отмечалось, за годы становления и развития этой технологии были выработаны - с различной степенью успеха - многочисленные стандарты, чтобы ослабить затраты на развертывание и обслуживание таких систем. Сегодня наиболее предпочтительными подходами к построению распределенных систем считаются сервисно-ориентированная архитектура (Service Oriented Architecture, SOA), технология веб-сервисов, и гридстандарты (в первую очередь - Открытая архитектура грид-сервисов (Open Grid Services Architecture, OGSA)). Однако, свои преимущества имеет и объектно-ориентированный подход. Ниже мы даем краткое общее описание этих подходов и соотношений между ними. При написании этого раздела существенно использовалась статья [28].

1.4.3.2.1 Сервисно-ориентированная архитектура (SOA) распределенных При рассмотрении термина «сервисно-ориентированная архитектура», полезно предварительно определить ключевые термины:

Архитектура это формальное описание системы, определяющее ее цели, функции, внешне видимые свойства, и интерфейсы. Она также включает описание внутренних компонентов системы и их отношений, наряду с принципами, управляющими ее дизайном, функционированием и возможной последующей Сервис (служба) - программный компонент, к которому можно удаленно обратиться посредством компьютерной сети, и предоставляющая некоторые функциональные возможности запрашивающей стороне.

Сервисно-ориентированная архитектура (service-oriented architecture, SOA) является основой построения надежных распределенных систем, которые в качестве услуг предоставляют функциональные возможности, с дополнительным акцентом на слабые связи между взаимодействующими сервисами.

Таким образом, SOA это архитектурный стиль, который подчеркивает реализацию компонентов системы как модульных сервисов, которые могут быть найдены и использованы клиентами. Вообще говоря, сервисы имеют следующие характеристики:

Сервисы могут быть полезными каждый сам по себе, или они могут быть объединены, чтобы предоставить единый высокоуровневый сервис. Среди других достоинств, это позволяет многократно использовать уже существующие функциональные возможности.

Сервис общаются со своими клиентами, обмениваясь сообщениями: фактически, сервисы и различаются/идентифицируются в соответствии с совокупностью сообщений, которые они могут принять и ответов, которые они могут направить запрашивающей стороне.

Сервис может участвовать в таких процессах обработки запросов, при которых порядок, в котором сообщения посылаются и принимаются, влияет на результат операций, выполненных сервисом. Это называется "сервисной хореографией" (service choreography) [5].

Сервис может быть полностью независимым, или может зависеть от существования других сервисов, или каких-либо ресурсов, например, баз данных.

Простейшим примером первого типа является сервис, осуществляющий возведение в квадрат числа, посланного в запросе; примером второго типа является сервис, осуществляющий конвертацию валют – для этого ему необходим текущий Сервисы предоставляют информацию о своих возможностях, интерфейсах, политике и поддерживаемых протоколах связи. Детали реализации, например, язык программирования и платформа, на которой он реализован, не нужны клиентам для направления запросов и не предоставляются.

Рис. 3 иллюстрирует простой цикл взаимодействия сервисов, который начинается с того, что данный сервис оповещает о своем существовании и свойствах посредством известного сервиса регистрации (1), свойства и способы взаимодействия с котоорым должны быть заранее известны клиентам.

Потенциальный клиент, который может быть другим сервисом (или человеком), делает запрос в сервис регистрации (2), чтобы найти сервис, который удовлетворяет его потребностям. Регистрационный сервис возвращает (возможно пустой) список подходящих сервисов; клиент выбирает один из них и передает ему запрос, используя любой взаимно распознаваемый протокол (3). В этом примере, сервис отвечает (4), передавая или результат требуемой операции или сообщение об ошибке. На рисунке показан самый простой случай. В реальной установке процесс может быть значительно более сложным. Например, данный сервис может поддержать только HTTPS протокол, обслуживать только зарегистрированных пользователей, предлагать различные уровни сервиса различным пользователям, или требовать оплаты за использование.

Представленный иллюстративный пример соответствует простому синхронному, двунаправленному способу обмена сообщениями, в то время как в реальной жизни взаимодействие может быть односторонним, или ответ может быть получен не от того сервиса, которому клиент посылал запрос, но от некоторого другого, которому он был передан для завершения обработки.

1.4.3.2.2 Принцип слабой связи В определение SOA входит понятие слабой связи сервисов. Этот термин подразумевает, что взаимодействующие программные компоненты имеет минимальное знание друг о друге: они находят информацию, которая им нужна для взаимодействия непосредственно перед взаимодействием. Например, узнав о существовании сервиса, клиент может выяснить его возможности, условия предоставления услуг, его местоположение, его интерфейсы и поддерживаемые протоколы. Как только эти сведения получены, клиент может сразу же обратиться к сервису, используя любой взаимоприемлемый протокол.

Достоинствами слабой связи являются:

Гибкость: сервис может быть расположен на любом сервере, а при необходимости - перемещен. Пока ссылка на этот сервис есть в службе регистрации, предполагаемые клиенты будут в состоянии найти и использовать его.

Масшабируемость: функциональные возможности сервиса могут быть расширены или сужены, поскольку при этом описание сервиса динамически меняется и, соответственно, изменяются и запросы.

Возможность модификации реализации: при условии, что оригинальные интерфейсы сохраняются, реализация сервиса может быть обновлена без сбоев в обслуживании клиентов.

Отказоустойчивость: Если возникают проблемы в работе сервера, программного компонента или сегмента сети, или сервис становится недоступным по любой другой причине, клиенты могут сделать запрос к службе регистрации для обнаружения другого сервиса, который предоставляет требуемые услуги.

Ясно, все эти преимущества имеют большое значение в динамической распределенной среде. Однако, необходимо отметить, что при конкретных реализациях сервисов далеко не всегда удается достигнуть полной независимости клиентов от свойств сервисов. В реальности термин «слабосвязанный» является относительным и степень зависимости клиента и сервиса, при которой их можно назвать сильносвязанными, в значительной степени является субъективным решением.

1.4.3.2.3 Понятие состояния сервисов и сервисы без состояний Одними из ключевых понятий в теории слабосвязанных сервисов являются понятия «состояния сервиса» и «сервис без состояний». Дело в том, что преимущества слабой связи вытекают из факта, что клиент может использовать любой сервис, который способен выполнить его запрос. Если выбор клиента ограничен единственным сервисом, тогда преимущества слабой связи существенно уменьшаются. В простом случае калькулятора или сервиса отслеживания курса акций является очевидным, что, как только клиент запросил и получил информацию, транзакция закончена, и у клиента нет никакой особой нужды при последующих запросах на аналогичные услуги обращаться к тому же самому сервису. С этой точки зрения, клиент и сервис связаны слабо.

Однако, для более сложных запросов, которые требуют нескольких шагов, дизайн сервиса мог бы быть таким, что сервис сохраняет в своей локальной памяти некоторую информацию ("состояние") о первом шаге, предполагая использовать ее, когда клиент входит с ним в контакт на следующем шаге. В этом случае, сервис обладает состоянием (stateful service), и клиент должен возвратиться к тому же самому сервису при следующем шаге. Это может привести к задержкам, если много клиентов используют один и тот же сервис или даже к отказу в обслуживании, если узел, являющийся главным сервисом, аварийно прекращает работу между шагами.

Более правильный подход при разработке сервисов основан на «сервисах без состояний»

(stateless). Это подразумевает что при многошаговой обработке запросов:

В конце каждого промежуточного шага сервис должно возвратить клиенту достаточную информацию о состоянии, чтобы дать возможность любому сервису с соотвествующими свойствами идентифицировать и продолжить обслуживание.

Клиент должен передавать информацию о состоянии любому сервису на следующем шаге обработки запроса.

Выбранный сервис должен быть в состоянии принимать и обрабатывать информацию о состоянии, поставляемую клиентом, независимо от того обрабатывал ли он сам запрос на предыдущем шаге, или это делал другой сервис.

Рис. 4 показывает клиента, делающего запрос, для обработки которого требуется три шага и несколько сервисов, каждый из которого может быть способен к обработке любой части или всего запроса.

Рис. 4 Мношаговое взаимодействие клиента и сервисов Сервис, который обрабатывает шаг 1, сохраняет детали обработки текущего запроса в базе данных, и возвращает запрашиваемую информацию клиенту, наряду с идентификатором запроса. Клиент может запросить подтверждение со стороны пользователя перед передачей этого идентификатора другому сервису, который использует его, чтобы отыскать информацию о состоянии в базе данных и инициализирует шаг 2. Этот сервис затем обновляет базу данных и возвращает дополнительную информацию клиенту.

Наконец, клиент передает операционный идентификатор третьему сервису вместе с запросом на окончание всей обработки.

Большинство нетривиальных приложений требует доступа к некоторому количеству информации о состоянии, и вопрос не о том, должны ли состояния существовать, а о том, где они должны храниться. В подходе, описанном выше, состояние обработки запроса отделено от сервиса, который эту обработку осуществляет – обеспечивая, тем самым, слабую связь сервисов и клиента. Для того чтобы максимально уменьшить объем информации о состояниях, которой обмениваются клиент и сервисы, существенные детали об обработке запроса сохраняются в базе данных. При все участвующие сервисы должны быть в состоянии обратиться к базе данных и получить требуемую информации на основе идентификационного номера клиента/запроса, который можно легко передать от клиента сервисам.

1.4.3.2.4 Веб-сервисы Большинство людей знакомо с доступом во всемирную паутину через веб-браузеры, которые обеспечивают ориентируемый на пользователя интерфейс к информации (вебстраницам) и к ориентированным на человека сервисам типа сетевых аукционов и розничных продаж (интернет-магазинам). Когда пользователь запрашивает веб-страницу, запрос обрабатывается удаленным веб-сервером, который возвращает информацию на языке разметки гипертекста (HTML). Это позволяет браузеру представить ее используя соответствующие шрифты, цвета и изображения, все то, что делает восприятие человеком этой информации более простым и удобным.

Веб-сервисы (или веб-службы) – это распределенные программные компоненты, идентифицируемые своим сетевым адресом, интерфейс которых описан на специальном «диалекте» языка XML (eXtensible Markup Language), а именно WSDL (Web Service Description Language). Другие программные системы могут взаимодействовать с вебсервисами согласно этому описанию посредством сообщений, основанных на другом «диалекте» XML - SOAP, и передаваемых с помощью интернет-протоколов (обзор технологий веб-сервисов можно найти, например, в [5]). В интернет-магазинах, например, веб-сервисы, которые могут быть реализованы на географически далеко удаленных друг от друга серверах, могут обеспечивать ведение счетов, контроль наличия товаров на складе, составление «корзины» покупателя и службу авторизации кредитной карты.

Каждая из этих функций может быть многократно вызвана в ходе одной покупки.

Веб-сервисы предоставляют детальную информацию об их функциях и о интерфейсах, но не о деталях реализации и платформе; таким образом клиент и сервис, которые поддерживают общие протоколы коммуникации, могут взаимодействовать независимо от платформ, на которых они выполняются или языков программирования, на которых они написаны. Это делает веб-сервисы особенно подходящими для распределенной гетерогенной среды.

Ключевыми спецификациями, используемыми веб-сервисами являются:

XML - язык разметки для того, чтобы обмениваться структурированными данными;

SOAP – основанный на XML протокол для спецификации содержания сообщений, служебной «обертывающей» информации («конверт сообщения») и информации, необходимой для правильной обработки сообщений;

WSDL (Web Services Description Language - язык описания веб-сервис) – основанный на XML, используемый для описания атрибутов, интерфейсов и других свойств веб-сервис. Документ WSDL используется потенциальным клиентом, чтобы узнать о сервисе и способах обращения к нему.

Хотя веб-сервисы, вообще говоря, могут использовать разные транспортные протоколы, и даже могут предлагать клиентам выбор, самым распространенным является SOAP поверх протоколов HTTP или HTTPS. Это важно поскольку использование HTTP и HTTPS обычно не вызывает проблем с обходом систем сетевой защиты в организациях, которые разрешают двунаправленный трафик HTTP.

1.4.3.2.5 Веб-сервисы и SOA SOA и веб-сервисы являются «ортогональными» понятиями: сервисная ориентация – это архитектурный стиль, а веб-сервисы - технология выполнения. Они, конечно, могут использоваться совместно – как это часто и случается, но они взаимно независимы.

Например, хотя принято считать, что SOA предназначена для распределенных систем, она может использоваться и для одиночных компьютеров, когда сервис соответствует индивидуальным процессам с четкими интерфейсами, которые взаимодействуют используя внутренние каналы связи, или для кластера персональных компьютеров, где они могли бы общаться посредством высокоскоростной локальной сети.

Аналогично, веб-сервисы хорошо подходят в качестве строительных блоков SOA-среды, но в их определении нет ничего, что обязательно требует воплощение принципов SOA.

Хотя отсутствие состояний зачастую рассматривается как ключевая характеристика вебсервис, нет никаких технических причин, по которым они обязательно должны быть без состояний – это определяется выбором разработчика и архитектурным стилем среды, в которой сервис должен работать.

1.4.3.2.6 Веб-сервисы и виртуализация Легкость, с которой веб-сервисы могут быть реализованы и возможность обращаться к ним локально или удаленно и независимо от платформы на которой работает клиент, привела к тому, что они были широко приняты администраторами систем как «агенты виртуализации», которые обеспечивают общие интерфейсы управления к различным ресурсам. Например, веб-сервиса может быть спроектирована так, чтобы "представлять" специфическое устройство или обычное приложение, принимая запросы управления и контроля через стандартизированные интерфейсы, с ресурсом общаясь посредством его «родного» интерфейса, и возвращая результат запрашивающей стороне опять в стандартном формате. Рис. 5 иллюстрирует, каким образом единая консоль может управлять совокупностью разнообразных ресурсов посредством уровня виртуализации на основе веб-сервис, каждая из которых предоставляет консоли стандартизированные интерфейсы для взаимодействия со связанным с ней ресурсом.

Рис.5 Виртуализация ресурсов с помощью Веб-сервисов 1.4.3.2.7 Сервисно-ориентированный грид Работа грид-систем опирается на программное обеспечение промежуточного уровня:

программные компоненты и протоколы, которые обеспечивают требуемый контролируемый доступ к ресурсам. На первом этапе своего существования грид-системы строились или на основе специально разработанных общедоступных компонент или на основе закрытых (проприетарных) технологий. Хотя различные общественные и коммерческие решения были успешны в своих областях применения грида, каждое со своими сильными и слабыми сторонами, они имели ограниченный потенциал как основы для грида нового поколения, который должен быть масштабируемым и интероперабельным, чтобы удовлетворять потребности широкомасштабных научных и производственных проектов.

В последние годы стало ясно, что есть значительное перекрытие между целями вычислительного грида и преимуществ сред, основанных на SOA и веб-сервисах. Быстрый прогресс в технологии веб-сервисов и разработке соответствующих стандартов обеспечили эволюционный путь от жесткой и узко-направленной архитектуры гридсистем первого поколения к стандартизированным, сервис-ориентированным гридам, гарантирующим стабильно-высокое качество обслуживания пользователей (грид промышленного уровня).

На рис. 6 показана схематично представлен простой сервисно-ориентированный грид, в котором сервисы используется и для виртуализации ресурсов, и для обеспечения других функциональных возможностей грида.

Рис. 6 Упрощенная схема сервисно-ориентированного грида На схеме показана единая консоль и для запуска заданий в грид-среду, и для управления грид-ресурсами. Программное обеспечение интерфейса пользователя (консоли) обращается к сервису регистрации, чтобы получить информацию о существующих гридресурсах. Затем пользователь посредством консоли входит в контакт с сервисами, «представляющими» (виртуализующими) каждый ресурс, чтобы запросить периодическое получение данных о работе ресурсов и получение извещений о существенных изменениях в их состоянии (например, если ресурс становится недоступным или сильно загруженным).

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

Если подходящие ресурсы доступны, планировщик выбирает наилучшую доступную совокупность ресурсов и передает информацию о их сервису приложения с запросом на начало выполнения. В противном случае планировщик ставит задание в очередь и выполняет его, когда необходимые ресурсы становятся доступными. Когда выполнение задания заканчивается, сервис приложения сообщает о результате планировщику, который извещает об этом сервис запуска заданий. Сервис запуска заданий, в свою очередь, уведомляет пользователя.

Отметим, что этот пример для ясности сильно упрощен: функционирование реального грида промышленного уровня является намного более сложным чем показано на схеме.

Главным результатом его работы должна быть высокая степень автоматизации и оптимизации использовании ресурсов в рамках грид-среды.

1.4.3.2.8 Open Grid Services Architecture (OGSA) Конвергенция SOA и вычислительных грид-систем воплощена Глобальным грид-форумом (Global Grid Forum, GGF) в Открытой архитектуре грид-сервисов (Open Grid services Architecture, OGSA). Основной документ [34], фиксирующий архитектуру OGSA, описывает общие принципы построения сервисно-ориентированного грида в терминах необходимых функциональных возможностей, например, выполнение заданий, управление ресурсами и данными, обеспечение безопасности. Основной целью этого и других документов, посвященных OGSA (см. [23]), является стандартизация интерфейсов и поведения основного (базового) набора грид-сервисов, чтобы они могли взаимодействовать как друг с другом, так и с грид-приложениями независимо от конкретных реализаций таких грид-сервисов. OGSA, в частности, определяет стандартные механизмы для создания, именования и обнаружения постоянных и временных экземпляров сервисов;

обеспечивает прозрачность местонахождения и взаимодействия по различным протоколам для экземпляров сервисов;

описывает общую модель ресурсов, которая представляет собой абстрактное представление как физических ресурсов (таких как процессоры, процессы, диски и файловые системы), так и логических (экземпляров сервисов).

Для понимания терминологии необходимо отметить, что в рамках OGSA различают общее понятие сервиса и понятие экземпляра сервиса. Сервис - это абстрактное понятие, он определяется своим интерфейсом и способом взаимодействия с другими сервисами. При этом не имеется в виду, что сервис обязательно как-то реализован и реально функционирует. Напротив, реально функционирующий сервис является экземпляром того или иного сервиса.

При разработке OGSA учитывался ряд требований, полученных в результате анализа различных сценариев использования грид-систем, в том числе:

интероперабельность (виртуализация ресурсов, общие способы управления и обнаружение ресурсов, стандартизация протоколов);

разделяемый доступ к ресурсам;

оптимизация выделения ресурсов;

возможность запуска заданий на удаленных вычислителях;

возможность манипуляции данными;

снижение стоимости администрирования больших гетерогенных систем;

безопасность (аутентификация и авторизация, возможность интеграции с различными системами безопасности, делегирование прав) гарантии качества обслуживания;

простота использования и расширяемость (возможность расширения спектра масштабируемость (отсутствие узких мест, препятствующих наращиванию Кратко упомянем некоторые положения Открытой архитектуры грид-сервисов.

Грид-сервисы в OGSA. OGSA определяет грид-сервис как веб-сервис, который предоставляет набор корректно определенных интерфейсов, определенных на языке WSDL, и следует специфическим конвенциям для их создания и композиции сложных распределенных систем. Интерфейсы определяют способы обнаружения, динамического создания службы, управления жизненным циклом, уведомления, управляемости.

Конвенции определяют способ именования и возможность модернизации грид-служб.

OGSA также определяет механизмы обновления «знаний» клиента о службе, в том числе, о поддерживаемых ею операциях и сетевых протоколах, которые клиент может использовать для связи с этой службой.

В отличие от традиционных веб-сервисов, которые позволяют обнаруживать и инициировать только постоянные (persistent) службы, OGSA также предусматривает поддержку временных (transient) экземпляров сервисов, инициируемых и завершаемых динамически (например, временный экземпляр службы может быть создан для обращения к хранилищу данных, для резервирования сетевых или процессорных ресурсов).

Таким образом, грид-сервис — это (возможно временная) служба на базе гридпротоколов, описанная посредством WSDL. Каждый интерфейс грид-службы определяет набор операций, которые инициируются путем передачи соответствующей последовательности сообщений.

OGSA описывает как создается грид-служба, как называется, как определено ее время жизни и т.д. OGSA предписывает базовое поведение, но не определяет конфигурацию службы и ее развертывание в грид-инфраструктуре. Другими словами, OGSA не касается вопросов реализации, парадигмы программирования, конкретных языков, механизмов и инструментальных средств реализации или операционной среды. Это позволяет модели грид-служб абстрагироваться от особенностей программного и аппаратного обеспечения, предлагая лишь набор стандартных интерфейсов высокого уровня.

В частности, согласно OGSA, любой грид-сервис должен реализовывать тип GridService, служащий основным определением интерфейсов в OGSA. Он аналогичен базовому классу Object в объектно-ориентированных языках в том, что он инкапсулирует базовое поведение компонентной модели. В качестве базовых средств коммуникации GridService предусматривает передачу сообщений, ориентированных на документы, а также механизм RPC (remote procedure call — «удаленный вызов процедур»). При передаче сообщений входными и выходными объектами являются XML-документы, в то время как RPC использует более строго определенные API, но зато обеспечивает более высокую производительность.

Дескрипторы Grid-сервисов. Экземпляры служб в рамках OGSA могут создаваться с помощью операции CreateService или вручную, и уничтожаться динамически, когда истекает время, на которое она создавалась, или в любой момент с помощью операции Destroy. Операция CreateService возвращает дескриптор грид-службы (Grid Service Handle, GSH), который представляет собой глобально уникальный указатель (URL), определяющий имя экземпляра службы и отличающий его от других экземпляров. GSH не несет в себе всей информации, достаточной для того, чтобы клиент мог напрямую взаимодействовать с экземпляром службы. Поэтому GSH необходимо отобразить на ссылку на грид-службу (Grid Service Reference, GSR), которая содержит информацию, необходимую клиенту для связи со службой. Такая двухступенчатая структура позволяет GSH оставаться неизменной в течение всего срока существования экземпляра гридсервиса, в то время как GSR может измениться (например, если служба «переносится» на другой компьютер). Если такое происходит, клиент должен отобразить GSH службы на новую ссылку.

Модель уведомлений. Эта часть OGSA описывает доставку сообщений о наборах данных о структуре службы и об изменениях ее состояния от источника адресату. Источник уведомлений — это экземпляр грид-службы, который реализует интерфейс (portType в терминологии языка WSDL) NotificationSource и посылает сообщение с уведомлением.

Адресат — экземпляр грид-службы, который реализует интерфейс NotificationSink и получает сообщение с уведомлением. Чтобы инициировать уведомление от конкретной грид-службы, пользователь вызывает операцию subscribe в соответствии с интерфейсом источника уведомления, передавая ему дескриптор GSH службы-получателя уведомления.

В любом случае, подход на основе OGSA предполагает использование стандартов, гарантирующих функциональную совместимость различных реализаций грид-систем. По мере того как спецификации OGSA будут публиковаться и становиться зрелыми (см.

Дорожную карту OGSA [35]), ожидается, что программные средства промежуточного уровня различных поставщиков будут обладать OGSA-совместимыми функциональными возможностями и интерфейсами. В этом случае разработчики грид-систем смогут объединять компоненты различных поставщиков ПО для построения масштабируемых, функционально-совместимых (интероперабельных), надежных и легко управляемых гридсистем.

Важно отметить, что при определении рабочими группами GGF/OGF новых стандартов, OGSA будет использовать, как уже отмечалось в разделе 1.3.3, существующие и появляющиеся стандарты из всех сегментов веб-сервисного сообщества, чтобы обеспечить потребности различных категорий пользователей. Например, на первом этапе спецификации OGSA методы управления грид-системами определяются на основе вебсервисного стандарта WSDM (Web Services Distributed Management) [40] международной организации OASIS [36], с возможностью использования также альтернативного набора спецификаций, основанного на стандарте ассоциации DMTF [37]. А вот стандарты WSRF (Web Services Resource Framework), которые определяют способы представления и управления ресурсами/сервисами с состоянием, и WS-Notification, который обеспечивает общий механизм извещений и подписки на уведомления о событиях, были с самого начала разработаны и утверждены в качестве стандарта OASIS для нужд построения грид-систем (более подробно об этих стандартах – в следующем разделе).

Краткий обзор OGSA можно найти в [42].

1.4.3.2.9 Грид-спецификации WSRF (Web Services Resource Framework) и WSNotification Цель, преследуемая при создании этих спецификаций, заключается в сближении OGSA с веб-сервисами и SOA. С помощью средств, соответствующих этим спецификациям, может быть реализован подход к моделированию и управлению состоянием в контексте вебсервисов. Иными словами, делается попытка реализовать «состояние» — именно то, что отличает грид-сервисы от веб-сервисов. Подобный подход позволяет пользователям, находясь в контексте веб-сервисов, контролировать и изменять состояние доступных им ресурсов.

WSRF включает следующие спецификации 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 - организация и категоризация тем для подписки.

Этот список дает представление о наборе функциональностей, для которых определяются стандарты этими спецификациями. Поскольку это чисто технические документы, подробно мы их не описываем. Хорошее введение в «идеологию» WSRF можно найти в статьях [43].

1.4.3.2.10 Другие грид-стандарты Заметим, что некоторые грид-проекты, не могут дожидаться завершения работ над WSRF и пользуются альтернативными спецификациями, например, Basic Profile (BP1.0) от WSInteroperability, Web Services Grid Application Framework (WS-GAF, North-East Regional eScience Centre, www.neresc.ac.uk/ws-gaf) и WS-I+ (Open Middleware Infrastructure Institute, www.omii.ac.uk).

WS-Eventing. Предложенный Microsoft, BEA, Tibco, Sun и CA стандарт WS-Eventing обеспечивает общий метод взаимодействия веб-сервисов. Объявленная цель создания WSEventing заключается в поддержке обмена данными о событиях по схеме подписки/публикации. Формальная модель WS-Eventing строится на основе схемы XML, спецификации WSDL и поддерживает SOAP. В нем описывается протокол, позволяющий веб-сервисам предоставлять подписку «на себя» и подписываться на другие сервисы. Как указано в разд. 1.3.2, сейчас наметился процесс сближения этого стандарта с WSRF/WS-N.

Стандарт безопасности. Добавим еще, что фактическим стандартом безопасности в грид является Grid Security Infrastructure (GSI). Подробнее о нем будет рассказано во части II. В некоторых проектах исследуются альтернативные решения, которые могут повлиять на стандарты GSI. Например, в рамках проекта GridShib (http://grid.ncsa.uiuc.edu/GridShib) создаются новые механизмы и стратегии распределенной аутентификации, позволяющие виртуальным организациям в грид интегрироваться с традиционной инфраструктурой корпоративной безопасности.

В заключение рассказа о стандартизующих спецификациях, хочется подчеркнуть, что если кто-то создает свою грид-систему, совсем не обязательно следовать каким-либо спецификациям. Более того, вполне может оказаться, что созданная таким образом оригинальная система будет работать даже эффективнее созданной по спецификациям – всегда платой за универсальность (интероперабильность) является пониженная производительность. Однако, необходимо четко понимать, что при этом не удастся развивать такую систему за счет интеграции сторонних продуктов (из-за несовместимости) и если возникнет необходимость «выхода во внешний мир», то есть включения такой грид-системы в качестве сегмента во внешнюю грид-среду, - это может потребовать значительных усилий, а показатели эффективности взаимодействия «с внешним миром» могут оказаться весьма низкими.

Обсуждение достоинств и недостатков (в том числе, вопросов производительности) систем на основе веб-сервисных технологий мы продолжим в следующем разделе.

1.4.3.2.11 Сервисно-ориентированные и объектно-ориентированные системы:

сходство и различия, преимущества и недостатки Выбор типа связи между компонентами распределенной системы - жесткий или свободный, - которому отдается предпочтение, соответственно, в объектноориентированном и сервисно-ориентированном подходах, интенсивно обсуждается специалистами и практиками, в том числе на ряде интернет-форумов. Мы сосредоточимся на различие этих подходов с точки зрения крупномасштабных распределенных гридсистем.

Традиционно, в распределенных объектно-ориентированных системах типа CORBA [45] и DCOM [46] программные компоненты с определенными функциональными возможностями рассматривались как распределенные объекты. В этой парадигме, клиенты имеют статическое знание об объектах, экземпляры объектов инкапсулируют данные, и взаимодействие происходит посредством синхронного вызова удаленных методов с использованием протоколов специального назначения. Это подразумевает, что взаимодействующие объекты являются сильно связанными, с жестко регламентированными методами запросов и ответов. В этой парадигме, объект с инкапсулированными данными является центральной фигурой. Объекты имеют тенденцию быть «мелкозернистым» отображением чего-то реально существующего.

Другими словами, если речь идет о какой-либо сравнительно сложной системе, объекты имеют тенденцию отображать не ее общие свойства, а каждую из ее небольших частей, подсистем.

С другой стороны, в сервисно-ориентированной среде сервисы слабо связаны: они взаимодействуют с помощью обменами сообщениями, которые могут быть односторонними, синхронными или асинхронными. Этот подход стимулирует такой дизайн систем, в которых запросы и ответы не обязательно обрабатываются одним и тем же набором взаимодействующих компонент. В качестве примера, рассмотрим клиента, который обращается к сервису А, чтобы инициализировать заказ. Сервис A может проверить наличие товара, обращаясь к сервису Б, а сервис Б возможно обратится к сервису С, который формирует заявку и отправляет ее клиенту для подтверждения. Это простой пример, который иллюстрирует понятие свободной связи: запрос может быть направлен одному сервису, а ответ получен от другого. В этой парадигме, сервис является центральной фигурой. Вообще говоря, сервисы имеют тенденцию быть более «крупнозернистым» (общим, грубым) отображением реальных сущностей, чем объекты.

При текущей тенденции строить распределенные системы только на основе веб-сервисов, в подходе, основанном на распределенных объектах, зачастую видят одни недостатки.

Это, однако, не так: достоинствами объектно-ориентированного подхода является зрелость существующих реализаций, эффективное взаимодействие компонент, модель инкапсулирования состояний и поведения объектов и это хорошо подходит для некоторым приложениям. Поэтому объектно-ориентированные распределенные технологии получили распространение в индустриальных приложениях – для распределенных систем, например, финансовых учреждений, организаций здравоохранения, телекоммуникационных предприятий.

С другой стороны, хотя ясно, что SOA и веб-сервисы будут главной линией развития в обозримом будущем, нужно понимать, что они все еще имеют множество серьезных проблем, которые еще надо преодолеть, включая:

пока все еще незрелую технологию, разночтения и некоторый беспорядок в области стандартов, существенные «накладные расходы» при работе Веб-сервисов, связанные сериализацией/десериализацией (преобразованием программного кода в XMLтекст и обратно) и анализом SOAP-сообщений и документов XML при каждом обмене сообщениями.

Особенно существенным является последний недостаток, поскольку он негативным образом сказывается на производительности распределенных систем. Как всегда, за универсальность надо платить падением эффективности! Однако платформонезависимость является столь важным доводом в пользу SOA и Веб-сервисов, что большинство крупных IT-фирм усиленно продвигают на рынок эту архитектуру и технологию.

К сожалению, наиболее известные в рамках объектно-ориетированного подхода спецификации CORBA обеспечивая хорошую производительность построенных на их основе реализаций, также несвободны от недостатков. Главный из них – чрезмерная громоздкость и недостаточная четкость этих спецификаций. Поэтому ряд существовавших грид-проектов на основе CORBA не получили значительного развития.

Сравнительно недавно появилось новое поколение ППО на основе объектнораспределенных технологий – ICE (Internet Communications Engine) [47]. Оно сочетает (и даже превосходит) высокую производительность CORBA с сравнительной простотой спецификаций, удобным языком описания интерфейсов, поддержкой основных языков программирования, развитым набором средств для построения распределенных систем и с рядом других достоинств.

Важно отметить, что, в то время как каждый архитектурный стиль имеет присущие ему достоинства и недостатки (в значительной степени преимущество того или иного стиля зависит от конкретной задачи, для которой они используются), оба стиля обеспечивают такие важные свойства, как:

модульность, что, в свою очередь, позволяет наращивать функциональные возможности без коренной переделки всей возможность построения крупных систем из более мелких;

масштабируемость (увеличение числа однотипных компонент системы, например, вычислительных ресурсов грид-системы);

устойчивость в работе;

способности скрыть детали выполнения запросов за четкими интерфейсами;

Эти свойства позволяют создавать хорошо организованные распределенные среды для выполнения прикладных заданий.

1.4.3.2.12 Разработка систем на основе SOA Как мы видели, сервисная ориентация следует таким общим программным принципам архитектуры, как инкапсуляция, модульность и отделение интерфейсов от их реализации.