Программные продукты и системы

Введение. Основным принципом работы суперкомпьютерных центров является режим коллективного пользования. Для пользователей суперкомпьютер представляется в виде  некоторой типовой архитектуры. Элементом выделения ресурсов в таком параллельном компьютере является вычислительный узел (ВУ). Обычно в качестве ВУ выступает высокопроизводительный сервер с одним или несколькими многоядерными процессорами. Узел может оснащаться одним или более ускорителями вычислений, как правило, на базе высокопроизводительных графических процессоров, управляется собственной ОС и имеет уникальное сетевое имя, однозначно идентифицирующее его среди других ВУ. В состав суперкомпьютера входят множество ВУ, которые объединяются с помощью высокоскоростной низколатентной сети в единый вычислитель, часто называемый в литературе решающим полем.

Управление вычислителем (распределением вычислительной работы между ВУ) осуществляет специально выделенный сервер – управляющая ЭВМ. Доступ пользователей к параллельному компьютеру происходит через отдель- ный сервер доступа, к которому пользователи подключаются через Интернет при помощи собственных оконечных устройств: рабочих станций, мобильных телефонов, планшетов, ноутбуков и т.п. В системах с относительно малым числом ВУ функции управляющей ЭВМ  и сервера доступа могут объединяться на одной машине.

Пользователи подключаются к серверу доступа через собственные клиентские машины. Каждому выделяется определенное дисковое пространство в системе хранения данных (СХД) суперкомпьютерного центра. Это пространство монтируется на всех ВУ, сервере доступа и управляющей ЭВМ в каталоги с одними  и теми же именами, что дает возможность пользователю иметь одинаковый доступ к своим файлам на всех компонентах параллельного компьютера. Для получения доступа к ВУ пользователь оформляет так называемое задание – специальный информационный объект,  в состав которого в общем случае входят:

– параллельная программа, реализующая алгоритм решения прикладной задачи и состоящая из нескольких взаимодействующих процессов (потоков), которые могут одновременно выполняться на нескольких ВУ (процессорных ядрах);

– требования к параллельному ресурсу, под которым будем понимать подмножество ВУ, выделяемое заданию на определенное время, при этом величина параллельного ресурса (число ВУ и время выполнения) называется размером задания;

– входные данные параллельной програм- мы.

Обработку входного потока заданий от разных пользователей осуществляют специальные программные системы управления заданиями (СУЗ). В работе [1] сравниваются наиболее распространенные СУЗ.

Система PBS (Portable Batch System) [2]  ведет свою историю с 1991 года от системы NQS (Network Queuing System), считающейся первым планировщиком заданий для суперкомпьютеров. Существует несколько как открытых, так и коммерческих версий PBS, среди которых следует выделить OpenPBS/TORQUE [3] – свободно распространяемое решение и PBS Professional (PBS Pro) – проприетарную версию PBS.

Распространенной коммерческой СУЗ является IBM Spectrum LSF (Load Sharing Facility) [4]. Продукт поставляется совместно с супер- компьютерными системами фирмы IBM. Следует отметить производный от LSF проект OpenLAVA [5] – СУЗ с открытым исходным кодом, которая, по оценкам [1], обладает необходимым сбалансированным набором функций.

