Героем этого обзора будет скромная система хранения данных DotHill 4824. Наверняка многие из вас слышали, что DotHill в качестве OEM-партнёра производит СХД начального уровня для Hewlett-Packard — те самые популярные HP MSA (Modular Storage Array), существующие уже в четвёртом поколении. Линейка DotHill 4004 соответствует HP MSA2040 с небольшими различиями, которые будут подробно описаны ниже.
DotHill — это классическая СХД начального уровня. Форм-фактор, 2U, два варианта под разные диски и с большим многообразием хостовых интерфейсов. Зеркалируемый кэш, два контроллера, ассиметричный active-active с ALUA. В прошлом году добавился новый функционал: дисковые пулы с трёхуровневым tiering'ом (ярусным хранением данных) и SSD-кэшом.
Для тех, кто не знаком с теорией, стоит рассказать о принципах работы дисковых пулов и ярусного хранения. Точнее, о конкретной реализации в СХД DotHill.
До появления пулов у нас было два ограничения:
Дисковый пул в СХД DotHill — совокупность нескольких дисковых групп с распределением нагрузки между ними. С точки зрения производительность можно рассматривать пул в качестве RAID-0 из нескольких подмассивов, т.е. мы уже решаем проблему коротких дисковых групп. Всего на СХД поддерживается только два дисковых пула, A и B, по одному на контроллер), в каждом пуле может быть до 16-ти дисковых групп. Главное архитектурное отличие — максимальное использование свободного размещения страйпов по дискам. На этой особенности основаны несколько технологий и особенностей:
Подключение производилось через один контроллер, прямое, через 4 порта 8Гбит FC. Естественно, маппинг томов к хосту был через 4 порта, а на хосте настроен multipath.
Данный тест представляет собой трёхчасовую (180 циклов по 60 секунд) нагрузку со случайным доступом блоками 8КиБ (8 потоков с глубиной очереди 16 каждый) с различным соотношением чтение/запись. Вся нагрузка сосредоточена на области 0-20ГБ, которая гарантированно меньше объема performance tier'а или кэша на SSD (800ГБ) — это сделано с целью быстрого наполнения кэша или яруса за приемлемое время.
Перед каждым запуском теста том создавался заново (для очистки SSD-tier'а или SSD-кэша), наполнялся случайными данными (последовательная запись блоками 1МиБ), на томе оключалось упреждающее чтение. Значения IOPS, средней и максимальной задержки определялись в пределах каждого 60-секундного цикла.
Тесты со 100% чтением и 65/35 чтение+запись проводились как с SSD-tier'ом (в пул добавлялась дисковая группа из 4x400ГБ SSD в RAID-10), так и с SSD-кэшом (2x400ГБ SSD в RAID-0, СХД не позволяет добавить больше двух SSD в кэш для каждого пула). Том создавался на пуле из двух дисковых групп RAID-6 по 10 дисков 46ГБ 15 тыс. об/мин SAS (т.е. фактически это RAID-60 по схеме 2x10). Почему не 10 или 50? Чтобы намеренно осложнить для СХД случайную запись.
Результаты получились вполне предсказуемыми. Как и утверждает вендор, преимущество SSD-кэша перед SSD-tier'ом заключается в более быстром наполнении кэша, т.е. СХД быстрее реагирует на появление «горячих» областей с интенсивной нагрузкой на случайный доступ: на 100% чтении IOPS'ы растут вместе падением задержки быстрее, чем в случае использования tier'инга.
Это преимущество заканчивается как только добавляется значительная нагрузка на запись. RAID-60, мягко говоря, не очень подходит для случайной записи небольшими блоками, но такая конфигурация была выбрана специально чтобы показать суть проблемы: СХД не справляется с записью, т.к. она идёт в обход кэша на медленный RAID-60, очередь быстро забивается, времени на обслуживание запросов на чтение остаётся мало даже с учётом кэширования. Какие-то блоки туда всё-же попадают, но быстро становятся невалидными, ведь идёт запись. Этот замкнутый круг приводит к тому, что при таком профиле нагрузки кэш, работающий только на чтение, становится неэффективным. Точно такую же ситуацию можно было наблюда с ранними вариантами SSD-кэша (до появления Write-Back) в PCI-E RAID-контроллерах LSI и Adaptec. Решение — используйте изначально более производительный том, т.е. RAID-10 вместо 5/6/50/60 и/или SSD-tier'инг вместо кэша.
В данном графике используется логарифмическая шкала. В случае 100% и использования SSD-кэша можно увидеть более стабильное значение задержки — после наполнения кэша пиковые значения не превышают 20мс.
Какой же можно подвести итог в дилемме «кэширование против ярусного хранения (tiering'а)»?
Что выбрать?
Тестировался том на линейной дисковой группе — RAID-10 из четырёх SSD 400ГБ. В данной поставке DotHill в качестве абстрактных «400GB SFF SAS SSD» оказались HGST HUSML4040ASS600. Это SSD серии Ultrastar SSD400M с достаточно высокой заявленной производительностью (56000/24000 IOPS на чтение/запись 4КиБ), а главное — ресурс в 10 перезаписей в день на 5 лет. Конечно, сейчас в арсенале HGST есть более производительные SSD800MM и SSD1600MM, но для DotHill 4004 вполне хватает и этих.
Использовались тесты, предназначенные для одиночных SSD — «IOPS Test» и «Latency Test» из спецификации SNIA Solid State Storage Performance Test Specification Enterprise v1.1:
Тест состоит из серии замеров — 25 раундов по 60 секунд. Предварительная нагрузка — последовательная запись блоками 128КиБ до достижения 2-кратной емкости. Окно установившегося состояния (4 раунда) проверяется построением графика. Критерии установившегося состояния: линейная аппроксимация в пределах окна не должна выходить за границы 90%/110% среднего значения.
Как и ожидалось, был достигнут заявленный предел производительности одного контроллера по IOPS с малыми блоками. Почему-то DotHill указывает 100000 IOPS на чтение, а HP для MSA2040 — более реалистичные 80000 IOPS (получается по 40 тыс. на контроллер), что мы и видим на графике.
Для проверки проводился тест одиночного SSD HGST HGST HUSML4040ASS600 с подключением к SAS HBA. На блоке 4КиБ было получено около 50 тыс. IOPS на чтение и запись, при насыщении (SNIA PTS Write Saturation Test) запись опускалась до 25-26 тыс. IOPS, что соответствует характеристикам, заявленным HGST.
Средняя задержка (мс):
Максимальная задержка (мс):
Средние и пиковые значения задержки всего на 20-30% превышают таковые для одиночного SSD при подключении к SAS HBA.
Конечно, статья получилась несколько сумбурной и на несколько важных вопросов ответа не даёт:
DotHill — это классическая СХД начального уровня. Форм-фактор, 2U, два варианта под разные диски и с большим многообразием хостовых интерфейсов. Зеркалируемый кэш, два контроллера, ассиметричный active-active с ALUA. В прошлом году добавился новый функционал: дисковые пулы с трёхуровневым tiering'ом (ярусным хранением данных) и SSD-кэшом.
Характеристики
- Форм-фактор: 2U 24x 2,5" или 12x 3,5"
- Интерфейсы (на контроллер): 4524C/4534C — 4x SAS3 SFF-8644, 4824C/4834C — 4x FC 8Гбит/с / 4x FC 16Гбит/с / 4x iSCSI 10Гбит/с SFP+ (в зависимости от используемых трансиверов)
- Масштабирование: 192 диска 2,5" или 96 дисков 3,5", поддерживается до 7-ми дополнительных дисковых полок
- Поддержка RAID: 0, 1, 3, 5, 6, 10, 50
- Кэш (на контроллер): 4ГБ c флеш-защитой
- Функционал: cнапшоты, клонирование томов, асинхронная репликация (кроме SAS), thin provisioning, SSD-кэш, 3-уровневый tiering (SSD, 10/15k HDD, 7.2k HDD)
- Конфигурационные пределы: 32 массива (vDisk), до 256 томов на массив, 1024 тома на систему
- Управление: CLI, Web-интерфейс, поддержка SMI-S
Дисковые пулы в DotHill
Для тех, кто не знаком с теорией, стоит рассказать о принципах работы дисковых пулов и ярусного хранения. Точнее, о конкретной реализации в СХД DotHill.
До появления пулов у нас было два ограничения:
- Максимальный размер дисковой группы. RAID-10, 5 и 6 могут иметь максимум 16 дисков. RAID-50 — до 32-х дисков. Если нужен том с большим количеством шпинделей (ради производительности и/или объёма), то приходилось объединять LUN'ы на стороне хоста.
- Неоптимальное использование быстрых дисков. Можно насоздавать большое количество дисковых групп под несколько профилей нагрузки, но при большом числе хостов и сервисов на них постоянно следить за производительностью, объёмом и периодически вносить изменения становится тяжело.
Дисковый пул в СХД DotHill — совокупность нескольких дисковых групп с распределением нагрузки между ними. С точки зрения производительность можно рассматривать пул в качестве RAID-0 из нескольких подмассивов, т.е. мы уже решаем проблему коротких дисковых групп. Всего на СХД поддерживается только два дисковых пула, A и B, по одному на контроллер), в каждом пуле может быть до 16-ти дисковых групп. Главное архитектурное отличие — максимальное использование свободного размещения страйпов по дискам. На этой особенности основаны несколько технологий и особенностей:
- Thin Provisioning (тонкое выделение ресурсов). Технология не нова, с TP наверняка сталкивались даже те, кто ни одной СХД не видел, например, в настольных гипервизорах. Поверх пула или обычной линейной дисковой группы создаются тома, которые затем презентуются хостам. Дисковое пространство под «тонкий» том резервируется не сразу, а только по мере заполнения данными. Это позволяет заранее распределить необходимое дисковое пространство с учётом прогнозов роста и выделить пространства больше, чем есть на самом деле. В дальнейшем расширять систему либо не понадобится вообще (не все тома будут реально использовать выделенный объём), или мы сможем добавить необходимое количество дисков, не прибегая к сложным манипуляциям (перенос данных, увеличение LUN'ов и файловых систем на них и т.п.). Если вы опасаетесь возможной ситуации с нехваткой объёма, то в настройках пула можно отключить over-provisioning, и выделить больше дискового пространства, чем есть в наличии, не получится.
При использовании Thin Provisioning важно обеспечить обратный процесс — возврат неиспользуемого дискового пространства обратно в пул (space reclamation). При удалении файла СХД не сможет узнать об освобождении соответствующих блоков, если не предпринять дополнительные действия. Когда-то СХД с поддержкой space reclamation могли полагаться только на периодическую запись нулей со стороны хоста (например, при помощи SDelete), но сейчас практически все (и, конечно, DotHill) поддерживают команду SCSI UNMAP (аналог известного TRIM в наборе ATA-команд).
- Возможность прозрачного добавления и удаления элементов пула. В традиционных RAID-массивах часто есть возможность расширения массива путём добавления дисков, но большинство реализаций дисковых пулов, в том числе у DotHill, позволяют добавить или извлечь дисковую группу без потери данных. Блоки из этой группы будут перераспределены по оставшимся группам в пуле. Естественно, при условии наличия достаточного количества свободных блоков.
- Tiering (ярусное хранение данных). Вместо распределения томов с разными требованиями к производительности по различным дисковым группам можно объединить тома на дисках с разной производительностью в общий пул и положиться на автоматическую миграцию блоков между тремя ярусами с различной производительностью. Критерий для миграции — интенсивность нагрузки со случайным доступом. Более часто запрашиваемые блоки «всплывают» наверх, редко используемые «оседают» на медленных дисках.
В СХД DotHill есть три фиксированных яруса: Archive (архивный, диски 7200 об/мин), Standard (стандартный, «настоящие» SAS-диски 10/15 тыс. об/мин) и Performance (производительный, SSD). В связи с этим есть шанс получить некорректно работающую конфигурацию, состоящую, например из десятка 7200-дисков и пары 15k-дисков. DotHill будет считать зеркало из пары 15k-дисков более производительным и перемещать на него «горячие» данные.
При планировании конфигурации с tiering'ом следует учитывать то, что вы всегда будете получать прирост производительности с некоторой задержкой — системе нужно время на то, чтобы переместить блоки на нужный ярус. Второй момент — примитивность организации tiering'а в DotHill 4004, т.е. отсутствие возможности назначить томам приоритеты. Никаких сложных конструкций с профилями и tier affinity, как в DataCore или каких-нибудь СХД класса midrange тут нет, это всё-таки СХД начального уровня. Хотите гарантированной производительности сразу и всегда? Используйте обычные дисковые группы. Ещё одна альтернатива tiering'у в DotHill — SSD-кэш, подробности о реализации которого будут ниже.
DotHill 4004 имеет простой и наглядный инструмент для анализа эффективности использования пула:
Это скриншот из вкладки Pools нового web-интерфейса Storage Management Console (SMC) v3 (у HP это называется SMU). Можно увидеть пул, состоящий из двух ярусов: Standard (2 дисковых группы) и Performance. Сразу можно понять, как распределены данные в пуле, и сколько выделено места на каждом ярусе: только что создан один том и он не заполнен реальными данными, так что реально выделено всего 8 с небольшим МБ.
Второй скриншот, производительность:
В данный момент запущен нагрузочный тест после предварительного заполнения тома. Мы можем увидеть, сколько в IOPS и пропускной способности отдаёт каждый ярус в пуле. Пространство под новые блоки первоначально выделяется на Standard-ярусе, и тут уже виден процесс миграции на Performance-ярус под воздействием нагрузки.
Отличия от HP MSA2040
- MSA 2040 — это продукт HP, со всеми вытекающими последствиями и преимуществами. Прежде всего — разветвлённая сеть сервисных центров и возможность покупки различных пакетов расширенной поддержки. Русскоязычной поддержкой и обслуживанием DotHill пока что занимаются только дистрибуторы и их партнёры. Остаётся лишь опциональная поддержка 8x5 с реакцией на следующий рабочий день и отправка запчастей на следующий рабочий день.
Документация полностью идентична HP'шной за исключением названий и логотипов, т.е. столь же качественна и подробна. Конечно, у HP есть много дополнительных FAQ, best practices, описаний референсных архитектур с участием MSA2040. Веб-интерфейс у HP (HP SMU) отличается лишь фирменным шрифтом и иконками.
Цена. Разумеется, ничего не даётся даром. Цена на MSA2040 в распространенных конфигурациях (два контроллера, 24 диска 450-600ГБ 10k, 8Гбит FC трансиверы) примерно на 30% выше DotHill 4004. Разумеется, без CarePack'ов. Так же без учёта отдельно лицензируемых у HP расширения количества снапшотов (с 64-х до 512-ти) и асинхронной репликации (Remote Snap), которые добавляют к стоимости решения еще несколько тысяч USD. Наша статистика показывает, что дополнительные CarePack'и к MSA на территории РФ покупают крайне редко, всё-таки это бюджетный сегмент. Внедрение в большинстве случаев осуществляется своими силами, иногда это осуществляет поставщик в рамках общего проекта, крайне редко — инженеры HP.
- Диски. У DotHill и HP они «свои», то есть используются HDD и SSD с нестандартной прошивкой, салазки идут в комплекте с дисками. DotHill предлагает из 3,5" дисков только nearline SAS, т.е. со частотой вращения шпинделя 7200 об/мин, т.е.
все быстрые диски — только 2,5"*. HP предлагает 300, 450 и 600ГБ 15000 об/мин диски в 3,5" исполнении.
*Обновление от 25.03.2015: Диски 10k и 15k в 3,5" варианте у DotHill всё-таки доступны по запросу.
- Родственные продукты. HP MSA 1040 — бюджетный вариант MSA 2040 с определёнными ограничениями:
- Нет поддержки SSD. Опциональный auto-tiering по-прежнему есть, просто он 2-уровневый.
- Меньше хост-портов — по 2 на контроллер вместо 4-х. Поддержки 16Гбит FC и SAS нет.
- Меньше дисков — только 3 дополнительных дисковых полки вместо 7.
Так что если вам не нужны все возможности MSA 2040, то можно сэкономить порядка 20% и вплотную приблизиться к стоимости «оригинала» (но полнофункционального).
У DotHill есть другая разновидность — серия AssuredSAN Ultra. Это СХД с точно такими же контроллерами, функционалом и интерфейсом управления, как и у серии 4004, но с высокой плотностью размещения дисков: Ultra48 — 48x 2,5" в 2U и Ultra56 — 56x 3,5" в 4U.
Производительность
Конфигурация СХД
- DotHill 4824 (2U, 24x2.5")
- Версия прошивки: GL200R007 (последняя на момент тестирования)
- Активированная лицензия RealTier 2.0
- Два контроллера с CNC портами (FC/10GbE), 4 трансивера 8Гбит FC (установлены в первый контроллер)
- 20x 146ГБ 15 тыс. об/мин SAS HDD (Seagate ST9146852SS)
- 4x 400ГБ SSD (HGST HUSML4040ASS600)
Конфигурация хоста
- Платформа Supermicro 1027R-WC1R
- 2x Intel Xeon E5-2620v2
- 8x 8ГБ DDR3 1600МГц ECC RDIMM
- 480ГБ SSD Kingston E50
- 2x Qlogic QLE2562 (2-портовый 8Гбит FC HBA)
- CentOS 7, fio 2.1.14
Подключение производилось через один контроллер, прямое, через 4 порта 8Гбит FC. Естественно, маппинг томов к хосту был через 4 порта, а на хосте настроен multipath.
Пул с tier-1 и кэшом на SSD
Данный тест представляет собой трёхчасовую (180 циклов по 60 секунд) нагрузку со случайным доступом блоками 8КиБ (8 потоков с глубиной очереди 16 каждый) с различным соотношением чтение/запись. Вся нагрузка сосредоточена на области 0-20ГБ, которая гарантированно меньше объема performance tier'а или кэша на SSD (800ГБ) — это сделано с целью быстрого наполнения кэша или яруса за приемлемое время.
Перед каждым запуском теста том создавался заново (для очистки SSD-tier'а или SSD-кэша), наполнялся случайными данными (последовательная запись блоками 1МиБ), на томе оключалось упреждающее чтение. Значения IOPS, средней и максимальной задержки определялись в пределах каждого 60-секундного цикла.
Тесты со 100% чтением и 65/35 чтение+запись проводились как с SSD-tier'ом (в пул добавлялась дисковая группа из 4x400ГБ SSD в RAID-10), так и с SSD-кэшом (2x400ГБ SSD в RAID-0, СХД не позволяет добавить больше двух SSD в кэш для каждого пула). Том создавался на пуле из двух дисковых групп RAID-6 по 10 дисков 46ГБ 15 тыс. об/мин SAS (т.е. фактически это RAID-60 по схеме 2x10). Почему не 10 или 50? Чтобы намеренно осложнить для СХД случайную запись.
IOPS
Результаты получились вполне предсказуемыми. Как и утверждает вендор, преимущество SSD-кэша перед SSD-tier'ом заключается в более быстром наполнении кэша, т.е. СХД быстрее реагирует на появление «горячих» областей с интенсивной нагрузкой на случайный доступ: на 100% чтении IOPS'ы растут вместе падением задержки быстрее, чем в случае использования tier'инга.
Это преимущество заканчивается как только добавляется значительная нагрузка на запись. RAID-60, мягко говоря, не очень подходит для случайной записи небольшими блоками, но такая конфигурация была выбрана специально чтобы показать суть проблемы: СХД не справляется с записью, т.к. она идёт в обход кэша на медленный RAID-60, очередь быстро забивается, времени на обслуживание запросов на чтение остаётся мало даже с учётом кэширования. Какие-то блоки туда всё-же попадают, но быстро становятся невалидными, ведь идёт запись. Этот замкнутый круг приводит к тому, что при таком профиле нагрузки кэш, работающий только на чтение, становится неэффективным. Точно такую же ситуацию можно было наблюда с ранними вариантами SSD-кэша (до появления Write-Back) в PCI-E RAID-контроллерах LSI и Adaptec. Решение — используйте изначально более производительный том, т.е. RAID-10 вместо 5/6/50/60 и/или SSD-tier'инг вместо кэша.
Средняя задержка
Максимальная задержка
В данном графике используется логарифмическая шкала. В случае 100% и использования SSD-кэша можно увидеть более стабильное значение задержки — после наполнения кэша пиковые значения не превышают 20мс.
Какой же можно подвести итог в дилемме «кэширование против ярусного хранения (tiering'а)»?
Что выбрать?
- Наполнение кэша происходит быстрее. Если ваша нагрузка состоит из преимущественного случайного чтения и при этом область «горячих» периодически меняется, то стоит выбрать кэш.
- Экономия «быстрого» объёма. Если «горячие» данные умещаются целиком в кэш, но не в SSD-tier, то кэш, возможно, будет более эффективным. SSD-кэш в DotHill 4004 работает только на чтение, так что под него создаётся дисковая группа RAID-0. Например, имея 4 SSD по 400ГБ вы можете получить по 800ГБ кэша для каждого из двух пулов (1600ГБ всего) или в 2 раза меньше при использовании tiering'а (800ГБ для одного пула или по 400ГБ для двух). Конечно, есть ещё вариант 1200ГБ в RAID-5 для одного пула, если на втором не нужны SSD.
С другой стороны, общий полезный объём пула при использовании tiering'а будет больше за счет хранения только одной копии блоков.
- Кэш не влияет на производительность при последовательном доступе. При кэшировании не происходит перемещения блоков, только копирование. При подходящем профиле нагрузки (случайное чтение небольшими блоками с повторым обращением к одним и тем же LBA) СХД выдаёт данные из SSD-кэша, если они там есть, или с HDD и копирует их в кэш. При появлении нагрузки с последовательным доступом данные будут прочитаны с HDD. Пример: пул из 20-ти 10 или 15k HDD может дать порядка 2000МБ/с при последовательном чтении, но если нужные данные окажутся на дисковой группе из пары SSD, то мы получим около 800МБ/с. Критично это или нет — зависит от реального сценария использования СХД.
4x SSD 400ГБ HGST HUSML4040ASS600 RAID-10
Тестировался том на линейной дисковой группе — RAID-10 из четырёх SSD 400ГБ. В данной поставке DotHill в качестве абстрактных «400GB SFF SAS SSD» оказались HGST HUSML4040ASS600. Это SSD серии Ultrastar SSD400M с достаточно высокой заявленной производительностью (56000/24000 IOPS на чтение/запись 4КиБ), а главное — ресурс в 10 перезаписей в день на 5 лет. Конечно, сейчас в арсенале HGST есть более производительные SSD800MM и SSD1600MM, но для DotHill 4004 вполне хватает и этих.
Использовались тесты, предназначенные для одиночных SSD — «IOPS Test» и «Latency Test» из спецификации SNIA Solid State Storage Performance Test Specification Enterprise v1.1:
- IOPS Test. Измеряется количество IOPS'ов (операций ввода-вывода в секунду) для блоков различного размера (1024КиБ, 128КиБ, 64КиБ, 32КиБ, 16КиБ, 8КиБ, 4КиБ) и случайного доступа с различным соотношением чтение/запись (100/0, 95/5, 65/35, 50/50, 35/65, 5/95, 0/100). Использовалось 8 потоков с глубиной очереди 16.
- Latency Test. Измеряется значение средней и максимальной задержки для различных размеров блока (8КиБ, 4КиБ) и соотношений чтение/запись (100/0, 65/35, 0/100) при минимальной глубине очереди (1 поток с QD=1).
Тест состоит из серии замеров — 25 раундов по 60 секунд. Предварительная нагрузка — последовательная запись блоками 128КиБ до достижения 2-кратной емкости. Окно установившегося состояния (4 раунда) проверяется построением графика. Критерии установившегося состояния: линейная аппроксимация в пределах окна не должна выходить за границы 90%/110% среднего значения.
SNIA PTS: IOPS test
Как и ожидалось, был достигнут заявленный предел производительности одного контроллера по IOPS с малыми блоками. Почему-то DotHill указывает 100000 IOPS на чтение, а HP для MSA2040 — более реалистичные 80000 IOPS (получается по 40 тыс. на контроллер), что мы и видим на графике.
Для проверки проводился тест одиночного SSD HGST HGST HUSML4040ASS600 с подключением к SAS HBA. На блоке 4КиБ было получено около 50 тыс. IOPS на чтение и запись, при насыщении (SNIA PTS Write Saturation Test) запись опускалась до 25-26 тыс. IOPS, что соответствует характеристикам, заявленным HGST.
SNIA PTS: Latency Test
Средняя задержка (мс):
Максимальная задержка (мс):
Средние и пиковые значения задержки всего на 20-30% превышают таковые для одиночного SSD при подключении к SAS HBA.
Заключение
Конечно, статья получилась несколько сумбурной и на несколько важных вопросов ответа не даёт:
- Сравнение в аналогичной конфигурации с продуктами других вендоров: IBM v3700, Dell PV MD3 (и другие потомки LSI CTS2600), Infrotrend ESDS 3000 и др. СХД к нам попадают в разных конфигурациях и, как правило, не надолго — нужно скорее грузить и/или внедрять.
- Не тестировался предел СХД по пропускной способности. Порядка 2100МиБ/с (RAID-50 из 20-ти дисков) увидеть удалось, но подробно я последовательную нагрузку не тестировал из-за недостаточного количества дисков. Уверен, что заявленные 3200/2650 МБ/с на чтение/запись получить бы удалось.
- Нет полезного во многих случаях графика IOPS vs latency, где при варьировании глубины очереди можно увидеть, сколько IOPS можно получить при приемлемом значении задержки. Увы, не хватило времени.
- Best Practices. Не хотелось изобретать велосипед, так как есть хороший документ к HP MSA 2040. К нему можно добавить лишь рекомендации по правильному использованию дисковых пулов (см. выше).
