OceanStore: «первичный суп» нового тысячелетия

6 март, 2001 - 11:45Сергей Митилино

Миллионы лет тому назад воды мирового океана стали колыбелью жизни на Земле, а спустя весьма продолжительный период времени здесь суждено было появиться разумному человеку. Исследователи Берклеевского университета решили создать свой рукотворный «информационный океан», который в будущем, возможно, послужит «питательной средой» для первых цифровых форм жизни. Итак, каковы же ключевые концепции этого уникального проекта, получившего название, ни много ни мало, OceanStore?

МОТИВЫ

Прежде чем углубиться в теорию, следует упомянуть основные цели, преследуемые создателями OceanStore. Поклонники новомодного течения «ubiquitous computing», они решили подготовить идеальную самоорганизующуюся среду, в которой смогли бы «сосуществовать» самые разнообразные информационные устройства, начиная от десктопов и заканчивая интеллектуальными кофеварками. Поскольку все эти приборы не вечны и подвержены износу, предполагается, что в будущем человек не будет церемониться со своими «помощниками». После покупки очередной «обновки» ее предшественника безжалостно отправят на свалку подобно любой другой бытовой технике. Здесь возникает проблема сохранения накопленных за время эксплуатации данных, а также резервного копирования на случай утраты или разрушения устройства, обновления ПО и т. д. Если заставить человека делать все это вручную, то он станет рабом своей техники. А учитывая современные тенденции, это еще и выглядеть будет довольно глупо: «Минутку, дети, прежде чем идти играть, не забудьте сделать резервную копию файлов из ваших кроссовок (киберсобачки, тамагочи, КПК) на дискету». Отсюда следует простое правило — информация должна храниться отдельно от устройств. Развитие беспроводных средств коммуникации поможет каждой микросхеме, будь она вмонтирована в ваши наручные часы или свитер, автомобиль или мотоцикл, загрузить данные из сети. Кроме того, ученые решили наделить файлы максимальной мобильностью, так что вы сможете получить к ним доступ с помощью соответствующего интеллектуального прибора в любой точке мира. Они обещают абсолютную конфиденциальность и высочайшую степень надежности, которую не сможет обеспечить даже жесткий диск ПК, запертый в офисном сейфе. Как это ни удивительно, но в качестве базовой инфраструктуры предполагается использовать любые доступные системе сетевые узлы вне зависимости от их производительности, конфигурации и мощности канала связи. При этом владелец узла не связывается какими-либо обязательствами. Такова специфика OceanStore: высокая надежность достигается за счет большого количества образующих сеть узлов, а не высокого уровня стабильности отдельных компонентов.

OceanStore: «первичный суп» нового тысячелетия

Впрочем, существует ряд допущений. Например, авторы проекта полагают, что ядро системы будет размещено на серверах «ответственных» коммерческих провайдеров, а каналы связи будут иметь достаточную пропускную способность и стабильность большую часть времени. Тем не менее они утверждают: «Система тиражирует данные для сохранности и доступности. Механизмы глубокого архивирования позволят информации выжить даже во время глобальной катастрофы». Согласно плану, услуги OceanStore будет предоставлять сообщество коммерческих компаний, владеющих мощными сетевыми инфраструктурами, за определенную месячную плату.

АРХИТЕКТУРА

Главную роль в архитектуре «цифрового первичного супа» играют универсальные идентификаторы GUID (Globally Unique IDentifier). Они используются для именования и поиска объектов, также эти метки принимают непосредственное участие в процессе маршрутизации внутри системы. GUID объекта представляет собой хэш его названия на естественном языке с секретным кодом владельца. Таким образом, удается однозначно определять подлинного владельца идентификатора, исключая возможность его незаконного присваивания. Любой элемент системы может иметь собственный идентификатор, например GUID сервера является хэшем его публичного ключа. Шифрованием защищены не только имена, но и объекты — пользовательские данные. Кодирование выполняется исключительно клиентскими приложениями, и система не должна иметь доступа к раскодированной информации. Это делает принципиально невозможным несанкционированное чтение. Операции записи контролируются с помощью списков ACL (Access Control List), описывающих права доступа и соответствующую им цифровую подпись. Серверы перед внесением изменений должны проверять адекватность подписи автора. Честно говоря, здесь возникают некоторые сомнения относительно надежности такого подхода, поскольку свободный доступ к ACL не скажется на безопасности только в том случае, если подделать цифровую подпись невозможно.

Теперь к вопросу маршрутизации. В свете того, что создатели OceanStore проповедуют концепцию «мигрирующих данных» (nomadic data), задача определения местоположения объекта отнюдь не тривиальна. К тому же объекты имеют свои копии (replica), которые постоянно перемещаются по сети. В принципе, с увеличением числа копий повышается как надежность хранения (в описании приводится такой пример: в сети из 10 млн. узлов, из которых 10% всегда находятся в нерабочем состоянии, надежность достигает 99%), так и скорость доступа. Однако последнее справедливо только в том случае, если пользователь всегда будет взаимодействовать с ближайшей репликой данных.

