Проект

Общее

Профиль

Руководство пользователя кластера OpenPOWER ВЦ ДВО РАН

Версия: 0.4
Дата: 16.11.2017
Значимые обновления в руководстве и ответы на часто задаваемые вопросы вынесены на отдельные страницы.

 
 
Данное руководство содержит минимально необходимый объем информации для работы на гибридном кластере ВЦ ДВО РАН: описание процесса регистрации, сведения по работе в ОС Linux (вход в систему, работа с каталогами и файлами, мониторинг) и работе с MPI программами и непараллельными программами на кластере (компиляция, запуск, остановка, работа с очередями). В тексте под термином параллельная программа подразумеваются только MPI программы.

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

Вопросы относительно работы кластера следует отправлять на e-mail: .

Вопросы относительно этого документа (ошибки, неточности, предложения) можно отправлять на e-mail: .

Описание системы

Гибридный вычислительный кластер состоит из одного управляющего и четырех вычислительных узлов. Все они представляют собой серверы Sitonica PW22LC (IBM Power Systems S822LC 8335-GTB). Каждый включает в себя два процессора IBM POWER8 с максимальной частотой 4,023 ГГц, два сопроцессора NVIDIA Tesla P100 GPU, 256 ГБ DDR4 ОЗУ, контроллер EDR InfiniBand и два жестких диска Seagate ST1000NX0313 1 ТБ 7200RPM. Для хранения пользовательских данных используется внешнее дисковое хранилищу объемом 50 ТБ. В качестве сети управления используется сеть, построенная по технологии Gigabit Ethernet. В качестве сети передачи данных используется сеть EDR InfiniBand с пропускной способностью в 100 Гбит/с.

Регистрация

Регистрация пользователей на кластере происходит через систему ЦКП http://ckp.ccfebras.ru.

Вход в систему

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

При первом входе в систему предлагается сменить пароль. Обратите внимание, что перед вводом нового пароля в строке (current) LDAP Password: необходимо ввести еще раз текущий пароль. Требования к новому паролю: он должен быть достаточной длины, содержать хотя бы 1 цифру и 1 заглавную букву. Директория ~/.ssh содержит пару ключей (id_rsa и authorized_keys) для доступа к узлам кластера. При добавлении личного ssh-ключа, необходимо добавить открытый ключ в файл authorized_keys через перенос строки (т.е. после уже имеющегося одного открытого ключа).

Пользователи имеют возможность работать на кластере с любой машины, находящейся в сети института и интернет. Для входа в систему пользователю необходим адрес сервера (http://jupiter.febras.net), а также имя и пароль, полученные при регистрации.

Вход с Windows-машины

Работа с системой осуществляется по безопасному протоколу SSH при помощи какого-либо ssh-клиента. Клиент должен поддерживать протокол версии 2. Рекомендуется использовать PuTTY. Эта программа является свободно распространяемой и проста в использовании.

После запуска программы пользователь должен выбрать протокол ssh и в поле «Host Name (or IP address)» указать адрес сервера. Нажатие на «Open» приведет к отправке запроса на подключение. В случае успешного подключения к серверу будет предложено ввести имя (логин), а затем и пароль.

Окно ssh-клиента PuTTY

При вводе пароля символы на экране не отображаются. Если все введено правильно, то пользователь автоматически окажется в своей домашней директории. Этот каталог доступен пользователю с любого узла кластера.

Примечание. На кластере существует единое дисковое пространство для директорий /opt (только чтение) и /home. Все узлы используют дисковый массив сервера посредством сетевой файловой системы NFS. Файл записанный на одном из узлов кластера автоматически становится доступен на любом другом.

Работа в ssh-сессии происходит в терминальном (текстовом, консольном) режиме. Необходимо помнить, что консоль Linux, в отличии от Windows, различает регистр вводимых символов, то есть mydoc.txt и mydoc.TXT не одно и то же. После входа на экране отображается консоль командного интерпретатора в формате имя_пользователя@машина текущий_каталог:

[user@jupiter ~]$

Вход с терминала Linux

В любой дистрибутив ОС Linux входит терминальный ssh-клиент (обычно OpenSSH). Минимальный формат команды для подключения к кластеру таков:

[user@localhost ~]$ ssh jupiter.febras.net -l имя_пользователя

Копирование файлов

См. соответсвующий раздел руководства кластера версии 5.0.

Навигация

См. соответсвующий раздел руководства кластера версии 5.0.

Редактирование файлов

См. соответсвующий раздел руководства кластера версии 5.0.

Environment Modules

На кластере используется система модулей окружения (Environment Modules). Загруженные модули можно посмотреть с помощью команды:

[user@jupiter ~]$ module list
Currently Loaded Modulefiles:
  1) pbs            2) cuda           3) essl           4) spectrum_mpi

Указанные выше модули загружаются по умолчанию при входе в систему.

Список всех доступных модулей можно увидеть с помощью команды:

[user@jupiter ~]$ module avail

