Пошаговое руководство по использованию распределенной файловой системы. Современные распределенные файловые системы для Linux: Основные сведения

Распределенная файловая система (Distributed File System – DFS) предоставляет возможность просто и прозрачно управлять сетевыми дисками. Вместо использования физического расположения сетевого ресурса (по имени сервера), пользователи могут просто подключаться к корню распределенной файловой системы.

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

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

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

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

Репликация данных выполняется Службой репликации файлов (Fire Replication Service - FRS) , которая также занимается репликацией папки SYSVOL с объектами групповой политики Active Directory.

При первой настройке распределенной файловой системы необходимо указать начальную точку для дерева распределенной файловой системы. Она известна под именем корень распределенной файловой системы. Существует два типа корня распределенной файловой системы:

• Изолированный корень (Standalone) - конфигурация пространства имен распределенной файловой системы и архитектура хранятся локально на корневом сервере. Путь доступа (путь UNC) к корню начинается с имени сервера. Изолированный корень позволяет существование только одного корня распределенной файловой системы для пространства имен распределенной файловой системы. Это значит, что корень не предоставляет устойчивости к ошибкам и представляет единственную точку отказа при доступе к данным.
• Домен (Domain) - пространство имен распределенной файловой системы храниться в Active Directory. При использовании домена распределенной файловой системы можно создавать несколько устойчивых к ошибкам корней распределенной файловой системы, а клиенты будут получать доступ к распределенной файловой системе по имени домена. Использование интеграции в Active Directory позволяет клиентам автоматически быть перенаправленными к корню распределенной файловой системы в локальном сайте Active Directory, что имеет определенные преимущества в больших сетях, где инфраструктура распределенной файловой системы может простираться на несколько сайтов.

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

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

Назначение и возможности DFS

Распределенная файловая система DFS (Distributed File System ) появилась как стандартный компонент еще в Win2k. Ее задача – облегчить управление, доступ и поиск данных в сети. Для этого файловые ресурсы, находящиеся на разных компьютерах, объединяются в единое логическое пространство имен. Пользователь, вместо того чтобы запоминать имена всех общих сетевых ресурсов (Universal Naming Convention, UNC), вроде \\Server\Folder, будет обращаться к единому пространству UNC-имен, в котором объединены все серверы и общие ресурсы сети. А на каком конкретно компьютере находится запрашиваемый файл, уже забота DFS , пользователю не нужно беспокоиться о реальном расположении файла. При обращении клиента он просто перебрасывается на нужный ему каталог. На месте источника, на который указывает ссылка, может быть любая операционная система, к ресурсам которой можно обратиться, используя UNC (Windows, Linux, xBSD, NetWare). Физические объекты, связанные ссылками с DFS , называются целевыми объектами (targets) или репликами (replics).

Но удобство для пользователей и администраторов – далеко не самое важное из основных преимуществ DFS . Дело в том, что с одним логическим именем может быть связано несколько общих ресурсов, в которых хранится идентичная информация. Такой набор альтернативных общих ресурсов, связанных с одним логическим именем DFS , называется набором реплик. И если общие ресурсы находятся в одном пространстве доменного корня DFS и располагаются на серверах Win2k или Win2k3, есть возможность настроить автоматическую синхронизацию информации между ними. Пользователь, обратившийся к DFS , обычно перенаправляется к ближайшей реплике, и если она не доступна, он будет перенаправлен к альтернативному ресурсу. Для уменьшения нагрузки на сервер DFS на стороне клиента данные кэшируются, поэтому при частом обращении к одному и тому же ресурсу каждый запрос к DFS не производится. Таким образом, автоматическое резервирование важной информации , реализованное в DFS , еще и повышает отказоустойчивость всей системы (выход одного сервера или дискового устройства не повлияет на работу пользователей). Хотя следует помнить, что DFS не создавалась для работы часто с обновляющимися данными, и особенно для тех случаев, когда файл одновременно может обновляться в нескольких местах (в DFS остается та версия файла, где были внесены последние изменения).

В реализации DFS в Win2k можно было разместить только одно пространство имен, в Win2k3 их может быть уже несколько. В Win2k3 R2 появилась новая версия этой системы – DFS Namespaces , в которой многие вопросы уже решены. За репликацию данных в Win2k3 SP1 и SP2 отвечает FRS (File Replication Server ), в Win2k3 R2 – DFS Replicatio n. Главным их отличием является то, что в FRS самым маленьким объектом, подлежащим репликации, является файл, в DFS Replication используется более развитая технология RDC (Remote Differential Compression ), которая умеет копировать только изменившиеся части файла, а функция cross-file RDC меньше нагружает канал при копировании новых файлов. Таким образом, использование DFS еще и уменьшает нагрузку на сеть, что особенно актуально для удаленных офисов с недостаточной пропускной способностью. В службе DFS не используется никаких дополнительных средств обеспечения безопасности. При обращении к targets проверяются только права доступа файловой системы и установленные для этих объектов разрешения в каталоге Active Directory.

Эти разные корни

