Содержание


Оптимизация управления ресурсами суперкомпьютеров с помощью SLURM

Познакомьтесь с инструментом Simple Linux Utility for Resource Management

Comments

Суперкомпьютеры являются классическим примером гонки вооружений. Растущая производительность этих огромных систем позволяет решать все более сложные проблемы. Суперкомпьютеры – это предмет национальной и корпоративной гордости: страны и корпорации стремятся получить наивысшие баллы в тестах LINPACK. На рисунке 1 изображен график производительности суперкомпьютеров за последние пять лет, согласно которому в 2012 году самым производительным должен стать суперкомпьютер IBM Sequoia. Как видно из графика, первым суперкомпьютером, преодолевшим барьер в один петафлопс, стал суперкомпьютер IBM Roadrunner (а суперкомпьютер IBM Blue Gene® /L занимал первое место по производительности с 2004 по 2008 годы).

Рисунок 1. Производительность суперкомпьютеров: 2008-2012
Рисунок 1. Производительность суперкомпьютеров: 2008-2012
Рисунок 1. Производительность суперкомпьютеров: 2008-2012

Первые суперкомпьютеры были разработаны для моделирования ядерного оружия. Сегодня суперкомпьютеры применяются в самых различных областях и служат инструментами для решения проблем, связанных с огромными объемами вычислений – например, исследование климата, молекулярное моделирование, крупномасштабное физическое моделирование и даже взламывание шифров.

С 1964 г. по наши дни

Первым суперкомпьютером принято считать суперкомпьютер Control Data Corporation (CDC) 6600, который был разработан Сеймуром Крэйем (Seymour Cray) и запущен в 1964 году. Суперкомпьютер 6600 занимал четыре стойки, имел фреоновую систему охлаждения и один процессор, способный выполнять 3 млн. операций с плавающей точкой в секунду (Floating-Point Operations per Second – FLOPS). Стойки были заполнены цветными кабелями, соединявшими процессоры периферийных устройств с центральным процессором и обеспечивающими его максимально возможную загрузку.

На сегодняшний день лидером среди суперкомпьютеров является японский компьютер Kei, созданный компанией Fujitsu. Эта система спроектирована для получения максимальной вычислительной мощности и использует более 88 тыс. процессоров SPARC64, распределенных по 864 стойкам. Суперкомпьютер Kei первым преодолел барьер производительности в 10 петафлопс. Так же, как и CDC 6600, помимо воздушного охлаждения Kei использует водяное охлаждение.

Что такое суперкомпьютер?

Суперкомпьютер – это не какая-то конкретная архитектура, а просто конструкция компьютерной системы, обеспечивающая экстремальную производительность, т.е. на уровне нескольких петафлопс (т. е. квадрильонов флопс) по результатам теста LINPACK.

Независимо от того, каким образом суперкомпьютеры достигают таких значений производительности, архитектура любого суперкомпьютера обеспечивает оптимальную загрузку его вычислительных ресурсов при выполнении задач. Аналогично периферийным процессорам CDC 6600, предназначавшимся для поддержания загрузки единственного центрального процессора, современным суперкомпьютерам необходим тот же самый основной функционал. Давайте рассмотрим одну из таких реализаций системы управления ресурсами вычислительных узлов, которая называется Simple Linux® Utility for Resource Management (SLURM).

Коротко о SLURM

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

Не вдаваясь в подробности, можно сказать, что SLURM - это надежный, переносимый, масштабируемый на большое количество узлов, отказоустойчивый и, что самое важное, открытый менеджер кластеров (ориентированный больше на необходимые функции, чем на обеспечение дополнительных возможностей). SLURM начинал совместно разрабатываться несколькими компаниями (в их число входила Ливерморская национальная лаборатория имени Э. Лоуренса) как Open Source-менеджер ресурсов. Сегодня SLURM является лидером среди менеджеров ресурсов и используется на многих самых мощных суперкомпьютерах.

Архитектура SLURM

В SLURM реализована типичная архитектура управления кластером (см. рисунок 2). Верхний уровень управления – это резервированная пара контроллеров кластера (хотя резервирование не является обязательным). Эти контроллеры управляют вычислительным кластером и содержат демон управления под названием slurmctld. Демон slurmctld следит за вычислительными ресурсами, но, что более важно, он занимается распределением этих ресурсов между разными заданиями.

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

Рисунок 2. Высокоуровневое представление архитектуры SLURM
Рисунок 2. Высокоуровневое представление архитектуры SLURM
Рисунок 2. Высокоуровневое представление архитектуры SLURM

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

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

Эта иерархия, более подробно показывающая разделение ресурсов на разделы в SLURM, изображена на рисунке 3. Обратите внимание на то, что при таком разделении учитывается близость ресурсов, что позволяет обеспечить низкие задержки при взаимодействии совместно работающих узлов.