------------------------------------- /usr/share/Modules/modulefiles --------------------------------------
dot         module-git  module-info modules     null        use.own

-------------------------------------------- /etc/modulefiles ---------------------------------------------
cuda                      openmpi/gcc/2.0.2a1/4.8.5 openmpi/xl/2.0.2a1        pgi/2016
cudnn/5.1                 openmpi/gcc/2.1.0/4.8.5   openmpi/xl/2.1.0          pgi/2017
essl                      openmpi/pgi/1.10.2/2016   pbs                       spectrum_mpi
mpi/mvapich2-ppc64le      openmpi/pgi/1.10.2/2017   pgi/16.10(default)
openmpi/gcc/1.10.6/4.8.5  openmpi/xl/1.10.6         pgi/17.4

Компиляция программ

Доступные компиляторы

На кластере (на 21.07.2017) поддерживаются следующие компиляторы языков программирования для архитектуры ppc64le:

Компиляторы на кластере
Компилятор Файл компилятора Язык Модуль
GNU C 4.8.5 gcc C -
GNU C++ 4.8.5 g++ C++ -
GNU Fortran 4.8.5 gfortran Fortran 90 -
IBM XL Fortran 15.1.5 xlf/xlf_r* Fortran 77 -
IBM XL Fortran 15.1.5 xlf90/xlf90_r Fortran 90 -
IBM XL C 13.1.5 xlc/xlc_r C -
IBM XL C++ 13.1.5 xlc++/xlc++_r C++ -
PGI C 17.4 pgcc C pgi/17.4
PGI C++ 17.4 pgc++ C++ pgi/17.4
PGI Fortran 17.4 pgf90 Fortran pgi/17.4
NVIDIA Cuda 8.0.61 nvcc - cuda

* - файлы компиляторов IBM с постфиксом "_r" используются для сборки безопасных с точки зрения потоков исполняемых файлов.

Пути к компиляторам GNU и IBM XL прописаны в переменной окружения «PATH» для всех пользователей. Дополнительно в переменной среды «LD_LIBRARY_PATH» указаны пути к библиотекам этих компиляторов. Поэтому загружать какие-либо модули для их использования не нужно. Для использования остальных компиляторов необходимо подгружать соответствующие модули.

Компиляция MPI программ

На кластере (на 21.07.2017) поддерживаются следующие реализации библиотеки MPI:

Библиотеки MPI на кластере
Библиотека MPI Компилятор Модуль
IBM Spectrum MPI 10.1 GNU C/C++/Fortran 4.8.5 spectrum-mpi/gcc/10.1/4.8.5
IBM XL C/C++ 13.1.5 и Fortran 15.1.5 spectrum-mpi/xl/10.1/13.1-15.1
PGI С/C++/Fortran 17.4 spectrum-mpi/pgi/10.1/17.4
OpenMPI 2.0.2a1 GNU C/C++/Fortran 4.8.5 openmpi/gcc/2.0.2a1/4.8.5
IBM XL C/C++ 13.1.5 и Fortran 15.1.5 openmpi/xl/2.0.2a1
OpenMPI 1.10.2 PGI С/C++/Fortran 17.4 openmpi/pgi/1.10.2/2017

По умолчанию для всех пользователей установлены переменные среды, позволяющие использовать библиотеку Spectrum MPI совместно с компиляторами IBM XL (модуль spectrum-mpi/xl/10.1/13.1-15.1). Для использования остальных реализаций MPI, или при необходимости использования других компиляторов, нужно загрузить соответствующий модуль. В связи с тем, что все реализации MPI конфликтуют между собой, перед загрузкой нового модуля необходимо выгружать текущий:

module unload spectrum-mpi/xl/10.1/13.1-15.1
module load openmpi/gcc/2.0.2a1/4.8.5

При использовании компилятора PGI требуется загрузить его модуль перед загрузкой модуля библиотеки MPI:

module unload spectrum-mpi/xl/10.1/13.1-15.1
module load pgi/17.4
module load openmpi/pgi/1.10.2/2017

После подключения нужного модуля, пути к данной библиотеке добавляются в переменные среды «PATH» и «LD_LIBRARY_PATH».

Для компиляции mpi программ лучше всего использовать обёртки к компиляторам, чем вручную прописывать для этого специальные флаги. Так, например, чтобы скомпилировать mpi программу, написанную на языке Fortran, нужно воспользоваться оберткой mpifort. Данная команда вызовет компилятор IBM XL Fortran (при условии, что подключен модуль spectrum-mpi/xl/10.1/13.1-15.1), с указанием всех необходимых флагов.

Распишем соответствие между обертками и соответствующими им компиляторами:

Соответствие между обертками MPI и компиляторами
Обертка XL GNU PGI
mpicc xlc_r gcc pgcc
mpifort xlf_r gfortran pgfortran
mpif77 xlf_r gfortran pgfortran
mpif90 xlf90_r gfortran pgfortran
mpic++ xlC_r g++ pgc++
mpicxx xlC_r g++ pgc++

