- редовно архивиране на всички данни: не е реалистично да се извърши тази операция за няколко десетки или стотици компютри, но е напълно възможно - от един сървър или няколко сървъра.
- повишаване на надеждността на съхранението на данни: неразумно е всеки компютър в мрежата да се оборудва с RAID масив, тъй като по-голямата част от файловете в компютъра, като например инсталираните софтуерни пакети, са по-лесни за преинсталиране, отколкото да се защитят от повреда; но би било съвсем разумно да се оборудва файловия сървър с хардуерен RAID-масив или да се организира софтуерен RAID-масив там, поне просто дублиране на диска.
- Намаляване на разходите за съхранение: Скъпо и неефективно е да инсталирате огромен диск във всеки компютър, в случай че трябва да съхранявате много данни, но е напълно възможно да инсталирате мащабируема дискова подсистема с голям обем на сървъра.
- осигуряване на достъп до същите данни от всеки компютър.
Описание на NFS
Услугата NFS позволява на сървъра да предоставя споделен достъп до определени директории на своя локален файлова системаи клиентът трябва да монтира тези директории точно така, сякаш са локални директории на клиента.
NFS версии
NFS, разработен от Sun Microsystems, е толкова успешен, че внедряванията са били внедрени от различни компании в почти всички операционни системи. Има няколко фундаментално различни реализации на NFS. NFS 2.0 е доста често срещан, въпреки че NFS 3.0 е въведен в Solaris 2.5. Следващите издания на Solaris, включително Solaris 9, направиха значителни подобрения в NFS, но самият протокол остана съвместим с реализациите на NFS 3.0 в други системи. Започвайки с NFS 3.0, TCP и UDP предаването на пакети се поддържа, преди се поддържаше само UDP.
Бъди внимателен! Използвайте същата версия на NFS клиенти и сървъри в мрежата. NFS 2.0 може да се намери на по-стари системи като HP-UX 10.0. Сътрудничеството между системи, използващи различни версии на NFS, не е желателно.
Съвместимост на NFS и други услуги за споделени директории
NFS е подобен по смисъл и организация на работа на споделени директории(споделени папки) в Windows системи, но тези услуги използват напълно различни операционни протоколи и не са съвместими една с друга. Въпреки това, има няколко софтуерни продукта, които инсталират поддръжка на NFS на Windows системи, така че използването на NFS в мрежа с различни операционни системи не е проблем, просто не забравяйте да използвате една и съща версия на NFS.
NFS е модел клиент-сървър, при който различни програми се изпълняват на клиентски компютри и сървърни компютри, за да осигурят достъп до споделени директории на сървъра.
Тъй като компютрите на работните места на служителите в Русия обикновено се контролират от Windows системи, Windows системите също често се използват като файлови сървъри. Често обаче има желание да се инсталира UNIX на файлов сървър, за да се подобри надеждността, да се намалят разходите за хардуер или да се използва същият сървър за редица други корпоративни нужди: като уеб сървър, сървър на база данни и т.н. За да не инсталирате допълнителен софтуер за поддръжка на NFS, в този случай е достатъчно да инсталирате пакета samba на UNIX машина. Това ще й позволи да се „преструва“ на Windows сървър, така че всички клиентски компютри да го възприемат като най-често срещания файлов сървър или сървър за печат в мрежа на Windows. Пакетът samba осигурява поддръжка за SMB протокола, който е роден за Windows.
В случаите, когато няколко UNIX компютъра работят в мрежата и те трябва да имат достъп до един и същ файлов сървър, има смисъл да използвате механизма NFS (мрежова файлова система).
NFS не е много устойчив на прекъсвания в мрежата, изисква непрекъсната работа и предполага бързи връзки между клиента и сървъра. Използването на NFS за монтиране на файлови системи извън локалната мрежа, например през интернет, е технически осъществимо, но не е много рационално и несигурно.
NFS терминология
След настройка на NFS сървъра, UNIX компютърът ще предостави на външни потребители достъп до някои от неговите директории. файлова система... Това предоставяне на достъп се нарича "експортиране": казва се, че системата експортира своите каталози. Как точно се експортират директориите се определя от списък, зададен от системния администратор. В повечето UNIX системи този списък е във файла / etc / за експортиране, но на Solaris е в друг файл, / etc / dfs / dfstab.
NFS работи чрез механизма за отдалечено извикване на процедури ( RPC - отдалечено повикване на процедура).
Какво е RPC
Идеологията на RPC е много проста и привлекателна за програмиста. Как обикновено работи мрежово приложение? Той следва определен протокол (например HTTP): генерира пакет със заявка, извиква системната функция за установяване на връзка, след това функцията за изпращане на пакета, след това изчаква пакет с отговор и извиква функцията за затваряне на Връзка. Това означава, че цялата работа с мрежата е грижа на програмиста, който пише приложението: той трябва да помни за извикването на функциите на мрежовия API на системата, да мисли какво да прави в случай на мрежови повреди.
RPC предполага различен начин за обмен на данни между клиент и сървър. От гледна точка на програмиста, RPC клиентско приложение извиква функция на сървъра, тя изпълнява и връща резултата. Препращането на заявка за изпълнение на функция през мрежата и връщането на резултати от сървъра към клиента е невидимо за приложението, така че последното не трябва да се тревожи за мрежови сривове или подробности за реализацията на транспортния протокол.
За да се гарантира прозрачността на преноса на данни през мрежата, е разработена процедура в две стъпки. На сървъра всяко приложение, което предоставя услугата си чрез RPC, трябва да се регистрира с програма, наречена портов картограф. Функцията на тази програма е да установи съответствие между номера на RPC процедурата, която клиентът е поискал, и номера на TCP или UDP порта, на който сървърното приложение чака заявки. Най-общо казано, RPC може да работи с повече от TCP или UDP. Solaris реализира работа на базата на механизма TI (TransportIndependent), така че в Solaris преводачът на порта се нарича rpcbind, но не portmapкато Linux или FreeBSD.
Приложение, което се регистрира с преводач на портове, му казва номера на програмата, номера на версията и номерата на процедурите, които могат да бъдат обработени от програмата. Тези процедури впоследствие ще бъдат извикани от клиента по номер. В допълнение, приложението отчита номерата на TCP и UDP портовете, които ще бъдат използвани за получаване на заявки за изпълнение на процедури.
Клиент, който желае да извика изпълнението на процедура на сървъра, първо изпраща заявка до преводача на портове на сървъра, за да разбере към кой TCP или UDP порт да изпрати заявката. Преводачът на портове стартира при стартиране на системата и винаги работи на стандартния порт 111. След като получи отговор от него, клиентът изпраща заявка до порта, който съответства на изискваното приложение. Например, NFS сървър работи на порт 2049.
Как да монтирате споделена директория чрез NFS
Преди да преминем към описанието на настройките за NFS сървъра и клиентите, е необходимо да разберем как по принцип се монтират отдалечени файлови системи.
NFS клиентът изпраща заявка за монтиране към отдалечения компютър, който предоставя своята файлова система(обикновено част от него) за обща употреба. Казва се, че NFS сървърът "експортира" тази или онази директория (което означава - с поддиректории). Заявка на клиента
Глава 29 NFS: Мрежова файлова система
Въведение
В тази глава ще разгледаме мрежовата файлова система (NFS), популярно приложение, което предоставя на клиентските приложения прозрачен достъп до файлове. Крайъгълният камък на NFS е Sun RPC: Remote Procedure Call, който ще опишем първо.
Клиентската програма не изисква никакви специални инструменти, за да се възползва от NFS. Ядрото открива, че файлът е на NFS сървъра и автоматично генерира RPC повикване за достъп до файла.
Няма да навлизаме в подробности как се реализира достъпът до файлове, а по-скоро ще разгледаме как се използват интернет протоколите, особено UDP.
Повикване за дистанционно процедура Sun
В повечето случаи проблемите с мрежовото програмиране се постигат чрез писане на приложни програми, които извикват функции, предоставени от системата, за извършване на специфични мрежови операции. Например, една функция извършва активно отваряне на TCP, друга пасивно отваряне на TCP, трета изпраща данни през TCP връзка, четвърта задава специфични опции за протокол (включва таймер за поддържане на TCP) и т.н. В раздела „Интерфейси за програмиране на приложения“ на Глава 1 споменахме, че има два популярни набора от функции за мрежово програмиране (API), сокети и TLI. API, използван от клиента, и API, използван от сървъра, може да се различават, както и операционните системи, които работят между клиента и сървъра. Комуникационните и приложните протоколи са тези, които определят дали даден клиент може да комуникира със сървъра. Unix клиент, написан на C, използващ сокети като програмен интерфейс и TCP като комуникационен протокол, може да комуникира с мейнфрейм сървър, написан на COBOL, използвайки други API и TCP, ако и двата хоста са свързани към мрежата и и двата имат TCP реализации. / IP.
Обикновено клиентът изпраща команди до сървъра, а сървърът изпраща отговори до клиента. Всички приложения, които прегледахме - Ping, Traceroute, демони за маршрутизиране, DNS клиенти и сървъри, TFTP, BOOTP, SNMP, Telnet, FTP, SMTP - са изградени по този начин.
RPC, Remote Procedure Call, използва различен подход към мрежовото програмиране. Клиентската програма просто извиква функции в сървърната програма. Това се решава от гледна точка на програмиста, но в действителност се извършва следната последователност от действия.
- Когато клиентът извика отдалечената процедура, се извиква функцията на локалния хост, която се генерира от пакета RPC. Тази функция се нарича клиентско мъниче. client stub обвива аргументите на процедурата в мрежово съобщение и изпраща съобщението до сървъра.
- заглушка на сървъра на хоста на сървъра получава мрежово съобщение. Аргументите се извличат от мрежовото съобщение и се извършва извикване към сървърна процедура, написана от програмист на приложения.
- Сървърната функция връща контрола към сървърното мъниче, което от своя страна приема получените стойности, пакетира ги в мрежово съобщение и изпраща съобщението обратно до клиентското мъниче.
- клиентското мъниче връща стойности от мрежовото съобщение към клиентското приложение.
Мрежовото програмиране, използващо модули и RPC библиотечни рутинни програми, използва API (сокети или TLI), но потребителските приложения (клиентска програма и сървърни рутинни извикани от клиента) никога не имат достъп до API. Клиентското приложение трябва само да извика сървърната процедура, като всички детайли за внедряването са скрити от RPC пакета, клиентското мъниче и сървърното мъниче.
RPC пакетите имат следните предимства.
- Програмирането става по-лесно, защото не е нужно да решавате проблеми с мрежовото програмиране (а ако трябва, то доста). Приложните програмисти просто пишат клиентската програма и сървърните процедури, които клиентът извиква.
- Ако се използва ненадежден протокол като UDP, всички подробности, а именно изчакване и повторни предавания, се обработват от RPC пакета. Това от своя страна опростява потребителското приложение.
- RPC библиотеката обработва необходимото преобразуване на аргументи и върнати стойности. Например, ако аргументите се състоят от цели числа и числа с плаваща запетая, пакетът RPC ще обработва всякакви разлики между клиентското и сървърното представяне на цели числа и числа с плаваща запетая. Това улеснява внедряването на клиенти и сървъри за работа в хетерогенни среди.
RPC програмирането е подробно описано в глава 18. Двата най-популярни RPC пакета са Sun RPC и пакетът RPC в разпределената изчислителна среда (DCE) на Open Software Foundation (OSF). Ще разгледаме как се извършва извикване на процедура, как изглежда върнатото съобщение и как това се отнася до пакета Sun RPC, тъй като именно този пакет се използва от мрежовата файлова система. Sun RPC версия 2 е описана в RFC 1057 [Sun Microsystems 1988a].
Има два вкуса на Sun RPC. Една версия е изградена с помощта на API на сокета и работи с TCP и UDP. Другият се нарича TI-RPC (независим от транспорта) и е изграден с помощта на TLI API и работи с всички транспортни слоеве, предоставени от ядрото. От наша гледна точка няма разлика между двете, тъй като в тази глава обсъждаме само TCP и UDP.
Фигура 29.1 показва формата на съобщение за извикване на RPC процедура, използващо UDP.
Фигура 29.1 RPC съобщения за повикване във формат на UDP дейтаграма.
Стандартните IP и UDP заглавки са показани по-рано (Фигура 3.1 и Фигура 11.2). Всичко след UDP заглавката се определя от RPC пакета.
Идентификаторът на транзакцията (XID - идентификатор на транзакцията) се задава от клиента и се връща от сървъра. Когато клиентът получи отговор, той сравнява XID, върнат от сървъра, с XID на изпратената заявка. Ако не съвпадат, клиентът отхвърля съобщението и чака следващото да пристигне. Всеки път, когато клиент издава нов RPC, той променя XID. Въпреки това, ако клиентът препредаде RPC (ако не е получен отговор), XID не се променя.
Променливата повикване е 0 за повикването и 1 за отговора. Текущата RPC версия е 2. Следващите три променливи, номерът на програмата, номерът на версията и номерът на процедурата, идентифицират конкретната процедура, която да бъде извикана на сървъра.
Удостоверенията идентифицират клиента. В някои примери това поле е оставено празно, докато в други можете да намерите цифровия потребителски идентификатор и идентификатора на групата, към която той принадлежи. Сървърът може да разгледа идентификационните данни и да реши дали да обработи заявката или не. Verifier се използва за Secure RPC (Secure RPC), който използва DES криптиране. Въпреки че полетата за разрешение и валидиране са полета с променлива дължина, тяхната дължина се предава като част от полето.
Следват параметрите на процедурата. Техният формат зависи от това как приложението дефинира отдалечената процедура. Как приемникът (сървърът) знае размера на параметрите? Тъй като се използва UDP, размерът на параметрите може да бъде изчислен като размерът на UDP дейтаграмата минус дължината на всички полета до полето за проверка. Когато TCP се използва вместо UDP, няма концепция за фиксирана дължина, тъй като TCP е поток от байтове без разделители на записи. В този случай между TCP заглавката и XID се появява поле с дължина 4 байта, от което получателят знае дължината на RPC повикването в байтове. Това позволява да се изпрати съобщение за RPC повикване на множество TCP сегменти, ако е необходимо. (DNS използва подобна техника; упражнение 4 в глава 14.)
Фигура 29.2 показва формата на RPC отговора. Изпраща се от заглушката на сървъра към клиентската мъничка, когато отдалечената процедура излезе.
Фигура 29.2 Формат на съобщението за RPC отговор като UDP дейтаграма.
XID на повикването просто се копира в XID на отговора. Полето за отговор е 1, което прави разлика между предизвикателство и отговор. Полето за състояние е нула, ако съобщението за повикване е прието. (Съобщението може да бъде отхвърлено, ако номерът на RPC версията не е 2 или ако сървърът не може да удостовери клиента.) Полето за проверка се използва в случай на защитен RPC, за да посочи сървъра.
Полето за състояние на приемане е нула, ако всичко е наред. Ненулева стойност може да показва например невалиден номер на версията или невалиден номер на процедурата. Ако се използва TCP вместо UDP, поле с дължина 4 байта се изпраща между TCP заглавката и XID, както при съобщението за RPC предизвикателно.
XDR: Представяне на външни данни
Външно представяне на данни (XDR) е стандарт, използван за кодиране на стойности в съобщенията за RPC повикване и отговор - RPC заглавни полета (XID, номер на програмата, статус на получаване и т.н.), параметри на процедурата и резултати от процедурите. Стандартният начин за кодиране на данни позволява на клиента да извика процедура в система с различна архитектура. XDR е дефиниран в RFC 1014 [Sun Microsystems 1987].
XDR дефинира редица типове данни и точния начин, по който те се прехвърлят в RPC съобщение (ред на битове, ред на байтове и т.н.). Подателят трябва да изгради RPC съобщението в XDR формат, след което получателят ще преобразува XDR формата в оригиналното му представяне. (Във формата, който е приет за неговата система.) Виждаме, например, на фигури 29.1 и 29.2, че всички цели числа, които показваме (XID, повикване, номер на програмата и т.н.) са 4-байтови цели числа. Всъщност всички цели числа в XDR са 4 байта. XDR поддържа други типове данни, включително цели числа без знак, булеви числа, числа с плаваща запетая, масиви с фиксирана дължина, масиви с променлива дължина и структури.
Съвпадение на портове
Сървърните RPC програми, съдържащи отдалечени процедури, използват динамично присвоени портове, а не предварително известни портове. Това изисква някаква форма на "регистрация", за да имате постоянно информация за това кой динамично присвоен порт използва определена RPC програма. В Sun RPC този регистратор се нарича преобразувател на портове. (Преобразувателят на портове е сървър, който преобразува номерата на RPC програми в номера на портове на протокола DARPA. Този сървър трябва да работи, за да извърши RPC повикване.)
Терминът "порт" в името идва от номерата на TCP и UDP портовете, характеристики на семейството на интернет протоколите. Тъй като TI-RPC работи върху всеки транспортен слой, а не само TCP и UDP, името на преобразувателя на портовете в системи, използващи TI-RPC (SVR4 и Solaris 2.2, например) е преобразувано в rpcbind. Въпреки това, ние ще продължим да използваме по-познатия портов картограф.Всъщност самият преобразувател на портове трябва да има добре познат порт: UDP порт 111 и TCP порт 111. Преобразувателят на портове е просто RPC сървърна програма. Той има номер на програмата (100000), номер на версия (2), TCP порт 111 и UDP порт 111. Сървърите се регистрират един друг с преобразувателя на портове, използвайки RPC повиквания, а клиентите изискват преобразувателя на портове, използвайки RPC повиквания. Преобразувателят на портовете предоставя четири сървърни процедури:
- PMAPPROC_SET. Извиква се от RPC сървъра при стартиране, за да регистрира номера на програмата, номера на версията и протокола в картографа на портове.
- PMAPPROC_UNSET. Извиква се от сървъра за премахване на по-рано регистрирана трансформация.
- PMAPPROC_GETPORT. Извиква се от RPC клиента при стартиране, за да получи номера на порта за дадения номер на програмата, номера на версията и протокола.
- PMAPPROC_DUMP. Връща всички елементи (номер на програма, номер на версия, протокол и номер на порт) в базата данни на преобразувателя на портове.
Когато RPC сървърната програма стартира и по-късно, когато бъде извикана от RPC клиентската програма, се изпълняват следните стъпки.
- Преобразувателят на порт трябва да се стартира първо, обикновено при стартиране на системата. Това създава TCP крайна точка и пасивно отваря TCP порт 111. Също така създава UDP крайна точка, която чака UDP дейтаграма да пристигне на UDP порт 111.
- При стартиране RPC сървърната програма създава TCP крайна точка и UDP крайна точка за всяка поддържана версия на програмата. (Програма RPC може да поддържа множество версии. Клиентът посочва необходимата версия при извикване на сървърна процедура.) На всяка крайна точка се присвоява динамично присвоен номер на порт. (Няма разлика дали номерата на TCP и UDP портовете са еднакви или различни.) Сървърът регистрира всяка програма, версия, протокол и номер на порт, като прави отдалечено повикване към процедурата за преобразуване на порт PMAPPROC_SET.
- Когато клиентската програма RPC стартира, тя извиква рутинната програма за преобразуване на портове PMAPPROC_GETPORT, за да получи динамично присвоения номер на порт за дадена програма, версия и протокол.
- Клиентът изпраща съобщение за RPC предизвикателство до номера на порта, получен в стъпка 3. Ако се използва UDP, клиентът просто изпраща UDP дейтаграма, съдържаща съобщението за RPC предизвикателно (Фигура 29.1) до номера на UDP порта на сървъра. В отговор сървърът изпраща UDP дейтаграма, съдържаща съобщение за RPC отговор (Фигура 29.2). Ако TCP се използва, клиентът извършва активно отваряне на номера на TCP порта на сървъра и след това изпраща съобщение за RPC повикване през връзката. Сървърът отговаря със съобщение за RPC отговор през връзката.
Програмата rpcinfo (8) отпечатва всички текущи настройки на конвертора на портове. (Тук се извиква рутинната програма за преобразуване на порт PMAPPROC_DUMP.) Типичният изход е показан по-долу:
слънце% / usr / etc / rpcinfo -p
програма срещу прото порт
100005 1 tcp 702 монтиран NFS демон за монтиране
100005 1 udp 699 монт
100005 2 tcp 702 монт
100005 2 udp 699 монт
100003 2 udp 2049 nfs самата NFS
100021 1 tcp 709 nlockmgr NFS мениджър за заключване
100021 1 udp 1036 nlockmgr
100021 2 tcp 721 nlockmgr
100021 2 udp 1039 nlockmgr
100021 3 tcp 713 nlockmgr
100021 3 udp 1037 nlockmgr
Можем да видим, че някои програми поддържат множество версии и всяка комбинация от номер на програмата, номер на версията и протокол има свое собствено съпоставяне на номерата на портове, обслужвани от картографа на портове.
И двете версии на демона за монтиране могат да бъдат достъпни чрез един и същ номер на TCP порт (702) и същия номер на UDP порт (699), но всяка версия на мениджъра за блокиране има свой собствен номер на порт.
NFS протокол
NFS предоставя на клиентите прозрачен достъп до файловете и файловата система на сървъра. Това е в контраст с FTP (глава 27), който осигурява прехвърляне на файлове. С помощта на FTP се извършва пълно копие на файла. NFS има достъп само до части от файл, до които процесът е осъществил достъп, а основното предимство на NFS е, че прави този достъп прозрачен. Това означава, че всяко клиентско приложение, което може да работи с локален файл, може също да работи с NFS файл, без никакви модификации на самата програма.
NFS е клиент-сървър приложение, изградено с помощта на Sun RPC. NFS клиентите имат достъп до файлове на NFS сървъра, като изпращат RPC заявки към сървъра. Това може да бъде реализирано с помощта на нормални потребителски процеси - а именно, NFS клиентът може да бъде потребителски процес, който извършва специфични RPC извиквания към сървъра, който също може да бъде потребителски процес. Въпреки това, NFS обикновено се изпълнява по различен начин по две причини. Първо, достъпът до NFS файлове трябва да бъде прозрачен за клиента. Следователно повикванията към NFS клиента се извършват от клиентската операционна система от името на потребителския процес на клиента. Второ, NFS сървърите са внедрени в операционната система, за да се подобри ефективността на сървъра. Ако NFS сървърът беше потребителски процес, всяка клиентска заявка и отговор на сървъра (включително данни за четене или запис) ще трябва да премине през разделител между ядрото и потребителския процес, което обикновено е доста скъпо.
В този раздел ще разгледаме версия 2 на NFS, както е документирано в RFC 1094 [Sun Microsystems 1988b]. За по-добро описание на Sun RPC, XDR и NFS вижте [X / Open 1991]. За подробности относно използването и администрирането на NFS вижте [Stern 1991]. Спецификациите на протокола NFS версия 3 бяха внедрени през 1993 г., за което ще говорим в част от тази глава.
Фигура 29.3 показва типичните настройки за NFS клиент и NFS сървър. На тази фигура трябва да обърнете внимание на следното.
- Клиентът не се интересува дали осъществява достъп до локалния файл или NFS файла. Ядрото открива това, когато файлът е отворен. След отваряне на файла, ядрото прехвърля всички извиквания към локални файлове в полето, отбелязано като "достъп до локални файлове", и всички връзки към NFS файлове се прехвърлят в полето "NFS клиент".
- NFS клиентът изпраща RPC заявки към NFS сървъра чрез TCP / IP модула. NFS обикновено използва UDP, но по-новите реализации могат да използват TCP.
- NFS сървърът получава заявки от клиента като UDP дейтаграми на порт 2049. Въпреки че NFS може да работи с преобразувател на портове, което позволява на сървъра да използва динамично присвоени портове, UDP порт 2049 е твърдо кодиран за NFS в повечето реализации.
Фигура 29.3 Типични настройки за NFS клиент и NFS сървър.
Повечето Unix хостове могат да функционират като NFS клиент и NFS сървър, или и двете. Повечето PC реализации (MS-DOS) имат само NFS клиентски реализации. Повечето мейнфрейми на IBM предоставят само функционалност на NFS сървър.
NFS наистина е нещо повече от просто NFS протокол. Фигура 29.4 показва различните RPC програми, които се използват с NFS.
Приложение |
Номер на програмата |
Номер на версията |
Брой процедури |
| преобразувател на портове | |||
| NFS | |||
| програма за монтиране | |||
| мениджър на блокове | |||
| монитор на състоянието |
Фигура 29.4 Различни RPC програми, използвани в NFS.
Версиите, показани на тази фигура като единици, се намират в системи като SunOS 4.1.3. По-новите реализации предоставят по-нови версии на някои програми. Solaris 2.2, например, също поддържа версия 3 и 4 на преобразувателя на портове и версия 2 на демона за монтиране. SVR4 също поддържа версия 3 на преобразувателя на портове.Демонът за монтиране се извиква на NFS хоста на клиента, преди клиентът да има достъп до файловата система на сървъра. По-долу ще опишем този процес.
Мениджърът на заключване и мониторът на състоянието позволяват на клиента да заключи някои от файловете, които са на NFS сървъра. Тези две програми са независими от NFS протокола, тъй като блокирането изисква удостоверяване на клиента както за клиентския хост, така и за сървъра, а самата NFS е „безразлична“. (Говорим за безразличието към NFS по-подробно по-долу.) Глави 9, 10 и 11 от [X / Open 1991] документират процедурите, които мениджърът на заключване и мониторът на състоянието използват за заключване в NFS.
Файлови дескриптори
Една от основите на NFS са файловите дескриптори. За да се обърнете към файл или директория на обектния сървър, използвайте opaque. Терминът непрозрачен означава, че сървърът създава файлов дескриптор, предава го обратно на клиента, който клиентът след това използва при достъп до файла. Клиентът никога не разглежда съдържанието на файловия дескриптор - неговото съдържание представлява интерес само за сървъра.
NFS клиент получава файлов дескриптор всеки път, когато отвори файл, който всъщност е на NFS сървъра. Когато NFS клиент чете или пише в този файл (от името на потребителски процес), файловият дескриптор се предава обратно на сървъра. Това показва, че файлът е бил достъпен.
Обикновено персонализираният процес не работи с файлови дескриптори. Файловите дескриптори се обменят между NFS клиент и NFS сървър. Във версия 2 на NFS файловият дескриптор е 32 байта, а във версия 3 е нараснал до 64 байта.
Unix сървърите обикновено съхраняват следната информация във файловия дескриптор: идентификатор на файловата система (основни и второстепенни номера на устройства на файловата система), номер на inode (i-node) (уникален номер във файловата система), номер на генериране на inode (номер, който се променя всеки път inode се използва повторно за друг файл).Протокол за монтиране
Клиентът използва протокола за монтиране на NFS, за да монтира файловата система на сървъра, преди да получи достъп до NFS файлове. Това обикновено се случва, когато клиентът се стартира. В резултат на това клиентът получава файлов дескриптор за файловата система на сървъра.
Фигура 29.5 описва последователността от действия за Unix клиент при изпълнение на командата монтиране (8).
Фигура 29.5 Протокол за монтиране, използван от командата за монтиране на Unix.
В този случай се предприемат следните стъпки.
- Когато сървърът се стартира, преобразувателят на портове стартира на него.
- След картографа на портове, демонът за монтиране стартира на сървъра. Той създава TCP крайна точка и UDP крайна точка и присвоява динамично присвоен номер на порт на всяка. След това регистрира тези номера с картографа на портове.
- Клиентът изпълнява командата за монтиране, която издава RPC извикване към портовото устройство на сървъра, за да получи номера на порта от демона за монтиране на сървъра. Както TCP, така и UDP могат да се използват за комуникация между клиента и картографа на портове, но обикновено се използва UDP.
- Преобразувателят на порта отчита номера на порта.
- Командата mount издава RPC извикване към демона за монтиране, за да монтира файловата система на сървъра. Отново могат да се използват както TCP, така и UDP, но обикновено се използва UDP. Сървърът вече може да валидира клиента въз основа на неговия IP адрес и номер на порт, за да види дали клиентът може да монтира определената файлова система.
- Демонът за монтиране отговаря с файлов дескриптор за посочената файлова система.
- Командата за монтиране на клиента издава системното извикване за монтиране, за да обвърже файловия дескриптор, получен в стъпка 5, към локалната точка на монтиране на клиентския хост. Файловият дескриптор се съхранява в клиентския код на NFS и от този момент нататък всеки достъп от потребителски процеси до файлове във файловата система на сървъра ще използва файловия дескриптор като отправна точка.
Такава реализация делегира целия процес на монтиране, с изключение на системното извикване за монтиране на клиента, на потребителски процеси, а не на ядрото. Трите програми, които показахме - командата за монтиране, картографът на портове и демонът за монтиране - са потребителски процеси.
В този пример, на хост sun (NFS клиент), командата
слънце # mount -t nfs bsdi: / usr / nfs / bsdi / usrТази команда монтира директорията / usr на хоста bsdi (NFS сървър) като локална файлова система / nfs / bsdi / usr. Фигура 29.6 показва резултата.
Фигура 29.6 Монтиране на директорията bsdi: / usr като / nfs / bsdi / usr на sun.
След това, при достъп до файла /nfs/bsdi/usr/rstevens/hello.c на клиента sun, файлът /usr/rstevens/hello.c се осъществява на bsdi сървъра.
NFS процедури
NFS сървърът предоставя 15 процедури, които сега ще опишем. (Числата, използвани в описанието, не съвпадат с NFS рутините, тъй като сме ги групирали по функции.) Въпреки че NFS е проектиран да работи между различни операционни системи, а не само Unix системи, някои от процедурите се основават на функционалността на Unix, която , от своя страна, може да не се поддържа от други операционни системи (например твърди връзки, символни връзки, групиране, разрешения за изпълнение и т.н.). Глава 4 съдържа повече информация за характеристиките на файловите системи, някои от които използва NFS.
- GETATTR. Връща атрибути на файла: тип на файла (обикновен файл, директория и т.н.), права за достъп, размер на файла, собственик на файла, време за последен достъп и т.н.
- SETATTR. Задава атрибутите на файл. Може да се зададе само определен набор от атрибути: права на достъп, собственик, собственост на групата, размер, време на последен достъп и време на последна модификация.
- STATFS. Връща състоянието на файловата система: свободно пространство, оптимален размер за трансфер и т.н. Използва се например от командата Unix df.
- ПОГЛЕДНИ НАГОРЕ. „Оценява“ файла. Тази процедура се извиква от клиента всеки път, когато потребителски процес отвори файл, който се намира на NFS сървъра. Връща се файловият дескриптор, заедно с атрибутите на файла.
- ПРОЧЕТИ. Чете от файл. Клиентът посочва файловия дескриптор, началното изместване на байта и максималния брой байтове за четене (до 8192).
- ПИШЕТЕ. Записва във файл. Клиентът посочва файловия дескриптор, началното изместване на байтовете, броя на байтовете за запис и данните за запис.
Записванията в NFS трябва да бъдат синхронни (изчакващи). Сървърът не може да отговори ОК, докато данните не бъдат записани успешно (и всяка друга информация за файла, която трябва да бъде актуализирана) на диска.
- СЪЗДАВАЙТЕ. Създава файл.
- ПРЕМАХВАНЕ. Изтрива файла.
- ПРЕИМЕНУВАНЕ. Преименува файла.
- ВРЪЗКА. Прави твърда връзка към файл. Твърдата връзка е Unix концепция, която определя, че конкретен файл на диск може да има произволен брой входни точки (имена, наричани също твърди връзки), които сочат към този файл.
- SYMLINK. Създава символна връзка към файла. Символна връзка е файл, който съдържа името на друг файл. Повечето от операциите, които се извършват върху символна връзка (например отваряне), всъщност се изпълняват върху файла, към който сочи символната връзка.
- ПРОЧЕТЕТЕ ВРЪЗКА. Четенето на символна връзка връща името на файла, посочен от символната връзка.
- MKDIR. Създава директория.
- RMDIR. Премахва директория.
- READDIR. Чете директория. Използва се например от командата ls на Unix.
Всъщност имената на горните процедури започват с префикса NFSPROC_, който пропуснахме.
UDP или TCP?
Първоначално NFS е написан да използва UDP и всички доставчици предоставят тази възможност. По-новите реализации обаче също поддържат TCP. TCP поддръжката се използва за работа във все по-бързи глобални мрежи. Следователно използването на NFS вече не е ограничено до локални мрежи.
Границите между локални и глобални мрежи се размиват и всичко това се случва много бързо. Времената за връщане варират в много широк диапазон и преливанията се случват все по-често. Тези характеристики на широкообхватните мрежи водят до факта, че те все повече използват алгоритмите, които разгледахме за TCP - бавен старт и избягване на претоварване. Тъй като UDP не предоставя нищо подобно на тези алгоритми, те или подобни трябва да бъдат вградени в NFS клиента и сървъра, в противен случай трябва да се използва TCP.
NFS през TCP
Внедряването на Berkeley Net / 2 NFS поддържа както UDP, така и TCP. [Macklem 1991] описва тази реализация. Нека да разгледаме как NFS се различава от TCP.
- Когато сървърът се зареди, той стартира NFS сървъра, който извършва активно отваряне на TCP порт 2049, чакайки заявка за връзка от клиента. Това обикновено се прави в допълнение към нормалния NFS UDP, който слуша входящи дейтаграми на UDP порт 2049.
- Когато клиент монтира файловата система на сървъра с помощта на TCP, той прави активно отваряне на TCP порт 2049 на сървъра. Това установява TCP връзка между клиента и сървъра за тази файлова система. Ако същият клиент монтира друга файлова система на същия сървър, се създава друга TCP връзка.
- И клиентът, и сървърът задават опцията за поддържане на TCP в техните краища на връзката (глава 23). Това ви позволява да определите момента на повреда или рестартиране на един или друг участник в обмен.
- Всички приложения на клиента, които използват файловата система на сървъра, споделят една и съща TCP връзка за тази файлова система. Например, ако беше на фигура 29.6, щеше да има друга директория на bsdi с име smith под директорията /usr, достъп до файлове в /nfs/bsdi/usr/rstevens и /nfs/bsdi/usr/smith ще споделя една и същата TCP връзка.
- Ако клиентът открие, че сървърът се е сринал или се е рестартирал (след като получи TCP грешка „изтекло време за изчакване на връзката“ или „връзката затворена от хост“), той се опитва да се свърже отново със сървъра. Клиентът прави друго активно отваряне, за да възстанови TCP връзка за тази файлова система. Всяка заявка от клиент, която е изтекла при предишна връзка, се издава повторно при нова връзка.
- Ако клиент се срине, същото се случва и с приложения, които са работили преди срива. Когато клиентът се рестартира, той вероятно ще монтира отново файловата система на сървъра, използвайки TCP, като използва различна TCP връзка със сървъра. Предишната връзка клиент-сървър за тази файлова система е в полуотворено състояние (сървърът смята, че все още е отворен), но тъй като сървърът е задал опцията „поддържане на живо“, тази полуотворена връзка ще бъде затворена, когато TCP сървърът изпраща следващата сонда. "остани жив."
С течение на времето други доставчици планират да започнат да поддържат NFS през TCP.
NFS примери
Нека използваме tcpdump, за да видим кои NFS подпрограми се извикват от клиента за нормални файлови операции. Когато tcpdump открие, че UDP дейтаграмата съдържа RPC повикване (повикването е 0 на фигура 29.1) с дестинационен порт 2049, той декодира дейтаграмата като NFS заявка. По същия начин, ако UDP дейтаграмата съдържа RPC отговор (отговорът е 1 на фигура 29.2) с изходен порт 2049, тя декодира дейтаграмата като NFS отговор.
Прост пример: четене на файл
В първия пример ще копираме файла, намиращ се на NFS сървъра, в терминала с помощта на командата cat (1):
слънце% котка /nfs/bsdi/usr/rstevens/hello.cкопирайте файла в терминала
основен ()
{
printf ("здравей, свят \ n");
}
Файловата система / nfs / bsdi / usr на sun (NFS клиент) всъщност е файловата система / usr на bsdi (NFS сървър), както е показано на Фигура 29.6. Sun kernel открива това, когато cat отвори файл и използва NFS за достъп до файла. Фигура 29.7 показва изхода на командата tcpdump.
1 0.0 sun.7aa6> bsdi.nfs: 104 getattr
2 0,003587 (0,0036) bsdi.nfs> sun.7aa6: отговор добре 96
3 0.005390 (0.0018) sun.7aa7> bsdi.nfs: 116 търсене "rstevens"
4 0,009570 (0,0042) bsdi.nfs> sun.7aa7: отговор добре 128
5 0.011413 (0.0018) sun.7aa8> bsdi.nfs: 116 търсене "hello.c"
6 0,015512 (0,0041) bsdi.nfs> sun.7aa8: отговор добре 128
7 0,018843 (0,0033) sun.7aa9> bsdi.nfs: 104 getattr
8 0,022377 (0,0035) bsdi.nfs> sun.7aa9: отговор добре 96
9 0.027621 (0.0052) sun.7aaa> bsdi.nfs: 116 четене на 1024 байта @ 0
10 0,032170 (0,0045) bsdi.nfs> sun.7aaa: отговор добре 140
Фигура 29.7 NFS поведение при четене на файл.
Командата tcpdump декодира NFS заявка или отговор и отпечатва полето XID за клиента вместо номера на порта. Полето XID на редове 1 и 2 е 0x7aa6.
Името на файла /nfs/bsdi/usr/rstevens/hello.c се обработва от функцията за отваряне в клиентското ядро един елемент по един. Когато отворената функция достигне / nfs / bsdi / usr, тя открива, че това е NFS точка за монтиране.
На ред 1 клиентът извиква процедурата GETATTR, за да получи атрибутите на директорията на сървъра, която клиентът е монтирал (/usr). Тази RPC заявка съдържа 104 байта данни, в допълнение към IP и UDP заглавките. Отговорът на ред 2 връща OK и съдържа 96 байта данни, в допълнение към IP и UDP заглавките. На тази фигура можем да видим, че най-малкото NFS съобщение съдържа приблизително 100 байта данни.
На ред 3 клиентът извиква LOOKUP във файла rstevens и получава отговор OK на ред 4. LOOKUP указва името на файла rstevens и файлов дескриптор, който е записан от ядрото при монтиране на отдалечената файлова система. Отговорът съдържа нов файлов дескриптор, който се използва в следващата стъпка.
На ред 5, клиентът ПРЕРСИ файла hello.c, използвайки файловия дескриптор от ред 4. Той получава различен файлов дескриптор на ред 6. Този нов файлов дескриптор е точно това, което клиентът използва на редове 7 и 9 за достъп до / nfs файл /bsdi/usr/rstevens/hello.c. Можем да видим, че клиентът извършва LOOKUP на всеки компонент с име в пътя към отваряния файл.
На ред 7 клиентът изпълнява GETATTR отново, последвано от READ на ред 9. Клиентът изисква 1024 байта, започвайки от отместване 0, но получава по-малко от 1024 байта данни. (След изваждане на размерите на RPC полета и други стойности, върнати от процедурата READ, 38 байта данни се връщат на ред 10. Това е точно размерът на файла hello.c.)
В този пример потребителският процес не знае за тези NFS заявки и отговори, които се правят от ядрото. Приложението просто извиква функцията за отваряне на ядрото, която извиква обмена на 3 заявки и 3 отговора (редове 1-6) и след това извиква функцията за четене на ядрото, която извиква 2 заявки и 2 отговора (редове 7-10). За клиентското приложение файлът, намиращ се на NFS сървъра, е прозрачен.
Прост пример: създаване на директория
Като друг пример променете работната директория на директорията на NFS сървъра и след това създайте нова директория:
слънце% cd / nfs / bsdi / usr / rstevensпромяна на работната директория
слънце% mkdir Пощасъздайте директория
Фигура 29.8 показва изхода на командата tcpdump.
1 0.0 sun.7ad2> bsdi.nfs: 104 getattr
2 0,004912 (0,0049) bsdi.nfs> sun.7ad2: отговор добре 96
3 0,007266 (0,0024) sun.7ad3> bsdi.nfs: 104 getattr
4 0,010846 (0,0036) bsdi.nfs> sun.7ad3: отговор добре 96
5 35.769875 (35.7590) sun.7ad4> bsdi.nfs: 104 getattr
6 35.773432 (0.0036) bsdi.nfs> sun.7ad4: отговор добре 96
7 35.775236 (0.0018) sun.7ad5> bsdi.nfs: 112 търсене "Поща"
8 35.780914 (0.0057) bsdi.nfs> sun.7ad5: отговор добре 28
9 35.782339 (0.0014) sun.7ad6> bsdi.nfs: 144 mkdir "Mail"
10 35.992354 (0.2100) bsdi.nfs> sun.7ad6: отговор ок 128
Фигура 29.8 NFS поведение чрез промяна на директория (cd) в NFS директория и след това създаване на директория (mkdir).
Когато променя директорията, клиентът извиква процедурата GETATTR два пъти (редове 1-4). Когато създадем нова директория, клиентът извиква процедурата GETATTR (редове 5 и 6), след това LOOKUP (редове 7 и 8, за да провери дали не съществува такава директория), след това MKDIR, за да създаде директорията (редове 9 и 10). Отговорът OK на ред 8 не означава, че директорията съществува. Това просто означава, че процедурата е върнала някаква стойност. tcpdump не интерпретира стойността, върната от NFS рутинни процедури. Командата просто отпечатва ОК и броя на байтовете данни в отговора.
Безразличие
Една от характеристиките на NFS (критиците на NFS наричат това брадавица, а не характеристика) е, че NFS сървърът е безразличен. Сървърът не се интересува кои клиенти имат достъп до кои файлове. Обърнете внимание, че в списъка с NFS процедури, показан по-рано, няма процедура за отваряне или затваряне. LOOKUP е подобен на отварянето, но сървърът никога не знае дали клиентът е осъществил достъп до файла, след като LOOKUP е направен.
Причината за това "мързеливо поведение" е да се улесни възстановяването от срив на сървъра и рестартиране.
Пример: Отказ на сървъра
В следващия пример четем файл от NFS сървър, когато сървърът се срине и се рестартира. Това ще покаже как "безразличието" на сървъра позволява на клиента да "не знае", че сървърът не работи. Докато сървърът се срива и се рестартира, клиентът не е наясно с проблема и клиентското приложение работи по същия начин, както преди.
На клиента sun стартирахме cat с много голям файл като аргумент (/usr / share / lib / termcap на svr4 NFS сървъра), изключихме Ethernet кабела по време на трансфера, изключихме и рестартирахме сървъра и след това свързахме отново кабел. Клиентът е конфигуриран да чете 1024 байта в едно NFS четене. Фигура 29.9 показва изхода от tcpdump.
Редове 1-10 съответстват на клиента, който отваря файла. Тази операция прилича на тази, показана на Фигура 29.7. На ред 11 виждаме първото четене (READ) от файл с 1024 байта данни; отговорът се връща на ред 12. Това продължава до ред 129 (четене на 1024 байтов READ и след това отговор OK).
На редове 130 и 131 виждаме две заявки, които са изтекли и са препредадени на редове 132 и 133. Първи въпрос: виждаме две заявки за четене, едната започва с отместване 65536, а другата започва с изместване 73728, защо? Клиентското ядро определи, че клиентското приложение чете последователно и се опита да получи блоковете данни преди време. (Повечето ядра на Unix правят това с четене напред.) Клиентското ядро също изпълнява няколко NFS блок I/O демона (биод процеси), които се опитват да генерират множество RPC заявки от името на клиента. Един демон чете 8192 байта, започвайки от 65536 (в 1024-байтови вериги), докато други четат напред 8192 байта, започвайки от 73728.
Клиентските повторни предавания се появяват на редове 130-168. На ред 169 виждаме, че сървърът се е рестартирал и е изпратил ARP заявка, преди да отговори на NFS заявката на клиента от ред 168. Отговорът на ред 168 се изпраща на ред 171. Заявките за READ на клиента продължават.
1 0.0 sun.7ade> svr4.nfs: 104 getattr
2 0.007653 (0.0077) svr4.nfs> sun.7ade: отговор добре 96
3 0.009041 (0.0014) sun.7adf> svr4.nfs: 116 търсене "споделяне"
4 0.017237 (0.0082) svr4.nfs> sun.7adf: отговор ок 128
5 0.018518 (0.0013) sun.7ae0> svr4.nfs: 112 търсене "lib"
6 0.026802 (0.0083) svr4.nfs> sun.7ae0: отговор добре 128
7 0.028096 (0.0013) sun.7ae1> svr4.nfs: 116 търсене "termcap"
8 0,036434 (0,0083) svr4.nfs> sun.7ae1: отговор ок 128
9 0,038060 (0,0016) sun.7ae2> svr4.nfs: 104 getattr
10 0,045821 (0,0078) svr4.nfs> sun.7ae2: отговор добре 96
11 0.050984 (0.0052) sun.7ae3> svr4.nfs: 116 четене на 1024 байта @ 0
12 0,084995 (0,0340) svr4.nfs> sun.7ae3: отговор ок 1124
Четене
128 3.430313 (0.0013) sun.7b22> svr4.nfs: 116 четене на 1024 байта @ 64512
129 3.441828 (0.0115) svr4.nfs> sun.7b22: отговор добре 1124
130 4.125031 (0.6832) sun.7b23>
131 4.868593 (0.7436) sun.7b24>
132 4.993021 (0.1244) sun.7b23> svr4.nfs: 116 прочетете 1024 байта @ 65536
133 5.732217 (0.7392) sun.7b24> svr4.nfs: 116 четене на 1024 байта @ 73728
134 6.732084 (0.9999) sun.7b23> svr4.nfs: 116 четене на 1024 байта @ 65536
135 7.472098 (0.7400) sun.7b24> svr4.nfs: 116 четене на 1024 байта @ 73728
136 10.211964 (2.7399) sun.7b23>
137 10.951960 (0.7400) sun.7b24>
138 17.171767 (6.2198) sun.7b23> svr4.nfs: 116 прочетете 1024 байта @ 65536
139 17.911762 (0.7400) sun.7b24> svr4.nfs: 116 четене на 1024 байта @ 73728
140 31.092136 (13.1804) sun.7b23> svr4.nfs: 116 прочетете 1024 байта @ 65536
141 31.831432 (0.7393) sun.7b24> svr4.nfs: 116 четене на 1024 байта @ 73728
142 51.090854 (19.2594) sun.7b23> svr4.nfs: 116 прочетете 1024 байта @ 65536
143 51.830939 (0.7401) sun.7b24> svr4.nfs: 116 прочетете 1024 байта @ 73728
144 71.090305 (19.2594) sun.7b23> svr4.nfs: 116 прочетете 1024 байта @ 65536
145 71.830155 (0.7398) sun.7b24> svr4.nfs: 116 прочетете 1024 байта @ 73728
Повторни предавания
167 291.824285 (0.7400) sun.7b24> svr4.nfs: 116 прочетете 1024 байта @ 73728
168 311.083676 (19.2594) sun.7b23> svr4.nfs: 116 прочетете 1024 байта @ 65536
Сървърът се рестартира
169 311.149476 (0.0658) arp кой има слънце кажи svr4
170 311.150004 (0.0005) arp отговор слънце е в 8: 0: 20: 3: f6: 42
171 311.154852 (0.0048) svr4.nfs> sun.7b23: отговор добре 1124
172 311.156671 (0.0018) sun.7b25> svr4.nfs: 116 прочетете 1024 байта @ 66560
173 311.168926 (0.0123) svr4.nfs> sun.7b25: отговор добре 1124
четене
Фигура 29.9 Клиент прочете файл, когато NFS сървърът се срине и се рестартира.
Клиентското приложение никога няма да разбере, че сървърът се е сринал и рестартирал, освен че е имало 5-минутна пауза между редове 129 и 171, така че сривът на сървъра е прозрачен за клиента.
За да оцените продължителността на изчакванията за повторно предаване в този пример, представете си, че има два клиентски демона, всеки със свои собствени изчаквания. Интервалите за първия демон (четене от изместване 65536) са приблизително следните (закръглени до два знака след десетичната запетая): 0,68; 0,87; 1,74; 3,48; 6,96; 13,92; 20,0; 20,0; 20.0 и така нататък. Разстоянието за втория демон (четене от офсет 73728) е абсолютно същото. Това означава, че тези NFS клиенти използват изчаквания, кратни на 0,875 секунди с горна граница от 20 секунди. След всяко изчакване интервалът на повторно предаване се удвоява: 0,875; 1,75; 3,5; 7.0 и 14.0.
Колко време клиентът ще прави повторни предавания? Клиентът има две опции, които могат да повлияят на това. Първо, ако файловата система на сървъра е монтирана трудно, клиентът ще препредава завинаги, но ако файловата система на сървъра е меко монтирана, клиентът ще прекрати след фиксиран брой повторни предавания. Също така, в случай на твърдо монтиране, клиентът има опция да позволи на потребителя да прекъсне неуспешни повторни предавания или не. Ако при монтиране на файловата система на сървъра клиентският хост посочи, че е възможно прекъсване, и ако не искаме да чакаме 5 минути сървърът да се рестартира след повреда, можем да въведем символа за прекъсване, за да прекратим клиентското приложение .
Няколко от същите процедури
RPC процедурите могат да бъдат изпълнявани от сървъра няколко пъти, но те все още връщат същия резултат. Например, NFS рутина за четене. Както видяхме на Фигура 29.9, клиентът просто преиздава повикването READ, докато не получи отговор. В нашия пример причината за повторното предаване беше, че сървърът се срина. Ако сървърът не се повреди и съобщенията, съдържащи RPC отговорите, са загубени (тъй като UDP не е надежден протокол), клиентът просто предава повторно и сървърът извършва отново същото READ. Същата част от същия файл се чете отново и се изпраща на клиента.
Това работи, защото всяко READ съдържа начално отместване. Ако NFS процедурата поиска от сървъра да прочете следващите N байта от файла, тя няма да работи. Ако сървърът не е бил безразличен (тази стойност е противоположна на indifference) и отговорът е загубен и клиентът повторно издава READ за следващите N байта, резултатът ще бъде различен. Ето защо NFS процедурите READ и WRITE имат начално изместване. Клиентът е този, който поддържа състоянието (текущото изместване за всеки файл), а не сървърът.
За съжаление, не всички операции с файловата система могат да се извършват няколко пъти. Например, представете си следните стъпки: NFS клиентът издава заявка REMOVE за изтриване на файл; NFS сървърът изтрива файла и отговаря с OK; отговорът на сървъра е загубен; NFS клиентът изтече и препредава заявката; NFS сървърът не може да намери файла и връща грешка; клиентското приложение получава грешка, че файлът не съществува. Тази грешка се връща на клиентското приложение и тази грешка носи неправилна информация - файлът не е съществувал и е изтрит.
По-долу е даден списък с NFS рутинни процедури, които могат да се изпълняват няколко пъти: GETATTR, STATFS, LOOKUP, READ, WRITE, READLINK и READDIR. Процедури, които не могат да се изпълняват многократно: СЪЗДАВАНЕ, ОТХВЪРВАНЕ, ПРЕИМЕНУВАНЕ, ВРЪЗКА, SYMLINK, MKDIR и RMDIR. SETATTR обикновено се изпълнява няколко пъти, освен ако не е бил използван за съкращаване на файла.
Тъй като винаги може да има загубени отговори в случай на UDP, NFS сървърите ТРЯБВА да имат начин да обработват операции, които не могат да се изпълняват многократно. Повечето сървъри имат скорошен кеш за отговори, в който съхраняват последните получени отговори за такива операции. Всеки път, когато сървърът получи заявка, той първо преглежда своя кеш и ако бъде намерено съвпадение, той връща предишния отговор, вместо да извиква NFS процедурата отново. [Juszczak 1989] описва подробностите за тези типове кеш.
Подобен подход към процедурите на сървърите се прилага за всички UDP-базирани приложения, а не само за NFS. DNS, например, предоставя услуга, която се използва безболезнено многократно. DNS сървърът може да направи заявка за анализатор произволен брой пъти, което няма да доведе до отрицателни резултати (може би, освен че мрежовите ресурси ще бъдат заети).
NFS версия 3
През 1994 г. бяха публикувани спецификациите за версия 3 на NFS протокола [Sun Microsystems 1993]. Очаква се реализациите да станат достъпни през 1994 г.
Тук накратко са описани основните разлики между версия 2 и версия 3. Ще ги наричаме V2 и V3.
- Файловите дескриптори във V2 са масив с фиксиран размер от 32 байта. Във V3 това е масив с променлив размер до 64 байта. Масив с променлива дължина в XDR се дефинира от 4-байтов брояч, последван от реални байтове. Това намалява размера на файловия дескриптор в реализации като Unix, които изискват само около 12 байта, но позволява на не-Unix реализации да обменят допълнителна информация.
- V2 ограничава броя на байтовете на READ или WRITE RPC до 8192 байта. Това ограничение не се прилага във V3, което от своя страна означава, че при използване на UDP ограничението ще бъде само в размера на IP дейтаграмата (65535 байта). Това позволява да се използват големи пакети при четене и писане в бързи мрежи.
- Размерите на файловете и първоначалните отмествания на байтове за процедурите READ и WRITE са разширени от 32 на 64 бита, за да се поберат по-големи файлове.
- Файловите атрибути се връщат при всяко повикване, което може да повлияе на атрибутите. Това намалява броя на GETATTR повикванията, изисквани от клиента.
- Записванията (WRITE) могат да бъдат асинхронни, докато във V2 те трябваше да бъдат синхронни. Това може да подобри производителността на процедурата WRITE.
- Една процедура беше премахната (STATFS) и бяха добавени седем: ACCESS (проверка на разрешенията за файлове), MKNOD (създаване на специален Unix файл), READDIRPLUS (връща имената на файловете в директория заедно с техните атрибути), FSINFO (връща статистическа информация за файловата система), FSSTAT (връща информация за динамична файлова система), PATHCONF (връща информация за файла POSIX.1) и COMMIT (прехвърля предварително направени асинхронни записи в постоянно съхранение).
Кратки заключения
RPC е начин за изграждане на клиент-сървър приложение по такъв начин, че клиентът просто извиква процедури на сървъра. Всички мрежови подробности са скрити в клиентски и сървърни модули, които се генерират за приложения от RPC пакета и в рутинните RPC библиотеки. Показахме формата на съобщението за RPC повикване и отговор и споменахме, че XDR се използва за кодиране на стойности, което позволява на RPC клиенти и сървъри да работят на машини с различни архитектури.
Едно от най-широко използваните RPC приложения е Sun NFS, хетерогенен протокол за достъп до файлове, който се използва широко на хостове от почти всички размери. Разгледахме NFS и как използва UDP или TCP. NFS Версия 2 дефинира 15 процедури.
Клиентският достъп до NFS сървъра започва с дневник за монтиране, след което на клиента се връща файлов дескриптор. След това клиентът може да осъществява достъп до файлове във файловата система на сървъра, използвайки този файлов дескриптор. Имената на файловете се търсят на сървъра един елемент от името наведнъж и за всеки елемент се връща нов файлов дескриптор. Крайният резултат е манипулатор на файла, който е бил достъпен и използван за последователно четене и запис.
NFS се опитва да направи всички свои процедури независими от броя на изпълненията, така че клиентът да може просто да преиздаде заявката, ако отговорът бъде загубен. Виждали сме примери за това: в случай, когато клиентът чете файл, докато сървърът се срине и се рестартира.
Упражнения
На фигура 29.7 видяхме, че tcpdump интерпретира пакетите като NFS заявки и отговори и отпечатва XID. Може ли tcpdump да направи това за всякакви RPC заявки или отговори?Мрежова файлова система (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 ограничава броя на байтовете на RPC READ или WRITE до 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 клиентът преобразува локалните данни в канонична форма, а сървърът прави обратното.
Услугата Remote Procedure Call (RPC), която позволява на клиента да изисква отдалечени процедури и да ги изпълнява на сървъра, е функция на ниво сесия. Свързване на мрежови ресурси
Процедурата за свързване на мрежов ресурс с помощта на 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 Споразумение между Интернет обществото, IETF и Sun Microsystems, Inc. по въпроса за NFS V.4 Protocols
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.gogle.com
Мрежова файлова система NFS или мрежова файлова система е популярен протокол за мрежова файлова система, който позволява на потребителите да монтират отдалечени мрежови директории на своята машина и да прехвърлят файлове между сървъри. Можете да използвате дисково пространство на друга машина за вашите файлове и да работите с файлове, разположени на други сървъри. Всъщност това е алтернатива на споделянето на Windows за Linux, за разлика от Samba, то се реализира на ниво ядро и работи по-стабилно.
Тази статия ще ви преведе през инсталирането на nfs на Ubuntu 16.04. Ще преминем през инсталирането на всички необходими компоненти, настройването на споделена папка, както и свързването на мрежови папки.
Както вече споменахме, NFS е мрежова файлова система. За да работите, имате нужда от сървър, който ще хоства споделената папка и клиенти, които могат да монтират мрежовата папка като обикновен диск в системата. За разлика от други протоколи, NFS осигурява прозрачен достъп до отдалечени файлове. Програмите ще виждат файлове като в обикновена файлова система и ще работят с тях като с локални файлове, nfs връща само исканата част от файла, вместо целия файл, така че тази файлова система ще работи добре на системи с бърз интернет или локална мрежа .
Инсталиране на NFS компоненти
Преди да можем да работим с NFS, трябва да инсталираме няколко програми. На машината, която ще бъде сървърът, трябва да инсталирате пакета nfs-kernel-server, който ще отвори nfs споделяния в ubuntu 16.04. За да направите това, стартирайте:
sudo apt инсталира nfs-kernel-server
Сега нека проверим дали сървърът е инсталиран правилно. Услугата NFS изслушва връзки както за TCP, така и за UDP на порт 2049. Можете да видите дали тези портове всъщност се използват с командата:
rpcinfo -p | grep nfs
Също така е важно да проверите дали NFS се поддържа на ниво ядро:
cat / proc / файлови системи | grep nfs
Виждаме какво работи, но ако не, трябва ръчно да заредите модула на ядрото на nfs:
Нека добавим и nfs към стартирането:
sudo systemctl активира nfs
На клиентския компютър трябва да инсталирате пакета nfs-common, за да можете да работите с тази файлова система. Не е необходимо да инсталирате сървърните компоненти, само този пакет ще бъде достатъчен:
sudo apt инсталирайте nfs-common
Настройка на NFS сървър в Ubuntu
Можем да отворим NFS достъп до всяка папка, но нека създадем нова за тази цел:
папка_адрес клиент (опции)
Адресът на папката е папката, която искате да направите достъпна в мрежата. Клиент - ip адрес или мрежов адрес, от който може да се осъществи достъп до тази папка. Но опциите са малко по-сложни. Нека разгледаме някои от тях:
- rw- разрешаване на четене и писане в тази папка
- ро- позволява само четене
- синхронизиране- отговаряйте на следните заявки само когато данните са записани на диск (по подразбиране)
- асинхронно- не блокирайте връзките, докато данните се записват на диск
- сигурен- използвайте само портове под 1024 за връзка
- несигурен- използвайте всякакви портове
- nohide- не скривайте поддиректории, когато отваряте достъп до множество директории
- root_squash- заменете заявките от root с анонимни
- all_squash- направи всички заявки анонимни
- анонуидени анонгиден- определя uid и gid за анонимния потребител.
Например за нашата папка този ред може да изглежда така:
/ var / nfs 127.0.0.1 (rw, sync, no_subtree_check)
Когато всичко е настроено, остава да актуализирате таблицата за експортиране на NFS:
sudo exportfs -a
Това е всичко, отварянето на nfs топки в ubuntu 16.04 приключи. Сега нека се опитаме да конфигурираме клиента и да се опитаме да го монтираме.
NFS връзка
Няма да се спираме подробно на този въпрос в днешната статия. Това е доста голяма тема, която заслужава отделна статия. Но ще кажа няколко думи.
За да монтирате мрежова папка, нямате нужда от клиент на ubuntu nfs, просто използвайте командата mount:
sudo mount 127.0.0.1:/var/nfs/ / mnt /
Сега можете да опитате да създадете файл в свързаната директория:
Ще разгледаме и монтираните файлови системи с df:
127.0.0.1:/var/nfs 30G 6,7G 22G 24% / mnt
За да деактивирате тази файлова система, просто използвайте стандартния umount:
sudo umount / mnt /
заключения
Тази статия разгледа настройката на nfs ubuntu 16.04, както можете да видите, всичко се прави много просто и прозрачно. Свързването на NFS споделяния се извършва с няколко щраквания с помощта на стандартни команди, а отварянето на nfs споделяния в ubuntu 16.04 не е много по-трудно от свързването. Ако имате въпроси, пишете в коментарите!
Свързани записи:
"И вече имате представа за" мрежовата файлова система ", нейните възможности и степента на сигурност. В тази статия обаче всичко беше разбрано основно от гледна точка на клиента... но какво ще стане, ако искате да имате свой собствен NFS сървър? (забележка: „да имаш“ не означава „да счупиш“, но означава „да инсталираш и конфигурираш“).
Е, ако имате такова желание, тогава първият въпрос, който трябва да си зададете, е: "Какво за козата, акордеона?" За поставяне на NFS сървър у дома
доста безсмислено - никой няма да го оцени, но ако имате късмета да администрирате "хора в черно" в офиса или в новосъздадената "домашна мрежа" - тогава това е съвсем различен въпрос ...
Стартирането на самия сървър е доста прост въпрос, ако прочетете предишната статия, тогава можете да се справите доста добре. И така, имате нужда от следните демони:
- nfsd - директно обслужване на протокола
NFS; - mountd - обслужване на операции по монтиране;
- rpc.portmap - демон на RPC портове; необходимо, тъй като заявките към NFS сървъра се изпращат като пакети
RPC;
Как да го направим? Много просто - отидете на файла "/etc/rc.d/rc.inet2" и разкоментирайте съответните редове. Всичко може да се счита, че първоначалното стартиране е направено, ще бъде малко по-трудно да настроите всичко ...
Първото нещо, което трябва да решите, е кой какви права има по отношение на тази или онази информация. Това се конфигурира чрез файла / etc / exports. Разрешенията са "четене" и "четене и писане". Как е конфигурирано това е описано в „Основи
NFS“.
Второто е, разбира се, натоварването на сървъра, т.е. броят на активните потребители и техните приблизителни заявки. Заявките към NFS сървъра обикновено се разделят на два типа: първият е когато клиентът работи с атрибути, а вторият е когато клиентът иска данни директно. Заявките от първия тип са търсене на файл, четене на списък с разрешения и т.н., разбира се, разбирате, че те не натоварват много мрежата. Заявките от втория тип са предаването и получаването от клиента директно на съдържанието на файловете; и тук възниква въпросът: "какво ще се предава и колко често?" Това е особено важно, ако имате мрежа от 10 Mbps (добре, с други думи, стандартна руска мрежа). Ако знаете, 10 Mbps са малко над 1 Mb в секунда; естествено, ако постоянно се прехвърлят файлове с размер десетки мегабайта, мрежата просто ще умре. Ако това е вашата ситуация, тогава ще трябва да настроите кеширане на данни на клиентската машина (biod демон). След това, след като е поискал файл и отново се позовава на него, клиентът няма да го „изтегли“ отново от сървъра, а ще го вземе от кеша; в същото време той редовно ще проверява дали файлът се е променил на сървъра, ако се разкрие фактът на промяната, тогава файлът в кеша ще бъде заменен с "нова версия"
(както можете да си представите, проверката „променен ли е файл“ е заявка „по атрибути“, която често е стотици пъти по-малка от самия файл).
Е: стартирахме NFS сървъра, определихме разрешенията за достъп, подредихме натоварването ... Сега остава да завием винта с необходимата информация и да използваме
Възможностите на NFS в най-голяма степен ...
Вместо заключение:
Ако сте изправени пред въпроса за организиране на обмена на данни в мрежата, тогава не се колебайте да изберете NFS - NFS е с три глави по-висока от една глава по-висока от
FTP е с главата и раменете над "топките" на Windows, но не е толкова трудно да се настрои ...
