На самом деле всё началось с проекта Mosix, который и стал впоследствии openMosix. И, как мне кажется, openMosix намного интереснее и привлекательнее своего родителя не с технической точки зрения, а скорее из-за более соответствующей ему лицензии. В данном HOWTO я сосредоточу своё внимание именно на openMosix, а не на Mosix, по той простой причине, что у первого намного больше пользователей и разработчиков. (Moshe Bar утверждает, что на openMosix перешло около 97% бывших пользователей Mosix). Учитывая всё вышесказанное, я решил разделить HOWTO. Последняя версия Mosix-HOWTO будет иметь номер 0.20. Моё личное стремление – это сосредоточиться на openMosix-HOWTO, в то же время не забывая и о пользователях Mosix. Более подробная информация здесь http://howto.ipng.be/Mosix-HOWTO/.

В данном документе приводится краткое описание openMosix, программы, позволяющей превратить компьютеры под управлением GNU/Linux в компьютерный кластер. Также вкратце рассказано о параллельных вычислениях вообще, и приведён небольшой обзор приложений, которые можно использовать максимально эффективно в системе openMosix. Помимо этого в HOWTO можно найти описание особенностей работы openMosix в различных дистрибутивах.

С момента создания данного HOWTO многие разработчики Mosix переключились на openMosix (читайте об этом более подробно далее), так что часть информации в нём касается в равной степени и openMosix, и Mosix. Ввиду этого я решил разделить информацию о двух системах. Последний релиз Mosix HOWTO, содержащий информацию сразу о двух проектах, имеет версию 0.20, а найти его можно по этому адресу http://howto.ipng.be/Mosix-HOWTO/Mosix-HOWTO/.

Kris Buytaert подключился к этому документу в феврале 2002 года по просьбе Scot'a Stevenson'a, и хотя мы обсуждали и Mosix, и openMosix, данный HOWTO касается в основном openMosix. Так что учтите, пожалуйста, что здесь и далее под Mosix надо понимать openMosix.

Вы, наверное, заметили, что некоторые заголовки звучат не так серьёзно, как должны бы. Дело в том, что Scot планировал написать данный HOWTO в лёгком стиле, потому что в мире (даже в той части мира, где талисманом служит рыгающий пингвин) и так полно скучной технической литературы. Поэтому кое-где в тексте вы можете встретить подобные комментарии.

Вы можете использовать информацию из этого документа только на свой собственный страх и риск. Я снимаю с себя всю возможную ответственность за содержание документа. Любые изложенные здесь концепции, примеры и любая другая информация может быть использована только под вашу ответственность.

Все авторские права принадлежат их соответствующим владельцам, в случае если это не указано отдельно. Использование терминов в данном документе не должно рассматриваться как посягательство на законность торгового или служебного знака. Авторское право на openMosix принадлежит Moshe Bar (Copyright © 2002 by Moshe Bar). Авторское право на Mosix принадлежит Amnon Barak (Copyright © 2002 by Amnon Barak). Linux™ является зарегистрированным торговым знаком Linus'a Torvalds'a. openMosix распространяется под лицензией GNU General Public License version 2, опубликованной организацией Free Software Foundation.

Упоминание определённых продуктов или изготовителей не должно рассматриваться как одобрение.

Перед тем, как начать установку системы, настоятельно рекомендуется сделать резервную копию системы.

Copyright © 2002 by Kris Buytaert and Scot W. Stevenson. Данный документ распространяется на условиях GNU Free Documentation License, Version 1.1 и более поздних версиях данной лицензии, опубликованных организацией Free Software Foundation. Текст этой лицензии есть в приложении Перевод на русский язык лицензии gnu на свободную документацию.

Официальные новые версии документа можно найти на страницах the Linux Documentation Project. Черновики и бета-версии доступны по адресу howto.ipng.be в соответствующем подкаталоге. Изменения в данный документ предварительно обсуждаются в Списках Рассылки openMosix. Подробнее об этом смотрите здесь openMosix.

В настоящее время документ поддерживает Kris Buytaert, так что, пожалуйста, шлите все ваши замечания и дополнения на его адрес.

Если у вас есть технический вопрос именно по openMosix/Mosix, то задайте его в соответствующем списке рассылки.

Большую часть времени ваш компьютер не загружен. Запустите утилиты типа xload или top, которые показывают загруженность системы, и вы увидите, что загрузка процессора может даже не превышать значения 1.0. А если у вас два компьютера, то вероятность того, что в один момент времени один из них ничем не занят, существенно возрастает. К сожалению, когда вам действительно нужна вся мощь процессора – будь то компиляция программ на С++ или кодирование файлов Ogg Vorbis, – то она нужна вам в максимально короткое время. Основной задачей кластера и является распределение этой нагрузки на все доступные компьютеры и их свободные ресурсы.

Составной единицей кластера является один компьютер, также именуемый как “узел” (node). Кластеры также можно наращивать путём добавления новых машин. Чем мощнее составляющие кластер единицы, и чем быстрее соединение между ними, тем мощнее будет и весь кластер в целом. Помимо этого, и операционная система кластера должна максимально эффективно использовать имеющееся в кластере оборудование. Особенно это требование необходимо в гетерогенных кластерах, т.е. составные единицы которого не идентичны. Ещё одним важным аспектом является устойчивость к непредсказуемой смене конфигурации (например, когда в кластер добавляются/удаляются новые машины), и следующей из этого непредсказуемой нагрузки.

openMosix кластеры могут приобретать самую разную форму. Чтобы лучше себе это представить, давайте предположим что вы – студент, и живёте в одной комнате с богатым компьютерщиком, с которым вы объединили свои компьютеры в openMosix кластер. Теперь давайте предположим, что вы сейчас конвертируете музыку с компакт-дисков в файлы Ogg Vorbis, что вполне легально в вашей стране. Ваш сожитель работaет над проектом на С++, который, по его словам, принесёт мир во всём мире. Но в данный момент он в ванной, где занимается непонятными вещами, а его компьютер простаивает.

Итак, вы запускаете программу, скажем, bladeenc, чтобы сконвертировать творения Баха из формата .wav в .ogg. Алгоритм openMosix на вашей машине сравнивает загрузку на обоих узлах и решает, что процесс будет выполняться быстрее, если его отправить с вашего Pentium-233 на соседний Athlon XP. Всё это происходит автоматически: вы выполняете команды как на обычном персональном компьютере. Всё, что вы заметите, это, например, когда вы запустите сразу две задачи, то они будут работать быстрее, а время их ответа не затянется надолго.

Итак, пока вы что-то там набираете на клавиатуре, ваш сожитель возвращается, бормоча что-то про красный перец в кафетерии. Он садится за свой компьютер и продолжает свои тесты, используя при этом программу pmake – версию make, только оптимизированную для параллельного выполнения. В общем, он так загрузил ей свой процессор, что openMosix даже начал посылать подпроцессы на вашу машину для балансировки нагрузки.

Подобная конфигурация кластера называется “single-pool” (единый пул): в ней все компьютеры используются как единый кластер. Преимуществом или недостатком такой конфигурации, исходя из обстановки, является то, что ваш компьютер – часть пула, то есть, ваши задачи выполняются на других машинах, хотя и процессы с других машин будут мигрировать на вашу машину тоже. О других конфигурациях подробнее читайте в главе Планирование вашего кластера.

В целях поддержки openMosix Major Chai Mee Joon предоставляет всем пользователям openMosix тестовую учётную запись в своём openMosix кластере, под которой они могут поэкспериментировать и проверить openMosix в действии.

Такая служба поможет новым пользователям в решении проблем настройки кластера, а также окажется полезной тем, кто разрабатывает или портирует приложения для openMosix.

Получить имя пользователя и пароль для работы с этим кластером можно отправив письмо по адресу: <[email protected]>

Для начальной инсталляции кластера необходимо как минимум 2 соединённые сетью машины, использующие либо кросс-кабель между двумя сетевыми карточками или использующие коммутатор (switch) или концентратор (hub) (хотя коммутатор намного лучше концентратора, и стоит он всего на несколько баксов больше). Конечно же, чем быстрее ваши сетевые карточки, тем проще будет вам получить лучшую производительность от вашего кластера.

В наши дни Fast Ethernet (100 Мб/с) является стандартом; установка нескольких портов в машину не является уж очень трудным делом, но убедитесь, что вы подключили их к различным физическим сетям для получения желаемой скорости. Gigabit Ethernet с каждым днём становится всё дешевле, но я не советую вам спешить в магазин и тратить свои деньги, прежде чем вы протестировали вашу конфигурацию с несколькими 100 Мбит карточками и заметили, что вам действительно нужна дополнительная пропускная способность сети. После установки гигабитной карточки вам также, наверное, захочется соединить несколько 100 Мбит карточек вместе (см. главу Простое соединение каналов (Channel Bonding)). И даже более дешёвой альтернативой может оказаться Firewire, как обсуждается в главе openMosix и FireWire.

Установка большого кластера требует некоторых размышлений: где вы собираетесь разместить машины? Не где-нибудь под столом или в центре вашего офиса, я надеюсь! Это нормально, если вы хотите провести несколько маленьких тестов, но если вы хотите развернуть кластер из N узлов, вам нужно будет убедиться, что окружение, которое будет содержать эти машины, приспособлено к этому.

