PARALLEL.RU

Дискуссионный клуб по параллельным вычислениям
Текущее время: 7 дек 19 22:22

Часовой пояс: UTC + 4 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 55 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: 7 июн 05 20:50 
Уважаемый Andrew Sapronov.
Вы писали, что новый OpenPBS пропатченный
не имеет проблем с зависанием диспетчерской
системы. Так вот, довожу до Вашего сведения,
что последняя версия OpenPBS-2.3.16 со всеми известными
патчами виснет точно также, как и предыдущая версия 2.3.12.
Единственную проблему, которую они решили с помощью
патчей - это установка лимита на CPU, используемых всеми
задачами пользователя. Это действительно сделано и работает.
А вот с зависанием проблемы остались. Поскольку Вы не всегда
понимаете мои вопросы, объясняю подробнее.
Запускается несколько однопроцессорных задач.С помощью
команды pestat определяется узел, на котором решается
одна из задач. Подходите к этому узлу и выдергиваете служебную
сеть. После этого, ни одна команда PBS на серверной машине
не исполняется. Ни qsub, ни qstat, ни pbsnodes.
Такая ситуация продолжается до тех пор, пока либо не будет
восстановлен узел, либо не будет перезагружен сервер PBS.
В результате чего все задачи пропадают.Точнее начнут решаться
сначала..
Вопрос остается в силе - есть ли решение этой проблемы?


Вернуться к началу
  
 
 Заголовок сообщения:
СообщениеДобавлено: 7 июн 05 20:53 
Уважаемый Andrew Sapronov.
Вы писали, что новый OpenPBS пропатченный
не имеет проблем с зависанием диспетчерской
системы. Так вот, довожу до Вашего сведения,
что последняя версия OpenPBS-2.3.16 со всеми известными
патчами виснет точно также, как и предыдущая версия 2.3.12.
Единственную проблему, которую они решили с помощью
патчей - это установка лимита на CPU, используемых всеми
задачами пользователя. Это действительно сделано и работает.
А вот с зависанием проблемы остались. Поясняю ситуацию подробнее.
Запускается несколько однопроцессорных задач.С помощью
команды pestat определяется узел, на котором решается
одна из задач. Подходите к этому узлу и выдергиваете служебную
сеть. После этого, ни одна команда PBS на серверной машине
не исполняется. Ни qsub, ни qstat, ни pbsnodes.
Такая ситуация продолжается до тех пор, пока либо не будет
восстановлен узел, либо не будет перезагружен сервер PBS.
В результате чего все задачи пропадают.Точнее начнут решаться
сначала..
Вопрос остается в силе - есть ли решение этой проблемы?


Вернуться к началу
  
 
 Заголовок сообщения:
СообщениеДобавлено: 7 июн 05 20:55 
Уважаемый Andrew Sapronov.
Вы писали, что новый OpenPBS пропатченный
не имеет проблем с зависанием диспетчерской
системы. Так вот, довожу до Вашего сведения,
что последняя версия OpenPBS-2.3.16 со всеми известными
патчами виснет точно также, как и предыдущая версия 2.3.12.
Единственную проблему, которую они решили с помощью
патчей - это установка лимита на CPU, используемых всеми
задачами пользователя. Это действительно сделано и работает.
А вот с зависанием проблемы остались. Поясняю ситуацию подробнее.
Запускается несколько однопроцессорных задач.С помощью
команды pestat определяется узел, на котором решается
одна из задач. Подходите к этому узлу и выдергиваете служебную
сеть. После этого, ни одна команда PBS на серверной машине
не исполняется. Ни qsub, ни qstat, ни pbsnodes.
Такая ситуация продолжается до тех пор, пока либо не будет
восстановлен узел, либо не будет перезагружен сервер PBS.
В результате чего все задачи пропадают.Точнее начнут решаться
сначала..
Вопрос остается в силе - есть ли решение этой проблемы?


Вернуться к началу
  
 
 Заголовок сообщения:
