9grid = Plan 9^grid

Андрей Кухар, "Комиздат"

Поведай правду обо мне неутоленным…
В. Шекспир

Глаголить о grid считается признаком хорошего тона, модной фрондой - но, в то же время, разговор о Plan 9 представляется, извините, совершенно ненужным козе баяном…

Отдавая дань инфраструктуре grid computing, экстенсивно движущейся к достижению критической массы, и факту предпочтения распределенной операционной системы от Bell Labs, в нынешней публикации обследованию будут подданы, во-первых, характерные, отличительные свойства Plan 9, которые представляют основу для создания масштабируемых и безопасных интегрированных grid computing сред (grids), и, во-вторых, собственно 9grid - проект сотрудничества между географически разрозненной группой энтузиастов Plan 9.

Grid computing: вводная часть и мотивировка

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

Имя инфраструктуры (поскольку grid охватывает самые разнообразные ресурсы, от вычислительных циклов, данных, датчиков, et cetera… до людей :-)), по словам ее авторов Яна Фостера (Ian Foster) и Карла Кессельмана (Carl Kesselman), сродни термину "электросеть", которая в начале XX века обеспечила повсеместный доступ к источникам электроэнергии и аналогично компьютерам оказала сильное влияние на человеческое общество.

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

Сравнительно молодая, однако семимильными шагами развивающаяся область computer science, grid computing выступает за эксплуатацию разрозненных ресурсов для решения проблем, требующих технологий определенного уровня, не всегда доступного одному предприятию. Большинство ученых считает, что следующий эволюционных шаг к высокопроизводительным вычислениям будет зиждиться на отказе от всеохватывающего суперкомпьютера и переходе на массивы из небольших гетерогенных кластеров, наподобие машин класса Beowulf.

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

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

Grid-приложения увеличивают возможности операционной системы, независимо от ее конструкции "as is", и переносят ее в распределенную среду, в которой место порождения приложения отлично от места размещения (точнее размещений), где выполняются его вычисления. Были разработаны middleware toolkits (стандарт де-факто - Globus), действующие как клей для различных, иногда даже взаимоисключающих расположений в grid. Они-то и создают большую систему для научных целей (не осуществляемых на кластерном уровне) и способствуют развитию виртуальных организаций.

Итак, замысел величествен. Попробуем осмыслить под определенным углом зрения Plan 9 - интегрированный метод для grid computing.

Plan 9 от Bell Labs как Grid ОС

Plan 9 - это попытка устранения фундаментальных недостатков конструкции Unix, главный из которых - врожденное отсутствие сетевых и графических возможностей. И те и другие были добавлены еще в период расцвета Unix, но каждый новый уровень, прокладывающий дорогу к новому оборудованию, способствовал усложнению системы в целом из-за связанных с ним гомерических объемов кода, а также постоянному изменению требований к интерфейсу. Кроме разрешения проблем своей предшественницы, Plan 9 обрела иммунитет к быстро (чрезвычайно быстро) развивающемуся рынку дешевого аппаратного обеспечения посредством ориентации на среду из персональных рабочих станций вместо централизованных мэйнфреймов, работающих в режиме разделения времени.

Простота (как известно, присущая гениальности), с которой конструкционные решения для новых моделей вычислений были приспособлены к широко адаптированным и принятым парадигмам Unix, считается главной чертой Plan 9.

Основные принципы философии Plan 9 таковы:

• Все ресурсы представлены как файлы и каталоги (которые, кстати сказать, также являются подмножеством файлов), заключенные в глобальной файловой системе под названием пространство имен. Впрочем, сия концепция не означает буквальное "все - файл", на самом деле в контрасте с Linux, где для поддержки многочисленных типов ресурсов насчитывается целый сонм (около трехсот) системных вызовов. У Plan 9 их всего сорок плюс однородный метод перечисления и управления ресурсами. Последние соответствуют модели файл/каталог для приложений и пользователей.
• Устройства подвластны простому и последовательному интерфейсу. За каждое устройство (или файловую систему, что, впрочем, одно и то же) отвечают, как минимум, два файла: ctl - для управляющих сообщений, data - для данных. Операции по управлению устройством выполняются при помощи записи текстовых строк в файл ctl - прочитав его, можно получить статус устройства. И, наконец, любые данные, которые необходимо направить устройству или получить из него, считываются или записываются в data.
• Файлоподобный интерфейс распространяется на все системные ресурсы и универсально применяется во всей среде; благодаря протоколу 9P он также прозрачно действует через сеть - к примеру, устройство (как то: сетевой интерфейс на удаленной машине) может импортироваться и работать, будто оно физически расположено на локальной машине. Как следствие, локальные и удаленные ресурсы - функционально эквивалентны.
• Разного рода сервисы, предоставляемые операционной системой, объединяются в единое пространство имен, частное для процесса, который инициировал его построение; порожденные процессы, независимо от того, запущены они на той же машине или нет, могут получать данное пространство без модификаций.
• Plan 9 выделяет CPU-серверы, файловые серверы и терминалы, работающие на разных аппаратных средствах. Возможна (и рекомендуема) оптимизация последних для конкретных функций - например, не выглядит необычным использование мультипроцессоров в роли CPU-серверов или RAID-контроллеров - как систем хранения данных. Это способствует существенному снижению затрат на АО и его поддержку, ибо происходит концентрация дорогостоящего оборудования в серверной комнате, в то время как пользователи выполняют свою работу на недорогих терминалах. Протоколы, используемые для доступа к файловым серверам, обладают достаточной степенью защищенности, так что необходимости в скрытии серверов за межсетевыми экранами нет.
• Портабельность. Для целей импорта/экспорта ПО разработана среда APE (ANSI/POSIX Environment). Большинство приложений Unix, не использующих графику, могут легко компилироваться для работы в Plan 9. Чаще всего, для того чтобы переписать приложение для компиляции в родной среде системы, требуется всего лишь избавиться от больших кодовых частей, обеспечивающих совместимость между вариациями Unix.

Резюмируя, к характеристикам уникальной конструкции Plan 9 можно отнести: глобальную файловую систему, прозрачно доступную через сеть, функцию импорта удаленных ресурсов (процессов, сетевых интерфейсов, накопителей на жестких дисках, областей подкачки и т.д.) в локальное пространство имен и портабельность. Совмещенные, они представляют убедительный довод в пользу использования Plan 9 в grid computing.

Аутентификация

Аутентификационные механизмы в grid имеют отношение к возможности системы управления окружением осуществлять проверку личности абонентов, развертывание и хранение безопасной информации. Аутентификацию в распределенной среде Plan 9 выполняют выделенные аутентификационные (auth) серверы. Аутентификация совершенно отделена от ПО, сервисов или архитектуры, лежащих в основе среды, в которой аутентификация производится. Комплекс для обеспечения безопасности сетевого доступа состоит из двух дополняющих друг друга программ: это хранилище персональной информации secure store и агент аутентификации factotum.

Только factotum понимает все аутентификационные протоколы, ключи безопасности и механизмы их развертывания. Этот агент хранит аутентификационные ключи для приложений, совместно с которыми он использует среду. Он осуществляет аутентификацию и как клиент, и как сервер; способен к принятию обеих сторон диалога проверки личности в ходе одной сессии. Factotum не взаимодействует с внешними программами непосредственно - вместо этого он обращается к локальным данным, разделяя свое пространство имен, когда необходима аутентификация. После принятия запроса на установление доверительных отношений, клиент начинает действовать как proxy - реализуя передачу сообщений связи между factotums клиента и сервера, пока не произойдет взаимная аутентификация. Кроме того, factotum выполняет двойную работу, выступая агентом одноразового предъявления пароля со способностью к запоминанию текущих активных аутентификационных признаков для частного пространства имен, им обслуживаемого. Он хранит введенную пользователем информацию, вроде паролей VNC или SSH, и вместо ее запроса всякий раз, когда требуется аутентификация, довольствуется теми данными, которые у него уже имеются. По сути, получается среда, где пароли не вводятся более одного раза и, как только прошло удостоверение личности, удаленные серверы запоминают владельца задания, без влияния на целостность основных протоколов и риска для безопасности.

