Основи конфігурування мережевих файлових систем на прикладі 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 Redivsentation) забезпечує машинно-незалежний метод кодування даних для пересилки через мережу. Всі запити 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 показує, як випадкова природа роботи різних клієнтів приводить до ефекту згладжування навантаження на сервер. Графік показує навантаження на сервер двадцяти бездискових клієнтів з пам'яттю 16 Мбайт протягом десяти днів.

Рис. 4.4. Навантаження NFS сервера SPARCserver10 протягом 10 днів. Цей сервер обслуговує
20 бездискових клієнтів, у тому числі клієнта, показаного на малюнку 4.3.

NFS і клієнтські ПК

На відміну від робочих станцій, які працюють під управлінням UNIX чи VMS, найбільш поширені операційні системи персональних комп'ютерів MS-DOS і Windows 3.x не використовують однорівневу віртуальну пам'ять для виконання операцій з диском або віртуальних операцій дискового введення / виводу. Системи з однорівневою віртуальною пам'яттю, подібні Solaris, розглядають всі диски і віртуальний дисковий введення / висновок як розширення пам'яті. У результаті має місце тенденція відкладати звернення до диска або мережі до тих пір, поки це не виявиться абсолютно необхідним. Звичайно ця стратегія призводить до більш рівномірного розподілу вимог введення / виводу. У системах з невеликою пам'яттю це іноді призводить до більшої активності введення / виводу, хоча в системах з типовим розміром пам'яті така стратегія забезпечує в середньому значно меншу загальну активність введення / виводу.

Операційні системи реальної пам'яті

Операційні системи персональних комп'ютерів використовують більш просту дворівневу модель введення / виводу, в якій основна пам'ять і введення / висновок файлів управляються окремо. На практиці це призводить навіть до ще меншому навантаженні на підсистему введення / виводу. Наприклад, коли ПК під Windows викликає для виконання Lotus 1-2-3, весь 123.exe копіюються в основну пам'ять системи. При цьому в основну пам'ять копіюється повний код об'ємом 1.5 Мбайт, навіть якщо користувач слідом за цим виконає команду quit без виконання будь-якої іншої функції. Під час виконання програми цей клієнт не буде видавати жодних додаткових запитів на введення / висновок цього файлу, оскільки весь двійковий код знаходиться резидентної в пам'яті. Навіть якщо цей код свопіруется Windows, він буде відкачуватися на локальний диск, що призводить до відсутності мережевого трафіку.

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

Більш дрібні файли

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

Менш вимогливі клієнти

Хоча найбільш швидкі ПК в даний час по продуктивності ЦП цілком можуть оскаржити перевагу робочих станцій початкового рівня, типовий ПК виявляється значно менш вимогливим мережевим клієнтом, ніж типова робоча станція. Частково це відбувається через те, що переважна більшість нинішніх ПК все ще базуються на більш повільних процесорах 386 (і навіть 286), а більш повільні процесори як правило працюють з менш вимогливими додатками і користувачами. Більш того, ці більш повільні процесори, що працюють навіть на повній швидкості, просто генерують запити менш швидко, ніж робочі станції, оскільки внутрішні шини і мережеві адаптери таких ПК не настільки добре оптимізовані в порівнянні з відповідними пристроями систем більшого розміру. Наприклад типові адаптери Ethernet ISA, доступні в 1991 році були здатні підтримувати швидкість передачі даних тільки на рівні 700 Кбайт / с (в порівнянні зі швидкістю більше 1 Мбайт / с, яка досягалася у всіх робочих станціях 1991 року), а деякі досить поширені інтерфейсні плати були здатні забезпечувати швидкість тільки на рівні приблизно 400 Кбайт / с. Ряд ПК, зокрема портативні, використовують інтерфейси "Ethernet", які реально підключаються через паралельний порт. Хоча таке підключення дозволяє заощадити слот шини і досить зручно, однак такий інтерфейс Ethernet виявляється одним із самих повільних, оскільки багато реалізації паралельного порту обмежені швидкістю передачі даних 500-800 Кбіт / с (60-100 Кбайт / с). Звичайно, коли в призначеній для користувача базі стали превалювати ПК на базі процесора 486, оснащені 32-бітовими мережевими адаптерами DMA, ці відмінності поступово стерлися, але корисно пам'ятати, що переважна більшість клієнтів PC-NFS (особливо в нашій країні) потрапляють в старішу, менш вимогливу категорію. Можливості ПК на базі процесора 33 МГц 486DX, оснащеного 32-бітовим інтерфейсом Ethernet, продемонстрована на малюнку 4.2.

