Содержание


Inferno и Plan 9

Часть 2. Построение Grid

Comments

Серия контента:

Этот контент является частью # из серии # статей: Inferno и Plan 9

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Inferno и Plan 9

Следите за выходом новых статей этой серии.

Отцами-основателями технологии Grid принято считать Карла Кессельмана и Айана Фостера, которые еще в 1998 году определили Grid как "программно-аппаратную инфраструктуру, которая обеспечивает надежный, совместимый, повсеместный и недорогой доступ к вычислительным ресурсам большой мощности", а в 2000 году расширили это определение, добавив: "координированное распределение ресурсов и решение проблем в динамических виртуальных организациях".

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

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

  • Вычисления (Computing). Распределенные вычисления, в которых задания выполняются на большом числе объединенных с помощью сети слабосвязанных компьютеров или, если хотите: "вычисление, где задания, запущенные на распределенном вычислительном устройстве, выполняются двумя и более не связанными узлами". Это самый типичный вариант применения Grid, цель которого состоит в том, чтобы сократить время выполнения сложной задачи. В качестве примера приведу SETI@home – проект поиска внеземного разума, к которому может присоединиться любой желающий, скачав и установив на свой ПК Grid-клиент.
  • Хранение данных (Storage). Хранилище данных с централизованным доступом, за хранение информации в котором отвечают географически распределенные узлы. Иногда это называют Data Grid, а в качестве примера вполне сгодятся p2p-сети.
  • Совместное использование устройств (Device Sharing). Редкий вид Grid-систем, назначение которых – централизованное управление множеством разбросанных по всему миру устройств. Это, например, может быть сбор данных со множества телескопов.

Ложная сложность

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

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

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

Доводы в пользу

Inferno и Plan 9 не просто хорошо подходят для реализации распределенных систем, они для этого созданы, а значит, уже обладают всеми качествами классических Grid-инструментов, включая встроенные механизмы аутентификации клиентов и обеспечения безопасности, системы обнаружения ресурсов и управления данными.

Уместнее всего сравнивать Inferno и Plan 9 с набором Grid-инструментов Globus, который не является готовой к использованию Grid-системой, но предоставляет средства для создания таких систем. Обладая схожей функциональностью, Plan 9 гораздо проще как в понимании, так и в реализации (на самом деле архив исходных текстов всей ОС Plan 9 занимает меньше места на диске, чем архив исходных текстов Globus).

Inferno, с другой стороны, будучи основанной на Plan 9 и наследуя все его качества, обладает еще одним, очень важным для Grid, качеством: кросс-платформенностью. Inferno не только ОС, но и программа, которая может быть запущена в среде UNIX, Linux и Windows. Именно поэтому оставшаяся часть статьи посвящена установке Inferno и примерам построения Grid на ее основе.

Установка Inferno в качестве Linux-приложения

Inferno распространяется в виде исходных текстов, доступных из репозитория, расположенного на Google Code, поэтому для ее получения придется установить систему управления версиями Mercurial, а также компилятор gcc и пакет binutils. После того как это будет сделано, выполните следующую команду:

$ hg clone https://inferno-os.googlecode.com/hg/ inferno-os

Установите полный путь к каталогу inferno-os в качестве значения переменной EMUROOT:

$ export EMUROOT=/путь/до/inferno-os

Далее перейдите в этот каталог и откройте файл mkconfig. Замените строку 'ROOT=/usr/inferno' на 'ROOT=/путь/до/inferno-os', строку 'SYSHOST=Plan9' на 'SYSHOST=Linux', раскомментируйте строку '#OBJTYPE=386' и закомментируйте 'OBJTYPE=$objtype'.

Выполните следующую команду для создания недостающих каталогов (Mercurial не сохраняет пустые каталоги):

$ xargs mkdir -p < lib/emptydirs

Далее запустите на исполнение команду "./makemk.sh", которая скомпилирует утилиту mk, используемую для сборки Inferno. Включите путь до нее в переменную PATH:

