openMosix HOWTO
Live free() or die()
История переиздания | |
---|---|
Издание 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. Обратная связь
- 1.2. Введение
- 1.1. openMosix
HOWTO
- 2. Что же такое openMosix?
-
- 2.1. Ну очень краткое введение в кластеры
- 2.2. История появления проекта от и до
-
- 2.2.1. История
развития
- 2.2.2. openMosix
- 2.2.3. Текущее состояние проекта
- 2.2.4. Какие приложения работают
- 2.2.2. openMosix
- 2.2.1. История
развития
- 2.3. openMosix
в действии: Пример
- 2.4. Компоненты
-
- 2.4.1. Миграция
процессов
- 2.4.2. Файловая система openMosix (oMFS)
- 2.4.3. Direct File System Access (DFSA)
- 2.4.2. Файловая система openMosix (oMFS)
- 2.4.1. Миграция
процессов
- 2.5. Демонстрационная система openMosix
- 3. Преимущества и недостатки openMosix
-
- 3.1. Преимущества
openMosix
- 3.2. Недостатки openMosix
- 3.1. Преимущества
openMosix
- II. Инсталляция openMosix
-
- 4. Требования и планирование
- 5. Инсталляции, специфические для дистрибутива
-
- 5.1. Инсталляция
openMosix
- 5.2. Прежде чем вы получите openMosix
- 5.3. Получение openMosix
- 5.4. Общие инструкции openMosix
- 5.2. Прежде чем вы получите openMosix
-
- 5.4.1. Компиляция
ядра
- 5.4.2. Синтаксис файла /etc/openmosix.map
- 5.4.3. oMFS
- 5.4.2. Синтаксис файла /etc/openmosix.map
- 5.4.1. Компиляция
ядра
- 5.5. RedHat
и openMosix
- 5.6. SuSE и openMosix
- 5.7. Debian и openMosixView
- 5.8. openMosix и Gentoo
- 5.9. Другие дистрибутивы
- 5.6. SuSE и openMosix
- 5.1. Инсталляция
openMosix
- 6. Автообнаружение
- 7. Инсталляция кластера
- III. Администрирование openMosix
-
- 8. Администрирование openMosix
-
- 8.1. Основы
Администрирования
- 8.2. Конфигурация
- 8.3. Пользовательские утилиты
- 8.4. Кластерная маска
- 8.2. Конфигурация
- 8.1. Основы
Администрирования
- 9. Тонкая Настройка Mosix
-
- 9.1. Введение
- 9.2. Создание мастер-узла
- 9.3. Оптимизация Mosix
- 9.4. Простое соединение каналов (Channel Bonding)
- 9.5. Updatedb
- 9.6. openMosix и FireWire
- 9.2. Создание мастер-узла
- 9.1. Введение
- 10. openMosixView
-
- 10.1. Введение
- 10.2. openMosixView по сравнению с Mosixview
- 10.3. Установка
- 10.2. openMosixView по сравнению с Mosixview
-
- 10.3.1. Установка
из .rpm-пакета
- 10.3.2. Установка из исходных текстов
- 10.3.3. Автоматический установочный скрипт
- 10.3.4. Компиляция вручную
- 10.3.5. Советы по компиляции
- 10.3.2. Установка из исходных текстов
- 10.3.1. Установка
из .rpm-пакета
- 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.4.2. Окно конфигурации
- 10.4.1. Основная
программа
- 10.5. Окно openMosixprocs
-
- 10.5.1. Введение
- 10.5.2. Окно migrator
- 10.5.3. Управление удалёнными процессами
- 10.5.2. Окно migrator
- 10.5.1. Введение
- 10.6. openMosixcollector
- 10.7. openMosixanalyzer
-
- 10.7.1. окно
load-overview
- 10.7.2. Статистическая информация об узле
- 10.7.3. окно memory-overview
- 10.7.4. openMosixhistory
- 10.7.2. Статистическая информация об узле
- 10.7.1. окно
load-overview
- 10.8. openMosixmigmon
-
- 10.8.1. Описание
- 10.8.2. Подсказки:
- 10.8.3. Drag'n Drop!
- 10.8.2. Подсказки:
- 10.8.1. Описание
- 10.9. openMosixView
FAQ
- 10.10. openMosixView + SSH
- 10.1. Введение
- 11. Прочие проекты, связанные с openMosix
-
- 11.1. Введение
- 11.2. openMosixView
- 11.3. openMosixApplet
- 11.4. wmonload
- 11.5. openMosixWebView
- 11.2. openMosixView
- 11.1. Введение
- 12. Распространённые проблемы и ошибки
-
- 12.1. Введение
- 12.2. Процессы не хотят мигрировать!
- 12.3. Я не вижу все свои узлы!
- 12.4. Я постоянно получаю ошибки типа: No such process
- 12.5. DFSA? MFS?
- 12.6. Проблемы с Python
- 12.2. Процессы не хотят мигрировать!
- 12.1. Введение
- 13. Советы и подсказки
-
- 13.1. Запертые
процессы
- 13.2. О выборе процессов
- 13.3. Java и openMosix
- 13.4. openMosix и Hyperthreading
- 13.5. openMosix и брандмауэры
- 13.2. О выборе процессов
- 13.1. Запертые
процессы
- 14. (стресс) Тестирование работы вашей openMosix-системы
-
- 14.1. Небольшой
тестовый скрипт
- 14.2. Программа тестирования на Perl'е от Charles Nadeau
- 14.3. Стресс-тест openMosix
- 14.2. Программа тестирования на Perl'е от Charles Nadeau
-
- 14.3.1. Общее
описание
- 14.3.2. Подробное описание
- 14.3.3. Установка комплекта strestest
- 14.3.4. Пример запуска тестов
- 14.3.2. Подробное описание
- 14.3.1. Общее
описание
- 14.1. Небольшой
тестовый скрипт
- IV. Выполение приложений на openMosix
- V. Разработка openMosix
- A. Как сделать .rpm пакеты ядра openMosix
- B. Дополнительная информация
-
- B.1. IRC
- B.2. Для дальнейшего чтения
- B.3. Переводы
- B.2. Для дальнейшего чтения
-
- B.3.1. Китайский
- B.3.2. Инспанский
- B.3.1. Китайский
- B.4. Ссылки
- B.5. Почтовые списки рассылок
- B.1. IRC
- C. Список
разработчиков
- D. Перевод на русский язык лицензии gnu на свободную документацию
- Глоссарий
- Предметный указатель
- D. Перевод на русский язык лицензии gnu на свободную документацию
Список таблиц
- 3.1. Преимущества
openMosix
- 3.2. Недостатки openMosix
- 5.1. Другие директории
- 8.1. Изменение параметров /proc/hpc
- 8.2. Параметры /proc/hpc/admin/
- 8.3. Результат установки в 1 содержимого следующих файлов каталога /proc/hpc/decay/
- 8.4. Информация о других узлах в кластере
- 8.5. Дополнительная информация о локальных процессах
- 8.6. …более подробно
- 8.7. дополнительные опции для утилиты mosrun
- 10.1. Варианты запуска
- 3.2. Недостатки openMosix
Самый лучший способ разобраться с предметом изучения, это написать о нём книгу… |
||
--Benjamin Disraeli |
Содержание
- 1. Введение
-
- 1.1. openMosix
HOWTO
- 1.2. Введение
- 1.3. Отказ от ответственности
- 1.4. Стратегия распространения
- 1.5. Новые версии данного документа
- 1.6. Обратная связь
- 1.2. Введение
- 1.1. openMosix
HOWTO
- 2. Что же такое openMosix?
-
- 2.1. Ну очень краткое введение в кластеры
- 2.2. История появления проекта от и до
-
- 2.2.1. История
развития
- 2.2.2. openMosix
- 2.2.3. Текущее состояние проекта
- 2.2.4. Какие приложения работают
- 2.2.2. openMosix
- 2.2.1. История
развития
- 2.3. openMosix
в действии: Пример
- 2.4. Компоненты
-
- 2.4.1. Миграция
процессов
- 2.4.2. Файловая система openMosix (oMFS)
- 2.4.3. Direct File System Access (DFSA)
- 2.4.2. Файловая система openMosix (oMFS)
- 2.4.1. Миграция
процессов
- 2.5. Демонстрационная система openMosix
- 3. Преимущества и недостатки openMosix
-
- 3.1. Преимущества
openMosix
- 3.2. Недостатки openMosix
- 3.1. Преимущества
openMosix
Содержание
- 1.1. openMosix
HOWTO
- 1.2. Введение
- 1.3. Отказ от ответственности
- 1.4. Стратегия распространения
- 1.5. Новые версии данного документа
- 1.6. Обратная связь
- 1.2. Введение
На самом деле всё началось с проекта Mosix, который и стал впоследствии openMosix. И, как мне кажется, openMosix намного интереснее и привлекательнее своего родителя не с технической точки зрения, а скорее из-за более соответствующей ему лицензии. В данном HOWTO я сосредоточу своё внимание именно на openMosix, а не на Mosix, по той простой причине, что у первого намного больше пользователей и разработчиков. (Moshe Bar утверждает, что на openMosix перешло около 97% бывших пользователей Mosix). Учитывая всё вышесказанное, я решил разделить HOWTO. Последняя версия Mosix-HOWTO будет иметь номер 0.20. Моё личное стремление – это сосредоточиться на openMosix-HOWTO, в то же время не забывая и о пользователях Mosix. Более подробная информация здесь http://howto.ipng.be/Mosix-HOWTO/.
В данном документе приводится краткое описание openMosix, программы, позволяющей превратить компьютеры под управлением GNU/Linux в компьютерный кластер. Также вкратце рассказано о параллельных вычислениях вообще, и приведён небольшой обзор приложений, которые можно использовать максимально эффективно в системе openMosix. Помимо этого в HOWTO можно найти описание особенностей работы openMosix в различных дистрибутивах.
С момента создания данного HOWTO многие разработчики Mosix переключились на openMosix (читайте об этом более подробно далее), так что часть информации в нём касается в равной степени и openMosix, и Mosix. Ввиду этого я решил разделить информацию о двух системах. Последний релиз Mosix HOWTO, содержащий информацию сразу о двух проектах, имеет версию 0.20, а найти его можно по этому адресу http://howto.ipng.be/Mosix-HOWTO/Mosix-HOWTO/.
Kris Buytaert подключился к этому документу в феврале 2002 года по просьбе Scot'a Stevenson'a, и хотя мы обсуждали и Mosix, и openMosix, данный HOWTO касается в основном openMosix. Так что учтите, пожалуйста, что здесь и далее под Mosix надо понимать openMosix.
Вы, наверное, заметили, что некоторые заголовки звучат не так серьёзно, как должны бы. Дело в том, что Scot планировал написать данный HOWTO в лёгком стиле, потому что в мире (даже в той части мира, где талисманом служит рыгающий пингвин) и так полно скучной технической литературы. Поэтому кое-где в тексте вы можете встретить подобные комментарии.
Вы можете использовать информацию из этого документа только на свой собственный страх и риск. Я снимаю с себя всю возможную ответственность за содержание документа. Любые изложенные здесь концепции, примеры и любая другая информация может быть использована только под вашу ответственность.
Все авторские права принадлежат их соответствующим владельцам, в случае если это не указано отдельно. Использование терминов в данном документе не должно рассматриваться как посягательство на законность торгового или служебного знака. Авторское право на openMosix принадлежит Moshe Bar (Copyright ? 2002 by Moshe Bar). Авторское право на Mosix принадлежит Amnon Barak (Copyright ? 2002 by Amnon Barak). Linux™ является зарегистрированным торговым знаком Linus'a Torvalds'a. openMosix распространяется под лицензией GNU General Public License version 2, опубликованной организацией Free Software Foundation.
Упоминание определённых продуктов или изготовителей не должно рассматриваться как одобрение.
Перед тем, как начать установку системы, настоятельно рекомендуется сделать резервную копию системы.
Copyright ? 2002 by Kris Buytaert and Scot W. Stevenson. Данный документ распространяется на условиях GNU Free Documentation License, Version 1.1 и более поздних версиях данной лицензии, опубликованных организацией Free Software Foundation. Текст этой лицензии есть в приложении Перевод на русский язык лицензии gnu на свободную документацию.
Официальные новые версии документа можно найти на страницах the Linux Documentation Project. Черновики и бета-версии доступны по адресу howto.ipng.be в соответствующем подкаталоге. Изменения в данный документ предварительно обсуждаются в Списках Рассылки openMosix. Подробнее об этом смотрите здесь openMosix.
Содержание
- 2.1. Ну очень краткое введение в кластеры
- 2.2. История появления проекта от и до
-
- 2.2.1. История
развития
- 2.2.2. openMosix
- 2.2.3. Текущее состояние проекта
- 2.2.4. Какие приложения работают
- 2.2.2. openMosix
- 2.2.1. История
развития
- 2.3. openMosix
в действии: Пример
- 2.4. Компоненты
-
- 2.4.1. Миграция
процессов
- 2.4.2. Файловая система openMosix (oMFS)
- 2.4.3. Direct File System Access (DFSA)
- 2.4.2. Файловая система openMosix (oMFS)
- 2.4.1. Миграция
процессов
- 2.5. Демонстрационная система openMosix
Большую часть времени ваш компьютер не загружен. Запустите утилиты типа xload или top, которые показывают загруженность системы, и вы увидите, что загрузка процессора может даже не превышать значения 1.0. А если у вас два компьютера, то вероятность того, что в один момент времени один из них ничем не занят, существенно возрастает. К сожалению, когда вам действительно нужна вся мощь процессора – будь то компиляция программ на С++ или кодирование файлов Ogg Vorbis, – то она нужна вам в максимально короткое время. Основной задачей кластера и является распределение этой нагрузки на все доступные компьютеры и их свободные ресурсы.
Составной единицей кластера является один компьютер, также именуемый как “узел” (node). Кластеры также можно наращивать путём добавления новых машин. Чем мощнее составляющие кластер единицы, и чем быстрее соединение между ними, тем мощнее будет и весь кластер в целом. Помимо этого, и операционная система кластера должна максимально эффективно использовать имеющееся в кластере оборудование. Особенно это требование необходимо в гетерогенных кластерах, т.е. составные единицы которого не идентичны. Ещё одним важным аспектом является устойчивость к непредсказуемой смене конфигурации (например, когда в кластер добавляются/удаляются новые машины), и следующей из этого непредсказуемой нагрузки.
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, часто могут позволить себе запланировать время отключения для своих окружений, а до тех пор они могут использовать максимальную мощность своих машин при необходимости.
Традиционно суперкомпьютеры собирались определёнными поставщиками, к тому же компания или организация, которой требовалась мощь такого суперкомпьютера, должна была выложить за него приличную сумму. Многие университеты не могут позволить себе таких затрат, поэтому они и создали другие альтернативы суперкомпьютерам. Концепция недорогого кластера родилась тогда, когда люди попытались распределить задачи сразу на много компьютеров, а затем собрать с них результат выполненной работы. Конечно, на простом и недорогом оборудовании можно только мечтать о производительности, сравнимой с настоящим суперкомпьютером, тем не менее, с развитием платформы РС разница в мощности между суперкомпьютером и кластером из множества персональных компьютеров стремительно сокращается.
Существует несколько технологий реализации параллельных вычислений: (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.
Программный пакет openMosix позволяет превратить в кластер компьютеры под управлением GNU/Linux, объединённые в сеть. Такой кластер позволит автоматически балансировать нагрузку на узлах, при этом новые узлы могут присоединяться или покидать кластер без прерывания его работы. Нагрузка на узлы распределяется исходя из скорости соединения и мощностей процессоров.
Поскольку openMosix является частью ядра и полностью совместим с Linux, то и все пользовательские программы, файлы и прочие ресурсы будут работать также, как и раньше, без каких-либо изменений. Простой пользователь даже не заметит разницы между Linux и openMosix системой. В целом картину можно представить, как будто весь кластер работает как одна (быстрая) GNU/Linux система.
openMosix представляет собой патч для ядра Linux, который, тем не менее, обеспечивает полную совместимость с платформой IA32. Благодаря внутреннему механизму балансировки нагрузки процессы могут мигрировать на другие узлы кластера. В результате получается выигрыш в производительности при использовании ресурсов нескольких машин. К тому же кластер постоянно самостоятельно пытается оптимизировать обработку процессов (естественно, что администратор системы может вмешаться в процесс автобалансировки в любое время).
Такой механизм прозрачной миграции процессов позволяет представить кластер как одну большую SMP-систему с множеством процессоров на доступных узлах кластера (конечно, следует учитывать и количество процессоров в двух и четырёх процессорных системах). К тому же openMosix предоставляет оптимизированную файловую систему (oMFS) для HPC-приложений, которая, в отличие от NFS, поддерживает кэширование, отметки о времени и ссылки.
Если верить слухам, то 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 (см. следующий параграф).
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 и списками рассылки для разработчиков и пользователей.
Как и в большинстве активных проектов с открытым исходным кодом, в openMosix темп изменений программы опережает возможность пользователей обновить документацию до соответствующего состояния.
На момент написания данной части документа в феврале 2003 была доступна версия openMosix 2.4.20 и пользовательские утилиты openMosix v0.2.4, включая и средства автообнаружения.
Но проект развивается очень быстро, так что ищите более новые версии на веб-сайте проекта openMosix.
Практически невозможно сделать полный список всех приложений, работающих в openMosix. Тем не менее, сообщество старается особо выделить приложения, которые мигрируют, и те, которые не мигрируют.
openMosix кластеры могут приобретать самую разную форму. Чтобы лучше себе это представить, давайте предположим что вы – студент, и живёте в одной комнате с богатым компьютерщиком, с которым вы объединили свои компьютеры в openMosix кластер. Теперь давайте предположим, что вы сейчас конвертируете музыку с компакт-дисков в файлы Ogg Vorbis, что вполне легально в вашей стране. Ваш сожитель работaет над проектом на С++, который, по его словам, принесёт мир во всём мире. Но в данный момент он в ванной, где занимается непонятными вещами, а его компьютер простаивает.
Итак, вы запускаете программу, скажем, bladeenc, чтобы сконвертировать творения Баха из формата .wav в .ogg. Алгоритм openMosix на вашей машине сравнивает загрузку на обоих узлах и решает, что процесс будет выполняться быстрее, если его отправить с вашего Pentium-233 на соседний Athlon XP. Всё это происходит автоматически: вы выполняете команды как на обычном персональном компьютере. Всё, что вы заметите, это, например, когда вы запустите сразу две задачи, то они будут работать быстрее, а время их ответа не затянется надолго.
Итак, пока вы что-то там набираете на клавиатуре, ваш сожитель возвращается, бормоча что-то про красный перец в кафетерии. Он садится за свой компьютер и продолжает свои тесты, используя при этом программу pmake – версию make, только оптимизированную для параллельного выполнения. В общем, он так загрузил ей свой процессор, что openMosix даже начал посылать подпроцессы на вашу машину для балансировки нагрузки.
Подобная конфигурация кластера называется “single-pool” (единый пул): в ней все компьютеры используются как единый кластер. Преимуществом или недостатком такой конфигурации, исходя из обстановки, является то, что ваш компьютер – часть пула, то есть, ваши задачи выполняются на других машинах, хотя и процессы с других машин будут мигрировать на вашу машину тоже. О других конфигурациях подробнее читайте в главе Планирование вашего кластера.
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?).
В целях поддержки openMosix Major Chai Mee Joon предоставляет всем пользователям openMosix тестовую учётную запись в своём openMosix кластере, под которой они могут поэкспериментировать и проверить openMosix в действии.
Такая служба поможет новым пользователям в решении проблем настройки кластера, а также окажется полезной тем, кто разрабатывает или портирует приложения для openMosix.
Получить имя пользователя и пароль для работы с этим кластером можно отправив письмо по адресу: <om@majorlinux.com>
Содержание
- 3.1. Преимущества
openMosix
- 3.2. Недостатки 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
Зависит от ядра. |
Возникают проблемы при работе с разделяемой памятью (альфа релиз DSM должен появиться в конце марта 2003). |
Возникают проблемы с производительностью при использовании Multiple Threads. |
Не удастся достичь прироста в производительности единичного процесса, как например, веб-браузера на openMosix кластере. Такой процесс не будет распределять себя в кластере, хотя может мигрировать на более мощную машину в кластере. |
Содержание
- 4. Требования и планирование
- 5. Инсталляции, специфические для дистрибутива
-
- 5.1. Инсталляция
openMosix
- 5.2. Прежде чем вы получите openMosix
- 5.3. Получение openMosix
- 5.4. Общие инструкции openMosix
- 5.2. Прежде чем вы получите openMosix
-
- 5.4.1. Компиляция
ядра
- 5.4.2. Синтаксис файла /etc/openmosix.map
- 5.4.3. oMFS
- 5.4.2. Синтаксис файла /etc/openmosix.map
- 5.4.1. Компиляция
ядра
- 5.5. RedHat
и openMosix
- 5.6. SuSE и openMosix
- 5.7. Debian и openMosixView
- 5.8. openMosix и Gentoo
- 5.9. Другие дистрибутивы
- 5.6. SuSE и openMosix
- 5.1. Инсталляция
openMosix
- 6. Автообнаружение
- 7. Инсталляция кластера
Содержание
Для начальной инсталляции кластера необходимо как минимум 2 соединённые сетью машины, использующие либо кросс-кабель между двумя сетевыми карточками или использующие коммутатор (switch) или концентратор (hub) (хотя коммутатор намного лучше концентратора, и стоит он всего на несколько баксов больше). Конечно же, чем быстрее ваши сетевые карточки, тем проще будет вам получить лучшую производительность от вашего кластера.
В наши дни Fast Ethernet (100 Мб/с) является стандартом; установка нескольких портов в машину не является уж очень трудным делом, но убедитесь, что вы подключили их к различным физическим сетям для получения желаемой скорости. Gigabit Ethernet с каждым днём становится всё дешевле, но я не советую вам спешить в магазин и тратить свои деньги, прежде чем вы протестировали вашу конфигурацию с несколькими 100 Мбит карточками и заметили, что вам действительно нужна дополнительная пропускная способность сети. После установки гигабитной карточки вам также, наверное, захочется соединить несколько 100 Мбит карточек вместе (см. главу Простое соединение каналов (Channel Bonding)). И даже более дешёвой альтернативой может оказаться Firewire, как обсуждается в главе openMosix и FireWire.
Установка большого кластера требует некоторых размышлений: где вы собираетесь разместить машины? Не где-нибудь под столом или в центре вашего офиса, я надеюсь! Это нормально, если вы хотите провести несколько маленьких тестов, но если вы хотите развернуть кластер из N узлов, вам нужно будет убедиться, что окружение, которое будет содержать эти машины, приспособлено к этому.
Я говорю о приготовлении одной или нескольких 19-ти дюймовых стоек (19" racks) для того, чтобы содержать эти машины, конфигурировании соответствующей сетевой топологии, либо прямой, прямо соединённой или даже 1-к-1 кросс-соединённой сети между всеми узлами. Вам также необходимо убедиться, что у вас есть достаточно энергии, чтобы запитать такую группу машин, что ваша воздушная кондиционерная система выдерживает нагрузку, и что в случае сбоя в питании ваши UPS могут правильно остановить все требуемые системы. Возможно, вам захочется вложить деньги в КВМ (Клавиатура, Видео, Мышка) коммутатор, чтобы легко получать доступ к терминалам машин.
Но даже если у вас нету такого количества узлов, чтобы оправдать такие вложения, убедитесь, что вы всегда можете легко получить доступ к любому узлу, так как никогда не знаешь, что нужно поменять вентилятор на CPU или винчестер в неисправной машине. Если это значит, что вам нужно достать кучу машин, чтобы добраться до самой нижней, а следовательно, остановить ваш кластер, – вы в беде.
Для системы, которую мы планируем использовать, необходима базовая инсталляция Linux на ваш выбор: RedHat, SuSE, Debian, Gentoo или любой другой дистрибутив, – на самом деле не важно, какой именно. Что имеет значение, так это версия ядра Linux как минимум 2.4 и правильно сконфигурированные сетевые карточки. После этого вам необходимо значительное пространство для свопа.
Когда наступит время конфигурировать кластер openMosix с пулом серверов и множеством (персональных) рабочих станций, у вас будет несколько вариантов, каждый из которых имеет свои преимущества и недостатки.
-
В конфигурации с одним пулом все сервера и рабочие станции используются в едином кластере: каждая машина является частью кластера и может мигрировать процессы на любой другой существующий узел. Это, конечно же, делает вашу рабочую станцию частью пула.
-
В окружении, которое называется серверным пулом, сервера являются частью кластера, в то время как рабочие станции – нет, они даже не имеют ядра openMosix. Если вы захотите выполнить приложение на кластере, вам нужно будет специальным образом зайти на эти сервера (logon). Тем не менее, ваша рабочая станция также будет оставаться “чистой”: ни один из удалённых процессов не будет мигрировать на неё.
-
Третья альтернатива называется конфигурацией с адаптивным пулом: в ней сервера являются общими, в то время как рабочие станции присоединяются и покидают кластер. Представьте себе, что ваша рабочая станция в течение дня используется вами самими, но как только вы выходите из системы (logout) вечером, скрипт приказывает вашей рабочей станции присоединиться к кластеру и начать перемалывать числа. Таким образом, ваша машина используется, в то время как вам она не нужна. Если вам снова необходимы ресурсы машины, всего лишь запустите openMosix стоп-скрипт и ваши процессы будут держаться подальше от кластера и наоборот.
На практике это значит, что вы будете изменять роль своей машины используя mosctl.
Хотя это может показаться хорошей идеей превратить ночью ваш класс в openMosix кластер, но вам нужно будет принять во внимание обучение конечных пользователей не нажимать кнопку питания этих машин, когда они снова хотят их использовать. Самые последние машины поддерживают автоматическое отключение при нажатии на кнопку питания, но на более старых машинах вы можете потерять некоторые данные сейчас или позже, когда это действительно случится.
Содержание
- 5.1. Инсталляция
openMosix
- 5.2. Прежде чем вы получите openMosix
- 5.3. Получение openMosix
- 5.4. Общие инструкции openMosix
- 5.2. Прежде чем вы получите openMosix
-
- 5.4.1. Компиляция
ядра
- 5.4.2. Синтаксис файла /etc/openmosix.map
- 5.4.3. oMFS
- 5.4.2. Синтаксис файла /etc/openmosix.map
- 5.4.1. Компиляция
ядра
- 5.5. RedHat
и openMosix
- 5.6. SuSE и openMosix
- 5.7. Debian и openMosixView
- 5.8. openMosix и Gentoo
- 5.9. Другие дистрибутивы
- 5.6. SuSE и openMosix
В этой главе обсуждается инсталляция openMosix на различных дистрибутивах. Это не будет список всех возможных комбинаций. Тем не менее в этой главе вы найдёте достаточно информации для инсталляции openMosix в вашем окружении.
Методы инсталляции нескольких машин с openMosix будут обсуждаться в главе Инсталляция кластера.
Прежде всего, вы должны понимать, что openMosix состоит из патча к ядру Linux и нескольких утилит пространства пользователя. Патч на ядро необходим, чтобы позволить ядру общаться с другими openMosix машинами в сети. Если вы скачаете openMosix как двоичный пакет (например, как файл .rpm), вам даже не нужно беспокоиться о патче на ядро, потому что ядро уже пропатчено и скомпилировано для вас с наиболее общими опциями и модулями по-умолчанию.
Пользовательские утилиты нужны для эффективного использования ядра openMosix. Они нужны для запуска/остановки демона миграции, файловой системы openMosix (MFS), для миграции задач на определённые узлы, а не на любые, и других задач, которые обычно достигаются при помощи старого доброго друга: интерфейса командной строки. Что касается двоичных пакетов, то же самое, что и для патча ядра, имеет место и для пользовательских утилит: если вы инсталлируете .rpm, вы не должны беспокоиться об их компиляции или конфигурировании чего-либо; просто проинсталлируйте и запускайте. Это всё. На самом деле :)
Как только вы попадёте на страницу закачки (о которой я поговорю во-вторых), вам нужно получить две отдельные части: ядро и пользовательские утилиты. Вы можете скачать два двоичных пакета или получить патч на ядро плюс исходники пользовательских утилит. Патч на ядро обычно называется согласно следующей схеме: openMosix-x.y.z-w, где x.y.z – версия оригинального ядра Linux, на которое должен быть наложен этот патч, а w – это ревизия патча для этого конкретного релиза ядра. Для прекомпилированных двоичных ядер, пожалуйста, обратитесь к файлу README-openMosix-kernel.txt, который вы найдёте на странице закачки. Этот файл также содержит обновлённую информацию для самостоятельной компиляции ядра.
О пользовательских утилитах: вы их найдёте в пакете, который называется openmosix-tools. Мы будем использовать термины “утилиты пространства пользователя”, “пользовательские утилиты”, “утилиты openMosix” взаимозаменяемым образом. Заметим, что с версии 0.3 пользовательских утилит файл /etc/openmosix.map считается устаревшим, и очень поощряется использование демона автообнаружения omdiscd, так как он заботится о том, чтобы сделать вашу жизнь легче.
Вы можете скачать последние версии openMosix с http://sourceforge.net/project/showfiles.php?group_id=46729. Вы можете выбрать двоичный файл (даже в .rpm), скомпилированный для однопроцессорных (UP) или мультипроцессорных (SMP) систем. В качестве альтернативы вы можете получить версию из CVS:
cvs -d:pserver: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 ;-)
Всегда используйте “чистые” оригинальные исходные коды ядра с 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 кластера готов!
Прежде чем запускать openMosix, должен быть конфигурационный файл /etc/openmosix.map, одинаковый на всех узлах.
Стандартным теперь является файл /etc/openmosix.map, а /etc/mosix.map и /etc/hpc.map уже устаревшие стандарты, но CVS-версия утилит является обратно-совместимой и ищет /etc/openmosix.map, /etc/mosix.map и /etc/hpc.map (в таком порядке).
Файл /etc/openmosix.map содержит три, разделённых пробелами, поля:
openMosix-Node_ID IP-адрес(или имя хоста) Размер диапазона |
Например, файл /etc/openmosix.map может выглядеть так:
1 node1 1 2 node2 1 3 node3 1 4 node4 1 |
или
1 192.168.1.1 1 2 192.168.1.2 1 3 192.168.1.3 1 4 192.168.1.4 1 |
или при помощи задания размера диапазона оба предыдущих примера эквивалентны:
1 192.168.1.1 4 |
openMosix увеличивает последний байт IP-адреса узла согласно его openMosix-Node_ID. Конечно же, если вы используете размер диапазона больше 1, вы должны использовать IP-адреса вместо имён хостов.
Если у узла есть более одного сетевого интерфейса, то он может быть сконфигурирован с опцией ALIAS в поле размера диапазона (что равносильно установке размера диапазона в 0), то есть:
1 192.168.1.1 1 2 192.168.1.2 1 3 192.168.1.3 1 4 192.168.1.4 1 4 192.168.10.10 ALIAS |
Тут узел с openMosix-Node_ID 4 имеет два сетевых интерфейса (192.168.1.4 + 192.168.10.10), которые оба видны openMosix.
![]() |
Важно |
---|---|
Всегда будьте уверены в том, что запущены одинаковые версии openMosix с одинаковыми конфигурациями на каждом узле кластера! |
Запустите openMosix утилитой setpe на каждом узле:
setpe -w -f /etc/openmosix.map |
Выполните эту команду (которая будет описана позже в главе Пользовательские утилиты) на каждом узле своего openMosix кластера.
В качестве варианта вы можете взять скрипт openmosix, который может быть найден в директории со скриптами в пользовательских утилитах, и скопировать его в директорию /etc/init.d, выполнить для него chmod 0755 и затем использовать следующие команды под суперпользователем:
/etc/init.d/openmosix stop /etc/init.d/openmosix start /etc/init.d/openmosix restart |
Сейчас инсталляция завершена: кластер запущен и работает :)
5.4.3. oMFS
Прежде всего, должна быть включена опция CONFIG_MOSIX_FS в конфигурации ядра. Если текущее ядро было скопировано без этой опции, то нужна перекомпиляция с этой включенной опцией.
Также UID (идентификаторы пользователей) и GID (идентификаторы групп) для всех файловых систем узлов кластера должны быть одинаковыми. Возможно, вы захотите достичь этого используя openldap. Опция ядра CONFIG_MOSIX_DFSA является необязательной, но, конечно же, необходимой, если должна использоваться DFSA. Для того, чтобы смонтировать oMFS на кластере, необходима дополнительная запись на каждом узле в файле /etc/fstab
со включенной DFSA:
mfs_mnt /mfs mfs dfsa=1 0 0 |
с выключенной DFSA:
mfs_mnt /mfs mfs dfsa=0 0 0 |
синтаксис fstab-записи:
[имя_устройства] [точка_монтирования] mfs defaults 0 0 |
После монтирования точки монтирования /mfs на каждом узле файловая система любого узла становится доступной через директорию /mfs/openMosix-Node_ID/.
С помощью нескольких символических ссылок все узлы кластера могут получить доступ к одним и тем же данным, например, /work на node1:
на узле node2: ln -s /mfs/1/work /work на узле node3: ln -s /mfs/1/work /work на узле node3: ln -s /mfs/1/work /work ... |
Теперь на любом узле вы можете читать/писать из/в /work!
Следующие специальные файлы и директории исключаются из доступа через oMFS:
-
директория /proc
-
специальные файлы, которые не являются регулярными файлами, директориями или символическими ссылками (например, исключается /dev/hda1).
Создание ссылок, таких как
ln -s /mfs/1/mfs/1/usr |
или
ln -s /mfs/1/mfs/3/usr |
является неправильным.
Следующие системные вызовы поддерживаются без пересылки мигрировавшего процесса (который выполняет этот вызов на удалённом узле) назад на его UHN:
read, readv, write, writev, readahead, lseek, llseek, open, creat, close, dup, dup2, fcntl/fcntl64, getdents, getdents64, old_readdir, fsync, fdatasync, chdir, fchdir, getcwd, stat, stat64, newstat, lstat, lstat64, newlstat, fstat, fstat64, newfstat, access, truncate, truncate64, ftruncate, ftruncate64, chmod, chown, chown16, lchown, lchown16, fchmod, fchown, fchown16, utime, utimes, symlink, readlink, mkdir, rmdir, link, unlink, rename
Здесь даны ситуации, когда системные вызовы на DFSA-смонтированной файловой системе могут не работать:
Вслед за директориями /mfs/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Тб свободного пространства для этих систем.
Если вы используете RedHat версий 7.2, 7.3 или 8.0, то это, вероятно, самая лёгкая инсталляция *Mosix, которую вы когда-либо производили. Выберете соответствующие .rpm openMosix с sourceforge.net Они содержат прекомпилированные ядра (на время написания этого – 2.4.20), которые работают без заминки: я протестировал их на нескольких машинах, включая лаптопы с карточками PCMCIA, и на серверах с SCSI дисками. Если вы – пользователь grub, .rpm с ядром даже модифицирует ваш grub.conf. Итак, всё, что вам нужно, – это проинсталлировать две .rpm:
rpm -Uvh openmosix-kernel-2.4.20-openmosix2.i686.rpm openmosix-tools-0.2.4-1.i386.rpm |
и отредактировать ваш /etc/openmosix.map, если вы не используете демон автообнаружения omdiscd.
Так так выяснилось, что это является проблемой для многих людей, давайте рассмотрим другой пример. Скажем, у вас есть 3 машины: 192.168.10.220, 192.168.10.78 и 192.168.10.84. Ваш /etc/openmosix.map будет выглядеть, например, так:
[root@oscar0 root]# more /etc/openmosix.map # openMosix CONFIGURATION # =================== # # Each line should contain 3 fields, mapping IP addresses to openMosix node-numbers: # 1) first openMosix node-number in range. # 2) IP address of the above node (or node-name from /etc/hosts). # 3) number of nodes in this range. # # Example: 10 machines with IP 192.168.1.50 - 192.168.1.59 # 1 192.168.1.50 10 # # openMosix-# IP number-of-nodes # ============================ 1 192.168.10.220 1 2 192.168.10.78 1 3 192.168.10.84 1 |
Теперь, перезагружая машины с новым установленным ядром, вы станете на шаг ближе к получению работающего кластера.
В большинстве инсталляций RedHat есть ещё одна вещь для исправления. Вы часто получаете следующую ошибку:
[root@inspon root]# /etc/init.d/openmosix start Initializing openMosix... setpe: the supplied table is well-formatted, but my IP address (127.0.0.1) is not there! |
Это значит, что имя вашего хоста не перечислено в /etc/hosts с тем же IP-адресом, как и в вашем /etc/openmosix.map. Возможно, машина, которая называется omosix1.localhost.org, перечислена в /etc/openmosix.map как:
127.0.0.1 omosix1.localhost.org localhost |
Если вы измените ваш /etc/hosts так, чтобы он выглядел как далее, у openMosix будет меньше проблем при старте:
192.168.10.78 omosix1.localhost.org 127.0.0.1 localhost |
[root@inspon root]# /etc/init.d/openmosix start Initializing openMosix... [root@inspon root]# /etc/init.d/openmosix status This is openMosix node #2 Network protocol: 2 (AF_INET) openMosix range 1-1 begins at 192.168.10.220 openMosix range 2-2 begins at inspon.localhost.be openMosix range 3-3 begins at 192.168.10.84 Total configured: 3 |
Если вы хотите использовать ещё больше кровопролитных патчей, вы всегда можете воспользоваться в качестве альтернативы .srpm и выполнить для него rpmbuild --rebuild. Это проинсталлирует для вас исходники и создаст начальный конфигурационный файл. Начиная с этого момента вы можете наложить патчи на openMosix.
Пособие по тому, как построить свои .rpm openMosix, может быть найдено в приложении Как сделать .rpm пакеты ядра openMosix.
По мере того, как будут выходить новые версии RedHat, их можно будет поддерживать, поэтому не стесняйтесь написать автору короткое письмо, чтобы помочь ему содержать эту информацию обновлённой.
Хотя RPM компилируются в окружении, основанном на RedHat, вы можете использовать большинство из них на других системах, основанных на RPM.
В SuSE, тем не менее, /sbin/mk_initrd является символической ссылкой на /sbin/mkinitrd, что приводило к ошибке при установке .rpm до версии 20-2. В новых версиях это должно быть исправлено.
Инсталлирование openMosix “дебиановским способом” легко может быть выполнено, как описано ниже.
Первый шаг состоит в скачивании пакетов из Интернет. Я вынужден был использовать ядро 2.4.19, так как пакеты с патчами openMosix не были готовы для 2.4.20 к тому моменту, когда я это писал. Так как мы используем установку для Debian, то нам нужны: http://packages.debian.org/unstable/net/openmosix.html, http://packages.debian.org/unstable/net/kernel-patch-openmosix.html, http://packages.debian.org/unstable/misc/kernel-package.html, http://packages.debian.org/unstable/devel/kernel-source-2.4.19.html. Вы также можете их apt-get install ;).
Следующей частью является добавление в ядро кластерных возможностей openMosix.
В основном, процедура, которую необходимо придерживаться, следующая:
cd /usr/src apt-get install kernel-source-2.4.19 kernel-package \ openmosix kernel-patch-openmosix tar vxjf kernel-source-2.4.19.tar.bz2 ln -s /usr/src/kernel-source-2.4.19 /usr/src/linux cd /usr/src/linux ../kernel-patches/i386/apply/openmosix make menuconfig make-kpkg kernel_image modules_image cd .. dpkg -i kernel-image-*-openmosix-*.deb |
Сейчас вам необходимо будет отредактировать свой /etc/openmosix.map. Пожалуйста, следуйте инструкциям, изложенным в главе Синтаксис файла /etc/openmosix.map.
После перезагрузки с этим ядром и сконфигурированным /etc/openmosix.map, вы должны будете получить кластер из машин openMosix, которые общаются друг с другом, и в ходе этого процессы мигрируют.
Вы можете протестировать это, выполнив следующий маленький скрипт
awk 'BEGIN {for(i=0;i<10000;i++)for(j=0;j<10000;j++);}' |
пару раз и наблюдайте его поведение при помощи mosmon, где вы увидите, что он распределяет нагрузку между различными узлами.
Мы также проинсталлируем openMosixView на машине Debian:
apt-get install openmosixview |
Для того, чтобы получить возможность действительно воспользоваться openMosixView, вам необходимо будет запустить его от имени пользователя, который может заходить на различные узлы как root. Мы предлагаем вам установить это при помощи SSH. Пожалуйста учтите, что существует разница между реализациями SSH и SSH2. Если у вас есть файл identity.pub, ssh проверит authorized_keys, в то время, как если у вас есть id_dsa.pub, вам понадобится authorized_keys2!
openMosixView предоставляет вам приятный интерфейс, который отображает нагрузку различных машин и даёт вам возможность мигрировать процессы вручную. Более детальное обсуждение openMosixView может быть найдено в главе openMosixView.
Сперва проинсталлируйте Gentoo для Linux.
Затем проинсталлируйте openMosix: наберите emerge sys-apps/openmosix-user, что проинсталлирует исходные коды ядра openMosix в /usr/src/linux вместе с пользовательскими утилитами openMosix.
Майкл Имхоф (Michael Imhof), также известный как tantive, поддерживает Gentoo в соответствии с последней версией openMosix.
Даниел Робинс (Daniel Robbins), президент/генеральный директор Gentoo Technologies, Inc. и создатель Gentoo для Linux, написал статьи, которые мы используем как наше введение в кластеры openMosix.
Содержание
Демон автообнаружения (omdiscd) предоставляет способ автоматически конфигурировать кластер openMosix, а следовательно, избавляет от необходимости ручного конфигурирования /etc/openmosix.map или вроде него. Автообнаружение использует широковещательные (multicast) пакеты для уведомления других узлов, что это есть узел openMosix. Согласно этому способу, добавление дополнительного узла в ваш кластер значит, что вы всего лишь должны запустить omdiscd на вашей машине, и она присоединится к кластеру.
Тем не менее, есть некоторые небольшие требования: как и для любого кластера openMosix вы должны иметь правильно сконфигурированную сеть, главным образом маршрутизацию. Без маршрута по-умолчанию вы должны задать omdiscd интерфейс при помощи опции -i. В противном случае omdiscd завершит работу с ошибкой, как например:
Aug 31 20:41:49 localhost omdiscd[1290]: Unable to determine address of default interface. This may happen because there is no default route configured. Without a default route, an interface must be: Network is unreachable Aug 31 20:41:49 localhost omdiscd[1290]: Unable to initialize network. Exiting. |
Пример правильной таблицы маршрутов ниже:
[root@localhost log]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 10.0.0.99 0.0.0.0 UG 0 0 0 eth0 |
Главным образом с настоящего момента всё станет проще. Всего лишь запустите:
omdiscd |
и взгляните на ваши лог-файлы, в которых вы должны увидеть что-то похожее на это:
Sep 2 10:00:49 oscar0 kernel: openMosix configuration changed: This is openMosix #2780 (of 6 configured) Sep 2 10:00:49 oscar0 kernel: openMosix #2780 is at IP address 192.168.10.220 Sep 2 10:00:49 oscar0 kernel: openMosix #2638 is at IP address 192.168.10.78 Sep 2 10:00:49 oscar0 kernel: openMosix #2646 is at IP address 192.168.10.86 Sep 2 10:00:49 oscar0 kernel: openMosix #2627 is at IP address 192.168.10.67 Sep 2 10:00:49 oscar0 kernel: openMosix #2634 is at IP address 192.168.10.74 |
Поздравляем, ваш кластер openMosix сейчас работает.
У omdiscd есть некоторые другие опции, которые вы можете использовать. Вы можете запустить omdiscd как демон (по-умолчанию) или в обычном режиме, когда весь вывод идёт на экран (стандартный вывод):
omdiscd -n |
Интерфейс может быть задан с помощью опции -i:
omdiscd -i eth0 |
Теперь давайте всё же глянем на другую утилиту – showmap. Эта утилита покажет вам наиболее последнюю автосгенерированную карту openMosix.
[root@oscar0 root]# showmap My Node-Id: 0x0adc Base Node-Id Address Count ------------ ---------------- ----- 0x0adc 192.168.10.220 1 0x0a4e 192.168.10.78 1 0x0a56 192.168.10.86 1 0x0a43 192.168.10.67 1 0x0a4a 192.168.10.74 1 |
У автообнаружения есть некоторые другие свойства, не перечисленные здесь, такие как механизм маршрутизации для кластеров с более чем одной сетью. Более детальная информация может быть найдена в файлах README и DESIGN в дереве исходных кодов пользовательских утилит.
Самые недавние версии rc-скриптов openMosix в первую очередь проверяют, существует ли файл /etc/openmosix.map или похожий, перед попыткой использовать автоконфигурацию.
Если вы компилируете автообнаружение из исходников, вам необходимо будет внести небольшое изменение в openmosix.c. Одной из первых строчек будет:
#define ALPHA |
Вам необходимо будет это закомментировать. Если вы хотите получить дополнительную отладочную информацию, вы должны отредактировать файл main.c где-то в районе 84 строки:
log_set_debug(DEBUG_TRACE_ALL); |
Теперь выполните:
% make clean % make |
Иногда, однако, автообнаружение не работает так, как вам бы хотелось, например, узел не может видеть широковещательный трафик с других узлов. Это может случиться с некоторыми драйверами ethernet для PCMCIA. Одним из решений является переключить интерфейс в неразборчивый и/или широковещательный режим, как подробно описано ниже:
Aug 31 20:45:58 localhost kernel: openMosix configuration changed: This is openMosix #98 (of 1 configured) Aug 31 20:45:58 localhost kernel: openMosix #98 is at IP address 10.0.0.98 Aug 31 20:45:58 localhost omdiscd[1627]: Notified kernel to activate openMosix Aug 31 20:45:58 localhost kernel: Received an unauthorized information request from 10.0.0.99 |
Что вы должны после этого попытаться сделать – это перевести ваш NIC в неразборчивый и/или широковещательный режим вручную.
ifconfig eth0 promisc |
или
ifconfig eth0 multicast |
Вы также возможно захотите выполнить:
tcpdump -i eth0 ether multicast |
что приведёт к тому же эффекту, но вы теперь также сможете увидеть пакеты сами.
На некоторых коммутаторах 3-го уровня может потребоваться дополнительное конфигурирование. Пользователь openMosix выяснил, что для его коммутатора Summit48Si (Extreme Networks) он должен был выполнить:
disable ipmcforwarding # для дизактивации маршрутизации широковещательных пакетов disable igmp snooping |
прежде чем различные omdiscd смогли увидеть друг друга. Для других коммутаторов может потребоваться похожее конфигурирование.
Aug 31 22:14:43 inspon omdiscd[1422]: Simulated notification to activate openMosix [root@inspon root]# showmap My Node-Id: 0x0063 Base Node-Id Address Count ------------ ---------------- ----- 0x0063 10.0.0.99 1 [root@inspon root]# /etc/init.d/openmosix status OpenMosix is currently disabled |
Если вы увидите simulated, то вы, вероятно, забыли закомментировать:
#define ALPHA |
Я заметил, что автообнаружение не работает с сетевыми карточками FireWire.
Содержание
Эта глава не имеет отношение к инсталляции openMosix как такового, она, тем не менее, имеет отношение к инсталляции нескольких машин с openMosix. Автоматические или полуавтоматические массовые инсталляции.
На время написания (Май 2003) наиболее последняя версия DSH доступна с http://www.netfort.gr.jp/~dancer/software/downloads/. Больше дополнительной информации о пакете может быть найдено на http://www.netfort.gr.jp/~dancer/software/dsh.html. Последняя доступная для скачивания версия 0.23.6. Вам так же понадобятся libdshconfig-0.20.8.tar.gz и dsh-0.23.5.tar.gz. Начнём с инсталляции libdshconfig:
./configure make make install |
Повторите процесс для пакета dsh.
Скажем, у нас есть небольшой кластер с парой узлов. Для того, чтобы сделать жизнь проще, мы хотим набрать команду только один раз, но чтобы она была выполнена на каждом узле. Для этого вы должны создать файл $HOME/.dsh/group/clusterwname, в котором перечислены IP-адреса узлов вашего кластера. Например:
[root@inspon root]# cat ~/.dsh/group/mosix 192.168.10.220 192.168.10.84 |
Для примера мы выполним ls на каждой из этих машин. Мы задействуем -g для использования групп Mosix (таким образом, вы можете создать подмножества групп с различными конфигурациями).
[root@inspon root]# dsh -r ssh -g mosix ls 192.168.10.84: anaconda-ks.cfg 192.168.10.84: id_rsa.pub 192.168.10.84: install.log 192.168.10.84: install.log.syslog 192.168.10.84: openmosix-kernel-2.4.17-openmosix1.i686.rpm 192.168.10.84: openmosix-tools-0.2.0-1.i386.rpm 192.168.10.220: anaconda-ks.cfg 192.168.10.220: id_dsa.pub 192.168.10.220: id_rsa.pub 192.168.10.220: openmosix-kernel-2.4.17-openmosix1.i686.rpm 192.168.10.220: openmosix-tools-0.2.0-1.i386.rpm 192.168.10.220: oscar-1.2.1rh72 192.168.10.220: oscar-1.2.1rh72.tar.gz |
Заметьте, что ни одна из машин не спросила пароля. Это потому что мы установили RSA аутентификацию для различных учётных записей. Если вам нужно выполнить команды с различными параметрами, вам нужно будет или заключить команды в кавычки:
[root@inspon root]# dsh -r ssh -g mosix "uname -a" 192.168.10.84: Linux omosix2.office.be.stone-it.com 2.4.17-openmosix1 #1 Wed May 29 14:32:28 CEST 2002 i686 unknown 192.168.10.220: Linux oscar0 2.4.17-openmosix1 #1 Wed May 29 14:32:28 CEST 2002 i686 unknown |
или использовать опцию -c. Оба способа выдают практически то же самое на экран:
[root@inspon root]# dsh -r ssh -g mosix -c -- uname -a 192.168.10.220: Linux oscar0 2.4.17-openmosix1 #1 Wed May 29 14:32:28 CEST 2002 i686 unknown 192.168.10.84: Linux omosix2.office.be.stone-it.com 2.4.17-openmosix1 #1 Wed May 29 14:32:28 CEST 2002 i686 unknown |
Содержание
- 8. Администрирование openMosix
-
- 8.1. Основы
Администрирования
- 8.2. Конфигурация
- 8.3. Пользовательские утилиты
- 8.4. Кластерная маска
- 8.2. Конфигурация
- 8.1. Основы
Администрирования
- 9. Тонкая Настройка Mosix
-
- 9.1. Введение
- 9.2. Создание мастер-узла
- 9.3. Оптимизация Mosix
- 9.4. Простое соединение каналов (Channel Bonding)
- 9.5. Updatedb
- 9.6. openMosix и FireWire
- 9.2. Создание мастер-узла
- 9.1. Введение
- 10. openMosixView
-
- 10.1. Введение
- 10.2. openMosixView по сравнению с Mosixview
- 10.3. Установка
- 10.2. openMosixView по сравнению с Mosixview
-
- 10.3.1. Установка
из .rpm-пакета
- 10.3.2. Установка из исходных текстов
- 10.3.3. Автоматический установочный скрипт
- 10.3.4. Компиляция вручную
- 10.3.5. Советы по компиляции
- 10.3.2. Установка из исходных текстов
- 10.3.1. Установка
из .rpm-пакета
- 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.4.2. Окно конфигурации
- 10.4.1. Основная
программа
- 10.5. Окно openMosixprocs
-
- 10.5.1. Введение
- 10.5.2. Окно migrator
- 10.5.3. Управление удалёнными процессами
- 10.5.2. Окно migrator
- 10.5.1. Введение
- 10.6. openMosixcollector
- 10.7. openMosixanalyzer
-
- 10.7.1. окно
load-overview
- 10.7.2. Статистическая информация об узле
- 10.7.3. окно memory-overview
- 10.7.4. openMosixhistory
- 10.7.2. Статистическая информация об узле
- 10.7.1. окно
load-overview
- 10.8. openMosixmigmon
-
- 10.8.1. Описание
- 10.8.2. Подсказки:
- 10.8.3. Drag'n Drop!
- 10.8.2. Подсказки:
- 10.8.1. Описание
- 10.9. openMosixView
FAQ
- 10.10. openMosixView + SSH
- 10.1. Введение
- 11. Прочие проекты, связанные с openMosix
-
- 11.1. Введение
- 11.2. openMosixView
- 11.3. openMosixApplet
- 11.4. wmonload
- 11.5. openMosixWebView
- 11.2. openMosixView
- 11.1. Введение
- 12. Распространённые проблемы и ошибки
-
- 12.1. Введение
- 12.2. Процессы не хотят мигрировать!
- 12.3. Я не вижу все свои узлы!
- 12.4. Я постоянно получаю ошибки типа: No such process
- 12.5. DFSA? MFS?
- 12.6. Проблемы с Python
- 12.2. Процессы не хотят мигрировать!
- 12.1. Введение
- 13. Советы и подсказки
-
- 13.1. Запертые
процессы
- 13.2. О выборе процессов
- 13.3. Java и openMosix
- 13.4. openMosix и Hyperthreading
- 13.5. openMosix и брандмауэры
- 13.2. О выборе процессов
- 13.1. Запертые
процессы
- 14. (стресс) Тестирование работы вашей openMosix-системы
-
- 14.1. Небольшой
тестовый скрипт
- 14.2. Программа тестирования на Perl'е от Charles Nadeau
- 14.3. Стресс-тест openMosix
- 14.2. Программа тестирования на Perl'е от Charles Nadeau
-
- 14.3.1. Общее
описание
- 14.3.2. Подробное описание
- 14.3.3. Установка комплекта strestest
- 14.3.4. Пример запуска тестов
- 14.3.2. Подробное описание
- 14.3.1. Общее
описание
- 14.1. Небольшой
тестовый скрипт
Содержание
- 8.1. Основы
Администрирования
- 8.2. Конфигурация
- 8.3. Пользовательские утилиты
- 8.4. Кластерная маска
- 8.2. Конфигурация
openMosix позволяет получить преимущество от миграции процессов HPC-приложений. Администратор может сконфигурировать openMosix-кластер при помощи пакета openMosix-user-space-tools или интерфейса /proc/hpc, который будет подробно описан в главе Пользовательские утилиты.
Вплоть до версии openMosix 2.4.16 /proc интерфейс назывался /proc/mosix! Начиная с версии 2.4.17 он называется /proc/hpc.
Значения в текстовых файлах в каталоге /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. Информация о других узлах в кластере
Таблица 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 | статистика об использовании процессом процессора |
Перечисленные ниже утилиты облегчают процесс администрирования кластеров 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.
Многие пользователи просили добавить в 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.1. Введение
- 9.2. Создание мастер-узла
- 9.3. Оптимизация Mosix
- 9.4. Простое соединение каналов (Channel Bonding)
- 9.5. Updatedb
- 9.6. openMosix и FireWire
- 9.2. Создание мастер-узла
Некоторые нижеследующие части всё ещё относятся к старому документу Mosix HOWTO, но со временем они будут заменяться частями, соответствующими openMosix, тем не менее, многие утверждения могут ещё совпадать.
Вообще-то сама архитектура openMosix не требует создания мастер-узла как такового, тем не менее, вы наверняка выделите какой-нибудь головной узел, с которого вы будете запускать процессы. Такую роль может также играть и мультиузел, с которого пользователи подключаются к кластеру. Проще говоря, вы должны сконфигурировать этот узел так, чтобы процессы с него мигрировали на другие узлы.
Для всего этого необходимо заставить этот узел “думать”, что он – самый медленный, и что лучше мигрировать его процессы на более быстрые соседние узлы. Такого эффекта можно добиться следующей “замедляющей” командой:
mosctl setspeed [n] |
где значение n должно быть намного ниже, чем скорость других узлов. Теперь процессы довольно быстро мигрируют на другие узлы. Узнать же скорость любого узла можно командой:
mosctl getspeed |
Редакторский комментарий: Приведённые ниже команды могут изменяться в последующих версиях openMosix.
Подключитесь к терминалу с правами пользователя root. Выполните команду:
setpe -r |
Эта команда должна вывести на экран файл /etc/openmosix.map. Если этого не произошло, то попробуйте такую команду
setpe -w -f /etc/mosix.map |
для конфигурирования вашего узла. Следующая команда
cat /proc/$$/lock |
покажет, могут ли процессы потомки мигрировать с данного узла (0) или нет (1). Если же они заблокированы, то вы можете разблокировать их командой
echo 0 > /proc/$$/lock |
Проделайте аналогичную конфигурацию на другом компьютере. К сожалению, программы tune_kernel и prep_tune, которые Mosix использует для калибровки отдельных узлов, не работают в дистрибутиве SuSE Linux. Тем не менее, с этим можно побороться. Для начала переведите компьютер, подлежащий настройке, а также второй компьютер с Mosix в однопользовательский режим командой
init 1 |
(разумеется, все действия надо выполнять с правами root). Все остальные компьютеры в сети желательно отключить вообще. На обеих машинах выполните следующие команды:
/etc/init.d/network start /etc/init.d/mosix start echo 1 > /proc/mosix/admin/quiet |
Это позволит “обмануть” prep_tune и поначалу tune_kernel. Также учтите, что если у вас ноутбук с сетевой картой PCMCIA, то вам надо запускать/etc/init.d/pcmcia start вместо /etc/init.d/network start. На компьютере, который вы настраиваете, запустите tune_kernel и следуйте инструкциям. В зависимости от ваших машин, процесс работы этой программы может занять значительное время – если у вас есть собачка, то можете даже пойти и прогуляться с ней. tune_kernel создаст тестовую программу pg в каталоге /root, не обращайте на неё внимания. После того как процесс настройки закончился, скопируйте содержимое /tmp/overheads в файл /etc/overheads (и/или перекомпилируйте ядро). Повторите процедуру настройки на каждом компьютере. Теперь можно перезагрузиться и наслаждаться openMosix, и не забудьте похвастаться перед друзьями своим новым кластером.
На самом деле соединение каналов просто до смешного. Наверное, это и объясняет отсутствие документации на эту тему. Объединённая сеть для приложений выглядит как самая обычная сеть. Все машины в подсети должны быть объединены одинаковым способом. Объединённые и не объединённые машины практически никак не сообщаются друг с другом.
Объединение каналов требует как минимум две физические подсети, которых, тем не менее, может быть и больше (например, у меня сейчас тройной связанный кластер). Для поддержки этой возможности нужно встроить в ядро (или модуль ядра bonding.o) поддержку Channel Bonding, в версиях ядра 2.4.x – это стандартная опция ядра. Сетевые карты настраиваются как обычно за исключением того, что ifconfig надо использовать для активации первой сетевой карты в связке. Утилита ifenslave используется для активации оставшихся сетевых карт связанного соединения. Программу ifenslave можно найти в каталоге с исходным кодом ядра /linux/Documentation/network/. Её нужно будет скомпилировать, поскольку это просто файл на С. Пример использования программы таков:
ifenslave <master> <slave1> <slave2> ... |
Сети с объединёнными каналами могут соединяться с обычными сетями посредством маршрутизатора или моста, поддерживающего технологию Channel Bonding (я просто использую дополнительную сетевую карту и перенаправление портов на головном узле).
Вообще говоря, использование updatedb в комбинации с MFS может вызвать некоторые проблемы: чтобы отключить индексацию точек монтирования, можно добавить /mfs в PRUNEFPATHS или mfs в PRUNEFS в опции файла /etc/updatedb.conf.
openMosix работает с гораздо большим эффектом на этом типе оборудования, подробнее написано в документе openMosix и FireWire
Содержание
- 10.1. Введение
- 10.2. openMosixView по сравнению с Mosixview
- 10.3. Установка
- 10.2. openMosixView по сравнению с Mosixview
-
- 10.3.1. Установка
из .rpm-пакета
- 10.3.2. Установка из исходных текстов
- 10.3.3. Автоматический установочный скрипт
- 10.3.4. Компиляция вручную
- 10.3.5. Советы по компиляции
- 10.3.2. Установка из исходных текстов
- 10.3.1. Установка
из .rpm-пакета
- 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.4.2. Окно конфигурации
- 10.4.1. Основная
программа
- 10.5. Окно openMosixprocs
-
- 10.5.1. Введение
- 10.5.2. Окно migrator
- 10.5.3. Управление удалёнными процессами
- 10.5.2. Окно migrator
- 10.5.1. Введение
- 10.6. openMosixcollector
- 10.7. openMosixanalyzer
-
- 10.7.1. окно
load-overview
- 10.7.2. Статистическая информация об узле
- 10.7.3. окно memory-overview
- 10.7.4. openMosixhistory
- 10.7.2. Статистическая информация об узле
- 10.7.1. окно
load-overview
- 10.8. openMosixmigmon
-
- 10.8.1. Описание
- 10.8.2. Подсказки:
- 10.8.3. Drag'n Drop!
- 10.8.2. Подсказки:
- 10.8.1. Описание
- 10.9. openMosixView
FAQ
- 10.10. openMosixView + SSH
openMosixView – это следующая версия Mosixview, переписанная заново. Любой может свободно скачать и использовать этот GUI для openMosix-кластера (разумеется, на свой страх и риск). openMosixView состоит из пяти приложений для мониторинга и администрирования кластера.
Все эти приложения доступны из основного окна приложения. Наиболее используемые команды openMosix выполняются в несколько щелчков мышью, а развитый диалог запуска команд упрощает запуск приложений в кластере. Так называемые “ползунки приоритета” для каждого узла делают простым и наглядным процесс ручной и автоматической балансировки нагрузки. Сейчас openMosixView полностью адаптирован к службе автообнаружения openMosix и использует все параметры настройки кластера через /proc интерфейс.
openMosixView спроектирован специально для кластера openMosix. Веб-сайт проекта Mosixview (и все его зеркала) всё ещё действуют, но всё, что касается разработки openMosixView, находится на своём собственном сайте: www.openmosixview.com.
Если у вас есть вопросы, проблемы с установкой, комментарии, или просто думаете что программе не хватает какой-либо опции или хотите поделиться своим опытом, то можете написать автору программы (Matt Rechenburg), или подписаться на список рассылки openMosix/Mosixview-mailing-list и пообщаться непосредственно через него.
изменения: (для Mosixview 1.1) openMosixView отличается от Mosixview тем, что переписан “с нуля”! У него есть все те же функции Mosixview, но во все части исходного кода openMosixView внесены фундаментальные изменения. openMosixView тестируется на кластерах с постоянно меняющейся топографией, а все “сомнительные” части были удалены или переписаны заново, за счёт чего приложение стало намного стабильней.
-
адаптирован для автообнаружения openMosix
-
больше не использует файл /etc/mosix.map или какой другой файл-карту вообще
-
удалён некорректный код парсера .map-файла
-
переписаны все части/функции/методы в соответствии с правилами чистого C++
-
исправлены небольшие недочёты при работе с экраном
-
приложение MosixMem+Load заменено на openMosixanalyzer
-
… и множество других изменений
Требования
-
библиотека 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.
Скачайте последнюю версию .rpm-пакета openMosixView. Затем просто выполните следующую команду:
rpm -i openmosixview-1.4.rpm |
Она установит двоичные файлы в каталог /usr/bin. Для удаления пакета выполните:
rpm -e openmosixview |
Скачайте самую последнюю версию openMosixView и распакуйте архив, например, в /usr/local/.
gunzip openmosixview-1.4.tar.gz tar -xvf openmosixview-1.4.tar |
Для его запуска просто перейдите в каталог openmosixview и выполните команду
./setup [путь_к_установленным_библиотекам_qt_2.3.x_] |
Установите переменную окружения QTDIR в соответствии с установленным в системе дистрибутивом QT, т.е.
export QTDIR=/usr/lib/qt-2.3.0 (для bash) |
или
setenv QTDIR=/usr/lib/qt-2.3.0 (для csh) |
(отдельная благодарность пользователям, протестировавших компиляцию 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 |
Вот так выглядит основное окно приложения. Принцип работы с ним описан далее.
![](omview1.gif)
Окно openMosixView содержит такие элементы как индикатор, кнопку, ползунок (слайдер), поле с цифровым значением, индикатор выполнения и текстовые метки для каждого узла кластера. Цветовые индикаторы слева отображают openMosixview-ID и статус узла. Красная обозначает, что узел не активен, а зелёная наоборот – активное состояние.
Если вы нажмёте кнопку с IP-адресом узла, то появится конфигурационное окно. Оно содержит кнопки для выполнения наиболее общих команд mosctl. Ползунками же устанавливается значение openMosix-скорости для узла. Текущее значение скорости отображается в поле с цифровым значением.
Манипулируя этими значениями скоростей можно влиять на балансировку нагрузки кластера. В openMosix-кластере процессы мигрируют на узлы с бОльшим значением openMosix-скорости. Естественно, что это – не физическое быстродействие узла, но именно по этому значению openMosix “определяет” её для себя, другими словами, при запуске требовательной к процессору задаче на узле, с установленным наименьшим значением скорости, миграция такого процесса на другие узлы с более высоким значением скорости будет эффективнее.
Индикаторы выполнения посередине окна представляют картину нагрузку на каждом узле кластера. Они отображают лишь процентное соотношение, а не точное значение из /proc/hpc/nodes/xload.
Следующий индикатор показывает количество памяти на узлах, опять же в процентном отношении от общей доступной памяти на хостах. Ещё правее можно увидеть, сколько процессоров доступно в вашем кластере. В первой строке основного окна приложения есть кнопка с надписью “all-nodes”, как можно догадаться, с её помощью возможно задать единую конфигурацию для всех узлов.
Индикатор состояния вверху слева показывает, насколько хорошо работает механизм распределения нагрузки. 100% – это очень хорошее значение, и означает, что на всех узлах нагрузка примерно одинакова.
Для управления openMosixcollector и openMosixanalyzer нужно воспользоваться меню “collector” и “analyzer”. Эти две части openMosixView полезны для анализа состояния кластера в длительный промежуток времени.
Это окно появится после нажатия кнопки “cluster-node”.
![](omview2.gif)
Данный диалог позволяет довольно просто и быстро произвести настройку любого хоста 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 будет отображаться на вашей машине, а не на том узле, на котором вы зарегистрировались. В поле ввода есть история ввода значений, так что вам больше не надо будет каждый раз набирать имя хоста.
Если вы хотите запустить задания в кластере, то диалог "advanced execution" может сильно упростить эту задачу.
![](omview3.gif)
Нажмите кнопку “run-prog” и выберите программу для запуска; здесь же можно указать, как и где выбранная программа будет выполняться. Возможно несколько вариантов выполнения этой процедуры, давайте рассмотрим их подробнее.
Вы можете указать дополнительные аргументы командной строки в поле ввода вверху окна.
Таблица 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) |
Для всех задач, запускаемых не локально, можно использовать этот диалог. Для его запуска просто щёлкните на имени хоста. Значение openMosix-Node_ID отображается в виде lcd-цифры. Теперь щёлкните на execute для запуска задачи.
Этот менеджер процессов очень полезен при манипуляции процессами на вашем кластере.
![](omview4.gif)
Эту программу необходимо установить на каждом узле кластера!
Перечень процессов позволяет получить представление обо всех запущенных процессах. Во второй графе отображены openMosix ID каждого процесса. Здесь цифра 0 означает, что процесс локальный, любые другие цифры символизируют процессы удалённых узлов. Мигрирующие процессы имеют зелёные иконки, а запертые процессы обозначены символом замка.
Если дважды кликнуть на процессе из списка, то появится диалог управления миграцией процесса. Здесь есть опции для миграции процесса на удалённые узлы, отправка процессу сигналов SIGSTOP и SIGCONT, а также доступна манипуляция процессом наподобие команды renice.
Кнопка “manage procs from remote” открывает диалог, показывающий процессы, мигрировавшие на данный хост.
Этот диалог появляется, если кликнуть на каком-либо процессе из окна списка процессов.
![](omview5.gif)
Окно openMosixview-migrator отображает все узлы вашего кластера, но предназначен для управления лишь одним процессом. Двойным щелчком на хосте из списка можно заставить процесс мигрировать на этот хост. После этого иконка выбранного процесса сменится на зелёную, означая, что процесс выполняется на удалённой машине.
Кнопка “home” позволяет отправить процесс на его UHN. В свою очередь, кнопкой “best” процесс можно отправить на наилучший из доступных узлов кластера. В целом, процесс миграции зависит от нагрузки, скорости, процессоров и того, что openMosix “думает” о каждом узле. Наиболее вероятно, что процесс мигрирует на хост с наиболее мощным процессором и значением скорости. Кнопка “kill” позволяет моментально уничтожить доступный процесс.
Чтобы временно остановить выполнение программы, просто нажмите кнопку “SIGSTOP”, а чтобы затем продолжить – нажмите “SIGCONT”. Ползунком, расположенным ниже, вы можете манипулировать приоритетом выбранного процесса (-20 значит очень высокий, 0 – нормально, а 20 – очень низкий).
Этот диалог появляется при нажатии кнопки “manage procs from remote”
![](omview6.gif)
Здесь TabView отображает процессы, мигрировавшие на данный хост – т.е. процессы, пришедшие с других узлов кластера и выполняющиеся на машине, на которой запущен openMosixView. Точно также, как и в случае с окном migrator, процесс можно отправить на UHN кнопкой “goto home node” или на наилучший из доступных узлов кластера (кнопка “goto best node”).
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.
Здесь отображается хронология нагрузки openMosix.
![](omview7.gif)
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” для каждого узла показывает некоторые полезные статистические данные. Если кликнуть на неё, то появится небольшое окно, содержащее показатели средней нагрузки, использования памяти и подобные статистические и динамические полезные данные об определённом узле или о кластере в целом.
![](omview9.gif)
Если в истории нагрузки были контрольные точки, то они показаны здесь вертикальной синей чертой. Теперь вам намного легче сравнить значения нагрузки в определённый момент времени.
![](omview8.gif)
Здесь представляется обзор использования памяти (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 записал контрольные точки в историю памяти, то они будут отображены вертикальной синей чертой
![](omview10.gif)
показывает список процессов, выполнявшихся ранее
openMosixhistory позволяет посмотреть, какой процесс выполнялся ранее на любом из узлов. openMosixcollector сохраняет список этих процессов с того хоста, на котором он был запущен, и именно эту информацию вы и можете просмотреть при помощи openMosixhistory. Частоту сохранения можно изменить при помощи ползунка в openMosixhistory.
openMosixhistory умеет анализировать текущие файлы журналов, но также возможно открывать и архивы журналов через меню.
![](ommigmon2.gif)
openMosixmigmon – это монитор всех миграций процессов в вашем кластере. Он отображает все ваши узлы в виде маленьких пингвинов, сидящих в центре круга.
-> nodes-circle.
Центральный круг с пингвином – это узел, на котором запущен openMosixmigmon, а вокруг этого узла показаны его процессы, также в круге, как небольшие чёрные квадраты.
-> main process-circle
Если процесс мигрирует на один из узлов, то у него также появляется круг из процессов, в который входит и процесс, мигрировавший на неё. После этого данный процесс помечается зелёным цветом, и прорисовывает линию от своего источника к удалённому узлу, символизируя таким образом процесс миграции.
openMosixmigmon полностью поддерживает механизм Drag'n Drop. Вы можете брать любой процесс и бросать его на любой из узлов (обозначенных пингвинами) – таким образом, этот процесс будет мигрировать туда. Если дважды кликнуть на процесс на удалённом узле, то он сразу же будет отправлен на свой UHN.
- 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.2. Можно ли использовать openMosixViewopenMosixView с SSH?
10.9.1. |
У меня не получается скомпилировать openMosixView на моей системе? |
Для начала следует проверить, установлены ли библиотеки QT >= 2.3.x. Также проверьте, установлена ли переменная окружения QTDIR в соответствии с каталогами установки, как описано в INSTALL-файле. В версиях < 0.6 можно выполнить команду make clean и удалить два файла: /openmosixview/Makefile и /openmosixview/config.cache, и попробовать скомпилировать ещё раз. Если у вас всё равно возникли какие-либо проблемы при сборке, то пишите о них в openMosixview-mailinglist (или сразу мне). Смотри также главу Советы по компиляции | |
10.9.2. | |
Да, начиная с версии 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. Если кто-нибудь из читателей знает хороший способ сбора этой информации с узлов, то я буду рад, если вы сообщите мне о нём. |
(это 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.1. Введение
- 11.2. openMosixView
- 11.3. openMosixApplet
- 11.4. wmonload
- 11.5. openMosixWebView
- 11.2. openMosixView
Есть и другие приложения, позволяющие контролировать openMosix. В этой главе будет представлен краткий обзор таких проектов.
openMosixView – наиболее известное и часто используемое приложение для администрирования openMosix. Более подробно о нём рассказывается в главе openMosixView.
openMosixApplet позволяет просматривать нагрузку в openMosix кластере в режиме реального времени. Программа представляет собой локальный демон, который слушает все соединения апплета. Апплет основан на chart2D и выглядит довольно симпатично.
wmomload – это простой dockapp, показывающий нагрузку на узлах в небольшом openMosix-кластере.
openMosixWebView генерирует веб-диаграммы и графы, отображающие состояние openMosix кластера. openMosixWebView представляет собой скрипт на PHP для мониторинга openMosix кластера через WEB-браузер. Использует логи openMosixCollector (из состава openMosixview). Скачать последний релиз можно отсюда openmosixwebview-0.2.12.tar.gz (16 Feb 2003).
См. снимки экрана запущенного openMosixWebView :-) Выпущен под лицензией GNU General Public License (GPL). См. README и FAQ.
Содержание
- 12.1. Введение
- 12.2. Процессы не хотят мигрировать!
- 12.3. Я не вижу все свои узлы!
- 12.4. Я постоянно получаю ошибки типа: No such process
- 12.5. DFSA? MFS?
- 12.6. Проблемы с Python
- 12.2. Процессы не хотят мигрировать!
Большинство из приведенных проблем в этой главе могли бы войти в FAQ, но здесь, в отличие от ограничений FAQ, можно дать более подробный ответ на возникшую проблему и попытаться объяснить её.
Помогите, процесс XYZ не мигрирует. Ниже Moshe Bar постарался объяснить, почему одни процессы мигрируют, а другие нет. Тем не менее, предварительно загляните в /proc/$pid/, там может быть файл cantmove, который может подсказать вам, почему же определённый процесс не может мигрировать.
Также процесс может быть просто заблокирован. Чтобы это проверить, посмотрите файл:
cat /proc/$PID/lock |
где $PID – это ID проблемного процесса.
А теперь посмотрим что говорит об этом сам Moshe.
Иногда подобные проблемы возникают при использовании одного ядра, но на разных дистрибутивах, к примеру, кластер из смешанных узлов под RedHat или Debian, а rc-скрипты, запускающие на них openMosix, немного различаются. Некоторые версии имеют сильно модифицированный /etc/inittab, запускающий все демоны (и их потомков) при помощи mosrun -h. Таким образом получается, что процессы не могут нормально мигрировать. Следовательно, все эти процессы имеют значение 1 в файле /proc/pid/lock при старте. Но можно заставить их мигрировать, записав 0 в этот файл.
Рассмотрим пример. Есть небольшая программа, которая должна мигрировать, если она запущена в количестве, превышающем количество процессоров на локальной машине. То есть, на двухпроцессорной SMP машине запуск программы в трёх экземплярах заставит её мигрировать, если другие узлы кластера по скорости хотя бы сопоставимы с локальной:
int main() { unsigned int i; while (1) { i++; } return 0; } |
На процессоре Pentium 800Mhz она достигает переполнения довольно быстро.
А вот, к примеру, подобная программа никогда не будет мигрировать:
#include <sys/types.h> #include <sys/ipc.h> #include <sys/shm.h> ... key_t key; /* key to be passed to shmget() */ int shmflg; /* shmflg to be passed to shmget() */ int shmid; /* return value from shmget() */ int size; /* size to be passed to shmget() */ ... key = ... size = ... shmflg) = ... if ((shmid = shmget (key, size, shmflg)) == -1) { perror("shmget: shmget failed"); exit(1); } else { (void) fprintf(stderr, "shmget: shmget returned %d\n", shmid); exit(0); } ... |
Программы, использующие каналы, тоже должны нормально мигрировать:
int pdes[2]; pipe(pdes); if (fork() == 0) { /* child */ close(pdes[1]); /* not required */ read(pdes[0]); /* read from parent */ ... } else { close(pdes[0]); /* not required */ write(pdes[1]); /* write to child */ ... } |
Программы, использующие pthreads версии 2.4.17 и выше, не мигрируют, но, тем не менее, уже и не завершаются аварийно.
// // Very simple program demonstrating the use of threads. // // Command-line argument is P (number of threads). // // Each thread writes "hello" message to standard output, with // no attempt to synchronize. Output will likely be garbled. // #include <iostream> #include <cstdlib> // has exit(), etc. #include <unistd.h> // has usleep() #include <pthread.h> // has pthread_ routines // declaration for function to be executed by each thread void * printHello(void * threadArg); // ---- Main program ------------------------------------------------- int main(int argc, char* argv[]) { if (argc < 2) { cerr << "Usage: " << argv[0] << " numThreads\n"; exit(EXIT_FAILURE); } int P = atoi(argv[1]); // Set up IDs for threads (need a separate variable for each // since they're shared among threads). int * threadIDs = new int[P]; for (int i = 0; i < P; ++i) threadIDs[i] = i; // Start P new threads, each with different ID. pthread_t * threads = new pthread_t[P]; for (int i = 0; i < P; ++i) pthread_create(&threads[i], NULL, printHello, (void *) &threadIDs[i]); // Wait for all threads to complete. for (int i = 0; i < P; ++i) pthread_join(threads[i], NULL); // Clean up and exit. delete [] threadIDs; delete [] threads; cout << "That's all, folks!\n"; return EXIT_SUCCESS; } // ---- Code to be executed by each thread --------------------------- // pre: *threadArg is an integer "thread ID". // post: "hello" message printed to standard output. // return value is null pointer. void * printHello(void * threadArg) { int * myID = (int *) threadArg; cout << "hello, world, "; // pointless pause, included to make the effects of // synchronization (or lack thereof) more obvious usleep(10); cout << "from thread " << *myID << endl; pthread_exit((void*) NULL); } |
Программы, использующие все виды файловых дескрипторов (описателей), включая и сокеты, также мигрируют (естественно, что сокеты не мигрируют вместе с процессом, а файлы мигрируют только при использовании oMFS/DFSA)
(весь вышеприведённый код написан Moshe, он же Moshe Bar, он же Moshe – CTO компании Qlusters, Inc.)
Пожалуйста, прочтите также man страницы openMosix, в них также содержится исчерпывающая информация о миграции процессов.
Если по какой-либо причине ваши процессы остаются запертыми, хотя по идее не должны бы, то попробуйте разрешить миграцию запертых процессов, добавив команду
# разрешает подпроцессам мигрировать на другие узлы echo 0 > /proc/self/lock |
в файл /etc/profile.
![]() |
Внимание |
---|---|
Это позволит мигрировать всем процессам, а не тем, которые вы хотите. Для указания миграции определённых процессов используйте утилиту mosrun -l для разблокировки нужного процесса. |
Для начала убедитесь, что вы используете одинаковые версии ядра на каждой машине. Под этим подразумевается именно версия ядра, а не набор опций и модулей, включенных в него для поддержки аппаратных ресурсов узла. То же самое относится и к установке openMosix: версия ядра должна совпадать на всех узлах, к примеру, ядро openmosix-x.x.x-y установлено на всех машинах, а не так, что на одной – openmosix-x.x.x-x, на другой – openmosix-x.x.x-y, на третьей – openmosix-x.x.x-z и т.д.
Запустите в консоли программу mosmon и нажмите клавишу t для просмотра списка работающих машин. Не появилось ли сообщения о том, что Mosix не запущен?
Если появилось, то проверьте наличие IP-адреса в файле /etc/openmosix.map в случае, если вы не пользуетесь omdiscd (но только не используйте 127.0.0.1: если у вашей машины такой IP-адрес, то, вероятно, у вас проблемы с сервером имён или DHCP). Если же сообщения о том, что openMosix не запущен, нет, то посмотрите, какие машины обнаружены. Видите ли вы только свою машину?
Если да, то наиболее вероятно, что ваша машины отделена от других брандмауэром, который не пропускает трафик openMosix.
Если же это не так, то проблема может быть и в самой машине, которая не обнаруживается. Да, а не используете ли вы две сетевые карты на узле? В этом случае необходимо отредактировать файл /etc/hosts, добавив в него ваши значения в похожем формате:
non-cluster_ip cluster-hostname.cluster-domain cluster-hostname |
Помимо этого, вам также может понадобиться настроить таблицу маршрутизации, что уже является темой отдельной главы.
Ко всему прочему, такая проблема может быть вызвана в связи с использованием разных параметров ядра на разных машинах. В частности, если вы использовали опцию 'Support clusters with a complex network topology', то убедитесь, что и в опции 'Maximum network-topology complexity support' вы использовали одинаковое значение на всех узлах.
Например, вот такая ошибка
bash: child setpgid (4061 to 4061): No such process |
что это значит?
Такое сообщение означает, что оболочка, которую вы использовали, мигрировала на другой узел. А вывод такого сообщения в bash вызван ошибкой в старой версии openMosix, которая давно устранена. (Muli Ben-Yehuda <mulix@actcom.co.il>)
Многие часто путаются, говоря об MFS и DFSA. Как было описано ранее в главе Файловая система openMosix (oMFS), MFS – это функция openMosix, предоставляющая возможность доступа к удалённым файловым системам так, как будто они смонтированы локально. Обычно они монтируются в /mfs. Наиболее распространённое заблуждение в том, что поддержка MFS обязательно необходима для работы openMosix, что в корне не верно, хотя MFS действительно может быть очень полезна.
Поддержка DFSA позволяет выполнять системные вызовы на удаленных узлах без миграции процесса обратно на его UHN. Такое поведение (прямой доступ к файловой системе) заставляет процессы мигрировать к данным, а не наоборот. При отсутствии поддержки DFSA, MFS играет роль обычной некэширующей файловой системы.
Если в двух словах, то при выключенной DFSA абсолютно каждый запрос на ввод/вывод будет возвращаться на UHN для выполнения. Если же DFSA включена, то процесс ввода/вывода будет происходить локально.
Очень частая ошибка: многие используют ядра как с поддержкой DFSA, так и без неё. Так что необходимо окончательно определиться, будете ли вы использовать DFSA или нет. Информацию о том, поддерживает ли ядро DFSA или нет, можно такой командой:
cat /proc/hpc/admin/version |
Некоторые пользователи заметили проблемы, возникающие при работе с Python. Как выяснилось, это проблемы, относящиеся не к openMosix, а к glibc.
Возможно, решение проблемы – простое удаление /lib/i686/lib*, таким образом позволив приложениям линковать динамически /lib/libpthread (или другие). К счастью, исправления в новых версиях glibc и openMosix помогли решить подобные проблемы.
Содержание
- 13.1. Запертые
процессы
- 13.2. О выборе процессов
- 13.3. Java и openMosix
- 13.4. openMosix и Hyperthreading
- 13.5. openMosix и брандмауэры
- 13.2. О выборе процессов
Если по какой-то причине процессы остаются постоянно запертыми на домашнем узле, и вы не можете выяснить причину этого, то как решение можно добавить следующие команды в ваш файл ~/.profile, которые автоматически включают миграцию:
if [ -x /proc/$$/lock ]; then echo 0 > /proc/$$/lock fi |
Тем не менее, рекомендуется всё же выяснить причину вашей проблемы.
Наверняка вы захотите протестировать настройку своего кластера перед тем, как решать, какие программы будут мигрировать. К примеру, вы работаете в KDE на слабой машине, хотя у вас есть и намного более мощные машины в кластере. В этом случает можно мигрировать ресурсоёмкие программы типа kmail. Ничего страшного при этом не произойдёт: самое неприятное, что может быть, – это просто небольшая задержка вывода текста на экран при наборе.
Программы, использующие Green Threads из JVM, мигрируют без особых проблем, т.к. при этом каждый поток Java – это отдельный процесс. Потоки, отличные от Java Green Threads, не мигрируют в Linux, поэтому openMosix также не сможет обеспечить миграцию программ, использующих эти потоки.
Если у вас есть исходный код вашего Java приложения, то можно скомпилировать его для конкретной машины. В этом случае такое приложение будет мигрировать и на другие узлы.
Gian Paolo Ghilardi написал статью под заголовком “Consideration on openMosix” (Размышления об openMosix), в которой, помимо всего прочего, затронута и тема о Java и openMosix. http://www.democritos.it/events/openMosix/papers/crema.pdf
По правде говоря, производительность openMosix возрастает, если поддержка Hypethreading отключена. Это можно сделать добавив параметр загрузки ядра “noht”, или отключив Hypethreading в BIOS.
Для тех, кто ещё не знает, что такое hypetrheading: объяснение Hypethreading от Intel.
Очень часто возникают вопросы относительно openMosix и брандмауэров. Всё очень просто (из файла hpc/comm.c):
#define MIG_DAEMON_PORT 0x3412 #define INFO_DAEMON_PORT 0x3415 |
что в десятичной системе значит 4660 и 5428 соответственно (преобразовывается число 1234, а не 3412, “в связи с порядками преобразования байт сети-узла”; подробности читайте в IP/TCP/UDP RFC).
Здесь порт mig_daemon это TCP порт, а порт info_daemon – UDP. Следовательно, TCP/4660 и UDP/5428.
Содержание
- 14.1. Небольшой
тестовый скрипт
- 14.2. Программа тестирования на Perl'е от Charles Nadeau
- 14.3. Стресс-тест openMosix
- 14.2. Программа тестирования на Perl'е от Charles Nadeau
-
- 14.3.1. Общее
описание
- 14.3.2. Подробное описание
- 14.3.3. Установка комплекта strestest
- 14.3.4. Пример запуска тестов
- 14.3.2. Подробное описание
- 14.3.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 на домашнем узле.
Программа на 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; } |
Стресс-тест сделан с целью тестирования openMosix кластера и ядра. Он выполняет несколько тестов приложений и ядра на предмет устойчивости, и различных опций openMosix (таких как миграция процессов, MFS…). В процессе теста кластер нагружается по максимуму, так что рекомендуется остановить другие приложения перед запуском теста. По окончании теста генерируется подробный отчёт о каждой протестированной компоненте.
Стресс-тест 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 раз.
Сначала загрузите .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).
[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) |
Содержание
Содержание
- 15.1. Введение
Работа над эти разделом в процессе.
Многие люди пытаются использовать openMosix как подобие компилирующей фермы, очень часто они возвращаются назад очень разочарованными. Эта глава HOWTO попытается объяснить, в каких случаях ваши компиляции выиграют от openMosix, и как улучшить ваш уровень успеха.
Прежде всего, вы должны запомнить одну вещь: openMosix не будет мигрировать все процессы, которые вы запускаете на кластере, но только те, которые выиграют от миграции к другому узлу. Для сбора информации об этом это значит, что процесс должен выполнятся достаточно долго. Компиляция ядра обычно состоит из многих коротких компиляций, каждая из которых не достаточно продолжительна для действительной миграции.
Работа над эти разделом в процессе.
Компьютерная графика всегда было приложением, которое требовало много мощности CPU, – это не изменилось. В рамках этой главы я продемонстрирую некоторые практические примеры того, как компьютерная графика может выиграть от openMosix.
The Persistence of Vision Raytracer – это высококачественный, абсолютно свободный инструмент для создания ошеломляющей трёхмерной графики.
Трассировка лучей – это техника визуализации, которая вычисляет картинку сцены посредством симуляции того, как луч света движется в реальном мире. Тем не менее, она делает работу наоборот. В реальном мире лучи света испускаются из источников света и иллюминирующих объектов. Этот отражённый свет попадает в наши глаза или, возможно, в объектив камеры. Поскольку подавляющее большинство лучей никогда не попадают к обозревателю, это бы заняло вечность протрассировать сцену.
Этот тип приложений может легко быть распараллелен используя pvmpovray. Ожидается, что pvmpovray работает на кластере в стиле Beowulf и распределяет его нагрузку по другим узлам кластера используя PVM. Способ openMosix выполнения этого точно такой же, хотя мы просто делаем всё на одной машине, и у нас есть openMosix, который производит распределение нагрузки за вас!
Великолепный HOWTO по PVM Povray покажет вам, как установить PVMPovray. Ниже – краткое изложение.
$ cd pvmpov3_1g_2 $ tar xfz ../povuni_s.tgz $ tar xfz ../povuni_d.tgz $ ./inst-pvm Trying to apply the patch. Searching for rejected files $ |
Теперь скомпилируйте с помощью aimk, который является скриптом-обёрткой, предоставляемый PVM .rpm, но который, вероятно, не окажется в вашем PATH (некоторые читатели могут вспомнить aimk из других платформ/приложений).
Если вы под RedHat 8.0, я бы поместил libpng и zlib в .notused… Это нужно, чтобы предотвратить проблемы версий с другими версиями libpng и zlib.
export PATH=$PATH:/usr/share/pvm3/lib export PVMROOT=/usr/share/pvm3 |
После этого я выполнил aimk newunix. Затем мы запускаем pvm и выходим из него. Демон остаётся активным…
И последняя вещь, которая не известна начинающему пользователю PVM, это то, что PVM использует свои пути, и вы должны либо поместить pvmpov в свои пути, либо запускать её, задавая полный путь.
[root@dhcp71 povray31]# /usr/local/bin/pvmpov -L /usr/src/povray/pvmpov3_1g_2/povray31/include/ +Iskyvase.pov +Oskyvase.tga +NT16 +NW64 +NH64 +v +w1024 +h768 Persistence of Vision(tm) Ray Tracer Version 3.1g.Linux.gcc This is an unofficial version compiled by: Jakob Flierl - PVMPOV Version 3.1g.2 The POV-Ray Team(tm) is not responsible for supporting this version. Copyright 1999 POV-Ray Team(tm) Never found section in file /usr/src/povray/pvmpov3_1g_2/povray31/include/. Initializing PVMPOV Spawning /usr/local/bin/pvmpov with 16 PVM tasks on 1 hosts... ...16 PVM tasks successfully spawned. Waiting up to 120s for first slave to start... Slave 0 successfully started. Parsing Options Input file: skyvase.pov (compatible to version 3.1) Remove bounds........On Split unions........Off Library paths: /usr/local/lib/povray31 /usr/local/lib/povray31/include Output Options Image resolution 1024 by 768 (rows 1 to 768, columns 1 to 1024). Output file: skyvase.tga, 24 bpp PNG Graphic display.....Off Mosaic preview......Off CPU usage histogram.Off Continued trace.....Off Allow interruption...On Pause when done.....Off Verbose messages.....On Tracing Options Quality: 9 Bounding boxes.......On Bounding threshold: 25 Light Buffer.........On Vista Buffer.........On Antialiasing........Off Radiosity...........Off Animation Options Clock value.... 0.000 (Animation off) PVM Options Block Width.... 64 Block Height... 64 PVM Tasks...... 16 PVM Nice....... 5 PVM Arch....... PVM Slave...... /usr/local/bin/pvmpov PVM WorkingDir. /usr/src/povray/pvmpov3_1g_2/povray31 Redirecting Options All Streams to console..........On Debug Stream to console.........On Fatal Stream to console.........On Render Stream to console........On Statistics Stream to console....On Warning Stream to console.......On Starting frame 0... Slave 1 at dhcp71.office.be.stone-it.com successfully started. Slave 2 at dhcp71.office.be.stone-it.com successfully started. Slave 3 at dhcp71.office.be.stone-it.com successfully started. Slave 4 at dhcp71.office.be.stone-it.com successfully started. Slave 5 at dhcp71.office.be.stone-it.com successfully started. Slave 6 at dhcp71.office.be.stone-it.com successfully started. Slave 7 at dhcp71.office.be.stone-it.com successfully started. Slave 8 at dhcp71.office.be.stone-it.com successfully started. Slave 9 at dhcp71.office.be.stone-it.com successfully started. Slave 10 at dhcp71.office.be.stone-it.com successfully started. Slave 11 at dhcp71.office.be.stone-it.com successfully started. Slave 12 at dhcp71.office.be.stone-it.com successfully started. Slave 13 at dhcp71.office.be.stone-it.com successfully started. Slave 14 at dhcp71.office.be.stone-it.com successfully started. Slave 15 at dhcp71.office.be.stone-it.com successfully started. 0:00:53 86.46 of blocks complete.Not using dhcp71.office.be.stone-it.com for reassignment (77%) 0:00:53 86.98 of blocks complete.Not using dhcp71.office.be.stone-it.com for reassignment (67%) Not using dhcp71.office.be.stone-it.com for reassignment (86%) Not using dhcp71.office.be.stone-it.com for reassignment (85%) 0:00:55 89.06 of blocks complete. 640 of 768 lines finished (in frame 0).Not using dhcp71.office.be.stone-it.com for reassignment (65%) 0:00:56 91.67 of blocks complete.Not using dhcp71.office.be.stone-it.com for reassignment (72%) 0:00:56 92.71 of blocks complete.Not using dhcp71.office.be.stone-it.com for reassignment (80%) 0:00:57 93.75 of blocks complete. Slave at dhcp71.office.be.stone-it.com has exited. 0:00:57 94.79 of blocks complete. Slave at dhcp71.office.be.stone-it.com has exited. Slave at dhcp71.office.be.stone-it.com has exited. 0:00:58 95.83 of blocks complete. Slave at dhcp71.office.be.stone-it.com has exited. 0:00:58 96.35 of blocks complete. 672 of 768 lines finished (in frame 0).Not using dhcp71.office.be.stone-it.com for reassignment (77%) Slave at dhcp71.office.be.stone-it.com has exited. 0:00:58 97.14 of blocks complete. 688 of 768 lines finished (in frame 0). Slave at dhcp71.office.be.stone-it.com has exited. 0:00:59 97.92 of blocks complete. Slave at dhcp71.office.be.stone-it.com has exited. 0:00:60 98.44 of blocks complete. 704 of 768 lines finished (in frame 0). Slave at dhcp71.office.be.stone-it.com has exited. 0:01:03 100.00 of blocks complete. 768 of 768 lines finished (in frame 0). Finishing frame 0...rtw. 768 Waiting for remaining slave stats. PVM Task Distribution Statistics: host name [ done ] [ late ] host name [ done ] [ late ] dhcp71.office.be.stone-it.com [ 5.21%] [ 0.00%]dhcp71.office.be.stone-it.com [ 7.81%] [ 0.07%] dhcp71.office.be.stone-it.com [ 8.85%] [ 1.17%]dhcp71.office.be.stone-it.com [ 4.69%] [ 0.00%] dhcp71.office.be.stone-it.com [ 8.85%] [ 0.98%]dhcp71.office.be.stone-it.com [ 4.17%] [ 0.00%] dhcp71.office.be.stone-it.com [ 5.21%] [ 0.00%]dhcp71.office.be.stone-it.com [ 8.33%] [ 0.52%] dhcp71.office.be.stone-it.com [ 5.21%] [ 0.00%]dhcp71.office.be.stone-it.com [ 5.73%] [ 0.72%] dhcp71.office.be.stone-it.com [ 7.29%] [ 2.73%]dhcp71.office.be.stone-it.com [ 4.17%] [ 0.00%] dhcp71.office.be.stone-it.com [ 5.21%] [ 0.00%]dhcp71.office.be.stone-it.com [ 6.77%] [ 0.13%] dhcp71.office.be.stone-it.com [ 4.69%] [ 0.00%]dhcp71.office.be.stone-it.com [ 7.81%] [ 0.00%] POV-Ray statistics for finished frames: skyvase.pov Statistics (Partial Image Rendered), Resolution 1024 x 768 ---------------------------------------------------------------------------- Pixels: 303104 Samples: 303104 Smpls/Pxl: 1.00 Rays: 1192710 Saved: 0 Max Level: 0/5 ---------------------------------------------------------------------------- Ray->Shape Intersection Tests Succeeded Percentage ---------------------------------------------------------------------------- Cone/Cylinder 1842227 900504 48.88 CSG Intersection 2742731 323346 11.79 CSG Union 1801008 521692 28.97 Plane 20223278 11233348 55.55 Quadric 1801008 1196533 66.44 Sphere 1801008 461786 25.64 Bounding Object 1842227 900504 48.88 ---------------------------------------------------------------------------- Calls to Noise: 1201944 Calls to DNoise: 2108954 ---------------------------------------------------------------------------- Shadow Ray Tests: 2856188 Succeeded: 85620 Reflected Rays: 889606 ---------------------------------------------------------------------------- Smallest Alloc: 9 bytes Largest: 20508 Peak memory used: 5643343 bytes ---------------------------------------------------------------------------- Time For Trace: 0 hours 1 minutes 7.0 seconds (67 seconds) Total Time: 0 hours 1 minutes 7.0 seconds (67 seconds) |
Как вы можете видеть, приложение было разбито на различные части и выполнялось раздельно, после этого openMosix выполнил работу по балансировке нагрузки по отношению к другим машинами.
У меня получились хорошие результаты при значении в два-три раза большим числа CPU, которые у меня были доступны.
Одним из наиболее часто используемых приложений в этой области является Blast. Для Blast есть патч, который заставляет его работать более гладко с openMosix, но это – не единственная альтернатива.
Прежде всего, у этого патча и у других версий Blast есть некоторые известные проблемы: Blast имеет иногда тенденцию к ошибке сегментации (segfault). Это в основном случается с преформатированными базами, которые вы скачиваете из Интернет. Если вы выполните formatdb на исходной базе, эти ошибки склонны исчезать.
Вслед за патчем Blast для openMosix многие люди применяют MPIBlast. Принимая во внимание факт, что openMosix имеет тенденцию ускорять MPI, добавление openMosix к этой конфигурации должно придать вашим деньгам больше силы, тем не менее, мы должны будем произвести некоторые дополнительные исследования, чтобы получить возможность подтвердить это.
Содержание
Содержание
- 18.1. Введение
На самом деле, пока не так много документации о ядре, но надеюсь, что ситуация улучшится со временем. Тем не менее, для начала, вот где располагаются исходники:
Код 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 генерируются во время компиляции.
Содержание
Руководство “шаг-за-шагом” от Mirko Caserta для менеджера релизов и для “сделай сам” авантюрного создателя пакетов .rpm.
-
Установите RedHat 8 на вашей машине. Эта платформа до настоящего времени используется для получения .rpm, и известно, что она выполняет эту работу хорошо.
-
Получите обновлённую копию модуля linux-openmosix из репозитория CVS openMosix, детали см. на http://sourceforge.net/cvs/?group_id=46729.
-
Получите архив .tar для исходников ядра Linux, которые мы собираемся пропатчить, и разместите его в /usr/src/redhat/SOURCES: предполагая, что мы говорим о ядре 2.4.20, получите linux-2.4.20.tar.bz2 с одного из многих зеркал http://www.kernel.org/ по всему миру.
-
Распакуйте архив .tar в /usr/src, то есть:
# cd /usr/src # tar vxjf redhat/SOURCES/linux-2.4.20.tar.bz2
-
Создайте символическую ссылку на директорию, куда вы вытянули из CVS модуль linux-openmosix, например:
# ln -s /home/mcaserta/src/linux-openmosix/linux-openmosix \ /usr/src/linux-openmosix
-
Скопируйте .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
-
Теперь настало время проверить номера версий, прежде чем мы сделаем патч-файл: удостоверьтесь, что первые строки файлов /usr/src/linux-openmosix/Makefile и /usr/src/redhat/SOURCES/openmosix-kernel.spec имеют правильные версию ядра и номер ревизии openMosix.
-
Хорошо, время сделать патч (предполагаю, что мы выпускаем патч для ядра 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
-
На данный момент ваша директория /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
-
Теперь вам всего лишь нужно 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
-
После того, как rpmbuild выполнит свою работу, вы должны будете получить следующие файлы в директории /usr/src/redhat:
двоичный пакет ядра для i386 UP машин двоичный пакет ядра для i686 UP машин двоичный пакет ядра для i686 SMP машин двоичный пакет ядра для athlon UP машин двоичный пакет ядра для athlon SMP машин исходный пакет ядра для любой x86 машины (в основном это необходимо, если вам нужны заголовочные файлы ядра openMosix) исходный пакет ядра патч-файл ядра, сжатый gzip -
Магическое заклинание для извлечения всех файлов из .srpm:
# rpm2cpio openmosix-kernel-....src.rpm | cpio -di
Отдельное спасибо Martin Huy за помощь, когда я пытался собрать все вещи воедино.
Я надеюсь, что вы найдёте этот документ полезным. По крайней мере, он полезен для меня, так как я имею тенденцию забывать вещи в течение нескольких минут после того, как я их закончил :)
Содержание
- B.1. IRC
- B.2. Для дальнейшего чтения
- B.3. Переводы
- B.2. Для дальнейшего чтения
-
- B.3.1. Китайский
- B.3.2. Инспанский
- B.3.1. Китайский
- B.4. Ссылки
- B.5. Почтовые списки рассылок
Некоторые энтузиасты openMosix проводят время online, помогая людям в IRC. Нас можно найти на irc://irc.freenode.net/#openMosix. Всего лишь присоединяйтесь к нам для обсуждения ваших проблем, идей и других вещей об openMosix.
Некоторые люди работали над частичным переводом этого HOWTO или обычной документации openMosix на свой язык.
Если вы работаете над переводом этого документа, дайте нам знать.
Ding Wei написал некоторые документы на Китайском, вы можете прочитать их тут: http://software.ccidnet.com/pub/disp/Article?columnID=732&articleID=25795&pageNO=1
Это локальная копия документов на Китайском в PDF.
Вместе с некоторыми коллегами Miquel Catalán Coïthas работает над переводом HOWTO на испанский: http://w3.akamc2.net/
-
User Mode openMosix, a virtual openMosix cluster running in User-mode
-
RxLinux, Web Interface for central configuration and management
-
Italian experiences with openMosix clusters Links to several papers presented at the conference. These papers cover many recurring questions seen on the openMosix mailing list:
-
Osservatorio Astronomico Cagliari (pdf)Securing an openMosix cluster in an untrusted networking environment.
-
D.T.I. dell'Università di Milano, Polo didattico e ricerca, Crema (pdf) Experiences with Java and C programs on openMosix.
-
Riello Group (pdf) Use of openMosix for parallel I/O balancing on storage (backup)
-
INFM & Dept. of Physics University of Napoli (pdf) Documents a number of small to large clusters and their uses.(Includes many references to software and projects.)
-
-
Use networked Linux systems to solve your computing challenges by Daniel Robbins
Невозможно перечислить здесь 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 и присланные советы.
автор перевода Елена Тяпкина [ 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
Версия 1.1, март 2000г.
Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA Каждый вправе копировать и распространять экземпляры настоящей Лицензии без внесения изменений в ее текст.
Цель настоящей Лицензии - сделать свободными справочник, руководство пользователя или иные документы в письменной форме, т.е. обеспечить каждому право свободно копировать и распространять как с изменениями, так и без изменений, за вознаграждение или бесплатно указанные документы. Настоящая Лицензия также позволяет авторам или издателям документа сохранить свою репутацию, не принимая на себя ответственность за изменения, сделанные третьими лицами.
Настоящая Лицензия относится к категории "copyleft" [1]. Это означает, что все произведения, производные от документа, должны быть свободными в соответствии с концепцией "copyleft". Настоящая Лицензия дополняет General Public License GNU, которая является лицензией "copyleft", разработанной для свободного программного обеспечения.
Настоящая Лицензия разработана для применения ее к документации на свободное программное обеспечение, поскольку свободное программное обеспечение должно сопровождаться свободной документацией. Пользователь должен обладать теми же правами в отношении руководства пользователя, какими он обладает в отношении свободного программного обеспечения. При этом действие настоящей Лицензии не распространяется только на руководство пользователя. Настоящая Лицензия может применяться к любому текстовому произведению независимо от его темы или от того, издано ли данное произведение в виде печатной книги или нет. Настоящую Лицензию рекомендуется применять для произведений справочного или обучающего характера.
Условия настоящей Лицензии применяются к любому руководству пользователя или иному произведению, которое в соответствии с уведомлением, помещенным правообладателем, может распространяться на условиях настоящей Лицензии. Далее под термином "Документ" понимается любое подобное руководство пользователя или произведение. Лицо, которому передаются права по настоящей Лицензии, в дальнейшем именуется "Лицензиат".
"Модифицированная версия Документа" - любое произведение, содержащее Документ или его часть, скопированные как с изменениями, так и без них и/или переведенные на другой язык.
"Второстепенный раздел" - имеющее название приложение или предисловие к Документу, в котором отражено исключительно отношение издателей или авторов Документа к его содержанию в целом, либо к вопросам, связанным с содержанием Документа. Второстепенный раздел не может включать в себя то, что относится непосредственно к содержанию Документа. (Например, если часть Документа является учебником по математике, во Второстепенном разделе не может содержаться что-либо имеющее отношение непосредственно к математике). Во Второстепенных разделах могут быть затронуты вопросы истории того, что составляет содержание или что связано с содержанием Документа, а также правовые, коммерческие, философские, этические или политические взгляды относительно содержания Документа.
"Неизменяемые разделы" - определенные Второстепенные разделы, названия которых перечислены как Неизменяемые разделы в уведомлении Документа, определяющем лицензионные условия.
"Текст, помещаемый на обложке" - определенные краткие строки текста, которые перечислены в уведомлении Документа, определяющем лицензионные условия, как текст, помещаемый на первой и последней страницах обложки.
"Прозрачный" экземпляр Документа - экземпляр Документа в машиночитаемой форме, представленный в формате с общедоступной спецификацией при условии, что документ может просматриваться и редактироваться непосредственно с помощью общедоступных текстовых редакторов или общедоступных программ для векторной или растровой графики (в случае, если в документе содержатся изображения векторной или растровой графики). Указанный формат должен обеспечить ввод текста Документа в программы форматирования текста или автоматический перевод Документа в различные форматы, подходящие для ввода текста Документа в программы форматирования текста. Экземпляр Документа, представленный в ином формате, разметка которого затрудняет или препятствует внесению в Документ последующих изменений пользователями, не является Прозрачным. Такой экземпляр документа называется "Непрозрачным".
Форматы, в которых может быть представлен Прозрачный экземпляр Документа, включают простой формат ASCII без разметки, формат ввода Texinfo, формат ввода LaTeX, SGML или XML с использованием общедоступного DTD, а также соответствующий стандартам простой формат HTML, предназначений для внесения модификаций человеком. "Непрозрачные" форматы включают в себя PostScript, PDF, форматы, которые можно прочитать и редактировать только с помощью текстовых редакторов, права на использование которых свободно не передаются, форматы SGML или XML, для которых DTD или инструменты для обработки не являются общедоступными, а также генерируемый машиной HTML, который вырабатывается некоторыми тесктовыми редакторами исключительно в целях вывода.
"Титульный лист" - для печатной книги собственно титульный лист, а также следующие за ним страницы, которые должны содержать сведения, помещаемые на титульном листе в соответствии с условиями настоящей Лицензии. Для произведений, формат которых не предполагает наличие титульного листа, под Титульным листом понимается текст, который помещен перед началом основного текста произведения, после его названия, напечатанного наиболее заметным шрифтом.
Лицензиат вправе воспроизводить и распространять экземпляры Документа на любом носителе за вознаграждение или безвозмездно при условии, что каждый экземпляр содержит текст настоящей Лицензии, знаки охраны авторских прав, а также уведомление, что экземпляр распространяется в соответствии с настоящей Лицензией, при этом Лицензиат не вправе предусматривать иные лицензионные условия дополнительно к тем, которые закреплены в настоящей Лицензии. Лицензиат не вправе использовать технические стредства для воспрепятствования или контроля за чтением или последующим изготовлением копий с экземпляров, распространяемых Лицензиатом. Лицензиат вправе получать вознаграждение за изготовление и распространение экземпляров Документа. При распространении большого количества экземпляров Документа Лицензиат обязан соблюдать условия пункта 3 настоящей Лицензии.
Лицензиат вправе сдавать экземпляры Документа в прокат на условиях, определенных в предыдущем абзаце, или осуществлять публичный показ экземпляров Документа.
Если Лицензиат издает печатные экземпляры Документа в количестве свыше 100, и в соответствии с уведомлением Документа, определяющем лицензионные условия, Документ должен содержать Текст, помещаемый на обложке, Лицензиат обязан издавать экземпляры Документа в обложке с напечатанными на ней ясно и разборчиво соответстветствующими Текстами, помещаемыми на обложке: Тексты, помещаемые на первой странице обложки - на первой странице, Тексты, помещаемые на последней странице - соответственно на последней. Также на первой и последней странице обложки экземпляра Документа должно быть ясно и разборчиво указано, что Лицензиат является издателем данных экземпляров. На первой странице обложки должно быть указано полное название Документа без пропусков и сокращений, все слова в названии должны быть набраны шрифтом одинакового размера. Лицензиат вправе поместить прочие сведения на обложке экземпляра. Если при издании экземпляров Документа изменяются только сведения, помещенные на обложке экземпляра, за исключением названия Документа, и при этом соблюдаются требования настоящего пункта, такие действия приравниваются к копированию без внесения изменений.
Если объем текста, который должен быть помещен на обложке экземпляра, не позволяет напечатать его разборчиво, Лицензиат обязан поместить разумную часть текста непосредственно на обложке, а остальной текст на страницах Документа, следующих сразу за обложкой.
Если Лицензиат издает или распространяет Непрозрачные экземпляры Документа в количестве свыше 100, Лицезиат обязан к каждому такому экземпляру приложить Прозрачный экземпляр этого Документа в машиночитаемой форме или указать на каждом Непрозрачном экземпляре Документа адрес в компьютерной сети общего пользования, где содержится Прозрачный экземпляр без каких-либо добавленных материалов, полный текст которого каждый пользователь компьютерной сети общего пользования вправе бесплатно, не называя своего имени и не регистрируясь, записать в память компьютера с использованием общедоступных сетевых протоколов. Во втором случае Лицензиат обязан предпринять разумные шаги с тем, чтобы доступ к Прозрачному экземпляру Документа по указанному адресу сохранялся по крайней мере в течение одного года после последнего распространения Непрозрачного экземпляра Документа данного тиража, независимо от того, было ли распространение осуществлено Лицензиатом непосредственно или через агентов или розничных продавцов.
Прежде чем начать распространение большого количества экземпляров Документа Лицензиату заблаговременно следует связаться с авторами Документа, чтобы они имели возможность предоставить Лицензиату обновленную версию Документа. Лицензиат не обязан выполнять данное условие.
Лицензиат вправе воспроизводить и распространять Модифицированные версии Документа в соответствии с условиями пунктов 2 и 3 настоящей Лицензии, при условии что Модифицированная версия Документа публикуется в соответствии с настоящей Лицензией. В частности, Лицензиат обязан передать каждому обладателю экземпляра Модифицированной версии Документа права на распространение и внесение изменений в данную Модифицированную версию Документа, аналогично правам на распространение и внесение изменений, которые передаются обладателю экземпляра Документа. При распространении Модифицированных версий Документа Лицензиат обязан:
Если в Модифицированную версию включены новые предисловия или приложения, которые могут быть определены как Второстепенные разделы и которые не содержат текст, скопированный из Документа, Лицензиат вправе по своему выбору определить все или некоторые из этих разделов как Неизменяемые. Для этого следует добавить их названия в список Неизменяемых разделов в уведомлении в Модифицированной версии, определяющем лицензионные условия. Названия данных разделов должны отличаться от названий всех остальных разделов.
Лицензиат вправе дополнить Модифицированную версию новым разделом "Одобрения" при условии, что в него включены исключительно одобрения Модифицированной версии Лицензиата третьими сторонами, например оценки экспертов или указания, что текст Модифицированной версии был одобрен организацией в качестве официального определения стандарта.
Лицензиат вправе дополнительно поместить на обложке Модифицированной версии Текст, помещаемый на обложке, не превышающий пяти слов для первой страницы обложке и 25 слов для последней страницы обложки. К Тексту, помещаемому на обложке, каждым лицом непосредственно или от имени этого лица на основании соглашения с ним может быть добавлено только по одной строке на первой и на последней страницах обложки. Если на обложке Документа Лицензиатом от своего имени или от имени лица, в интересах которого действует Лицензиат, уже был помещен Текст, помещаемый на обложке, Лицензиат не вправе добавить другой Текст. В этом случае Лицензиат вправе заменить старый текст на новый с разрешения предыдущего издателя, который включил старый текст в издание.
По настоящей Лицензии автор(ы) и издатель(и) Документа не передают право использовать их имена и/или наименования в целях рекламы или заявления или предположения, что любая из Модифицированных Версий получила их одобрение.
Лицензиат с соблюдением условий п.4 настоящей Лицензии вправе объединить Документ с другими документами, которые опубликованы на условиях настоящей Лицензии, при этом Лицензиат должен включить в произведение, возникшее в результате объединения, все Неизменяемые разделы из всех первоначальных документов без внесения в них изменений, а также указать их в качестве Неизменяемых разделов данного произведения в списке Неизменяемых разделов, который содержится в уведомлении, определяющем лицензионные условия для произведения.
Произведение, возникшее в результате объединения, должно содержать только один экземпляр настоящей Лицензии. Повторяющиеся в произведении одинаковые Неизменяемые разделы могут быть заменены единственной копией таких разделов. Если произведение содержит несколько Неизменяемых Разделов с одним и тем же названием, но с разным содержанием, Лицензиат обязан сделать название каждого такого раздела уникальным путем добавления после названия в скобках уникального номера данного раздела или имени первоначального автора или издателя данного раздела, если автор или издатель известны Лицензиату. Лицензиат обязан соответственно изменить названия Неизменяемых разделов в списке Неизменяемых разделов в уведомлении, определяющем лицензионные условия для произведения, возникшего в результате объединения.
В произведении, возникшем в результате объединения, Лицензиат обязан объединить все разделы "История" из различных первоначальных Документов в один общий раздел "История". Подобным образом Лицензиат обязан объединить все разделы с названием "Благодарности" и "Посвящения". Лицензиат обязан исключить из произведения все разделы под названием "Одобрения".
Лицензиат вправе издать сборник, состоящий из Документа и других документов, публикуемых в соответствии с условиями настоящей Лицензии. В этом случае Лицензиат вправе заменить все экземпляры настоящей Лицензии в документах одним экземпляром, включенным в сборник, при условии, что остальной текст каждого документа включен в сборник с соблюдением условий по осуществлению копирования без внесения изменений.
Лицензиат вправе выделить какой-либо документ из сборника и издать его отдельно в соответствии с настоящей Лицензией, при условии, что Лицензиатом в данный документ включен текст настоящей Лицензии и им соблюдены условия Лицензии по осуществлению копирования без внесения изменений в отношении данного документа.
Размещение Документа или произведений, производных от Документа, с другими самостоятельными документами или произведениями на одном устройстве для хранения информации или носителе не влечет за собой возникновения Модифицированной версии Документа, при условии, что Лицензиат не заявляет авторских прав на осуществленный им подбор или расположение документов при их размещении. Такое размещение называется "Подборкой", при этом условия настоящей Лицензии не применяются к самостоятельным произведениям, размещенным вышеуказанным способом вместе с Документом, при условии, что они не являются произведениями, производными от Документа.
Если условия пункта 3 настоящей Лицензии относительно Текста, помещаемого на обложке, могут быть применены к экземплярам Документа в Подборке, то в этом случае Текст с обложки Документа может быть помещен на обложке только собственно Документа внутри подборки при условии, что Документ занимает менее четвертой части объема всей Подборки. Если Документ занимает более четвертой части объема Подборки, в этом случае Текст с обложки Документа должен быть помещен на обложке всей Подборки.
Перевод является одним из способов модификации Документа, в силу чего Лицензиат вправе распространять экземпляры перевода Документа в соответствии с пунктом 4 настоящей Лицензии. Замена Неизменяемых разделов их переводами может быть осуществлена только с разрешения соответствующих правообладателей, однако Лицензиат вправе в дополнение к оригинальным версиям таких Неизменяемых разделов включить в текст экземпляра перевод всех или части таких Разделов. Лицензиат вправе включить в текст экземпляра перевод настоящей Лицензии при условии, что в него включен также и оригинальный текст настоящей Лицензии на английском языке. В случае разногласий в тольковании текста перевода и текста на английском языке предпочтение отдается тексту Лицензии на английском языке.
Лицензиат вправе воспроизводить, модифицировать, распространять или передавать права на использование Документа только на условиях настоящей Лицензии. Любое воспроизведение, модификация, распространение или передача прав на иных условиях являются недействительными и автоматически ведут к расторжению настоящей Лицензии и прекращению всех прав Лицензиата, предоставленных ему настоящей Лицензией. При этом права третьих лиц, которым Лицензиат в соответствии с настоящей Лицензией передал экземпляры Документа или права на него, сохраняются в силе при условии полного соблюдения ими настоящей Лицензии.
Free Software Foundation может публиковать новые исправленные версии GFDL. Такие версии могут быть дополнены различными нормами, регулирующими правоотношения, которые возникли после опубликования предыдущих версий, однако в них будут сохранены основные принципы, закрепленные в настоящей версии (смотри http://www/gnu.org/copyleft/).
Каждой версии присваивается свой собственный номер. Если указано, что Документ распространяется в соответствии с определенной версией, т.е. указан ее номер, или любой более поздней версией настоящей Лицензии, Лицензиат вправе присоединиться к любой из этих версий Лицензии, опубликованных Free Software Foundation (при условии, что ни одна из версий не является проектом Лицензии). Если Документ не содержит такого указания на номер версии Лицензии Лицензиат вправе присоединиться к любой из версий Лицензии, опубликованных когда-либо Free Software Foundation (при условии, что ни одна из версий не является Проектом Лицензии).
Чтобы применить условия настоящей Лицензии к созданному вами документу, вам следует включить в документ текст настоящей Лицензии, а также знак охраны авторского права и уведомление, определяющее лицензионные условия, сразу после титульного листа документа в соответствии с нижеприведенным образцом:
? имя (наименование) автора или иного правообладателя, год первого опубликования документа Каждый имеет право воспроизводить, распространять и/или вносить изменения в настоящий Документ в соответствии с условиями 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
Symbols
- (N)UMA, Модели
кластеров [(N)UMA, PVM/MPI]
- суперкомпьютер, Суперкомпьютеры против кластеров
B
C
D
- Debian, Требования
к программному обеспечению, Debian
и openMosixView, Процессы
не хотят мигрировать!
- DFSA, Direct File System Access (DFSA), oMFS, Конфигурация, Процессы не хотят мигрировать!, DFSA? MFS?, Введение
- DSM, Модели кластеров [(N)UMA, PVM/MPI], openMosix, Преимущества openMosix, Недостатки openMosix
- DFSA, Direct File System Access (DFSA), oMFS, Конфигурация, Процессы не хотят мигрировать!, DFSA? MFS?, Введение
G
I
- IRC, IRC
L
- Linux, Введение,
Отказ
от ответственности, Модели
кластеров [(N)UMA, PVM/MPI], Роль
openMosix, История
развития, Преимущества
openMosix, Требования
к программному обеспечению, Прежде
чем вы получите openMosix, Компиляция
ядра, openMosix
и Gentoo, Другие
дистрибутивы, Конфигурация,
Оптимизация
Mosix, Установка,
Советы
по компиляции, Java
и openMosix, Подробное
описание, Введение,
Как
сделать .rpm пакеты ядра openMosix?
- LTSP, Преимущества openMosix
M
- MFS, Direct
File System Access (DFSA), Преимущества
openMosix, Прежде
чем вы получите openMosix, oMFS,
Конфигурация,
Пользовательские
утилиты, Updatedb,
DFSA?
MFS?, Общее
описание
- Mosix, openMosix HOWTO, Введение, Отказ от ответственности, Обратная связь, История развития, openMosix, Direct File System Access (DFSA), RedHat и openMosix, DSH – распределённый шелл (Distributed SHell), Введение, Оптимизация Mosix, Я не вижу все свои узлы!
- MPI, Модели кластеров [(N)UMA, PVM/MPI], Blast
- Mosix, openMosix HOWTO, Введение, Отказ от ответственности, Обратная связь, История развития, openMosix, Direct File System Access (DFSA), RedHat и openMosix, DSH – распределённый шелл (Distributed SHell), Введение, Оптимизация Mosix, Я не вижу все свои узлы!
N
- NFS, Роль openMosix
O
- oMFS, Роль
openMosix, Файловая
система openMosix (oMFS), Преимущества
openMosix, oMFS,
Процессы
не хотят мигрировать!, Подробное
описание
- openMosixApplet, Преимущества openMosix, openMosixApplet
- openMosixView, Преимущества openMosix, Debian и openMosixView, Пользовательские утилиты, Введение, openMosixView по сравнению с Mosixview, Установка, Установка из .rpm-пакета, Установка из исходных текстов, Советы по компиляции, Основная программа, Управление удалёнными процессами, openMosixView FAQ, openMosixView + SSH, openMosixView, Список разработчиков
- openMosixWebView, Преимущества openMosix, openMosixWebView
- openMosixApplet, Преимущества openMosix, openMosixApplet
P
- Povray, Povray
- PVM, Модели кластеров [(N)UMA, PVM/MPI], Povray
R
- RedHat, Преимущества
openMosix, Требования
к программному обеспечению, RedHat
и openMosix, SuSE
и openMosix, Установка,
Процессы
не хотят мигрировать!, Установка
комплекта strestest, Povray,
Как
сделать .rpm пакеты ядра openMosix?
- RFC, openMosix и брандмауэры
- RSA, DSH – распределённый шелл (Distributed SHell), Подробное описание
- RFC, openMosix и брандмауэры