Storage Performance

Данная статья просилась сразу после окончания курса по HP EVA, но я ее откладывал по различным причинам.

Своеобразным катализатором стала вот эта статья, и я решил – сейчас или никогда 😉

В статье по ссылке рассказывается общая теория про различные уровни рейд-массивов (Raid1, Raid5, Raid6 и Raid10).

В частности, мы видим, что в теории пенальти по IOPS на запись для R10 – 2, для R5 – 4 и для R6 – 6.  Логично предположить, что для MB/s пенальти будет таким же?

IOPS это операция чтения/записи с системой хранения данных. Пролетарии всех стран никак не могут договориться о величине этих IOPS для разных типов дисков(7к, 10к, 15к).

Причина этого кроется в том, что очень важен размер блока, с которым происходит тестирование диска. Возьмем, к примеру СХД HP MSA500 G2, участвующую в наших тестах. По мнению HP: на двух хостах по двум каналам она достигает производительности в 14000IOPS. А между тем скорость чтения в MB/s данной системы с одного хоста (14 SCSI) уступает семи SAS-дискам (то есть, дисков вдвое меньше, а скорость чтения с помощью HDTune выше)!

Вот тут я предложил угадать, кто будет быстрее: 7 SAS-дисков или 14 SCSI 🙂

Даю долгожданный ответ:

Дам несколько пояснений: seq – последовательный доступ, rand – случайный.

Тестировались три набора “железа” (физический сервер HP Proliant DL380 G5, 2Xeon 53**, 4GB RAM):

1. Smart Array P400 PCI-E, 8 hdd 300Gb 10k, Raid6 (модель диска – HP DG0300FARVV – двухпортовые SAS-диски);
2. Smart Array P400 PCI-E, 7 hdd 72Gb 10k, Raid6 (модель диска – HP DG072A8B54 – однопортовые SAS-диски);
3. MSA500 G2 (СХД) SCSI + Smart Array 642(HBA) PCI-X, 14 hdd 72Gb 15k, Raid10 (модель диска – COMPAQ BF0728A4CB)

Для чистоты эксперимента делалось три теста по 5 минут в IOmeter. Случайный доступ тестировался блоками по 8кб, последовательный – 32кб. Остальные настройки IOmeter:

=====================================

Worker 1

Worker type

DISK

Default target settings for worker

Number of outstanding IOs,test connection rate,transactions per connection

64,ENABLED,500

Disk maximum size,starting sector

20000000,0

Run time = 5 min

=====================================

Как мы видим, по операциям последовательного доступа SCSI-диски уступают более новым SAS-дискам, в то время как на случайном доступе имеем отрыв SCSI-дисков 😉

Причем если операции чтения быстрее на 50%, то операции записи на 200% (Raid10 – сила) 😉

Вопросы вызывает разве что завал по скорости записи у 300GB SAS-дисков. Частично его можно объяснить тем, что в процессе тестирования на эти диски шла DFS-репликация файлового хранилища.

После торжества R10 я решил, что это все хорошо, но неплохо сравнить разные типы рейдов на одном наборе железа.

В результате был выбран HP Proliant BL460G6 и СХД HP EVA4400 (8*FC300GB_15k), на котором созданы три луна по 50GB (R1, R5, R6).

Как видим по случайному доступу на запись, теория блестяще подтверждается. С другой стороны, теория гласит, что потери по IOPS на запись составляют в R10 вдвое по сравнению с чтением. Соответственно, если на запись мы получаем 3000 IOPS, то на чтение должны получить 6000IOPS. А вот фигХмм?

Непонятен завал по скорости последовательной записи у R6. Не совсем понятна и более низкая скорость R1 на чтение…

Каждый подобный завал по скорости в обоих тестах я тестировал еще два раза, чтобы убедиться, что ошибки нет.

Чтобы убедиться в торжестве теории еще раз (и заодно проверить, что я не упираюсь в каналы, был проведен тест случайной записи на R1/R5(по 27 дискам, нагруженным другой нагрузкой ~500IOPS чтения/записи от VMware vSphere).

Результаты более менее прогнозируемые: R1 – 9529, R5 – 4290.

Есть хорошая новость – далеко не каждому типу загрузки свойственна случайная запись, тем более в таких количествах. К примеру, базы MS Exchange 2007 используют случайный доступ, но из него только 50% идет на запись.

Кроме скорости дискового массива также стоит учитывать степень его надежности и нагрузки в случае ребилда массива.

R1/R10 способен (в оптимистичном сценарии) пережить смерть половины своих жестких дисков. В пессимистичном его прибьет смерть двух дисков из одной пары. Ребилд массива дает 35% пенальти, согласно рекомендациям от MS (на которые ссылается документ по ссылке).

R5 переживает смерть только одного диска из массива. Ребилд удваивает пенальти (то есть нам нужно вдвое больше дисков, чтобы не просесть по IOPS при ребилде).

R6 переживает смерть любых двух дисков, пенальти на перестроение массива аналогично R5.

Вот тут сравнивают R10 vs R5 – сколько дисков потребуется под базы Exchange 2007 в конфигурации CCR. 8,9TB на ноду в R10 против 39ТБ в R5 – как вам?

Впрочем, про это уже писал Romx, когда предлагал считать системы по IOPS’ам, а не по мегабайтам.

Резюме

1. Считаем скорость в MB/s только если нам предстоит последовательный доступ к данным! Как мы видели на тестах, наличие кэша вполне способно до определенной степени сравнять последовательную нагрузку на диски в разных типах рейд-массивов. Производительность случайного доступа может отличаться;
2. Не стоит считать, что если 8 дисков на чтение дадут 750 MB/s, то 16 дисков выдадут 1,5GB/s. Это неправильно как с точки архитектуры, так и того, что производительность кэша не увеличивается пропорционально количеству дисков 😉 Очень похоже, что данный тест (последовательное чтение) уперся в скорость интерфейса – FC8GBIT/s. Помним, что на эффективность последовательного доступа влияют алгоритмы и продвинутость кэша;
3. Согласно HP, FC15k выдает 115IOPS. Знакомый препод из HP называл 120 IOPS. При этом жесткий диск с EVA в тестах выдает от 352 до 386 IOPS. Подозреваю, народ рекомендует такие цифры потому, что многие из нас выберут R5/R6, а у него пенальти на перестроение массива 100%. Соответственно, чтобы по IOPS’ам из калькуляторов/документации не пролететь и задается подобный запас прочности;
4. Скорость диска согласно документации из курса по HP EVA- 20MB/s. Я бы считал скорость в 20MB/s для SATA-диска. А для SAS/FC 15k – 40 MB/s. Это справедливее, чем верить маркетологам, заявляющим, что home SATA дает скорость в 50-60MB/s;
5. Подбираем тип рейда под существующую загрузку. Ложить транзакционные логи на R6 можно (спасибо алгоритмам кэширования), но оптимальнее будет это сделать на R1/R10;
6. С точки зрения надежности, не стоит объединять больше 8 дисков  в Raid5, даже если это Enterprise SATA/SAS/FC-диски.