Раздел 2: Расширенная функциональность планировщика заданий HPC

Архитектура Grid Moab или конфигурация с множеством кластеров предоставляет объединённое управление по всем вычислительным кластерам, как в центре обработке данных, так и за его пределами.

Adaptive Computing Moab является проверенным лидером в гибкости, предоставляя нашим потребителям реализацию систем, которые предлагают расширенные службы для всей организации. Агрегация ресурсов из множества кластеров является подобным примером. Методы Grid- архитнектуры и кластера со множеством кластеров могут применяться в качестве альтернативы или в комбинации друг с другом.

Термин "множественный кластер" (multi- cluster) в соединениии с Moab чётко отличается от термина "Grid". Множество кластеров может быть собрано под обним экземпляром планировщика Moab, как мы уже показывали ранее. Множество экземпляров планировщиков Moab может быть применено для вормирования архитектуры Grid. Схема ниже отображает иерархическую структуру Grid. Подобные этой структуры выбираются для реализации роли пользовательского доступа соответствующего кластера представления и множественного испольнения или компьютерных кластеров.

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

Альтернативой для иерархической организации кластера является одноранговая (peer-to-peer) конфигурация. В приводимом ниже примере ресурсы обоих кластеров доступны пользователям, и они могут настраиваться таким образом, что каждое задание выполняется с оптимальными ресурсами. Более того, MOAB предоставляет такие функциональные возможности, что пользователи могут определять особенные потребности в ресурсе для своих вычислительных заданий, которые MOAB будет затем интеллектуально помещать в наиболее подходящий кластер.

