Аппаратный RAID: особенности использования

Скажите, а ваше мнение по поводу 'WB повышает производительность' основывается на бенчмарках или просто "подумали и сказали"?

Вот у меня как я не кручу, лишние 50k IOPS с устройства теряются при включении WB. И график распределения latency из милого двугорбого существа превращается в шути что.

А у вас?

Я не из Селектела, но, отвечу/спрошу: судя по «лишние 50k IOPS» в тестах учавствуют SSD. Для SSD желательно без «вот этих кэшей» с прямой записью на диск.

Был у меня опыт взаимодействия с разными RAID, лет 8 назад.
1. Принесли на восстановление данных комп, софтовый рейд, 2 винта в зеркале, на них 1С базы, система на отдельном винте. Сгорел контроллер на матери, винты из зеркала не читаются по отдельности. Бэкап «по выходным». Поход в ближайший магазин, покупка такой же платы, всё читается.
Почему не читались данные, хотя должны были — не разбирался, глубокого анализа таблиц размещения, как на хабре любят, не будет. С тех пор обхожу софтовый рейд и никому не советую.
2. Самосбор из 6 или 8 винтов в 5 рейде на отдельном рейд-контроллере, кажется LSI, за давностью лет точно не помню. Бэкап суточный. Умирает контроллер, увлекательный квест по поиску такого же, нашли в соседнем городе за весьма завышенный прайс + 250 км путешествие.
Выводы: решили поиграть с рейд-контроллерами — покупайте сразу запасной и кладите на полку, может не повезти с поисками замены, особенно если вы не в %default_city%
С тех пор только Q-nap для неответственных данных и дисковые полки + carepack для ответственных данных.

Программный RAID — наименее затратный вариант, но и наименее производительный

О какой производительности речь — о дисковом вводе/выводе или о процессорной вычислительной мощности? Каковы типичные потери производительности?

В целлм я согласен с тем, что софтовый RAID — плохая идея. Но это лишь потому, что современные процессоры повадились непременно иметь FPU и прочее говно, которое во многих случаях не нужно.

Интегрированный аппаратный RAID — микрочип, установленный на материнскую плату, который берет на себя часть функционала аппаратного RAID-контроллера

Ну и как именно распределяется работа между CPU и микрочипом?

Аппаратный RAID — это отдельный контроллер с собственным процессором и кэширующей памятью

А чем отличается микрочип из второго пункта? Там нет процессора или нет памяти?

полностью забирающий на себя выполнение всех дисковых операций

Полностью? Гы, смешно!

Для подключения дисков используются специальные интерфейсные кабели.

Этого уже достаточно для того, чтобы предпочесть какой-то другой контроллер.

BBU (Battery Backup Unit) — модуль расширения с литий-ионной батареей, позволяющий поддерживать напряжение на энергозависимой микросхеме кэша.

Странная идея. Не лучше ли поставить Flash-память и сбрасывать отложенную запись туда — но только при сбое питания?
В нормальном режиме во Flash-память ничего не пишется — так что она не изнашивается. А при сбое питания — достаточно небольшого накопителя энергии, чтобы питать систему, пока данные из RAM будут переписаны во Flash-память; и храниться оно там будет не 72 часа, а практически вечность.

Это особенно важно, когда включен режим отложенной записи кэша (Writeback).

Вообще-то, WriteBack — это единственная причина защищаться от сбоя питания. Если использовать WriteThrow — то зашиты от сбоя питания не требуется.

При пропадании электропитания содержимое кэша не будет сброшено на диски, что приведет к потере данных и, как следствие, штатная работа дискового массива будет нарушена.

Я так понимаю, о транзакционном режиме работы программ (драйвера файловой системы и прикладных программ) Вы не слышали.

Все они оснащены небольшими пассивными радиаторами, что может вызвать ложное представление о небольшом тепловыделении.

Осталось понять, откуда там вообще взялось значительное тепловыделение.

При создании система запросит желаемый размер страйпа, то есть размер блока данных за одну I/O-операцию

Я всегда думал, что размер каждой I/O-операции определяется программной частью — прикладной программой или операционной системой. Интересно, что будет, если операционная система посылает контроллеру запрос на чтение всего одного сектора?

Сразу становится понятно, что аппаратный RAID-контроллер ускоряет операции чтения и записи на дисковый носитель за счет использования кэша

А я думал, что операции чтения и записи лимитируются скоростью дисков. Конечно, кэширование может помочь — но кэш можно организовать и в оперативной памяти, причём там наверняка можно сделать его больше, чем на контроллере (производители обычно жмотятся поставить приличную память и не желают ставить слот для обычной памяти, чтобы пользователь мог сам поставить туда сколько считает нужным).

Чтобы достичь максимальной скорости работы, необходимо использовать вариант Write Back. При такой схеме работы контроллер будет сообщать операционной системе об успешной IO-операции сразу после того, как данные поступят в кэш.

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

PS: Больше всего бесит отсутствие стандартов на организацию RAID-массивов; и документация разработчиков не публикуется. Как результат — нет средств восстановления порушенного RAID-массива.

По хорошему — RAID-контроллер должен быть устроен примерно как совеременная видеокарта: т.е. программу для работы с RAID-массивом туда должна закидывать операционка. Тогда можно быть уверенным, что программный код открыт, формат данных опубликован, в случае сбоя можно разобраться и спасти данные. Однако, производители предпочитают vendor-lock.

Не mdadm'ом единым софтовые рейды ограничены. Да и насчет простоты их настройки можно было б поспорить. Потому как, если делать хорошо, то что софтовый, что железный рейды — оно будет «сложно». Чисто личный опыт после полугодовой эпопеи с построением хранилища примерно на 300тб на 3х серверах скажу, что железные рейды в общем проигрывают более-менее грамотно собранному пулу на ZFS. К сожалению, на сегодняшний день, zfs нормально работает только на FreeBSD (ну и на солярке, но это, имхо, совсем редкий зверь теперь). На Linux работает, но рискованно и скорее всего не так быстро.
А с железными рейдами я наелся, хоть и не админ по обязанностям. Что адаптек, что lsi — Imho, дрянь.
И да, я осознал за что бизнес платит такие бабки всяким EMC и netapp. =) Потому что все эти самопалы — всё равно баловство и наколеннечество. Иногда надо чтобы работало хорошо и вопрос денег отходит на второй план… Всё исключительное imho.

Если нужен RAID1/RAID10 — то по производительности (как и по загрузке проца) практической разницы железного с софтовым не будет (по крайней мере на современных процах), по надёжности тоже. Если говорить про RAID5/6, то всё зависит от нагрузок, но всё равно в большинстве случаев всё упирается в производительность самих дисков и размеры кэша (под линухом тут сильно может помочь bcache).

С другой стороны, из личного опыта — за последние 20 лет была куча проблем с железными, причём именно Adaptec — от полной потери данных массива (когда они сходили с ума) до банальных проблем вроде недоступности всего массива после выхода из строя всего одного диска. Не то что бы часто такое случалось, но сам факт несколько расстраивает — от железного RAID такой подставы совсем не ожидаешь. В то же время, с софтовыми (mdadm) вообще ни разу проблем не было, не говоря уже о том что с ними, в случае чего, нет проблем с восстановлением.