Распределенная файловая система (Distributed File System, DFS) настраивается в операционной системе Windows 2000 Server (Панель управления – Администрирование – Распределенная файловая система DFS ) и позволяет объединить файловые ресурсы, находящиеся на различных компьютерах, в одно пространство имен. Таким образом, вместо сети, состоящей из большого количества машин, пользователь видит структуру логических имен, связанных с общими ресурсами.

Преимущества DFS:

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

· удобное администрирование томов – общий ресурс, входящий в состав тома DFS, может быть отключен без какого-либо влияния на оставшуюся часть пространства имен;

· наличие графического инструмента администрирования;

· возможность организации отказоустойчивых схем хранения информации – одному логическому имени могут соответствовать несколько копий ресурса (реплик), наличие которых прозрачно для пользователя;

· сбалансированная нагрузка на общие ресурсы сети за счет связывания одного имени ресурса с разными репликами этого ресурса;

· прозрачность соответствия логического представления данных и их физического местоположения – пользователи не знают об изменениях физического местоположения ресурса;

· интегрирование с моделью безопасности Windows 2000 – используются единые учетные записи пользователей;

· интеллектуальное кэширование данных на стороне клиента;

· возможность взаимодействия с другими сетевыми файловыми системами.

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

Начальной точкой для логических имен дерева DFS служит корень распределенной файловой системы, для создания которого необходимо указать некоторый общий ресурс, находящийся на сервере. Все остальные имена DFS будут находиться на следующем иерархическом уровне. Общие ресурсы компьютерной сети в дереве DFS представляются с помощью логических имен, имеющих следующее место в полном имени ресурса в сети: \\Имя_Сервера\Логическое_Имя_DFS\ Путь\Файл.

Распределенная файловая система DFS обеспечивает подключение к одному логическому имени до 32 альтернативных общих ресурсов (реплик). Если реплики находятся в разделе NTFS 5.0 в распределенной файловой системе, созданной на серверах Windows 2000 и интегрированной с Active Directory, то для них можно настроить автоматическую синхронизацию – согласование данных (репликацию). В других случаях согласование реплик необходимо выполнять вручную .

Элементы системной интеграции

В распределенных вычислительных системах или общедоступных компьютерных сетях, например в Интернете, существует множество объектов, представляющих интерес – таких, как базы данных, принтеры, серверы службы факсов, приложения, пользователи. Пользователям желательно уметь находить и использовать эти объекты. Администраторам необходимо управлять использованием этих объектов.

Служба каталогов

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

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

Служба каталогов может решать следующие задачи:

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

· Распределять каталог по различным компьютерам сети.

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

· Разбивать каталог на несколько разделов для обеспечения возможности хранения большого количества объектов.

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

Active Directory – это служба каталогов, включенная в операционную систему Windows 2000/2003 Server. Она является наглядным примером системной интеграции – расширяет возможности существовавших ранее служб каталогов на базе Windows и добавляет совершенно новые возможности.

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

Служба каталогов Active Directory образует пространство имен, в котором имя объекта в каталоге разрешается в сам объект.

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

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

Класс объектов определяет тип информации, содержащейся в Active Directory для экземпляров (объектов) данного класса. Следовательно, каждый объект принадлежит, по крайней мере, к одному объектному классу, представляющему собой некоторое семейство объектов с определенными общими характеристиками.

Схема службы каталогов Active Directory реализована как набор экземпляров классов объектов, которые хранятся в каталоге. Следовательно, схема – совокупность (матрица) всех атрибутов и классов.

Контейнер подобен объекту в том, что у него есть атрибуты и он является частью пространства имен службы каталогов Active Directory. Но он, в отличие от объекта, не представляет собой нечто конкретное. Он лишь «оболочка» для группы объектов и других контейнеров.

Термин дерево используется для описания иерархии объектов и контейнеров. Вершины дерева обычно являются объектами. Узлы дерева (точки, где дерево ветвится) являются контейнерами. Дерево показывает связь между объектами или путь от одного объекта к другому. Простой каталог является контейнером. Компьютерная сеть или домен также являются контейнерами. Непрерывным поддеревом называется любой неразрывный путь в дереве, включая все составляющие каждого включенного в этот путь контейнера (рис. 3.5).

Рис 3.5. Непрерывное поддерево каталога файлов

Имя идентифицирует любой объект службы каталогов Active Directory. Имена бывают двух типов: различающееся имя и относительное различающееся имя.

Различающееся имя (DN – distinguished name) определяет домен, содержащий объект, а также полный путь по иерархии контейнеров, ведущий к данному объекту. Типичное DN может иметь вид:

/O=Internet/DC=COM/DC=Microsoft/CN=Users/CN=James Smith

Это DN определяет объект-пользователь «James Smith» в домене Microsoft.com. Здесь CN обозначает общее имя. (рис. 3.6)

Рис. 3.6. Графическое представление различающегося имени

Относительное различающееся имя (RDN – Relative Distinguished Name) объекта – это часть его имени, которая представляет собой атрибут самого объекта. В предыдущем примере RDN объекта-пользователя «James Smith» будет CN=James Smith. RDN его родительского объекта будет CN=Users.

Служба каталогов Active Directory обеспечивает эффективную работу сложной корпоративной среды, предоставляя следующие возможности.

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

· Безопасность информации . Средства аутентификации и управления доступом к ресурсам, встроенные в службу Active Directory, обеспечивают централизованную защиту сети. Права доступа можно определять не только для каждого объекта каталога, но и каждого свойства (атрибута) объекта.

· Централизованное управление . Администраторы могут централизованно управлять всеми корпоративными ресурсами. Рутинные задачи администрирования не нужно повторять для многочисленных объектов сети.

· Администрирование с использованием групповых политик. При загрузке компьютера или регистрации пользователя в системе выполняются требования групповых политик; их настройки хранятся в объектах групповых политик (GPO) и «привязываются» к сайтам, доменам или организационным единицам. Групповые политики определяют, например, права доступа к различным объектам каталога или ресурсам, а также множество других «правил» работы в системе.

· Гибкость изменений . Служба каталогов гибко следует за изменениями структуры компании или организации. При этом реорганизация каталога не усложняется, а может и упроститься. Кроме того, службу каталога можно связать с Интернетом для взаимодействия с деловыми партнерами и поддержки электронной коммерции.

· Интеграция с DNS . Служба Active Directory тесно связана с DNS. Этим достигается единство в именовании ресурсов локальной сети и глобальной сети Интернет, в результате чего упрощается подключение пользовательской сети к Интернету. Служба каталогов Active Directory использует систему DNS в качестве службы определения местоположения. Имена доменов Windows 2000/2003 являются именами доменов DNS.

· Расширяемость каталога . Администраторы могут добавлять в схему каталога новые классы объектов или добавлять новые атрибуты к существующим классам.

· Масштабируемость . Служба Active Directory может охватывать как один домен, так и множество доменов, один контроллер домена или множество контроллеров домена – т. е. она отвечает требованиям сетей любого масштаба. Несколько доменов можно объединить в дерево доменов, а несколько деревьев доменов можно связать в лес.

· Репликация информации . В службе Active Directory используется репликация служебной информации в схеме со многими ведущими (multi-master), что позволяет модифицировать каталог на любом контроллере домена. Наличие в домене нескольких контроллеров обеспечивает отказоустойчивость и возможность распределения сетевой нагрузки.

· Гибкость запросов к каталогу . Пользователи и администраторы сети могут быстро находить объекты в сети, используя свойства объекта (например, имя пользователя или адрес его электронной почты, тип принтера или его местоположение и т. п.). Это, в частности, можно сделать при помощи команды Пуск – Поиск папку Мое сетевое окружение или оснастку Active Directory – пользователи и компьютеры .Оптимальность процедуры поиска достигается благодаря использованию глобального каталога.

· Стандартные интерфейсы . Для разработчиков приложений служба каталогов предоставляют доступ ко всем возможностям (средствам) каталога и поддерживают принятые стандарты и интерфейсы программирования (API). Служба каталогов тесно связана с операционной системой, что позволяет избежать дублирования в прикладных программах функциональных возможностей системы, например, средств безопасности.

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

Можно сказать, что служба Active Directory «стоит на трех китах»:

· Стандарт Х.500

· Служба DNS (Domain Name Service)

· Протокол LDAP (Lightweight Directory Access Protocol)

В Active Directory частично реализована модель данных, описываемая стандартом Х.500. Традиционная в сетях TCP/IP служба DNS используется, в частности, для поиска контроллеров домена, а благодаря протоколу LDAP клиенты могут по имени находить в каталоге Active Directory нужные объекты и получать доступ к их атрибутам.

Для понимания структуры Active Directory рассмотрим сначала отличия Windows 2000 от предыдущих версий серверных операционных систем Windows. Компьютеры на базе Windows 2000 по-прежнему объединяются в домены. Домены – это известное решение для администрирования групп, предоставляющее каждому пользователю учетную запись в конкретном домене. Однако, в отличие от Windows NT Server 4.0, где доменам давались простые строковые имена (имена NetBIOS), в среде Windows 2000 Server каждый домен должен иметь имя, отвечающее соглашениям именования доменов Domain Name System (DNS). Так, домен, имеющий имя NetBIOS MainOffice при обновлении может получить новое имя типа mainoffice.company.com.

В каждом домене один или несколько компьютеров должны выполнять функции контроллеров домена. В среде Windows 2000 Server каждый контроллер домена содержит полную копию базы данных Active Directory этого домена.

В Active Directory используются так называемое ядро Extended Storage Engine (ESE) и два различных протокола, обеспечивающих связь между клиентами и базой данных.

Для поиска контроллера домена клиент обращается к протоколу, описанному в DNS – «стандартной» службе каталогов, применяемой в настоящее время для сетей TCP/IP.

Для доступа к данным в Active Directory клиент использует протокол Lightweight Directory Access Protocol (LDAP) (рис. 3.7).

Рис 3.7. Доступ к данным с использованием LDAP

После того как с помощью DNS нужный контроллер домена обнаружен, для доступа к данным Active Directory используется протокол LDAP. Протокол LDAP работает поверх TCP/IP и – как следует из названия протокола – определяет способы доступа к каталогу со стороны клиентов.

Помимо механизма доступа данный протокол реализует соглашения по именованию информации в каталоге, в явном виде описывая структуру этой информации. Для клиента все данные, хранящиеся в базе LDAP, представляются в виде иерархического дерева. Каждый узел дерева (объект или элемент) может быть либо контейнером, либо листом. Различие между ними вполне очевидно: контейнеры могут содержать другие элементы, а листья – нет.

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

Тип информации (объектные классы и типы атрибутов), содержащейся в конкретной базе данных Active Directory, задается схемой, определенной для этого каталога. В Active Directory схема каждого каталога представлена элементами, хранящимися непосредственно в самом каталоге. Компания Microsoft определяет стандартную схему, однако пользователи и разработчики программных средств могут добавлять новые классы и типы атрибутов. Изменение схемы каталога – полезная возможность, которой нужно пользоваться очень осторожно, поскольку такие изменения могут иметь весьма значительные последствия.

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

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

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

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

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

Для любого файлового сервиса, независимо от того, централизован он или распределен, самым главным является вопрос, что такое файл? Во многих системах, таких как UNIX и MS DOS, файл – это неинтерпретируемая последовательность байтов. Значение и структура информации в файле является заботой прикладных программ, операционную систему это не интересует.

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

Важным аспектом файловой модели является возможность модификации файла после его создания. Обычно файлы могут модифицироваться, но в некоторых распределенных системах единственными операциями с файлами являются СОЗДАТЬ и ПРОЧИТАТЬ. Такие файлы называются неизменяемыми. Для неизменяемых файлов намного легче осуществить кэширование файла и его репликацию (тиражирование), так как исключается все проблемы, связанные с обновлением всех копий файла при его изменении.

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

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

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

Принципиальной проблемой, связанной со способами именования файлов, является обеспечение прозрачности. В данном контексте прозрачность понимается в двух слабо различимых смыслах. Первый – прозрачность расположения – означает, что имена не дают возможности определить месторасположение файла. Например, имя /server1/dir1/ dir2/x говорит, что файл x расположен на сервере 1, но не указывает, где расположен этот сервер. Сервер может перемещаться по сети, а полное имя файла при этом не меняется. Следовательно, такая система обладает прозрачностью расположения.

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

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

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

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

Во-вторых, необходимо определить правило замены данных при заполнении кэш-памяти. Здесь можно использовать любой стандартный алгоритм кэширования, например, алгоритм LRU (least recently used), соответствии с которым вытесняется блок, к которому дольше всего не было обращения.

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

Pr0grammer 29 октября 2009 в 01:31

Распределенная файловая система GFS (Google File System)

• Разработка веб-сайтов

В настоящее время, в условиях роста информации, возникают задачи хранения и обработки данных очень большого объема. Поэтому эти данные обрабатывается сразу на нескольких серверах одновременно, которые образуют кластеры. Для упрощения работы с данными на кластерах и разрабатывают распределенные файловые системы. Мы подробно рассмотрим пример распределенной файловой системы Google File System , используемую компанией Google . (Статья является, фактически, вольным и урезанным переводом оригинальной статьи).

GFS является наиболее, наверное, известной распределенной файловой системой. Надежное масштабируемое хранение данных крайне необходимо для любого приложения, работающего с таким большим массивом данных, как все документы в интернете. GFS является основной платформой хранения информации в Google . GFS - большая распределенная файловая система, способная хранить и обрабатывать огромные объемы информации.
GFS строилась исходя из следующим критериев:

• Система строится из большого количества обыкновенного недорого оборудования, которое часто дает сбои. Должны существовать мониторинг сбоев, и возможность в случае отказа какого-либо оборудования восстановить функционирование системы.
• Система должна хранить много больших файлов. Как правило, несколько миллионов файлов, каждый от 100 Мб и больше. Также часто приходится иметь дело с многогигабайтными файлами, которые также должны эффективно храниться. Маленькие файлы тоже должны храниться, но для них не оптимизируется работа системы.
• Как правило, встречаются два вида чтения: чтение большого последовательного фрагмента данных и чтение маленького объема произвольных данных. При чтении большого потока данных обычным делом является запрос фрагмента размером в 1Мб и больше. Такие последовательные операции от одного клиента часто читают подряд идущие куски одного и того же файла. Чтение небольшого размера данных, как правило, имеет объем в несколько килобайт. Приложения, критические по времени исполнения, должны накопить определенное количество таких запросов и отсортировать их по смещению от начала файла. Это позволит избежать при чтении блужданий вида назад-вперед.
• Часто встречаются операции записи большого последовательного куска данных, который необходимо дописать в файл. Обычно, объемы данных для записи такого же порядка, что и для чтения. Записи небольших объемов, но в произвольные места файла, как правило, выполняются не эффективно.
• Система должна реализовывать строго очерченную семантику параллельной работы нескольких клиентов, в случае если они одновременно пытаются дописать данные в один и тот же файл. При этом может случиться так, что поступят одновременно сотни запросов на запись в один файл. Для того чтобы справится с этим, используется атомарность операций добавления данных в файл, с некоторой синхронизацией. То есть если поступит операция на чтение, то она будет выполняться, либо до очередной операции записи, либо после.
• Высокая пропускная способность является более предпочтительной, чем маленькая задержка. Так, большинство приложений в Google отдают предпочтение работе с большими объемами данных, на высокой скорости, а выполнение отдельно взятой операции чтения и записи, вообще говоря, может быть растянуто.

Файлы в GFS организованы иерархически, при помощи каталогов, как и в любой другой файловой системе, и идентифицируются своим путем. С файлами в GFS можно выполнять обычные операции: создание, удаление, открытие, закрытие, чтение и запись.
Более того, GFS поддерживает резервные копии, или снимки (snapshot). Можно создавать такие резервные копии для файлов или дерева директорий, причем с небольшими затратами.

Архитектура GFS

Рисунок взят из оригинальной статьи.

