Почему mdadm не может справиться с «почти неисправным» диском?

Несколько раз в своей карьере я сталкивался с наборами mdadm RAID (RAID1+0, 5, 6 и т. д.) в различных средах (например, на компьютерах с CentOS/Debian, сетевыми хранилищами Synology/QNAP), которые, по-видимому, просто не в состоянии справиться с неисправным диском. Это диск, который не полностью мертв, но имеет десятки тысяч сбойных секторов и просто не может обрабатывать ввод-вывод. Но он не совсем мертв, он все еще работает. Журнал ядра обычно полон ошибок UNC.

Иногда SMART идентифицирует диск как неисправный, в других случаях никаких других симптомов, кроме медленного ввода-вывода, не наблюдается.

Медленный ввод-вывод фактически приводит к зависанию всей системы. Подключение по ssh занимает вечность, веб-интерфейс (если это NAS) обычно перестает работать. Выполнение команд через ssh также занимает вечность. То есть до тех пор, пока я не отключу / намеренно не «выведу» диск из массива, тогда все вернется к «нормальному» - это настолько нормально, насколько это может быть с деградировавшим массивом.

Мне просто интересно, если чтение/запись диска занимает так много времени, почему бы просто не выбить его из массива, оставить сообщение в журнале и продолжить? Кажется, что вся система останавливается из-за того, что один диск немного неисправен, полностью сводит на нет одно из основных преимуществ использования RAID (отказоустойчивость - способность продолжать работу в случае сбоя диска). Я могу понять, что в сценарии с одним диском (например, в вашей системе подключен как один диск SATA, и он не может правильно выполнять чтение/запись) это катастрофа, но в наборе RAID (особенно отказоустойчивых "личностей") это кажется не только раздражающим, но и противоречащим здравому смыслу.

Есть ли очень веская причина, по которой поведение mdadm по умолчанию состоит в том, чтобы в основном вывести из строя коробку, пока кто-нибудь не подключится и не починит ее вручную?

В общем, цель А. RAID, в зависимости от выбранного уровня Рейда, обеспечивает различный баланс между ключевыми целями избыточность данных, доступность, спектакль и емкость.

Исходя из конкретных требований, ответственность владельца хранилища решить, какой баланс различных факторов является правильным для данной цели, создать надежный решение.

Работа выбранного решения Raid (здесь в данном случае речь идет о программном мдадм) заключается в обеспечении защиты данных в первую очередь. Имея это в виду, становится ясно, что задача рейдового решения не состоит в том, чтобы ставить непрерывность бизнеса выше, чем целостность данных.

Другими словами: задача mdadm — избежать неудачного рейда. Пока «диск со странным поведением» не полностью сломан, он все равно участвует в рейде.

Так почему бы просто не выбить диск со странным поведением из массива, оставить сообщение в журнале и продолжить? Потому что это повысит риск потери данных.

Я имею в виду, вы правы, на данный момент, с точки зрения бизнеса, кажется лучшим решением просто продолжить.Однако в действительности сообщение, которое было сброшено в журнал, может остаться необнаруженным, поэтому деградированное состояние рейда остается необнаруженным. Некоторое время спустя, в конце концов, другой диск в том же рейде выходит из строя, в результате чего сохраненные данные на вышедшем из строя рейде в конечном итоге исчезают.

В дополнение к этому: трудно точно определить, что такое «диск со странным поведением». Другими словами: каково еще приемлемое поведение одного диска, работающего в дисковом массиве?

Некоторые из нас могут ответить: «Диск показывает какие-то ошибки». Другие могут ответить: «Пока ошибки можно исправить, все в порядке». Другие могут ответить: «Пока диск отвечает на все команды в заданное время, все в порядке». Другие говорят «в случае, если температура диска отличается более чем на 5°C по сравнению со средней температурой всех дисков в одном массиве». Другой ответ может быть «до тех пор, пока чистка не выявит ошибок» или «до тех пор, пока SMART не выявит ошибок».

Написано не длинный и тоже не полный список.

Дело в том, что определение «приемлемого поведения диска» является вопросом интерпретации и, следовательно, ответственностью владельца хранилища, а не тем, что mdadm должен решать самостоятельно.

Основная проблема заключается в том, что неисправный диск SATA может иногда заморозить всю шину на время внутренней процедуры восстановления после ошибки. По этой причине следует использовать с поддержкой TLER диски только в массивах RAID (и желательно модель корпоративного класса).

Диски SAS меньше страдают от этой проблемы, но и не полностью свободны от нее.

В дополнение к сказанному хочу добавить свою копейку, но это важное соображение.

Какие вождение делает, когда сектор медленно читается?