Другим известным коммерческим продуктом является Moab от компании Adaptive Computing. Он ведет свою историю от свободно распространяемого проекта Maui [6]. После прекращения его разработки все преимущества проекта были воплощены в новом коммерческом продукте Moab HPC Suite (https://adaptive computing.com/wp-content/uploads/2022/05/Moab- HPC-Suite_datasheet_05062022.pdf). Платформа Moab HPC Suite не только автоматизирует пла- нирование и управление заданиями, осуществляет мониторинг ресурсов параллельного компьютера и учет их потребления, но и использует многомерные политики и расширенное предсказательное моделирование для оптимизации планирования заданий.

Несмотря на мощность и широкий спектр возможностей коммерческих СУЗ, наибольшее распространение получила система SLURM (Simple Linux Utility for Resource Management – простая утилита Linux для управления ресурсами) [7], созданная для решения проблемы масштабируемости СУЗ. За 20-летнюю историю развития SLURM прошла путь от простой утилиты до развитого программного комплекса с множеством поддерживаемых функций и встроенных модулей. Система является свободно распространяемым в открытых исходных текстах программным продуктом, способным управлять параллельными компьютерами практически произвольной мощности. Отмечается, что главным преимуществом SLURM является модульная архитектура, позволяющая для добавления или изменения функционала подключать к системе различные модули третьих разработчиков [1]. Такая архитектура дает возможность настраивать SLURM для разных видов входных потоков заданий, различных программно-аппаратных стеков, политик планирования задания и т.п.

Среди отечественных разработок следует отметить систему Cleo [8], в начале 2000-х гг. разработанную в НИВЦ МГУ им. М.В. Ломоно- сова для эффективного управления ресурсами вычислительных кластеров. Система организует поток вычислительных заданий в одну или несколько очередей и позволяет управлять порядком их выполнения на кластерах. В качестве вычислительной единицы в Cleo используется процессор. Система дает возможность оперировать понятием ВУ, но рассматривает узел как объединение нескольких равноправных процессоров. Cleo написана на интерпретируемом языке Perl, что позволяет портировать ее практически на любую вычислительную систему. К сожалению, с появлением SLURM разработки и развитие Cleo были свернуты.

Другая отечественная СУЗ – Slurm-ВНИИТФ [9] – разработана и функционирует  в РФЯЦ-ВНИИТФ им. акад. Е.И. Забабахина. В основе системы лежит менеджер ресурсов SLURM. Система Slurm-ВНИИТФ расширяет функции SLURM и предоставляет дополнительные возможности управления заданиями. Главной из них является разделение заданий на классы в зависимости от срочности выполнения. Выделяются класс интерактивных заданий, необходимых для отладки и визуализации расчетов, и класс фоновых заданий, которые при поступлении более приоритетных заданий могут вытесняться с выполнения с сохранением промежуточных результатов расчетов.  За счет возможности перезапуска фоновых заданий система Slurm-ВНИИТФ обеспечивает обработку более интенсивного потока заданий по сравнению со стандартной версией SLURM. В то же время авторы отмечают в высокой степени специализированный характер предлагаемых ими подходов.

Начиная с 1999 года в ИПМ им. М.В. Келдыша РАН и в МСЦ РАН – отделении суперкомпьютерных систем и параллельных вычислений НИЦ «Курчатовский институт» разрабатывается и эксплуатируется отечественная СУЗ – Система управления прохождением параллельных заданий (СУППЗ). В ранее проведенных исследованиях [10, 11] СУППЗ сравнивалась с рядом СУЗ (SLURM, PBS и Microsoft HPC Server). Исследования показали, что сравниваемые системы обладают относительно оди- наковыми качественными характеристиками,  а также имеют паритет по основным показателям качества, таким как загрузка (утилизация) ресурсов, среднее время ожидания в очереди  и средний коэффициент замедления заданий.

Несмотря на более чем 25-летнюю историю исследований, развития и разработок, модель управления ресурсами и архитектура СУППЗ до настоящего времени не были подробно рассмотрены в научных публикациях, и настоящая статья призвана восполнить этот пробел.

Управление вычислительными ресурсами суперкомпьютера при организации  режима коллективного пользования

Рассмотрим основные задачи организации режима.

Подготовка пользователями программ  и данных для высокопроизводительных рас- четов. Размещая программы и данные в СХД суперкомпьютерного центра, на сервере досту- па пользователи осуществляют редактирование входных данных и исходных текстов программ, трансляцию и сборку программ, подготовку их к выполнению, которая заключается  в оформлении соответствующего задания. Задание, как правило, представляет собой текстовый файл определенного формата, называемый паспортом. Паспорт задания направляется на вход СУЗ, которая разделяется на клиентскую и серверную части (рис. 1). Клиентская часть – это набор команд или API, выполняемых пользователями на сервере доступа. Серверная часть функционирует на управляющей ЭВМ и реализует дальнейший порядок обработки задания.

Формирование входного потока заданий из множества различных заданий разного размера от разных пользователей. Во время приема очередного задания СУЗ осуществляет:

– авторизацию пользователя, направившего задание в СУЗ;

– проверку правильности оформления паспорта задания;

– проверку действительности квот пользователя на доступ к запрашиваемым ВУ;

– присваивание заданию уникального имени или иного идентификатора;

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

Ведение очереди заданий на управляющей ЭВМ. Выполнение этой задачи необходимо, когда для очередного задания из входного потока в определенный момент времени требуемый параллельный ресурс будет занят. На рисунке 1 цветом выделены ВУ, занятые разными заданиями (один цвет соответствует одному заданию), а свободные ВУ не окрашены. Важнейшая задача СУЗ при ведении очереди – планирование заданий, под которым понимается составление расписания их запусков на решающем поле.

Применяемые методы планирования заданий в большинстве СУЗ основаны на приоритетной невытесняющей дисциплине обслуживания с динамическим справедливым распределением ресурсов [12]. Суть этого подхода  в том, что, чем больше ресурсов пользователь потребил, тем ниже приоритет его заданий.  В рамках одного приоритета задания обрабатываются строго в порядке поступления в очередь (принцип FCFS). Однако в большинстве СУЗ разрешен запуск вне очереди заданий, которые не повлияют на время старта стоящих впереди. Такое возможно, например, в случае, если для задания А, стоящего в очереди выше, недостаточно ресурсов и при этом задание Б, стоящее в очереди ниже, успеет завершиться до момента, когда освободится достаточное количество ресурсов для запуска задания А. Принцип такого перераспределения заданий впервые был представлен в [13] и получил название обратного заполнения. В настоящее время стратегия обратного заполнения является основной для всех современных СУЗ, поскольку позволя- ет радикально повысить утилизацию ресурсов.

Выделение заданию требуемых вычислительных ресурсов после прохождения очереди. СУЗ выполняет следующие действия:

– выбрать для задания ВУ из числа свободных;

– проверить работоспособность выбран- ных ВУ;

– провести конфигурацию выбранных ВУ;

– предоставить доступ пользователю – владельцу задания на выделенные узлы;

– зафиксировать факт старта задания в системных журналах.

Выбор ВУ из состава свободных производится в соответствии с требованиями задания  и далеко не всегда является тривиальным. Если ВУ однородны, выбор может сводиться к поиску наиболее связного подмножества узлов, чтобы обеспечить высокую скорость информационных обменов. Например, в [14] рассмотрена задача выбора узлов в суперкомпьютерной системе на базе отечественной коммуникационной среды «Ангара», которая решается таким образом, чтобы сетевой трафик разных заданий не пересекался.

В случае гетерогенного вычислителя могут применяться различные критерии выбора. Например, можно подобрать заданию ВУ, удовлетворяющие требованиям по минимуму, а можно, наоборот, выделять в первую очередь самые мощные узлы, чтобы задание выполнилось как можно быстрее.

На этапе проверки работоспособности ВУ производится диагностика узлов, в ходе которой тестируются доступность узла и СХД,  а также готовность основных программных  и аппаратных подсистем. Сценарий тестирования разрабатывается системным администратором с учетом нюансов, присущих конкретному суперкомпьютерному центру. Если какой-либо ВУ не проходит диагностику, он помечается как неисправный, выводится из состава решающего поля, а для задания подбирается другой, исправный узел.

Конфигурация выбранных ВУ для задания преследует две цели: предоставление заданию требуемой программной платформы и обеспечение взаимной изоляции заданий. Требуемая программная платформа может быть предостав- лена в следующих видах:

– окружение, сформированное для используемых заданием прикладных программных пакетов;

– набор прикладных или коммуникационных библиотек, иных инструментальных средств, упакованных в контейнер;

– отдельный экземпляр ОС в виде виртуальной машины;

– перезагрузка ВУ с переключением на другую ОС.

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

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

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

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

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

– прекращение доступа пользователя-владельца задания на занятые заданием ВУ;

– прекращение выполнения всех процессов задания на каждом выделенном для него ВУ;

– освобождение захваченных заданием разделяемых ресурсов ВУ, таких как очереди и семафоры IPC, области разделяемой памяти, временные файлы и др.;

– реконфигурацию ВУ, подразумевающую их возврат в то состояние, которое было до  запуска задания;

– фиксацию факта и статуса завершения задания в системных журналах.

Следует отметить, что освобождение занятых заданием вычислительных ресурсов является отнюдь не тривиальным процессом. Поскольку на алгоритм и код параллельной программы  не накладывается никаких ограничений, ВУ вправе совершать любые не запрещенные ОС анормальные действия, в том числе зависать самим и подвешивать ОС, не возвращать или терять занятую память, бесконтрольно размножаться и т.п. Если СУЗ не удается пресечь анормальные действия процессов задания и корректно завершить их выполнение, то ВУ либо перезагружается, либо помечается как аварийный и выводится из состава решающего поля.

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

Непрерывный мониторинг состояния вычислительных ресурсов параллельного компьютера во время его работы. Помимо отсле- живания работоспособности, готовности и загруженности ВУ решающего поля, систем энергоснабжения и охлаждения, подсистема мониторинга может в автоматическом или автоматизированном режиме отслеживать эффек- тивность использования вычислительных ресурсов каждым заданием. Некоторые системы мониторинга [15] способны выдавать пользователям рекомендации по оптимизации выполнения их заданий. Немаловажной функцией подсистемы мониторинга является наглядное интерактивное графическое отображение состо- яния подсистем параллельного компьютера [16], помогающее администраторам осуществлять оперативный контроль работоспособности и эффективности использования вычислительных ресурсов.

Учет потребления пользовательскими заданиями ресурсов параллельного компьютера. С этой целью СУЗ в том или ином виде ведет БД, способную собирать и обрабатывать статистическую информацию о работе параллельного компьютера. В такой БД сохраняется информация об обработанных заданиях, включая время поступления и характеристики каж- дого задания, время его старта и завершения, изменения в составе и статусе ВУ, изменения параметров планирования заданий и др. Пользователям и администрации суперкомпьютерного центра БД предоставляет статистические отчеты за заданный период, отражающие объемы потребленных ресурсов каждым заданием, пользователем, группой пользователей, организацией. Кроме этого, в БД могут записываться данные подсистемы мониторинга, отражающие степень загруженности и эффективности использования вычислительных ресурсов.

Иерархическая модель управления  вычислительными ресурсами  суперкомпьютерной системы

В фундаментальной работе [1] представле- на модель СУЗ, основанная на разбиении систе- мы по функциональному признаку. Эта модель выделяет подсистемы управления жизненным циклом задания и вычислительными ресурсами, планирования и выполнения заданий. Такая модель соответствует практически любой СУЗ, но при этом не отражает иерархическую структуру управления в параллельных вычислительных системах.

В монографии [17] рассмотрена иерархическая модель управления многопроцессорными вычислительными системами (МВС). Предполагается, что в МВС могут быть выделены отдельные подсистемы и на каждую выделенную подсистему может быть назначен определенный вид вычислительных работ. Состояние МВС, связанное с определенным разбиением на подсистемы и с назначением на подсистемы определенных видов работ, называется функциональным, или F-состоянием системы. Периодически в такой системе необходимо производить перераспределение ресурсов, то есть изменение F-состояния системы.

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

Разделим СУЗ на иерархические уровни, каждый из которых уменьшает неопределен- ность сложной мультипрограммной ситуации, определяя и фиксируя ряд параметров для вышестоящего уровня. Выделим четыре базовых уровня принятия решений.

Первый уровень – уровень пользователя, который выбирает алгоритмы для своих задач, средства для записи алгоритмов, их анализа, отладки и т.п. На втором уровне принимаются локальные, автономные решения по распределению ресурсов в рамках одного или нескольких ВУ. На третьем принимаются решения, связанные с управлением подсистемой ВУ, а на четвертом – системные решения, изменяющие F-состояние отдельной суперкомпьютерной системы. Эти решения определяются приоритетами режимов функционирования, очередью заданий, состоянием ресурсов системы, директивами оператора и т.п.

Дополним модель [17] пятым уровнем иерар- хии, на котором представлены средства управления несколькими параллельными компьютерами, объединенными в единую распределенную вычислительную систему (РВС). На этом уровне принимаются глобальные решения по распределению вычислительных работ по очередям суперкомпьютерных систем, входящих  в РВС.

Представим СУЗ совокупностью блоков  {Sij (i = 1, 2, 3, 4, 5; j = 1, 2, …, J(i)}, где i – соответствующий уровень иерархии (рис. 2).

Рассмотрим соответствие между блоками разных уровней иерархии и типовой архитектурой параллельного компьютера (рис. 3).

Пусть P = {pi: i = 1…C} – множество процессорных ядер, а N = {ni: i = 1…M} – множество ВУ распределенной вычислительной системы, соответственно, С – общее число ядер, M – общее число узлов в РВС. Данная РВС со-стоит из L МВС, каждая из которых ведет собственную (локальную) очередь заданий. Пусть в некоторый момент времени существует множество W = {ti: i = 1…T} назначенных работ, то есть множество выполняющихся в данный момент времени заданий, T – общее число работ (заданий). Каждая работа ti является назначенной на некоторую подсистему = {: k =  = 1…}, состоящую из ВУ. Заметим, что

При этом существует некоторое множество nfree, такое, что

Множество nfree – это множество не занятых ни одной работой, свободных ВУ. Общее число занятых под работы узлов составляет

Разбиение множества N на подмножества с назначением на каждое подмножество  опре- деленной работы ti фактически определяет текущее F-состояние всей РВС.

Первый уровень иерархии будут представлять средства управления отдельным процессорным ядром, причем J(1) = C. Блоки S1j представляют собой ветви параллельной программы: потоки либо процессы в зависимости от модели параллельного программирования. Каждый блок S1j назначается на процессорное ядро pj средствами вышестоящего второго уровня иерархии, и задача управления вычислительным процессом на этом уровне целиком возлагается на пользователя-программиста, который в зависимости от прикладного алгоритма определяет степень параллелизма своей программы. Например, программист может задействовать или не задействовать векторные команды, использовать механизмы распараллеливания графических процессоров и т.п.

Второй уровень иерархии образуют средства управления отдельным ВУ. Средства второго уровня осуществляют контроль над средствами первого уровня и имеют возможность вмешиваться в их работу, прерывать и даже уничтожать и порождать новые. Кроме этого, средства второго уровня контролируют взаимодействие блоков как первого, так и второго уровня. Число блоков второго уровня равно числу ВУ в системе, J(2) = N. Блоки S2j представляют ОС ВУ, контролирующие взаимодействующие потоки и процессы параллельной программы. В состав ОС ВУ также включаются компоненты СУЗ, управляющие отдельным ВУ. Узлы {ni : i = 1…m} заняты определенными работами (заданиями), соответствующие им управляющие средства {S2i : i = 1…m} находят- ся в режиме функционирования. Узлы {nj : j =  = m+1 … N} свободны, соответствующие им управляющие средства {S2j : j = m+1…N} находятся в режиме ожидания (бездействия) или отсутствуют. Назначение работы ti на некоторый узел nj производится средствами вышестоящего, третьего, уровня иерархии.

Третий уровень иерархии представлен средствами управления подсистемами (подмножествами узлов)  Число блоков третьего уровня равно числу выделенных подсистем,  то есть числу назначенных заданий, J(3) = T. Средства третьего уровня полностью контролируют средства второго уровня в рамках подчиненных им подсистем. Блоки S3j представляют собой компоненты СУЗ, выполняющиеся на управляющей ЭВМ и контролирующие запуск, выполнение и завершение отдельного  задания, для которого выделено некоторое подмножество ВУ.

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

– разделение одного узла между процессами разных заданий ослабляет изоляцию заданий и неизбежно влечет их конкуренцию за ресурсы узла и, как следствие, снижение скорости вычислений в обоих заданиях;

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

Следует отметить, что для мощных мно- гоядерных ВУ с несколькими ускорителями фрагментация может обойтись достаточно дорого и в этом случае приходится разделять один ВУ между разными заданиями [18].

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

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

1.    Для любых i, j = 1… T выполняется

2.    Для любых i, j = 1… T взаимодействие между блоками S2i и S2j будет разрешено тогда и только тогда, когда существует такое k = 1… T, что  и

Четвертый уровень иерархии образуют средства, управляющие очередью отдельной МВС. Средства этого уровня полностью контролируют средства нижестоящего, третьего, уровня и имеют возможность формировать отображение множества заданий W на мно- жество подсистем  Число блоков J(4) = L равно числу локальных очередей МВС в составе распределенной вычислительной систе- мы. Блоки S4j представляют собой локальные планировщики СУЗ, выполняющиеся на управляющей ЭВМ и составляющие расписание запусков заданий на соответствующих им МВС. В состав блоков S4j включаются также средства приема входного потока заданий от вышестоящего, пятого, уровня иерархии.

Пятый уровень иерархии представлен средствами, обеспечивающими доступ пользователей и администраторов к ресурсам системы. На этом уровне формируется входной поток заданий для локальных очередей МВС. Это могут быть запросы пользователей локальной МВС либо один или несколько планировщиков глобальной очереди заданий, распре- деляемых в распределенной вычислительной  системе. Число блоков J(5) = K можно рассматривать как число различных управляющих функций пятого уровня иерархии, таких как команды отправки заданий в локальную и глобальную очереди, контроля выполнения зада- ний, средства ведения глобальной очереди заданий (метапланировщик) и др.

В отличие от функциональной модели [1] представленная иерархическая модель в явном виде отображает схему распараллеливания обработки информации в суперкомпьютерном центре коллективного пользования. На высшем, пятом, уровне происходит распределение крупных вычислительных работ (заданий) между разными очередями, каждая из которых представляет собственную суперкомпьютерную систему или ее раздел. Уровнем ниже задания распределяются между подсистемами одного раздела, при этом обеспечивается мультизадачный режим работы, подразумевающий одновременное выполнение нескольких заданий  на разных непересекающихся подсистемах.  На третьем уровне в рамках одной подсистемы осуществляется распределение вычислительной работы между узлами суперкомпьютера. Дальнейшее распараллеливание происходит на втором уровне в рамках ВУ, когда процессы или потоки прикладной программы распределяются по ядрам как центрального процессора, так и ускорителя вычислений. Наконец, на нижнем, первом, уровне назначенный на ядро процесс (поток) пользовательской программы использует возможности распараллеливания процессоров, такие как векторизация кода [19], одновременная [20] и/или гетерогенная многопоточность [21].

Архитектура системы управления  прохождением параллельных заданий

В соответствии с представленной иерархической моделью была построена архитектура СУППЗ, которая представлена на рисунке 4,  а соответствие компонентов архитектуры уровням иерархической модели отражено на рисунке 5.

Архитектурно СУППЗ можно разделить на ядро и надстройки. Ядро включает планировщик (сервер очереди) и служебные процессы: клиентское приложение, серверы запросов и запуска и менеджеры заданий. Надстройками являются подсистемы:

– сценариев пользовательских команд;

– команд и утилит оператора и системного программиста;

– сценариев управления заданием;

– сценариев диагностики, выделения и осво- бождения узлов.

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

Для стандартных сред параллельного программирования, например, различных реализаций MPI, СУППЗ предоставляет надстройку сценариев подготовки задания, предназначение которых – автоматизация подготовки паспорта задания для выполнения параллельной программы в заданной стандартной среде. При применении пользователем сценариев над- стройки соответствующий сценарий выполнения задания будет сформирован системой автоматически. На рисано, что в результате работы сценариев подготовки заданий X и Y формируются соответствующие сценарии выполнения заданий.

Сценарии подготовки заданий, взаимодействуя с клиентской утилитой на сервере доступа, обеспечивают подготовку входного потока заданий и могут быть отнесены к пятому уровню управления. На этом же уровне располагаются не входящие в состав СУППЗ средства управления глобальной очередью.

Клиентская утилита обеспечивает авторизованный доступ пользователя к нижестоящему, четвертому, уровню управления через связь с сервером запросов, выполняющимся на управляющей ЭВМ. При этом применяется сетевой протокол сервера запросов, обеспечивающий постановку задания в очередь, просмотр состояния очереди, снятие задания с выполнения или удаление его из очереди и другие действия управления. На четвертом уровне управления функционирует сервер очереди, осуществляющий планирование заданий в соответствии с методом, подробно рассмотренным в работе [22]. На этом же уровне выполняются команды оператора из соответствующей надстройки. Для взаимодействия со служебными процессами ядра и командами надстройки применяется специфицированный протокол сервера очереди.

Третий уровень управления представлен служебными процессами ядра – сервером запуска и менеджером задания. Сервер запуска производит выделение ВУ для задания, их диагностику и конфигурацию, для чего применяет сценарии соответствующей надстройки. При обнаружении неисправных узлов последние автоматически выводятся из состава вычислителя, а задание возвращается в очередь на перепланирование. Менеджер задания открывает отдельный сеанс, в котором запускает на управляющей ЭВМ главный управляющий сценарий, определяющий действия по управлению выделенной подсистемой узлов. В частности,при этом сценарии возможна передача функций управления узлами сторонней СУЗ [23].

На первом из выделенных заданию узлов от имени администратора выполняется сценарий управления заданием, который поддерживает возобновляемый сеанс взаимодействия с главным управляющим сценарием, за счет чего, например, возможна независимая перезагрузка управляющей ЭВМ без прерывания выполнения заданий.

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

Качественные характеристики СУППЗ

Императивность управления. Наиболее полно принцип императивности управления был сформулирован в монографии [24]. Принцип постулирует техническую невозможность таких действий пользователя и процессов его прикладной программы, которые потенциально могут привести к нарушению работы как других прикладных программ, так и всей суперкомпьютерной системы. В СУППЗ императивность управления обеспечивается рассмотренным механизмом изоляции заданий. Кроме этого, при останове задания сценарии управления осуществляют принудительное завершение всех процессов пользователя и освобождение разделяемых ресурсов на выделенных заданию узлах. В случае невозможности освобождения ресурсов соответствующий узел автоматически выводится из состава вычислителя  с извещением сервера очереди и оператора.

На момент создания СУППЗ в 1999 году  в свободном распространении не было СУЗ, удовлетворяющих принципу императивности управления, что во многом обусловило необходимость разработки собственной СУЗ, которой и стала СУППЗ [24].

Надежность. СУЗ должна выполнять свои функции при любой, сколь угодно сложной мультипрограммной ситуации в системе. Напри- мер, пользовательские процессы могут зацикливаться, выдавать некорректные запросы  к ОС узла и к СУЗ, может произойти разрушение ОС ВУ. Во всех этих случаях, если нет аппаратных неисправностей в системе, СУЗ должна быть способной решать задачи управления  вычислительными ресурсами. Надежность в СУППЗ обеспечивается за счет принципа делегирования функций управления ресурсами высоконадежным компонентам и утилитам ОС с сохранением контроля за жизненным циклом заданий. Под высоконадежными понимаются такие компоненты, отказ которых означает неисправность всей суперкомпьютерной системы в целом. В СУППЗ в качестве таких компо- нентов выступают сетевая файловая система (NFS) и ОС Linux на узлах. Сетевая файловая система используется в СУППЗ для следующих критических функций управления:

– авторизация клиента сервером запросов;

– ведение оперативной БД статусов ВУ (свободен, занят, неисправен);

– контроль сценария управления заданием главным управляющим сценарием;

– перенаправление стандартных потоков ввода/вывода задания.

В отличие от SLURM, LSF и PBS подобное делегирование позволяет отказаться от наличия активных компонентов СУППЗ на ВУ: сце- нарий управления заданием запускается в момент старта задания через систему удаленного выполнения команд. Отсутствие активных ком- понентов на узлах, с одной стороны, исключает их выход из строя и повышает надежность функционирования суперкомпьютера, а с другой, открывает возможность применять для уп- равления ресурсами сторонние системы, такие как SLURM [23].

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

Автоматизация работы в стандартном программном окружении. Наличие в архитектуре СУППЗ надстройки сценариев подготовки заданий позволяет автоматизировать подготовку паспорта задания для некоторого стандартного программного окружения. Одной из таких групп сценариев, изначально входившей в состав СУППЗ, являются сценарии поддержки MPI-программ. СУППЗ имеет собствен- ную команду mpirun, осуществляющую автоматическое оформление для MPI-программы паспорта задания и постановку в очередь на выполнение. Практика показала, что именно MPI-надстройка оказалась наиболее востребованной пользователями и стала характерной особенностью СУППЗ.

Модульность архитектуры, позволяющая заменять отдельные компоненты системы с сохранением ее общей архитектуры. Модульность в СУППЗ обеспечивается:

– соответствием архитектуры иерархической модели управления ресурсами;

– разделением на ядро, не изменяемые и  изменяемые системным программистом над- стройки;

– применением специфицированных протоколов взаимодействия компонентов.

Ядро СУППЗ, реализованное на языке  высокого уровня, изменяется разработчиками сравнительно редко. Достаточно большое число функций управления и мониторинга, таких как диагностика ВУ, подключение разных сред программирования прикладных программных пакетов, реализованы в виде командных сценариев, что позволяет разработчикам при необходимости оперативно вносить изменения в си- стему, не затрагивая ядро. Наконец, разгра- ничение функций компонентов по уровням иерархии управления и применение специфицированных протоколов, таких как протоколы сервера запросов и сервера очереди, дали возможность подключения к СУППЗ ключевых сторонних компонентов. Примерами могут служить работа [6] по интеграции в СУППЗ известного планировщика Maui и применение для управления ВУ СУЗ SLURM [23].

Результаты эксплуатации  СУППЗ

Эксплуатация СУППЗ осуществляется с 1999 года на множестве суперкомпьютерных систем МСЦ и ИПМ им. М.В. Келдыша РАН. Подробное описание суперкомпьютерных систем МСЦ РАН приведено на странице центра (https://www.jscc.ru/resources/hpc/). Описание суперкомпьютерных систем ИПМ им. М.В. Келдыша РАН дано в работе [25]. Обобщенная статистика о числе пользователей-исследователей и выполненных ими заданиях на некоторых  суперкомпьютерных системах (разделах) под уп- равлением СУППЗ приведена в таблице. Кроме перечисленных в ней вычислительных систем, под управлением СУППЗ работали установленные в МСЦ РАН суперкомпьютеры серии МВС-1000 [26], а в ИПМ им. М.В. Келдыша РАН суперкомпьютеры МВС-1000/16, МВС-1000/RSC4, МВС-Экспресс [27].

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

Общее число выполненных под управлением СУППЗ заданий составляет более 3,7 млн. Общее число исследователей, воспользовавших- ся услугами СУППЗ, насчитывает в МСЦ РАН свыше 1 240 человек, а в ИПМ им. М.В. Келдыша РАН – свыше 280 человек. Общее число научных проектов, реализованных при помощи суперкомпьютеров МСЦ РАН, превышает 530, а реализованных при помощи суперкомпьютеров ИПМ им. М.В. Келдыша РАН – более 32.

Десятилетия успешной эксплуатации СУППЗ позволяют говорить о сформировавшейся на ее основе цифровой экосистеме. В работе [28] такая экосистема определяется как цифровое пространство, построенное на базе одной или нескольких цифровых платформ и включающее в себя совокупность сервисов, которые позволяют пользователям удовлетворять разнообразные потребности в рамках реализации единого бесшовного процесса. В данном случае именно СУППЗ предоставляет пользователям сервисы высокопроизводительных вычислений в рамках реализации процесса научных исследований.

Заключение

В статье предложена архитектура системы управления заданиями пользователей, основанная на иерархической пятиуровневой модели управления вычислительными ресурсами суперкомпьютерной системы коллективного пользования. Предложенная архитектура реа- лизована в виде программной системы, обес- печивающей императивность и надежность управления вычислительными ресурсами, возможность реконфигурации в процессе функционирования. Кроме того, СУППЗ позволяет  автоматизировать работу пользователей в стандартных средах параллельного программирования. Модульность архитектуры СУППЗ дает возможность подключать к системе компоненты сторонних производителей. За 25 лет эксплуатации СУППЗ ее услугами воспользовались более 1 240 пользователей-исследователей, выполнивших свыше 3,7 млн. заданий при реализации более чем 530 научных проектов. Сложившаяся практика работы суперкомпьютеров под управлением СУППЗ позволяет  говорить о формировании на ее основе цифровой экосистемы научного суперкомпьютерного центра.

Список литературы

1. Reuther A., Byun C., Arcand W., Bestor D. et al. Scalable system scheduling for HPC and big data. J. of Parallel and Distributed Computing, 2018, vol. 111, pp. 76–92. doi: 10.1016/j.jpdc.2017.06.009.

2. Henderson R.L. Job scheduling under the portable batch system. In: JSSPP. LNCS, 1995, vol. 949, pp. 279–294. doi: 10.1007/3-540-60153-8_34.

3. Staples G. TORQUE resource manager. Proc. ACM/IEEE Conf. SC, 2006, pp. 35–40. doi: 10.1145/1188455.1188464.

4. Quintero D., Black M., Hussein A.Y., McMillan B.S., Samu G., Welch J.S. IBM Spectrum LSF Suite: Installation Best Practices Guide, 2020, 94 p.

5. Joshi P., Babu M.R. Openlava: An open source scheduler for high performance computing. Proc. Int. Conf. RAINS, 2016, pp. 1–3. doi: 10.1109/RAINS.2016.7764375.

6. Баранов А.В., Голинка Д.М. Система управления прохождением задач и планировщик Maui для МВС-100К // Научный сервис в сети Интернет: масштабируемость, параллельность, эффективность: тр. Всерос. суперкомпьютерной конф. 2009. C. 314–315.

7. Jette M.A., Wickberg T. Architecture of the slurm workload manager. In: LNCS. JSSPP, 2023, vol. 14283, pp. 3–23. doi: 10.1007/978-3-031-43943-8_1.

8. Воеводин В.В., Жуматий С.А. Вычислительное дело и кластерные системы. М.: Изд-во МГУ, 2007. 150 с.

9. Игнатьев А.О., Калинин А.А., Мокшин С.Ю. Реализация функций управления задачами и ресурсами высокопроизводительной вычислительной системы в «СПО Супер-ЭВМ» // Тр. ИСП РАН. 2022. Т. 34. № 2. С. 159–178. doi: 10.15514/ISPRAS-2022-34(2)-13.

10. Баранов А.В., Ляховец Д.С. Сравнение качества планирования заданий в системах пакетной обработки SLURM и СУППЗ // Научный сервис в сети Интернет: все грани параллелизма: тр. Междунар. суперкомпьютерной конф. 2013. С. 410–414.

11. Баранов А.В., Киселев А.В., Старичков В.В., Ионин Р.П., Ляховец Д.С. Cравнение систем пакетной обработки с точки зрения организации промышленного счета // Научный сервис в сети Интернет: поиск новых решений: тр. Междунар. суперкомпьютерной конф. 2012. С. 506–508.

12. Yalim J. Toward dynamically controlling slurm’s classic fairshare algorithm. Proc. PEARC, 2020, pp. 538–542. doi: 10.1145/3311790.3399628.

13. Lifka D.A. The ANL/IBM SP scheduling system. In: LNCS. JSSPP, 1995, vol. 949, pp. 295–303. doi: 10.1007/3-540-60153-8_35.

14. Мукосей А.В., Семенов А.С., Симонов А.С. Оптимизация утилизации при выделении ресурсов для высокопроизводительных вычислительных систем с сетью Ангара // Вестн. ЮУрГУ. Сер.: Вычислительная математика и информатика. 2019. Т. 8. № 1. С. 5–19. doi: 10.14529/cmse190101.

15. Nikitenko D., Zhumatiy S., Paokin A., Voevodin V. Evolution of the octoshell HPC center management system. In: CCIS. Proc. PCT, 2019, vol. 1063, pp. 19–33. doi: 10.1007/978-3-030-28163-2_2.

16. Костенецкий П.С., Шамсутдинов А.Б., Чулкевич Р.А., Козырев В.И. HPC TaskMaster – система мониторинга эффективности задач суперкомпьютера // Суперкомпьютерные дни в России: тр. Междунар. конф. 2021. С. 18–25. doi: 10.29003/m2454.RussianSCDays2021.

17. Миренков Н.Н. Параллельное программирование для многомодульных вычислительных систем. М.: Радио и связь, 1989. 320 с.

18. Kostenetskiy P.S., Chulkevich R.A., Kozyrev V.I. HPC resources of the higher school of economics. JPCS, 2021, vol. 1740, art. 012050. doi: 10.1088/1742-6596/1740/1/012050.

19. Savin G., Shabanov B., Rybakov A., Shumilin S. Vectorization of flat loops of arbitrary structure using instructions AVX-512. Lobachevskii J. of Math., 2020, vol. 41, pp. 2575–2592. doi: 10.1134/S1995080220120331.

20. Nemirovsky M., Tullsen D.M. Simultaneous multithreading. In: Multithreading Architecture. SLCA, 2013, pp. 33–40. doi: 10.1007/978-3-031-01738-4_5.

21. Hsu K.Ch., Tseng H.W. Simultaneous and heterogenous multithreading: Exploiting simultaneous and heterogeneous parallelism in accelerator-rich architectures. IEEE Micro, 2024, vol. 44, no. 4, pp. 11–19. doi: 10.1109/mm.2024.3414941.

22. Baranov A.V. HPC scheduling method based on debug and background job classes division. Lobachevskii J. of Math., 2024, vol. 45, pp. 4899–4911. doi: 10.1134/S1995080224606118.

23. Баранов А.В., Киселев Е.А. Интеграция систем управления заданиями SLURM и СУППЗ // Тр. НИИСИ РАН. 2019. Т. 9. № 5. С. 29–35.

24. Лацис А.О. Как построить и использовать суперкомпьютер. М.: Бестселлер, 2003. 240 с.

25. Якобовский М.В., Корнилина М.А. Развитие суперкомпьютерных технологий в ИММ РАН и ИПМ им. М.В. Келдыша РАН // Computational Math. and Inform. Tech. 2024. Т. 8. № 1. С. 12–28. doi: 10.23947/2587-8999-2024-8-1-12-28.

26. Забродин А.В., Левин В.К., Корнеев В.В. Массово параллельные системы МВС-100 и МВС-1000 // Научная сессия МИФИ. 2000. Т. 2. С. 194–195.

27. Давыдов А.А., Лацис А.О., Луцкий А.Е. Смольянов Ю.П., Четверушкин Б.Н., Шильников Е.В. Многопроцессорная вычислительная система гибридной архитектуры МВС-Экспресс // Докл. Академии наук. 2010. Т. 434. № 4. С. 459–463.

28. Каленов О.Е. Цифровые экосистемы организаций // Вестн. РЭУ им. Г.В. Плеханова. 2022. Т. 19. № 1. С. 139–147. doi: 10.21686/2413-2829-2022-1-139-147.

References

1. Reuther, A., Byun, C., Arcand, W., Bestor, D. et al. (2018) ‘Scalable system scheduling for HPC and big data’, J. of Parallel and Distributed Computing, 111, pp. 76–92. doi: 10.1016/j.jpdc.2017.06.009.

2. Henderson, R.L. (1995) ‘Job scheduling under the portable batch system’, in JSSPP. LNCS, 949, pp. 279–294. doi: 10.1007/3-540-60153-8_34.

3. Staples, G. (2006) ‘TORQUE resource manager’, Proc. ACM/IEEE Conf. SC, pp. 35–40. doi: 10.1145/1188455.1188464.

4. Quintero, D., Black, M., Hussein, A.Y., McMillan, B.S., Samu, G., Welch, J.S. (2020) IBM Spectrum LSF Suite: Installation Best Practices Guide, 94 p.

5. Joshi, P., Babu, M.R. (2016) ‘Openlava: An open source scheduler for high performance computing’, Proc. Int. Conf. RAINS, pp. 1–3. doi: 10.1109/RAINS.2016.7764375.

6. Baranov, A.V., Golinka, D.M. (2009) ‘Baranov, A.V., Golinka, D.M. (2009) ‘Task flow control system and Maui scheduler for МВС-100К’, Proc. Scientific Service on the Internet: Scalability, Concurrency, Efficiency, pp. 314–315
(in Russ.).

7. Jette, M.A., Wickberg, T. (2023) ‘Architecture of the slurm workload manager’, in LNCS. JSSPP, 14283, pp. 3–23. doi: 10.1007/978-3-031-43943-8_1.

8. Voevodin, V.V., Zhumatiy, S.A. (2007) Computer Science and Cluster Systems. Moscow, 150 p. (in Russ.).

9. Ignatyev, A.O., Kalinin, A.A., Mokshin, S.Yu. (2022) ‘Task and resources management function in HPC operation system “SPO Super-EVM”, Proc. of ISP RAS, 34(2), pp. 159–178 (in Russ.). doi: 10.15514/ISPRAS-2022-34(2)-13.

10. Baranov, A.V., Lyakhovets, D.S. (2013) ‘Comparison of the quality of job scheduling in workload management systems SLURM and SUPPZ’, Proc. Int. Supercomputing Conf. Scientific Services and Internet: All Facets of Parallelism, pp. 410–414 (in Russ.).

11. Baranov, A.V., Kiselev, A.V., Starichkov, V.V., Ionin, R.P., Lyakhovets, D.S. (2012) ‘Comparison of batch processing systems in terms of industrial account organization’, Proc. Int. Supercomputing Conf. Scientific Services and Internet: Searching for New Solutions, pp. 506–508 (in Russ.).

12. Yalim, J. (2020) ‘Toward dynamically controlling slurm’s classic fairshare algorithm’, Proc. PEARC, pp. 538–542. doi: 10.1145/3311790.3399628.

13. Lifka, D.A. (1995) ‘The ANL/IBM SP scheduling system’, in LNCS. JSSPP, 949, pp. 295–303. doi: 10.1007/3-540-60153-8_35.

14. Mukosey, A.V., Semenov, A.S., Simonov, A.S. (2019) ‘Allocation optimization for reducing resource utilization in angara high-speed interconnect’, Bull. of the SUrSU. Ser. Computational Math. and Software Eng., 8(1), pp. 5–19 (in Russ.). doi: 10.14529/cmse190101.

15. Nikitenko, D., Zhumatiy, S., Paokin, A., Voevodin, V. (2019) ‘Evolution of the octoshell HPC center management system’, in CCIS. Proc. PCT, 1063, pp. 19–33. doi: 10.1007/978-3-030-28163-2_2.

16. Kostenetskiy, P.S., Shamsutdinov, A.B., Chulkevich, R.A., Kozyrev, V.I. (2021) ‘HPC TaskMaster system for monitoring the efficiency of supercomputer tasks’, Proc. Int. Conf. Russian Supercomputing Days, pp. 18–25 (in Russ.). doi: 10.29003/m2454.RussianSCDays2021.

17. Mirenkov, N.N. (1989) Parallel Programming for Multimoduling Computing Systems. Moscow, 320 p. (in Russ.).

18. Kostenetskiy, P.S., Chulkevich, R.A., Kozyrev, V.I. (2021) ‘HPC Resources of the Higher School of Economics’, JPCS, 1740, art. 012050. doi: 10.1088/1742-6596/1740/1/012050.

19. Savin, G., Shabanov, B., Rybakov, A., Shumilin, S. (2020) ‘Vectorization of flat loops of arbitrary structure using instructions AVX-512’, Lobachevskii J. of Math., 41, pp. 2575–2592. doi: 10.1134/S1995080220120331.

20. Nemirovsky, M., Tullsen, D.M. (2013) ‘Simultaneous multithreading’, in Multithreading Architecture. SLCA, pp. 33–40. doi: 10.1007/978-3-031-01738-4_5.

21. Hsu, K.Ch., Tseng, H.W. (2024) ‘Simultaneous and heterogenous multithreading: Exploiting simultaneous and heterogeneous parallelism in accelerator-rich architectures’, IEEE Micro, 44(4), pp. 11–19. doi: 10.1109/mm.2024.3414941.

22. Baranov, A.V. (2024) ‘HPC scheduling method based on debug and background job classes division’, Lobachevskii J. of Math., 45, pp. 4899–4911. doi: 10.1134/S1995080224606118.

23. Baranov, A.V., Kiselev, E.A. (2019) ‘Integration of job management systems SLURM and SUPPZ’, Proc. of NIISI RAS, 9(5), pp. 29–35 (in Russ.).

24. Latsis, A.O. (2003) How to Build and Use a Supercomputer. Moscow, 240 p.

25. Yakobovskiy, M.V., Kornilina, M.A. (2024) ‘Development of supercomputer technologies at the institute of mathematical modelling and keldysh institute of applied mathematics of russian academy of sciences’, Computational Math. and Inform. Tech., 8(1), pp. 12–28 (in Russ.). doi: 10.23947/2587-8999-2024-8-1-12-28.

26. Zabrodin A.V., Levin V.K., Korneev V.V. (2000) ‘Massively parallel systems MVS-100 and MVS-1000’, Scientific Session of Institute of Nuclear Physics and Engineering, 2, pp. 194–195 (in Russ.).

27. Davydov, A.A., Latsis, A.O., Lutsky, A.E., Smolyanov, Yu.P., Chetverushkin, B.N., Shilnikov, E.V. (2010) ‘The hybrid supercomputer MVS-express’, Doklady Mathematics, 82(2), pp. 816–819.

28. Kalenov, O.E. (2022) ‘Digital ecosystems of organizations’, Vestn. of the Plekhanov Russian University of Economics, 19(1), pp. 139–147 (in Russ.). doi: 10.21686/2413-2829-2022-1-139-147.