$ export PATH="$EMUROOT/Linux/386/bin:$PATH"

Дайте команду на сборку Inferno:

$ mk install clean

После ее окончания создайте нового Inferno-пользователя:

$ cp usr/inferno usr/$USER

Для облегчения запуска Inferno напишите простой shell-скрипт:

#!/bin/sh 
OS=`uname` 
ARCH="386" 
EMUROOT="/путь/до/inferno-os" 
$EMUROOT/${OS}/${ARCH}/bin/emu -r${EMUROOT}

После запуска скрипта откроется окно Inferno.

Data Grid и Device Sharing Grid

Нет ничего проще, чем создать Data Grid или Device Sharing Grid на основе Inferno. Для этого достаточно экспортировать нужный участок пространства имен каждого клиента и добиться того, чтобы к экспортированным данным любого клиента можно было обратиться через одну точку. Реализация может выглядеть примерно так:

  1. Запуск сервиса registry на головном сервере:
    % ndb/cs 
    % mount -c {ndb/registry} /mnt/registry 
    % listen -A -v 'tcp!*!registry' {export /mnt/registry&}
  2. Экспорт пространства имен клиента и его регистрация в registry:
    % ndb/cs 
    % mount -A 'net!IP-адрес-сервера!registry' /mnt/registry 
    % grid/reglisten -A -r svc data 'tcp!*!1234' {export /mnt/local&}
  3. Подключение экспортированных пространств имен всех клиентов к единой точке:
    % load string 
    % ndb/cs 
    % mount -A 'net!IP-адрес-сервера!registry' /mnt/registry 
    % mkdir /grid 
    % mount {mntgen} /grid 
    % for i in `{ndb/regquery -n svc data} { 
    	(nil mntpnt nil) := ${fields ! $fi} 
    	mount -A $i /grid/$mntpnt 
    }

В первом шаге осуществляется инициализация сервера, которая состоит из запуска файлового сервера ndb/cs, ответственного за трансляцию сетевых адресов, монтирования файлового сервера ndb/registry к каталогу /mnt/registry и экспорт этого каталога.

Второй шаг – инициализация клиента, которая состоит из запуска все того же ndb/cs, подключения экспортированного сервером файлового дерева registry к каталогу /mnt/registry и регистрации сервиса data, экспортирующего каталог /mnt/local, в registry (команда grid/reglisten).

Третий шаг – получение доступа к пространствам имен всех клиентов. Для этого к каталогу /grid подключается файловый сервер mntgen, автоматически создающий точки монтирования внутри каталога, и запускается цикл опроса registry (с помощью команды ndb/regquery). При каждой итерации цикла в переменную $i записывается адрес следующего клиента, зарегистрировавшего в registry сервис data. Последующие команды выполняют монтирование клиентского каталога /mnt/local к каталогу /grid/имя-узла.

Ключевую роль здесь играет файловый сервер ndb/registry, предназначенный для регистрации сервисов, расположенных на удаленных узлах, в единой базе. Он обеспечивает возможность доступа к любому зарегистрированному сервису через единую точку, без необходимости применения внешних механизмов поиска узлов и сервисов, ведения базы адресов и т.д. Если вы просмотрите содержимое каталога /mnt/registry из любого узла, то увидите все сервисы всех клиентов.

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

Благодаря тому, что устройства в Inferno представлены файлами, описанный Data Grid легко превратить в Device Sharing Grid. Фактически для этого потребуется всего лишь экспортировать другой каталог с машин-клиентов.

Простой пример вычислительного Grid

Наиболее убедительное доказательство пригодности Inferno для Grid-вычислений привел в своих письмах на адрес дискуссионного листа Inferno энтузиаст по имени Caerwin B. Jones. Он в буквальном смысле "на коленке" собрал работающую Grid-систему, код которой состоит примерно из 20 строк на языке командного интерпретатора sh.

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

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

# Инициализация планировщика 
fn masterinit { 
	ndb/cs 
	mount -A -c {ndb/registry} /mnt/registry 
	listen -A -v 'tcp!*!registry' {export /mnt/registry&} 
} 
 
# Инициализация рабочего 
fn workerinit { 
	ndb/cs 
	mount -A 'net!$registry!registry' /mnt/registry 
} 
 
# Запуск сервиса rstyx и его регистрация в registry 
fn newcpu { 
	grid/reglisten -A -r svc rstyx 'tcp!*!0' {auxi/rstyxd&} 
}

Функция masterinit отвечает за инициализацию планировщика, workerinit – инициализация рабочего. Функция newcpu отвечает за регистрацию сервиса rstyxd в registry.

Файл gridlib должен быть скопирован на все машины, участвующие в Grid. При этом для инициализации системы на планировщике должны быть выполнены команды:

% run gridlib 
% masterinit

А на машинах-рабочих – команды:

% run gridlib 
% workerinit 
% newcpu

Через запуск функции newcpu каждый рабочий регистрирует в registry сервис rstyx, своего рода SSH-сервер в мире Inferno.

Кроме приведенных выше функций, gridlib также содержит следующие строки:

# Запуск указанной задачи на всех рабочих и ожидание ее исполнения 
fn rsplit { 
	args := $* 
	rpid := () 
	for i in `{ndb/regquery -n svc rstyx} { 
		rcmd -A $i sh -c ${quote $"args }& 
		rpid = $apid $rpid 
	} 
	for i in  /prog/ ^ $rpid ^ /wait {read < $i } >/dev/null >[2=1] 
} 
 
