• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Протокол NFS

Вирішення задачі передачі даних з використанням мережевих файлових систем

Тема 12. Обмін файлами у мережах. NFS, SMB, BitTorrent

Література

1. http://www.linuxcenter.ru/lib/books/ftp/

На даний момент у вашому розпорядженні повинно бути працююче TCP/IP-підключення до вашої мережі. Ви повинні бути в змозі пінгувати інші комп'ютери мережі і, якщо ви відповідним чином налаштували шлюз, ви також повинні бути в змозі пінгувати комп'ютери в Інтернеті. Як відомо, головною метою підключення комп'ютера до мережі, є отримання доступу до інформації. Хоча деякі люди можуть підключати комп'ютер до мережі просто так, більшість людей хотіли б надавати і отримувати доступ до файлів і принтерів. Вони хотіли б отримувати доступ до документів в Інтернеті або грати в онлайнові ігри. Встановивши у свою нову систему Slackware підтримку TCP/IP і необхідне програмне забезпечення, ви все це отримаєте, а проте, встановивши тільки підтримку TCP/IP, функціональність буде дуже обмеженою. Щоб надавати і отримувати загальний доступ до файлів, нам буде потрібно переносити їх туди і назад, використовуючи FTP або SCP. Ми не можемо поглядати на нашому нової комп'ютері зі Slackware дерево файлів через значки "Мережеве оточення" або "Вся мережа" з Windows-комп'ютерів. Ми хотіли б мати можливість мати постійний доступ до файлів на інших Unix-машинах.

В ідеалі ми хотіли б використовувати мережеву файлову систему, що дозволяє нам мати прозорий доступ до файлів на комп'ютерах. Програмами, які ми використовуємо для роботи з інформацією, що зберігається на комп'ютерах, насправді навіть не треба знати на якому комп'ютері зберігається потрібний файл. Їм потрібно тільки знати, що цей файл існує, і спосіб для його отримання. Подальше вже є завданням операційної системи, що забезпечує доступ до цього файлу за допомогою доступних локальних і мережевих файлових систем. Дві найбільш часто використовувані мережеві файлові системи – це SMB (реалізована через Samba) і NFS.

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

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

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

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

На рисунку 12.1 показані типові налаштування NFS клієнта і NFS сервера.

Рисунок 12.1 – Типові налаштування NFS клієнта і NFS сервера

На цьому рисунку необхідно звернути увагу на наступне:

1. Клієнту байдуже, чи отримує він доступ до локального файла або до NFS файлу. Ядро визначає це, коли файл відкритий. Після того як файл відкритий, ядро передає всі звернення до локальних файлів в квадратик, позначений як "доступ до локальних файлів", а всі посилання на NFS файли передаються в квадратик "NFS клієнт".

2. NFS клієнт відправляє RPC запити NFS сервера через модуль TCP/IP. NFS зазвичай використовує UDP, однак більш нові реалізації можуть використовувати TCP.

3. NFS сервер отримує запити від клієнта у вигляді UDP датаграм на порт 2049. Незважаючи на те, що NFS може працювати з перетворювачем портів, що дозволяє серверу використовувати динамічно призначаються порти, UDP порт 2049 жорстко закріплений за NFS в більшості реалізацій.

4. Коли NFS сервер отримує запит від клієнта, він передаються локальної підпрограмі доступу до файлу, яка забезпечує доступ до локальному диску на сервері.

5. Сервера може знадобитися час, для того щоб обробити запити клієнта. Навіть доступ до локальної файлової системи може зайняти деякий час. Протягом цього часу сервер не хоче блокувати запити від інших клієнтів, які також повинні бути обслужені. Щоб справитися з подібною ситуацією, більшість NFS серверів запускаються кілька разів, тобто усередині ядра існує кілька NFS серверів. Конкретні методи рішення залежать від операційної системи. У більшості ядер Unix систем не «живе» кілька NFS серверів, замість цього запускається кілька користувальницьких процесів (які зазвичай називаються nfsd), які здійснюють один системний виклик і залишаються всередині ядра в якості процесу ядра.

