NFS - файлова система в мережі

Малобюджетні сайти.

Просування веб-сайту.

NFS - файлова система в мережі

Нещодавно ми обговорювали використання розподілених файлових систем на основі протоколу SMB. Після півдюжини маніпуляцій SMB дає вам доступ до розподілених ресурсів Windows-машини. Доступ до загальних ресурсів UNIX-машини набагато простіше! FreeBSD підтримує стандартну UNIX'ову Network File System (мережева файлова система) прямо «з коробки», тобто. практично без додаткових маніпуляцій (уже GENERIC-ядро вам точно не доведеться перекомпілювати – прим. перекладача). NFS лякає багатьох новачків у справі системного адміністрування, проте насправді вона дуже проста в експлуатації, за умови, що ви знаєте що робите (все як завжди – прим. перекладача).

Будь-яке NFS-з'єднання працює за клієнт-серверною схемою. Один комп'ютер є сервером і надає файлові системи іншим машинам. Це називається «NFS-експортування», а файлові системи, що надаються, називають «експортами». Клієнти можуть монтувати експорти сервера майже так само, як і локальні файлові системи.

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

У цій статті ми обговоримо створення з'єднань від будь-яких FreeBSD-клієнтів до сервера на основі FreeBSD 4-STABLE. Різні реалізації NFS трохи відрізняються один від одного. Ви виявите невеликі відмінності вреалізації NFS для Solaris, Linux та будь-якої іншої UNIX системи. NFS буде працювати на всіх цих системах, проте вам може знадобитися деяке доведення налаштувань для роботи в гетерогенній мережі (тобто мережі з різними операційними системами – прим. перекладача). Якщо ви зіткнетеся з труднощами при реалізації NFS-з'єднання між різними реалізаціями NFS, зверніться до архіву списку розсилки freebsd-net, там майже напевно є опис вирішення вашої проблеми.

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

Отже, займемося для початку серверною стороною. Ви можете дозволити підтримку NFS, додавши до файлу /etc/rc.conf наступні рядки:

Portmap надає, як можна здогадатися, функції відображення для мережевих портів. Різним експортам та клієнтам потрібні унікальні мережеві порти. Клієнт запитує portmap номер порту, до якого слід підключатися для проведення поточного монтування файлової системи. Опція nfs_server_enable запускає демонів nfsd та mountd. Mountd просто чекає вхідних NFS-запитів на певних портах з великими номерами, а також робить ці порти доступними для portmap. Коли клієнт спілкується з mountd та portmap, насправді його запити обслуговує демон nfsd.

Після перезавантаження сервер повинен показувати щось подібне у відповідь на команду sockstat. Це говорить про те, що ваш серверпрацює більш-менш нормально. Якщо ви не бачите такого повідомлення, подивіться файл журналу /var/log/massages для виявлення причин збою.

Тепер, коли ваші системи повністю підготовлені для використання NFS, нам необхідно вказати серверу, які каталоги він може експортувати. Ми можемо експортувати весь вміст сервера, але зазвичай це нерозумно. Клієнти повинні мати мінімальну або взагалі не мати потреби у віддаленому монтуванні кореневої директорії сервера. Каталоги дозволені на експорт вказуються у файлі /etc/exports. Кожен рядок у цьому файлі відповідає фізичному дисковому розділу. Рядок конфігурації може містити до трьох параметрів:

  • Експортований каталог
  • Параметри експортування
  • Клієнти, які можуть підключатися