Начальной точкой для всех имен дерева DFS служит корень распределенной файловой системы. Фактически корень – это некоторый общий ресурс, находящийся на сервере, все остальные логические имена системы DFS будут подключаться как следующий иерархический уровень. Корни в DFS могут быть двух видов, каждый отличается способами хранения данных и возможностями. Изолированный (автономный) корень (Standalone DFS ) не связан с Active Directory, и все ссылки на сетевые ресурсы хранятся в реестре самого сервера DFS . Такой корень не использует DFS Replication , то есть не предполагает дублирование информации на другие ресурсы, и поэтому не обеспечивает отказоустойчивость. При выходе из строя сервера DFS вся иерархия становится не доступной, хотя пользователи могут обращаться к ресурсам напрямую. К слову, несколько Standalone DFS серверов способны работать в кластере, поэтому эта проблема может быть решена. Если сервер DFS является членом домена, используется доменный корень (Domain-based DFS ). При таком варианте можно подключать несколько реплик и использовать DFS Replication для репликации как самого корня, так и ссылок DFS . Если в Domain-based DFS корни находятся на компьютерах под управлением Win2k и Win2k3, то такой корень называется “Mixed mode domain DFS “.

При доменном DFS вся информация о пространстве имен находится на контроллере домена, к которому периодически обращается сервер DFS . Учитывая синхронизацию между DFS в домене, которая становится все более сложной при каждом изменении структуры, эти запросы могут быть узким местом в системе, поэтому в этом случае также есть некоторые ограничения. Так в Win2k существовало ограничение на 16 корней для одного пространства имен. В Win2k3 это ограничение снято, так как сервер DFS теперь может обращаться к любому DC, а не только к эмулятору PDC. Второе ограничение доменных корней связано с тем, что вся структура хранится в специальном объекте, который также необходимо дублировать на всех DC при любом малейшем изменении в структуре DFS . В документации рекомендуется ограничивать максимальный размер объекта 5-тью Мб, что приблизительно соответствует 5000 ссылкам (каталогам). Эта величина зависит от многих параметров, длины имени ссылок, наличия и размера комментариев, которые также хранятся в этом объекте. Но в среднем DFS редко когда превышает 50-100 ссылок, и после первоначальной настройки она остается в основном статичной, а значит, часто дублироваться не будет, и этих ограничений достигнуть просто не удастся. Кстати, в будущей Windows 2008 ограничение в 5000 ссылок уже снято, но для этого все серверы должны работать под управлением Longhorn. Для Standalone DFS рекомендованный лимит ссылок на порядок выше и составляет 50000 ссылок .

Настройка DFS

Для примера настроим DFS на компьютере под управлением Win2k3 с SP2, все настройки в SP1 аналогичны. В настройках DFS в R2 и Win2k есть некоторые отличия, но не настолько глобальные, чтобы не разобраться самостоятельно. Все управление распределенной файловой системой выполняется централизованно с помощью оснастки MMC “Распределенная файловая система DFS “, которую можно вызвать во вкладке “Администрирование” Панели управления Windows. С ее помощью можно создавать и удалять корни, подключаться к любым корням DFS . Удобно, что в одной вкладке может отображаться несколько корней DFS . В случае работы корня в “Mixed mode domain DFS “, то есть когда реплики и корни DFS располагаются на компьютерах под управлением разных версий Windows, управление DFS необходимо производить с компьютера, работающего под Win2k3. Как вариант, можно установить пакет Win2k3 Administration Tools Pack (adminpak.msi), который лежит в свободном доступе на сайте корпорации. В этом случае для управления можно использовать и компьютеры с WinXP. Информацию по этому пакету найдешь по адресу support.microsoft.com/kb/304718 . Кроме этого, для работы с DFS также можно использовать утилиты командной строки dfscmd.exe и dfsutil.exe. Последняя имеет больше возможностей, но по умолчанию не включена в состав операционной системы, чтобы ее использовать, необходимо установить пакет Win2k3 Support Tools. Обрати внимание, что для успешной установки Support Tools требуется скачать два файла: suptools.msi и support.cab.

Для создания нового корня вызываем оснастку, щелкаем мышкой по заголовку и в контекстном меню выбираем “Создать корень” (New Root), как вариант, можно выбрать аналогичный пункт в меню “Действие”. Появляется Мастер создания нового корня (New Root Wizard), следуем его подсказкам. На втором шаге выбираем тип создаваемого корня (доменный или изолированный), указываем несущий домен и сервер. После проверки соединения с выбранным сервером вводим имя корня. Обрати внимание, как будет выглядеть UNC путь к новому корню, по умолчанию \\server\nameshare. Так как на данный момент общего каталога не существует, на следующем шаге нужно выбрать локальный каталог, который будет использоваться в качестве общего. Этот каталог не содержит реальных данных, в нем будут находиться ссылки, указывающие на физическое расположение данных. Мастер создает ресурсы, разрешающие чтение и выполнение членам группы Пользователи. При необходимости следует скорректировать разрешения. Теперь нажимаем кнопку Готово, новый корень появится в окне консоли. Если сервер работает под управлением Win2k3, аналогичным образом создаем и другие корни. С помощью команды Проверить статус (Check Status), вызываемую из меню консоли или контекстного меню, можно проверить состояние реплики. Состояние будет указано в одноименном столбце и рядом с именем появится кружок с отметкой. Если она зеленого цвета, значит, все нормально. Для проверки можно зайти по указанному UNC или использовать на локальном компьютере команду «net share» или «net view computer_name» с удаленного. Команда «dfsutil /Root:\\server\share /View» покажет информацию о DFS .