Я говорю о приготовлении одной или нескольких 19-ти дюймовых стоек (19" racks) для того, чтобы содержать эти машины, конфигурировании соответствующей сетевой топологии, либо прямой, прямо соединённой или даже 1-к-1 кросс-соединённой сети между всеми узлами. Вам также необходимо убедиться, что у вас есть достаточно энергии, чтобы запитать такую группу машин, что ваша воздушная кондиционерная система выдерживает нагрузку, и что в случае сбоя в питании ваши UPS могут правильно остановить все требуемые системы. Возможно, вам захочется вложить деньги в КВМ (Клавиатура, Видео, Мышка) коммутатор, чтобы легко получать доступ к терминалам машин.

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

Для системы, которую мы планируем использовать, необходима базовая инсталляция Linux на ваш выбор: RedHat, SuSE, Debian, Gentoo или любой другой дистрибутив, – на самом деле не важно, какой именно. Что имеет значение, так это версия ядра Linux как минимум 2.4 и правильно сконфигурированные сетевые карточки. После этого вам необходимо значительное пространство для свопа.

Когда наступит время конфигурировать кластер openMosix с пулом серверов и множеством (персональных) рабочих станций, у вас будет несколько вариантов, каждый из которых имеет свои преимущества и недостатки.

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

В этой главе обсуждается инсталляция openMosix на различных дистрибутивах. Это не будет список всех возможных комбинаций. Тем не менее в этой главе вы найдёте достаточно информации для инсталляции openMosix в вашем окружении.

Методы инсталляции нескольких машин с openMosix будут обсуждаться в главе Инсталляция кластера.

Прежде всего, вы должны понимать, что openMosix состоит из патча к ядру Linux и нескольких утилит пространства пользователя. Патч на ядро необходим, чтобы позволить ядру общаться с другими openMosix машинами в сети. Если вы скачаете openMosix как двоичный пакет (например, как файл .rpm), вам даже не нужно беспокоиться о патче на ядро, потому что ядро уже пропатчено и скомпилировано для вас с наиболее общими опциями и модулями по-умолчанию.

Пользовательские утилиты нужны для эффективного использования ядра openMosix. Они нужны для запуска/остановки демона миграции, файловой системы openMosix (MFS), для миграции задач на определённые узлы, а не на любые, и других задач, которые обычно достигаются при помощи старого доброго друга: интерфейса командной строки. Что касается двоичных пакетов, то же самое, что и для патча ядра, имеет место и для пользовательских утилит: если вы инсталлируете .rpm, вы не должны беспокоиться об их компиляции или конфигурировании чего-либо; просто проинсталлируйте и запускайте. Это всё. На самом деле :)

Как только вы попадёте на страницу закачки (о которой я поговорю во-вторых), вам нужно получить две отдельные части: ядро и пользовательские утилиты. Вы можете скачать два двоичных пакета или получить патч на ядро плюс исходники пользовательских утилит. Патч на ядро обычно называется согласно следующей схеме: openMosix-x.y.z-w, где x.y.z – версия оригинального ядра Linux, на которое должен быть наложен этот патч, а w – это ревизия патча для этого конкретного релиза ядра. Для прекомпилированных двоичных ядер, пожалуйста, обратитесь к файлу README-openMosix-kernel.txt, который вы найдёте на странице закачки. Этот файл также содержит обновлённую информацию для самостоятельной компиляции ядра.

О пользовательских утилитах: вы их найдёте в пакете, который называется openmosix-tools. Мы будем использовать термины “утилиты пространства пользователя”, “пользовательские утилиты”, “утилиты openMosix” взаимозаменяемым образом. Заметим, что с версии 0.3 пользовательских утилит файл /etc/openmosix.map считается устаревшим, и очень поощряется использование демона автообнаружения omdiscd, так как он заботится о том, чтобы сделать вашу жизнь легче.

Вы можете скачать последние версии openMosix с http://sourceforge.net/project/showfiles.php?group_id=46729. Вы можете выбрать двоичный файл (даже в .rpm), скомпилированный для однопроцессорных (UP) или мультипроцессорных (SMP) систем. В качестве альтернативы вы можете получить версию из CVS:

cvs -d:pserver:[email protected]:/cvsroot/openmosix login
cvs -z3 -d:pserver:[email protected]:/cvsroot/openmosix co linux-openmosix
cvs -z3 -d:pserver:[email protected]:/cvsroot/openmosix co userspace-tools

При приглашении ввести пароль просто нажмите “ввод”, так как вы используете анонимный доступ. Пожалуйста, имейте в виду, что дерево CVS может быть нерабочим сейчас или потом, и что это, может быть, не самый простой способ проинсталлировать openMosix ;-)

Если вы используете RedHat версий 7.2, 7.3 или 8.0, то это, вероятно, самая лёгкая инсталляция *Mosix, которую вы когда-либо производили. Выберете соответствующие .rpm openMosix с sourceforge.net Они содержат прекомпилированные ядра (на время написания этого – 2.4.20), которые работают без заминки: я протестировал их на нескольких машинах, включая лаптопы с карточками PCMCIA, и на серверах с SCSI дисками. Если вы – пользователь grub, .rpm с ядром даже модифицирует ваш grub.conf. Итак, всё, что вам нужно, – это проинсталлировать две .rpm:

rpm -Uvh openmosix-kernel-2.4.20-openmosix2.i686.rpm openmosix-tools-0.2.4-1.i386.rpm

и отредактировать ваш /etc/openmosix.map, если вы не используете демон автообнаружения omdiscd.

Так так выяснилось, что это является проблемой для многих людей, давайте рассмотрим другой пример. Скажем, у вас есть 3 машины: 192.168.10.220, 192.168.10.78 и 192.168.10.84. Ваш /etc/openmosix.map будет выглядеть, например, так:

[root@oscar0 root]# more /etc/openmosix.map
# openMosix CONFIGURATION
# ===================
#
# Each line should contain 3 fields, mapping IP addresses to openMosix node-numbers:
# 1) first openMosix node-number in range.
# 2) IP address of the above node (or node-name from /etc/hosts).
# 3) number of nodes in this range.
#
# Example: 10 machines with IP 192.168.1.50 - 192.168.1.59
# 1	 192.168.1.50	 10
#
# openMosix-# IP number-of-nodes
# ============================
1 192.168.10.220 1
2 192.168.10.78 1
3 192.168.10.84 1

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

В большинстве инсталляций RedHat есть ещё одна вещь для исправления. Вы часто получаете следующую ошибку:

[root@inspon root]# /etc/init.d/openmosix start
Initializing openMosix...
setpe: the supplied table is well-formatted,
but my IP address (127.0.0.1) is not there!

Это значит, что имя вашего хоста не перечислено в /etc/hosts с тем же IP-адресом, как и в вашем /etc/openmosix.map. Возможно, машина, которая называется omosix1.localhost.org, перечислена в /etc/openmosix.map как:

127.0.0.1	omosix1.localhost.org localhost

Если вы измените ваш /etc/hosts так, чтобы он выглядел как далее, у openMosix будет меньше проблем при старте:

192.168.10.78 omosix1.localhost.org
127.0.0.1 localhost

[root@inspon root]# /etc/init.d/openmosix start
Initializing openMosix...
[root@inspon root]# /etc/init.d/openmosix status
This is openMosix node #2
Network protocol: 2 (AF_INET)
openMosix range 1-1 begins at 192.168.10.220
openMosix range 2-2 begins at inspon.localhost.be
openMosix range 3-3 begins at 192.168.10.84
Total configured: 3

Если вы хотите использовать ещё больше кровопролитных патчей, вы всегда можете воспользоваться в качестве альтернативы .srpm и выполнить для него rpmbuild --rebuild. Это проинсталлирует для вас исходники и создаст начальный конфигурационный файл. Начиная с этого момента вы можете наложить патчи на openMosix.

Пособие по тому, как построить свои .rpm openMosix, может быть найдено в приложении Как сделать .rpm пакеты ядра openMosix.

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

Хотя RPM компилируются в окружении, основанном на RedHat, вы можете использовать большинство из них на других системах, основанных на RPM.

В SuSE, тем не менее, /sbin/mk_initrd является символической ссылкой на /sbin/mkinitrd, что приводило к ошибке при установке .rpm до версии 20-2. В новых версиях это должно быть исправлено.

Инсталлирование openMosix “дебиановским способом” легко может быть выполнено, как описано ниже.

Первый шаг состоит в скачивании пакетов из Интернет. Я вынужден был использовать ядро 2.4.19, так как пакеты с патчами openMosix не были готовы для 2.4.20 к тому моменту, когда я это писал. Так как мы используем установку для Debian, то нам нужны: http://packages.debian.org/unstable/net/openmosix.html, http://packages.debian.org/unstable/net/kernel-patch-openmosix.html, http://packages.debian.org/unstable/misc/kernel-package.html, http://packages.debian.org/unstable/devel/kernel-source-2.4.19.html. Вы также можете их apt-get install ;).

Следующей частью является добавление в ядро кластерных возможностей openMosix.

В основном, процедура, которую необходимо придерживаться, следующая:

cd /usr/src
apt-get install kernel-source-2.4.19 kernel-package \
 openmosix kernel-patch-openmosix
tar vxjf kernel-source-2.4.19.tar.bz2
ln -s /usr/src/kernel-source-2.4.19 /usr/src/linux
cd /usr/src/linux
../kernel-patches/i386/apply/openmosix
make menuconfig
make-kpkg kernel_image modules_image
cd ..
dpkg -i kernel-image-*-openmosix-*.deb

Сейчас вам необходимо будет отредактировать свой /etc/openmosix.map. Пожалуйста, следуйте инструкциям, изложенным в главе Синтаксис файла /etc/openmosix.map.

После перезагрузки с этим ядром и сконфигурированным /etc/openmosix.map, вы должны будете получить кластер из машин openMosix, которые общаются друг с другом, и в ходе этого процессы мигрируют.

Вы можете протестировать это, выполнив следующий маленький скрипт

awk 'BEGIN {for(i=0;i<10000;i++)for(j=0;j<10000;j++);}'

пару раз и наблюдайте его поведение при помощи mosmon, где вы увидите, что он распределяет нагрузку между различными узлами.

Мы также проинсталлируем openMosixView на машине Debian:

apt-get install openmosixview

