ГОСТ Р 55768-2013 Информационная технология. Модель открытой Грид-системы. Основные положения

ГОСТ Р 55768-2013

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология

МОДЕЛЬ ОТКРЫТОЙ ГРИД-СИСТЕМЫ

Основные положения

Information technology. Model of the open grid-system. General

ОКС 35.020

Дата введения 2015-01-01

Предисловие

1 РАЗРАБОТАН Федеральным государственным бюджетным учреждением науки "Институт радиотехники и электроники им.В.А.Котельникова РАН" (ИРЭ им.В.А.Котельникова РАН), Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр"

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 8 ноября 2013 г. N 1546-ст

4 ВВЕДЕН ВПЕРВЫЕ

5 ПЕРЕИЗДАНИЕ. Ноябрь 2018 г.

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

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

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

В этом стандарте представлена модель Сервис-ориентированной архитектуры открытых Грид-систем (СОАОГС), которая удовлетворяет потребность в стандартизации, определяя набор основных характеристик (возможностей) и поведения, касающихся ключевых проблем в области Грид-систем. Наличие модели позволяет найти общий язык между разработчиками, поставщиками и пользователями Грид-систем и их компонентов. Данный стандарт разработан на основе стандарта международной организации OpenGridForum, специализирующейся на разработке стандартов Грид-систем, GFD-1-080* "Архитектура сервисов открытых Грид-систем" Версия 1.5. Представленная модель является трехмерной. Она включает в себя по одной оси свойства открытой Грид-системы, соответствующие требованиям к открытой Грид-системе, по другой оси - сервисы, необходимые для обеспечения этих свойств и, наконец по третьей оси - уровни интероперабельности: технический, семантический и организационный.

________________

* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - .

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

1 Область применения

1.1 Настоящий стандарт определяет требования и сферу важных характеристик, необходимых для поддержки Грид-систем и приложений как в электронной науке, так и в электронном бизнесе. Описанные характеристики включают в себя:

- Управление исполнением,

- Данные,

- Управление ресурсами,

- Безопасность,

- Самоуправление,

- Информацию.

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

1.2 В настоящий стандарт включены абстрактные определения, составляющие набор требований, которым должна удовлетворять СОАОГС.

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

1.3 Настоящий стандарт устанавливает согласованный набор характеристик, которые в совокупности определяют СОАОГС. Эти характеристики являются трансформацией набора требований.

Сначала описаны сервисы инфраструктуры и предположения, которые сдерживают развитие структуры СОАОГС, в частности приведено объяснение, как строится основа СОАОГС и как она вносит свой вклад в развитие растущего набора технических спецификаций, которые образуют новые архитектуры web-сервисов. Затем дано уточнение необходимых функциональных характеристик в следующих областях: Управление исполнением, Данные, Управление ресурсами, Безопасность, Самоуправление, Информация.

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ 1.1 Межгосударственная система стандартизации. Термины и определения

ГОСТ Р 1.12 Стандартизация в Российской Федерации. Термины и определения

ГОСТ Р 55022-2012 Информационная технология. Спецификация языка описания представления задач (JSDL). Версия 1.0

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

_______________
* Текст документа соответствует оригиналу. - .

3 Термины, определения и сокращения

3.1 Термины и определения

В настоящем стандарте применены термины согласно ГОСТ 1.1, ГОСТ Р 1.12, а также используются следующие термины с соответствующими определениями:

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

3.1.2 метаданные: Структурированные данные, представляющие собой характеристики описываемых объектов для целей их идентификации, поиска, оценки и управления ими.

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

3.1.4 поставщик услуг: Система, обеспечивающая потребителей необходимым набором ресурсов и сервисов.

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

3.1.6 NET: Программная платформа, выпущенная компанией Microsoft.

3.2 Сокращения

В настоящем стандарте применены следующие сокращения:

IP (Internet protocol) - межсетевой протокол;

J2EE (Java 2 Platform Enterprise Edition) - независящая от платформы среда, основанная на Java;

JSDL (Job Submission Description Language) - язык описания представления задачи;