СообщениеДобавлено: 8 июн 05 4:19 
Не в сети

Зарегистрирован: 28 май 05 21:12
Сообщения: 217
Откуда: Москва
Дацюк В.Н. писал(а):
Уважаемый Andrew Sapronov.
Вы писали, что новый OpenPBS пропатченный
не имеет проблем с зависанием диспетчерской
системы.

Ну новым он быть точно не может :)
Дацюк В.Н. писал(а):
Так вот, довожу до Вашего сведения,
что последняя версия OpenPBS-2.3.16 со всеми известными
патчами виснет точно также, как и предыдущая версия 2.3.12.

Все известные патчи накладывать, мне кажется, не стоит. Лишь те, в которых есть НЕОБХОДИМОСТЬ.
Приму к сведению, что на кластере К с архитектурой А, с дистрибутивом Д, ядром Я и т.д. и т.п. OpenPBS со всевозможными патчами не работает. Хотя, неизвестные тоже интересно узнать.
Дацюк В.Н. писал(а):
Поскольку Вы не всегда
понимаете мои вопросы, объясняю подробнее.
Запускается несколько однопроцессорных задач.С помощью
команды pestat определяется узел, на котором решается
одна из задач. Подходите к этому узлу и выдергиваете служебную
сеть. После этого, ни одна команда PBS на серверной машине
не исполняется. Ни qsub, ни qstat, ни pbsnodes.

Я прекрасно понимаю о чем речь. Я делал и так, и питание отключал у узла и еще много чего. Я вообще бы не решился ставить ПО с такого рода проблемами на кластер.
Дацюк В.Н. писал(а):
Такая ситуация продолжается до тех пор, пока либо не будет
восстановлен узел, либо не будет перезагружен сервер PBS.
В результате чего все задачи пропадают.Точнее начнут решаться
сначала..

Ну если они начинаются с начала, то все не так плохо. Это происходит в случе когда задача Rerunable = False и в случае Rerunable = True?

Дацюк В.Н. писал(а):
Вопрос остается в силе - есть ли решение этой проблемы?

TorquePBS попробуйте. Возьмите готовую реализаци кластерного пакета. ROCKS или OSCAR, например. Посмотрите как там реализовано.
А вообще... обратите внимание на мой пост, в начале этой ветки. Если у Вас система новее чем RH9 я бы рекомендовал отказаться от OpenPBS.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 8 июн 05 15:48 
Не в сети

Зарегистрирован: 28 май 05 21:12
Сообщения: 217
Откуда: Москва
Serg_Zhum писал(а):
Пока подробная документация есть только в виде doc-файла, обычный README/FAQ всё никак не сделаю :)
Архитектура предполагает, что на узлах работают программки-агенты, которые и осуществляют запуск/прибивание процессов, а также опознавание узла, как рабочего. Они же отслеживают появление процессов задачи в случае "пассивного" мониторинга. Отслеживают они эти процессы по маске - в конфиге задаётся регулярное выражение и все НОВЫЕ процессы под него попадающие от указанного пользователя маркируются как принадлежащие задаче. Делается такой анализ только в течении некоторого интервала времени после запуска, чтобы не грузить узел лишней работой.

Что значит пассивный мониторинг? Т.е. имеет ся возможность запуска задач в обход системы диспетчеризации? Программка-агент - демон?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: openPBS
СообщениеДобавлено: 8 июн 05 16:37 
++++++Запускается несколько однопроцессорных задач.С помощью
команды pestat определяется узел, на котором решается
одна из задач. Подходите к этому узлу и выдергиваете служебную
сеть. После этого, ни одна команда PBS на серверной машине
не исполняется. Ни qsub, ни qstat, ни pbsnodes.


ага...а еще хорошо выдернуть питание или топором порубать комутатор....вобщем можно придумать массу способов как сделать хард или софт неработоспособным...


Вернуться к началу
  
 
 Заголовок сообщения: Re: openPBS