В настоящее время самой крупной инсталляцией данного типа является HLRN в Германии www.hlrn.de (на англ. яз: https://www.hlrn.de/home/view/Organisation/AboutHlrn?section=en. При этом администрирвоание остаётся автономным - как в HLRN - где каждая площадка вносит ресурсы по своему желанию (оговорено контрактом), но сохраняет свою соответствующую автономию сайта, авторизацию и права администрирования.

Осведомлённость рабочей нагрузки об управлении питанием предоставляет возможность разделять и увеличивать число активных вычислительных узлов в соответствии с требованиями рабочей нагрузки. Более того, частота ЦПУ вычислительных узлов может настраиваться таким образом, чтобы выполнять рабочие нагрузки максимально быстро или в тех пределах, насколько того позволяет охлаждение.

Выходя за пределы классического варианта применения c "экономией энергии", Moab позволяет управление пределами мощности - так называемыми "Заглушками мощности" (Power Caps) - наряду с управлением увеличения энергопотребления или всплесками для гарантированности стабильности на стороне энергоснабжения.

Moab Green: Ключевым элементом управления потреблением Adaptive Computing является планировщик, механизм принятия решений Moab. Moab консолидирует рабочую нагрузку таким образом, что могут применяться политики защиты окружающей среды на освобождённых узлах. Одним параметром можно выключить неиспользуемые узлы. Это также оказывает самое непосредственное воздействие на значения PUE.

Moab Green вводит концепцию "Green Pool", которая создаёт баланс между требованиями пользователя для быстрого реагирования и владельца бюджета в отношении уменьшения потребления мощности.

Размер Green Pool может быть настраиваемым, например, быть бОльшим в бизнес- часы и меньше на протяжении более бедных часов пакетной нагрузки. Схема выше показывает 4 узла Green Pool и 3 выключенных узла.

Интерфейс действия Green может применяться администратором и соответсвенно автоматизированными сценариями.

Moab позволяет настраивать частоты WGE для вычислительных узлов применяя регулятор мощности Linux.

Эталонное тестирование NASA отображает важность и воздействие таких измерений: различные производительности приложений ощущают воздействие со стороны различных значений частот ЦПУ. На схемах ниже приводится банлансировочый оптимум.

В контектсе площадок HPC сегодняшнего дня, сталкивающихся с потребностями в более быстрых запуске заданий и временах исполнения, Adaptive Computing недавно предоставил технологический прорыв в вычислениях с высокой пропускной спсобностью (HTC, High Throughput Computing). при содействии Nitro в пределах одной и той же установки могут исключительно сосуществовать HTC и HPC.

Nitro впечатляюще увеличивает пропускную способность для рабочих нагрузок HTC. Приводимая ниже схема иллюстрирует "вызов на исполнение по требованию мигрирующие суб-кластеры".

При помощи Nitro Moab легко достигает скоростей постановки в миллионы заданий в секунду и скорстей исполнения в тысячи заданий в секунду на сеанс Nitro.

Тестирование Nitro демонстрирует производительность около 13500 исполненных заданий в секунду для примерно 10 миллионов заданий в одном сеансе Nitro (кластер из 20 узлов, доступна подробная информация).

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

Сеансы Nitro запускаются по запросу для адекватной рабочей нагрузки HTC и удаляются из кластера когда нагрузка завершается. Nitro удобен для последовательных и параллельных с отдельным узлом нагрузок. В отличие от Job Array, сеансы Nitro подобны любому обычному параллельному заданию. Осознавая требования ресурсов для набора узлов и сеанса Nitro, Moab планирует подходящие узлы.

Менеджер ресурсов (Torque, portal или любой другой) запустит новое задание на самом первом узле из данного набора. Н нём координатор Nitro устанавливает и берёт на себя взаимодействие с прочими работающими узлами в данном сеансе при помощи очереди сообщений.

Реальная рабочая нагрузка обрабатывается как список задач - в данном примере "mybatch.txt" может содержать от 1000 до миллионов задач. Было успешно оттестировано и продемонстрировано 10 миллионов задач в списке. Так как одновременно может быть использовано множество сеансов Nitro, максимальную пропускную способность ограничивает только размер кластера.

Nitro предоставляет API для прямого взаимодействия и добавления дополнительных рабочих нагрузок в исполняющийся сеанс ("режим удержания", linger mode), что важно, например, для динамичных рабочих нагрузок. Adaptive Computing Nitro может применяться на любом оборудовании и со всем промежуточным ПО.

Adaptive Computing заново переработал возможности NUMA с самого основания. Moab предоставляет:

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

msub -L tasks=1:lprocs=3:memory=5GiB:usecores:place=core=4 # 1 System-level simulation (red)
     -L tasks=4:lprocs=1:memory=10GiB:usecores:place=core=2 # 4 Board A simulations (orange)
     -L tasks=2:lprocs=2:memory=20GiB:usecores:place=core=3 # 2 Board B simulations (yellow)
     -L tasks=1:lprocs=4:memory=50GiB:usecores:place=core=5 # 1 Board C simulation (green)
     -L tasks=3:lprocs=8:memory=30GiB:usecores:place=socket # 3 Board D simulations (blue)
     -l naccesspolicy=singlejob mySim.sh
Note: one msub command-line without the # comments
 	   

Приводимое ниже изображение иллюстрирует результирующее выделение планировщиком Moab осведомлённым о NUMA (Moab Numa Aware).

Моделирование подзадач настолько компактно, насколко это возможно для каждой компоненты, с выделением минимального числа узлов для каждой компоненты; причём с последующим выделением памяти с наилучшим приближением.

Естественный рабочий поток Moab (Moab Native Workflow) обслуживает все типы пользователей: от учёных, которые всего лишь хотят чтобы их рабочий поток исполнялся, до продвинутых пользователей и, наконец, экспертов, которые желают иметь полный контроль над своим потоком.

Все 4 варианта применения имеют свои особенные характеристики, однако могут применяться с выходом за рамки приведённых здесь описаний. Например: Подход "лёгкого в использовании" "Just Flow" может применяться в качестве асинхронного интерфейса между слабосвязанными системами.

Определения потока "Workflow Unlimited" могут переносится между доменами Moab.

Вариант применения 1: Just Flow

Цель применения модели "Just Flow" состоит в предоставлении пользователям, которые просто хотят получить "вычисления" простой в использовании службы, которая бы с пользой работала для них. Минимальные требования к специальным знаниям пользователя следующие:

Применение модели "Just Flow" отлично подходит для комфортного повторения предварительно подготовленных рабочих потоков. В качестве индивидуальных папок могут быть предоставлено множество альтернативных рабочих потоков, например: "WorkFlow#2", ...

Вариант применения 2: Advanced Workflow

Поток с дополнительными возможностями основывается на шаблонах задания Moab (Moab Job Templates). Рабочий поток определяется шаблонами задания в moab.cfg. Рабочие потоки применяются при помощи определения таких шаблонов при постановке задания.

Рабочий поток на основе шаблона использует модель, реализующую разделение отвественности для данного потока следующим образом - шаблоны задания Moab - на системном администраторе, а на пользователе выбор правильного шаблона рабочего потока в момент постановки. Это требует чтобы пользователь был в курсе определяющих различные рабочие потоки шаблонов.

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

Вариант применения 3: Workflow Unlimited

Чтобы соответствовать требованиям продвинутых ползователей, модель применения "Workflow Unlimited" основывается на определении рабочего потока в сценариях. Этот метод снабжает пользователя полным контролем над рабочим потоком, а также любыми его изменениями. Не требуется никакое вмешательство администратора - пользователь может "помочь сам себе".

"Workflow Unlimited" удобен для крупномасштабных сложных рабочих потоков. Поскольку такие рабочие потоки могут иметь высокую скорость изменений и обновлений, их владельцы (owner) получают подход "всё под моим управлением". Для сравнения: вариант применения "Advanced Workflow" употреблял размещение шаблонов задания Moab структуры рабочего потока в moab.cfg - под управлением системного администратора.

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

Хотя подход и основан на сценариях, для мониторинга потоков может применяться MCM GUI. В настоящее время MCM отображает 255 этапов рабочих потоков, что может быть достаточным для большинства вариатнов использования. Потои больших размеров отображаются отобранными частями. Примерный формат сценария (не обязательно) разделяется между "содержимым" и "структурой рабочего потока", см. схему.

Естетстенный рабочий поток Moab использует самый сильный диспетчер в мире HPC в качестве механизма рабочего потока. Преимущества включают высокую производительность и масштабируемость, а также бесшовную интеграцию в обычный механизм пакетной обработки. Далее он способствует применению уже подготовленных сложных потоков, таких как разбиение на этапы данных Moab (Moab Data Staging).

Масштабируемость естетстенного рабочего потока Moab недавно была протестирована в лабораторных условиях. Примениялись автоматически создаваемые рабочие нагрузки: от 10-тысяч потоков с длиной в 7 этапов каждый до одного потока с потоком в 100000 этапов, см. таблицу ниже.

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

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

Тесты простой масштабируемости естественных потоков Moab

Этапов потока	# потоков	Поставлено	Исполнено	Комментарий
7	10000	ОК	все выполнены	скорсть та же, что и при обычной работе
100	1000	ОК	все выполнены	скорсть та же, что и при обычной работе
1000	100	ОК	все выполнены	скорсть та же, что и при обычной работе
10000	10	ОК	все выполнены	скорсть та же, что и при обычной работе
20000	5	ОК	OK*	скорсть та же, что и при обычной работе
50000	2	ОК	OK*	скорсть та же, что и при обычной работе
100000	1	ОК	OK*	скорсть та же, что и при обычной работе

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

Moab поддерживает произвольную глубину (без аппаратных ограничений) иерархического планирования со взносом честности (Fair-Share) основанном на совместно используемом дереве. В этой модели могут произвольно организовываться пользователи, группы, классы и учётные записи, а их использование отслеживается и ограничивается. Moab расширяет общую концепцию соместно используемого дерева разрешая смешивать типы полномочий, принуждая к использованию в качестве целей стилей верхних и нижних ограничений, а также смешивая иерархию состояния планирования со взносом честности с прочими компонентами приоритета.

Иерархические деревья взноса честности настраиваются в XML. Например:

FSTREE[myTree]
<fstree>
  <tnode name="root" share="100">
    <tnode name="john" type="user" share="50" limits="MAXJOB=8 MAXPROC=24 MAXWC=01:00:00">
    </tnode>
    <tnode name="jane" type="user" share="50" limits="MAXJOB=5">
    </tnode>
  </tnode>
</fstree>
 	   

эта конфигурация создаёт в качестве примера дерево взноса честности в которм 2 пользователя совместно используют значение 100. Пользователи John и Jane совместно применяют это значение на равных правах, поскольку каждому дано по 50. Кроме того, определены необязательные пределы для обоих пользователей. Пределами могут быть: MAXIJOB, MAXJOB, MAXMEM, MAXNODE, MAXPROC, MAXSUBMITJOBS, MAXWC. Заметим: в сравнении с обсуждавшимся ранее заполнением (Backfill), мы понимаем, что цель использования заполняемости может ощущать препятствовие со стороны подобных пределов взноса честности.

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

Конфигурация дерева взноса честности может быть просмотрена при помощи mdiag -f. Информация о дереве будет отражена ниже всей информации о применённых настройках взноса честности в moab.cfg.

> mdiag -f
Share Tree Overview for partition 'ALL'
Name      Usage   Target      (FSFACTOR)
----      -----   ------      ------------
root     100.00   100.00 of   100.00 (node: 1171.81) (0.00)
- john    16.44    50.00 of   100.00 (user: 192.65) (302.04) MAXJOB=8 MAXPROC=24 MAXWC=3600
- jane    83.56    50.00 of   100.00 (user: 979.16) (-302.04) MAXJOB=5
 	   

Как основной принцип работы, заполнения (Backfill) планируют впереди самый ранний запуск (= местам зарезервированным для) самого большого задания. Далее, заполнение ищет для заданий приемлемое выполнение в процессе времени ожидания пока это запланированное задание может запуститься.

Заполнение имеет сторонний эффект запускать менее приоритетные задания раньше если они помещаются в заполняемое окно, имея результатом задержку запуска более приоритетных заданий. Параметр RESERVATIONDEPTH управляет насколько консервативна или либеральна политика заполнения, балансируя между использованием системы и приоритетностью.

Если планирование со взносом честности настроено классически чтобы иметь в качестве результата динамичную приоритезацию задания, её комбинирование с заполнением является бесшовным. Как уже описывалось, заполнение может выбирать для запуска задание (нарушая взнос честности!), потому что такое определённое задание может поместиться в окно заполнения.

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

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

Возможность комбинирования динамически вычисляемых приоритетов взноса честности с пределами или "заглушками" является уникальной для Moab и предоставляет высокую степень свободы в определении SLA. Приводимая выше схема описывает принципы планирования заполнения (Backfill):

Существует множество измерений, которые различают рабочие нагрузки:

Комбинирование политик Moab - BackFill, Fair Share и QoS - имеет результатом динамические приоритеты - что делает возможным сосуществование всех различных типов рабочих нагрузок в системе. Как уже описывалось, Moab будет выделять и резервировать ресурсы, например, для 160- потокового параллельного задания, а затем - при последующих итерациях - позаботится чтобы не было потеряно никакое время и пространство для вычислений, заполняя их короткими и "тонкими" заданиями.

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

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

В данном примере выше Moab пытается вначале подогнать задание к узлам на наборе блед- лезвий. Если это не работает, он перемещается поверх узлов на наборы четвёрок (набор из четырёх лезвий). Если четвёрки не доступны, он пытается применять узлы в наборах по шестнадцать (набор из четырёх четвёрок наборов узлов). Приводимое ниже определение является примером "от наименьшего к наибольшему" настраиваемому набору узлов.

NODESETPOLICY ONEOF
NODESETATTRIBUTE FEATURE
NODESETISOPTIONAL FALSE
NODESETLIST blade1a,blade1b,blade2a,blade2b,blade3a,blade3b,blade4a,blade4b,quad1a,quad1b,quad2a,quad2b,octet1,octet2,sixteen
 	   

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

Соглашения об уровне обслуживания (SLA, Service Level Agreements) могут настраиваться в Moab в качестве QoS, определений качества обслуживания (Quality of Service). Возможности QoS Moab позволяют площадке давать особое толкование различным классам заданий, пользователей, групп и тому подобному. Каждый объект QoS может рассматриваться как контейнер специальных полномочий от изъятия политики справедливого распределения до специализированного назначения приоритета заданию для доступа с определённой функциональностью.

Качества обслуживания (QoS):

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

Ниже отображается пример настройки QoS для HydroQoS и его взаимосвязь с Reservation и Accountlist:

# Define the QOS/SLA parameters
QOSCFG[ HydroQoS] REQRID= HydroRsv
QOSCFG[ HydroQoS] MAXPROC=12
QOSCFG[ HydroQoS] MAXJOB[USER]=1        jobs/user
QOSCFG[ HydroQoS] ALIST= HydroAcc       AccountList
# Define the members who belong to the account can access the QOS/SLA and their job restrictions
ACCOUNTCFG[ HydroAcc] MEMBERULIST=bob,sue,john,peter,gabriel,adam,tom,mary
ACCOUNTCFG[ HydroAcc] PRIORITY=1500
ACCOUNTCFG[ HydroAcc] MAX.WCLIMIT=24:00:00:00
ACCOUNTCFG[ HydroAcc] MAXJOB[USER]=16,18   in case of low utilization, second limit aplies
ACCOUNTCFG[ HydroAcc] QLIST= HydroQoS
ACCOUNTCFG[ HydroAcc] QDEF= HydroQoS
# Define a reservation to compliment the Qos/SLA and the access period
SRCFG[ HydroRsv] HOSTLIST=node001,node002,node003,node004
SRCFG[ HydroRsv] ACCOUNTLIST= HydroAcc
SRCFG[ HydroRsv] ACCESS=SHARED
SRCFG[ HydroRsv] PERIOD=INFINITY
SRCFG[ HydroRsv] QOSLIST= HydroQoS
 	   

Данное задание будет иметь QoS по умолчанию и может иметь доступ к некоторым дополнительным QoS. Когда применяется задание, его получатель может запросить определённое QoS или просто разрешить применение QoS по умолчанию.

Политики приоритета Moab гарантируют, что рабочие нагрузки с самым высоким приоритетом исполняются первыми, таким образом усиливаются и выполняются соглашения об уровне обслуживания (SLA) и организационные приоритеты.

Интеллектуальный механизм Moab одновременно рассматривает множество измерений и факторов при вычислениях и непрерывно подстраивает приоритеты заданий. Он рассматривает полномочия задания такие как пользователь, группа или учётная запись, запрашиваемые ресурсы задания такие, как число узлов, процессоров, объём памяти, фактическое время исполнения и т.п., желательные или выделенные для данного типа пользователя уровни служб (QoS): время в очереди, предельный срок, число перезапусков задания, параметры задания такие как приоритетность для определённого кода или приложения, или для определённого состояния задания, или настраиваемый под пользователя тип порционного ресурса, такого как GPGPU.

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

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

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

На основании концепции резервирования Moab могут гарантироваться для резервирования ресурсы для создания 4 отчётов в день. Предположим, что для отчёта выделяются 2 часа, такое резервирование будет предохранять ресурс для обработки с 2 часами вперёд до истечения её срока. На протяжении этих времён только пользователям обработки разрешается размещать задания в ресурсах, запасённых таким резервированием. А также для ещё более оптимального использования кластера во время обработки - предположим, что рабочая нагрузка обработки (пока) не полностью заполняет все зарезервированные ресурсы - задания с коротким временем исполнения, например 5 минут, могут быть разрешены в пределах данного резервирования.

Изображённый ниже план расписания Moab иллюстрирует резервирования 1-4 объединённых ресурсов для использования в обработке. Ситуация показанная в 6:00AM: задания были выполнены до начала резерва "Report1". Множество заданий было выполнено для обработки очёта.

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

Позже в это же день, или ранним вечером, ситуация может выглядеть примерно так: в 18:00 заканчивается зарезервированный Report3.

И наконец - для иллюстрации - полный план расписания на весь день.

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

1) Незапланированная срочная рабочая нагрузка

