[Soft] RAID5 or RAID10 для сервера?

я бы не доверял результатам софтовых рейдов на левом железе

>RAID1 через mdadm - скорость чтения такая же, как и для одного диска. А где параллельность чтения?

Вот, это я примерно и представлял.
Больше интересует, будет ли скорость выше у RAID 0+1, где скорость чтения с массивов RAID1 должна быть выше даже без распараллеливания.

>>RAID1 через mdadm - скорость чтения такая же, как и для одного диска. А где параллельность чтения?

Это странно, у меня в 1.5 раза выше, чем с одного диска. Но это «прямая» скорость чтения, не random.

>может swap просто в файл писать на raid10

А как же куча срачей по поводу фрагментации этого файла и размазывании по диску тонким слоем?
Уж лечше просто раздел внутри RAID10

> чтение (всех дисков, кроме контрольной суммы, делается параллельно со всех дисков, считаем одной операцией)

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

За счет чего меньшие цифры?

За счет того, что они взяты с потолка.

Асинхронность работы дисков? Т.е., пока идет операция записи обрабатывается уже другой запрос?

Тут играет роль масса факторов - наличие и объем энергонезависимого кэша, его заполненность, наличие или отсутствие изменяемого страйпа в кэше, особенности реализации, и так далее.

Хочешь увидеть реальные тормоза - выключи кэш. Кстати, при отключенном кэше RAID5 уже гораздо труднее обеспечивать корректную работу, ибо повторить операцию в случае сбоя уже неоткуда.. И тут уже начинают изголяться - например, пишут сначала новое содержимое диска с данными, потом - новое содержимое диска с четностью, чтобы, если в процессе профилактической проверки обнаружится несоответствие содержимого дисков с данными и диска с четностью, считать, что исправлять нужно четность. Впрочем, это тоже спасает далеко не всегда.

Потребление ресурсов со сравнению с RAID5 - да, больше, но куда девается производительность?

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

> Производительность RAID1 на запись примерно равна скорости одного диска, соответственно, фразу выше можно расценивать как сравнение с одним диском. Почему берется 10-25%? Ведь с учетом того, что при записи произвольного блока данных небольшого размера надо выполнить 2 операции - чтение (всех дисков, кроме контрольной суммы, делается параллельно со всех дисков, считаем одной операцией) и запись (модифицированный блок и контрольная сумма для всего страйпа, тоже делаются параллельно) - и если чтение и запись у нас делается примерно с одной скоростью (в принципе, у реальных дисков они не сильно различаются), допустим, по 200 Мб/сек, то с точки зрения системы изначальная операция записи должна проходить со скоростью около 100 Мб/сек, т.е., потери скорости должны быть порядка 50% от скорости одного диска. За счет чего меньшие цифры? Асинхронность работы дисков? Т.е., пока идет операция записи обрабатывается уже другой запрос?

Это все еще зависит от того сколько данных пишется. Если достаточно много, то теоретически скорость записи в raid5 с 3-мя дисками должна быть существенно выше, чем в raid1. В идеале примерно в 2 раза.

Запись: raid1 (2 диска) — один блок данных пишется одновременно на два диска. raid5 (3 диска) — два блока данных пишутся параллельно на два диска, и на третий пишется их xor. Потеря в скорости идет из-за вычисления xor. Говорят, она 10-20%, в софтверном рейде и примерно это и наблюдаю.

Чтение: raid1 (2 диска) — если повезет, то два блока данных читаются параллельно. raid5 (3 диска) — если повезет, то три блока данных читаются параллельно.

Т.е. все проблемы от того как попадутся блоки данных, можно ли их запараллелить? Если чтение будет проводится очень маленькими блоками (меньше, чем разметка рейда), то разумеется у raid5 и пр. будет большой проигрыш, а у raid1 не будет выйгрыша в паралелльности чтения (ее просто не будет).

> Необязательно читать все, можно прочитать тот, который меняется, и тот, который с четностью, и используя старое содержимое диска с данными и диска с четностью плюс новое содержимое диска с данными можно вычислить новое содержимое диска с четностью.

А все равно 2 операции остается, просто алгоритм меняется.

Хочешь увидеть реальные тормоза - выключи кэш.

Что отключать в случае ядерного raid'а? :)

Операций выполнять больше приходится (а диски не все одинаковые, то есть выполняться каждый этап будет столько, сколько выполняется операция на самом медленном диске)

Ок, но если рассматривать теоретическую физику процесса, не привязываясь к тому, что могут попасться медленные диски и т.п. - тогда просадок быть не должно?

