openMosix и htb|cbq+iptables

И ты вовершенно верно уверен! Действительно, само ПО должно быть приспособленно к функционированию в подобных кластерных вычислительных средах. Ну ты сам понимаешь? Распаралеливание вычислительных процессов и так далее.. Сильно сомневаюсь, что твой шейпер к этому адаптирован. Судя по всему, как иначе балансировать нагрузку ты и сам не хуже меня знаешь. Так что, как вариант, могу предложить замутить проэкт по адаптации шейпера к определённым потребностям..

В том то и дело что openMosix не требует адаптации кода ПО, потому и задумался о возможности реализации. Но с другой стороны, мигрировать процессу это все просто это всего лишь pid но то что мне недо это уже ядро.... вот потому и закрались сомнения.

Вот что умеет мосикс.

Determine how much information about processes is disclosed by default when they run as guests on remote nodes: 0 = no information 1 = only PID (and TGID if different) 2 = PID(/TGID), UID, GID 3 = PID(/TGID), UID, GID, PGRP, SESSION, COMMAND Processes may modify this default by writing to /proc/self/disclosure.

Есть ли еще какая возможность реализовать мою задачу не покупая еще пачку серверов ? :)

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

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

Давай, если что, держи связь - aleksei<@>tallpost.ee! ;-)

в доках на опенмосик есть описания приложений которые мигрирую и которые не мигрируют.... в принцепе я так понял сетевые процесы типа apache mysql и прочего не мигрируют, "математические" приложения типа gcc и прочего мигрируют... (могу сильно ошибаться)

я думаю вы в чем то правы в чем то нет, но в любом случаее в моём варианте ответ спорный и скорее отрицательный