Я использую Ubuntu 12.04 LTS. Вчера я обнаружил в своем почтовом ящике сообщение о том, что мой сервер выключен. Я приступил к перезагрузке системы, но через много минут ничего не вышло, и у меня не было аппаратной системы KVM, чтобы посмотреть, что ядро выводит на терминал. Итак, я перезагрузил систему в аварийный образ Linux и увидел, что программный массив RAID 1 рассинхронизирован. Спасательная система также начала реконструировать RAID-массив.
Пока нет свидетельств того, что на каком-либо из дисков есть аппаратные ошибки. Статусы SMART пока выглядят хорошо.
Я никогда не получал уведомления по электронной почте от mdadm, хотя уведомление по электронной почте было включено в /etc/mdadm/mdadm.conf.
Этот сервер также был настроен для пересылки всех сообщений системного журнала на хост журнала, поэтому я проверил свой хост журнала. Соответствующие части:
May 20 15:38:40 kernel: [ 1.869825] md0: detected capacity change from 0 to 536858624 May 20 15:38:40 kernel: [ 1.870687] md0: unknown partition table May 20 15:38:40 kernel: [ 1.877412] md: bind May 20 15:38:40 kernel: [ 1.878337] md/raid1:md1: not clean -- starting background reconstruction May 20 15:38:40 kernel: [ 1.878376] md/raid1:md1: active with 2 out of 2 mirrors May 20 15:38:40 kernel: [ 1.878418] md1: detected capacity change from 0 to 3000052808704 May 20 15:38:40 kernel: [ 1.878575] md: resync of RAID array md1 [snip] May 20 15:52:33 kernel: Kernel logging (proc) stopped. May 20 15:52:33 rsyslogd: [origin software="rsyslogd" swVersion="5.8.6" x-pid="845" x-info="http://www.rsyslog.com"] exiting on signal 15.
Как видите, система (обычная, а не система восстановления) уже обнаружила, что что-то не так с массивом RAID во время загрузки системы. Затем, вскоре после этого, что-то (не я) остановило систему.
Итак, мои вопросы:
У меня вопрос не о правильной практике резервного копирования. Я уже знаю, что RAID не является резервной копией и т. Д. Мой вопрос касается исключительно уведомлений и диагностики.
Что могло вызвать внезапную рассинхронизацию дисков?
Сбой привода, сбой контроллера, отказ какого-либо другого оборудования. Какая-то непонятная проблема с программным обеспечением.
Почему я не получил уведомление по электронной почте?
В Ubuntu есть cronjob /etc/cron.d/mdadm Это приводит к тому, что тома RAID проверяются один раз в день в 00:57. Если тогда в вашей системе не было проблем или она уже вышла из строя, значит, не было возможности отправить сообщение.
Почему ошибка не была должным образом записана в системный журнал перед остановкой системы?
Что ж, если диски выходят из строя, на самом деле нет смысла пытаться писать на них, поскольку любая дальнейшая запись может привести к уничтожению всего, что осталось. Не зная точного характера вашего сбоя, возможно, ваш том или файловая система стали доступны только для чтения. По умолчанию Ubuntu настроен на переключение на файловую систему только для чтения, если в корневом томе есть ошибки.
как я могу улучшить ведение журнала и уведомления, чтобы в следующий раз я мог лучше провести вскрытие?
Настройте ведение журнала на удаленный хост системного журнала. Таким образом, отказ хранилища не означает, что ничего нельзя регистрировать.
Что могло вызвать внезапную рассинхронизацию дисков?
Это может быть аппаратный или программный сбой на пути между дисками накопителя и данными в памяти. Что может означать, но не ограничивается: головка привода, контроллер привода, соединительная головка на кабеле, сам кабель (внутренний обрыв провода), порт, к которому кабель подключается на приводе, порт на материнской плате или дочерней плате. , микросхема контроллера на материнской плате или дочерней плате, или даже программный сбой (где-то).
Правдивая история: у меня однажды было зеркало RAID, которое шатается, сбрасывая диск без причины. Диски проверены нормально, пластины были чистыми (повторные проходы SMART ничего не дали), и все работало хорошо - до тех пор, пока он не отслаивался снова и снова. Я заменил кабель SATA за 3 доллара и проблемы мгновенно ушел. Мораль этой истории: есть МНОГО, что может пойти не так, и вы не всегда можете предполагать, что «все в порядке», если вы не проверяете каждый компонент на пути данных.
Почему я не получил уведомление по электронной почте?
Уведомление по электронной почте происходит только при (а) активном мониторинге массива или (б) при опросе массива.
Мой совет: вам нужно, чтобы mdadm активно контролировал массив дисков как процесс. Это можно сделать с помощью чего-то похожего (но не совсем так):
mdadm --monitor --scan --syslog
Вам нужно будет отрегулировать указанную выше строку для вашей конкретной установки.
Почему ошибка не была должным образом записана в системный журнал перед остановкой системы? Может быть, система пыталась войти в системный журнал, но сделала это после остановки демона системного журнала? Если да, то что я могу сделать, чтобы предотвратить это?
Возможны различные проблемы, которые привели к прерыванию ведения журнала.
Во-первых, это вопрос о том, как вообще работает syslog; и хотя на то, чтобы сделать его устойчивым и надежным, ушло много лет, есть определенные крайние случаи, когда данные могут не попасть на диск. Это хорошо известная проблема проектирования, которая активно решалась с помощью управления службами в стиле супервизии (также известного как daemontools и им подобные). Решение заключалось в том, чтобы полностью обойти системный журнал и записать вывод в регистратор, который всегда имел открытый файловый дескриптор, чтобы ничего не пропадало, а регистратор сбрасывал вывод на диск как можно быстрее; Хотя это не 100% эффективное решение, оно значительно повышает вероятность записи событий на диск до того, как ядро сработает или отключится.
Во-вторых, существует вероятность того, что в ядре произошла явная паника или произошло какое-то другое событие, которое загнало бы машину в угол. Даже неисправное оборудование могло вызвать проблему - я видел, как машины с недостаточно мощными блоками питания вызывали самопроизвольные выключения в Windows 8. Замена блока питания навсегда устранила проблему выключения. Очевидно, ничего ядро может защитить от машины, которая просто решила: «С меня этого достаточно» и бросилась делать перезагрузку.
Что я могу сделать, чтобы узнать, что случилось? Или, если у меня сейчас нет возможности узнать, что произошло, как я могу улучшить ведение журнала и уведомления, чтобы в следующий раз я мог лучше провести вскрытие?
Есть несколько подходов:
Разместите логирование на отдельном разделе. Хотя это не является гарантией того, что вы получите неповрежденные журналы, это действительно помогает изолировать проблемы файловой системы, такие как переполнение диска, невозможность записи, повреждение, приводящее к перемонтированию в режим только для чтения и т. Д. Это, безусловно, помогает в тех случаях, когда конкретные случаи.
Посмотрите на удаленную запись важной системной информации. Опять же, это не гарантия, но поможет, если последний пакет сможет «выбраться за дверь» до того, как произойдет перезагрузка, и у этого пакета есть важные ключи к разгадке причины перезагрузки.
Для конкретных критически важных сервисов обратите внимание на замену вывода в системный журнал чем-то другим, например ведением журнала в стиле наблюдения, когда специальный регистратор перехватывает вывод и записывает его на диск как можно скорее. Это увеличивает надежность вывода на хранение. Немного поработав, его можно заставить сосуществовать бок о бок с другими механизмами управления услугами.