При том же объеме кэша больше места занимает четность, соответственно, можно закэшировать меньше полосок.

Опять-таки, возвращаемся к mdadm.

Потеря в скорости идет из-за вычисления xor. Говорят, она 10-20%, в софтверном рейде

Странно, ибо даже на моем паршивом Athlon 3800+:

[ 817.811264] xor: automatically using best checksumming function: generic_sse

[ 817.816009] generic_sse: 6156.000 MB/sec

Даже если писать данные со скоростью 200 МБ/сек - это будет порядка 3%.

> А все равно 2 операции остается, просто алгоритм меняется.

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

Что отключать в случае ядерного raid'а? :)

Так ты про софтовый? Тогда там и включать то нечего :) И использовать софтовый RAID5 для чего-то чуть более серьезного, чем файловая помойка - я бы не стал (корректность).

Ок, но если рассматривать теоретическую физику процесса, не привязываясь к тому, что могут попасться медленные диски и т.п. - тогда просадок быть не должно?

См. выше про позиционирование головок.

> При том же объеме кэша больше места занимает четность, соответственно, можно закэшировать меньше полосок.

Опять-таки, возвращаемся к mdadm.

Ну возвращаемся, и чего? Памяти то все равно больше надо :-) Хотя время позиционирования головок будет играть наибольшую роль, пожалуй.

> будет ли скорость выше у RAID 0+1

В случае тех же двух дисков? Или полноценный RAID 0+1? В любом случае должна быть выше, что и подтверждается у меня экспериментом

> Так ты про софтовый?

Первые 2 вопроса, как уже сказал, скорее по теории, чем в привязке к конкретной реализации RAID'a :)

И использовать софтовый RAID5 для чего-то чуть более серьезного, чем файловая помойка - я бы не стал

За что такая нелюбовь к софтовым RAID'ам?

См. выше про позиционирование головок.

Ок, пусть будет совсем без головок - на SSD.

> Если чтение будет проводится очень маленькими блоками (меньше, чем разметка рейда), то разумеется у raid5 и пр. будет большой проигрыш, а у raid1 не будет выйгрыша в паралелльности чтения (ее просто не будет).

Кто сказал? IOPS'ы то никуда не денутся, и пока один маленький блок читается с одного диска, другой диск может выполнять чтение дургого маленького блока. Конечно, если фишка ляжет так, что читаться будет только один диск, тогда да.. Но это при случайном характере нагрузки маловероятно.

> За что такая нелюбовь к софтовым RAID'ам?

Попрошу не обобщать - нелюбовь только к RAID5/6. Против RAID1 возражений меньше, и совсем нет, если он в исполнении btrfs (с включенными контрольными суммами, разумеется).

См. выше про позиционирование головок.

Ок, пусть будет совсем без головок - на SSD.

Да, SSD не требуется время на позиционирование головок. Но с SSD есть свои особенности. Например, из-за более высокой скорости передачи данных могут начать вылезать проблемы с мастшабируемостью внутри софта, которые с обычными дисками увидеть малореально. Соответственно, операции чтения/записи могут получиться не параллельными, а последовательными.

Так что фиг его знает, что там на самом деле с SDD.. А поскольку ни SSD, ни времени и желания разбираться, как в md соотносятся скорости RAID5 и RAID6, у меня нету, я предпочту на этом остановиться.

Или полноценный RAID 0+1?
Да, имеется ввиду софтовый рэйд10

> Попрошу не обобщать - нелюбовь только к RAID5/6.

Ок, за что такая нелюбовь к софтовым RAID'ам 5-го/6-го уровня?

или линуксовый raid1 не умеет параллельно читать данные с нескольких дисков?

green года 3 назад смотрел код ядерного md, говорил, что не мог.

Однако... Т.е., тогда с оглядкой на

RAID 10 — .......... Нынешние контроллеры используют этот режим по умолчанию для RAID 1. То есть, 1 диск основной, 2-й диск — зеркало, причем чтение производится с них поочередно, как для RAID 0.

(с) W

лучше и софтовый RAID1 создавать в виде

mdadm -C -l10 -p f2 -n2 /dev/md0 /dev/sda1 /dev/sdb1

> Ок, за что такая нелюбовь к софтовым RAID'ам 5-го/6-го уровня?

Вопросов два - скорость (ибо кэша нет) и корректность (ибо кэша нет). Понятие «Write hole» знакомо?

