HP Proliant выходит из строя с индикатором критической ошибки Мигает - что тогда?

Question

После нескольких часов корректной работы наш сервер останавливают расчет с мигающим светодиодом System Healt 12, который согласно документации ( http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c01706108-8 .pdf ) является признаком «Обнаружен критический сбой системы (процессор, память, регулятор, тепловое событие, вентилятор, NMI)» (стр. 96).

SSH тогда потерян. Мы можем перезагрузиться и снова получить ssh (я не на месте), но я не знаю, что тогда проверять? есть ли лог-файл, где можно найти информацию?

Я нашел это руководство: http://denis.herve.free.fr/trsfrt/HProliant.pdf, но мне кажется, что это ошеломляет.

Мой коллега предположил, что это может быть перегрузка RAM + Swap, которая приводит к краху всего сервера. Я не совсем согласен с ним, поскольку, насколько мне известно, проблема с памятью не приведет к критическому отказу системы. Есть идеи на этот счет?

Мне интересно, могут ли быть какие-либо отношения с моим предыдущим постом: замена сервера Linux до полного заполнения памяти.

мы находимся на Ubuntu 14.04.

PS: сервер находится в подвале, утром может быть немного конденсата ...

РЕДАКТИРОВАТЬ Folowing @Hennes замечание, мы вернули сервер обратно в гостиную. Но после ночи исчисления, это снова мерцало с красным светом :-(

Теперь я пытаюсь разобраться с файлами журналов. Мы перезагрузили сервер сегодня утром около 09:44 Вот файлы, которые были недавно изменены:

Что искать, где, чтобы получить информацию об ошибке?

Я старался :

romain@pl:/var/log$ cat syslog | grep error
Dec 27 12:00:23 pl kernel: [    1.053210] [Firmware Warn]: GHES: Poll interval is 0 for generic hardware error source: 1, disabled.
Dec 27 12:00:23 pl kernel: [    6.740763] ata3.00: failed to enable AA (error_mask=0x1)
Dec 27 12:00:23 pl kernel: [    6.741967] ata3.00: failed to enable AA (error_mask=0x1)
Dec 27 12:00:23 pl kernel: [    7.082169] ata4.00: failed to enable AA (error_mask=0x1)
Dec 27 12:00:23 pl kernel: [    7.112776] ata4.00: failed to enable AA (error_mask=0x1)
Dec 27 12:00:23 pl kernel: [    9.905224] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro
Dec 27 11:52:18 pl kernel: [    1.053048] [Firmware Warn]: GHES: Poll interval is 0 for generic hardware error source: 1, disabled.
Dec 27 11:52:18 pl kernel: [    6.364768] ata3.00: failed to enable AA (error_mask=0x1)
Dec 27 11:52:18 pl kernel: [    6.365903] ata3.00: failed to enable AA (error_mask=0x1)
Dec 27 11:52:18 pl kernel: [    6.684685] ata4.00: failed to enable AA (error_mask=0x1)
Dec 27 11:52:18 pl kernel: [    6.686080] ata4.00: failed to enable AA (error_mask=0x1)
Dec 27 11:52:18 pl kernel: [   11.211120] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro
Dec 28 09:46:55 pl kernel: [    1.051638] [Firmware Warn]: GHES: Poll interval is 0 for generic hardware error source: 1, disabled.
Dec 28 09:46:55 pl kernel: [    6.348693] ata3.00: failed to enable AA (error_mask=0x1)
Dec 28 09:46:55 pl kernel: [    6.349786] ata3.00: failed to enable AA (error_mask=0x1)
Dec 28 09:46:55 pl kernel: [    6.699099] ata4.00: failed to enable AA (error_mask=0x1)
Dec 28 09:46:55 pl kernel: [    6.731027] ata4.00: failed to enable AA (error_mask=0x1)
Dec 28 09:46:55 pl kernel: [    8.959211] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro

а также :

romain@pl:/var/log$ cat dmesg | grep error
[    1.051638] [Firmware Warn]: GHES: Poll interval is 0 for generic hardware error source: 1, disabled.
[    6.348693] ata3.00: failed to enable AA (error_mask=0x1)
[    6.349786] ata3.00: failed to enable AA (error_mask=0x1)
[    6.699099] ata4.00: failed to enable AA (error_mask=0x1)
[    6.731027] ata4.00: failed to enable AA (error_mask=0x1)
[    8.959211] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro

-> Здесь я не понимаю, какие значения в первом столбце, например, [6.731027]: это количество секунд с момента загрузки?

Я проверил

romain@pl:/var/log$ cat syslog | grep memory
Dec 27 12:00:23 pl kernel: [    0.000000] Scanning 1 areas for low memory corruption
Dec 27 12:00:23 pl kernel: [    0.000000] Base memory trampoline at [ffff880000094000] 94000 size 24576
[...]
Dec 27 12:00:23 pl kernel: [    0.000000] init_memory_mapping: [mem 0x100000000-0x61fffffff]
Dec 27 12:00:23 pl kernel: [    0.000000] Early memory node ranges
Dec 27 12:00:23 pl kernel: [    0.000000] PM: Registered nosave memory: [mem 0x00000000-0x00000fff]
[...]
Dec 27 12:00:23 pl kernel: [    0.000000] PM: Registered nosave memory: [mem 0xffc00000-0xffffffff]
Dec 27 12:00:23 pl kernel: [    0.019764] Initializing cgroup subsys memory
Dec 27 12:00:23 pl kernel: [    0.019992] Freeing SMP alternatives memory: 32K (ffffffff81e88000 - ffffffff81e90000)
Dec 27 12:00:23 pl kernel: [    0.971501] Freeing initrd memory: 20288K (ffff880035850000 - ffff880036c20000)
Dec 27 12:00:23 pl kernel: [    0.972518] Scanning for low memory corruption every 60 seconds
Dec 27 12:00:23 pl kernel: [    6.154807] memory memory67: hash matches
Dec 27 12:00:23 pl kernel: [    6.205519] Freeing unused kernel memory: 1412K (ffffffff81d27000 - ffffffff81e88000)
Dec 27 12:00:23 pl kernel: [    6.234958] Freeing unused kernel memory: 232K (ffff8800017c6000 - ffff880001800000)
Dec 27 12:00:23 pl kernel: [    6.254602] Freeing unused kernel memory: 336K (ffff880001bac000 - ffff880001c00000)
Dec 27 12:00:23 pl kernel: [    9.739558] EDAC i7core: Driver loaded, 2 memory controller(s) found.
Dec 27 12:00:32 pl kernel: [   20.152332] cgroup: docker-runc (2183) created nested cgroup for controller "memory" which has incomplete hierarchy support. Nested cgroups may change behavior in the future.
Dec 27 12:00:32 pl kernel: [   20.152335] cgroup: "memory" requires setting use_hierarchy to 1 on the root
Dec 27 11:52:18 pl kernel: [    0.000000] Scanning 1 areas for low memory corruption
Dec 27 11:52:18 pl kernel: [    0.000000] Base memory trampoline at [ffff880000094000] 94000 size 24576
Dec 27 11:52:18 pl kernel: [    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[...]
Dec 27 11:52:18 pl kernel: [    0.000000] init_memory_mapping: [mem 0x100000000-0x61fffffff]
Dec 27 11:52:18 pl kernel: [    0.000000] Early memory node ranges
Dec 27 11:52:18 pl kernel: [    0.000000] PM: Registered nosave memory: [mem 0x00000000-0x00000fff]
[...]
Dec 27 11:52:18 pl kernel: [    0.000000] PM: Registered nosave memory: [mem 0xffc00000-0xffffffff]
Dec 27 11:52:18 pl kernel: [    0.019779] Initializing cgroup subsys memory
Dec 27 11:52:18 pl kernel: [    0.020005] Freeing SMP alternatives memory: 32K (ffffffff81e88000 - ffffffff81e90000)
Dec 27 11:52:18 pl kernel: [    0.970708] Freeing initrd memory: 20288K (ffff880035850000 - ffff880036c20000)
Dec 27 11:52:18 pl kernel: [    0.971734] Scanning for low memory corruption every 60 seconds
Dec 27 11:52:18 pl kernel: [    5.854654] Freeing unused kernel memory: 1412K (ffffffff81d27000 - ffffffff81e88000)
Dec 27 11:52:18 pl kernel: [    5.883624] Freeing unused kernel memory: 232K (ffff8800017c6000 - ffff880001800000)
Dec 27 11:52:18 pl kernel: [    5.902731] Freeing unused kernel memory: 336K (ffff880001bac000 - ffff880001c00000)
Dec 27 11:52:18 pl kernel: [   10.983190] EDAC i7core: Driver loaded, 2 memory controller(s) found.
Dec 27 11:52:25 pl kernel: [   19.933483] cgroup: docker-runc (2140) created nested cgroup for controller "memory" which has incomplete hierarchy support. Nested cgroups may change behavior in the future.
Dec 27 11:52:25 pl kernel: [   19.933486] cgroup: "memory" requires setting use_hierarchy to 1 on the root
Dec 28 09:46:55 pl kernel: [    0.000000] Scanning 1 areas for low memory corruption
Dec 28 09:46:55 pl kernel: [    0.000000] Base memory trampoline at [ffff880000094000] 94000 size 24576
Dec 28 09:46:55 pl kernel: [    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[...]
Dec 28 09:46:55 pl kernel: [    0.000000] init_memory_mapping: [mem 0x100000000-0x51fffffff]
Dec 28 09:46:55 pl kernel: [    0.000000] Early memory node ranges
Dec 28 09:46:55 pl kernel: [    0.000000] PM: Registered nosave memory: [mem 0x00000000-0x00000fff]
[...]
Dec 28 09:46:55 pl kernel: [    0.000000] PM: Registered nosave memory: [mem 0xffc00000-0xffffffff]
Dec 28 09:46:55 pl kernel: [    0.020007] Initializing cgroup subsys memory
Dec 28 09:46:55 pl kernel: [    0.020233] Freeing SMP alternatives memory: 32K (ffffffff81e88000 - ffffffff81e90000)
Dec 28 09:46:55 pl kernel: [    0.970821] Freeing initrd memory: 20288K (ffff880035850000 - ffff880036c20000)
Dec 28 09:46:55 pl kernel: [    0.971834] Scanning for low memory corruption every 60 seconds
Dec 28 09:46:55 pl kernel: [    5.824432] Freeing unused kernel memory: 1412K (ffffffff81d27000 - ffffffff81e88000)
Dec 28 09:46:55 pl kernel: [    5.853109] Freeing unused kernel memory: 232K (ffff8800017c6000 - ffff880001800000)
Dec 28 09:46:55 pl kernel: [    5.871990] Freeing unused kernel memory: 336K (ffff880001bac000 - ffff880001c00000)
Dec 28 09:46:55 pl kernel: [    8.826997] EDAC i7core: Driver loaded, 2 memory controller(s) found.
Dec 28 09:47:04 pl kernel: [   19.154325] cgroup: docker-runc (2171) created nested cgroup for controller "memory" which has incomplete hierarchy support. Nested cgroups may change behavior in the future.
Dec 28 09:47:04 pl kernel: [   19.154328] cgroup: "memory" requires setting use_hierarchy to 1 on the root

Я также проверил «fan», «nmi», «критический» в файле системного журнала, но ничего не выводил.

Я вспомнил некоторые вопросы о стековом потоке, когда люди, которые копируют / вставляют файлы на внешнем веб-сайте журнала - я не могу вспомнить имя - я готов выложить файлы в Интернете, если кому-то это интересно.

Любой намек на то, где искать, какое ключевое слово приветствуется.

Мы используем сервер с докером и сервером r-studio наверху для исчисления ML. Я действительно сомневаюсь, что тип использования может быть источником этой проблемы, но в ИТ мы никогда не узнаем, поэтому я уточняю это;)

Спасибо за любую идею.

Answer 1

Предполагая, что вашей системой является ML150 G6, о котором упоминается в документации, о которой вы упомянули, позвольте мне настоятельно рекомендовать вам настроить и использовать в системе функции управления Lights Out-100.

Основные инструкции можно найти здесь. Как только вы получите доступ к управлению Lights Out-100 (я бы рекомендовал использовать веб-интерфейс, пока вы не ознакомитесь с тем, что предлагает LO100 и как вы его используете), а затем посмотрите страницы 28-32 этого же документа. ; он показывает, как вы можете видеть в режиме реального времени датчики и информацию о событиях для вашей системы. Часто, если проблема с оборудованием вызывает перезагрузку, она будет указана в журнале системных событий, и ее обнаружение даст вам некоторое представление о том, что происходит с вашей машиной. Журнал системных событий должен собирать свои данные независимо от того, касались ли вы когда-нибудь LO100, поэтому, как только вы попадете туда, у него должно быть что-то интересное, чтобы рассказать вам.

Большую часть той же информации можно получить через вашу работающую ОС, либо через /var /log /messages (которую вы уже пробовали без особого успеха), либо через инструменты HP Insight, которые доступны для установки для некоторых версий Linux (см. Http ://downloads.linux.hp.com/SDR/project/mcp/ для хорошей отправной точки для получения некоторых из этих инструментов). К сожалению, не все события видны в системных журналах, так как они зависят от оборудования, и агенты HP, а не собственно ядро, являются их инструментом.

Сказав это, вы также можете увидеть, если у вас установлен и работает mcelog; он может перехватывать некоторые аппаратные события и, как правило, записывает что-то в журнал сообщений, когда перехватывает событие. Он также обычно либо записывает информацию о событии в отдельный журнал, либо сохраняет ее в памяти, чтобы вы могли запросить ее с помощью команды mcelog. Стоит поискать mcelog в журнале сообщений или посмотреть, есть ли у вас недавно обновленный файл /var/log/mcelog .