Мережева файлова система - це мережева абстракція поверх звичайної файлової системи, що дозволяє віддаленому клієнту звертатися до неї через мережу так само, як і при доступі до локальних файлових систем. Хоча NFS не є першою мережевою системою, вона сьогодні розвинулася до рівня найбільш функціональної і затребуваною мережевої файлової системи в UNIX®. NFS дозволяє організувати спільний доступ до загальної файлової системи для безлічі користувачів і забезпечити централізацію даних для мінімізації дискового простору, необхідного для їх зберігання.

Ця стаття починається з короткого огляду історії NFS, а потім переходить до дослідження архітектури NFS і шляхів її подальшого розвитку.

До Ратко історія NFS

Перша мережева файлова система називалася FAL (File Access Listener - обробник доступу до файлів) і була розроблена в 1976 році компанією DEC (Digital Equipment Corporation). Вона була реалізацією протоколу DAP (Data Access Protocol - протокол доступу до даних) і входила в пакет протоколів DECnet. Як і у випадку з TCP / IP, компанія DEC опублікувала специфікації своїх мережевих протоколів, включаючи протокол DAP.

NFS була першою сучасної мережевої файлової системою, побудованої над протоколом IP. Її прообразом можна вважати експериментальну файлову систему, розроблену в Sun Microsystems на початку 80-х років. З огляду на популярність цього рішення, протокол NFS був представлений в якості специфікації RFC і згодом розвинувся в NFSv2. NFS швидко утвердилася в якості стандарту завдяки здатності взаємодіяти з іншими клієнтами і серверами.

Згодом стандарт був оновлений до версії NFSv3, визначеної в RFC 1813. Ця версія протоколу була більш масштабируема, ніж попередні, і підтримувала файли більшого розміру (більше 2 ГБ), асинхронний запис і TCP в якості транспортного протоколу. NFSv3 задала напрямок розвитку файлових систем для глобальних (WAN) мереж. У 2000 році в рамках специфікації RFC 3010 (переробленої в версії RFC 3530) NFS була перенесена в корпоративну середу. Sun представила більш захищену NFSv4 c підтримкою збереження стану (stateful) (попередні версії NFS не підтримували збереження стану, тобто належали до категорії stateless). На поточний момент останньою версією NFS є версія 4.1, певна в RFC 5661, в якій в протокол за допомогою розширення pNFS була додана підтримка паралельного доступу для розподілених серверів.

Історія розвитку NFS, включаючи конкретні RFC, що описують її версії, показана на малюнку 1.

Малюнок 1. Історія розвитку NFS

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

А рхітектура NFS

NFS використовує стандартну архітектурну модель "клієнт-сервер" (як показано на малюнку 2). Сервер відповідає за реалізацію файлової системи спільного доступу і сховища, до якого підключаються клієнти. Клієнт реалізує користувальницький інтерфейс до загальної файлової системи, змонтованої всередині локального файлового простору клієнта.

Малюнок 2. Реалізація моделі "клієнт-сервер" в архітектурі NFS

В ОС Linux® віртуальний комутатор файлової системи (virtual file system switch - VFS) надає кошти для одночасної підтримки на одному хості декількох файлових систем (наприклад, файлової системи ISO 9660 на CD-ROM і файлової системи ext3fs на локальному жорсткому диску). Віртуальний комутатор визначає, до якого накопичувача виконується запит, і, отже, яка файлова система повинна використовуватися для обробки запиту. Тому NFS має таку ж сумісністю, як і інші файлові системи, що застосовуються в Linux. Єдина відмінність NFS полягає в тому, що запити введення / виведення замість локальної обробки на хості можуть бути спрямовані для виконання в мережу.

