Основи конфігурування мережевих файлових систем (на прикладі NFS)
Зміст
Розподілені файлові системи
Загальні властивості розподілених файлових систем
Питання розробки
Мережева файлова система NFS
Погляд з боку користувача
Цілі розробки
Компоненти NFS
Відсутність збереження стану
Загальні відомості про роботу і навантаженні NFS
Операції з атрибутами
Операції з даними
Порівняння програм з різними наборами операцій NFS
Характер робочого навантаження NFS
"Повністю активні" клієнти
Типовий приклад використання NFS
NFS і клієнтські ПК
Операційні системи реальної пам'яті
Більш дрібні файли
Менш вимогливі клієнти
Клієнт NFS
Взаємодія з системою віртуальної пам'яті
Файлова система з реплікацією даних (CFS)
Конфігурування NFS-сервера
Вихідні передумови
Конфігурація мережі (локальної і глобальної)
Мережева середу, що визначається профілем програми
Використання високошвидкісних мереж для запобігання перевантаження
NFS і глобальні мережі
Вибір типу мережі і кількості клієнтів
Споживання процесорних ресурсів
Конфігурації дискової підсистеми і балансування навантаження
Організація послідовного доступу в NFS з інтенсивним використанням даних
Організація довільного доступу в NFS з інтенсивними запитами атрибутів
Розподіл навантаження з доступу до дисків за допомогою програмного забезпечення типу Online: DiskSuit
Використання оптимальних зон диска
Заключні рекомендації по конфігурації дисків
Нестандартні вимоги до пам'яті
PrestoServe/NVSIMM
Забезпечення резервного копіювання та стійкості до несправностей
Попередня оцінка робочого навантаження
Вимірювання існуючих систем
Оцінка навантаження під час відсутності системи
Оцінка середовища з інтенсивним використанням даних
Оцінка середовища з інтенсивним використанням атрибутів
Розподілені файлові системи
, що з'явилася в 70-х роках можливість об'єднання комп'ютерів в єдину мережу зробила революцію в комп'ютерній промисловості. Ця можливість перш за все
викликала бажання організувати розділення доступу до файлів між різними комп'ютерами. Перші досягнення в цій галузі були обмежені можливістю
копіювання цілих файлів з однієї машини в іншу. Як приклад можна вказати програму UNIX-to-UNIX copy (uucp) і File Transfer Protocol (ftp). Однак ці
рішення не дозволяли навіть близько підійти до реалізації доступу до файлів на віддаленій машині, за своїми можливостями нагадує доступ до файлів на
локальних дисках.
Тільки в середині 80-х років з'явилося кілька розподілених файлових систем, які забезпечили прозорий доступ через мережу до виділених файлів. Це
були Network File System (NFS) компанії Sun Microsystems (1985), Remote File Sharing system (RFS) компанії AT & T (1986) і Andrew File System (AFS)
університету Карнегі-Меллона (1995). Ці три системи різко відрізнялися один від одного по цілям розробки, архітектурі і семантику, хоча всі вони намагалися
вирішити одну й ту саму фундаментальну проблему. Сьогодні RFS доступна практично на всіх системах, що базуються на UNIX System V. Розробка ASF перейшла
корпорації Transarc, в якій вона була розвинена і перетворена на Distributed File System (DFS) - компоненнти розподіленої обчислювальної середовища DSE (Distributed
Computing Environment) Open Software Foundation. Але найбільше поширення отримала NFS, яка підтримується на всіх UNIX і багатьох "не UNIX"
системах.
Загальні властивості розподілених файлових систем
Традиційна централізована файлова система дозволяє безлічі користувачів, що працюють на одній системі, розділяти доступ до файлів,
що зберігаються локально на цій машині. Розподілена файлова система розширює ці можливості, дозволяючи розділяти доступ до файлів користувачам на різних
машинах, об'єднаних між собою за допомогою мережі. В основі розподілених файлових систем лежить модель клієнт-сервер. У даному випадку під клієнтом
розуміється машина, яка звертається до деякого файлу, а під сервером - машина, що зберігає файли і забезпечує доступ до них. Деякі системи
вимагають, щоб клієнти і сервери були різними машинами, у той час як інші припускають, щоб одна машина працювала і як клієнт, і як сервер.
Важливо зазначити відмінність між розподіленими файловими системами та розподіленими операційними системами. Розподілена операційна система,
подібна V або Amoeba, для користувача виглядає як централізована операційна система, але працює одночасно на декількох машинах. Вона може
мати файлову систему, яка поділяється усіма машинами системи. На відміну від них, розподілена файлова система являє собою певний шар
програмного забезпечення, що керує зв'язком між традиційними операційними системами та файловими системами. Цей шар програмних засобів
інтегрується з операційними системами мащін-хостів мережі і забезпечує сервіс розподіленого доступу до файлів для систем, які мають централізоване
ядро.
Розподілені файлові системи мають ряд важливих властивостей. Кожна конкретна система може мати всі або частиною цих властивостей. Це якраз і створює
основу для порівняння різних архітектур між собою.
Мережева прозорість - Клієнти повинні мати можливість звертатися
до виділених файлів користуючись тими ж самими операціями, що і для доступу
до локальних файлів.
Прозорість розміщення - Файл не повинно визначати його
місця розташування в мережі.
Незалежність розміщення - Файл не повинно змінюватися при
зміну його фізичного меторасположенія.
Мобільність користувача - Користувачі повинні мати можливість
звертатися до поділюваних файлів з будь-якого вузла мережі.
Стійкість до збоїв - Система повинна продовжувати функціонувати
при несправності окремого компонента (сервера або сегменту мережі).
Однак це може призводити до деградації продуктивності або до
виключення доступу до деякої частини файлової системи.
Масштабованість - Система повинна мати можливість
масштабування в разі збільшення навантаження. Крім того, повинна
існувати можливість поступового нарощування системи шляхом додавання
окремих компонентів.
Мобільність файлів - Повинна бути можливість переміщення файлів з
одного місця розташування до іншого на працюючій системі.
Питання розробки
Є декілька важливих питань, які розглядаються при розробці розподілених файлових систем. Вони стосуються функціональних можливостей,
семантики та продуктивності системи. Різні файлові системи можна порівнювати між собою, з'ясовуючи як вони вирішують ці питання:
Простір імен - Деякі розподілені файлові системи
забезпечують однорідне простір імен таке, що кожен клієнт
використовує один і той же колійне ім'я для доступу до даного файлу. Інші
системи дозволяють клієнту створювати свій простір імен шляхом
монтування поділюваних піддерев до довільним каталогами в ієрархії
файлів. Обидва методи мають свою привабливість.
Операції зі збереженням і без збереження станів - Сервер
зберігає стану забезпечує зберігання інформації про операції
клієнта між запитами і використовує цю інформацію про стан для
коректного обслуговування подальших запитів. Такі запити як open або
seek пов'язані зі зміною станів, тому що хтось повинен запам'ятати
інформацію про те, які файли відкрив клієнт, а також усі зміщення в
відкритих файлах. У системі без збереження станів кожен запит є
"самодостатньою" і сервер не підтримує стійких станів
про клієнтів. Наприклад, замість того, щоб підтримувати інформацію про
зміщення у відкритому файлі сервер може вимагати від клієнта вказівки зміщення
в кожній операції читання або запису. Сервери зі збереженням станів
працюють швидше, оскільки вони можуть використовувати знання про стан
клієнта для істотного зменшення мережевого трафіку. Однак вони повинні
мати й цілий комплекс механізмів підтримки узгодженого стану
системи і відновлення після її відмови. Сервери без збереження станів
більш прості в розробці та реалізації, а не дають такої високої
продуктивності.
Семантика розділення - Розподілена файлова система повинна
визначити семантику, яка застосовується коли декілька клієнтів
одночасно звертаються до одного файлу. Семантика UNIX вимагає, щоб усі
зміни, зроблені одним клієнтом, були б видно іншим клієнтам, коли
вони видають наступний системний виклик read або write. Деякі файлові
системи забезпечують "семантику сесії" (session semantics), при
якої зміни стають доступними іншим клієнтам на основі
гранулювання системних викликів open і close. А деякі системи дають
навіть ще більш слабкі гарантії, наприклад, інтервал часу, який повинен
пройти перш, ніж зміни, напевно, потраплять до іншим клієнтам.
Методи віддаленого доступу - У простій моделі клієнт-сервер
використовується метод віддаленого обслуговування, при якому кожна дія
ініціюється клієнтом, а сервер просто представляє собою агента, який
виконує заявки клієнта. У багатьох розподілених системах, особливо в
системах, що зберігають стан, сервер грає набагато більш активну
роль. Він не тільки обслуговує запити клієнтів, але і бере участь у роботі
механізму забезпечення когерентності, повідомляючи клієнтів про всі випадки,
коли кешовані в ньому дані стають недостовірними.
Мережева файлова система NFS
Компанія Sun Microsystems представила NFS в 1985 році як засіб забезпечення прозорого доступу до віддалених файлових систем. Крім
публікації протоколу Sun ліцензувала його базову реалізацію, яка була використана різними постачальниками для портування NFS на різні
операційні системи. З тих пір NFS фактично стала промисловим стандартом, який підтримується дійсно усіма варіантами системи UNIX, а також
деякими іншими системами, наприклад, VMS і MS-DOS.
Архітектура NFS базується на моделі клієнт-сервер. Файл-сервер являє собою машину, яка експортує деякий набір файлів. Клієнтами є
машини, що мають доступ до цих файлів. Одна машина може для різних файлових систем виступати як як сервер, так і як клієнт.
Однак програмний код NFS розділений на дві частини, що дозволяє мати лише клієнтські або тільки серверні системи.
Клієнти і сервери взаємодіють за допомогою віддалених викликів процедур (rpc - remote procedure call), які працюють як синхронні запити. Коли
додаток на клієнті намагається звернутися до віддаленого файлу, ядро посилає запит на сервер, а процес клієнта блокується до отримання відповіді. Сервер чекає
приходять запити, обробляє їх і відсилає відповіді тому клієнтам.
Погляд з боку користувача
Сервер NFS експортує одну або кілька файлових систем. Кожна експортована файлова система може бути або цілим розділом диска або його
піддерево. (Різні варіанти UNIX мають свої власні правила дроблення експортованих систем. Деякі з них можуть, наприклад, дозволяти
експортувати тільки файлову систему цілком, інші - тільки одне одне піддерево в кожній файловій системі). Сервер може визначити, звичайно
за допомогою рядків у файлі/etc/exports, які клієнти можуть мати доступ до кожної експортованої файлової системи, а також дозволений режим доступу до
неї: "тільки читання" або "читання і запис".
Потім клієнтські машини можуть подмонтіровать таку файлову систему або її піддерево до будь-якого каталогу у своїй існуючої ієрархії файлів, точно так само,
як вони змогли б змонтувати будь-яку локальну файлову систему. Клієнт може монтувати каталог з режимом "тільки читання", навіть якщо сервер
експортує його в режимі "читання і запис". NFS підтримує два типи монтування: жорстке і мякгое. Від типу монтування залежить поведінка
клієнта у випадку, якщо сервер не відповідає на запит. Якщо файлова система змонтована жорстко, клієнт продовжує повторні запити до отримання відповіді. У
випадку м'якого монтування клієнт через деякий час відмовляється від повторних запитів і отримує помилки. Коли монтування вироблено, клієнт
може звертатися до файлів на віддаленій файловій системі, використовуючи ті ж самі операції, які застосовуються до локальних файлів. Деякі системи
підтримують також такий тип монтування, поведінка якого відповідає жорсткого монтування при організації повторних спроб змонтувати файлову
систему, але виявляється м'яким для наступних операцій введення/виводу.
Операції монтування NFS менш обмежені в порівнянні з операціями монтування локальних файлових систем. Протокол не вимагає, щоб викликає
операцію монтування користувач був привілейованим, хоча більшості користувачів нав'язуються ці вимоги. (Наприклад, ULTRIX компанії Digital
дозволяє будь-якому користувачеві монтувати файлову систему NFS до тих пір, поки ця особа має права доступу по запису в каталог точки монтування.
Користувач може монтувати ту ж саму файлову систему до кількох точках дерева каталогів, навіть до свого підкаталогу. Сервер може експортувати тільки
свої локальні файлові системи і не може перетинати свої власні точки монтування під час проходу по подорожнього імені. Таким чином, щоб побачити
всі файли сервера, клієнт повинен змонтувати всі його файлові системи.
На малюнку 4.1 приведений приклад. Серверна система nfssrv має два диски. Вона змонтувала диск 1 до каталогу/usr/local диска 0 і експортувала каталоги
/ usr та/usr/local. Припустимо, що клієнт виконує наступні чотири операції mount:
mount-t nfs nfssrv:/usr/usr
mount-t nfs nfssrv:/usr/u1/u1
mount-t nfs nfssrv:/usr/users
mount-t nfs nfssrv:/usr/local/usr/local
Ріс.4.1. Монтування файлових систем NFS
Всі чотири операції монтування будуть успішно виконані. На клієнта піддерево/usr відображає повне піддерево/usr на nfssrv, оскільки клієнт також
змонтував/usr/local. Піддерево/u1 на клієнті відображає піддерево/usr/u1 на nfssrv. Цей приклад ілюструє, що цілком законно можна монтувати
підкаталог експортованої файлової стстеми (це дозволяють не всі реалізації). Нарешті, піддерево/users на клієнті відображає тільки ту частину піддереві/usr
сервера, яка розміщена на диску 0. Файлова система диска 1 під/users/local не видно.
Цілі розробки
Первісна розробка NFS мала наступні цілі:
NFS не повинна обмежуватися операційною системою UNIX. Будь-яка
операційна система повинна бути здатною реалізувати сервер і клієнт
NFS.
Протокол не повинен залежати від будь-яких певних апаратних
коштів.
Повинні бути реалізовані прості механізми відновлення у випадку
відмов сервера або клієнта.
Додатки повинні мати прозорий доступ до виділених файлів без
використання спеціальних дорожніх імен або бібліотек і без перекомпіляції.
Для UNIX-клієнтів повинна підтримуватися семантика UNIX.
Продуктивність NFS повинна бути порівнянна з продуктивністю
локальних дисків.
Реалізація повинна бути незалежною від транспортних засобів.
Компоненти NFS
Реалізація NFS складається з декількох компонент. Деякі з них локалізовані або на сервері, або на клієнті, а деякі використовуються і тим і
іншим. Деякі компоненти не потрібні для забезпечення основних функціональних возможностеей, але становлять частину розширеного інтерфейсу NFS:
Протокол NFS визначає набір запитів (операцій), які можуть
бути спрямовані клієнтом до сервера, а також набір аргументів і
повертають значення для кожного з цих запитів. Версія 1 цього
протоколу існувала тільки в надрах Sun Microsystems і ніколи не була
випущена. Всі реалізації NFS (у тому числі NFSv3) підтримують версію 2 NFS
(NFSv2), яка вперше була випущена у 1985 році в SunOS 2.0. Версія 3
протоколу була опублікована в 1993 році і реалізована деякими
фірмами-постачальниками. У таблиці 3.1 наведено повний набір запитів NFS.
Протокол віддаленого виклику процедур (RPC) визначає формат всіх
взаємодій між клієнтом і сервером. Кожен запит NFS посилається як
пакет RPC.
Розширене подання даних (XDR - Extended Data
Representation) забезпечує машинно-незалежний метод кодування даних
для пересилання через мережу. Всі запити RPC використовують кодування XDR для
передачі даних. Слід зазначити, що XDR і RPC використовуються для
реалізації багатьох інших сервісів, крім NFS.
Програмний код сервера NFS відповідає за обробку всіх запитів
клієнта і забезпечує доступ до експортним файлових систем.
Програмний код клієнта NFS реалізує всі звернення клієнтської
системи до виділених файлів шляхом посилки серверу одного або кількох
запитів RPC.
Протокол монтування визначає семантику монтування та
від'єднання файлових систем NFS.
NFS використовує кілька фонових процесів-демонів. На сервері
набір демонів nfsd очікують запити клієнтів NFS і відповідають на них. Демон
mountd обробляє запити монтування. На клієнта набір демонів biod
обробляє асинхронний ввід/вивід блоків файлів NFS.
Менеджер блокувань мережі (NLM - Network Lock Manager) і монітор
стану мережі (NSM - Network Status Monitor) разом забезпечують кошти
для блокування файлів у мережі. Ці кошти, хоча формально не пов'язані з
NFS, можна знайти в більшості реалізацій NFS. Вони забезпечують сервіси не
можливі в базовому протоколі. NLM і NSM реалізують функціонування
сервера за допомогою демонів lockd і statd відповідно.
Відсутність збереження стану
Можливо найбільш важливою характеристикою протоколу NFS є те, що сервер, щоб працювати коректно, не запам'ятовує станів і не потребує ні
якої інформації про своїх клієнтів. Кожен запит є повністю незалежним від інших запитів і містить всю необхідну інформацію для його обробки.
Серверу не потрібно підтримувати жодних записів про минулі запитах клієнтів, за винятком необов'язкових можливостей, які можуть використовуватися з метою
кешування даних або для збору статистики.
Наприклад, у протоколі NFS відсутні запити по відкривання та закривання файлів, оскільки вони створили б інформацію про стан, яка повинна
запам'ятовуватися сервером. З цієї ж причини, запити read і write передають як параметр початкове зміщення, на відміну від операцій read і write з
локальними файлами, які отримують зсув з об'єкта "відкритий файл".
Протокол без збереження станів спрощує відновлення після краху системи. Якщо відмовляє клієнтська система, ніякого відновлення не
потрібно, оскільки сервер не підтримує ніякої стійкої інформації про клієнта. Якщо клієнт перезавантажився, він може перемонтувати файлові системи
і запустити програми, які звертаються до виділених файлів. Серверу не потрібно ні знати, ні турбуватися про відмову клієнта.
Якщо відмовляє сервер, то клієнт побачить, що на свої запити він не отримує відповіді. Тоді він продовжує повторно відправляти запити до тих пір, поки сервер
НЕ перезавантажиться. (Це справедливо лише у разі жорсткого монтування (яке виконується за замовчуванням). При м'якій монтуванні клієнт через
деякий час припиняє посилку запитів і повертає з додатком повідомлення про помилку). З цього моменту часу сервер почне отримувати запити і може їх
обробляти, оскільки запити не залежать ні від якої більш ранньої інформації про стан. Коли нарешті сервер відповість на запити, клієнт перестане їх
повторно посилати. У клієнта немає жодних коштів визначити, чи дійсно сервер відмовив і був перезавантаження, або просто повільно виконує операції.
Протоколи з збереженням стану вимагають реалізації складних механізмів відновлення після відмови. Сервер повинен виявляти відмови клієнта і
ліквідувати всі стани, пов'язані з цим клієнтом. Якщо відмовляє і перезавантажується сервер, він повинен повідомити клієнтів так, щоб вони могли
заново створити свій стан на сервері.
Головна проблема роботи без збереження стану полягає в тому, що сервер повинен зафіксувати всі зміни в стабільній пам'яті до посилки відповіді
на запит. Це означає, що не тільки дані файлу, а й усі метадані, такі як індексні дескриптори або непрямі блоки повинні бути скинуті на диск до
повернення результатів. В іншому випадку сервер може втратити дані, про які клієнт впевнений, що вони успішно записалися на диск. (Відмова системи може
призвести до втрати даних навіть у локальній файловій системі, але в таких випадках користувачі знають про відмову і про можливість втратити дані). Робота без
збереження стану пов'язана також з іншими недоліками. Вона вимагає окремого протоколу (NLM) для забезпечення блокування файлів. Крім того, щоб
вирішити проблеми продуктивності операцій синхронному запису більшість клієнтів кешує дані та метадані локально. Але це суперечить гарантіям
протоколу про дотримання узгодженого стану.
Загальні відомості про роботу і навантаженні NFS
Принаймні на системах Sun чисті сервери NFS являють собою найбільш прості для конфігурування широкомасштабні сервери, головним чином
тому, що вони працюють з одним і тим самим кодом операційної системи (мається тільки одна реалізація сервера NFS, яку можна знайти на Sun, оскільки вона
являє собою пов'язаний з операційною системою продукт). Більш того, самі по собі сервіси NFS відносно прості, так як NFS виконує всього 18
операцій, які своєю семантикою обмежені розміщенням видалених файлів і забезпеченням доступу до них. Вони набагато менш складні, наприклад, у порівнянні з
сервісами реляційної бази даних, де є більше 75 операцій, визначених стандартом SQL, причому ці операції застосовуються до складного набору одиниць
даних, які включають структурні відносини. NFS вирішує тільки частина цих проблем і тому набагато простіше.
Нижче в таблиці 3.1 представлені 18 операцій NFS. Шість з них є основними і представляють величезну більшість реально виконуваних операцій як
за кількістю, так і за споживанням ресурсів: getattr, setattr, lookup, readlink, read і write. Ці операції реалізуються пошук і модифікацію атрибутів
файлу, пошук імені файлу, дозвіл символічних зв'язків, а також читання і запис даних відповідно. Можна явно виділити два принципово різних
набору операцій: зокрема, операції read і write маніпулюють дійсним вмістом файла, у той час як інші операції маніпулюють атрибутами
файлів. Відмінності між цими наборами операцій визначаються перш за все типом навантаження, що лягає при виконанні відповідного запиту на серверні
і мережеві ресурси системи.
Таблиця 4.1. Операції NFS
Операція
Призначення операції
getattr
Отримує атрибути файлу такі як тип, розмір, права доступу та дати модифікації
setattr
Змінює значення атрибутів файлу/каталогу
root
Вибирає корінь віддаленої файлової системи в даний час не використовується)
lookup
Розшукує файл у каталозі і повертає розширений дескриптор файлу
readlink
Слід символічної зв'язку на сервері
read
Читає блок даних розміром 8 Кбайт
wrcache
Записує блок даних розміром 8 Кбайт у віддалений кеш (в даний час не використовується)
write
Записує блок даних розміром 8 Кбайт
create
Створює індексний дескриптор файлової системи; може бути файлом або символічної зв'язком
remove
Видаляє індексний дескриптор файлової системи
rename
Змінює рядок імені каталозі файлу
link
Створює жорстку зв'язок у віддаленій файловій системі
symlink
Створює символічний зв'язок у віддаленій файловій системі
mkdir
Створює каталог
rmdir
Видаляє каталог
readdir
Читає рядок каталозі
fsstat
Вибирає динамічну інформацію файлової системи
null
Нічого не робить; використовується для тестування і хронометражу відповіді сервера
У кожному рядку каталозі файлової системи є деяка кількість характеристик, що описують файл або доступ до нього, такі як тип рядка
(файл, символічна зв'язок, каталог), розмір, дати звернень, права доступу тощо Більшість операцій NFS пов'язано з маніпулюванням цими атрибутами
файлу.
Операції з атрибутами
Операції з атрибутами створюють для системи набагато менше навантаження, ніж операції з даними. Оскільки розмір атрибутів файлу дуже малий (пара сотень
байтів на фото), більшість атрибутів файлової системи, пов'язаних з активними файлами, буде буферізованние (кешуватися) в основній пам'яті сервера. Навіть
якщо атрибути файлу не кешуються, вони просто відшукуються і читаються з диска. Після того як атрибути файла вибрані сервером для будь-якого клієнта,
обслуговування будь-якого запиту до цих атрибутів полягає лише в маніпулюванні битами кешованих атрибутів та виконанні звичайного мережевого протоколу.
Накладні витрати, пов'язані з мережевою обробкою цих операцій порівняно високі, оскільки відносна кількість корисних байтів даних в реально
переданому пакеті невелика. Атрибути пересилаються невеликими пакетами (більшість мають розмір 64-128 байт). У результаті операції з атрибутами
споживають відносно невелику смугу пропускання мережі.
Операції з даними
На відміну від операцій з атрибутами, операції з даними за визначенням мають розмір 8 Кбайт. (Це розмір блоку даних, визначений NFS. Порівняно недавно
анонсована версія протоколу NFS + допускає блоки даних розміром до 4 Гбайт. Однак це суттєво не змінює саму природу операцій з даними). Крім
того, у той час як для кожного файлу є тільки один набір атрибутів, кількість блоків даних розміром по 8 Кбайт в одному файлі може бути великим
(потенційно може досягати декілька мільйонів). Для більшості типів NFS-серверів блоки даних зазвичай не кешуються і, таким чином, обслуговування
відповідних запитів пов'язано з істотним споживанням ресурсів системи. Зокрема, для виконання операцій з даними потрібно значно більша
смуга пропускання мережі: кожна операція з даними включає пересилання шести великих пакетів по Ethernet (двох по FDDI). В результаті ймовірність перевантаження
мережі являє собою набагато більш важливий фактор при розгляді операцій з даними.
Як це не дивно, але в більшості існуючих систем домінують операції з атрибутами, а не операції з даними. Якщо клієнтська система NFS
хоче використати файл, що зберігається на віддаленому файл-сервер, вона видає послідовність операцій пошуку (lookup) для визначення розміщення файлу в
віддаленої ієрархії каталогів, за якою йде операція getattr маски для отримання прав доступу і інших атрибутів файлу; нарешті, операція читання витягує
перші 8 Кбайт даних. Для типового файлу, який знаходиться на глибині чотирьох або п'яти рівнів підкаталогів віддаленої ієрархії, просте відкривання
файлу вимагає п'яти-шести операцій NFS. Оскільки більшість файлів досить короткі (у середньому для більшості систем менше 16 Кбайт) для читання всього
файла потрібно менше операцій, ніж для його пошуку та відкриття. Останні дослідження компанії Sun виявили, що з часів операційної системи BSD
4.1 середній розмір файлу істотно збільшився від приблизно 1 Кбайт до трохи більше 8 Кбайт.
Для визначення коректної конфігурації сервера NFS перш за все необхідно віднести систему до одного з двох класів у відповідності з домінуючою робочої
навантаженням для передбачуваних сервісів NFS: з інтенсивними операціями над атрибутами або з інтенсивними операціями над даними.
Порівняння програм з різними наборами операцій NFS
У загальному випадку програми, які звертаються до величезної кількості невеликих файлів, можуть характеризуватися як виконують інтенсивні операції над атрибутами. Можливо
найкращим прикладом такого додатка є класична система розробки програмного забезпечення. Великі програмні системи зазвичай складаються з тисяч
невеликих модулів. Кожен модуль звичайно містить файл включення (include file), файл вихідного коду, об'єктний файл і певний тип файлу управління архівом
(подібний SCCS або RCS). Більшість файлів мають невеликий розмір, часто в межах від 4 до 100 Кбайт. Оскільки зазвичай під час обслуговування транзакції
NFS запитувача блокується, час обробки в таких програмах визначається швидкістю обробки сервером легковагих запитів атрибутів. У загальній кількості
операцій операції над даними займають менше 40%. В більшості серверів з дуже інтенсивним виконанням операцій з атрибутами потрібно тільки помірна
пропускна здатність мережі: пропускна здатність мережі Ethernet (10 Мбіт/с) звичайно є адекватною.
Більшість серверів домашніх каталогів (home directory) потрапляють у категорію
інтенсивного виконання операцій з атрибутами: більшість збережених файлів невеликі. Крім того, що ці файли мають невеликий розмір у порівнянні з
розміром атрибутів, вони дають також можливість клієнтської системі кешувати дані файлу, усуваючи необхідність їх повторного відновлення із сервера.
Програми, що працюють з дуже великими файлами, потрапляють в категорію інтенсивного виконання операцій з даними. До цієї категорії належать,
наприклад, програми з галузі геофізики, обробки зображень та електронних САПР. У цих додатках звичайний сценарій використання NFS робочими станціями
або обчислювальними машинами включає: читання дуже великого файлу, досить тривалу обробку цього файлу (хвилини або навіть години) і, нарешті, зворотну
запис меншого за розмірами файлу результату. Файли в цих прикладних областях часто досягають розміру 1 Гбайт, а файли розміром більше 200 Мбайт є
скоріше правилом, ніж винятком. Під час обробки великих файлів домінують операції, пов'язані з обслуговуванням запитів даних. Для застосувань з
інтенсивним виконанням операцій з даними наявність достатньої пропускної здатності мережі завжди критично.
Наприклад, вважається, що швидкість передачі даних у середовищі Ethernet складає 10 Мбіт/с. Така швидкість здається досить високою, проте 10
Мбіт/с складає всього 1.25 Мбайт/с, і навіть ця швидкість на практиці не може бути досягнута через накладних витрат протоколу обміну і обмеженої
швидкості обробки на кожній з взаємодіючих систем. У результаті реальна гранична швидкість Ethernet складає приблизно 1 Мбайт/с. Але навіть ця
швидкість досяжна тільки майже в ідеальних умовах - при наданні всієї смуги пропускання Ethernet для передачі даних тільки між двома системами. До
нещастя така організація виявляється малопрактічной, хоча насправді нерідко трапляється, що лише невелика кількість клієнтів мережі запитують дані
одночасно. При наявності безлічі активних клієнтів максимальне завантаження мережі становить приблизно 35%, що відповідає агрегатований швидкості
передачі даних 440 Кбайт/с. Сама природа такого типу клієнтів, що характеризуються інтенсивним виконанням операцій з даними, визначає
процес планування конфігурації системи. Вона зазвичай визначає вибір Межовий середовища і часто диктує тип передбачуваного сервера. У багатьох випадках освоєння
додатків з інтенсивним виконанням операцій з даними викликає необхідність перепрокладкі мереж.
У загальному випадку вважається, що в середовищі з інтенсивним виконанням операцій з даними, приблизно більше половини операцій NFS пов'язані з пересиланням
призначених для користувача даних. У ролі представника середовища з інтенсивним виконанням операцій з атрибутами зазвичай береться класична суміш Legato, в
якій 22% всіх операцій складають операції читання (read) і 15% - операції запису (write).
Характер робочого навантаження NFS
Якби клієнти NFS постійно виконували запити до серверів (або мережі), то в конфігурацію системи довелося б включити величезну кількість виділених мереж
Ethernet або велике число високошвидкісних мереж типу FDDI або FastEthernet. На щастя, звичайно трафік NFS має досить вибуховий характер. Клієнти можуть
виконувати інтенсивні запити до файл-серверів або мереж, але періоди такої інтенсивної роботи виникають досить випадково і відносно не дуже часто.
"Повністю активні" клієнти
Решту часу клієнти генерують або невелике число запитів, або взагалі обходяться без них. Скрізь далі по тексту ми будемо називати клієнта,
який активно виконує запити, повністю активним клієнтом. З різних причин багато клієнтів (у ряді випадків такими виявляється переважна
більшість клієнтів) часто виявляються не дуже зайнятими, тим самим не очень навантажуючи, або взагалі не навантажуючи свій сервер. Наприклад, деякі клієнти
працюють на досить потужних системах і можуть кешувати більшість, або всі свої дані. Інші системи використовуються тільки частину робочого часу, і навіть
інтенсивно використовуються клієнти часто залишаються повністю вільними в той час, коли їх власники обідають або перебувають на нарадах.
Типовий приклад використання NFS
Зрештою приклади використання більшості програм показують, що клієнти навантажують сервер дуже нерівномірно. Розглянемо роботу з типовим
додатком. Зазвичай користувач повинен перш за все вважати двійковий код додатку, виконати ту частину коду, яка відповідає за організацію діалогу з
користувачем, який має визначити необхідну для роботи набір даних. Потім програма читає набір даних з диска (можливо віддаленого). Далі
користувач взаємодіє з додатком маніпулюючи поданням даних в основній пам'яті. Ця фаза продовжується більшу частини часу роботи програми
до тих пір, поки в кінці кінців модифікований набір даних не запишеться на диск. Більшість (але не всі) програми дотримуються цієї універсальної схемою
роботи, часто з повторюваними фазами. Наведені нижче малюнки ілюструю типову навантаження NFS.
Рис. 4.2. Журнал трафіку NFS в Sun Net Manager для клієнта на базі 486/33 PC,
використовує Lotus 1-2-3
На малюнку 4.2 показаний фрагмент журналу SunNetManager для ПК 486/33, що працюють під управлінням MS-DOS. Вибуховий характер навантаження клієнтів
проявляється дуже чітко: в короткі проміжки часу видно піки, що досягають 100 операцій в секунду, але середнє навантаження невелика - 7 операцій в
секунду, а типова навантаження можливо становить близько 1 операції в секунду. Цей графік знімався з інтервалом вимірювань в одну секунду, щоб переглянути
швидкість транзакцій при дрібної грануляції.
Рисунок 4.3 показує фрагмент журналу SunNetManager для бездискового клієнта - SPARCstation ELC з 16 Мбайт пам'яті, що виконує різні
інструментальні програми автоматизації офісної діяльності. Щодо рівна навантаження, відображена на цьому графіку, є типовою для більшості
клієнтів (Lotus 1-2-3, Interleaf 5.3, OpenWindows DeskSet, електронної пошти з дуже великими файлами). Хоча є кілька випадків, коли потрібно
швидкість 40-50 операцій в секунду, всі вони мають невелику тривалість (1-5 секунд). Усереднена за часом результуюча загальне навантаження набагато
нижче: в даному випадку істотно нижче 1 операції в секунду, навіть якщо не враховувати вільні нічні години. На цьому графіку інтервал вимірювань становить
10 хвилин. Зауважимо, що це бездискових система з відносно невисокою пам'яттю. Навантаження від клієнтів, оснащених дисками і великою оперативною пам'яттю
буде ще менше.
Нарешті, малюнок 4.4 показує, як випадкова природа роботи різних клієнтів приводить до ефекту згладжування навантаження на сервер. Графік показує
навантаження на сервер двадцяти бездискових клієнтів з пам