Клієнт NFS Взаємодія з системою віртуальної пам'яті

У базуються на UNIX системах, подібних Solaris, робота підсистеми клієнта NFS еквівалентна роботі дискової підсистеми, а саме, вона забезпечує сервіс менеджеру віртуальної пам'яті і, зокрема, файлової системи на тій же самій основі, що і дисковий сервіс, за винятком того, що цей сервіс здійснюється із залученням мережі. Це може здатися очевидним, але має певний вплив на роботу системи NFS клієнт / сервер. Зокрема, менеджер віртуальної пам'яті розташовується між додатками і клієнтом NFS. Виконувані додатками звернення до файлової системи кешуються системою віртуальної пам'яті клієнта, скорочуючи вимоги клієнта до введення / висновку. Це можна побачити на малюнку 4.5. Для більшості додатків більший обсяг пам'яті на клієнті призводить до меншої навантаженні на сервер і більш високого загального (тобто клієнт / сервер) продуктивності системи. Це особливо справедливо для бездискових клієнтів, які змушені використовувати NFS у якості зовнішнього запам'ятовуючого пристрою для анонімної пам'яті.

Рис. 4.5. Взаємодія між додатком, файловою системою віртуальної пам'яті і NFS

Робота механізмів кешування системи віртуальної пам'яті затримує, а іноді й повністю скасовує роботу NFS. Наприклад, розглянемо бездискових робочих станцій, що виконує 1-2-3. Якщо і дані, і виконавчі коди програми розміщуються віддалено, система повинна буде, як і потрібно, завантажити в сторінки пам'яті виконуються двійкові коди 1-2-3 за допомогою NFS. Потім за допомогою NFS у пам'ять будуть завантажені дані. Для більшості файлів 1-2-3 на типово сконфігурованої робочої станції дані будуть кешуватися в пам'яті і залишатися там протягом значного часу (швидше хвилини, а не секунди). Якщо відкривається і залишається відкритим тимчасовий файл, то саме відкриття файлу виконується негайно як на клієнті, так і на сервері, але всі оновлення вмісту файлу зазвичай кешуються на деякий час у клієнті перед передачею на сервер. Відповідно до семантикою UNIX-файлу, коли файл закривається всі зміни повинні бути записані на зовнішній пристрій в даному випадку на сервер NFS. В альтернативному варіанті кешовані записи можуть записуватися на зовнішній пристрій за допомогою демонів fsflush (Solaris 2.x) або udpated (Solaris 1.x). Як і у випадку звичайного дискового введення / виведення, кешовані дані вводу / виводу NFS залишаються в пам'яті до тих пір, поки пам'ять не буде потрібна для будь-яких інших цілей.

Коли операція запису видана в сервер, він повинен зафіксувати ці дані в стабільній пам'яті перед наступною передачею. Однак на клієнті все відбувається дещо інакше. Якщо знову відбувається звернення до кешовані даними, наприклад, якщо в нашому прикладі знову обробляються деякі текстові сторінки 1-2-3, то замість видачі запитів до сервера, звернення задовольняється прямо з віртуальної пам'яті клієнта. Звичайно, коли клієнтові не вистачає пам'яті, для того щоб виділити простір для нових даних модифіковані сторінки швидко записуються назад на сервер, а немодифіковані сторінки просто виключаються.

Файлова система з реплікацією даних (CFS)

Починаючи з версії Solaris 2.3 Sun пропонує нову можливість, яка називається файловою системою з реплікацією даних або кешуючий файлової системою (CFS - Cashed File System). У відповідності зі стандартним протоколом NFS файли вибираються блок за блоком прямо з сервера в пам'ять клієнта і всі маніпуляції з ними відбуваються безпосередньо в цій пам'яті. Дані записуються назад на диск сервера. Програмне забезпечення CFS розташовується між кодом клієнта NFS і методами доступу сервера NFS. Коли блоки даних отримані кодом клієнта NFS, вони кешуються у виділеної області на локальному диску. Локальна копія називається файлом переднього плану (front file), а копія сервера - файлом заднього плану (back file). Будь-яке подальше звернення до кешованих файлів виконується до його копії на локальному диску, а не до копії, що знаходиться на сервері. З очевидних причин така організація може істотно зменшити навантаження на сервер.