Предположительно приводы, предназначенные для работы в одиночку, т.е. г. типичные «настольные» диски, предполагают, что нет другого способа получить данные, хранящиеся в этом поврежденном секторе. Они будут пытаться получить данные любой ценой, повторяя снова и снова в течение длительного периода времени. Конечно, они также пометят этот сектор как неисправный, поэтому они переназначат его в следующий раз, когда вы будете писать в него, но вы должны написать для этого. Пока не перепишешь, они будут задыхаться каждый раз, когда ты будешь читать оттуда. В настройках RAID это означает, что для RAID диск все еще работает, и нет причин его отключать, но для приложений массив будет замедляться до минимума.

С другой стороны, «корпоративные» диски, особенно «фирменные», часто предполагают, что они всегда используются в настройках RAID. «Фирменный» контроллер, увидев «фирменный» диск, может даже уведомлять их прошивки о наличии RAID. Таким образом, накопитель остановится раньше и сообщит об ошибке ввода-вывода, даже если можно было сделать еще несколько попыток и прочитать сектор. Тогда у контроллера есть возможность ответить быстрее, зеркально отразив инструкцию чтения на родственный диск (и выкинув плохой из массива). Когда вы вытащите и тщательно изучите/протестируете этот выбитый диск, вы не обнаружите явных проблем — он просто замедлился на мгновение, и этого было достаточно, чтобы прекратить его использование, согласно логике контроллера.

Я предполагаю, что это может быть единственный разница между «настольными» дисками и «фирменными»/«корпоративными» дисками NL-SAS и SATA. Вероятно, поэтому вы платите в три раза больше, когда покупаете диск «HPE», который на самом деле был произведен Toshiba, по сравнению с покупкой диска под маркой «Toshiba».

Однако некоторые приводы поддерживают некоторые общие элементы управления этим. Он называется SCT ERC, что означает SMART Command Transport Error Recovery Control Control. Вот как это выглядит в смартктл:

неподдерживаемый

# smartctl --all /dev/sda
=== НАЧАЛО ЧТЕНИЯ РАЗДЕЛА SMART DATA ===
Возможности SCT: (0x3037) Поддерживается состояние SCT.
                                        Поддерживается управление функциями SCT.
                                        Поддерживается таблица данных SCT.

поддерживается

=== НАЧАЛО ЧТЕНИЯ РАЗДЕЛА SMART DATA ===
...
Возможности SCT: (0x003d) поддерживается статус SCT.
                                        Поддерживается контроль восстановления после ошибок SCT.
                                        Поддерживается управление функциями SCT.
                                        Поддерживается таблица данных SCT.

Если вам повезет, вы можете управлять этой функцией с помощью смартктл. Вы можете получить или установить два тайм-аута, как долго пытаться перечитать и как долго пытаться перезаписывать:

# smartctl -l scterc /dev/sda
Контроль восстановления после ошибок SCT:
           Чтение: 70 (7,0 секунд)
          Запись: 70 (7,0 секунд)

# smartctl -l scterc /dev/sde
Контроль восстановления после ошибок SCT:
           Чтение: отключено
          Пишите: отключен

# smartctl -l scterc /dev/sdd
Предупреждение: устройство не поддерживает команду SCT Error Recovery Control.

smartctl -l scterc,120,60 /dev/sde

Что означает: 120 десятых секунды на повторную попытку чтения; 60 десятых секунды на повторную попытку записи. Ноль означает «повторяй, пока не умрешь». Различные диски имеют разные настройки по умолчанию для этого.

Итак, если вы используете только диск «RAID edition», лучше установить тайм-ауты ERC на ноль, иначе вы можете потерять данные. С другой стороны, если вы используете диски в RAID, лучше установить какое-нибудь разумное низкое ненулевое значение.

Источник amarao @ Habrahabr, на русском языке.

P.S. И заметка о SAS. Использовать сдпарм, он поддерживает больше элементов управления этим.

У меня были ситуации, когда диск не работал, но каким-то образом выводил из строя контроллер.

Исторически это было возможно с PATA, где главный и подчиненный диски были подключены к одному и тому же кабелю, и сбой одного диска мог помешать доступу к другому все еще исправному диску. Удаление неисправного диска может снова открыть доступ к оставшемуся диску, или может потребоваться выключение и выключение питания, но рейд может выйти из строя, и тогда можно будет начать восстановление.

SATA менее уязвим для этого, но контроллер все еще может быть затронут. Исходя из моего опыта программных рейдов, я обнаружил больше кровавых внутренностей, которые были бы скрыты более причудливым специализированным рейд-контроллером.

Я не сталкивался с этим с SAS или NVME, но SAS часто означает аппаратные RAID-контроллеры, которые имеют больше внутренних возможностей для обработки дисков.