zabika.ru 1

Использование методологии ГРИД для управления

жизненным циклом программных систем

А.С. Шундеев

Научно-исследовательский институт механики МГУ
имени М.В. Ломоносова (НИИ механики МГУ)

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

1. Введение


Проведенный анализ [1] развития технологии ГРИД [2] позволяет выделить два программных проекта, оказавших существенное влияние на данную технологию. Первый проект связан с созданием инструментального комплекса Globus Toolkit [3], а второй   с созданием программного комплекса Condor [4]. Основной областью применения технологии ГРИД выступают распределенные высокопроизводительные вычисления. Ключевыми объектами выступают пакетная программа и система выполнения пакетных программ. При этом, в качестве системы выполнения пакетных программ может выступать как отдельная рабочая станция, так и суперкомпьютер.

Каждый из обозначенных программных проекта привнес в технологию ГРИД свои уникальные решения. Так в рамках Globus Toolkit были разработаны механизмы GRAM и GridFTP, первый из которых представляет собой универсальный адаптер (реализует универсальный интерфейс) для широкого класса систем выполнения пакетных программ, а второй   представляет собой безопасное и надежное решение для передачи данных.

Изначально проект Condor был ориентирован на объединение вычислительных ресурсов, предоставляемых отдельными рабочими станциями. Подобное сужение класса целевых вычислительных ресурсов позволило эффективно выработать и апробировать на практике механизмы планирования и диспетчеризации вычислительных заданий. На момент становления рассматриваемых программных проектов о них можно было говорить как об отдельных направлениях в рамках ГРИД.


Первая попытка совмещения направлений Globus Toolkit и Condor была выполнена в рамках программного средства Condor-G [5]. Для пользователей Condor это предоставило возможность расширить класс доступных для использования систем выполнения пакетных программ. Было также найдено решение, устранявшее имевшуюся «недоработку» в механизме GRAM   операции по предварительному выделению (захвату) ресурса и его непосредственному использованию не были разделены. На сегодняшний день наиболее эффективные инструментальные средства построения ГРИД-систем базируются на интеграции отдельных компонентов из Globus Toolkit и Condor. В качестве примера можно привести инструментальный комплекс Virtual Data Toolkit, сопровождаемый в рамках проекта Open Science Grid [6].

Ряд выработанных в рамках технологии ГРИД архитектурных решений, касающихся диспетчеризации и планирования вычислительных заданий, напрямую не связан с выполнением именно пакетной программы. Запуск пакетной программы в рамках вычислительного задания может быть заменен на запуск веб-сервиса или на выполнение операций по управлению им. Таким образом, возникает подход к управлению жизненным циклом [7] распределенных программных систем, базирующийся на методологии ГРИД.

Настоящий доклад посвящен описанию данного подхода.

2. Управление жизненным циклом


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

Система управления жизненным циклом (далее   управляющая система) также представляет собой распределенную программную систему. Компоненты управляющей системы (далее   управляющие компоненты) запускаются в виде отдельных процессов операционной системы и предоставляют для взаимодействия интерфейс RESTful веб-сервиса. На одном сервере одновременно может быть развернуто несколько управляющих компонентов. Управляющий компонент соответствует серверу Condor, а также фабрике ГРИД-сервисов в открытой инфраструктуре ГРИД-сервисов [10].


Основная операция управляющего компонента заключается в запуске процесса операционной системы, а также перенаправление стандартных потоков ввода/вывода в подсистему мониторинга управляющего компонента. Это является аналогом механизма shadow стандартного вычислительного пространства (standart universe) Condor. К запуску процессов операционной системы сводятся как непосредственно запуск и инициализация (например, задание порта) RESTful веб-сервиса, так и изменение его состояние (например, безопасное завершение работы).

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

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

Интерфейс управляющего компонента содержит следующие методы:


  • загрузка / удаление данных (например, исполняемых файлов);

  • запуск / остановка / автоматический перезапуск целевого веб-сервиса (группы веб-сервисов);

  • получение актуальной информации о запущенных целевых веб-сервисах (состояние, содержимое потоков ввода/вывода);

  • обновление и миграция веб-сервиса;

  • проверка инфраструктуры развертывания.

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


