Несколько массивов для Random I/O

[Хармонт]

Созрел такой вопрос. Когда мы имеем случайный паттерн записи на RAID 5 массив (например виртуальная инфраструктура) один IOPS попадает на один жесткий диск. Чтобы его записать, контроллер должен считать data strip'ы со всех дисков, затем parity strip, пересчитать parity, записать все data strip'ы и parity strip. Т.е. получается, что за один IOPS, один диск выполняет работу, а остальные работают вхолостую. Если есть 12 дисков, не лучше ли для такой нагрузки создать три RAID 5 по 4 диска, вместо одного на 12?

[LCF_R]

Вы говорите про Raid Penalty. С точки зрения бОльшей производительности целесообразнее собрать RAID-10.

[gs]

Рэйд5 делает 4 дисковых операции на одну операцию записи хоста. От количества массивов это не изменится - только больше винтов потеряете. Делайте рэйд10.

[Хармонт]

Рэйд5 делает 4 дисковых операции на одну операцию записи хоста. От количества массивов это не изменится - только больше винтов потеряете. Делайте рэйд10.

У нас хранилище разделено на два уровня. Часть машин на RAID 10 массиве из 10k SAS дисков. Другая часть на RAID 5 из 7,2k NL-SAS. Но вопрос не в этом. Возможно я не четко сформулировал.

Penalty на RAID 5 от количества массивов конечно же не изменится. Но предположим у нас есть две операции ввода/вывода. Если мы имеем один массив, то мы будем выполнять их последовательно. Сначала прочитаем и запишем stride в который попадает первая операция, потом то же самое сделаем для второй. На двух RAID-массивах мы сможем выполнять две эти операции параллельно. Т.е. первый RAID будет читать/пересчитывать/писать stride для первой операции, а второй RAID для второй.

Если сравнить большой массив с маленьким для random write с точки зрения скорости записи, то она будет одинаковая. Ведь блок данных попадает всего на один диск. И нет разницы находится этот диск в большом массиве или маленьком. А если сравнивать один большой массив с двумя маленькими с точки зрения IOPS, то получаем профит от параллельной работы.

Я понимаю, что у диска есть своя очередь, операции туда падают и обрабатываются с определенной скоростью. Если операции падают примерно равномерно по всем дискам, то чем больше в массиве дисков, тем больше данных он способен обработать в один момент времени. Но очередь просто не будет наполняться. Ведь на каждую операцию записи мы будем дергать все диски на чтение. И в результате в каждый момент времени в RAID'е будет лежать одна операция ввода/вывода на одном диске.

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

[gs]

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

[Хармонт]

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

Да, я намеренно не включал в свои рассуждения работу кэша. Чтобы кто-то мог подтвердить мои первоначальные рассуждения.

Что касается кэша. Польза кэша на запись заключается в том, что он способен собирать мелкие операции и писать их, так называемыми, full stride write'ами. RAID5 в такой ситуации получится быстрее RAID10. Но мне кажется, что к mid-range системам это не относится. Возьмем пресловутый Storwize V7000 с 8ГБ кэша. Одно дело, когда к нему подключен единственный OLTP-хост с базой. Если начать валить на него нагрузку с 12 лезвий, на каждом из которых по 6 виртуальных машин, то эта ситуация называется модным нынче термином "I/O Blender". Т.е. в кэше получается такая мешанина, что оптимизировать мало что получается.

Что Вы думаете на этот счет?

[gs]

Я думаю, что Вы занимаетесь пустым философствованием.

[Хармонт]

Я думаю, что Вы занимаетесь пустым философствованием.

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

[Bormoto]

To Хармонт:
Что мешает найти закономерности самостоятельно? Аппаратура у Вас вроде бы есть, iometer тоже для всех доступен. Составляйте матрицу планирования эксперимента, тестируйте, стройте зависимости, выкладывайте в сети или сохраняйте в тайне.
Есть computer science и есть инженерные методы расчетов, зачастую чисто эмпирические.
Вот, например, хранилища Xyratex. Ознакомиться с фирменной книжкой "Xyratex Performance Specialist Handbook. Support for 5000 and 6000 series RAID Products" мне удалось только после прекращения их выпуска и поддержки производителем и незадолго до окончания гарантии на купленные устройства. Т.е., схемотехническое устройство было практически неизвестно и никаких особых предположений, кроме вытекающих из рекомендаций и правил от руководств пользователя по HW и SW, было не сделать. Тестирование, сравненительный анализ - обычный путь для "черных ящиков".

[diz]

Для IBM`овских СХД есть тулза, которая позволяет моделировать нагрузку и достаточно достоверно предсказывать результат даже с учетом "сложных" технологий типа EasyTier. Для расчета под конкретную задачу Вы всегда можете обратиться к партнеру, который все посчитает, или попросит посчитать IBM.

[Stranger03]

Для IBM`овских СХД есть тулза, которая позволяет моделировать нагрузку и достаточно достоверно предсказывать результат даже с учетом "сложных" технологий типа EasyTier. Для расчета под конкретную задачу Вы всегда можете обратиться к партнеру, который все посчитает, или попросит посчитать IBM.

Ты имеешь ввиду диск-магик? Есть такая, часто пользуемся.

[Stranger03]

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

Если есть конкретная задача, то нужны вводные данные:
1. требуемый размер тома
2. соотношение записи и чтения
3. размер блока на запись и на чтение
4. требуемое кол-во ИОПС-ов или МБ в сек.
Тогда можно легко сделать расчет и понять, что можно получить при каком рейде и сколько дисков понадобится.

[diz]

Ты имеешь ввиду диск-магик? Есть такая, часто пользуемся.

Ага.

[UA8]

Я думаю, что Вы занимаетесь пустым философствованием.

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

Автору респект за вопрос. По-моему, решение лежит примерно здесь
http://msdn.microsoft.com/ru-ru/library ... 63392.aspx
Disk
Storage is one of the aspects most often overlooked when you configure an RD Session Host system, and it can be the most common limitation on systems that are deployed in the field.
The disk activity that is generated on a typical RD Session Host system affects the following three areas:
• System files and application binaries
• Pagefiles
• User profiles and user data

Ideally, these three areas should be backed by distinct storage devices. Using striped RAID configurations or other types of high-performance storage further improves performance. We highly recommend that you use storage adapters with battery-backed caches that allow writeback optimizations. Controllers with writeback caches offer improved support for synchronous disk writes. Because all users have a separate hive, synchronous disk writes are significantly more common on an RD Session Host system. Registry hives are periodically saved to disk by using synchronous write operations. To enable these optimizations, from the Disk Management console, open the Properties dialog box for the destination disk and, on the Policies tab, select the Enable write caching on the disk and Enable advanced performance check boxes.

Ничего, если не винда и не рдп - важна идея разнесения разнотипной нагрузки по разным хост-адаптерам. Очевидно, что к этим хба нужно мапить разные массивы\LUN'ы

[Хармонт]

To Хармонт:
Что мешает найти закономерности самостоятельно? Аппаратура у Вас вроде бы есть, iometer тоже для всех доступен. Составляйте матрицу планирования эксперимента, тестируйте, стройте зависимости, выкладывайте в сети или сохраняйте в тайне.

Комплекс активно развертывается, особо не потестируешь. Многое уже сделано. Но дело даже не в этом. Вы же не будете по любому вопросу составлять матрицу планирования эксперимента и строить зависимости. А потом при любых изменениях исходных данных снова составлять матрицу планирования эксперимента и снова строить зависимости. Я согласен, что СХД - в определенной степени черный ящик. Но матчасть у всех одна. Я не знаю почему мой вопрос вызвал такие затруднения.