openMosix HOWTO

openMosix HOWTO

openMosix HOWTO

Live free() or die()

Kris Buytaert

и другие. Перевод на русский:

Юрий Прушинский

Дмитрий Кацубо

История переиздания
Издание v1.0.2 29 july 2003
RPM Build
Издание v1.0.1 19 july 2003
Major updates
Издание v1.0 09 july 2003
Minor updates
Издание v1.0 11 may 2003
At last
Издание v1.0 RC 1 07 may 2003
Major Cleaning
Издание v0.95 04 april 2003
Replaced ClumpOS by PlumpOS
Издание v0.94 25 february 2003
Patches by Mirko Caserta
Издание v0.93 16 february 2003
Extra features and fixes
Издание v0.92 21 january 2003
Издание v0.91 27 september 2002
Издание v0.90 03 september 2002
Издание v0.71 26 August 2002
Spleling Fexis
Издание v0.70 22 August 2002
Stripped out empty parts, replaced Mosixview with openMosixView
Издание v0.50 6 July 2002
First openMosix HOWTO
Издание v0.20 5 July 2002
Latest Mosix HOWTO (for now)
Издание v0.17 28 June 2002
Издание v0.15 13 March 2002
Издание v0.13 18 Feb 2002
Издание ALPHA 0.03 09 October 2001

Содержание

Предисловие
I. Введение
1. Введение
1.1. openMosix HOWTO
1.2. Введение
1.3. Отказ от ответственности
1.4. Стратегия распространения
1.5. Новые версии данного документа
1.6. Обратная связь
2. Что же такое openMosix?
2.1. Ну очень краткое введение в кластеры
2.1.1. Ну очень краткое введение в кластеры
2.2. История появления проекта от и до
2.2.1. История развития
2.2.2. openMosix
2.2.3. Текущее состояние проекта
2.2.4. Какие приложения работают
2.3. openMosix в действии: Пример
2.4. Компоненты
2.4.1. Миграция процессов
2.4.2. Файловая система openMosix (oMFS)
2.4.3. Direct File System Access (DFSA)
2.5. Демонстрационная система openMosix
3. Преимущества и недостатки openMosix
3.1. Преимущества openMosix
3.2. Недостатки openMosix
II. Инсталляция openMosix
4. Требования и планирование
4.1. Требования к аппаратной части
4.2. Руководство по установке аппаратной части
4.3. Требования к программному обеспечению
4.4. Планирование вашего кластера
4.5. Классная комната
5. Инсталляции, специфические для дистрибутива
5.1. Инсталляция openMosix
5.2. Прежде чем вы получите openMosix
5.3. Получение openMosix
5.4. Общие инструкции openMosix
5.4.1. Компиляция ядра
5.4.2. Синтаксис файла /etc/openmosix.map
5.4.3. oMFS
5.5. RedHat и openMosix
5.6. SuSE и openMosix
5.7. Debian и openMosixView
5.8. openMosix и Gentoo
5.9. Другие дистрибутивы
6. Автообнаружение
6.1. Простая конфигурация
6.2. Компиляция автообнаружения
6.3. Устранение проблем с автообнаружением
7. Инсталляция кластера
7.1. Инсталляция кластеров
7.2. DSH – распределённый шелл (Distributed SHell)
III. Администрирование openMosix
8. Администрирование openMosix
8.1. Основы Администрирования
8.2. Конфигурация
8.3. Пользовательские утилиты
8.4. Кластерная маска
9. Тонкая Настройка Mosix
9.1. Введение
9.2. Создание мастер-узла
9.3. Оптимизация Mosix
9.4. Простое соединение каналов (Channel Bonding)
9.5. Updatedb
9.6. openMosix и FireWire
10. openMosixView
10.1. Введение
10.2. openMosixView по сравнению с Mosixview
10.3. Установка
10.3.1. Установка из .rpm-пакета
10.3.2. Установка из исходных текстов
10.3.3. Автоматический установочный скрипт
10.3.4. Компиляция вручную
10.3.5. Советы по компиляции
10.4. Использование openMosixView
10.4.1. Основная программа
10.4.2. Окно конфигурации
10.4.3. Окно advanced-execution
10.4.4. Командная строка
10.4.5. Окно host-chooser
10.4.6. Окно parallel host-chooser
10.5. Окно openMosixprocs
10.5.1. Введение
10.5.2. Окно migrator
10.5.3. Управление удалёнными процессами
10.6. openMosixcollector
10.7. openMosixanalyzer
10.7.1. окно load-overview
10.7.2. Статистическая информация об узле
10.7.3. окно memory-overview
10.7.4. openMosixhistory
10.8. openMosixmigmon
10.8.1. Описание
10.8.2. Подсказки:
10.8.3. Drag'n Drop!
10.9. openMosixView FAQ
10.10. openMosixView + SSH
11. Прочие проекты, связанные с openMosix
11.1. Введение
11.2. openMosixView
11.3. openMosixApplet
11.4. wmonload
11.5. openMosixWebView
12. Распространённые проблемы и ошибки
12.1. Введение
12.2. Процессы не хотят мигрировать!
12.3. Я не вижу все свои узлы!
12.4. Я постоянно получаю ошибки типа: No such process
12.5. DFSA? MFS?
12.6. Проблемы с Python
13. Советы и подсказки
13.1. Запертые процессы
13.2. О выборе процессов
13.3. Java и openMosix
13.4. openMosix и Hyperthreading
13.5. openMosix и брандмауэры
14. (стресс) Тестирование работы вашей openMosix-системы
14.1. Небольшой тестовый скрипт
14.2. Программа тестирования на Perl'е от Charles Nadeau
14.3. Стресс-тест openMosix
14.3.1. Общее описание
14.3.2. Подробное описание
14.3.3. Установка комплекта strestest
14.3.4. Пример запуска тестов
IV. Выполение приложений на openMosix
15. Улучшаем производительность компиляции.
15.1. Введение
16. Формирование изображений с помощью openMosix
16.1. Введение
16.2. Povray
17. Биоинформатика и openMosix
17.1. Введение
17.2. Blast
V. Разработка openMosix
18. Начальные сведения о внутреннем устройстве openMosix
18.1. Введение
A. Как сделать .rpm пакеты ядра openMosix
A.1. Как сделать .rpm пакеты ядра openMosix?
B. Дополнительная информация
B.1. IRC
B.2. Для дальнейшего чтения
B.3. Переводы
B.3.1. Китайский
B.3.2. Инспанский
B.4. Ссылки
B.5. Почтовые списки рассылок
C. Список разработчиков
D. Перевод на русский язык лицензии gnu на свободную документацию
Глоссарий
Предметный указатель

Предисловие

 

Самый лучший способ разобраться с предметом изучения, это написать о нём книгу…

 
--Benjamin Disraeli  

Введение

Глава 1. Введение

1.1. openMosix HOWTO

На самом деле всё началось с проекта 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/.

1.2. Введение

В данном документе приводится краткое описание 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 в лёгком стиле, потому что в мире (даже в той части мира, где талисманом служит рыгающий пингвин) и так полно скучной технической литературы. Поэтому кое-где в тексте вы можете встретить подобные комментарии.

1.3. Отказ от ответственности

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

Все авторские права принадлежат их соответствующим владельцам, в случае если это не указано отдельно. Использование терминов в данном документе не должно рассматриваться как посягательство на законность торгового или служебного знака. Авторское право на 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.

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

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

1.4. Стратегия распространения

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

1.5. Новые версии данного документа

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

1.6. Обратная связь

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

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

Глава 2. Что же такое openMosix?

2.1. Ну очень краткое введение в кластеры

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

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

2.1.1. Ну очень краткое введение в кластеры

2.1.1.1. Виды кластеров: HPC, Fail-over и Load-balancing

Существуют три основных вида кластеров: Fail-over (отказоустойчивые), Load-balancing (балансировочные, распределяющие нагрузку) и High Performance Computing (высокопроизводительные вычислительные). Наверное, наиболее распространёнными сейчас являются первые два типа кластеров.

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

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

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

Наиболее известный пример использования балансировочных и отказоустойчивых кластеров – это веб-фермы, базы данных или брандмауэры. Люди хотят чтобы сервис работал на 99,99999%, а интернет работает в режиме 24/24 7/7/ 365/365, а не как раньше, когда сервер можно было выключить, когда закрывается офис.

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

2.1.1.2. Суперкомпьютеры против кластеров

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

2.1.1.3. Модели кластеров [(N)UMA, PVM/MPI]

Существует несколько технологий реализации параллельных вычислений: (N)UMA, DSM, PVM и MPI – всё это различные схемы параллельных вычислений. Некоторые из них уже реализованы аппаратно, другие только в программном, а некоторые – и в том, и в другом виде.

(N)UMA: здесь машины пользуются разделяемым доступом к памяти, в которой они могут выполнять свои программы. В ядре Linux реализована поддержка NUMA, позволяющая получать доступ к разным областям памяти. При этом задача ядра использовать ту память, которая находится ближе к процессору, работающему с ней.

DSM уже реализована не только в программном виде, но и в аппаратном. Основная концепция DSM в организации абстрактного слоя для физически распределённой памяти.

Технологии PVM и MPI наиболее часто упоминаются, когда речь заходит о GNU/Linux Beowulf кластерах.

