Система запуска заданий Slurm

В данном разделе описана работа с системой запуска заданий через ЛМР Slurm.

Предварительные требования

Перед тем как начать сборку и установку этой компоненты, следует установить и настроить пакеты Slurm и Munge, если они еще не установлены и не настроены.

Как правило, либой счетный узел может быть преобразован в шлюз стыка установкой и настройкой Globus-компонент, так как счетные узлы имеют все необходимые настройке для Slurm и Munge.

В данном разделе приводится информация специфичная, в значительной степени, для Slurm. Общую информацию по настройке и установке для всех типов ЛМР можно найти в разделе по Fork.

Установка

GRAM компоненты

Для установки стыка Slurm/GRAM вам нужно иметь установленный Globus Toolkit. Вы можете собирать стык как отдельный компонент или вы можете воспользоваться интегрированными исходными кодами стыка в исходный код Globus Toolkit (последние доступны только из репозитория РНЦ КИ; в репозитории svn.ngrid.ru их на данный момент нет).

Если компоненты стыка входят в загруженную вами версию Globus Toolkit, то сборку стыка можно произвести одновременно со сборкой всех компонентов GT (как описано в wiki:HowTo/GlobusToolkit/BasicInstall); к флагам configure нужно добавить "--enable-wsgram-slurm".

Если у вас еще не скомпилирован Globus Toolkit и вы хотите собирать компонент Slurm/GRAM отдельно, то вам будет нужно загрузить исходный код Globus Toolkit 4.2.1 и установить его так, как описано в wiki:HowTo/GlobusToolkit/BasicInstall.

NB: обратите внимание, что если происходит досборка на системе, где уже установлен Globus Toolkit и запущен WSGRAM (или другие WS сервисы), то на время сборки необходимо остановить контейнер WS.

Если вы пользовались исходными кодами с интегрированным адаптером Slurm/GRAM, то сборка завершена и можно переходить к настройке компонента.

Если вы хотите собрать адаптер Slurm/GRAM отдельно от Globus Toolkit, то вам нужно сделать следующие действия (при этом переменная GLOBUS_LOCATION должна быть установлена и указывать на место, куда был инсталлирован GLOBUS_TOOLKIT):

svn co https://svn.ngrid.ru/lrm-slurm/
cd lrm-slurm/trunk
for i in globus*slurm*.pch
do
  patch -p0 < $i;
done
(cd globus_gram_job_manager_setup_slurm; \
  sh ./bootstrap; \
  ./configure; \
  make; \
  make install)

(cd globus_scheduler_event_generator_slurm; \
  sh ./bootstrap; \
  ./configure --with-flavor=<flavor>; \
  make; \
  make install)

(cd globus_scheduler_event_generator_slurm_setup; \
  sh ./bootstrap; \
  ./configure; \
  make; \
  make install)

(cd globus_scheduler_provider_setup_slurm; \
  sh ./bootstrap; \
  ./configure; \
  make; \
  make install)

(cd globus_wsrf_gram_service_java_setup_slurm; \
  make install)

ToDo: проверить последний шаг с java_setup, и заменить шаги ./configure, make, make install на gpt-build, предложить патч для cleo на эту тему.

Дополнительная обвязка

Если нет возможности поставлять журнал работы Slurm до стыка, рекомендуется использовать модуль генераци PBS-совместимого журнала. Кроме того, подобный модуль может понадобиться в случае изменения формата отладочных записей, генерируемых Slurm в журнал. Сама обвязка устанавливается rpm пакетом, собрать который можно из патча, доступного на svn.ngrid.ru:

patch -p0 < slurmsegfake.pch
tar cvzf slurm-seg-fake-0.1.3{.tar.gz,}
rpmbuild -ta slurm-seg-fake-0.1.3.tar.gz
rpm -Uvh /usr/src/redhat/RPMS/x86_64/slurm-seg-fake-0.1.3-1.x86_64.rpm

Генератор событий планировщика (SEG)

Генератор событий на основе журнала Slurm

(Недоступен; стадия разработки: практически написан, еще не тестировался) Для использования этого типа SEG, необходимо организовать доступность журнала Slurm с включенной отладочной печатью. Без использования "фильтров" объем генерируемой информации может быть весьма интенсивен.

Генератор псевдо-журнала

Данный SEG использует стандартный PBS совместимый SEG модуль и генератор псевдожурнала, на основе опроса очереди Slurm. Этот вариант подходит в случае невозможности по различным причинам доставлять журнал Slurm на узел-шлюз. Недостатками этого метода являются невозможность вести аккаунтиг с точностью выше частоты опроса очереди и невозможность определить точные причины отсутствия задачи в очереди (завершилась корректно/некорректа, была "выкинута" из-за сбоя и т.п.)