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