Я использую Ubuntu 12.04 LTS. Вчера я нашел в своем почтовом ящике сообщение о том, что мой сервер был выключен. Я начал перезагружать систему, но она не появилась в течение многих минут, и у меня не было аппаратной системы KVM, чтобы увидеть, что ядро выводит на терминал. Поэтому я перезагрузил систему в образ восстановления Linux и увидел, что программный массив RAID 1 был рассинхронизирован. Система восстановления также начала восстанавливать массив RAID.
Пока нет никаких доказательств того, что на каком-либо из дисков есть аппаратные ошибки. Статусы SMART пока выглядят хорошо.
Я так и не получил уведомление по электронной почте от mdadm, хотя уведомление по электронной почте было включено в /etc/mdadm/mdadm.conf.
Этот сервер также был настроен на пересылку всех сообщений syslog на хост журнала, поэтому я проверил свой хост журнала. Соответствующие части:
20 мая 15:38:40 ядро: [ 1.869825] md0: обнаружено изменение емкости с 0 до 536858624 20 мая 15:38:40 ядро: [ 1.870687] md0: неизвестная таблица разделов 20 мая 15:38:40 ядро: [ 1.877412] md: bind 20 мая 15:38:40 ядро: [ 1.878337] md/raid1:md1: не чисто -- начинается фоновая реконструкция 20 мая 15:38:40 ядро: [ 1.878376] md/raid1:md1: активно с 2 из 2 зеркал 20 мая 15:38:40 ядро: [ 1.878418] md1: обнаружено изменение емкости с 0 до 3000052808704 20 мая 15:38:40 ядро: [ 1.878575] md: повторная синхронизация RAID-массива md1 [вырезка] 20 мая 15:52:33 ядро: Ведение журнала ядра (proc) остановлено. 20 мая 15:52:33 rsyslogd: [origin software="rsyslogd" swVersion="5.8.6" x-pid="845" x-info="http://www.rsyslog.com"] выход по сигналу 15.
Как вы видите, система (обычная, а не аварийная) уже обнаружила, что с RAID-массивом что-то не так во время загрузки системы. Затем, вскоре после этого, что-то (не я) остановило систему.
Итак, мои вопросы:
- Что может привести к внезапной рассинхронизации дисков?
- Почему мне не пришло уведомление по электронной почте?
- Почему ошибка не была должным образом зарегистрирована в syslog перед остановкой системы? Может ли быть, что система пыталась зарегистрировать syslog, но сделала это после остановки демона syslog? Если да, то что я могу сделать, чтобы предотвратить это?
- Что я могу сделать, чтобы узнать, что произошло? Или, если сейчас у меня нет возможности узнать, что произошло, как я могу улучшить ведение журнала и уведомления, чтобы в следующий раз я мог провести более качественное вскрытие?
Мой вопрос:нето правильной практике резервного копирования. Я уже знаю, что RAID не является резервным копированием и т. д. Мой вопрос касается исключительно уведомлений и диагностики.
решение1
Что может привести к внезапной рассинхронизации дисков?
Это может быть любая аппаратная или программная неисправность на пути между пластинами привода и данными в памяти. Что может означать, но не ограничиваться: головка привода, контроллер привода, соединительная головка на кабеле, сам кабель (внутренний обрыв провода), порт, к которому подключается кабель на приводе, порт на материнской плате или дочерней карте, микросхема контроллера на материнской плате или дочерней карте или даже сбой в программном обеспечении (где-то).
Реальная история: однажды у меня было зеркало RAID, которое было нестабильным, и диск падал без причины. Диски проверялись нормально, пластины были чистыми (повторные проходы SMART ничего не дали), и все работало хорошо — пока оно не начинало ломаться снова и снова. Я заменил кабель SATA за 3 доллара, и проблемынемедленноушел. Мораль истории такова: МНОГОЕ может пойти не так, и вы не всегда можете предполагать, что «все хорошо», если не проверите каждый компонент на пути данных.
Почему мне не пришло уведомление по электронной почте?
Уведомление по электронной почте происходит только тогда, когда (а) массив активно отслеживается или (б) массив опрашивается.
Мой совет: вам нужно, чтобы mdadm активно следил за дисковым массивом как за процессом. Это можно сделать с помощью чего-то похожего на (но не совсем так):
mdadm --monitor --scan --syslog
Вам необходимо будет скорректировать указанную выше строку в соответствии с вашей конкретной установкой.
Почему ошибка не была должным образом зарегистрирована в syslog перед остановкой системы? Может ли быть, что система пыталась зарегистрировать syslog, но сделала это после остановки демона syslog? Если да, то что я могу сделать, чтобы предотвратить это?
Могло возникнуть множество проблем, из-за которых ведение журнала было прекращено.
Во-первых, есть проблема того, как работает syslog в целом; и хотя много лет ушло на то, чтобы сделать его надежным и прочным, существуют определенные крайние случаи, когда данные могут не попадать на диск. Это известная проблема проектирования, и она активно решалась с помощью управления службами в стиле супервизора (также известного как daemontools и им подобных). Решением было полностью обойти syslog и записывать вывод в регистратор, который всегда имел открытый файловый дескриптор, чтобы ничего не терялось, а регистратор как можно быстрее сбрасывал вывод на диск; хотя это и не 100% эффективное решение, оно значительно повышает вероятность записи событий на диск до того, как ядро выйдет из строя или завершит работу.
Во-вторых, есть вероятность, что ядро впало в панику или произошло какое-то другое событие, которое загнало машину в угол. Даже неисправное оборудование может вызвать проблему — я видел, как машины с недостаточно мощными блоками питания вызывали спонтанные отключения в Windows 8. Замена блока питания исправила проблему отключения навсегда. Очевидно,ничегоядро может защитить от машины, которая просто решила: «С меня хватит» и отправилась на перезагрузку.
Что я могу сделать, чтобы узнать, что произошло? Или, если сейчас у меня нет возможности узнать, что произошло, как я могу улучшить ведение журнала и уведомления, чтобы в следующий раз я мог провести более качественное вскрытие?
Существует несколько подходов:
Разместите ведение журнала на отдельном разделе. Хотя это не гарантирует, что вы получите неповрежденные журналы, это помогает изолировать проблемы файловой системы, такие как disk-full-can't-write, повреждение, которое приводит к перемонтированию в режим только для чтения и т. д. Это, безусловно, помогает в этих конкретных случаях.
Посмотрите на удаленное ведение журнала жизненно важной системной информации. Опять же, это не гарантия, но это поможет, если последний пакет сможет «выйти за дверь» до того, как произойдет перезагрузка, и этот пакет будет иметь критические подсказки о том, почему произошла перезагрузка.
Для определенных критических служб рассмотрите возможность замены вывода в syslog на что-то другое, например, на ведение журнала в стиле супервизора, где выделенный регистратор перехватывает вывод и записывает его на диск как можно скорее. Это повышает надежность вывода, поступающего в хранилище. Приложив немного усилий, его можно заставить сосуществовать бок о бок с другими механизмами управления службами.
решение2
Что может привести к внезапной рассинхронизации дисков?
Сбой привода, сбой контроллера, какой-то другой сбой оборудования. Какая-то непонятная проблема с программным обеспечением.
Почему мне не пришло уведомление по электронной почте?
В Ubuntu есть cronjob /etc/cron.d/mdadm, который проверяет тома RAID раз в день в 00:57. Если в то время у вашей системы не было проблем или она уже вышла из строя к тому времени, то не было способа отправить сообщение.
Почему ошибка не была должным образом зарегистрирована в системном журнале перед остановкой системы?
Ну, если диски выходят из строя, то нет смысла пытаться записывать на них, так как любые дальнейшие записи могут испортить все, что осталось. Не зная точной природы вашего сбоя, это может быть то, что ваш том или файловая система перешли в режим только для чтения. По умолчанию Ubuntu настроена на переключение в режим только для чтения файловой системы, если на корневом томе есть ошибки.
как мне улучшить ведение журнала и уведомления, чтобы в следующий раз я мог провести более качественное вскрытие?
Настройте ведение журнала на удаленном хосте syslog. Таким образом, сбой хранилища не означает, что ничего нельзя будет записать.