Создание удобных вычислительных сетей на базе Inferno OS
Making Infernal Grids Usable
Источник: www.vitanuova.com/papers/ugrid.pdf
C H Forsyth
Vita Nuova
3 Innovation Close
York Science Park
York YO10 5ZF
6 January 2006
forsyth @ vitanuova.com
КРАТКИЙ ОБЗОР[]
Мы будем рассматривать «grid» как распределенную систему специализированного применения. Мы опишем построение нескольких промышленных систем реализованных с использованием распределенной операционной системы Inferno. Лежащая в основе технология исходно была удобным средством, обе системы разрабатывались в качестве коммерческих проектов, спроектированных в тесном сотрудничестве с конечными пользователями, которые в результате внесли неоценимый вклад в их удобство. Тем не менее, технология помогла ускорить разработку и и сделала даже низкоуровневые интерфейсы легко документируемыми, понятными и поддерживаемыми. Она представляет всю функциональность сети, включая планировщик, иерархическую структуру каталогов, доступ осуществляемый через обычные операции файлового ввода-вывода, и импорт/экспорт при помощи сети Internet в случае необходимости.
ВВЕДЕНИЕ[]
Vita Nuova применила новые технологии для построения распределенной сети. Прежняя подготовка основателей компании включала в себя успешную разработку в 90-х годах систем аукционов реального времени (свиней и машин, отдельно) и онлайновых интернет-игр. Это были значительные распределенные системы изготовленные на коммерческой основе при помощи традиционной технологии (C и Unix) и нестандартном подходе. Например, интерфейсы между различными компонентами аукционной системы были определены в соответствии с Promela — языком описания протокола, автоматически проверенного при помощи SPIN — верификатора протокола, и были реализованы как распределенные коммуникационные процессы непосредственно порожденные ими. Позже, мы сформировали Vita Nuova для разработки и эксплуатации нескольких новых систем созданных в исследовательском центре Bell Labs, создавшей 30 лет назад Unix, а теперь Plan 9 и Inferno. В отличии от Unix (и клонов Unix) они были спроектированы с ориентацией на сеть.
В следующие несколько лет Vita Nuova закончила несколько успешных проектов в обоих направлениях: разделения ресурсов (resource-sharing) и вычислительных сетей (computational grids). Целью являлось не создания набора инструментов, а удобной развертываемой системы, «конечные пользователи» в нашем случае были исследователи и ученые, а не пользователи программных интерфейсов. Как бы то ни было, некоторые ученые нуждались в программных интерфейсах, и нам требовалось чтобы они были открытые и простые. Нам могли помочь различные аспекты технологии лежащей в основе системы. Я опишу три системы которые мы построили, процесс их разработки и некоторые заключения к которым мы пришли. Все три системы были построены на базе ОС Inferno. Мы ощущали что эта технологическая модель позволяет производить системы легкие в проектировании и построении, быстро, с опорой на хорошие стандарты, и я вам приведу некоторые доводы в пользу этого. Однако более важным, ключевым аспектом процесса разработки, явилось то, что в каждом случае мы тесно работали с потребителями — учеными и исследователями, которые и были конечными пользователями, для создания системы которая бы удовлетворила их потребности, которую бы они сочли «удобной».
INFERNO[]
Inferno1, 2 это операционная система, которая предоставляет альтернативную вселенную для построения распределенных систем. Окружение предоставленное приложениям заимствовано из Plan 9,3 и не общепринято (неортодоксально). Все ресурсы представлены в иерархическом пространстве имен которое может быть собрано динамически для каждого процесса4. Ресурсы включат в себя привычную файловую систему, устройства, сетевые интерфейсы, протоколы, оконную графику и системные службы, такие как обнаружение ресурсов и разрешение имен. ОС Inferno запускается непосредственно на голом железе, но и что необычно, она может работать в «гостевом» режиме под управлением другой операционной системы, включая Windows и Unix-подобные системы. Она представляет виртуальную операционную систему для распределенных приложений, включая виртуальные сети, скорее выступая в качестве программного обеспечения промежуточного уровня.
Inferno-приложения получают доступ ко всем ресурсам при помощи операций файлового ввода-вывода: открытие, чтение, запись и закрытие. Приложение предоставляющее сервис разделяемый между клиентами выступает в роли файлового сервера. В этом контексте, файловый сервер это просто программа, которая интерпретирует общий протокол независимого файлового сервиса названного Styx(TM) в Inferno и 9P2000 в Plan 9.2,5 Распределение достигается прозрачно при помощи импортирования и экспортирования ресурсов из одного места в другое используя этот протокол, поверх любого подходящего транспортного протокола. Приложения запущенные в локальном пространстве имен которое содержит необходимые ресурсы, импортированные если необходимо, не осведомлено об их местонахождении. Ресурсы могут быть легко и безопасно импортироваться в пределах административных ограничений. В случае гостевого режима, Inferno предоставляет одно и тоже пространство имен представленное ресурсами основной системы (включая драйвера и сетевые интерфейсы) как если бы они были предоставлены в родном режиме. Так например, некто может импортировать сетевой интерфейс машины под управлением Linux в приложение запущенное под управлением Windows и использовать машину с Linux в качестве шлюза. В любом случае, Inferno предоставляет одинаково точный интерфейс вызовов к его приложениям.
Протокол Styx, сам по себе является независимым от языка и от системы. Он насчитывает несколько операций, в основном очевидных, открыть, прочитать и закрыть, дополненные операциями по навигации и работе в пространством имен и его метаданными. Он был реализован на малых устройствах, таких как программируемый конструктор Lego(TM),6 есть реализация на языках C, Java, Python и других. Реализация сервера Styx на FPGA (ПЛИС) была разработана для поддержки массовых вычислений. Он был предложен для использования в беспроводной сенсорной сети.7 Blower et al.8 предоставляет Grid-услуги включающие техпроцесс с использованием из реализации Styx на Java. Модуль v9fs серии ядер Linux 2.6 предоставляет непосредственный доступ к 9P2000 и Styx через обычные системные вызовы Linux.9
АДСКИЕ СЕТИ[]
Мы применили Inferno и Styx для построения grid. Пожалуй, одним из импульсов было прочтение газет сообщающих об исследовании в области вещей которые годами выполняются совершенно мимоходом в Plan 9 и Inferno , такие как запуск интерактивных каналов с компонентами взаимной аутентификации, администрированием и безопасным доступом через интернет к ресурсам множества систем, как к одной. Я опишу три направления: демонстратор (demonstrator), который представляет интерес с точки зрения доступа к спектру ресурсов; сеть хранения данных (data-sharing grid), которая создает безопасное локальное хранилище данных из распределенной коллекции; и более традиционную вычислительную сеть (computational grid), который распределяет вычислительную нагрузку на доступное множество вычислительных элементов, наподобие Condor.10 Вопреки таким разным задачам, все они могут быть построены с использованием единообразного механизма Inferno описанного выше: все ресурсы представлены файловыми серверами Styx, и могут быть доступны традиционным командам и системным вызовам.
Демонстратор[]
Первая система была небольшим экспериментом по построению простого grid (по крайней мере в нашем значении слова), который должен был выступать в качестве демонстратора, выставочным образцом Grid, привлекающим бизнесменов.11 У нас была коллекция разных машин работавших под различными операционными системами, и целью было дать доступ к ним любому подключившемуся к системе. «Ресурсы» включали в себя данные и службы все соединенные и доступные удаленно (безопасно). Мы добивались широкого разнообразия подчеркивающего какой диапазон поддерживается единственным представлением ресурса в Inferno. Среди других вещей, мы предлагали следующие:
- Lego(TM) Mindstorm(TM) программируемый конструктор встроенный в работающие часы6
- цифровая камера Kodak(TM) управляемая компьютером
- база данных ODBC
- совместная деятельность: общая доска для рисования и многопользовательская карточная игра
- распределенный вычислительный сервис по обработке изображений (‘cpu service’)
- регистрация ресурсов
Три человека за четыре недели связали системы вместе, включая написание cpu-сервиса, регистрации ресурсов, демонстрации обработки изображений, и пользовательский интерфейс. Позже, с накоплением опыта, все было снова проверено и улучшено, написано несколько страниц руководства, но с сохранением реализованной структуры. Так же, как часть демонстрации, нами был достаточно легко написан плагин к Internet Explorer, представляющий собой встроенное окружение Inferno на веб-странице, позволившее браузеру получить доступ к нашей маленькой демонстрационной «сети» без необходимости устанавливать специальное программное обеспечение, и без компроментации нами демо-сети через HTTP -шлюз. Компьютер с Inferno запущенной в родном режиме служил шлюзом к набору сервисов, расположенных за нашим файерволом. Inferno пользовался системой публичных ключей для авторизации подключающихся, которые должны были добавить их собственные машины в пул cpu-серверов для увеличения вычислительной мощности демо-grid.
Система была продемонстрирована на нескольких конференциях, включая Британскую академическую конференцию по Grid в июне 2003.11 Система не предназначалась для промышленного использования, к примеру, она не была достаточно защищена от сбоев. Но даже такая, она позволяла нам экспериментировать с различными способами представления вычислительных ресурсов. Она также показала реалистичную область ресурсов которые могут быть собраны и к которым может быть получен доступ при помощи единственного метода предоставления ресурсов Inferno: все ресурсы и службы перечисленные выше были представлены файловыми серверами, к которым клиенты получали доступ при помощи открытия, чтения, записи и закрытия. Сами по себе ресурсы были предоставлены различными машинами запущенными с родной операционной системой, но на всех них работала ОС Inferno.
Data grid для гуманитарного факультета (?)[]
Центр электронных текстов гуманитарного факультета университета Рутгерс выразил желание использовать распределенную компьютерную систему для унифицированного предоставления полного доступа к разрозненным ресурсам литературных коллекций, разбросанных на разных машинах, платформах и находящихся под различным административным управлением. Целью было сделать возможным безопасное «интерактивное взаимодействие для достижения общих целей, как если бы пользователи работали на одном большом виртуальном компьютере».12 Задачи заключались не только в просмотре существующих архивов, но и управление и их модификация, добавление нового материала, включая ссылки и аннотации.
Мы сблизились с одним из директоров и поскольку в дело была вовлечена некоммерческая организация, договорились создать систему «по себестоимости». Некоторые подготовительные технические требования и спецификации были собраны по телефону и электронной почте, до того как как один из участников нашей команды был отправлен в Рутгерс для проведения работ. Он провел несколько дней на месте, уточняя окончательную спецификацию в переговорах с конечными пользователями, осуществляя поддержку приложений Inferno, приводя их в законченный вид, инсталлируя систему на соответствующие машины и предоставляя некоторое обучение. Это приложение используется и по сей день.
Реализация была прямолинейной: один или более приложений-браузеров архива запускались на клиенте, каждый создавал соответствующее пространство имен для данной задачи, включал пространство имен с других серверов или клиентов как это требовалось для текущего взаимодействия. Поскольку все ресурсы выглядели как файлы в файловом браузере, тем не менее не существовало иерархии физических файлов относящейся к представленному виду. Было весьма важно, что машины легко добавлять, что доступ безопасен, что сотрудники видели только те файлы, которые были частью совместной работы. Кроме того, приложения которые использовали ресурсы не были доступны в исходных текстах, и поэтому оставались не измененными.
Вычислительная сеть[]
Вычислительная сеть была, пожалуй, наиболее интересной, поскольку она должна была содержать существенно новые компоненты. Это была полностью коммерческая разработка, намного большего масштаба. Однако, мы следовали тому же самому подходу: сбор требований, разработка спецификации, реализация, развертывание, тестирование и доводка.
Покупатель интенсивно использовал существующий набор научных приложений. Они использовали их для собственных исследований, и также предоставляли аналитическую службу для сторонних компаний. Приложение должно было потреблять как можно больше вычислительных мощностей. К счастью, как это часто случается, входные данные можно было разбить на небольшие фрагменты, обрабатываемые независимо, а полученные независимые результаты объединить или сгруппировать для получения окончательного результата. В различных отделах компании насчитывались многие сотни компьютеров работавших под управлением Windows, и несколько серверов, и они хотели использовать холостые циклы компьютеров для построения большой виртуальной вычислительной системы.
Несколько представителей группы разработчиков Vita Nuova, включая менеджера проекта работали с хорошо осведомленными сотрудниками копании-покупателя для уточнения и расширения их первоначального набора требований. У них был предыдущий опыт работы с grid-системами и поэтому их первоначальные требования были достаточно точны чем могли бы оказаться в другом случае.
Спецификация и реализация проводились в два этапа, с краткими обсуждениями и сводными отчетами на всем протяжении. Во-первых мы пришли к соглашению относительно общей концепции, и изготовили демонстрационное программное обеспечение. Мы продемонстрировали ученым (и управляющим) что мы можем запустить существующие Windows-приложения на небольшом количестве машин в нашем офисе и что заявленное увеличение производительности может быть достигнуто. Затем мы обсудили требования и спецификацию реальной системы в деталях, разработали и реализовали и передали им.
Конечно, если бы наша небольшая демонстрация провалилась из-за фундаментальных причин, проект бы легко завершился. По нашему опыту, это обычный подход для коммерческих проектов. Конечно, если не учитывать множество неточностей: например, будет ли «промышленная» система масштабируемой до нескольких сотен узлов?
Окончательная система, теперь называемая «Owen», была простой моделью раздачи заданий,13 образующая сердце виртуальной системы разделения времени. Рабочие узлы с доступным временем, представляли соответствующие атрибуты и условия планировщику для обмена, который предлагал задания из своей очереди. Если задача была подходящей, рабочий исполнял ее и отправлял результаты, которые проверялись при получении (например на полноту или валидность) перед тем, как окончательно пометить работу как «завершенную». Планировщик подсчитывал сбои для узлов и задач. Наибольшей единицей передачи задания и управления было задание, разделяемое на одну или большее количество элементарных задач. Каждое задание было ассоциировано с генератором задач, который разбивал задание на задачи основываясь на некоторых специфичных критериях присущих данному приложению. Обычно, задание делится в соответствии со свойствами входных данных, известных заранее до запуска задания, но задачи могут создаваться динамически генератором задач в случае необходимости. Рабочие запрашивают задания в случае бездействия, когда процессоры собирают задания на многопроцессорной архитектуре, вероятнее чем работа будет им послана в зависимости от планируемой загрузки.
В команде программистов было три человека: один работал над планировщиком, один над рабочим, и один делал различные программы с графическим интерфейсом для управления grid. Это заняло от шести до восьми недель до окончательного доставки, установки и тестирования. Затем была предпринята дальнейшая разработка, добавление возможностей не относящихся к этому обсуждению.
ИНТЕРФЕЙСЫ ПОЛЬЗОВАТЕЛЯ И ПРОГРАММИСТА[]
Представление на основе файлов, как самый нижний видимый уровень доступа так или иначе дает доступ к ресурсам с ощущением твердости (о как...). Легко строить различные типы интерфейса на такой основе. Я буду здесь использовать в качестве примера вычислительную сеть.
Администрирование узлов и заданий[]
Owen администрируется посредством двух простых приложений в стиле ‘point and click’. Монитор Узлов показан на Рисунке 1, где виден статус доступных компьютеров производящих вычисления. Узлы могут отключаться после получения заданий, и снова подключаться позже для передачи результатов. Монитор Узлов в таком случае отличается. Он позволяет добавлять и удалять узлы из рабочего набора, приостанавливать, и организовывать в именованные группы с ограничениями на определенные работы, классы работ или владельцев работ.
Рисунок 1
Монитор Заданий показан на Рисунке 2 отображает статус задания выданного пользователю, включая индикатор завершения. Задания могут создаваться и удаляться, приостанавливаться и продолжаться и их приоритет может регулироваться. Цель этих двух приложений быть простыми, выглядящими незагроможденными, отражающими простую модель за которой скрывается сложный комплекс механизмов базовой системы.
Рисунок 2
Фундаментальный интерфейс раздачи заданий[]
Чтобы быть более конкретным и помочь нам оправдать наш выбор Inferno, давайте заглянем за графический пользовательский интерфейс. Стартовой точкой для проектирования было описание пространства имен представляющего вычислительные ресурсы. Планировщик заданий обслуживает это пространство имен. Каждый рабочий узел присоединяет его к своему собственному локальному пространству имен, в определенном месте. Мы можем посмотреть на него при помощи следующих команд:
mount $scheduler /mnt/sched cd /mnt/sched; ls -l
Планировщик обслуживает иерархию пространства имен со следующими именами в своем корне, ниже приведен вывод Unix-подобной команды ls -l данной выше:
d-r-xr-x--- M 8 admin admin 0 Apr 13 19:58 admin --rw-rw-rw- M 8 worker worker 0 Apr 13 19:58 attrs --rw-rw-rw- M 8 admin admin 0 Apr 13 19:58 nodename --rw-rw-rw- M 8 worker worker 0 Apr 13 19:58 reconnect --r--r--r-- M 8 worker worker 0 Apr 13 19:58 stoptask --rw-rw-rw- M 8 worker worker 0 Apr 13 19:58 task
Отметьте, что каждый работник видит одни и те же имена, с точки же зрения планировщика, каждый работник уникален и получает предназначенные ему данные. К тем файлам, у которых установлен владелец «worker» работник может получить доступ. Работник может писать в файл attrs для описания свойств своего узла и допустимой работы. Рабочий читает файл task для получения предложения о работе, чтение блокируется до тех пор, пока задание не будет доступно. (В основном, так в окружении Styx осуществляется публикация/подписка: вместо того чтобы иметь специальный механизм или терминологию, приложение просто открывает файл для «подписки», являющийся источником данных от сервера, и в последующем считывает возвращаемые данные, представляющие запрашиваемые «события» как только они становятся доступными, точно так же как это происходит с клавиатурой, мышью и другими устройствами.) Дальнейшие чтения и запись, обмен данными специфичными для задачи происходит с генератором задач, запущенным как процесс в планировщике. Далее они обрабатываются компонентами специфичными для задачи запущенными у рабочего. Среди прочих вещей, клиентские компоненты могут принимать набор параметров задания, небольшое количество данных или список ресурсов где-то в сети для подключения к локальному пространству имен задачи для использования в приложении. Первый генератор заданий был характерен для таких программ как GOLD или CHARMM, так что покупатели могли заниматься продуктивной работой прямо сейчас. Затем мы абстрагировались от этого. Более поздние генераторы поддерживали различные общие классы вычислений (включающие эти приложения); последний генератор предлагал простой язык описания заданий.
Управление и мониторинг заданий предоставляется файлами в каталоге admin:
d-r-xr-x--- M 4 rog admin 0 Apr 14 16:31 3 d-r-xr-x--- M 4 rog admin 0 Apr 14 16:31 4 d-r-xr-x--- M 4 rog admin 0 Apr 14 16:31 7 --rw-rw---- M 4 admin admin 0 Apr 14 16:31 clone ---w--w---- M 4 admin admin 0 Apr 14 16:31 ctl --r--r----- M 4 admin admin 0 Apr 14 16:31 formats --r--r----- M 4 admin admin 0 Apr 14 16:31 group --r--r----- M 4 admin admin 0 Apr 14 16:31 jobs --r--r----- M 4 admin admin 0 Apr 14 16:31 nodes d-rwxrwx--- M 4 admin admin 0 Apr 14 16:31 times
Доступ к нему ограничен для членов группы admin. Каждое задание ассоциировано со своим подкаталогом (3,4 и 7 как видно здесь) содержат относящиеся к задаче данные.
--rw-rw---- M 4 rog admin 0 Apr 14 17:08 ctl --rw-rw---- M 4 rog admin 0 Apr 14 17:08 data --rw-rw---- M 4 rog admin 0 Apr 14 17:08 description --r--r----- M 4 rog admin 0 Apr 14 17:08 duration --r--r----- M 4 rog admin 0 Apr 14 17:08 group --r--r----- M 4 rog admin 0 Apr 14 17:08 id --r--r----- M 4 rog admin 0 Apr 14 17:08 monitor
Для создания нового задания программа открывает новый файл admin/clone который выделяет новую директорию названную новым номером задания, и возвращает дескриптор файла ctl. Управляющие запросы являются простым текстом. Например:
load jobtype arg ...
выделяет генератор заданий для задания и предоставляет статические параметры этого задания, start запускает набор на выполнение, stop приостанавливает их и delete отменяет их.
Чтение id возвращает идентификатор задания. Чтение duration выдает число, представляющее время жизни задания. Чтение group возвращает название группы рабочих узлов которые обслуживают это задание. Первое чтение из файла monitor возвращает текущий статус задания, каждое последующее чтение будет заблокировано до тех пор, пока статус не изменится, следуя тем же самым принципам что и в случае с файлом task описанным ранее. Обратите внимание, что только администратор grid и владелец задания имеют разрешения на доступ к этим файлам. Файлы в каталоге admin описывают или управляют всей сетью grid.
Уровни интерфейса[]
Мониторы Заданий и Узлов — приложения которые предоставляют удобный графический интерфейс и они, это то как раз то, что используется большинством пользователей. Программа действует, однако, открывая, читая и записывая файлы в пространство имен о котором упоминалось ранее. Таким образом, монитор читает файл для того чтобы узнать текущий статус системы, который отображается в рамке. Монитор Заданий удаляет задание открыв соответствующий ctl файл (при наличии прав) и записывает туда сообщение delete. Благодаря этому его легко написать и отладить. Программное обеспечение узла-работника действует так же, открывая считывая и записывая файлы.
Приведенное описание пространства имен планировщика, и протокол используемый для каждого из его файлов, три программных компонента (монитор, работник и планировщик) могут быть написаны и протестированы независимо друг от друга. Легко создать для проверки либо «настоящий» файл, либо простой синтетический файловый сервер, который ведет себя подобно содержимому действительного файла планировщика. И напротив, когда производится тестирование планировщика, любой может воспользоваться командным интерпретатором Inferno для взаимодействия с пространством имен и записать в скрипт последовательность операций. Это подстегивает независимую разработку. На уровень ниже графического интерфейса, система предоставляет набор шелл-функций для интерактивного или скриптового использования. На этом уровне немного работы для конечного пользователя, поэтому обсуждение будет носить поверхностный характер. Вот простой скрипт для того чтобы послать простое задание в grid:
run /lib/sh/sched # load the library mountsched # dial the exchange and put it in name space start filesplit -l /tmp/mytasks test md5sum
Заключительная команда start является шелл-функцией которая запускает новое задание. В этом случае, filesplit job, создает отдельные задачи для каждой строки в файле /tmp/mytasks, каждая задача вычисляет MD5 хэш соответствующих данных. Реализация самой функции start показана ниже:
fn start {
id := ${job $*}
ctl $id start
echo $id
}
Она вызывает две другие функции job и ctl, которые взаимодействуют с пространством имен планировщика заданий, как об этом упоминалось ранее. Job клонирует новый каталог заданий и зпускает генератор задач. Проигнорировав обработку ошибок получим следующее:
subfn job {
{
id := `{cat}
result=$id
echo load $* >[1=0]
} $* <> /mnt/sched/admin/clone # open for read/write
}
И ctl посылает управляющее сообщение данному заданию:
fn ctl {
(id args) := $*
echo $args > /mnt/sched/admin/$id/ctl
}
Разные генераторы задач вызывают шелл-функции специфичные для приложения выдачи заданий и клиентов, позволяющие легко производить подгонку. Например, клиентская функция runtask вызывается для запуска на клиенте и передает результирующие данные (если они есть) обратно выдающему модулю. Задание test использованное выше у клиента определено так:
load std
fn runtask {
$* > result # run arguments as command
}
fn submit {
cat result
}
Приложение runtask для Windows обычно более сложное, содержащее код для запуска, проверяющее предусловия, и предоставляющее свои данные в требуемом формате. Ниже приведена версия для задачи обработки изображения:
fn runtask {
# get files
check gettar -v # unpack standard input as tar file
# run
cd /grid/slave/work
check mkdir Output
check {
os -n $emuroot^/grid/slave/image/process.exe <image >Output/image
}
}
fn submit {
check puttar Output
}
Соответствующий класс спецификации задания находится в планировщике. Это также шелл-функция: mkjob подготавливает глобальные параметры для задания; mktask для подготовки особых параметров задачи; runtask для передачи задачи и ее параметров работнику; endtask для проверки результатов; и failedtask для коррекции ошибок. Требования спецификации накладывают ограничения на размер файла шелл-скрипта в 70-140 строк кода, а наибольшей функции в 10-20 строк.
Генераторы задач упоминавшиеся ранее это модули написанные на языке программирования Limbo. Их длина варьируется от 200 до 700 строк кода, и им необходимы сведения об интерфейсе с планировщиком. На практике, когда мы определили генераторы общего назначения которые вызывали шелл-скрипты или выполняли наши заметки в описании задания, и это не похоже на все ранее написанное, однако интерфейс позволяет этого добиться.
Описание задачи[]
Один из генераторов выполняет простой способ составления описания задачи. Он точно определяет задачу и ее компоненты декларативно, в терминах файла и значений ему переданных. Для избежания путаницы с синтаксисом, мы воспользовались S-выражениями. Например, следующая тривиальная задача подсчитывает MD5 хэш каждой строки в файле myfile, при помощи отдельного задания для каждой строки:
(job (file (path myfile) (split lines)) (task exec md5sum))
Маленький декларативный язык позволяет описывать набор задач как гибридный продукт постоянных параметров и входных файлов и каталогов, и имеет директивы для управления поведением вывода. Опционально, могут указываться шелл-функции для вызова на разных стадиях исполнения задания или задачи.
Родственные работы[]
Компания Newcastle Connection[14] собрала большое количество отдельных UNIX-систем и заставила их действовать как единую систему (и это в 1981!) путем распределения системных вызовов UNIX (изменив ядро и библиотеки).
Систему было просто понять и использовать благодаря существующим скоглашениям наименований в UNIX, а также сходству интерфейсов, представляемых командным интерпретатором и ОС с локальной системой, которые предоставляли доступ к расширяющемуся ряду систем и устройств в сети (в их документе упомянута более ранние системы, которые также расширеля UNIX разными путями чтобы создать распределенные системы из более мелких компонентов). Однако, процесс развертывания и использования их системы был осложнен ограничениями, заложенными в дизайн UNIX в 1970-х, в особенности тем, что управление устройствами и идентификация пользователей были предназначены для включенной саму в себя системы, и возможно более значительно тем, что сервисы, предоставляемые не ядром не имели общего представления и не были распределны по подключениям. Plan 9 from Bell Labs[15] в противоположность был изначально спроектирован для распредленных вычислений и брал фундаментально отличающийся подход для решения проблем UNIX: в частности, он представляет все ресурсы универсульным способом, не обращая внимания на источник, и может использовать единый механизм для распредления всего. С помощью виртуализации Plan 9, Inferno распространяет эти достоинства на гетерогенные сети. Однако, лежащий в основе протокол может быть использован независимо.
Minnich[16] разработал эспериментальную систему xcpu для построения кластеров из компьютерных узлов используя модуль Linux-ядра v9fs. Как принято в 9P2000 или Styx, низкоуровнеый интерфейс к системе представляет собой иерархию имен, представляющих узлы и процессы на наборе гетерогенных cpu-серверов. Вместо отдачи задачи планировщику (scheduler), как это делается в системах пакетного стиля старого типа, xcpu создает модель интерактивной системы с разделением времени. Пользователь запрашивает набор узлов определенного типа (например, вычисления или ввод-вывод) и импортирует пространство имен каждого из них, которое затем подключает к своему локальному пространству имен Linux. Файлы пространства имен каждого узла представляют атрибуты узла (такие как архитектура и способности), программу, готовую к запуску и ее стандартный ввод и вывод. Пользователь может использовать любую смесь обычных системных вызовов Linux, команды и скрипты для прямого взаимодействия с любым из этих узлов, видя результаты по мере их появления. Например, с помощью команд шелла можно подключить группу узлов для запуска MPI-приложения, скопировать программу на все узлы одновременно, а затем запустить ее. И все это с помощью всего нескольких строк:
for i in $NODES; do cp my-mpiapp-binary /mnt/9/$i/exec & done wait # for all copies to finish for i in $NODES; do echo mpiapp $i $NODES >/mnt/9/$i/argv && echo exec >/mnt/9/$i/ctl done
Сборка вывода, обнаружение ошибок и умение пользоваться командным языком и командами хорошо знакомо пользователям, не работающим с Grid-технологиями. Minnich замечает, что более высокоуровневые интерфейсы возможны и часто желательны; отмечая, однако, что это низкоуровневый интерфейс, и он может быть использован напрямую без предварительной подготовки.
Legion[17] used a virtual operating system model to build a distributed object system, specifically for grid applications. The naming hierarchy locates objects, which have object-specific operations, and objects communicate (below the name space) using messages carrying method call parameters and results. The system provides support for object persistence, fault-tolerance, scheduling, and more, but the programming and user interface is unique to it, and non-trivial. Grimshaw et. al18 compare Legion and Globus GT2 at many levels, including design principles, architecture, and the implications of the passive object model then used by Globus to Legion’s active object model. Differences are, indeed, legion. Most important here, though, is the observation that ‘‘it was very difficult [with Legion] to deliver only pieces of a grid solution to the [grid] community, so we could not provide immediate usefulness without the entire product’’ but Globus (by providing short-term solutions to key problems) ‘‘provided immediate usefulness to the grid community’’. Architecturally, they contrast a bottom-up approach used by Globus to the top-down design of Legion. They describe the then emerging Open Grid Services Architecture as a collection of ‘‘specialized service standards that, together, will realize a metaoperating system environment’’, similar in aim therefore to Legion, with a different RPC mechanism based on SOAP, WSDL, etc. Given the relative complexity of Legion itself, though, and the authors’ admission that it was most useful as an ‘entire product’, that could be double-edged.
There are several commercial suppliers of grids, sometimes offshoots of university experience.17, 19 Hume describes specialised software for fault-tolerant data processing clusters,20, 21 processing huge telephony billing data sets to deadlines. Google has produced grid systems that are impressive in scale and resiliency,22 based on a general underlying storage subsystem,23 with a specialised high-level language to ease programming.24 These developers have enthusiastic end-users, and argue that their systems (particularly Google’s) are objectively easier to use and more productive than ones they replaced, based on metrics such as size and complexity of programs, and comparative system performance.
Discussion[]
Beckles25 lists some properties by which ‘usable’ grid software might be assessed: ‘‘engagement with the intended user community; APIs and other programmatic interfaces; user interfaces; security; documentation; and deployment issues’’.
Our Owen computational grid software was developed in close consultation with its initial users, but has subsequently been provided to other customers. They have similar application profiles to the original users; all of them continue to do useful work with it. Some are contented users of newer facilities such as its job specification notation. We have also made the software available to a few universities and research organisations. Results there are mixed, limited mainly by documentation. If they wish to use it as originally designed, it works well. Others quite reasonably need much more flexibility, and although that is often supported by the underlying software, the extra documentation to allow them to use it easily is not yet available.
At a lower level, however, our systems are undoubtedly distinctive in having clients access and control the grid using file-oriented operations. Consequently, the specification of the programming interface ߞ such as the manual page for the scheduler ߞ defines the hierarchy of names it serves, and the contents of the files therein, including a list of control files, the textual messages that can be written to them, and their effect. What are the advantages of this representation? It is directly accessible through any programming language in which there are constructions (or libraries) providing explicit file access with open, read and write. Even better, in some environments it can be accessed directly by existing commands. As discussed above, a small file of shell functions allow grid jobs to be created and controlled from the Inferno command line as discussed above. That is currently of little interest to many end-users, who largely wish the whole process to be invisible: to have the computational distribution happen without their explicit intervention. Some, however, such as those who already write their own Perl scripts, are able, with only a little training, to provide their own interfaces to the grid. Beckles argues for APIs that support ‘progressive disclosure’ of functionality, and we find the underlying file-based metaphor well supports that. The demonstrator grid mentioned above showed that the metaphor can be applied to a respectable range of resource types; there are many other examples to show it is not limiting.26, 3, 5
Another possible difference compared to a Globus27 or Web Services28 interface is that instead of learning both protocol and mechanism, with the file-oriented interface, such users must learn only the names and the protocol: the file-access mechanism is almost always quite familiar to them, and they can carry across their intuitions about it. As it happens, the protocol for the use of a given name space is also usually simpler and more straightforward to use than languagespecific APIs full of complex data structures or objects. Indeed, the implementation of file servers has not been discussed here, but it is notable that although the Styx protocol has messages of a specific structure, there are only 13 operations, most of them obvious (eg, open, close, read, write) with obvious parameters, and every file server implements the same operations. Compared (say) to plug-ins to a web server, there are neither programming interfaces nor data structures imposed on the servers by their surroundings; they can manage their own internals as they like, as self-contained programs. For instance, some are concurrent programs, but many are simple programs that run in a single process. Within Inferno, there is a system primitive file2chan that makes it easy to write applications that serve only a handful of names. Lacking (and a serious omission) are good tutorials on writing ‘full’ file servers from scratch.
For wide-scale release, it is easy to underestimate the effort required to document both infrastructure and applications, especially to suit a range of end-users (ie, scientists and programmers). In 1999-2000, for the first public release of Inferno itself, a team of five spent many months preparing its documentation and assembling the distribution (and Inferno is not a huge system). That documentation was intended for programmers (perhaps even system programmers). It can be harder still to prepare things for end users, even when the applications have been kept simple. We do not yet consider our grid documentation to be up to our standards.
We originally distributed the client software from a CD using the same mechanism as Inferno, but that was clumsy. The grid client software is now typically installed simply by copying a small hierarchy (a few megabytes), for instance from a USB memory stick or a shared file store.
Conclusions[]
Supposing that within the constraints of our time and treasure, we have indeed managed to build grids that customers found usable, and with underlying technology and interfaces that we consider usable, are there any general lessons? They are mainly traditional ones. As implied in the company history in the Introduction, we have successfully applied them in the past, outside Inferno.
We had a clear and indeed limited design (‘‘do one thing well’’). Rather than provide an abstract interface to a big family of possibilities, as is done by some of the Web Service specifications, we decided on one that was ‘fit for purpose’. We used mature technology with which we had much design and implementation experience; its definition is compact and stable. The system should help separate concerns and provide a focus for the design. In our case, system-level mechanisms do distribution and station-to-station authentication. The name space provides the focus of discussion during initial design meetings, and its description acts as a high-level contract between components. Minimisation of mechanism is a good engineering principle; we were working with an infrastructure that provides a narrow interface. On the other hand, if the system-provided mechanisms are too primitive (‘‘message passing’’ or ‘‘remote procedure call’’) then there is little structural support for application development, no common currency, and little chance of either users or programmers being able to re-use knowledge. Using simple metaphors that make sense to them must surely help, especially if the just one can be used throughout.
Most important, as Beckles suggests,25 interaction with end users is essential. Our various projects have been successful, and the resulting new systems worked well for their users, partly because the underlying technology worked well and was easy to use, but also because we dealt with them as normal commercial projects, working closely with customers to provide something that suited them. As important as that interaction is an imposed discipline. We have fortunately been able to deal directly with end users who really must get their work done; the amazing politics now associated with the e-science grid world is irrelevant to them and to us. Furthermore, commercial requirementsߞcertainly for a small companyߞmean that the result must meet deadlines, satisfy customer expectations, and keep to budget. We find this helps to focus mind and energy wonderfully.
Acknowledgements[]
Roger Peppé and Chris Locke designed and implemented the labour exchange; Peppé subsequently added the job description language and other improvements, and wrote the documentation. Danny Byrne wrote the graphical interface applications.
References[]
1. Sean Dorward, Rob Pike, David L Presotto, Dennis M Ritchie, Howard Trickey, Phil Winterbottom, ‘‘The Inferno Operating System,’’ Bell Labs Technical Journal 2(1), pp. 5-18 (Winter 1997). Inferno Programmer’s Manual, Third Edition, Vita Nuova Limited (2000). Rob Pike, Dave Presotto, Ken Thompson, Howard Trickey, Phil Winterbottom, ‘‘The Use of Name Spaces in Plan 9,’’ Proceedings of the 5th ACM SIGOPS European Workshop, Mont Saint-Michel (1992). Rob Pike, Dennis M Ritchie, ‘‘The Styx Architecture for Distributed Systems,’’ Bell Labs Technical Journal 4(2), pp. 146-152 (April-June 1999). C H Forsyth, ‘‘The Ubiquitous File Server in Plan 9,’’ Proceedings of the Libre Software Meeting, Dijon, France, Vita Nuova Limited (5-9 July 2005). Chris Locke, Styx-on-a-Brick, Vita Nuova Limited, York, England (June 2000). Sameer Tilak, Bhanu Pisupati, Kenneth Chiu, Geoffrey Brown, Nael Abu-Ghazaleh, ‘‘A File System Abstraction for Sense and Respond Systems,’’ Workshop on End-to-End, Sense-andRespond Systems, Applications and Services, Seattle WA, pp. 1-6 (June 2005). Jon Blower, Keith Haines, Ed Llewellin, Data streaming, workflow and firewall-friendly Grid Services with Styx, e-Science Centre, University of Reading (2005). Eric Van Hensbergen, Ron Minnich, ‘‘Grave Robbers from Outer Space: Using 9P2000 Under Linux,’’ Proceedings of the USENIX 2005 Annual Technical Conference, FREENIX Track, Anaheim, CA, pp. 83-94 (April 2005). M Litzkow, M Livny, M W Mutka, ‘‘Condor - a Hunter of Idle Workstations,’’ Proceedings of the 8th International Conference of Distributed Computing Systems, pp. 104-111 (June 1988). Michael Jeffrey, Inferno Grid Applications, Vita Nuova Limited, York, England (June 2003). Brian Hancock, ‘‘A Brief Introduction to the Humanities Grid,’’ Library Hi Tech News, New Brunswick, New Jersey(8), pp. 32-33, Rutgers University Libraries (2004).