Как и при работе с другими сетевыми службами, в Сетевой файловой системе (NFS) могут возникнуть неполадки. Для их устранения необходимо: определить стратегию поиска неполадки NFS, проанализировать сообщения об ошибках, относящиеся к NFS и, наконец, определить требуемые действия по исправлению. На этапе поиска неполадки NFS рекомендуется определить, на каком из трех возможных объектов возникла ошибка: на сервере, на клиенте или в самой сети.
Примечание: Устранение неполадок с блокировками описано в разделе Устранение неполадок Диспетчера сетевой блокировки.
В случае неполадок сервера и сети сбои программ, работающих с мягко и жестко смонтированными удаленными файлами, проявляются по-разному.
Если сервер не отвечает на запрос о жестком монтировании файла, NFS выдает следующее сообщение:
Сервер имя-хоста NFS не отвечает, запрос будет повторен
Жестко смонтированные файловые системы приводят к зависанию программ до момента ответа сервера, поскольку клиент продолжает повторять запрос на монтирование до тех пор, пока он не будет принят. Если в команде mount указан флаг -bg, при сбое на сервере клиент будет повторять запросы на монтирование в фоновом режиме.
В случае, если сервер не отвечает на запрос о мягком монтировании файла, NFS выдает следующее сообщение:
Тайм-аут соединения
Мягко смонтированные удаленные файловые системы после нескольких неудачных запросов прекращают попытки и возвращают сообщение об ошибке. К сожалению, многие программы не проверяют состояние после выполнения операций с файловой системой, поэтому при обращении к "мягко" смонтированным файлам вы не видите этих сообщений об ошибках. Однако, на консоли будет показано сообщение об ошибке сервера NFS.
Если на клиенте NFS возникла ошибка, выполните следующие действия:
/usr/bin/rpcinfo -p имя-сервера
Если сервер работает, то будет показан список используемых программ, версий, протоколов и номеров портов:
версия протокол порт программа 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100005 1 udp 1025 mountd 100001 1 udp 1030 rstatd 100001 2 udp 1030 rstatd 100001 3 udp 1030 rstatd 100002 1 udp 1036 rusersd 100002 2 udp 1036 rusersd 100008 1 udp 1040 walld 100012 1 udp 1043 sprayd 100005 1 tcp 694 mountd 100003 2 udp 2049 nfs 100024 1 udp 713 status 100024 1 tcp 715 status 100021 1 tcp 716 nlockmgr 100021 1 udp 718 nlockmgr 100021 3 tcp 721 nlockmgr 100021 3 udp 723 nlockmgr 100020 1 udp 726 llockmgr 100020 1 tcp 728 llockmgr 100021 2 tcp 731 nlockmgr
Если подобный вывод не будет получен, войдите в систему сервера и проверьте состояние демона inetd, следуя инструкциям из раздела Получение текущего состояния демонов NFS.
/usr/bin/rpcinfo -u имя-сервера mount /usr/bin/rpcinfo -u имя-сервера portmap /usr/bin/rpcinfo -u имя-сервера nfs
Если программы-демоны на сервере запущены, появятся такие сообщения:
программа 100005 версия 1 готова и ждет программа 100000 версия 2 готова и ждет программа 100003 версия 2 готова и ждет
Номера программ соответствуют командам, показанным в предыдущем примере. Если подобный вывод не будет получен, войдите в систему сервера и проверьте состояние демонов, следуя инструкциям из раздела Получение текущего состояния демонов NFS.
showmount -e имя-сервера
Будет показан список файловых систем, экспортированных в настоящее время на сервере.
Когда приложение отправляет запрос на запись в файл смонтированной файловой системы NFS, демон biod планирует асинхронную обработку операции записи. Если ошибка на сервере NFS возникает непосредственно в момент записи данных на диск, то клиенту NFS возвращается сообщение об ошибке, а демон biod сохраняет данные о возникшей ошибке во внутренних структурах данных системы NFS. Затем, при повторном вызове приложением функции fsync или close, сохраненное сообщение об ошибке снова возвращается приложению. При подобных ошибках приложение не получит уведомления об ошибке записи до тех пор, пока не закроет файл. Типичный пример - ситуация, когда в файловой системе на сервере отсутствует свободное дисковое пространство, из-за чего клиенты не могут выполнить запись в файл.
В данном разделе приведены описания кодов ошибок, которые могут возникнуть при работе с NFS.
Недостаточное количество буферов передачи в сети может привести к следующей ошибке:
nfs_server: bad sendreply
Для увеличения числа буферов передачи запустите Web-администратор системы, wsm, или команду SMIT smit commodev. Затем выберите тип адаптера и увеличьте число буферов передачи.
При монтировании файловой системы могут возникнуть сбои нескольких типов. Примеры сообщений об ошибках монтирования приведены ниже:
Если в команде mount задано только имя каталога или только имя файловой системы, то за недостающими данными команда обращается к файлу /etc/filesystems, в котором находит запись для указанного имени файловой систем или каталога. Если команда mount обнаруживает следующую запись:
/dancer.src:
dev=/usr/src
nodename = d61server
type = nfs
mount = false
то она может выполнить монтирование так, как если бы все необходимые данные были заданы ей в командной строке:
/usr/sbin/mount -n dancer -o rw,hard /usr/src /dancer.src
Проверьте правильность написания и синтаксис команды mount. Если команда была введена правильно, в сети отсутствует NIS, и подобное сообщение получено только для данного хоста, то проверьте соответствующую запись в файле /etc/hosts.
Если в сети установлена NIS, то проверьте, работает ли демон ypbind, введя в командной строке следующую команду:
ps -ef
Если демон ypbind запущен, он должен быть показан в списке. С помощью команды rlogin попробуйте подключиться к другому удаленному компьютеру, или попробуйте скопировать какой-либо файл на удаленный компьютер с помощью команды rcp. Если и эти попытки не увенчаются успехом, то это значит, что скорее всего демон ypbind завершил работу или завис.
Если указанное сообщение выводится только для одного хоста, проверьте запись /etc/hosts на сервере NIS.
Если вы не можете подключиться к удаленному серверу командой rlogin, попробуйте подключиться к какому-либо другому удаленному компьютеру, чтобы проверить исправность работы сети. Также рекомендуется проверить связь сервера с сетью.
Получить список экспортированных сервером файловых систем можно с помощью следующей команды:
showmount -e имя-хоста
Если целевая система отсутствует в списке, а также если ваша система или группа отсутствует в списке пользователей файловой системы, войдите в систему сервера и исправьте файл /etc/exports. Если имя файловой системы указано в файле /etc/exports, но отсутствует в списке, который выводит на экран команда showmount, то это указывает на ошибку демона mountd. Вероятно, демон либо не смог проанализировать данную строку в файле, ему не удалось найти каталог, или данный каталог не был смонтирован на этом компьютере. Если записи в файле /etc/exports верны, и в вашей сети работает система NIS, то рекомендуется проверить работу демона ypbind на сервере. Возможно, ее работа была завершена или она зависла. Дополнительная информация приведена в книге AIX 5L Version 5.1 Network Information Services (NIS and NIS+) Guide.
Проверьте правильность файла /etc/exports на сервере и, если это необходимо - работу демона ypbind. Вы можете исправить имя хоста с помощью команды hostname и после этого повторить команду mount.
Медленный доступ к удаленным файлам может быть связан с перегрузкой демона или плохой линией tty.
Введите следующую команду в командной строке сервера:
ps -ef
Если сервер работает нормально и своевременно отвечает на запросы остальных пользователей, проверьте, запущен ли демон biod. Выполните следующие шаги:
Если эти демоны не запущены, перейдите к пунктам 2 и 3.
stopsrc -x biod -c
startsrc -s biod
Для проверки работы демонов biod, если вы подозреваете, что часть из них зависли, запустите несколько раз команду nfsstat -c. Если число операций чтения и записи клиентом с помощью Вызова удаленных процедур (RPC) не изменится, по крайней мере один из демонов biod не выполнил запрос. Определение конкретного неактивного демона biod таким образом невозможна.
Если демоны biod работают, проверьте сетевые соединения. Команда nfsstat определяет, происходит ли потеря пакетов. С помощью команд nfsstat -c и nfsstat -sопределите, не выполняет ли сервер или клиент повторную передачу больших блоков. Из-за потери пакетов и перегрузки серверов всегда есть вероятность повторной передачи. Величина в 5% повторных передач считается большой.
Для уменьшения вероятности повторной передачи следует изменить параметры очереди передачи адаптера связи. Эти параметры можно изменить с помощью SMIT.
Ниже приведены рекомендуемые
значения для серверов NFS.
| Размер максимального блока передачи (MTU) для адаптера связи и очереди передачи | ||
| Адаптер | MTU | Очередь передачи |
| Token-Ring
4 Мб 16 Мб |
1500 3900 1500 8500
|
50 40 (Увеличьте в случае тайм-аута команды nfsstat.) 40 (Увеличьте в случае тайм-аута команды nfsstat.)
|
| Ethernet | 1500 | 40 (Увеличьте в случае тайм-аута команды nfsstat.) |
Чем больше размер MTU для каждого соединения Token-Ring, тем меньше нагрузка на процессор, и тем лучше выполняются операции чтения/записи.
Примечания:
Задать размер MTU можно либо с помощью Web-администратора системы, wsm, либо командой smit chif. Выберите соответствующий адаптер и введите в поле Максимальный размер пакета IP значение размера MTU.
Для установки размера MTU можно также использовать команду ifconfig (ее необходимо использовать, если вы хотите задать значение размера MTU 8500). Команда ifconfig имеет следующий формат:
ifconfig trn имя-узла up mtu размер-MTU
где trn - имя данного адаптера, например, tr0.
Другой способ задания размеров MTU заключается в применении команды ifconfig и SMIT.
Размер очереди передачи адаптера связи устанавливаются с помощью SMIT. Введите команду быстрого доступа smit chgtok, выберите соответствующий адаптер и введите значение размера очереди в поле Передача.
При зависании программ во время выполнения операций с файлами сервер NFS может перестать работать. В этом случае появится следующее сообщение об ошибке:
Сервер NFS имя-хоста не отвечает, запрос будет повторен
Сервер NFS имя выключен. Подобное сообщение означает, что возникла ошибка либо на сервере NFS, либо в сети, либо на сервере NIS.
Если ваш компьютер полностью завис, проверьте серверы, с которых были смонтированы файловые системы. Если один или несколько из этих серверов не работают, то никаких действий предпринимать не нужно. Программы автоматически возобновят работу вместе с сервером. Файлы повреждены не будут.
Выход из строя сервера, с которого было произведено мягкое монтирование, не повлияет на работу других программ. Если при попытках доступа к файловым системам "мягкого" монтирования возник тайм-аут, программа прекращает попытки, выдав сообщение об ошибке с кодом errno. При этом доступ к остальным файловым системам не теряется.
Если все серверы работают нормально, выясните, не возникли ли неполадки при работе с этими же серверами у других клиентов. Если трудности возникли у нескольких клиентов, это указывает на неполадки в работе программ-демонов nfsd но сервере. В таком случае войдите в систему сервера и запустите команду ps чтобы выяснить, работает ли демон nfsd (потребляет ли он ресурсы CPU). Если выяснится, что этого не происходит, завершите и перезапустите демон nfsd. Если эти действия не помогут, необходимо перезагрузить сервер.
Если остальные системы включены и нормально работают, проверьте соединения вашего компьютера с сервером и с сетью в целом.
Иногда после успешного монтирования каталогов возникают ошибки при чтении, записи или создании удаленных файлов и каталогов. Как правило, подобные сложности возникают из-за неполадок, связанных с правами доступа и идентификацией. Причины неполадок, связанных с правами доступа и идентификацией, могут отличаться, в зависимости от того, используется ли система NIS, и выполняется ли защищенное монтирование.
Если применяется незащищенное монтирование и NIS не используется, то устранить ошибки достаточно просто. В этом случае идентификаторы пользователей (UID) и групп (GID) преобразуются с помощью файлов /etc/passwd сервера и /etc/group клиента. При этом пользователь B для правильной идентификации должен обладать в обеих системах одинаковым UID в файлах /etc/passwd. Ниже показано, каким образом это может привести к неполадкам:
UID пользователя B в системе клиента foo равен 200. UID пользователя B в системе сервера bar равен 250. UID пользователя G в системе сервера bar равен 200.
Каталог /home/bar смонтирован с сервера bar на клиенте foo. Когда пользователь B в системе клиента foo редактирует файлы удаленной файловой системы /home/bar, в момент сохранения файла возникает конфликт.
Сервер bar считает, что файл принадлежит пользователю G, поскольку в системе bar идентификатор 200 соответствует пользователю G. Когда пользователь B напрямую подключится к серверу bar с помощью команды rlogin, файлы, только что созданные им при работе через удаленную смонтированную файловую систему, могут оказаться недоступными. Однако пользователю G эти файлы будут доступны, поскольку права доступа предоставляются не по имени пользователя, а по его UID.
Для того чтобы исправить эту ошибку, следует заново задать правильные UID на обоих компьютерах. Например, присвойте пользователю B номер UID 200 на сервере bar или номер 250 на клиенте foo. Затем к файлам, принадлежащим пользователю B, необходимо применить команду chown, чтобы они соответствовали новому идентификатору в соответствующей системе.
Поскольку поддерживать согласованность UID и GID во всех системах сети вручную сложно, часто для выполнения всех необходимых преобразований применяется NIS или NIS+. Более подробная информация приведена в книге AIX 5L Version 5.1 Network Information Services (NIS and NIS+) Guide.
При получении запроса на монтирование сервер NFS определяет имя запрашивающего клиента. Сервер преобразует IP-адрес (адрес протокола Internet) запрашивающего клиента в имя хоста. После выяснения имени хоста сервер обращается к списку экспорта запрашиваемого каталога и проверяет, присутствует это имя в списке доступа к данному каталогу. Если запись для этого клиента имеется, и имя хоста указано правильно, это означает, что первый этап идентификации пройден успешно.
Если серверу не удается выполнить преобразование IP-адреса в имя хоста, то сервер отклоняет запрос на монтирование. Для выполнения запроса на монтирование серверу необходимо преобразовать IP-адрес клиента в соответствующее имя. Даже если доступ к экспортированному каталогу разрешен для всех клиентов, то для того, чтобы разрешить его монтирование, сервер должен выполнить обратное преобразование имени.
Также необходимо, чтобы сервер мог правильно выяснить имя клиента. Например, если в файле /etc/exports существует следующая запись:
/tmp -access=silly:funny
В файле /etc/hosts ей соответствуют следующие записи:
150.102.23.21 silly.domain.name.com 150.102.23.52 funny.domain.name.com
Обратите внимание, что имена не совсем совпадают. Имена хостов silly и funny, найденные сервером в списке доступа к экспортированному каталогу, не совпадают точно с именами, преобразованными из IP-адресов хостов. Подобные трудности обычно возникают в случае, если преобразование имен выполняет демон named. Большинство баз данных демонов named содержат псевдонимы полных имен хостов домена, чтобы при обращении к хостам не требовалось вводить их полные имена. И, хотя записи преобразования имени хоста в IP-адрес существуют для всех псевдонимов, возможности обратного преобразования может и не быть. База данных обратного преобразования имен (IP-адреса в имя хоста) состоит из записей, содержащих IP-адрес и полное имя домена каждого хоста, но не его псевдоним. Иногда в записях списка экспортированных каталогов указывают сокращенные псевдонимы, что вызывает трудности при монтировании.
NFS версии 3.2 не позволяет пользователю быть членом более 16 групп. В противном случае возникают неполадки. (Группы определяются командой groups.) Пользователь, входящий в 17 или более групп, не сможет получить доступ к файлам, принадлежащим семнадцатой (или большей по порядку) группы. Для того чтобы пользователь смог получить к ним доступ, нумерацию групп придется изменить.
В случае, если каталог NFS монтируется клиентом с с сервера версии 3 (или более ранней) и пользователь входит более чем в 8 групп, могут возникать ошибки. Некоторые серверы вообще не справляются с подобной задачей и отклоняют запрос на монтирование. Для того чтобы обойти это ограничение, необходимо изменить количество групп, в которые входит пользователь, на значение, меньшее 8, а затем повторить попытку монтирования. Обычно при подобных неполадках появляется следующее сообщение об ошибке:
RPC: Ошибка идентификации; why=Неправильное одноразовое разрешение клиента
Некоторые команды NFS выполняются неправильно, если не загружено расширение ядра NFS. Вот некоторые из таких команд: nfsstat, exportfs, mountd, nfsd и biod. При установке на компьютер системы NFS расширение ядра помещается в файл /usr/lib/drivers/nfs.ext. Затем, после настройки системы, этот файл загружается в качестве расширения ядра NFS. Файл /etc/rc.net загружается специальным сценарием. Этот сценарий выполняет множество других функций, в частности загрузку расширения ядра NFS. Важно учесть, что расширение ядра TCP/IP (Протокола управления передачей/протокола Internet) необходимо загружать перед расширением ядра NFS.
Примечание: Для загрузки расширения NFS в ядро во время начальной загрузки системы применяется команда gfsinstall. Эту команду можно выполнять в процессе загрузки системы несколько раз, это не вызовет никаких ошибок. В настоящее время вместе с системой поставляется команда gfsinstall, которая применима для обоих файлов /etc/rc.net и /etc/rc.nfs. Отменять какой-либо из этих вызовов не нужно.