В системе существуют мастер-сервера и чанк-сервера, собственно, хранящие данные. Как правило, GFS кластер состоит из одной главной машины мастера (master) и множества машин, хранящих фрагменты файлов чанк-серверы (chunkservers). Клиенты имеют доступ ко всем этим машинам. Файлы в GFS разбиваются на куски - чанки (chunk, можно сказать фрагмент). Чанк имеет фиксированный размер, который может настраиваться. Каждый такой чанк имеет уникальный и глобальный 64 - битный ключ, который выдается мастером при создании чанка. Чанк-серверы хранят чанки, как обычные Linux файлы, на локальном жестком диске. Для надежности каждый чанк может реплицироваться на другие чанк-серверы. Обычно используются три реплики.
Мастер отвечает за работу с метаданными всей файловой системы. Метаданные включают в себя пространства имен, информацию о контроле доступа к данным, отображение файлов в чанки, и текущее положение чанков. Также мастер контролирует всю глобальную деятельность системы такую, как управление свободными чанками, сборка мусора (сбор более ненужных чанков) и перемещение чанков между чанк-серверами. Мастер постоянно обменивается сообщениями (HeartBeat messages) с чанк-серверами, чтобы отдать инструкции, и определить их состояние (узнать, живы ли еще).
Клиент взаимодействует с мастером только для выполнения операций, связанных с метаданными. Все операции с самими данными производятся напрямую с чанк-серверами. GFS - система не поддерживает POSIX API, так что разработчикам не пришлось связываться с VNode уровнем Linux.
Разработчики не используют кеширование данных, правда, клиенты кешируют метаданные. На чанк-серверах операционная система Linux и так кеширует наиболее используемые блоки в памяти. Вообще, отказ от кеширования позволяет не думать о проблеме валидности кеша (cache coherence).

Мастер

Использование одного мастера существенно упрощает архитектуру системы. Позволяет производить сложные перемещения чанков, организовывать репликации, используя глобальные данные. Казалось бы, что наличие только одного мастера должно являться узким местом системы, но это не так. Клиенты никогда не читают и не пишут данные через мастера. Вместо этого они спрашивают у мастера, с каким чанк-сервером они должны контактировать, а далее они общаются с чанк-серверами напрямую.
Рассмотрим, как происходит чтение данных клиентом. Сначала, зная размер чанка,
имя файла и смещение относительно начала файла, клиент определяет номер чанка внутри файла. Затем он шлет запрос мастеру, содержащий имя файла и номер чанка в этом файле. Мастер выдает чанк-серверы, по одному в каждой реплике, которые хранят нужный нам чанк. Также мастер выдает клиенту идентификатор чанка.
Затем клиент решает, какая из реплик ему нравится больше (как правило та, которая ближе), и шлет запрос, состоящий из чанка и смещения относительно начала чанка. Дальнейшее чтения данных, не требует вмешательства мастера. На практике, как правило, клиент в один запрос на чтение включает сразу несколько чанков, и мастер дает координаты каждого из чанков в одном ответе.
Размер чанка является важной характеристикой системы. Как правило, он устанавливается равным 64 мегабайт, что гораздо больше, чем размер блока в обычной файловой системе. Понятно, что если необходимо хранить много файлов, размеры которых меньше размера чанка, то будем расходоваться много лишней памяти. Но выбор такого большого размера чанка обусловлен задачами, которые приходится компании Google решать на своих кластерах. Как правило, что-то считать приходится для всех документов в интернете, и поэтому файлы в этих задачах очень большого размера.

Метаданные

Мастер хранит три важных вида метаданных: пространства имен файлов и чанков, отображение файла в чанки и положение реплик чанков. Все метаданные хранятся в памяти мастера. Так как метаданные хранятся в памяти, операции мастера выполняются быстро. Состояние дел в системе мастер узнает просто и эффективно. Он выполняется сканирование чанк-серверов в фоновом режиме. Эти периодические сканирования используются для сборки мусора, дополнительных репликаций, в случае обнаружения недоступного чанк-сервера и перемещение чанков, для балансировки нагрузки и свободного места на жестких дисках чанк-серверов.
Мастер отслеживает положение чанков. При старте чанк-сервера мастер запоминает его чанки. В процессе работы мастер контролирует все перемещения чанков и состояния чанк-серверов. Таким образом, он обладает всей информацией о положении каждого чанка.
Важная часть метаданных - это лог операций. Мастер хранит последовательность операций критических изменений метаданных. По этим отметкам в логе операций, определяется логическое время системы. Именно это логическое время определяет версии файлов и чанков.
Так как лог операций важная часть, то он должен надежно храниться, и все изменения в нем должны становиться видимыми для клиентов, только когда изменятся метаданные. Лог операций реплицируется на несколько удаленных машин, и система реагирует на клиентскую операцию, только после сохранения этого лога на диск мастера и диски удаленных машин.
Мастер восстанавливает состояние системы, исполняя лог операций. Лог операций сохраняет относительно небольшой размер, сохраняя только последние операции. В процессе работы мастер создает контрольные точки, когда размер лога превосходит некоторой величины, и восстановить систему можно только до ближайшей контрольной точки. Далее по логу можно заново воспроизвести некоторые операции, таким образом, система может откатываться до точки, которая находится между последней контрольной точкой и текущем временем.

Взаимодействия внутри системы

Выше была описана архитектура системы, которая минимизирует вмешательства мастера в выполнение операций. Теперь же рассмотрим, как взаимодействуют клиент, мастер и чанк-серверы для перемещения данных, выполнения атомарных операций записи, и создания резервной копии (snapshot).
Каждое изменение чанка должно дублироваться на всех репликах и изменять метаданные. В GFS мастер дает чанк во владение (lease) одному из серверов, хранящих этот чанк. Такой сервер называется первичной (primary) репликой. Остальные реплики объявляются вторичными (secondary). Первичная реплика собирает последовательные изменения чанка, и все реплики следуют этой последовательности, когда эти изменения происходят.
Механизм владения чанком устроен таким образом, чтобы минимизировать нагрузку на мастера. При выделении памяти сначала выжидается 60 секунд. А затем, если потребуется первичная реплика может запросить мастера на расширение этого интервала и, как правило, получает положительный ответ. В течение этого выжидаемого периода мастер может отменить изменения.
Рассмотрим подробно процесс записи данных. Он изображен по шагам на рисунке, при этом тонким линиям соответствуют потоки управления, а жирным потоки данных.


Этот рисунок также взят из оригинальной статьи.

1. Клиент спрашивает мастера, какой из чанк-серверов владеет чанком, и где находится этот чанк в других репликах. Если необходимо, то мастер отдает чанк кому-то во владение.
2. Мастер в ответ выдает первичную реплику, и остальные (вторичные) реплики. Клиент хранит эти данные для дальнейших действий. Теперь, общение с мастером клиенту может понадобиться только, если первичная реплика станет недоступной.
3. Далее клиент отсылает данные во все реплики. Он может это делать в произвольном порядке. Каждый чанк-сервер будет их хранить в специальном буфере, пока они не понадобятся или не устареют.
4. Когда все реплики примут эти данные, клиент посылает запрос на запись первичной реплике. В этом запросе содержатся идентификация данных, которые были посланы в шаге 3. Теперь первичная реплика устанавливает порядок, в котором должны выполняться все изменения, которые она получила, возможно от нескольких клиентов параллельно. И затем, выполняет эти изменения локально в этом определенном порядке.
5. Первичная реплика пересылает запрос на запись всем вторичным репликам. Каждая вторичная реплика выполняет эти изменения в порядке, определенном первичной репликой.
6. Вторичные реплики рапортуют об успешном выполнении этих операций.
7. Первичная реплика шлет ответ клиенту. Любые ошибки, возникшие в какой-либо реплике, также отсылаются клиенту. Если ошибка возникла при записи в первичной реплике, то и запись во вторичные реплики не происходит, иначе запись произошла в первичной реплике, и подмножестве вторичных. В этом случае клиент обрабатывает ошибку и решает, что ему дальше с ней делать.

Из примера выше видно, что создатели разделили поток данных и поток управления. Если поток управления идет только в первичную реплику, то поток данных идет во все реплики. Это сделано, чтобы избежать создания узких мест в сети, а взамен широко использовать пропускную способность каждой машины. Так же, чтобы избежать узких мест и перегруженных связей, используется схема передачи ближайшему соседу по сетевой топологии. Допустим, что клиент передает данные чанк-серверам S1 ,..., S4 . Клиент шлет ближайшему серверу данные, пусть S1 . Он далее пересылает ближайшему серверу, пусть будет S2 . Далее S2 пересылает их ближайшему S3 или S4 , и так далее.
Также задержка минимизируется за счет использования конвейеризации пакетов передаваемых данных по TCP . То есть, как только чанк-сервер получил какую-то часть данных, он немедленно начинает их пересылать. Без сетевых заторов, идеальное время рассылки данных объемом B байт на R реплик будет B/T + RL , где T сетевая пропускная способность, а L - задержка при пересылке одного байта между двумя машинами.
GFS поддерживает такую операцию, как атомарное добавление данных в файл. Обычно, при записи каких-то данных в файл, мы указываем эти данные и смещение. Если несколько клиентов производят подобную операцию, то эти операции нельзя переставлять местами (это может привести к некорректной работе). Если же мы просто хотим дописать данные в файл, то в этом случае мы указываем только сами данные. GFS добавит их атомарной операцией. Вообще говоря, если операция не выполнилась на одной из вторичных реплик, то GFS , вернет ошибку, а данные будут на разных репликах различны.
Еще одна интересная вещь в GFS - это резервные копии (еще можно сказать мгновенный снимок) файла или дерева директорий, которые создаются почти мгновенно, при этом, почти не прерывая выполняющиеся операции в системе. Это получается за счет технологии похожей на сopy on write . Пользователи используют эту возможность для создания веток данных или как промежуточную точку, для начала каких-то экспериментов.

