Несколько раз за свою карьеру я сталкивался с наборами mdadm RAID (RAID1+0, 5, 6 и т. д.) в различных средах (например, CentOS/Debian boxs, Synology/QNAP NAS), которые, похоже, просто неспособны справиться с отказавшим диском. Это диск, который не полностью мертв, но имеет десятки тысяч поврежденных секторов и просто неспособен обрабатывать ввод-вывод. Но он не полностью мертв, он все еще как-то работает. Журнал ядра обычно полон ошибок UNC.
Иногда SMART определяет, что диск неисправен, в других случаях нет никаких других симптомов, кроме медленного ввода-вывода.
Медленный ввод-вывод фактически приводит к зависанию всей системы. Подключение по ssh занимает вечность, webGUI (если это NAS) обычно перестает работать. Выполнение команд по ssh также занимает вечность. Это происходит до тех пор, пока я не отключу / намеренно не «выведу» диск из массива, затем все возвращается к «нормальному» состоянию — настолько нормальному, насколько это вообще возможно для деградировавшего массива.
Мне просто интересно, если диск так долго читается/записывается, почему бы просто не выбить его из массива, не выбросить сообщение в журнал и не продолжить работу? Кажется, что остановка всей системы из-за того, что один диск какой-то хреновый, полностью сводит на нет одно из главных преимуществ использования RAID (отказоустойчивость — способность продолжать работу, если диск выходит из строя). Я понимаю, что в однодисковом сценарии (например, в вашей системе подключен только один диск SATA, и он не может нормально выполнять чтение/запись) это катастрофично, но в RAID-массиве (особенно отказоустойчивых «личностях») это кажется не только раздражающим, но и противоречащим здравому смыслу.
Есть ли веская причина, по которой поведение mdadm по умолчанию заключается в том, чтобы фактически парализовать работу устройства до тех пор, пока кто-то не подключится удаленно и не исправит его вручную?
решение1
В целом, цельРЕЙДв зависимости от выбранного уровня рейда обеспечивает разный баланс между ключевыми целями избыточность данных, доступность, производительностьиемкость.
Исходя из конкретных требований, этоответственность владельца хранилищарешить, какой баланс различных факторов является правильным для данной цели, создатьнадежныйрешение.
Задача выбранного решения Raid (в данном случае мы говорим о программном обеспечении mdadm) — обеспечить защиту данных в первую очередь. Учитывая это, становится ясно, что задача решения RAID не в том, чтобы ставить непрерывность бизнеса выше целостности данных.
Другими словами: работа mdadm заключается в том, чтобы избежать неудачного рейда. Пока "странно ведущий себя диск" не сломан окончательно, он все равно вносит свой вклад в рейд.
Так почему бы просто не выбить странно ведущий себя диск из массива, не оставить сообщение в журнале и не продолжить работу?Потому что это увеличит риск потери данных.
Я имею в виду, что вы правы, на данный момент, с точки зрения бизнеса, кажется лучшим решением просто продолжить. Однако в реальности сообщение, которое было сброшено в журнал, может остаться необнаруженным, поэтому деградированное состояние рейда остается необнаруженным. Некоторое время спустя, в конечном итоге, другой диск в том же рейде выходит из строя, в результате чего сохраненные данные на неисправном рейде в конечном итоге исчезают.
В дополнение к этому: Трудно точно определить, что такое «странно ведущий себя диск». Выражаясь по-другому: Какое рабочее поведение одного диска, работающего в дисковом массиве, все еще является приемлемым?
Некоторые из нас могут ответить: «диск показывает некоторые ошибки». Другие могут ответить: «пока ошибки можно исправить, все в порядке». Другие могут ответить: «пока диск отвечает на все команды за определенное время, все в порядке». Другие говорят: «в случае, если температура диска отличается более чем на 5°C по сравнению со средней температурой всех дисков в одном массиве». Другой ответ может быть: «пока очистка не выявит ошибок» или «пока SMART не выявит ошибок».
Написанное не является ни длинным, ни полным списком.
Дело в том, что определение «приемлемого поведения диска» является вопросом интерпретации, а значит, и ответственностью владельца хранилища, а не чем-то, что mdadm должен решать самостоятельно.
решение2
Ключевая проблема заключается в том, что неисправный диск SATA может иногда заморозить всю шину на время выполнения внутренней процедуры восстановления после ошибки. По этой причине следует использоватьС поддержкой TLERдиски только в RAID-массивах (и желательно модель корпоративного класса).
Диски SAS меньше страдают от этой проблемы, но и не полностью от нее застрахованы.
решение3
В дополнение к сказанному хочу добавить свою копейку, но это важное соображение.
Чтовождениекогда сектор медленно читается?
Предположительно, диски, которые предназначены для работы в одиночку, например, типичные диски «настольных компьютеров», предполагают, что нет другого способа извлечь данные, хранящиеся в этом плохом секторе. Они попытаются извлечь данные любой ценой, повторяя это снова и снова в течение длительного периода времени. Конечно, они также пометят этот сектор как неисправный, поэтому они переназначат его в следующий раз, когда вы будете в него писать, но вы должны записать для этого. Пока вы не перепишете его, они будут захлебываться каждый раз, когда вы будете читать из этого места. В настройках RAID это означает, что для RAID диск все еще работает, и нет причин его выключать, но для приложения массив замедлится до скорости улитки.
С другой стороны, "корпоративные" диски, особенно "брендовые", часто предполагают, что они всегда используются в настройках RAID. Контроллер "бренда", увидев "брендовый" диск, на самом деле может дажепоставить в известностьих прошивка о наличии RAID. Поэтому диск остановится раньше и сообщит об ошибке ввода-вывода, даже если можно было сделать еще несколько попыток и прочитать сектор. Тогда контроллер имеет возможность ответить быстрее, зеркалируя инструкцию чтения на родственный диск (и выкидывая плохой из массива). Когда вы вытаскиваете и тщательно исследуете/тестируете этот выброшенный диск, вы не обнаруживаете никаких явных проблем — он просто замедлился на мгновение, и этого было достаточно, чтобы прекратить его использование, согласно логике контроллера.
Я предполагаю, что это может бытьединственныйразница между "настольными" дисками и "брендовыми"/"корпоративными" NL-SAS и SATA. Вероятно, поэтому вы платите в три раза больше, когда покупаете диск "HPE", который на самом деле был произведен Toshiba, по сравнению с покупкой диска под брендом "Toshiba".
Однако некоторые приводы поддерживают некоторые общие элементы управления этим. Это называется SCT ERC, который шандс дляУправление восстановлением ошибок передачи команд SMART. Вот как это выглядит в smartctl:
не поддерживается
# smartctl --all /dev/sda
=== START OF READ SMART DATA SECTION ===
SCT capabilities: (0x3037) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.
поддерживается
=== START OF READ SMART DATA SECTION ===
...
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
Если вам повезет, вы сможете управлять этой функцией с помощью smartctl. Вы можете получить или установить два тайм-аута, как долго пытаться перечитать и как долго пытаться переписать:
# smartctl -l scterc /dev/sda
SCT Error Recovery Control:
Read: 70 (7.0 seconds)
Write: 70 (7.0 seconds)
# smartctl -l scterc /dev/sde
SCT Error Recovery Control:
Read: Disabled
Write: Disabled
# smartctl -l scterc /dev/sdd
Warning: device does not support SCT Error Recovery Control command
smartctl -l scterc,120,60 /dev/sde
Что означает: 120 десятых секунды для повторной попытки чтения; 60 десятых секунды для повторной попытки записи. Ноль означает «повторять, пока не умрешь». Разные приводы имеют разные настройки по умолчанию для этого.
Итак, если вы используете только диск "RAID edition", лучше установить тайм-ауты ERC на ноль, иначе вы можете потерять данные. С другой стороны, если вы используете диски в RAID, лучше установить разумные низкие ненулевые настройки.
Источник amarao @ Habrahabr, на русском языке.
PS И еще замечание по поводу SAS. Используйте sdparm, он поддерживает больше элементов управления.
решение4
У меня были ситуации, когда диск не работал, но при этом каким-то образом выходил из строя контроллер.
Исторически это было возможно с PATA, где главный и подчиненный диски были на одном кабеле, и отказ одного диска мог помешать доступу к другому, все еще исправному диску. Извлечение неисправного диска могло восстановить доступ к оставшемуся диску, или может потребоваться выключение и включение питания, но RAID мог бы выйти из строя, и тогда можно было бы начать восстановление.
SATA менее уязвим к этому, но контроллер все еще может быть затронут. Из моего опыта программных рейдов, там больше кровавых внутренностей, которые были бы скрыты более навороченным выделенным рейд-контроллером.
Я не сталкивался с этим при использовании SAS или NVME, но SAS часто подразумевает наличие аппаратных RAID-контроллеров, которые обладают более интеллектуальной внутренней обработкой дисков.