RAID10=RAID1+RAID0. Соответственно, если RAID1 не умеет читать одновременно с двух дисков, то почему ты думаешь, что RAID10 может? :)

Потому что это RAID0 на двух однодисковых RAID1.

Собственно, параллельность чтения зависит в данном случае от конфигурации RAID10 и -p f2 этому способствует. Дефолтно создается массив с n2, т.е., зеркалируемые блоки располагаются с одним сдвигом и параллельного чтения нет.

> Кэш

А разве системного кэша дисковых операций (т.е., всей свободной оперативки) в случае софтового массива недостаточно? Или это немного не то?

Понятие «Write hole» знакомо?

Нет, не слышал, читаю...

Кстати, насчет кэша - в статьях по оптимизации soft-raid'a нашел такой парамер, как stripe_cache_size, например. Насколько понимаю, тоже такой себе аналог кэша на железных контроллерах.

> А разве системного кэша дисковых операций (т.е., всей свободной оперативки) в случае софтового массива недостаточно? Или это немного не то?

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

> Насколько понимаю, тоже такой себе аналог кэша на железных контроллерах.

Так себе аналог. Он просто говорит, сколько памяти md отожрет под свой кэш страйпов.

В чем отличие от кэша на аппаратном RAID'е, который RAID так же само использует «под свой кэш страйпов» (с)?

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

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

я бы не доверял результатам софтовых рейдов на левом железе

Я бы тоже, то только при условии, что ФС не поддерживает сквозную целостность данных.

Энергонезависимость актуальна при перебоях с питанием, в остальном они равнозначны. В случае с soft-raid'ом это решается ЮПСкой и корректным выключением.

Насчет синхронной записи и кэша - мне кажется, ты путаешь системный дисковый кэш (который я упомянул в link, но да, это немного не то) и кэш самого RAID'a, работающий на более низком уровне (который вот это) и аналогичный кэшу железного RAID'а. И там, и там к синхронной записи они отношения уже не имеют (думаю, в софтовом это тоже так, иначе бы в нем не было особого смысла) - система кинула на диск данные, а как там с ними разбирается массив - уже не ее дело.

Давай пропустим в RAID'отреде вопросы о ZFS, BSD и иже с ними :)

Я хотел бы поднять вопрос о Btrfs. Как она поддерживает RAID-5? ;)

Не знаю, я не рисковал пока ее где-либо использовать. Да и вряд ли буду в ближайшем будущем организовывать RAID средствами FS.

> Энергонезависимость актуальна при перебоях с питанием, в остальном они равнозначны. В случае с soft-raid'ом это решается ЮПСкой и корректным выключением.

Перебои с питанием не есть единственный возможный вариант некорректного завершения работы. Другие примеры сам придумаешь или подсказать?

мне кажется, ты путаешь системный дисковый кэш

Крестись, раз кажется :-) Думаю, тебе надо еще раз почитать про то, что такое RAID5 и как он работает, и подумать. Объяснять по второму кругу мне неохота.

> Другие примеры сам придумаешь

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

Думаю, тебе надо еще раз почитать про то, что такое RAID5 и как он работает, и подумать.

Я уже достаточно почитал на этот счет. Можно было бы провести наглядный эксперимент, но сейчас под рукой не осталось свободных и более/менее одинаковых дисков.

Объяснять по второму кругу мне неохота.

Ок, тогда лучше на этом закончим.

Раз уж завернули в тему ФС, что можете посоветовать для рэйд10 в свете поставленных задач?

хз, я традиционно для мелких файлов веб-контента reiser 3.6 использую. Проблем с ней не было. Другой человек посоветует другое, а reiser назовет глюкавой поделкой. Пробуй сам, решай сам :)

при чём тут контроль целостности?
я про цифры, которые получены на софтовой реализации рейда.

reiserfs 3.6 или ext4 если ядро достаточно новое.

Вот своего рода бенчмарк с сервера с RAID10 (4 диска по терабайту), ОС - Linux 2.6.32.14-ovz32 x86_64, ФС - ext4 (замаунчена с опцией «nodelalloc», иначе openvz вешает все нафиг).

root@vps-1:~# dd if=/dev/zero of=5G bs=10M count=500
500+0 records in
500+0 records out
5242880000 bytes (5.2 GB) copied, 24.3414 s, 215 MB/s
root@vps-1:~#

Есть сторонняя нагрузка, а без нагруза ~220MB/s давало.

Забыл добавить, там LVM еще, а потом уже ext4.

Спасибо, будет с чем сравнить. Как раз и думал терабайтники брать.