Для маршрутизации используется две методики. Сначала система пытается сориентироваться с помощью модифицированных фильтров Блума (attenuated Bloom filters). На каждом узле вычисляется и хранится настроенный фильтр глубины D, который представляет собой массив фильтров с D-элементами. Каждый i-й элемент массива есть объединение всех фильтров Блума, вычисленных на узлах, находящихся на расстоянии i. В настоящий момент в качестве единицы измерения расстояний применяются так называемые «хопы», т. е. количество ретрансляций сетевого пакета. 0-й элемент массива перечисляет все объекты, находящиеся на узле. Когда выполняется поиск объекта, алгоритм маршрутизации использует эти фильтры, чтобы определить, расположены ли искомые данные на текущем узле, а если нет, то в каком направлении надо продолжать движение. Такой итеративный процесс принято называть «подъемом на холм» (hill-climbing).

Другой способ маршрутизации основывается на иерархических структурах данных Плакстона (Plaxton). В самом простом случае схема выглядит следующим образом: все узлы пронумерованы, а каждая связь между ближайшими, с точки зрения сети, узлами маркируется числом, отдельные цифры которого точно соответствуют цифрам из номеров, расположенных в этом направлении серверов. Например, связь 1234 может указывать на сервер 0004, что в свою очередь соединен с серверами 0234, 1304 и 5554. Чтобы метод сработал, система всегда размещает копию объекта на сервере с идентификатором, максимальным образом совпадающим с GUID объекта, начиная с младших битов. Когда делается очередная копия объекта, указатель на нее отправляется сервером, на котором она находится, в направлении этого корневого узла. По «пути следования» указатель отмечается на всех промежуточных серверах. Так что при пользовательском запросе системе не обязательно искать корневой узел, достаточно в процессе поиска обнаружить такой указатель.

Необходимость предоставить пользователю системы гибкие возможности обновления данных ставит целый ряд вопросов. Во-первых, каким образом сервер должен манипулировать зашифрованными файлами? Тут существует два варианта: использование индексных файлов, которые описывают внутреннюю структуру данных, или присоединение к данным журналов (logs) с перечислением проведенных модификаций. В первом случае всю работу выполняют серверы, во втором — клиенты. Сами обновления состоят из списков команд вида «если — то» (сравнить версию, сравнить размер, сравнить блок и поиск).

Если заданное условное выражение истинно, то обновление выполняется, иначе — оно отвергается. Собственно обновление тоже программируется с помощью набора стандартных инструкций: заменить блок, вставить блок, удалить блок и присоединить. Конечно, чтобы реализовать эти операции, требуется использовать позиционно-зависимый блочный шифр, который позволит разделить объект на блоки и составить индекс указателей. Как вы, наверное, уже заметили, подобная схема обновления содержит серьезный изъян в плане безопасности: отслеживание характера вносимых изменений может открыть злоумышленникам нежелательные подробности вашей работы. Еще читая новеллы Эдгара По, мы осознали возможности частотного анализа. Поэтому авторы системы сочли необходимым кратко упомянуть и о варианте с «журналом». Наконец, еще более серьезная проблема заключается в необходимости разрешения конфликтов, т. е. упорядочения серии обновлений. Однозначного способа выполнения данной важнейшей операции OceanStore на текущем этапе своего развития не предлагает. В реализованном прототипе копии объектов разделены на две «касты», или два слоя: привилегированные находятся в высокопроизводительной части сети, они урегулируют возникающие неоднозначности с помощью протокола Бизантина (Byzantine agreement protocol). Прочие копии, расположенные во втором слое, получают подготовленные ими списки обновлений. Дело в том, что все известные разработчикам системы протоколы согласования чрезвычайно требовательны к производительности сети, поэтому распространить их действие на большое число копий невозможно. Вторичный слой часто содержит неточные и неполные сведения, объекты в нем организованы в так называемые «деревья распространения» (dissemination trees). Эти структуры служат проводником корректных изменений от привилегированных копий. Процесс требует времени, следовательно, нет никакой гарантии, что полученные от такого «вторичного» узла данные будут актуальны. Однако предполагается, что ряд приложений выиграет скорее от большего числа доступных копий, чем от высокой адекватности информации.

Одновременно с генерацией корректных пакетов обновлений первичный слой серверов занимается архивированием: данные кодируются с помощью алгоритмов коррекции ошибок (применяются коды Рида—Соломона и Торнадо), разделяются на фрагменты, рассылаемые на множество архивных узлов. Их целостность гарантируют хэш-деревья: для каждого фрагмента генерируется хэш, который вместе с хэшем соседнего фрагмента служит основой для вычисления хэша более высокого уровня и т. д. Промежуточные результаты сохраняются вдоль всей цепочки архивных узлов, так что любой из них может проверить работу «нижестоящих товарищей». Помимо этого, введено ранжирование серверов по степени надежности, и при архивировании это учитывается. Проблемы медленных узлов и сетевых «заторов» удается избежать, создавая и запрашивая избыточное число копий фрагментов по принципу «кто не успел, тот опоздал». Ведь «сборка» объекта может начинаться сразу по получении всех необходимых данных.

