Назад | Перейти на главную страницу

Клиент NFS не берет сервер после перезапуска

РЕДАКТИРОВАТЬ :

Подводя итог, можно сказать, что это проблема, связанная с изменением IP-адреса сервером NFS, а клиенты NFS не получают новый адрес. Я могу видеть через tcpdump что клиент все еще пытается связаться со старым IP-адресом на порту 2049.

У нас есть несколько точек монтирования NFS, определенных таким образом в /etc/fstab. Как видите, это NFS v3.

storage-1:/data/medias/media /var/www/myproject/data/media nfs rsize=32768,wsize=32768,hard,intr,actimeo=300,nfsvers=3,async,noatime,sec=sys 0 0
storage-1:/data/medias/secure /var/www/myproject/web/secure nfs rsize=32768,wsize=32768,hard,intr,actimeo=300,nfsvers=3,async,noatime,sec=sys 0 0
storage-1:/data/tobeprocessed /var/www/myproject/data/tobeprocessed nfs rsize=32768,wsize=32768,hard,intr,actimeo=300,nfsvers=3,async,noatime,sec=sys 0 0
storage-1:/data/ftp /var/ftp nfs rsize=32768,wsize=32768,hard,intr,actimeo=300,nfsvers=3,async,noatime,sec=sys 0 0

Когда мы перезапускаем сервер, мы должны размонтировать и снова подключить каждую конечную точку, иначе клиенты не смогут получить доступ к серверу NFS. Я пробовал через 5 минут после перезагрузки до размонтирования и повторного монтирования.

После перезапуска сервера NFS простой ls /var/www/myproject/data/media заставляет консоль зависать.

Я также вижу следующие сообщения в /var/log/syslog :

Sep 16 11:24:36 encoder-1 kernel: [69688.160102] nfs: server storage-1 not responding, still trying
Sep 16 11:30:15 encoder-1 kernel: [70027.744042] nfs: server storage-1 not responding, still trying

Когда я umount а потом mount один из каталогов nfs на клиенте, я могу получить к нему доступ. Но я не могу получить доступ к другим, если я тоже umount и mount их.

Я кто-нибудь знает возможное решение для этого, я все уши. Обратите внимание, что rpcinfo показывает, что клиент может связаться с сервером, как показано ниже.

Есть один сервер NFS, 4 клиента NFS, всего 12 точек монтирования.

Результат rpcinfo -p storage-1 от клиента:

[0]root@encoder-1:/var/log # rpcinfo -p storage-1
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  52115  status
    100024    1   tcp  57907  status
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    2   tcp   2049
    100227    3   tcp   2049
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    2   udp   2049
    100227    3   udp   2049
    100021    1   udp  59603  nlockmgr
    100021    3   udp  59603  nlockmgr
    100021    4   udp  59603  nlockmgr
    100021    1   tcp  47716  nlockmgr
    100021    3   tcp  47716  nlockmgr
    100021    4   tcp  47716  nlockmgr
    100005    1   udp    892  mountd
    100005    1   tcp    892  mountd
    100005    2   udp    892  mountd
    100005    2   tcp    892  mountd
    100005    3   udp    892  mountd
    100005    3   tcp    892  mountd

При включении трассировки отладки NFS как объяснено здесь, мы получаем следующее сообщение журнала:

Sep 17 05:35:00 encoder-1 kernel: [135112.160230] nfs: server storage-1 not responding, still trying
Sep 17 05:53:47 encoder-1 kernel: [136240.018538] NFS: nfs_lookup_revalidate(///) is valid
Sep 17 05:53:47 encoder-1 kernel: [136240.018538] NFS: revalidating (0:12/5242881)
Sep 17 05:53:47 encoder-1 kernel: [136240.018538] NFS call  getattr

Я думаю, что это может быть проблема с разрешением имени хоста. Я заметил, что даже если разрешение работает нормально, в противном случае в системе и сети у процессов монтирования NFS иногда возникают проблемы. Я бы изменил имя хоста на фактический IP-адрес и попробовал это. Допустим, полное доменное имя - storage-1.example.org, и оно разрешится до 192.0.2.11, а затем выполните:

192.0.2.11:/data/medias/media /var/www/myproject/data/media nfs bg,rsize=32768,wsize=32768,hard,intr,actimeo=300,nfsvers=3,async,noatime,sec=sys 0 0

Даже если это не решит проблему, я лично считаю, что предпочтительнее использовать IP-адрес вместо имени хоста или FQDN. Но я понимаю, что могут быть причины, по которым вы не захотите этого делать.

Заметка: Я добавил bg опция, которая будет фоновым процессом монтирования в случае, если монтирование займет больше времени, чтобы ускорить загрузку. Вам решать, хотите ли вы этого. Я подумал, что упомянул бы об этом, так как, когда существует несколько точек монтирования NFS, каждая из которых занимает больше времени (или время ожидания) для монтирования, время загрузки может легко стать больше одного часа.