Раздел 1: Обзор концепций и свойств пакетной системы
Содержание
- Раздел 1: Обзор концепций и свойств пакетной системы
- Moab представляет "Единый образ системы"
- Архитектура программного обеспечения пакетной системы
- Viewpoint облегчает использование, мониторинг и администрирование
- Viewpoint - удалённая визуализация
- Интеллектуальная диспетчеризация
- Динамичное выделение рабочей нагрузки, управляемое повторно собираемыми образами вычислительных узлов
- Динамичное автоматическое масштабирование кластера: эластичные вычисления
- Динамичное развёртывание с использованием Docker
- Совместное планирование множества типов ресурсов в одном задании
- Расширенное разбиение данных на стадии Moab
- Разбиение данных на стадии Moab для управления групповым буфером
- Менеджер учётных записей Moab - управление динамическим выделением
- Выбор Moab & Torque вместо альтернатив
Adaptive Computing Moab является решением, выбранным для многих признанных международных центров HPC по всему миру. В данном первом разделе приводится озор выбранных концепций. Здесь мы также выделяем взаимодействие с OpenStck и другими инструментами подготовки к работе, делая доступной всю возможную гибкость И производительность для требующихся приложений.
несмотря на то, что вычислительный кластер является флагманом системы в любом вычислительном центре, для пользоваттеля должны быть интегрированы и сделаны доступными простым образом прочие системы, такие как предварительная и окончательная обработка, многопроцессорные узлы с большими данными, кластеры визуализации, кластеры ускорения и многое другое. С точки зрения пользователя это можно назвать "Единым образом системы"
Moab реализует такой "Единый образ системы" и делает доступной полные использование и производительность, предоставляя наилучшие возможные значения для гетерогенных систем HPC.
Одним из примеров является "Диспетчеризация дуального домена Moab" (“Moab Dual Domain Scheduling”), позволяющая заданиям выделять ресурсы из вычислительного кластера и - в пределах одного и того же отдельного задания - например, многопроцессорных узлов с большими данными, существенно способствовать моделированию множества физических свойств.
Moab предоставляет ясное разделение на планировщик и менеджер ресурсов. Данная схема выделяет уровень внешнего интерфейса для доступа пользователя и системы. Планировщик сосредотачивается на расписании, в то время как мониторинг и управление ресурсами, поддержка очередей и запуск заданий обрабатываются одним или более менеджерами пакетных ресурсов- по умолчанию Torque - и/ или другими менеджерами ресурсов. Отделением планировщика от менеджера ресурсов, реализуется выигрыш в масштабируемости и производительности при уменьшении сложности в компонентах.
менеджеры ресурсов могут быть различных типов: пакетные (Torque), управления питанием (Green), интерфейсом с менеджерами лицензий, контроллерами хранения и тому подобным.
Некоторые "группы ресурсов" организованы как отдельные кластеры. Множество менеджеров ресурсов объединяют ресурсы из этих соответствующих кластеров и делают их доступными для сборки в единый образ системы осуществляемый Moab. Moab будет видеть эти кластеры как отдельные разделы, однако всё ещё предоставлять единый образ для своего пользователя.
Данная схема отображает сеанс Nitro. Nitro является новым решением Adaptive Computing, которое не просто может работать на всех архитектурах, но также делать это во множестве одновременных сеансов. Подробнее о Nitro в разделе "Ускорение вычислений с высокой пропускной способностью =>Nitro".
Портал Viewpoint обслуживает пользователей и администраторов. Viewpoint увеличивает производительность конечных пользователей более простым и лёгким представлением задач/ заданий на основе портала. Viewpoint позволяет администраторам управлять запросами пользователей с меньшими временными затратами благодаря основанной на шаблонах наилучшей практике. Администраторы приобретают быструю визуализацию трудностей в состоянии системы и рабочей нагрузки.
Портал Viewpoint основан на Django/HTML5. Это приводит к лёгкой, но мощной системе. Viewpoint легко поддерживается и изменяется, а также предоставляет гибкие администрирование и поддержку пользователей для сложной высокопроизводительной системы.
InsightDB собирает данные каждого цикла расписания Moab. Поскольку очереди портала обслуживаются базой данных, производительность Moab не оказывет существенного влияния. Для непосредственного взаимодействия применяется MWS (Moab Web Services).
Домашняя страница пользователя отображает все задания пользователя плюс информацию о кластере, например, графическое изображение используемости ЦПУ и оперативной памяти, быстрый просмотр по узлам и из загруженность, плюс обзор общих сведений о рабочей нагрузке.
Представление задания основано на концепции шаблонов приложения, см. шаблоны "Free form" и "Ansys" (ниже, на Рис. 5). Представление задания упрощается при помощи подготовленных под определённые приложения шаблонов. Шаблоны приложения представляют конкретному пользователю какие значения по умолчанию могут быть изменены, какую информацию необходимо ввести для успешного запуска задания. Основанный на ролях доступ (RBAC, Role Based Access) гарантирует доступ пользователей только шаблонам приложения опубликованным для него. Введение концепции шаблонов делает возможным размещение заданий пользователей без необходимости для них быть специалистами в HPC.
Шаблоны приложения автоматически снабжаются номерами версии, могут быть экспортированы и импортированы, а также обмениыаться между площадками. Встренный Построитель сценариев предоставляет вставку drag & drop переменных в сценарии заданий.
Сценарии (также как и шаблоны приложения) могут импортироваться, экспортироваться и подвергаться обмену между администраторами и пользователями. Перечисляемые переменные содержат те же определения, которые задаются в шаблоне, предоставляя значения по умолчанию и элементы пользователя.
Ниже приводится (Рис. 7) страница детализации задания, содержащая статистики использования ЦПУ на протяжении времени жизни задания. В разделе Управления данными осуществляется практическая отработка связей с путями исполнения, а также стандартных вывода и сообщений об ошибках.
Их применение открывает встроенный менеджер файлов (отображён ниже), делающий возможным выбор, загрузку/ выгрузку в/из локальную/ удалённую систему, а также предварительный просмотр содержимого файла в стиле "tail" либо "head".
Безопасность: администратор портала может определять какие файловые системы, каталоги или ссылки доступны в данном менеджере файлов для соответствующего пользователя.
Viewpoint также обслуживает администраторов. Веб- портал предоставляет сжатый и подробный обзор мониторинга для поддерживаемой системы, развитие данного кластера и рабочей нагрузки в нём. Вот снимок экрана:
Одно из уникальных свойств Viewpoint, улучшающих работу администратора, это "Временная линия ресурсов задания", графически отображающая отчёт об исполнении задания (предоставлены два графических примера). Временная линия ресурсов задания является мощным инструментом визуализации для понимания того, какие ресурсы используются, что из них работает и как долго располагается на этом ресурсе рабочая нагрузка. Она также отображает резервирования в помощь отображению планов. Задания представляются в блоках различных размеров и форм для отображения: длительности заданий, числа запрошенных ядер, размера (чем темнее блок, тем больше задание).
Портал Viewpoint вносит в облегчение работы вклад, предоставляя веб- портал основанный на мониторинге параметрах для размещения тестовых заданий. Операции по мониторингу HPC систем могут обрабатываться различными центрами операций общего назначения, например NOC (Network Operations Center), которые могут быть уже установленными. Операторам с глубокими знаниями ИТ опытом в построении сетевых сред управлении серверами, имеющим практику выполнения отдельно подготовленных процедур исполнения, предоставляется возможность лёгкого мониторинга и тестирования систем HPC и доставки наилучших служб без необходимости иметь доступными экспертов в HPC в режиме 24x7.
Viewpoint Remote Visualization является интеллектуальным решением 3D/2D удалённого доступа и управления рабочей нагрузкой.
-
улучшает производительность для приложений 3D/2D удалённого доступа
-
уменьшает стоимость позволяя эффективно совместно использовать GPU и уменьшая требования к высококлассным настольным приложениям
Пользователи запрашивают сеанс удалённого доступа предоставляя задание удалённому порталу с применением обычного браузера. Moab отвечает требованиям ресурса и запускает сервер удалённого доступа на вычислительном узле, а затем соединяет сервер визуализации с порталом. Браузер пользователя отображает визуализацию. Портал визуализации применяет HTML5, не требуя подключаемых модулей или устанавливаемых браузером расширений.
Принцип стратегии диспетчеризации Moab одновременно ясен и прямолинеен: всё резервируется. В Moab план диспетчеризации строится автоматически размещая резервирования для каждого задания - в добавление к тем резервированиям, которые были размещены в явном виде - см. схему.
Например, поддержка резервирования в будущем не требует блокирования узлов ПЕРЕД тем как это резервирование станет активным. Планировщик разместит рабочую нагрузку здесь в соответствии с политикой заполнения (Backfill). В рамках такого контекста Moab имеет чёткий план оптимального размещения заданий, который может быть сделан даже более эффективным при помощи дополнительных функций, например, этапов данных (Data Staging).
График временной линии ресурсов задания Viewpoint ("Resource Job Timeline", изображённый ниже) отображает идеальную схему приведённую выше, свидетельствующую развитые возможности планирования Moab.
Как мы уже описывали, Moab является диспетчером с планированием резервирований. Moab создаёт план расписания на будущее. Moab производит повторное подтверждение плана исполнения на каждом цикле планирования и подстраивается под изменения и реальное время исполнения задания.
В качестве побочного результата Moab управляет фрагментацией кластера. Выделенные Moab ресурсы систематически перераспределяются таким образом, чтобы свободными оставалось максимальное число узлов. Обычные настройки для прочих планировщиков, например LSF, не управляют фрагментацией; они распределяют нагрузку по всей топологии. Фрагментация блокирует размещение новой рабочей нагрузки, например, целого узла. Приводимая ниже схема отображает подобную ситуацию для LSF: хотя доступно достаточное число процессов, к ним не может быть осуществлён доступ как к целому зулу.
Вне пределов текущей топологии использования управляемые Moab кластеры виртуально не имеют фрагментации: рабочая нагрузка никогда не должна блокироваться существующим применением. Maob помещает новые запросы на ресурсы на последующее время (автоматическое резервирование). При подобном подходе планирования диспетчеризации существует возможность найти достаточные ресурсы почти для любых условий.
Благодаря своему уникальному построению планировщика, взаимодействующего с произвольными менеджерами ресурсов, Moab может легко интегрироваться с различными инструментами развёртывания для ОС, стеков ПО или ВМ. Примерами являются xCat, OpenStack, Cobbler, HP-CMU, Bright Cluster Manager и многие другие. В качестве примера в документации приводится подробное описание интеграции с xCat.
xCat тесно интерируется с Moab при помощи концепции подключаемых модулей менеджера ресурсов, уникальной для Moab: xCat действует как другой менеджер ресурсов.
Динамичное клонирование узла Moab определяет когда ОС узла (, уровень исправления, стек ПО приложения, настройка, ...) должна быть изменена для лучшего соответствия текущим потребностям рабочей нагрузки.
Если не существует достаточного числа узлов с необходимыми ОС доступными для соответствия текущим запросам задания, Moab может динамически изменить ОС на доступных узлах с тем, чтобы они могли обслужить задания в данной очереди, поэтому они не должны ожидать.
Политика учитывает потребности использования ресурсов, соглашений SLA, а также рабочую нагрузку при определении того нужно ли изменять ОС узла. Она автоматически инициирует клонирование нудного Linux и стека ПО только для необходимого числа узлов, требующихся для заданий с текущим приоритетом. Это имеет ряд преимуществ. Это оптимизирует применение существующих доступных ресурсов, которые могли бы оказаться простаивающими, поскольку они имеют неверную ОС и/или стек ПО на данный момент. Это позволяет одним и тем же ресурсам кластера обслуживать более разнообразные нагрузки более эффективно. А в итоге это ускоряет пропускную способность заданий и имеет результатом то, что они в противном случае должны были бы ожидать в линейной очереди ресурсов с нужными ОС и стеком прикладного ПО.
Дополнительно, это также работает с OpenStack и Docker.
Схема ниже иллюстрирует динамичные опции управления HPC и инфраструктурой виртуальных компьютеров.
HPC ресурсы в виде непосредственно разворачиваемых вычислительных узлов могут переключать роли либо
гипервизоров, либо узлов Docker. Затем соответствующим образом разворачиваются ВМ или контейнеры.
Отметим, что Professional Service может ускорять реализацию.
Многие площадки HPC ищут возможности динамичного управления разделами между частным облаком OpenStack и инфраструктурой HPC. Moab Elastic Computing предоставляет средство для решения подобной политики.
Регулируемые вычисления являются способностью добавлять или удалять ресурсы в среде для соответствия изменяющимся обстоятельствам.
Moab применяет осведомлённость для предоставления автоматизации с применением инструментов, подобных OpenStack для того чтобы делать доступными регулируемые вычисления.
Жизненный цикл регулируемых вычислений состоит из размещения пользователем рабочей нагрузки, последующего поиска Moab текущего уровня ресурсов не отвечающих заданному SLA, и затем обращения к инструментам развёртывания, которые имеют доступ к общему пулу ресурсов (такому как Облако). Начиная с этого момента выделяются необходимые ресурсы и затем предоставляются соответствующему нуждающемуся в них окружению. После этого на добавленных ресурсах выполняется данная рабочая нагрузка и, в качестве завершающего этапа в данном процессе, запрошенные ресурсы возвращаются в общий пул (с отменой выделения и удалением из менеджера рабочей нагрузки).
-
Динамично управляет расширением ресурсов для соответствия SLA
-
Размер незавершённой работы (backlog)
-
-
Отказ от ресурсов по завершению здания или когда узлы становятся свободными
-
NodeIdlePurgeTime
-
-
Применяет OpenStack и другие платформы развёртывания
(Xcat, HP CMU, Bright Cluster Manager и другие)
-
Поддерживает виртуальные машины
(физическое развёртывание может быть добавлено через Professional Services)
Основным вариантом применения регулируемых вычислений является добавление и удаление совместно используемых ресурсов в существующий кластер.
Администратор определит пороговое значение времени выполнения незавершённых работ, которое определяет насколько продолжительным может быть приемлемое для рабочей нагрузки нахождение в отложенных (backlog) заданиях перед тем как должна произойти их эскалация. Ресурсы запрашиваются при помощи геометрии запроса (числа узлов и продолжительности запроса). Геометрия ресурса может быть с предварительно настроенным размером или может динамично вычисляться с использованием размера самого приоритетного задания в очереди.
Рисунок 18
Регулируемые вычисления - вариант применения добавления/ удаления локальных совместно используемых ресурсов
При запросе ресурса он может иметь предварительно настроенную продолжительность время жизни (TTL, time to live), после чего он может быть освобождён, или же он может освобождаться на основании политики времени освобождении простаивающего узла (Node Idle Purge Time). Политика времени освобождения простаивающего узла является продолжительностью, которая разрешена регулируемому ресурсу оставаться не используемой до того, как она будет удалена из данного менеджера рабочей нагрузки.
Регулируемые вычисления Moab (Elastic Computing) могут применяться для реализации сотрудничества с гарантируемой HPC конфиденциальность данных. HPC4HEALTH, эталонно устанавливаемый для регулируемых вычислений Moab (http://www.hpc4health.ca/) был сертифицирован в 2015г регулирующими органами для безопасной обработки данных клиента.
Такая установка с множеством владельцев состоит из кластера центрального пула (координирующего Moab), содержащего все ресурсы и ряда владельцев (tenant) кластера, причём каждый имеет свои собственные экземпляры Moab (в случае HPC4HEALTH 8).
Каждая среда владельца полностью администрируемой самостоятельно системой, которая может иметь свои собственные полностью независимые наборы правил и политик. Когда должны быть добавлены дополнительные ресурсы к данному владельцу (tenant) переключаются пороги на основе SLA. Каждый владелец может устанавливать свои собственные пороговые значения SLA, или все пороговые значения могут быть теми же самыми. Координирующий Moab гарантирует, что существует баланс между различными владельцами и что эти запросы не "накладываются" друг на друга. По существу, координирующий Moab рассматривает владельца как некую учётную запись (Account) и может применять все политики вокруг этой учётной записи для регулирования и ведения учёта использования.
Например, пределы использования, назначение приоритетов, выделение ресурсов/ ведение бюджета и прочие общие политики учётной записи могут применяться для управления содержимым ресурса и соответствующим учётом использования всего владельца. Однако, политики нижнего уровня (пользователь, группа и т.п.) не применяются координирующим Moab, а осуществляются экземплярами Moab владельцев внутри каждых из выделенных им ресурсов. Аналогично, учёт в координирующем Moab осуществляются только на основе учётной записи/ владельца (Account/Tenant), а учётные записи на основе пользователя, группы и т.п. реализуются экземпляром менеджера учётных записей Moab в рамках владельца.
![[Замечание]](/common/images/admon/note.png) | Замечание |
|---|---|
|
Регулируемые вычисления с множеством владельцев являются решением с разрешённым PS, так как оно состоит из наборов множества экземпляров Moab в иерархическом порядке, адаптируя сценарии и обеспечивая надлежащее поведение управления развёртывания. |
Контейнеры Docker применяются в HPC чрезвычайно широко. Поддержка Moab контейнеров Docker доступна начиная с Moab 9.0, делая доступной автоматизацию для задания развёртывания контейнеров последовательных работ. Функциональность Moab 9.0.1:
-
Создание, прекращение, контрольная точка и повторная постановка в очередь (Create, Cancel, Checkpoint и Requeue) контейнеров со связанными с ними последовательными заданиями
-
Запуск вручную или на основе шаблона задания
-
Интерактивная и автономная поддержка задания
-
Монтирование внешних томов на по-образной основе
Преимущества для пользователей HPC Moab:
-
Гетерогенная среда для задания/ приложения: применяются определённые ОС и библиотеки которые достигают наивысшей производительности и соответствуют сертификации требованиям окружения на базе применения для каждого задания/ приложения.
-
Создание контрольных точек: Делает возможным базовое создание контрольных точек с сохраняемым файлом состояния контейнера. Подобные задания могут запускаться на различных узлах.
-
Мобильность: Заключённые в контейнеры задания более легко перемещать в другие окружения (гриды, облака и т.п.)
-
Безопасность: Улучшает безопасность и изоляцию ресурсов.
-
Лёгкая настройка: Добавляется к узлам поддержка Docker и настройка вычислительного узла для применения сценария настройки Docker.
Жизненный цикл задания Docker: схема разъясняет различия обычного исполнения от выполнением с контрольными точками. Оба варианта применения поддерживаются в Moab 9.0.1 и далее.
В интеграции контейнеров Docker Moab 9.0.2 будут поддерживаться параллельные задания: например, автоматическое развёртывание такого числа контейнеров, которое запрашивается узлами для рабочей нагрузки HPC.
Moab поддерживает комбинации вычислительных ресурсов различных (под-)систем в отном задании или в цепочке зависимости множества заданий (рабочем потоке, multi-job-dependency-chain).
Adaptive Computing предлагает уникальное "Дуальное планирование домена" (Dual Domain Scheduling), которое делает возможным для пользователя передавать одно отдельное задание объединяющее узлы внутри вычислительного кластера, наряду с внешними узлами предварительной/ окончательной обработки.
Для объединённого применения вычислительных узлов с предварительной-, завершающей- или одновременной обработкой на узлах за пределами основного кластера, в основном существуют два не исключающих друг друга подхода:
При передаче задания запрашиваются приемлемые ресурсы для многодоменного (также называемого "гетерогенным") задания.
-
Пример:
qsub job_script.sh -l nodes=X:compute+Y:externalгде "external" относится к узлам вне вычислительного кластера, см. рисунок "Планирование дуального домена Moab"
-
Пример использования в аэрокосмической отрасли: обработка CFD выполняется в вычислительном кластере, а структурная целостность лопастей пропеллера выполняется на внешнем узле с большой памятью. Оба моделирования взаимодействуют во время исполнения.
-
Поддерживается множество различных внешних типов узла.
Альтернативным подходом могло бы быть определение рабочего потока или "цепочки заданий".
Определяем рабочий поток или "цепочку заданий" (подробнее см. Естественный рабочий поток Moab). Пример определения 3 этапов (предварительной- , вычислительной- и завершающей- обработки) зависимости рабочего потока:
Submit 3 jobs with dependencies:
jobid_pre=`qsub preprocessing_script`
jobid=`qsub actual_job_script -W depend=afterok:${jobid_pre}`
qsub post_processing_script -W depend=afterok:$jobid
Этот метод полезен для комбинирования произвольных требований, а также для определения последовательного порядка этаппов обработки. Необязательные дополнительные директивы планирования гарантируют топологию и удовлетворение ограничению по расстоянию.
Расширенное разбиение данных на стадии Moab обрабатывает обмен файлами ввода и вывода независимо от приложений вычислительных узлов. Разбиение данных на этапы применяет "системные" задания Moab, которые создаются и обрабатываются совершенно прозрачно для пользователя.
Как показывается в типичном варианте моделирования резервуара, входные файлы являются небольшими по размеру, в то время как результаты вывода имеют максимальный размер 30ГБ. Если мы предполагаем применять в качестве рабочего пространства на вычислительных узлах локальные диски (HDD или SDD), расширенное разбиение данных на стадии Moab ускоряет завершающую обработку и обычно ускоряет производительность интелектуально применяя локальное рабочее пространство.
Стадии данных ввода и вывода системы заданий планируются Moab раздельно. Зависимости между заданиями системы и заданиями пользователя гарантируют что:
-
Разбиение на этапность данных не блокирует вычислительные узлы.
-
Вычисления - задание пользователя - фактическое время исполнения (wall time) управляются независимо от разбиения на стадии фактического времени исполнения.
Чтобы гарантировать гибкость и масштабируемость необходимые для перспективных площадок HPC, Расширенное разбиение данных на стадии Moab предоставляет:
-
Выбор утилит обмена данными
-
Linux scp
-
Linux rsync
-
коммерческие продукта обмена данными (например, Aspera)
-
-
Параметры разбиения на стадии данных:
-
По умолчанию мастер Moab работает как хост разбиения данных на стадии.
-
По желанию можно применять множество серверов разбиения данных на стадии.
-
Разбиение данных на стадии 2-мя и 3-мя способами
-
Разбиение данных на стадии Moab осуществляет обмен входными и выходными данными в пределах отдельного кластера и между кластерами, а также за пределами отдельной площадки.
Для ускорения файлового ввода/ вывода вычислительных заданий и создания контрольных точек были введены групповые буфера как промежуточный уровень ускорения между параллельной файловой системой и вычислительным кластером.
Состоящий из множества распределённых серверов загруженных SSD, групповой буфер логически представляется как отдельная одноуровневая файловая система.
Для управления входящими и исходящими данными применяется разбиение данных на стадии Moab.
Вместо обычных методов файлового обмена наподобие scp
или rsync используются специальные команды групповой буферизации
(Burst Buffer).
Контроллер групповой буферизации управляет лежащей в основе параллельной файловой системой, включая блокировку файлов.
Вычислительные узлы будут выделяться только после того, как выполнится этап групповой буферизации исходных данных (data-stage-in). Вычислительные узлы будут изыматься после запуска этапа групповой буферизации выгрузки данных (data-stage-out).
Соображения производительности: Необходимое для обмена данными группового буфера к/ из параллельной файловой системе время сильно зависит от производительности PFS (parallel file system) и реальной загруженности. Применяя совместно контроллер группового буфера и планировщик Moab, осуществляется управление обменом данными в-кэш/ из-PFS и избегается состязательность.
Предпосылки технологии: Moab планирует и отслеживает выделение пространства группового буфера (Burst Buffer) на основании уровня для каждого задания по мере построения и итеративного повтора своего плана диспетчеризации. План диспетчеризации Moab состоит из резервирований - всё является резервированиями. При этом каждое задание (-резервирование) может иметь множество ресурсов и назначенных для него свойств, например определённое количество МБ группового буфера.
Не все задания могут запрашивать пространство группового буфера - либо для слишком низких требований к данным, либо из- за доступа к чрезвычайно большим файлам может оказаться целесообразным прямой доступ к PFS.
Общий объём группового буфера может меняться в зависимости от распределений обходов пакетной системы как самой системой, так и пользователем. Для каждого временного интервала Moab будет переключать обновление метрик, гарантируя отсутствие переполнения или простоев пространства группового буфера.
Описанная методика также покрывает вариант с применением контрольных точек. Контрольные точки и повторные запуски управляются Moab, а также выполняются и отслеживаются соответствующие резервирования пространства группового буфера в рамках плана диспетчеризации Moab.
Менеджер учётных записей Moab (MAM, Moab Accounting Manager) следует классичекому ведению учётных записей для применения ресурсов; MAM делает возможным организациям выполнять отображение/ выставление счетов за выделение размещений. Совместно с Moab MAM планирует управление динамичным выделением ресурсов - перед запуском рабочей нагрузки. Это сравнимо с предварительной оплатой использования мобильного телефона. Для групп и/ или пользователей и т.п. может быть выделен бюджет. Когда пользователь выставляет задание, предсказываемое время исполнения совместно с пониманием запрашиваемых ресурсов (и их соответствующих стоимостей) вычисляются и выставляются против связанного с пользователем бюджета. Когда данное задание завершается, реальное использование ресурсов сравнивается с предсказанным заказом и применяются корректировки: в большинстве случаев некоторый бюджет пользователя может быть освобождён. При подобном подходе может исполняться управляемое бюджетом использование ресурсов HPC.Рабочая нагрузка, которая превосходит оставшийся бюджет пользователя просто не будет запускаться или могут быть определены политики исключений совместно с уведомлениями на основе групп, проектов или подразделений. Менеджер учётных записей может быть настроен в 4 различных режимах:
-
Строгое выделение (Strict allocation) - Применяйте этот метод если вы хотите строго придерживаться пределов выделения. При этом режиме задания могут не допускаться к исполнению если конечные пользователи не имеют достаточных фондов. Это значение установлено по умолчанию.
-
Быстрое выделение (Fast allocation) - Применяйте этот режим если вы хотите дебитовать выделения, однако нуждаетесь в более высоких пропускных способностях устранения залога и квотирования метода строго выделения.
-
Смысловое наполнение (Notional-charging) - Применяйте этот метод если вы желаете вычислять и записывать затраты на использование рабочей нагрузки, однако не придерживаться отслеживания балансов фондов или пределов выделения.
-
Отслеживание использования (Usage-tracking) - Используйте данный подход если вам нужно записывать подробности использования рабочей нагрузки, однако нет необходимости вычислять стоимость или отслеживать балансы фондов или пределы выделения.
Пример отчёта настроенного для пользователя: одна строка конфигурации MAM упаковывается как nchargeuser
|
| Замечание |
|---|---|
|
Бюджеты MAM могут быть ограничены по времени жизни, определяться с ослаблением, добавляться частично к новым бюджетам, автоматически пополняться и к ним может применяться многое другое. |
Moab явно является лидером в диспетчеризации HPC. Moab планирует рабочие нагрузки на основе требований задания и свойств, а затем создаёт, сопровождает и итеративно диспетчеризует план размещая резервирования на будущее. Кроме того, что эта методология близка к исключительному заполнению, она систематически предотвращает соответствующее управление фрагментацией вашего кластера.
Moab выделяется из альтернатив благодаря встроенной архитектуре планирования, имеющей результатом возможность применять важные политики, такие как Fairshare (взнос честности) и Backfill (заполнение) в одной и той же системе одновременно. Интегрированный планировщик Moab доставляет надёжность и предсказуемые результаты в комбинации с политиками Fairshare и Backfill.
Другие планировщики организуются как последовательности встраиваемых модулей, причём каждый уменьшает число отыскиваемых ресурсов (= заданий). Когда комбинируются Backfill и Fairshare, одна политика пытается удалять задания другой политики, что требуется ей для эффективной работы.
В Moab комбинация Fairshare и Backfill работает очень хорошо. SLA для больших заданий доставляются без ущемления небольших или последовательных рабочих нагрузок.
Благодаря открытой концепции менеджера ресурсов, Moab может легко интегрироваться с прочими системами, управляющими или использующими специальные ресурсы и предоставляеет ранее не виданную функциональность. Moab может даже использовать Slurm или PBS в качестве менеджеров ресурсов.
Другое преимущество Moab над альтернативами состоит в системе переключателей (trigger) Moab. Переключатели Moab делают возможным определение инцидентов и реальное принятие действий при них. Развитая концепция резервирования основанного на планировании приходит совместно с параметром переключателя Moab при запуске каждого резервирования. В своей основе MOAB предоставляет основу для творчества в максимизации ресурсов HPC.
С точки зрения производительности Moab также лидирует на рынке. Призводительность Moab масштабируется с размером системы, максимально измеренная производительности постановки в 500 заданий/с может быть продолжительной. Приводимая ниже диаграмма измерений показывает производительность подачи в малой тестовой системе с более чем 150000 заданий в очереди. Отметим, Moab не замедляется - скорость устойчвая.
Наконец, даже когда запрашиваются ещё большие постановки И производительность исполнения, Moab опять лидирует с Nitro. Вновь производительность масштабируется вместе с размером системы - измеренная производительность на кластере с 20 узлами имеет результатом устойчивую скорость исполнения 13500 заданий/c при одном сеансе Nitro на 10 миллионов заданий. Более того, в этом примере скорость постановки превосходит 100 миллионов заданий в секунду.
С точки зрения Масштабируемости Moab также поддерживает лидерство над альтернативами. В то время как прочие системы нуждаются в применении многоуровненвой иерархии планирования с внутренними ограничениями и пределами прозрачности, Moab просто масштабируется.
Высоко ранжированная в Top500 система Bluewaters Titan с приблизительно 30000 узлов напрямую управляется Moab на протяжении многих лет.
Одним из основных преимуществ Moab является обработка больших заданий MPI. например, в HLRS, Stuttgart, Germany, Moab одновременно управляет 14400-процессорными параллельными заданиями в рамках гетерогенной смешанной рабочей нагрузки при одновременном сохранении динамичного разделения системы для промышленных и научных пользователей.
Именно поэтому, одна из наиболее известных площадок технологического лидера HPC, NREL, объединилась с эталонной площадкой Adaptive Computing & HP=Apollo, выбрав Moab &TORQUE вместо чего бы то ни было ещё. Приведём перечень потребителей в нефтегазовой, финансовой, химической отраслях и науке о жизни:
Moab является очевидным лидером в планировании HPC.