Для того, чтобы получить возможность действительно воспользоваться openMosixView, вам необходимо будет запустить его от имени пользователя, который может заходить на различные узлы как root. Мы предлагаем вам установить это при помощи SSH. Пожалуйста учтите, что существует разница между реализациями SSH и SSH2. Если у вас есть файл identity.pub, ssh проверит authorized_keys, в то время, как если у вас есть id_dsa.pub, вам понадобится authorized_keys2!

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

Сперва проинсталлируйте Gentoo для Linux.

Затем проинсталлируйте openMosix: наберите emerge sys-apps/openmosix-user, что проинсталлирует исходные коды ядра openMosix в /usr/src/linux вместе с пользовательскими утилитами openMosix.

Майкл Имхоф (Michael Imhof), также известный как tantive, поддерживает Gentoo в соответствии с последней версией openMosix.

Даниел Робинс (Daniel Robbins), президент/генеральный директор Gentoo Technologies, Inc. и создатель Gentoo для Linux, написал статьи, которые мы используем как наше введение в кластеры openMosix.

Основываясь на вышесказанных объяснениях, у вас должно получиться проинсталлировать openMosix на большинстве других Linux платформах.

Демон автообнаружения (omdiscd) предоставляет способ автоматически конфигурировать кластер openMosix, а следовательно, избавляет от необходимости ручного конфигурирования /etc/openmosix.map или вроде него. Автообнаружение использует широковещательные (multicast) пакеты для уведомления других узлов, что это есть узел openMosix. Согласно этому способу, добавление дополнительного узла в ваш кластер значит, что вы всего лишь должны запустить omdiscd на вашей машине, и она присоединится к кластеру.

Тем не менее, есть некоторые небольшие требования: как и для любого кластера openMosix вы должны иметь правильно сконфигурированную сеть, главным образом маршрутизацию. Без маршрута по-умолчанию вы должны задать omdiscd интерфейс при помощи опции -i. В противном случае omdiscd завершит работу с ошибкой, как например:

Aug 31 20:41:49 localhost omdiscd[1290]: Unable to determine address of default interface.
                This may happen because there is no default route configured. Without a
                default route, an interface must be: Network is unreachable 
Aug 31 20:41:49 localhost omdiscd[1290]: Unable to initialize network. Exiting. 

Пример правильной таблицы маршрутов ниже:

[root@localhost log]# route -n 
Kernel IP routing table
Destination	Gateway		Genmask		Flags	Metric	Ref	Use	Iface
10.0.0.0	0.0.0.0		255.0.0.0	U	0	0	0	eth0
127.0.0.0	0.0.0.0		255.0.0.0	U	0	0	0	lo
0.0.0.0		10.0.0.99	0.0.0.0		UG	0	0	0	eth0

Главным образом с настоящего момента всё станет проще. Всего лишь запустите:

omdiscd

и взгляните на ваши лог-файлы, в которых вы должны увидеть что-то похожее на это:

Sep 2 10:00:49 oscar0 kernel: openMosix configuration changed: This is openMosix #2780 (of 6 configured)
Sep 2 10:00:49 oscar0 kernel: openMosix #2780 is at IP address 192.168.10.220
Sep 2 10:00:49 oscar0 kernel: openMosix #2638 is at IP address 192.168.10.78
Sep 2 10:00:49 oscar0 kernel: openMosix #2646 is at IP address 192.168.10.86
Sep 2 10:00:49 oscar0 kernel: openMosix #2627 is at IP address 192.168.10.67
Sep 2 10:00:49 oscar0 kernel: openMosix #2634 is at IP address 192.168.10.74

Поздравляем, ваш кластер openMosix сейчас работает.

У omdiscd есть некоторые другие опции, которые вы можете использовать. Вы можете запустить omdiscd как демон (по-умолчанию) или в обычном режиме, когда весь вывод идёт на экран (стандартный вывод):

omdiscd -n

Интерфейс может быть задан с помощью опции -i:

omdiscd -i eth0

Теперь давайте всё же глянем на другую утилиту – showmap. Эта утилита покажет вам наиболее последнюю автосгенерированную карту openMosix.

[root@oscar0 root]# showmap
My Node-Id: 0x0adc

Base Node-Id	Address			Count
------------	----------------	-----
0x0adc		192.168.10.220		1
0x0a4e		192.168.10.78		1
0x0a56		192.168.10.86		1
0x0a43		192.168.10.67		1
0x0a4a		192.168.10.74		1

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

Самые недавние версии rc-скриптов openMosix в первую очередь проверяют, существует ли файл /etc/openmosix.map или похожий, перед попыткой использовать автоконфигурацию.

Если вы компилируете автообнаружение из исходников, вам необходимо будет внести небольшое изменение в openmosix.c. Одной из первых строчек будет:

#define ALPHA

Вам необходимо будет это закомментировать. Если вы хотите получить дополнительную отладочную информацию, вы должны отредактировать файл main.c где-то в районе 84 строки:

log_set_debug(DEBUG_TRACE_ALL);

Теперь выполните:

% make clean
% make

Иногда, однако, автообнаружение не работает так, как вам бы хотелось, например, узел не может видеть широковещательный трафик с других узлов. Это может случиться с некоторыми драйверами ethernet для PCMCIA. Одним из решений является переключить интерфейс в неразборчивый и/или широковещательный режим, как подробно описано ниже:

Aug 31 20:45:58 localhost kernel: openMosix configuration changed: This is openMosix #98 (of 1 configured)
Aug 31 20:45:58 localhost kernel: openMosix #98 is at IP address 10.0.0.98
Aug 31 20:45:58 localhost omdiscd[1627]: Notified kernel to activate openMosix
Aug 31 20:45:58 localhost kernel: Received an unauthorized information request from 10.0.0.99

Что вы должны после этого попытаться сделать – это перевести ваш NIC в неразборчивый и/или широковещательный режим вручную.

ifconfig eth0 promisc

или

ifconfig eth0 multicast 

Вы также возможно захотите выполнить:

tcpdump -i eth0 ether multicast 

что приведёт к тому же эффекту, но вы теперь также сможете увидеть пакеты сами.

На некоторых коммутаторах 3-го уровня может потребоваться дополнительное конфигурирование. Пользователь openMosix выяснил, что для его коммутатора Summit48Si (Extreme Networks) он должен был выполнить:

disable ipmcforwarding	# для дизактивации маршрутизации широковещательных пакетов
disable igmp snooping

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

Aug 31 22:14:43 inspon omdiscd[1422]: Simulated notification to activate openMosix

[root@inspon root]# showmap
My Node-Id: 0x0063

Base Node-Id	Address			Count
------------	----------------	-----
0x0063		10.0.0.99		1

[root@inspon root]# /etc/init.d/openmosix status
OpenMosix is currently disabled

Если вы увидите simulated, то вы, вероятно, забыли закомментировать:

#define ALPHA

Я заметил, что автообнаружение не работает с сетевыми карточками FireWire.

Эта глава не имеет отношение к инсталляции openMosix как такового, она, тем не менее, имеет отношение к инсталляции нескольких машин с openMosix. Автоматические или полуавтоматические массовые инсталляции.

На время написания (Май 2003) наиболее последняя версия DSH доступна с http://www.netfort.gr.jp/~dancer/software/downloads/. Больше дополнительной информации о пакете может быть найдено на http://www.netfort.gr.jp/~dancer/software/dsh.html. Последняя доступная для скачивания версия 0.23.6. Вам так же понадобятся libdshconfig-0.20.8.tar.gz и dsh-0.23.5.tar.gz. Начнём с инсталляции libdshconfig:

./configure
make
make install

Повторите процесс для пакета dsh.

Скажем, у нас есть небольшой кластер с парой узлов. Для того, чтобы сделать жизнь проще, мы хотим набрать команду только один раз, но чтобы она была выполнена на каждом узле. Для этого вы должны создать файл $HOME/.dsh/group/clusterwname, в котором перечислены IP-адреса узлов вашего кластера. Например:

[root@inspon root]# cat ~/.dsh/group/mosix
192.168.10.220
192.168.10.84

Для примера мы выполним ls на каждой из этих машин. Мы задействуем -g для использования групп Mosix (таким образом, вы можете создать подмножества групп с различными конфигурациями).

[root@inspon root]# dsh -r ssh -g mosix ls
192.168.10.84: anaconda-ks.cfg
192.168.10.84: id_rsa.pub
192.168.10.84: install.log
192.168.10.84: install.log.syslog
192.168.10.84: openmosix-kernel-2.4.17-openmosix1.i686.rpm
192.168.10.84: openmosix-tools-0.2.0-1.i386.rpm
192.168.10.220: anaconda-ks.cfg
192.168.10.220: id_dsa.pub
192.168.10.220: id_rsa.pub
192.168.10.220: openmosix-kernel-2.4.17-openmosix1.i686.rpm
192.168.10.220: openmosix-tools-0.2.0-1.i386.rpm
192.168.10.220: oscar-1.2.1rh72
192.168.10.220: oscar-1.2.1rh72.tar.gz

Заметьте, что ни одна из машин не спросила пароля. Это потому что мы установили RSA аутентификацию для различных учётных записей. Если вам нужно выполнить команды с различными параметрами, вам нужно будет или заключить команды в кавычки:

[root@inspon root]# dsh -r ssh -g mosix "uname -a"
192.168.10.84: Linux omosix2.office.be.stone-it.com 2.4.17-openmosix1 #1 Wed May 29 14:32:28 CEST 2002 i686 unknown
192.168.10.220: Linux oscar0 2.4.17-openmosix1 #1 Wed May 29 14:32:28 CEST 2002 i686 unknown

или использовать опцию -c. Оба способа выдают практически то же самое на экран:

[root@inspon root]# dsh -r ssh -g mosix -c -- uname -a
192.168.10.220: Linux oscar0 2.4.17-openmosix1 #1 Wed May 29 14:32:28 CEST 2002 i686 unknown
192.168.10.84: Linux omosix2.office.be.stone-it.com 2.4.17-openmosix1 #1 Wed May 29 14:32:28 CEST 2002 i686 unknown