VFS визначає, що отриманий запит відноситься до NFS, і передає його в обробник NFS, що знаходиться в ядрі. Оброблювач NFS обробляє запит введення / виведення і транслює його в NFS-процедуру (OPEN, ACCESS, CREATE, READ, CLOSE, REMOVE і т.д.). Ці процедури, описані в окремій специфікації RFC, визначають поведінку протоколу NFS. Необхідна процедура вибирається залежно від запиту і виконується за допомогою технології RPC (виклик віддаленої процедури). Як можна зрозуміти з назви, RPC дозволяє здійснювати виклики процедур між різними системами. RPC-служба з'єднує NFS-запит з його аргументами і відправляє результат на відповідний віддалений хост, а потім стежить за отриманням і обробкою відповіді, щоб повернути його ініціатору запиту.

Також RPC включає в себе важливий рівень XDR (external data representation - незалежне уявлення даних), що гарантує, що всі користувачі NFS для однакових типів даних використовують один і той же формат. Коли якась платформа відправляє запит, який використовується нею тип даних може відрізнятися від типу даних, що використовується на хості, який займається обробкою цей запит. Технологія XDR бере на себе роботу по перетворенню типів в стандартне уявлення (XDR), так що платформи, що використовують різні архітектури, можуть взаємодіяти і спільно використовувати файлові системи. У XDR визначено бітовий формат для таких типів, як float, і порядок байтів для таких типів, як масиви постійної і змінної довжини. Хоча XDR в основному відома завдяки застосуванню в NFS, це специфікація може бути корисна у всіх випадках, коли доводиться працювати в одному середовищі з різними архітектурами.

Після того як XDR переведе дані в стандартний вигляд, запит передається по мережі за допомогою певного транспортного протоколу. У ранніх реалізаціях NFS використовувався протокол UDP, але сьогодні для забезпечення більшої надійності застосовується протокол TCP.

На стороні NFS-сервера застосовується схожий алгоритм. Запит піднімається з мережевого стека через рівень RPC / XDR (для перетворення типів даних відповідно до архітектури сервера) і потрапляє в NFS-сервер, який відповідає за обробку запиту. Там запит передається NFS-демону для визначення цільової файлової системи, якій він адресований, а потім знову надходить в VFS для звернення до цієї файлової системи на локальному диску. Повністю схема цього процесу приведена на малюнку 3. При цьому локальна файлова система сервера - це стандартна для Linux файлова система, наприклад, ext4fs. По суті NFS - це не файлову систему в традиційному розумінні цього терміна, а протокол віддаленого доступу до файлових систем.

Малюнок 3. Схема взаємодії між NFS-клієнтом і NFS-сервером

Для мереж з великим часом очікування в NFSv4 пропонується спеціальна складова процедура (compound procedure). Ця процедура дозволяє помістити кілька RPC-викликів всередину одного запиту, щоб мінімізувати витрати на передачу запитів по мережі. Також в цій процедурі реалізований механізм callback-функцій для отримання відповідей.

На початок

П ротокол NFS

Коли клієнт починає працювати з NFS, першою дією виконується операція mount, яка представляє собою монтування віддаленої файлової системи в простір локальної файлової системи. Цей процес починається з виклику процедури mount (однієї з системних функцій Linux), який через VFS перенаправляється в NFS-компонент. Потім за допомогою RPC-виклику функції get_port на віддаленому сервері визначається номер порту, який буде використовуватися для монтування, і клієнт через RPC відправляє запит на монтування. Цей запит на стороні сервера обробляється спеціальним демоном rpc.mountd, що відповідає за протокол монтування (mount protocol). Демон перевіряє, що запитана клієнтом файлова система є в списку систем, доступних на даному сервері. Якщо запитана система існує і клієнт має до неї доступ, то у відповіді RPC-процедури mount вказується дескриптор файлової системи. Клієнт зберігає у себе інформацію про локальної та дистанційної точках монтування і отримує можливість здійснювати запити вводу / виводу. Протокол монтування не є бездоганним з точки зору безпеки, тому в NFSv4 замість нього використовуються внутрішні RPC-виклики, які також можуть управляти точками монтування.