# Поиск файла с расширением .b или .m в каталоге исходных текстов (/appl) 
fn limbofiles { 
	fs print {select {mode -d} {filter -d {match -ar '.*\.(b|m)$'} {walk /appl}} } 
} 
 
# Монтирование именованного канала, запуск задачи поиска подстроки в 
# именованном канале на всех рабочих одновременно 
fn lk { 
	re = $1 
	bind '#|' /tmp/rpipe 
	rsplit { 
		re=`{cat /n/client/env/re}; 
		getlines {grep -i $re $line /dev/null} < /n/client/tmp/rpipe/data1 
	}& 
	sid := $apid 
	limbofiles > /tmp/rpipe/data 
	read < /prog/ ^ $sid ^ /wait >/dev/null >[2=1] 
}

Вся работа Grid сводится к поиску определенного файла в каталоге исходных текстов приложений (/appl). При этом за отдачу всех файлов с исходными текстами каталога /appl отвечает функция limbofiles, использующая инструмент fs для навигации по ФС. Функция rsplit ответственна за запуск переданной в аргументе команды на всех рабочих одновременно. Она очень проста: команда "ndb/regquery -n svc rstyx" запрашивает у registry адрес узла с запущенным сервисом rstyx. Вызов команды происходит в цикле, поэтому каждый раз команда возвращает адрес нового рабочего. На каждом из них запускается указанная команда с помощью rcmd, клиента сервиса rstyx. В последней строке происходит ожидание завершения каждого rcmd-процесса путем чтения закрепленного за ним файла wait файловой системы /prog (аналог /proc в Plan 9 и UNIX).

Функция lk запускает процесс распределенного поиска файла в /appl. Она эксплуатирует одно из отличительных качеств Inferno: экспортируемое пространство имен. Для отдачи списка для поиска рабочим используется предоставленный устройством '#I' именованный канал, смонтированный к каталогу /tmp/rpipe вызывающей машины. Затем, с помощью функции rsplit, на каждом рабочем запускается процесс получения строки из файла /n/client/tmp/rpipe/data1 (функция getlines) и поиска в ней указанной в аргументе подстроки (команда grep). Сервис rstyx, который используется rsplit для выполнения команды на рабочем, отличается от SSH тем, что перед выполнением команды монтирует пространство имен клиента к каталогу /n/client, поэтому запущенная с помощью rcmd команда получает доступ к именованному каналу через файл /n/client/tmp/rpipe/data1.

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

Для тестирования системы создайте каталог /tmp/rpipe:

% mkdir /tmp/rpipe

И запустите процесс поиска:

% lk wmexport

Естественно, вы можете использовать команду rsplit просто для запуска команды на множестве клиентов, или модифицировать скрипт для поиска в текстовых файлах или для выполнения других действий.

Inferno Owen. Обзор

Специалисты могут сказать, что приведенный пример всего лишь игрушка, не имеющая ничего общего с реальными Grid-системами, и будут абсолютно правы. Grid-система для Inferno, распространяемая Vita Nuova, гораздо более интеллектуальна и сложна (что, однако, не мешает ей быть чрезвычайно простой в использовании).

Программный комплекс Owen, названный в честь британского предпринимателя Роберта Оуена (Robert Owen), создавшего беспристрастную биржу труда, представляет собой набор инструментальных средств, с помощью которых любое количество инстанций Inferno, разбросанных по сети, может быть объединено в Grid.

Owen состоит из следующих трех компонентов.

  • Планировщик (Scheduler) – центральный компонент Owen, который отвечает за привязку заданий к рабочим, помогает в передаче данных и следит за качеством выполнения работы. Это "биржа труда", на которую приходят рабочие.
  • Рабочие (Workers) – узлы, выполняющие работу. Рабочие приходят на биржу труда, анонсируют тип работы, за которую готовы взяться, и ждут своей очереди.
  • Управляющие (Controllers) – работодатели. Как и рабочие, управляющие приходят на биржу труда, но с целью не получить работу, а дать ее.

Как и многие другие Grid-системы, Owen использует термин работа (Job) для обозначения задачи, которую следует выполнить в рамках Grid, и задание (Task) для обозначения одного из кусочков этой работы, предназначенного для выполнения одним рабочим. Для расщепления работы на набор заданий применяются так называемые "генераторы заданий".

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

  • Рабочие подключаются к планировщику, используя протокол TCP. После удачного соединения рабочий импортирует пространство имен планировщика и записывает свои атрибуты, такие как скорость процессора и объем памяти, в файл nodeattrs, системное имя – в файл nodename. После этого рабочий открывает файл task и блокируется до появления готового к выполнению задания.
  • Когда приходит рабочий, Owen спрашивает у генератора заданий о новых заданиях. Если таковые имеются, Owen отправляет генератору заданий различную информацию о рабочем (скорость процессора, объем памяти, IP-адрес и т.д.). Если генератор заданий решает, что рабочий ему подходит, он устанавливает с ним связь и отправляет данные для обработки.
  • Рабочий читает данные задания и выполняет его, записывая результаты исполнения обратно в файл task. Затем он вновь открывает файл task на чтение в ожидании следующего задания.

В Owen заложено несколько механизмов, обеспечивающих устойчивость. Планировщик регулярно делает дамп своего состояния, чтобы восстановить его после обрушения и/или перезапуска. Если это случается, рабочие автоматически пробуют переподключиться. Как следствие, после "падения" планировщика работоспособность Grid восстанавливается в автоматическом порядке.

Одна из возможных проблем заключается также и в том, что рабочий, взявший на исполнение задание, может никогда не закончить его исполнение (потеря связи, отказ ПО и т.д.). Чтобы гарантировать выполнение всей работы, Owen продолжает рассылать задания, связанные с работой, даже после того, как раздал их все. Когда работа заканчивается, все рабочие, выполняющие дублирующие задания, оповещаются о том, что выполнение задания следует прекратить.

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

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

Модель безопасности Owen полностью основана на модели безопасности самой Inferno и не добавляет к ней ни одного нового слоя. Это значит, что все данные, передаваемые между рабочими, планировщиком и управляющими по протоколу 9P/Styx могут быть зашифрованы, сами узлы обязаны предъявлять сертификаты, а выполняемые задания могут быть помещены в изолированное окружение исполнения (пространства имен). При этом сам Owen предлагает механизм защиты рабочих от исполнения нелегального кода через описательные файлы работы (они рассматриваются ниже).

Owen предлагает несколько генераторов заданий общего назначения, каждый из которых готов справиться с некоторым общим классом работы. Один из них, известный как filesplit, берет файл и создает задания, каждое из которых обрабатывает некоторый указанный участок файла. Другой, названный просто job (работа), рассчитан на более широкий диапазон работ, которые имеют известное количество заданий, каждая из которых требует входные данные в виде файлов и значений параметров (возможно, различные для каждой задачи).

Inferno Owen. Использование

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

Чтобы проделать это, установите Inferno, как было показано выше. Затем получите дистрибутив Owen:

$ cd /tmp 
$ wget http://inferno-owen.googlecode.com/files/owen-20080430-r4.tgz

Распакуйте его в корень вашей инсталляции Inferno:

$ cd /путь/до/inferno-os 
$ tar -xzf /tmp/owen-20080430-r4.tgz

Скопируйте каталог inferno-os в другое место так, чтобы у вас получилось две Inferno-инсталляции:

$ cp -R /путь/до/inferno-os /путь/до/inferno-owen-slave

Откройте файл /путь/до/inferno-os/grid/master/config и отредактируйте его так, чтобы опции schedaddr и schedfsaddr указывали на адрес машины, которая будет исполнять роль планировщика:

(schedaddr "tcp!host.com!6678") 
(schedfsaddr "tcp!host.com!1234") 
(auth "0")

Адрес задается в формате "протокол!имя-узла!порт". Внесите соответствующие изменения в файл /путь/до/inferno-owen-slave/grid/slave/config.

Рабочий позволит планировщику запросить исполнение только определенного набора заданий, перечисленных в шелл-скриптах с расширением .job, расположенных в каталоге /grid/slave каждого клиента. Существует библиотека шелл-скриптов для возможных заданий в каталоге /grid/slave/tasks, указанная задача разрешается на клиенте через копирование .job-файла в /grid/slave. Мы сделаем так, чтобы можно было запустить все, что угодно. Скрипт .job, позволяющий сделать это, называется test.job и лежит в /grid/slave/tasks. Его содержимое очень просто:

load std 
fn runtask { 
	$* > result 
} 
fn submit { 
	cat result 
}

Скопируйте его в каталог /путь/до/inferno-owen-slave/grid/slave. Перенесите каталог inferno-os на машину-планировщик, а inferno-owen-slave – на машины-рабочих.

Чтобы запустить планировщик, запустите Inferno, наберите wm/wm, в открывшемся графическом окне нажмите на кнопку в левом нижнем углу и выберите в меню пункт "Shell". Наберите следующую команду:

% /grid/scripts/Inferno/scheduler&

На машинах-рабочих запустите Inferno и выполните:

% /grid/scripts/Inferno/worker

Теперь вернитесь на машину-планировщик и выполните команду owen/nodemonitor. Вы должны увидеть список всех подключенных узлов-рабочих и их статус.

Чтобы проверить работоспособность нашего Grid, запустим на исполнение простую работу, которая заключается в чтении файла и создании md5-суммы каждой его строки. Естественно, строки будут поделены между узлами и обработаны независимо.

Нам понадобится исходный материал для обработки, которым может быть любой текстовый файл, разбитый на строки. Для примера возьмем /INSTALL – файл, хранящийся в корне Inferno-окружения и описывающий процесс установки ОС. Скопируем его в отдельный каталог, например /tmp (все приведенные ниже команды следует выполнять в терминале планировщика):

% cp /NOTICE /tmp/tasks

И запустим работу:

% run /lib/sh/sched 
% mountsched 
% start filesplit -l /tmp/tasks test md5sum 
1 
%

Генератор заданий filesplit берет файл, разбивает его на множество записей (аргумент -l означает, что записи должны быть разделены новой строкой) и отдает каждую запись на стандартный ввод перечисленных в следующих аргументах команд. В нашем случае записи будут отданы заданию test, которое запустит скрипт /grid/slave/test.job с аргументом md5sum на каждом клиенте.

Результат будет сохранен в файл, имя которого совпадает с источником, плюс расширение .result:

% cat /tmp/tasks.result 
data 33 2 
68b329da9893e34099c7d8ad5cb9c940 
data 33 0 
af325e1d9e7df186ec43b7064971e591 
data 33 3 
b1ab8481a01ba86bc936c679f9d09187 
data 33 1 
bd04ba4c99cb67c7371b6a2c359d7391 
...

Скорее всего, вы не сможете наблюдать за выполнением этой работы из-за слишком высокой скорости исполнения. Однако в любом случае "монитор работ", который можно вызвать набрав owen/jobmonitor в окне терминала, поможет сделать это.

Графические приложения owen/nodemonitor и owen/jobmonitor – всего лишь обертки к файловому интерфейсу Owen, который используется как для общения рабочих с планировщиком, так и для управления самим планировщиком. Фактически вы можете вообще не использовать какие-либо приложения и команды для управления Grid, положившись на файловый интерфейс. Пример просмотра списка работ:

% mount tcp!host.com!owen 
% cd /n/remote/admin 
% cat jobs

Запуск новой работы:

% cd /n/remote/admin 
% echo load filesplit -l /tmp/tasks test md5sum > clone

Установку не обязательно производить описанным в статье способом. Vita Nuova предлагает установочный CD, который содержит сборки Inferno с предустановленным планировщиком Owen для разных платформ, а также варианты сборки рабочих с облегченной версией Inferno. Одна из них предназначена для запуска в качестве сервиса Windows NT.

По умолчанию Owen не производит шифрования передаваемых данных и аутентификации рабочих. Чтобы заставить его делать это, настройте auth-сервер, как это описано в официальной документации Inferno, и используйте файлы /grid/master/authconfig и /grid/slave/authconfig в качестве шаблонов конфигурационных файлов Owen.

Inferno Owen. Выводы

  1. Owen – отличная Grid-система, обладающая массой достоинств: 1. Простота установки и использования. На развертывание Owen-сети уходит не больше часа.
  2. Высокий уровень безопасности:
    • Inferno шифрует любые передаваемые данные и обязывает клиентов к предъявлению сертификатов, удостоверяющих их подлинность.
    • Ни один компонент Owen не работает с правами root.
    • На планировщике необходимо открыть всего один порт.
    • Возможность привязки рабочих только к определенным типам заданий (чтобы избежать запуска небезопасного кода).
  3. Интерфейс управления планировщиком, основанный на файловом дереве, позволяет легко создавать различные фронт-енды для управления работами и мониторинга (реализация протокола Styx существует почти для всех популярных языков программирования).
  4. Очень небольшая кодовая база, которая позволяет легко производить различные модификации и доработки.
  5. С помощью Inferno очень просто создать Data Grid, который может быть использован совместно с Owen.

К недостаткам Owen можно отнести:

  • плохую документацию и скудную базу пользователей;
  • отсутствие "продвинутых функций": миграция, MPI (существует проект owen-mpi, но он реализован на Java);
  • отсутствие интеграции с Globus;
  • плохое масштабирование (Owen не позволяет иметь более одного планировщика на один Grid, однако такую возможность нетрудно добавить).

Выводы

Inferno не только пригодна для создания систем типа Grid, она годится для этого лучше любой другой операционной системы. В этой статье мы рассмотрели несколько различных Grid-систем для Inferno, особый акцент сделав на Owen – готовом к промышленному использованию комплексу ПО для построения Grid. И вот какие выводы можем сделать:

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

Существует множество других реализаций Grid-систем для Inferno. Например: Geryon Grid – простая Grid-система, написанная на sh и обладающая функциональностью MapReduce; Melua Grid – реализация Data Grid, использующая mesh-топологию (без центрального узла); 9gridchan.org – Grid на основе Plan 9 и Inferno.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux, Open source
ArticleID=579903
ArticleTitle=Inferno и Plan 9: Часть 2. Построение Grid
publish-date=11112010