openMosix позволяет получить преимущество от миграции процессов HPC-приложений. Администратор может сконфигурировать openMosix-кластер при помощи пакета openMosix-user-space-tools или интерфейса /proc/hpc, который будет подробно описан в главе Пользовательские утилиты.

Вплоть до версии openMosix 2.4.16 /proc интерфейс назывался /proc/mosix! Начиная с версии 2.4.17 он называется /proc/hpc.

Значения в текстовых файлах в каталоге /proc/hpc/admin отражают текущую конфигурацию кластера. Естественно, что администратор может записать свои собственные значения в эти файлы в процессе работы, например, такими командами:

…

Перечисленные ниже утилиты облегчают процесс администрирования кластеров openMosix.

migrate	-	отправляет запрос на миграцию процесса
		синтаксис:
		migrate [PID] [openMosix_ID]

mon	-	это терминальный монитор, основанный на библиотеке ncurses, который
		отображает текущее состояние кластера в виде гистограмм

mosctl	-	основная конфигурационная утилита openMosix
		синтаксис:
		mosctl	[stay|nostay]
			[lstay|nolstay]
			[block|noblock]
			[quiet|noquiet]
			[nomfs|mfs]
			[expel|bring]
			[gettune|getyard|getdecay]

		mosctl	whois [openMosix_ID|IP-address|hostname]

		mosctl	[getload|getspeed|status|isup|getmem|getfree|getutil] [openMosix_ID]

		mosctl	setyard [Processor-Type|openMosix_ID||this]

		mosctl	setspeed interger-value

		mosctl	setdecay interval [slow fast]

mosrun	-	запускает специально сконфигурированную команду на указанном узле или группе узлов.
		синтаксис:
		mosrun	[-h|openMosix_ID| список_openMosix_ID] команда [аргументы]

Команду mosrun можно выполнять с дополнительными аргументами командной строки. Для облегчения этой задачи есть несколько преконфигурированных скриптов для запуска задач на специальной конфигурации openMosix.

setpe	-	утилита ручной конфигурации
		синтаксис:
		setpe	-w -f [hpc_map]
		setpe	-r [-f [hpc_map]]
		setpe	-off

-w	читает конфигурацию openMosix из файла (обычно /etc/openmosix.map)
-r	записывает конфигурацию openMosix в файл (обычно /etc/openmosix.map)
-off	отключает текущую конфигурацию openMosix

tune	-	утилита калибровки и оптимизации openMosix (для более подробной
		информации обратитесь к man-странице утилиты tune)

Помимо /proc интерфейса и утилит командной строки (которые в свою очередь используют тот же /proc интерфейс) существуют ещё и специальные версии утилит, аналогичных программам ps и top (они называются mps и mtop), которые отличаются тем, что в них присутствует колонка с номером openMosix-Node_ID. Они могут пригодиться, если, например, необходимо выяснить, где обрабатывается определённый процесс.

Вот, пожалуй, и всё, что можно вкратце рассказать об утилитах командной строки, но не забудьте, что есть ещё и openMosixView – графический интерфейс (GUI) для административных целей; подробнее о нём будет рассказано в главе openMosixView.

Многие пользователи просили добавить в openMosix возможность администратору указывать, на какие узлы процесс и его потомки могут мигрировать, а на какие – нет.

Сейчас благодаря Simone Ettore, который и реализовал эту функцию в новом патче на CVS, такая возможность есть, и работает она следующим образом:

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

Некоторые нижеследующие части всё ещё относятся к старому документу Mosix HOWTO, но со временем они будут заменяться частями, соответствующими openMosix, тем не менее, многие утверждения могут ещё совпадать.

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

Для всего этого необходимо заставить этот узел “думать”, что он – самый медленный, и что лучше мигрировать его процессы на более быстрые соседние узлы. Такого эффекта можно добиться следующей “замедляющей” командой:

mosctl setspeed [n]

где значение n должно быть намного ниже, чем скорость других узлов. Теперь процессы довольно быстро мигрируют на другие узлы. Узнать же скорость любого узла можно командой:

mosctl getspeed

Редакторский комментарий: Приведённые ниже команды могут изменяться в последующих версиях openMosix.

Подключитесь к терминалу с правами пользователя root. Выполните команду:

setpe -r

Эта команда должна вывести на экран файл /etc/openmosix.map. Если этого не произошло, то попробуйте такую команду

setpe -w -f /etc/mosix.map

для конфигурирования вашего узла. Следующая команда

cat /proc/$$/lock

покажет, могут ли процессы потомки мигрировать с данного узла (0) или нет (1). Если же они заблокированы, то вы можете разблокировать их командой

echo 0 > /proc/$$/lock

Проделайте аналогичную конфигурацию на другом компьютере. К сожалению, программы tune_kernel и prep_tune, которые Mosix использует для калибровки отдельных узлов, не работают в дистрибутиве SuSE Linux. Тем не менее, с этим можно побороться. Для начала переведите компьютер, подлежащий настройке, а также второй компьютер с Mosix в однопользовательский режим командой

init 1

(разумеется, все действия надо выполнять с правами root). Все остальные компьютеры в сети желательно отключить вообще. На обеих машинах выполните следующие команды:

/etc/init.d/network start
/etc/init.d/mosix start
echo 1 > /proc/mosix/admin/quiet

Это позволит “обмануть” prep_tune и поначалу tune_kernel. Также учтите, что если у вас ноутбук с сетевой картой PCMCIA, то вам надо запускать/etc/init.d/pcmcia start вместо /etc/init.d/network start. На компьютере, который вы настраиваете, запустите tune_kernel и следуйте инструкциям. В зависимости от ваших машин, процесс работы этой программы может занять значительное время – если у вас есть собачка, то можете даже пойти и прогуляться с ней. tune_kernel создаст тестовую программу pg в каталоге /root, не обращайте на неё внимания. После того как процесс настройки закончился, скопируйте содержимое /tmp/overheads в файл /etc/overheads (и/или перекомпилируйте ядро). Повторите процедуру настройки на каждом компьютере. Теперь можно перезагрузиться и наслаждаться openMosix, и не забудьте похвастаться перед друзьями своим новым кластером.

На самом деле соединение каналов просто до смешного. Наверное, это и объясняет отсутствие документации на эту тему. Объединённая сеть для приложений выглядит как самая обычная сеть. Все машины в подсети должны быть объединены одинаковым способом. Объединённые и не объединённые машины практически никак не сообщаются друг с другом.

Объединение каналов требует как минимум две физические подсети, которых, тем не менее, может быть и больше (например, у меня сейчас тройной связанный кластер). Для поддержки этой возможности нужно встроить в ядро (или модуль ядра bonding.o) поддержку Channel Bonding, в версиях ядра 2.4.x – это стандартная опция ядра. Сетевые карты настраиваются как обычно за исключением того, что ifconfig надо использовать для активации первой сетевой карты в связке. Утилита ifenslave используется для активации оставшихся сетевых карт связанного соединения. Программу ifenslave можно найти в каталоге с исходным кодом ядра /linux/Documentation/network/. Её нужно будет скомпилировать, поскольку это просто файл на С. Пример использования программы таков:

ifenslave <master> <slave1> <slave2> ...

Сети с объединёнными каналами могут соединяться с обычными сетями посредством маршрутизатора или моста, поддерживающего технологию Channel Bonding (я просто использую дополнительную сетевую карту и перенаправление портов на головном узле).

Вообще говоря, использование updatedb в комбинации с MFS может вызвать некоторые проблемы: чтобы отключить индексацию точек монтирования, можно добавить /mfs в PRUNEFPATHS или mfs в PRUNEFS в опции файла /etc/updatedb.conf.

openMosix работает с гораздо большим эффектом на этом типе оборудования, подробнее написано в документе openMosix и FireWire

openMosixView – это следующая версия Mosixview, переписанная заново. Любой может свободно скачать и использовать этот GUI для openMosix-кластера (разумеется, на свой страх и риск). openMosixView состоит из пяти приложений для мониторинга и администрирования кластера.

Все эти приложения доступны из основного окна приложения. Наиболее используемые команды openMosix выполняются в несколько щелчков мышью, а развитый диалог запуска команд упрощает запуск приложений в кластере. Так называемые “ползунки приоритета” для каждого узла делают простым и наглядным процесс ручной и автоматической балансировки нагрузки. Сейчас openMosixView полностью адаптирован к службе автообнаружения openMosix и использует все параметры настройки кластера через /proc интерфейс.

openMosixView спроектирован специально для кластера openMosix. Веб-сайт проекта Mosixview (и все его зеркала) всё ещё действуют, но всё, что касается разработки openMosixView, находится на своём собственном сайте: www.openmosixview.com.

Если у вас есть вопросы, проблемы с установкой, комментарии, или просто думаете что программе не хватает какой-либо опции или хотите поделиться своим опытом, то можете написать автору программы (Matt Rechenburg), или подписаться на список рассылки openMosix/Mosixview-mailing-list и пообщаться непосредственно через него.

изменения: (для Mosixview 1.1) openMosixView отличается от Mosixview тем, что переписан “с нуля”! У него есть все те же функции Mosixview, но во все части исходного кода openMosixView внесены фундаментальные изменения. openMosixView тестируется на кластерах с постоянно меняющейся топографией, а все “сомнительные” части были удалены или переписаны заново, за счёт чего приложение стало намного стабильней.

Требования

В дистрибутиве RedHat Linux 8.0 вам потребуются пакеты .rpm: qt-3.0.5-17, libmng-1.0.4, XFree86-Mesa-libGLU-4.2.0, glut-3.7 и т.п. …

Документация openMosixView. В состав openMosixView входит полноценный комплект документации в формате HTML. Стартовую страницу документации можно найти в каталоге установки openMosixView: openmosixview/openmosixview/docs/en/index.html.