СообщениеДобавлено: 8 июн 05 17:33 
Не в сети

Зарегистрирован: 28 май 05 21:12
Сообщения: 217
Откуда: Москва
good-new писал(а):
ага...а еще хорошо выдернуть питание или топором порубать комутатор....вобщем можно придумать массу способов как сделать хард или софт неработоспособным...

Ваши комментарии не уместны. Система диспетчеризации (и вообще кластерное ПО) должна уметь обрабатывать такие ситуации. И за аксиому берется то, что в любой момент времени узел/сервер может отвалиться из за аппаратной/программной ошибки и функционирование кластера не должно быть нарушено. Особенно это касается кластеров с большим числом узлов. Например, на BlueGene отказ одного из 100000 процессоров происходит раз в несколько минут (http://www.linux-mag.com/2004-11/fault_01.html)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: по делу
СообщениеДобавлено: 8 июн 05 17:34 
опустим момент с «кластерной сетью»…надеюсь уже не требуется доказывать аксиому, что из локальной сети суперкомпьютера не сделать. Поэтому если вы действительно хотите решать параллельные задачи и причем делать это эффективно, придется позаботиться об однородности харвера.

Теперь что о софте. Конечно, можно придумать свой велосипед, или использовать для решения определенных задач средства, которые предназначены для решения задач совершенно иных, но как показывает практика наиболее эффективны те решения, которые проверены, протестированы и ДАВНО используются и только при возникновении ДЕЙСТВИТЕЛЬНО необходимых потребностей дописывать свое.

Сейчас существует достаточно большое количество проектов по созданию кластерного софта. Среди них есть те которые стали да-факто стандартом. С помощью СУ OSCAR установлено порядка 30% всех кластеров из Top500. Система крайне простая в установке, позволяет инсталлировать как 32 разрядные так 64 разрядные кластерные системы. Гарантирует ПОЛНУЮ системную однородность вычислительных узлов. Предлагает целый набор полезных утилит пор управлению и администрированию. В качестве системы пакетной обработки использует OpenPBS с планировщиком на выбор Maui или torque.

Теперь по OpenPBS. Люди, НЕТ, НЕ СУЩЕСТВУЕТ проблем с установкой или использованием OpenPBS и MAUI. Это делается ЧЕРЕЗВЫЧАЙНО просто. Существует достаточно понятна документация (в том числе и на русском языке). Настроить OpenPBS под необходимые требования планирования можно силами одного вменяемого студента в течении нескольких дней (если оценка его квалификация в данном вопросе 0.)

По самой системе. OpenPBS система обладает достаточными возможностями чтобы реализовать самые извращенные стратегии планирования и доступа к ресурсам. По реализованным возможностям и надежности работы всем самодеятельным системам до OpenPBS примерно как до Луны.

Наберите в http://www.google.com “Clumon Help Page” и вы увидите ссылки на систему мониторинга Clumon которая работает под OpenPBS на системах в открытом доступе. Уберите в адресе help.html и перегрузите страницу и вы увидите что это за системы и где они инсталлированы.

Хороший пример 891 узловой кластер в NCSA.
http://tg-monitor.ncsa.teragrid.org/

и 262 узловой кластер в SDSC
http://clumon.sdsc.edu/

Удачи,
Good-new


Вернуться к началу
  
 
 Заголовок сообщения: Re: openPBS
СообщениеДобавлено: 8 июн 05 17:41 
Ваши комментарии не уместны. Система диспетчеризации (и вообще кластерное ПО) должна уметь обрабатывать такие ситуации. И за аксиому берется то, что в любой момент времени узел/сервер.


Нет проблем. Если вы один или несколько узлов падает OpenPBS легко справляется с этой задачей. Сложности возникают в случае если упавший узл использовался каким либо из заданий. В этом случае действительно, все остальные узлы под этой задачей становятся недоступны. Но нет никаких проблем для администратора "убрать" эту задачу руками а mom-на зависший узлах перегрузить. При этом нужно заметить, что все остальные узлы системы остаются доступны и работоспособны. Теперь расскажите как эта задача решается в других БЕСПЛАТНЫХ системах.

Кстати если виснет сервер, на уже работающие задачи это не произведет ровно никакого эффекта. Они нормально отработают, после чего сервер лучше поднять.

Удачи,
good-new


Вернуться к началу
  
 
 Заголовок сообщения: Re: openPBS
СообщениеДобавлено: 8 июн 05 19:01 
Не в сети

Зарегистрирован: 28 май 05 21:12
Сообщения: 217
Откуда: Москва
good-new писал(а):
Сейчас существует достаточно большое количество проектов по созданию кластерного софта. Среди них есть те которые стали да-факто стандартом. С помощью СУ OSCAR установлено порядка 30% всех кластеров из Top500. Система крайне простая в установке, позволяет инсталлировать как 32 разрядные так 64 разрядные кластерные системы. Гарантирует ПОЛНУЮ системную однородность вычислительных узлов. Предлагает целый набор полезных утилит пор управлению и администрированию. В качестве системы пакетной обработки использует OpenPBS с планировщиком на выбор Maui или torque.

Довожу до Вашего сведения... :) что OSCAR использует Torque, а не OpenPBS
и torque это не планировщик, а полноценный PBS.