Для того, чтобы посмотреть какие опции компилятора указываются при вызове обертки, можно воспользоваться следующей командой:

[user@jupiter ~]$ mpicc --show
gcc -I/opt/soft/openmpi/2.0.2a1/gcc/include -pthread -Wl,-rpath -Wl,/opt/soft/openmpi/2.0.2a1/gcc/lib -Wl,
--enable-new-dtags -L/opt/soft/openmpi/2.0.2a1/gcc/lib -lmpi

Как видно из данного вывода, единственными опциями, которые может потребоваться указать при вызове компилятора, могут оказаться опции оптимизации.

Замечания по разработке программ на отдельной машине

Практически все реализации MPI поддерживают запуск параллельных приложений в режиме эмуляции на отдельно взятой рабочей станции. Это можно делать как на Linux, так и Windows машинах.

В Linux рекомендуется использовать пакет OpenMPI, а для создания MPI приложений на Windows машинах можно использовать пакет MPICH в версии для Windows. Для успешного портирования программ с Windows на Linux не следует использовать расширения предоставляемые средами программирования, такими как Visual Studio и Borland Builder.

Подготовленные исходные коды программ лучше всего компилировать на кластере.

Запуск задач

Диспетчеризация задач

Для диспетчеризации задач на кластере используется система PBS Professional 14.1. С её помощью пользователь может отправлять свои задачи на исполнение, снимать их с исполнения и получать информацию по текущему статусу задачи.

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

Чтобы поставить задачу на исполнение, пользователь должен добавить ее при помощи команды qsub в какую-либо очередь. Очереди отличаются друг от друга совокупностью ресурсов, которыми они обладают.

Система очередей

На данный момент для пользователей действует единая очередь маршрутизации задач workq, в которой доступны все 5 узлов. Задачи из неё распределяются по очередям выполнения. Поставить задачу напрямую в очередь выполнения нельзя. Так задачи, для которых установлен walltime не более 10 минут, отправляются в короткую очередь fastq, привязанную к первой половине jupiter1[0] узла jupiter1. Иначе говоря, часть ресурсов 1 узла кластера, в т.ч. и GPU0, доступна только для быстрых тестовых задач. Установить значение walltime можно с помощью строки:

#PBS -l walltime=0:10:00
в файле задачи. В настоящее время есть затруднение при работе с очередью fastq (в случае, когда заняты все остальные GPU, кроме GPU на jupiter1[0], задача, запрашивающая этот свободный GPU, не получает его), поэтому для обхода этой проблемы рекомендуется явно указывать vnode в строке ресурсов, например:
#PBS -l select=1:mpiprocs=1:ncpus=8:ngpus=1:vnode=jupiter1[0]
#PBS -l walltime=0:10:00

Задачу, которая не влезает на 1 виртуальный узел, невозможно запустить с walltime<=0:10:00, поскольку все такие задачи размещаются в очередь fastq, строго привязанную к виртуальному узлу jupiter1[0]. Поэтому, для любых больших задач необходимо задавать значение walltime как минимум 0:10:01.

Для получения информации об очередях, можно выполнить команду qstat -q:

[eab@jupiter install]$ qstat -q

server: jupiter1

Queue            Memory CPU Time Walltime Node   Run   Que   Lm  State
---------------- ------ -------- -------- ---- ----- ----- ----  -----
workq              --      --       --     --      0     0   --   E R
mixedq             --      --       --     --      8     0   --   E R
fastq              --      --    00:10:00  --      0     0   --   E R
lowq               --      --       --     --      0     0   --   E R
                                               ----- -----
                                                   8     0

Queue – имя очереди; Run – число выполняемых задач; Que – число задач, ожидающих начала выполнения. Команда qstat -Qf имя_очереди позволяет получить информацию о конкретной очереди.

Постановка задачи в очередь

Для постановки задачи в очередь на исполнение используется команда qsub. Данная команда принимает в качестве параметра имя скрипта, в котором описываются требуемые задачей ресурсы и указываются команды, исполняемые при запуске. Рассмотрим пример, иллюстрирующий запуск ранее скомпилированной программы на 1 чанке (некоторой виртуальной части) кластера, с использованием 4 mpi процессов, выделением 4 процессоров и 1 GPU на этом чанке:

[user@jupiter mpi_test]$ cat mpi_test.qsub
#PBS -k oe
#PBS -l select=1:mpiprocs=4:ncpus=32:ngpus=1
#PBS -l place=shared
#PBS -r n
#PBS -M user@mail.com
#PBS -m abe
#PBS -q workq
#PBS -N mpi_test
#!/bin/sh

cd /home/user/test/mpi_test

module unload spectrum_mpi && module load openmpi/gcc/1.10.6/4.8.5
mpirun -np 4 -npernode 4 --hostfile $PBS_NODEFILE --bind-to core ./mpi

[user@jupiter mpi_test]$ qsub mpi_test.qsub
66330.jupiter1