Пакеты .rpm устанавливаются в каталог /usr/local/openmosixview.

rpm -i openmosixview-1.4.rpm

rpm -e openmosixview

gunzip openmosixview-1.4.tar.gz
tar -xvf openmosixview-1.4.tar

./setup [путь_к_установленным_библиотекам_qt_2.3.x_]

export QTDIR=/usr/lib/qt-2.3.0 (для bash)

setenv QTDIR=/usr/lib/qt-2.3.0 (для csh)

ln -s /usr/local/qt-2.3.0 /usr/lib/qt

export QTDIR=/usr/lib/qt (для bash)

setenv QTDIR /usr/lib/qt (для csh)

./configure
make

cp openmosixview/openmosixview /usr/bin
cp openmosixviewproc/openmosixviewprocs/mosixviewprocs /usr/bin
cp openmosixcollector/openmosixcollector/openmosixcollector /usr/bin
cp openmosixanalyzer/openmosixanalyzer/openmosixanalyzer /usr/bin
cp openmosixhistory/openmosixhistory/openmosixhistory /usr/bin

cp openmosixcollector/openmosixcollector.init /etc/init.d/openmosixcollector

cp openmosixcollector/openmosixcollector.init /etc/rc.d/init.d/openmosixcollector

rcp openmosixprocs/openmosixprocs your_node:/usr/bin/openmosixprocs

openmosixview

openMosixcollector – это демон, который может быть запущен на любом из узлов кластера. Он журналирует нагрузку openMosix в каталог /tmp/openmosixcollector/*. Затем эти журналы анализируются программой openMosixanalyzer (будет описан далее), что в результате даёт представление о нагрузке, использовании памяти и процессах кластера. Основным журналом является файл /tmp/openmosixcollector/cluster. Помимо него в этом каталоге создаются и другие файлы.

При запуске openMosixcollector записывает свой PID (process id) в файл /var/run/openMosixcollector.pid.

Демон openMosixcollector рестартует каждые 12 часов и сохраняет накопленную историю в файл вида /tmp/openmosixcollector[date]/*. Такие резервные копии создаются автоматически, хотя их можно создавать и вручную.

Существует также возможность записать контрольную точку в историю. В openMosixanalyzer такие контрольные точки обозначаются на графике вертикальной синей линией. К примеру, вы можете создать контрольную точку при запуске задачи на кластере и по окончании этого задания.

Вот расшифровка возможных аргументов командной строки:

openmosixcollector -d		// запускает коллектор в виде демона
openmosixcollector -k		// останавливает коллектор
openmosixcollector -n		// записывает контрольную точку в историю
openmosixcollector -r		// сохраняет накопленную историю и начинает новую
openmosixcollector		// выводит небольшую подсказку

Этот демон можно стартовать и в виде init-скрипта в /etc/init.d или /etc/rc.d/init.d. Нужно просто создать символическую ссылку в соответствующем уровне выполнения для его автозапуска.

О том, как анализировать созданные файлы журналов, рассказывается в разделе про openMosixanalyzer.

(это HOWTO о настройке SSH)

Самая веская причина, по которой следует использовать SSH вместо RSH, – это частые сообщения о том, как очередной хакер проник в незащищённую систему/сеть. Так что SSH – это неплохая защита в любом случае.

freedom x security = constant	(из группы новостей по безопасности)

Специфика SSH такова, что устанавливаемое соединение защищено, даже если у вас не запрашивается пароль. Ниже изложено описание, как такое соединение настроить.

Для начала необходимо запустить демон sshd на удалённой стороне. Если он ещё не установлен, то скорей установите его! Если он просто не запущен, то выполните:

/etc/init.d/ssh start

Теперь вам необходимо сгенерировать ключ для локальной машины утилитой ssh-keygen.

ssh-keygen

Программа попросит у вас секретную фразу для нового ключа. Эта фраза может быть намного длиннее пароля, может быть даже целым предложением. ^[2] Затем ключ шифруется этой фразой и сохраняется в файл

/root/.ssh/identity		// ваш личный ключ

и

/root/.ssh/identity.pub		// ваш публичный ключ

Никому не давайте свой личный ключ!!! Теперь скопируйте файл /root/.ssh/identity.pub в /root/.ssh/authorized_keys на локальной (потому что openMosixview подключается к локальной машине также по SSH) и удалённой машине.

Если сейчас попробовать подключиться к удалённой машине, то система запросит ту самую секретную фразу. После её правильного ввода следует вход в систему. ^[3]

Какие здесь преимущества??? Фраза намного длиннее пароля!

Что можно сделать с помощью ssh-agent? По идее он поможет нам в управлении фразой во время сессии SSH.

ssh-agent

После запуска ssh-agent появляются две переменные окружения, которые необходимо установить (если они ещё не установлены). Выполните:

echo $SSH_AUTH_SOCK

и

echo $SSH_AGENT_PID

чтобы убедиться, что они уже экспортированы. Если нет, то их можно просто скопировать и вставить из терминала. т.е. для bash:

SSH_AUTH_SOCK=/tmp/ssh-XXYqbMRe/agent.1065
export SSH_AUTH_SOCK
SSH_AGENT_PID=1066
export SSH_AGENT_PID

пример для csh:

setenv SSH_AUTH_SOCK /tmp/ssh-XXYqbMRe/agent.1065
setenv SSH_AGENT_PID 1066

По этим переменным удаленный демон sshd сможет соединяться с вашим локальным ssh-agent через файл-сокет в /tmp (в данном примере /tmp/ssh-XXYqbMRe/agent.1065). Теперь ssh-agent может передавать фразу на удалённый хост через указанный сокет.

Нужно только добавить ваш публичный ключ в ssh-agent командой ssh-add.

ssh-add

Теперь можно подключаться по SSH к удалённой машине без запроса пароля!

Осталось лишь добавить команды ssh-agent и ssh-add в ваш файл профайла, т.е.

eval `ssh-agent`
ssh-add

Таким образом, всё запускается, когда вы входите в систему. Вот и всё! Желаю вам безопасных логинов! ^[4]

В главном окне openMosixView есть меню, позволяющее выбирать между RSH/SSH. После выбора не забудьте сохранить конфигурацию!

Если вы выберите службу, которая не настроена правильным образом, openMosixView не будет работать! (т.е. в случае, если вы выбрали RSH/SSH, но не можете подключиться к узлам без запроса пароля).

Есть и другие приложения, позволяющие контролировать openMosix. В этой главе будет представлен краткий обзор таких проектов.

openMosixView – наиболее известное и часто используемое приложение для администрирования openMosix. Более подробно о нём рассказывается в главе openMosixView.

openMosixApplet позволяет просматривать нагрузку в openMosix кластере в режиме реального времени. Программа представляет собой локальный демон, который слушает все соединения апплета. Апплет основан на chart2D и выглядит довольно симпатично.

wmomload – это простой dockapp, показывающий нагрузку на узлах в небольшом openMosix-кластере.

openMosixWebView генерирует веб-диаграммы и графы, отображающие состояние openMosix кластера. openMosixWebView представляет собой скрипт на PHP для мониторинга openMosix кластера через WEB-браузер. Использует логи openMosixCollector (из состава openMosixview). Скачать последний релиз можно отсюда openmosixwebview-0.2.12.tar.gz (16 Feb 2003).

См. снимки экрана запущенного openMosixWebView :-) Выпущен под лицензией GNU General Public License (GPL). См. README и FAQ.

Большинство из приведенных проблем в этой главе могли бы войти в FAQ, но здесь, в отличие от ограничений FAQ, можно дать более подробный ответ на возникшую проблему и попытаться объяснить её.

Помогите, процесс XYZ не мигрирует. Ниже Moshe Bar постарался объяснить, почему одни процессы мигрируют, а другие нет. Тем не менее, предварительно загляните в /proc/$pid/, там может быть файл cantmove, который может подсказать вам, почему же определённый процесс не может мигрировать.

Также процесс может быть просто заблокирован. Чтобы это проверить, посмотрите файл:

cat /proc/$PID/lock

где $PID – это ID проблемного процесса.

А теперь посмотрим что говорит об этом сам Moshe.

Иногда подобные проблемы возникают при использовании одного ядра, но на разных дистрибутивах, к примеру, кластер из смешанных узлов под RedHat или Debian, а rc-скрипты, запускающие на них openMosix, немного различаются. Некоторые версии имеют сильно модифицированный /etc/inittab, запускающий все демоны (и их потомков) при помощи mosrun -h. Таким образом получается, что процессы не могут нормально мигрировать. Следовательно, все эти процессы имеют значение 1 в файле /proc/pid/lock при старте. Но можно заставить их мигрировать, записав 0 в этот файл.

Рассмотрим пример. Есть небольшая программа, которая должна мигрировать, если она запущена в количестве, превышающем количество процессоров на локальной машине. То есть, на двухпроцессорной SMP машине запуск программы в трёх экземплярах заставит её мигрировать, если другие узлы кластера по скорости хотя бы сопоставимы с локальной:

int main() {
	unsigned int i;
	while (1) {
		i++;
	}
	return 0;
}

На процессоре Pentium 800Mhz она достигает переполнения довольно быстро.

А вот, к примеру, подобная программа никогда не будет мигрировать:

#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/shm.h>

...

key_t key; /* key to be passed to shmget() */
int shmflg; /* shmflg to be passed to shmget() */
int shmid; /* return value from shmget() */
int size; /* size to be passed to shmget() */

...

key = ...
size = ...
shmflg) = ...

if ((shmid = shmget (key, size, shmflg)) == -1) {
	perror("shmget: shmget failed"); exit(1); } else {
	(void) fprintf(stderr, "shmget: shmget returned %d\n", shmid);
	exit(0);
}
...

Программы, использующие каналы, тоже должны нормально мигрировать:

int pdes[2];