MPI (message passing interface) - интерфейс передачи сообщений;

OASIS (advancing open standards for the information society) - расширенные открытые стандарты для информационного сообщества;

PKI (public key infrastructure) - инфраструктура открытых ключей;

POSIX (Portable Operating System Interface) - интерфейс переносимых операционных систем;

SQL (Structured Query Language) - язык структурированных запросов;

WSDL (Web Service Description Language) - язык описания web-сервисов;

XML (eXtensible Markup Language) - расширяемый язык разметки;

XMLQuery - Язык запросов XML;

ВО - виртуальная организация;

ГНК - генератор набора кандидатов;

ИПП - интерфейс прикладных программ;

КО - качество обслуживания;

ОС - операционная система;

ПО - программное обеспечение;

СОАОГС - сервис-ориентированная архитектура открытых Грид-систем;

СПВ - сервисы планирования выполнения;

СУБД - система управления базой данных;

СУВ - сервисы управления выполнением;

УУС - управление уровня сервиса.

4 Требования

Модель СОАОГС определяется набором функциональных и нефункциональных требований, полученных из вариантов использования, перечисленных в таблице 1. Эти варианты использования охватывают инфраструктуру и сценарии приложений как в коммерческой, так и в научной областях. Они не представляют собой формальный анализ требований, но дают полезный вклад в процесс определения архитектуры.

Таблица 1 - Варианты использования СОАОГС

4.1 Интероперабельность и поддержка динамических и гетерогенных сред

Некоторые варианты использования СОАОГС применяют квалификационные ограничения, или однородные среды, что мотивирует использование специализированных профилей. В общем случае среда Грид гетерогенна и является распределенной, имеет различные среды размещения (например, J2EE, NET), операционные системы (например, Unix, Linux, Windows, встраиваемые системы), устройства (например, компьютеры, приборы, датчики, системы хранения данных, баз данных, сетей) и сервисы, предоставляемые различными поставщиками. Кроме того, Грид-среды часто являются долгоживущими и динамичными и поэтому могут развиваться в направлениях, которые изначально не предполагались.

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

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

1) Виртуализация ресурсов. Задача - снизить сложность управления гетерогенными системами и обрабатывать разнообразные ресурсы единообразно.

2) Общие средства управления. Упрощение администрирования гетерогенной системы требует существования механизмов для единообразного и последовательного управления ресурсами. Требуется минимальный набор общих возможностей управления.

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

4) Для интероперабельности важны стандартные протоколы и схемы. Кроме того, особенно важны стандартные протоколы, так как их использование может упростить переход к использованию Грид.

4.2 Разделение ресурсов между организациями

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

Требования на ресурсы совместного использования включают в себя следующее:

1) Глобальное пространство имен, служащее для облегчения доступа к данным и ресурсам. Организации, архитектура которых основана на СОАОГС, должны иметь возможность прозрачного доступа к другим объектам СОАОГС, с учетом ограничений безопасности, независимо от местонахождения.

2) Сервисы метаданных. Они важны для поиска, использования и контроля объектов СОАОГС, должны предоставлять возможность доступа и распространения метаданных, их агрегации и управления в рамках административных доменов.

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

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

4.3 Оптимизация

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

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

_______________
* Текст документа соответствует оригиналу. - .

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

4.4 Обеспечение качества обслуживания

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

Требования по обеспечению качества обслуживания включают в себя следующее.

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

2) Достижение требуемого уровня обслуживания. Если соглашение требует получения уровня обслуживания, ресурсы, используемые сервисом, должны быть настроены таким образом, чтобы сохранить требования КО. Таким образом, требуются механизмы контроля за КО, оценки использования ресурсов и планирования и регулирования использования ресурсов.

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

4.5 Выполнение задач

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

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

1) Поддержка различных типов задач. Должно поддерживаться выполнение различных типов задач, включая простые и сложные задачи, такие как поток заданий и составные (сложные) сервисы.

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

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

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

4.6 Сервисы данных

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