MPI – это открытая спецификация библиотеки передачи сообщений. Самой популярной реализацией MPI является MPICH. Второй по популярности после MPICH можно назвать LAM, также являющейся свободной реализацией MPI.

PVM – ещё один родственник MPI, широко используемый при создании Beowulf. PVM работает как пользовательская программа, поэтому никаких изменений в ядро системы вносить не нужно – выходит, что любой пользователь с минимальными правами может запустить PVM.

2.1.1.4. Роль openMosix

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

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

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

Такой механизм прозрачной миграции процессов позволяет представить кластер как одну большую SMP-систему с множеством процессоров на доступных узлах кластера (конечно, следует учитывать и количество процессоров в двух и четырёх процессорных системах). К тому же openMosix предоставляет оптимизированную файловую систему (oMFS) для HPC-приложений, которая, в отличие от NFS, поддерживает кэширование, отметки о времени и ссылки.

2.2. История появления проекта “от и до”

2.2.1. История развития

Если верить слухам, то Mosix появился из Moshe Unix. Вообще же Mosix начался как приложение для BSD/OS 3.0.

Выход MO6 для BSD/OS 3.0
Oren Laadan (orenl@cs.huji.ac.il)
Tue, 9 Sep 1997 19:50:12 +0300 (IDT)

Всем привет!
Мы рады объявить о выходе MO6 Version 3.0 Release 1.04 (beta-4) - совместимом
с BSD/OS 3.0, patch level K300-001 through M300-029.

MO6 - это шестипроцессорная версия расширения MOSIX для BSD/OS PC кластера.
Если у вас то двух до шести PC объединённых в ЛВС, то можете проверить
настоящую мультикомпьютерную среду при помощи MO6.

Дистрибутив MO6.
--------------------
MO6 доступен как в виде исходников, так и в двоичном виде. Он устанавливается
как патч для BSD/OS при помощи интерактивного скрипта.

MO6 можно скачать с http://www.cnds.jhu.edu/mirrors/mosix/
или с нашего сайта: http://www.cs.huji.ac.il/mosix/

Основные новшества данного релиза:
--------------------------------------
- Улучшение работы с памятью (предотвращение утечки) при миграции процессов.
- Улучшенная процедура установки.
- Расширенное управление миграцией.
- Улучшенные утилиты администрирования.
- Добавлены пользовательские утилиты.
- Добавлена документация и man-страницы.
- Динамическая конфигурация.

Пожалуйста, шлите свои комментарии и замечания на адрес mosix@cs.huji.ac.il.
-------------------

GNU/Linux был выбран в качестве основной платформы в 1999 году. В начале 1999 вышел Mosix MO6 Beta для ядра Linux 2.2.1. В конце 2001 года и начале 2002 появился проект openMosix – свободная версия Mosix (см. следующий параграф).

2.2.2. openMosix

openMosix – это ответвление выдающегося проекта Mosix, возглавляемого профессором Бараком (prof. Barak).

Моше Бар (Moshe Bar) также несколько лет участвовал в проекте Mosix и был одним из его менеджеров, а также главным менеджером коммерческой организации Mosix.

Позднее их мнения разошлись по поводу коммерческого будущего Mosix, и Моше создал новую кластерную компанию – Qlusters Inc., а профессор Барак решил пока не участвовать в этом предприятии (хотя серьёзно об этом подумывал), и вёл затяжные переговоры с инвесторами. Таким образом Mosix более не развивается как GPL проект. Тем не менее, проект оказался популярным среди пользователей (около 1000 установленных систем по всему миру), и Моше Бар решил продолжать развитие и поддержку проекта Mosix под новым именем и новой GPL2 лицензией: openMosix. Весь код в openMosix, который был заимствован из старого проекта Mosix, принадлежит Амнон Бараку (Copyright ? 2002 by Amnon Barak). Весь новый код принадлежит Моше Бар (Copyright ? 2002 by Moshe Bar).

В будущих версиях openMosix планируются серьёзные архитектурные изменения. В списках рассылки openMosix обсуждаются новые концепции авто-конфигурации, обнаружения узлов и новые пользовательские утилиты. Многие из этих новшеств уже реализованы, хотя некоторые, такие как DSM, ещё только планируется внести (на момент написания этого документа, март 2003).

В целях стандартизации и будущей совместимости /proc-интерфейс был переименован с /proc/mosix на /proc/hpc, а файл /etc/mosix.map переименован в /etc/hpc.map. Пока что он называется /etc/openmosix.map (фактически это первый конфигурационный файл, который считывает скрипт /etc/init.d/openmosix). Адаптированные пользовательские утилиты уже доступны для на странице проекта openMosix.

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

openMosix поддерживается многими компетентными людьми (см. sourceforge.net), работающими вместе по всему миру. Главной целью проекта является создание стандартизованного кластерного окружения для всех типов HPC-приложений.

Проект openMosix имеет свою веб-страницу с деревом CVS и списками рассылки для разработчиков и пользователей.

2.2.3. Текущее состояние проекта

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

На момент написания данной части документа в феврале 2003 была доступна версия openMosix 2.4.20 и пользовательские утилиты openMosix v0.2.4, включая и средства автообнаружения.

Но проект развивается очень быстро, так что ищите более новые версии на веб-сайте проекта openMosix.

2.2.4. Какие приложения работают

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

2.3. openMosix в действии: Пример

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

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

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

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

2.4. Компоненты

2.4.1. Миграция процессов

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

Миграция означает, что процесс разделяется на две части: пользовательскую и системную. Пользовательская часть будет перемещена на другой узел, в то время как системная останется на UHN. Системная часть иногда называется представительским процессом: такой процесс отвечает за разрешение большинства системных вызовов.

Задачей же openMosix является поддержка связи между этими двумя процессами.

2.4.2. Файловая система openMosix (oMFS)

oMFS является частью openMosix и позволяет обеспечить доступ к удалённым файловым системам кластера точно также, как и к любым другим смонтированным файловым системам. Таким образом, можно, к примеру, файловые системы всех узлов смонтировать в /mfs, и в результате получится, что содержимое /home третьего узла доступно с любой машины в каталоге /mfs/3/home.

2.4.3. Direct File System Access (DFSA)

И Mosix, и openMosix поддерживают кластерную файловую систему MFS с опцией DFSA (Direct File System Access), что позволяет получить доступ ко всем локальным и удалённым файловым системам узлов в Mosix или openMosix кластере (подробнее о MFS и DFSA смотри в главе DFSA? MFS?).

2.5. Демонстрационная система openMosix

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

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

Получить имя пользователя и пароль для работы с этим кластером можно отправив письмо по адресу: <om@majorlinux.com>

Глава 3. Преимущества и недостатки openMosix

3.1. Преимущества openMosix

Таблица 3.1. Преимущества openMosix

Не требует дополнительных программных пакетов.
Не требует внесения изменений в код вашего приложения.
Прост в установке и настройке.
Для систем, основанных на дистрибутиве RedHatLinux возможна установка в виде обычного .rpm-пакета командой: # rpm -Uvh openMosix*.rpm
Планируется поддержка DSM (ориентировочно в конце марта 2003).
Хорошая интеграция с openAFS.
Запланирован порт для архитектуры IA-64 и AMD-64.
oMFS значительно улучшена по сравнению с обычной MFS.
openMosix имеет более десяти сопутствующих проектов: openMosixView, openMosixWebView, openMosixApplet, RxLinux, PlumpOS, K12LTSP, LTSP и другие.
openMosix – это продукт, созданный самими пользователями, и поэтому близок пользователям по определению.
Демон автообнаружения узлов (autodiscovery/fail-over daemon) уже включен в состав пакета пользовательских утилит.
Поддержка псевдонимов для хостов с несколькими сетевыми интерфейсами.
Поддержка простейшей маршрутизации (на тот редкий случай, когда нежелательна широковещательная маршрутизация).
Кластерная маска позволяет указывать, на какие узлы процесс может мигрировать.

3.2. Недостатки openMosix

Таблица 3.2. Недостатки openMosix

Зависит от ядра.
Возникают проблемы при работе с разделяемой памятью (альфа релиз DSM должен появиться в конце марта 2003).
Возникают проблемы с производительностью при использовании Multiple Threads.
Не удастся достичь прироста в производительности единичного процесса, как например, веб-браузера на openMosix кластере. Такой процесс не будет распределять себя в кластере, хотя может мигрировать на более мощную машину в кластере.

Инсталляция openMosix

Глава 4. Требования и планирование

4.1. Требования к аппаратной части

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

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

4.2. Руководство по установке аппаратной части

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

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

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

4.3. Требования к программному обеспечению

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

4.4. Планирование вашего кластера

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

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

  • В окружении, которое называется серверным пулом, сервера являются частью кластера, в то время как рабочие станции – нет, они даже не имеют ядра openMosix. Если вы захотите выполнить приложение на кластере, вам нужно будет специальным образом зайти на эти сервера (logon). Тем не менее, ваша рабочая станция также будет оставаться “чистой”: ни один из удалённых процессов не будет мигрировать на неё.

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

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

4.5. Классная комната

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

Глава 5. Инсталляции, специфические для дистрибутива

5.1. Инсталляция openMosix

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

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

5.2. Прежде чем вы получите 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, так как он заботится о том, чтобы сделать вашу жизнь легче.