6. Точно так само, NFS клієнту потрібен час, щоб обробити запит від користувача процесу на хості клієнта. RPC видається на хост сервера, після чого очікується відгук. Для того, щоб користувальницькі процеси на хості клієнта могли в будь-який момент скористатися NFS, існує кілька NFS клієнтів, запущених всередині ядра клієнта. Конкретна реалізація також залежить від операційної системи. Unix система зазвичай використовує техніку, що нагадує NFS сервер: користувальницький процес, званий biod, здійснює один єдиний системний виклик і залишається всередині ядра як процес ядра.

Більшість Unix хостів може функціонувати як NFS клієнт і як NFS сервер, або як і те й інше одночасно. Більшість PC реалізацій (MS-DOS) мають тільки реалізації NFS клієнта. Більшість IBM мейнфреймів надає тільки функції NFS сервера.

NFS насправді – це щось більше, ніж просто NFS протокол. В таблиці 12.1 показані різні програми RPC, які використовуються з NFS.

Версії, які було наведено в таблиці 12.2 у вигляді одиниць, знайдені в таких системах як SunOS 4.1.3. Нові реалізації надають більш нові версії деяких програм. Solaris 2.2, наприклад, також підтримує версії 3 і 4 перетворювача портів і версію 2 демона mount. SVR4 також підтримує версію 3 перетворювача портів.

Демон монтування викликається на хості NFS клієнта, перед тим як клієнт може отримати доступ до файлової системи сервера. Ми опишемо цей процес нижче.

Менеджер блокування і монітор статусу дозволяють клієнту заблокувати частина файлів, які знаходяться на NFS сервері. Ці дві програми не залежні від протоколу NFS, тому що блокування потребує ідентифікації клієнта і на хості клієнта, і на сервері, а NFS сам по собі "байдужий". (Нижче ми скажемо про байдужості NFS більш докладно.) Глави 9, 10 і 11 [X/Open 1991] документують процедури, які використовуються менеджером блокування і монітором статусу для блокування в NFS.

Таблиця 12.1 - Різні RPC програми, використовувані в NFS

Одна з основ NFS реалізується описувачем файлів. Для звернення до файлу або директорії на сервері об'єкта використовується opaque. Термін opaque позначає, що сервер створює описувач файлу, передає його назад клієнтові, який клієнт потім використовує при зверненні до файлу. Клієнт ніколи не переглядає вміст описателя файлу - його вміст становить інтерес тільки для сервера.

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

Зазвичай користувальницький процес не працює з описувачем файлів. Обмін описувачем файлів здійснюють NFS клієнт і NFS сервер. У версії 2 NFS описувач файлу займає 32 байти, а у версії 3 він виріс до 64 байт.

Unix сервери зазвичай зберігають у описувач файлу наступну інформацію: ідентифікатор файлової системи (major і minor номера пристрою файлової системи), номер инода (i-node) (унікальний номер усередині файлової системи), номер покоління инода (номер, який змінюється кожен раз, коли инод повторно використовується для іншого файлу).

На протязі 1994 року було випущені специфікації для версії 3 протоколи NFS [Sun Microsystems 1993]. Реалізації, як очікується, стануть доступними протягом 1994 року.

Тут коротко описані основні відмінності між версіями 2 і 3. Ми будемо називати їх V2 і V3:

1. Описувачі файлів у V2 це масив фіксованого розміру - 32 байта. У V3 це масив змінного розміру з розміром до 64 байт. Масив змінної довжини в XDR визначається 4-байтним лічильником, за яким слідують реальні байти. Це зменшує розмір описателя файлу в таких реалізаціях, як, наприклад, Unix, де потрібно всього близько 12 байт, проте дозволяє не-Unix реалізаціям обмінюватися додатковою інформацією.

2. V2 обмежує кількість байт на процедури READ або WRITE RPC розміром 8192 байта. Це обмеження не діє в V3, що, у свою чергу, означає, що з використанням UDP обмеження буде тільки в розмірі IP датаграми (65535 байт). Це дозволяє використовувати великі пакети при читанні і запису у швидких мережах.