Операции, выполняемые мастером

Мастер важное звено в системе. Он управляет репликациями чанков: принимает решения о размещении, создает новые чанки, а также координирует различную деятельность внутри системы для сохранения чанков полностью реплицированными, балансировки нагрузки на чанк-серверы и сборки неиспользуемых ресурсов.
В отличие от большинства файловых систем GFS не хранит состав файлов в директории. GFS логически представляет пространство имен, как таблицу, которая отображает каждый путь в метаданные. Такая таблица может эффективно храниться в памяти в виде бора (словаря этих самых путей). Каждая вершина в этом дереве (соответствует либо абсолютному пути к файлу, либо к директории) имеет соответствующие данные для блокировки чтения и записи(read write lock). Каждое операция мастера требует установления некоторых блокировок. В этом месте в системе используются блокировки чтения-записи. Обычно, если операция работает с /d1/d2/.../dn/leaf , то она устанавливает блокировки на чтение на /d1, /d1/d2, ..., d1/d2/.../dn и блокировку, либо на чтение, либо на запись на d1/d2/.../dn/leaf . При этом leaf может быть как директорией, так и файлом.
Покажем на примере, как механизм блокировок может предотвратить создание файла /home/user/foo во время резервного копирования /home/user в /save/user . Операция резервного копирования устанавливает блокировки на чтение на /home и /save , а так же блокировки на запись на /home/user и /save/user . Операция создания файла требует блокировки на чтение /home и /home/user , а также блокировки на запись на /home/user/foo . Таким образом, вторая операция не начнет выполняться, пока не закончит выполнение первая, так как есть конфликтующая блокировка на /home/user . При создании файла не требуется блокировка на запись родительской директории, достаточно блокировки на чтение, которая предотвращает удаление этой директории.
Кластеры GFS , являются сильно распределенными и многоуровневыми. Обычно, такой кластер имеет сотни чанк-серверов, расположенных на разных стойках. Эти сервера, вообще говоря, доступны для большого количества клиентов, расположенных в той же или другой стойке. Соединения между двумя машинами из различных стоек может проходить через один или несколько свитчей. Многоуровневое распределение представляет очень сложную задачу надежного, масштабируемого и доступного распространения данных.
Политика расположения реплик старается удовлетворить следующим свойствам: максимизация надежности и доступности данных и максимизация использование сетевой пропускной способности. Реплики должны быть расположены не только на разных дисках или разных машинах, но и более того на разных стойках. Это гарантирует, что чанк доступен, даже если целая стойка повреждена или отключена от сети. При таком расположении чтение занимает время приблизительно равное пропускной способности сети, зато поток данных при записи должен пройти через различные стойки.
Когда мастер создает чанк, он выбирает где разместить реплику. Он исходит из нескольких факторов:

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

Как только число реплик падает ниже устанавливаемой пользователем величины, мастер снова реплицирует чанк. Это может случиться по нескольким причинам: чанк-сервер стал недоступным, один из дисков вышел из строя или увеличена величина, задающая число реплик. Каждому чанку, который должен реплицироваться, устанавливается приоритет, который тоже зависит от нескольких факторов. Во-первых, приоритет выше у того чанка, который имеет наименьшее число реплик. Во-вторых, чтобы увеличить надежность выполнения приложений, увеличивается приоритет у чанков, которые блокируют прогресс в работе клиента
Мастер выбирает чанк с наибольшим приоритетом и копирует его, отдавая инструкцию одному из чанк-серверов, скопировать его с доступной реплики. Новая реплика располагается, исходя из тех же причин, что и при создании.
Во время работы мастер постоянно балансирует реплики. В зависимости от распределения реплик в системе, он перемещает реплику для выравнивания загруженности дисков и балансировки нагрузки. Также мастер должен решать, какую из реплик стоит удалить. Как правило, удаляется реплика, которая находится на чанк-сервере с наименьшим свободным местом на жестких дисках.
Еще одна важная функция, лежащая на мастере - это сборка мусора. При удалении файла, GFS не требует мгновенного возвращения освободившегося дискового пространства. Он делает это во время регулярной сборки мусора, которая происходит как на уровне чанков, так и на уровне файлов. Авторы считают, что такой подход делает систему более простой и надежной.
При удалении файла приложением, мастер запоминает в логах этот факт, как и многие другие. Тем не менее, вместо требования немедленного восстановления освободившихся ресурсов, файл просто переименовывается, причем в имя файла добавляется время удаления, и он становится невидимым пользователю. А мастер, во время регулярного сканирования пространства имен файловой системы, реально удаляет все такие скрытые файлы, которые были удалены пользователем более трех дней назад (этот интервал настраивается). А до этого момента файл продолжает находиться в системе, как скрытый, и он может быть прочитан или переименован обратно для восстановления. Когда скрытый файл удаляется мастером, то информация о нем удаляется также из метаданных, а все чанки этого файла отцепляются от него.
Мастер помимо регулярного сканирования пространства имен файлов делает аналогичное сканирование пространства имен чанков. Мастер определяет чанки, которые отсоединены от файла, удаляет их из метаданных и во время регулярных связей с чанк-серверами передает им сигнал о возможности удаления всех реплик, содержащих заданный чанк. У такого подхода к сборке мусора много преимуществ, при одном недостатке: если место в системе заканчивается, а отложенное удаление увеличивает неиспользуемое место, до момента самого физического удаления. Зато есть возможность восстановления удаленных данных, возможность гибкой балансировки нагрузки при удалении и возможность восстановления системы, в случае каких-то сбоев.

Устойчивость к сбоям и диагностика ошибок

Авторы системы считают одной из наиболее сложных проблем частые сбои работы компонентов системы. Количество и качество компонентов делают эти сбои не просто исключением, а скорее нормой. Сбой компонента может быть вызван недоступностью этого компонента или, что хуже, наличием испорченных данных. GFS поддерживает систему в рабочем виде при помощи двух простых стратегий: быстрое восстановление и репликации.
Быстрое восстановление - это, фактически, перезагрузка машины. При этом время запуска очень маленькое, что приводит к маленькой заминке, а затем работа продолжается штатно. Про репликации чанков уже говорилось выше. Мастер реплицирует чанк, если одна из реплик стала недоступной, либо повредились данные, содержащие реплику чанка. Поврежденные чанки определяется при помощи вычисления контрольных сумм.
Еще один вид репликаций в системе, про который мало было сказано - это репликация мастера. Реплицируется лог операций и контрольные точки (checkpoints). Каждое изменение файлов в системе происходит только после записи лога операций на диски мастером, и диски машин, на которые лог реплицируется. В случае небольших неполадок мастер может перезагрузиться. В случае проблем с жестким диском или другой жизненно важной инфраструктурой мастера, GFS стартует нового мастера, на одной из машин, куда реплицировались данные мастера. Клиенты обращаются к мастеру по DNS, который может быть переназначен новой машине. Новый мастер является тенью старого, а не точной копией. Поэтому у него есть доступ к файлам только для чтения. То есть он не становится полноценным мастером, а лишь поддерживает лог операций и другие структуры мастера.
Важной частью системы является возможность поддерживать целостность данных. Обычный GFS кластер состоит из сотен машин, на которых расположены тысячи жестких дисков, и эти диски при работе с завидным постоянством выходят из строя, что приводит к порче данных. Система может восстановить данные с помощью репликаций, но для этого необходимо понять испортились ли данные. Простое сравнение различных реплик на разных чанк-серверах является неэффективным. Более того, может происходить несогласованность данных между различными репликами, ведущая к различию данных. Поэтому каждый чанк-сервер должен самостоятельно определять целостность данных.
Каждый чанк разбивается на блоки длиной 64 Кбайт . Каждому такому блоку соответствует 32 -битная контрольная сумма. Как и другие метаданные эти суммы хранятся в памяти, регулярно сохраняются в лог, отдельно от данных пользователя.
Перед тем как считать данные чанк-сервер проверяет контрольные суммы блоков чанка, которые пересекаются с затребованными данными пользователем или другим чанк-сервером. То есть чанк-сервер не распространяет испорченные данные. В случае несовпадения контрольных сумм, чанк-сервер возвращает ошибку машине, подавшей запрос, и рапортует о ней мастеру. Пользователь может считать данные из другой реплики, а мастер создает еще одну копию из данных другой реплики. После этого мастер дает инструкцию этому чанк-серверу об удалении этой испорченной реплики.
При добавлении новых данных, верификация контрольных сумм не происходит, а для блоков записывается новые контрольные суммы. В случае если диск испорчен, то это определится при попытке чтения этих данных. При записи чанк-сервер сравнивает только первый и последний блоки, пересекающиеся с границами, в которые происходит запись, поскольку часть данных на этих блоках не перезаписывается и необходимо проверить их целостность.

