Даже в Windows можно активировать поддержку этого протокола.
Наверное из-за такой прозрачной интеграции часто возникают коллизии и недопонимания при настройке NFS. Помните, я писал про важность синхронизации времени на сервере и клиенте?
В конце прошлого года я столкнулся с ещё одной интересной ситуацией. Эта интересная ситуация лишила меня покоя на 3 дня. :) Сейчас всё расскажу по порядку.
Сервер, работающий на операционной системе HP-UX 11.11. Версия старая, согласен, но работает хорошо. И, как говорится, что есть, с тем и работаем. Так вот, данный сервер, в разрезе NFS является сервером, раздавая часть своих файловых систем для других систем, и одновременно клиентом, монтируя пару файловых систем по протоколу NFS с других серверов.
В один момент времени один из серверов, файловую систему с которого наш герой монтировал, пропал. За сервер отвечает третья сторона, поэтому причины падения я не знаю. Но сервер с HP-UX повёл себя следующим образом. Файловая система просто "зависла". Зависали любые попытки перейти в директорию, которая является точкой монтирования злополучной NFS файловой системы, операции-попытки прочитать таблицу файловых систем (команда bdf), команды просмотра содержимого файловой системы и тому подобное.
Команда umount файловой системы не проходила, отвечая, что файловая система "занята" процессами системы: "nfs umount: nfs_unmount: /path: is busy".
Все вы знаете, наверное, команду fuser, которая показывает список процессов, которые держат файлы файловой системы. Так вот, эта команда с опцией, в которой я указывал точку монтирования тоже жестко зависала. Таким образом, я плодил процессы, которые держали файловую систему.
Зная, что команды bdf, fuser висят по моей вине, я нашёл их в таблице процессов командой вида:
# ps -ef | grep bdfВсе они стали сиротами, то есть родительский процесс у них заменился процессом init: PPID=1.
Но на моё удивление, попытки послать им команды останова вида:
# kill -9 PIDни к чему не приводили. Они продолжали сиротливо висеть в таблице процессов, дополнительно удерживая злополучную файловую систему.
Дальше, стало еще интереснее. Третья сторона, после сообщения им, что их NFS ресурс не отвечает, отработала и ответила, что сервер восстановлен. Но, у меня на стороне NFS клиента ничего не изменилось! Файловая система не отвечает, наглухо зависнув. В таблице процессов список уже из 7-8 сирот, которые пытались попасть на файловую систему с моей подачи.
При этом, команды ping на сервер проходят, команда вида:
# telnet 2049где 2049 это NFS порт, отрабатывает корректно. Даже команда запроса экспортируемых файловых систем с NFS сервера (showmount -e IP_NFS_server) отрабатывает! А попытка выполнить монтирование этой файловой системы во временную точку монтирования (/tmp/tmp2) не удаётся! (рис. 1).
 |