В Moab для задания может быть назначено множество QoS. Это может оказаться полезным при выходе за пределы запланированного расписания, когда требуется выполнение срочной рабочей нагрузки (например, в случае стихийного бедствия). Подготовленная предварительно администратором Super-Prio-QoS может быть сделана доступной для определённых пользователей, которые подключают это QoS к своим срочным рабочим нагрузкам. основываясь на такой новой политике, Moab будет выставлять этой нагрузке приоритет выше всех прочих. Использование любого (специфичной для задания) QoS загружается как приоритетное для этого пользователя задание, см. Менеджер учётных записей Moab - управление динамическим выделением.

2) Обработка критических ситуаций

В случае если потребовалась обработка критической ситуации в то время как ресурсы заняты стандартной рабочей нагрузкой, ресурсы должны быть сделаны доступными. Это можно выполнить путём создания контрольной точки или приоритетным вытеснением, при котором может быть выбран метод приоритетного вытеснения, временное прекращение (suspend) или окончание исполнения (kill). Для многих кодов доступны контрольные точки уровня приложения. Необходимо подготовить и протестировать их, однако затем необходимо сделать доступными их координацию и эффективное действие в случае критической ситуации. Поддерживаемые системными администраторами пользователи, соблюдающие создание контрольных точек, могут получить преимущества, например, в виде определений QoS, которые они могут применять для своих заданий.