На жаль, CFS - це не вичерпне засіб для зниження навантаження на сервер. По-перше, оскільки вона дійсно створює копії блоків даних, система повинна забезпечувати певні заходи для підтримки узгодженого стану цих копій. Зокрема, підсистема CFS періодично перевіряє атрибути файлу заднього плану (періодичність такої перевірки встановлюється користувачем). Якщо файл заднього плану був модифікований, файл переднього плану вичищається з кешу і подальше звернення до (логічного) файлу призведе до того, що він наново буде обраний з сервера і кешуватися. На жаль, більшість прикладних програм продовжують працювати з цілим файлом, а не з певними блоками даних. Наприклад, програми vi, 1-2-3 і ProEngineer читають і записують свої файли даних цілком, незалежно від дійсних цілей користувача. (Взагалі кажучи, програми, що використовують для доступу до файлів команду mmap (2), не звертаються до файлу в цілому, в той час як, програми, що використовують команди read (2) і write (2), зазвичай це роблять). Як наслідок, CFS зазвичай кешує весь файл. У результаті файлові системи NFS, піддаються частим змінам, виявляються не дуже гарними кандидатами для CFS: файли будуть постійно кешуватися і очищатися, що врешті-решт призводить до збільшення загального мережевого трафіку, у порівнянні з простою роботою через NFS.

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

Оскільки CSF є відносно новою можливістю, на жаль було зроблено дуже мало вимірів її поведінки при дійсному використанні. Проте, сама ідея протоколу CSF призводить до наступних рекомендацій:

CSF слід використовувати для файлових систем, з яких головним чином здійснюється читання даних, наприклад, для файлових систем поділюваних кодів додатків. CSF особливо корисна для розділення даних між відносно повільними мережами, наприклад WAN, з'єднаних за допомогою ліній зв'язку рівня менш ніж Т1. CSF корисна і для високошвидкісних мереж, з'єднаних між собою маршрутизаторами, які вносять затримку. Конфігурування NFS-сервера Вихідні передумови

Щоб зібрати достатню і точну інформацію для створення конфігурації сервера NFS необхідно відповісти на наступні питання:

Чи є навантаження інтенсивної за атрибутами чи інтенсивної за даними? Чи будуть клієнти користуватися кешуючий файловою системою для скорочення числа запитів? Скільки в середньому буде повністю активних клієнтів? Які типи клієнтських систем передбачається використовувати і під управлінням яких операційних систем вони працюють? Наскільки великі файлові системи передбачається використовувати в режимі розділення доступу? Повторюються чи запити різних клієнтів до одних і тих же файлів (наприклад, до файлів include), або вони відносяться до різних файлів? Які кількість і тип передбачуваних для експлуатації мереж? Чи є існуюча конфігурація мережі підходящої для відповідного типу трафіку? Чи достатньо в передбачуваній конфігурації сервера кількість ЦП для управління трафіком, пов'язаним із існуючими мережами? Якщо використовуються територіальні мережі (WAN), чи мають середовище передачі даних і маршрутизатори досить малу затримку і високу пропускну здатність, щоб забезпечити практичність застосування NFS? Чи достатньо дискових накопичувачів і головних адаптерів SCSI для досягнення заданої продуктивності? Чи потрібна застосування програмних засобів типу Online: DiskSuit для адекватного розподілу навантаження з доступу до дисків між усіма доступними дисковими накопичувачами? Якщо часто використовуються операції запису NFS, то чи є в конфігурації системи NVSIMM? Чи відповідає передбачувана стратегія резервного копіювання типу, числа і розміщення на шині SCSI пристроїв резервного копіювання? Конфігурація мережі (локальної і глобальної)

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

Мережеве середовище, обумовлена ​​профілем програми