Требования, необходимые для сервисов данных, включают в себя следующее.

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

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

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

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

5) Управление расположением данных. Эти сервисы управляют физическим расположением данных. СОАОГС должна поддерживать множественные методы, дающие пользователям возможность получать доступ к данным в конкретном месте, согласно требованиям политики как пользователя, так и ресурса данных.

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

7) Устойчивость данных. Данные должны быть защищены в соответствии с указанной политикой. Связь локальных данных с их метаданными также должна быть защищена согласно соответствующей политике. Должна существовать возможность использования одной из многих допустимых моделей устойчивости данных.

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

4.7 Безопасность

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

Требования безопасности следующие.

1) Аутентификация и авторизация. Требуются механизмы аутентификации, цель которых - идентифицировать индивидуального пользователя и сделать возможным установление требуемых сервисов. Грид-система должна следовать требованиям политики безопасности каждого домена, а также, возможно, будет вынуждена выяснять пользовательские политики безопасности. Авторизация должна включать различные модели контроля доступа и их реализации.

2) Множественные инфраструктуры безопасности. Распределенные операции предполагают необходимость интеграции и взаимодействия с несколькими инфраструктурами безопасности. СОАОГС необходимо интегрироваться и взаимодействовать с существующими архитектурами и моделями безопасности.

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

4) Изоляция. Должны быть обеспечены различные виды изоляции, например изоляция пользователей, изоляция выполнения, изоляция между содержимым, предлагаемым в рамках одной Грид-системы.

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

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

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

4.8 Уменьшение стоимости администрирования

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

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

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

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

4.9 Масштабируемость

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

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

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

4.10 Работоспособность

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

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

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

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

4.11 Простота использования и расширяемость

Пользователь должен иметь возможность использовать СОАОГС для сокрытия сложности среды, если это требуется.

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

Невозможно заранее предсказать все многочисленные и разнообразные потребности, которые будут иметь пользователи. Поэтому механизмы и политики должны реализовываться при помощи расширяемых и сменных компонентов, чтобы позволить СОАОГС с течением времени развиваться и даст возможность пользователям в соответствии с конкретными потребностями создавать свои собственные механизмы и политики. Кроме того, основные компоненты системы сами должны быть расширяемыми и сменными. Такая расширяемость позволит локализованным реализациям третьей стороны, которые обеспечивают дополнительные сервисы, использоваться и развиваться. Расширения и настройки должны быть обеспечены таким образом, чтобы не нарушить интероперабельность.

5 Характеристики

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

5.1 Обзор

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

Рисунок 1 - Логическое, абстрактное, послойное представление возможностей СОАОГС

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

Примеры

1 Физические организации, включающие процессоры, память и диски.

2 Логические объекты, включающие лицензии, содержание и процессы в операционных системах.

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

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

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

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

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

Все эти уровни должны взаимодействовать и работать, усиливая друг друга, чтобы обеспечить требуемое КО.

5.2 Модель СОАОГС

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

Несколько важных замечаний.

1) Важным стимулом для СОАОГС является подход, основанный на парадигме композиций, или парадигме "строительных блоков". При таком подходе набор характеристик или функций строится или адаптируется согласно требованиям начиная с самого минимального набора начальных характеристик, чтобы удовлетворить потребность. Не предполагается никакого предварительного знания об этих потребностях. Это обеспечивает адаптивность, гибкость и надежность изменений, которые требуются в архитектуре.

2) Полный набор характеристик СОАОГС не обязан присутствовать в системе. Другими словами, система может быть построена при использовании только подмножества характеристик, определенных в СОАОГС. Более того, сами характеристики не являются монолитными. Система может выбрать только подмножество сервисов из любой характеристики к реализации или обеспечению.

3) СОАОГС представляет сервисы, их интерфейсы и семантику/поведение/взаимодействие этих сервисов.

Уровни интероперабельности: 1 - технический; 2 - семантический; 3 - организационный

Рисунок 2 - Модель СОАОГС