Защите безопасности обслуживаемого эккаунта способствует - извините за невольную тавтологию - хранение всех ключей безопасности в защищенных областях основной памяти, предотвращающих своппинг и отладку. Для инициализации состояния агента пользователь должен либо предоставить пароли, когда они будут запрошены, либо вызвать factotum во время начальной загрузки системы и прочитать ключи из зашифрованного хранилища данных secstore, где доступ поддерживается аутентификационным механизмом, отделенным от системы.

Используемые в Plan 9 протоколы безопасности включают сертификаты X.509, RSA-ключи для работы с SSH, DES (протокол вызова-ответа) и текстовые парольные схемы для таких сервисов, как Telnet, FTP и VNC.

Теперь надлежит проанализировать аутентификацию Plan 9, расширенную для grid. Распространение распределенных и grid-like сред, каждая из которых имеет многочисленные расположения и аутентификационные домены, требует переоценки используемых механизмов аутентификации, которые обычно основаны на имени и уникальном номере, определяющих конкретного абонента системы. Plan 9 избегает этой проблемы, не используя числовые пользовательские идентификаторы; тем не менее, одного имени, ассоциированного с процессом на любой ОС, в распределенной среде более не достаточно для представления всей необходимой информации о пользователе.

Grid toolkits, включая Globus, используют схему создания глобального пространства имен, где всю необходимую информацию о пользователе несет аутентификационная информация. Локальные grid-узлы выбирают собственное отображение глобального пользовательского ID в локальный, где конкретный набор и соглашение об наименовании для клиентов Globus создается заблаговременно. Конверсия между глобальными и локальными пользователями выполняется прозрачно при помощи специальных утилит (например, GridFTP). Все ПО, которое зависит от такой конверсии, должно быть модифицировано для ликвидации препятствий процессу grid-приспособления наследственных приложений.

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

Данная концепция позволяет пользователям выбирать желаемые имена, предоставляет возможность избежать перекрытий с процессами локальных пользователей и предлагает администраторам легкий способ идентификации местонахождения конкретного пользовательского процесса. Аутентификационный сервер, к которому обращается пользователь, функционирует как глобальный auth-агент для этих процессов, аутентифицируя их в любой точке grid. Благодаря проведению всех связанных с администрированием заданий ближе к порожденному расположению, взамен уполномочивания их централизованному административному объекту, упрощается администрирование в целом.

Безопасность

В контексте grid computing безопасная среда способна к:

• защите связи между заданиями от сторонних наблюдателей;
• защите заданий от неблагоприятного влияния действий прочих заданий;
• защите заданий от зависания ресурсов (предохранение от DoS-атак или незаконного использования ресурсов другими пользователями).

Как ОС, Plan 9 не полагается на чужие добавления по управлению связями с АО или между узлами. Она была разработана для осуществления строгой политики безопасности, которой должны придерживаться все программы.

Бесспорно, ключевыми элементами инфраструктуры безопасности в Plan 9 являются:

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

Ядро поручает значительную часть решений инфраструктуры безопасности драйверам межпроцессовой связи: вызовам mount и bind, а также 9P - протоколу файловой системы, отвечающему за доступ к информации во всей системе. Задание grid не должно заботиться об основной инфраструктуре безопасности до тех пор, пока оно может гарантировать со своей стороны, что безопасности его factotum ничего не грозит. Но для успеха этой схемы требуется, возможно, самая важная характеристика безопасности Plan 9 - концепция частных, процессовых пространств имен, основа каждого аспекта распределенной системы.

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

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

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

Обнаружение ресурсов