В настоящее время, в условиях роста информации, возникают задачи хранения и обработки данных очень большого объема. Поэтому эти данные обрабатывается сразу на нескольких серверах одновременно, которые образуют кластеры. Для упрощения работы с данными на кластерах и разрабатывают распределенные файловые системы. Мы подробно рассмотрим пример распределенной файловой системы Google File System , используемую компанией Google . (Статья является, фактически, вольным и урезанным переводом оригинальной статьи).

GFS является наиболее, наверное, известной распределенной файловой системой. Надежное масштабируемое хранение данных крайне необходимо для любого приложения, работающего с таким большим массивом данных, как все документы в интернете. GFS является основной платформой хранения информации в Google . GFS - большая распределенная файловая система, способная хранить и обрабатывать огромные объемы информации.
GFS строилась исходя из следующим критериев:

• Система строится из большого количества обыкновенного недорого оборудования, которое часто дает сбои. Должны существовать мониторинг сбоев, и возможность в случае отказа какого-либо оборудования восстановить функционирование системы.
• Система должна хранить много больших файлов. Как правило, несколько миллионов файлов, каждый от 100 Мб и больше. Также часто приходится иметь дело с многогигабайтными файлами, которые также должны эффективно храниться. Маленькие файлы тоже должны храниться, но для них не оптимизируется работа системы.
• Как правило, встречаются два вида чтения: чтение большого последовательного фрагмента данных и чтение маленького объема произвольных данных. При чтении большого потока данных обычным делом является запрос фрагмента размером в 1Мб и больше. Такие последовательные операции от одного клиента часто читают подряд идущие куски одного и того же файла. Чтение небольшого размера данных, как правило, имеет объем в несколько килобайт. Приложения, критические по времени исполнения, должны накопить определенное количество таких запросов и отсортировать их по смещению от начала файла. Это позволит избежать при чтении блужданий вида назад-вперед.
• Часто встречаются операции записи большого последовательного куска данных, который необходимо дописать в файл. Обычно, объемы данных для записи такого же порядка, что и для чтения. Записи небольших объемов, но в произвольные места файла, как правило, выполняются не эффективно.
• Система должна реализовывать строго очерченную семантику параллельной работы нескольких клиентов, в случае если они одновременно пытаются дописать данные в один и тот же файл. При этом может случиться так, что поступят одновременно сотни запросов на запись в один файл. Для того чтобы справится с этим, используется атомарность операций добавления данных в файл, с некоторой синхронизацией. То есть если поступит операция на чтение, то она будет выполняться, либо до очередной операции записи, либо после.
• Высокая пропускная способность является более предпочтительной, чем маленькая задержка. Так, большинство приложений в Google отдают предпочтение работе с большими объемами данных, на высокой скорости, а выполнение отдельно взятой операции чтения и записи, вообще говоря, может быть растянуто.

Файлы в GFS организованы иерархически, при помощи каталогов, как и в любой другой файловой системе, и идентифицируются своим путем. С файлами в GFS можно выполнять обычные операции: создание, удаление, открытие, закрытие, чтение и запись.
Более того, GFS поддерживает резервные копии, или снимки (snapshot). Можно создавать такие резервные копии для файлов или дерева директорий, причем с небольшими затратами.

Архитектура GFS

Рисунок взят из оригинальной статьи.

В системе существуют мастер-сервера и чанк-сервера, собственно, хранящие данные. Как правило, GFS кластер состоит из одной главной машины мастера (master) и множества машин, хранящих фрагменты файлов чанк-серверы (chunkservers). Клиенты имеют доступ ко всем этим машинам. Файлы в GFS разбиваются на куски - чанки (chunk, можно сказать фрагмент). Чанк имеет фиксированный размер, который может настраиваться. Каждый такой чанк имеет уникальный и глобальный 64 - битный ключ, который выдается мастером при создании чанка. Чанк-серверы хранят чанки, как обычные Linux файлы, на локальном жестком диске. Для надежности каждый чанк может реплицироваться на другие чанк-серверы. Обычно используются три реплики.
Мастер отвечает за работу с метаданными всей файловой системы. Метаданные включают в себя пространства имен, информацию о контроле доступа к данным, отображение файлов в чанки, и текущее положение чанков. Также мастер контролирует всю глобальную деятельность системы такую, как управление свободными чанками, сборка мусора (сбор более ненужных чанков) и перемещение чанков между чанк-серверами. Мастер постоянно обменивается сообщениями (HeartBeat messages) с чанк-серверами, чтобы отдать инструкции, и определить их состояние (узнать, живы ли еще).
Клиент взаимодействует с мастером только для выполнения операций, связанных с метаданными. Все операции с самими данными производятся напрямую с чанк-серверами. GFS - система не поддерживает POSIX API, так что разработчикам не пришлось связываться с VNode уровнем Linux.
Разработчики не используют кеширование данных, правда, клиенты кешируют метаданные. На чанк-серверах операционная система Linux и так кеширует наиболее используемые блоки в памяти. Вообще, отказ от кеширования позволяет не думать о проблеме валидности кеша (cache coherence).

Мастер

Использование одного мастера существенно упрощает архитектуру системы. Позволяет производить сложные перемещения чанков, организовывать репликации, используя глобальные данные. Казалось бы, что наличие только одного мастера должно являться узким местом системы, но это не так. Клиенты никогда не читают и не пишут данные через мастера. Вместо этого они спрашивают у мастера, с каким чанк-сервером они должны контактировать, а далее они общаются с чанк-серверами напрямую.
Рассмотрим, как происходит чтение данных клиентом. Сначала, зная размер чанка,
имя файла и смещение относительно начала файла, клиент определяет номер чанка внутри файла. Затем он шлет запрос мастеру, содержащий имя файла и номер чанка в этом файле. Мастер выдает чанк-серверы, по одному в каждой реплике, которые хранят нужный нам чанк. Также мастер выдает клиенту идентификатор чанка.
Затем клиент решает, какая из реплик ему нравится больше (как правило та, которая ближе), и шлет запрос, состоящий из чанка и смещения относительно начала чанка. Дальнейшее чтения данных, не требует вмешательства мастера. На практике, как правило, клиент в один запрос на чтение включает сразу несколько чанков, и мастер дает координаты каждого из чанков в одном ответе.
Размер чанка является важной характеристикой системы. Как правило, он устанавливается равным 64 мегабайт, что гораздо больше, чем размер блока в обычной файловой системе. Понятно, что если необходимо хранить много файлов, размеры которых меньше размера чанка, то будем расходоваться много лишней памяти. Но выбор такого большого размера чанка обусловлен задачами, которые приходится компании Google решать на своих кластерах. Как правило, что-то считать приходится для всех документов в интернете, и поэтому файлы в этих задачах очень большого размера.

Метаданные