4) Архитектура не является слоистой, когда реализация одного сервиса может взаимодействовать только с элементами своего слоя. Архитектура также не является объектно-ориентированной, хотя многие концепции могут выглядеть как объектно-ориентированные.

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

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

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

Ожидается, что может существовать основной набор ненулевых интерфейсов, стандартов и общих знаний/инициализаций, которые сервисы должны реализовать, чтобы быть частью СОАОГС. Этот набор общих реализаций и проявлений для поддержки СОАОГС называется сервисами инфраструктуры.

5.3 Сервисы инфраструктуры

5.3.1 Цели

СОАОГС использует и строится на ряде общих компонент. Этот пункт описывает компоненты инфраструктуры.

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

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

5.3.2 Именование

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

Пример - В имени файла Unix "node1:/var/log/error" контекстом для "var" является корневой каталог на машине с именем "node", контекстом для директории "log" служит "var", контекстом для "error" является "log".

Система именования СОАОГС не требует уникальности имен, ориентированных на человека. Существует много разных схем именования. В этом документе не предпринимается попытка предварительно описать набор всех поддерживаемых схем.

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

Адрес определяет местоположение объекта. Примерами адресов являются ссылки на конечную точку в документе, адрес памяти, а также пары IP-адрес/порт. Для связи абстрактных имен и адресов необходим механизм, описание которого выходит за рамки этого документа.

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

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

- сервисы, совместимые с СОАОГС, при возвращении адреса должны использовать адресацию web-сервисов на конечную точку;

- сервисы, совместимые с СОАОГС, могут возвращать профилированное использование адресации web-сервисов на конечную точку;

- сервисы, совместимые с СОАОГС, должны возвращать профилированное использование адресации web-сервисов на конечную точку, где это возможно;

- сервисы, совместимые с СОАОГС, не должны требовать, чтобы было возвращено специфичное профилированное использование адресации web-сервисов на конечную точку;

- сервисы, совместимые с СОАОГС, не должны требовать, чтобы было возвращено профилированное наименование web-сервисов адресации web-сервисов на конечную точку.

5.3.3 Безопасность

Одной из ключевых областей, в которой требования Грид обуславливают расширение существующих спецификаций, является безопасность. Проблемы безопасности возникают на различных уровнях инфраструктуры СОАОГС. Используются стандартные протоколы безопасности web-сервисов, чтобы позволить сервису СОАОГС безопасно запрашивать выполнение соответствующих маркеров для целей аутентификации, авторизации и защиты сообщений. Для некоторых сценариев рассматриваемой инфраструктуры СОАОГС требуется защита сообщения от его начала до конца. Таким образом, СОАОГС должна также обеспечивать механизмы защиты высокого уровня, таких как XML-шифрование и цифровая подпись, в дополнение (или вместо) безопасности транспортного уровня "точка-точка". В дополнение к безопасности уровня сообщений интероперабельная и многокомпонентная инфраструктура нуждается в собственных компонентах безопасности, предоставляемых в виде сервисов. Существуют различные способы, реализуемые для спецификации определений сервисов таких сервисов безопасности.

Пример - Сервис авторизации СОАОГС может использовать предложенный стандарт соглашений web-сервисов совместно со стандартами OASIS для описания формальных утверждений безопасности и описания контроля доступа. Когда и где это уместно, СОАОГС будет принимать или определять такие сервисы безопасности.

5.3.4 Представляющее состояние

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

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

5.3.5 Уведомления

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

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

5.3.6 Транзакции

СОАОГС не определяет механизм транзакций как таковой. Эти функции должны быть предоставлены другим разработкам в сообществе web-сервисов.

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

Сами клиенты определенных сервисов должны принимать решение об обеспечении возможности конкретной реализации совершать транзакцию.

5.3.7 Гармонизация

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

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

- оркестровка - описывает, каким образом бизнес-процессы строятся на основе web-сервисов и других бизнес-процессов и как эти процессы взаимодействуют.

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

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

СОАОГС не определяет новые механизмы в этой области.

5.3.8 Обеспечение интероперабельности: профили СОАОГС

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

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

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

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