Функции обнаружения ресурсов предназначены для того, чтобы позволить пользователям выполнять запросы о присутствии и характеристиках сервисов, доступных в конкретной сети. В grid наличествует два способа обнаружения ресурсов: первый - создание средств, пригодных для эксплуатации только в новой распределенной среде, и второй - адаптация утилит операционной системы схожего предназначения для сетевого метода работы.

Такого рода сервисы включались в Plan 9 с самого ее рождения. В первую очередь это специальная программа srv - фильтр передачи сообщений между двумя пространствами имен. Процесс, которому необходимо разделить свое пространство имен с другими, с помощью утилиты srv публикует файловый дескриптор, который указывает на корень пространства, в специализированном месте - каталоге /srv. Задания затем монтируют требуемую иерархию файлового сервера из /srv, если, конечно, у них есть на то разрешения.

Расширение этой схемы для grid можно совершить посредством иерархии файлового сервера, используемого вместо каталога типа /srv. Первый уровень этой иерархии содержит подкаталог для каждого расположения, входящего в сеть и функционирующего в текущий момент. Узлы регистрируют свою готовность к участию, публикуя файловые дескрипторы, которые указывают на их собственные /srv.

Локально каждое расположение обслуживает /srv там, где узлы опубликовали файловые дескрипторы, анонсирующие их готовность к участию. В листовом каталоге находится описание состояния конкретного узла. Не листовой /srv не содержит информации о фактических ресурсах, которые к нему приписаны, а служит связью между именем расположения и файловым дескриптором, указывающим на корень /srv этого расположения. Опрос ресурсов допускается только со стороны клиента.

Используя описанную схему, можно получить любую информацию обо всей grid без необходимости обращения к чему-либо отличному от стандартных ls, cd, cat и т.п., уже знакомых пользователям системы. К примеру, чтобы вывести список названий и IP-адресов всех активных в grid узлов, клиенту достаточно импортировать /srv из главного репозитория и дать команду:

cat /srv/*/*/name

Другой пример - chat-сервер (первое Plan 9 grid приложение):

% import plan9 /srv /srv
% mount /srv/consoles /mnt/consoles/
% con -l /mnt/consoles/irc
[+user1]
this is a test
[user1] this is a test
[+user2, user1]
[user2] hello user1!
[-user2, user1]

Действия: "постинг" fid в grid, монтирование дескриптора, где он виден остальным, использование con (hacked-версия consolefs) для подключения к каналу, далее - мультиплексирование введенного текста всем подключенным абонентам.

Ну, чем вам не IRC?

Управление данными

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

В Plan 9 единицей связи выступает поток данных файловых операций. Протокол 9P, доставляющий каждую транзакцию, универсален. Каждая удаленная операция совершается подмонтированным, или импортированным, пространством имен. В результате легко расширить набор операций, выполняемых над пространством имен, для включения новых идей вроде сжатых, шифрованных или параллелизованных передач данных (это делает программа import) или даже отказоустойчивых и кэшируемых сетевых соединений (а это достигается наложением фильтра aan - always available network).

Репликация осуществляется с помощью сервиса replica, который доступен как часть операционной системы. Он обычно содержит основное хранилище, в которое помещаются дополнения и модификации файлов в схожем с CVS стиле и откуда клиенты могут выборочно скачивать (копировать) необходимые им файлы или более новые версии, чем их локальные копии. Plan 9 replica не требует, чтобы все файлы индивидуального хранилища были локальны для системы, предлагая построение иерархической структуры реплик, где replica-запросы передаются основному хранилищу. Кроме того, есть возможность делать replica-запросы без принятия каких-либо изменений или обследовать его журнальный файл для истории конкретного набора данных. В связке с бесконечной историей и back-log свойством сервера постоянного хранения информации Venti можно получить любую версию любого файла, когда-либо сохраненного в replica.

Планирование ресурсов

