2.3Отличие разрабатываемой системы от существующих решений запуска заданий в грид с помощью ППО gLite и Globus Toolkit
Разрабатываемая CСЗ-РСИ отличается от систем ППО gLite и Globus Toolkit тем, что позволяет запускать задачи в различных средах исполнения по запросам пользователей. ППО gLite, использующее модули Globus Toolkit, позволяет запускать задания, подготовленные для исполнения только в единственной фиксированной среде, заранее развернутой на рабочих узлах грида. Globus Toolkit является программным инструментарием, предназначенным для разработки и создания грид-систем, и сам по себе не имеет готовой полнофункциональной системы управления загрузкой грид-ресурсов.
Для того, чтобы обеспечить возможность запуска заданий в различных средах исполнения, необходим ряд дополнительных модулей, которые в совокупности образуют систему запуска заданий, подготовленных для различных сред исполнения, в грид-среду (СЗЗ-РСИ). Состав этой системы и ее архитектура и алгоритмы работы представлены в разд. 3.2 (после описания форматов описания грид-ресурсов с различными средами исполнения заданий в разд. 3.1). В частности, центральным модулем СЗЗ-РСИ является Служба предоставления сред исполнения (СПСИ), которая заменяет плагин взаимодействия с системой управления пакетными заданиями (выделено на рис. 5 жирным шрифтом). Описание этой грид-службы представлено в разд. 3.2.3.
3Разработка детальной архитектуры и алгоритмов работы модулей системы запуска заданий с различными средами исполнения в грид. 3.1Описание форматов описания грид-ресурсов с системой запуска заданий в различных средах исполнения 3.1.1Общие сведения о схеме GLUE
Отличительной особенностью грида является постоянное изменение состояния его компонент: запускаются и завершаются задания, создаются и удаляются файлы, изменяется конфигурация вычислительных ресурсов и ресурсов хранения данных и т.п. Ресурсы грида могут достаточно широко варьироваться, например используются различные хранилища данных – от дисковой до ленточной памяти, различные операционные системы и типы процессоров.
Чтобы грид мог работать, должны быть известны статус и конфигурация всех этих составных частей. Это позволяет выделять ресурсы пользователям, проводить мониторинг сайтов и собирать учетные данные. Во многих грид-инфраструктурах и, в частности в грид-инфраструктуре EGEE/РДИГ, эта проблема решается при помощи схемы GLUE (Grid Laboratory Uniform Environment) [6].
Схема GLUE – это общепринятый способ публикации информации о грид-ресурсах, принятый консорциумом грид-проектов, в состав которого входят EGEE, OSG, Australian Partnership for Advanced Computing и Nordic DataGrid Facility. Схема описывает атрибуты грид-сайтов и сервисов, вычислительных элементов и элементов памяти. Различные реализации схемы GLUE осуществлены для ряда систем, таких как LDAP (система доступа к директориям), R-GMA (система мониторинга) и для языка XML.
GLUE-схема делает возможной интерактивность грид-проектов благодаря унифицированному представлению состояния грид-служб и ресурсов. Первоначально схема GLUE была выдвинута трансатлантическим исследовательским проектом DataTAG и международной грид-лабораторией виртуальных данных (International Virtual Data Grid Laboratory), позже она была поддержана многими ведущими грид-проектами.
С точки зрения WMS важна возможность получать информацию о доступных
в данный момент ресурсах. Эта информация, в частности, включает:
сайты (CE), способные выполнить данное задание, их загрузка, ПО, установленное на них;
сайты, предоставляющие возможности для хранения данных, включая их статус, максимальный размер и число файлов, которые могут быть сохранены.
данные мониторирования процесса выполнения задания.
Примерами атрибутов GLUE-схемы для описания состояния вычислительных ресурсов являются:
GlueCEUniqueID - уникальный идентификатор вычислительного элемента (CE);
GlueCEStateRunningJobs - число заданий, выполняющихся на данном CE;
GlueCEStateWaitingJobs - - число заданий в состоянии ожидания на данном CE.
В Приложении 1 представлена полная GLUE-схема (версия 1.3) для описания вычислительных ресурсов.
3.1.2Описание запросов на запуск заданий в определенных средах исполнения
Запросы на выполнения задачи (задания) пользователя в среде ГРИД оформляются в файле задания, который указывается в параметре запуска задания в ГРИД, файл состоит из команд на Языке Описания Задания (Job Description Language - JDL) [7], которые описывают:
что надо передать для выполнения;
из каких файлов программ и локальных данных состоит задание;
каким условиям должны удовлетворять вычислительные ресурсы, непосредственно выполняющие задание - эта часть основана на описании ресурсов с помощью GLUE-схемы, описанной в предыдущем разделе.
В процессе обработки задания на интерфейсе пользователя условия выполнения и соответствующие файлы упаковываются во входную песочницу (контейнер) задания (Input Sandbox) и передаются сервису регистрации и учета, который после первичной регистрации задания предает его подсистеме управления загрузкой (WMS) для возможного выполнения. Выходные данные задания упаковываются в выходную песочницу (контейнер) задания (Output Sandbox) и возвращаются пользователю.
Кроме того, выходными данными являются сообщения информационной системы: о текущем статусе задачи; сведения о наличие в грид-системе каких-либо данных; отчет о прохождении задачи; список ресурсов, имеющихся и доступных в данный момент в грид-системе. Входные и выходные данные информационной системы являются текстовыми строками, возможно с использованием специальных символов для задания поиска по маскам, или по регулярному выражению.
3.1.2.1 Язык описания заданий (Job Description Language, JDL)
Файл описания задания на языке JDL (Язык Описания Заданий) является ключевым для отсылки задания в грид и правильного подбора ресурсов. Этот файл описывает необходимые входные данные, генерируемые выходные данные, и требования к ресурсам. Ниже приведен типичный пример файла описания задания:
[
Type = "Job";
JobType = "Normal";
Executable = "myexe";
StdInput = "myinput.txt";
StdOutput = "message.txt";
StdError = "error.txt";
InputSandbox = {"/users/pacini/example/myinput.txt",
"/users/pacini/example/myexe"};
OutputSandbox = {"message.txt", "error.txt"};
DataAccessProtocol={"gsiftp"};
Requirements = other.GlueCEInfoLRMSType == "PBS";
Rank = other.FreeCPUs;
]
Такой JDL-файл обеспечивает передачу выполнимого файла myexe на удаленный CE, на котором очередь управляется PBS-системой, и будет исполняться с использованием файла myinput.txt (также переданного с компьютера ИП) в качестве входных данных. Стандартные потоки задания переадресовываются на рабочем узле в файл message.txt и error.txt и могут быть позднее получены на WMS-UI посредством команды glite-job-output.
Значение части параметров, использованных в этом примере, указаны в Таблице 1.
Таблица 1. Ключевые параметры языка JDL
Executable="executable_file_name"
|
Имя исполняемого файла
|
StdOutput="std.out";
|
Имя файла стандартного вывода
|
StdError="std.err";
|
Имя файла стандартного вывода сообщений об ошибках
|
InputSandbox={"example.pl"};
|
Список файлов передаваемых на CE перед запуском задания
|
OutputSandbox={"std.out","std.err"};
|
Список файлов передаваемых пользователю после выполнения задания
|
InputData={"lfn:example_values"};
|
Параметр, указывающий подсистеме планирования заданий использовать (по возможности) CE, ближайший к указанным данным.
|
DataAccessProtocol={"gsiftp"};
|
Тип протокола, используемого при передачи файлов.
|
Полный список ключевых параметров приведен в документе http://server11.infn.it/workload-grid/docs/DataGrid-01-TEN-0142-0_2.pdf
Для системы запуска заданий, подготовленных для различных сред исполнения, важными являются атрибуты, позволяющие определить требования для вычислительного элемента, который должен быть найден менеджером загрузки для исполнения данного задания. Синтаксис таких требований выглядит следующим образом
Requirements = other.OpSys == "RH 6.2" && other.Arch == "INTEL";
Заметим, что префикс other. показывает, что требование относится к рабочему узлу -кандидату на выполнения задания. В случае, если префикс не указан, подразумевается значение по умолчанию - “self.”, указывающее на то, что требование относится к заданию.
Параметры Requirements и Rank влияют на подбор ресурсов для данного задания. Значение для параметра Requirements определяет ограничения на ресурсы, необходимые для выполнения задания. В вышеприведенном примере, требуется сайт, на котором установлена система PBS, и задание будет направлено только на ресурс, который удовлетворяет этому условию. Если более чем один ресурс соответствует требованиям задания, то используется параметр Rank, чтобы определить, какой из ресурсов является наиболее подходящим (чем выше значение Rank - тем лучше ресурс). Значения параметров Requirements и Rank могут быть произвольными выражениями, соответствующими параметрам, которые ресурсы публикуют в информационной системе грида.
В следующем разделе мы рассмотрим атрибут Requirements подробнее, поскольку он будет ключевым для запроса определенной среды исполнения заданий.
3.1.2.2 Параметры для запроса среды исполнения
Как уже отмечалось, требования к ресурсам определяются значениями атрибута Requirements в JDL-описании задания. Значениями этого атрибута являются булевы выражения, которые определяет необходимые ограничения. Поддерживается почти полный набор операторов и синтаксис языка C.
Например, чтобы выразить, что задание требует по крайней мере 25 минут процессорного времени и 100 минут реального времени, используется выражение:
Requirements = other.GlueCEPolicyMaxCPUTime >= 1500 && \ other.GlueCEPolicyMaxWallClockTime >= 6000;
(время задается в секундах).
Иногда бывает желательно исключить или включить сайт (ресурсный центр) вручную. При использовании ППО gLite это можно сделать либо с помощью соответствующей опции команды glite-job-submit, либо с помощью задания параметра Requirements в JDL-файле:
Requirements = other.GlueCEUniqueID == "ccgridli03.in2p3.fr:2119/jobmanager-bqs-A";
Важно, что последний способ является значительно более гибким, поскольку можно использовать механизм регулярных выражений. Например:
Requirements = RegExp(".*nikhef.*",other.GlueCEUniqueID);
Requirements = (!(RegExp(".*nikhef.*",other.GlueCEUniqueID)));
(чего нельзя сделать с помощью опции glite-job-submit).
Если больше чем один ресурс соответствует указанным требованиям, то будет использоваться ресурс с наивысшим рангом. Когда атрибут Rank не определен в пользовательском JDL-файле, то по умолчанию добавляется:
Rank = - other.GlueCEStateEstimatedResponseTime ;
(это определено в файле конфигурации интерфейса пользователя). Это означает, что ресурсы ранжируются по времени, в течение которого задание ожидает начала выполнения в локальной пакетной системной очереди на ресурсном сайте. Такое ранжирование не всегда идеально, и пользователь может пожелать выбрать некоторые другие критерии для ранжирования. Например,
Rank = other.GlueCEStateFreeCPUs ;
заставит WMS выбрать сайт с наибольшим числом свободных процессоров.
Чем выше ранг, тем более подходящим считается ресурс. Если несколько сайтов имеют одинаковый ранг, то брокер ресурсов выбирает один из них случайным образом.
Таким образом, указание, что задание должно быть выполнено на конкретном грид-сайте, на котором установлена система запуска заданий в грид-систему для различных сред исполнения, должно быть задано следующим образом:
Requirements = other.GlueCEUniqueID == "grid.sinp.msu.ru:2119/jobmanager-vres";
Первая часть указания (grid.sinp.msu.ru:2119) определяет сайт и порт CE, а вторая часть (jobmanager-vres) указывает, что обработчиком заданий на сайте должна быть служба предоставления сред исполнения (СПСИ) по запросам пользователей (использована англоязычная аббревиатура VRES - Virtual Runtime Environment Service).
Если задание должно быть выполнено на любом сайте со службой предоставления сред исполнения, то должен быть использовано механизм регулярных выражений. Например:
Requirements = RegExp(".*jobmanager-vres",other.GlueCEUniqueID);
Конкретный тип требуемой среды задается выражением, например:
Requirements =
Member("VEE-WindowsXP",other.GlueHostApplicationSoftwareRunTimeEnvironment);
Функция Member возвращает значение “true”, если тэг VEE-WindowsXP является членом списка other.GlueHostApplicationSoftwareRunTimeEnvironment.
В соответствии с синтаксисом JDL, все требования должны быть объединены с помощью булевских операций. Например,
Requirements = RegExp(".*jobmanager-vres",other.GlueCEUniqueID) &&
Member("VEE-WindowsXP",other.GlueHostApplicationSoftwareRunTimeEnvironment);
3.1.2.3 Пример JDL-файла
Ниже приведен пример файла описания заданий, которое должно быть выполнено в ресурсном центре со службой предоставления сред исполнения и на рабочем узле, где будет выполняться задание должна быть развернута операционная система WindowsXP:
[
JobType=“Normal”;
Executable = “gridTest”;
StdError = “stderr.log”;
StdOutput = “stdout.log”;
InputSandbox = {“/home/mydir/test/gridTest”};
OutputSandbox = {“stderr.log”, “stdout.log”};
InputData = {“lfn:/glite/myvo/mylfn” };
DataAccessProtocol = “gridftp”;
Requirements = RegExp(".*jobmanager-vres",other.GlueCEUniqueID) &&
Member("VEE-WindowsXP",other.GlueHostApplicationSoftwareRunTimeEnvironment);
Rank = other.GlueCEPolicyMaxCPUTime;
]
|
