Недавно в одной из моих систем, использующих ext4 на LVM на аппаратном RAID6, произошел катастрофический сбой. Чтобы назвать некоторые из бедствий: несколько файловых систем вышла из строя без возможности ремонта, по крайней мере, один был предоставлен лестницы в небеса. Это действительно застало меня врасплох! Я считал, что эта установка достаточно устойчива, чтобы противостоять даже худшему, и это подтвердилось за 7 лет безупречной замены вышедших из строя жестких дисков. Но недавно это не удалось. Жесткий.
Изучив всю информацию, касающуюся этого сбоя, я не смог прийти к выводу о том, что может потерпеть неудачу и, самое главное, почему. Я надеюсь, что кто-то из опытных сможет определить причину и причину этого. Вся собранная информация приводится ниже.
Примерно в 10:45 по местному времени в наш дом прекратилось электроснабжение из-за отказа районной электросети. Примерно через 40 минут работы от батареи было решено выключить серверы, так как не было ETA для восстановления питания. Это определенно было чистое отключение, так как в тот момент у нас было еще 20 минут до разрядки батарей. Эти серверы не являются критически важными, поэтому их можно отключить в ожидании восстановления питания. Позже эти серверы снова были в сети. На этом конкретном сервере при запуске был 1 неисправный жесткий диск. С RAID6 я не боялся, поскольку для отказа требуется еще 2 жестких диска, что маловероятно, пока я не получу замену. Как и всегда, я удалил неисправный жесткий диск и позволил серверу продолжить работу с ухудшенным RAID6. Через некоторое время я случайно обнаружил, что LDAP не запускается из-за отсутствия папки с данными +r разрешение. Это было странно, но легко исправить. На всякий случай я проверил другие сервисы, и они были в порядке. Позже этот сервер был перезагружен один раз в рамках обслуживания, и на всякий случай началась проверка целостности RAID. В 18:00 по местному времени мой коллега поработал на одном из наших сервисов на этом сервере и заверил меня, что он полностью работоспособен. Примерно в 21:00 по местному времени он сообщил мне, что конкретный сервис внезапно потерял стиль и не пускает его. Сначала я подумал, что это та же таинственная потеря +r разрешение, но обнаружил, что статическая папка полностью отсутствует. Я решил, что это все еще тривиальное решение, и отложил это до следующего утра, совершенно не подозревая о происходящих событиях. Настало следующее утро, и я столкнулся с абсолютной катастрофой вместо тривиальное исправление Я вспомнил прошлый вечер (я должен сказать, что это трудно выразить).
Стоит отметить, что другие серверы пережили это событие совершенно спокойно. Один с ext4 на LVM на программном RAID10, другой с голыми жесткими дисками.
Изучив журналы, я обнаружил, что примерно в 20:05 PostgreSQL начал не записывать свои данные из-за файл исчез ошибки типа. Однако на 20:00 у нас запланировано резервное копирование. Очевидно, с большой нагрузкой ввода / вывода. Резервное копирование также не удалось из-за тех же ошибок. Скоро ext4_lookup ошибки начали рассылать спам в системный журнал, и все другие службы начали отказывать. В конце концов, эта самая служба ответила случайной тарабарщиной страницей, а страница без какого-либо стиля была просто кэшированной копией, предоставленной клиентской стороной браузера.
RAID6 сообщил о снижении производительности, но ни разу не сообщил о сбое. Ни один из них не сообщил о проверке согласованности ошибок. Так что с точки зрения оборудования это было неоптимально, но никоим образом не провалилось.
Как я уже указывал по ссылкам, файловые системы каким-то образом вышли из строя. Интересно, что пострадали только файловые системы ext4 на LVM на аппаратном RAID6. Остальные файловые системы за пределами RAID6 (на SSD) остались нетронутыми. Выявленные проблемы с отказавшими файловыми системами:
Некоторые из пунктов этого маркированного списка могли быть результатом попытки исправить файловую систему с помощью e2fsck, в то время как другие, очевидно, являются сама коррупция. Проверяя inodes, я обнаружил, что среди действительных inodes есть неудачливые, заполненные случайными данными в их метаданных. Я не обнаружил совпадений, поскольку файлы были повреждены случайным образом: независимо от того, были ли они новыми или 10-летними, использовавшимися или долгое время не использовавшимися - все типы файлов пострадали, и, наоборот, были выжившие и все виды.
Из этого списка сбоев файловой системы следует, что некоторые библиотеки были смешанными, и из-за этого apache выдавал полную тарабарщину на выходе наших служб. Также я не мог восстановить данные PostgreSQL, так как его файлы были в полном беспорядке. К счастью, я смог восстановить данные MySQL, поскольку в них были повреждены только системные метаданные, которые было относительно легко восстановить. Также повезло, что в каталоге данных LDAP был поврежден только журнал доступа, который можно было легко воссоздать. dpkg Список установленных пакетов смешался с другими двоичными данными. И так далее...
Графики счетчиков производительности также останавливаются примерно на 20:05, но не показывают никаких неожиданных действий, кроме обычного увеличения количества операций ввода-вывода при файловых операциях.
Я, конечно, подозревал наличие вируса, но счетчики производительности вообще не фиксировали никаких необычных действий, и никаких доказательств при проверке системы обнаружено не было.
Учитывая отсутствие совпадений с возрастом поврежденного файла, я считаю, что это не был сбой журнала ext. Учитывая огромное количество поврежденных данных и метаданных, я думаю, маловероятно, что ОЗУ сервера или ОЗУ RAID-контроллера могут повредить это, поскольку поврежденный объем данных на порядки больше, чем оба ОЗУ вместе взятые. Даже случайно заполненные inodes находятся не в каком-то конкретном регионе, а по всему тому. Все это приводит меня к выводу, что что-то должен сделали RAID-контроллер записывать все эти случайные данные на жесткие диски, если он настаивает на том, чтобы жесткие диски считывали допустимые данные (контрольные суммы RAID могли бы обнаружить ошибки), но я не могу представить, как это могло произойти.
Поэтому я прошу любого, кто имеет опыт, проанализировать предоставленную информацию, могут ли они определить неисправность и ее причину, или, возможно, посоветовать мне какие-либо шаги, которые я еще не предпринял, чтобы определить неисправность и ее причину.
PS: Обратите внимание, что этот вопрос не о резервном копировании.