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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


реферат Кластерные системы на основе ОС Linux. Построение учебного кластера

Информация:

Тип работы: реферат. Добавлен: 03.11.2012. Сдан: 2012. Страниц: 13. Уникальность по antiplagiat.ru: < 30%

Описание (план):


?

МИНИСТЕРСТВО НАУКИ И ОБРАЗОВАНИЯ УКРАИНЫ

Одесский национальный политехнический университет

"Кафедра интеллектуальных компьютерных систем и сетей"

 

 

 

 

 

 

Методические указания по теме:

«Кластерные системы на основе ОС Linux. Построение учебного кластера.»

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Выполнили:
студенты группы АМ-055
Василиади Николай
Стеля Андрей
 
 
 
 
Одесса 2010
СОДЕРЖАНИЕ:
 
1 КЛАСТЕРЫ. ОБЩИЕ ПОНЯТИЯ.
 1.1 ВИДЫ КЛАСТЕРОВ.
 1.2 МОДЕЛИ КЛАСТЕРОВ.
2 ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВЫЧИСЛИТЕЛЬНЫХ КЛАСТЕРОВ.
2.1 ОСОБЕННОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.
2.2 МЕХАНИЗМЫ ПОСТРОЕНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.
2.2.1 ИНТЕРФЕЙС MPI.
2.2.2 РЕАЛИЗАЦИИ MPI.
2.2.3 СРЕДСТВА ПРОГРАММИРОВАНИЯ ВЫСОКОГО УРОВНЯ.
3 СОВРЕМЕННЫЕ ВАРИАНТЫ LINUX - КЛАСТЕРОВ.
3.1 BEOWULF.
3.2 MOSIX.
4 РАЗВОРАЧИВАНИЕ LINUX КЛАСТЕРА НА БАЗЕ OPENMOSIX.
4.1 КОМПИЛЯЦИЯ ЯДРА.
4.2 КОНФИГУРАЦИИ КЛАСТЕРА.
4.3 НАСТРОЙКА ФАЙЛОВОЙ СИСТЕМЫ OMFS.
4.4 НАСТРОЙКА DSH (DISTRIBUTED SHELL).
4.5 ТЕСТ ПРОИЗВОДИТЕЛЬНОСТИ КЛАСТЕРА.
5 ИТОГИ.
6 СИПИСОК ИСТОЧНИКОВ ИНФОРМАЦИИ

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1. КЛАСТЕРЫ. ОБЩИЕ ПОНЯТИЯ.
 
Кластер — это модульная многопроцессорная система, созданная на базе стандартных вычислительных узлов, соединенных высокоскоростной коммуникационной средой.
Каждый узел работает под управлением своей копии стандартной операционной системы. Состав и мощность узлов могут быть разными в рамках одного кластера, однако чаще строятся однородные кластеры. Выбор конкретной коммуникационной среды определяется многими факторами: особенностями решаемых задач, доступным финансированием, требованиями к масштабируемости и т. п.

 
1.1. ВИДЫ КЛАСТЕРОВ.
 
Существуют три основных вида кластеров: Fail-over (отказоустойчивые), Load-balancing (балансировочные, распределяющие нагрузку) и High Performance Computing (высокопроизводительные вычислительные).
Отказоустойчивые кластеры представляют собой два или более связанных по сети компьютера с дополнительным выделенным контрольным (heartbeat) соединением между ними. Это выделенное соединение между машинами используется для мониторинга состояния сервисов: как только заданный сервис на одной машине выходит из строя, то другая начинает выполнять её функции.
Концепция балансировочных кластеров заключается в том, что если, допустим, приходит запрос к веб-серверу, то кластер сначала определяет наименее загруженную машину, а затем направляет к ней запрос. Довольно часто балансировочный кластер выполняет и функции отказоустойчивого кластера, хотя для этого и требуется большее количество узлов.
Последний вид - вычислительный кластер, используется специально для центров обработки информации, которым необходима максимально возможная производительность. К подобным системам относится система Beowulf, разработанная именно для исследовательских центров, нуждающихся в большой скорости вычислений. В таких системах также присутствует некоторая функция балансировочных кластеров: для повышения производительности они стараются распределить процессы на большее количество машин. Только в данном случае процесс распараллеливается на части, которые выполняются на многих машинах одновременно, вместо того чтобы выполняться друг за другом по очереди.
 
 
1.2. МОДЕЛИ КЛАСТЕРОВ.
 
