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 -бітна контрольна сума Як і інші метадані, ці суми зберігаються в пам'яті, регулярно зберігаються в лог, окремо від даних користувача.
Перед тим як рахувати дані чанк-сервер перевіряє контрольні сумиблоків чанка, які перетинаються із затребуваними даними користувачем чи іншим чанк-сервером. Тобто чанк-сервер не розповсюджує зіпсовані дані. У разі розбіжності контрольних сум, чанк-сервер повертає помилку машині, яка подала запит, і рапортує про неї майстру. Користувач може вважати дані з іншої репліки, а майстер створює ще одну копію даних іншої репліки. Після цього майстер дає інструкцію цього чанк-сервера про видалення цієї зіпсованої репліки.
При додаванні нових даних верифікація контрольних сум не відбувається, а для блоків записується нові контрольні суми. Якщо диск зіпсований, це визначиться під час спроби читання цих даних. При записі чанк-сервер порівнює лише перший та останній блоки, що перетинаються з межами, в які відбувається запис, оскільки частина даних на цих блоках не перезаписується і необхідно перевірити їхню цілісність.

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

Важливо розуміти різницю між файловим сервісом і файловим сервером. Файловий сервіс – опис функцій, які файлова система пропонує своїм користувачам. Цей опис включає примітиви, їх параметри та функції, які вони виконують. З погляду користувачів файловий сервіс визначає те, із чим користувачі можуть працювати, але нічого не говорить про те, як все це реалізовано. По суті файловий сервіс визначає інтерфейс файлової системи з клієнтами.

Файловий сервер – це процес, який виконується окремій машині і допомагає реалізовувати файловий сервіс. У системі може бути один файловий сервер або декілька, але в добре організованій розподіленій системі користувачі не знають, як реалізовано файлову систему. Зокрема, вони не знають кількість файлових серверів, їх місцезнаходження та функції. Вони лише знають, що й процедура визначено у файловому сервісі, то необхідна робота якимось чином виконується, і вони повертаються необхідні результати. Більше того, користувачі не повинні знати, що файловий сервіс є розподіленим. В ідеалі він має виглядати так само, як і в централізованій файловій системі.

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

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

Для будь-кого файлового сервісу, незалежно від того, централізований він чи розподілений, найголовнішим є питання, що таке файл? У багатьох системах, таких як UNIX і MS DOS, файл – це послідовність байтів, що не інтерпретується. Значення та структура інформації у файлі є турботою прикладних програм, Операційну систему це не цікавить.

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

Важливим аспектомфайлової моделі є можливість модифікації файлу після створення. Зазвичай файли можуть бути модифіковані, але в деяких розподілених системах єдиними операціями з файлами є Створити і прочитати. Такі файли називаються незмінними. Для незмінних файлів набагато легше здійснити кешування файлу та його реплікацію (тиражування), оскільки виключається всі проблеми, пов'язані з оновленням усіх копій файлу під час його зміни.

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

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

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

Важливою проблемою, що з способами іменування файлів, є забезпечення прозорості. У цьому контексті прозорість розуміється у двох слабо помітних сенсах. Перший - прозорість розташування - означає, що імена не дають можливості визначити місцезнаходження файлу. Наприклад, ім'я /server1/dir1/ dir2/xкаже, що файл x розташовано на сервері 1, але не вказує, де розташований цей сервер. Сервер може переміщатися через мережу, а повне ім'я файлу при цьому не змінюється. Отже, така система має прозорість розташування.

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

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

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

При виборі алгоритму мають розв'язуватися дві задачі. По-перше, якими одиницями оперує кеш. Цими одиницями можуть бути дискові блоки, або цілі файли. Якщо це цілі файли, вони можуть зберігатися на диску безперервними областями (по Крайній міріу вигляді великих ділянок), при цьому зменшується кількість обмінів між пам'яттю і диском, а отже, забезпечується висока продуктивність. Кешування блоків диска дозволяє ефективніше використовувати пам'ять кеша та дисковий простір.

По-друге, необхідно визначити правило заміни даних під час заповнення кеш-пам'яті. Тут можна використовувати будь-який стандартний алгоритм кешування, наприклад, алгоритм LRU (least recently used), відповідно до якого витісняється блок, до якого найдовше не було звернення.

Кеш-пам'ять на сервері легко реалізується і є абсолютно прозорою для клієнта. Оскільки сервер може синхронізувати роботу пам'яті та диска, з погляду клієнтів існує лише одна копія кожного файлу, тому проблема узгодження не виникає.

