Использование технологий MPI и OpenMP в кластерных системах с локальными менеджерами ресурсов

Д. С. Кастерин, М. М. Степанова

ИСПОЛЬЗОВАНИЕ ТЕХНОЛОГИЙ MPI И OPENMP В КЛАСТЕРНЫХ СИСТЕМАХ С ЛОКАЛЬНЫМИ МЕНЕДЖЕРАМИ РЕСУРСОВ*

Введение. Параллельные вычислительные системы характеризуются типом организации памяти как системы с распределённой (MPP) или разделяемой/общей (SMP) памятью [1]. Эффективность использования параллельной системы определяется программным обеспечением, учитывающим особенности её архитектуры. Широкое применение для создания прикладных параллельных программ получила технология MPI, разработанная для MPP-систем [2]. В программах, ориентированных на SMP-системы, оптимальным является применение стандарта OpenMP [3]. Современные кластеры строятся из узлов с многоядерной архитектурой и позволяют выполнять приложения, использующие MPI и OpenMP, а также гибридные приложения, использующие обе эти технологии.

Для эффективной эксплуатации кластера необходимо обеспечить единую точку входа для пользователей и контроль ресурсами. Эти функции выполняются системой пакетной обработки или локальным менеджером ресурсов. В настоящее время известно более 20 систем кластерного управления (например, SGE, PBS/Torque, Condor, SLURM), каждая из которых в конкретных условиях эксплуатации имеет свои плюсы и минусы.

Запуск параллельных приложений через систему очередей требует от менеджера ресурсов нетривиальных решений при выделении и учёте ресурсов, используемых программой, в частности обеспечения сбалансированного распределения процессов/потоков по узлам.

Целью работы является анализ возможностей менеджеров ресурсов Sun Grid Engine [4] и PBS/Torque [5] в отношении обеспечения полного контроля прохождения заданий, использующих технологии MPI и OpenMP. Это две наиболее популярные системы, которые допускают бесплатное использование в некоммерческих целях.

Аппаратное и программное обеспечение. В работе использовалось следующее оборудование:

• сервер a5-216.tut, P4 CPU 1,50 ГГц, 1 Гб RAM;

• вычислительный узел gek.tut, P4 CPU 1,50 ГГц, 512 M6 RAM;

• вычислительный узел w1.tut, 2 x Xeon 3,0 ГГц (Dual Core, HTT) EM64T, 4 Гб RAM.

Узлы обьединены в сегмент с помощью сети Ethernet 100 Mбит/с. Компьютеры работают под управлением ОС Scientific Linux 5.2. Были установлены следующие пакеты:

• Sun Grid Engine v6.1u6 (бинарные пакеты [9] для архитектур x86 и x86_64);

• Torque v2.2.1 (сборка из исходных кодов [10] с указанием дополнительных опций);

• Maui v3.2.6 (сборка из исходных кодов [11] с указанием дополнительных опций);

• По материалам доклада на юбилейном семинаре «Вычислительная физика» 29—30 октября 2009 г., С.-Петербург.

© Д. С. Кастерин, М. М. Степанова, 2010

• MPICH2 v1.0.8 (сборка из исходных кодов [12] с указанием дополнительных опций);

• SGE-MPICH2 Integration scripts [13];

• Mpiexec v0.83 (сборка из исходных кодов [14] с указанием дополнительных опций).

MPI и локальные менеджеры ресурсов. Для запуска MPI-приложений на кластере без менеджера ресурсов при использовании пакета MPICH2 пользователю потребуется:

• выполнить запуск с помощью команды mpdboot менеджеров процессов mpd на узлах, заданных в файле mpd.hosts;

• осуществить запуск задания командой mpiexec;

• при необходимости завершения mpd вызвать команду mpdallexit.

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

Поскольку утилита mpdboot осуществляет доступ на узлы по протоколам rsh/ssh, процессы заданий не будут являться дочерними процессами демона, работающего на вычислительном узле. Это не повлияет на сам процесс вычислений, но, во-первых, оценка используемых ресурсов будет произведена неправильно, во-вторых, если в случае какой-либо ошибки часть процессов не будет корректно завершена, администратору потребуется вручную разобраться в ситуации.

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

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

Решение проблемы контроля процессов параллельных заданий для SGE основано на использовании механизма параллельных окружений вместе с дополнительным пакетом скриптов интеграции SGE и MPICH2.

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

процессам и настроить пути к исполняемым файлам, выполняемым перед стартом/после завершения основного задания.

Основное отличие этого метода от спотоба, описанного в предыдущем разделе, заключается в использовании специальной утилиты удаленного доступа qrsh [6], входящей в состав пакета SGE. В отличие от стандартных утилит rsh и ssh при её использовании все запросы проходят через сервер и процессы задания надлежащим образом учитываются в системе SGE.

В Torque проблема контроля процессов параллельных заданий может быть решена с помощью внешней утилиты Mpiexec [7]. Она полностью заменяет собой утилиты mpiexec/mpirun из состава пакета MPICH2. Среди её достоинств необходимо отметить следующие:

• поддержка большого количества реализаций MPI;

• возможность использования библиотеки PMI при сборке с поддержкой MPICH2, при этом отпадает необходимость в демонах mpd на вычислительных узлах;