Мастер хранит три важных вида метаданных: пространства имен файлов и чанков, отображение файла в чанки и положение реплик чанков. Все метаданные хранятся в памяти мастера. Так как метаданные хранятся в памяти, операции мастера выполняются быстро. Состояние дел в системе мастер узнает просто и эффективно. Он выполняется сканирование чанк-серверов в фоновом режиме. Эти периодические сканирования используются для сборки мусора, дополнительных репликаций, в случае обнаружения недоступного чанк-сервера и перемещение чанков, для балансировки нагрузки и свободного места на жестких дисках чанк-серверов.
Мастер отслеживает положение чанков. При старте чанк-сервера мастер запоминает его чанки. В процессе работы мастер контролирует все перемещения чанков и состояния чанк-серверов. Таким образом, он обладает всей информацией о положении каждого чанка.
Важная часть метаданных - это лог операций. Мастер хранит последовательность операций критических изменений метаданных. По этим отметкам в логе операций, определяется логическое время системы. Именно это логическое время определяет версии файлов и чанков.
Так как лог операций важная часть, то он должен надежно храниться, и все изменения в нем должны становиться видимыми для клиентов, только когда изменятся метаданные. Лог операций реплицируется на несколько удаленных машин, и система реагирует на клиентскую операцию, только после сохранения этого лога на диск мастера и диски удаленных машин.
Мастер восстанавливает состояние системы, исполняя лог операций. Лог операций сохраняет относительно небольшой размер, сохраняя только последние операции. В процессе работы мастер создает контрольные точки, когда размер лога превосходит некоторой величины, и восстановить систему можно только до ближайшей контрольной точки. Далее по логу можно заново воспроизвести некоторые операции, таким образом, система может откатываться до точки, которая находится между последней контрольной точкой и текущем временем.

Взаимодействия внутри системы

Выше была описана архитектура системы, которая минимизирует вмешательства мастера в выполнение операций. Теперь же рассмотрим, как взаимодействуют клиент, мастер и чанк-серверы для перемещения данных, выполнения атомарных операций записи, и создания резервной копии (snapshot).
Каждое изменение чанка должно дублироваться на всех репликах и изменять метаданные. В GFS мастер дает чанк во владение (lease) одному из серверов, хранящих этот чанк. Такой сервер называется первичной (primary) репликой. Остальные реплики объявляются вторичными (secondary). Первичная реплика собирает последовательные изменения чанка, и все реплики следуют этой последовательности, когда эти изменения происходят.
Механизм владения чанком устроен таким образом, чтобы минимизировать нагрузку на мастера. При выделении памяти сначала выжидается 60 секунд. А затем, если потребуется первичная реплика может запросить мастера на расширение этого интервала и, как правило, получает положительный ответ. В течение этого выжидаемого периода мастер может отменить изменения.
Рассмотрим подробно процесс записи данных. Он изображен по шагам на рисунке, при этом тонким линиям соответствуют потоки управления, а жирным потоки данных.


Этот рисунок также взят из оригинальной статьи.

1. Клиент спрашивает мастера, какой из чанк-серверов владеет чанком, и где находится этот чанк в других репликах. Если необходимо, то мастер отдает чанк кому-то во владение.
2. Мастер в ответ выдает первичную реплику, и остальные (вторичные) реплики. Клиент хранит эти данные для дальнейших действий. Теперь, общение с мастером клиенту может понадобиться только, если первичная реплика станет недоступной.
3. Далее клиент отсылает данные во все реплики. Он может это делать в произвольном порядке. Каждый чанк-сервер будет их хранить в специальном буфере, пока они не понадобятся или не устареют.
4. Когда все реплики примут эти данные, клиент посылает запрос на запись первичной реплике. В этом запросе содержатся идентификация данных, которые были посланы в шаге 3. Теперь первичная реплика устанавливает порядок, в котором должны выполняться все изменения, которые она получила, возможно от нескольких клиентов параллельно. И затем, выполняет эти изменения локально в этом определенном порядке.
5. Первичная реплика пересылает запрос на запись всем вторичным репликам. Каждая вторичная реплика выполняет эти изменения в порядке, определенном первичной репликой.
6. Вторичные реплики рапортуют об успешном выполнении этих операций.
7. Первичная реплика шлет ответ клиенту. Любые ошибки, возникшие в какой-либо реплике, также отсылаются клиенту. Если ошибка возникла при записи в первичной реплике, то и запись во вторичные реплики не происходит, иначе запись произошла в первичной реплике, и подмножестве вторичных. В этом случае клиент обрабатывает ошибку и решает, что ему дальше с ней делать.

Из примера выше видно, что создатели разделили поток данных и поток управления. Если поток управления идет только в первичную реплику, то поток данных идет во все реплики. Это сделано, чтобы избежать создания узких мест в сети, а взамен широко использовать пропускную способность каждой машины. Так же, чтобы избежать узких мест и перегруженных связей, используется схема передачи ближайшему соседу по сетевой топологии. Допустим, что клиент передает данные чанк-серверам S1 ,..., S4 . Клиент шлет ближайшему серверу данные, пусть S1 . Он далее пересылает ближайшему серверу, пусть будет S2 . Далее S2 пересылает их ближайшему S3 или S4 , и так далее.
Также задержка минимизируется за счет использования конвейеризации пакетов передаваемых данных по TCP . То есть, как только чанк-сервер получил какую-то часть данных, он немедленно начинает их пересылать. Без сетевых заторов, идеальное время рассылки данных объемом B байт на R реплик будет B/T + RL , где T сетевая пропускная способность, а L - задержка при пересылке одного байта между двумя машинами.
GFS поддерживает такую операцию, как атомарное добавление данных в файл. Обычно, при записи каких-то данных в файл, мы указываем эти данные и смещение. Если несколько клиентов производят подобную операцию, то эти операции нельзя переставлять местами (это может привести к некорректной работе). Если же мы просто хотим дописать данные в файл, то в этом случае мы указываем только сами данные. GFS добавит их атомарной операцией. Вообще говоря, если операция не выполнилась на одной из вторичных реплик, то GFS , вернет ошибку, а данные будут на разных репликах различны.
Еще одна интересная вещь в GFS - это резервные копии (еще можно сказать мгновенный снимок) файла или дерева директорий, которые создаются почти мгновенно, при этом, почти не прерывая выполняющиеся операции в системе. Это получается за счет технологии похожей на сopy on write . Пользователи используют эту возможность для создания веток данных или как промежуточную точку, для начала каких-то экспериментов.

Операции, выполняемые мастером

Мастер важное звено в системе. Он управляет репликациями чанков: принимает решения о размещении, создает новые чанки, а также координирует различную деятельность внутри системы для сохранения чанков полностью реплицированными, балансировки нагрузки на чанк-серверы и сборки неиспользуемых ресурсов.
В отличие от большинства файловых систем GFS не хранит состав файлов в директории. GFS логически представляет пространство имен, как таблицу, которая отображает каждый путь в метаданные. Такая таблица может эффективно храниться в памяти в виде бора (словаря этих самых путей). Каждая вершина в этом дереве (соответствует либо абсолютному пути к файлу, либо к директории) имеет соответствующие данные для блокировки чтения и записи(read write lock). Каждое операция мастера требует установления некоторых блокировок. В этом месте в системе используются блокировки чтения-записи. Обычно, если операция работает с /d1/d2/.../dn/leaf , то она устанавливает блокировки на чтение на /d1, /d1/d2, ..., d1/d2/.../dn и блокировку, либо на чтение, либо на запись на d1/d2/.../dn/leaf . При этом leaf может быть как директорией, так и файлом.
Покажем на примере, как механизм блокировок может предотвратить создание файла /home/user/foo во время резервного копирования /home/user в /save/user . Операция резервного копирования устанавливает блокировки на чтение на /home и /save , а так же блокировки на запись на /home/user и /save/user . Операция создания файла требует блокировки на чтение /home и /home/user , а также блокировки на запись на /home/user/foo . Таким образом, вторая операция не начнет выполняться, пока не закончит выполнение первая, так как есть конфликтующая блокировка на /home/user . При создании файла не требуется блокировка на запись родительской директории, достаточно блокировки на чтение, которая предотвращает удаление этой директории.
Кластеры GFS , являются сильно распределенными и многоуровневыми. Обычно, такой кластер имеет сотни чанк-серверов, расположенных на разных стойках. Эти сервера, вообще говоря, доступны для большого количества клиентов, расположенных в той же или другой стойке. Соединения между двумя машинами из различных стоек может проходить через один или несколько свитчей. Многоуровневое распределение представляет очень сложную задачу надежного, масштабируемого и доступного распространения данных.
Политика расположения реплик старается удовлетворить следующим свойствам: максимизация надежности и доступности данных и максимизация использование сетевой пропускной способности. Реплики должны быть расположены не только на разных дисках или разных машинах, но и более того на разных стойках. Это гарантирует, что чанк доступен, даже если целая стойка повреждена или отключена от сети. При таком расположении чтение занимает время приблизительно равное пропускной способности сети, зато поток данных при записи должен пройти через различные стойки.
Когда мастер создает чанк, он выбирает где разместить реплику. Он исходит из нескольких факторов:

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

