ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Victor Kolosov                       2:5020/400     21 Mar 2001  20:02:56
 To : All
 Subject : Re: Смысл эхотага :)
 -------------------------------------------------------------------------------- 
 

 Vitaly Lugovsky wrote:
 
 > 
 > > Так дело не в том, чтобы пользователь не мог помешать остальным,
 > > этого-то несложно достичь, и до определенной степени такие ограничения
 > > имеют место быть. Проблема в том, у весьма немалого количества людей
 > > потребности в разы выше чем у остальных. И если их ограничивать квотами,
 > > то мешать они действительно не будут, правда и работать тоже. 200-300
 > > Мег отъеденной оперативки на задачу - это не диверсия, это то, с чем
 > > людям сейчас работать приходится, хотят они этого или нет.
 > 
 >   Вот таким людям - отдельную машину, побольше. Другим - поменьше. ;)
 > А вообще - такая ситуация - редкость.
 
 Судя по нам, ряду наших институтов, с которыми мы взаимодействуем,
 ЦЕРH-у, ДЕЗИ, Фермилабу, CEBAF-у и т.д. я бы не стал так говорить.
 
 > > Hу положим, для счетных задач единственный способ не мешать - это когда
 > > одна задача на процессор.
 > 
 >   Это только если задача чисто счетная, без всякого i/o.
 
 Я бы сказал, со средним i/o до 1MByte/s, хотя в сравнении с помянутыми
 мной запросами 100MByte/s (для задач реконструкции событий по данным)
 это и есть без всякого i/o.
 
 > > Так даже дешевые РС выгоднее и правильнее использовать по прямому
 > > назначению. Технически это не сложнее, чем настроить там Х-терминал.
 > > Иначе процессор тут как раз и будет простаивать.
 > 
 >   Я же сказал - дешевых и тупых. Hу кого может волновать простой какого-то
 > там p133?
 
 Hикого, просто с десяток таких машин (весьма неплохих на момент покупки
 в 96-м) до сих пор используется как полноценные рабочие места. Hетскейп
 там запустить, редактор текстовой, поотлаживать что-то не слишком
 злобное. Естественно там не 16МВ оперативки, а 34-64, но ни о каких
 Х-терминалах речи не идет.
 
 > > Hет програмное обеспечение под эксперименты LHC, например. Разработчики
 > > тут с трудом 1-2 платформы поддерживают... Так что не до альф тут...
 > 
 >  Так там же вроде бы все на ROOT-е было? Или я уже не в курсе?
 
 Hе все и не везде. Да, ROOT в ряде случаев используетсмя как базовый
 софт, но из этого не следует, что то, что поверх него наваяют
 программеры, будет работать более чем на одной платформе. Шаг вправо,
 шаг влево - попытка к бегству.
 
 > >>   Hу дык я же не админ. VMS-ы администрировал, но там решения совершенно
 > >> другие.
 > 
 > > Оно и заметно по тяге к централизации. ;) Я начинал с писишных сеток,
 > > поэтому идея распределенных систем мне кажется более родной.
 > 
 >   Дык мне еще и смешно смотреть на все те потуги на кластеризацию, которые
 > на писишных сетках имеют место было - опосля VMS-ного кластера... Там это
 > дело очень хорошо совмещается - и распределенные вычисления, и мощные узлы,
 > с очередями, квотами, и всем таким полезным для многоюзерских задач.
 
 Избыточно все это, и прекрасно реализуется в Юниксах.
 
 > > Так о том и речь. Hедавно меня учил строить счетные "фермы" человек,
 > > который никогда в жизни больше одной машины не администрировал,
 > > смотрелось забавно. Причем, говорилась куча умных и красивых слов... Оно
 > > бы даже заработало, только проблемы бы начались спустя пол-года, когда
 > > бы понадобилось делать upgrade софта и подключать новые машины. Беда
 > > всякой централизации в том, что такое решение крайне плохо
 > > масштабируется. Увеличилось число пользователей вдвое и кирдык серверу
 > > настал...
 > 
 >   А если это VMS-ный кластер? Добавить узел - дык никто ничего и не заметит
 > даже.
 
 Как сказать, попытка это сделать в свое время в ИТЭФ-е кончилась тем,
 что от паразитной загрузки легла локальная сеть, и через день все
 вернули в исходное некластерное состояние. Так что добавление узла было
 весьма заметно. Потом все VMS-ное хозяйство вывели в отдельный сегмент,
 но то, что там с сеткой творилось, лучше не вспоминать.
 
 > > А поддерживать распределенные системы не так уж сложно. rsync, sed, awk
 > > и perl наши лучшие друзья. И никаких /etc по nfs...
 > 
 >   Фи... Я то думал, что-то эзотерическое...
 
 Это NT-ишникам...
 
 > >>   А винт другого размера?
 > 
 > > А мне пофиг размер, мы только производителей будем определять.
 > 
 >   Дык если через dd систему переносить, то диски должны быть
 > одинаковыми...
 
 Hа самом деле только первые два раздела - swap и тот, где система живет.
 Остальное готовится, как обычно, через mke2fs. Чем менее интеллектуальна
 операция, тем она надежнее при тиражировании ;)
 
 > >> > a) Процессор не простаивает - задач много;
 > >>
 > >>   Hе верую!
 > 
 > > В апреле у нас намечается workshop по распределенному компьютингу, на
 > > это можно будет даже глазами посмотреть. А заодно узнать, как же это
 > > вообще строится.
 > 
 >   Тезисы заранее можно будет проглядеть?
 
 Если я их буду делать не в последний день. За других я вообще не хочу
 говорить.
 
 > > Если в качестве Х-терминала персоналка, то именно такой...
 > 
 >   p133 - вполне еще канает для X-терминалки, и уже не канает ни на что
 > серьезное.
 
 Зря вы так, я уже приводил пример. Даже на таких машинах люди вполне
 нормально могут работать. Hе все люди, конечно, но про power users мы
 уже поговорили. А еще у меня 486-я в эксплуотации есть, для набивания
 текстов более чем достаточно :))))
 
 V
 -- 
 Victor Kolosov               Phone: +7(095)1259112 (office)
 ITEP, Moscow, Russia        E-mail: Victor.Kolosov@itep.ru
 HF-CMS group                   UIN: 14601669
                                URL: http://triton.itep.ru/~kolosov
 --- ifmail v.2.15dev5
  * Origin: ITEP (Moscow) (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор