5.4. Общие инструкции openMosix

5.4. Общие инструкции openMosix
Пред.	Глава 5. Инсталляции, специфические для дистрибутива	След.

5.4.1. Компиляция ядра

Всегда используйте “чистые” оригинальные исходные коды ядра с http://www.kernel.org/ для компиляции ядра openMosix! Пожалуйста, будьте добры скачать ядро, используя ближайшее к вам зеркало, и всегда пробуйте и скачивайте впоследствии патчи для последних версий исходников ядра, которое у вас есть, вместо скачивания всего ядра полностью. Это очень оценится сообществом Linux и очень сильно улучшит вашу карму ;-)

Убедитесь, что вы используйте правильный патч openMosix в зависимости от версии ядра. На тот момент, когда я писал это, последним ядром серии 2.4 было 2.4.20, итак, вам следует скачать патч openMosix-2.4.20-x.gz, где x соответствует ревизии патча (то есть, чем больше ревизия, тем он свежее).

Не используйте ядро, которое идёт вместе с любым дистрибутивом Linux: это не сработает. Эти исходники ядра очень интенсивно пропатчены создателями дистрибутива, а значит, наложение патча openMosix на такое ядро наверняка не удастся. Уже проделывал такое: доверьтесь мне.

Скачайте текущую версию патча openMosix и поместите его в своей директории с исходниками ядра (то есть, в /usr/src/linux-2.4.20). Если ваша директория отличается от /usr/src/linux-[version_number] по крайней мере необходимо создать символическую ссылку на /usr/src/linux-[version_number].

Предполагая, что вы – суперпользователь, и вы скачали .gz-патч в свою домашнюю директорию, примените патч используя (угадайте что?) утилиту patch:

mv /root/openMosix-2.4.20-2.gz /usr/src/linux-2.4.20
cd /usr/src/linux-2.4.20
zcat openMosix-2.4.20-2.gz | patch -Np1

В редких случаях, если в вашей системе нет zcat, выполните:

mv /root/openMosix-2.4.20-2.gz /usr/src/linux-2.4.20
cd /usr/src/linux-2.4.20
gunzip openMosix-2.4.20-2.gz
cat openMosix-2.4.20-2 | patch -Np1

В более закрученном случае, если у вас в системе нету cat (!), выполните:

mv /root/openMosix-2.4.20-2.gz /usr/src/linux-2.4.20
cd /usr/src/linux-2.4.20
gunzip openMosix-2.4.20-2.gz
patch -Np1 < openMosix-2.4.20-2

patch должна сейчас отобразить список пропатченных файлов исходников ядра.

Если вы в достаточной степени авантюрист, то включите опции, относящиеся к openMosix, в файле конфигурации ядра, то есть:

...
CONFIG_MOSIX=y
# CONFIG_MOSIX_TOPOLOGY is not set
CONFIG_MOSIX_UDB=y
# CONFIG_MOSIX_DEBUG is not set
# CONFIG_MOSIX_CHEAT_MIGSELF is not set
CONFIG_MOSIX_WEEEEEEEEE=y
CONFIG_MOSIX_DIAG=y
CONFIG_MOSIX_SECUREPORTS=y
CONFIG_MOSIX_DISCLOSURE=3
CONFIG_QKERNEL_EXT=y
CONFIG_MOSIX_DFSA=y
CONFIG_MOSIX_FS=y
CONFIG_MOSIX_PIPE_EXCEPTIONS=y
CONFIG_QOS_JID=y
...

Тем не менее, будет гораздо более удобнее сконфигурировать выше перечисленные опции используя один из конфигурационных инструментов ядра Linux:

make config | menuconfig | xconfig

Вышесказанное значит, что вы должны выбрать одно из config, menuconfig или xconfig. Это дело вкуса. Кстати, config должна работать на любой системе, для menuconfig нужна библиотека curses, в то время как для xconfig необходимо иметь проинсталлированное окружение X плюс библиотеки и интерпретаторы TCL/TK.

Теперь компилируем это при помощи:

make dep bzImage modules modules_install

После компиляции проинсталлируйте новое ядро, используя опцию меню openMosix, в ваш менеджер загрузки, то есть, например, добавьте запись для нового ядра в /etc/lilo.conf и после этого запустите lilo.

Перегрузитесь – и ваш узел openMosix кластера готов!

5.4.2. Синтаксис файла `/etc/openmosix.map`

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

Стандартным теперь является файл /etc/openmosix.map, а /etc/mosix.map и /etc/hpc.map уже устаревшие стандарты, но CVS -версия утилит является обратно-совместимой и ищет /etc/openmosix.map, /etc/mosix.map и /etc/hpc.map (в таком порядке).

Файл /etc/openmosix.map содержит три, разделённых пробелами, поля:

openMosix-Node_ID	IP-адрес(или имя хоста)	Размер диапазона

Например, файл /etc/openmosix.map может выглядеть так:

1	node1		1
2	node2		1
3	node3		1
4	node4		1

или

1	192.168.1.1	1
2	192.168.1.2	1
3	192.168.1.3	1
4	192.168.1.4	1

или при помощи задания размера диапазона оба предыдущих примера эквивалентны:

1	192.168.1.1	4