Существует несколько технологий реализации параллельных вычислений: (N)UMA, DSM, PVM и MPI – всё это различные схемы параллельных вычислений. Некоторые из них уже реализованы аппаратно, другие только в программном, а некоторые – и в том, и в другом виде.
(N)UMA: здесь машины пользуются разделяемым доступом к памяти, в которой они могут выполнять свои программы. В ядре Linux реализована поддержка NUMA, позволяющая получать доступ к разным областям памяти. При этом задача ядра использовать ту память, которая находится ближе к процессору, работающему с ней.
DSM уже реализована не только в программном виде, но и в аппаратном. Основная концепция DSM в организации абстрактного слоя для физически распределённой памяти.
Технологии PVM и MPI наиболее часто упоминаются, когда речь заходит о GNU/Linux Beowulf кластерах.
MPI – это открытая спецификация библиотеки передачи сообщений. Самой популярной реализацией MPI является MPICH. Второй по популярности после MPICH можно назвать LAM, также являющейся свободной реализацией MPI.
PVM – ещё один родственник MPI, широко используемый при создании Beowulf. PVM работает как пользовательская программа, поэтому никаких изменений в ядро системы вносить не нужно – выходит, что любой пользователь с минимальными правами может запустить PVM.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
2. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВЫЧИСЛИТЕЛЬНЫХ КЛАСТЕРОВ.
 
2.1 ОСОБЕННОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.
 
Главным препятствием к внедрению практически всех параллельных архитектур является отсутствие параллельных программ. У унаследованных от последовательного мира программ имеется недостаток - большой объем кода, принципиально не допускающий параллельного исполнения. Его нельзя преодолеть за счет усовершенствования техники компиляции. Так, если программа половину времени занимается действиями, которые требуется совершать строго последовательно, то параллельное выполнение оставшейся половины в предельном случае даст лишь двукратное ускорение. В результате, хотим мы этого или нет, последовательные вычислительные алгоритмы придется заменять параллельными.
Необходимость переработки существующих алгоритмов при переносе их на параллельные системы - момент принципиальный. Специалисты по численным методам наработали большой багаж программ на Fortran и не хотели бы переходить на другие языки (скажем, Cи или C++), чтобы не переписывать свои программы заново. Увы, при переходе на параллельные компьютеры или сети переделывать их придется, и процесс этот во много раз сложнее, чем переписывание программы с одного последовательного языка на другой.

 
2.2 МЕХАНИЗМЫ ПОСТРОЕНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.
 
Практически на всех параллельных системах имелись свои собственные библиотеки передачи сообщений. В простейшем случае они предусматривали передачу и прием отдельных пакетов между соседними процессорами. Более сложные поддерживали передачу сообщений произвольной длины, маршрутизацию сообщений и аппарат тегов, который позволяет принимающей стороне самой решать, в какой последовательности обрабатывать поступающие сообщения. Некоторые библиотеки допускали динамическое порождение и уничтожение процессов.

 
2.2.1 ИНТЕРФЕЙС MPI.
 