В случае вытеснения рабочей нагрузки путём завершения данного задания, Moab может автоматически вернуть эту рабочую нагрузку с соотвествующей настройкой. Кроме того, пользователи, удовлетворяющие такому запросу могут получить преимущества, например QoS для подключения к своим заданиям.

Хотя вытеснение является предметом, часто "не нравящимся" пользователям, хорошая подготовка является лучшим путём назад к "нормальной" работе после критической ситуации.

Инновационная архитектура и возможности менеджера ресурсов Torque создаёт наилучшую возможную производительность для параллельных нагрузок большого масштаба. Ключевой инновацией здесь является так называемое основание счисления (radix) заданий.

Job Radix является очень эффективным механизмом взаимодействия и запуска заданий который охватывает десятки тысяч или даже сотни тысяч узлов, а не просто процессоров.

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

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

Job Radix устраняет утраченные задания, узкие места запуска задания и блокировку обмена, вызываемую наличием во всех узлах демонов MOM, взаимодействующих только с одним головным узлом MOM.

Интеграция MPI с планировщиком нагрузки часто осложнена при её достижении и сопровождении. С применением Moab и Torque она проста. Здесь мы перечисляем необходимые этапы:

Moab/ Torque управляют заданиями MPI тесно интегрируясь с уровнем OpenMPI: подробнее в документации по Torque для MPICH и OpenMPI http://docs.adaptivecomputing.com/8-1-0/enterprise/help.htm#topics/torque/7-messagePassing/MPISupport.htm.

