[hpc-devel] HPC-CD.ISO

[Serge Ryabchun]

15.08.07, Alexander A. Naumov<alexander.naumov на t-platforms.ru> написал(а):
> Позволю себе изложить комментарии.
>
> --
> С уважением,
> Александр Наумов
> ООО "Т-Платформы"
> Тел.: (495)744-0995
> http://www.t-platforms.ru
> On Wed, Aug 15, 2007 at 01:20:03PM +0300, Serge Ryabchun wrote:
> > 15.08.07, Michael Shigorin<mike на osdn.org.ua> написал(а):
> > > > Да вообще, так было бы гораздо лучше. Но openvz на узлах имел
> > > > бы хоть какой то смысл ровно при одном условии - если бы openvz
> > > > умел виртуализировать infiniband. Без выполнения этого условия
> > > > мы просто на узлах имеем чуть более медленное ядро с лишней
> > > > функциональностью, а в generic kernel у нас замедлителей и так
> > > > хватает, хотя для начала можно и с одного с ovz-шного начать.
> > >
> > > Собственно, для начала надо что? -- считать.  Для этого вовсе
> > > необязательно виртуализовать.
> > >
> > > Ты бы рассказал, что именно в КПИ оно решает, а то ведь можно
> > > в частности и навороты залезть до того, как базовая система
> > > взлетит и сможет выполнять базовые задачи.
> >
> > Как раз в КПИ ovz и нету. ovz есть в ИнКиб-е. А решает как обычно - на одном
> > сервере доступа висят несколько VPS-ов для пользовательского доступа в 64-х
> > и 32-х битах для двух кластеров со своим окружением, VPS как фронтенд для
> > GEOSS, VPS как фронтенд для UAGRID и VPS как фронтенд для CERN. Ессейсно с
> > ограничениями какими только можно. Поэтому для узла управления openvz дает
> > приличный бонус. Иначе либо мешанина в одной системе либо дополнительные слегка
> > нагруженные сервера.
> >
> > Для вычислительных узлов без виртуализации infiniband ничего не дает.
> > С ней он тоже
> > может дать приличный бонус - для задачи выделяется виртуальный кластер на нужное
> > количество узлов и вуаля, фактически персональный кластер для задачи.
> > Для агрессивной среды, типа ВУЗ-ов, где каждый второй считает своим долгом
> > попробовать чего-нибудь поламать, было бы спасение, хотя время старта самой
> > задачи и увеличивается. Что характерно, административно это решается плохо,
> > всегда найдется любитель рискнуть ;-). Для более взрослой/серьезной аудитории
> > лишняя морока.
> > Второй момент - это гриды и задачи, которые туда попадают со всей планеты и черт
> > знает что они там делают кроме расчетов. И, к примеру, рядом досчитываются
> > харьковские задачи, за исходные данные для которых бимеры были готовы выложить
> > сумму с шестью нулями.
>
> Мне кажется, что заводить виртуальный кластер под каждую задачу - неэффективно.
> Можно просто выделять вычислительные узлы экслюзивно под задачу.

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

> Решение задачи про "любителя рискнуть" лежит _ИМЕННО_ в административной
> плоскости.

К сожалению, нет. Из-за потока этих задач, из-за доступности компилятора по
определению, из-за умения читать сообщения о свеженайденных дырах,
из-за задач, которые нельзя остановить ближайшие три месяца для затыкания
этих дыр (да дыры там в общем-то и не стараются затыкать - кластер с RedHat 7.1
я знаю где стоит), etc.

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

К сожалению, нет. Ошибку в конфигурации легко сделать и на локалхосте, а когда
этих хостов сотни, то она гарантирована.

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