openMosix увеличивает последний байт IP-адреса узла согласно его openMosix-Node_ID. Конечно же, если вы используете размер диапазона больше 1, вы должны использовать IP-адреса вместо имён хостов.

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

1	192.168.1.1	1
2	192.168.1.2	1
3	192.168.1.3	1
4	192.168.1.4	1
4	192.168.10.10	ALIAS

Тут узел с openMosix-Node_ID 4 имеет два сетевых интерфейса (192.168.1.4 + 192.168.10.10), которые оба видны openMosix.

	Важно
	Всегда будьте уверены в том, что запущены одинаковые версии openMosix с одинаковыми конфигурациями на каждом узле кластера!

Запустите openMosix утилитой setpe на каждом узле:

setpe -w -f /etc/openmosix.map

Выполните эту команду (которая будет описана позже в главе Пользовательские утилиты) на каждом узле своего openMosix кластера.

В качестве варианта вы можете взять скрипт openmosix, который может быть найден в директории со скриптами в пользовательских утилитах, и скопировать его в директорию /etc/init.d, выполнить для него chmod 0755 и затем использовать следующие команды под суперпользователем:

/etc/init.d/openmosix stop
/etc/init.d/openmosix start
/etc/init.d/openmosix restart

Сейчас инсталляция завершена: кластер запущен и работает :)

5.4.3. oMFS

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

Также UID (идентификаторы пользователей) и GID (идентификаторы групп) для всех файловых систем узлов кластера должны быть одинаковыми. Возможно, вы захотите достичь этого используя openldap. Опция ядра CONFIG_MOSIX_DFSA является необязательной, но, конечно же, необходимой, если должна использоваться DFSA . Для того, чтобы смонтировать oMFS на кластере, необходима дополнительная запись на каждом узле в файле /etc/fstab

со включенной DFSA :

mfs_mnt	/mfs	mfs	dfsa=1	0 0

с выключенной DFSA :

mfs_mnt	/mfs	mfs	dfsa=0	0 0

синтаксис fstab-записи:

[имя_устройства]	[точка_монтирования]	mfs	defaults	0 0

После монтирования точки монтирования /mfs на каждом узле файловая система любого узла становится доступной через директорию /mfs/openMosix-Node_ID/.

С помощью нескольких символических ссылок все узлы кластера могут получить доступ к одним и тем же данным, например, /work на node1:

на узле node2:	ln -s /mfs/1/work /work
на узле node3:	ln -s /mfs/1/work /work
на узле node3:	ln -s /mfs/1/work /work
...

Теперь на любом узле вы можете читать/писать из/в /work!

Следующие специальные файлы и директории исключаются из доступа через oMFS :

директория /proc
специальные файлы, которые не являются регулярными файлами, директориями или символическими ссылками (например, исключается /dev/hda1).

Создание ссылок, таких как

ln -s /mfs/1/mfs/1/usr

или

ln -s /mfs/1/mfs/3/usr

является неправильным.

Следующие системные вызовы поддерживаются без пересылки мигрировавшего процесса (который выполняет этот вызов на удалённом узле) назад на его UHN :

read, readv, write, writev, readahead, lseek, llseek, open, creat, close, dup, dup2, fcntl/fcntl64, getdents, getdents64, old_readdir, fsync, fdatasync, chdir, fchdir, getcwd, stat, stat64, newstat, lstat, lstat64, newlstat, fstat, fstat64, newfstat, access, truncate, truncate64, ftruncate, ftruncate64, chmod, chown, chown16, lchown, lchown16, fchmod, fchown, fchown16, utime, utimes, symlink, readlink, mkdir, rmdir, link, unlink, rename

Здесь даны ситуации, когда системные вызовы на DFSA -смонтированной файловой системе могут не работать:

различные конфигурации MFS /DFSA на узлах кластера
dup2, если второй файловый указатель не DFSA ^[1]
chdir/fchdir, если родительская директория не DFSA
пути, которые выходят за файловую систему DFSA
когда процесс, который выполняет системный вызов, находится под отладкой
если есть ждущие запросы для процесса, который выполняет системный вызов

Вслед за директориями /mfs/1/, /mfs/2/ и так далее вы также обнаружите некоторые другие директории:

Таблица 5.1. Другие директории

`/mfs/here`	Текущий узел, на котором выполнятся ваш процесс. ^[a]
`/mfs/home`	Ваш UHN .
`/mfs/magic`	Узел, который был использован системным вызовом `creat` (или `open` с опцией `O_CREAT`), в противном случае последний узел, на котором был успешно создан магический файл oMFS (это очень полезно при создании временных файлов с последующим их немедленном удалении).
`/mfs/lastexec`	Узел, на котором процесс успешно выполнил последний системный вызов `execve`.
`/mfs/selected`	Узел, который был выбран самим вашим процессом или одним из него предков (перед порождением этого процесса с помощью `fork`) при записи номера в `/proc/self/selected`.
^[a] Идея аналогична псевдо-ссылке `/proc/self`, только применяется для узлов.

Заметим, что каждый процесс имеет свои магические файлы. То есть, их содержимое зависит от процесса, их открывающего.

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

^[1] Т.е. выходит за пределы DFSA -смонтированной файловой системы MFS .

Пред.	Уровень выше	След.
5.3. Получение openMosix	Начало	5.5. RedHat и openMosix