Протоколът за мрежов файлов сървър (NFS) е отворен стандартда предостави на потребителя отдалечен достъпкъм файлови системи. Централизираните файлови системи, изградени върху него, улесняват ежедневните задачи като архивиране или сканиране за вируси, а консолидираните дискови дялове са по-лесни за поддръжка от много по-малки, разпределени.
В допълнение към предоставянето на централизирано съхранение, NFS се оказа много полезен за други приложения, включително бездискови и тънки клиенти, мрежови клъстери и сътрудничество в междинния софтуер.
По-доброто разбиране както на самия протокол, така и на детайлите на неговото прилагане ще улесни справянето с практически проблеми. Тази статия е посветена на NFS и се състои от две логически части: първо описва самия протокол и целите, поставени по време на неговото разработване, а след това прилагането на NFS в Solaris и UNIX.
КЪДЕ ЗАПОЧНА ВСИЧКО...
Протоколът NFS е разработен от Sun Microsystems и се появява в Интернет през 1989 г. като RFC 1094 под следното заглавие: Спецификация на протокола за мрежова файлова система (NFS). Интересно е да се отбележи, че стратегията на Novell по това време беше насочена към по-нататъшно подобряване на файловите услуги. Доскоро, преди движението за отворен код да тръгне, Sun не желаеше да споделя тайните на своите мрежови решения, но дори тогава компанията разбираше важността на оперативната съвместимост с други системи.
RFC 1094 съдържа две оригинални спецификации. Към момента на публикуването си Sun вече разработваше следващата, трета версия на спецификацията, която е изложена в RFC 1813 „NFS Version 3 Protocol Specification“. Версия 4 от този протоколдефиниран в RFC 3010, NFS версия 4 протокол.
NFS се използва широко във всички видове UNIX хостове, в мрежи на Microsoft и Novell и в решения на IBM като AS400 и OS/390. Въпреки че е непознат извън мрежовото царство, NFS е може би най-разпространената независима от платформата мрежова файлова система.
UNIX БЕШЕ ГЕНЕЗИСЪТ
Въпреки че NFS е независима от платформата система, нейният предшественик е UNIX. С други думи, йерархичната архитектура на архитектурата и методите за достъп до файлове, включително структура на файловата система, начини за идентифициране на потребители и групи и техники за обработка на файлове, са много подобни на файловата система UNIX. Например файловата система NFS, тъй като е структурно идентична на файловата система UNIX, се монтира директно върху нея. Когато работите с NFS на др операционна системаах, параметрите за идентификация на потребителя и правата за достъп до файлове подлежат на картографиране.
NFS
NFS системата е предназначена за използване в клиент-сървър архитектура. Клиентът осъществява достъп до файловата система, експортирана от NFS сървъра, през точка на монтиране на клиента. Този достъп обикновено е прозрачен за клиентското приложение.
За разлика от много системи клиент-сървър, NFS използва Remote Procedure Calls (RPC) за обмен на информация. Обикновено клиентът установява връзка към предварително известен порт и след това, в съответствие с протокола, изпраща заявка за извършване на конкретно действие. В случай на извикване на отдалечена процедура, клиентът създава извикване на процедура и след това го изпраща на сървъра за изпълнение. Подробно описание на NFS ще бъде представено по-долу.
Като пример, да предположим, че клиент е монтирал директорията usr2 в локалната основна файлова система:
/root/usr2/ -> дистанционно:/root/usr/
Ако клиентско приложение се нуждае от ресурси от тази директория, то просто изпраща заявка до операционната система за него и името на файла, което дава достъп през NFS клиента. Като пример, разгледайте простата UNIX команда cd, която „не знае нищо“ за мрежовите протоколи. Екип
CD /root/usr2/
ще постави работната директория на отдалечена файлова система, „без дори да осъзнава“ (потребителят също няма нужда от това), че файловата система е отдалечена.
След като получи заявката, NFS сървърът ще провери дали потребителят има право да извърши исканото действие и, ако отговорът е положителен, ще го извърши.
НЕКА СЕ ОПОЗНАЕМ ПО-ДОБРЕ
От гледна точка на клиента процесът на локално монтиране на отдалечена файлова система чрез NFS се състои от няколко стъпки. Както споменахме, NFS клиентът ще издаде извикване на отдалечена процедура за изпълнение на сървъра. Имайте предвид, че в UNIX клиентът е една програма (команда за монтиране), докато сървърът всъщност е реализиран като няколко програми със следния минимален набор: услуга за картографиране на портове, демон за монтиране и NFS сървър.
Командата за монтиране на клиента първо комуникира с услугата за превод на портове на сървъра, която слуша за заявки на порт 111. Повечето реализации на командата за монтиране на клиента поддържат множество версии на NFS, което увеличава вероятността за намиране на обща версия на протокола за клиента и сървъра. Търсенето се извършва, като се започне с най-високата версия, така че когато се намери обща, тя автоматично ще стане най-новата версия, поддържана от клиента и сървъра.
(Представеният материал е фокусиран върху третата версия на NFS, тъй като тя е най-разпространената в момента. Четвъртата версия все още не се поддържа от повечето реализации.)
Услугата за превод на портове на сървъра отговаря на заявки въз основа на поддържания протокол и порта, на който работи демонът за монтиране. Клиентската програма за монтиране първо установява връзка с демона за монтиране на сървъра и след това издава командата за монтиране към него чрез RPC. Ако тази процедура е успешна, тогава клиентското приложение се свързва към NFS сървъра (порт 2049) и с помощта на една от 20-те отдалечени процедури, които са дефинирани в RFC 1813 и изброени в таблица 1, получава достъп до отдалечената файлова система.
Значението на повечето команди е интуитивно и не създава затруднения на системните администратори. Следният списък, получен с помощта на tcdump, илюстрира командата за четене, генерирана от командата cat на UNIX за четене на файл с име test-file:
10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 търсене fh 32.0/ 224145 "тестов файл" 10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 търсене fh 32.0/ 224145 "тестов файл" 10:30:16.012729 eth0 192.168.1.254.3476097947: отговор добре 128 търсене fh 32.0/2 24 307 (DF) 10:30: 16.012729 eth0 192.168 .1.254.3476097947: отговор добре 128 търсене fh 32.0/224307 (DF) 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 четене fh 32.0/ 224307 4096 байта @ 0 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 четене fh 32.0/ 224307 4096 байта @ 0 10:30:16.013650 eth0 192.168.1.254.3492875163: отговор добре 108 четене (DF 10:3 ) 0:16.013650 eth0 192.168.1.254.3492875163 : отговор добре 108 прочетено (DF)
NFS традиционно се внедрява върху UDP. Някои версии на NFS обаче поддържат TCP (TCP поддръжката е дефинирана в спецификацията на протокола). Основното предимство на TCP е по-ефективен механизъм за препредаване в ненадеждни мрежи. (В случай на UDP, ако възникне грешка, тогава пълно съобщение RPC, състоящ се от множество UDP пакети, се изпраща повторно. Ако TCP е наличен, само повреденият фрагмент се предава повторно.)
NFS ДОСТЪП
Реализациите на NFS обикновено поддържат четири начина за предоставяне на права за достъп: чрез потребителски/файлови атрибути, на ниво споделен ресурс, на ниво главен възел и като комбинация от други методи за достъп.
Първият метод се основава на вградената в UNIX файлова система за разрешения за индивидуален потребителили групи. За да се опрости поддръжката, идентификацията на потребителите и групите трябва да е последователна във всички NFS клиенти и сървъри. Сигурността трябва да се обмисли внимателно: NFS може по невнимание да предостави достъп до файлове, които не са били предназначени, когато са били създадени.
Достъпът на ниво споделени ресурси ви позволява да ограничите правата, като разрешите само определени действия, независимо от собствеността върху файла или UNIX привилегиите. Например работата с файловата система NFS може да бъде ограничена само до четене. Повечето реализации на NFS ви позволяват допълнително да ограничите достъпа на ниво споделен ресурс до конкретни потребители и/или групи. Например на групата Човешки ресурси е позволено да преглежда информация и нищо повече.
Достъпът на ниво главен възел ви позволява да монтирате файлова система само на определени възли, което като цяло е добра идея, тъй като файловите системи могат лесно да бъдат създадени на всякакви възли с NFS.
Комбинираният достъп просто комбинира горните типове (например достъп на споделено ниво с достъп, предоставен на конкретен потребител) или позволява на потребителите да имат достъп до NFS само от конкретен възел.
NFS В СТИЛ НА ПИНГВИН
Представеният материал, свързан с Linux, е базиран на системата червена шапка 6.2 с ядро версия 2.4.9, което се доставя с пакет nfs-utils версия 0.1.6. Има и по-нови версии: към момента на писане най-новата актуализация на пакета nfs-utils е 0.3.1. Може да бъде изтеглен от: .
Пакетът nfs-utils съдържа следните изпълними файлове: exportfs, lockd, mountd, nfsd, nfsstat, nhfsstone, rquotad, showmount и statd.
За съжаление, понякога поддръжката на NFS предизвиква объркване сред Linux администратори, тъй като наличността на определена функционалност директно зависи от номерата на версията както на ядрото, така и на пакета nfs-utils. За щастие нещата се подобряват в тази област, като най-новите дистрибуции включват най-новите версии и на двете. За предишни издания, раздел 2.4 на NFS-HOWTO предоставя пълен списък на функционалността на системата, налична за всяка комбинация от пакети на ядро и nfs-utils. Разработчиците поддържат обратна съвместимост на пакета с по-ранни версии, като обръщат много внимание на осигуряването на сигурност и премахване на софтуерни грешки.
Поддръжката на NFS трябва да бъде инициирана по време на компилация на ядрото. Ако е необходимо, възможността за работа с NFS версия 3 трябва да се добави към ядрото.
За дистрибуции, които поддържат linuxconf, е лесно да конфигурирате NFS услуги както за клиенти, така и за сървъри. Въпреки това, бърз начин NFS инсталацииизползването на linuxconf не предоставя информация за това кои файлове са създадени или редактирани, което е много важно за администратора да знае, за да разбере ситуацията в случай на повреда на системата. Архитектурата на NFS на Linux е слабо свързана с версията на BSD, така че необходимите файлове за поддръжка и програми са лесни за намиране за администратори, работещи с BSD, Sun OS 2.5 или по-ранни версии на NFS.
Файлът /etc/exports, както и в по-ранните версии на BSD, дефинира файловите системи, до които NFS клиентите имат достъп. Освен това съдържа номер допълнителни функциисвързани с проблемите на управлението и сигурността, предоставяйки на администратора средства за фина настройка. Това текстов файл, състоящ се от записи, празни редове или коментирани редове (коментарите започват със символ #).
Да кажем, че искаме да дадем на клиентите достъп само за четене до директорията /home на възела Lefty. Това в /etc/exports ще съответства следващ запис:
/начало (ro)
Тук трябва да кажем на системата кои директории ще направим достъпни с помощта на демона за монтиране rpc.mountd:
# exportfs -r exportfs: Няма посочено име на хост в /home (ro), въведете *(ro), за да избегнете предупреждението #
Когато се изпълни, командата exportfs издава предупреждение, че /etc/exports не ограничава достъпа до конкретен възел и създава съответен запис в /var/lib/nfs/etab от /etc/exports, указващ кои ресурси могат да се разглеждат с помощта на cat :
# cat /var/lib/nfs/etab /home (ro,async,wdelay,hide,secure,root_squash, no_all_squash,subtree_check, secure_locks, mapping=identity,anonuid= -2,anongid=-2)
Други опции, изброени в etab, включват стойностите по подразбиране, използвани от NFS. Подробностите ще бъдат описани по-долу. За да предоставите достъп до директорията /home, трябва да стартирате съответните NFS услуги:
# portmap # rpc.mountd # rpc.nfsd # rpc.statd # rpc.rquotad
По всяко време след стартиране на демона за монтиране (rpc.mountd), можете да видите отделните файлове, налични за извеждане, като прегледате съдържанието на файла /proc/fs/nfs/exports:
# cat /proc/fs/nfs/exports # Версия 1.0 # Клиентски път (Флагове) # IP адреси /home 192.168.1.252(ro,root_squash,async, wdelay) # 192.168.1.252 #
Същото може да се види с помощта на командата showmount с параметъра -e:
# showmount -e Експортиране на списък за lefty: /home (всички) #
Прескачайки малко напред, командата showmount може също да се използва за определяне на всички монтирани файлови системи или с други думи, за да разберете кои възли са NFS клиенти за системата, изпълняваща командата showmount. Командата showmount -a ще изброи всички точки на монтиране на клиента:
# showmount -a Всички точки на монтиране вляво: 192.168.1.252:/home #
Както беше посочено по-горе, повечето реализации на NFS поддържат различни версии на този протокол. Изпълнението на Linux ви позволява да ограничите списъка с версии на NFS, които могат да бъдат стартирани, като посочите ключа -N за демона за монтиране. Например, за да стартирате NFS версия 3 и само версия 3, въведете следната команда:
# rpc.mountd -N 1 -N 2
Редовните потребители може да сметнат за неудобно, че NFS демонът на Linux (rpc.nfsd) чака пакети версия 1 и версия 2, въпреки че това има желания ефект да не поддържа съответния протокол. Да се надяваме, че разработчиците следващи версиище направи необходимите корекции и ще може да постигне по-голяма последователност между компонентите на пакета по отношение на различни версиипротокол.
"ПЛУВАЙТЕ С ПИНГВИНИ"
Достъпът до конфигурираната по-горе Lefty, базирана на Linux NFS експортируема файлова система, зависи от операционната система на клиента. Стил на инсталиране за повечето операционни системи UNIX семействоотговаря на стила или на оригиналната Sun OS и BSD системи, или на по-новата Solaris. Тъй като тази статия е както за Linux, така и за Solaris, нека да разгледаме клиентската конфигурация на Solaris 2.6 от гледна точка на установяване на връзка с Linux версията на NFS, която описахме по-горе.
Благодарение на функциите, наследени от Solaris 2.6, той може лесно да бъде конфигуриран да действа като NFS клиент. Това изисква само една команда:
# монтиране -F nfs 192.168.1.254:/home /tmp/tmp2
Ако приемем, че предишната команда за монтиране е била успешна, тогава командата за монтиране без параметри ще изведе следното:
# монтиране / на /dev/dsk/c0t0d0s0 read/write/setuid/ largefiles на Mon Sep 3 10:17:56 2001 ... ... /tmp/tmp2 на 192.168.1.254:/home read/ write/remote на понеделник, 3 септември 23:19:25 2001 г
Нека анализираме изхода tcpdump, получен на възела Lefty, след като потребителят издаде командата ls /tmp/tmp2 на възела Sunny:
# tcpdump хост lefty и хост sunny -s512 06:07:43.490583 sunny.2191983953 > lefty.mcwrite.n.nfs: 128 getattr fh Unknown/1 (DF) 06:07:43.490678 lefty.mcwrite.n.nfs > sunny. 2191983953: отговор добре 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:07:43.491397 sunny.2191983954 > lefty.mcwrite.n.nfs: 132 достъп fh Неизвестно/10001 (DF) 43.4914 63 mcwrite.n. nfs > sunny.2191983954: отговор добре 120 достъп c0001 (DF) 06:07:43.492296 sunny.2191983955 > lefty.mcwrite.n.nfs: 152 readdirplus fh 0.1/16777984 1048 байта @ 0x0000 00000 (DF) 06:07:43.492417 lefty.mcwrite.n.nfs > sunny.2191983955: отговор добре 1000 readdirplus (DF)
Виждаме, че възел Sunny изисква файлов манипулатор (fh) за ls, на който възел Lefty отговаря с OK и връща структурата на директорията. След това Sunny проверява разрешението за достъп до съдържанието на директорията (132 достъп fh) и получава отговор за разрешение от Lefty. След това възелът Sunny чете цялото съдържание на директорията с помощта на рутината readdirplus. Извикванията на отдалечени процедури са описани в RFC 1813 и са изброени в началото на тази статия.
Въпреки че последователността на командите за достъп до отдалечени файлови системи е много проста, редица обстоятелства могат да доведат до неправилно монтиране на системата. Преди да монтирате директория, точката на монтиране трябва вече да съществува в в противен случайтрябва да се създаде с помощта на командата mkdir. Обикновено единствената причина за грешки на клиентска странае липсата на локална директория за монтиране. Повечето проблеми, свързани с NFS, се дължат на несъответствие между клиента и сървъра или неправилна конфигурация на сървъра.
Най-лесният начин за отстраняване на проблеми на сървър е от възела, на който сървърът работи. Въпреки това, когато някой друг администрира сървъра вместо вас, това не винаги е възможно. Бърз начин да се уверите, че подходящите сървърни услуги са конфигурирани правилно, е да използвате командата rpcinfo с опцията -p. От хоста на Solaris Sunny можете да определите кои RPC процеси са регистрирани на хоста на Linux:
# rpcinfo -p 192.168.1.254 програма vers proto port service 100000 2 tcp 111 rpcbind 100000 2 udp 111 rpcbind 100024 1 udp 692 status 100024 1 tcp 694 status 100005 3 udp 1024 монтиране d /100005 3 tcp 1024 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100021 1 udp 1026 nlockmgr 100021 3 udp 1026 nlockmgr 100021 4 udp 1026 nlockmgr #
Имайте предвид, че тук също е предоставена информация за версията, което е доста полезно, когато системата изисква поддръжка за различни NFS протоколи. Ако някоя услуга не работи на сървъра, тогава тази ситуация трябва да бъде коригирана. Ако монтирането е неуспешно, следната команда rpcinfo -p ще ви помогне да определите, че услугата mountd на сървъра не работи:
# rpcinfo -p 192.168.1.254 програма vers прото порт услуга 100000 2 tcp 111 rpcbind ... ... 100021 4 udp 1026 nlockmgr #
Командата rpcinfo е много полезна за установяване дали нещо е активно отдалечен процес. Параметърът -p е най-важният от ключовете. За да видите всички функции на rpcinfo, вижте страницата с ръководство.
Друг полезен инструмент е командата nfsstat. С негова помощ можете да разберете дали клиентите действително имат достъп до експортираната файлова система, както и да показвате статистическа информация в съответствие с версията на протокола.
Накрая, още един е достатъчен полезен инструментопределяне на причините за системни повреди е tcpdump:
# tcpdump хост lefty и хост sunny -s512 tcpdump: слушане на eth0 06:29:51.773646 sunny.2191984020 > lefty.mcwrite.n.nfs: 140 търсене fh Unknown/1"test.c" (DF) 06:29:51.773819 lefty.mcwrite.n.nfs > sunny.2191984020: отговор добре 116 ГРЕШКА при търсене: Няма такъв файл или директория (DF) 06:29:51.774593 sunny.2191984021 > lefty.mcwrite.n.nfs: 128 getattr fh Неизвестно/1 ( DF) 06:29:51.774670 lefty.mcwrite.n.nfs > sunny.2191984021: отговор добре 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:29:51.775289 sunny.2191984022 > lefty m cwrite.n.nfs : 140 търсене fh Неизвестно/1"test.c" (DF) 06:29:51.775357 lefty.mcwrite.n.nfs > sunny.2191984022: отговор добре 116 търсене ГРЕШКА: Няма такъв файл или директория (DF) 06:29: 51.776029 sunny.2191984023 > lefty.mcwrite.n.nfs: 184 create fh Unknown/1 "test.c" (DF) 06:29:51.776169 lefty.mcwrite.n.nfs > sunny.2191984023: отговор добре 120 create ERROR: Разрешението е отказано (DF)
Горният списък, създаден чрез изпълнение на оператора touch test.c, показва следната последователност от действия: първо командата touch се опитва да получи достъп до файл с име test.c, след това търси директория със същото име и след неуспешни опити опитва се да създаде файл test.c , което също не води до успех.
Ако файловата система е монтирана, тогава повечето типични грешкисвързани с нормални UNIX разрешения. Използването на uid или NIS+ на Sun помага да се избегне глобалното задаване на разрешения за всички файлови системи. Някои администратори практикуват "отворени" директории, където достъпът за четене се дава на "целия свят". Това обаче трябва да се избягва от съображения за безопасност. Като оставим настрана опасенията за сигурността, този подход все още е лоша практика, тъй като потребителите рядко създават данни с намерението да ги направят четими от всички.
Достъпът от привилегирован потребител (root) до монтирани NFS файлови системи се третира по различен начин. За да се избегне предоставянето на неограничен достъп на привилегирован потребител, заявките от привилегирования потребител се третират така, сякаш идват от потребителя никой. Този мощен механизъм ограничава достъпа на привилегирован потребител до глобално четими и записваеми файлове.
NFS СЪРВЪР SOLARIS ВЕРСИЯ
Конфигурирането на Solaris да работи като NFS сървър е толкова лесно, колкото и с Linux. Командите и местоположенията на файловете обаче са малко по-различни. Когато Solaris се стартира, при достигане на ниво на изпълнение 3, NFS услугите се стартират автоматично и всички файлови системи се експортират. За да стартирате тези процеси ръчно, въведете командата:
#/usr/lib/nfs/mountd
За да стартирате демона за монтиране и NFS сървъра, въведете:
#/usr/lib/nfs/nfsd
Започвайки с версия 2.6, Solaris вече не използва файл за експортиране, за да посочи кои файлови системи да експортира. Файловете вече се експортират с помощта на командата за споделяне. Да кажем, че искаме да позволим на отдалечени хостове да монтират /export/home. За да направите това, въведете следната команда:
Споделяне -F nfs /export/home
Мерки за сигурност
СИГУРНОСТ В LINUX
Някои NFS системни услуги са включени Базиран на Linuxимат допълнителен механизъм за ограничаване на достъпа чрез контролни списъци или таблици. На вътрешно ниво този механизъм се реализира с помощта на библиотеката tcp_wrapper, която използва два файла за генериране на списъци за контрол на достъпа: /etc/hosts.allow и /etc/hosts/deny. Изчерпателният преглед на правилата за работа с tcp_wrapper е извън обхвата на тази статия, но основният принцип е следният: сравнението първо се прави с etc/hosts.allow, а след това с /etc/hosts. отричам. Ако правилото не бъде намерено, тогава исканата системна услуга не се представя. За да заобиколите това последно изискване и да осигурите много високо ниво на сигурност, можете да добавите следния запис в края на /etc/hosts.deny:
ВСИЧКИ: Всички
След това можете да използвате /etc/hosts.allow, за да зададете един или друг режим на работа. Например файлът /etc/hosts. позволи, който използвах при писането на тази статия, съдържаше следните редове:
Lockd:192.168.1.0/255.255.255.0 mountd:192.168.1.0/255.255.255.0 portmap:192.168.1.0/255.255.255.0 rquotad:192.168.1.0/255.255.255.0 statd:192 .1 68.1.0/255.255.255.0
Това позволява специфичен тип достъп до хостове, преди да предостави достъп на ниво приложение. В Linux достъпът на ниво приложение се контролира от файла /etc/exports. Състои се от записи в следния формат:
Експортиране на директория (пространство) хост|мрежа (опции)
„Експортна директория“ е директория, за която демонът nfsd има право да обработва заявки. „Възел|мрежа“ е възелът или мрежата, която има достъп до експортираната файлова система, а „опциите“ определят ограниченията, които демонът nfsd налага върху използването на този споделен ресурс – достъп само за четене или съпоставяне на потребителски идентификатори. .
Следният пример дава достъп само за четене на целия домейн mcwrite.net до /home/mcwrite.net:
/home/mcwrite.net *.mcwrite.net(ro)
Повече примери могат да бъдат намерени в страницата за ръководство за експорти.
NFS СИГУРНОСТ В SOLARIS
В Solaris възможността за предоставяне на достъп до NFS е подобна на Linux, но в този случай ограниченията се задават с помощта на определени параметри в командата за споделяне с превключвателя -o. Следният пример показва как да активирате монтиране само за четене на /export/mcwrite.net на всеки хост в домейна mcwrite.net:
#share -F nfs -o ro=.mcwrite.net/ export/ mcwrite.net
Man страницата за share_nfs предоставя подробности за предоставяне на достъп чрез контролни списъци на Solaris.
Интернет ресурси
NFS и RPC не са без дупки. Най-общо казано, NFS не трябва да се използва при сърфиране в Интернет. Не можете да пробиете дупки в защитните стени, за да разрешите всякакъв вид достъп през NFS. Важно е да следите отблизо всички нововъзникващи RPC и NFS кръпки и множество източници на информация за сигурността могат да помогнат. Двата най-популярни източника са Bugtraq и CERT:
Първият може да се преглежда редовно в търсене на необходимата информация или като се абонирате за периодични бюлетини. Вторият предоставя може би не толкова бърза информация в сравнение с други, но в доста пълен обем и без сянката на сензация, характерна за някои сайтове, посветени на информационната сигурност.
NFS: удобна и обещаваща мрежова файлова система
Мрежова файлова системае мрежова абстракция върху обикновена файлова система, която позволява на отдалечен клиент да има достъп до нея през мрежата по същия начин, както при достъп до локални файлови системи. Въпреки че NFS не беше първата мрежова файлова система, тя се разви, за да стане най-способната и популярна мрежова файлова система в UNIX® днес. NFS позволява на множество потребители да споделят обща файлова система и централизира данните, за да ги минимизира дисково пространствонеобходими за тяхното съхранение.
Тази статия започва с кратък преглед на историята на NFS и след това преминава към изследване на архитектурата на NFS и как тя може да се развие в бъдеще.
Кратка история на NFS
Първата мрежова файлова система се нарича FAL (File Access Listener) и е разработена през 1976 г. от DEC (Digital Equipment Corporation). Това беше реализация на протокола DAP (протокол за достъп до данни) и беше част от пакета протоколи DECnet. Както при TCP/IP, DEC публикува спецификации за своите мрежови протоколи, включително DAP протокола.
NFS беше първата модерна мрежова файлова система, изградена върху IP протокола. Неговият прототип може да се счита за експериментална файлова система, разработена в Sun Microsystems в началото на 80-те години. Като се има предвид популярността на това решение, NFS протоколът беше въведен като RFC спецификация и впоследствие еволюира в NFSv2. NFS бързо се утвърди като стандарт поради способността си да взаимодейства с други клиенти и сървъри.
Впоследствие стандартът беше актуализиран до NFSv3, дефиниран в RFC 1813. Тази версия на протокола беше по-мащабируема от предишните версии и поддържаше по-големи размери на файлове (над 2 GB), асинхронно писане и TCP като транспортен протокол. NFSv3 определя посоката за развитие на файлови системи за широкообхватни мрежи (WAN). През 2000 г. RFC 3010 (ревизиран като RFC 3530) въведе NFS в корпоративната среда. Sun представи по-сигурен NFSv4 с поддръжка на състояние (предишните версии на NFS не поддържаха съхранение на състояние, т.е. бяха класифицирани като без състояние). В момента най-новата версия на NFS е версия 4.1, дефинирана в RFC 5661, която добавя към протокола чрез разширяване pNFSдобавена е поддръжка за паралелен достъп за разпределени сървъри.
Историята на NFS, включително специфични RFC, описващи нейните версии, е показана на фигура 1.
Изненадващо, NFS се разработва от почти 30 години. Това е изключително стабилна и преносима мрежова файлова система с изключителна мащабируемост, производителност и характеристики за качество на услугата. Тъй като скоростите се увеличават и забавянето намалява при комуникация в мрежа, NFS продължава да бъде популярен начин за внедряване на файлова система в мрежа. Дори в случай на локални мрежи виртуализацията насърчава съхраняването на данни в мрежата, за да осигури допълнителна мобилност на виртуалните машини. NFS също поддържа най-новите модели на изчислителна среда, насочени към оптимизиране на виртуални инфраструктури.
NFS архитектура
NFS използва стандартен архитектурен модел клиент-сървър (както е показано на фигура 2). Сървърът е отговорен за внедряването на споделена файлова система и хранилище, към което се свързват клиентите. Клиентът реализира потребителски интерфейс към споделена файлова система, монтирана в локалното файлово пространство на клиента.
Фигура 2. Внедряване на модела клиент-сървър в NFS архитектурата
В операционната система Linux® превключвател на виртуална файлова система (VFS) осигурява средствата за едновременна поддръжка на множество файлови системи (например файлова система) на един хост. ISO системи 9660 на CD-ROM и файлова система ext3fs на локален твърд диск). Виртуалният превключвател определя към кое устройство е направена заявката и следователно коя файлова система трябва да се използва за обработка на заявката. Следователно NFS има същата съвместимост като другите файлови системи, използвани в Linux. Единствената разлика с NFS е, че вместо да се обработват локално на хоста, I/O заявките могат да се изпращат към мрежата за изпълнение.
VFS определя, че получената заявка е NFS и я предава на манипулатора на NFS, разположен в ядрото. NFS манипулаторът обработва I/O заявката и я превежда в NFS процедура (ОТВАРЯНЕ, ДОСТЪП, СЪЗДАВАНЕ, ЧЕТЕНЕ, ЗАТВОРЯВАНЕ, ПРЕМАХВАНЕ и т.н.). Тези процедури, описани в отделна RFC спецификация, дефинират поведението на NFS протокола. Необходимата процедура се избира в зависимост от заявката и се изпълнява чрез технологията RPC (remote procedure call). Както подсказва името му, RPC позволява да се правят извиквания на процедури между различни системи. RPC услугата свързва NFS заявка с нейните аргументи и изпраща резултата до съответния отдалечен хост, след което следи получаването и обработката на отговора, за да го върне на заявителя.
RPC също включва важен XDR слой ( външно представяне на данни- независимо представяне на данни), гарантирайки, че всички потребители на NFS използват един и същ формат за едни и същи типове данни. Когато дадена платформа изпрати заявка, типът данни, който използва, може да е различен от типа данни, използван на хоста, обработващ заявката. Технологията XDR се грижи за работата по преобразуването на типове в стандартно представяне (XDR), така че платформите, използващи различни архитектури, да могат да си взаимодействат и да споделят файлови системи. XDR дефинира битовия формат за типове като float и реда на байтовете за типове като масиви от константи и променлива дължина. Въпреки че XDR е известен предимно с използването си в NFS, тази спецификация може да бъде полезна във всички случаи, когато трябва да работите в една и съща среда с различни архитектури.
След като XDR преведе данните в стандартно представяне, заявката се изпраща по мрежата с помощта на специфичен транспортен протокол. Ранните реализации на NFS използваха UDP, но днес TCP се използва за по-голяма надеждност.
Подобен алгоритъм се използва от страната на NFS сървъра. Заявката се движи нагоре по мрежовия стек през RPC/XDR слоя (за преобразуване на типовете данни според архитектурата на сървъра) и в NFS сървъра, който отговаря за обработката на заявката. Там заявката се предава на NFS демона, за да определи целевата файлова система, към която е адресирана, и след това отново отива на VFS за достъп до тази файлова система на локалния диск. Пълната диаграма на този процес е показана на фигура 3. В този случай локалната файлова система на сървъра е стандартна за Linux файлсистема, например ext4fs. По същество NFS не е файлова система в традиционния смисъл на думата, а протокол за отдалечен достъп до файлови системи.
За мрежи с голяма латентност NFSv4 предлага специална комбинирана процедура ( комбинирана процедура). Тази процедура ви позволява да поставите множество RPC повиквания в рамките на една заявка, за да минимизирате разходите за изпращане на заявки по мрежата. Тази процедура също така прилага механизъм за функция за обратно извикване за получаване на отговори.
NFS протокол
Когато клиент започне да използва NFS, първото действие е да извърши операция за монтиране, която е да монтира отдалечената файлова система в пространството на локалната файлова система. Този процес започва с извикване на процедурата за монтиране (една от системни функции Linux), който се пренасочва чрез VFS към NFS компонента. След това RPC извикване към функцията get_port на отдалечения сървър определя номера на порта, който ще се използва за монтиране, и клиентът изпраща заявка за монтиране чрез RPC. Тази заявка от страната на сървъра се обработва от специален демон rpc.mountd, който отговаря за протокола за монтиране ( протокол за монтиране). Демонът проверява дали файловата система, поискана от клиента, е в списъка на наличните системи този сървър. Ако исканата система съществува и клиентът има достъп до нея, отговорът от процедурата за монтиране на RPC указва дескриптор на файлова система. Клиентът запазва информация за локални и отдалечени точки на монтиране и може да прави I/O заявки. Протоколът за монтиране не е защитен от гледна точка на сигурността, така че NFSv4 използва вместо това вътрешни RPC извиквания, които също могат да управляват точки за монтиране.
За да прочетете файл, първо трябва да го отворите. В RPC няма процедура OPEN; вместо това клиентът просто проверява това посочен файли директория съществуват в монтираната файлова система. Клиентът започва с отправяне на GETATTR RPC заявка към директорията, която връща атрибутите на директорията или индикатор, че директорията не съществува. След това, за да провери наличието на файла, клиентът издава LOOKUP RPC заявка. Ако файлът съществува, към него се прави GETATTR RPC заявка, за да се открият атрибутите на файла. Използвайки информацията, получена от успешни извиквания на LOOKUP и GETATTR, клиентът създава манипулатор на файла, който се предоставя на потребителя за бъдещи заявки.
След като файлът бъде идентифициран в отдалечената файлова система, клиентът може да издава RPC READ заявки. Тази заявка се състои от файлов дескриптор, състояние, отместване и броя байтове за четене. Клиентът използва състояние ( състояние), за да се определи дали операцията може да се извърши в момента, т.е. Файлът заключен ли е? Изместване ( изместване) показва от коя позиция да започне четенето, а броячът на байтовете ( броя) определя колко байта трябва да бъдат прочетени. В резултат на RPC READ повикване, сървърът не винаги връща толкова байтове, колкото са били заявени, но заедно с върнатите данни винаги отчита колко байта са изпратени на клиента.
Иновация в NFS
Най-голям интерес представляват двете последни версии на NFS - 4 и 4.1, като примери за които можете да проучите най-важните аспекти от еволюцията на NFS технологията.
Преди NFSv4 да беше достъпен за изпълнение на задачи за управление на файлове като монтиране, заключване и т.н. имаше специални допълнителни протоколи. В NFSv4 процесът на управление на файлове беше опростен до един протокол; Освен това, започвайки с тази версия, UDP вече не се използва като транспортен протокол. NFSv4 включва поддръжка за UNIX и Windows® семантика за достъп до файлове, което позволява на NFS да се интегрира естествено в други операционни системи.
NFSv4.1 въведе концепцията за паралелен NFS(паралелен NFS - pNFS). За да осигури по-високи нива на мащабируемост, NFSv4.1 прилага архитектура, в която данните и метаданните ( маркиране) се разпределят между устройствата по начин, подобен на начина, по който се прави в клъстерните файлови системи. Както е показано в , pNFS разделя екосистемата на три компонента: клиент, сървър и хранилище. В този случай се появяват два канала: единият за предаване на данни, а другият за предаване на команди за управление. pNFS разделя данните от метаданните, които ги описват, осигурявайки двуканална архитектура. Когато клиент иска достъп до файл, сървърът му изпраща метаданни с „маркиране“. Метаданните съдържат информация за местоположението на файла на устройствата за съхранение. След като клиентът получи тази информация, той може да получи директен достъп до хранилището, без да се налага да взаимодейства със сървъра, подобрявайки скалируемостта и производителността. Когато клиентът приключи работата с файла, той потвърждава направените промени във файла и неговата "маркировка". Ако е необходимо, сървърът може да поиска метаданни с маркиране от клиента.
С появата на pNFS бяха добавени няколко нови операции към NFS протокола, за да поддържат такъв механизъм. Методът LayoutGet се използва за извличане на метаданни от сървъра, методът LayoutReturn "освобождава" метаданни, "уловени" от клиента, а методът LayoutCommit зарежда "оформлението", получено от клиента, в хранилището, така че да е достъпно за други потребители. Сървърът може да извика метаданни от клиента с помощта на метода LayoutRecall. „Маркираните“ метаданни се разпределят между множество устройства за съхранение, за да се осигури паралелен достъп и висока производителност.
Данните и метаданните се съхраняват на устройства за съхранение. Клиентите могат да изпълняват директни I/O заявки въз основа на полученото маркиране, а NFSv4.1 сървърът съхранява и управлява метаданните. Самата тази функционалност не е нова, но pNFS добави поддръжка за различни методи за достъп до устройства за съхранение. Днес pNFS поддържа използването на блокови протоколи (Fibre Channel), обектни протоколи и самия NFS (дори не във формата на pNFS).
Разработването на NFS продължава и през септември 2010 г. бяха публикувани изискванията за NFSv4.2. Някои от иновациите са свързани с продължаващата миграция на технологиите за съхранение на данни към виртуализация. Например в виртуални средиПри хипервизор дублирането на данни е много вероятно (няколко операционни системи четат/записват и кешират едни и същи данни). Поради това е желателно системата за съхранение като цяло да разбере къде възниква дублирането. Този подход ще помогне да се спести място в кеша на клиента и общ капацитет за съхранение. NFSv4.2 предлага използването на "блокова карта на споделени блокове" за решаване на този проблем. Тъй като модерни системисистемите за съхранение все повече се оборудват със собствена вътрешна изчислителна мощност, въвежда се копиране от страна на сървъра, за да се намали натоварването при копиране на данни в вътрешна мрежакогато може да се направи ефективно на самото устройство за съхранение. Други нововъведения включват кеширане на подфайлове за флаш памет и препоръки за I/O настройка от страна на клиента (като използване на mapadvise).
NFS алтернативи
Въпреки че NFS е най-популярната мрежова файлова система в UNIX и Linux, има и други мрежови файлови системи. В платформата Windows® най-често се използва SMB, известен още като CIFS; обаче Windows OS също поддържа NFS, както и Linux поддържа SMB.
Една от най-новите разпределени файлови системи, поддържани от Linux, Ceph, е проектирана от самото начало да бъде толерантна към грешки POSIX-съвместима файлова система. Повече информация за Ceph можете да намерите в раздела.
Също така си струва да се споменат файловите системи OpenAFS (версия с отворен код на разпределената файлова система Andrew, разработена в университета Карнеги Мелън и IBM Corporation), GlusterFS (разпределена файлова система с общо предназначениеза организиране на мащабируемо съхранение на данни) и Luster (мрежова файлова система с масивен паралелизъм за клъстерни решения). Всички тези системи с отворен код могат да се използват за изграждане на разпределено хранилище.
Заключение
Развитието на файловата система NFS продължава. Подобно на операционната система Linux, която може да поддържа както решения от нисък клас, вградени, така и решения от висок клас, NFS предоставя архитектура за мащабируеми решения за съхранение, подходящи както за физически лица, така и за организации. Когато погледнете пътя, който NFS вече е извървял, и перспективите за бъдещото му развитие, става ясно, че тази файлова система ще продължи да променя начина, по който мислим за това как се внедряват и използват технологиите за съхранение на файлове.
Мрежова файлова система (NFS)- протокол достъп до мрежатакъм файлови системи, ви позволява да свържете отдалечени файлови системи.
Първоначално разработен от Sun Microsystems през 1984 г. Основата е Sun RPC: Remote Procedure Call. NFS е независим от типовете файлови системи на сървъра и клиента. Има много реализации на NFS сървъри и клиенти за различни операционни системи. В момента се използва NFS версия v.4, който поддържа различни средства за удостоверяване (по-специално Kerberos и LIPKEY, използвайки RPCSEC GSS протокол) и списъци за контрол на достъпа (както POSIX, така и тип Windows).
NFS дава на клиентите прозрачен достъп до файловете и файловата система на сървъра. За разлика от FTP, протоколът NFS има достъп само до онези части от файла, които са достъпни от процеса, като основното му предимство е, че прави този достъп прозрачен. Благодарение на това всяко клиентско приложение, което може да работи с локален файл, може да работи със същия успех с NFS файл, без да променя самата програма.
NFS клиентите имат достъп до файлове на NFS сървър чрез изпращане на RPC заявки към сървъра. Това може да се реализира с помощта на нормални потребителски процеси - а именно NFS клиентът може да бъде потребителски процес, който прави специфични RPC извиквания към сървъра, който също може да бъде потребителски процес.
Версии
NFSv1 беше за вътрешна употреба само за експериментални цели. Подробностите за внедряването са определени в RFC 1094.
NFSv2 (RFC 1094, март 1989 г.) първоначално работи изцяло върху UDP.
NFSv3 (RFC 1813, юни 1995 г.). Файловите дескриптори във версия 2 са масив с фиксиран размер от 32 байта. Във версия 3 това е масив с променлив размер с размер до 64 байта. Масив с променлива дължина в XDR се определя от 4-байтов брояч, последван от реални байтове. Това намалява размера на файловия дескриптор в реализации като UNIX, където са необходими само около 12 байта, но позволява на не-Unix реализации да обменят допълнителна информация.
Версия 2 ограничава броя на байтовете на READ или WRITE RPC до 8192 байта. Това ограничение не се прилага във версия 3, което от своя страна означава, че при използване на UDP ограничението ще бъде само размерът на IP дейтаграмата (65535 байта). Това позволява големи пакети да се използват за четене и запис в бързи мрежи.
Размерите на файловете и отместванията на началните байтове за процедурите READ и WRITE вече използват 64-битово адресиране вместо 32-битово, което позволява работа с по-големи файлове.
Атрибутите на файла се връщат при всяко извикване, което може да повлияе на атрибутите.
Записите (WRITE) могат да бъдат асинхронни, докато във версия 2 те трябваше да бъдат синхронни.
Една процедура беше премахната (STATFS) и бяха добавени седем: ACCESS (проверете разрешенията за файл), MKNOD (създайте специален файл Unix), READDIRPLUS (връща имената на файловете в директория заедно с техните атрибути), FSINFO (връща статистическа информация за файловата система), FSSTAT (връща динамична информация за файловата система), PATHCONF (връща POSIX.1 информация за файл) и COMMIT (предава предварително направени асинхронни записи за постоянно съхранение).
По време на въвеждането на версия 3 разработчиците започнаха да използват TCP повече като транспортен протокол. Въпреки че някои разработчици вече са използвали TCP за NFSv2, Sun Microsystems добави TCP поддръжка в NFS версия 3. Това направи използването на NFS през Интернет по-осъществимо.
NFSv4 (RFC 3010, декември 2000 г., RFC 3530, ревизиран април 2003 г.), повлиян от AFS и CIFS, включва подобрения на производителността, висока сигурност и се превръща в пълноценен протокол. Версия 4 беше първата версия, разработена съвместно с Internet Engineering Task Force (IETF), след като Sun Microsystems прехвърли разработката на протокол към NFS. NFS v4.1 беше одобрен от IESG през януари 2010 г. и получи номер RFC 5661. Важна иновация във версия 4.1 е спецификацията на pNFS - Parallel NFS, механизъм за паралелен NFS клиентски достъп до данни от множество разпределени NFS сървъри. Наличието на такъв механизъм в стандарта на мрежовата файлова система ще помогне за изграждането на разпределени „облачни“ системи за съхранение и информация.
Структурата на NFS включва три компонента на различни нива:
Приложният слой (самият NFS) се състои от извиквания на отдалечени процедури (rpc), които извършват необходимите операции с файлове и директории от страната на сървъра.
Функциите на презентационния слой се изпълняват от протокола XDR (eXternal Data Representation), който е междуплатформен стандарт за абстракция на данни. Протоколът XDR описва унифицирана, канонична форма на представяне на данни, която не зависи от архитектурата на компютърната система. При предаване на пакети RPC клиентът преобразува локалните данни в канонична форма, а сървърът извършва обратната операция.
Услугата RPC (Remote Procedure Call), която позволява на клиента да поиска отдалечени процедури и да ги изпълни на сървъра, представлява функции на ниво сесия. Свързване на мрежови ресурси
Процедурата за свързване на мрежов ресурс чрез NFS се нарича „експортиране“. Клиентът може да поиска от сървъра да изброи експортираните ресурси, които представлява. Самият NFS сървър не излъчва списък на своите експортирани ресурси.
В зависимост от посочените опции, експортираният ресурс може да бъде монтиран (прикачен) „само за четене“, можете да дефинирате списък с хостове, на които е разрешено да монтирате, да посочите използването на защитен RPC (secureRPC) и т.н. Една от опциите определя метода на монтаж: „твърд“ (твърд) или „мек“ (мек).
При "твърдо" монтиране клиентът ще се опита да монтира файловата система на всяка цена. Ако сървърът не работи, това ще доведе до блокиране на цялата NFS услуга: процесите, осъществяващи достъп до файловата система, ще преминат в състояние на изчакване за завършване на RPC заявките. От гледна точка на потребителските процеси, файловата система ще изглежда като много бавен локален диск. Когато сървърът се върне в работно състояние, NFS услугата ще продължи да функционира.
При меко монтиране NFS клиентът ще направи няколко опита да се свърже със сървъра. Ако сървърът не отговори, системата показва съобщение за грешка и спира опитите за монтиране. От гледна точка на логиката на файловите операции, когато сървърът се повреди, „мекото“ монтиране емулира повреда на локален диск.
Изборът на режим зависи от ситуацията. Ако данните на клиента и сървъра трябва да се синхронизират по време на временна повреда на услугата, тогава е за предпочитане „твърдо“ монтиране. Този режим също е незаменим в случаите, когато монтираните файлови системи съдържат програми и файлове, които са жизненоважни за работата на клиента, особено за бездискови машини. В други случаи, особено когато ние говорим заПо отношение на системите само за четене, режимът на меко монтиране изглежда по-удобен.
Споделяне в смесена мрежа
NFS е идеален за UNIX-базирани мрежи, тъй като идва с повечето версии на операционната система. Освен това поддръжката на NFS е внедрена на ниво ядро на UNIX. Използването на NFS на клиентски компютри с Windows създава определени проблеми, свързани с необходимостта от инсталиране на специализиран и доста скъп клиентски софтуер. В такива мрежи използването на инструменти за споделяне на ресурси, базирани на протокола SMB/CIFS, по-специално софтуер Samba, изглежда по-предпочитано.
Стандарти
RFC 1094 NFS: Спецификация на протокола за мрежова файлова система] (март 1989 г.)
RFC 1813 NFS версия 3 спецификация на протокола] (юни 1995 г.)
RFC 2224 NFS URL схема
RFC 2339 Споразумение Между Internet Society, IETF и Sun Microsystems, Inc. по отношение на NFS V.4 протоколи
RFC 2623 Проблеми със сигурността на NFS версия 2 и версия 3 и използването на RPCSEC_GSS и Kerberos V5 от NFS протокола
RFC 2624 NFS версия 4 Съображения относно дизайна
RFC 3010 NFS версия 4 протокол
RFC 3530 Протокол за мрежова файлова система (NFS) версия 4
RFC 5661 Мрежова файлова система (NFS) Версия 4 Второстепенна версия 1 Протокол
Използвани източници
1. ru.wikipedia.org
2. ru.science.wikia.com
3. phone16.ru
4. 4stud.info
5. yandex.ru
6.google.com
Основни характеристики на файловата система NFS на платформа UNIX.
Щастието е, когато нашите желания съвпадат с възможностите на другите хора.
"Времечко"
Мрежовите файлови системи са играли, играят и ще играят важна роля в информационна инфраструктура. Въпреки нарастващата популярност на сървърите за приложения, файловата услуга остава универсално средство за организиране на колективен достъп до информация. Освен това, много сървъри на приложения също действат като файлови сървъри.
В момента операционната система UNIX преживява нещо като ренесанс и дължи голяма част от този ръст на интереса на свободно разпространяваната операционна система Linux. В същото време различни версии на Windows се използват на настолни компютри, предимно Windows 9x и Windows NT/2000, въпреки че свободно разпространяваните разновидности на UNIX постепенно придобиват гражданство тук.
За много организации хостването на мрежова файлова услуга на UNIX компютри е много привлекателно решение, при условие че услугата има достатъчна производителност и надеждност. Като се имат предвид многото разлики във файловите системи UNIX и Windows, предимно в схемите за именуване на файлове, правата за достъп, заключването и системните извиквания при достъп до файлове, осигуряването на прозрачност на достъпа в разнородната UNIX/Windows среда е от особено значение. В допълнение UNIX файловите сървъри често се инсталират като допълнение към съществуващите Windows NT и NetWare сървъри.
За операционната система UNIX има реализации на всички повече или по-малко популярни мрежови файлови системи, включително тези, използвани в мрежите на Microsoft (SMB), NetWare (NCP), Macintosh (AFP). Разбира се, UNIX мрежите имат свои собствени протоколи, най-вече NFS и DFS. Имайте предвид, че всеки UNIX сървър може едновременно да предоставя NFS и SMB услуги (както и NCP и AFP) и по този начин осигурява допълнителна гъвкавост при създаване на мрежова инфраструктура.
Въпреки разнообразието от мрежови файлови системи на UNIX, безспорни лидери са системите NFS (Network File System, буквален превод - мрежова файлова система) и SMB (Service Message Block). Тази статия ще обсъди възможностите на NFS. В същото време в един от предстоящите издания планираме да разгледаме характеристиките на SMB на платформата UNIX и на първо място продукта Samba, който се е доказал добре в мрежи UNIX/Windows.
NFS ВЕРСИИ
Първата реализация на мрежовата файлова система NFS е разработена от Sun Microsystems през 1985 г. Оттогава NFS стана широко разпространен в света на UNIX, като инсталациите наброяваха десетки милиони. Освен в UNIX, системата NFS като сървърна платформа намери приложение в операционните системи VMS, MVS и дори Windows.
NFS е родната файлова система за UNIX и следва логиката на файловите операции на UNIX като никоя друга. Това се отнася за пространството на имената на файловете и разрешенията. Освен това поддръжката на NFS е вградена в ядрото на всички популярни версии на UNIX-подобни операционни системи.
В момента NFS е представена от втора и трета версия (първата версия на NFS никога не се е появявала на пазара). Въпреки редица ограничения, NFS v2 е много популярен; той е част от свободно разпространявания UNIX (по-специално Linux), както и някои търговски UNIX.
Третата версия на NFS е разработена в средата на 90-те години от съвместните усилия на Sun, IBM, Digital и други компании за подобряване на производителността, сигурността и лекотата на администриране на мрежовата файлова система. NFS v3 е обратно съвместим с предишната NFS спецификация, което означава, че NFS v3 сървър може да обслужва повече от NFS клиенти v3, но също и NFS v2 клиенти.
Въпреки доста дългото си присъствие на пазара, NFS v3 все още отстъпва на NFS v2 по отношение на броя на инсталациите. Въз основа на тези съображения първо ще се съсредоточим върху основните характеристики на NFS v2, а след това ще се запознаем с новостите в третата версия на NFS.
Имайте предвид, че специфичните реализации на една и съща версия на NFS може леко да се различават една от друга. Разликите се отнасят предимно до състава на демоните, техните имена, местоположение и имената на NFS конфигурационните файлове. В допълнение, реализациите на NFS зависят от възможностите и характеристиките на самия UNIX. Например NFS v2 поддържа ACL, но само във варианти на UNIX, които имат такава поддръжка, вградена в ядрото. Ето защо, когато описваме NFS, ще разгледаме най-общия случай.
NFS V2 ПРОТОКОЛИ
Фигура 1 показва мрежовия модел NFS v2 според референтния модел OSI. За разлика от повечето TCP/IP мрежови услуги, NFS изрично използва протоколи за представяне и сесия. NFS работи въз основа на концепцията за извикване на отдалечени процедури (RPC). Според тази концепция при достъп отдалечен ресурс(например към файл) програма на локален компютъризвършва нормално системно извикване (да речем извикване на функцията за отваряне на файл), но всъщност процедурата се изпълнява дистанционно - на ресурсния сървър. В този случай потребителският процес не може да определи дали повикването се извършва локално или отдалечено. След като установи, че даден процес има достъп до ресурс на отдалечен компютър, действащ като сървър, ядрото или специален демон на системата пакетира аргументите на процедурата заедно с нейния идентификатор в мрежов пакет, отваря комуникационна сесия със сървъра и препраща този пакет към него. Сървърът разопакова получения пакет, определя исканата процедура и аргументи и след това изпълнява процедурата. След това сървърът изпраща кода за връщане на процедурата на клиента, който го предава на потребителския процес. Така че RPC е напълно съвместим ниво на сесията OSI модели.
Възниква справедлив въпрос: защо NFS мрежовият модел се нуждае от специален протокол на ниво презентация? Въпросът е, че Sun разумно разчита на използването на NFS в разнородни мрежи, където компютрите имат различни системни архитектури, включително различно подреждане на байтове в машинна дума, различни представяния с плаваща запетая, несъвместими граници на подравняване на структурата и т.н. Тъй като протоколът RPC включва изпращане структурирани данни, наличието на протокол на ниво представяне е спешна необходимост в хетерогенна среда. Това е протоколът за външно представяне на данни (eXternal Data Representation, XDR). Той описва така наречената канонична форма на представяне на данни, която не зависи от системната архитектура на процесора. Когато предава RPC пакети, клиентът превежда локалните данни в канонична форма, а сървърът извършва обратната операция. Трябва да се има предвид, че канонична форма XDR съответства на представянето на данните, прието за фамилията процесори SPARC и Motorola. В сървъри, които прилагат подобна форма на представяне на данни, това позволява да се постигне известно (макар и най-вероятно микроскопично) предимство в производителността спрямо конкурентите в случаите на интензивен достъп до файловия сървър.
В NFS v2 UDP беше избран като транспортен протокол. Разработчиците обясняват това с факта, че RPC сесията трае кратък период от време. Освен това, от гледна точка на изпълнение на отдалечени процедури, всеки RPC пакет е самостоятелен, т.е. всеки пакет носи пълна информация за това какво трябва да се изпълни на сървъра или за резултатите от процедурата. RPC услугите обикновено са без връзка, което означава, че сървърът не съхранява информация за това какви клиентски заявки са били обработени в миналото, като например къде във файл клиентът последно е прочел данни. За мрежова файлова система това е определено предимство по отношение на надеждността, тъй като клиентът може да продължи файловите операции веднага след рестартирането на сървъра. Но тази схема е изпълнена с проблеми при писане и заключване на файлове и за да ги заобиколят, разработчиците на NFS бяха принудени да използват различни заобикалящи решения (използването на UDP поражда друг набор от специфични проблеми, но ще ги разгледаме по-късно).
Важна разлика между RPC услугите, включени в NFS, и други мрежови сървърни услуги е, че те не използват inetd super daemon. Обикновените мрежови услуги, като telnet или rlogin, обикновено не се стартират като демони при стартиране на системата, въпреки че това не е забранено. Най-често те използват така наречения super daemon inetd, който „слуша“ софтуерните портове TCP протоколии UDP. Услугите са посочени в конфигурационния файл на superdaemon (обикновено /etc/inetd.conf). Когато се получи заявка на софтуерен порт от клиент, inetd стартира съответния процес като дъщерен процес. мрежова услуга(например in.rlogind), който обработва заявката.
RPC услугите не използват inetd super daemon, тъй като, както беше отбелязано, RPC сесията продължава само за много кратко време, всъщност само за продължителността на една заявка. Това означава, че за всяка заявка inetd ще бъде принуден да стартира нов дъщерен процес на услугата RPC, което е много скъпо за UNIX. По подобни причини един RPC процес не може да създаде нови процеси и не може да обслужва множество заявки паралелно. Следователно, за да се подобри производителността, RPC услугите се изпълняват като множество екземпляри на демон, работещи едновременно. Въпреки това, броят на екземплярите на даден демон не е пряко свързан с броя на клиентите. Дори един демон може да обслужва много клиенти, но в даден момент може да обработи една заявка, останалите ще бъдат поставени на опашка.
Друга важна разлика между RPC услугите и обикновените мрежови услуги е, че те не използват предварително дефинирани UDP софтуерни портове. Вместо това се използва така наречената система за картографиране на портове. За да го поддържа, специален демон на portmap се инициализира, когато системата се зарежда. Като част от системата за превод на портове, на всяка RPC услуга се присвоява номер на програма, номер на версия, номер на процедура и протокол (UDP или TCP). Номерът на програмата уникално идентифицира конкретна RPC услуга. Връзката между имената на RPC услугите и номерата на програмите може да бъде проследена въз основа на съдържанието на файла /etc/rpc. Всяка RPC програма поддържа много процедури, които се идентифицират с техните номера на процедури. Номерата на процедурите могат да бъдат намерени в съответните заглавни файлове: например за услугата NFS те са посочени във файла /usr/include/nfs/nfs.h.
По-специално услугата NFS има номер на програма 100003 и включва процедури като „отвори файл“, „блок за четене“, „създайте файл“ и т.н. При извикване на отдалечени процедури номерът на програмата на услугата се предава заедно с аргументите на процедурата в RPC пакет, номер на процедура и номер на версия. Номерът на версията се използва за идентифициране на възможностите на услугата. Факт е, че разработчиците непрекъснато подобряват NFS услугата и всяка нова версия е напълно обратно съвместима с предишните.
Принципът на работа на преводача на portmap е доста прост. Когато която и да е RPC услуга се инициализира (по-специално по време на зареждане на операционната система), тя се регистрира с помощта на демона на portmap. Когато се стартира на сървър, RPC услугата търси незает софтуерен порт, запазва го за себе си и съобщава номера на порта на демона на portmap. За да комуникира със сървъра, RPC клиентът трябва първо да се свърже с portmap на сървъра и да го попита кой софтуерен порт е зает от определена RPC услуга на сървъра. Едва тогава клиентът може директно да се свърже със сервиза. В някои случаи клиентът комуникира с желаната услуга индиректно, тоест първо се свързва с демона на portmap, който изисква RPC услугата от името на клиента. За разлика от RPC услугите, транслаторът на portmap на port винаги е обвързан с предварително дефиниран порт 111, така че клиентът комуникира с portmap по стандартния начин.
СЪСТАВ НА NFS V2
Като цяло, в допълнение към portmap, NFS сървърът включва демоните rpc.mountd, nfsd, rpc.lockd, rpc.statd. NFS клиентска машина, работеща на UNIX платформа, трябва да има работещи демони biod (по избор), rpc.lockd и rpc.statd.
Както бе споменато по-рано, UNIX поддържа NFS на ниво ядро, така че не всички демони са необходими, но те могат значително да подобрят производителността на файловите операции и да позволят заключване на запис на файлове.
Демонът rpc.mountd обработва клиентски заявки за монтиране на файлови системи. Услугата за монтиране е внедрена като отделен демон, тъй като протоколът за монтиране не е част от NFS. Това е така, защото операцията по монтиране е тясно свързана със синтаксиса за именуване на файлове и принципите за именуване на файлове са различни между UNIX и, да речем, VMS.
Демонът nfsd приема и обслужва NFS RPC заявки. Обикновено, за да се подобри производителността, множество екземпляри на nfsd се изпълняват на сървъра.
Демонът rpc.lockd, работещ както на клиента, така и на сървъра, е проектиран да заключва файлове, докато демонът rpc.statd (също работещ на сървъра и клиента) поддържа статистика за заключванията, в случай че те трябва да бъдат автоматично възстановени, ако NFS услугата се срива.
Демонът biod, работещ на клиента, е способен на операции за предварително четене и мързелив запис, което значително подобрява производителността. Наличието на биод обаче не е необходимо за работа на клиента. За допълнително подобряване на производителността, множество biod демони могат да бъдат заредени на клиентската машина.
Друг демон, работещ на сървъра, отговаря за услугите за удостоверяване и печат за клиенти на DOS/Windows; на някои системи се нарича pcnfsd, на други in.pcnfsd.
Освен това пакетът NFS включва различни системни помощни програми и диагностични програми (showmount, rpcinfo, exportfs, nfsstat).
ПРАВИЛА ЗА ИЗНОС
Файловите системи и директориите, които клиентите могат да монтират дистанционно на NFS сървъра, трябва да бъдат изрично посочени. Тази процедура се нарича "експортиране" на ресурси в NFS. В същото време NFS сървър, за разлика от, да речем, SMB сървър, не излъчва списък на своите експортирани ресурси. Клиентът обаче може да поиска такъв списък от сървъра. От страната на сървъра демонът rpc.mountd отговаря за обслужването на заявките за монтиране.
Експортирането на NFS файлови ресурси следва четири основни правила.
- Файловата система може да бъде експортирана като цяло или на части, като директории и файлове. Трябва да се помни, че най-голямата експортирана единица е файловата система. Ако на сървъра определена файлова система (/usr/bin) е монтирана в йерархията под друга файлова система (/usr), тогава експортирането на системата /usr няма да засегне системата /usr/bin.
- Могат да се експортират само локални файлови ресурси, с други думи, ако нечия друга файлова система е монтирана на сървъра, тоест разположена на друг сървър, тогава тя не може да бъде повторно експортирана.
- Не можете да експортирате поддиректории на вече експортирана файлова система, освен ако не са отделни файлови системи.
- Не можете да експортирате родителските директории на директория, която вече е била експортирана, освен ако родителската директория не е независима файлова система.
Всяко нарушение на тези правила ще доведе до грешка в работата на NFS.
Таблицата с експортирани ресурси се намира във файла /etc/exports. За съжаление, синтаксисът на този файл е специфичен за UNIX, така че ще използваме Solaris като пример. Файлът /etc/exports се състои от текстови редове във формат:
Някои от най-популярните опции са изброени в таблица 1. Всъщност опциите описват правата за достъп, които клиентите имат до експортираните ресурси. Важно е да запомните, че разрешенията, изброени по време на експортиране, по никакъв начин не отменят разрешенията, които се прилагат директно към файловата система. Например, ако файловата система е експортирана с възможност за запис и определен файл има атрибут само за четене, тогава няма да е възможно да го промените. Така при експортиране правата за достъп действат като допълнителен филтър. Освен това, ако, да речем, файлова система е експортирана с опцията ro (само за четене), тогава клиентът има право да я монтира с опцията rw (четене/запис), но опитът за запис ще доведе до съобщение за грешка.
Опцията за достъп ви позволява да посочите хостове с право да монтирате ресурс. Съответно, никой друг хост, освен споменатите в него, няма способността да монтира и следователно да извършва операции върху ресурса.
Списъкът с хостове, които могат да записват информация, се определя с помощта на опцията rw. Ако опцията rw не указва списък с хостове, тогава всеки хост има право да пише.
Опцията root ви позволява да посочите хостове, в които локалните root суперпотребители получават сървърни root права за експортирания ресурс. В противен случай, дори ако на хоста са дадени rw права, root потребителят на него е еквивалентен на потребител nobody (uid=-2), т.е. потребител с минимални права за достъп. Горното се отнася специално за правата за достъп до отдалечен ресурс и не засяга правата за достъп до локални клиентски ресурси.
Anon и сигурните опции ще бъдат обсъдени при описване на схемата за NFS удостоверяване.
ПРАВИЛА ЗА МОНТАЖ
Ако за сървъра експортираните ресурси могат да действат като файлова система или отделна директория, тогава за клиента те винаги изглеждат като файлови системи. Тъй като поддръжката на NFS е вградена в ядрото на UNIX, операцията по монтиране на NFS файлови системи се извършва от стандартната помощна програма за монтиране (не е необходим отделен демон за монтиране на NFS) и трябва само да посочите, че монтираната файлова система е NFS. Друг начин за монтиране е използването на файла /etc/fstab (/etc/filesystems в някои версии на UNIX). IN в такъв случайотдалечените NFS системи (също като локалните) се монтират на етапа на зареждане на ОС. Точките на монтиране могат да бъдат всякакви, включително като част от други NFS файлови системи, т.е. NFS системите могат да бъдат „нанизани“ една върху друга.
Основните опции за монтиране на NFS са изброени в таблица 2.
Опцията bg ви позволява да монтирате във фонов режим, като в този случай можете да стартирате други команди за монтиране.
Двойката твърди/меки опции изглежда много интересна. При "твърдо" монтиране клиентът ще се опита да монтира файловата система на всяка цена. Ако сървърът не работи, това ще доведе до блокиране на цялата NFS услуга: процесите, осъществяващи достъп до файловата система, ще преминат в състояние на изчакване за завършване на RPC заявките. От гледна точка на потребителските процеси, файловата система ще изглежда като много бавен локален диск. Когато сървърът се върне в работно състояние, услугата NFS ще продължи да функционира, сякаш нищо не се е случило. Използването на опцията intr ви позволява да използвате системен сигнал INTERRUPT прекъсва процеса на твърдо монтиране.
По време на меко монтиране NFS клиентът ще направи няколко опита да се свърже със сървъра, както е посочено от опциите retans и timeo (някои системи поддържат и специална опция за повторен опит). Ако сървърът не отговори, системата показва съобщение за грешка и спира опитите за монтиране. От гледна точка на логиката на файловите операции, когато сървърът се повреди, „мекото“ монтиране емулира повреда на локален диск. Ако опцията retrans (повторен опит) не е зададена, броят на повторните опити е ограничен до стойността по подразбиране за дадената UNIX система. Опциите retrans и timeo се прилагат не само за монтиране, но и за всички RPC операции, извършвани на файловата система NFS. Тоест, ако клиентът извърши операция за запис и в този момент има повреда в мрежата или на сървъра, клиентът ще се опита да повтори заявките.
На въпроса кой режим, „мек“ или „твърд“, е по-добър, не може да се отговори недвусмислено. Ако данните на сървъра трябва да са последователни, когато той временно се повреди, тогава е за предпочитане „твърдо“ монтиране. Този режим също е незаменим в случаите, когато монтираните файлови системи съдържат програми и файлове, които са жизненоважни за работата на клиента, особено за бездискови машини. В други случаи, особено когато става въпрос за системи само за четене, режимът на меко монтиране изглежда за предпочитане.
УДОСТОВЕРЯВАНЕ И СИГУРНОСТ
Както беше отбелязано, всеки RPC пакет е самостоятелен. Освен това, като цяло, NFS не осигурява държавност, т.е. не следи какви заявки клиентите са направили преди това, нито проследява производителността на клиента. Следователно в системи, които използват отдалечени извиквания на процедури, проблемът със сигурността се оказва изключително актуален.
В NFS удостоверяването се извършва изключително на етапа на монтиране на файловата система и само въз основа на името на домейна (или IP адреса) на клиентската машина. Тоест, ако NFS клиент (тук имаме предвид компютър, а не потребител на компютър) се свърже със сървъра с искане за монтиране, сървърът определя правата за достъп, използвайки таблицата /etc/exports, и клиентът се идентифицира с името (IP адрес) на компютъра. Ако на клиента е разрешено да извършва определени операции върху експортирания ресурс, тогава му се казва определено „магическо число“ (магическа бисквитка). В бъдеще клиентът трябва да включва този номер във всяка RPC заявка, за да докаже своите пълномощия.
Това всъщност е целият прост набор от инструменти за удостоверяване на клиента; потребителите не се удостоверяват по никакъв начин. Всяка RPC заявка обаче съдържа uid на потребителя, който е инициирал заявката, и списък с групови идентификатори, gid, към които принадлежи потребителят. Но тези идентификатори не се използват за удостоверяване, а за определяне на правата за достъп на конкретен потребител до файлове и директории.
Моля, обърнете внимание, че uid и gid се определят от страната на клиента, а не от страната на сървъра. Следователно администраторите са изправени пред проблема с координирането на съдържанието на /etc/passwd (и /etc/group) между клиенти и NFS сървъри, така че потребителят Vasya на сървъра да не получава правата на потребител Petya. За големи мрежи това създава сериозни затруднения. Можете да осигурите последователност на потребителската база данни, както и на системните файлове като /etc/hosts, /etc/rpc, /etc/services, /etc/protocols, /etc/aliases и т.н., като използвате мрежа информационно обслужване(Network Information System, NIS), разработена от Sun през 1985 г. и включена в повечето версии на UNIX (нейната по-разширена версия NIS+ не се използва широко). NIS е информационна услуга, донякъде напомняща на директорийната услуга на Windows NT, която ви позволява централно да съхранявате и обработвате системни файлове. Между другото, NIS е изграден на същия принцип като NFS, по-специално използва протоколите RPC и XDR.
Друга важна характеристика на NFS е, че всяка RPC заявка носи списък на gid групите на потребителя. За да ограничат размера на RFC пакета, повечето реализации на NFS ограничават броя на групите до 8 или 16 групи. Ако даден потребител е член на повече групи, това може да доведе до грешки при определяне на разрешенията на сървъра. Този проблем е много важен за корпоративните файлови сървъри. Радикално решение е да се използват ACL, но, за съжаление, не всички разновидности на UNIX ги поддържат.
Системата за удостоверяване, приета от NFS, е много лоша и не осигурява надеждна защита. Всеки, който се е сблъсквал с NFS, знае колко лесно е да се заобиколи сигурността му. За да направите това, дори не е необходимо да използвате методи за подправяне на IP адреси (IP-spoofing) или имена (DNS-spoofing). Нападателят просто трябва да прихване „магическото число“ и в бъдеще може да извършва действия от името на клиента. В допълнение, "магическото число" не се променя до следващото рестартиране на сървъра.
На множество интернет сървъри можете да намерите други, включително много екзотични, методи за хакване на NFS. Броят на откритите „дупки“ е хиляди. Поради това NFS v.2 се препоръчва да се използва само в защитени мрежи.
Въз основа на тези съображения Sun разработи протокола SecureRPC, използвайки както асиметрични, така и симетрични ключове за криптиране. В този случай криптографските методи се използват за удостоверяване не само на хостове, но и на потребители. Самите данни обаче не са криптирани. За съжаление, поради ограниченията на правителството на САЩ за износ, не всички UNIX се доставят с поддръжка на SecureRPC. Затова няма да се спираме на възможностите на този протокол. Въпреки това, ако вашата версия на UNIX поддържа SecureRPC, тогава книгата на Hal Stein "Managing NFS and NIS", публикувана от O'Reilly & Associates, ще предостави безценна помощ при настройката.
Друг проблем е с NFS клиенти на MS-DOS и Windows 3.x/9x платформи. Тези системи са за един потребител и не е възможно да се идентифицира потребителят с помощта на нормални NFS инструменти. За целите на идентифицирането на потребителите на DOS/Windows на сървъра се стартира демонът pcnfsd. При свързване (монтиране) на NFS дискове на клиентската машина, той изисква потребителско име и парола, което позволява не само идентификация, но и удостоверяване на потребителите.
Въпреки че Windows NT е многопотребителска операционна система, нейната потребителска база данни и схема за идентификация на потребителите са несъвместими с тези на UNIX. Следователно NFS клиентските сайтове, базирани на Windows NT, също са принудени да използват възможностите на pcnfsd.
В допълнение към удостоверяването на потребителя, pcnfs позволява печат на UNIX от клиентски сайтове на DOS/Windows. Вярно е, че първоначално Windows NT включва програмата LPR.EXE, която също позволява печат на UNIX сървъри.
За да получите достъп до файловата услуга и NFS услугата на DOS/Windows машини, трябва да инсталирате специален клиентски софтуер, а цените за тези продукти са доста високи.
Нека се върнем обаче към опциите за експортиране на NFS файлове (вижте Таблица 1). Опцията anon дефинира uid на потребителския идентификатор в случай, когато потребителят на DOS/Windows не може да се удостовери (зададе неправилна парола) или когато потребителят на хоста, свързан чрез SecureRPC, не успя да се удостовери. По подразбиране anon има uid=-2.
Сигурната опция се използва, когато се използва протоколът SecureRPC.
АРХИТЕКТУРНИ ХАРАКТЕРИСТИКИ НА NFS V2
NFS файловите системи трябва да отговарят на две условия (между другото, същите изисквания се прилагат не само за NFS, но и за други мрежови файлови системи).
- От гледна точка на клиентските потребителски програми файловата система NFS се намира като на локален диск. Програмите нямат начин да разграничат NFS файловете от обикновените файлове.
- NFS клиентът не може да определи коя платформа се използва като сървър. Това може да е UNIX, MVS или дори Windows NT. Разликите в сървърната архитектура засягат само конкретни операции, но не и NFS възможности. За клиента файлова структура NFS е подобна на локалната система.
Първото ниво на прозрачност се постига чрез използването на виртуалната файлова система (VFS) от UNIX. VFS е отговорен за взаимодействието не само с NFS, но и с локални системи като UFS, ext2, VxFS и др.
Второто ниво на прозрачност се осигурява чрез използването на така наречените виртуални възли (vnodes), чиято структура може да бъде съпоставена с inodes във файловите системи на UNIX.
Операциите на NFS файлови системи са VFS операции, докато взаимодействията с отделни файлове и директории се определят от vnode операции. RPC протоколът от NFS v2 описва 16 процедури, свързани с операции не само върху файлове и директории, но и върху техните атрибути. Важно е да се разбере, че RPC повикванията и интерфейсът vnode са различни концепции. vnode интерфейсите дефинират OS услуги за достъп до файлови системи, независимо дали са локални или отдалечени. RPC от NFS е специфична реализация на един от vnode интерфейсите.
Операциите за четене/запис се кешират от страна на клиента, т.е. клиентът кешира съдържанието на файлове и директории. Обикновено размерът на NFS кеш буфера е 8 KB. Ако biod демоните се изпълняват на клиента, тогава четенето се извършва предварително, а записът се извършва в мързелив режим. Например, ако потребителски процес запише информация, данните се натрупват в кеш буфер и едва след това се изпращат, обикновено в един RPC пакет. Когато се извърши операция по запис, ядрото незабавно връща контрола на процеса и функциите за пренасочване на RPC заявки се прехвърлят към biod. Ако biod демоните не работят и ядрото не поддържа многонишкова RPC обработка, тогава ядрото трябва да обработва препращането на RPC пакети в еднонишков режим и потребителският процес преминава в състояние на изчакване на края на препращане. Но в този случай все още се използва NFS кеша.
В допълнение към съдържанието на NFS файлове и директории, атрибутите на файловете и директориите се кешират от страна на клиента и кешът на атрибутите се актуализира периодично (обикновено на всеки няколко секунди). Това се дължи на факта, че стойността на атрибутите може да се използва за преценка на състоянието на файл или директория. Нека обясним този подход с пример. Когато потребител чете файл, съдържанието на файла се поставя в NFS кеша, но атрибутите на файла (време на създаване/актуализация, размер и т.н.) също се поставят в кеша на атрибутите. Ако в този момент друг клиент пише в същия файл, това може да доведе до несъответствие на съдържанието в кеш паметта на различни клиенти. Въпреки това, тъй като кешът на атрибутите на първия клиент се актуализира на всеки няколко секунди, той може да определи, че атрибутите са се променили (в този случай времето, когато файлът е актуализиран), така че клиентът трябва да извърши операция за актуализиране на кеша на съдържанието на файла (тази операция се извършва автоматично).
За да обслужват клиентски заявки, nfsd демоните трябва да работят на сървъра. В този случай демоните кешират информацията при четене от сървърни дискове. Всички демони обслужват една и съща опашка от клиентски заявки, което позволява оптимално използване на ресурсите на процесора.
За съжаление, определянето на оптималния брой biod и nfsd демони е много трудно. От една страна, колкото по-голям е броят на работещите демони, толкова по-голям е броят на заявките, които могат да бъдат обработени едновременно; от друга страна, увеличаването на броя на демоните може да повлияе неблагоприятно на производителността на системата поради увеличените разходи за превключване на процеси. Фината настройка на NFS е много досадна процедура и изисква вземане под внимание не само на броя на клиентите и потребителските процеси, но и на такива характеристики като време за превключване между контексти на процеси (т.е. характеристики на архитектурата на процесора), размер на RAM, натоварване на системата и т.н. По-добре е да се определят такива настройки експериментално, въпреки че в повечето случаи стандартните ще свършат работа (обикновено 8 nfsd демона се изпълняват на сървъра и 4 biod демона се изпълняват на клиентите).
| Фигура 2. Операция за запис в NFS v2. |
Много важна характеристика NFS v2 е, че операциите за запис не се кешират от страната на сървъра (вижте Фигура 2). Това беше направено, за да се гарантира висока надеждност на услугата NFS и ви позволява да гарантирате целостта на данните след рестартиране на сървъра в случай на повреда на сървъра. Липсата на кеширане на информация при писане е най-голяма голям проблем NFS v2. В операциите за запис NFS е значително по-нисък от конкурентните технологии, въпреки че при операциите за четене губи малко от тях. Единственият метод за борба с ниската производителност на запис е използването на дискови подсистеми с независим от захранването вграден кеш, както в доста скъпите RAID масиви.
Когато работи в разпределени и глобални мрежи, NFS v2 има друг недостатък поради избора на UDP като транспортен протокол за услугата. Както знаете, UDP не гарантира доставката на пакети; освен това редът, в който се получават пакетите, може да не съответства на реда, в който се изпращат.
Това може да доведе до следните две неприятни последствия: загуба на пакет и дълго забавяне на обработката му. Представете си, че клиент извършва операция за четене на голям файл. В този случай сървърът трябва да изпрати няколко пакета, за да запълни кеш буфера на клиента. Ако един от пакетите бъде загубен, клиентът ще бъде принуден да повтори заявката отново, а сървърът ще бъде принуден да генерира отговори и т.н.
Ситуацията със забавяне на обработката на RPC заявки поради, да речем, голямо натоварване на сървъра или мрежови проблеми също е доста неприятна. Ако определеното времево ограничение бъде надвишено, клиентът ще приеме, че пакетът е загубен и ще се опита да повтори заявката. За много NFS операции това не е проблем, тъй като дори операцията за запис може да бъде повторена от сървъра. Но какво да кажем за операции като "премахване на директория" или "преименуване на файл"? За щастие, повечето реализации на NFS поддържат сървърно кеширане на дублирани заявки. Ако сървърът получи повтаряща се заявка за операция в рамките на кратък период от време, тогава такава заявка се игнорира.
Системата RPC не проследява състоянието на връзката, което създава проблеми, когато множество клиенти имат достъп до един и същ файл едновременно. Тук има две трудности:
- как да заключите файл, по-специално когато пишете в него;
- Как да гарантираме целостта на ключалките в случай на срив и рестартиране на NFS сървъра или клиента?
За да направи това, NFS използва два специални демона: rpc.lockd е отговорен за заключването на файлове, а rpc.statd е отговорен за наблюдение на състоянието на ключалките (вижте Фигура 3). Тези демони работят както на клиента, така и на сървъра. На демоните rpc.lockd и rpc.statd са присвоени две специални директории (sm и sm.bak), където се съхранява информацията за заключване.
Уникална и доста удобна допълнителна услуга, automounter, ви позволява автоматично да монтирате файлови системи, когато потребителските процеси имат достъп до тях. Впоследствие automounter периодично (веднъж на всеки пет минути по подразбиране) се опитва да демонтира системата. Ако е зает (например файл е отворен), тогава услугата продължава да работи нормален режим. Ако вече няма достъп до файловата система, тя автоматично се демонтира. Функцията за автоматично монтиране се изпълнява от няколко програми, като amd и autofs са особено популярни сред тях.
NFS V3 ХАРАКТЕРИСТИКИ
Третата версия на NFS е напълно обратно съвместима с втората версия, т.е. NFS v3 сървърът „разбира“ NFS v2 и NFS v3 клиенти. По същия начин NFS v3 клиент може да има достъп до NFS v2 сървър.
Важна иновация в NFS v3 е поддръжката на транспортния протокол TCP. UDP е страхотен за локални мрежи, но не е подходящ за бавни и не винаги надеждни глобални комуникационни линии. В NFS v3 целият клиентски трафик се мултиплексира в една TCP връзка.
В NFS v3 размерът на кеш буфера е увеличен до 64 KB, което има благоприятен ефект върху производителността, особено в светлината на активното използване на високоскоростни мрежови технологии Fast Ethernet, Gigabit Ethernet и ATM. В допълнение, NFS v3 ви позволява да съхранявате информация, кеширана на клиента, не само в RAM, но и на локалния диск на клиента (честно казано, заслужава да се отбележи, че някои реализации на NFS v2 също предоставят тази функция). Тази технология е известна като CacheFS.
| Фигура 4. Операция за запис в NFS v3. |
Но може би още по-важно нововъведение на NFS v3 може да се счита за радикално увеличаване на производителността при операции за запис. Сега кеширането на записаната информация се извършва и от страна на сървъра, докато регистрацията и потвърждението на факта на записване на данни на диск се извършва с помощта на специална заявка за ангажиране (вижте Фигура 4). Тази технология се нарича защитен асинхронен запис. След като данните бъдат изпратени до кеша на сървъра, клиентът му изпраща заявка за ангажиране, която инициира операция за запис на диска на сървъра. На свой ред, след запис на информация на диска, сървърът изпраща на клиента потвърждение за успешното му завършване.
Новото в NFS v3 е поддръжка за 64-битови файлови системи и подобрена поддръжка за ACL.
Що се отнася до бъдещето, Sun сега насърчава технологията WebNFS, чието използване позволява достъп до файлови системи от всеки уеб браузър или чрез приложения, написани на Java. Няма нужда да инсталирате клиентски софтуер. WebNFS (според Sun) осигурява увеличение на производителността от три до пет пъти спрямо ftp или HTTP.
ЗАКЛЮЧЕНИЕ
Познавайки принципите на работа на NFS протоколите, администраторът може оптимално да конфигурира услугата. Мрежовата файлова система NFS е идеална за UNIX мрежи, тъй като идва с почти всички версии на тази операционна система. Освен това поддръжката на NFS е внедрена на ниво ядро на UNIX. Тъй като Linux започва постепенно да наддава на ниво настолни компютри, тогава NFS има шанс да получи признание и тук. За съжаление използването на NFS на клиентски компютри с Windows създава определени проблеми, свързани с необходимостта от инсталиране на специализиран и доста скъп клиентски софтуер. В такива мрежи използването на услугата SMB, по-специално софтуера Samba, изглежда по-предпочитано. Ние обаче ще се върнем към SMB продуктите за UNIX в един от предстоящите LAN издания.
В този момент трябва да имате работеща TCP/IP връзка към вашата мрежа. Трябва да можете да пингвате други компютри в мрежата и, ако сте конфигурирали правилно шлюза, трябва също да можете да пингвате компютри в Интернет. Както знаете, основната цел на свързването на компютър към мрежа е получаването на достъп до информация. Докато някои хора могат да свържат компютър към мрежа само защото, повечето хора биха искали да споделят и имат достъп до файлове и принтери. Те биха искали да имат достъп до документи в Интернет или да играят онлайн игри. Инсталиран във вашия нова система Slackware TCP/IP поддръжка и необходимия софтуер, вие ще получите всичко; въпреки това, чрез инсталиране само на TCP/IP поддръжка, функционалността ще бъде много ограничена. За да предоставяме и споделяме файлове, ще трябва да ги прехвърляме напред-назад чрез FTP или SCP. Не можем да видим файловото дърво на нашия нов компютър със Slackware чрез иконите „Network Neighborhood“ или „Whole Network“ от компютри с Windows. Бихме искали да можем да имаме постоянен достъп до файлове на други Unix машини.
В идеалния случай бихме искали да използваме мрежова файлова система, което ни позволява да имаме прозрачен достъп до файловете на компютрите. Програмите, които използваме за работа с информация, съхранявана на компютри, всъщност дори не трябва да знаят на кой компютър се съхранява необходимият файл. Те трябва само да знаят, че файлът съществува и начин да го получат. Останалото е задача на операционната система, която осигурява достъп до този файл, използвайки наличните локални и мрежови файлови системи. Двете най-често използвани мрежови файлови системи са SMB (имплементирана чрез Samba) и NFS.
5.6.1. SMB/Samba/CIFS
SMB (Server Message Block) е потомък на по-стария NetBIOS протокол, първоначално разработен от IBM за техния продукт LAN Manager. компания Microsoftна свой ред винаги съм се интересувал от NetBIOS и неговите наследници (NetBEUI, SMB и CIFS). Проектът Samba започва през 1991 г., когато е написан за осигуряване на комуникация между IBM PC и Unix сървър. Днес споделянето на файлове и услуги за печат през SMB мрежа е предпочитаният метод за почти целия цивилизован свят, тъй като Windows го поддържа.
Конфигурационният файл на Samba /etc/samba/smb.conf е един от най-добре документираните конфигурационни файлове, които ще намерите. На ваше разположение са готови примери с настройки за споделени ресурси, така че можете да ги преглеждате и променяте според нуждите си. Ако искате още повече контрол, страницата с ръководство на smb.conf е на ваше разположение. Тъй като Samba има толкова добра документация, няма да я пренаписваме тук. Нека обаче бързо да преминем през основните моменти.
smb.conf е разделен на няколко секции: една секция на споделяне, плюс една глобална секция за конфигуриране на параметри, които се използват навсякъде. Някои параметри са валидни само в глобалната секция, а някои са валидни само извън нея. Не забравяйте, че глобална секция може да бъде заменена от всяка друга секция. Моля, вижте страниците с ръководство за повече информация.
Най-вероятно ще искате да редактирате вашия smb.conf файл, за да отразява настройките на вашата локална мрежа. Съветваме ви да промените следните точки:
Това ще бъде описанието на вашия Slackware компютър, показано в папката My Network Places (или Entire Network).
Почти сигурно ще искате да използвате потребителското ниво на защита на вашата Slackware система.
Ако криптирането на парола не е активирано, няма да можете да използвате Samba със системи NT4.0, Win2k, WinXP и Win2003. За предишни версии на операционни системи Windows, за предоставяне на достъп до споделени ресурсине е необходимо криптиране.
SMB е удостоверен протокол, т.е. можете да предоставите потребителско име и парола, за да се възползвате от тази услуга. Казваме на samba сървъра, че потребителските имена и паролите са правилни, като използваме командата smbpasswd. smbpasswd позволява добавянето на публични ключове като обикновени потребители, и потребителски машини (SMB изисква да добавите NETBIOS имената на компютрите като потребителски машини, като по този начин ограничавате броя на компютрите, от които може да се извърши удостоверяване).
Важно е да се отбележи, че даденото потребителско име или име на машина трябва вече да съществува във файла /etc/passwd. Можете да постигнете това с помощта на командата adduser. Имайте предвид, че когато използвате командата adduser за добавяне на име на компютър, трябва да го добавите със знака за долар („$“). Това обаче Нетрябва да се направи, когато работите с smbpasswd. Помощната програма smbpasswd сама добавя знака за долар. Нарушаването на това правило с помощта на adduser ще доведе до грешка при добавяне на името на машината към samba.
|
#adduser машина$ |
5.6.2. Мрежова файлова система (NFS)
NFS (Network File System) първоначално е написана от Sun за Solaris - тяхната реализация Unix системи. И въпреки че е много по-лесно да се настрои и конфигурира в сравнение с SMB, NFS е много по-малко защитен. Основен слаба точкасигурността е лесното заместване на потребителски и групови идентификатори на една машина с идентификатори от друга машина. NFS протоколът не прилага удостоверяване. Беше заявено, че бъдещите версии на NFS протокола ще подобрят сигурността, но към момента на писане това все още не е направено.
NFS се конфигурира чрез файла /etc/exports. Когато заредите стандартния файл /etc/exports в редактора, ще видите празен файлс коментар най-отгоре на два реда. Ще трябва да добавим ред към файла за експортиране за всяка от директориите, които искаме да експортираме, изброявайки клиентските работни станции, на които ще бъде разрешен достъп до тази директория. Например, ако трябва да експортираме директорията /home/foo за работната станция на Bar, ще трябва да добавим следния ред към нашия файл /etc/exports:
Както можете да видите, има няколко различни опции, но повечето от тях трябва да са ясни от този пример.
NFS вярва в това определен потребителот една от машините в мрежата има същия идентификатор на всички други машини. Когато NFS клиент се опита да чете или пише на NFS сървър, UID се изпраща като част от заявката за четене/запис. Този UID се счита за същия, както ако заявката е направена с локална машина. Както можете да видите, ако някой може произволно да посочи даден UID при достъп до ресурси на отдалечена машина, проблеми могат да се случат и се случват. Средство за частично избягване на това е монтирането на всички директории с опцията root_squash. Това заменя UID на всеки потребител, който твърди, че е root, с различен UID, като по този начин предотвратява root достъп до файлове и директории в експортираната директория. Изглежда, че root_squash е активиран по подразбиране от съображения за сигурност, но авторите все пак препоръчват изрично да го посочите във вашия файл /etc/exports.
Можете също така да експортирате директория на сървъра директно от командния ред, като използвате командата exportfs, както е показано по-долу:
|
# exportfs -o rw,no_root_squash Bar:/home/foo |
Тази команда експортира директорията /home/foo за компютъра „Bar“ и му дава достъп за четене/запис. В допълнение, NFS сървърът няма активиран параметър root_squash, което означава, че всеки потребител на Bar с UID „0“ (UID root) ще има същите привилегии на сървъра като root. Синтаксисът изглежда доста странен (обикновено, когато посочите директория във формата компютър:/директория/файл, препращате към файл в директория на посочения компютър).
Можете да намерите повече информация за файла за експортиране в страницата на ръководството.
