Я запускаю сервер, на котором только что произошла ошибка, с которой я раньше не сталкивался. Он издал несколько звуковых сигналов, перезагрузился и застрял на стартовом экране (та часть, где в BIOS отображается логотип и начинается перечисление информации) с ошибкой:
Узел 0: неисправимая ошибка ECC DRAM
Узел 1: ошибка синхронизации HT Link
После полной перезагрузки система загрузилась нормально и еще ничего не сообщила о edac-util.
Мои исследования говорят мне, что даже с памятью ECC и системой в идеальных условиях неисправимая ошибка все еще возможна и, вероятно, в какой-то момент, вероятно, произойдет в течение срока службы системы; в некоторых отчетах предлагается не реже одного раза в год или раньше.
На сервере работает CentOS 6.5 с несколькими модулями ECC. Я уже пытаюсь определить, какой модуль выдал ошибку, чтобы оценить, является ли это ошибкой или результатом чего-то столь же неизбежного, как космический луч.
Мои исследования также показывают, что, когда система останавливается таким образом, нет места для записи журнала, и что единственный надежный способ сделать это - подключить систему к другой системе, при этом журнал будет записываться через последовательный порт.
Есть ли что-нибудь еще, что я должен учитывать при устранении этой ошибки, помимо обычного edac-util, memtest, стресс-тестирования и предупредительной замены?
Мне не удалось найти никаких записей об этом сбое ни в одном из журналов CentOS, которые я искал, что согласуется с моим убеждением в том, что невозможно записать эту ошибку на локальный диск. Об ошибке мне сообщил только биос после автоматической перезагрузки. Целесообразно ли постоянно записывать системные журналы на последовательный порт, чтобы регистрировать такие ошибки?
Можно ли избежать такого рода сбоев с помощью одной системы или это возможно только с помощью дорогостоящего корпоративного решения?
Что я могу сделать, чтобы обеспечить резервные меры в этих случаях отказа для одного рабочего сервера; например, сам производственный сервер не охватывает несколько машин, но может существовать резервный сервер.
В ответ расскажите, как я остановил сбой системы, но не отвечает на исходный вопрос. Я все еще ищу решения и буду делиться любой новой информацией, которую придумаю, когда узнаю ее.
Система представляет собой белый ящик с материнской платой Supermicro H8SGL-F с оперативной памятью Viking 64 ГБ (16x4) и 32 ГБ (16x2). В спецификации материнской платы сказано, что модули оперативной памяти должны устанавливаться наборами по четыре, поскольку процессор использует четырехканальный контроллер памяти. Я добавил два дополнительных модуля 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, расположенных ниже по компоновке, к которому обращаются достаточно редко. не виноват.
Пожалуйста, рассматривайте этот ответ не как вывод к проблеме, а как шаг, который я предпринял для решения общей проблемы. Я не закончил и продолжу докладывать, пока продолжаю искать решения.
Также следует отметить, что вчера система отключила и снова отключила питание, впервые с тех пор, как я установил новый макет памяти. Я не могу подтвердить, было ли это из-за решаемой проблемы с памятью или это отдельная проблема с источником питания, поэтому воспринимайте этот единственный инцидент как крупицу соли.
Если в модуле DIMM есть неисправимая ошибка, я рекомендую заменить его. Если это только исправимые ошибки по низкой цене, вы, вероятно, сможете с этим смириться, и в любом случае для исправимых ошибок будет сложнее получить возмещение.
Если вы хотите узнать, есть ли запись, попробуйте получить доступ к записям IPMI SEL с помощью ipmitool sel elist или аналогичный инструмент.
Другой альтернативой является установка аварийного ядра Linux для загрузки и сохранения dmesg, это также может улавливать информацию об отказе оборудования.
Третья альтернатива - записать последовательную консоль сервера в какое-то постоянное место, она также будет включать подсказки для сбоя сервера программного или аппаратного типа.
Что ж, это не полностью интегрированная система, такая как сервер 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