На моем конце ума. Что может привести к случайной полной перезагрузке моего сервера? (Похоже, связано с ZFS)

У меня есть сервер, который я построил много лет назад и работал как чемпион. Но за последние несколько месяцев он стал серьезно нестабильным, без видимых изменений. Я отлаживал его и менял части безрезультатно. Я заменил почти все в системе, о чем я могу думать, что может быть причиной сохранения дисков, используемых для хранения.

Обратите внимание, что в системе работает CentOS 7.5.

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

Я удалил все, кроме самого необходимого. Обратите внимание, что я заменил:

Материнская плата, процессор, оперативная память и блок питания.

Если какой-либо из флеш-накопителей был неисправен, я бы ожидал увидеть журналы исправленных / не исправляемых ошибок ECC, чего у меня нет. Если бы это был процессор, я бы ожидал чего-то более случайного с некоторыми регистрациями из-за возможной паники ядра. Я подозревал, что это может быть неисправность блока питания, и заменил его. Проблема сохранилась, поэтому я попытался заменить материнскую плату. Без изменений.

Система была сконфигурирована с двумя процессорами и 16 блоками идентичной памяти, поэтому я попытался удалить один процессор и половину оперативной памяти, посмотреть, не сломался ли он, а затем заменить другой набор. Никаких изменений симптомов.

Я начал удалять дополнительные компоненты и достиг минимума без изменения симптомов.

  • В журналах никогда ничего не говорится о сбое оборудования; они просто заканчиваются в точке сброса.
  • В логах IPMI ничего нет.
  • В журналах ИБП ничего нет (удаление ИБП тоже не помогло).
  • Процессоры не перегреваются. Я зарегистрировал lmsensors без каких-либо отклонений.
  • Мониторинг температуры системы, Vcore процессора и памяти, оборотов вентилятора и напряжений блока питания с помощью журналов ipmitool.
  • Все отчеты SMART испытаний пройдены.
  • Я переставил основной диск, используемый для ОС (/ root, boot, swap), на другой SSD, отразив его с помощью mdadm и установив grub.
  • Оба RAID-массива (см. Спецификации ниже) являются ZFS и не сообщают о каких-либо сбоях. Нет проблем при сканировании на наличие гнили или повреждения.

Я сейчас в полной и полной растерянности. За исключением нескольких оставшихся дисков в системе, у меня закончились попытки заменить сохранение для самого дела.

Что может быть причиной сброса моего сервера? Что еще я могу проверить? Неужели ошибка действительно будет исходить от одного из дисков?

В настоящее время система работает следующим образом:

Базовые компоненты:

Место хранения:

Приводы 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, но будьте осторожны с предварительными выпусками, если вы очень цените свои данные. Я не ожидаю потери данных, но вы можете быть в безопасности, чем потом сожалеть.

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