>dfsutil /Root:\\server.com\first /View
DFS Utility Version 5.2 (built on 5.2.3790.3959)
Domain Root with 0 Links
Root Name="\\SERVER\first" Comment="first Root" State="1" Timeout="300"
Target Server="GRINDERS" Folder="first" State="2"

После создания корня его можно опубликовать в Active Directory. Для этого в контекстном меню выбираем Свойства, переходим на вкладку Публикация и устанавливаем флажок “Опубликовать этот корень в Active Directory”. Доменные корни публикуются автоматически и в обязательном порядке.

Создание ссылок

После создания корня можно начинать подключать общие ресурсы. Для чего в том же контекстном меню выбираем пункт Создать ссылку (New Link). В появившемся окне “Новая ссылка”, в поле “Имя ссылки”, вводим имя ссылки, под которым она будет доступна в DFS, затем чуть ниже UNC-путь к целевому каталогу (должен уже существовать). Для поиска общих ресурсов можно использовать кнопку Обзор, чуть ниже можно изменить время кэширования этой ссылки для клиентов DFS (по умолчанию 1800 сек). По окончании нажимаем кнопку ОК. Команда «dfsutil /view» должна показать состояние всех подключенных ссылок и их свойства. Если в сети работает несколько серверов, есть возможность добавить реплику, указывающую на альтернативную ссылку. Реплика на корень или отдельный объект создается аналогично, только в первом случае в контекстном меню выбираем пункт “Создать корневую целевую папку”, а во втором – “Создать папку”.

Общие ресурсы, с которыми будет производиться репликация, должны располагаться в разделах с файловой системой NTFS на компьютерах, работающих под управлением серверных версий Windows от 2000 (лучше 2003). В поле “Путь к целевой общей папке” появившегося окна вводим или при помощи кнопки Обзор указываем общий ресурс, располагающийся на другом компьютере. В том случае если для синхронизации информации между этими ресурсами планируется использовать альтернативные программы (или синхронизация будет производиться вручную), следует снять флажок “Добавить эту целевую папку к набору репликации” (Add this target to the replication set). Нажимаем ОК, и появляется Мастер настройки репликации (Configure Replication Wizard), который поможет выбрать мастер-реплику и топологию репликации. На первом шаге указываем каталог, который будет использоваться в качестве основного целевого, вся информация из этого каталога затем будет скопирована в другую папку. Последняя должна быть пустой, если в ней есть файлы, они будут скопированы во временный каталог, а затем удалены. Если общий ресурс по каким-либо причинам не подходит для репликации (например, расположен не в разделе с NTFS), он будет отмечен красным крестиком, при попытке перейти к следующему шагу мастер предложит указать другую ссылку или закончить работу.

Нажатием кнопки “Промежуточное хранение ” (Staging Folder ) можно изменить расположение каталога, который будет использоваться для временного хранения реплицируемых данных. По умолчанию этот каталог размещается в разделе, отличном от того, на котором находится общий ресурс, связанный с DFS . Далее мастер предложит выбрать топологию репликации. Необходимо будет указать один из следующих вариантов:

• Кольцо (Ring) - все реплики обмениваются информацией с двумя соседними;
• Звезда (Hub and spoke) - указывается основная ссылка, с которой и будут обмениваться информацией все остальные реплики;
• Полная сетка (Mesh) - все реплики обмениваются друг с другом;
• Особая (Custom) - позднее администратор самостоятельно настроит репликацию для каждой пары серверов.

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

После создания реплики для ссылки соответствующий ей значок в окне оснастки изменится. В контекстном меню также появятся два новых пункта: Отобразить/Скрыть статус репликации и Остановить репликацию. В поле статуса репликации может быть один из трех результатов. Если процесс репликации завершен нормально, на значках будут зеленые флажки. Красный крестик на значке реплики укажет, что она в данный момент недоступна, в поле Состояние подпись изменится на Автономный. Если в проверяемой ссылке недоступны лишь некоторые реплики, в значке появится желтый восклицательный знак.

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

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

Для принудительной репликации информации, хранящейся на определенном сервере, можно воспользоваться утилитой NtfrsUtl.exe, которая входит в состав пакета Support Tools . Команда проста: «ntfrsutl poll /now server.com». Чтобы увидеть установленные временные интервалы, через которые производится репликация, следует ввести «ntfrsutl poll». Все установки доступны по команде «ntfrsutl sets server.com».

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

Администратору для контроля следует почаще заглядывать в журнал “Администрирование – Просмотр событий – Служба репликации файлов”, где можно найти информацию обо всех событиях, происходящих со службой FRS.

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

На этой странице

Введение

Поскольку в сетях широко распространены общие файлы, администраторы все чаще сталкиваются с проблемами при предоставлении доступа пользователям к необходимым им данным. В операционной системе Windows 2000 распределенная файловая система предоставляет администраторам механизм для создания логических представлений каталогов и файлов независимо от того, где эти файлы физически находятся в сети. Кроме того, благодаря использованию DFS обеспечивается отказоустойчивость сетевых ресурсов хранения. В этом руководстве описано, как использовать мастер создания нового корня DFS (New DFS Root Wizard), а также другие средства для работы с DFS.

Предварительные условия

В примерах, приведенных в этом документе, подразумевается, что уже сконфигурирована и используется служба каталогов Active Directory, и у Вас имеются права администратора домена и сервера, на котором будет конфигурироваться DFS. Для этой цели Вы можете воспользоваться базовой инфраструктурой, описанной в Пошаговом руководстве по развертыванию базовой инфраструктуры Windows 2000 Server (Step-by-Step Guide to a Common Infrastructure for Windows 2000 Server Deployment) http://www.microsoft.com/windows2000/techinfo/planning/server/serversteps.asp (EN).

Использование оснастки Распределенная файловая система DFS

В этом пошаговом руководстве описывается, как использовать оснастку . Хотя установка службы DFS производится автоматически при установке ОС Windows 2000 Server, Вы должны сконфигурировать DFS для обеспечения доступа клиентов к общим сетевым ресурсам. Для выполнения этих процедур Вам необходимо войти на контроллер домена под учетной записью администратора домена.

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

Вы можете также создать изолированный сервер DFS, однако, при этом Вы не получите преимуществ службы каталогов Active Directory, и не будет обеспечена отказоустойчивость корневого уровня. Контроллер домена может быть несущим только для одного корня DFS, но в действительности нет ограничений на количество корней DFS в каждом домене. Каждый корень DFS могут поддерживать до 32 контроллеров домена. В домене может поддерживаться несколько корневых томов DFS. Дополнительные компьютеры, которые поддерживают корневые или дочерние узлы (ссылки), позволяют улучшить распределение нагрузки, повысить отказоустойчивость и обеспечить обслуживание сетевых клиентов на основе их принадлежности определенным сайтам сети. Ссылки DFS, указанные в корне, задаются с помощью UNC-пути, доступного для сервера и клиентов DFS.

В этом руководстве Вам будет предложено создать отказоустойчивый корень DFS.

Начало работы с DFS

Если у Вас имеется несколько контроллеров домена, обеспечивающих отказоустойчивость DFS, помните, что для отказоустойчивости DFS используется служба каталогов Active Directory, которая хранит сведения о топологии. Следовательно, необходимо, чтобы сведения о топологии реплицировались между контроллерами домена. Обновление конфигурации DFS изначально производится на одном из серверов домена Windows 2000, который содержит корень DFS. Различные контроллеры домена могут содержать различные данные о текущем состоянии конфигурации DFS, пока мастером репликации не будут реплицированы сведения об изменениях конфигурации DFS между всеми контроллерами доменов. Корень DFS и все его ссылки хранятся в виде единого элемента, имеющего тип – большой бинарный объект (Binary Large Object, BLOB). После осуществления изменений в этом большом бинарном объекте, необходимо выполнение репликации всего бинарного объекта целиком так, чтобы эти изменения были отражены на всех контроллерах домена в домене.

Репликация данных между двумя контроллерами домена, расположенными в пределах одного сайта занимает около пяти минут, и как минимум 15 минут для контроллеров домена, находящихся в различных сайтах. Пока репликация не будет выполнена, конфигурация DFS , отображаемая с помощью оснастки Распределенная файловая система DFS (Distributed File System)на различных клиентах, может различаться. Вы можете воспользоваться кнопкой Обновить (Refresh) для обновления отображаемых сведений о текущем состоянии хоста DFS.

Если Вы выполнили описанные выше процедуры, то сейчас в Вашей сети имеется пустой корень DFS в службе каталогов Active Directory. Чтобы эта общая папка представляла интерес для пользователей, Вам необходимо опубликовать в ней нелокальные общие папки данного пространства имен DFS.

Для публикации нелокальной общей папки

	Щелкните правой кнопкой мыши на созданном Вами корневом объекте DFS и затем нажмите Создать ссылку DFS (New DFS Link) .
	Щелкните правой кнопкой мыши на объекте \\Reskit.com\Books .
	Определите каталог для данной ссылки. В нашем примере названием ссылки будет ART . Укажите действительный UNC-адрес общей папки Windows 2000, находящейся в Вашей сети, в поле Переадресовать пользователя на эту общую папку (Send the user to this network path) . Для этих целей можно также воспользоваться кнопкой Обзор (Browse) . В нашем примере используется общая папка Architecture , расположенная на сервере BR3-VAN-SRV-01 , который входит в домен Vancouver . Примечание. Эта общая папка была предварительно создана для этого упражнения. Рисунок 3 – Выбор общей папки
	Нажмите кнопку OK . Вы можете опционально указать комментарий и значение таймаута. Значение таймаута определяет число секунд, на которое клиентами кэшируется указатель, и по истечении которого они должны будут обновить указатель с одного из несущих DFS-серверов.
	Если имеется несколько серверов для конфигурирования (например, на двух серверах, один из которых находится в Хартфорде, а второй – в Сиэтле, содержится идентичная информация), то Вы можете добавить их для этого набора реплик. Для этого на значке общей папки, опубликованной в корневом DFS, щелкните правой кнопкой мыши и нажмите Создать реплику (New Replica) .
	Выберите общую папку \\Reskit\BR2-RES-SRV-01\Engineering Diagrams и нажмите кнопку OK .
	Нажмите OK еще раз.
	Щелкните правой кнопкой мыши на подключенной ссылке и нажмите Политика репликации (Replication Policy) . Выберите каждую общую папку и нажмите кнопку Подключить (Enable) , затем нажмите кнопку OK .

Примечание . Для возможности использования репликации общие папки корня или ссылок DFS должны располагаться на томах NTFS 5.0, находящихся на контроллере домена Windows 2000 или на рядовых серверах. Флагом Основной (Primary) помечены конкретные файлы и папки серверов, указанные для принудительной начальной репликации, после выполнения которой будут осуществляться штатные репликации.

Рисунок 5 – Политика репликации
На рисунке, представленном ниже, изображена оснастка DFS после выполнения описанных процедур.

Рисунок 6 – Корень DFS

Проверка механизма DFS

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

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

Чтобы получить доступ к корню DFS с помощью Проводника (Windows Explorer)

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

Примечание . В данное время, DFS поддерживает службу кластеров (Microsoft Cluster Service), используя только DFS на основе отдельных компьютеров, поэтому Вы не можете создать отказоустойчивую топологию DFS, работающую в кластере, поскольку кластер выступает в роли единого компьютера.

Репликация

Если Вы используете отказоустойчивую распределенную файловую систему в окружении, в котором имеется множество контроллеров домена, важно определить время, которое необходимо для выполнения репликации данных между контроллерами домена, требуемое для конкретной конфигурации DFS. Для немедленной репликации Вам понадобиться инструмент REPLMon , который Вы можете установить из папки support\tools, находящейся на компакт-диске Windows 2000 Server.

Клиенты, которые до сих пор используют ранние версии операционных систем (например, Windows NT 4.0), и которым необходимо использовать возможности DFS, не смогут воспользоваться отказоустойчивостью корня DFS. Однако, такие клиенты могут напрямую подключаться к конкретным корням DFS, которые входят в состав отказоустойчивой распределенной файловой системы. В таком случае при использовании команды Net use необходимо заменить имя домена на имя конкретного компьютера.

Рабочие станции, работающие под управлением Windows NT и использующие DFS, могут также определить, какую общую папку они используют в текущий момент. Для этого необходимо воспользоваться вкладкой DFS , находящейся в диалоговом окне Свойства (Properties) общей папки в проводнике (Windows Explorer).

Примечание. Большинство административных функций могут быть выполнены из командной строки или с помощью файла-сценария с использованием утилиты DFSCMD.EXE. Введите в командной строке DFSCMD /? для получения краткой справки по команде.

Рисунок 7 – Просмотр свойств DFS
При необходимости Вы всегда можете изменить свойства этого объекта.

Также Вы можете опубликовать Ваш отказоустойчивый DFS корень, как общую папку в Active Directory, и получать к ней доступ с использованием обозревателя службы каталогов. Откройте оснастку Active Directory – пользователи и компьютеры (Active Directory Users and Computers) , щелкните правой кнопкой мыши на объекте Вашего домена, нажмите Создать (New) , выберите опцию Общие папки (Shared Folders) и введите соответствующую информацию.

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

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

Понятие файлового сервиса и файлового сервера .

Файловый сервис - это то, что файловая система предоставляет своим клиентам, т.е. интерфейс с файловой системой.
Файловый сервер - это процесс, который реализует файловый сервис.

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

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

5.1 Архитектура распределенных файловых систем

Распределенная система обычно имеет два существенно отличающихся компонента - непосредственно файловый сервис и сервис директорий.

5.1.1 Интерфейс файлового сервера

Для любой файловой системы первый фундаментальный вопрос - что такое файл. Во многих системах, таких как UNIX и MS-DOS, файл - не интерпретируемая последовательность байтов. На многих централизованных ЭВМ (IBM/370) файл представляется последовательность записей, которую можно специфицировать ее номером или содержимым некоторого поля (ключом). Так, как большинство распределенных систем базируются на использовании среды UNIX и MS-DOS, то они используют первый вариант понятия файла.

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

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

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

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

5.1.2 Интерфейс сервера директорий

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

Определяет алфавит и синтаксис имен. Для спецификации типа информации в файле используется часть имени (расширение) либо явный атрибут.

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

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

Прозрачность именования .
Две формы прозрачности именования различают - прозрачность расположения (/server/d1/f1) и прозрачность миграции (когда изменение расположения файла не требует изменения имени).

Имеются три подхода к именованию:


• машина + путь;
• монтирование удаленных файловых систем в локальную иерархию файлов;
• единственное пространство имен, которое выглядит одинаково на всех машинах.

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

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

5.1.3 Семантика разделения файлов

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

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

Транзакции
Процесс выдает операцию НАЧАЛО ТРАНЗАКЦИИ, сообщая тем самым, что последующие операции должны выполняться без вмешательства других процессов. Затем выдает последовательность чтений и записей, заканчивающуюся операцией КОНЕЦ ТРАНЗАКЦИИ. Если несколько транзакций стартуют в одно и то же время, то система гарантирует, что результат будет таким, каким бы он был в случае последовательного выполнения транзакций (в неопределенном порядке). Пример - банковские операции.

5.2 Реализация распределенных файловых систем

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

5.2.1 Использование файлов

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

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

5.2.2 Структура системы

Есть ли разница между клиентами и серверами ? Имеются системы, где все машины имеют одно и то же ПО и любая машина может предоставлять файловый сервис. Есть системы, в которых серверы являются обычными пользовательскими процессами и могут быть сконфигурированы для работы на одной машине с клиентами или на разных. Есть системы, в которых клиенты и серверы являются фундаментально разными машинами с точки зрения аппаратуры или ПО (требуют различных ОС, например).

Второй вопрос - должны ли быть файловый сервер и сервер директорий отдельными серверами или быть объединенными в один сервер. Разделение позволяет иметь разные серверы директорий (UNIX, MS-DOS) и один файловый сервер. Объединение позволяет сократить коммуникационные издержки.

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

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

Последний важный вопрос - должны ли серверы хранить информацию о клиентах.

Серверы с состоянием . Достоинства.

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

Серверы без состояния . Достоинства.

• устойчивость к ошибкам.
• не требуется операций ОТКРЫТЬ/ЗАКРЫТЬ.
• не требуется память для таблиц.
• нет ограничений на число открытых файлов.
• нет проблем при крахе клиента.

5.2.3 Кэширование

Во-первых, хранение файлов на дисках сервера. Нет проблемы когерентности, так как одна копия файла существует. Главная проблема - эффективность, поскольку для обмена с файлом требуется передача информации в обе стороны и обмен с диском.

Кэширование в памяти сервера. Две проблемы - помещать в кэш файлы целиком или блоки диска, и как осуществлять выталкивание из кэша.

Коммуникационные издержки остаются.

Избавиться от коммуникаций позволяет кэширование в машине клиента.

Кэширование на диске клиента может не дать преимуществ перед кэшированием в памяти сервера, а сложность повышается значительно.

Поэтому рассмотрим подробнее организацию кэширования в памяти клиента.

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

Когерентность кэшей.

Алгоритм с отложенной записью .
Через регулярные промежутки времени все модифицированные блоки пишутся в файл. Эффективность выше, но семантика непонятная пользователю (UNIX).

Алгоритм записи в файл при закрытии файла .
Реализует семантику сессий. Не намного хуже случая, когда два процесса на одной ЭВМ открывают файл, читают его, модифицируют в своей памяти и пишут назад в файл.

Алгоритм централизованного управления .
Можно выдержать семантику UNIX, но не эффективно, ненадежно, и плохо масштабируется.

5.2.4 Размножение