Рисунок 3. Разделение на разделы в SLURM
Рисунок 3. Разделение на разделы в SLURM
Рисунок 3. Разделение на разделы в SLURM

Инсталляция SLURM

Процесс инсталляции SLURM зависит от конкретного окружения Linux, но может сводиться к простой работе с менеджером пакетов. SLURM доступен в виде готового пакета, который просто установить и настроить. В моем любимом дистрибутиве, Ubuntu, для установки пакета SLURM и всех его зависимостей я использую инструмент Advanced Packaging Tool (APT):

$ sudo apt-get install slurm-llnl

Для инсталляции SLURM вместе со всеми зависимостями, основными подключаемыми модулями и другими необходимыми пакетами требуется менее 40 МБ дискового пространства.

Конфигурирование SLURM

Прежде чем запускать SLURM, необходимо настроить его для конкретного окружения. Для создания конфигурации я использовал онлайновый конфигуратор SLURM, который сгенерировал для меня конфигурационный файл на основе данных из формы. Обратите внимание на то, что в конце процедуры необходимо подправить этот файл и удалить из него опции, которые больше не поддерживаются. В листинге 1 представлено содержимое моего конечного конфигурационного файла (/etc/slurm-llnl/slurm.conf).

Листинг 1. Конфигурационный файл SLURM для одноузлового кластера
# slurm.conf file generated by configurator.html.
# Put this file on all nodes of your cluster.
# See the slurm.conf man page for more information.
#
ControlMachine=mtj-VirtualBox
#
AuthType=auth/none
CacheGroups=0
CryptoType=crypto/openssl
MpiDefault=none
ProctrackType=proctrack/pgid
ReturnToService=1
SlurmctldPidFile=/var/run/slurmctld.pid
SlurmctldPort=6817
SlurmdPidFile=/var/run/slurmd.pid
SlurmdPort=6818
SlurmdSpoolDir=/tmp/slurmd
SlurmUser=slurm
StateSaveLocation=/tmp
SwitchType=switch/none
TaskPlugin=task/none
#
# TIMERS
InactiveLimit=0
KillWait=30
MinJobAge=300
SlurmctldTimeout=120
SlurmdTimeout=300
Waittime=0
#
# SCHEDULING
FastSchedule=1
SchedulerType=sched/backfill
SchedulerPort=7321
SelectType=select/linear
#
# LOGGING AND ACCOUNTING
AccountingStorageType=accounting_storage/none
ClusterName=cluster
JobCompType=jobcomp/none
JobCredentialPrivateKey = /usr/local/etc/slurm.key
JobCredentialPublicCertificate = /usr/local/etc/slurm.cert
JobAcctGatherFrequency=30
JobAcctGatherType=jobacct_gather/none
SlurmctldDebug=3
SlurmdDebug=3
#
# COMPUTE NODES
NodeName=mtj-VirtualBox State=UNKNOWN
PartitionName=debug Nodes=mtj-VirtualBox Default=YES MaxTime=INFINITE State=UP

Следует отметить, что в реальном кластере параметр NodeName относился бы к нескольким узлам, например, имел бы значение snode[0-8191] для обозначения 8192 уникальных узлов кластера (с именами от snode0 до snode8191).

Последний шаг – это создание набора ключей сертификации для моего сайта (в листинге 1 они называются JobCredential*). Для этого я использовал команду openssl, просто запустив ее, как показано в листинге 2:

Листинг 2. Создание электронных сертификатов для SLURM
$ sudo openssl genrsa -out /usr/local/etc/slurm.key 1024
Generating RSA private key, 1024 bit long modulus
.................++++++
............................................++++++
e is 65537 (0x10001)
$ sudo openssl rsa -in /usr/local/etc/slurm.key -pubout -out /usr/local/etc/slurm.cert
writing RSA key

Если вы выполнили все эти действия, то SLURM готов к запуску и работе.

Запуск SLURM

Для запуска SLURM просто используйте управляющий файл сценария /etc/init.d/slurm. Этот сценарий принимает команды start, stop, restart и startclean (запуск без учета ранее сохраненных состояний). Такой способ запуска SLURM запускает в нашей простой конфигурации демон slurmctld, а также демон slurmd на единственном узле:

$ sudo /etc/init.d/slurm-llnl start

Чтобы убедиться в том, что SLURM запущен, используйте команду sinfo, которая возвращает информацию об узлах и разделах SLURM (в нашем случае кластер состоит из одного узла), как показано в листинге 3.

Листинг 3. Использование команды sinfo для просмотра информации о кластере
$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
debug*       up   infinite      1   idle mtj-VirtualBox
$

Другие команды SLURM