3. Розміри файлів і початкове зміщення байтів для процедур READ і WRITE розширені з 32 до 64 біт, що дозволяє працювати з файлами більшого розміру.

4. Атрибути файлу повертаються в кожному виклику, який може вплинути на атрибути. Це зменшує кількість викликів GETATTR, необхідних клієнтом.

5. Записи (WRITE) можуть бути асинхронними, тоді як у V2 вони повинні були бути синхронними. Це може поліпшити продуктивність процедури WRITE.

6. Одна процедура була видалена (STATFS) і сім були додані: ACCESS (перевірка прав доступу до файлу), MKNOD (створення спеціального файлу Unix), READDIRPLUS (повертає імена файлів у директорії разом з їх атрибутами), FSINFO (повертає статистичну інформацію про файлову систему ), FSSTAT (повертає динамічну інформацію про файлову систему), PATHCONF (повертає POSIX.1 інформацію про фото) і COMMIT (передає раніше зроблені асинхронні запису на постійне зберігання).

Процедури авторизації і монтування

Клієнт використовує NFS протокол монтування, щоб змонтувати файлову систему сервера, перед тим як отримати доступ до NFS файлів. Зазвичай це відбувається при завантаженні клієнта. У результаті клієнт отримує описувач файлу файлової системи сервера.

На рисунку 12.2 описана послідовність дій Unix клієнта при виконанні команди mount.

При цьому здійснюються наступні кроки:

1. При завантаженні сервера на ньому стартує перетворювач портів.

2. Після перетворювача портів на сервері стартує демон монтування (mountd). Він створює кінцеву точку TCP і кінцеву точку UDP, а також призначає кожній з них динамічно призначається номер порту. Потім він реєструє ці номери у перетворювача портів.

3. Клієнт виповнюється команду mount, яка видає RPC виклик на перетворювач портів сервера, щоб отримати номер порту від демона монтування на сервері. Для обміну між клієнтом і перетворювачем портів можуть бути використані і TCP і UDP, проте зазвичай використовується UDP.

4. Перетворювач портів повідомляє номер порту.

5. Команда mount видає RPC виклик демону монтування, щоб змонтувати файлову систему сервера. І знову може бути використаний як TCP, так і UDP, проте зазвичай використовується UDP. Тепер сервер може перевірити "придатність" клієнта ґрунтуючись на його IP адресу і номер порту, щоб переконатися, чи можна цьому клієнту змонтувати зазначену файлову систему.

6. Демон монтування відгукується описувачем файлу зазначеної файлової системи.

7. Команда mount клієнта видає системний виклик mount, щоб зв'язати описувач файлу, отриманий у кроці 5, з локальною точкою монтування на хості клієнта. Описувач файлу зберігається в коді NFS клієнта, і з цього моменту будь-яке звернення користувача процесів до файлів на файловій системі сервера буде використовувати описувач файлу як стартову точку.

Рисунок 12.2 – Протокол монтування, використовуваний Unix командою mount

Подібна реалізація віддає весь процес монтування, крім системного виклику mount на клієнті, призначеним для користувача процесам, а не ядра. Три програми, які ми показали - команда mount, перетворювач портів і демон монтування - користувача процеси.

У цьому прикладі на хості sun (NFS клієнт) була виконана команда

# mount -t nfs bsdi:/usr /nfs/bsdi/usr

Ця команда монтує директорію /usr на хості bsdi (NFS сервер) як локальну файлову систему /nfs/bsdi/usr. На рисунку 12.3 показаний результат.

Рисунок 12.3 – Монтування директорії bsdi:/usr як /nfs/bsdi/usr на хості sun

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

1. GETATTR. Повертає атрибути файлів: тип файлу (звичайний файл, директорія і так далі), права доступу, розмір файлу, власника файлу, час останнього звернення і так далі.

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

3. STATFS. Повертає статус файлової системи: розмір вільного простору, оптимальний розмір для передачі і так далі. Використовується, наприклад, Unix командою df.

