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

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

сервис, которому делегируются права (делегат) создает пару ключей (открытый и закрытый);

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

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

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

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

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

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

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

В ППО gLite информацию для авторизации пользователей предоставляет сервис VOMS (Virtual Organization Membership Service – Сервис управления членством в виртуальных организациях). Сервер VOMS использует реляционные база данных MySQL или ORACLE в качестве систем хранения данных и основывается на добавлении некритичных расширений к пользовательскому прокси-сертификату, которые и содержат сведения о пользователе, необходимые для его авторизации.

52

2.6 Подсистема протоколирования

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

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

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

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

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

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

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

2.6.2Безопасность и управление доступом к информации подсистемы протоколирования

Информация о задании, хранящаяся на сервере LB, должна быть доступна только для владельца задания (пользователя, который отправлял задание), и, возможно, для тех пользователей, которых владелец указал в специальном списке контроля доступа (Access Control List, ACL). Пользователи в ACL могут быть определены непосредственно по их именам (указанным в их сертификатах), или по названиям групп виртуальных

53