За последние годы в деле создания ПО для систем с распределенной памятью наметился серьезный прогресс. Самым крупным достижением была стандартизация интерфейса передачи сообщений MPI (message passing interface). Набор функций этого интерфейса вобрал в себя лучшие черты своих предшественников p4 и PVM. Во-первых, MPI поддерживает несколько режимов передачи данных, важнейшие из которых: синхронная передача, не требующая выделения промежуточных буферов для данных и обеспечивающая надежную передачу данных сколь угодно большого размера, и асинхронная передача, при которой посылающий сообщение процесс не ждет начала приема, что позволяет эффективно передавать короткие сообщения. Во-вторых, MPI позволяет передавать данные не только от одного процесса к другому, но и поддерживает коллективные операции: широковещательную передачу (broadcasting), разборку-сборку (scatter и gather), операции редукции. В-третьих, MPI предусматривает гетерогенные вычисления. Вычислительная система может включать разные процессоры, в том числе имеющие различные наборы команд и разное представление данных. Если у вас имеется суперкомпьютер, то это кажется излишним, но для организаций, эксплуатирующих сети рабочих станций с различными процессорами и версиями Unix, - это находка.
Синтаксис MPI облегчает создание приложений в модели SPMD (single program multiple data) - одна программа работает в разных процессах со своими данными. Одна и та же функция вызывается на узле-источнике и узлах-приемниках, а тип выполняемой операции (передача или прием) определяется с помощью параметра. Такой синтаксис вызовов делает SPMD-программы существенно компактнее, хотя и труднее для понимания.
Основное отличие стандарта MPI от его предшественников - понятие коммуникатора. Все операции синхронизации и передачи сообщений локализуются внутри коммуникатора. С коммуникатором связывается группа процессов. В частности, все коллективные операции вызываются одновременно на всех процессах, входящих в эту группу. Поскольку взаимодействие между процессами инкапсулируется внутри коммуникатора, на базе MPI можно создавать библиотеки параллельных программ.
Поддержка модульного программирования в сочетании с независимостью от аппаратуры дала мощный импульс к созданию библиотек. Одна из самых интересных разработок - пакет линейной алгебры ScaLAPACK, разработанный группой Дж. Донгарра.

>>к содержанию>>
2.2.2 РЕАЛИЗАЦИИ MPI
 
Библиотеки MPI реализованы практически на всех современных суперкомпьютерах.
Основное достоинство пакета LAM - богатые отладочные возможности. Трассировка обращений к MPI и анализ состояния параллельной программы после аварийного завершения - серьезный аргумент в пользу этой библиотеки, особенно учитывая серьезность проблем отладки. С другой стороны, пакет MPICH более мобилен - имеются инструкции, следуя которым можно перенести MPI на новую платформу. Для этого необходимо написать лишь несколько драйверов нижнего уровня. Установка библиотеки MPICH проходит труднее, чем установка LAM MPI, поскольку приходится задавать гораздо большее число параметров, причем назначение некоторых из них известно только разработчикам. К тому же, по нашим наблюдениям, MPICH несколько эффективнее передает сообщения, однако отлаживать программы в среде MPICH труднее.
Самые последние экспериментальные версии MPICH поддерживают мультипротокольную передачу сообщений. Часто на одном узле (особенно если он включает несколько процессоров, имеющих доступ к общей памяти) функционирует несколько процессов. Однако однопротокольные библиотеки не учитывают это обстоятельство, и для передачи сообщений как вовне, так и внутри узла используют стек TCP/IP. Из-за этого передача сообщения внутри узла сопровождается бесчисленными вызовами функций стека и многократным копированием информации в локальной памяти узла. Мультипротокольная реализация позволяет в рамках узла передавать данные через общую память, что намного быстрее.
MPICH дает возможность использовать механизм сокетов и протокол TCP/IP для реализации драйверов нижнего уровня. При этом библиотека берет на себя все преобразования типов, работу с внутренними очередями и организацию коллективных операций. Но, несмотря на то что протокол сетевого уровня поддерживает передачу сообщений "один - многие", на транспортном уровне такая поддержка отсутствует. В результате для реализации широковещательной рассылки существующие общедоступные реализации MPI используют цикл одиночных посылок. Если коммуникатор включает в себя более двух процессов, время выполнения широковещательных операций возрастает пропорционально числу процессов.
Чтобы исправить этот недостаток, следует воспользоваться одним из экспериментальных протоколов транспортного уровня, поддерживающих передачу данных от одного узла группе. Зачастую дело тормозит отсутствие стандарта. Здесь могут помочь протоколы MTP-2 (Multicast Transport Protocol), RMP (Reliable Multicast Transport), RMTP (Reliable Multicast Transport Protocol). Отметим, что в идеале передача широковещательного сообщения будет занимать столько же времени, сколько и пересылка сообщения между двумя процессами.
Возможен и другой способ оптимизации коллективных операций. Если используется сеть с коммутатором, когда по сети одновременно без коллизий можно передавать несколько пакетов, то нетрудно реализовать передачу широковещательного сообщения по дереву - параллельно несколько пар процессов будут обмениваться информацией. В этом случае время передачи широковещательного сообщения будет пропорционально логарифму числа процессов в коммуникаторе, по которому идет передача.