Как только число реплик падает ниже устанавливаемой пользователем величины, мастер снова реплицирует чанк. Это может случиться по нескольким причинам: чанк-сервер стал недоступным, один из дисков вышел из строя или увеличена величина, задающая число реплик. Каждому чанку, который должен реплицироваться, устанавливается приоритет, который тоже зависит от нескольких факторов. Во-первых, приоритет выше у того чанка, который имеет наименьшее число реплик. Во-вторых, чтобы увеличить надежность выполнения приложений, увеличивается приоритет у чанков, которые блокируют прогресс в работе клиента
Мастер выбирает чанк с наибольшим приоритетом и копирует его, отдавая инструкцию одному из чанк-серверов, скопировать его с доступной реплики. Новая реплика располагается, исходя из тех же причин, что и при создании.
Во время работы мастер постоянно балансирует реплики. В зависимости от распределения реплик в системе, он перемещает реплику для выравнивания загруженности дисков и балансировки нагрузки. Также мастер должен решать, какую из реплик стоит удалить. Как правило, удаляется реплика, которая находится на чанк-сервере с наименьшим свободным местом на жестких дисках.
Еще одна важная функция, лежащая на мастере - это сборка мусора. При удалении файла, GFS не требует мгновенного возвращения освободившегося дискового пространства. Он делает это во время регулярной сборки мусора, которая происходит как на уровне чанков, так и на уровне файлов. Авторы считают, что такой подход делает систему более простой и надежной.
При удалении файла приложением, мастер запоминает в логах этот факт, как и многие другие. Тем не менее, вместо требования немедленного восстановления освободившихся ресурсов, файл просто переименовывается, причем в имя файла добавляется время удаления, и он становится невидимым пользователю. А мастер, во время регулярного сканирования пространства имен файловой системы, реально удаляет все такие скрытые файлы, которые были удалены пользователем более трех дней назад (этот интервал настраивается). А до этого момента файл продолжает находиться в системе, как скрытый, и он может быть прочитан или переименован обратно для восстановления. Когда скрытый файл удаляется мастером, то информация о нем удаляется также из метаданных, а все чанки этого файла отцепляются от него.
Мастер помимо регулярного сканирования пространства имен файлов делает аналогичное сканирование пространства имен чанков. Мастер определяет чанки, которые отсоединены от файла, удаляет их из метаданных и во время регулярных связей с чанк-серверами передает им сигнал о возможности удаления всех реплик, содержащих заданный чанк. У такого подхода к сборке мусора много преимуществ, при одном недостатке: если место в системе заканчивается, а отложенное удаление увеличивает неиспользуемое место, до момента самого физического удаления. Зато есть возможность восстановления удаленных данных, возможность гибкой балансировки нагрузки при удалении и возможность восстановления системы, в случае каких-то сбоев.

Устойчивость к сбоям и диагностика ошибок

Авторы системы считают одной из наиболее сложных проблем частые сбои работы компонентов системы. Количество и качество компонентов делают эти сбои не просто исключением, а скорее нормой. Сбой компонента может быть вызван недоступностью этого компонента или, что хуже, наличием испорченных данных. GFS поддерживает систему в рабочем виде при помощи двух простых стратегий: быстрое восстановление и репликации.
Быстрое восстановление - это, фактически, перезагрузка машины. При этом время запуска очень маленькое, что приводит к маленькой заминке, а затем работа продолжается штатно. Про репликации чанков уже говорилось выше. Мастер реплицирует чанк, если одна из реплик стала недоступной, либо повредились данные, содержащие реплику чанка. Поврежденные чанки определяется при помощи вычисления контрольных сумм.
Еще один вид репликаций в системе, про который мало было сказано - это репликация мастера. Реплицируется лог операций и контрольные точки (checkpoints). Каждое изменение файлов в системе происходит только после записи лога операций на диски мастером, и диски машин, на которые лог реплицируется. В случае небольших неполадок мастер может перезагрузиться. В случае проблем с жестким диском или другой жизненно важной инфраструктурой мастера, GFS стартует нового мастера, на одной из машин, куда реплицировались данные мастера. Клиенты обращаются к мастеру по DNS, который может быть переназначен новой машине. Новый мастер является тенью старого, а не точной копией. Поэтому у него есть доступ к файлам только для чтения. То есть он не становится полноценным мастером, а лишь поддерживает лог операций и другие структуры мастера.
Важной частью системы является возможность поддерживать целостность данных. Обычный GFS кластер состоит из сотен машин, на которых расположены тысячи жестких дисков, и эти диски при работе с завидным постоянством выходят из строя, что приводит к порче данных. Система может восстановить данные с помощью репликаций, но для этого необходимо понять испортились ли данные. Простое сравнение различных реплик на разных чанк-серверах является неэффективным. Более того, может происходить несогласованность данных между различными репликами, ведущая к различию данных. Поэтому каждый чанк-сервер должен самостоятельно определять целостность данных.
Каждый чанк разбивается на блоки длиной 64 Кбайт . Каждому такому блоку соответствует 32 -битная контрольная сумма. Как и другие метаданные эти суммы хранятся в памяти, регулярно сохраняются в лог, отдельно от данных пользователя.
Перед тем как считать данные чанк-сервер проверяет контрольные суммы блоков чанка, которые пересекаются с затребованными данными пользователем или другим чанк-сервером. То есть чанк-сервер не распространяет испорченные данные. В случае несовпадения контрольных сумм, чанк-сервер возвращает ошибку машине, подавшей запрос, и рапортует о ней мастеру. Пользователь может считать данные из другой реплики, а мастер создает еще одну копию из данных другой реплики. После этого мастер дает инструкцию этому чанк-серверу об удалении этой испорченной реплики.
При добавлении новых данных, верификация контрольных сумм не происходит, а для блоков записывается новые контрольные суммы. В случае если диск испорчен, то это определится при попытке чтения этих данных. При записи чанк-сервер сравнивает только первый и последний блоки, пересекающиеся с границами, в которые происходит запись, поскольку часть данных на этих блоках не перезаписывается и необходимо проверить их целостность.

Что такое распределенные файловые системы?

Способность совместно использовать диски, каталоги, и файлы по сети это одно из наиболее значительных достижений современных информационных технологий. Эта способность может существенно сократить требования к дисковому пространству компьютеров и облегчить совместную работу пользователей. Компьютеры с Microsoft Windows и MacOS Apple / MacOS X используют для этого механизм совместного использования дисков и директорий. В системах Linux / Unix для тех же самых задач традиционно используется NFS сетевая файловая система.

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