Если команда выполнена успешно, то на экране отобразится идентификатор задачи (в данном случае это 66330.jupiter1), в противном случае появится сообщение об ошибке. Ошибки пользовательской программы (неправильная компиляция и т.п.) проявятся только при переходе задачи к активному состоянию.

Примечание. Весь вывод программы в стандартный поток и в поток ошибок перенаправляется в файлы, находящиеся в домашней директории пользователя. Названия таких файлов имеют формат имя_задачи.(e/o)порядковый_номер. Для запущенной задачи это будут: mpi_test.e66330 – для потока ошибок и mpi_test.o66330 – для стандартного потока вывода.

Прокомментируем каждую из строчек скрипта mpi_test.qsub:

#PBS -k oe — указание сброса потока вывода (o) и потока ошибок (e)
#PBS -l select=1:mpiprocs=4:ncpus=32:ngpus=1 — требуемое количество чанков (1); количество mpi процессов (4), количество выделяемых процессоров (4 = 32/8) и количество выделяемых GPU (1) на каждом чанке

Параметр ngpus=<число> является обязательным к указанию для задач, планируемых к запуску с использованием графических ускорителей. <число> - количество ускорителей, требуемое задачей.

#PBS -l place=shared — использование узла вместе с другими задачами; shared — совместное использование, excl — монопольное использование
#PBS -r n — является ли задача перезапускаемой (задачей с контрольными точками); y — является, n — не является
#PBS -M user@mail.com — почтовый адрес пользователя
#PBS -m abe — какие сообщения отправляются на указанный адрес (a — ошибка в выполнении задачи, b — начало выполнения, e — завершение выполнения)
#PBS -q workq — идентификатор очереди
#PBS -N mpi_test — название задачи
#!/bin/sh — указание необходимого командного интерпретатора
cd /home/user/test/mpi_test — переход в директорию с исполняемым файлом
module unload spectrum_mpi && module load openmpi/gcc/1.10.6/4.8.5 — выбор openmpi вместо spectrum_mpi
mpirun -np 4 -npernode 4 --hostfile $PBS_NODEFILE --bind-to core ./mpi — запуск приложения

Запуск интерактивных программ

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

Для перенаправления подготавливается текстовый файл, содержимое которого в точности представляет собой данные, вводимые пользователем. Например, если программа solver предполагает ввод в первой строке размерности матрицы, а во второй количества итераций, то текстовый файл input.txt будет иметь вид:

[user@jupiter solver]$ cat input.txt
10000000
1000

После каждого числа обязателен символ новой строки. Запуск программы на выполнение производится так:

solver < input.txt

Скрипт для постановки в очередь задания, в рамках которого будет выполняться интерактивная программа, будет выглядеть следующим образом:

[user@jupiter solver]$ cat job.qsub
#PBS -k oe
#PBS -l select=1:ncpus=64:mpiprocs=8
#PBS -r n
#PBS -M user@mail.com
#PBS -m abe
#PBS -q workq
#PBS -N solver
#!/bin/sh

cd /home/user/test/solver

mpirun -np 8 -npernode 8 --hostfile $PBS_NODEFILE --bind-to core ./solver < ./input.txt

exit 0

Запуск непараллельных программ

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

#PBS -l select=1:ncpus=8

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

Состояние пользовательских задач

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

[user@jupiter ~]$ qstat
Job id                  Name             User            Time Use S Queue
----------------------- ---------------- --------------- -------- - -----
700.jupiter1            mpi_test         user            00:10:40 R workq
701.jupiter1            sample_job       user            0        Q workq
702.jupiter1            solver           user            0        Q workq

Job id — идентификатор задачи, полученный при выполнении qsub; Name — имя задачи; User — имя пользователя, запустившего задачу; Time Use — процессорное время, потраченное задачей; S (State) — с остояние задачи ( R – задача выполняется, Q – ожидает в очереди); Queue — очередь.

В данном случае пользователю user принадлежат три задачи.

С помощью команды qstat -n идентификатор_задачи можно получить список узлов, на которых выполняется конкретная задача. Эта информация полезна при мониторинге эффективности использования вычислительных ресурсов с использованием системы Ganglia, так как позволяет отслеживать состояние только используемых задачей узлов.

[user@jupiter ~]$ qstat -n 701

jupiter1:
                                                           Req'd  Req'd   Elap
Job ID          Username Queue    Jobname    SessID NDS TSK Memory Time  S Time
--------------- -------- -------- ---------- ------ --- --- ------ ----- - -----
298.jupiter1    eab      workq    mpi_test      --    1   4    2gb 00:00 R   -- 
   jupiter1/0*4

Для получения более подробной информации о конкретной задаче можно запустить команду qstat -f идентификатор_задачи. Для просмотра информации по завершенным задачам можно использовать команды qstat -x | tail и qstat -xf идентификатор_задачи.

Остановка задач

Остановка программы производится командой qdel идентификатор_задачи

[user@jupiter ~]$ qdel 700

Этой командой задача, стоящая в очереди, убирается из нее, а выполняющаяся задача снимается с выполнения. Следующая по очереди и приоритету задача встает на выполнение.

Задача снимается в течении некоторого времени, поэтому при вызове qstat непосредственно после qdel удаленная задача все еще может быть отражена в таблице.

Углубленная настройка задач

Каждый узел кластера состоит из двух виртуальных узлов, разделяющих ресурсы узла поровну. Для оперативной памяти действует исключение: она может заимствоваться из соседнего виртуального узла.

Определение количества mpi-процессов

На каждом узле кластера имеется 2 десятиядерных процессора, каждое ядро может обрабатывать 8 потоков. В скриптах запуска для параметра ncpus максимальным является значение 160 - общее количество потоков. Тем не менее, при определенных условиях (если код запускаемых программ хорошо оптимизирован), количество вычислительных процессов значительно большее, чем 20 доступных ядер, может стать причиной неэффективного выполнения - задачи будут мешать друг другу. Поэтому, если нет особых оснований, рекомендуется использовать 20 mpi-процессов на узле. Таким образом, количество запускаемых mpi-процессов должно соответствовать количеству запрашиваемых ncpus, поделенному на 8. В некоторых случаях допускаются отклонения от этой схемы, например, для приложения GAMESS запускается в 2 раза больше потоков, чем обычно, и половина из них не требует отдельного процессора. В данном случае количество mpi-процессов будет соответствовать количеству ncpus, поделенному на 4.

В силу специфики узла кластера, имеющего 2 GPU, для задач, использующих все 20 mpi-процессов и не использующих GPU, рекомендуется устанавливать значение ncpus=144, чтобы было возможно размещение еще 2х задач, не требовательных к CPU и задействующих GPU, с параметрами ncpus=8:ngpus=1.

Использование MPS-сервера

На данный момент на кластере можно использовать CUDA MPS сервер. Настройка пока доступна только для задач, требующих 1 GPU и помещающихся ровно на 1 виртуальный узел (что означает задание ncpus<=80 при полностью свободных процессорных ресурсах виртуального узла). Чтобы активировать этот режим, необходимо в скрипте запуска указать:

#PBS -v USE_MPS=True

MPS-сервер будет создан при запуске задачи и удален после её завершения.

Мониторинг

Web-интерфейс

Мониторинг кластера реализован при помощи системы Ganglia. Эта система позволяет следить за ресурсами кластера посредством web-интерфейса. Система мониторинга находится по адресу http://jupiter.febras.net/ganglia.

Для мониторинга пользователю доступно большое число типов ресурсов: загруженность процессора, оперативная память, загрузка сети, средняя загрузка, количество процессов и ряд других. Имеется возможность наблюдать как за всеми узлами в кластере (по одному параметру), так и за каждым (по всем параметрам).

Консоль

Кроме графического интерфейса существует несколько полезных консольных команд для мониторинга. Команда pbsnodes имя_узла позволяет получить информацию о конкретном узле: тип, состояние, количество процессоров, выполняющиеся задачи. Ниже представлен фрагмент вывода этой команды.

[user@jupiter ~]$ pbsnodes jupiter2
jupiter2
     Mom = jupiter2
     Port = 15002
     pbs_version = 14.1.0
     ntype = PBS
     state = free
     pcpus = 160
     resources_available.arch = linux
     resources_available.host = jupiter2
     resources_available.mem = 263653568kb
     resources_available.ncpus = 160
     resources_available.ngpus = 2
     resources_available.nodetype = jupiter
     resources_available.vnode = jupiter2
     resources_assigned.accelerator_memory = 0kb
     resources_assigned.mem = 0kb
     resources_assigned.naccelerators = 0
     resources_assigned.ncpus = 0
     resources_assigned.netwins = 0
     resources_assigned.ngpus = 0
     resources_assigned.vmem = 0kb
     resv_enable = True
     sharing = default_shared

state – состояние узла (job-exclusive – все ресурсы узла заняты; free – на узле есть свободные ресурсы для запуска заданий; offline – узел временно выведен из эксплуатации, запуск заданий на нем невозможен; down – узел выключен); pcpus – число процессорных потоков на узле; jobs – задачи, запущенные на узле; resources_available.ngpus – число GPU на узле; resources_available.nodetype - тип узла: jupiter (CentOS).

При выполнении команды pbsnodes -a -S -j будет выведена сводная информация обо всех узлах кластера.

[user@jupiter ~]$ pbsnodes -a -S -j
                                                        mem       ncpus   nmics   ngpus
vnode           state           njobs   run   susp      f/t        f/t     f/t     f/t   jobs
--------------- --------------- ------ ----- ------ ------------ ------- ------- ------- -------
jupiter1        free                 0     0      0  251gb/251gb 160/160     0/0     2/2 --
jupiter2        free                 0     0      0  251gb/251gb 160/160     0/0     2/2 --
jupiter3        free                 0     0      0  251gb/251gb 160/160     0/0     2/2 --
jupiter4        free                 0     0      0  251gb/251gb 160/160     0/0     2/2 --
jupiter5        free                 0     0      0  251gb/251gb 160/160     0/0     2/2 --