Як зазначалося раніше, найбільш важливим фактором, що визначає вибір конфігурації мережі, є домінуючий тип операцій NFS, використовуваних додатками. Для додатків з інтенсивним навантаженням за даними потрібно відносно невелика кількість мереж, але ці мережі повинні мати більшу смугу пропускання, як наприклад, в мережах FDDI або CDDI. Ці вимоги можуть задовольнятися також за допомогою мереж 100baseT (Ethernet 100 Мбіт / с) або ATM (Asynchronous Transfer Mode 155 Мбіт / с). Більшість інтенсивних по атрибутах додатків працюють і при наявності менше дорогої інфраструктури, хоча може знадобитися велика кількість мереж.

Прийняти рішення щодо вибору типу мережі порівняно просто. Якщо для роботи індивідуального клієнта потрібно агрегатованої швидкість передачі даних, що перевищує 1 Мбайт / с, або якщо для одночасної роботи декількох клієнтів необхідна смуга пропускання мережі, що перевищує 1 Мбайт / с, то такі програми вимагають застосування високошвидкісних мереж. Реально ця цифра (1 Мбайт / с) штучно завищена, оскільки вона характеризує швидкість передачі даних, яку ви гарантуєте не перевищувати. Звичайно більш розумно розглядати швидкість мережі Ethernet рівної приблизно 440 Кбайт / с, а не 1 Мбайт / с. (Зазвичай користувачі сприймають Ethernet як "неотвечающую" вже приблизно при 35% завантаженні мережі. Наведена тут цифра 440 Кбайт / с відповідає 35%-ної завантаженні лінії з пропускною здатністю 1.25 Мбайт / с).

Якщо програма в усталеному режимі роботи не вимагає широкої смуги пропускання, то можливо буде достатня менш швидкісна мережеве середовище типу Ethernet або TokenRing. Це середовище забезпечує достатню швидкість передачі даних при виконанні операцій lookup і getattr, які домінують у додатках з інтенсивним використанням атрибутів, а також відносно легкий трафік даних, пов'язаний з таким використанням.

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

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

Загальний ефект такої організації проявляється в тому, що максимальна швидкість передачі даних між клієнтом і сервером, які взаємодіють через кільце FDDI, складає приблизно 2.7 Мбайт / с. (Ця швидкість досягається тільки при додаванні в файл / etc / system на клієнті оператора set nfs: nfs_async_threads = 16. Клієнти SunOS 4.1.x повинні запускати 12 демонів biod, а не 8, як це робиться за замовчуванням). Ця швидкість всього в три рази перевершує максимальну швидкість, яку забезпечує Ethernet незважаючи на те, що швидкість середовища FDDI в десять разів більше. (NFS являє собою протокол прикладного рівня (рівня 7 в моделі OSI). Протоколи більш низьких рівнів, такі як TCP і UDP можуть працювати з набагато більш високими швидкостями, використовуючи ті ж самі апаратні засоби. Більша частина часу витрачається на очікування відповідей та іншу обробку прикладного рівня. Інші протоколи прикладного рівня, які не розраховані на негайне отримання відповіді та / або підтвердження, також можуть ефективно використовувати значно більш високу швидкість середовища). Пікова швидкість при використанні 16 Мбіт / с Token Ring складає приблизно 1.4 Мбайт / с. Порівняно недавно була анонсована нова версія протоколу NFS +, яка усуває цей недолік, дозволяючи роботу з блоками значно більших розмірів. NFS + допускає пересилання блоків даних майже довільних розмірів. Клієнт і сервер домовляються про максимальний розмір блоку при кожному монтуванні файлової системи. При цьому розмір блоку може збільшуватися до 4 Гбайт.

Головна перевага 100-Мбітних мереж при роботі із звичайними версіями NFS полягає в тому, що ці мережі можуть підтримувати багато одночасних передач даних без деградації. Коли сервер пересилає по Ethernet дані клієнту із швидкістю 1 Мбайт / с, то така передача споживає 100% доступної смуги пропускання мережі. Спроби передачі по цій мережі більшого обсягу даних призводять до більш низької пропускної здатності для всіх користувачів. Ті ж самі клієнт і сервер можуть здійснювати пересилання даних зі швидкістю 2.7 Мбайт / с по кільцю FDDI, але в більш високошвидкісної мережі ця транзакція споживає лише 21% доступної смуги пропускання. Мережа може підтримувати п'ять або шість пересилань одночасно без серйозної деградації.

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

