3.2Архитектура и алгоритмы системы запуска заданий в грид для различных сред исполнения 3.2.1Взаимодействие СЗЗ-РСИ с другими подсистемами грида
Общий алгоритм работы системы запуска заданий, подготовленных для различных сред исполнения, представлен на рис. 6.
Рис.6 Общий алгоритм работы системы запуска заданий, подготовленных для различных сред исполнения
В соответствии с этим алгоритмом сценарий использования системы запуска заданий, подготовленных для различных сред исполнения, является следующим:
Пользователь в описании задания на языке JDL в значении атрибута Requirements указывает значение "*jobmanager-vres" и наименование требуемой среды, как описано в предыдущем разделе;
Менеджер загрузки с помощью подсистемы информационного обслуживания находит ресурсный центр и CE, имеющий службу предоставления сред исполнения (СПСИ) и свободные рабочие узлы и направляет туда задание;
на CE задание обрабатывается с участием СПСИ; при этом создается специальный обертывающий скрипт, который через локальную систему управления пакетными заданиями передается на рабочий узел;
при необходимости СПСИ инициирует передачу (репликацию) на локальный SE нужного образа ВМ с требуемой средой с удаленного SE;
при запуске на рабочем узле с установленным монитором виртуальных машин (МВМ) СПСИ и обертывающий скрипт выполняют следующие основные действия (ср. рис. 6):
копирует образ диска с SE на локальный диск,
запускает ВМ и инсталлирует гостевую ОС,
запускает на хосте ftp-сервер,
после окончания выполнения задания и выгрузки результатов из ВМ в хост-систему, скрипт останавливает ВМ и уничтожает образ на локальном диске.
результаты задания доставляются пользователю стандартными средствами gLite.
Необходимо отметить, что в этом сценарии подразумевается, что в грид-системе (хотя бы на одном SE) находится образ диска с требуемой средой. Это может быть как общедоступный образ, или образ, специально приготовленный пользователем для выполнения данного задания. Такой образ должен быть выложен на один из SE, с помощью стандартными средствами системы управления данными в грид-среде и зарегистрирован в распределенных файловых каталогах.
3.2.2Архитектура службы предоставления сред исполнения (СПСИ)
Поскольку, в соответствии с Техническим заданием, система запуска заданий для произвольных сред исполнения должна быть совместима с промежуточным программным обеспечением (ППО) gLite, служба запуска заданий в средах исполнения по запросам пользователей (СПСИ) должна быть совместима с вычислительным элементом LCG-CE и, соответственно, подклассом модуля Globus::GRAM::JobManager, отвечающего за запуск любых заданий в ППО gLite. Имя подкласса удобно выбрать так, чтобы оно соответствовало его функциональному назначению сервиса запуска заданий в средах исполнения по запросам: Globus::GRAM::JobManager::vres (опять использова аббревиатура английского Virtual Runtime Environment Service – VRES). Минимальный набор основных методов, который должен реализовывать этот сервис являются следующими (ср. [8]):
submit – запуск задания;
poll – запрос статуса задания;
cancel – отмена запуска.
Алгоритм работы сервиса (подкласса) сводится к следующему.
1. Импортируются модули, необходимые для работы сервиса GRAM (Grid Resource Allocation Manager – основной модуль запуска заданий на грид-ресурсах в ППО gLite).
2. Декларируется принадлежность сервиса запуска заданий в средах исполнения по запросам пользователя (VRES) как подкласса Globus::GRAM::JobManager
3. Декларируются значения переменных среды исполнения модуля VRES (в частности, пути к командам, которые будут использоваться при работе модуля).
4. Реализуется метод “submit”:
Анализируются атрибуты задания, указанные в файле JDL (они доступны сервису в виде объекта JobDescription)
Используя результаты анализа, создается специальный скрипт с
соответствующим образом подготовленным описанием задания, которое передается локальной системе управления заданиями (СУПЗ) в качестве параметра команды запуска задания;
указанием исполнимого файла (собственно задания);
С помощью созданного скрипта задание передается СУПЗ, при этом результатом выполнения скрипта должно быть либо сообщение об ошибке (объект GRAMerror) или идентификатор задания.
5. Реализуется метод “poll”:
Идентификатор задания, полученный в результате выполнения метода “submit”, передается команде СУПЗ, проверяющей состояние задания, выполняемого на рабочем узле вместе с объектом JobDescription, содержащим описание задания.
Выдача команды СУПЗ, проверяющей состояние задания, выполняемого на рабочем узле, анализируется, преобразуется к удобному виду и передается подсистеме мониторинга ППО gLite.
6. Реализуется метод “cancel”:
Идентификатор задания, полученный в результате выполнения метода “submit”, передается команде СУПЗ, отменяющей выполнение задания на рабочем узле
Подсистеме мониторинга ППО gLite передается состояние задания "FAILED".
7. Для того, чтобы грид-шлюз (gatekeeper) ППО gLite мог взаимодействовать с сервисом предоставления сред исполнения по запросам пользователей, необходимо произвести его настройку. Это делается с помощью специального установочного скрипта.
8. Сервис предоставления сред исполнения регистрируется в грид-шлюзе как обработчик заданий с помощью команды globus-job-manager-service.
9. Инсталируется файл проверки атрибутов JDL, специфических для сервиса предоставления сред исполнения.
3.2.3Архитектура вычислительного элемента и рабочих узлов со службой предоставления сред исполнения (СПСИ)
На рис. 7 представлена общая архитектура ресурсного грид-центра со службой предоставления сред исполнения.
Рис. 7 Общая архитектура вычислительных грид-ресурсов (CE и WN) при наличии службы предоставления сред исполнения (СПСИ)
Алгоритм выполнения задания в требуемой среде, соответствующий этой архитектуре показан на рис.8.
Рис.8 Алгоритм выполнения задания в среде по запросу пользователя с помощью службы предоставления сред исполнения.
3.2.4Обеспечение безопасности грид-среды
При реализации системы запуска заданий важно обеспечить безопасность грид-среды, с точки зрения возможности несанкционированных действий недобросовестных пользователей. Возможные проблемы связаны с тем, что запуск виртуальной машины Xen, которая была выбрана в качестве основного кандидата для виртуализации грид-ресурсов на первом этапе работы, осуществляется от имени привилегированного пользователя хост-системы.
Для решения этой проблемы и обеспечения общей безопасности будет использоваться инфраструктуры безопасности грида Globus GSI [9] и программа "sudo" [10].
Инфраструктура безопасности обеспечивает безопасный доступ к ресурсам в незащищенных сетях общего доступа (Интернет) с учетом прав данного пользователя и правил обслуживания пользователей данным ресурсным центром (такие правила часто называют «локальной политикой»). Система Globus GSI предоставляет такие сервисы, как аутентификация, конфиденциальность передачи информации и делегирование прав. Под делегированием прав подразумевается, что пользователю нужно лишь один раз пройти процедуру аутентификации, а далее система сама позаботится о том, чтобы аутентифицировать его на всех ресурсах, которыми он собирается воспользоваться. GSI, в свою очередь, основана на надежной и широко используемой технологии открытых криптографических ключей (Public Key Infrastructure, PKI).
Программа sudo (англ. superuser/substitute user do, дословно «выполнить от суперпользователя») - это программа, разработанная в помощь системному администратору и позволяющая делегировать те или иные привилегированные ресурсы пользователям с ведением протокола работы. Основная функциональность, которая будет использоваться для безопасной работы СЗЗ-РСИ - это возможность предоставления пользователям строго ограниченных прав, но при этом ровно столько, сколько необходимо для решения поставленных задач. Команда sudo предоставляет возможность пользователям выполнять команды от имени привилегированного пользователя (root) либо других пользователей:
sudo требует указания пароля того пользователя, который получает права другого, а не пароля того, чьи права преобретаются:
действие sudo распространяется по умолчанию только на одну команду - ту, которая указывается в качестве ее аргумента (хотя это можно изменить с помощью соответствующих опций).
Правила, используемые sudo для принятия решения о предоставлении доступа, зависят от настроек программы, которые описываются в файле Linux-дистрибутива /etc/sudoers. В частности, в нем можно задать правила, допускающие исполнение определенных команд только отдельным пользователям. В обощенном виде это выглядит так:
username host = command
Здесь username - имя пользователя, для которого устанавливается данное правило, host - имя машины, с которой он может к этому правилу прибегнуть, command - конкретная команда, использование которой разрешается данному пользователю с данной машины. Команда должна указываться с указанием полного абсолютного пути (то есть /sbin/fdisk, а не fdisk). Поле описания команд может включать несколько значений, разделенных запятыми, например:
username ALL = /sbin/fdisk, /bin/mount
Таким образом, sudo позволяет разрешенному пользователю выполнять команду как суперпользователь или другой пользователь, как определено в файле sudoers. Реальный и эффективный uid и gid при этом устанавливаются так, чтобы соответствовать таковым целевого пользователя, как определено в файле passwd (также инициализируется вектор группы, если целевой пользователь - не root). По умолчанию sudo требует, что бы пользователи аутентифицировали себя при помощи пароля. Как только пользователь аутентифицировал себя происходит обновление временной метки и пользователь может использовать sudo некоторый период времени без пароля (по умолчанию пять минут, если в sudoers не указано другое).
Если не указанный в файле sudoers пользователь попытается выполнить при помощи sudo команду (в частности, представляющую угрозу безопасности грид-системы), то уполномоченному пользователю (администратору данного грид-ресурса) будет отправлено электронное сообщение. Программа sudo может регистрировать оба типа попыток выполнени команд - успешные и неудачные, (так же как и ошибки) при помощи системного журнала регистрации событий, собственного журнала, или с использованием обоих вариантов. Далее такие записи могут обрабатываться подсистемой протоколирования грид-инфраструктуры.
Для обеспечения безопасности будет учтено, что sudo регистрирует только явно выполненные команды. Если пользователь выполняет такую команду как sudo su или sudo sh, то команды выполненные из этих оболочек не будут запротоколированы и при этом их не затронет управление доступом sudo. Тоже-самое верно по отношению к командам, допускающим использование управляющих символов (включая большинство редакторов). В связи с этим должна быть проявлена осторожность при предоставление пользователям доступа к выполнению команд посредством sudo, во-избежание нечаянного предоставления пользователю доступа к оболочке суперпользователя (root).
3.2.5Предварительные шаги по реализации алгоритмов работы СЗЗ-РСИ 3.2.5.1 Инструкция по ручному развертыванию виртуальной машины и запуску в ней заданий средствами грида
Здесь предполагается вставить инструкцию И.Горбунова по ручному развертыванию ВМ и ОС в ней, а также запуску заданий средствами промежуточного программного обеспечения.
3.2.5.2 Выбор реализации обмена данными между хостовой и гостевой операционными системами на рабочем узле грид-системы
Здесь предполагается вставить результаты Л.Шамардина по выбору ftp-сервера, способа его запуска и т.д.
|
