PARALLEL.RU

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

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




Начать новую тему Ответить на тему  [ Сообщений: 55 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: 1 июн 05 11:28 
Не в сети

Зарегистрирован: 11 дек 02 19:37
Сообщения: 872
Откуда: НИВЦ МГУ
taleks писал(а):
полноценный diskless-client существенно лучше в подавляющем большинстве задач.

Ну, это пока не случится маленькая или большая беда - если машина по какой-то причине не сможет сеть использовать или на сервере проблема - и на решение такой задачи приходится гробить кучу времени. Или если хоть одна задача немного свопа отгрызёт - с диском она просто чуть (или не чуть) медленнее отработает, а вот без дика - всем поплохеет, т.к. nfs-у станет худо. Да и цена вопроса-то $100, а то и дешевле (если не блейды ставить, конечно).

taleks писал(а):
Тригеры должны реализовываться уровнем выше. Интеграция кода обработки условий в код собственно сбора - неестественный подход.

О! Точно. Именно из этого я и исходил, когда делал свою систему - приятно, что не один я так думаю :) А насчёт оптимальности в ганглии я бы поспорил - столько broadcat-ов, сколько она делает свич приводят в "восторг" - так он светится :) На 10 узлов может оно и хорошо, а вот на 32 - уже чувствуется нагрузка...


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

Зарегистрирован: 28 май 05 21:12
Сообщения: 217
Откуда: Москва
Serg_Zhum писал(а):
А насчёт оптимальности в ганглии я бы поспорил

Давайте поспорим :)

Serg_Zhum писал(а):
- столько broadcat-ов, сколько она делает свич приводят в "восторг" - так он светится :) На 10 узлов может оно и хорошо, а вот на 32 - уже чувствуется нагрузка...

Она НЕ использует броадкаст. Она использует мультикаст, а это абсолютно разные вещи. Помимо этого она умеет работать и по обычному TCP.

О нагрузке ганглии при использовании на большом количесвте узлов (тысячи)
можно почитать здесь: http://www.cs.berkeley.edu/~massie/papers/science.pdf.


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

Зарегистрирован: 24 май 05 9:00
Сообщения: 9
Цитата:
Ну, это пока не случится маленькая или большая беда - если машина по какой-то причине не сможет сеть использовать

Мы же вроде про узлы кластера говорим.
Если машина не сможет использовать сеть - она автоматически не узел кластера, даже если она и не дисклесс. Мы не можем разделять задачи, мы не можем складировать данные централизованно, вообще узел уже отпочковывается от той цельной структуры, что называется кластер.
Идея кластерного решения пропадает, у нас просто кучка рабочих станций получится. Ну а в случае дисклесс... кучка неспособных работать как рабочие станции узлов :)

Цитата:
или на сервере проблема

В реальности, всё зависит от реализации. Может и выжить даже если сервер выключить и уйти в бессрочный отпуск. Реализация большинства функции ввода-вывода пайпами предполагает по дефолту блокировку операции. Соотвественно, все потоки упадут в сонный режим и система просто остановит вычисления до пробуждения. В идеале, конечно. Хотя такое случалось.

Цитата:
Или если хоть одна задача немного свопа отгрызёт

Вот это уже более серьёзная проблема, хотя:
1. swap via NFS никто не отменял.
2. в идеале задача не должна требовать своп. И система диспетчеризации и библиотека обеспечения распределенных вычислений должны об этом побеспокоиться.

Цитата:
Да и цена вопроса-то $100

Где вы видели аппаратный RAID всего за 100$?
Ну а просто винт, без рейда - тогда где надёжность?

100$ на каждую машину+2х100$ винты.
Мне кажется эффективнее прикупить 1гб оперативной памяти на каждый узел, чем следовать такой стратегии.

+ не забываем про питание, износ оборудования и прочее. Дисклесс - выгоднее, в том числе в централизованном администрировании и достаточно лёгком обновлении системы на всех узлах сразу.

Цитата:
На 10 узлов может оно и хорошо, а вот на 32 - уже чувствуется нагрузка...

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

По трафику. Набор стандартных метрик ганглии (сейчас что-то около 50) в сумме составляет менее 1 кб для узла (порядка 100-200б, для особо используемых и часто обновляемых, остальные имхо, можно не мониторить). Причём этот килобайт размазан по временному интервалу где-то в минут 5-10 в среднем. Даже с учётом накладных расходов - всё не так уж и страшно. Что мне лично не нравится - это обилие пакетов. Т.е. замер сделан метрики - пакет ушёл. Вот это не очень хорошо, хотя иногда ганглия старается пакеты спаивать вместе.


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

Зарегистрирован: 11 дек 02 19:37
Сообщения: 872
Откуда: НИВЦ МГУ
Цитата:
Мы же вроде про узлы кластера говорим.

Я имею в виду сбои. Перестал узел загружаться - а почему? Когда он с винта грузится решить проблему во сто крат проще.
Цитата:
Вот это уже более серьёзная проблема, хотя:
1. swap via NFS никто не отменял.

И проблема одной задачи становится проблемой ВСЕХ запущенных задач.
Цитата:
2. в идеале задача не должна требовать своп.

Завидую тем, кто работает только с идеальными задачами :)

Цитата:
Где вы видели аппаратный RAID всего за 100$?
Ну а просто винт, без рейда - тогда где надёжность?

Надёжность нужна на файл-сервере. Даже если ОС начала сбоить или перестала грузиться, заменить винчестер не проблема. А случается это не часто - у меня на 80 машинах такое случалось раз 5 за 4 года и решалось быстро и безболезненно.


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

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

Утверждение спорное. Как мы определяем причину? Заходим, тыкаемся в логи, в т.ч. логи загрузки, методом тыка устраняем проблему. Для дисклеса всё это справедливо. Процесс протекает аналогично, только логи лежат на сервере одном, например.

Цитата:
И проблема одной задачи становится проблемой ВСЕХ запущенных задач.

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

Цитата:
Завидую тем, кто работает только с идеальными задачами

:) зависть это плохо...

Цитата:
Даже если ОС начала сбоить или перестала грузиться, заменить винчестер не проблема.

Ну а в дисклесс его и менять не надо...

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

По крайней мере при организации взаимодействия с помощью NFS.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 1 июн 05 22:25 
Уважаемые коллеги.
Мы давно используем OpenPBS,
у нее есть как достоинства, так и недостатки,
Достоинства - очень низкое потребление ресурсов и
динамическое управление конфигурацией.
Недостатки - повисание системы, если валится узел,
на котором висел процесс. Если узел был пуст то все в порядке.
И второе, отсутствие лимита на используемые процессоры.
Лимит имеется только на количество задач.
Вторая проблема поправима, и мы собираемся ей заняться.
А вот что касается первой - то то пока не понятно как ее решать.
Если имеется информация, то хотелось бы с этого места по подробнее.


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

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

Да недостатки есть, но не те о которых Вы говорите.
Дацюк В.Н. писал(а):
Недостатки - повисание системы, если валится узел,
на котором висел процесс.
Если узел был пуст то все в порядке.

Опишите подробней вашу конфигурацию. НА каких задачах виснет - только на параллельных или даже на "обычных". У нас ни чего подобного НЕТ.
Почему эта ситуация имеет место смотрите мой пост выше пожалуйста.
Дацюк В.Н. писал(а):
И второе, отсутствие лимита на используемые процессоры.
Лимит имеется только на количество задач.
Вторая проблема поправима, и мы собираемся ей заняться.

Неужели...
man pbs_resources
qmgr
qreate queue dque test_que queue_type=e
s q test_que resources_max.nodes=3,resource_default.nodes=node2+node3

Чуть выше для очереди test_que был задан предела в 3 узла, а по умолчанию задача будет запущена только на двух, причем указанных (node2, node3)
Запрет/разрешение доступа к очереди конкретного пользователя/группы пользователей делается через переменные acl_users/acl_groups.
Дацюк В.Н. писал(а):
А вот что касается первой - то то пока не понятно как ее решать.
Если имеется информация, то хотелось бы с этого места по подробнее.

Проблема решена очень давно. Самое первое что приходит на ум отказ от
OpenPBS и переход на TorquePBS. Если по каким то субъективным причинам это Вас не устраивает воспользуйтесь поиском, например google. А начать можно отсюда:
http://www-unix.mcs.anl.gov/openpbs/
http://bellatrix.pcl.ox.ac.uk/~ben/pbs/


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

Зарегистрирован: 11 дек 02 19:37
Сообщения: 872
Откуда: НИВЦ МГУ
Принудительное использование LAM или патченного mpich, это, конечно, хорошо, но не решает проблему в ряде других случаев. А именно - использование закрытых реализаций MPI (ScaMPI, например), использование заранее собранных пакетов. В этом случае все проблемы вылезают в полный рост. У Вас их нет - это хорошо, но когда они появятся на их решение придётся много труда положить...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 2 июн 05 11:55 
Уважаемый Andrew Sapronov

Вы не поняли о чем идет речь.
В OpenPBS я могу установить лимит
для одной задачи, например, 10 CPU.
Могу установить лимит на количество задач для пользователя
одновременно находящихся в решении, например, 10.
Но я не могу запретить пользователю запустить 10
задач, каждая из которых захватит 10 процессоров.
А мне бы хотелось бы, чтобы ни какой пользователь
не мог захватить одновременно больше 10 процессоров.
Если Вы знаете как это сделать - поделитесь, пожалуйста.
На каких задачах зависает OpenPBS? На любых.
Вы проводили эксперимент, когда у Вас решается куча
разных задач и Вы просто грубо выключаете питание узла,
на котором решалась задача? Как себя при этом ведет
PBS. Что она говорит и что происходит со всей очередью?


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

Зарегистрирован: 28 май 05 21:12
Сообщения: 217
Откуда: Москва
Serg_Zhum писал(а):
Принудительное использование LAM или патченного mpich, это, конечно, хорошо, но не решает проблему в ряде других случаев.