1. Повысить надежность.
2. Повысить доступность (крах одного сервера не вызывает недоступность размноженных файлов.
3. Распределить нагрузку на несколько серверов.
4. Явное размножение (непрозрачно). В ответ на открытие файла пользователю выдаются несколько двоичных имен, которые он должен использовать для явного дублирования операций с файлами.
5. Ленивое размножение. Одна копия создается на одном сервере, а затем он сам автоматически создает (в свободное время) дополнительные копии и обеспечивает их поддержание.
6. Симметричное размножение. Все операции одновременно вызываются в нескольких серверах и одновременно выполняются.

1. Метод размножения главной копии. Один сервер объявляется главным, а остальные - подчиненными. Все изменения файла посылаются главному серверу. Он сначала корректирует свою локальную копию, а затем рассылает подчиненным серверам указания о коррекции. Чтение файла может выполнять любой сервер. Для защиты от краха главного сервера до завершения всех коррекций, до выполнения коррекции главной копии главный сервер запоминает в стабильной памяти задание на коррекцию. Слабость - выход из строя главного сервера не позволяет выполнять коррекции.
2. Метод голосования. Идея - запрашивать чтение и запись файла у многих серверов (запись - у всех!). Запрос может получить одобрение у половины серверов плюс один. При этом должно быть согласие относительно номера текущей версии файла. Этот номер увеличивается на единицу с каждой коррекцией файла. Можно использовать различные значения для кворума чтения (Nr) и кворума записи (Nw). При этом должно выполняться соотношение Nr+Nw>N. Поскольку чтение является более частой операцией, то естественно взять Nr=1. Однако в этом случае для кворума записи потребуются все серверы.

5.2.5 Пример: Sun Microsystems Network File System (NFS)

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

Клиент получает доступ к экспортированным директориям путем их монтирования. Если клиент не имеет дисков, то может монтировать директории в свою корневую директорию.

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

Многие клиенты монтируют требуемые удаленные директории автоматически при запуске (используя командную процедуру shell-интерпретатора ОС UNIX).

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

Второй протокол - для доступа к директориям и файлам. Клиенты посылают сообщения, чтобы манипулировать директориями, читать и писать файлы. Можно получить атрибуты файла. Поддерживается большинство системных вызовов ОС UNIX, исключая OPEN и CLOSE. Для получения дескриптора файла по его символическому имени используется операция LOOKUP, отличающаяся от открытия файла тем, что никаких внутренних таблиц не создается. Таким образом, серверы в NFS не имеют состояния (stateless). Поэтому для захвата файла используется специальный механизм.

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

Все ключи, используемые для контроля доступа, поддерживаются специальным сервисом (и серверами) - сетевым информационным сервисом (NIS). Храня пары (ключ, значение), сервис обеспечивает выдачу значения кода при правильном подтверждении ключей. Кроме того, он обеспечивает отображение имен машин на их сетевые адреса, и другие отображения. NIS-серверы используют схему главный -подчиненные для реализации размножения (ленивое размножение). Реализация NFS (XDR - External Data Represantation)

Задача уровня виртуальной файловой системы - поддерживать для каждого открытого файла строку в таблице (v-вершину), аналогичную i-вершине UNIX. Эта строка позволяет различать локальные файлы от удаленных. Для удаленных файлов вся необходимая информация хранится в специальной r-вершине в NFS-клиенте, на которую ссылается v-вершина. У сервера нет никаких таблиц.

Передачи информации между клиентом и сервером NFS производятся блоками размером 8К (для эффективности).

Два кэша - кэш данных и кэш атрибутов файлов (обращения к ним очень часты, разработчики NFS исходили из оценки 90%). Реализована семантика отложенной записи - предмет критики NFS.

Имеется также кэш подсказок для ускорения получения v-вершины по символическому имени. При использовании устаревшей подсказки NFS-клиент будет обращаться к NFS-серверу и корректировать свой кэш (пользователь об этом ничего не должен знать).

Лаборатория Параллельных Информационных Технологий, НИВЦ МГУ

1. Martin Marshall. «Intel-Architecture Unix: Still a Moving Target» (англ.) // InfoWorld. - 1989. - P. 64 . - «The new SCO release also adds a fast file system designed by Acer Counterpoint <…> According to SCO Xenix product manager Bill Brothers, the Acer Fast File System performance can be as high as 600 to 800 kilobytes per second, compare to about 100 kilobytes per second for standart Unix file formats.»
2. 1.3 release confirmed on September 16, 1988 by Carolyn Scheppner of CATS in amiga.dev in . Copy of BIX announcement from USENET
3. (неопр.) .
4. Была впервые представлена в NTFS 3.0
5. Rob Radez. 2.4.15-final (неопр.) . Linux kernel mailing list (23 ноября 2001). Проверено 30 ноября 2010. Архивировано 26 августа 2011 года.
6. Microsoft’s Opposition to Datel’s Motion for Partial Summary Judgment (PDF‐файл на сайте Electronic Frontier Foundation) - «FatX is an unpublished, proprietary format that is not readable using standard tools available on a Macintosh, Windows, or Linux computer. », много текста закрашено.
7. Sergey Ptashnick. «Открыт код Next3 - файловой системы для Linux с поддержкой слепков ФС» (неопр.) . (09 июня 2010 г.). Проверено 17 февраля 2011. Архивировано 26 августа 2011 года.
8. Файловая система ReFS изнутри Released (неопр.) . R.Lab (16 марта 2012). Архивировано 31 мая 2012 года.
9. «Btrfs and Squashfs merged into Linux kernel» (англ.) (10 января 2009 г.). Проверено 4 января 2011. Архивировано 26 августа 2011 года.
10. Help - IBM AIX Compilers
11. VERITAS Foundation Suite and Foundation Suite HA 3.5 (неопр.) (недоступная ссылка) . VERITAS. Проверено 21 ноября 2007. Архивировано 25 октября 2003 года.

Файловые системы для флеш-дисков / твердотельных носителей [ | ]

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

Запись-ориентированные файловые системы [ | ]

В файлы хранятся как коллекция записей (а не как неструктурированный набор байтов). Такие файловые системы ассоциируются, прежде всего, со старыми мейнфреймами и операционными системами для мини-компьютеров . Программы считывают и записывают целыми записями, вместо байт, записанных, в определенном порядке; такой способ работы с файлами отражён в операторах ввода-вывода в старых версиях языка FORTRAN .

Файловые системы для сетевых хранилищ [ | ]

Файловые системы для общих дисков (также известные как Файловые системы для сетевых (общих) хранилищ (файловая система SAN) или кластерные файловые системы ) в основном используются в сетевых хранилищах, где все узлы сети имеют прямой доступ к блоковому устройству хранения, где расположена эта файловая система. Такие файловые системы функционируют даже при поломке одного из узлов. Данные файловые системы обычно используются в кластерах высокой доступности вместе с аппаратным RAID . Файловые системы для сетевых хранилищ обычно не расширяются больше 64 или 128 узлов.

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

• (XFS для кластера) - файловая система, расширяющая XFS для использования в сети, имеющей SGI -сервера. Сфера применения типична для решений Silicon Graphics - видеомонтаж, обработка массивов видеоматериалов.
• от компании EMC . Доступна для ОС AIX, HP-UX, IRIX, Solaris и Windows. Асимметрична.
• (англ. ) - распределённая файловая система, разработанная IBM
• Files-11 - файловая система для кластеров VMS , выпущена DEC в 1983, ныне компания . Симметрична.
• (GFS) - компания Red Hat . Выпущена в Linux под лицензией GNU GPL . Симметрична () и асимметрична ().
• (CFS) (TruCluster) - компания . Доступна для Tru64 UNIX .
• - компания. Доступна для Windows . Симметрична.
• - файловая система от компании. Доступна в Linux и Solaris. Асимметрична.
• OCFS - Oracle Cluster File System, кластерная файловая система от Oracle . Лицензия GNU GPL . Симметрична
• (PSFS) - компания - используется в их , который фокусируется на экспортировании клиентам через CIFS или NFS , также как и Microsoft SQL Server и Oracle 9i RAC и 10g. Доступна в Linux и Windows. Симметрична.
• (англ. ) от. Асимметрична. Доступна в AIX , HP-UX , IRIX , Linux , Mac OS , Solaris и Windows . Совместима с Xsan .
• QFS , создана компанией Sun Microsystems . Доступна в Linux (только клиентская часть) и Solaris (полностью). Асимметрична.
• (CFS) - разработана компанией Symantec . Доступна в AIX, HP-UX, Linux и Solaris. Асимметрична.
• Xsan - кластерная файловая система, созданная компанией Apple Computer, Inc. Асимметрична, доступна в Mac OS. Совместима с.
• - разработана VMware /EMC Corporation . Доступна в VMware ESX Server . Симметрична.

Распределённые файловые системы [ | ]

Распределённые файловые системы известны и как сетевые файловые системы.

• Andrew File System (AFS) - масштабируемая и независимая от расположения ФС, имеет сильный кэш -клиент и использует Kerberos для авторизации . Различные внедрения используют оригинальные части от IBM (ранее), Arla и OpenAFS .
• - свободно распространяемые сервер и клиент с поддержкой AFS
• Apple Filing Protocol (AFP) - ФС от Apple Computer . AFP может использовать протокол Kerberos для авторизации.
• CIFS - распределённая ФС, основанная на SMB с поддержкой UNIX-прав и блокировок, при этом использующая DNS -имена машин, а не NetBIOS -, в отличие от SMB.
• (/DFS) - ФС от IBM (ранее) похожа на AFS и полностью соответствует стандарту POSIX и стандартам систем высокой доступности . Доступна для ОС AIX и Solaris под запатентованной лицензией.
• NetWare Core Protocol (NCP) - ФС от Novell . Используется в сетях, основанных на NetWare .
• Network File System (NFS) изначально от Sun Microsystems , теперь является стандартом в UNIX-подобных сетях. NFS может использовать протокол Kerberos для авторизации и кэш клиента.
• (Remote File Sharing - совместное использование удаленных файлов) - сетевая файловая система только для UNIX System V , начиная с Release 3. Использует протокол интерфейса транспортного уровня TLI.
• (англ. ) - One File System, полностью журналируемая распределённая ФС , разработанная. Позволяет хранить более 150 Тбайт данных.
• - открытая реализация распределенной файловой системы AFS.
• (SFS), Глобальная сетевая файловая система, разработанная для безопасного доступа к файлам через различные административные домены.
• Server Message Block (SMB) - изначально разработана IBM (большинство общих версий серьёзно модифицировано Microsoft) - является стандартом в Windows-ориентированных сетях. SMB также известна как Common Internet File System (CIFS) - Общая Файловая система в Интернет. SMB может использовать протокол Kerberos для авторизации.
• - распределённая файловая система для ОС Plan 9 и Inferno .

Распределённые параллельные файловые системы с защитой от сбоев [ | ]

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

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

• Ceph - свободная распределённая файловая система, может использоваться на системах, состоящих как из нескольких машин, так и из тысяч узлов. Не требует какой-то особой поддержки от ядра. Может работать поверх блочных устройств, внутри одного файла или используя существующую ФС.
• Coda - ФС, созданная в Carnegie Mellon University и нацеленная на операции, адаптируемые к пропускной способности канала (включая операции в режиме). Использует кэш на стороне клиента для мобильных компьютеров. Данная ФС является потомком AFS-2 и доступна для Linux под лицензией GNU GPL .
• - ФС от компаний Fermilab и DESY . Является бесплатным ПО (однако не относится к свободному программному обеспечению из-за лицензионных ограничений).
• - распределённая ФС от. Идёт как часть, основанном на Linux NAS решении запущенном на оборудовании Intel , обслуживает NFS v2/v3, SMB/CIFS и AFP для Microsoft Windows, Mac Os, Linux и других UNIX клиентов. Доступна под патентованной лицензией.
• - ФС, использующая