good-new писал(а):
Нет проблем. Если вы один или несколько узлов падает OpenPBS легко справляется с этой задачей. Сложности возникают в случае если упавший узл использовался каким либо из заданий. В этом случае действительно, все остальные узлы под этой задачей становятся недоступны. Но нет никаких проблем для администратора "убрать" эту задачу руками а mom-на зависший узлах перегрузить. При этом нужно заметить, что все остальные узлы системы остаются доступны и работоспособны. Теперь расскажите как эта задача решается в других БЕСПЛАТНЫХ системах.
good-new


Она отлично решается и на TorquePBS и на SGE... Мне кажется вы подменяете понятия PBS и стандарта POSIX 1003.2b, на OpenPBS.

good-new писал(а):
Кстати если виснет сервер, на уже работающие задачи это не произведет ровно никакого эффекта. Они нормально отработают, после чего сервер лучше поднять.

По моему именно это я и говорил несколько постов назад. Следите за веткой уважаемый гость.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 8 июн 05 19:07 
++++Гм... И подвисшие задачки прибиваются корректно?

что значит подвисшие задачки? например средствами никакой системы пакетной обработки невозможно обнаружить зависший MPI ресив и следовательно невозможно понять статус процесса...можно лишь по истечении определенного времени (заказанного пользователем) снять задачу...это делается корректно.

+++++И зависание узла отрабатывается и на него не "летят" задачи?

Без всяких проблем. если mom какого либо узла не отвечает PBS считает узел выключенным и ес-но в дальнешем распределении задач он не принимает участия. Другое дело если узел завис в процессе выполнения задачи. В этом случае из пула достпных узлов "вылетают" все те которые былы зарезервированны под задачу. НО во-первых остальные узлы работают нормально, вернуть к жизни залипшие узлы можно удалив задание в ручную и перегрузив mom-ы залипших узлов.

+++++И пользователю можно разрешить занимать не более трети процессоров всеми задачами зараз?

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

+++ А Васе лично - считать задачки не более получаса, а потом срубать принудительно их процессы на узлах?

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

При этом реализован удовлетворительный бекфил алгоритм т.е. кластер ВСЕГДА будет использоваться по максимуму и при этом не будет "вечных" задач...

Почитайте документацию на http://www.supercluster.com для MAUI. Там все есть!

Good-new.


Вернуться к началу
  
 
 Заголовок сообщения: Re: по делу
СообщениеДобавлено: 8 июн 05 19:15 
Не в сети