Патченный OpenPBS, а не MPICH. ПРичем именно Open т.е. старая версия. В новых такого нет и не нужно ничего патчить. Хотите хоть из RPM ставьте.
Serg_Zhum писал(а):
А именно - использование закрытых реализаций MPI (ScaMPI, например), использование заранее собранных пакетов. В этом случае все проблемы вылезают в полный рост. У Вас их нет - это хорошо, но когда они появятся на их решение придётся много труда положить...

Что то кроме MPICH и LAM увы не пробовал и потребности попросту не было. PBS в принципе не знает, что на ней запускается. Ей все равно MPICH, MPI/PRO или что то еще. Она просто резервирует заданное количество узлов. Хотите MPICH, хотите ScaMPI, единственное, иногда (в зависимости от реализации MPI) нужно "убирать за собой".
Выбор LAM продиктован удобством. Если использовать MPICH придется разрешать запуск по RSH/SSH.
Очень интересно как Cleo решает эти вопросы? И вопросы неавторизированного запуска задач на узлах посредством RSH/SSH? PAM по всей видимости?


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

Зарегистрирован: 11 дек 02 19:37
Сообщения: 872
Откуда: НИВЦ МГУ
Andrew Sapronov писал(а):
Патченный OpenPBS, а не MPICH. ПРичем именно Open т.е. старая версия. В новых такого нет и не нужно ничего патчить. Хотите хоть из RPM ставьте.

Из приведённых ссылок следовало, что именно MPICH патчится, но, возможно, я не очень внимательно смотрел.


Andrew Sapronov писал(а):
Очень интересно как Cleo решает эти вопросы? И вопросы неавторизированного запуска задач на узлах посредством RSH/SSH? PAM по всей видимости?

Есть варианты. Если нужен просто запуск по rsh/ssh без хитростей (обычный mpich), то есть возможность "эмулировать" rsh - Cleo сама запускает процессы и чистит их по мере необходимости вместо rsh. При этом оригинальный rsh, понятно, надо переименовать, либо собирать mpich с указанием "фальшивого" rsh.
А можно совсем ничего не менять и разрешить задаче запускаться так как предполагается разработчиком, посредством PAM делать авторизацию доступа для rsh/ssh, а Cleo тогда просто следит за тем, чтобы процессы задачи не оставались на узлах после сбоя или завершения и, при необходимости, прибивает их. Ну, и всё управление ресурсами, понятно, тоже на ней.


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

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

Вы не поняли о чем идет речь.

Извиняюсь, но каков ворос
Дацюк В.Н. писал(а):
И второе, отсутствие лимита на используемые процессоры.

таков и ответ :)

Дацюк В.Н. писал(а):
В OpenPBS я могу установить лимит
...
А мне бы хотелось бы, чтобы ни какой пользователь
не мог захватить одновременно больше 10 процессоров.
Если Вы знаете как это сделать - поделитесь, пожалуйста.

Пожалуй именно так сделать не получтся. Но я не ручаюсь.
А Вы не пробовали использовать такой ресурс как
other судя по описанию Вам может подойти:

Allows a user to specify site specific information. This
resource is provided for use by the site’s scheduling policy.
The allowable values and effect on job placement is site
dependent. Units: string.

Самому пробовать пока времени нет. Диплом.

Дацюк В.Н. писал(а):
На каких задачах зависает OpenPBS? На любых.
Вы проводили эксперимент, когда у Вас решается куча
разных задач и Вы просто грубо выключаете питание узла,
на котором решалась задача? Как себя при этом ведет
PBS. Что она говорит и что происходит со всей очередью?

Да странно. Если PBS патченный. Если нет, то вполне закономерно.
Да подобные эксперименты я проводил. "Многоузловые" задачи валились с сообщением об ошибке и узлы оставшие жить освобождались. Ну а при "моно" задачах все еще проще. Узел отвливается и pbsnodes просто выдает, что он down. Включаем и спустя некоторое время он появляется опять в системе.

Более того, при сбое пришлось отключить центральный узел, после включения все задачи остались на месте и УСПЕШНО досчитались. Но это проходило только для набора "моно" задач. Особенность обнаружтлась недавно и поисследовать пока не было времени и возможностей.


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

Зарегистрирован: 28 май 05 21:12
Сообщения: 217
Откуда: Москва
Serg_Zhum писал(а):
Из приведённых ссылок следовало, что именно MPICH патчится, но, возможно, я не очень внимательно смотрел.

Есть и один из пары десятков патчей и для mpich, но он немного не из этой темы.

А определние того, что конкретный процес это процесс задачи определенного пользователя как происходит? Просто немного хочется про архитектуру Cleo почитать.


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

Зарегистрирован: 11 дек 02 19:37
Сообщения: 872
Откуда: НИВЦ МГУ
Andrew Sapronov писал(а):
А определние того, что конкретный процес это процесс задачи определенного пользователя как происходит? Просто немного хочется про архитектуру Cleo почитать.

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


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


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

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


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

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


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

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