Context Navigation

Работа с опциями, поддерживаемыми кластерами

Описание

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

Текущее состояние

Обсуждение.

Подробное описание

Проблема, которая породила данное предложение: предположим, пользователь пишет задачу, которая требует MPI для работы. Ему без разницы, какая реализация MPI при этом будет использоваться (но надо, чтобы на кластере была хоть какая-то). Сейчас единственный способ добиться запуска такой задачи, это указать явно flavour (или даже конкретную версию) того mpi, который нужен, через атрибут software в требованиях. Это сильно сужает круг доступных ресурсов.

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

<Queue>
...
  <Feature>MPI</Feature>
  <Feature>OpenMP</Feature>
...
</Queue>

Формат описания сейчас приблизительный, возможно это стоит делать как-то иначе.

Предварительный список допустимых значений Feature:

single
multiple
mpi

stepanova 2011-02-18 03:55

Вставлять не в <SubCluster?>, а все же в <Queue>;
и можно без выделенного блока (искать чуть проще, наверно)

<SubCluster>
   ...
   <Queue>
        <CEInfo>xxx/yyy</CEInfo>
        <JobType>single</JobType>
        ...
        <JobType>mpi</JobType>
        <ACL>
            ..
        </ACL>
   </Queue>
</SubCluster>

*/ Возможные типы сейчас только single, mpi, multiple.

shamardin 2011-02-18 11:22

Я считаю, что анонсировать нужно именно эти самые features, а не поддерживаемые jobtype'ы. Насколько я понимаю, single и multiple, тем более, поддерживает любой кластер. Может потом появитяся еще что-то полезное, типа там <Feature>SharedMemory</Feature>

kurakin 2011-02-18 11:34

single и multiple конечно поддерживает любой (теоретически), но в очередях есть запреты. У нас (KI) есть очередь single, в которую нельзя запускать задачи multiple. Соответственно и в очередь для mpi запускать задачи на одно ядро тоже нельзя. Так что хочется деления по капабилити по очередям.

shamardin 2011-02-18 11:40

Ok, тогда предлагаю набор Features, который пока совпадает с допустимыми jobType глобуса, но имеющий строго фиксированную семантику (в отличие от jobType):

single: поддержка запуска однопроцессных заданий.
multiple: поддержка запуска многопроцессных заданий, без MPI.
mpi: поддержка запуска mpi-заданий.

kurakin 2011-02-18 11:34

А касательно mpi, есть ли у нас общие для всех правила описания какие варианты mpi поддерживаются и как выбирать запуск именно через это тип mpi. У нас как и у всех, наверное, реализован один какой-то mpi, более того, поддерживаем официально только один, но теоретически можно позволить выбирать mpi. Поидее это было бы удобно делать так: mpi - любой дефолтный, mpiX конкретный.

shamardin 2011-02-18 12:27

Очень жаль, что вы не присутствуете на митингах, об этом и шла речь. Выбрать сейчас конкретную реализацию MPI можно, и достаточно легко (через "software": "mvapich" например). А вот сказать "дай мне любой mpi, какой есть, и используй на кластере тот mpi, который для него дефолтный" сейчас нельзя.

stepanova 2011-02-18 12:43

Ок, нормально, пусть <Feature> для очереди.
Правда, насчет семантики чего-то больно мудрено - пусть single, mpi, multiple и будет пока (это ж с конкретной вещью связано, зачем админов заставлять лишнее преобразование в другие слова делать.

Тогда что - сегодня правлю схему c примером и вечером делаю рассылку админам, чтобы все добавили? Или всем тикеты?

kurakin 2011-02-18 13:23

Лучше тикеты, если известно кому. Быть может предварительно заслать "решение рабочей группы" в develop, на финальный review и как своего рода уведомление. Вдруг у остальных есть какие мысли. И если до некоторого времени Ч не поступит комментариев, вступает в силу новая схема. Да. За одно, будет не плохо добавить уведомление о том как проще всего провести валидацию своего сайта на текущую схему (со ссылкой на схему), конечно все должны знать, но уверен что лишнем не будет. Спасибо.

shamardin 2011-02-18 13:34

Давайте не будем торопиться, и немного "осмыслим" это предложение до понедельника, может еще кто-либо сегодня прокомментирует. Плюс, нужно сначала задокументировать это все в текстах про настройку ЛИС.

У меня лично есть некоторое предубеждение против feature "multiple". Я пока знаю только один use case, для которого это нужно: это openmp. Может, лучше его так и называть?

kurakin 2011-02-18 13:49

Лично я не вижу причин почему не может быть осуществлен запуск не mpi задачи, но которой требуется N вычислителей. Грубо говоря запустить обычный hostname N раз имеет право на жить. Простые тупые молотилки, не взаимодействующие друг с другом, но решающие "одну" задачу. Почему нет?

shamardin 2011-02-18 13:54

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

kurakin 2011-02-17 14:09

Конечно вариант, но сколько отдельных молотилок можно запустить, а сколько "пакетов" молотилок. Ограничения разные, опять же, на каждую молотилку загружать данные или на "пакет". Собственно тут опять же можно рисовать и за и против. И что забавно и то и другое будет верно. Может просто банально не вводить лишнее ограничение. Если есть видение что openmp отдельный случай, его можно выделить в новый jobtype, а уж позволять ли другие виды multiple или нет - оставить на откуп локальным ресурсам. Хотя, лично я, разници не вижу для себя как для ресурса. Но может я просто чего-то не понимаю.

stepanova 2011-02-18 02:50

Именно эта тройка поддерживается GRAM в настоящее время. Введение ее сейчас никаких плохих последствий создать не должно. Может multiple реально и мало понадобится, зато остальным можно будет пользоваться.
По поводу качественной выделенной фичи openmp или еще какой-то экзотики придется еще думать, тестить, вносить изменения в GRAM. Со всеми вытекающими временными затратами, в т.ч.переделкой всех сборок ngrid-ce-*.

Короче, я со своей стороны все сделала, внизу страницы драфт сообщения в рассылку.

kurakin 2011-03-01 12:36

Для тех кто в танке, а чем все закончилось то?

После этого pilot будет автоматически знать, что если в задаче стоит (пока не утвержденный) атрибут type = mpi, то нужно выбирать только те ресурсы, для которых заявлен Feature MPI.

Преимущества, которые это даст

Более универсальные и простые для использования описания задач.

Какие компоненты нуждаются в модификации

pilot
ngrid-lis /site-info-example +schema - немного.
ngrid-cis? - не требуется

Сценарий использования

TBD.

Сообщение администраторам

Коллеги,

в результате обсуждения http://www.ngrid.ru/trac/wiki/PilotFeatureClusterFeatures сформировалось такое решение:

для оптимизации обработки пилотом разных типов заданий необходимо в файле site-info.xml добавить новые теги Feature в описание очередей субкластеров.

<Queue>
  <CEInfo>...
  <Feature>mpi</Feature>
  <Feature>single</Feature>
  <ACL>...
</Queue>

Допустимые значения Feature: single, multiple, mpi. Такой набор в настоящее время поддерживается GRAM. В дальнейшем возможно его расширение, а также добавление других мета-опций. Напоминаю, что желательно эту операцию совместить с проверкой валидности ваших site-info.xml, например, так:

xmlstarlet val --err -s http://ngrid.ru/glueschema/V13/R1/glueschema13R2-7.xsd site-info.xml

P.S.
Последние варианты файлов с примерами в svn:

lis/ngrid-lis-1.0/samples/site-info-example.xml
		 /samples/site-info-example-with-comments.xml
		 /schema/glueschema13R2-7.xsd

В старый пример на wiki http://www.ngrid.ru/trac/wiki/SiteInfoWithComments изменения добавлены;
в новой новой инструкции изменения не требуются.

Схема, как и раньше, здесь:
http://ngrid.ru/glueschema/V13/R1/glueschema13R2-7.xsd;

Изменения:

$ diff -u glueschema13R2-7.xsd-17.02.11 glueschema13R2-7.xsd
--- glueschema13R2-7.xsd-17.02.11       2010-10-07 12:29:37.000000000 +0400
+++ glueschema13R2-7.xsd        2011-02-19 01:02:52.000000000 +0300
@@ -4,6 +4,7 @@

+<!-- Revision number: 3.2 date: 18 Feb 2011 :: add FeatureTypeEnum (single,mpi,multiple) -->

@@ -22,6 +23,36 @@

        <!-- enumerations definition -->
+       <xs:simpleType name="FeatureTypeEnum">
+               <xs:restriction base="xs:string">
+                       <xs:enumeration value="single"/>
+                       <xs:enumeration value="mpi"/>
+                       <xs:enumeration value="multiple"/>
+               </xs:restriction>
+       </xs:simpleType>

@@ -166,6 +171,7 @@
        <xs:complexType name="Queue">
                <xs:sequence>
                        <xs:element name="CEInfo" type="xs:string"/>
+                       <xs:element name="Feature" type="FeatureTypeEnum" minOccurs="0"  maxOccurs="unbounded"/>
                        <xs:element name="ACL" type="ACLType"/>
                </xs:sequence>
        </xs:complexType>

Download in other formats:

Plain Text