У меня есть массив raid 5 mdadm, настроенный с 6 дисками и горячим резервом на сервере Ubuntu 11. На диске есть пара акций самбы, и до сегодняшнего дня они работали хорошо.
Пару часов назад пользователи начали замечать, что их общие ресурсы сканируются или вообще не подключаются, и им потребовалось много минут, чтобы составить список имеющихся файлов. Попытка скопировать файлы большую часть времени приводила к зависанию соединения и, в конечном итоге, к их отключению. Я смог просмотреть общие ресурсы в смонтированном каталоге через ssh, но у samba определенно были проблемы. Я попытался перезапустить самбу, но безуспешно.
Я запустил mdadm --detail / dev / md2 и ... ничего. Он ничего не выводил и не возвращал мою подсказку, и мне пришлось нажать Ctrl-c, чтобы вернуть подсказку. / proc / mdstat также был пуст. Но по какой-то причине я все еще мог просматривать смонтированный массив рейдов, и все выглядело нормально. Оглядываясь назад, я должен был попробовать добавлять и удалять файлы через терминал ...
Проверка монитора процессов показала множество процессов smbd для каждого пользователя, зависшего в состоянии D, и я не мог остановить их с помощью команды kill. Я не видел ничего подобного, и, поскольку mdadm не дал ничего полезного, я попытался перезагрузить сервер. Это тоже зависло. Я скрестил пальцы и сказал парню из центра обработки данных выполнить полную перезагрузку.
В итоге рейд восстанавливается нормально и все диски работают. Но я до сих пор не уверен, что может привести к тому, что mdadm зависнет, отключит все соединения самбы и перестанет отвечать.
Я новичок во всем этом, поэтому надеялся получить помощь в отладке проблемы от тех из вас, кто, возможно, сталкивался с подобными проблемами раньше. Куда бы вы посмотрели в первую очередь?
РЕДАКТИРОВАТЬ :: Следуя совету ACase, вот еще дополнительная диагностическая информация:
Файловая система на / dev / md2 (рассматриваемый RAID-диск) - ext3
Вот моя информация о ядре
2.6.35-22-server #33-Ubuntu SMP Sun Sep 19 20:48:58 UTC 2010 x86_64 GNU/Linux
Просмотр / var / log / messages показывает, что перед перезапуском у меня была куча этих ошибок (может быть, 15 каждые 3 секунды) в течение периода времени, когда диски были недоступны через samba:
kernel: [17343195.826943] mptbase: ioc0: LogInfo(0x31123000): Originator={PL}, Code={Abort}, SubCode(0x3000)
который через поисковые системы похоже, что это может быть связано с результатами SMART, запущенными с дисками SATA через контроллер SAS. Сервер - это dell t610 с интегрированным SAS 6 / iR, так что это вполне может быть причиной моей проблемы - MDADM пытается запустить Smart на дисках, а затем замораживает ввод-вывод со всеми ошибками. Звучит правильно? Какие тесты вы бы провели, чтобы подтвердить это? Я бы предпочел не снимать весь массив снова, если это возможно, поскольку он используется (очевидно, преждевременно). Это сообщение журнала перестает отображаться после перезагрузки, а затем самба снова работает, поэтому я почти уверен, что они связаны. Между этими сообщениями не появляются сообщения - есть ли способ включить более подробный журнал ядра в / var / log / messages, который может доказать, что они связаны с SMART?
Еще раз спасибо.
Ищите ошибки в /var/log/messages или /var/log/kernel. Похоже, ядро перестало писать и / или читать на диск. Это объяснило бы, почему он не перезагружается нормально.
hdparm утилита для проверки скорости ввода / вывода диска и соответствующих настроекЯ бы обычно предлагал вам запустить fsck в вашей файловой системе после такого случая.
Вдобавок в Linux есть пара reboot параметры, которые позволят вам игнорировать определенные проблемы с диском и принудительно перезагружать систему, не вызывая вашего специалиста по контролю качества для полной перезагрузки (в порядке от наименьшей до наибольшей):
-f Force halt or reboot, don’t call shutdown(8).
-n Don’t sync before reboot or halt. Note that the kernel and stor-
age drivers may still sync.
Оба эти варианта более безопасны, чем полный сброс.
[Редактировать №1]:
Проверить вывод из smartctl -a /dev/sd[a-z] чтобы узнать, есть ли проблемы с дисками.
[Редактировать №2]:
Я бы посоветовал запланировать время простоя и обновить прошивку. Он имеет тенденцию исправлять множество ошибок. В частности, контроллер SAS и BIOS. Может быть, другие, если они их предложат.
Вдобавок, поскольку это t610, есть ли у него интерфейс DRAC? Вы часто можете увидеть там журналы, связанные с оборудованием, если произошел аппаратный сбой.