• Несколько вопросов новичка, по Глобусу или чуть более общих

Добрый день.

У меня несколько вопросов практически новичка, хотя всякие бумажки и документы я почитываю уже несколько месяцев. Что мне в этих документах не нравится - это то, что они либо очень общие (типа, "ну, аутентификация должна происходить через gsi", либо слишком частные (откройте такой-то конфигурационный файл, отредактируйте такие-то параметры); сервисы, описываемые в документах, это либо примитивный CounterService, либо монструозный GRAM et.al., ну и так далее. Может, я просто не те документы читал...

Итак. Вопрос первый. Мне нужно развернуть тестовый грид на основе пакета Globus, моделирующий несколько кластеров, участвующих в общих вычислениях. Не могли бы вы описать приблизительную СХЕМУ, как могла бы быть устроена такая система. Допустим, про кластеры известно, что их два, на каждом стоит так или иначе MPI и PBS (не важно какие реализации). Можно ли сделать так, чтобы с каждого из них можно было запустить MPI-задачу, для которой оба кластера будут прозрачно представлены как один? В случае такой прозрачности, как учесть/настроить, что скорость связи между некоторыми узлами велика (допустим, myrinet между узлами внутри кластера), а между некоторыми - мала (например, между узлами из разных кластеров - ethernet)? Как это делается - с помощью стандартных средств типа GRAM, MPICH-G2 etc. или требуется какие-то усилия по программированию? Есть ли возможность сделать изменения на каждом кластере минимальными (например, затрагивали только управляющую машину кластера, а не каждый узел)?

Вопрос второй. Какова доля программирования, какова - использования существующих средств при разработке реальных (для научной сферы в моем случае) use-case'ов на основе грид? Я понимаю, что с помощью Globus API можно написать что угодно, и свою реализацию MPICH-G2 например, и оно будут настраиваться, как мне надо, использовать ресурсы, как мне надо, и т.д. Только это долго, мне бы прикладные задачи писать, а не системную часть... Скажем так: что реально можно сделать, используя существующие средства, что - программируя самостоятельно (в умеренных объемах: сервис написать я могу, а систему, сопоставимую по мощности, например, с mpi+pbs - не очень

Последний вопрос можно еще переформулировать так: вот я поставил GT4, как описано в admin.pdf с globus.org на один, два, десять компов. Да, я могу написать свой CounterService, задеплоить на одном компе и дернуть с другого, но мне это не надо (или надо, но я не представляю, зачем). Что РЕАЛЬНОЕ, приближенное к жизни, полезное для человечества (скажем, опять же, науки) можно из этой системы сделать, и как (программируя? - что и на каком уровне? администрируя? - что и на каком уровне?)...

Я понимаю, что сбивчиво и путано, но надо хоть с чего-нибудь начать, каша в голове у меня та еще %) Если разговор получится - продолжим и уточним.

Спасибо.