При выполнении команды pbsnodes -v -a -S -j будет выведена сводная информация обо всех узлах кластера с внутренней детализацией.

[user@jupiter ~]$ pbsnodes -v -a -S -j
                                                        mem       ncpus   nmics   ngpus
vnode           state           njobs   run   susp      f/t        f/t     f/t     f/t   jobs
--------------- --------------- ------ ----- ------ ------------ ------- ------- ------- -------
jupiter2        free                 0     0      0      0 b/0 b     0/0     0/0     0/0 --
jupiter3        free                 0     0      0      0 b/0 b     0/0     0/0     0/0 --
jupiter3[0]     free                 2     2      0  126gb/126gb   52/80     0/0     0/1 5272,5326
jupiter3[1]     free                 1     1      0  126gb/126gb   72/80     0/0     0/1 5273
jupiter1        free                 0     0      0      0 b/0 b     0/0     0/0     0/0 --
jupiter4        free                 0     0      0      0 b/0 b     0/0     0/0     0/0 --
jupiter5        free                 0     0      0      0 b/0 b     0/0     0/0     0/0 --
jupiter4[0]     free                 1     1      0  126gb/126gb   72/80     0/0     0/1 5278
jupiter4[1]     free                 1     1      0  126gb/126gb   72/80     0/0     0/1 5279
jupiter5[0]     free                 1     1      0  126gb/126gb   72/80     0/0     0/1 5280
jupiter5[1]     free                 1     1      0  126gb/126gb   72/80     0/0     0/1 5281
jupiter1[0]     free                 1     1      0  126gb/126gb   72/80     0/0     0/1 5276
jupiter1[1]     free                 1     1      0  126gb/126gb   72/80     0/0     0/1 5277
jupiter2[0]     free                 1     1      0  126gb/126gb   72/80     0/0     0/1 5275
jupiter2[1]     free                 1     1      0  126gb/126gb   72/80     0/0     0/1 5274

Пакеты прикладных программ

Фреймворки машинного и глубокого обучения

На кластере доступны следующие фреймворки машинного и глубокого обучения:

Фреймворк Версия Модуль
Caffe (Berkeley Vision and Learning Center) 1.0.0 caffe/bvlc/1.0.0
Caffe (оптимизированная версия от IBM) 1.0.0 caffe/ibm/1.0.0
Caffe (форк NVIDIA) 0.15.14 caffe/nvidia/0.15.14
Chainer 1.23.0 chainer/1.23.0
DIGITS 5.0.0 digits/5.0.0
TensorFlow 1.1.0 tensorflow/1.1.0
Theano 0.9.0 theano/0.9.0
Torch 7 torch/7

TensorFlow