Мы плавно подошли к задаче поддержания «цифрового первичного супа» в порядке. OceanStore относится ее создателями к классу самоорганизующихся систем, поэтому все сервисные процедуры выполняются автоматически и децентрализованно. Для этого создана архитектура «самоанализа» (introspection architecture). В ее основе — события, которые фиксируют главные показатели функционирования узлов. Они хранятся в оперативной памяти серверов в виде краткосрочной истории. Обработчики событий обеспечивают своевременную реакцию системы на текущие изменения. Предусмотрен и более глубокий анализ: периодически накопленные события просматриваются на предмет выявления тенденций. И наконец, обработанные данные пересылаются удаленным модулям, которые проводят более сложный анализ. С помощью «интроспекции» OceanStore выделяет кластеры взаимосвязанных данных, что облегчает задачи кэширующих и маршрутизирующих механизмов, определяет оптимальное количество и местоположение копий объектов, повышает надежность архивирования.

Теперь несколько слов о форме, которую приобретает система для «внешнего мира». В настоящий момент действующий прототип реализован на языке Java, проводятся лабораторные исследования и доработка концепций. Доступ к системе осуществляется с помощью специально разработанного API. Однако не стоит думать, что ученые Берклеевского университета витают в облаках, они прекрасно осознают инерционность информационной индустрии. Поэтому готовится и набор API-надстроек, которые будут поддерживать общепризнанные стандарты. Уже написаны эмуляции Unix-совместимой файловой системы, транзактной БД и шлюза для доступа к WWW. Такие надстройки называются «фасадами» (facades). В дальнейшем для обеспечения дополнительного комфорта разработчикам прикладного ПО будут предлагаться и другие «фасады», имитирующие различные специфические интерфейсы.

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

ENDEAVOR — ЛУЧШИЙ ДРУГ ИЛИ «БОЛЬШОЙ БРАТ»?

На самом деле OceanStore — лишь маленький «залив» в океане проекта Endeavor. Его целью стало создание Information Utility — гигантского программно-аппаратного комплекса решений, который охватывал бы все сферы человеческой жизни. 19 исследователей, специалистов в различных областях компьютерных наук, готовят спецификации и реальные прототипы глобальной системы, способной собирать, обрабатывать, хранить и пересылать гигабайты данных, поступающих из разнообразных источников. Судя по информации, размещенной на официальном сайте проекта, Information Utility станет единым архитектурным каркасом, универсальным прозрачным системным слоем, обеспечивающим функционирование любых распределенных приложений. Нечто вроде всемирной сетевой операционной системы. В качестве базовой концепции используется понятие «текучего ПО» (fluid software), что означает свободу размещения информации, унификацию интерфейсов, динамическое перераспределение сервисных операций между узлами.

Работы ведутся в трех основных направлениях: аппаратное обеспечение (Information Devices), системное программное обеспечение (Information Utility) и прикладное ПО (Applications). В рамках первого направления изучаются возможные разновидности клиентских устройств, которые будут пользоваться инфраструктурой Endeavor. Например, это могут быть миниатюрные датчики-чипы (MEMS), вмонтированные в различные предметы обихода. Датчики могут являться и составной частью более сложной структуры (интерактивной аудитории, устройства трехмерного позиционирования, складской системы учета и т. д.). Второе направление представлено OceanStore. Третье — совершенствуемыми в настоящий момент обучающими приложениями и разработками в области систем быстрого принятия решений. Тестирование и эксперименты проводятся на базе университетского кампуса. В работе принимают участие некоторые коммерческие компании, поставляющие оборудование. В здании Soda Hall была развернута и функционирует экспериментальная сеть «посткомпьютерной эпохи». IBM предоставила в распоряжение ученых необходимое количество КПК WorkPad, связь осуществляется с помощью беспроводной сети на базе техники фирмы Metricom. Учебные аудитории оборудованы компьютерными проекционными системами, а отдельные комнаты полностью автоматизированы. В них установлены большие дисплеи, используются камеры, отслеживающие движение, управление освещением и аудио/ видеооборудованием осуществляется компьютером. В планы исследователей входит расширение тестовой системы на весь университетский кампус, а впоследствии и на город Беркли (Berkley, 120 тыс. жителей).

Энтузиазм и цели, которые поставили перед собой инициаторы проекта Endeavor, не могут не восхищать. Внедрение глобальной универсальной среды распространения информации откроет дорогу совершенно новым разновидностям приложений. Однако столь глубокая унификация вызывает и серьезные опасения. Насколько нам будет легче искать и получать информацию, настолько же проще будет специальным службам и преступным организациям собирать сведения о нас. Даже то малое, что привнесло в документооборот широкое распространение Internet, — единообразие доступа, позволило создать «Эшелон» и ему подобные системы. Хотя идея перлюстрации почтовых сообщений, проходящих через маршрутизирующий сервер, вполне успешно применялась и продолжает использоваться в «мирных» целях, например, для ведения базы адресов электронной почты (www.botik.ru/intermap/, служба была запущена еще в 1992 году!).

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