Мережа FDDI також небагато (приблизно на 5%) більш ефективна в порівнянні з Ethernet і Token Ring в середовищі з інтенсивною пересиланням даних, оскільки в її пакеті можна розмістити більший обсяг корисних даних (4500 байт в порівнянні з 1500 байт у Ethernet і 2048 байт у Token Ring). При пересиланнях даних об'ємом 8 Кбайт потрібно обробити всього два пакети в порівнянні з п'ятьма-шістьма для Token Ring або Ethernet. Але всі ці міркування мають сенс тільки для середовища з інтенсивною передачею даних, оскільки обсяг атрибутів при обробці відповідних запитів настільки малий (по 80-128 байт), що для їх передачі потрібна тільки один пакет незалежно від типу використовуваної мережі. Якщо існуюча на підприємстві проводка мережі заздалегідь виключає можливість застосування оптоволоконної середовища FDDI, то існують стандарти "FDDI по мідних проводах" (CDDI), які забезпечують можливість запобігання перевантаження мережі при збереженні існуючої розводки на основі витої пари.

Хоча ATM до цих пір не перетворилася в повсюдно застосовується технологію, можливо в майбутньому вона стане основним засобом для середовища з інтенсивною пересиланням даних, оскільки вона забезпечує більш високу швидкість передачі даних (в даний час визначені швидкості передачі даних 155 Мбіт / с, 622 Мбіт / с і 2.4 Гбіт / с), а також використовує топологію точка-точка, в якій кожне з'єднання клієнт-хаб може працювати зі своєю певною швидкістю середовища.

NFS і глобальні мережі

У реальному житті часто виникають ситуації, коли клієнти і сервери NFS можуть розташовуватися в різних мережах, об'єднаних маршрутизаторами. Топологія мережі може істотно відбитися на відчутною користувачем продуктивності сервера NFS і забезпечуваного їм сервісу. Ефективність забезпечення NFS-сервісу через комплексні мережі повинна ретельно аналізуватися. Але принаймні відомо, що можна успішно конфігурувати мережі та програми в глобальних (wide-area) топологіях NFS.

Можливо найбільш важливим питанням у цій ситуації є затримка виконання операцій: час, який проходить між видачею запиту й одержанням відповіді. Затримка виконання операцій в локальних мережах не така критична, оскільки пов'язані з такими мережами порівняно короткі відстані не можуть викликати значних затримок у середовищі передачі даних. У глобальних мережах затримки виконання операцій можуть відбуватися просто при транспортуванні пакетів з одного пункту в іншій. Затримка передачі пакетів складається з декількох складових:

Затримка маршрутизатора: маршрутизатори витрачають деякий кінцевий (і часто істотне) час на виконання власне маршрутизації пакетів з однієї мережі в іншу. Зауважимо, що під час формування більшості глобальних мереж (навіть при прокладці ліній між двома сусідніми будинками) використовуються принаймні два маршрутизатора. На малюнку 4.6 представлена ​​топологія типового університетського кампусу, в якому зазвичай між клієнтом і сервером встановлюються три або навіть чотири маршрутизатора. Затримка передачі по мережі: фізичне середовище, що використовується для передачі пакетів через глобальні мережі, часто може вносити свою власну істотну затримку, яка перевершує по величині затримку маршрутизаторів. Наприклад, організація супутникових мостів часто пов'язана з появою дуже великих затримок. Помилкові передачі: глобальні мережі можливо на порядок величини більш сприйнятливі до помилок передачі, ніж більшість локальних мереж. Ці помилки викликають значний обсяг повторних пересилань даних, що призводить як до збільшення затримки виконання операцій, так і до зниження ефективної пропускної здатності мережі. Для мереж, сильно схильних до помилок передачі, розмір блоку даних NFS часто встановлюється рівним 1 Кбайт, замість нормальних 8 Кбайт. Це дозволяє скоротити обсяг даних, які повинні повторно передаватися у разі появи помилки.