Более подробную информацию о вашем кластере SLURM можно получить с помощью различных команд, доступных в SLURM. В разделе Запуск SLURM вы познакомились с командой sinfo, использующейся для получения информации о конкретном кластере. Более подробную информацию можно получить с помощью команды scontrol, позволяющей детально рассмотреть все аспекты работы кластера (в листинге 4 приведены примеры получения информации о разделе и узле).

Листинг 4. Получение более подробной информации о кластере с помощью scontrol
$ scontrol show partition
PartitionName=debug
   AllocNodes=ALL AllowGroups=ALL Default=YES
   DefaultTime=NONE DisableRootJobs=NO Hidden=NO
   MaxNodes=UNLIMITED MaxTime=UNLIMITED MinNodes=1
   Nodes=mtj-VirtualBox
   Priority=1 RootOnly=NO Shared=NO PreemptMode=OFF
   State=UP TotalCPUs=1 TotalNodes=1
 
$ scontrol show node mtj-VirtualBox
NodeName=mtj-VirtualBox Arch=i686 CoresPerSocket=1
   CPUAlloc=0 CPUErr=0 CPUTot=1 Features=(null)
   Gres=(null)
   OS=Linux RealMemory=1 Sockets=1
   State=IDLE ThreadsPerCore=1 TmpDisk=0 Weight=1
   BootTime=2012-03-07T14:59:01 SlurmdStartTime=2012-04-17T11:10:43
   Reason=(null)

Для проверки нашего простого кластера SLURM воспользуемся командой srun, которая выделяет вычислительные ресурсы и запускает задачу для нашего задания. Заметим, что эти действия можно выполнять и по отдельности (с помощью команд salloc и sbatch). В листинге 5 приведен пример, в котором сначала в качестве задания указывается простая команда интерпретатора (чтобы продемонстрировать использование srun), а затем команда sleep с аргументом (чтобы продемонстрировать использование команды squeue для вывода списка работающих на кластере заданий).

Листинг 5. Назначение заданий для кластера и проверка статуса очереди
$ srun -l hostname
0: mtj-VirtualBox
$ srun -l sleep 5 &
[1] 24127
$ squeue
  JOBID PARTITION     NAME     USER  ST       TIME  NODES NODELIST(REASON)
     15     debug    sleep      mtj   R       0:03      1 mtj-VirtualBox
$
[1]+  Done                    srun -l sleep 5
$

Отметим, что назначаемое задание для кластера (как в листинге 5) может являться простой командой Linux, файлом сценария командной оболочки или исполняемым файлом.

В качестве последнего примера рассмотрим завершение задания. В этом случае мы запустим задание, которое выполняется длительное время, и используем команду squeue для определения его идентификатора, после чего с помощью команды scancel и полученного идентификатора завершим этот шаг задания (см. листинг 6).

Листинг 6. Завершение шага задания
$ srun -l sleep 60 &
[1] 24262
$ squeue
  JOBID PARTITION     NAME     USER  ST       TIME  NODES NODELIST(REASON)
     16     debug    sleep      mtj   R       0:03      1 mtj-VirtualBox
$ scancel 16
srun: Force Terminated job 16
$ srun: Job step aborted: Waiting up to 2 seconds for job step to finish.
0: slurmd[mtj-VirtualBox]: error: *** STEP 16.0 CANCELLED AT 2012-04-17T12:08:08 ***
srun: error: mtj-VirtualBox: task 0: Terminated
 
[1]+  Exit 15                 srun -l sleep 60
$

Наконец, можно остановить кластер с помощью того же сценария slurm-llnl, как показано в листинге 7.

Листинг 7. Остановка кластера SLURM
$ sudo /etc/init.d/slurm-llnl stop
 * Stopping slurm central management daemon slurmctld                           [ OK ]
 * Stopping slurm compute node daemon slurmd                                    [ OK ]
slurmd is stopped
$

В отличие от Apache Hadoop, в SLURM не использует распределенной файловой системы, поэтому в SLURM создается дополнительная нагрузка на процессоры, связанная с распределением исходных данных вычислений по узлам. В SLURM есть команда sbcast, которая используется для передачи файла на все узлы, выделенные для обработки задания. Можно (и, возможно, это даже более эффективно) использовать параллельную или распределенную по всем узлам кластера SLURM файловую систему, таким образом, избавляясь от необходимости использования sbcast для передачи данных процессу.

В нашем простом примере используется лишь часть имеющихся команд и еще более малая часть их доступных опций (посмотрите, например, полный список доступных опций команды srun). Но даже с минимальным набором доступных команд SLURM является функциональным и эффективным менеджером кластеров.

Тонкая настройка SLURM

