Стандарт Grid в сетевых технологиях

5.4. Безопасность.

 

Инфраструктура безопасности GRID (Grid Security Infrastructure – GSI) обеспечивает безопасную работу в незащищенных сетях общего доступа (Интернет), предоставляя такие сервисы, как аутентификация, конфиденциальность передачи информации и единый вход в GRID-систему. Под единым входом подразумевается, что пользователю нужно лишь один раз пройти процедуру аутентификации, а далее система сама позаботится о том, чтобы аутентифицировать его на всех ресурсах, которыми он собирается воспользоваться. GSI основана на криптографии с открытым ключом (Public Key Infrastructure – PKI).

В качестве идентификаторов пользователей  и ресурсов в GSI используются цифровые сертификаты X.509. В работе с сертификатами X.509 и в процедуре выдачи/получения сертификатов задействованы три стороны:

 

1. Центр Сертификации (Certificate Authority – CA) – специальная организация, обладающая полномочиями выдавать (подписывать) цифровые сертификаты. Различные CA обычно независимы между собой. Отношения между CA и его клиентами регулируются специальным документом.
2. Подписчик – это человек или ресурс, который пользуется сертификационными услугами CA. CA включает в сертификат данные, предоставляемые подписчиком (имя, организация и пр.) и ставит на нем свою цифровую подпись.
3. Пользователь – это человек или ресурс, полагающийся на информацию из сертификата при получении его от подписчика. Пользователи могут принимать или отвергать сертификаты, подписанные какой-либо CA.

 

В Globus Toolkit используются два типа сертификатов X.509:

 

1. Сертификат пользователя (User Certificate) – этот сертификат должен иметь каждый пользователь, работающий с GRID-системой. Сертификат пользователя содержит информацию об имени пользователя, организации, к которой он принадлежит, и центре сертификации, выдавшем данный сертификат.
2. Сертификат узла (Host Certificate) – это сертификат должен иметь каждый узел (ресурс) GRID-системы. Сертификат узла аналогичен сертификату пользователя, но в нем вместо имени пользователя указывается доменное имя конкретного вычислительного узла.

6. Программное обеспечение LCG.

 

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

Примером такого программного обеспечения  может служить ПО LCG (LHC Computing Grid), разрабатываемое в Европейском центре ядерных исследований (CERN). Изначально целью проекта LCG была разработка полностью функционирующей GRID-системы на базе Globus Toolkit для обработки данных в физике высоких энергий. Со временем область применения LCG расширилась, и в настоящее время это – один из самых распространенных и быстро развивающихся пакетов ПО GRID.

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

Ниже перечислены основные элементы LCG и их назначение:

 

• CE (Computing Element) – набор программ, предназначенный для установки на управляющий узел вычислительного кластера. Данный элемент предоставляет универсальный интерфейс к системе управления ресурсами кластера и позволяет запускать на кластере вычислительные задания;
• SE (Storage Element) – набор программ, предназначенный для установки на узел хранения данных. Данный элемент предоставляет универсальный интерфейс к системе хранения данных и позволяет управлять данными (файлами) в GRID-системе;
• WN (Worker Node) – набор программ, предназначенный для установки на каждый вычислительный узел кластера. Данный элемент предоставляет стандартные функции и библиотеки LCG задачам, выполняющимся на данном вычислительном узле;
• UI (User Interface) – набор программ, реализующих пользовательский интерфейс GRID-системы (интерфейс командной строки). В этот элемент входят стандартные команды управления задачами и данными.
• RB (Resource Broker) – набор программ, реализующих систему управления загрузкой (брокер ресурсов). Это наиболее сложный (и объемный) элемент LCG, предоставляющий все необходимые функции для скоординированного автоматического управления заданиями в GRID-системе;
• PX (Proxy) – набор программ, реализующих сервис автоматического обновления сертификатов (myproxy);
• LFC (Local File Catalog) – набор программ, реализующих файловый каталог GRID-системы. Файловый каталог необходим для хранения информации о копиях (репликах) файлов, а также для поиска ресурсов, содержащих требуемые данные;
• BDII (Infornation Index) – набор программ, реализующих информационный индекс GRID-системы. Информационный индекс содержит всю информацию о текущем состоянии ресурсов, получаемую из информационных сервисов, и необходим для поиска ресурсов;
• MON (Monitor) – набор программ для мониторинга вычислительного кластера. Данный элемент собирает и сохраняет в базе данных информацию о состоянии и использовании ресурсов кластера.
• VOMS (VO Management Service) – набор программ, реализующих каталог виртуальных организаций. Данный каталог необходим для управления доступом пользователей к ресурсам GRID-системы на основе членства в виртуальных организациях.

 

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

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

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

7. Пользователь в GRID.

 

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

 

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

 

 

Для входа в GRID-систему пользователь должен:

 

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

 

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

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

Доступ к GRID-системе может быть произведен из любой точки (вычислительной системы, терминала), в которой установлен пользовательский интерфейс системы GRID. Он может быть выполнен различными способами (командная строка, web-интерфейс), однако должен предоставлять пользователю возможность полноценно работать с GRID-системой, т.е. запускать новые задания, управлять уже запущенными и получать результаты работы завершившихся заданий. Наиболее стандартным является интерфейс командной строки (Command Line Interface – CLI), позволяющий выполнять все операции по управлению заданиями и данными, а также административные действия. Серьезные минусы этого интерфейса – его «недружественность» к пользователю и отсутствие ориентации на конкретное приложение. Пользователю намного удобнее работать со средой, ориентированной на решаемую им задачу и предоставляющую удобный графический интерфейс. Эту задачу решают web-интерфейсы, позволяющие работать с GRID-системой прямо из браузера.

7.1. Использование интерфейса командной строки.

 

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

 

grid-proxy-init

 

Для получения информации о прокси-сертификате можно воспользоваться следующей командой:

 

grid-proxy-info -all

 

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

Регистрации прокси-сертификата на сервере:

 

myproxy-init -s <сервер> -t <время регистрации>

 

Получение автоматически обновленного прокси-сертификата:

 

myproxy-get-delegation -s <сервер>

 

Получение информации о зарегистрированном прокси-сертификате:

 

myproxy-info -s <сервер>

 

Отмена регистрации:

 

myproxy-destroy -s <сервер>

 

После проведения всех подготовительных операций с прокси-сертификатами  можно приступать к запуску заданий в GRID-системе. Для описания заданий в среде LCG используется специальный язык JDL (Job Description Language). Типичное описание задания содержит информацию о расположении исполняемого файла задачи, аргументах командной строки, размещении входных и выходных данных и, наконец, информацию о требованиях, предъявляемых к вычислительным ресурсам (минимальный объем памяти, тип процессора и т.д.). Простейший пример задания на языке JDL приведен ниже:

 

Executable = "/bin/echo";

Arguments  = "Hello World";

StdOutput  = "hello.out";

StdError   = "hello.err";

OutputSandbox = {"hello.out", "hello.err"};

 

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

 

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

 

edg-job-submit hello.jdl

 

2. Получение информации о текущем состоянии задачи:

 

edg-job-status <JobID>

 

3. Получение результатов выполнения задачи после ее завершения:

 

edg-job-get-output <JobID>