5.4 Сервисы управления выполнением (СУВ)

5.4.1 Цели

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

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

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

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

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

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

- Управление исполнением. После начала исполнения задача должна управляться и контролироваться до окончания. Что будет, если произойдет сбой? Или не будут выполнены соглашения? Должна ли задача быть перезапущена в другом месте? Должна ли для обеспечения перезапуска периодически формироваться контрольная точка? Имеет ли выполняемая часть какой-нибудь тип обнаружения ошибок и схему восстановления после сбоя?

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

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

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

СУВ содержат несколько сервисов, работающих совместно.

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

5.4.2 Сервисы СУВ

Существуют три класса сервисов СУВ

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

- управление задачами

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

Предполагается доступность сервисов управления данными, сервисов безопасности и сервисов регистрации.

5.4.3 Ресурсы

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

Интерфейс базового контейнера может представлять только малый набор операций (Базовые сервисы выполнения СОАОГС). Помимо базового контейнера, предполагается наличие расширенных интерфейсов.

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

5.4.4 Управление задачами

5.4.4.1 Задача

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

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

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

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

5.4.4.2 Менеджер задач

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

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

Менеджер задач реализует интерфейс управления.

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

Примеры

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

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

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

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

5.4.5 Сервисы выбора

5.4.5.1 Сервисы планирования выполнения (СПВ)

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

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

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

5.4.5.2 Генератор набора кандидатов

Основная идея довольно проста: определить набор ресурсов, на которых единица работы может быть выполнена, то есть где она может быть выполнена, а не где она будет выполняться. Здесь могут учитываться такие параметры как доступные бинарные коды, специальные требования приложения (например, 4 ГБ оперативной памяти, 40 ГБ временного дискового пространства, инсталлированные xyz-библиотеки), параметры безопасности и доверия.

Генератор набора кандидатов генерирует набор контейнеров ссылок на конечную точку, в которых возможно выполнение задачи, описанной в ГОСТ Р 55022. Набор контейнеров искомых ресурсов может либо быть набором по умолчанию для конкретного сервиса, либо передаваться сервису в качестве параметра.

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

5.4.5.3 Сервисы резервирования

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

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

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

Сервисы резервирования могут использоваться многими различными сервисами: менеджер задач должен создавать резервирования для групп задач, которыми он управляет; сервисы СПВ должны использовать резервирование для обеспечения плана выполнения конкретной задачи. Также возможен случай создания резервирования, связанного с шагом обеспечения задачи.

5.4.6 Взаимодействие с другими сервисами СОАОГС

5.4.6.1 Сервис запуска и конфигурирования

Перед использованием единицей работы сервиса или контейнера данных он должен быть настроен или снабжен дополнительными ресурсами.

5.4.6.2 Наименование

СОАОГС СУВ используют систему наименований СОАОГС.

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

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

Пример - Абстрактное имя до и после миграции задачи должно оставаться одним и тем же.

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

5.4.6.3 Информационный сервис

Информационные услуги являются базами данных атрибутов метаданных о ресурсах. В СУВ информационные услуги используются многими различными сервисами. Например, контейнерам необходимо опубликовать информацию о своих атрибутах так, чтобы сервисы ГНК могли оценить пригодность контейнера для задачи; сервисы СПВ должны иметь возможность прочитать информационную политику ВО из информационного сервиса. Способ получения информации информационным сервисом не определен.

5.4.6.4 Мониторинг

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

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

5.4.6.5 Сервисы детектирования отказов и восстановления

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

5.4.6.6 Регистрация

Регистрация является важной в контексте сервисов СУВ, так как можно ожидать, что некоторое число других сервисов будет строиться поверх этих сервисов. Например, можно предположить, что регистрация является основой всей действующей цепочки сервисов.

- Снятие показаний есть использование журнала для записи последовательности использования ресурсов.

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

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

5.5 Сервисы данных

5.5.1 Цели

Описываются сервисы СОАОГС, которые связаны с управлением, доступом и обновлением ресурсов данных, а также с передачей данных между ресурсами. Все вместе это называется "сервисы данных".

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

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

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