5.3. Получение openMosix

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

cvs -d:pserver:anonymous@cvs.openmosix.sourceforge.net:/cvsroot/openmosix login
cvs -z3 -d:pserver:anonymous@cvs.openmosix.sourceforge.net:/cvsroot/openmosix co linux-openmosix
cvs -z3 -d:pserver:anonymous@cvs.openmosix.sourceforge.net:/cvsroot/openmosix co userspace-tools

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

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

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.

[Important] Важно

Всегда будьте уверены в том, что запущены одинаковые версии 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.5. RedHat и 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, их можно будет поддерживать, поэтому не стесняйтесь написать автору короткое письмо, чтобы помочь ему содержать эту информацию обновлённой.

5.6. SuSE и openMosix

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

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

5.7. Debian и openMosixView

Инсталлирование 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.

5.8. openMosix и Gentoo

Сперва проинсталлируйте 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.

5.9. Другие дистрибутивы

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

Глава 6. Автообнаружение

6.1. Простая конфигурация

Демон автообнаружения (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 или похожий, перед попыткой использовать автоконфигурацию.

6.2. Компиляция автообнаружения

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

#define ALPHA

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

log_set_debug(DEBUG_TRACE_ALL);

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

% make clean
% make

6.3. Устранение проблем с автообнаружением

Иногда, однако, автообнаружение не работает так, как вам бы хотелось, например, узел не может видеть широковещательный трафик с других узлов. Это может случиться с некоторыми драйверами 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.

Глава 7. Инсталляция кластера

7.1. Инсталляция кластеров

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

7.2. DSH – распределённый шелл (Distributed SHell)

На время написания (Май 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

Содержание

8. Администрирование openMosix
8.1. Основы Администрирования
8.2. Конфигурация
8.3. Пользовательские утилиты
8.4. Кластерная маска
9. Тонкая Настройка Mosix
9.1. Введение
9.2. Создание мастер-узла
9.3. Оптимизация Mosix
9.4. Простое соединение каналов (Channel Bonding)
9.5. Updatedb
9.6. openMosix и FireWire
10. openMosixView
10.1. Введение
10.2. openMosixView по сравнению с Mosixview
10.3. Установка
10.3.1. Установка из .rpm-пакета
10.3.2. Установка из исходных текстов
10.3.3. Автоматический установочный скрипт
10.3.4. Компиляция вручную
10.3.5. Советы по компиляции
10.4. Использование openMosixView
10.4.1. Основная программа
10.4.2. Окно конфигурации
10.4.3. Окно advanced-execution
10.4.4. Командная строка
10.4.5. Окно host-chooser
10.4.6. Окно parallel host-chooser
10.5. Окно openMosixprocs
10.5.1. Введение
10.5.2. Окно migrator
10.5.3. Управление удалёнными процессами
10.6. openMosixcollector
10.7. openMosixanalyzer
10.7.1. окно load-overview
10.7.2. Статистическая информация об узле
10.7.3. окно memory-overview
10.7.4. openMosixhistory
10.8. openMosixmigmon
10.8.1. Описание
10.8.2. Подсказки:
10.8.3. Drag'n Drop!
10.9. openMosixView FAQ
10.10. openMosixView + SSH
11. Прочие проекты, связанные с openMosix
11.1. Введение
11.2. openMosixView
11.3. openMosixApplet
11.4. wmonload
11.5. openMosixWebView
12. Распространённые проблемы и ошибки
12.1. Введение
12.2. Процессы не хотят мигрировать!
12.3. Я не вижу все свои узлы!
12.4. Я постоянно получаю ошибки типа: No such process
12.5. DFSA? MFS?
12.6. Проблемы с Python
13. Советы и подсказки
13.1. Запертые процессы
13.2. О выборе процессов
13.3. Java и openMosix
13.4. openMosix и Hyperthreading
13.5. openMosix и брандмауэры
14. (стресс) Тестирование работы вашей openMosix-системы
14.1. Небольшой тестовый скрипт
14.2. Программа тестирования на Perl'е от Charles Nadeau
14.3. Стресс-тест openMosix
14.3.1. Общее описание
14.3.2. Подробное описание
14.3.3. Установка комплекта strestest
14.3.4. Пример запуска тестов

Глава 8. Администрирование openMosix

8.1. Основы Администрирования

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

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

8.2. Конфигурация

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

Таблица 8.1. Изменение параметров /proc/hpc

echo 1 > /proc/hpc/admin/block блокирует приём удалённых процессов
echo 1 > /proc/hpc/admin/bring возвращает все мигрировавшие процессы домой

Таблица 8.2. Параметры /proc/hpc/admin/

(двоичные файлы) config основной конфигурационный файл (генерируется утилитой setpe)
(плоские файлы) block разрешает/запрещает приём удалённых процессов
  bring возвращает домой все мигрировавшие процессы
  dfsalinks список текущих символических ссылок DFSA
  expel отсылает гостевые процессы домой
  gateways максимальное количество шлюзов
  lstay не даёт мигрировать локальным процессам
  mospe содержит идентификатор узла openMosix
  nomfs активирует/блокирует MFS
  overheads для тонкой настройки
  quiet останавливает сбор информации о балансировке нагрузки
  decay-interval интервал для сбора информации о балансировке нагрузки
  slow-decay по умолчанию 975
  fast-decay по умолчанию 926
  speed скорость по отношению к процессору PIII/1GHz
  stay активирует/блокирует автоматическую миграцию процессов

Таблица 8.3. Результат установки в 1 содержимого следующих файлов каталога /proc/hpc/decay/

clear обнуляет статистическую информацию
cpujob сообщает openMosix о том, что процесс нагружает процессор (cpu-bound)
iojob сообщает openMosix о том, что процесс активно использует ввод-вывод (io-bound)
slow принуждает openMosix медленнее собирать статистическую информацию
fast принуждает openMosix быстрее собирать статистическую информацию

Таблица 8.4. Информация о других узлах в кластере

/proc/hpc/nodes/[openMosix_ID]/CPUs отображает общее количество процессоров на узле
/proc/hpc/nodes/[openMosix_ID]/load нагрузка на данном узле для openMosix
/proc/hpc/nodes/[openMosix_ID]/mem доступная память для openMosix
/proc/hpc/nodes/[openMosix_ID]/rmem доступная память для Linux
/proc/hpc/nodes/[openMosix_ID]/speed скорость узла относительно процессора PIII/1GHz
/proc/hpc/nodes/[openMosix_ID]/status статус узла
/proc/hpc/nodes/[openMosix_ID]/tmem доступная память
/proc/hpc/nodes/[openMosix_ID]/util использование узла

Таблица 8.5. Дополнительная информация о локальных процессах

/proc/[PID]/cantmove причина, по которой процесс не поддаётся миграции
/proc/[PID]/goto указывает, на какой узел процесс должен мигрировать
/proc/[PID]/lock если процесс заблокирован на UHN
/proc/[PID]/nmigs сколько раз процесс мигрировал
/proc/[PID]/where где сейчас обрабатывается данный процесс
/proc/[PID]/migrate то же, что и значение goto для удалённых процессов
/proc/hpc/remote/from UHN процесса
/proc/hpc/remote/identity дополнительная информация о процессах
/proc/hpc/remote/statm статистика об использовании процессом памяти
/proc/hpc/remote/stats статистика об использовании процессом процессора

8.3. Пользовательские утилиты

Перечисленные ниже утилиты облегчают процесс администрирования кластеров 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]

Таблица 8.6. …более подробно

stay останавливает автомиграцию процессов
nostay автомиграция процессов (значение по умолчанию)
lstay удержание локальных процессов
nolstay позволяет миграцию локальных процессов
block блокирует приём гостевых процессов
noblock разрешает приём гостевых процессов
quiet отключает сбор информации о балансировке нагрузки
noquiet включает сбор информации о балансировке нагрузки
nomfs отключает MFS
mfs активизирует MFS
expel отсылает гостевые процессы
bring возвращает все мигрировавшие процессы домой
gettune отображает текущий параметр overhead
getyard отображает текущую принятую единицу измерения
getdecay отображает текущий параметр задержки
whois разрешает значения openMosix-ID, IP-адреса и имена хостов в кластере
getload отображает нагрузку (openMosix)
getspeed отображает скорость (openMosix)
status отображает текущий статус и конфигурацию
isup возвращает состояние узла: “up” или “down” (своего рода ping для openMosix)
getmem отображает свободную логическую память
getfree отображает свободную физическую память
getutil отображает информацию об использовании узла
setyard устанавливает новую единицу измерения
setspeed устанавливает новое значение скорости (openMosix)
setdecay устанавливает новый интервал задержки

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

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

Таблица 8.7. дополнительные опции для утилиты mosrun

nomig запускает команду, процессы которой не будут мигрировать
runhome запускает команду, замкнутую на своём UHN
runon запускает команду, которая сразу же мигрирует и замыкается на указанном узле
cpujob сообщает openMosix о том, что процесс нагружает процессор (cpu-bound)
iojob сообщает openMosix о том, что процесс активно использует ввод-вывод (io-bound)
nodecay выполняет команду и сообщает кластеру не обновлять статистику о балансировке нагрузки
slowdecay выполняет команду с пониженным интервалом сбора статистической информации о балансировке нагрузки
fastdecay выполняет команду с повышенным интервалом сбора статистической информации о балансировке нагрузки

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.

8.4. Кластерная маска

(автор: Moshe Bar)

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

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

  • /proc/[pid]/migfilter включает/отключает возможность фильтра миграции.

  • /proc/[pid]/mignodes – это бит-лист узлов. Позиция бита вычисляется как 2^(PE-1). Здесь PE – это номер узла.

  • /proc/[pid]/migpolicy – это политика фильтрации: 0=DENY (запретить): т.е. процесс может мигрировать на все узлы, кроме тех случаев, когда относительный бит в mignodes равен 1. 1=ALLOW (разрешить): процесс может мигрировать на все узлы, для которых относительный бит в mignodes равен 1.

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

Глава 9. Тонкая Настройка Mosix

9.1. Введение

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

9.2. Создание “мастер”-узла

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

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

mosctl setspeed [n]

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

mosctl getspeed

9.3. Оптимизация Mosix

Редакторский комментарий: Приведённые ниже команды могут изменяться в последующих версиях 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, и не забудьте похвастаться перед друзьями своим новым кластером.

9.4. Простое соединение каналов (Channel Bonding)

(при содействии Evan Hisey)

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

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

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

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

9.5. Updatedb

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

9.6. openMosix и FireWire

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

Глава 10. openMosixView

10.1. Введение

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

openMosixView – основное приложение для мониторинга+администрирования
openMosixprocs – окно для управления процессами
openMosixcollector – демон, который ведёт журнал сообщений узла и кластера в целом
openMosixanalyzer – анализирует информацию, собранную openMosixcollector
openMosixhistory – история процессов кластера

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

10.2. openMosixView по сравнению с Mosixview

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

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

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

  • адаптирован для автообнаружения openMosix

  • больше не использует файл /etc/mosix.map или какой другой файл-карту вообще

  • удалён некорректный код парсера .map-файла

  • переписаны все части/функции/методы в соответствии с правилами чистого C++

  • исправлены небольшие недочёты при работе с экраном

  • приложение MosixMem+Load заменено на openMosixanalyzer

  • … и множество других изменений

10.3. Установка

Требования

  • библиотека QT

  • права root!

  • rlogin, rsh (или ssh) на всех узлах кластера с доступом без пароля, пакет программ пользовательских утилит openMosix: mosctl, migrate, runon, iojob, cpujob… (их можно скачать с сайта www.openmosix.org)

В дистрибутиве 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.

10.3.1. Установка из .rpm-пакета

Скачайте последнюю версию .rpm-пакета openMosixView. Затем просто выполните следующую команду:

rpm -i openmosixview-1.4.rpm

Она установит двоичные файлы в каталог /usr/bin. Для удаления пакета выполните:

rpm -e openmosixview

10.3.2. Установка из исходных текстов

Скачайте самую последнюю версию openMosixView и распакуйте архив, например, в /usr/local/.

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

10.3.3. Автоматический установочный скрипт

Для его запуска просто перейдите в каталог openmosixview и выполните команду

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

10.3.4. Компиляция вручную

Установите переменную окружения QTDIR в соответствии с установленным в системе дистрибутивом QT, т.е.

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

или

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

10.3.5. Советы по компиляции

(отдельная благодарность пользователям, протестировавших компиляцию openMosixView/Mosixview на разных дистрибутивах Linux, и приславших свои советы по установке) Создайте ссылку /usr/lib/qt, указывающую на каталог установки QT-2.3.x, т.е. если QT-2.3.x установлен в /usr/local/qt-2.3.0:

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

Затем необходимо установить переменную окружения QTDIR

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

или

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

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

./configure
make

потом выполните эти же команды в подкаталогах openmosixcollector, openmosixanalyzer, openmosixhistory и openmosixviewprocs. Скопируйте получившиеся бинарные файлы в /usr/bin:

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

А также init-скрипт для openmosixcollector в ваш каталог init, т.е.

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

или

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

В заключение не забудьте скопировать двоичный файл openmosixprocs на каждый узел вашего кластера в /usr/bin/openmosixprocs:

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

Теперь можно запустить openmosixview:

openmosixview

10.4. Использование openMosixView

10.4.1. Основная программа

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

Окно openMosixView содержит такие элементы как индикатор, кнопку, ползунок (слайдер), поле с цифровым значением, индикатор выполнения и текстовые метки для каждого узла кластера. Цветовые индикаторы слева отображают openMosixview-ID и статус узла. Красная обозначает, что узел не активен, а зелёная наоборот – активное состояние.

Если вы нажмёте кнопку с IP-адресом узла, то появится конфигурационное окно. Оно содержит кнопки для выполнения наиболее общих команд mosctl. Ползунками же устанавливается значение openMosix-скорости для узла. Текущее значение скорости отображается в поле с цифровым значением.

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

Индикаторы выполнения посередине окна представляют картину нагрузку на каждом узле кластера. Они отображают лишь процентное соотношение, а не точное значение из /proc/hpc/nodes/xload.

Следующий индикатор показывает количество памяти на узлах, опять же в процентном отношении от общей доступной памяти на хостах. Ещё правее можно увидеть, сколько процессоров доступно в вашем кластере. В первой строке основного окна приложения есть кнопка с надписью “all-nodes”, как можно догадаться, с её помощью возможно задать единую конфигурацию для всех узлов.

Индикатор состояния вверху слева показывает, насколько хорошо работает механизм распределения нагрузки. 100% – это очень хорошее значение, и означает, что на всех узлах нагрузка примерно одинакова.

Для управления openMosixcollector и openMosixanalyzer нужно воспользоваться меню “collector” и “analyzer”. Эти две части openMosixView полезны для анализа состояния кластера в длительный промежуток времени.

10.4.2. Окно конфигурации

Это окно появится после нажатия кнопки “cluster-node”.

Данный диалог позволяет довольно просто и быстро произвести настройку любого хоста openMosix. Все команды выполняются на хостах по протоколам SSH или RSH (даже на локальном узле), так что для этого необходимо настроить возможность пользователю root подключаться без запроса пароля по этим протоколам для каждого узла (эта настройка подробно описана в документации к Beowulf и в главе openMosixView + SSH).

Доступны следующие команды:

automigration on/off
quiet yes/no
bring/lstay yes/no
exspel yes/no
openMosix start/stop

Если openMosixprocs корректно установлен на удалённых узлах кластера, то нажмите кнопку “remote proc-box”, чтобы открыть диалог openMosixprocs (proc-box) удалённой системы. Значения xhost+hostname и номер дисплея будут указывать на ваш localhost. Клиентская часть также работает по RSH или SSH (двоичный файл openmosixprocs должен быть в каталоге /usr/bin каждого узла кластера). openMosixprocs полезен в управлении программ, запущенных и выполняющихся на удалённых узлах, и будет описан подробнее далее в этом документе.

Если вы подключитесь к кластеру с удалённой машины, то вы можете ввести её локальное имя в поле ввода под “remote proc-box”. После этого openMosixprocs будет отображаться на вашей машине, а не на том узле, на котором вы зарегистрировались. В поле ввода есть история ввода значений, так что вам больше не надо будет каждый раз набирать имя хоста.

10.4.3. Окно advanced-execution

Если вы хотите запустить задания в кластере, то диалог "advanced execution" может сильно упростить эту задачу.

Нажмите кнопку “run-prog” и выберите программу для запуска; здесь же можно указать, как и где выбранная программа будет выполняться. Возможно несколько вариантов выполнения этой процедуры, давайте рассмотрим их подробнее.

10.4.4. Командная строка

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

Таблица 10.1. Варианты запуска

-no migration запускает задачу локально, без возможности миграции
-run home запускает задачу локально
-run on запускает задачу на узле, который можно выбрать посредством "host-chooser"
-cpu job запускает задачу на узле с интенсивным использованием процессора (host-chooser)
-io job запускает задачу с интенсивным использованием ввода-вывода (io) (host-chooser)
-no decay запускает задачу без задержек (no decay) (host-chooser)
-slow decay запускает задачу с пониженной задержкой (slow decay) (host-chooser)
-fast decay запускает задачу с повышенной задержкой (fast decay) (host-chooser)
-parallel запускает задачу параллельно на определённых или всех узлах (special host-chooser)

10.4.5. Окно host-chooser

Для всех задач, запускаемых не локально, можно использовать этот диалог. Для его запуска просто щёлкните на имени хоста. Значение openMosix-Node_ID отображается в виде lcd-цифры. Теперь щёлкните на execute для запуска задачи.

10.4.6. Окно parallel host-chooser

Здесь вы можете установить диапазон из начального и конечного узла. После этого запущенная команда будет выполняться на всех заданных узлах в диапазоне. Эту опцию возможно использовать и в обратном направлении.

10.5. Окно openMosixprocs

10.5.1. Введение

Этот менеджер процессов очень полезен при манипуляции процессами на вашем кластере.

Эту программу необходимо установить на каждом узле кластера!

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

Если дважды кликнуть на процессе из списка, то появится диалог управления миграцией процесса. Здесь есть опции для миграции процесса на удалённые узлы, отправка процессу сигналов SIGSTOP и SIGCONT, а также доступна манипуляция процессом наподобие команды renice.

Кнопка “manage procs from remote” открывает диалог, показывающий процессы, мигрировавшие на данный хост.

10.5.2. Окно migrator

Этот диалог появляется, если кликнуть на каком-либо процессе из окна списка процессов.

Окно openMosixview-migrator отображает все узлы вашего кластера, но предназначен для управления лишь одним процессом. Двойным щелчком на хосте из списка можно заставить процесс мигрировать на этот хост. После этого иконка выбранного процесса сменится на зелёную, означая, что процесс выполняется на удалённой машине.

Кнопка “home” позволяет отправить процесс на его UHN. В свою очередь, кнопкой “best” процесс можно отправить на наилучший из доступных узлов кластера. В целом, процесс миграции зависит от нагрузки, скорости, процессоров и того, что openMosix “думает” о каждом узле. Наиболее вероятно, что процесс мигрирует на хост с наиболее мощным процессором и значением скорости. Кнопка “kill” позволяет моментально уничтожить доступный процесс.

Чтобы временно остановить выполнение программы, просто нажмите кнопку “SIGSTOP”, а чтобы затем продолжить – нажмите “SIGCONT”. Ползунком, расположенным ниже, вы можете манипулировать приоритетом выбранного процесса (-20 значит очень высокий, 0 – нормально, а 20 – очень низкий).

10.5.3. Управление удалёнными процессами

Этот диалог появляется при нажатии кнопки “manage procs from remote

Здесь TabView отображает процессы, мигрировавшие на данный хост – т.е. процессы, пришедшие с других узлов кластера и выполняющиеся на машине, на которой запущен openMosixView. Точно также, как и в случае с окном migrator, процесс можно отправить на UHN кнопкой “goto home node” или на наилучший из доступных узлов кластера (кнопка “goto best node”).

10.6. openMosixcollector

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.

10.7. openMosixanalyzer

10.7.1. окно load-overview

Здесь отображается хронология нагрузки openMosix.

openMosixanalyzer позволяет вести беспрерывную историю нагрузки вашего кластера. Файлы журналов, создаваемые openMosixcollector, представляются в графическом виде, таким образом, можно получить полномасштабную картину всех процессов, происходящих на вашем кластере. Кроме того, openMosixanalyzer позволяет анализировать текущие “online” файлы. Файлы журналов располагаются в каталоге /tmp/openmosixcollector/* (архивы в /tmp/openmosixcollector[date]/*, где [date] – дата создания архива журнала), а чтобы просмотреть всю историю сразу, достаточно открыть лишь основной файл журнала. Время начала ведения журнала отображается сверху, а масштаб времени openMosixanalyzer равен полному дню (12 ч).

Если вы пользуетесь openMosixanalyzer для просмотра “online”-файлов, то вам, возможно, окажется полезна функция обновления. Для её включения нужно отметить опцию “refresh”.

Если нагрузка кластера в пределах нормы, то линия графика чёрного цвета. Если же нагрузка >75, то линия красная. Всё это так называемые значения openMosix--informations. openMosixanalyzer получает эти значения из файлов /proc/hpc/nodes/[openMosix-Node_ID]/*.

Кнопка “Find-out” для каждого узла показывает некоторые полезные статистические данные. Если кликнуть на неё, то появится небольшое окно, содержащее показатели средней нагрузки, использования памяти и подобные статистические и динамические полезные данные об определённом узле или о кластере в целом.

10.7.2. Статистическая информация об узле

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

10.7.3. окно memory-overview

Здесь представляется обзор использования памяти (Memory-overview) в openMosixanalyzer

При помощи Memory-overview в openMosixanalyzer вы можете анализировать историю использования памяти аналогично Load-overview. Файлы журналов, создаваемые openMosixcollector, также отображаются в графическом виде, так что получается полномасштабный обзор всего происходящего в кластере. Программа анализирует текущие файлы журналов, но также через меню возможно открывать и архивы журналов.

Вся отображаемая информация берётся из следующих файлов:

/proc/hpc/nodes/[openMosix-ID]/mem.
/proc/hpc/nodes/[openMosix-ID]/rmem.
/proc/hpc/nodes/[openMosix-ID]/tmem.

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

10.7.4. openMosixhistory

показывает список процессов, выполнявшихся ранее

openMosixhistory позволяет посмотреть, какой процесс выполнялся ранее на любом из узлов. openMosixcollector сохраняет список этих процессов с того хоста, на котором он был запущен, и именно эту информацию вы и можете просмотреть при помощи openMosixhistory. Частоту сохранения можно изменить при помощи ползунка в openMosixhistory.

openMosixhistory умеет анализировать текущие файлы журналов, но также возможно открывать и архивы журналов через меню.

10.8. openMosixmigmon

10.8.1. Описание

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

-> nodes-circle.

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

-> main process-circle

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

10.8.2. Подсказки:

Если навести курсор мыши на процесс, то появится его PID и команда.

10.8.3. Drag'n Drop!

openMosixmigmon полностью поддерживает механизм Drag'n Drop. Вы можете брать любой процесс и бросать его на любой из узлов (обозначенных пингвинами) – таким образом, этот процесс будет мигрировать туда. Если дважды кликнуть на процесс на удалённом узле, то он сразу же будет отправлен на свой UHN.

10.9. openMosixView FAQ

10.9.1. У меня не получается скомпилировать openMosixViewopenMosixView на моей системе?
10.9.2. Можно ли использовать openMosixViewopenMosixView с SSH?
10.9.3. Я запускаю openMosixViewopenMosixView, но появляется только splash-screen. В чём дело?
10.9.4. У меня не работает openMosixviewprocs/mosixview_client!
10.9.5. Почему кнопки в диалоге openMosixViewopenMosixView-configuration не нажаты в соответствии с конфигурацией?
10.9.1.

У меня не получается скомпилировать openMosixView на моей системе?

Для начала следует проверить, установлены ли библиотеки QT >= 2.3.x. Также проверьте, установлена ли переменная окружения QTDIR в соответствии с каталогами установки, как описано в INSTALL-файле. В версиях < 0.6 можно выполнить команду make clean и удалить два файла: /openmosixview/Makefile и /openmosixview/config.cache, и попробовать скомпилировать ещё раз. Если у вас всё равно возникли какие-либо проблемы при сборке, то пишите о них в openMosixview-mailinglist (или сразу мне). Смотри также главу Советы по компиляции

10.9.2.

Можно ли использовать openMosixView с SSH?

Да, начиная с версии 0.7 появилась встроенная поддержка ssh. Для работы по SSH необходим доступ без запроса пароля к каждому узлу кластера (аналогично как и в случае для rsh).

10.9.3.

Я запускаю openMosixView, но появляется только splash-screen. В чём дело?

Не запускайте openMosixView фоновым процессом (т.е. командой openmosixview &). Также, вероятно, у вас нет доступа без запроса пароля для пользователя root по RSH/SSH (в зависимости от того, что вы используете) к узлам. Попробуйте выполнить rsh имя_хоста от имени root. Вместо запроса пароля вы должны попасть сразу в оболочку (в случае с SSH надо выполнить ssh имя_хоста от имени root). В кластере вы должны работать под учётной записью root, поскольку только этот пользователь имеет право выполнять административные команды. Имейте в виду, что по умолчанию openMosixView работает по RSH! Так что если в вашем кластере установлен только ssh, то отредактируйте (либо создайте) файл /root/.openMosixview и напишите в нём “1111”. Это основной конфигурационный файл для openMosixView, а последняя “1” в нём означает “использовать ssh вместо rsh”. Таким образом, при старте openMosixView будет сразу работать по SSH.

10.9.4.

У меня не работает openMosixviewprocs/mosixview_client!

openMosixview-client выполняется через rsh (или ssh) на удалённой машине. Поэтому он должен быть установлен в /usr/bin на каждом узле. Если вы используете RSH, попробуйте выполнить xhost+имя_хоста; rsh имя_хоста /usr/bin/openMosixview_client -display имя_локальной_машины:0.0, или, если вы работаете по SSH: xhost +имя_хоста; ssh имя_хоста /usr/bin/openMosixview_client -display имя_локальной_машины:0.0. Если всё работает, что openMosixView тоже будет работать. В случае если openMosixView завершается с сообщением “segmentation fault”, то скорее всего вы используете старую версию openMosixView/Mosixview. Такое случается из-за ошибки парсера файла mosix.map (который уже полностью удалён из openMosixView!!!), версии openMosixView 1.2+ и Mosixview >1.0 работают стабильно.

10.9.5.

Почему кнопки в диалоге openMosixView-configuration не нажаты в соответствии с конфигурацией?

(automigration on/off, blocking on/off …) – на самом деле я хотел сделать так, чтобы они были уже нажаты заранее. Вся проблема в том, как получить информацию с узла. Для этого надо подключаться к каждому узлу кластера, потому что эти установки разные для каждого из них (по моему мнению). Статус каждого узла хранится в /proc/hpc/admin. Если кто-нибудь из читателей знает хороший способ сбора этой информации с узлов, то я буду рад, если вы сообщите мне о нём.

10.10. openMosixView + SSH

(это 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, но не можете подключиться к узлам без запроса пароля).



[2] При настройке логина по SSH без запроса пароля необходимо сгенерировать ключ с пустой фразой! – прим. перев.

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

[4] Если у вас ничего не получилось, то на сайте howto.ipng.be есть более детальное описание процесса настройки беспарольного входа по SSH – прим. перев.

Глава 11. Прочие проекты, связанные с openMosix

Содержание

11.1. Введение
11.2. openMosixView
11.3. openMosixApplet
11.4. wmonload
11.5. openMosixWebView

11.1. Введение

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

11.2. openMosixView

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

11.3. openMosixApplet

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

11.4. wmonload

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

11.5. openMosixWebView

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.

Глава 12. Распространённые проблемы и ошибки

12.1. Введение

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

12.2. Процессы не хотят мигрировать!

Помогите, процесс 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.

[Warning] Внимание

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

12.3. Я не вижу все свои узлы!

Для начала убедитесь, что вы используете одинаковые версии ядра на каждой машине. Под этим подразумевается именно версия ядра, а не набор опций и модулей, включенных в него для поддержки аппаратных ресурсов узла. То же самое относится и к установке 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' вы использовали одинаковое значение на всех узлах.

12.4. Я постоянно получаю ошибки типа: No such process

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

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

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

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

12.5. DFSA? MFS?

Многие часто путаются, говоря об 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

12.6. Проблемы с Python

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

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

Глава 13. Советы и подсказки

13.1. Запертые процессы

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

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

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

13.2. О выборе процессов

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

13.3. Java и openMosix

Программы, использующие 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

13.4. openMosix и Hyperthreading

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

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

13.5. openMosix и брандмауэры

Очень часто возникают вопросы относительно 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_daemonUDP. Следовательно, TCP/4660 и UDP/5428.

Глава 14. (стресс) Тестирование работы вашей openMosix-системы

14.1. Небольшой тестовый скрипт

Самый быстрый способ проверить 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 на домашнем узле.

14.2. Программа тестирования на Perl'е от Charles Nadeau

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

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

Charles wrote this little program (in Perl) to stress test his home cluster (3 P200MMX and a P166). It is a program simulating different sets of stocks in a portfolio for a given period of time. The code is well documented and it should be easy to add/remove stocks and change the average monthly yield and standard deviation for each stock. Since the problem of portfolio optimization cannot be solved analytically, it simulate a lot of portfolios and report the results at the end. Please note that this program does not take stock correlation into account. It is not finished yet but it's a good start. I plan to add more code at the end of the program to improve the reporting format of the data (generating SVG graph on the fly). But the simulation part works very well. In order to take advantage of the parallelism offered by openMosix, it uses the Perl module Parallel::?ForkManager (from CPAN) to span threads that openMosix can then assign to all the machines of the cluster (it also require another module for the statistical calculations, don't forget to install both, I provide the URLs in the comments of the code). Take a look at it and tell me what you think. Cheers!

#! /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;

}

14.3. Стресс-тест openMosix

(автор: Matt Rechenburg)

14.3.1. Общее описание

Стресс-тест сделан с целью тестирования openMosix кластера и ядра. Он выполняет несколько тестов приложений и ядра на предмет устойчивости, и различных опций openMosix (таких как миграция процессов, MFS…). В процессе теста кластер нагружается по максимуму, так что рекомендуется остановить другие приложения перед запуском теста. По окончании теста генерируется подробный отчёт о каждой протестированной компоненте.

14.3.2. Подробное описание

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

  • distkeygen: Эта программа генерирует 4000 RSA ключей длиной 1024 бит каждый. При этом она распределяется на столько процессов, сколько процессоров в вашем openMosix кластере.

    Требования: компилятор gcc и библиотека OpenSSL. Copyright ? 2001 by Ying-Hung Chen (GPL) http://www.yingternet.com/mosix

  • portfolio – это скрипт на perl, который симулирует портфолио для разных структур в заданный период времени. Этот метод основан на книге "The intelligent asset allocator", автор William Bernstein.

    Программа распространяется по лицензии GPL. Copyright ? 2002 by Charles-E. Nadeau Ph.D. charlesnadeau@hotmail.com.

  • eatmem: Программа просто вычисляет синус+корень из числа 1000000 раз и выводит всё в файл (который разрастается при этом неимоверно). Этот тест запускается столько раз, сколько процессоров в вашем кластере.

  • forkit: Тест forkit похож на тест eatmem, но использует ветвление при создании множественных процессов (3*[количество_процессоров_в_кластере]) и не пишет ничего в файлы.

  • mfstest: Этот тест создаёт 10MB файл и копирует его по узлам туда-сюда. Предназначен для проверки возможностей oMFS.

  • kernel syscall test: Linux Test Project – это совместный проект SGI, IBM, OSDL и Bull, целью которого является создание набора тестов для open source сообщества, который проверяет надёжность и устойчивость Linux. The Linux Test Project представляет собой набор утилит для тестирования ядра Linux. Все заинтересовавшиеся могут присоединиться к проекту. За подробностями обращайтесь на: http://ltp.sf.net.

  • moving: Скрипт moving.sh перемещает start_openMosix_test.sh по всем узлам кластера во время выполнения всего стресс-теста. Таким образом, start_openMosix_test.sh мигрирует по узлам каждую минуту во время всего теста. В зависимости от того, сколько будет выполняться весь тест, программа может мигрировать 20-40 раз.

14.3.3. Установка комплекта strestest

Сначала загрузите .rpm или исходники с http://www.openmosixview.com/omtest/

  • при использовании исходных кодов:

    Распакуйте openMosix stress-test следующими командами, например, в /usr/local:

    gunzip omtest.tar.gz
    tar -xvf omtest.gz
    

    Затем перейдите в каталог /usr/local/omtest и выполните:

    ./compile_tests.sh
    

    Это установит необходимые модули perl и скомпилирует тестовые программы. Установка модулей требует прав root, но после установки можно запускать openMosix stress-test и с правами обычного пользователя (может понадобиться удалить старые временные файлы, созданные с правами пользователя root, т.к. обычный пользователь не сможет перезаписать их). После этого можно запускать тест командой:

    ./start_openMosix_test.sh
    

  • при использовании .rpm пакета

    Для успешной установки omtest.rpm необходимо наличие в системе сompat-libstdc++-7.3-2.96.110 (Для дистрибутива RedHat 8.0). Установить можно вот такой командой:

    rpm -ihv omtest.rpm
    

    После этого можно запускать openMosix stress test командой:

    start_openMosix_test.sh
    

    (.rpm пакет будет установлен в /usr/local/omtest). (Учтите, что также будут установлены и модули для perl).

14.3.4. Пример запуска тестов

[root@dhcp51 omtest]# ./start_openMosix_test.sh

starting the openMosix stress test now!

the results will be saved in: /tmp/openMosix-stress-test-report-03/16/2003-11:27:02.txt

oMFS is not mounted at /mfs! oMFS-test will be disabled.
Please mount oMFS before running this openMosix-test
You will find instructions how to configure and use oMFS at:
http://howto.ipng.be/openMosix-HOWTO/x222.htm#AEN243

(return to continue, ctrl-c for cancel)

Выполение приложений на openMosix

Глава 15. Улучшаем производительность компиляции.

Содержание

15.1. Введение

15.1. Введение

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

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

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

Глава 16. Формирование изображений с помощью openMosix

Содержание

16.1. Введение
16.2. Povray

16.1. Введение

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

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

16.2. Povray

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, которые у меня были доступны.

Глава 17. Биоинформатика и openMosix

Содержание

17.1. Введение
17.2. Blast

17.1. Введение

17.2. Blast

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

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

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

Разработка openMosix

Глава 18. Начальные сведения о внутреннем устройстве openMosix

Содержание

18.1. Введение

18.1. Введение

(автор: Amit Shah)

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

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

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

  • hpc/badops.c: Единый файл, обрабатывающий неудачные операции: в основном возвращает коды ошибок.

  • hpc/balance.c: Код балансировки (нагрузка + использование памяти).

  • hpc/comm.c: Настройка внутрикластерного взаимодействия.

  • hpc/config.c: Код конфигурации для openMosix: то есть то, что выполняется после того, как вы запустили startup script.

  • hpc/decay.c: Задержка (возраст) статистики и информации, собираемой с других узлов.

  • hpc/deputy.c: Код, выполняемый как вспомогательный: удалённые системные вызовы служб (т.е. после того, как процесс мигрировал), сигналы и т.п.

  • hpc/dfsa.c: Код DFSA: уровень абстракции распределённой файловой системы.

  • hpc/div.c: Алгоритмы, отвечающие за деление с плавающей точкой.

  • hpc/export.c: Экспорт символов, необходимых для других файлов.

  • hpc/freemem.c: Необходим для отслеживания свободной и доступной памяти, а также её освобождения при необходимости. Большая часть кода заимствована из кода Linux mm/.

  • hpc/hpcadmin.c: Настройка административных опций openMosix (посредством /proc/hpc).

  • hpc/hpcproc.c: Здесь обрабатывается код /proc/hpc.

  • hpc/info.c: info-демон: отправляет и получает (multicast) информацию о нагрузке+использовании памяти в кластере.

  • hpc/init.c: Код инициализации: стартует демоны и т.п.

  • hpc/kernel.c: Основной код: здесь определяются все основные алгоритмы, решения и т.п.

  • hpc/load.c: Вычисление локальной нагрузки.

  • hpc/mig.c: Код, управляющий миграцией. Отвечает за любую миграцию: подчинённая->удалённая, удалённая->подчинённая; удалённая->удалённая.

  • hpc/prequest.c: обрабатывает запросы процессов: сигналы, память и т.п.

  • hpc/remote.c: Код, который исполняет процесс, будучи перемещённым: системные вызовы, передача управления и т.п.

  • hpc/rinode.c: всё, что относится к разделу fs/: в основном используется для DFSA

  • hpc/service.c: настройка демонов, выделение памяти и т.п.

  • hpc/syscalls.c: здесь происходит обработка удалённых системных вызовов

  • hpc/ucache.c: работа с ucache: в основном касается mm/ и fs/.

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

Приложение A. Как сделать .rpm пакеты ядра openMosix

A.1. Как сделать .rpm пакеты ядра openMosix?

Руководство “шаг-за-шагом” от Mirko Caserta для менеджера релизов и для “сделай сам” авантюрного создателя пакетов .rpm.

  1. Установите RedHat 8 на вашей машине. Эта платформа до настоящего времени используется для получения .rpm, и известно, что она выполняет эту работу хорошо.

  2. Получите обновлённую копию модуля linux-openmosix из репозитория CVS openMosix, детали см. на http://sourceforge.net/cvs/?group_id=46729.

  3. Получите архив .tar для исходников ядра Linux, которые мы собираемся пропатчить, и разместите его в /usr/src/redhat/SOURCES: предполагая, что мы говорим о ядре 2.4.20, получите linux-2.4.20.tar.bz2 с одного из многих зеркал http://www.kernel.org/ по всему миру.

  4. Распакуйте архив .tar в /usr/src, то есть:

    # cd /usr/src
    # tar vxjf redhat/SOURCES/linux-2.4.20.tar.bz2
    

  5. Создайте символическую ссылку на директорию, куда вы вытянули из CVS модуль linux-openmosix, например:

    # ln -s /home/mcaserta/src/linux-openmosix/linux-openmosix \
     /usr/src/linux-openmosix
    

  6. Скопируйте .spec файл и все .config файлы, которые могут быть найдены в этой директории, в /usr/src/redhat/SOURCES, то есть:

    # cp /usr/src/linux-openmosix/configs/openmosix-kernel.spec \
     /usr/src/redhat/SOURCES
    
    # cp /usr/src/linux-openmosix/configs/*.config \
     /usr/src/redhat/SOURCES
    

  7. Теперь настало время проверить номера версий, прежде чем мы сделаем патч-файл: удостоверьтесь, что первые строки файлов /usr/src/linux-openmosix/Makefile и /usr/src/redhat/SOURCES/openmosix-kernel.spec имеют правильные версию ядра и номер ревизии openMosix.

  8. Хорошо, время сделать патч (предполагаю, что мы выпускаем патч для ядра Linux 2.4.20 и 3-го релиза openMosix):

    # cd /usr/src
    # diff -Naur --exclude=CVS --exclude=configs \
     linux-2.4.20 linux-openmosix > \
     /usr/src/redhat/SOURCES/openMosix-2.4.20-3
    # bzip2 /usr/src/redhat/SOURCES/openMosix-2.4.20-3
    

  9. На данный момент ваша директория /usr/src/redhat/SOURCES должна выглядеть похожей на:

    # ls /usr/src/redhat/SOURCES
    kernel-2.4.20-athlon.config
    kernel-2.4.20-athlon-smp.config
    kernel-2.4.20-i386.config
    kernel-2.4.20-i686.config
    kernel-2.4.20-i686-smp.config
    linux-2.4.20.tar.bz2
    openMosix-2.4.20-3.bz2
    openmosix-kernel.spec
    

  10. Теперь вам всего лишь нужно rpmbuild всё: что я обычно делаю, это

    # cd /usr/src/redhat/SOURCES
    # rpmbuild -ba --target i386 openmosix-kernel.spec
    # rpmbuild -bb --target i686 openmosix-kernel.spec
    # rpmbuild -bb --target athlon openmosix-kernel.spec
    

    но вы можете легко построить все .rpm, запуская

    # rpmbuild -ba --target all_x86 openmosix-kernel.spec
    

  11. После того, как rpmbuild выполнит свою работу, вы должны будете получить следующие файлы в директории /usr/src/redhat:

    RPMS/i386/openmosix-kernel-2.4.20-openmosix3.i386.rpm               1
    RPMS/i686/openmosix-kernel-2.4.20-openmosix3.i686.rpm           2
    RPMS/i686/openmosix-kernel-smp-2.4.20-openmosix3.i686.rpm       3
    RPMS/athlon/openmosix-kernel-2.4.20-openmosix3.athlon.rpm       4
    RPMS/athlon/openmosix-kernel-smp-2.4.20-openmosix3.athlon.rpm   5
    RPMS/i386/openmosix-kernel-source-2.4.20-openmosix3.i386.rpm    6
    SRPMS/openmosix-kernel-2.4.20-openmosix3.src.rpm                7
    SOURCES/openMosix-2.4.20-3.gz                                   8
    

    1 двоичный пакет ядра для i386 UP машин
    2 двоичный пакет ядра для i686 UP машин
    3 двоичный пакет ядра для i686 SMP машин
    4 двоичный пакет ядра для athlon UP машин
    5 двоичный пакет ядра для athlon SMP машин
    6 исходный пакет ядра для любой x86 машины (в основном это необходимо, если вам нужны заголовочные файлы ядра openMosix)
    7 исходный пакет ядра
    8 патч-файл ядра, сжатый gzip

  12. Магическое заклинание для извлечения всех файлов из .srpm:

    # rpm2cpio openmosix-kernel-....src.rpm | cpio -di
    

Отдельное спасибо Martin Huy за помощь, когда я пытался собрать все вещи воедино.

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

Приложение B. Дополнительная информация

B.1. IRC

Некоторые энтузиасты openMosix проводят время online, помогая людям в IRC. Нас можно найти на irc://irc.freenode.net/#openMosix. Всего лишь присоединяйтесь к нам для обсуждения ваших проблем, идей и других вещей об openMosix.

B.2. Для дальнейшего чтения

B.3. Переводы

Некоторые люди работали над частичным переводом этого HOWTO или обычной документации openMosix на свой язык.

Если вы работаете над переводом этого документа, дайте нам знать.

B.3.1. Китайский

Ding Wei написал некоторые документы на Китайском, вы можете прочитать их тут: http://software.ccidnet.com/pub/disp/Article?columnID=732&articleID=25795&pageNO=1

Это локальная копия документов на Китайском в PDF.

B.3.2. Инспанский

Вместе с некоторыми коллегами Miquel Catalán Coïthas работает над переводом HOWTO на испанский: http://w3.akamc2.net/

B.4. Ссылки

B.5. Почтовые списки рассылок

Приложение C. Список разработчиков

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

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

Scot W. Stevenson

Должен поблагодарить Scot W. Stevenson за всё проделанное им задолго до того, как я перенял у него эстафету по этому HOWTO. Он положил хорошее начало этому документу.

Assaf Spanier

работал вместе со Scott'ом над разработкой и главами этого HOWTO, а позднее предложившим и мне помощь в работе над этим документом.

Matthias Rechenburg

Нужно поблагодарить Matthias'а Rechenburg'а за работу, проделанную над openMosixView и сопутствующую документацию, которую мы включили в данный HOWTO.

Jean-David Marrow

является автором Clump/OS, помогал с документированием своего дистрибутива в этом HOWTO.

Bruce Knox

занимается поддержкой веб-сайта openMosix, помогает как может, в том числе и в плане обратной связи!

Evan Hisey

благодарность за большой вклад документации в WIKI.

Charles Nadeau

благодарность за большой вклад документации в WIKI.

Louis Zechter

Moshe Bar

…за написание кода и и за посильную помощь в документации!

Amit Shah

…за начало главы о внутреннем устройстве openMosix.

Mirko Caserta

…за присланные исправления к этому howto.

Ramon Pons

…за перечитывание howto и присланные советы.

Приложение D. Перевод на русский язык лицензии gnu на свободную документацию

автор перевода Елена Тяпкина [ tiapkina@hotmail.com ], 09-Aug-2001

This is an unofficial translation of the GNU Free Documentation License (GFDL) into Russian. It was not published by the Free Software Foundation, and does not legally state the distribution terms for works that uses the GFDL - only the original English text of the GFDL does that. However, we hope that this translation will help Russian speakers understand the GFDL better.

Настоящий перевод Лицензии GNU на Свободную Документацию (GFDL) на русский язык не является официальным. Он не публикуется Free Software Foundation и не устанавливает имеющих юридическую силу условий для распространения произведений, которые распространяются на условиях GFDL. Условия, имеющие юридическую силу, закреплены исключительно в аутентичном тексте GFDL на английском языке. Я надеюсь, что настоящий перевод поможет русскоязычным пользователям лучше понять содержание GFDL.

Текст GFDL на английском языке вы можете прочитать здесь http://www.gnu.org/copyleft/fdl.html

D.1. Gnu free documentation license

Версия 1.1, март 2000г.

Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA Каждый вправе копировать и распространять экземпляры настоящей Лицензии без внесения изменений в ее текст.

D.1.1. Преамбула

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

Настоящая Лицензия относится к категории "copyleft" [1]. Это означает, что все произведения, производные от документа, должны быть свободными в соответствии с концепцией "copyleft". Настоящая Лицензия дополняет General Public License GNU, которая является лицензией "copyleft", разработанной для свободного программного обеспечения.

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

D.1.2. Сфера действия, термины и их определения

Условия настоящей Лицензии применяются к любому руководству пользователя или иному произведению, которое в соответствии с уведомлением, помещенным правообладателем, может распространяться на условиях настоящей Лицензии. Далее под термином "Документ" понимается любое подобное руководство пользователя или произведение. Лицо, которому передаются права по настоящей Лицензии, в дальнейшем именуется "Лицензиат".

"Модифицированная версия Документа" - любое произведение, содержащее Документ или его часть, скопированные как с изменениями, так и без них и/или переведенные на другой язык.

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

"Неизменяемые разделы" - определенные Второстепенные разделы, названия которых перечислены как Неизменяемые разделы в уведомлении Документа, определяющем лицензионные условия.

"Текст, помещаемый на обложке" - определенные краткие строки текста, которые перечислены в уведомлении Документа, определяющем лицензионные условия, как текст, помещаемый на первой и последней страницах обложки.

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

Форматы, в которых может быть представлен Прозрачный экземпляр Документа, включают простой формат ASCII без разметки, формат ввода Texinfo, формат ввода LaTeX, SGML или XML с использованием общедоступного DTD, а также соответствующий стандартам простой формат HTML, предназначений для внесения модификаций человеком. "Непрозрачные" форматы включают в себя PostScript, PDF, форматы, которые можно прочитать и редактировать только с помощью текстовых редакторов, права на использование которых свободно не передаются, форматы SGML или XML, для которых DTD или инструменты для обработки не являются общедоступными, а также генерируемый машиной HTML, который вырабатывается некоторыми тесктовыми редакторами исключительно в целях вывода.

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

D.1.3. Копирование без внесения изменений

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

Лицензиат вправе сдавать экземпляры Документа в прокат на условиях, определенных в предыдущем абзаце, или осуществлять публичный показ экземпляров Документа.

D.1.4. Тиражирование

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

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

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

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

D.1.5. Внесение изменений

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

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

Лицензиат вправе дополнить Модифицированную версию новым разделом "Одобрения" при условии, что в него включены исключительно одобрения Модифицированной версии Лицензиата третьими сторонами, например оценки экспертов или указания, что текст Модифицированной версии был одобрен организацией в качестве официального определения стандарта.

Лицензиат вправе дополнительно поместить на обложке Модифицированной версии Текст, помещаемый на обложке, не превышающий пяти слов для первой страницы обложке и 25 слов для последней страницы обложки. К Тексту, помещаемому на обложке, каждым лицом непосредственно или от имени этого лица на основании соглашения с ним может быть добавлено только по одной строке на первой и на последней страницах обложки. Если на обложке Документа Лицензиатом от своего имени или от имени лица, в интересах которого действует Лицензиат, уже был помещен Текст, помещаемый на обложке, Лицензиат не вправе добавить другой Текст. В этом случае Лицензиат вправе заменить старый текст на новый с разрешения предыдущего издателя, который включил старый текст в издание.

По настоящей Лицензии автор(ы) и издатель(и) Документа не передают право использовать их имена и/или наименования в целях рекламы или заявления или предположения, что любая из Модифицированных Версий получила их одобрение.

D.1.6. Объединение документов

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

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

В произведении, возникшем в результате объединения, Лицензиат обязан объединить все разделы "История" из различных первоначальных Документов в один общий раздел "История". Подобным образом Лицензиат обязан объединить все разделы с названием "Благодарности" и "Посвящения". Лицензиат обязан исключить из произведения все разделы под названием "Одобрения".

D.1.7. Сборники документов

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

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

D.1.8. Подборка документа и самостоятельных произведений

Размещение Документа или произведений, производных от Документа, с другими самостоятельными документами или произведениями на одном устройстве для хранения информации или носителе не влечет за собой возникновения Модифицированной версии Документа, при условии, что Лицензиат не заявляет авторских прав на осуществленный им подбор или расположение документов при их размещении. Такое размещение называется "Подборкой", при этом условия настоящей Лицензии не применяются к самостоятельным произведениям, размещенным вышеуказанным способом вместе с Документом, при условии, что они не являются произведениями, производными от Документа.

Если условия пункта 3 настоящей Лицензии относительно Текста, помещаемого на обложке, могут быть применены к экземплярам Документа в Подборке, то в этом случае Текст с обложки Документа может быть помещен на обложке только собственно Документа внутри подборки при условии, что Документ занимает менее четвертой части объема всей Подборки. Если Документ занимает более четвертой части объема Подборки, в этом случае Текст с обложки Документа должен быть помещен на обложке всей Подборки.

D.1.9. Перевод

Перевод является одним из способов модификации Документа, в силу чего Лицензиат вправе распространять экземпляры перевода Документа в соответствии с пунктом 4 настоящей Лицензии. Замена Неизменяемых разделов их переводами может быть осуществлена только с разрешения соответствующих правообладателей, однако Лицензиат вправе в дополнение к оригинальным версиям таких Неизменяемых разделов включить в текст экземпляра перевод всех или части таких Разделов. Лицензиат вправе включить в текст экземпляра перевод настоящей Лицензии при условии, что в него включен также и оригинальный текст настоящей Лицензии на английском языке. В случае разногласий в тольковании текста перевода и текста на английском языке предпочтение отдается тексту Лицензии на английском языке.

D.1.10. Расторжение лицензии

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

D.1.11. Пересмотр условий лицензии

Free Software Foundation может публиковать новые исправленные версии GFDL. Такие версии могут быть дополнены различными нормами, регулирующими правоотношения, которые возникли после опубликования предыдущих версий, однако в них будут сохранены основные принципы, закрепленные в настоящей версии (смотри http://www/gnu.org/copyleft/).

Каждой версии присваивается свой собственный номер. Если указано, что Документ распространяется в соответствии с определенной версией, т.е. указан ее номер, или любой более поздней версией настоящей Лицензии, Лицензиат вправе присоединиться к любой из этих версий Лицензии, опубликованных Free Software Foundation (при условии, что ни одна из версий не является проектом Лицензии). Если Документ не содержит такого указания на номер версии Лицензии Лицензиат вправе присоединиться к любой из версий Лицензии, опубликованных когда-либо Free Software Foundation (при условии, что ни одна из версий не является Проектом Лицензии).

D.1.1. Порядок применения условий настоящей лицензии к вашей документации

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

? имя (наименование) автора или иного правообладателя, год первого опубликования документа Каждый имеет право воспроизводить, распространять и/или вносить изменения в настоящий Документ в соответствии с условиями GNU Free Documentation License, Версией 1.1 или любой более поздней версией, опубликованной Free Software Foundation; Данный Документ содержит следующие Неизменяемые разделы (указать названия Неизменяемых разделов); данный документ содержит следующий Текст, помещаемый на первой странице обложки (перечислить), данный документ содержит следующий Текст, помещаемый на последней странице обложки (перечислить). Копия настоящей Лицензии включена в раздел под названием "GNU Free Documentation License".

Если документ не содержит Неизменяемых разделов, укажите "Данный документ не содержит Неизменяемых разделов". Если документ не содержит Текста, помещаемого на первой или последней страницах обложки, укажите "Данный документ не содержит Текста, помещяемого на первой странице обложки", соответственно укажите для последней страницы обложки.

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

 

Примечания переводчика

1. Термин "copyleft" используется авторами проекта GNU Free Software Foundation в качестве одного из основных понятий в концепции свободного программного обеспечения (free software). Данный термин образуется за счет замены в английском языке термина "copyright" (авторское право) на "copyleft". Как указывают авторы проекта, "copyleft" - это наиболее общий способ сделать программное обеспечение свободным и обеспечить соблюдение условий, в соответствии с которыми все измененные и распространяемые версии программного обеспечение также сохраняли бы статус свободного программного обеспечения. Более подробно о концепции "copyleft" вы можете прочитать здесь http://www.gnu.org/copyleft/copyleft.html

 

 

 

Глоссарий

UHN

Unique Home Node – уникальный домашний узел

NFS

Network File System – сетевая файловая система

DFSA

Direct File System Access – файловая система прямого доступа

MFS

Misix File System – файловая система Mosix

oMFS

openMosix File System – файловая система openMosix

omdiscd

OpenMosix auto DISCovery Daemon – демон автообнаружения openMosix

HPC

High Performance Computing – высокопроизводительные вычисления

MPI

Message Passing Interface – интерфейс передачи сообщений

PVM

Parallel Virtual Machine – параллельная виртуальная машина

DSM

Distributed Shared Memory – распределённая разделяемая память

GNU

GNU's Not Unix – GNU – это не Unix

См. также Домашняя страничка GNU .

(N)UMA

(Non-)Uniform Memory Access –

RFC

Request For Comments – запрос на комментарии

См. также Архив RFC .

CVS

Concurrent Versioning System

См. также Домашняя страничка CVS .

UP

UniProcessor (однопроцессорный) – один CPU

SMP

Symmetric Multi Processing (симметрическая мультиобработка) – более одного CPU

Предметный указатель

I

IRC, IRC