Якщо забезпечується прийнятний рівень безпомилкових передач даних, файловий сервіс по глобальних мережах цілком можливий. Найбільш часто в конфігурації таких мереж використовуються високошвидкісні синхронні послідовні лінії зв'язку точка-точка, які приєднуються до однієї або декількох локальних мереж на кожному кінці. У США такі послідовні лінії зв'язку звичайно мають швидкість передачі даних 1.544 Мбіт / с (лінія T1) або 56 Кбіт / с. Європейські комунікаційні компанії пропонують трохи більші швидкості: 2.048 Мбіт / с (лінія E1) або 64 Кбіт / с відповідно. Доступні навіть більш високошвидкісні лінії передачі даних. Ці орендовані лінії, відомі під назвою T3, забезпечують швидкість передачі до 45 Мбіт / с (5.3 Мбайт / с). На сьогодні більшість ліній T3 частково використовуються для передачі даних.

Рис. 4.6. Типова топологія мережі при організації зв'язку між будівлями

На перший погляд здається, що ці лінії значно повільніші у порівнянні з локальними мережами, до яких вони приєднуються. Однак у дійсності швидкі послідовні лінії (Т1) забезпечують пропускну здатність набагато ближчу до реальної пропускної здатності локальних мереж. Це відбувається тому, що послідовні лінії можуть використовуватися майже з 100% завантаженням без надмірних накладних витрат, у той час як мережі Ethernet зазвичай насичуються вже приблизно при 440 Кбайт / с (3.5 Мбіт / с), що всього приблизно вдвічі перевищує пропускну здатність лінії Т1 . З цієї причини файловий сервіс по високошвидкісним послідовним лініях зв'язку можливий і дозволяє передавати дані з прийнятними швидкостями. Зокрема, така організація виявляється корисною при передачі даних між віддаленими офісами. У додатках з інтенсивною обробкою атрибутів робота NFS з глобальних мереж може бути успішною, якщо затримка виконання операцій не є критичною. У глобальній мережі короткі пакети передаються через кожен сегмент досить швидко (при високій пропускної спроможності), хоча затримки маршрутизації і самого середовища часто викликають значну затримку виконання операцій.

Висновки:

Для реалізації глобальних сервісів NFS підходять послідовні лінії Т1, Е1 або Т3. Для більшості застосувань NFS лінії зі швидкостями передачі 56 і 64 Кбіт / с зазвичай виявляються недостатньо швидкими. При організації NFS через глобальні мережі існують проблеми із затримками мережі і маршрутизації. Пропускна здатність мережі зазвичай не викликає проблем. Для суттєвого скорочення трафіку по глобальній мережі, можна використовувати на клієнтських системах кешуючий файлову систему (CFS), якщо тільки в цьому трафіку не домінують операції запису NFS. Вибір типу мережі та кількості клієнтів

Враховуючи викладені вище міркування, для визначення належного типу і числа мереж можуть бути використані наступні емпіричні правила:

Якщо в додатку домінують операції з даними, слід вибрати мережу FDDI або яку-небудь іншу високошвидкісну мережу. Якщо з матеріально-технічних причин прокладка оптоволоконних кабелів не видається можливою, слід розглянути можливість реалізації FDDI на кручених парах. При створенні нової системи слід мати на увазі, що для мереж ATM використовуються ті ж самі кабелі, що і для FDDI. У конфігурації мережі необхідно передбачити одне кільце FDDI для кожних 5-7 клієнтів, одночасно повністю активних у сенсі NFS і інтенсивно працюють з даними. Слід пам'ятати, що дуже небагато інтенсивні за даними додатка безперервно генерують запити до сервера NFS. У типових інтенсивних за даними додатках автоматизації проектування електронних пристроїв і системах дослідження земних ресурсів це часто дозволяє мати до 25-40 клієнтів на кільце. У системах з інтенсивним використанням даних, де існуюча система кабелів змушує використовувати Ethernet, слід передбачити окрему мережу Ethernet для кожних двох активних клієнтів і максимально 4-6 клієнтів на одну мережу. Якщо програма пов'язана з інтенсивною обробкою атрибутів, то цілком достатньо побудови мереж Ethernet або Token Ring. У середовищі з інтенсивним використанням атрибутів слід мати одну мережу Ethernet на 8-10 повністю активних клієнтів. Нерозсудливо перевищувати рівень 20-25 клієнтів на Ethernet незалежно від вимог з-за різкої деградації, що виникає у разі активності багатьох клієнтів. В якості контрольної точки з точки зору здорового глузду можна вважати, що Ethernet здатний підтримувати 250-300 NFS-операцій в секунду на тесті SPECsfs_97 (LADDIS) навіть з високим рівнем колізій. Нерозумно перевищувати рівень 200 операцій NFS у секунду в усталеному режимі. Слід конфігурувати одну мережу TokenRing для кожних 10-15 повністю активних клієнтів у середовищі з інтенсивним використанням атрибутів. Якщо необхідно, до мережі Token Ring можна підключати 50-80 клієнтів завдяки чудовим характеристикам цього типу мережі по стійкості до деградації при важкій навантаженні (порівняно з Ethernet). Для систем, які забезпечують сервіс кількох класів користувачів мають сенс змішані конфігурації мереж. Наприклад, і FDDI, і Token Ring підходять для сервера, який підтримує як додатки, пов'язані з відображенням документів (інтенсивні за даними), так і групу ПК, виконують додаток фінансового аналізу (можливо інтенсивне за атрибутами). Споживання процесорних ресурсів

