16 Службы httpd2 и nfs в ОС Linux

 

httpd2

 

nfs

Сетевая файловая система (Network File System - NFS) служит для обеспечения доступа компьютерам сети к общим каталогам на сервере. Централизованное хранение файлов на сервере облегчает организацию работы в большой сети, особенно там, где один и тот же пользователь может работать в разное время на разных компьютерах. С помощью файлового сервера решается сразу несколько задач:

  1. регулярное резервное копирование всех данных: нереально выполнять эту операцию для нескольких десятков или сотен компьютеров, но вполне реально - с единственного сервера или нескольких серверов.
  2. повышение надежности хранения данных: неразумно каждый компьютер сети оснащать RAID-массивом, ведь подавляющее большинство файлов в компьютере, таких, как установленные пакеты программ, проще установить заново, чем защищать их от сбоя; но будет вполне разумным укомплектовать файловый сервер аппаратным RAID-массивом или организовать там программный RAID-массив, хотя бы простое зеркалирование дисков.
  3. уменьшение стоимости хранения данных: дорого и неэффективно в каждый компьютер устанавливать огромный диск на случай, если потребуется хранить много данных, но на сервере вполне можно установить масштабируемую дисковую подсистему большого объема.
  4. обеспечение доступа к одним и тем же данным с любого компьютера.

Описание NFS

Служба NFS позволяет серверу обеспечить разделяемый доступ к указанным каталогам его локальной файловой системы, а клиенту - монтировать эти каталоги так же, как если бы они были локальными каталогами клиента.

Версии NFS

NFS, разработанная компанией Sun Microsystems, оказалась настолько удачной, что ее реализации были воплощены разными компаниями почти во всех операционных системах. Существует несколько принципиально разных реализаций NFS. Достаточно распространена версия NFS 2.0, хотя уже в Solaris 2.5 была введена NFS 3.0. В последующих версиях Solaris, включая Solaris 9, в NFS были внесены существенные дополнения, но сам протокол остался совместимым с реализациями NFS 3.0 в других системах. Начиная с NFS 3.0, поддерживается передача пакетов посредством TCP и UDP, ранее поддерживался только UDP.

Будьте внимательны! В сети следует использовать клиенты и серверы NFS одной и той же версии. NFS 2.0 можно встретить в старых системах, например, в HP-UX 10.0. Совместная работа систем, использующих разные версии NFS , нежелательна.

Процедура монтирования общего каталога через NFS

Прежде чем мы перейдем к описанию настроек сервера и клиентов NFS, следует понять, как осуществляется монтирование удаленных файловых систем в принципе.

Клиент NFS посылает запрос на монтирование удаленному компьютеру, который предоставляет свою файловую систему (обычно - некоторую ее часть) для общего пользования. При этом говорят, что сервер NFS "экспортирует" тот или иной каталог (подразумевается - с подкаталогами). Запрос от клиента NFS попадает на обработку демону mountd. Тот выдает клиенту NFS специальный ключ. Этот ключ является идентификатором, который однозначно идентифицирует каталог, смонтированный по сети.

По NFS можно смонтировать как целые файловые системы, так и отдельные каталоги. Из соображений безопасности запрещено монтировать каталоги "через раздел". Это означает, что если каталог /var расположен на одном разделе диска, а каталог /var/adm - на другом, то при монтировании каталога /var каталог /var/adm не будет автоматически смонтирован. Если требуется монтировать те подкаталоги экспортируемого каталога, которые расположены в другой файловой системе (на другом разделе), следует экспортировать их отдельно и указывать в /etc/dfs/dfstab еще один разделяемый каталог - тот самый подкаталог с другого раздела.

Ключ, выданный клиенту при монтировании и идентифицирующий сеанс работы с данным удаленным каталогом, сохраняется при перезагрузке NFS-сервера, чтобы после восстановления его работы клиенты, замершие в ожидании, продолжили работу с удаленным сервером как ни в чем ни бывало. При демонтировании и новом монтировании файловой системы через NFS ключ обычно изменяется. На практике перезагрузка NFS-сервера все-таки может привести к сбою в работе клиентского приложения, особенно, если приложение читает или записывает файл в удаленный каталог во время перезагрузки.

После монтирования файловой системы через NFS клиент посылает серверу запросы на передачу и прием файлов, эти запросы обрабатывает демон nfsd.

Демонтирование файловой системы NFS выполняется так же, как и демонтирование любой другой файловой системы - командой umount.

Ниже будут обсуждены следующие аспекты настройки службы NFS в сети:

Настройка NFS-сервера

Для настройки NFS сервера нам потребуется выполнить настройку как минимум трех приложений: rpcbind, mountd и nfsd. Прежде всего, создадим файл /etc/dfs/dfstab, в котором опишем экспортируемые каталоги; в отличие от других систем UNIX, Solaris требует указать здесь не просто список каталогов с параметрами монтирования, а набор команд share, которые фактически и запускают экспорт каталогов. Таким образом, получается, что /etc/dfs/dfstab - это скрипт, который выполняется для того, чтобы сделать общие каталоги доступными для монтирования через сеть.

Проверка работоспособности служб NFS

Теперь необходимо проверить, правильно ли запущены mountd и nfsd. Сначала это делается с помощью команды rpcinfo -p.

100000   4             tcp           111         rpcbind
100000   3             tcp           111         rpcbind
100000   2             tcp           111         rpcbind
100000   4             udp          111         rpcbind
100000   3             udp          111         rpcbind
100000   2             udp          111         rpcbind
100003   2             udp          2049       nfs
100003   3             udp          2049       nfs
100005   3             udp          1023       mountd
100005   3             tcp           1023       mountd
100005   1             udp          1023       mountd
100005   1             tcp           1023       mountd

Как видно, rpcbind успешно анонсирует службы.

Если в ответ на rpcinfo -p мы получили сообщение

rpcinfo: can't con

или

RPC_PROG_NOT_REGISTERED

или нечто похожее вместо ожидаемого - стало быть, rpcbind не доступен (отключен). Возможно, в файлах /etc/hosts.allow или /etc/hosts.deny есть настройки, запрещающие программе rpcbind отвечать нам.

Для перезапуска служб NFS можно завершить выполнение демонов nfsd, mountd и rpcbind, и потом запустить их вновь в таком порядке: rpcbind, затем mountd и nfsd. Программе nfsd может быть передан числовой аргумент - число потоков, которые следует запустить при старте. Программа "распараллелится" в указанном количестве потоков.

Более стандартным выходом является запуск скрипта

/etc/init.d/nfs.server

вначале с параметром stop, затем с параметром start.

При штатной работе mountd и nfsd запускаются на сервере NFS при старте системы из стартовых скриптов. Это можно проверить командами

ps -ef | grep mountd 
ps -ef | grep nfsd

Программа rpcbind объявляет свои службы независимо от того, продолжают ли работать программы, ранее зарегистрировавшиеся и (возможно) прекратившие работу вследствие аварии.

Следовательно, вышеприведенная проверка с помощью ps обязательна, если служба NFS перестала работать.

Заключение

Совместный доступ к данным существенно упрощает процесс интеграции ваших UNIX и Linux систем. Если вы обеспечите совместный доступ к учетным данным, а также к другой пользовательской информации, ваши пользователи смогут входить в систему и работать на машинах UNIX и Linux, не задумываясь о необходимости запоминать несколько разных паролей. Настроив совместное использование данного функционала с функционалом NFS, вы можете предоставлять пользователям общий доступ к файлам. Если при этом вы используете автоматическое монтирование домашних каталогов, то независимо от операционной системы или компьютеров, за которыми работают пользователи, они смогут использовать свои файлы и ресурсы так, будто эти файлы расположены на локальном диске.

 

Hosted by uCoz