Оценка некорректируемых ошибок ECC и методов нейтрализации
Я выполняю сервер, который только что столкнулся с ошибкой, с которой я не встретился прежде. Это испустило несколько звуковых сигналов, перезагруженных, и застряло в экранной заставке (часть, где BIOS показывает свой логотип и начинает перечислять информацию) с ошибкой:
Node0: DRAM некорректируемая Ошибка ECC
Node1: ошибка СИНХРОНИЗАЦИИ ссылки HT
После жесткой перезагрузки система загруженный штраф и должен все же сообщить о чем-либо относительно edac-util.
Мое исследование говорит мне, что даже с памятью ECC и системой в идеальных условиях, некорректируемая ошибка все еще возможна и вероятно вероятно, произойдет во время продолжительности жизни системы в какой-то момент; в некоторых докладах предполагается по крайней мере один раз в год или раньше.
Сервер выполняет CentOS 6.5 с несколькими модулями ECC. Я уже нахожусь в процессе попытки диагностировать, какой модуль бросил ошибку сделать оценку, является ли это отказом или результатом чего-то столь же неизбежного, такого как космический луч.
Мое исследование также предполагает что, когда системные остановы как это, нигде нет, чтобы журнал был записан и что единственный надежный способ сделать этому нужно было присоединить систему к другому с журналом, выписываемым через последовательный порт.
Помимо обычного edac-util, memtest, стресс-тестирование и предупредительная замена, являются там чем-либо еще, что я должен учесть при исправлении этой ошибки?
Я не мог найти любую запись этого катастрофического отказа в любом из журналов CentOS, которые я искал, который соглашается с моей верой, что не возможно зарегистрировать эту ошибку к локальному диску. Об ошибке только сообщила мне BIOS после автоматической перезагрузки. Действительно ли желательно быть системой письменности, выходит из системы к сериалу в любом случае для входа этих видов ошибок?
Действительно ли это - вид отказа, преодолимое использование единой системы или действительно ли это единственное возможное использование являются дорогим решением для предприятия?
Что может я делать для обеспечения мер по нейтрализации в этих случаях возникновения отказов для единственного рабочего сервера; как в, сам рабочий сервер не охватывает несколько машин, но сервер нейтрализации может существовать.
Это в ответе, расскажите, как я остановил сбой системы, но не отвечает на исходный вопрос. Я все еще занимаюсь поиском решений и буду делиться любой новой информацией, которую придумаю по мере ее изучения.
Система представляет собой белый ящик с материнской платой Supermicro H8SGL-F с 64 ГБ (16x4) Hynix, 32 ГБ (16x2) оперативной памятью Viking . В спецификации материнской платы указано, что модули оперативной памяти должны устанавливаться наборами по четыре, поскольку процессор использует четырехканальный контроллер памяти. Я добавил два дополнительных модуля Viking, чтобы проверить, работает ли он. Это решение работало месяцами, но это была моя первая ошибка.
Вторая моя ошибка заключалась в том, что я неправильно установил плунжер. Слоты памяти имеют цветовую маркировку и чередуются для четырехканальной настройки. У меня был установлен плунжер следующим образом:
[ ========== ] 16GB Hynix
[ ---------- ] 16GB Hynix
[ ========== ] 16GB Hynix
[ ---------- ] 16GB Hynix
[ ========== ] 16GB Viking
[ ---------- ] 16GB Viking
[ ========== ]
[ ---------- ]
Хотя эта установка работала в течение нескольких месяцев и только недавно возникла проблема, я не мог определить, была ли неисправность связана с увеличением емкости, вызвавшей проблему с моей нестандартной компоновкой
Поскольку у меня была только одна производственная система, я удалил все модули и начал чередовать их попарно по два (все еще вне спецификации) и запустил систему с уменьшенной мощностью для нескольких недели. Я не получал сбоев и сообщений об ошибках ecc от edac-util. Однако вполне возможно, что неисправный модуль мог быть во втором слоте, и к нему просто не было доступа, так что это может вызвать неисправность.
После того, как при вращении плунжера не удалось воспроизвести ошибку, я понял, что я настроил плунжер неправильно. Я удалил модули Viking и настроил новую компоновку следующим образом:
[ ========== ] 16GB Hynix
[ ---------- ]
[ ========== ] 16GB Hynix
[ ---------- ]
[ ========== ] 16GB Hynix
[ ---------- ]
[ ========== ] 16GB Hynix
[ ---------- ]
С тех пор, как я внес это изменение, система осталась стабильной. Однако, несмотря на согласование со спецификацией, это не подтверждает, связана ли ошибка с компоновкой, модулем Viking (поскольку они были удалены) или является ли неисправный модуль просто одним из модулей Hynix, расположенных ниже по компоновке, к которому обращаются достаточно редко. не виноват.
Пожалуйста, рассматривайте этот ответ не как вывод к проблеме, а как шаг, который я предпринял для решения общей проблемы. Я еще не закончил и продолжу докладывать по мере продолжения поиска решений.
Также следует отметить,Вчера система отключила и снова отключила питание, впервые с тех пор, как я установил новую схему памяти. Я не могу подтвердить, было ли это из-за решаемой проблемы с памятью или это отдельная проблема с источником питания, поэтому воспринимайте этот единственный инцидент как крупицу скепсиса.
Что ж, это не полностью интегрированная система, такая как сервер HP, Dell или IBM, поэтому мониторинг и отчетность о таком сбое не будет присутствовать или согласовываться.
В системах, которыми я управлял, чаще всего выходят из строя диски, за ними следуют ОЗУ, блоки питания, вентилятор, системные платы и процессоры.
Память может выйти из строя ... Вы мало что можете с этим поделать.
См .: Нужно ли сжигать ОЗУ для оборудования серверного класса?
Поскольку вы не можете действительно предотвратить ошибки ECC и сбой ОЗУ, просто будьте готовы к этому. Сохраните запчасти. Имейте физический доступ к вашим системам и сохраняйте гарантию на ваши компоненты. Я бы определенно не стал вводить «предупредительную замену» в среду. Отчасти это зависит от вашего оборудования ... У вас есть IPMI? Иногда журналы оборудования попадают туда.
Это одно из дополнительных преимуществ лучшего серверного оборудования. Вот фрагмент с сервера HP ProLiant DL580 G4, на котором был превышен порог ECC в ОЗУ, затем перешел к отключению DIMM ... затем, наконец, произошел сбой сервера (ASR) и перезагрузка с отключенным плохим DIMM.
0004 Repaired 22:21 12/01/2008 22:21 12/01/2008 0001
LOG: Corrected Memory Error threshold exceeded (Slot 1, Memory Module 1)
0005 Repaired 20:41 12/06/2008 20:43 12/06/2008 0002
LOG: POST Error: 201-Memory Error Single-bit error occured during memory initialization, Board 1, DIMM 1. Bank containing DIMM(s) has been disabled.
0006 Repaired 21:37 12/06/2008 21:41 12/06/2008 0002
LOG: POST Error: 201-Memory Error Single-bit error occured during memory initialization, Board 1, DIMM 1. Bank containing DIMM(s) has been disabled.
0007 Repaired 02:58 12/07/2008 02:58 12/07/2008 0001
LOG: POST Error: 201-Memory Error Single-bit error occured during memory initialization, Board 1, DIMM 1. Bank containing DIMM(s) has been disabled.
0008 Repaired 19:31 12/08/2009 19:31 12/08/2009 0001
LOG: ASR Detected by System ROM
Если DIMM имеет неустранимую ошибку, я рекомендую заменить его. Если это только исправляемые ошибки в малом количестве, то, скорее всего, с этим можно жить, и в любом случае за исправляемые ошибки будет сложнее получить возврат средств.
Если вы хотите посмотреть, есть ли запись, попробуйте получить доступ к записям IPMI SEL, с помощью ipmitool sel elist или эквивалентного инструмента.
Другой альтернативой является установка аварийного ядра Linux для загрузки и сохранения dmesg, это также может поймать информацию об аппаратном сбое.
Третья альтернатива - это запись в последовательную консоль сервера в каком-нибудь постоянном месте, она также будет включать подсказки для отказа сервера программного или аппаратного вида.
.