- Потоки. Непрерывный поток данных называется потоком. Сервисы доступа к данным поддерживают запросы к этим потокам и их преобразование.

- СУБД. Некоторые виды СУБД могут быть частью Грид. Они включают реляционные, XML, объектно-ориентированные и некоторые другие типы баз данных.

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

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

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

5.5.2 Гетерогенность и расширяемость

5.5.2.1 Прозрачность и виртуализация

Распределенная система может содержать различные ресурсы данных. Эти ресурсы могут использовать различные модели структуры данных, различные физические носители для хранения данных, различные системы программного обеспечения для управления ресурсами, различные схемы описания, а также различные протоколы и интерфейсы для доступа к ресурсу. Данные могут храниться локально или удаленно; могут быть уникальными или являться копиями; могут быть материализованы или получены по требованию. Сервисы данных СОАОГС предоставляют различные уровни виртуализации этих ресурсов данных. Виртуализация есть абстрактное представление, позволяющее скрыть указанные различия и позволяющее управлять ресурсами данных без учета их физических особенностей.

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

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

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

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

5.5.2.2 Интерфейсы прикладных программ клиентов

Пользователи могут использовать сервисы данных СОАОГС для обычных приложений, которые используют существующие интерфейсы прикладных программ, такие как NFS, POSIX IO и др. Зачастую переделка программ клиентами для использования новых интерфейсов является очень дорогой и непрактичной. Интерфейсы СОАОГС могут быть легко экранированы посредством эмуляции этих существующих интерфейсов прикладных программ, хотя сама СОАОГС не определяет способы экранирования.

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

5.5.2.3 Поддержка расширяемых типов данных и операций над ними

Невозможно предсказать все ресурсы данных, которые будут использоваться сервисами данных СОАОГС. В любом случае, в будущем будут созданы новые ресурсы данных. Слоистая архитектура (см.рисунок 1) позволяет добавлять новые сервисы данных, которые будут иметь доступ к новым типам ресурсов.

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

5.5.3 Функциональные возможности

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

5.5.3.1 Передача данных

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

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

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

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

Политики безопасности могут также быть присоединены как передаваемым данным, так и к собственно ресурсам.

5.5.3.2 Управление хранением

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

5.5.3.3 Простой доступ

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

5.5.3.4 Запросы

Сервисы доступа к данным СОАОГС обеспечивают механизмы для применения запросов к ресурсам данных. В простых случаях они могут запустить SQL-запрос к реляционной базе данных, XML-запрос по базе данных XML или обычное выражение к текстовому файлу. Другие сервисы могут осуществлять анализ текста по набору документов или распределенных запросов по базам данных объединения.

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

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

5.5.3.5 Федеративное объединение

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

5.5.3.6 Управление местом расположения данных

Решение о том, где хранить данные, может быть принято на основании целого ряда параметров, таких как скорость доступа для данного клиента и гарантии доступа. Сервисы данных СОАОГС предоставляют несколько сервисов, которые управляют расположением данных.

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

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

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

5.5.3.7 Обновления

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

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

5.5.3.8 Преобразования

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

Сервисы данных могут сами преобразовывать данные.

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

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

5.5.3.9 Расширения отображения безопасности

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

Пример - Сервисы данных могут переводить информацию, связанную с безопасностью, от модели СОАОГС в информацию, которая необходима ресурсу данных.

5.5.3.10 Конфигурация ресурсов и сервисов

Ресурсы данных часто имеют сложные варианты конфигурации. Эти варианты могут быть сделаны доступными для клиентов посредством сервисов данных СОАОГС. Кроме того, сервисы могут предоставлять дополнительные операции по настройке виртуализации ресурсов, предоставляемых сервисами.

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

5.5.3.11 Каталоги метаданных

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

Метаданные для сервисов данных СОАОГС могут включать информацию о структуре данных, включая ссылки на схемы, описывающие эти данные. Для некоторых сервисов не практично, если ресурсы данных включают в себя много схем, которые часто модифицируются, и в этом случае информация о схеме может предоставляться самими сервисами.