Управление доступом к ресурсам и их планирование - важнейшая часть администрирования в grid-среде. Системе Plan 9 не важно, где (в каком окружении) инициировано задание. Типы архитектур прозрачно абстрагируются посредством программирования и исполняемых библиотек. Среда и программы, запущенные в ней, портабельны для архитектурных платформ. Простота, с которой процессы могут перенести удаленные ресурсы в свое пространство имен и объединить их для построения полностью независимых от размещения сред, значительно упрощает задачу планировщика Plan 9. Планирование здесь представляется дуальной проблемой: решение о том, какое задание будет выполняться на конкретной машине или кластере, и о том, какое расположение принимает обязательства за задания на уровне grid (известное еще как "метапланирование").

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

Из-за того что импортирование и использование планировщика нисколько не отличается от импортирования любого другого сервиса grid, он подлежит тем же аутентификационным и безопасным ограничениям, что и вся среда (то есть расположения решают, кто может использовать их планировщики). Такая схема расширяема и гибка благодаря модели безопасности планировщика с присущей ей независимостью от общей системной архитекутуры.

Решения метапланирования не должны приниматься специализированным агентом (агентами), даже если его (их) присутствие в Plan 9 и возможно. К настоящему времени grid-задания импортируют набор доступных планировщиков, которые могут быть найдены при помощи механизма обнаружения ресурсов,- и выбирают тот, характеристики которого лучше прочих подходят для данного случая.

"Брошенный вперед"

9grid projectus был "брошен" в августе 2003 года Роном Майнничем (Ron Minnich), Андреем Мирчовски (Andrey Mirtchovski), Колином Интайкоттом (Colin Enticott), которым, так же как и идеологам grid, харизмы не занимать.

Что отличает 9grid от прочих проектов, так это, первым делом, концепция "simple is better", новаторский подход к использованию инфраструктуры grid и распределенных вычислений, а также отказ от тридцатилетнего наследия Unix-среды.

9grid является доказательством того, что grids могут создаваться и поддерживаться без приложения серьезных усилий, это новая страница в распределенных вычислениях, где стирается грань между локальными и удаленным вычислениями.

К числу главных участников "9grid-забав" причисляют:

• Cluster Research Group при Лос-аламосской национальной лаборатории (Лос-Аламос, штат Нью-Мексико);
• Lucent Technologies, Bell Labs (Мюррей Хилл, штат Нью-Джерси);
• университет Калгари (Калгари, Канада);
• Монашский университет (Мельбурн, Австралия);
• индивидуалов (к сожалению, пока немногочисленных), выделяющих проекту CPU-серверы.

К примеру, Bell Labs предоставила 14 машин (a b c d e f g h i j k l m n).grid.bell-labs.com в качестве ресурсов для 9grid. Это 500 МГц Celeron'ы c 64 Мб основной памяти.

a.grid.bell-labs.com - secstore, auth и файловый сервер для CPU-серверов b…n. a запускает отдельный auth-домен и два файловых сервера fossil, этот узел находится в домене cs.bell-labs.com, использующемся большинством систем в Bell Labs. Этим достигается простота администрирования и поддержки. Первый fossil - не экспортируемый, с него запускается машина a; второй экспортируется и используется остальными 9grid-машинами, у него свой factotum, который находится в аутентификационном домене grid.bell-labs.com.

The 9End: вывод результатов

На сей час это почти все, что хотелось собрать, проанализировать, перевести, написать - осталось вывести измышления "из вышесказанного следует".

ОС Plan 9 - не замена и, тем более, не угроза (по крайней мере, она не должна так рассматриваться) для Globus или любого иного уже адаптированного grid toolkit. Напротив, резонным выглядят эксплуатация ее в родной среде и принятие ее же конструкционных решений при создании grids будущего. Ведь разве не великолепны среды, объединенные вместе с помощью унифицированного легкого протокола вроде 9P? А как насчет удивительного упрощения разработки grid-сервисов - ведь это всего-навсего экспорт пространства имен, в котором они доступны?