SLURM – это не статический, а, наоборот, весьма динамичный менеджер ресурсов, который постепенно дополняется новым функционалом. В SLURM реализован подключаемый API-интерфейс, позволяющий динамически загружать библиотеки времени исполнения в процессе работы кластера. Этот API-интерфейс использовался для реализации различных новых функций, включая "фабрику" внутренних соединений, аутентификацию и диспетчеризацию. Подключаемые интерфейсы поддерживают и другие различные возможности, например, учет заданий, криптографические функции, интерфейс Message Passing Interface (MPI), отслеживание процессов и выбор ресурсов. Все это позволяет SLURM поддерживать различные кластерные архитектуры и реализации. За дополнительной информацией вы можете обратиться к руководству SLURM Programmer's Guide (см. раздел Ресурсы).

Что ждет SLURM в будущем

В 2011 году в SLURM было добавлено множество новых возможностей, включая частичную поддержку суперкомпьютеров IBM Blue Gene/Q, Cray XT и XE. Также была добавлена поддержка контрольных групп Linux (cgroups), обеспечивающая лучший контроль над контейнерами процессов Linux.

В 2012 году была полностью реализована поддержка Blue Gene/Q, а также была улучшена функция выбора ресурсов в соответствии с потребностями заданий и возможностями вычислительных ресурсов (например, узел с процессорами AMD). Запланирован новый инструмент для получения статистики диспетчеризации, а в ближайшем будущем будет создан инструментарий на основе Web-интерфейса. Другая запланированная функция SLURM связана с концепцией cloud bursting (выгрузка в облако), в которой необходимые вычислительные ресурсы размещаются у провайдера облачных вычислений, а излишняя нагрузка перемещается из локального кластера в облако (в котором также запущены демоны SLURM). Эта модель может оказаться очень полезной и поддерживает идею адаптации к нагрузке внутри определенного суперкомпьютера.

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

Что дальше

Из этого краткого описания SLURM видно, насколько просто использовать этот менеджера ресурсов, созданный движением Open Source. Несмотря на то, что суперкомпьютеры очень дороги и большинство людей не могут купить их, SLURM является основой для менеджеров масштабируемых кластеров, позволяющей превратить обычные серверы в высокопроизводительный кластер. Более того, архитектура SLURM упрощает настройку менеджера ресурсов для архитектуры любого суперкомпьютера (или доступного обычного кластера). Вероятно, именно поэтому SLURM является самым популярным менеджером суперкомпьютерных кластеров.


Ресурсы для скачивания


Похожие темы

  • Оригинал статьи: Optimizing resource management in supercomputers with SLURM (EN).
  • SLURM: A Highly Scalable Resource Manager (EN) – Web-сайт Ливерморской национальной лаборатории имени Э. Лоуренса, содержащий обзорную информацию о SLURM, подробный список публикаций и презентаций, документацию, а также полезные ответы на часто задаваемые вопросы. Также вы можете получить профессиональную поддержку по SLURM на Web-сайте SchedMD (EN).
  • Статья A Brief History of Supercomputing (EN) Гордона Белла (Gordon Bell) из Microsoft рассказывает историю суперкомпьютеров (хотя и не содержит много дат), начиная от CDC 6600 и заканчивая кластерами Beowulf.
  • Статья The LINPACK Benchmark: Past, Present, and Future (EN) (Jack Dongarra, Piotr Luszczek и Anttoine Petitet) познакомит вас с историей и внутренним устройством тестового пакета LINPACK. Статья также содержит результаты тестов LINPACK для распространенных аппаратных платформ (AMD Athlon, Intel® Pentium® и т. д.)
  • Статья SLURM Elastic Computing (EN) рассказывает об одноименной функции, реализующей концепцию под названием cloud bursting (выгрузка в облако), позволяющую увеличивать и уменьшать размеры кластеров в зависимости от потребностей в ресурсах. В частности, для расширения кластера используются ресурсы публичного облака, что обеспечивает экономически эффективный рост его мощностей.
  • Top500 (EN) – это список содержит список самых быстрых в мире суперкомпьютеров, а также подробности о современных и старых системах. Списки обновляются дважды в год. Не удивительно, что все суперкомпьютеры, входящие в десятку лидеров, работают под управлением Linux.
  • Суперкомпьютеры IBM имеют длинную и славную историю. На этих страницах Википедии (EN) вы найдете информацию о некоторых суперкомпьютерах, разработанных IBM.
  • Руководство разработчика SLURM (EN) – это хорошее введение в разработку подключаемых модулей. Оно также содержит документацию и общую информацию о структуре исходного кода SLURM.
  • С помощью инструмента SLURM Configuration Tool (EN) вы можете легко сгенерировать конфигурационный файл slurm.conf, заполнив простую форму. После ввода необходимой информации вы получите файл slurm.conf, готовый для использования в вашем кластере.

Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux, Open source
ArticleID=841166
ArticleTitle=Оптимизация управления ресурсами суперкомпьютеров с помощью SLURM
publish-date=10182012