>>к содержанию>>
2.2.3 СРЕДСТВА ПРОГРАММИРОВАНИЯ ВЫСОКОГО УРОВНЯ.
 
Несмотря на то что MPI представляет собой значительный шаг вперед по сравнению с предшествующим поколением библиотек передачи сообщений, ожидать появления большого числа прикладных пакетов, построенных непосредственно над MPI, не приходится, поскольку программировать на MPI достаточно сложно. Причину этого следует искать не в изъянах стандарта, а в самой сути передачи сообщений. Его можно рассматривать как уровень ассемблера для параллельных программ. Неопытный программист может, как угодно далеко в тексте программы разнести вызовы функций посылки и получения сообщения и потом долго искать ошибку, связанную с неверным тегом или размером сообщения. Типичные ошибки, связанные с недетерминированностью программ, основанных на парадигме передачи сообщений, часто никак не проявляются на относительно небольших системах, на которых идет отладка, но приводят к загадочным сбоям при запуске на системах, включающих множество узлов. В итоге основные усилия тратятся не на поиск наиболее быстрого алгоритма, а на отыскание элементарных ошибок.
Часто в сетях отдельные компьютеры неравноценны, и имеет смысл нагружать их по-разному, однако даже простейшая программа, учитывающая балансировку нагрузки, - если кодировать ее, используя лишь средства MPI, - становится необъятной, и отладка ее мало кому окажется по силам. Так, матрицы в пакете SсаLAPACK, независимо от решаемой задачи и мощностей вычислительных элементов, всегда распределяются по процессорам равномерно. В результате, при наличии хотя бы одного слабого компьютера в сети, вычисления затягиваются - все ждут отстающего. Динамическая балансировка нагрузки, практически бесплатно получающаяся на SMP-компьютерах, в распределенных системах чрезвычайно трудна, и даже простое распределение данных в соответствии с мощностями узлов и последующие пересылки кодируются весьма непросто.
Выходом из создавшегося положения стали языки программирования, основанные на параллелизме данных. Первый из них, Fortran-D, появился в 1992 г. На смену ему пришел High Performance Fortran (HPF), представляющий собой расширение языка Fortran 90 и требующий от пользователя лишь указать распределение данных по процессорам. В остальном программа имеет последовательный вид (это, впрочем, не означает, что, придумывая алгоритм, не следует задумываться о присущем ему параллелизме). Транслятор самостоятельно распределяет вычисления по процессорам, выбирая в качестве узла, на котором следует производить вычисления, тот процессор, на котором будет использован результат вычисления выражения. При необходимости транслятор генерирует обращения к библиотеке передачи сообщений, например MPI. От компилятора HPF требуется тщательный анализ программы. Пользователь практически не имеет рычагов управления количеством пересылок, а поскольку инициализация каждой пересылки, независимо от объема передаваемой информации, - это десятки тысяч машинных тактов, качество получаемой программы от него зависит слабо. Язык HPF - вызов специалистам по оптимизации кода.
В языке программирования mpC - расширении ANSI C - принят компромиссный подход. Здесь пользователь распределяет не только данные, но и вычисления. Переменные и массивы распределяются по виртуальным сетям (networks) и подсетям, при этом в описаниях сетей указываются относительные мощности узлов и скорости связей между ними. В процессе выполнения mpC-программы система поддержки языка стремится максимально эффективно отобразить виртуальные сети на группы процессоров. В результате пользователь получает возможность равномерно нагружать узлы. Этот подход позволяет эффективно использовать гетерогенные сети и решать нерегулярные задачи, отличающиеся тем, что объем вычислений, производимых на каждом узле, выясняется динамически в процессе решения задачи. Этот язык позволяет избежать трудностей отладки, характерных для библиотек передачи сообщений. В то же время mpC достаточно прозрачный язык, и применяющий его программист сохраняет контроль за числом операций пересылок и объемами передаваемых данных. Относительная (по сравнению с MPI) простота программирования позволяет создавать программы и библиотеки функций, настраивающиеся на особенности конкретной вычислительной системы со своим числом процессоров и скоростями связей между ними. Такие программы не только мобильны, но и сохраняют свою эффективность при переносе с одной вычислительной системы на другую.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
3. СОВРЕМЕННЫЕ ВАРИАНТЫ LINUX - КЛАСТЕРОВ.
 