5.5.3.12 Обнаружение данных

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

5.5.3.13 Происхождение

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

5.5.4 Свойства

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

5.5.4.1 Масштабирование

Сервисы данных СОАОГС управляют большими масштабами в нескольких измерениях, включая размер набора данных, число наборов данных, размера потоков данных и число сайтов.

5.5.4.2 Выполнение

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

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

5.5.4.3 Доступность

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

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

5.5.4.4 Правовые и этические ограничения

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

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

Данные часто закрыты ограничениями прав собственности, которые ограничивают права создания копий данных. В Евросоюзе аналогичные ограничения "прав баз данных" налагаются отдельно на базы данных.

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

5.5.5 Взаимодействие с другими сервисами СОАОГС

Эта часть обобщает взаимодействия между сервисами данных и другими частями СОАОГС.

5.5.5.1 Транзакции

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

5.5.5.2 Регистрация

Аналогично другим сервисам СОАОГС сервисы данных используют сервисы регистрации (например, аудит). Напротив, сами сервисы регистрации могут использовать сервисы данных для сохранения журналов.

5.5.5.3 Сервисы развертывания и конфигурирования

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

5.5.5.4 Конвейер

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

5.5.5.5 Планирование выполнения и менеджер задач

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

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

5.5.5.6 Резервирование ресурсов

Сервисы данных могут требовать резервирования некоторых ресурсов для своей работы.

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

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

5.5.5.7 Обнаружение

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

5.5.5.8 Безопасность

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

Сервисы управления ВО обеспечивают аналогичный контроль такого отображения.

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

5.5.5.9 Управление сетью

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

5.5.5.10 Наименование

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

5.5.5.11 Нотификация

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

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

5.6 Сервисы управления ресурсами

5.6.1 Сферы управления ресурсами

Управление ресурсами имеет несколько форм в Грид. В Грид СОАОГС существуют три сферы управления, которые работают с ресурсами:

- Управление собственно физическими и логическими ресурсами.

- Управление ресурсами Грид СОАОГС, которые представлены посредством интерфейсов сервисов.

- Управление инфраструктурой Грид СОАОГС, осуществляемое посредством интерфейсов управления.

5.6.2 Свойства

5.6.2.1 Масштабируемость

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

5.6.2.2 Интероперабельность

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

5.6.2.3 Безопасность

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

5.6.2.4 Надежность

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

5.6.3 Взаимодействие с другими сервисами СОАОГС

Сервисы инфраструктуры реализуют интерфейсы на уровне инфраструктуры. Поскольку указанные интерфейсы определяют базовое поведение управления ресурсами, все сервисы СОАОГС должны использовать эти интерфейсы при управлении такими ресурсами.

Информационные сервисы обеспечивают функциональность управления ресурсами, в частности для мониторинга, который используется многими сервисами СОАОГС.

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

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

5.7 Сервисы безопасности

5.7.1 Цели

Далее описываются свойства сервисов безопасности. Обсуждается взаимодействие этих сервисов с остальными сервисами СОАОГС.

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

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

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

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

Архитектурные компоненты безопасности СОАОГС должны поддерживать, интегрировать и унифицировать популярные модели безопасности, механизмы, протоколы, платформы и технологии с целью обеспечения возможности безопасного взаимодействия множества систем. Указанные компоненты должны поддерживать интегрирование с существующими архитектурами и моделями безопасности между платформами и окружением узлов. Это предполагает, что данная архитектура может быть выражена в терминах любых существующих механизмов безопасности (таких как Kerberos); расширяемой, чтобы она могла инкорпорировать новые сервисы безопасности, как только они станут доступными; и могла интегрироваться с уже существующими сервисами безопасности. Кроме того, сервисы, которые "проходят сквозь" многие домены и среды узлов, должны иметь возможность взаимодействовать между собой, что приводит к необходимости интероперабельности на многих уровнях: протоколов, политик и объектов. В дополнение определенные ситуации могут делать невозможным установление доверительных отношений между набором сайтов перед выполнением задачи. Известно, что домены, участвующие в Грид, могут иметь различную инфраструктуру безопасности (или Kerberos, или PKI). Таким образом, существует необходимость реализации требуемых доверительных взаимоотношений посредством некоторых форм федеративных объединений механизмов безопасности.