pipe(pdes);
if (fork() == 0) { /* child */
	close(pdes[1]); /* not required */
	read(pdes[0]); /* read from parent */
	...
}
else
{
	close(pdes[0]); /* not required */
	write(pdes[1]); /* write to child */
	...
}

Программы, использующие pthreads версии 2.4.17 и выше, не мигрируют, но, тем не менее, уже и не завершаются аварийно.

//
// Very simple program demonstrating the use of threads.
//
// Command-line argument is P (number of threads).
//
// Each thread writes "hello" message to standard output, with
// no attempt to synchronize. Output will likely be garbled.
//
#include <iostream>
#include <cstdlib>	// has exit(), etc.
#include <unistd.h>	// has usleep()
#include <pthread.h>	// has pthread_ routines

// declaration for function to be executed by each thread
void * printHello(void * threadArg);

// ---- Main program -------------------------------------------------

int main(int argc, char* argv[]) {

	if (argc < 2) {
		cerr << "Usage: " << argv[0] << " numThreads\n";
		exit(EXIT_FAILURE);
	}
	int P = atoi(argv[1]);

	// Set up IDs for threads (need a separate variable for each
	// since they're shared among threads).
	int * threadIDs = new int[P];
	for (int i = 0; i < P; ++i)
	threadIDs[i] = i;

	// Start P new threads, each with different ID.
	pthread_t * threads = new pthread_t[P];
	for (int i = 0; i < P; ++i)
		pthread_create(&threads[i], NULL, printHello,
			(void *) &threadIDs[i]);

	// Wait for all threads to complete.
	for (int i = 0; i < P; ++i)
		pthread_join(threads[i], NULL);

	// Clean up and exit.
	delete [] threadIDs;
	delete [] threads;
	cout << "That's all, folks!\n";
	return EXIT_SUCCESS;
}

// ---- Code to be executed by each thread ---------------------------

// pre: *threadArg is an integer "thread ID".
// post: "hello" message printed to standard output.
// return value is null pointer.
void * printHello(void * threadArg) {

 int * myID = (int *) threadArg;
 cout << "hello, world, ";
 // pointless pause, included to make the effects of
 // synchronization (or lack thereof) more obvious
 usleep(10);
 cout << "from thread " << *myID << endl;
 pthread_exit((void*) NULL);
}

Программы, использующие все виды файловых дескрипторов (описателей), включая и сокеты, также мигрируют (естественно, что сокеты не мигрируют вместе с процессом, а файлы мигрируют только при использовании oMFS/DFSA)

(весь вышеприведённый код написан Moshe, он же Moshe Bar, он же Moshe – CTO компании Qlusters, Inc.)

Пожалуйста, прочтите также man страницы openMosix, в них также содержится исчерпывающая информация о миграции процессов.

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

# разрешает подпроцессам мигрировать на другие узлы
echo 0 > /proc/self/lock

в файл /etc/profile.

	Внимание
	Это позволит мигрировать всем процессам, а не тем, которые вы хотите. Для указания миграции определённых процессов используйте утилиту mosrun -l для разблокировки нужного процесса.

Для начала убедитесь, что вы используете одинаковые версии ядра на каждой машине. Под этим подразумевается именно версия ядра, а не набор опций и модулей, включенных в него для поддержки аппаратных ресурсов узла. То же самое относится и к установке openMosix: версия ядра должна совпадать на всех узлах, к примеру, ядро openmosix-x.x.x-y установлено на всех машинах, а не так, что на одной – openmosix-x.x.x-x, на другой – openmosix-x.x.x-y, на третьей – openmosix-x.x.x-z и т.д.

Запустите в консоли программу mosmon и нажмите клавишу t для просмотра списка работающих машин. Не появилось ли сообщения о том, что Mosix не запущен?

Если появилось, то проверьте наличие IP-адреса в файле /etc/openmosix.map в случае, если вы не пользуетесь omdiscd (но только не используйте 127.0.0.1: если у вашей машины такой IP-адрес, то, вероятно, у вас проблемы с сервером имён или DHCP). Если же сообщения о том, что openMosix не запущен, нет, то посмотрите, какие машины обнаружены. Видите ли вы только свою машину?

Если да, то наиболее вероятно, что ваша машины отделена от других брандмауэром, который не пропускает трафик openMosix.

Если же это не так, то проблема может быть и в самой машине, которая не обнаруживается. Да, а не используете ли вы две сетевые карты на узле? В этом случае необходимо отредактировать файл /etc/hosts, добавив в него ваши значения в похожем формате:

non-cluster_ip cluster-hostname.cluster-domain cluster-hostname

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

Ко всему прочему, такая проблема может быть вызвана в связи с использованием разных параметров ядра на разных машинах. В частности, если вы использовали опцию 'Support clusters with a complex network topology', то убедитесь, что и в опции 'Maximum network-topology complexity support' вы использовали одинаковое значение на всех узлах.

Например, вот такая ошибка

bash: child setpgid (4061 to 4061): No such process

что это значит?

Такое сообщение означает, что оболочка, которую вы использовали, мигрировала на другой узел. А вывод такого сообщения в bash вызван ошибкой в старой версии openMosix, которая давно устранена. (Muli Ben-Yehuda <[email protected]>)

Многие часто путаются, говоря об MFS и DFSA. Как было описано ранее в главе Файловая система openMosix (oMFS), MFS – это функция openMosix, предоставляющая возможность доступа к удалённым файловым системам так, как будто они смонтированы локально. Обычно они монтируются в /mfs. Наиболее распространённое заблуждение в том, что поддержка MFS обязательно необходима для работы openMosix, что в корне не верно, хотя MFS действительно может быть очень полезна.

Поддержка DFSA позволяет выполнять системные вызовы на удаленных узлах без миграции процесса обратно на его UHN. Такое поведение (прямой доступ к файловой системе) заставляет процессы мигрировать к данным, а не наоборот. При отсутствии поддержки DFSA, MFS играет роль обычной некэширующей файловой системы.

Если в двух словах, то при выключенной DFSA абсолютно каждый запрос на ввод/вывод будет возвращаться на UHN для выполнения. Если же DFSA включена, то процесс ввода/вывода будет происходить локально.

Очень частая ошибка: многие используют ядра как с поддержкой DFSA, так и без неё. Так что необходимо окончательно определиться, будете ли вы использовать DFSA или нет. Информацию о том, поддерживает ли ядро DFSA или нет, можно такой командой:

cat /proc/hpc/admin/version

Некоторые пользователи заметили проблемы, возникающие при работе с Python. Как выяснилось, это проблемы, относящиеся не к openMosix, а к glibc.

Возможно, решение проблемы – простое удаление /lib/i686/lib*, таким образом позволив приложениям линковать динамически /lib/libpthread (или другие). К счастью, исправления в новых версиях glibc и openMosix помогли решить подобные проблемы.

Если по какой-то причине процессы остаются постоянно запертыми на домашнем узле, и вы не можете выяснить причину этого, то как решение можно добавить следующие команды в ваш файл ~/.profile, которые автоматически включают миграцию:

if [ -x /proc/$$/lock ]; then
	echo 0 > /proc/$$/lock
fi

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

Наверняка вы захотите протестировать настройку своего кластера перед тем, как решать, какие программы будут мигрировать. К примеру, вы работаете в KDE на слабой машине, хотя у вас есть и намного более мощные машины в кластере. В этом случает можно мигрировать ресурсоёмкие программы типа kmail. Ничего страшного при этом не произойдёт: самое неприятное, что может быть, – это просто небольшая задержка вывода текста на экран при наборе.

Программы, использующие Green Threads из JVM, мигрируют без особых проблем, т.к. при этом каждый поток Java – это отдельный процесс. Потоки, отличные от Java Green Threads, не мигрируют в Linux, поэтому openMosix также не сможет обеспечить миграцию программ, использующих эти потоки.

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

Gian Paolo Ghilardi написал статью под заголовком “Consideration on openMosix” (Размышления об openMosix), в которой, помимо всего прочего, затронута и тема о Java и openMosix. http://www.democritos.it/events/openMosix/papers/crema.pdf

По правде говоря, производительность openMosix возрастает, если поддержка Hypethreading отключена. Это можно сделать добавив параметр загрузки ядра “noht”, или отключив Hypethreading в BIOS.

Для тех, кто ещё не знает, что такое hypetrheading: объяснение Hypethreading от Intel.

Очень часто возникают вопросы относительно openMosix и брандмауэров. Всё очень просто (из файла hpc/comm.c):

#define MIG_DAEMON_PORT		0x3412
#define INFO_DAEMON_PORT	0x3415

что в десятичной системе значит 4660 и 5428 соответственно (преобразовывается число 1234, а не 3412, “в связи с порядками преобразования байт сети-узла”; подробности читайте в IP/TCP/UDP RFC).

Здесь порт mig_daemon это TCP порт, а порт info_daemon – UDP. Следовательно, TCP/4660 и UDP/5428.

Самый быстрый способ проверить openMosix кластер – это написать простой скрипт следующего содержания:

awk 'BEGIN {for(i=0;i<10000;i++)for(j=0;j<10000;j++);}' &

Затем сохранить его, к примеру, как test_mosix, а потом запустить mosmon и выполнить этот скрипт огромное количество раз:

for i in `ls /etc/`; do ./test_mosix; done

После этого можно наблюдать, как напрягается ваш кластер…

Чтобы убить все процессы, можно просто выполнить pkill awk на домашнем узле.

Программа на Perl для тестирования openMosix кластера.

Представляю небольшую программу, которую я написал для тестирования openMosix кластера. Она взята из постинга, который я сделал в список рассылки openMosix-devel 6 Марта 2002г.:

#! /usr/bin/perl -w

# this mill unlock this process and all tis childs
sub unlock { 
open (OUTFILE,">/proc/self/lock") || 
die "Could not unlock myself!\n"; 
print OUTFILE "0"; 
} 

unlock;