Оскільки в мережах поширені спільні файли, адміністратори все частіше стикаються з проблемами при наданні доступу користувачам до необхідних їм даних. В операційній системі 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

	Натисніть кнопку Пуск (Start), Виберіть Програми (Programs), перейдіть до розділу Адміністрування (Administrative Tools)та виберіть Розподілена файлова система DFS(Distributed File System).
	Клацніть правою кнопкою миші на кореневому елементі Розподілена файлова система DFS (Distributed File System), розташованому на лівій панелі, та натисніть Створити корінь DFS (New DFS Root). Відобразиться Майстер створення нового кореня DFS (New DFS Root Wizard). Щоб продовжити, натисніть кнопку Далі (Next).
	Переконайтеся, що перемикач встановлено на позицію Створення кореня DFS в домені (Create a domain DFS root), та натисніть кнопку Далі (Next)для продовження.
	Виберіть несучий домен для кореня DFS (у нашому прикладі це домен reskit.com)та натисніть кнопку Далі (Next)для продовження. Рисунок 1 – Вибір несучого домену для кореня DFS
	Виберіть несучий сервер для цього кореня DFS. У нашому прикладі це сервер HQ-RES-DC-01.Reskit.com. Натисніть кнопку Далі (Next)для продовження.
	Вкажіть спільну папку, яка буде використовуватися як цільова для цього кореня DFS. Встановіть перемикач у положення Створити новий спільний ресурс (Create a new share), введіть шлях до цієї спільної папки (у нашому випадку це c:\dfsbooks)та вкажіть ім'я цієї спільної папки – Books. Оснащення Розподілена файлова система DFS (Distributed File System)дозволить Вам створити новий каталогі налаштувати для нього загальний доступякщо раніше це не було зроблено. Рисунок 2 – Вибір спільної папки для кореневого тому DFS
	Натисніть кнопку Далі (Next). Якщо вказана папка не існує, Вам буде поставлено питання про необхідність її створення. Натисніть кнопку Так (Yes)для продовження. За бажанням Ви можете ввести коментар з описом цього кореня. Щоб продовжити, натисніть кнопку Далі (Next).
	Натисніть кнопку Готово (Finish)для створення кореня DFS. Після завершення роботи майстра створення нового кореня DFS (Create New DFS Root Wizard) Ви можете розпочинати адміністрування Вашого кореня 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). У нашому прикладі використовується спільна папка Архітектура, розташована на сервері 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)

Натисніть Пуск (Start), натисніть Виконати (Run)і введіть \\reskit.com\bookу текстовому полі Відкрити (Open)та натисніть OK. Клацнувши правою кнопкою миші за відображеним на панелі оглядача посиланням, вибравши Властивості (Properties), Ви можете перейти на вкладку DFSдіалогового вікна Властивості (Properties)для перегляду наступної інформації:

У разі фізичного відключення одного з двох серверів у Вас все одно буде доступ до ресурсу тим же шляхом 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)та введіть відповідну інформацію.

Файлова система з не фрагментованим форматом запису файлів. Використовувалася на персональних комп'ютерахБК в операційних системах MKDOS, AO-DOS, NORD, MicroDOS, NORTON-БК, PascalDOS та ін. Підтримувалася тільки для читання в ANDOS. У різних ОС найчастіше підтримувалися різні друг від друга, який завжди повністю сумісні модифікації. Розвинена журнальна файлова система, доступна для ОС сімейства AmigaOS, а також MorphOS і AROS. Однією з особливостей системи є можливість проводити дефрагментацію навіть під час роботи з файлами. Примітки

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<…>Посилання на SCO Xenix product manager Bill Brothers, 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 confirmated on September 16, 1988 by Carolyn Scheppner 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 є непідготовленим, виробничим форматом, який не використовується для використання стандартних інструментів, доступних на Macintosh, Windows, або Linux комп'ютері. », багато тексту зафарбовано.
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 та 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 клієнтів. Доступна під патентованою ліцензією.
• - ФС, яка використовує

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

Корінь розподіленої файлової системи виступає у ролі логічної точки розподілу мережевих дисків. Це означає, що користувачі можуть просто перейти до кореня розподіленої файлової системи та переглядати список папок, підключених до цього кореня. При натисканні на папці, користувач може переглядати її вміст. Але користувач може не підозрювати, що вміст папки знаходиться на іншому сервері.

Все це означає, що розподілена файлова система надає додатковий рівень прозорості доступу до вмісту мережевих ресурсів. Багато хто посилається на цю концепцію як на віртуалізацію зберігання (storage virtualization). У разі використання розподіленої файлової системи користувачеві не обов'язково знати, де фізично знаходяться дані. Натомість досить пам'ятати розташування кореня файлової системи.

Логічно керуючи розташуванням мережевих дисків, можна переміщувати дані між серверами в мережі прозоро для користувачів. З точки зору користувачів, дані продовжуватимуть перебувати в корені розподіленої файлової системи. Все, що для цього необхідно, це скопіювати дані в інше місце і оновити посилання розподіленої файлової системи на об'єкт, що спільно використовується, щоб вона відображала нове розташування.

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

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

При першому налаштуванні розподіленої файлової системи необхідно вказати початкову точку для дерева розподіленої файлової системи. Вона відома під ім'ям корінь розподіленої файлової системи. Існує два типи кореня розподіленої файлової системи:

• Ізольований корінь (Standalone)- конфігурація простору імен розподіленої файлової системи та архітектура зберігаються локально на кореневому сервері. Шлях доступу (шлях UNC) до кореня починається з імені сервера. Ізольований корінь дозволяє існування лише одного кореня розподіленої файлової системи для простору імен розподіленої файлової системи. Це означає, що корінь не надає стійкості до помилок і є єдиною точкою відмови при доступі до даних.
• Домен (Domain)- простір імен розподіленої файлової системи зберігатиметься в Active Directory. При використанні домену розподіленої файлової системи можна створювати кілька стійких до помилок коренів розподіленої файлової системи, а клієнти отримуватимуть доступ до розподіленої файлової системи на ім'я домену. Використання інтеграції в Active Directory дозволяє клієнтам автоматично бути переспрямованими до кореня розподіленої файлової системи у локальному сайті Active Directory, що має певні переваги у великих мережах, де інфраструктура розподіленої файлової системи може сягати кількох сайтів.

Ще одним терміном, який необхідно знати, є Зв'язок розподіленої файлової системи (DFS link). Коріння є точками початку розподіленої файлової системи. При додаванні зв'язків визначаються імена мережних дисків та розташування мережних даних. Коли користувач отримує доступ до кореня розподіленої файлової системи, зв'язки відображаються як логічних підпапок кореня.