TensorFlow — открытая программная библиотека для машинного обучения, разработанная компанией Google для решения задач построения и тренировки нейронной сети с целью автоматического нахождения и классификации образов (https://www.tensorflow.org/).
На кластере доступна оптимизированная для работы на процессорах IBM POWER8 и сопроцессорах NVIDIA Tesla P100 версия пакета, входящая в состав IBM PowerAI 4.0. Для работы с ней применяются контейнеры Singularity. Ниже приводится пример скрипта описания заданий, используемого для запуска TensorFlow на одном вычислительном узле кластера с задействованием двух сопроцессоров.

#!/bin/sh
#PBS -k oe 
#PBS -l select=1:ncpus=16:ngpus=2 
#PBS -l place=exclusive 
#PBS -r n 
#PBS -M user@mail.com 
#PBS -m abe 
#PBS -q workq 
#PBS -N cifar10  

# Загружаем модуль TensorFlow
module add tensorflow/1.1.0

# Переходим в рабочую директорию проекта
cd /home/user/tf_working_dir 

# Запускаем тренировку нейронной сети,
# описанной в файлах cifar10_multi_gpu_train.py и cifar10.py
python-pai ./cifar10/cifar10_multi_gpu_train.py 

# Проводим оценку результатов обучения нейронной сети
python-pai ./cifar10/cifar10_eval.py
Использование нескольких GPU

Использование нескольких GPU позволяет ускорить расчет градиентов обновления весов сети. Для этого несколько копий модели параллельно просчитываются на отдельных GPU, после чего вычисляется средний градиент ошибки для обновления весов сети.

Ниже приведены части кода, исполняющего задачу классификации изображений из набора CIFAR-10, с помощью сверточной нейронной сети. Полный код приведен в файлах:

cifar10_multi_gpu_train.py – задает процесс обучения на нескольких графических сопроцессорах;
cifar10.py – содержит вспомогательные функции, а также описывает вычислительный граф;
cifar10_input.py – загружает и структурирует данные из набора CIFAR-10;
cifar10_eval.py – загружает обученную модель и оценивает точность тренировки нейронной сети.

Для параллелизации процесса обучения в файле cifar10_multi_gpu_train.py задается параметр FLAGS.num_gpus, представляющий собой количество GPU (задается в tf.app.flags.DEFINE_integer).
Копии модели в TensorFlow принято называть tower. Ниже приведен пример, в котором каждая tower рассчитывается на отдельном GPU, после чего вычисляется средний градиент весов сети:

    tower_grads = [] 
    with tf.variable_scope(tf.get_variable_scope()): 
      for i in xrange(FLAGS.num_gpus): 
        with tf.device('/gpu:%d' % i): 
          with tf.name_scope('%s_%d' % (cifar10.TOWER_NAME, i)) as scope: 
            # Dequeues one batch for the GPU 
            image_batch, label_batch = batch_queue.dequeue() 
            # Calculate the loss for one tower of the CIFAR model. This function 
            # constructs the entire CIFAR model but shares the variables across 
            # all towers. 
            loss = tower_loss(scope, image_batch, label_batch) 

            # Reuse variables for the next tower. 
            tf.get_variable_scope().reuse_variables() 

            # Retain the summaries from the final tower. 
            summaries = tf.get_collection(tf.GraphKeys.SUMMARIES, scope) 

            # Calculate the gradients for the batch of data on this CIFAR tower. 
            grads = opt.compute_gradients(loss) 

            # Keep track of the gradients across all towers. 
            tower_grads.append(grads) 

    # We must calculate the mean of each gradient. Note that this is the 
    # synchronization point across all towers. 
    grads = average_gradients(tower_grads)
Хранение данных на кластере

При работе с фреймворком TensorFlow настоятельно рекомендуется хэшировать данные в директории /tmp, имеющейся на каждом вычислительном узле. Эти директории находятся на локальных дисках объемом 2Tb. Для исключения конфликтов между данными разных пользователей на одном узле, необходимо размещать их в директории /tmp/username, как это сделано в коде ниже.

username = str(os.environ['USER']) 
tf.app.flags.DEFINE_string('data_dir', '/tmp/'+username+'/cifar10_data', """Path to the CIFAR-10 data directory.""")

Полное руководство по созданию данной модели глубокой нейронной сети в TensorFlow приведено по ссылке: https://www.tensorflow.org/tutorials/deep_cnn

Quantum ESPRESSO

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

Версии

Версии пакета
Версия Используемая библиотека Подержка GPU Модуль Сайт проекта
5.4 IBM ESSL - espresso/cpu/5.4 http://www.quantum-espresso.org/
5.4 IBM ESSL +* espresso/gpu/5.4 https://github.com/fspiga/qe-gpu-plugin
5.4 IBM ESSL (SMPCUDA) ++ espresso/gpu/5.4-esslcuda http://www.quantum-espresso.org/
6.0 IBM ESSL +++ espresso/gpu/6.0 https://github.com/RSE-Cambridge/qe-gpu

* – число символов “+” соотносится с производительностью пакета (больше – лучше)

Все версии пакета собраны с поддержкой MPI и могут работать в параллельном режиме. Версия Quantum ESPRESSO 6.0 является экспериментальной и может не поддерживать некоторые функции и настройки (например, в этой версии нельзя выставить значение nk большее 1; подробности смотрите на сайте проекта).

Запуск Quantum ESPRESSO

Перед началом работы с пакетом необходимо загрузить соответствующий модуль командой “module add”. Это позволит получить доступ к нужной версии исполняемых файлов пакета и выставить необходимые переменные среды. Также может потребоваться загрузить дополнительные модули, от которых зависит работоспособность соответствующей версии Quantum ESPRESSO. Все эти действия выполняются в скриптах описания заданий.

Ниже приводятся примеры скриптов описания заданий, используемых для запуска Quantum ESPRESSO в параллельном режиме на узлах кластера (два вычислительных узла; используются 2 процессора и 2 сопроцессора на каждом).

Версия Quantum Espresso – espresso/cpu/5.4.

#!/bin/sh
#PBS -N qe_job_name
#PBS -q workq
#PBS -j oe
#PBS -l select=2:ncpus=144:mpiprocs=20

# Загружаем необходимые модули
module add spectrum_mpi essl espresso/cpu/5.4

# Переходим в рабочую директорию
cd /home/user/qe_working_dir

# Запускаем исполняемый файл Quantum ESPRESSO “pw.x”
mpirun -np 40 -npernode 20 --hostfile $PBS_NODEFILE --bind-to core $QE_HOME/bin/pw.x < ausurf.in

Примечание. Здесь запрос с ncpus=144 практически эквивалентен запросу с ncpus=160 с той разницей, что остается возможность для другой, не требовательной к cpu, небольшой задачи с ncpus=8:ngpus=1 занять свободные ресурсы на узле.

Версия Quantum ESPRESSO – espresso/gpu/5.4.

#!/bin/sh
#PBS -N qe_job_name
#PBS -q workq
#PBS -j oe
#PBS -l select=2:ncpus=160:ngpus=2:mpiprocs=20

# Загружаем необходимые модули
module add spectrum_mpi essl espresso/gpu/5.4

# Переходим в рабочую директорию
cd /home/user/qe_working_dir

# Запускаем исполняемый файл Quantum ESPRESSO “pw-gpu.x”
mpirun -np 40 -npernode 20 --hostfile $PBS_NODEFILE --bind-to core $QE_HOME/bin/pw-gpu.x < ausurf.in

Версия Quantum ESPRESSO – espresso/gpu/5.4-esslcuda.

#!/bin/sh
#PBS -N qe_job_name
#PBS -q workq
#PBS -j oe
#PBS -l select=2:ncpus=160:ngpus=2:mpiprocs=20

# Загружаем необходимые модули
module add spectrum_mpi essl espresso/gpu/5.4-esslcuda

# Переходим в рабочую директорию
cd /home/user/qe_working_dir

# Запускаем исполняемый файл Quantum ESPRESSO “pw.x”
mpirun -np 40 -npernode 20 --hostfile $PBS_NODEFILE --bind-to core $QE_HOME/bin/pw.x < ausurf.in

Версия Quantum ESPRESSO – espresso/gpu/6.0.

#!/bin/sh
#PBS -N qe_job_name
#PBS -q workq
#PBS -j oe
#PBS -l select=2:ncpus=160:ngpus=2:mpiprocs=2

# Загружаем необходимые модули
module rm spectrum_mpi
module add pgi/17.4 openmpi/pgi/1.10.2/2017 essl espresso/gpu/6.0

# Переходим в рабочую директорию
cd /home/user/qe_working_dir

# Запускаем исполняемый файл Quantum ESPRESSO “pw.x”
mpirun -np 4 --hostfile $PBS_NODEFILE --map-by ppr:1:socket $QE_HOME/bin/pw.x < ausurf.in

Стандартный вывод и вывод ошибок перенаправляется в файл вида qe_job_name.o1079, где “1079” соответствует номеру задания.

GAMESS

GAMESS (US) — программа пакета вычислительной квантовой химии. GAMESS (US) способен производить расчеты МО при помощи многих методов вычислительной квантовой химии, включая метод Хартри-Фока, теорию функционала плотности (DFT), теорию валентных связей (GVB), и многоконфигурационное самосогласованное поле (MCSCF).

Версии

Установлена и протестирована версия GAMESS 2017 R2 с использованием ESSL и OpenMPI 2.0.2a1.
Для версии GAMESS+LIBCCHEM с использованием вычислений на GPU, компиляция проходит успешно, но часть тестов связанных с вычислением MP2 energy проваливаются.

Запуск GAMESS

Ниже приводится пример скрипта описания задания, используемого для запуска GAMESS в параллельном режиме на узлах кластера (два вычислительных узла).

#!/bin/sh
#PBS -N gm_job_name
#PBS -q workq
#PBS -k oe
#PBS -l select=2:ncpus=144:mpiprocs=40
#PBS -m abe

# Загружаем необходимые модули
module rm spectrum_mpi
module add openmpi/gcc/2.0.2a1/4.8.5

# Переходим в рабочую директорию
cd /home/user/gm_working_dir 
export OMP_NUM_THREADS=1
export GMSPATH=/opt/soft/gamess/07.10.2017-A/gamess

# Запуск GAMESS с входным файлом SubPc.inp.
# rungms принимает 4 параметра:
# имя входного файла (SubPc.inp)
# версия GAMESS (01) 
# количество ядер NCPUS (40)
# количество ядер на узел PPN (20) 
# т.е. происходит запуск на двух узлах с использованием 20 ядер на каждом.
# количество mpiprocs=2*PPN, потому что gamess использует 2 mpi процесса на каждом ядре.
$GMSPATH/rungms SubPc.inp 01 40 20 >&  run.log

exit 0

Дополнительно

Значение переменной для задания внешнего базисного набора атомных орбиталей установлено как:

setenv EXTBAS $HOME/EXTBAS.txt
Для его использования достаточно разместить файл EXTBAS.txt в своей домашней директории.

Справочная информация

Описание основных команд при работе в ОС Linux — http://wwwinfo.jinr.ru/unixinfo/pc/lin_os.html
Документация к системе диспетчеризации заданий PBS Pro — http://www.pbsworks.com/pdfs/PBSUserGuide14.2.pdf

putty.png Просмотреть (16,8 КБ) Евгений Бойков, 21.07.2017 12:12

пакеты_прикладных_программ.docx - Раздел ППП (19,6 КБ) Евгений Бойков, 08.09.2017 17:12

cifar10.py Просмотреть (14,4 КБ) Сергей Мальковский, 27.09.2017 15:44

cifar10_eval.py Просмотреть (5,53 КБ) Сергей Мальковский, 27.09.2017 15:44

cifar10_input.py Просмотреть (9,8 КБ) Сергей Мальковский, 27.09.2017 15:44

cifar10_multi_gpu_train.py Просмотреть (10,7 КБ) Сергей Мальковский, 27.09.2017 15:45