В случае отказа задания MPI все процессы очищаются в соответствии с документацией Adaptive Computing: http://docs.adaptivecomputing.com/8-1-0/basic/help.htm#topics/torque/7-messagePassing/MPICH.htm.

Чтобы сделать доступной интеграцию Torque в MPI, MPI стрлоится с поддержкой Torque. Пример:

./configure --prefix=/home/software/rhel6/openmpi-1.6.3-mxm/intel-12.1 --<…> --with-tm=/usr/local/torque --with-openib --with-psm –-<…>
 	   

Результаты:

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

Жёсткий рабочий поток представляемый из пакета в "рабочая загрузка завершена" звучит разумно, однако часто требуется гибкость. Moab позволяет изменять задания до бескрайних расширений на всех этапах жизненного цикла конкретного задания:

Для реализации изменения задания служат методы:

Данная глава первоначально следует за жизненным циклом задания при помощи примеров CLI (команд пользователя или администратора) и изменениям настроек.

Представление

При нахождении в очереди

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

mjobctl  -c jobexp (cancel)
         -c -w attr=val      (cancel selective)
         -C jobexp                 (checkpoint)
         -e jobid                       (rerun)
         -F jobexp               (force cancel)
         -h [hold type] jobexp           (hold)
   (hold types: [User|System|Batch|Defer|All])
         -N [<SIGNO>] jobexp      (send signal)
         -p <PRIORITY> jobexp        (priority)
         -r jobexp                     (resume)
         -R jobexp                    (requeue)
         -s jobexp                    (suspend)
         -u jobexp                     (unhold)
         -x [-w flags=val] jobexp     (execute)
         -m attr{+=|=|-=}val jobexp    (modify)
<ATTR>={ account | arraylimit | awduration| class | cpuclock | deadline | depend | eeduration | env | features | feature | flags | gres | group | hold | hostlist | jobdisk | jobmem | jobname | jobswap | loglevel | messages| minstarttime | nodecount | notificationaddress | partition | priority | queue | qos | reqreservation | rmxstring | reqattr | reqawduration | sysprio | trig | trigvar | user | userprio | var | wclimit}
 	   

Команда qalter изменяет свойства конкретного задания или заданий, определённых job_identifier в командной строке. Будут изменены только те свойства, которые перечислены в качаестве параметров в данной команде.

qalter [-a date_time] [-A account_string] [-c interval] [-e path] [-h hold_list]
       [-j join] [-k keep] [-l resource_list] [-m mail_options] [-M user_list]
       [-n node exclusive] [-N name] [-o path] [-p priority] [-r c] [-S path]
       [-t array_range] [-u user_list] [-W additional_attributes] job_identifier
 	   

Команда qalter совершает изменение отправляя пакетный запрос Modify Job на сервер пакетной обработки, который владеет каждым заданием.

В обеих командах: некоторые параметры не могут быть изменены после запуска задания, например, список узлов (nodelist). Исключение: пластичные (Melleable) задания, которые выполнены с узлами и передают их назад до исполнения этого задания.

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

Команда	Описание
canceljob	Прекращает существующее задание.
checkjob	Отображает состояние задания, запрашиваемые ресурсы, окружение, ограничения, полномочия, историю, выделенные ресурсы и использование ресурсов.
mdiag -j	Отображает суммированную информацию задания и непредвиденное состояние задания.
releasehold -a	Удаляет удерживаемое (holds) или отсроченное (deferrals) задание.
runjob	Если возможно, немедленно запускает задание.
sethold	Устанавливает удержание задания.
setqos	Устанавливает/ изменяет QoS существующего задания.
setspri	Регулирует приоритет задания/системы работы.
mcredctl	Управляет различными сторонами объектов полномочий в пределах Moab.
mdiag	Предоставляет диагностические сообщения для ресурсов, рабочих потоков, расписаний.
mrsvctl	Создаёт, управляет и изменяет резервирования.

QoS определённое, например, как "run now", может быть добавлено определённому заданию, что вызывает его немедленное исполнение.

Переключатели Moab являются средством управления независимого управления планировщика. Переключатели могут быть связаны с большинством логических объектов Moab и внешними событиями.

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

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

Веб службы Moab (MWS, Moab Web Services) позволяют практически те же самые параметры изменения, что и CLI, но при этом основаны на API RestFul.

Пример: Запрос MWS к данным и состоянию Moab "Get Single Job"

GET http://localhost:8080/mws/rest/jobs/<name>?api-version=3
Supported methods: GET, POST, PUT, DELETE
 	   

