PARALLEL.RU

Всем доброго времени суток!
Назрел у меня вопрос: Как объединить 2 вычислительных кластера???
Есть ли другие способы кроме ГРИДа? Просто не очень хочется разворачивать ГРИД ради объединения двух кластеров из учебных классов.

Зависит от цели.
Как легковесное средство могу посоветовать X-Com

Еще варианты могут быть такими:
1. Маршрутизирующая PBS очередь.
2. Один pbs_server на два кластера.

А чуть подробней ТЗ можно? А то если два класса находятся в одном здании, то может проще кинуть кабель и сделать из них просто один кластер?

Увы нужно объединить именно 2 кластера.


А можно поподробней?

Просто если идти таким путем, то есть для меня один непонятный момент. На каждом кластере есть своя консоль с диспетчеризатором и планировщиком, их нужно будет както связать с PBS-сервером?

В каком смысле объединить-то? Запускать одну большую MPI-задачу? Или запускать много маленьких MPI-задач, чтобы распределялись по кластерам? Или запускать однопроцессорные расчёты?

С некоторых пор меня тоже заинтересовала эта проблема.
Давай-те немного конкретизируем эту задачу.
В нашем случае, речь идет о том, что ресурсы центра коллективного пользования перегружены,
но университет приобрел множество кластеров на факультеты,
которые, по крайней мере сейчас, простаивают. Ни у кого нет принципиальных
возражжений, что бы мы часть своего потока перенаправили на выполнение на
эти кластера. Но при этом все факультеты хотят сохранить свою суверенность и автономность.
Поскольку на всех кластерах, к счастью, стоит одна и та же диспетчерская система -
OpenPBS/Torque, то имеется принципиальная возможность послатть задание
с любого кластера на любой. Но при этом возникает проблема синхронизации
рабочих каталогов до расчета и после расчета. И еще, хотелось бы избежать
двойной бухгалтерии и не регистрировать всех пользователей на всех кластерах и
избавить их от необходимости скакать по хостам.

У нас такая же проблема сейчас стоит. Задачей было подключение двух удаленных кластеров к одному грид-шлюзу с Globus Toolkit (в рамках проекта ГридННС). Нашли только два подходящих для нас варианта (как я озвучил ранее - маршрутизирующая очередь и общий сервер PBS). После долгих дискуссий выбрали общий сервер. По маршрутизирующим очередям мало документации. Официальная страничка - капля в море: http://www.clusterresources.com/torqued ... ml#routing так как там возникают проблемы, озвученные здесь: http://www.clusterresources.com/piperma ... 01816.html и какие проблемы еще предстоят в процессе эксплуатации, нам не известно.

В случае общего сервера PBS остается одна основная проблема - синхронизация директорий пользователей. Мы их собираемся хранить на одном хранилище, учетки держать в 1 экземпляре. Объединяем два кластера удаленных в несколько километров зданий, между площадками канал всего 1 Гбит - мало, если тянуть по нему /home, собираемся расширять и подумываем над распределеной ФС или просто синхронизацией директорий в скрипте пролога и эпилога PBS, пока не знаем. В случае, если кластера в 1 здании - с коммуникациями, я так понимаю, всё проще.

Если Вы используете один сервер PBS и общее хранилище данных,
то вообще ни каких проблем нет. У нас один сервер обслуживает 4-е кластера.
Для каждого из них создается отдельная очередь и пользователь посылает задание
либо на один, либо на другой кластер. Вопрос состоит в использовании ресурсов
другого, совершенно автономного кластера. Без индивидуальной регистрации
на нем всех пользователей.

Не было бы, если не считать, что между кластерами 1 канал, ширину которого нужно делить на число узлов в удаленном кластере.

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

Я обычно использую LDAP каталог в котором прописаны "считающие" пользователи. В вашем случае это может быть каталог центра коллективного пользования, который администраторы локальных кластеров разрешили в PAM. Монтирование домашнего каталога осукществляю посредством схемы autofs для LDAP и одноименного сервиса - autofs.

Грубо говоря, если позволяют каналы связи (на мой взгляд должны быть банальные >=100Мбит/с), то в LDAP каталоге добавляется пользователь, говорится где у него лежит HOME (схема autofs) - например на NFS сервере центра коллективного пользователя. Далее заходя по SSH пользователь авторизуется, ему монтируется его каталог и пусть себе считает.

В принципе, мы так и работаем. Каждый кластер имеет гигабитный свич для служебной сети, которые объединены линками.
У нас обее количество узлов 50, и особых проблем не возникает. Большинство задач основные объемы пишет на локальные
диски узлов.

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