Мне поставили задачу протестировать и оценить производительность аппаратного RAID под Coffeelake с помощью Intel RST Premium с опцией ускорения Intel Optane System в конфигурации RAID1 - под Linux.
Я использую Ubuntu 19.04, он устанавливает dmraid по умолчанию (также пробовал несколько других версий Linux, требующих дополнительной установки dmraid). Раньше я работал с корпоративными дисковыми массивами, и с точки зрения пользователя, я не могу понять ценность DUT, описанную выше.
После того, как система установки загрузится правильно, dmraid с опциями -s и -r сообщить о хорошем / статусе синхронизации. Я выключаюсь, удаляю один из дисков (представьте, что он вышел из строя) и пытаюсь запустить только с одного диска. Не загружается, переходит в аварийную оболочку.
Хорошо, я выключаю и возвращаю удаленный диск обратно. В моем корпоративном понимании система RAID должна обновлять различную информацию с помощью журнала, а носители должны синхронизироваться после этой операции.
Но этого не происходит. Я вижу восстановление в фоновом режиме - скорее всего, полное восстановление, dmsetup status достигает конечного значения, и больше ничего не происходит. По-прежнему написано XXXX / XXXX, dmraid все еще говорит nosync. Дисковой активности не наблюдается. Если я выключаю машину, затем загружаюсь снова, полное восстановление начинается с нуля, достигает той же стадии и застревает там.
Я новичок в dmraid, пробовал некоторые параметры -R, и в какой-то момент dmraid -s сказал "непоследовательный" или что-то в этом роде, восстановление началось снова, но застряло в конечном состоянии XXXX / XXXX, а том по-прежнему несоответствующий.
Перешел к настройке машины, удалил том RAID, воссоздал его, и логически вся информация потеряна (таким образом, это не способ восстановления из отказавшего тома RAID).
Скажите, какие предположения у меня здесь нет, и почему система не может нормально справиться с отсутствием одного диска, ужасно сходя с ума, когда диск возвращается обратно в комплект.
Я полностью стираю один из дисков прямо сейчас, чтобы проверить, не dmraid автоматически найдет и присоединит его к набору и выполнит перестройку, чтобы том RAID стал готовым и синхронизированным.
Обновить: после полного стирания одного из дисков и его установки в систему BIOS / программа установки сообщает, что этот диск не является RAID, а исходный диск - «деградировавшим» с возможностью «перестроить». После выбора этой опции программа установки говорит «восстановление», но активности диска не наблюдается. Затем я запустил Ubuntu, и он переходит в аварийную оболочку, кажется, что том не готов, и явно выполняется восстановление в фоновом режиме - подтверждено dmsetup status - но я все еще не могу правильно пользоваться системой.
После завершения этой перестройки состояние тома по-прежнему остается в состоянии отсутствия синхронизации. init 5 зависает, после перезагрузки том RAID по-прежнему недоступен и началась новая перестройка.
Таким образом, этот тип «RAID» не выдерживает отказа диска.
Обновление 1: конфигурация отлично работает под Windows 10. Удаление одного диска из набора R1, когда система выключена, поддерживает загрузку системы с другого диска. В Windows есть графический интерфейс для проверки состояния и включения дисков / инициации восстановления. По завершении перестройки драйвер обновляет системный RST до надлежащего состояния, и перестройка не перезапускается по ошибке при следующем инициирующем событии. Производительность последовательного чтения в конфигурации R1 составляет 1,1 ГБ / с с дисками SATA3 (Ubuntu показывает 528 МБ / с).
В принципе, вы должны иметь возможность загрузиться с неполного набора RAID (в конце концов, это то, что вам нужно сделать, если диск не раскручивается после выключения питания, что гораздо более вероятно, чем диск сбой во время работы), но в настройках по умолчанию, которые, кажется, по какой-то причине требуют разрешения оператора (например, принудительно собрать массив, а затем продолжить загрузку).
Кроме того, в принципе, простая попытка собрать массив, но на самом деле этого не делать, не должна увеличивать счетчик событий в суперблоках RAID, как система определяет, может ли диск быть синхронизированным. Если массив собран с отсутствующим диском, этот диск будет пропускать записи, поэтому, конечно, впоследствии потребуется перестройка, перезаписывающая диск.
Поэтому я подозреваю, что массив собран в деградированном состоянии, но какой-то загрузочный код затем решает, что «деградированный» недостаточно хорош, и переводит вас в аварийную оболочку. На данный момент решение о необходимости перестройки уже принято.
Перестройка должна оставить вас в согласованном состоянии в конце, но, возможно, диспетчеру устройств потребуется некоторая команда для завершения здесь, так же, как фоновый pvmove в LVM.
Полностью стертые диски будут добавлены только в том случае, если они распознаются как «горячий» резерв. При консервативной настройке мне бы потребовалось действие оператора для обозначения диска как горячего резерва. Вы можете добавить запасные диски до того, как диски выйдут из строя, если у вас есть слоты, которые позволяют немедленно переключаться в случае сбоя, но я бы с осторожностью относился к тому, чтобы просто взять первый диск, который появится после сбоя в качестве запасного, по крайней мере, не спросив оператора.
Встроенный Intel RAID - это не более чем fakeraid: все, что он делает, - это определение определенного формата метаданных (Intel Matrix RAID) и предоставление небольшого дополнительного BIOS, позволяющего загружаться с устройства «RAID», а не с одного диска (как видно из BIOS).
После загрузки управление передается самому ядру Linux двумя способами:
Вкратце: я бы действительно избегал использования dmraid. Если по каким-то причинам вам пришлось полагаться на dmraid при использовании Intel fakeraid, я бы предпочел не используйте сам fakeraid (вместо этого полагаясь на простой mdraid).
Если у вас проблема с загрузкой, посмотрите Вот: короче говоря, из-за такого специфического взаимодействия dracut / systemd / mdraid удаление исправного диска при перезагрузке может вызвать «таймаут сборки» деградированного массива RAID1. Чтобы этого избежать, вам понадобится одно из следующего:
rd.retry тайм-аут во время загрузки, добавив параметр rd.retry=30 к ядру;