Зарегистрирован: 28 май 05 21:12
Сообщения: 217
Откуда: Москва
good-new писал(а):
опустим момент с «кластерной сетью»…надеюсь уже не требуется доказывать аксиому, что из локальной сети суперкомпьютера не сделать. Поэтому если вы действительно хотите решать параллельные задачи и причем делать это эффективно, придется позаботиться об однородности харвера.

По этому, это почему??? Т.е. если не доказывать аксиому, придется заботиться об однородности... или что то еще... хм... странно

А что Вы понимаете под суперкомпьютером, который нельзя сделать из локальной сети???
good-new писал(а):
Наберите в http://www.google.com “Clumon Help Page” и вы увидите ссылки на систему мониторинга Clumon которая работает под OpenPBS на системах в открытом доступе. Уберите в адресе help.html и перегрузите страницу и вы увидите что это за системы и где они инсталлированы.

С виду это web надстройка над PBS. А что она умеет еще, что не умеет qstat?


Последний раз редактировалось Andrew Sapronov 8 июн 05 19:27, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: openPBS
СообщениеДобавлено: 8 июн 05 19:26 
++++Довожу до Вашего сведения... :) что OSCAR использует Torque, а не OpenPBS

все замечательно, только Torque в OSCAR как штатный пакет появился с версии 4.1 в 4.0 он был как дополнительный, а в 3.0 его вообще не было. Штатно же в OSCAR используется OpenPBS и MAUI.

+++и torque это не планировщик, а полноценный PBS.

да, тут согласен...полноценный PBS...фактически брат OpenPBS

++++Она отлично решается и на TorquePBS и на SGE... Мне кажется вы подменяете понятия PBS и стандарта POSIX 1003.2b, на OpenPBS.

возможно, я просто хочу донести нехитрую мысль..
OpenPBS реальная система, которую можно использовать и которую используют. Сложности в ней не больше чем в прочих решениях. Собственно это все :)

+++По моему именно это я и говорил несколько постов назад. Следите за веткой уважаемый гость.[/quote]

я просто не только для вас пишу...;)

Good-new


Вернуться к началу
  
 
 Заголовок сообщения: Re: по делу
СообщениеДобавлено: 8 июн 05 19:35 
+++А что Вы понимаете под суперкомпьютером, который нельзя сделать из локальной сети???qstat?[/quote]

понятнее наверное все таки так...:)

Что вы понимаете под локальной сетью, из которой можно сделать суперкомпьютер?



good-new.


Вернуться к началу
  
 
 Заголовок сообщения:
СообщениеДобавлено: 8 июн 05 19:37 
Не в сети

Зарегистрирован: 24 май 05 9:00
Сообщения: 9
Цитата:
например средствами никакой системы пакетной обработки невозможно обнаружить зависший MPI ресив

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

Теоретически (это всё ИМХО), MPI_ функции реализуются средствами системы, а потому состояния любого процесса/потока можно выяснить, далее по пиду уяснить родительскую задачу и послать сигнал уже средствами системы пакетной обработки. Другое дело что это никто особо не собирается делать.

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

Ы?
Локальная сеть != Ethernet network.
Или имеется в виду десяток компьютеров натыканных по секретутским рабочим местам? Тогда согласен, оно того не стоит. Хотя НАСА вроде была довольна использованием SETIatHome, которая как раз такие места и использовала.

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

Ну это и колючему ёжику понятно. И про однородность софта не забывать.

Цитата:
и ДАВНО используются

Зря вы так. Некоторые которые придуманы и реализованы ДАВНО, бывают просто не работают на новых ядрах. Поэтому берутся новые версии, которые вполне могут быть и нестабильными.

Цитата:
С помощью СУ OSCAR установлено порядка 30% всех кластеров из Top500

Что же, это хорошо. Но и масштаб несколько другой кластеров в топ500 и в топ50 СНГ. Не думаю что все решения приемлимые в одном случае легко перносятся на другой.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 55 ]  На страницу Пред.  1, 2, 3, 4  След.

Часовой пояс: UTC + 4 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB