[hpc-devel] Q: обновление узлов

[Michael Shigorin]

On Wed, Sep 12, 2007 at 11:48:18AM +0600, Constantin Mikhaylenko wrote:
> Вообще-то регулярные обновления, а тем более dist-upgrade на
> боевом кластере -- это из разряда мазохизма.

Я так понимаю, речь шла даже не о публичных updates, а о том, что:
- создано/отобрано и проверено администратором/оператором;
- устанавливается по какому-либо из событий или признаков,
  определённых администратором.

On Wed, Sep 12, 2007 at 11:28:03AM +0400, Alexander A. Naumov wrote:
> 2) Автоматический апдейт делать нецелесообразно, а вот сделать
> апдейт группы узлов по команде администратора надо. Еще я бы
> добавил контроль апдейтов на разных узлах, чтобы администратору
> было наглядно видно, какие узлы поапдейчены, а какие нет.

В порядке бреда (когда-то у меня дома так запускались cronjobs
вроде updatedb и makewhatis -- подбирая моменты, когда система
не занята): триггерить обновление по условию отсутствия нагрузки
на CPU/IO в течение некоего интервала времени?

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

Применимость подобного в додуманном виде сильно зависит от:
- распределения обязанностей и опыта между операторами;
- предполагаемого источника обновлений;
- (не)желательности обновления при первой возможности.

On Wed, Sep 12, 2007 at 02:21:13PM +0300, Serge Ryabchun wrote:
> Мы везде используем третий вариант и он зарекомендовал себя
> лучше всего - root на NFS. Узел достаточно быстро кеширует у
> себя все основные данные.  Обновление только в одном месте и
> тут же становит доступно всем. Причем обновлять можно как с
> узла управления так и с любого свободного узла.

Так у тебя сторадж вменяемый и потому получается сэкономить,
используя stateless linux вместо задачи администрирования
N систем.  А тут люди грузятся с локальных дисков и попадают
на весь концерт с их состоянием.

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

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/