Описание компонентов в Глобусе дается в основном только для того, чтобы понять какой компонент использовать в каких целях и какими параметрами при этом можно варьировать (конфигурационные файлы) и не более.
При первом прочтении естественно появится много вопросов и вовсе GRAM не такой уж и "монструозный" как может показаться
По личному опыту могу сказать, что я занимаюсь Глобусом уже несколько лет и у меня до сих пор существует непонимание в некоторых вопросах.
По поводу CounterService'а, если он не нравится, есть другой пример - MathService от Borja Sotomayor (http://gdp.globus.org/gt4-tutorial/), который прольет свет на связь WSRF с GT4. Кстати, в новой версии добавились разделы по безопасности.
В любом случае - это лишь маленькая часть, которая входит в Common Runtime (см. http://globus.org/toolkit/about.html). GRAM, как можно видеть из этой схемы - относится к стратегии управления исполнением и WSRF для него - просто средство реализации. В вопросах GRAM, где уже важны асепкты безопасности, и клиентский код должен быть более тяжелым.

===

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

===

Что касается первого вопроса, то, вообще не имеет значения один у вас кластер или два и где они расположены. Все равно прийдется обращаться к веб-сервису и где вы его настроите - дело ваше, может быть у вас будет несколько точек для отправки заданий, может быть одна как в Грид-диспетчере (Павел Березовский, поправьте меня если я чтото напутал )
Отправляются задания через GRAM, который пердставлен в виде web-сервиса, пример клиента для него - утилита globusrun-ws в поставке GT.
По вопросам, связанным с MPI ничего не могу сказать, поскольку не занимался этим вообще :\

О втором вопросе можно сказать, что use case в этом случае - это batch. Batch прийдется написать самому, а все остальное, включая его отправку на выполнение, мониторинг и т.д. можно осуществлять средствами GT без дополнительного программирования из консоли. Но ничего не мешает внести изменения в код клиента.. это же open source

Опять же по поводу клиента CounterService (раз уж он вам так запал в душу ), то такие сервисы и правда бесполезные и человечеству от них выгоды нет
Можно использовать WS Core для введения stateful web-сервисов для своих проектов, но тут уже речь пойдет не о GT вообще, а о его частичном применении. Такой вот он универсальный.
А что можно написать - на той ссылке (где карта компонентов) можно посмотреть на компоненты обведенные пунктирной линией - из серии contribution. Это может оказаться полезным

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

Дмитрий, добрый день!

Одной из целью создания нашего сайта как раз является предоставление участникам возможности публиковать свои работы, связанные с технологиями грид. О том, как публиковать собственные материалы, Вы можете прочитать здесь: http://www.gridclub.ru/help.html .

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

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

Большое спасибо за оперативные ответы, пожалуй, наилучшие из возможных при таких формулировках вопросов, как мои :)
Многое прояснилось, и теперь я бы хотел несколько уточнить свой первый вопрос.

Допустим, есть два (да, все-таки дваа :) кластера: один мой, второй - того парня. Каждый администрируется независимо, никаких точек входа друг для друга пока нет и в текущем виде (без глобуса) не предвидится. Я даже не хочу знать, что у него там стоит - remote shell, secure shell, condor, pbs ... Мы, короче, ***разные*** "виртуальные организации" :)

Мы хотим объединить вычислительные ресурсы. Мы оба согласны поставить Globus на свои кластеры. Мы даже согласны поставить некую промежуточную машину между нашими кластерами, и поставить туда глобус, если надо.

Задачи, которые нам надо решать, примитивны до безобразия. Забудем про mpi и так далее: это в связке с глобусом - слишком высокий для меня сейчас пилотаж. Мы просто хотим дать пользователям наших кластеров возможность запускать их проги, перебирающие параметры, распределяя нагрузку между кластерами. То есть если пользователь хочет запустить 16 экземпляров программы, у меня в кластере 12 процессоров, а у того парня сейчас 4 свободных, то все 16 экземпляров программы запускаются одновременно на разных процессорах. Входные данные для программ - из файла, выходные - в файл, никаких межпроцессных взаимодействий, дался мне этот MPI...

Мы бы очень хотели поменьше писать всякие противные сервисы (по крайней мере сейчас), а если и писать, то хоть знать точно, какие и что они должны делать. Мы слышали, что у Глобуса есть замечательный механизм распределения заданий GRAM, представленный в виде веб-сервиса, вот его-то нам бы и хотелось использовать (напоминаю, на моем кластере, на его и, возможно, на промежуточной тачке), и желательно не через API, а через контейнер с GRAM'ом, через globusrun-ws - короче, используя (читай - *настраивая*) то, что уже есть!

Так вот, не могли бы вы подсказать, чисто схематически, че делать-то?! :)

Спасибо.

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

В такой постановке задача на мой взгляд стала намного проще. Для этого вам с "тем парнем" надо установить на шлюзовых машинах Globus, в состав которого входит CSF (Community Scheduler Framework). Я так думаю, что CSF достаточно иметь на одной из шлюзовых машин, а вторую шлюзовую машину (второй кластер) подключить в настройках CSF, как дополнительный кластер. Я не знаком с деталями CSF, но по-моему, это то, что вам надо.

Попробуйте, возможно, это поможет.

P.S. GRAM - это служба *запуска* заданий, а не распределения. GRAM запускает задания в локальный менеджер кластера. *Распределением* как раз должен заниматься CSF.