# this will count the nodes
sub cpucount {
 $CLUSTERDIR="/proc/hpc/nodes/";
 $howmany=0;
 opendir($nodes, $CLUSTERDIR);
 while(readdir($nodes)) {
  $howmany++;
 }

 $howmany--;
 $howmany--;
 closedir ($nodes);
 return $howmany;
}

my $processes=cpucount;
$processes=$processes*3;

print("starting $processes processes\n");

#Portfolio.pl, version 0.1
#Perl program that simulate a portfolios for various stock composition for a given period of time
#We run various scenarios to find the mix of assets that give the best performance/risk ratio
#This method is base on the book "The intelligent asset allocator" by William Bernstein
#Can be used to test an OpenMosix cluster
#This program is licensed under GPL
#Author: Charles-E. Nadeau Ph.D., (c) 2002
#E-mail address: charlesnadeau AT hotmail DOT com

use Parallel::ForkManager; #We use a module to parallelize the calculation

#Available at http://theoryx5.uwinnipeg.ca/mod_perl/cpan-search?filetype=%20distribution%20name%20or%20description;join=and;arrange=file;download=auto;stem=no;case=clike;site=ftp.funet.fi;age=;distinfo=2589

use Statistics::Descriptive::Discrete; #A module providing statistical values

#Available at http://theoryx5.uwinnipeg.ca/mod_perl/cpan-search?new=Search;filetype=%20distribution%20name%20or%20description;join=and;arrange=file;download=auto;stem=no;case=clike;site=ftp.funet.fi;age=;distinfo=2988

srand; #We initialize the random number generator

#Initializing constant
$NumberOfSimulation=$processes;  #Number of simulation to run
$NumberOfMonth=100000; #Number of month for wich to run the simulation
$NumberOfStock=6; #Number of different stocks in the simulation

#Portfolio to simulate
#TODO: Read the stock details from a file
$Stock[0][0]="BRKB"; #Stock ticker
$Stock[0][1]=0.01469184; #Stock average monthly return
$Stock[0][2]=0.071724934; #Stock average monthly standard deviation
$Stock[1][0]="TEST "; #Stock ticker
$Stock[1][1]=-0.01519; #Stock average monthly return
$Stock[1][2]=0.063773903; #Stock average monthly standard deviation
$Stock[2][0]="SPDR"; #Stock ticker
$Stock[2][1]=0.008922718; #Stock average monthly return
$Stock[2][2]=0.041688404; #Stock average monthly standard deviation
$Stock[3][0]="BRKB"; #Stock ticker
$Stock[3][1]=0.01469184; #Stock average monthly return
$Stock[3][2]=0.071724934; #Stock average monthly standard deviation
$Stock[4][0]="TEST "; #Stock ticker
$Stock[4][1]=-0.01519; #Stock average monthly return
$Stock[4][2]=0.063773903; #Stock average monthly standard deviation
$Stock[5][0]="SPDR"; #Stock ticker
$Stock[5][1]=0.008922718; #Stock average monthly return
$Stock[5][2]=0.041688404; #Stock average monthly standard deviation




my $pm = new Parallel::ForkManager($NumberOfSimulation); #Specify the number of threads to span

$pm->run_on_start(
  sub { my ($pid,$ident)=@_;
  print "started, pid: $pid\n";
  }
);



#We initialize the array that will contain the results
@Results=();
for $i (0..$NumberOfSimulation-1){
	for $j (0..$NumberOfStock+3){
		$Results[$i][$j]=0.0; #Equal to 0.0 to start
	}
}

for $i (0..$NumberOfSimulation-1){ #Loop on the number of simulation to run
	$Results[$i][0]=$i; #The first column of each line is the number of the simulation
	$pm->start and next; #Start the thread

		$TotalRatio=1; #The sum of the proprtion of each stock

		#Here we calculate the portion of each investment in the portfolio for a given simulation
		for $j (0..$NumberOfStock-2){ #We loop on all stock until the second to last one
			#TODO: Replace rand by something from Math::TrulyRandom
			$Ratio[$j]=rand($TotalRatio);
			$Results[$i][$j+1]=$Ratio[$j]; #We store the ratio associated to this stock
			$TotalRatio=$TotalRatio-$Ratio[$j];
		}
		$Ratio[$NumberOfStock-1]=$TotalRatio; #In order to have a total of the ratios equal to one, we set the last ratio to be the remainder
		$Results[$i][$NumberOfStock]=$Ratio[$NumberOfStock-1]; #We store the ratio associated to this stock. Special case for the last stock

		$InvestmentValue=1; #Initially the investment value is 1 time the initial capital amount.
		my $stats=new Statistics::Descriptive::Discrete; #We initialize the module used to calculate the means and standard deviations

		for $j (1..$NumberOfMonth){ #Loop on the number of months

			$MonthlyGrowth[$j]=0.0; #By how much did we grow this month. Initially, no growth yet.

			#We loop on each stock to find its monthly contribution to the yield 
			for $k (0..$NumberOfStock-1){

			$MonthlyGrowth[$j]=$MonthlyGrowth[$j]+($Ratio[$k]*((gaussian_rand()*$Stock[$k][2])+$Stock[$k][1])); #We had the growth for this stock to the stock already calculated for the preceding stocks
			}

			$stats->add_data($MonthlyGrowth[$j]); #Add the yield for this month so we can later on have the mean and standard deviation for this simulation
			$InvestmentValue=$InvestmentValue*(1+$MonthlyGrowth[$j]); #Value of the Investment after this month
		}
		$Results[$i][$NumberOfStock+1]=$stats->mean(); #Calculate the average monthly growth
		$Results[$i][$NumberOfStock+2]=$stats->standard_deviation(); #Calculate the standard deviation of the monthly growth

	$pm->finish; #Finish the thread
}
$pm->wait_all_children; #We wait until all threads are finished

#Printing the results
print "Simulation ";
for $j (0..$NumberOfStock-1){
	print "Ratio$Stock[$j][0] ";
}
print "  Mean StdDev YieldRatio\n";
for $i (0..$NumberOfSimulation-1){
	printf "%10d ", $Results[$i][0];
	for $j (1..$NumberOfStock){
		printf "   %6.2f ",$Results[$i][$j];
	}

	if($Results[$i][$NumberOfStock+2]!=0) {
		printf "%5.4f %5.4f    %5.4f\n", $Results[$i][$NumberOfStock+1], $Results[$i][$NumberOfStock+2], ($Results[$i][$NumberOfStock+1]/$Results[$i][$NumberOfStock+2]);

	} else {
		printf "%5.4f %5.4f    %5.4f\n", $Results[$i][$NumberOfStock+1], $Results[$i][$NumberOfStock+2], 0;

	}
}



#Subroutines

#Subroutine to generate two numbers normally distributed
#From "The Perl Cookbook", recipe 2.10
sub gaussian_rand {
	my ($u1, $u2);
	my $w;
	my ($g1, $g2);

	do {
		$u1=2*rand()-1;
		$u2=2*rand()-1;
		$w=$u1*$u1+$u2*$u2;
	} while ($w>=1 || $w==0); #There was an error in the recipe, I corrected it here

	$w=sqrt(-2*log($w)/$w);
	$g2=$u1*$w;
	$g1=$u2*$w;
	return wantarray ? ($g1,$g2) : $g1;

}

Работа над эти разделом в процессе.

Многие люди пытаются использовать openMosix как подобие компилирующей фермы, очень часто они возвращаются назад очень разочарованными. Эта глава HOWTO попытается объяснить, в каких случаях ваши компиляции выиграют от openMosix, и как улучшить ваш уровень успеха.

Прежде всего, вы должны запомнить одну вещь: openMosix не будет мигрировать все процессы, которые вы запускаете на кластере, но только те, которые выиграют от миграции к другому узлу. Для сбора информации об этом это значит, что процесс должен выполнятся достаточно долго. Компиляция ядра обычно состоит из многих коротких компиляций, каждая из которых не достаточно продолжительна для действительной миграции.

Работа над эти разделом в процессе.

Компьютерная графика всегда было приложением, которое требовало много мощности CPU, – это не изменилось. В рамках этой главы я продемонстрирую некоторые практические примеры того, как компьютерная графика может выиграть от openMosix.

The Persistence of Vision Raytracer – это высококачественный, абсолютно свободный инструмент для создания ошеломляющей трёхмерной графики.

Трассировка лучей – это техника визуализации, которая вычисляет картинку сцены посредством симуляции того, как луч света движется в реальном мире. Тем не менее, она делает работу наоборот. В реальном мире лучи света испускаются из источников света и иллюминирующих объектов. Этот отражённый свет попадает в наши глаза или, возможно, в объектив камеры. Поскольку подавляющее большинство лучей никогда не попадают к обозревателю, это бы заняло вечность протрассировать сцену.

Этот тип приложений может легко быть распараллелен используя pvmpovray. Ожидается, что pvmpovray работает на кластере в стиле Beowulf и распределяет его нагрузку по другим узлам кластера используя PVM. Способ openMosix выполнения этого точно такой же, хотя мы просто делаем всё на одной машине, и у нас есть openMosix, который производит распределение нагрузки за вас!

Великолепный HOWTO по PVM Povray покажет вам, как установить PVMPovray. Ниже – краткое изложение.

$ cd pvmpov3_1g_2
$ tar xfz ../povuni_s.tgz
$ tar xfz ../povuni_d.tgz
$ ./inst-pvm
Trying to apply the patch.
Searching for rejected files
$

Теперь скомпилируйте с помощью aimk, который является скриптом-обёрткой, предоставляемый PVM .rpm, но который, вероятно, не окажется в вашем PATH (некоторые читатели могут вспомнить aimk из других платформ/приложений).

Если вы под RedHat 8.0, я бы поместил libpng и zlib в .notused… Это нужно, чтобы предотвратить проблемы версий с другими версиями libpng и zlib.