3.1. BEOWULF.
 
Одним из проектов развития параллельных распределенных вычислений является Beowulf, целью которого является применение технологии распределенных вычислений на сетях кластеров широко распространенных персональных ЭВМ. Основанием для такого проекта являлась широкое распростанение ПЭВМ, их дешивизна и увеличившаяся в достаточной степени производительность. В результате выполнения этого проекта на различных задачах была продемонстрирована пиковая производительность кластеров из 16 ПЭВМ доходящая до 1 Гоп/сек и суммарная емкость дискового простанства существенно превышающая возможности сравнимых по стоимости единичных ЭВМ.
Проект возник в научно-космическом центре NASA - Goddard Space Flight Center (GSFC), точнее в созданном на его основе CESDIS (Center of Excellence in Space Data and Information Sciences).
Проект Beowulf начался летом 1994 года сборкой в GSFC 16-процессорного кластера (на процессорах 486DX4/100MHz, 16MB памяти и 3 сетевых адаптера на каждом узле, 3 "параллельных" Ethernet-кабеля по 10Mbit). Данный кластер, который и был назван "Beowulf", создавался как вычислительный ресурс проекта Earth and Space Sciences Project (ESS).
Beowulf это мультикомпьютерная архитектура, которая предназначена для проведения параллельных вычислений. Такая система обычно состоит из одного server node (сервера) и нескольких (в самом простом случае - одного) client nodes (клиента), которые соединены между собой сетью Ethernet. Параллельная структура Beowulf строится из обычных общеупотребимых аппаратных средств, таких как персональные компьютеры класса IBM PC, стандартные Ethernet-адаптеры и маршрутизаторы. Комплекс работает под операционной системой Linux. Отказ от использования каких-либо специальных hardware-компонентов делает архитектуру Beowulf легко воспроизводимой и имеющей уникальное соотношение быстродействие/стоимость В число программных компонентов Beowulf кроме ОС Linux входят так же Parallel Virtual Machine (PVM) и Message Passing Interface (MPI). Сервер кластера управляет работой всего кластера и обслуживает файловые системы клиентских машин. Машина-сервер выполняет так же роль консоли кластера и моста в остальной intranet/internet. Крупные системы Beowulf могут иметь больше одного сервера и/или иметь несколько узловых машин (клиентов), посвященных исключительно выполнению отдельных задач, например консоль кластера или станция мониторинга системы. В болшинстве случаев клиенты кластера - очень тупые и несамостоятельные машины. И чем тупее они, тем лучше для кластера. Клиенты конфигурируются и управляются сервером кластера и делают только то, что он им задает. В случае бездисковой конфигурации клиенты не знают даже их IP-адреса или имена до тех пор, пока пока их не установит сервер. Одно из главных отличий между Beowulf и Cluster of Workstations (COW) является то, что Beowulf ведет себя больше как одиночная машина нежели чем как много рабочих станций. В большинстве случаев клиенты не имеют мониторов и клавиатур и доступны только через remote login или, возможно, через serial terminal. Другими словами, клиентские машины кластера выступают в роли просто дополнительных процессоров и модулей памяти.
Beowulf это не специальный пакет программ, новая сетевая топология или новая версия ядра. Beowulf - это технология кластеризации Linux-машин, технология формирования виртуального параллельного суперкомпьютера. Хотя имеются много программных пакетов, таких как kernel modifications, PVM- и MPI-библиотеки, и средства конфигурации, делающие архитектуру Beowulf быстрее, легче в настройке, и намного более годным к употреблению, Вы можете построить машину класса Beowulf, используя только стандартную дистрибуцию Linux без каких-либо дополнительных пакетов программ. Если у Вас есть два сетевых компьютера с расшаренным через NFS файловой системой /home, и вы доверяете этим компьютерам запускать друг у друга remote shells (rsh), тогда можно сказать, что у Вас есть простейшая двухнодовая Beowulf машина.
Кластер состоит из отдельных машин (узлов) и объединяющей их сети (коммутатора). Кроме ОС, необходимо установить и настроить сетевые драйверы, компиляторы, ПО поддержки параллельного программирования и распределения вычислительной нагрузки.

 
3.2. MOSIX.
 