Оскільки багато комп'ютерів представляють собою універсальні системи, які допускають досить велике розширення кількості підключеним до них периферійних пристроїв, майже завжди існує можливість сконфігурувати систему так, що основним обмежуючим фактором стане процесор. У середовищі NFS потужність процесора витрачається безпосередньо для обробки протоколів IP, UDP, RPC і NFS, а також для управління пристроями (дисками та мережевими адаптерами) та маніпуляціями з файловою системою (грубо можна вважати, що споживання процесорного часу наростає пропорційно відповідно до зазначеного тут порядком).

Наприклад, компанія Sun рекомендує наступні емпіричні правила для конфігурування NFS-серверів:

Якщо у замовника переважає інтенсивна по атрибутах середовище та є менш 4-6 мереж Ethernet або Token Ring, то для роботи в якості NFS-сервера цілком достатньо однопроцесорній системи. Для систем меншого розміру з однією-двома мережами досить процесорної потужності машини початкового рівня SPARCserver 4. Для дуже великий інтенсивному за атрибутами середовища з багатьма мережами рекомендуються двопроцесорні системи подібні SPARCstation 20 Мodel 502 або двопроцесорні конфігурації SPARCserver 1000 або SPARCcenter 2000. Якщо середовище інтенсивна за даними, то рекомендується конфігурувати по два процесори SuperSPARC з SuperCashe на кожну високошвидкісну мережу (подібну FDDI). Якщо існуючі обмеження щодо організації кабельної проводки диктують використання в такому середовищі Ethernet, то рекомендується конфігурувати один процесор SuperSPARC на кожні 4 мережі Ethernet або Token Ring. Конфігурації дискової підсистеми і балансування навантаження

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

Організація послідовного доступу в NFS з інтенсивним використанням даних

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

Наприклад, свого часу диск ємністю 2.9 Гбайт був найшвидшим диском Sun для послідовних додатків. Він міг забезпечувати обмін даними через файлову систему зі швидкістю 4.25 Мбайт / с. Це був також наймісткіший диск Sun і тому опинявся найбільш зручним для зберігання великих обсягів даних. Висока швидкість обміну даними по відношенню до швидкості шини SCSI (пікова пропускна здатність шини становить 20 Мбайт / с) визначає оптимальну конфігурацію дискової підсистеми: 4-5 активних дисків ємністю 2.9 Гбайт на один головний адаптер (DWI / S). Якщо Вам потрібна додаткова ємність для зберігання даних, то підключення більшого числа дисків на кожен головний адаптер цілком припустимо, але це не дасть збільшення продуктивності дискової підсистеми.

Диски 2.9 Гбайт в системах Sun розміщуються на встановлюваних в стійку шасі (до 6 дискових накопичувачів на шасі). Кожне шасі може бути підключено до двох незалежних головними адаптерами SCSI. Така можливість дуже рекомендується для конфігурування серверів, що обслуговують клієнтів, виконують інтенсивні запити до даних. Щоб забезпечити максимальну ємність дискової пам'яті до 12 дисків можуть бути сконфігуровані на одному адаптері DWI / S. Проте максимальна продуктивність досягається тільки з 4-5 накопичувачами.