После успешного запуска и инициализации обновленной (перемещенной) копии целевого веб-сервиса служебный прокси-сервис перенаправляет поток запросов на копию. После того, как принимается решение о том, что все запросы устаревшего целевого веб-сервиса были выполнены, он останавливается.

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

3. Сценарий эксперимента


Для апробации предложенного подхода осуществлялся эксперимент со следующим сценарием. Тестовый полигон состоял из двух серверов, на которых были запущены управляющие компоненты. Были приготовлены исполняемые файлы для двух тестовых RESTful веб-сервисов. В качестве первого была выбрана существующая система управления базами данных MongoDB [9]. Через второй веб-сервис осуществляются запросы к MongoDB и преобразование получаемых ответов. Рассматривались только поисковые запросы (HTTP GET). Далее, по этапам реализовывался следующий сценарий:

  1. загрузка исполняемого файла MongoDB, файлов тестовой базы данных, исполняемого файла второго веб-сервиса через первый управляющий компонент;

  2. запуск целевых веб-сервисов через первый управляющий компонент, проверка работоспособности целевой системы;

  3. миграция MongoDB на второй управляющий компонент, проверка работоспособности целевой системы;

  4. миграция второго веб-сервиса на второй управляющий компонент, проверка работоспособности целевой системы;

  5. остановка целевой системы;

  6. удаление данных тестовых веб-сервисов из управляющей системы.

4. Заключение

В работе был рассмотрен подход к управлению жизненным циклом распределенных программных систем, базирующийся на методологии ГРИД. Подход охватывает управление этапами жизненного цикла, относящимися к процессам поставки, эксплуатации, сопровождения, создания инфраструктуры и управления конфигурацией в соответствии со стандартом [7]. В основу подхода были положены архитектурные решения, выработанные в рамках проекта Condor, к числу которых можно отнести следующие: использование языка для описания требований к вычислительным ресурсам (ClassAds), алгоритмы сопоставления (matchmaking) между требуемыми ресурсами (planning) и доступными (scheduling), миграция вычислительных заданий, использование стандартного вычислительного пространства (standart universe) и управление композитными заданиями (DagMan).


Схожие архитектурные решения разрабатывались в рамках создания открытой инфраструктуры [10] и архитектуры [11] ГРИД-сервисов, которые относятся к направлению Globus Toolkit. Выбор в пользу Condor был сделан по причине того, что вопросы планирования и диспетчеризации вычислительных заданий в рамках данного проекта были наиболее полно проработаны и апробированы.

Литература


Васенин В.А., Шундеев А.С. Эволюция технологии ГРИД // Сборник научных трудов второй научно-практической конференции «Актуальные проблемы системной и программной инженерии». Московский государственный университет экономики, статистики и информатики, 2011. с. 124-128.

Foster I., Kesselman C., Tuecke S. The Anatomy of the Grid: Enabling Scalable Virtual Organizations // International J. Supercomputer Applications 2001. V. 15. N. 3. pp. 200-222.

Foster I., Kesselman C. Globus: A metacomputing intrastructure toolkit // International Journal of Supercomputer Applications 1997. V. 11. N. 2. pp. 115-128.

Thain D., Tannenbaum T., Livny M. Distributed Computing in Practice: the Condor Experience // Concurrency and Computation: Practice and Experience 2005. V. 17 N. 2-4. pp. 323–356.

Frey J., Tannenbaum T., Foster I., Livny M., Tuecke S. Condor-G: A computation management agent for multi-institutional grids // Cluster Computing 2002. V. 5. pp. 237-246.

OSG Blueprint, http://osg-docdb.opensciencegrid.org/0000/000018/012/OSG Blueprint v2.0.pdf

ГОСТ Р ИСО/МЭК 12207:1999 Информационная технология. Процессы жизненного цикла программных средств. М.: ГОССТАНДАРТ РОССИИ, 1999.

Fielding R.T. Architectural Styles and the Design of Network-based Software Architectures // Dissertation doctor of philosophy in Information and Computer Science. University of California 2000.

MongoDB, http://www.mongodb.org/

Banks T. et al. Open Grid Service Infrastructure Primer, http://www.gridforum.org/documents/GFD.31.pdf

Foster I. et al. The Open Grid Services Architecture, Version 1.5, http://www.ggf.org/documents/GFD.80.pdf

Nginx, http://nginx.org/