Главное назначение ЯОЗ — это правильное отображение требований задачи на архитектуру СК кластера. В данном разделе мы ограничимся только теми требованиями, которые существенны с точки зрения задач из области нанонаук, в том числе задач моделирования наноматериалов, которые требуют выполнения большого объема параллельных вычислений.
Параллельные задачи отличаются по использованию разных технологий параллелизации (MPI/OpenMP) и разных подключаемых библиотек. Разные типы параллельных задач требуют разных условий для выполнения. Главные из них – это условия на наличие требуемых ресурсов и программное окружение.
Во-первых, требуется подходящий вычислительный ресурс, то есть вычислитель с заданным числом ядер в определенной конфигурации. При работе параллельной программы возможности ресурса используются оптимально, если каждый процесс/поток выполняется на отдельном ядре при максимально плотном распределении по узлам. Кроме количества ядер ресурс должен обеспечить для каждого запущенного процесса необходимый размер оперативной памяти и дискового пространства.
Во-вторых, разные реализации MPI на уровне коммуникационных библиотек не совместимы, поэтому запуск и работа скомпилированной программы предполагает наличие соответствующего MPI-окружения.
Для формализации описания произвольных задач ведем базовый набор возможных типов одиночных задач.
- single - простая последовательная задача, выполняется один процесс.
- omp - openmp-задача, может использовать указанное число N потоков,
выполняется на одном smp-узле.
- mpi - mpi-задача, использует заданное число M процессов, которые могут
работать на разных узлах.
- mix - гибридная mpi/openmp-задача, где каждый из M mpi-процессов
является openmp, порождающим N потоков.
При этом каждый openmp либо порождает число потоков N = числу ядер на узле(default), либо число порожденных потоков ограничивается переменной OMP_NUM_THREADS=N.
С точки зрения запроса необходимого количества ядер, для описания требований произвольной задачи (фактически это тип mix) формально достаточно двух параметров: число потоков N и число процессов M. ( число ядер: сount=NxM )
При этом не учитывается реальная топология распределения используемых ядер по узлам, которую локальный планировщик может задавать произвольным образом, исходя из своих соображений об эффективности загрузки кластера.
Но в реальности у многих задач есть ряд критичных к этому распределению параметров (количество памяти или доступный размер жесткого диска под временные файлы), которые недостижимы при наиболее эффективном (плотном) распределении процессов на узлах. Нормальная работа таких задач возможна лишь при избыточном резервировании ресурсов, например, тяжелая mpi-задача должна запускается в режиме 1 процесс на 1 узел, а не на ядро.
Кроме того, в случае openmp-задач не всегда можно гарантировать запуск с числом потоков, заданным пользователем, а не равным числу ядер на smp-узле.
Для обеспечения универсальности по отношению к таким задачам дополним модель распределенной исполняющей системы двумя условиями на реализацию алгоритма запроса ресурсов. А именно, пусть
‒.для mix-задач полностью резервируется M узлов (=числу mpi-процессов);
‒.для mpi-задач с повышенными требованиями к вычислительному элементу, также резервируется M узлов целиком. Т. е. такие mpi-задачи переходят в категорию mix.
Несложно видеть, что топология произвольной задачи может быть полностью определена заданием пары парамеров, причем пара может быть выбрана относительно произвольно:
‒.полное_число_ядер + число узлов
‒.полное_число_ядер + число_ядер_на_один_узел
‒.число_узлов + число_ядер_на_один_узел
(фактически, один параметр фиксирует полное количество ядер, а второй позволяет уточнить их распределение по узлам и способ запуска задачи)
Атрибуты описания задачи
В качестве пары параметров можно взять jobType + count, которая кажется наиболее удобной и естественной для пользователя, а также исключает возможность неправильной интерпретации ошибочной комбинации других вариантов.
По тем же соображениям целесообразно оставить для описания задачи все четыре типа jobType, несмотря на некоторую избыточность (как было показано выше, типы single, omp и mpi являются пересекающимися подмножествами mix).
Интерпретация сount при обработке запроса на ресурс описана в таблице 1
Таблица 1 - Интерпретация параметра count при обработке запроса на ресурс
jobType | Count |
single | Default=1 |
omp | число потоков=число ядер, если не задано, то default на ресурсе |
mpi | число mpi-процессов=число ядер, произвольное распределение по узлам |
mix | число mpi-процессов = число узлов, которые полностью резервируются под задачу |
Softenv - среда окружения, которая должна быть установлена при запуске. Требования:
‒.на каждом ресурсе должен быть задан default, устанавливаемый по умолчанию;
‒.пользователь должен имеет описание всех доступных окружений.
INPUT/OUTPUT - входные/выходных данных задачи.
Предполагается, что сервисы распределенной среды, средства LRMS и конфигурация конкретного ресурса могут обеспечить загрузку входных данных в рабочий каталог задачи, а по завершении работы – выгрузку в указанное пользователем место.
walltime - время, необходимое для выполнения задачи. Важные параметр, который должен учитываться при выборе ресурса и сравниваться с соответствующим параметром очереди - для успешного завершения программы ее время выполнения не должно превышать временные лимиты очереди.
‒.Количество оперативной памяти, необходимое одному процессу. (Сколько должно быть доступно на ресурсе в расчете на одно ядро).
‒.Количество временного дискового пространства, которое должно быть доступно задаче на время выполнения. В большинстве случаев можно сравнивать со свободным местом на доступном задаче NFS-разделе.
Тип архитектуры узлов вычислительного ресурса (x86_64, PowerPC,SPARC etc…). Может быть критично при компиляции программ, оптимизированных под конкретную архитектуру.
Тип интерконнекта на кластере (Eth1000, IB, Marynet etc). Параметр может быть критичен в mpi-задачах с интенсивным обменом.
MPI_Type – реализация MPI.
Как уже было отмечено, различные MPI-реализации несовместимы на уровне библиотек.