На моем конце ума. Что может привести к случайной полной перезагрузке моего сервера? (Похоже, связано с ZFS)
У меня есть сервер, который я построил много лет назад и работал как чемпион. Но за последние несколько месяцев он стал серьезно нестабильным, без видимых изменений. Я отлаживал его и менял части безрезультатно. Я заменил почти все в системе, о чем я могу думать, что может быть причиной сохранения дисков, используемых для хранения.
Обратите внимание, что в системе работает CentOS 7.5.
Симптомы состоят в том, что аппарат самопроизвольно выполняет полный сброс, как если бы блок питания работал или произошла внезапная потеря питания. Это может происходить один раз в несколько дней или иногда два раза в день. Система может быть простаивающей или с нагрузкой. Там нет шаблона.
Я удалил все, кроме самого необходимого. Обратите внимание, что я заменил:
Материнская плата, процессор, оперативная память и блок питания.
Если какой-либо из флеш-накопителей был неисправен, я бы ожидал увидеть журналы исправленных / не исправляемых ошибок ECC, чего у меня нет. Если бы это был процессор, я бы ожидал чего-то более случайного с некоторыми регистрациями из-за возможной паники ядра. Я подозревал, что это может быть неисправность блока питания, и заменил его. Проблема сохранилась, поэтому я попытался заменить материнскую плату. Без изменений.
Система была сконфигурирована с двумя процессорами и 16 блоками идентичной памяти, поэтому я попытался удалить один процессор и половину оперативной памяти, посмотреть, не сломался ли он, а затем заменить другой набор. Никаких изменений симптомов.
Я начал удалять дополнительные компоненты и достиг минимума без изменения симптомов.
- В журналах никогда ничего не говорится о сбое оборудования; они просто заканчиваются в точке сброса.
- В логах IPMI ничего нет.
- В журналах ИБП ничего нет (удаление ИБП тоже не помогло).
- Процессоры не перегреваются. Я зарегистрировал lmsensors без каких-либо отклонений.
- Мониторинг температуры системы, Vcore процессора и памяти, оборотов вентилятора и напряжений блока питания с помощью журналов ipmitool.
- Все отчеты SMART испытаний пройдены.
- Я переставил основной диск, используемый для ОС (/ root, boot, swap), на другой SSD, отразив его с помощью mdadm и установив grub.
- Оба RAID-массива (см. Спецификации ниже) являются ZFS и не сообщают о каких-либо сбоях. Нет проблем при сканировании на наличие гнили или повреждения.
Я сейчас в полной и полной растерянности. За исключением нескольких оставшихся дисков в системе, у меня закончились попытки заменить сохранение для самого дела.
Что может быть причиной сброса моего сервера? Что еще я могу проверить? Неужели ошибка действительно будет исходить от одного из дисков?
В настоящее время система работает следующим образом:
Базовые компоненты:
- SuperMicro H8DG6-F (материнская плата)
- 1x AMD Opteron Процессор 6328 (ЦП)
- 16 ГБ х 8 Hynix DDR3 ECC HMT42GR7BMR4C-G7 (память)
Место хранения:
- 1x Samsung SSD 850 PRO 128 ГБ XFS (/ root, boot, swap)
- 2x Samsung SSD 850 PRO 512GB ZFS RAID-1 (/ данные)
- 8x Western Digital RED 4 ТБ WD40EFRX-68WT0N0 ZFS RAID-Z3 (/ резервное копирование)
Приводы Western Digital RED подключены к объединительной плате корпуса и подключены к встроенному контроллеру SAS. Все, если твердотельные накопители находятся в объединительной плате ToughArmor MB998SP-B, установленной в 5,25- дюймовом отсеке в передней части корпуса и подключенной к контроллеру SATA материнской платы.
Охлаждение:
- NH-U12DO A3 (процессор)
- Вентиляторы добавлены в радиаторы чипсета (они очень сильно нагреваются)
- Небольшой радиатор добавлен к чипу Intel Gigabit
- Термопаста на ВСЕХ радиаторах заменена на Noctua NT-H1, за исключением небольших радиаторов вокруг процессоров, которые имеют термопрокладки
Случай:
Источник питания:
UPS
ОБНОВИТЬ:
Я был в состоянии отследить проблему стабильности к маловероятному источнику: программному обеспечению. Это кажется маловероятным и ранее не принималось во внимание при дифференциальной диагностике, поскольку проблема с программным обеспечением (даже для модуля ядра) в худшем случае должна вызывать панику ядра.
Источник был идентифицирован как массив ZFS (ZFS в Linux). Я могу воспроизвести сбой, удалив все диски, кроме операционной системы и массива ZFS, а затем выполнив очистку этого массива, в то время как в системе выполняется одновременное чтение любого массива ZFS (того же или другого).
Основные настройки тестирования:
- 1 процессор
- 16 ГБ х 8 памяти
- Твердотельный накопитель 128 ГБ для CentOS 7.5 (Boot / Swap / Root)
- SuperMicro H8DG6-F Материнская плата
- Блок питания PWS-865-PQ 865 Вт
- Бортовой Matrox G200 Видео
Все диски подключены к материнской плате. Слоты PCIe не заполнены.
Устранение других источников:
- CPU (заменяется вторым CPU)
- Память (заменяется вторым набором памяти)
- Материнская плата (заменена другой идентичной платой; BIOS обновлен)
- Жесткий диск ОС (подкачка между Crucial и твердотельными накопителями Samsung 128 ГБ)
- Блок питания сертифицирован для использования с этой материнской платой (проверено на двух из них)
ZFS деятельность:
- Скраб на одном массиве
- Доступ к чтению / записи для одного и того же массива ИЛИ другого
Тест 1: !! CRASH!!
- Базовая настройка (как описано выше)
- 2x Samsung SSD 850 PRO 512GB ZFS RAID-1 (/ данные)
- 8x Western Digital RED 4 ТБ WD40EFRX-68WT0N0 ZFS RAID-Z3 (/ резервное копирование)
ZFS scrub on /backup. Несколько серверов Minecraft работают на /data.
Сервер внезапно перезагружается вскоре после этого.
Это похоже на то, что система обычно настраивается, но сокращается до минимального набора компонентов для тестирования и анализа.
Тест 2: !! СТАБИЛЬНО!!
- Базовая настройка (как описано выше)
- 8x Western Digital RED 4 ТБ WD40EFRX-68WT0N0 ZFS RAID-Z3 (/ резервное копирование)
ZFS scrub on /backup. НЕТ Майнкрафт серверы активны и нет доступа к любому диску ZFS.
Сервер стабилен более 24 часов и завершает работу.
На данный момент я подозреваю, что массив / data является ошибкой.
Тест 3: !! CRASH!!
- Базовая настройка (как описано выше)
- 8x Western Digital RED 4 ТБ WD40EFRX-68WT0N0 ZFS RAID-Z3 (/ резервное копирование)
ZFS scrub on /backup. Несколько серверов Майнкрафт работают в режиме резервного копирования.
Сервер внезапно перезагружается вскоре после этого.
На данный момент я подозреваю, что массив /backup может быть настоящей ошибкой, так как массив / data больше не присутствует, и система аварийно завершает работу, как и всегда.
Тест 4: !! CRASH!!
- Базовая настройка (как описано выше)
- 2x Samsung SSD 850 PRO 512GB ZFS RAID-1 (/ данные)
ZFS scrub on /data. Несколько серверов Minecraft работают на /data.
Сервер внезапно перезагружается вскоре после этого.
Стабильность, похоже, связана с ZFS?
Тест 5: !! СТАБИЛЬНО!!
- Базовая настройка (как описано выше)
- 1x Samsung SSD 850 PRO 512GB XFS (тестирование данных)
Несколько серверов Minecraft работают на /data-testing.
Сервер был стабильным в течение нескольких недель.
Теперь я уверен, что источник стабильности связан с массивами ZFS. Это очень странно, так как я годами запускал ZFS в этой системе без проблем до сих пор. Также очень странно, что сбой может привести к перезагрузке всей системы без паники или журнала ядра.
Я приветствую любые дополнительные идеи, которые кто-либо может предоставить.
2 ответа
Так как я был в своем уме в подобной ситуации, я думал, что опубликую то, что в конечном итоге мне помогло. Возможно, это не совсем связано с вашей ситуацией, но, возможно, какая-то другая бедная душа может наткнуться на это и найти утешение.
У меня есть резервный сервер ZFS, который запускает rsnapshot (rsync с ротацией) по всему парку серверов моей компании. Каждые 2-3 недели сервер просто перезагружается.
Как отметил @tjikkun, вы должны попытаться получить некоторую информацию о панике. В моем случае это была ошибка "Строка паники: двойная ошибка", которую я обнаружил в дампе, и что-то связанное с переполнением стека в рекурсивной подпрограмме ZFS.
Вокруг этого есть некоторая информация, но она применима только к 32-битным процессорам. Я, однако, работаю на 64-битной и для этого я не мог найти никакой информации.
Тем не менее 32-битная ошибка намекала на kern.kstack_pages
настройки ядра, которые необходимо увеличить в определенных ситуациях. В моем случае это то, что сделал трюк. я добавил kern.kstack_pages=16
в /boot/loader.conf
перезагрузил сервер, и с тех пор у меня не было сбоев (в течение 3 месяцев). Имеет смысл, что этот параметр помог, потому что произошел сбой, который произошел из-за ограничения стека в ZFS.
Опять же, это не обязательно относится к вашему конкретному случаю, но мне было очень трудно найти эту информацию, и я надеюсь, что кто-то найдет ее полезной.
Вот некоторые шаги, которые вы можете предпринять, чтобы сузить это:
Перезагрузка при панике
Если автоматическая перезагрузка при панике включена, вы можете отключить ее для тестирования. Если вы бежите sysctl kernel.panic
Вы должны получить текущее значение. Если это 0
, он выключен, любое другое значение - это количество секунд ожидания перед перезагрузкой. sysctl -w kernel.panic=0
Вы бы выключили его, если он еще не выключен. Если это установлено 0
и ваш сервер все еще сам перезагружается, я действительно думаю, что это аппаратная проблема. Если это останавливает автоматическую перезагрузку, то мы знаем, что перезагрузка вызвана сторожевым таймером.
Чтение ядра паники
Когда это останавливает перезагрузку, и вам повезло, на экране отображается некоторая информация о панике. Если это так, и вы хотите получить полную информацию о сбое, вам нужно настроить последовательное ведение журнала или netconsole.
Ничего на экране
Если вам не так повезло, вы можете настроить kdump и посмотреть, дает ли это какую-либо информацию.
Другие вещи, чтобы попробовать
Возможно, вы захотите вернуться к очень ранней версии ZFS 0.7.x, чтобы посмотреть, сможете ли вы воспроизвести проблему там. Другой вариант - попробовать 0.8.0-rc2, но будьте осторожны с предварительными выпусками, если вы очень цените свои данные. Я не ожидаю потери данных, но вы можете быть в безопасности, чем потом сожалеть.