Проблема, которую мы наблюдаем, заключается в том, что некоторые из наших смонтированных каталогов NFS исчезают. Буквально просто исчезает. Они продолжают существовать на стороне сервера.
На клиенте (CentOS 7.4, используя ядро-мл эл-репо в версии 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 !, cut!), Но это абсолютно (на мой взгляд) неправильный способ сделать это.
Быстрый гугл показывает, что nfsiostat может быть полезно, но хороших инструкций мало, то, что есть, похоже, не соответствует нашей ОС (в частности, необходим "count", несмотря на то, что говорится на странице руководства) и самое главное, нам не нужна статистика использования. Нам нужна информация о существовании. Буквально "ты там nfsdrive, это я root?" Я признаю, что мне нужно больше узнать о nfsiostat.
Еще одно решение, которое я видел, - это перейти от монтирования nfs, перечисленных в fstab, к использованию autofs. Документы CentOS закончились две версии назад но заявить:
Это не проблема с одним или двумя креплениями, но когда система поддерживает одновременные подключения ко многим системам, это может повлиять на общую производительность системы.
Учитывая, что у нас есть около 10-12 точек монтирования - это считается большим количеством? Мой коллега предположил, что многие из них находятся в диапазоне сотен. Тем не менее, эта информация устарела. Глядя в Документы Redhat, мы видим, что это копия / вставка.
Я видел эти два исправления / ошибки
но мы не можем выполнить обновление немедленно, потому что серверы являются производственными и находятся в клинических условиях. Кроме того, нет никаких указаний на то, что это явная наша проблема, и, учитывая, что мы не можем воспроизвести проблему по желанию, мы не можем протестировать на наших машинах разработчиков - хотя я пытался воспроизвести на наших машинах разработчиков. Существуют также более свежие версии ядра-ml для El Repo, но существует та же проблема - нельзя просто обновить в одночасье - эти серверы часто работают на 100% 24/7.
Итак, у меня есть два вопроса: