Мережеві файлові системи та Linux
NFS: зручна та перспективна мережева файлова система
Мережева файлова система - це мережна абстракція поверх звичайної файлової системи, що дозволяє віддаленому клієнту звертатися до неї через мережу так само, як і за доступу до локальних файлових систем. Хоча NFS не є першою мережевою системою, вона сьогодні розвинулася до рівня найбільш функціональної та затребуваної мережевої файлової системи UNIX®. NFS дозволяє організувати спільний доступ до спільної файлової системи для багатьох користувачів і забезпечити централізацію даних для мінімізації дискового простору, необхідного для їх зберігання.
Коротка історія NFS
NFS була першою сучасною мережевою файловою системою, побудованою поверх протоколу IP. Її прообразом можна вважати експериментальну файлову систему, розроблену Sun Microsystems на початку 80-х років. Враховуючи популярність цього рішення, протокол NFS був представлений як специфікація RFC і згодом розвинувся в NFSv2. NFS швидко утвердилася як стандарт завдяки здатності взаємодіяти з іншими клієнтами та серверами.
Історія розвитку 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.
Рисунок 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
Хоча 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, і її подальшого розвитку, стає зрозуміло, що ця файлова система продовжуватиме змінювати наші погляди те що, як реалізуються і використовуються технології зберігання файлів.