20.3.2. Файлова система nfs

Найвідомішим прикладом реалізації розподілених файлових систем є Network File System (NFS) [44]. Сьогодні NFS є стандартною файловою системою більшо­сті UNIX-сумісних ОС.

Принцип дії NFS

Файлова система NFS об'єднує окремі каталоги файлових систем віддалених комп'ютерів у єдине дерево каталогів локального комп'ютера. Таке об'єднання є прозорим для користувачів — з їхнього погляду остаточне дерево каталогів не відрізняється від локальної файлової системи UNIX.

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

1. Для того щоб NFS-клієнт міг отримати доступ до каталогу локальної файлової системи NFS-сервера, цей каталог потрібно експортувати. Для цього необхід­но додати відповідний шлях у список експорту, який зберігають на сервері, за­звичай у спеціальному файлі /etc/exports. Цей список зчитує ядро ОС під час завантаження системи.

2. Для доступу до експортованих каталогів сервера NFS-клієнти мають їх вмон­тувати в каталоги своєї локальної файлової системи аналогічно до того, як монтують файлові системи. Різні клієнти можуть монтувати віддалений ката­лог у різні точки своїх файлових систем, причому сервер не має інформації про точки монтування його каталогів.

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

NFS використовує протокол монтування і протокол NFS. Як базові компонен­ти обидва протоколи використовують віддалені виклики процедур відповідно до інтерфейсу Sun RPC.

Протокол монтування

Протокол монтування використовують для задання вихідного логічного з'єднан­ня між сервером і клієнтом під час операції монтування. Розглянемо кроки цього протоколу.

1. Клієнт виконує RPC-запит MNT для виклику процедури монтування. Парамет­ром цієї процедури на сервер передають шлях до віддаленого каталогу.

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

Є два підходи до монтування віддалених файлових систем. Перший - це явне монтування, аналогічне до монтування локальних файлових систем. Зокрема, спе­цифікації явного монтування можуть бути додані у файл /etc/fstab. Така конфігу­рація, однак, призводить до проблем, якщо віддалена система недоступна в мо­мент завантаження.

Більш розповсюдженим підходом є автоматичне монтування (automount), коли фактичне монтування каталогу виконують після першого звертання до нього.

Протокол NFS

Цей протокол визначає набір RPC-запитів, що реалізують операції із віддаленими файлами і каталогами (пошук файла в каталозі — LOOKUP, читання набору елемен­тів каталогу — READDIR, створення і вилучення файлів і каталогів — CREATE, REMOVE, MKDIR, RMDIR, читання і записування файлів - READ і WRITE, робота з атрибутами файлів - GETATTR, SETATTR).

Серед цих NFS-запитів, однак, немає аналогів системних викликів ореп() і ciose(). Це відображає фундаментальну властивість NFS-серверів - вони не зберігають стану між звертаннями клієнтів (див. розділ 11.5.1). Такий підхід використову­ють через небезпеку втрати стану в разі виходу сервера з ладу (у цьому випадку подальше використання відкритих файлів стане неможливим).

Те, що NFS-протокол не зберігає стану, визначає дві важливі характеристики запитів, що входять у нього.

1. NFS-запити є незалежними. Усю інформацію, необхідну для виконання такого запиту, потрібно передавати в нього як параметри. Наприклад, запит WRITE має приймати як параметри унікальний ідентифікатор файла та зсув усередині файла.

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

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

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

Якщо сервер вийде з ладу, клієнт повторюватиме запити в циклі і продовжу­вати роботу не зможе. Спосіб завершення циклу задають під час монтування ка­талогу. У разі жорсткого монтування (hard mount) цикл триватиме нескінченно (він може бути перерваний тільки після відновлення роботи сервера), у разі м'я­кого монтування (soft mount) цикл переривають після закінчення деякого часу (звичайно кількох хвилин), а клієнтові повертають помилку. За замовчуванням використовують жорстке монтування.

Кешування у NFS

Проблеми, які виникають під час реалізації кешування в NFS, наведено нижче.

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

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

Другою проблемою є забезпечення когерентності кеша клієнтів. Опишемо ба­зовий спосіб вирішення цієї проблеми у NFS.

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

Файлові блокування у NFS

Організація файлових блокувань на рівні NFS-протоколу неможлива, оскільки для цього потрібне збереження інформації на сервері. Сучасні версії NFS реалізу­ють підтримку блокувань за допомогою окремого протоколу NLM (Network Lock Manager). Коли NFS-клієнт запроваджує або знімає файлове блокування, буде згенеровано RPC-виклик відповідно до цього протоколу.

Протокол NLM підтримує збереження стану. У зв'язку з цим його викори­стання ускладнює обробку збоїв клієнта і сервера.

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

♦ У разі перезапуску клієнта він має надіслати серверу відповідне повідомлен­ня, після чого сервер вивільняє всі його блокування. Зазначимо, що в разі ава­рійного завершення клієнт зазвичай не встигає відіслати таке повідомлення, і його блокування адміністратор системи має вивільняти вручну.

Безпека даних у NFS

Керування доступом у NFS ґрунтується на рівнях аутентифікації Sun RPC.

Вихідна модель керування доступом не є безпечною, оскільки вона викори­стовує рівень аутентифікації AUTH_UNIX. Кожен NFS-запит супроводжують uid і на­бір gid, які порівнюють з атрибутами безпеки необхідного файла. У разі збігу ідентифікаторів і наявності відповідних прав вважають, що доступ до файла до­зволено. Проблеми, що виникають при цьому, описані у пункті 20.2.2.

Деякі сучасні реалізації NFS дають змогу використовувати аутентифікацію рівня AUTH_DES, таку технологію називають Secure NFS.