Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 11
В RAID 5 чтобы записать данные происходит 4 операции (Чтение существующих данных, четность RAID, Запись новых данных, Запись новой четности) тем самым пенальти в RAID 5 составляет 4.
Эти расчеты актуальны до тех пор, пока записываемый блок данных меньше или равен чанку, из которых состоит raid. Если же блок записываемых данных больше, или, банально, файловая система не выровнена относительно чанков, или если мы пишем сразу на все диски, то кол-во IOPS может изменяться. Во многих случаях операции записи кэшируются в памяти (сервера или дискового контроллера) и уже потом пишутся на диск последовательно.
Любые операции чтения, которые выполняются на дисках, не подвергаются никакому пенальти, поскольку все диски могут использоваться для операций чтения.
Это почему же не подвергаются? Какие полезные данные вы получаете с дисков, хранящие четность в RAID-5 или RAID-6? Или даже более наглядный пример — RAID-4, который использует выделенный диск под хранение четности.
Дожил хабр. Картинками показываем разницу между последовательным и произвольным доступом.
Ну а дальше вообще детский сад:
Да что вы говорите. Большие файлы, стало быть. И это исключает возможность чтения из разных областей накопителя. Ну-ну.
Велик и могуч русский язык. Грамматика, орфография и пунктуация смотрят на вас с негодованием. Плюс куча совершенно диких опечаток.
Это изречение устарело на несколько лет минимум (в части выбора RAID).
А это что такое было? Почему вы игнорируете размер блока, который по вашим словам так важен, при подсчете IOPS? Functional IOPS вы для какого размера блока считали? Зачем ружье в начале статьи повесили? По законам жанра оно должно стрелять.
Ну и вообще, зачем вы копипастите википедию? Расскажите о значении задержек, о том, что оценка в «лоб» IOPS уже давно не актуальна, о том что различные уровни RAID во многих массивах практически не отличаются по производительности, о том что существуют иные уровни RAID, кроме привычных и т.д и т.п
Ну а дальше вообще детский сад:
Под линейными операциям чтения/записи, при которых части файлов считываются последовательно, одна за другой, подразумевается передача больших файлов (более 128 К).
Да что вы говорите. Большие файлы, стало быть. И это исключает возможность чтения из разных областей накопителя. Ну-ну.
не подвергаются никакому пенальти
…
имеет два пенальти
…
Велик и могуч русский язык. Грамматика, орфография и пунктуация смотрят на вас с негодованием. Плюс куча совершенно диких опечаток.
Понимание характеристики рабочей нагрузки является наиболее критическим фактором, поскольку от этого и зависит выбор оптимального RAID для среды.
Это изречение устарело на несколько лет минимум (в части выбора RAID).
По сути, IOPS это количество блоков, которое успевает считаться или записаться на носитель. Чем больше размер блока, тем меньше кусков, из которых состоит файл, и тем меньше будет IOPS, так как на чтение куска большего размера будет затрачиваться больше времени.
Значит, для определения IOPS надо знать скорость и размер блока при операции чтения / записи. Параметр IOPS равен скорости, деленной на размер блока при выполнении операции.
А это что такое было? Почему вы игнорируете размер блока, который по вашим словам так важен, при подсчете IOPS? Functional IOPS вы для какого размера блока считали? Зачем ружье в начале статьи повесили? По законам жанра оно должно стрелять.
Ну и вообще, зачем вы копипастите википедию? Расскажите о значении задержек, о том, что оценка в «лоб» IOPS уже давно не актуальна, о том что различные уровни RAID во многих массивах практически не отличаются по производительности, о том что существуют иные уровни RAID, кроме привычных и т.д и т.п
С википедии взял значения iops для разных дисков, и картинку. Оценка в «лоб» IOPS давно не актуальна — простите, а как Вы тогда рассчитываете СХД под базы данных или запас производительности сервера БД, различными benchmark'ами, или просто используете Fusion-IO или ZeusIOPS® SSD? То, что различные уровни RAID во многих массивах практически не отличаются по производительности — тут я с Вами согласен. Недавно сравнивал RAID5, RAID6, RAID10 на одной СХД с одинаковым количеством дисков. Показатели по производительности практически одинаковые, только стоит учесть, что при вылете диска из RAID6 производительность упадет на порядок ниже, чем при вылете диска из RAID 10. Все остальные замечания запомнил на будущее, и постараюсь их не допускать.
Недавно сравнивал RAID5, RAID6, RAID10 на одной СХД с одинаковым количеством дисков. Показатели по производительности практически одинаковые
Не напишете конфигурацию СХД и методику замера?
На LSI CTS2600 с 24 дисками производительность R6, R10 и DDP заметно отличается, как в иопсах, так и в latency. DDP на 25% быстрее R6, а R10 на 30% быстрее DDP при R/W=67/33 и 4КБ блоках.
В качестве тестового стенда выступали сервер IBM System x3550 M3 с ОС Windows 2008 R2 (2х Xeon 5675 @ 3.07Ghz, 96Gb RAM) и СХД Hitachi Unified Storage (HUS-110, набитый 24 2,5" дисками по 600Gb со скорость 10k).
Тестирование проводилось в 3 этапа:
3RG-8D(7D+1P) — 3 рейд группы по 8 дисков (7 дисков + 1 диск четности) собранные в RAID5.
2RG-12D(10D+2P) — 2 рейд группы по 12 дисков (10 дисков + 2 диска четности) собранные в RAID6.
1RG-24D(22D+2P) — 1 рейд группа из 24 дисков (22 диска + 2 хотспара) собранные в RAID10.
Диски четности или диски хотспара СХД создает самостоятельно.
Тестирование проводилось утилитами SQLIO и IOMETER с 500Gb файлом.
Параметры SQLIO во время тестирования: Test with 6 threads using mask 0x0 6 threads reading / writing for 600sec using 8/64KB random/sequential IOs enabling multiple I/Os per thread with 4 outstanding buffering set to use hardware disk cache (but not file cache) using size 512000MB for file test.
Параметры IOMETER во время тестирования: Transfer request size 64k, Percent of access spetification 100%, Percent distribution 45% sequential 55% random, Percent distribution 60% write 40% read, Transfer delay 0ms, Burst length 1 I/Os, Test time 2h.
Результат по IOPS:
По latency R6 и R10 одинаковы, за исключением Write Random 8k и 64k. Тут R10 несколько быстрее R6.
В IOMETER примерно тоже самое, R10 немного быстрее R6.
Тестирование проводилось в 3 этапа:
3RG-8D(7D+1P) — 3 рейд группы по 8 дисков (7 дисков + 1 диск четности) собранные в RAID5.
2RG-12D(10D+2P) — 2 рейд группы по 12 дисков (10 дисков + 2 диска четности) собранные в RAID6.
1RG-24D(22D+2P) — 1 рейд группа из 24 дисков (22 диска + 2 хотспара) собранные в RAID10.
Диски четности или диски хотспара СХД создает самостоятельно.
Тестирование проводилось утилитами SQLIO и IOMETER с 500Gb файлом.
Параметры SQLIO во время тестирования: Test with 6 threads using mask 0x0 6 threads reading / writing for 600sec using 8/64KB random/sequential IOs enabling multiple I/Os per thread with 4 outstanding buffering set to use hardware disk cache (but not file cache) using size 512000MB for file test.
Параметры IOMETER во время тестирования: Transfer request size 64k, Percent of access spetification 100%, Percent distribution 45% sequential 55% random, Percent distribution 60% write 40% read, Transfer delay 0ms, Burst length 1 I/Os, Test time 2h.
Результат по IOPS:
По latency R6 и R10 одинаковы, за исключением Write Random 8k и 64k. Тут R10 несколько быстрее R6.
В IOMETER примерно тоже самое, R10 немного быстрее R6.
С википедии взял значения iops для разных дисков, и картинку.
Для начала давайте проясним, вы Юрий Семенихин или Антон Балашов? Потому что если вы Антон Балашов, то получается, что текст статьи цельнотянут отсюда. Ну а картинка да, с википедии.
Оценка в «лоб» IOPS давно не актуальна — простите, а как Вы тогда рассчитываете СХД под базы данных или запас производительности сервера БД, различными benchmark'ами, или просто используете Fusion-IO или ZeusIOPS® SSD?
Оценка в «лоб» с использованием ваших таблиц и формул не работает для большинства серьезных массивов, поскольку не учитывает влияние специфики реализации RAID на конкретной железке, заполнение дисков, их количество и размер RAID-групп, влияние кэширования и т.п. и т.д. Единственный смысл этой оценки — определение минимально возможной производительности бэкенда (дисков), да и то с прицелом в километр.
RAID6 производительность упадет на порядок ниже, чем при вылете диска из RAID 10
Когда делаете такие утверждения — указывайте пожалуйста конкретный массив, потому что лично я знаю несколько контр-примеров.
Используемые источники: citrix.pp.ru (большая часть), wikipedia.org (картинки и таблицы iops дисков), и aboutnetapp.ru.
Что же касается утверждений, то вот 2 массива, IBM DS3524(dual controller + Turbo Perfomance) и LSI MegaRAID 9280-8e (with BBU). На этом СХД и RAID-контроллере столкнулся с деградацией производительности на личном опыте года полтора назад.
Что же касается утверждений, то вот 2 массива, IBM DS3524(dual controller + Turbo Perfomance) и LSI MegaRAID 9280-8e (with BBU). На этом СХД и RAID-контроллере столкнулся с деградацией производительности на личном опыте года полтора назад.
Т.е. вы не господин Семенихин? А как вы объясните тот факт, что этот ваш топик и вот эта статья от января 2011 года совпадают дословно? Вплоть до ржачного "(Edited by Reader)" в таблице? На citrix.pp.ru хотя бы источник копипасты указывают.
Сначала приводится таблица различающая IOPSы по произвольности/последовательности, а потом следом бац таблица где просто IOPS :) и судя по числам, там имелись ввиду IOPS случайного доступа…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
IOPS — что это такое, и как его считать