У середовищі з послідовним доступом досить просто підрахувати, скільки дисків буде потрібно для обслуговування пікового навантаження. Кожен повністю активний клієнт може зажадати від дискової підсистеми пропускної здатності до 2.7 Мбайт / с. (Тут передбачається використання високошвидкісних мереж зі швидкістю передачі в середовищі 100 Мбіт / с і вище). Гарне перше наближення дає забезпечення одного 2.9 Гбайт диска для кожних трьох повністю активних клієнтів. Пропонується саме таке співвідношення, хоча кожен диск може передавати дані зі швидкістю більше 4 Мбайт / с, а клієнти запитують тільки 2.7 Мбайт / с, оскільки робота двох активних клієнтів на одному диску буде викликати постійне переміщення каретки вперед і назад між групами циліндрів (або навіть файловими системами) і приводити до істотно більш низької пропускної здатності. Щоб збалансувати роботу дисків, а також прискорити деякі типи пересилань даних можна використовувати спеціальне програмне забезпечення типу Online: DiskSuit 2.0 (розд. 4.3.4.3). Якщо в якості мережного середовища застосовується Ethernet або 16 Мбіт Token Ring, то досить одного диска на кожного повністю активного користувача. Якщо використовується NFS +, це співвідношення сильно змінюється, оскільки NFS + забезпечує індивідуальну пропускну здатність у режимі клієнт / сервер приблизно на швидкості мережного середовища.

Організація довільного доступу в NFS з інтенсивними запитами атрибутів

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

Як наслідок, критерії вибору конфігурації для інтенсивної по атрибутах NFS істотно відрізняються від критеріїв для середовища з інтенсивним використанням даних. Оскільки в загальному часу, що потрібно для виконання операції довільного вводу / виводу домінує час позиціонування каретки диска, загальна пропускна здатність диска в цьому режимі виявляється набагато менше, ніж в режимі послідовного доступу. Наприклад, типовий дисковий накопичувач 1993 року випуску здатний працювати з швидкістю 3.5-4 Мбайт / с в послідовному режимі доступу, але забезпечує виконання тільки 60-72 операцій довільного доступу в секунду, що відповідає приблизно швидкості 500 Кбайт / с. За цих умов шина SCSI виявляється набагато менше зайнята, що дозволяє сконфігурувати на ній набагато більше дисків, перш ніж встане питання про перевантаження шини.

Крім того, одним із завдань вибору конфігурації системи є забезпечення найбільшого розумного числа дискових накопичувачів, оскільки саме воно визначає число дискових кареток, які представляють собою обмежуючий фактор в дискової підсистеми. На щастя, сама природа інтенсивних по атрибутах додатків передбачає, що вимоги до обсягу дискової пам'яті порівняно невеликі (по відношенню до інтенсивних за даними додатками). У цих умовах часто буває корисно включати в конфігурацію системи замість одного великого диска два або навіть чотири диски меншої місткості. Хоча така конфігурація обійдеться трохи дорожче в перерахунку на мегабайт пам'яті, її продуктивність істотно підвищиться. Наприклад, два диски ємністю 1.05 Гбайт коштують приблизно на 15% дорожче, ніж один диск ємністю 2.1 Гбайт, але вони забезпечують більш ніж у два рази більшу пропускну здатність довільного вводу / виводу. Приблизно теж саме ставлення залишається справедливим між дисками ємністю 535 Мбайт і диском 1.05 Гбайт (див. таблицю 4.2).

Таким чином, для інтенсивної по атрибутах середовища краще конфігурувати більше число невеликих дисків, під'єднаних до помірного числа головних адаптерів SCSI. Диск ємністю 1.05 Гбайт має прекрасне фірмове програмне забезпечення, яке зводить до мінімуму завантаження шини SCSI. Диск ємністю 535 Мбайт має схожі характеристики. Рекомендована конфігурація - це 4-5 повністю активних 535 Мбайт або 1 Гбайт дисків на одну шину SCSI, хоча 6 або 7 дисків також можуть працювати не викликаючи серйозних конфліктів на шині.

Таблиця 4.2. Характеристики деяких дискових накопичувачів

Ємність