Network File System (NFS) — протокол мережевого доступу до файлових систем, що був розроблений компанією Sun Microsystems у 1984 році. Заснований на протоколі виклику віддалених процедур (ONC RPC, Open Network Computing Remote Procedure Call). Дозволяє підключати (монтувати) віддалені файлові системи через мережу.
NFS надає клієнтам прозорий доступ до файлів і файлової системи сервера. На відміну від FTP, протокол NFS здійснює доступ тільки до тих частин файлу, до яких звернувся процес, і основна перевага його в тому, що він робить цей доступ прозорим. Це означає, що будь-який сервіс/програма клієнта, що може працювати з локальним файлом, із таким же успіхом зможе працювати і файлом, що доступний через NFS, без будь-яких модифікацій самої програми.
NFS-клієнти одержують доступ до файлів на NFS-сервері шляхом відправлення RPC-запитів на сервер.(c) Wikipedia
Процес монтування каталогу віддаленого NFS-серверу можна розбити на такі кроки:
1. На сервері та клієнті на 111 порту udp та tcp запускається RPC-сервер (представлений як rpcbind). Він завантажується разом із запуском NFS-демону.
2. Запускаються служби rpc.statd, rpc.idmapd, rpc.statd і тд., що реєструються на довільних мережевих портах.
3. Команда mount на клієнті створює запит (із вказанням ip/доменнейму, каталогу) на монтування каталогу до ядра ОС. На що ядро формує і відсилає запит на віддалений RPC-сервер, на сервер, де власне локально зберігається необхідний каталог.
4. Ядро NFS-серверу через rpcbind перевіряє наявність процеса rpc.mountd і повертає номер порту, на якому він працює (знову, використовуючи RPC-протокол), ядру клієнта, що надав запит на монтування.
5. Отримавши номер порту, mount відправляє RPC-запит на отриманий порт серверу. Надалі сервер перевіряє дозволи і надає відповідні права на запитану директорію.
6. Демон монтування rpc.mountd на NFS-сервері повертає опис запитаної директорії і на основі цих данних проходить монтування директорії. Надалі в дереві директорій вона буде представлена як звичайна директорія.
Доступ до файлу в директорії, що примонтована як NFS, відбувається через модуль ядра nfsd/nfs, котрий вже потім надсилає запит на віддалений RPC-сервер (зазвичай на порт 2049, що відповідає за роботу з NFS). Тобто для клієнтських програм, що запитують файл на віддаленому розділі не важливо, що це не локальний файл, адже всі додаткові операції виконує ядро ОС та модуль ядра nfsd/nfs.
Щоб дізнатись на яких портах працюють RPC-програми, можна виконати таку команду:
# rpcinfo -p
program vers proto port service
100000 4 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 54107 status
100024 1 tcp 56055 status
100003 2 tcp 2049 nfs
100003 4 tcp 2049 nfs
100227 2 tcp 2049
100003 2 udp 2049 nfs
100003 4 udp 2049 nfs
100227 2 udp 2049
100021 1 udp 39802 nlockmgr
100021 4 udp 39802 nlockmgr
100021 1 tcp 32786 nlockmgr
100021 4 tcp 32786 nlockmgr
100005 1 udp 49768 mountd
100005 2 udp 43705 mountd
100005 2 tcp 54465 mountd
100005 3 tcp 35113 mountd
Для того, щоб практично показати як налаштовується NFS-сервер/клієнт я використав такі IP-адреси:
192.168.1.25 - NFS-сервер (Ubuntu 13.04)
192.168.1.30 - NFS-клієнт (CentOS 6.4)
Спершу встановлюємо пакети підтримки серверу і клієнта. OS Ubuntu буде виступати в ролі NFS-серверу:
# apt-get install nfs-kernel-server nfs-common portmap
А Centos - в ролі NFS-клієнта:
# yum install nfs-utils nfs-utils-lib
Для Debian/Ubuntu пакет для роботи клієнта має назву nfs-common.
Додаємо сервіс в автозавантаження:
# chkconfig nfs on
Запускаємо сервіси rpcbind та nfs:
# service rpcbind start
Starting rpcbind: [ OK ]
# service nfs start
Starting NFS services: [ OK ]
Starting NFS mountd: [ OK ]
Starting NFS daemon: [ OK ]
У Ubuntu сервіси мають запуститись автоматично, якщо ж ні - виконайте:
# /etc/init.d/nfs-kernel-server start
* Exporting directories for NFS kernel daemon... [ OK ]
* Starting NFS kernel daemon [ OK ]
Для початку вирішимо якими саме директоріями будемо ділитись із NFS-клієнтом. Нехай це будуть:
/home/ipeacocks/Downloads/
/media/other/music/
/media/other/programs/
Відповідно налаштовуємо сервер, зазначивши директорії, що будуть експортуватись:
# vim /etc/exports
/home/ipeacocks/Downloads/ 192.168.1.30(rw,sync,no_root_squash,no_subtree_check)
/media/other/music/ *(ro,async,no_subtree_check)
/media/other/programs/ 192.168.1.1/24(rw,sync,no_root_squash,no_subtree_check)
Отже, доступ до директорії Downloads надано лише хосту з IP 192.168.1.30 та правами read/write, доступ до директорії music з правами read only(ro) надано всім хостам, а до programs - всім хостам підмережі.
Між айпі хосту і опціями не має бути жодного пробіла, інакше запис буде інакше трактуватись.
Опції, що були використані при експортуванні:
rw/ro - доступ на запис/читання та лиш на читання відповідно.
sync/async - сервер буде давати відповіді на запити, лиш після запису данних на диск. Опція async указує не чекати запису на диск, а одразу відповідати на них. async підвищує продуктивність серверу, проте, зрозуміло, що знижує надійність.
no_root_squash - дозволяє користувачу root NFS-клієнту писати в примонтовані директорії. Інакше лише користувач із аналогічним (як і на сервері) UID/GID зможе писати у директорію.
subtree_check/no_subtree_check - якщо монтується тільки частина логічного тому, то сервер буде виконувати перевірку приналежності файлу запитаного клієнтом, саме до тієї частини тому, який примонтований. Відключення перевірки зменшує безпеку, але збільшує швидкість передачі даних.
Після налаштування директорій, що будуть експортуватись, необхідно перезапустити сервіс:
# /etc/init.d/nfs-kernel-server restart
А надалі можна просто перечитувати файл /etc/exports:
# sudo exportfs -a -v
exporting 192.168.1.1/24:/media/other/programs
exporting 192.168.1.30:/home/ipeacocks/Downloads
exporting *:/media/other/music
Переглянути папки котрі розшарені на сервері можна за допомогою команди exportfs:
# exportfs
/home/ipeacocks/Downloads
192.168.1.30
/media/other/programs
192.168.1.1/24
/media/other/music
<world>
Конфігуруємо клієнта 192.168.1.30, що працює під Centos 6.4.
Можна примонтувати віддалену файлову систему за допомогою команди mount (звичайно, що всі директорії, в котрі будуть відбуватись монтування, мають існувати):
# mount -v -t nfs 192.168.1.25:/home/ipeacocks/Downloads/ /mnt/Downloads
mount.nfs: timeout set for Wed Jul 24 14:47:13 2013
mount.nfs: trying text-based options 'vers=4,addr=192.168.1.25,clientaddr=192.168.1.30'
192.168.1.25:/home/ipeacocks/Downloads/ on /mnt/Downloads type nfs (rw)
Але після перезавантаження необхідно буде знову її монтувати. Тож ліпше за все описати nfs-розділи в /etc/fstab:
# vim /etc/fstab
192.168.1.25:/home/ipeacocks/Downloads/ /mnt/Downloads nfs defaults,intr 0 0
192.168.1.25:/media/other/programs/ /mnt/programs nfs defaults,intr 0 0
192.168.1.25:/media/other/music/ /mnt/music nfs defaults,noatime,udp 0 0
Звісно, що defaults - це купа стандартних опцій, котрі можна переглянути, наприклад, за допомогою nfsstat:
# nfsstat -m
/mnt/Downloads from 192.168.1.25:/home/ipeacocks/Downloads
Flags: rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.30,minorversion=0,local_lock=none,addr=192.168.1.25
/mnt/programs from 192.168.1.25:/media/other/programs
Flags: rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.30,minorversion=0,local_lock=none,addr=192.168.1.25
/mnt/music from 192.168.1.25:/media/other/music
Flags: rw,noatime,vers=4,rsize=32768,wsize=32768,namlen=255,hard,proto=udp,port=0,timeo=11,retrans=3,sec=sys,clientaddr=192.168.1.30,minorversion=0,local_lock=none,addr=192.168.1.25
Дещо про опції монтування:
rw - read/write. Можна обмежити на запис директорію зі сторони клієнта.
noatime - опція відключення оновлення дати останнього доступу до файлу.
relatime - оновлює дату останнього доступу лиш у випадку, якщо дата модифікації (mtime) більша за дату останнього доступу (atime). Тобто оновлює дату останнього доступу у випадку зміни атрибутів чи зміни вмісту файла.
vers - версія протоколу nfs
hard/soft - у випадку з опцією hard, програма що звернулась до nfs-розділу у разі його недоступності буде чекати і висіти в процесах до того часу поки nfs-сервер знову не стане доступний. У випадку з soft - буде просто згенерована помилка після певного часу відсутності серверу.
proto=udp/tcp - протокол через який працюватиме NFS
rsize/wsize - читання/запис блоками указаної величини.
Про інші опції можна почитати тут.
Немає коментарів:
Дописати коментар