• использование библиотеки tm, что обеспечивает корректный запуск и завершение всех процессов заданий на вычислительных узлах.

Mpiexec позволяет менеджеру ресурсов Torque корректно обрабатывать параллельные задания, использующие технологию MPI.

OpenMP и локальные менеджеры ресурсов. Для запуска OpenMP-заданий требуется только поддержка потоков операционной системой вычислительного узла. Этому требованию удовлетворяют все современные ОС.

Число рабочих потоков, используемых заданием, может быть явно определено переменной окружения OMP_NUM_THREADS, вызовом функции omp_set_num_threads и/или указанием опции num_threads в тексте программы. В двух последних случаях информация о числе используемых потоков доступна только внутри программы. Если число потоков не задается явно, система для выполнения параллельных секций программы создаёт по одному потоку на каждое ядро процессора [8].

В коде программ, создаваемых для работы на кластерах с системой очередей, следует избегать явного указания числа потоков вызовом функции omp_set_num_threads и заданием опции num_threads. В этих случаях менеджер ресурсов не имеет возможности правильно оценить ресурсы, которые реально займёт приложение, и может разрешить одновременное выполнение другой программы, что с большой вероятностью вызовет катастрофическое падение производительности. Кроме того, фиксация числа потоков в тексте программы приводит к потере масштабируемости приложения, а при неоптимальном выборе числа исполняющих потоков производительность приложения снижается.

Технологии MPI и OpenMP принципиально различны, и методы, используемые в средствах контроля MPI-заданий, не будут иметь эффекта при запуске OpenMP-задания через систему очередей.

В SGE для контроля OpenMP-заданий используется механизм параллельных окружений. Параллельное окружение настраивается таким образом, чтобы каждому OpenMP-заданию выделялись процессоры на одном вычислительном узле. К сожалению, реализация механизма параллельных окружений не позволяет установить переменную OMP_NUM_THREADS автоматически, это приходится делать пользователю. Если случайно или умышленно им будет указано неправильное значение, это нарушит учёт используемых заданием ресурсов.

В Torque отсутствуют какие-либо специальные средства контроля OpenMP-заданий, кроме установки переменной окружения OMP_NUM_THREADS. Установка данной переменной окружения осуществляется пользователем, что требует от него некоторых знаний об архитектуре кластера.

Заключение. В ходе работы изучены и проанализированы возможности менеджеров ресурсов SGE и Torque с точки зрения обеспечения контроля прохождения параллельных заданий, использующих технологии MPI и OpenMP. В результате:

1. Разработаны и реализованы варианты конфигурации менеджеров SGE и Torque, обеспечивающие полный контроль прохождения MPI-заданий, что позволяет добиться максимальной эффективности использования кластера. Для этого в SGE использовался механизм параллельных окружений, а в Torque - сторонняя утилита Mpiexec. Предложенная реализация требует минимальных усилий от администратора и позволяет прозрачно для пользователей контролировать использование ресурсов при выполнении параллельных MPI-заданий.

2. Для контроля OpenMP-заданий в менеджерах SGE и Torque реализована конфигурация, основанная на применении специальной переменной окружения, которая позволяет задавать количество потоков, используемых в параллельных участках приложения. Следует отметить, что это потребует от пользователей некоторых знаний об архитектуре кластера.

По итогам проделанной работы можно сделать вывод, что на сегодняшний день из менеджеров ресурсов SGE и Torque нельзя однозначно выбрать лучший. Каждый имеет свои сильные и слабые стороны: SGE очень хорошо подходит для запуска OpenMP-заданий, а использование Torque в комбинации с Mpiexec является наиболее простым способом обеспечить контроль MPI-заданий.

Литература

1. URL: http://www.parallel.ru/computers/classes.html.

2. Антонов А. С. Параллельное программирование с использованием технологии MPI: Учеб. пособие. М., 2004. Т1 c.

3. Антонов А. С. Параллельное программирование с использованием технологии OpenMP: Учеб. пособие. М., 2009. ТТ c.

4. URL: http://gridengine.sunsource.net/.

б. URL: http://www.clusterresources.com/products/torque-resource-manager.php.

6. Sun N1 Grid Engine 6.1 User’s Guide, p. Т6. URL: http://dlc.sun.com/pdf/820-0699/820--0699.pdf, http://docs.sun.com/app/docs/coll/1017.4.

Т. URL: http://www.osc.edu/djohnson/mpiexec/index.php.

8. OpenMP Application Program Interface, v 3.0, May 2008. URL: http://www.openmp.org/ mp-documents/spec30.pdf.

9. URL: http://gridengine.sunsource.net/downloads/61/download.html.

10. URL: http://www.clusterresources.com/downloads/torque/torque-2.2.1.tar.gz.

11. URL: http://www.clusterresources.com/product/maui.

12. URL: http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/1.0.8/ mpich2-1.0.8.tar.gz.

13. URL: http://gridengine.sunsource.net/howto/mpich2-integration/mpich2-62.tgz.

14. URL: http://www.osc.edu/djohnson/mpiexec/mpiexec-0.83.tgz.

Статья поступила в редакцию 19 марта 2010 г.