export PATH=$PATH:/usr/share/pvm3/lib
export PVMROOT=/usr/share/pvm3

После этого я выполнил aimk newunix. Затем мы запускаем pvm и выходим из него. Демон остаётся активным…

И последняя вещь, которая не известна начинающему пользователю PVM, это то, что PVM использует свои пути, и вы должны либо поместить pvmpov в свои пути, либо запускать её, задавая полный путь.

[root@dhcp71 povray31]# /usr/local/bin/pvmpov -L 
/usr/src/povray/pvmpov3_1g_2/povray31/include/ +Iskyvase.pov  
+Oskyvase.tga +NT16 +NW64 +NH64 +v +w1024 +h768
Persistence of Vision(tm) Ray Tracer Version 3.1g.Linux.gcc
  This is an unofficial version compiled by:
  Jakob Flierl  - PVMPOV Version 3.1g.2
  The POV-Ray Team(tm) is not responsible for supporting this version.
Copyright 1999 POV-Ray Team(tm)
Never found section  in file 
/usr/src/povray/pvmpov3_1g_2/povray31/include/.
Initializing PVMPOV
  Spawning /usr/local/bin/pvmpov with 16 PVM tasks on 1 hosts...
  ...16 PVM tasks successfully spawned.
  Waiting up to 120s for first slave to start...
  Slave 0 successfully started.
Parsing Options
  Input file: skyvase.pov (compatible to version 3.1)
  Remove bounds........On  Split unions........Off
  Library paths: /usr/local/lib/povray31 /usr/local/lib/povray31/include
Output Options
  Image resolution 1024 by 768 (rows 1 to 768, columns 1 to 1024).
  Output file: skyvase.tga, 24 bpp PNG
  Graphic display.....Off
  Mosaic preview......Off
  CPU usage histogram.Off
  Continued trace.....Off  Allow interruption...On  Pause when 
done.....Off
  Verbose messages.....On
Tracing Options
  Quality:  9
  Bounding boxes.......On  Bounding threshold: 25
  Light Buffer.........On  Vista Buffer.........On
  Antialiasing........Off
  Radiosity...........Off
Animation Options
  Clock value....   0.000  (Animation off)
PVM Options
  Block Width....      64  Block Height...      64
  PVM Tasks......      16
  PVM Nice.......       5
  PVM Arch.......
  PVM Slave...... /usr/local/bin/pvmpov
  PVM WorkingDir. /usr/src/povray/pvmpov3_1g_2/povray31
Redirecting Options
  All Streams to console..........On
  Debug Stream to console.........On
  Fatal Stream to console.........On
  Render Stream to console........On
  Statistics Stream to console....On
  Warning Stream to console.......On

Starting frame 0...
 Slave 1 at dhcp71.office.be.stone-it.com successfully started.
 Slave 2 at dhcp71.office.be.stone-it.com successfully started.
 Slave 3 at dhcp71.office.be.stone-it.com successfully started.
 Slave 4 at dhcp71.office.be.stone-it.com successfully started.
 Slave 5 at dhcp71.office.be.stone-it.com successfully started.
 Slave 6 at dhcp71.office.be.stone-it.com successfully started.
 Slave 7 at dhcp71.office.be.stone-it.com successfully started.
 Slave 8 at dhcp71.office.be.stone-it.com successfully started.
 Slave 9 at dhcp71.office.be.stone-it.com successfully started.
 Slave 10 at dhcp71.office.be.stone-it.com successfully started.
 Slave 11 at dhcp71.office.be.stone-it.com successfully started.
 Slave 12 at dhcp71.office.be.stone-it.com successfully started.
 Slave 13 at dhcp71.office.be.stone-it.com successfully started.
 Slave 14 at dhcp71.office.be.stone-it.com successfully started.
 Slave 15 at dhcp71.office.be.stone-it.com successfully started.
  0:00:53 86.46 of blocks complete.Not using dhcp71.office.be.stone-it.com 
for reassignment (77%)
  0:00:53 86.98 of blocks complete.Not using dhcp71.office.be.stone-it.com 
for reassignment (67%)
Not using dhcp71.office.be.stone-it.com for reassignment (86%)
Not using dhcp71.office.be.stone-it.com for reassignment (85%)
  0:00:55 89.06 of blocks complete.   640 of  768 lines finished (in frame 
0).Not using dhcp71.office.be.stone-it.com for reassignment (65%)
  0:00:56 91.67 of blocks complete.Not using dhcp71.office.be.stone-it.com 
for reassignment (72%)
  0:00:56 92.71 of blocks complete.Not using dhcp71.office.be.stone-it.com 
for reassignment (80%)
  0:00:57 93.75 of blocks complete.
Slave at dhcp71.office.be.stone-it.com has exited.
  0:00:57 94.79 of blocks complete.
Slave at dhcp71.office.be.stone-it.com has exited.

Slave at dhcp71.office.be.stone-it.com has exited.
  0:00:58 95.83 of blocks complete.
Slave at dhcp71.office.be.stone-it.com has exited.
  0:00:58 96.35 of blocks complete.   672 of  768 lines finished (in frame 
0).Not using dhcp71.office.be.stone-it.com for reassignment (77%)

Slave at dhcp71.office.be.stone-it.com has exited.
  0:00:58 97.14 of blocks complete.   688 of  768 lines finished (in frame 
0).
Slave at dhcp71.office.be.stone-it.com has exited.
  0:00:59 97.92 of blocks complete.
Slave at dhcp71.office.be.stone-it.com has exited.
  0:00:60 98.44 of blocks complete.   704 of  768 lines finished (in frame 
0).
Slave at dhcp71.office.be.stone-it.com has exited.
  0:01:03 100.00 of blocks complete.   768 of  768 lines finished (in 
frame 0).
Finishing frame 0...rtw. 768


Waiting for remaining slave stats.


PVM Task Distribution Statistics:
           host name  [ done ] [ late ]           host name  [ done ] [ 
late ]
dhcp71.office.be.stone-it.com  [ 5.21%] [ 
0.00%]dhcp71.office.be.stone-it.com  [ 7.81%] [ 0.07%]
dhcp71.office.be.stone-it.com  [ 8.85%] [ 
1.17%]dhcp71.office.be.stone-it.com  [ 4.69%] [ 0.00%]
dhcp71.office.be.stone-it.com  [ 8.85%] [ 
0.98%]dhcp71.office.be.stone-it.com  [ 4.17%] [ 0.00%]
dhcp71.office.be.stone-it.com  [ 5.21%] [ 
0.00%]dhcp71.office.be.stone-it.com  [ 8.33%] [ 0.52%]
dhcp71.office.be.stone-it.com  [ 5.21%] [ 
0.00%]dhcp71.office.be.stone-it.com  [ 5.73%] [ 0.72%]
dhcp71.office.be.stone-it.com  [ 7.29%] [ 
2.73%]dhcp71.office.be.stone-it.com  [ 4.17%] [ 0.00%]
dhcp71.office.be.stone-it.com  [ 5.21%] [ 
0.00%]dhcp71.office.be.stone-it.com  [ 6.77%] [ 0.13%]
dhcp71.office.be.stone-it.com  [ 4.69%] [ 
0.00%]dhcp71.office.be.stone-it.com  [ 7.81%] [ 0.00%]


POV-Ray statistics for finished frames:
skyvase.pov Statistics (Partial Image Rendered), Resolution 1024 x 768
----------------------------------------------------------------------------
Pixels:          303104   Samples:          303104   Smpls/Pxl: 1.00
Rays:           1192710   Saved:                 0   Max Level: 0/5
----------------------------------------------------------------------------
Ray->Shape Intersection          Tests       Succeeded  Percentage
----------------------------------------------------------------------------
Cone/Cylinder                  1842227          900504     48.88
CSG Intersection               2742731          323346     11.79
CSG Union                      1801008          521692     28.97
Plane                         20223278        11233348     55.55
Quadric                        1801008         1196533     66.44
Sphere                         1801008          461786     25.64
Bounding Object                1842227          900504     48.88
----------------------------------------------------------------------------
Calls to Noise:            1201944   Calls to DNoise:        2108954
----------------------------------------------------------------------------
Shadow Ray Tests:          2856188   Succeeded:                85620
Reflected Rays:             889606
----------------------------------------------------------------------------
Smallest Alloc:                  9 bytes   Largest:            20508
Peak memory used:          5643343 bytes
----------------------------------------------------------------------------
Time For Trace:    0 hours  1 minutes   7.0 seconds (67 seconds)
    Total Time:    0 hours  1 minutes   7.0 seconds (67 seconds)

Как вы можете видеть, приложение было разбито на различные части и выполнялось раздельно, после этого openMosix выполнил работу по балансировке нагрузки по отношению к другим машинами.

У меня получились хорошие результаты при значении в два-три раза большим числа CPU, которые у меня были доступны.

Одним из наиболее часто используемых приложений в этой области является Blast. Для Blast есть патч, который заставляет его работать более гладко с openMosix, но это – не единственная альтернатива.

Прежде всего, у этого патча и у других версий Blast есть некоторые известные проблемы: Blast имеет иногда тенденцию к ошибке сегментации (segfault). Это в основном случается с преформатированными базами, которые вы скачиваете из Интернет. Если вы выполните formatdb на исходной базе, эти ошибки склонны исчезать.

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

На самом деле, пока не так много документации о ядре, но надеюсь, что ситуация улучшится со временем. Тем не менее, для начала, вот где располагаются исходники:

Код openMosix находится в основном в каталогах hpc/ и include/hpc. Помимо этого, добавляется множество патчей для файлов ядра, начиная с каталогов arch/i386, и включая mm/, fs/ и т.д. Вам необходимо будет найти прочитать код, который вам нужен (это не проблема, если вы уже писали код для ядра).

А вот что вы можете обнаружить в файлах исходных текстов:

прочие файлы, например как auto_syscalls.c, alternate.c генерируются во время компиляции.