Для зчитування файлу його необхідно спочатку відкрити. У RPC немає процедури OPEN, замість цього клієнт просто перевіряє, що зазначені файл і каталог існують в змонтованої файлової системи. Клієнт починає з виконання RPC-запиту GETATTR до каталогу, у відповідь на який повертаються атрибути каталогу або індикатор, що каталог не існує. Далі, щоб перевірити наявність файлу, клієнт виконує RPC-запит LOOKUP. Якщо файл існує, для нього виконується RPC-запит GETATTR, щоб дізнатися атрибути файлу. Використовуючи інформацію, отриману в результаті успішних викликів LOOKUP і GETATTR, клієнт створює дескриптор файлу, який надається користувачу для виконання майбутніх запитів.

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

І нноваціі в NFS

Найбільший інтерес представляють дві останні версії NFS - 4 і 4.1, на прикладі яких можна вивчити найбільш важливі аспекти еволюції технології NFS.

До появи NFSv4 для виконання таких завдань з управління файлами, як монтування, блокування і т.д. існували спеціальні додаткові протоколи. У NFSv4 процес управління файлами був спрощений до одного протоколу; крім того, починаючи з цієї версії UDP більше не використовується в якості транспортного протоколу. NFSv4 включає підтримку UNIX і Windows®-семантики доступу до файлів, що дозволяє NFS "природним" способом інтегруватися в інші операційні системи.

У NFSv4.1 для більшої масштабованості і продуктивності була введена концепція паралельної NFS (parallel NFS - pNFS). Щоб забезпечити більший рівень масштабованості, в NFSv4.1 реалізована архітектура, в якій дані і метадані (розмітка) розподіляються по пристроях аналогічно тому, як це робиться в кластерних файлових системах. Як показано на малюнку 4 , PNFS розділяє екосистему на три складові: клієнт, сервер і сховище. При цьому з'являються два канали: один для передачі даних, а інший для передачі команд управління. pNFS відокремлює дані від описують їх метаданих, забезпечуючи двухканальную архітектуру. Коли клієнт хоче отримати доступ до файлу, сервер відправляє йому метадані з "розміткою". У метаданих міститься інформація про розміщення файлу на запам'ятовуючих пристроях. Отримавши цю інформацію, клієнт може звертатися безпосередньо до сховища без необхідності взаємодіяти з сервером, що сприяє підвищенню масштабованості та продуктивності. Коли клієнт закінчує роботу з файлом, він підтверджує зміни, внесені в файл і його "розмітку". При необхідності сервер може вимагати від клієнта метадані з розміткою.

З появою pNFS в протокол NFS було додано кілька нових операцій для підтримки такого механізму. Метод LayoutGet використовується для отримання метаданих з сервера, метод LayoutReturn "звільняє" метадані, "захоплені" клієнтом, а метод LayoutCommit завантажує "розмітку", отриману від клієнта, в сховище, так що вона стає доступною іншим користувачам. Сервер може відкликати метадані у клієнта за допомогою методу LayoutRecall. Метадані з "розміткою" розподіляються між декількома пристроями, що запам'ятовують, щоб забезпечити паралельний доступ і високу продуктивність.

Малюнок 4. Архітектура pNFS в NFS версії 4.1

Дані та метадані зберігаються на запам'ятовуючих пристроях. Клієнти можуть виконувати прямі запити введення / виведення на основі отриманої розмітки, а сервер NFSv4.1 зберігає метадані та управляє ними. Сама по собі ця функціональність і не нова, але в pNFS була додана підтримка різних методів доступу до запам'ятовуючим пристроям. Сьогодні pNFS підтримує використання блокових протоколів (Fibre Channel), об'єктних протоколів і власне NFS (навіть не в pNFS-формі).