5.7.2 Свойства

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

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

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

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

5.7.3 Взаимодействие с другими сервисами СОАОГС

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

В некоторых случаях требования и сервисы безопасности тесно связаны с другими сервисами СОАОГС более высокого уровня.

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

В этом отношении сервисы безопасности могут выступать в качестве потребителя для других сервисов СОАОГС.

5.8 Сервисы самоуправления

5.8.1 Цели

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

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

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

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

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

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

5.8.2 Базовые атрибуты

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

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

5.8.3 Функциональные возможности

5.8.3.1 Управление уровнем задач

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

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

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

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

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

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

5.8.3.2 Управление уровнем сервисов

Управление уровнем сервисов обеспечивает поддержку желаемого качества сервисов. Это достигается посредством действий МУС, как описано в 5.8.3. Такие действия по достижению уровня сервиса более детально описаны далее.

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

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

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

Примеры

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

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

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

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

5.8.3.3 Управление, основанное на политиках и модели

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

5.8.3.4 Наименование

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

5.8.3.5 Планирование

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

5.8.3.6 Управление возможностями

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

5.8.3.7 Подготовка к работе (инициализация)

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

5.8.3.8 Аналитики

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

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

5.8.4 Свойства

5.8.4.1 Цели

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

5.8.4.2 Доступность

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

5.8.4.3 Безопасность

Безопасность является экстремально важным аспектом среды ИТ. Ее измерения могут включать нарушения безопасности, вероятность нарушения безопасности, показатели управления объектами, такими как время создания или уничтожения пользователя и пр.

5.8.4.4 Производительность

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

5.8.5 Взаимодействие с другими сервисами СОАОГС

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

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

- Протоколирование и мониторинг - для обеспечения информацией, требуемой для определения состояния системы.

- Резервирование ресурсов - для содействия более предсказуемому использованию ресурсов.

- Конвейер - для автоматизации действий, которые вынужден проводить МУС при обнаружении нестандартных условий.

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

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

5.9 Информационные сервисы

5.9.1 Цели

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

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

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

СОАОГС не предписывает модель данных, которая используется для реализации информационного сервиса, или язык, используемый для запроса информации. Существующие системы широко используют модели и языки, которые основаны на ХМL и соответствующих языках запросов, реляционную модель и язык запросов SQL.

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

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

5.9.2 Функциональные возможности

5.9.2.1 Обнаружение

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

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

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

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

5.9.2.2 Доставка сообщений

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

5.9.2.3 Протоколирование

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

5.9.2.4 Мониторинг

Информация, которая обеспечивает область упорядочения целей (например, отметки времени и порядковый номер), может использоваться для контроля. Сервис мониторинга СОАОГС может одинаково использоваться как для приложений, так и для ресурсов. Некоторые ситуации (например, приложения реального времени) могли бы наложить строгие требования на сервис мониторинга (например, высокая скорость обновления и высокая эффективность). В таком случае может понадобиться специализированный сервис.

5.9.2.5 Сервис общей информации и мониторинга

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

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

Продвинутые пользователи могут потребовать понимания внутренней работы сервиса.

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

5.9.3 Свойства

5.9.3.1 Безопасность

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

5.9.3.2 Качество сервиса

Различные уровни качества сервиса могут быть обеспечены информационными сервисами СОАОГС (например, надежность, гарантирование доставки).

5.9.3.3 Доступность, производительность и масштабируемость

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

5.9.4 Взаимодействие с другими сервисами СОАОГС

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

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

Сервисы безопасности необходимы для аутентификации/авторизации между различными компонентами.

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

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

Электронный текст документа
и сверен по:

, 2018