| Рис. 1. Попытки достучаться до NFS-сервера. |
Не верить специалистам третьей стороны у меня причин не было. Занимаясь поиском путей решения на специализированных форумах в Интернете, я всё больше и больше убеждался, что проблема в HP-UX, то есть в NFS клиенте.
Выбрав период, когда я смогу устроить небольшой downtime для монтируемых по NFS файловых систем, я решил попробовать рестарт демонов nfs.client. Демон остановился и стартовал корректно, но отмонтировать данную файловую систему не смог. "nfs umount: nfs_unmount: /path: is busy" - ответила система. :) Рестартовать все NFS-процессы (серверные и клиентские) я не мог из-за использования текущего сервера, как NFS-сервера.
На форумах я узнал, что самое часторекомендуемое простое решение - это выполнить reboot сервера NFS клиента. Но это было крайне нежелательно для данной системы, и на это я пойти пока не мог.
Так же я узнал, что в данной ситуации команда bdf в силу своей особенности не рекомендуется (зависает), лучше использовать:
# mount -vА команде fuser надо в качестве аргумента давать не локальную точку монтирования, а путь до NFS сервера + директорию:
# fuser IP:/pathТакой вариант команды fuser у меня не зависал, отрабатывал, но ни одного процесса не находил. Да, и по предыдущему опыту я знал, что спящие процессы сигналы от команды kill не принимают.
Замкнутый круг. Примерная картина мне была понятна, но решения не было. Я всё больше и больше с тяжёлым сердцем думал о перезагрузке всей операционной системы.
Чтобы еще раз исключить проблемы с NFS сервером, я попытался выполнить временное монтирование нужной мне файловой системы на другой сервер. Попытка удалась. То есть всё сводилось к тому, что проблема на конкретном сервере.
Знаете пословицу: одна голова хорошо, а две лучше? Иногда одна лишь попытка описать проблему, систематизировав все симптомы, помогает. Но чаще, другой человек, со своим свежим взглядом на то, над чем ты бьёшься несколько дней, задаёт новые вопросы, предлагает новые пути решения, а иногда и даёт готовое решение. В этой ситуации для меня стал таким человеком мой коллега (Сергей Шевелёв). Готового решения он мне не дал, но нашел для меня документ "Forcible Unmount NFS filesystems", в котором была описана моя проблема и пути решения.
В данном документе инженер HPE, признавал проблему, описывал ситуации когда она может возникнуть и, если кратко, давал следующие советы:
- Применять команду fuser не на точку монтирования, а на NFS-путь, о чём я писал выше.
- Иногда бывает достаточно несколько минут подождать, пока процессы остановятся по timeout и отпустят файловую систему.
- Создать временный суррогатный NFS сервер, чтобы процессы, которые держат файловую систему получили отклик и остановились с ошибкой.
В документе автор признаёт, во-первых, что такая проблема зависших NFS файловых систем существует в HP-UX. Во-вторых, что в текущих релизах HP-UX (до версии 11.23) официального решения нет. Что в версию HP-UX 11.31 добавят опцию "-f" в команду umount, по которой будет производиться принудительное отмонтирование NFS файловых систем без ожидания освобождения их со стороны процессов системы. Такая опцию, к слову, есть в других операционных системах.
Прочитав этот основательный документ (15 страниц), я попробовал создать суррогатный NFS сервер прямо на текущем сервере. Процедура следующая:
- Необходимо определить IP адрес NFS сервера, который упал. Для этого смотрим вывод команды mount -v, а потом nslookup NFS_server_hostname.
- Находим сервер, на котором поднят nfs.server и смотрим доступные сетевые интерфейсы командой netstat -in. В идеале можно использовать сервер, который является NFS клиентом.
- На интерфейсе, который входит в ту же сеть, что и пропавший NFS сервер, поднять суррогатный сервер, выполнив команду вида: ifconfig lanX:1 IP_NFS_server. Здесь lanX - название необходимого сетевого интерфейса, а "1" - второй IP адрес на этом интерфейсе.
- Пробуем размонтировать файловую систему, дав если придётся, небольшой timeout процессам, которые удерживают файловую систему.
- После успешного отмонтирования файловой системы, удаляем суррогатный NFS-сервер, командой вида: ifconfig lanX:1 0.0.0.0.
Как только я поднял на одном из сетевых интерфейсов моего сервера IP адрес NFS сервера, все спящие процессы (bdf, fuser и другие) тут же отвалились (скорее всего с ошибками). После этого корректно отработала команда:
# umount IP:/pathИ я смог вздохнуть с облегчением, удалив суррогатный сервер.
Спустя какой-то период времени файловая система настоящего NFS-сервера корректно примонтировалась, то есть операционная система увидела его, выйдя из заколдованного круга.
Получилось очень многословно, поэтому буду заканчивать. В документе от HPE разложено всё по полочкам, объяснены такие моменты как:
- почему команда fuser не выдает в результатах процессы, хотя файловая система занята (виноват buffer cache memory),
- чем плохо использование команды umount с опцией "-f" для принудительного размонтирования,
- почему зависшие процессы не реагируют на команду kill -9 (процессы ждут I/O, а значит уходят на непрерываемый уровень ядра операционной системы),
- какие меры можно принять, чтобы похожая ситуация возникала реже (установка патчей на операционную систему, в особых ситуациях использование метода "soft" при монтировании NFS файловых систем и т.д.).
Допускаю, что в современных Unix-like операционных системах такого безобразия нет, но у кого HP-UX рекомендую скачать и ознакомиться с документом. Предупреждён, значит вооружён. :)
Скачать документ можно по ссылке на официальном сайте HPE.
Автор: Шиболов Вячеслав Анатольевич