Mosix - это пакет кластерообразующих программ, предназначенный для расширения ядра Linux . Расширенное ядро позволяет создавать кластеры любых размеров на базе семейства x86, Pentium процессоров. Для запуска приложений в Mosix кластере не требуется их модификация или перекомпиляция , а также не нужны дополнительные библиотеки. Ядром Mosix управляют адаптивные алгоритмы распределения ресурсов, эти алгоритмы используют приоритетное перемещение процессов, чтобы назначать и переназначать процессы среди узлов, выбирая наилучший среди доступных узлов, по признаку наименьшей занятости. Проще говоря, Mosix распределяет процессы на разные узлы кластера, при этом процесс мигрирует на наименее занятый узел.
Mosix начинался на компьютерах PDP-11 в 1977/79 годах и назывался:"UNIX with Satellite Processors" в качестве ОС использовалась Bell Lab's Unix Level 6 В 1981-83/84 годах вышли две версии под названием MOS на PDP-11 и CADMUS/PCS MC68K под обновленной ОС Bell Lab's Unix 7 с BSD 4.1. В 1987/88 вышел NSMOS на NS32332 и ОС AT&T Unix system V release 2 Также в 1988 году появилась версия под VAX, для которой впервые было использовано название MOSIX, использовалась таже ОС что и для NSMOS Первая реализация на семействе X86/Pentium появилась в 1992/93 под BSD/OS. Новая реинкарнация на X86/Pentium вышла уже на LINUX в 1998/99.
Программный пакет openMosix позволяет превратить в кластер компьютеры под управлением GNU/Linux, объединённые в сеть. Такой кластер позволит автоматически балансировать нагрузку на узлах, при этом новые узлы могут присоединяться или покидать кластер без прерывания его работы. Нагрузка на узлы распределяется исходя из скорости соединения и мощностей процессоров.
Поскольку openMosix является частью ядра и полностью совместим с Linux, то и все пользовательские программы, файлы и прочие ресурсы будут работать также, как и раньше, без каких-либо изменений. Простой пользователь даже не заметит разницы между Linux и openMosix системой. В целом картину можно представить, как будто весь кластер работает как одна (быстрая) GNU/Linux система.
ОpenMosix представляет собой патч для ядра Linux, который, тем не менее, обеспечивает полную совместимость с платформой IA32. Благодаря внутреннему механизму балансировки нагрузки процессы могут мигрировать на другие узлы кластера. В результате получается выигрыш в производительности при использовании ресурсов нескольких машин. К тому же кластер постоянно самостоятельно пытается оптимизировать обработку процессов (естественно, что администратор системы может вмешаться в процесс автобалансировки в любое время).
Такой механизм прозрачной миграции процессов позволяет представить кластер как одну большую SMP-систему с множеством процессоров на доступных узлах кластера (конечно, следует учитывать и количество процессоров в двух и четырёх процессорных системах). К тому же openMosix предоставляет оптимизированную файловую систему (oMFS) для HPC-приложений, которая, в отличие от NFS, поддерживает кэширование, отметки о времени и ссылки.
Миграция процессов. ОpenMosix позволяет запустить процесс на одной машине, а потом обнаружить, что фактически он выполняется на другой машине кластера. Каждый процесс имеет свой собственный UHN, на котором он был создан.
Миграция означает, что процесс разделяется на две части: пользовательскую и системную. Пользовательская часть будет перемещена на другой узел, в то время как системная останется на UHN. Системная часть иногда называется представительским процессом: такой процесс отвечает за разрешение большинства системных вызовов. Задачей же openMosix является поддержка связи между этими двумя процессами.
Файловая система openMosix (oMFS).OMFS является частью openMosix и позволяет обеспечить доступ к удалённым файловым системам кластера точно также, как и к любым другим смонтированным файловым системам. Таким образом, можно, к примеру, файловые системы всех узлов смонтировать в /mfs, и в результате получится, что содержимое /home третьего узла доступно с любой машины в каталоге /mfs/3/home. И Mosix, и openMosix поддерживают кластерную файловую систему MFS с опцией DFSA (Direct File System Access), что позволяет получить доступ ко всем локальным и удалённым файловым системам узлов в Mosix или openMosix кластере.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
4. РАЗВОРАЧИВАНИЕ LINUX КЛАСТЕРА НА БАЗЕ OPENMOSIX.
 