4. LOOKUP. "Оцінює" файл. Ця процедура викликається клієнтом щоразу, коли користувальницький процес відкриває файл, який знаходиться на NFS сервері. Повертається описувач файлу, разом з атрибутами файлу.

5. READ. Читає з файлу. Клієнт вказує описувач файлу, початковий зсув в байтах і максимальна кількість байтів, яке необхідно вважати (до 8192).

6. WRITE. Записує у файл. Клієнт вказує описувач файлу, початковий зсув в байтах, кількість байт, яке необхідно записати, і дані, які необхідно записати.

7. Потрібно, щоб NFS записи були синхронними (з очікуванням). Сервер не може відповісти OK доти, поки дані не були успішно записані (і будь-яка інша інформація про фото, яка повинна бути оновлена) на диск.

8. CREATE. Створює файл.

9. REMOVE. Видаляє файл.

10. RENAME. Перейменовує файл.

11. LINK. Робить жорсткий лінк на файл. Жорсткий лінк це Unix концепція, яка визначає, що конкретний файл на диску може мати будь-яку кількість точок входу (імен, які також називаються жорсткими лінками), які вказують на цей файл.

12. SYMLINK. Створює символічний лінк на файл. Символічний лінк це файл, який містить ім'я іншого файлу. Більшість операцій, що здійснюються над символічним лінком (наприклад, відкриття), насправді відбуваються з тим файлом, на котрий вказує символічний лінк.

13. READLINK. Читання символічного лінка повертає ім'я файлу, на який вказує символічний лінк.

14. MKDIR. Створює директорію.

15. RMDIR. Видаляє директорію.

16. READDIR. Читаю директорію. Використовується, наприклад, Unix командою ls.

Насправді, наведені імена процедур починаються із префікса NFSPROC_, який ми опустили.

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

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

Реалізація NFS Berkeley Net/2 підтримує як UDP, так і TCP. [Macklem 1991] описує цю реалізацію. Давайте розглянемо, чим відрізняється використання NFS при роботі поверх TCP.

Коли сервер завантажується, він запускає NFS сервер, який здійснює активне відкриття на TCP порт 2049, очікуючи приходу запиту на з'єднання від клієнта. Це зазвичай робиться на додаток до звичайного NFS UDP, який очікує входять датаграми на UDP Порті 2049.

Коли клієнт монтує файлову систему сервера з використанням TCP, він здійснює активне відкриття на TCP порт 2049 на сервері. При цьому встановлюється TCP з'єднання між клієнтом і сервером для цієї файлової системи. Якщо той же самий клієнт монтує ще одну файлову систему на тому ж самому сервері, створюється ще одне TCP з'єднання.

І клієнт, і сервер встановлюють TCP опцію "залишайся в живих" на своїх кінцях з'єднання. Це дозволяє визначити момент виходу з ладу або перезавантаження того чи іншого учасника обміну.

Всі додатки на клієнті, які використовують файлову систему сервера, ділять одне і те ж TCP з'єднання для цієї файлової системи. Наприклад, якщо була на рисунку 12.3, б ще одна директорія на bsdi, з ім'ям smith, нижче директорії /usr, звернення до файлів в /nfs/bsdi/usr/rstevens та /nfs/bsdi/usr/smith ділили б одне і те ж TCP з'єднання.

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

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

З часом і інші виробники планують розпочати підтримку NFS поверх TCP.

Читайте також:

1. Багаторівневий підхід. Протокол. Інтерфейс. Стек протоколів.
2. Види атак на механізми та протоколи автентифікації
3. Віддалена робота із ОС. Протокол SSH. Утиліта putty
4. Деякі протоколи і послуги Рівня застосувань.
5. Дипломатичний протокол: сутність і роль в міжнародних відносинах
6. Довідка. Протокол, витяг із протоколу
7. Додаткові протоколи до Женевських конвенцій 1977 р.
8. Етапи еволюції поштових протоколів
9. Задачі протоколів обміну файлами
10. Кіотський протокол
11. Класифікація протоколів
12. Криптографічні протоколи автентифікації

Переглядів: 1032