Распределенная файловая система OpenAFS (http://www.openafs.org/ ) это Open Source-аналог известной коммерческой распределенной файловой системы AFS. Поддержка для распределенных файловых систем InterMezzo (http://www.inter-mezzo.org/) и Coda (http://coda.cs.cmu.edu/) уже присутствует в новых ядрах Linux из серии 2.4. Новые механизмы совместного использования файлов, основанные на Web (например, WebDAV (http://www.webdav.org/)), тоже могут использоваться в качестве файловых систем.

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

Введение в распределенные файловые системы.

Сейчас сетевые файловые системы называют <<распределенными>>. Этот термин отражает тот факт, что многие из этих файловых систем имеют гораздо больше возможностей, чем простая передача данных по сети. Носители данных, связанные с этими файловыми системами, не обязательно могут быть расположены на одном компьютере они могут быть распределены между многими компьютерами.

Распределенные файловые системы OpenAFS и Coda имеют собственные механизмы управления разделами, которые упрощают возможности хранения общедоступной информации. Они так же поддерживают дублирование способность делать копии разделов и сохранять их на других файловых серверах. Если один файловый сервер становится недоступным, то все равно к данным, хранящимся на его разделах, можно получить доступ с помощью имеющихся резервных копий этих разделов.

Самое главное различие между подходом Windows / MacOS (совместное использование каталогов и дисков) и подходом Linux, MacOS X и других Unix-подобных многопользовательских операционных систем в том, как эти операционные системы используют и организовывают разделы. Windows / MacOS экспортируют разделы как отдельные каталоги или диски, и удаленные системы, которые хотят обратиться к общедоступным устройствам, должны обязательно подключить их к себе.

Когда самый высокий уровень организации в файловой системе это раздел диска (например, как в файловых системах Windows), рабочие станции клиентов для получения доступа к этим данным должны обязательно подключиться к разделу и назначить ему отдельную букву в своей локальной раскладке (например, диск E, F, G, и т.д). Буквы могут быть назначены сетевым разделам в пользовательских и групповых профилях Windows (для стандартизации). Но, к сожалению, не на всех компьютерах расположение букв может быть одинаковым. Например, на компьютере с большим количеством жестких дисков и разделов нужные буквы могут быть заняты, и поэтому придется давать сетевым разделам другие обозначения.

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

Современные распределенные файловые системы типа OpenAFS или Coda включают в себя специальные сервисы для управления разделами. Это позволяет вам смонтировать разделы различных файловых серверов в центральную иерархию директорий, поддерживаемую файловыми системами. OpenAFS использует центральный каталог, называемый <>, а Coda использует <>. Эти иерархии директорий доступны всем клиентам распределенной файловой системы, и выглядят одинаково на любой из клиентск х рабочих станций. Это дает возможность пользователям работать со своими файлами одинаково на любом компьютере. Если ваш настольный компьютер не работает, вы совершенно спокойно можете использовать любой другой все ваши файлы находятся в безопасности на сервере.

Распределенные файловые системы, предоставляющие одни и те же данные многим различным компьютерным системам, дают пользователям возможность использовать любую операционную систему, лучше всего подходящую для их задач. Пользователи Macintosh могут пользоваться всеми преимуществами графических инструментальных средств, доступных в Mac OS, и одновременно хранить свои данные на централизованных файловых серверах. Пользователи Windows так же могут иметь доступ к устойчивой глобальной файловой системе. Распределенные файловые системы особенно привлекательны при попытке координации работы между группами, расположенными в различных городах, государствах, или даже в разных странах. Преимущество общие данные всегда доступны по сети, независимо от вашего местонахождения.

Проблемы администрации распределенных файловых систем.

Использование распределенных файловых систем дает системным администраторам не только новые возможности, но и новые проблемы. Но распределенные системы способны упростить многие из стандартных административных задач. В сетевой среде пользователи должны иметь возможность зайти в сеть под своим именем с любого компьютера. Это значит, что механизм входа в сеть (или аутентификации) тоже должен быть сетевым. Поэтому в среде распределенной файловой системы файлы групп и паролей, расположенные на индивидуальных компьютерах, вторичны по отношению к сетевым механизмам аутентификации (таким, как Kerberos или NIS, которые предоставляют пользователям возможность работать на любом компьютере). Но стандартные локальные механизмы проверки пароля все же должны существовать, чтобы администраторы могли выполнять на локальных компьютерах необходимые задачи. Сохранение общих данных на централизованных файловых серверах (а не на индивидуальных компьютерах) упрощает такие административные задачи, как резервирование и восстановление файлов и каталогов. Это так же централизует такие стандартные административные задачи, как контроль за использованием файловой системы, и представляет новые возможности управления хранением данных например, балансирование загрузки.

Распределенные файловые системы типа OpenAFS и Coda обеспечивают встроенные логические системы управления разделами, которые дают администраторам возможность переместить интенсивно используемые данные на более мощные или менее используемые компьютеры. Если распределенная файловая система поддерживает дублирование, копии интенсивно используемых данных могут распределяться между многими файловыми серверами. Это может уменьшить нагрузку на сеть, и облегчить работу серверов. Распределенные файловые системы используют логические разделы вместо физических дисковых разделов, и это позволяет легко добавить в сеть новую свободную память прямо во время работы. (Для добавления нового диска в локальный компьютер пришлось бы потратить некоторое время).

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

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

Поддержка автономной работы с данными.

Использование распределенной файловой системы увеличивает зависимость компьютерных систем от сети. Эта зависимость от данных, к которым люди могут обращаться только по сети, вызывает некоторые интересные проблемы для пользователей лаптопов/мобильных компьютеров, которые нуждаются в доступе к своим данным даже тогда, когда доступ к сети невозможен. Это называется <<автономная работа>> система должна функционировать, если ресурсы, которые обычно присутствуют в сети (например, пользовательские данные), по каким-то причинам не доступны. Даже Windows обеспечивает графический интерфейс для возможности маркировки файлов, с которыми вы хотите работать, когда вы отключены от сети, и для синхронизации этих файлов, когда вы соединяетесь повторно.

Распределенные файловые системы Coda и InterMezzo, которые являются в настоящее время доступными для Linux, тоже обеспечивают интегрированную поддержку для автономной работы. Так же сейчас ведется работа над обеспечением этой возможности для файловых систем NFS. Coda и InterMezzo уже поддерживаются ядром Linux поддержка Intermezzo встроена в ядро, начиная с версии 2.4.5, а Coda вообще была интегрирована в ядро 2.4 с самого начала.

Coda распределенная файловая система с происхождением из OpenAFS, которая разрабатывается в университете Carnegie Mellon с 1987 года. InterMezzo относительно новая распределенная файловая система, упор в разработке которой сделан на высокой доступности, гибком дублировании каталогов, поддержке автономных операций, и постоянном кэшировании. Создатели InterMezzo были вдохновлены CMU Coda, но этот проект не основан на исходном тексте Coda. Начальный создатель InterMezzo, Питер Браам, был главой проекта Coda в CMU в течение нескольких лет, и после этого он сам начал разрабатывать InterMezzo и несколько других проектов.

Расширение файловых систем с помощью Web.

До создания распределенных файловых систем совместное использование файлов через сеть ограничивалось простыми передачами файлов с помощью использования протокола передачи файлов FTP (File Transfer Protocol). Появление Всемирной паутины в значительной степени упростила процесс работы с FTP теперь не нужно знать команды, потому что протокол FTP интегрирован в большинство броузеров. Способность легко передавать файлы через Web также вела к расширению Паутины и существенному улучшению основного протокола передачи гипертекста

HTTP (HyperText Transfer Protocol), который сейчас является основанием для многих систем распределенного использования файлов.

Самая известная из них это WebDAV, которая расшифровывается как <> (Web-enabled Distributed Authoring and Versioning). WebDAV это набор расширений к протоколу HTTP, обеспечивающий совместную среду для пользователей, которая позволяет им скачивать, упорядочивать и редактировать файлы, хранящиеся на Web-серверах.

Поддержка WebDAV встроена во многие популярные Web-серверы, например Apache, где это основывается на опознавательных механизмах сервера. (От простых файлов.htaccess до интегрированных NIS, LDAP, или даже механизма аутентификации Windows). Использование WebDAV для доступа и модификации файлов через Web встроено в операционные системы Mac OS X, в новые версии Microsoft Internet Explorer, а так же доступно и в Linux при использовании таких приложений, как менеджер файлов Nautilus. Хотя это и не файловая система в традиционном смысле, но вы можете даже смонтировать WebDAV в Линуксе, используя загружаемый модуль ядра под названием davfs.

WebDAV обеспечивает такие стандартные для распределенных систем возможности, как блокировка файлов, создание, переименование, копирование, удаление файлов, а так же поддерживает такие продвинутые возможности, как meta-данные файла (более подробная информация о файле заголовок, тема, создатель, и т.д). В ближайшем будущем WebDAV будет включать интегрированную поддержку управления версиями, которая упростит работу многих пользователей над общими файлами, отслеживая изменения, авторов этих изменений, и другие аспекты общего использования документа. Эти возможности контроля над версиями обеспечиваются в соответствии с протоколом DeltaV, который активно разрабатывается Рабочей группой DeltaV (http://www.webdav.org/deltav) подразделением Проектировочной группы Интернета (IETF Internet Engineering Task Force). Некоторые проекты, например, Subversion (http://subversion.tigris.org/) (WebDAV и DeltaV-основанная замена стандарту CVS), уже доступны в альфа-версии. Subversion обеспечивает систему контроля над версиями и сохранение архива файла на основе базы данных, имеющей API языка C, и моделирует версионную файловую систему, легко доступную через Web.