Из командной строки:

$ curl -u user:password -X GET http://localhost:8080/mws/rest/jobs/Moab.15?api-version=3
Note: in this example <name> => Moab.15
 	   

Пример ответного действия JSON:

{
"arrayIndex": null,
"arrayMasterName": null,
"attributes": [],
"blocks": [ {
"category": "jobBlock",
"message": null,
"type": null
}],
"bypassCount": 0,
"cancelCount": 0,
"commandFile": "/tmp/test.sh",
"commandLineArgs": null,
"completionCode":
…

<3 pages or 187 lines output, see
page 167ff in
MWSEnterprise-8.1.2.pdf>
 	   

Администраторам кластера HPC требуется эффективный мониторинг для осуществления управления и обеспечения производительности. Moab реализует соответствующие методы как через GUI, так и спомощью средств CLI. Таблица предоставляет список команд для создания отчётов в кластере и по рабочим нагрузкам.

Команда	Описание
Checkjob	Просмотр подробной информации для любого задания. Добавьте -v (-v -v) для увеличения подробностей.
Checknode	Просмотр подробной информации для любого узла. Добавьте -v (-v -v) для увеличения подробностей.
Checknode ALL	Просмотр подробной информации для ВСЕХ узлов в вашем кластере.
Mdiag	Предоставляет диагностические отчёты для ресурсов, рабочих нагрузок и расписаний.
Mjobctl	Изменение, управление и просмотр заданий.
Mnodectl	Изменение, управление и просмотр узлов.
Mrmctl	Изменение, управление и просмотр менеджеров ресурсов.
Mrsvctl	Изменение, управление и просмотр резервирований.
Mrsvctl -l	Отображает все параметры настройки планировщика.
Mshow	Просмотр существующих настроек и прогнозируемой доступности ресурсов.
Showstats	Просмотр всех статистик планировщика и полномочий.
Showstats –u <user>	Просмотр статистик определённого пользователя.
showres	Отображает подробную информацию для любого резервирования.
Showstate	Отображает подробную информацию для всех заданий, включая их местоположения, а также отображает сообщения об ошибках задания, если они присутствуют.

В качестве примера ниже мы воспользуемся детализацией showstate.

Будучи загруженным с полномочиями moab-admin, портал Viewpoint предоставляет внутреннюю информацию по всем рабочим нагрузкам ото всех пользователей в кластере.

Viewpoint поддерживает администратора отчётами по узлам и их соответствующим состояниям, выполняющимся на этих узлах заданиях, углубляется в подробности обзора узлов. В объединении с системой CMS, например XCat, текущая ОС может выдаваться как "свойство узла", отображая (помимо прочего) развёрнутый стек программного обеспечения.

Viewpoint предоставляет инновационный отчёт, называемый временной линией ресурса (Resource Job Timeline). Временная линия ресурса сообщает о выделении ресурсов заданию по времени - отчёт непосредственно связывается с планом расписания Moab (Moab Scheduling Plan). Для активации временной линии ресурса перейдите в просмотр узлов и выберите Resource Job Timeline.

Временная линия ресурсов задания сообщает о прошлых и исполняющихся заданиях в соответствии с узлами и продолжительностью. Помещение манипуляторы "мышь" над действием вызывает всплывающее менб определённых подробностей задания. Кликнув на задание углубитесь в в соответствующую страницу подробностей задания (Job Details Page), показанную ранее.

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

Синий и зелёный блоки: Вывод showstate из работающей системы, анонимные имена пользователя-/группы- и ID задания.

Пример:

Сводная таблица кластера: JobID 892658 обозначен как "E"

Сводная таблица применения: Задание "E" использует узлы из стоек 09 и 10.

Showstate позволяет быстро идентифицировать неожиданное поведение системы в соответствии с топологией аппаратных средств.

Сототяние не OK обозначется как:

[?]:Unknown (неизвестное)

[*]:Down w/Job (выключенный с заданием)

[#]:Down (выключенный)

[ ]:Idle (свободный)

[@] Busy w/No Job (занятый с отсутствием заданий)

[!] Drained (очищенный)

Moab поддерживает множество методов работы с контрольными точками. Здесь обсуждаются три из них.

Раздел документации Moab "9.4 Checkpoint/Restart Facilities" объясняет как работать с заданиями, которые могут получать сигналы для контрольных точек и могут повторно запускаться с такой контрольной точки. Контрольные точки могут создаваться периодически по запросу.

http://docs.adaptivecomputing.com/9-0- 1/MWM/help.htm#topics/moabWorkloadManager/topics/jobAdministration/checkpointrestart.html

Также см.:

Обзор вытеснения заданий http://docs.adaptivecomputing.com/9-0-1/MWM/Content/topics/moabWorkloadManager/topics/preemption/aboutPreemption.htm

Параметр PREEMPTPOLICY href="http://docs.adaptivecomputing.com/9-0-1/MWM/Content/topics/moabWorkloadManager/topics/appendices/a.aparameters.html#preemptpolicy

Атрибут менеджера ресурсов CHECKPOINTSIG http://docs.adaptivecomputing.com/9-0-1/MWM/Content/topics/moabWorkloadManager/topics/resourceManagers/rmconfiguration.html#checkpointsig

Атрибут менеджера ресурсов CHECKPOINTTIMEOUT http://docs.adaptivecomputing.com/9-0-1/MWM/Content/topics/moabWorkloadManager/topics/resourceManagers/rmconfiguration.html#checkpointtimeout

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

Раздел документации Moab "Z.104 Job Checkpoint and Restart" http://docs.adaptivecomputing.com/9-0-1/MWM/help.htm#topics/torque/2-jobs/jobCheckpointAndRestart.htm предоставляет подробности о том как выполнять интеграцию и раздел "Z.66 BLCR Acceptance Tests". Отметим, что BLCR поддерживается только для последовательных заданий.

Раздел http://docs.adaptivecomputing.com/9-0-1/MWM/help.htm#topics/torque/13-appendices/BLCRAcceptanceTests.htm описывает как выполнять приёмочное тестирование для BLCR.

Обычно для управления учётными записями и выделением рекомендуется менеджер учётных записей Moab (Moab Accounting Manager). Тем не менее, Moab также предоставляет собственные средства для извлечения или создания учётных данных.

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

Команда	Описание
Checkjob	Просмотр подробной информации для любого задания.
Checkjob -v -v -v <jobID>	Информация для любого узла. Добавьте -v (-v -v) для увеличения подробностей.
Qstat –f <jobID>	Просмотр всех статистик планировщика и полномочий.
Showstats –u <user>	Просмотр статистик определённого пользователя.
showhist.moab.pl [-a accountname] [-c classname] [-e enddate] [-g groupname] [-j jobid] [-n days] [-q qosname] [-s startdate] [-u username]	Сценарий showhist.moab.pl отображает историческую информацию о задании. Его цель аналогична цели команды checkjob, однако showhist.moab.pl отображает информацию об уже завершённых заданиях.

Для showhist и showstate мы предоставим здесь дополнительные сведения.

Приведём пример вывода showhist.moab.pl

> showhist.moab.pl
Job Id            : Moab.4
User Name         : user1
Group Name        : company
Queue Name        : NONE
Processor Count   : 4
Wallclock Duration: 00:00:00
Submit Time       : Mon Nov 21 10:48:32 2011
Start Time        : Mon Nov 21 10:49:37 2011
End Time          : Mon Nov 21 10:49:37 2011
Exit Code         : 0
Allocated Nodelist: 10.10.10.3
Job Id            : Moab.1
Executable        : 4
User Name         : user1
Group Name        : company
Account Name      : 1321897709
Queue Name        : NONE
Quality Of Service: 0M
Processor Count   : -0
Wallclock Duration: 00:01:05
Submit Time       : Mon Nov 21 10:48:29 2011
Start Time        : Mon Nov 21 10:48:32 2011
End Time          : Mon Nov 21 10:49:37 2011
Exit Code         : 0
Allocated Nodelist: 512M
 	   

Информация отображается для всех выполненных заданий. Отметим: когда Start Time и End Time имеют одно и то же значение, задание не имеет ограничений и всё ещё исполняется.

Отчёты об учётных данных для настроенного времени выдаются только после завершения задания. Для сохранения данных может быть выбрано значение для нескольких десятков тысяч заданий (успешное тестирование для 100000 заданий).

Для сохраняющихся учётных данных доступны 4 необязательных параметра:

Элемент в Moab.cfg создаёт полностью автоматизированную запись заданий для каждого задания по определённому пути

CLASSCFG[DEFAULT] JOBEPILOG="checkjob -v -v -v --xml $JOBID >/opt/share/jobs/$JOBID"
 	   

Moab сохраняет данные каждого заания между JOBSTART и JOBEND в соответсвующих файлах событий Moab. Эти журналы являются простыми текстовыми файлами ASCII, читаемыми человеком и прокручивающиеся ежедневно или по достижению предельного размера и сохраняются настраиваемое значение времени. Коллекция данных включает 24 параметра, которые могут применяться для детализации учётных записей. Список параметров можно увидеть в приводимом ниже блоке.

JOBID
REQUESTEDTC
UNAME
GNAME
WCLIMIT
STATE
RCLASS
SUBMITTIME
DISPATCHTIME
STARTTIME
COMPLETETIME
RMEMCMP
UMEM
RDISKCMP
SYSTEMQUEUETIME
FLAGS
COMMAND
RMXSTRING
DEPEND=jobsuccessfulcomplete:<JOBID>
PARTITION=pbs
DPROCS
ENDDATE
TASKMAP
SRM
MESSAGE
 	   

Запросы детализируют данные задания при помощи API RestFul. В разделе Другие методы реализации изменения заданий: MWS и переключатели мы уже приводили подробности того, как запрашивать информацию для одного определённого задания. Для целей учётных записей более предпочтительным является извлечение информации для групп заданий (или всех, ALL). Пример из документации MWS (Moab 9.0.1, MWS, section Jobs) http://docs.adaptivecomputing.com/9-0-1/MWS/help.htm#topics/moabWebServices/4-resources/jobs.htm%3FTocPath%3D4%2520Resources%7C_____10:

Section 4.19.2.A Get All Jobs

Get active jobs

Get completed jobs

Get jobs owned by a particular user

Пример для "Get completed jobs"

http://localhost:8080/mws/rest/jobs?api-version=3&query={"isActive":false}
 	   

Команда showstats предоставляет дополнительные метрики по пользователям и их соответствующим рабочим нагрузкам. Разница от чистого "job-by-job" showstats предоставляется просмотром "user", включающем метрики, такие как цель взноса честности (Fairshare) и эффективности задания.

Вывод showstats –u <username>

UserName	Имя пользователя.
UID	Идентификатор пользователя.
Jobs	Число выполняющихся заданий.
Procs	Число выделенных procs для исполняющихся заданий.
ProcHours	Число proc-hours необходимых для завершения исполняющихся заданий.
Jobs*	Число завершённых заданий.
%	Процент от общего числа заданий тех заданий, которые были выполнены пользователем.
PHReq*	Общее значение proc-hours запрошенных завершившимися заданиями.
%	Процент от общего значение proc-hours запрошенных завершившимися заданиями, который был запрошен пользователем.
PHDed	Общее значение proc-hours выделенных активным и завершившимся заданиям. Значение proc-hours выделенное заданиям вычисляется умножением числа выделенных proc на продолжительность времени, в течение которого эти proc были выделены, в зависимости от использования заданием ЦПУ.
%	Процент от общего выделенного значения proc-hours, которое было выделено пользователем.
FSTgt	Цель Fairshare. Цель fairshare определяется в файле fs.cfg. Это значение должно сравниваться с процентным значением выделенных пользователю node-hour для определения соответствует ли цель.
AvgXF*	Средний множитель расширения для завершённого задания. XFactor (множитель расширения) задания вычисляется по следующей формуле: (QueuedTime + RunTime) / WallClockLimit.
MaxXF*	Наибольшее значение множителя расширения полученное для завершившегося задания.
AvgQH*	Среднее время нахождения в очереди (в часах) для заданий.
Effic	Средняя эффективность задания. эффективность задания вычисляется делением действительного значения node-hour времени ЦПУ, использованного этим заданием на значение node-hour выделенное этому заданию.
WCAcc*	Средняя точность времни исполнения (wallclock) для завершённых заданий. Точность времени исполнения вычисляется делением действительного значения времени исполнения задания на определённый для него предел времени исполнения.

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

Adaptive Computing предлагает две различающиеся стратегии высокой доступности (HA, High Availability): Native HA (встроенная высокая доступность) и Extended HA (расширенная высокая доступность).

Moab (планировщик) и Torque (менеджер ресурсов) могут быть настроены для отказоустойчивой работы, называемой "встроенной высокой доступностью".

За дополнительными подробностями обращайтесь к документации Moab.

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

Наконец, процедуры работы должны быть настроены на поддержку и сопровождение высокой доступности. Для реализации Extended HA мы рекомендуем воспользоваться профессиональными службами Adaptive Computing (Adaptive Computing Professional Services).

Чтобы соответствовать наилучшей из возможных практик применения и производительности при высокой загруженности мы рекомендуем использовать 2 различных серверных узла для размещения Moab, Torque (или Slurm) и связанной MDB (Moab Data Base). При использовании локальных дисков стабильность пакетной системы не сцепляется с центральной распределённой файловой системой или другой совместно используемой (= потенциально перегруженной) системой хранения.

Standalone (автономная) установка: применяется один набор серверов.

Установка с Одним сервером: применяется для небольших систем и систем среднего размера, доступен единственный главный узел.

High Availability Когда необходима высокая доступность (HA), должен быть запланирован второй набор серверов, что отображено на приведённой ниже схеме как набор серверов HA1 и HA2. Сетевое соединение между серверами минимально должно быть 1GbE, а лучше 10GbE, и быть готовым выносить высокий широковещательный обмен UDP.

С применением CPUSETS, настраивается использование систем с помощью соответсвующих служб: Moab и Torque фиксируются соотвествующими настройками ядер и памяти. Отделение Moab и Torque, а также прочих служб на одном сервере от MDB на втором обеспечиывает наилучшую из возможных пропускную способность и чувствительность команд, отчётов и учётных записей.

ПО для всех серверов пакетной обработки (мин. требования)

64- битный сервер Linux, RedHat/CentOS 6.5 или выше, Sun® Java® 7JRE, Postgres 9.3
Конфигурация ПО	Moab1+2
Moab	14ГБ ОЗУ, 2 ядра
Torque	8ГБ ОЗУ, 1 ядрo
ОС, MWS, Mongo, Viewpoint, MAM	8ГБ ОЗУ, 1 ядрo
Конфигурация ПО	MDB1+2
MDB	28ГБ ОЗУ, 3 ядра
ОС и т.п.	4ГБ ОЗУ, 1 ядрo

Оборудование для всех серверов пакетной обработки (мин. требования)

Серверы	2 шт	Автономная конфигурация: "Moab1", "MDB1"
Альтернатива: Конфигурация автономная или с высокой доступностью
Серверы	4 шт	Автономная конфигурация: "Moab1", "Moab2" и "MDB1", "MDB2"
Torque	8ГБ ОЗУ, 1 ядрo
Срецификация серверов:
ЦПУ	4 ядра (плюс Hyper threading) или больше, 3ГГц
ОЗУ	32ГБ
локальные HDD	1ТБ	1ТБ или больше
локальные SDD	0.5ТБ	для пакетных системных данных

Сетевое соединение между серверами должно быть самым непосредственным, насколько это возможно (точка- точка?) и, было бы оптимально, иметь 10GbE.

Adaptive Computing предоставляет следующую документацию:

Формат и доступ к документации

Adaptive Computing предоставляет документацию и в формате на веб- основе и в виде файлов в pdf- формате. При каждом выходе новой версии или обновления выпускаются соответствующие замечания о редакции (Release Notes). Приглашаем Вас посетить http://docs.adaptivecomputing.com/.

Adaptive Computing курсы электронного убучения (e-Learning) разработаны для обучения в он-лайн режиме. Обучение на месте согласовывается на основе количества обучаемых плюс затраты на инструктора и дополнительные расходы.