Розвиток NFS триває, і у вересні 2010 року були опубліковані вимоги до NFSv4.2. Деякі з нововведень пов'язані з спостерігається міграцією технологій зберігання даних в сторону віртуалізації. Наприклад, в віртуальних середовищах з гіпервізором вельми ймовірне виникнення дублювання даних (кілька ОС виконують читання / запис і кешування одних і тих же даних). У зв'язку з цим бажано, щоб система зберігання даних в цілому розуміла, де відбувається дублювання. Такий підхід допоможе заощадити простір в кеші клієнта і загальну ємність системи зберігання. У NFSv4.2 для вирішення цієї проблеми пропонується використовувати "карту блоків, що знаходяться в спільному доступі" (block map of shared blocks). Оскільки сучасні системи зберігання все частіше оснащуються власними внутрішніми обчислювальними потужностями, вводиться копіювання на стороні сервера, що дозволяє знизити навантаження при копіюванні даних у внутрішній мережі, коли це можна ефективно робити на самому пристрої, що запам'ятовує. Інші інновації включають в себе субфайловое кешування для флеш-пам'яті і рекомендації по налаштуванню введення-виведення на стороні клієнта (наприклад, з використанням mapadvise).

А льтернатіви NFS

Хоча NFS - найпопулярніша мережева файлова система в UNIX і Linux, крім неї існують і інші мережеві файлові системи. На платформі Windows® найчастіше застосовується SMB, також відома як CIFS; при цьому ОС Windows також підтримує NFS, так само як і Linux підтримує SMB.

Одна з новітніх розподілених файлових систем, які підтримуються в Linux - Ceph - спочатку спроектована як відмовостійка POSIX-сумісна файлова система. Додаткову інформацію про Ceph можна знайти в розділі ресурси .

Варто також згадати файлові системи OpenAFS (Open Source-версія розподіленої файлової системи Andrew, розробленої в університеті Карнегі-Меллона і корпорації IBM), GlusterFS (розподілена файлова система загального призначення для організації масштабованих сховищ даних) і Lustre (мережева файлова система з масовим паралелізмом для кластерних рішень). Всі ці системи з відкритим вихідним кодом можна використовувати для побудови розподілених сховищ.

Висновок

Розвиток файлової системи NFS триває. Подібно ОС Linux, що підходить для підтримки та бюджетних, і вбудованих, і високопродуктивних рішень, NFS надає архітектуру масштабованих рішень для зберігання даних, придатних як окремим користувачам, так і організаціям. Якщо подивитися на шлях, вже пройдений NFS, і перспективи її подальшого розвитку, стає зрозуміло, що ця файлова система буде продовжувати змінювати наші погляди на те, як реалізуються і використовуються технології зберігання файлів.

Р есурси

• Network file systems and Linux (http://www.ibm.com/developerworks/linux/library/l-network-filesystems/index.html?S_TACT=105AGX99&S_CMP=CP) : Оригінал статті (EN).
• NFS - це стандарт специфікації яку переносять і мультиплатформенной мережевої файлової системи. NFS документована в декількох специфікаціях, включаючи першу реалізацію NFSv2 , NFSv3 , NFSv4 і новітню версію NFSv4.1 . Про направлення подальшого розвитку NFS можна дізнатися в вимогах до NFS v4.2 .
• Yet Another NFS (YANFS) - проект компанії Sun, що раніше називався WebNFS . Файлова система YANFS - це Java ™ -Реалізація NFSv3 і RPC / XDR для організації доступу до NFS з Java-додатків.
• XDR - це стандарт кодування даних, що дозволяє хостам з різною архітектурою спілкуватися по мережі з використанням стандартних типів даних.
• Linux підтримує різні файлові системи для безлічі запам'ятовуючих пристроїв. Ця можливість забезпечується за допомогою інтеграції різних файлових систем, драйверів для запам'ятовуючих пристроїв і VFS. Додаткову інформацію про VFS можна знайти в статті " Anatomy of the Linux File System "(DeveloperWorks, жовтень 2007 р.)
• Крім NFS, існують і інші способи побудувати мережеве файлове сховище. Також можна використовувати файлові системи OpenAFS , GlusterFS , Lustre і Ceph . Додаткову інформацію про Ceph можна знайти в статті Ceph: A Linux petabyte-scale distributed file system "(DeveloperWorks, травень 2010 р.)