Словосочетание «вычислительные ресурсы» является центральным по отношению к контенту сайта. Вокруг него сосредоточены все приведенные статьи с описанием общих подходов и моего опыта использования различных технологий.

Деловые партнеры никогда не дремлют, стараясь держать в курсе большинства новинок на рынке HPC (High-Performance Computing). Таким образом каждый год в моей практике случается несколько серьезных поворотов, в зависимости от того, насколько увеличилась плотность дисков в сервере в этом году, сколько ядер у очередного графического ускорителя NVIDIA и под какие задачи заточена передовая линейка процессоров от Intel. Суммируя новые поступления с уже имеющимися серверами имеем постоянно растущий парк оборудования, ресурсы которого тем или иным образом задействованы при решении различных задач. Таким образом в активе сисадмина HPC кластера имеются следующие вычислительные ресурсы:

  • Место для хранения данных (store)
  • Ядра CPU (cpu)
  • Ядра CUDA (gpu)
  • Оперативная память (ram)
  • Вычислительное время (time)

Что представляют из себя перечисленные вычислительные ресурсы без программного обеспечения? Стойки из серверов с проводами, которые можно потрогать. Как только монтажные работы заканчиваются и город засыпает, просыпается HPC сисадмин и перетыкивает провода, устанавливает ОС Centos 7.6, драйвер NVIDIA, планировщик задач SLURM и различные реализации технологий многопоточного программирования MPI, CUDA, OpenMP, OpenCL, настраивает режимы доступа ssh, X2Go/Spice.

В дальнейшем, определив ядро высокопроизводительного (~1 PFlops) вычислительного кластера, я буду добавлять описание различных компонент, ссылаясь на упомянутую конфигурацию.

Между вычислительными ресурсами кластера и пользователем нужен посредник, который мог бы взять под свой контроль обработку запросов пользователей. Таким посредником является планировщик задач, в данном случае SLURM. Пользователь запрашивает A cpu, D gpu, M ram, I time и N store используя специальные директивы в скрипте для запуска задач в режиме очереди.

Вычислительные ресурсы

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

Перейдем к аппаратной стороне вопроса об ускорении работы приложения за счет многопоточности. Уделю отдельное внимание области настроек планировщика, влияющих на степень гранулярности – степень разбиения физических устройств на потоки. Иногда достаточно отдать пользователю весь узел, иногда 20 ядер, иногда ему нужно два раза по 6 ядер с привязкой к различным node (связка память+процессор) в NUMA системе.

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

Мой личный опыт подсказывает, что в вопросах настроек гранулярности следует придерживаться правила «чем меньше знаешь, тем крепче спишь» и изолировать хрупкие натуры пользователей от таким вопросов, как: «а сколько ядер мне нужно?», «2 сокета, 12 ядер в два потока?», «логических или физических?», «NUMA o_O». Где-то рядом с единорогами, радугой и бабочками расположены стойки серверов с планировщиком настроенным таким образом, что в ответ на запрос, пользователь получает в распоряжение весь узел или несколько узлов, не углубляясь в параметры конфигурации. Подозреваю, что в этом случае сисадмину с кармой over 100500 гарантировано место в раю.