Кожна комбінація клієнтів та дискових розділів сервера може мати лише один рядок у файлі /etc/exports. Це означає, що якщо /usr/ports і /usr/home знаходяться на одному фізичному розділі, то їх експорт повинен бути описаний в одному рядку для всіх клієнтів (на жаль, з чим пов'язане таке обмеження абсолютно незрозуміло – прим. перекладача). Вам необов'язково експортувати весь розділ, ви можете зробити доступним один каталог у межах розділу. Цей каталог має бути заданий повним шляхом і не містити посилань (симлінків) та символів «точка» («.») та «дві точки» («..»). Якщо я захочу надати доступ до мого домашнього каталогу будь-якому вузлу в Інтернеті, то у файлі /etc/exports я повинен написати наступний рядок:

Ми не вказали ні параметрів, ні обмежень на доступ. Для того щоб зміни набули чинності нам необхідно змусити mountd перечитати /etc/exports:

Ця інформація вказала мені на місце виникнення проблеми. Усунення проблем – мояробота.

На стороні клієнта створив каталог $HOME/serverhome. Я хотів, щоб NFS-mount монтувала мій домашній каталог на сервері в цей каталог на клієнті. Це виглядає практично як і використання звичайної команди mount. Mount використовує два аргументи – фізичний пристрій та точку монтування. В даному випадку в ролі фізичного пристрою виступає віддалений сервер та файлова система, що експортується:

Після виконання команди монтування подивіться, що вийшло за допомогою команди df:

Переглянувши вміст каталогу $HOME/serverhome, ми побачимо, що більшістю файлів володіє користувач mwlucas, і лише деякими – користувач root. На мій погляд тут не повинно бути. Я зробив кілька png-скриншотів термінального вікна для моєї книги, якими володіє користувач root. Раз їх не повинно бути тут, я їх видалю:

Але ж я root! Чому я не можу видалити цей файл?

Я root на клієнта, але не на сервері. Сервер не довіряє користувачам root, зареєстрованим на інших машинах, виконувати команди від користувача root на сервері. NFS має спеціальний параметр підтримки користувача root, за допомогою якого ви можете виконувати запити клієнтського користувача root від імені будь-якого користувача сервера. Наприклад, ви можете вказати, що всі запити від користувача root на клієнті будуть виконуватися на сервері від імені користувача nfsroot. Правильно використовуючи групи, ви можете дати цьому користувачеві певний обмежений доступ до даних на сервері. Використовуйте -maproot для виконання запитів root'а від імені іншого користувача.

Так як це моя домашня мережа і крім мене в ній немає користувачів, я можу повністю довіряти клієнтові. У даному випадку я зрівняю клієнтського користувача root із серверним, задавшиідентифікатор 0 (u >Я знову перезапущу mountd. Так як у NFS відсутня прив'язка до поточного стану, раніше змонтовані каталоги не треба перемонтувати заново - зміни відіб'ються на них автоматично. У цей час я на клієнті залишався в тому ж каталозі; перезапуск mountd взагалі не торкнувся клієнтської сторони, і команда rm тепер працює бездоганно.

А якщо я захочу експортувати ще один каталог на тому ж фізичному розділі? Наприклад, припустимо, що я хочу експортувати каталог /usr/src для мого ноутбука для того, щоб зберегти місце на його невеликому вінчестері. Список інших каталогів вказується в / etc / exports через пробіли. Заодно я експортую каталог /usr/obj. У такий спосіб я можу запускати make buildworld на швидкій серверній машині, а на слабкому ноутбуці писати тільки make installworld, що різко прискорить оновлення системи. Тепер мій /etc/exports виглядає так:

Між компонентами рядка немає жодних розділових ідентифікаторів. Було б набагато простіше, якби кожному каталогу відповідав один рядок у файлі, але так зробити не можна, тому що всі каталоги належать до одного фізичного розділу. Команда розробників FreeBSD легко могла б усунути цю незручність, але наші /etc/exports стали б несумісні з реалізаціями NFS в інших UNIX системах. Перезапустіть mountd та змонтуйте ці файлові системи на клієнті:

Тепер список файлових систем на моєму клієнті виглядає так:

Команда make buildworld виконується на моєму ноутбуці дві години, на сервері вона займає лише 30 хвилин. Раніше мені доводилося виконувати make buildworld і make buildkernel на сервері, і якщо я хотів таке саме ядро, то я просто входив до /usr/src і писав make installkernel && make installworld&& mergemaster, і FreeBSD, зібрана на моєму сервері, встановлювалася на ноутбук.

Незабаром ще є привід для оновлення списку експортів – було б непогано збирати FreeBSD-порти на сервері, а встановлювати на клієнті, експортуючи /usr/ports. Це починає трохи забавним, але врешті-решт ви виявите, що майже всі каталоги, що знаходяться в /usr виявляться у файлі /etc/exports. Можна було б покінчити з цим експортувавши каталог /usr повністю. Це не так добре, як здається, тому що я хочу монтувати експортовані каталоги в різні місця, оскільки якщо експортований /usr/ports цілком може перекрити той самий каталог на клієнтській машині, то перекриття домашніх каталогів користувачів (/usr/home) неприпустимо. На щастя існує просте рішення: параметр -alldirs дозволяє експортувати каталог і всі його підкаталоги. Ви повинні вказувати розділ диска, коли ви використовуєте alldirs. Параметри розділяються комою:

Тепер я знову перезапустити mountd. Весь вміст /usr тепер можна монтувати окремо. Наприклад, я залишив /usr/obj і /usr/src змонтованими. Швидке тестування за допомогою df та ls показало, що вони залишилися на своїх місцях і файли в них, як і раніше, доступні, незважаючи на повну зміну способу їх експортування. Я можу монтувати будь-які каталоги із серверного /usr.

І нарешті поговоримо про продуктивність. За умовчанням, NFS використовує «безпечні» параметри монтування, які відмінно підходять для взаємодії з іншими реалізаціями NFS на інших UNIX. У цьому випадку всі машини «розмовляють» використовуючи обмежений набір команд, що більш-менш однаково розуміються. Ви можете змінити деякі параметри, збільшивши продуктивність, зменшуючи, однак, сумісність з іншими реалізаціями.Якщо ваша мережа налічує два-три NFS-клієнти, то швидше за все зміна цих параметрів вам не знадобиться, проте якщо ваша мережа зростатиме, вони можуть вам допомогти. Отже слід мати на увазі, що вони можуть працювати чи не працювати на різних системах – все залежить від підтримки їх операційною системою.

По-перше, NFS за замовчуванням використовує протокол UDP. Параметр tcp вказує на те, що для монтування необхідно використовувати протокол TCP.

Тепер зробимо монтовані каталоги «перериваються». Це означає, що при відключенні сервера з якоїсь причини, клієнтська програма, яка намагається отримати доступ до недоступного в даний момент експорту, може бути перервана. Якщо не вказати цей параметр, то клієнтська програма продовжуватиме намагатися отримати доступ до експорту, доки не закінчиться тайм файлової системи (тобто програма на час «глухо» зависне – прим. перекладача). «Припинення» встановлюється параметром intr.

NFS існує у кількох версіях. Остання та найпоширеніша на даний момент версія 3. Ви можете зажадати використання клієнтами третьої версії за допомогою параметра nfsv3.

Нарешті, можна змінити розмір блоків даних, якими обмінюються клієнт і сервер. За замовчуванням він занадто малий. Такий розмір добре підходив для мереж на початку 90-х років. Ви можете встановити більш сучасні значення для пакетів читання та запису, використовуючи параметри -r і -w. 32768 – гарне значення для обох.

Отже зібравши всі разом я монтуватиму мої експорти наступним способом:

Таким чином я отримав максимальну продуктивність у мінімальних витратах. Подальше тонке налаштування NFS вимагатиме від вас тестування різних параметрів на вашому конкретному мережевому обладнанні.

Тепер, коли я використовую NFS вдома, я став помічати, що монтую каталоги однієї машини на інший за найменшої потреби. Це варто того.