Кластер linux или windows
Для начала нужно разобраться что же такое кластер в общем случае. Как правило, кластер состоит из узлов (отдельных компьютеров) и объединяющей их сети. Для построения сети обычно используется технология Fast Ethernet (100Mbit/sec), но в простейшем случае (например, создание кластера в домашних условиях или в демонстративных целях) подойдет и один сегмент Ethernet на 10Mbit/sec.
Обычно кластеры используются научно-исследовательскими организациями для моделирования различного рода задач или проведения сложных расчетов. Цена суперкомпьютеров является недоступной для большинства организаций, поэтому появилась идея собрать свой ‘суперкомпьютер’ из ‘подручного материала’ — рабочих станций на базе процессоров Intel. Производительность процессоров производства Intel сейчас практически достигла уровня процессоров архитектуры RISC (процессоры Intel включая Pentium III используют архитектуру CISC, а P4 — VLIW).
Собираем свой кластер
Конфигурация узлов кластера зависит от задач, которые они будут выполнять. Если ваша цель — само создание кластера без решения каких-нибудь важных задач, подойдут и старенькие машины с 486-ым процессором (желательно DX2 или DX4). Для решения относительно важных задач подойдут компьютеры с процессорами Pentium II от 400Mhz или Pentium III (от 600Mhz).
Обратите внимание на объем оперативной памяти. В первом случае (486/демонстрация работы кластера) достаточным будет 16-32MB (желательно). Во втором — минимум 64Мб, рекомендуется 128Мб ОЗУ.
При использовании многопроцессорных машин объем ОЗУ желательно увеличить до уровня Nx64Mb, где N — это количество процессоров, то есть по 64Мб на каждый процессор. Обычно используются двухпроцессорные машины — в этом случае минимальный объем ОЗУ будет равен 128Мб, а рекомендуемый — 256Мб.
Один компьютер (узел) будет центральным. Желательно, чтобы он был более мощным, чем остальные узлы кластера. На нем нужно установить более мощный процессор, в два раза большим объем оперативной памяти, чем на остальных узлах (минимум 128Мб). Желательно на центральном компьютере использовать SCSI-диск, но подойдет и ATA133 / 7200 rpm. Лучше поставить быстрый SCSI, а на узлах вообще отказаться от жесткого диска — так будет дешевле. Все эти требования — желательные, но не обязательные.
Если вы откажетесь от использования жестких дисков на узлах кластера, операционная система будет загружаться по сети, но об этом мы поговорим немного позже. В этом случае вы получите лишь выигрыш во времени: операционную систему и программное обеспечение нужно будет настраивать только один раз.
Вполне возможен отказ и от видеоплат при сборке узлов кластера (на центральном узле видеоплата все-таки будет нужна).
Теперь поговорим о сети. Как я уже писал, желательно использовать Fast Ethernet . Если количество узлов довольно велико (от 20), для уменьшения коллизий необходимо разбить на отдельные сегменты или использовать для их соединения коммутатор (swith), а не повторитель (hub).
В некоторых случаях имеет смысл разбить сеть на сегменты даже при небольшом числе узлов (от 8), например, если вы используете Ethernet (10Mbit/sec).
При использовании Ethernet отказываться от жестких дисков не рекомендуется : кластер будет работать ужасно медленно, будет возникать огромное число коллизий.
Одним из самых эффективных решений для связи узлов кластера является использование 1.28GBit-ных коммутаторов Myrinet. Также можно использовать технологию Gigabit Ethernet.
Программное обеспечение
В качестве операционных систем можно использовать:
- Linux
- FreeBSD
- Windows NT
Предпочтительнее использовать любую Unix-систему, так как именно эти операционные системы наиболее эффективнее используют сетевые ресурсы. Оптимальным решением является операционная система Linux — она бесплатна и довольно проста в настройке.
Можно использовать любую Linux-систему с версией ядра 2.2.* и выше. Я бы порекомендовал использовать шестую версию Linux RedHat, так как она нетребовательна к системным ресурсам (минимальная конфигурация — 486 33Mhz/8MB RAM/120MB HDD) и в состав дистрибутива входит относительно новое программное обеспечение по сравнению с версией 5.2, которую также можно использовать для построения кластера. Версия ядра, используемая этим дистрибутивом (RH 6), 2.2.5-15.
После установки и настройки (настройки сети) операционной системы нужно установить специальные компиляторы . Дело в том, что бесплатно распространяемые компиляторы gcc/g77/egcs не обеспечивают необходимого уровня оптимизации программ для процессоров Intel (PII, PIII). Рекомендуется использовать коммерческие компиляторы, например, входящие в проект PGI Workstation.
При использовании Windows NT как операционной системы кластера можно также выбрать компилятор компании Intel, оптимизированный для платформы Intel.
В первом и во втором случае доступны тестовые версии компиляторов. Shareware-версию пакета PGI вы можете скачать на сайте PGI Group. А тестовую (14 дней) версию компилятора Intel можно скачать на сайте Intel.
После установки компиляторов нужно установить среду распределения задач. В этой статье я опишу работу со средой PVM, хотя доступны и другие средства MPI, Condor.
MPI CHameleon представляет собой реализацию промышленного стандарта MPI 1.1. MPI CHameleon позволяет программам выполнятся внутри локальной системы или на сетевом кластере с использованием TCP-соединений.
Среда Condor обеспечивает равномерную нагрузку на кластер путем миграции процессов между несколькими машинами.
Я выбрал более простой вариант — PVM (Parallel Virtual Machine). PVM обеспечивает условия для выполнения одной (или нескольких — в большинстве случаем) задач на нескольких машинах. Другими словами PVM просто распределяет процессы на узлах кластера также как планировщик заданий операционной системы распределяет процессорное время для выполнения нескольких задач.
PVM может работать на следующих архитектурах:
Это далеко не все архитектуры, которые поддерживает PVM. Список всех доступных архитектур вы найдете в документации pvm. Интересующие нас (точнее, доступные нам) архитектуры выделены жирным шрифтом.
Работа с ‘параллельной машиной’ довольно проста. Нужно установить ее на всех машинах кластера. Мой ‘кластер’ состоял из двух машин класса Pentium (100 и 150Mhz) с объемом ОЗУ по 32Мб и одной (центральной) Celeron 433 (128Mb). От сетевой загрузки я отказался из-за использование 10Mbit-го Ethernet’a. К тому же на всех узлах уже были установлены жесткие диски. На центральном была установлена ОС Linux Mandrake 7, а на вспомогательных машинах Linux RedHat 6.0 Hedwig. Я не устанавливал каких-нибудь коммерческих комплиляторов, а использовал те, которые входят в состав дистрибутива.
Кстати, PVM может работать и на платформе Windows 9x, но вот этого не рекомендую делать. Ради интереса я установил PVM для Windows 98. Скорость работы даже тестовых приложений (не говоря уже о реальных расчетах) была значительно ниже. То, что кластер работает медленнее было видно даже ‘невооруженным глазом’. Скорее всего, это объясняется неэффективной работой Windows с сетью. К тому же, довольно часто весь кластер ‘зависал’ даже при выполнении тестовых задач, которые входят в состав пакета PVM.
Использование PVM
PVM компилируется с помощью привычной тройки команды:
configure; make; make install
Перед запуском make установите переменную окружения PVM_ROOT. В этой переменной окружения нужно указать каталог, в котором находятся каталоги PVM (например, $HOME/pvm, если вы распаковали архив в свой домашний каталог). Еще одной важной переменной окружения является PVM_ARCH. В ней содержится название архитектуры операционной системы. Данная переменная должна устанавливаться автоматически, но если этого не произошло (как в моем случае), нужно установить архитектуру самостоятельно. При использовании Linux эта переменная должна содержать значение LINUX.
Как я уже писал, нужно установить PVM на всех узлах кластера. Вся параллельная машина состоит из демона pvmd и консоли pvm. Назначение опций запуска демона можно узнать, выполнив команду man pvmd. На центральной машине нужно запустить демон pvmd и выполнить команду:
pvm
Этим мы запустим консоль, с помощью которой мы будем управлять всем кластером.
После запуска консоли вы должны увидеть приглашение, которое свидетельствует о том, что кластер готов к работе:
pvm >
Введите команду conf для печати конфигурации кластера. Вы должны увидеть примерно это:
Листинг 1.
Из листинга 1 видно, что сейчас наш кластер состоит из одной машины — центрального узла, который работает под управлением Linux. Теперь самое время добавить в наш кластер еще два узла. Добавление узлов осуществляется с помощью команды:
add hostname
После успешного добавления узла в кластер он должен быть отображен в списке узлов кластера. Теперь уже можно запускать программы, которые поддерживают PVM. Примеры таких программ вы можете найти в каталоге $PVM_ROOT/bin/$PVM_ARCH/.В нашем случае это будет каталог /root/pvm/bin/LINUX (я установил pvm в каталог /root). Для начала запустим самую простую программу — hello. Прежде чем запустить ее, нужно сделать несколько замечаний:
- Вы не можете запускать процессы прямо из консоли pvm. Консоль служит лишь для управления кластером.
- Запуск задачи осуществляется обычным способом — из консоли операционной системы. Но ‘распараллеливаться’ будут лишь те процессы, которые поддерживают pvm. С помощью команды spawn также можно породить задачу (см. ниже)
При запуске hello вы должны увидеть сообщение
hello, world from hostname ,
где hostname — это узел кластера. Другими словами все узлы кластера должны поприветствовать вас.
Более интересной является программа gexample. После запуска нужно ввести два аргумента: n и число процессоров. Не вдаваясь в математические подробности, она рассчитывает сумму от 1 до n и факториал числа n. Второй аргумент определяет количество процессоров, которые будут задействованы в вычислении. В нашем случае второй аргумент равен трем. Просмотреть список всех задач можно с помощью команды ps -a. Эту команду нужно вводить в консоли pvm, а не в консоли операционной системы! Породить задачу можно также с помощью команды spawn, которая подробно рассмотрена ниже. Назначение всех команд консоли pvm представлено в таблице 1.
Таблица 1.
| Команда | Описание |
| add hostname | Добавляет узел в кластер |
| alias | Определяет псевдоним для команды |
| conf | Выводит текущую конфигурацию кластера |
| delete hostname | Удаляет узел из кластера |
| halt | Останавливает кластер (точнее завершает процесс pvmd — узлы при этом не выключаются, а продолжают работать) |
| help [command] | Выводит список всех команд или краткую справку по указанной команде |
| id | Выводит идентификатор процесса pvm (консоли) |
| jobs | Выводит список выполняемых задач |
| kill TID (task id) | ‘Убивает’ задачу |
| mstat host, tid | Показывает состояние узлов |
| ps -a | Выводит список всех задач параллельной машины |
| pstat task-tid | Показывает состояние задачи |
| quit | Выход из консоли pvm |
| reset | Сброс — завершаются все задачи |
| setenv | Отображает или устанавливает переменные окружения |
| sig signum task | Посылает сигнал задаче |
| spawn [opt] a.out | Порождает задачу. Об этой команде мы поговорим подробнее после этой таблицы. |
| trace | Устанавливает/отображает маску трассировки событий. Более подробное объяснение вы найдете в документации. |
| unalias | Удаляет ранее созданный псевдоним команды |
| version | Отображает версию библиотеки libpvm |
В таблице 1 я описал не все команды консоли pvm, обо всех остальных мы можете прочитать, введя команду man pvm.
Теперь рассмотрим некоторые команды подробнее. Начнем с самой простой — alias. С ее помощью можно определить псевдонимы для часто используемых команд, например
alias ? help
Теперь вместо команды help вы можете просто вводить ?
Команда id выводит идентификатор консоли pvm:
Команда mstat отображает состояние узла, например:
Подобно привычной нам команде ps, команда консоли pvm ps -a также используется для отображения всех выполняемых параллельной машиной задач:
Команда pstat выводит состояние задачи:
Вот теперь мы подошли к одной из самых интересных команд — spawn. Данная команда порождает задачу. С ее помощью можно указать некоторые параметры задачи, например, узел, на котором она должна выполняться.
spawn [opt] a.out
a.out — любой исполнимый бинарный файл — программа, которая даже не поддерживает библиотеку libpvm. Для таких программ также можно указать, на какой машине она будет выполняться. В среде Windows параметр a.out — это exe или com — файл.
Можно указать такие параметры команды spawn:
Таблица 2.
| Параметр | Описание |
| -(count) | Число задач. По умолчанию — 1. |
| -(host) | Определяет узел, на котором будет выполняться задача |
| -(ARCH) | Задает архитектуру узлов, на которых будет выполняться задача. |
| -? | Включает отладку (debugging) |
| -> | Перенаправляет стандартный вывод задачи на консоль |
| ->file (*) | Перенаправляет стандартный вывод задачи в файл |
| ->>file (*) | Дописывает стандартный вывод задачи в файл |
На этом я завершаю эту небольшую статью о Linux-кластерах. В следующих статьях мы поговорим о других кластерных проектах, в которых используется операционная система Linux. Список дополнительной литературы вы найдете ниже. Если что-нибудь непонятно, пишите — с удовольствием выслушаю ваши вопросы и комментарии, да и команду man тоже никто не отменял.
Источник
Сравнение операционных систем семейства Linux/UNIX и Windows
Введение
В последнее время наблюдается большой приток пользователей Linux. Как правило это люди уже имеющие вполне приличный опыт в общении с компьютером, но этот опыт в большинстве случаев ограничен одной системой. Естественно, что этой системой является самая распространенная на сегодня на дескотопах операционная система компании Microsoft MS Windows. Большое число пользователей Windows также ставят Linux, или запускают его с «Live CD» «на посмотреть».
И тут возникает сразу несколько проблем, связанных с тем, что новые пользователи Linux ожидают увидеть перед собой «еще один Windows». А Linux — это совсем не клон Windows, это совсем другая система, с другой основой, другими традициями, другими возможностями и другими требованиями к пользователю.
По моему убеждению именно это непонимание и является одним из источником такого количества так называемых «священных войн». Возможно данная статья позволит если не уменьшить количество таких войн, то хотя бы даст большее понимание позиций противников и снизит накал в войнах.
Очень глубоко лезть в устройство этих двух операционных систем нам, я думаю, ни к чему, будем рассматривать их в основном с точки зрения пользователя.
Экскурс в историю (очень краткий)
Для сравнения, думаю невредно освежить в памяти краткую историю сравниваемых операционных систем.
История Unix
Операционная система UNIX была создана еще до эры коммерческого софта. Она писалась инженерами, как система «для себя». Поэтому в нее были заложены передовые на то время концепции. В дальнейшем своем развитии при добавлении новых черт, обычно считалось, что делать нужно «правильно». Т.е. например если нужно было выбирать из двух решений, одно из которых было с инженерной точки зрения «неправильным», например повышало производительность сегодня, но могло принести затруднения в дальнейшем, как правило, такое решение отвергалось и выбиралось «правильное» решение, пусть и с определенной потерей производительности.
Первые версии UNIX были написаны на Ассеблере, затем система была переписана на СИ. Это дало системе уникальную переносимость. На PC UNIX был портирован, а точнее заново написан (Linux) сразу, как только развитие PC, а точнее выпуск PC на процессоре i386, позволило это сделать.
В 1985 году стартовал проект POSIX. Это стандарт на интерфейсы UNIX-подобных ОС. Во многом благодаря наличию такого стандарта, так быстро смог появится на свет и достигнуть зрелости Linux — свободная воплощение UNIX.
Развитие интернета с самого начала и до нашего времени неразрывно связано с серверами под управлением ОС UNIX. Сначала с коммерческими, а теперь все больше и больше со свободными.
С точки зрения коммерциализации развитие UNIX можно разделить на три этапа.
- Некоммерческое распространение в университетах.
- Распространение коммерческих UNIX систем.
- Появление свободных реализаций (Linux, FreeBSD) и вытеснение коммерческих систем (настоящий момент).
До появления системы X Window System UNIX была системой с текстовым интерфейсом, затем добавился графический, но традиционно текстовый интерфейс сохраняет важное значение.
Очень важно то, что UNIX с самого начала был многозадачной и многопользовательской системой. Т.е. на одной машине могут работать сразу несколько пользователей, и выполняться несколько программ одновременно.
Фирменной чертой всех UNIX-подобных ОС была и остается надежность.
| Год | Событие | Комментарий | Разр | Многопольз. | Многозадачн. |
| 1971 | Первая версия UNIX | На ассемблере | 32 | Есть | Есть |
| 1973 | Третья версия UNIX | На Си | 32 | Есть | Есть |
| 1983 | TCP/IP | — | 32 | Есть | Есть |
| 1983 | Проект GNU стартовал | Подготовил свободную обвязку для UNIX- подобных ОС | 32 | Есть | Есть |
| 1984 | X Window System | Оконная система | 32 | Есть | Есть |
| 1985 | Стартовал проект POSIX | Стандарты интерфейсов UNIX-подобных систем | 32 | Есть | Есть |
| 1991 | Появление Linux | Первая свободная реализация ядра UNIX для PC, 32 разрядная, сеть | 32 | Есть | Есть |
| 1993 | Появление FreeBSD | Еще одна свободная реализация ядра UNIX для PC, 32 разрядная, сеть | 32 | Есть | Есть |
История Windows
Истоки зарождения операционной системы Windows следует искать в предшествующей ей операционной системе той же самой фирмы — DOS. Все операционные системы компании Microsoft, это прежде всего коммерческие проекты. Об этом нужно помнить всегда, особенно, когда стараешься понять истоки тех или других решений, как коммерческого плана, так и технического.
Первой ОС из этого семейства была DOS. Может показаться, что DOS собственно имеет косвенное отношение к обсуждаемому предмету. Но, многие традиции, база пользователей и разработчиков, их привычки, идут именно оттуда.
DOS была однозадачной однопользовательской операционной системой с текстовым интерфейсом. Первая версия Windows представляла собой нечто, негодное для работы и распространения не получила. Работать стало в Windows стало возможно, начиная с версии 3. В версии Windows For Workgroups 3.1 появилась возможность работы с сетью. Winodws серии 3 представляли собой запускаемую поверх DOS систему. Отличались невысокой надежностью.
В 1995 годы вышла новая версия — Windows 95. Код частично был 32 разрядным, частично 16 разрядным, встроенная сеть. По сравнению с Windows серии 3 это был серьезный шаг вперед. Повысилась надежность, но до надежности UNIX-подобных ОС было еще далеко. В качестве рабочей станции с натяжкой конечно, надежности хватало, в качестве сервера, нет. Позже были выпущены еще две ОС этой линии, Windows 98 и Windows Me. После этого линия была закрыта.
В 1993 году вышла новая версия — Windows NT 3.1. Это уже была полностью 32 разрядная система. Разработана она была с нуля, для ее разработки были наняты известные специалисты. Были внедрены новые концепции. Это подняло надежность почти до уровня надежности UNIX-подобных систем. Эта ОС уже могла работать в качестве сервера. Продолжение этой линии, операционные системы Windows 2000, Windows XP и Windows Vista.
ОС линии NT были многозадачными, начиная с Windows XP появилась и возможность работать нескольким пользователям, хотя и более ограниченная и гораздо менее удобная, чем у UNIX-подобных ОС.
| Год | Событие | Комментарий | Разр | Многопольз. | Многозадачн. |
| 1981 | DOS | — | 16 | Нет | Нет |
| 1985 | Windows 1.0 | Надстройка над DOS | 16 | Нет | Нет |
| 1990 | Windows 3.0 | Надстройка над DOS | 16 | Нет | Есть |
| 1992 | Windows For Workgroups 3.1 | Надстройка над DOS, сеть | 16 | Нет | Есть |
| 1995 | Windows 95 | сеть | 16/32 | Нет | Есть |
| 1993 | Windows NT | сеть | 32 | с 1998 | Есть |
| 2000 | Windows 2000 | сеть | 32 | Есть | Есть |
| 2005 | Windows XP | сеть | 32 | Есть | Есть |
| 2007 | Windows Vista | сеть | 32 | Есть | Есть |
Техническое устройство с точки зрения пользователя
С точки зрения пользователя UNIX устроен примерно так:
- Ядро. Работает с устройствами, управляет памятью и процессами.
- Текстовая подсистема, работа с системой через терминал. Причем для управления всеми возможностями ОС достаточно только текстовой подсистемы. Возможно вход через эту подсистему многих пользователей. Богатый набор как встроенных утилит, так и приложений, работающих в текстовом режиме.
- Графическая подсистема Xwindow. Запускается как процесс в системе.
- Система удаленного доступа в текстовом режиме. Позволяет полноценную работу с ОС в текстовом режиме. Потребляет мало ресурсов. Позволяет работать на сравнительно слабых компьютерах одновременно десяткам и сотням пользователей. Количество сессий ограничено ресурсами компьютеров.
- Система удаленного доступа в графическом режиме. Позволяет одновременно работать нескольким пользователям в графическом режиме. Количество сессий ограничено ресурсами компьютеров.
- Система передачи графического окна приложения на другой компьютер. Позволяет запустив приложение на одном компьютере, управлять им с другого компьютера, через окно приложения, передаваемое на этот другой компьютер. Количество сессий ограничено ресурсами компьютеров.
Windows
- Ядро. Работает с устройствами, управляет памятью и процессами, управляет графической подсистемой.
- Графическая подсистема. Обеспечивает интерфейс с пользователем. Приоритетная система для пользовательского интерфейса.
- Текстовая подсистема. Обеспечивает текстовый интерфейс с пользователем. Текстовый интерфейс весьма урезанный. Набор утилит текстового режима как встроенных, так и других производителей весьма куцый. Синтаксис и состав команд текстового режима меняется от версии к версии. Запускается только поверх графического режима.
- Система удаленного доступа. Появилась впервые, как встроенная в систему, в Windows NT Server 4.0. До этого были только продукты других фирм. В связи с тем, что запускается полноценная графическая сессия, кушает очень много ресурсов. Наличие системы удаленного доступа и количество одновременных сессий может вообще отсутствовать или быть ограничено в разных версиях из коммерческих соображений.
Сравнение концепций
Давайте теперь рассмотрим, чем отличается подход к работе в этих двух системах.
UNIX: Концепция «Toolbox»
Поскольку UNIX разрабатывалась инженерами и для инженеров, в ее основу была положена концепция toolbox (ящик с инструментами). Что это значит? Это значит, что при создании софта и встроенных утилит для UNIX не делали универсальные программы, каждая из которых выполняла бы внутри себя все, необходимые пользователю действия, а для каждой небольшой задачи создавалась своя утилита, которая выполняла свою задачу, только одну, но делала это хорошо. Дело пользователя было при помощи набора этих утилит выполнить операции, которые ему нужно сделать.
При этом из этого набора утилит можно составлять цепочки и последовательности действий, что позволяет легко автоматизировать рутинные, часто повторяющиеся операции.
Для того, чтобы утилиты могли обмениваться между собой результатами своей работы, в качестве носителя информации был выбран текстовый файл. Для обмена информацией между утилитами были изобретены «pipes» (трубы). При помощи «труб» информация с выхода одной команды может быть передана на вход второй, та ее обрабатывает, выдает свою информацию на выход, которая может быть передана на вход третьей и так далее.
В общем, в результате UNIX позволяет пользователю легко создавать простые программные комплексы, выполняющие повторяющиеся действия как по команде пользователя, так и в автономном режиме.
Такой подход имеет как плюсы, так и недостатки. С одной стороны он дает больший контроль над системой, гибкость в настройке, но при этом повышается порог вхождения в систему, или говоря простыми словами, прежде, чем что нибудь сделать, как правило, нужно изучить основы.
Windows: Концепция «Тостер»
В Windows доминирует другая концепция. Эта концепция — максимально облегчить вхождение пользователя в задачу. Программы в Windows как правило большие, на каждое действие есть пункт в меню или иконка. В системы программы связываются как правило с большим трудом.
Ухудшает ситуацию о построением комплексов на базе Windows то, что большинство программ — коммерческие и используют свои, бинарные и как правило закрытые форматы данных и файлов. Такой подход превращает компьютер в устройство, которое может выполнять ограниченный изготовителем ПО набор функций, в пределе в этакий своеобразный «тостер», который выполняет только то, что задумал его изготовитель.
Плюс такого подхода — легкость вхождения неподготовленного пользователя. Минус — то, что обманутый кажущейся легкостью пользователь вообще не хочет ничему учиться и не выполнять необходимых действий. На поводу идут и производители софта. Это одна из причин такого обилия документов отформатированных пробелами, пренебрежения безопасностью и как следствие вирусных эпидемий.
Заключение
Конечно, в обоих системах не доминирует свой подход на 100 процентов. Как в Windows есть возможность пользоваться текстовой консолью и создавать .bat файлы, так и в UNIX есть большой набор программ, со свойствами присущими скорее «тостерному» подходу. И все таки описанная разница в подходах есть и она достаточно ярко выражена.
Источник