OpenMosix состоит из патча к ядру Linux и нескольких утилит пространства пользователя. Патч на ядро необходим, чтобы позволить ядру общаться с другими openMosix машинами в сети.
Пользовательские утилиты нужны для эффективного использования ядра openMosix. Они нужны для запуска/остановки демона миграции, файловой системы openMosix (MFS), для миграции задач на определённые узлы, а не на любые, и других задач, которые обычно достигаются при помощи старого доброго друга: интерфейса командной строки.

 
4.1. КОМПИЛЯЦИЯ ЯДРА.
 
Ядро и патч записываются в директорию /usr/src/, далее выполняется следующее.
 
cd /usr/src
tar vxjf kernel-source-2.4.19.tar.bz2
ln -s /usr/src/kernel-source-2.4.19 /usr/src/linux
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
 
Eсли в системе нет 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
 
Eсли в системе нету cat:
 
mv /root/openMosix-2.4.20-2.gz /usr/src/linux-2.4.20
cd /usr/src/linux-2.4.20
patch -Np1 < openMosix-2.4.20-2
 
patch должна сейчас отобразить список пропатченных файлов исходников ядра.
 
Теперь компилируем это при помощи следующей последовательности действий:
 
make config
make dep
make dep
make bzImage
make modules
make modules_install
mv /usr/src/linux/arch/i386/boot/bzImage /boot/newkernel
 
После этого редактируется конфигурационный файл загрузчика, затем компьютер перезагружается. После перезагрузки компьютер является узлом кластера.
 
 
4.2 КОНФИГУРАЦИИ КЛАСТЕРА.
 
Для запуска openMosix, должен быть сконфигурирован файл /etc/openmosix.map, одинаковый на всех узлах. Файл /etc/openmosix.map содержит три, разделённых пробелами, поля:
 
openMosix-Node_ID IP-адрес(или имя хоста) Размер диапазона
 
Например, файл /etc/openmosix.map может выглядеть так:
 
1 192.168.1.1 1
2 192.168.1.2 1
3 192.168.1.3 1
4 192.168.1.4 1
 
ОpenMosix увеличивает последний байт 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
 
Инсталляция завершена: кластер запущен и работает.

 
4.3. НАСТРОЙКА ФАЙЛОВОЙ СИСТЕМЫ OMFS.
 
Для поддержки OMFS должна быть включена опция CONFIG_MOSIX_FS в конфигурации ядра. Если текущее ядро было скопировано без этой опции, то нужна перекомпиляция с этой включенной опцией.
Также UID (идентификаторы пользователей) и GID (идентификаторы групп) для всех файловых систем узлов кластера должны быть одинаковыми. Опция ядра 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.

 
4.4 НАСТРОЙКА DSH (DISTRIBUTED SHELL)
 
Для инсталляции DSH понадобятся 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 (таким образ
и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.