Мониторинг монтирования NFS на наличие

Проблема, которую мы видим, заключается в том, что некоторые из наших подключенных каталогов NFS исчезают. Буквально просто исчезает. Они продолжают существовать на стороне сервера.

На клиентском компьютере (CentOS 7.4, использующем http://elrepo.org/tiki/kernel-ml версии 4.16.6, nfs-utils-1:1.3.0-0.48.el7) конец диска не отвечает. Звонки в ls /mountpoint просто повесить. ОС по-прежнему считает, что диск смонтирован - перезагрузка сервера требует полной перезагрузки, поскольку процесс выключения зависает при размонтировании диска.

В журналах мы видим очень мало - на стороне сервера мы ничего не видим. Иногда, но не каждый раз, когда мы видим что-то подобное в / var / log / messages на клиенте:

May 29 16:55:22 papr-res-compute06 kernel: INFO: task STAR:1370 blocked for more than 120 seconds. May 29 16:55:22 papr-res-compute06 kernel: Not tainted 4.16.6-1.el7.elrepo.x86_64 #1 May 29 16:55:22 papr-res-compute06 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. May 29 16:55:22 papr-res-compute06 kernel: STAR D 0 1370 1351 0x00000080 May 29 16:55:22 papr-res-compute06 kernel: Call Trace: May 29 16:55:22 papr-res-compute06 kernel: __schedule+0x290/0x890 May 29 16:55:22 papr-res-compute06 kernel: ? out_of_line_wait_on_atomic_t+0x110/0x110 May 29 16:55:22 papr-res-compute06 kernel: schedule+0x36/0x80 May 29 16:55:22 papr-res-compute06 kernel: io_schedule+0x16/0x40 May 29 16:55:22 papr-res-compute06 kernel: bit_wait_io+0x11/0x50 May 29 16:55:22 papr-res-compute06 kernel: __wait_on_bit+0x66/0x90 May 29 16:55:22 papr-res-compute06 kernel: out_of_line_wait_on_bit+0x91/0xb0 May 29 16:55:22 papr-res-compute06 kernel: ? bit_waitqueue+0x40/0x40 May 29 16:55:22 papr-res-compute06 kernel: nfs_wait_on_request+0x4b/0x60 [nfs] May 29 16:55:22 papr-res-compute06 kernel: nfs_lock_and_join_requests+0x12a/0x540 [nfs] May 29 16:55:22 papr-res-compute06 kernel: ? radix_tree_lookup_slot+0x22/0x50 May 29 16:55:22 papr-res-compute06 kernel: nfs_updatepage+0x120/0x9f0 [nfs] May 29 16:55:22 papr-res-compute06 kernel: ? nfs_flush_incompatible+0xc5/0x1c0 [nfs] May 29 16:55:22 papr-res-compute06 kernel: nfs_write_end+0xe2/0x3c0 [nfs] May 29 16:55:22 papr-res-compute06 kernel: generic_perform_write+0x10b/0x1c0 May 29 16:55:22 papr-res-compute06 kernel: ? _cond_resched+0x19/0x30 May 29 16:55:22 papr-res-compute06 kernel: ? _cond_resched+0x19/0x30 May 29 16:55:22 papr-res-compute06 kernel: nfs_file_write+0xd4/0x250 [nfs] May 29 16:55:22 papr-res-compute06 kernel: do_iter_readv_writev+0x109/0x170 May 29 16:55:22 papr-res-compute06 kernel: do_iter_write+0x7f/0x190 May 29 16:55:22 papr-res-compute06 kernel: vfs_writev+0x84/0xf0 May 29 16:55:22 papr-res-compute06 kernel: ? handle_mm_fault+0x102/0x220 May 29 16:55:22 papr-res-compute06 kernel: ? _cond_resched+0x19/0x30 May 29 16:55:22 papr-res-compute06 kernel: do_writev+0x61/0xf0 May 29 16:55:22 papr-res-compute06 kernel: SyS_writev+0x10/0x20 May 29 16:55:22 papr-res-compute06 kernel: do_syscall_64+0x79/0x1b0 May 29 16:55:22 papr-res-compute06 kernel: entry_SYSCALL_64_after_hwframe+0x3d/0xa2 May 29 16:55:22 papr-res-compute06 kernel: RIP: 0033:0x7f0cc1563230 May 29 16:55:22 papr-res-compute06 kernel: RSP: 002b:00007fff6f75f2c0 EFLAGS: 00000293 ORIG_RAX: 0000000000000014 May 29 16:55:22 papr-res-compute06 kernel: RAX: ffffffffffffffda RBX: 0000000000002025 RCX: 00007f0cc1563230 May 29 16:55:22 papr-res-compute06 kernel: RDX: 0000000000000002 RSI: 00007fff6f75f300 RDI: 000000000000000a May 29 16:55:22 papr-res-compute06 kernel: RBP: 000000001a7b0860 R08: 0000000000000000 R09: 00007f0cc15b8a00 May 29 16:55:22 papr-res-compute06 kernel: R10: cccccccccccccccd R11: 0000000000000293 R12: 000000000000000a May 29 16:55:22 papr-res-compute06 kernel: R13: 00007fff6f75f300 R14: 0000000000000028 R15: 0000000000001ffd

Мы не можем воспроизвести эту ошибку надежно. Существует очень мало общего между случаями падения дисков - это на HPC с около 40 серверами и 100 пользователями. Обычно влияет только на один сервер, но происходит на аппаратном уровне (Cisco UCSB-B200-M4 с 368 ГБ и UCSME-142-M4 с 32 ГБ). Общим является то, что на этих дисках хранятся биологические данные, которые могут быть очень большими файлами (иногда более половины ТБ).

Итак, мы хотели бы следить за тем, чтобы диски NFS работали, потому что SLURM продолжает назначать задания серверам, у которых есть эта проблема, и эти задания никогда не завершатся.

Мой коллега создал несколько сценариев оболочки, которые ping это и ls что и написать в файл и по электронной почте, когда это необходимо. Это умно и было бы интересно написать (awk!, вырезать!), Но это абсолютно (на мой взгляд) неправильный способ сделать это.

Быстрый Google показывает, что nfsiostat может быть полезно, но мало хороших инструкций, то, что там, похоже, не отображается в нашей ОС (в частности, "количество" необходимо, несмотря на то, что написано на странице руководства) и, самое главное, мы не хотим статистика по использованию. Мы хотим информацию о существовании. Буквально "ты там nfsdrive, это я рут?" Я признаю, что мне нужно больше узнать о nfsiostat.

Другое решение, которое я видел, - перейти от монтирований nfs, перечисленных в fstab, к использованию autofs. Документы CentOS заканчивают две версии назад, но заявляют:

Это не проблема для одного или двух монтирований, но когда система поддерживает монтирование на нескольких системах одновременно, это может повлиять на общую производительность системы.

Учитывая, что у нас есть около 10-12 точек монтирования - это считается столько же? Мой коллега предположил, что многие были больше в сфере сотен. Несмотря на это, эта информация сейчас старая. Изучая документы Redhat, мы видим, что это копия / вставка.

Я видел эти две ошибки / ошибки

но мы не можем обновить сразу, потому что серверы производственные и в клинических условиях. Кроме того, нет никаких указаний на то, что это явная наша проблема, и, учитывая, что мы не можем воспроизвести проблему по своему желанию, мы не можем тестировать ее на наших устройствах разработки - хотя я пытался воспроизвести на наших устройствах разработки. Существуют также более поздние версии El-Repo kernel-ml, но существует та же проблема - нельзя просто обновлять в одночасье - эти серверы часто работают на 100% круглосуточно.

Итак, я думаю, у меня есть два вопроса:

  • Каков наилучший метод, который люди знают для мониторинга существования диска (т. е. grepping mount является неприемлемым ответом)
  • должны ли мы перейти с / etc / fstab на autofs (что, если бы нам пришлось сделать, возможно, включало бы обновление ядра и ОС)
Источник

0 ответов

Другие вопросы по тегам