Способы определения действий в узлах графа исполнения - Повышение производительности работы библиотеки GridMD

Библиотека GridMD поддерживает три механизма определения действий, связываемых с узлами графа [8]. Узел графа может соответствовать исполнению стороннего приложения с помощью скрипта командной оболочки. Пользователь определяет исполняемый скрипт узла графа и его входные параметры с помощью конфигурационных функции менеджера сценариев. Другим механизмом является Явное определение связанных с узлами действий с помощью наследования от класса GmNodeAction и переопределения его метода OnExecute(). Экземпляр класса GmNodeAction передается в конфигурационную функцию Set_node_action() Менеджера сценариев, где происходит связывание действия, определенного внутри функции OnExecute(), с конкретным узлом графа. Необходимо отметить, что в случае с распределенным исполнением таких узлов требуется наличие Сервера функций На каждой из машин, исполняющих узлы. Сервер функций хранит реализацию всех классов наследников GmNodeAction и позволяет создать экземпляр нужного класса по его имени при запросе от клиентского приложения на исполнение конкретного узла. В большинстве случаев копия клиентского приложения в режиме исполнения графа, содержащая код реализации классов наследников GmNodeAction может служить сервером функций. Тогда при запуске сервера функций ему будут указаны требуемые узлы для исполнения в виде параметров командной строки.

Последним механизмом определения действий, связываемых с узлами графа, является Неявное Определение [9]. При использовании этого механизма пользователем определяется Встроенный Код действий узлов, оборачиваемый в условные конструкции проверки возвращаемого значения функции Node() (Листинг 1). В режиме конструирования графа функция Node() возвращает False, и узел графа конструируется исходя из параметров, передаваемых в функцию, таких как родительские узлы и тип связей с ними. В режиме исполнения графа функция возвращает True для запрашиваемого узла, идентификатор которого передается в качестве параметра командной строки. Тогда возможно исполнение Встроенного кода для запрашиваемого узла и код клиентского приложения выступает в качестве сервера функций. Такое поведение реализуется с помощью рекурсивного вызова функции Gridmd_main(), поэтому именно в ней должен быть определен встроенный код для каждого из узлов. Использование встроенного кода позволяет реализовывать небольшие распределенные сценарии исполнения без необходимости создания отдельных классов или процедур.

Менеджер заданий отвечает за выполнение узла графа на локальной или удаленной машине [10]. Общая последовательность действий менеджера заданий при исполнении узла состоит из загрузки входных файлов на вычислительный ресурс, отправки запроса вычислительному ресурсу на исполнение задачи, мониторинга состояния задачи во время исполнения и получения результатов исполнения узла. Задача для менеджера заданий представляется объектом класса GmJob, Который хранит информацию о входных и выходных данных, исполняемых командах, требуемом числе процессоров и других метаданных о контексте исполнения задачи. В состав задачи входит исполнение одного или нескольких узлов графа, в случае если они связаны Жесткой связью, Или планировщик упаковал их в одну задачу для минимизации издержек по передаче данных. При исполнении приложения менеджер сценариев автоматически создает задачи и контролирует работу менеджера заданий, однако пользователь может работать с менеджером заданий отдельно в ручном режиме, создавая и конфигурируя объекты GmJob, и делая запросы менеджеру заданий на их обработку с помощью его интерфейсных функций.

Перед запуском GridMD приложения необходимо сконфигурировать его работу с вычислительными ресурсами с помощью файла Resources. xml [2]. Пользователь обязан сконфигурировать возможные Типы вычислительных ресурсов и Способы доступа к ним. В качестве типа вычислительного ресурса могут выступать Системы управления заданиями - внешние программные пакеты, установленные на головной машине кластера или грида и обеспечивающие выделение ресурсов и управление программами пользователей, так и командный интерпретатор локальной операционной системы. Библиотека GridMD предоставляет интерфейс к каждому из типов вычислительных ресурсов в виде отдельных классов менеджеров заданий - наследников базового класса GmJobManager. Например, в GridMD реализованы менеджеры заданий GmPBSManager и GmSLURMManager для работы с системами управления заданий PBS, SLURM, а так же класс GmBshManager для локального и удаленного исполнения задач в bash shell. Способы доступа в GridMD реализуют Классы протоколы доступа. В данный момент поддерживается протокол SSH для удаленного исполнения узлов, и разные классы, отвечающие за доступ к удаленной системе, по-разному реализуют работу с ним. Одним из вариантов является запуск сторонних утилит ssh, scp для Unix и plink, pscp для Windows из GridMD приложения, другим - работа с помощью кроссплатформенной библиотеки libssh. Классы протоколы доступа выполняют низкоуровневую работу по передаче и преобразованию файлов, управлению каталогами пользователя, и выполнению отдельных команд по настройке вычислительного ресурса для исполнения пользовательских задач [10] .

Пример файла resources. xml изображен пример файла resources. xml, в котором пользователь конфигурирует доступные Ресурсы. Ресурсом в контексте GridMD называется совокупность настроек менеджера заданий конкретного типа и протокола доступа к вычислительному ресурсу. Настройки указываются пользователем в тегах <session> и <job_manager> соответственно. Для конфигурирования работы с вычислительными ресурсами необходимо вызвать метод объекта менеджера сценариев GmManager::load_resources() с передачей пути к конфигурационному файлу в качестве параметра на этапе конфигурирования приложения. Тогда менеджер сценариев автоматически настраивает и распределяет выполнение создаваемых им задач на сконфигурированных ресурсах. Пользователь может явно привязать выполнение узла графа к конкретному вычислительному ресурсу.

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

Похожие статьи




Способы определения действий в узлах графа исполнения - Повышение производительности работы библиотеки GridMD

Предыдущая | Следующая