Основы темы мы рассмотрели ранее, в статье "Тестирование флеш СХД. Теоретическая часть". Сегодня перейдем к практике. Нашим первым пациентом будет IBM RamSan FlashSystem 820. Отличная рабочая система, вышедшая в апреле 2013 года. Была топовой моделью до января этого года, уступив место FlashSystem 840.
В ходе тестирования решались следующие задачи:
Схема и конфигурация стенда приведены на рисунке.
Тестирование состояло из 2 групп тестов. Тесты выполнялись посредством создания синтетической нагрузки программой fio на блочное устройство (block device), представляющее собой логический том типа
К сожалению, рамки статьи не позволят нам привести весь объем полученных данных, но основные материалы мы, безусловно, вам покажем.
Запись:
Чтение:
Смешанная нагрузка (70/30 rw)
Минимально зафиксированная latency:
При выходе системы в режим насыщения на нагрузке чтения наблюдается снижения производительности СХД при увеличении нагрузки (вероятно это связанно с накладными расходами у СХД по обработке больших очередей ввода-вывода).
По субъективным впечатлениям и сумме показателей FlashSystem 820 оказалась отличным рабочим инструментом. Полученные нами данные, в общем совпадают с заявленными производителем. Из значимых отличий можно отметить только более низкую производительность записи, что можно объяснить разной конфигурацией тестовых стендов. Мы использовали RAID-5. IBM, скорее всего, использует стандартный алгоритм RAID-0.
К недостаткам, пожалуй, отнесем отсутствие стандартных для СХД уровня предприятия дополнительных функций, таких как создание моментальных снимков (snapshot), репликации, дедупликации и т.п. С другой стороны, всё это лишь дополнительные преимущества, далеко не всегда необходимые.
Надеюсь, вам было так же интересно, как и мне.
Скоро напишу про Violin Memory 6000 и HDS HUS VM. На разных этапах — тестирование еще нескольких систем от разных производителей. Если позволят обстоятельства, рассчитываю вскорости ознакомить вас с их результатами.
P.S. Автор выражает сердечную благодарность Павлу Катасонову, Юрию Ракитину и всем другим сотрудникам компании участвовавшим в подготовке данного материала.
Методика тестирования
В ходе тестирования решались следующие задачи:
- исследовать процесс деградации производительности СХД при длительной нагрузке на запись (Write Cliff) и чтение;
- исследовать производительность СХД IBM FlashSystem 820 при различных профилях нагрузки;
Конфигурация тестового стенда
Схема и конфигурация стенда приведены на рисунке.
 |
| Рисунок 1 Структурная схема тестового стенда. (кликабельна) |
Посмотреть утомительные подробности и всякие умные слова.
В качестве дополнительного программного обеспечения на тестовый сервер устанавливается Symantec Storage Foundation 6.1 с Hot Fix 6.1HF100, реализующий:
На тестовом сервере выполняются настройки, направленные на снижение латентности дискового ввода-вывода:
На СХД выполняются конфигурационные настройки по разбиению дискового пространства:
Для создания синтетической нагрузки (выполнения синтетических тестов) на СХД используется утилита Flexible IO Tester (fio) версии 2.1.4. При всех синтетических тестах используются следующие конфигурационные параметры fio секции [global]:
Для снятия показателей производительности при синтетической нагрузке применяются следующие утилиты:
Снятие показателей производительности во время выполнения теста утилитами iostat, vxstat, vxdmpstat производится с интервалом 5 с.
- Логический менеджер томов (Veritas Volume Manager);
- Файловую систему vxfs;
- Функционал отказоустойчивого подключения к дисковым массивам (Dynamic Multi Pathing)
На тестовом сервере выполняются настройки, направленные на снижение латентности дискового ввода-вывода:
- Изменен планировщик ввода-вывода с
cfqнаnoopчерез добавление параметра загрузки ядраelevator=noop; - Добавлен параметр в /etc/sysctl.conf, минимизирующий размер очереди на уровне логического менеджера томов Symantec:
vxvm.vxio.vol_use_rq = 0; - Увеличен размер очереди на FC адаптерах; путем добавления в конфигурационный файл /etc/modprobe.d/modprobe.conf опции
ql2xmaxqdepth=64 (options qla2xxx ql2xmaxqdepth=64);
На СХД выполняются конфигурационные настройки по разбиению дискового пространства:
- Реализуется конфигурация Flash модулей RAID5(10+P) & HS — полезная емкость 9.37TiB;
- Для всех тестов, кроме теста 2 первой группы, создается 8 LUN одинакового объема с суммарным объемом, покрывающим всю полезную емкость дискового массива. Для теста 2 создается 8 LUN одинакового объема с суммарным объемом, покрывающим 80% полезной емкости дискового массива. Размер блока LUN — 512 byte. Созданные LUN презентуются тестовому серверу.
Программное обеспечение, используемое в процессе тестирования
Для создания синтетической нагрузки (выполнения синтетических тестов) на СХД используется утилита Flexible IO Tester (fio) версии 2.1.4. При всех синтетических тестах используются следующие конфигурационные параметры fio секции [global]:
- thread=0
- direct=1
- group_reporting=1
- norandommap=1
- time_based=1
- randrepeat=0
- ramp_time=6
Для снятия показателей производительности при синтетической нагрузке применяются следующие утилиты:
- iostat, входящая в состав пакета sysstat версии 9.0.4 с ключами
txk; - vxstat, входящая в состав Symantec Storage Foundation 6.1 c ключами
svd; - vxdmpadm, входящая в состав Symantec Storage Foundation 6.1 c ключами
-q iostat; - fio версии 2.1.4, для формирования сводного отчета по каждому профилю нагрузки.
Снятие показателей производительности во время выполнения теста утилитами iostat, vxstat, vxdmpstat производится с интервалом 5 с.
Программа тестирования.
Тестирование состояло из 2 групп тестов. Тесты выполнялись посредством создания синтетической нагрузки программой fio на блочное устройство (block device), представляющее собой логический том типа
stripe, 8 column, stripe unit size=1MiB, созданный с использованием Veritas Volume Manager из 8-ми LUN на тестируемой системе и презентованный тестовому серверу.Поинтересоваться подробностями
При создании тестовой нагрузки, используются следующие дополнительные параметры программы fio (кроме уже описанных):
Группа 1 состоит из четырех тестов, отличающихся суммарным объемом LUN, презентуемых с тестируемой СХД, размером блока операций ввода-вывода и направлением ввода-вывода (write или read):
По результатам тестов, на основании данных, выводимых командой vxstat, формируются графики совмещающие результаты двух тестов:
Проводится анализ полученной информации и делаются выводы о:
В ходе тестирования исследуются следующие типы нагрузок:
Группа состоит из набора тестов, представляющего собой все возможные комбинации перечисленных выше типов нагрузки. Для снижения влияния сервисных процессов СХД (garbage collection) на результаты тестов, между тестами реализуется пауза, равная объему записанной в ходе теста информации, разделенному на производительность сервисных процессов СХД (определяется по результатам выполнения 1-ой группы тестов).
По результатам тестов, на основании данных выводимых ПО fio по завершению каждого из тестов, формируются графики для каждой комбинации следующих типов нагрузки: профиля нагрузки, способа обработки операций ввода-вывода, глубины очереди, совмещающие в себе тесты с разными значениями блока ввода-вывода:
Проводится анализ полученных результатов, делаются выводы о нагрузочных характеристиках дискового массива при latency<1ms.
Группа 1: Тесты, реализующие длительную нагрузку.
При создании тестовой нагрузки, используются следующие дополнительные параметры программы fio (кроме уже описанных):
- rw=randwrite
- blocksize=4K
- numjobs=64
- iodepth=64
Группа 1 состоит из четырех тестов, отличающихся суммарным объемом LUN, презентуемых с тестируемой СХД, размером блока операций ввода-вывода и направлением ввода-вывода (write или read):
- Тест 1. Тест на запись, выполняемый на полностью размеченной СХД. Суммарный объем презентуемых LUN равен полезной емкости СХД, длительность теста — 12 часов;
- Тест 2. Тест на запись, выполняемый на СХД, размеченной на 80%. Суммарный объем презентуемых LUN равен 80% от полезной емкости СХД, длительность теста — 5 часов.
- Тест 3. Тест на чтение, выполняемый на полностью размеченной СХД. Длительность теста — 4 часа.
- Тест 4. Тесты на запись с изменяющимся размером блока: 4,8,16,32,64,1024 KiB, выполняемые на полностью размеченном СХД, длительность каждого теста — 2 часа.
По результатам тестов, на основании данных, выводимых командой vxstat, формируются графики совмещающие результаты двух тестов:
- IOPS, как функция времени;
- Latency, как функция времени.
Проводится анализ полученной информации и делаются выводы о:
- наличии деградации производительности при длительной нагрузке на запись и на чтение;
- степени влияния объема размеченного дискового пространства СХД на производительность;
- производительности сервисных процессов СХД (garbage collection), ограничивающих производительность дискового массива на запись при длительной пиковой нагрузке;
- степени влияния размера блока операций в/в на производительность сервисных процессов СХД;
- объеме пространства, резервируемом на СХД для нивелирования влияния сервисных процессов.
Группа 2: Тесты производительности дискового массива при разных типах нагрузки, исполняемые на уровне блочного устройства.
В ходе тестирования исследуются следующие типы нагрузок:
- профили нагрузки (изменяемые параметры ПО
fio: randomrw, rwmixedread):
- случайная запись 100%;
- случайная запись 30%, случайное чтение 70%;
- случайное чтение 100%.
- размеры блока: 1КБ, 8КБ, 16КБ, 32КБ, 64КБ, 1МБ (изменяемый параметр ПО
fio: blocksize); - способы обработки операций ввода-вывода: синхронный, асинхронный (изменяемый параметр в ПО
fio: ioengine); - количество процессов, генерирующих нагрузку: 1, 2, 4, 8, 16, 32, 64, 128 (изменяемый параметр ПО
fio: numjobs); - глубина очереди (для асинхронных операций ввода-вывода): 32, 64 (изменяемый параметр в ПО
fio: iodepth).
Группа состоит из набора тестов, представляющего собой все возможные комбинации перечисленных выше типов нагрузки. Для снижения влияния сервисных процессов СХД (garbage collection) на результаты тестов, между тестами реализуется пауза, равная объему записанной в ходе теста информации, разделенному на производительность сервисных процессов СХД (определяется по результатам выполнения 1-ой группы тестов).
По результатам тестов, на основании данных выводимых ПО fio по завершению каждого из тестов, формируются графики для каждой комбинации следующих типов нагрузки: профиля нагрузки, способа обработки операций ввода-вывода, глубины очереди, совмещающие в себе тесты с разными значениями блока ввода-вывода:
- IOPS как функция от количества процессов, генерирующих нагрузку;
- Bandwidth как функция от количества процессов, генерирующих нагрузку;
- Latеncy (clat) как функция от количества процессов, генерирующих нагрузку;
Проводится анализ полученных результатов, делаются выводы о нагрузочных характеристиках дискового массива при latency<1ms.
Результаты тестирования
К сожалению, рамки статьи не позволят нам привести весь объем полученных данных, но основные материалы мы, безусловно, вам покажем.
Группа 1: Тесты, реализующие длительную нагрузку.
1. При длительной нагрузке на запись фиксируется значимая деградация производительности СХД, связанная с включением процессов garbage collection (GC). Производительность дискового массива, фиксируемую при работающих процессах GC, можно рассматривать как максимальную среднюю производительность дискового массива.
 |
| Изменение скорости операций в/в (iops) при длительной записи блоком 4K |
 |
| Изменение задержек при длительной записи блоком 4K |
2. При длительной нагрузке на чтение производительность дискового массива с течением времени не меняется
 |
| Изменение параметров производительности при длительном чтении блоком 4K |
3. Заполненность СХД не влияет на работу дискового массива
 |
| Изменение скорости операций в/в (iops) и задержек (Latency) при длительной записи при 100% и 80% заполненности СХД. |
4. Размер блока влияет на производительность при длительной нагрузке на запись, что выражается в изменении точки значимого падения производительности СХД и объема записанных до обозначенного момента данных.
 |
| Изменение скорости в/в (iops) и скорости передачи данных (bandwidth) при длительной записи различными размерами блока. |
 |
| Зависимость показателей СХД от размера блока при длительной нагрузке на запись |
Группа 2: Тесты производительности дискового массива при разных типах нагрузки, исполняемые на уровне блочного устройства.
Таблицы производительности блочного устройства.
 |
| Производительность СХД при одном процессе, генерирующем нагрузку (jobs=1) |
 |
| Максимальная производительность СХД при задержках меньше 1мс |
 |
| Максимальная производительность СХД при различном профиле нагрузки. |
Графики производительности блочного устройства.
(Все картинки кликабельны)
| Синхронным способом в/в | Асинхронным способом в/в с глубиной очереди 32 | Асинхронным способом в/в с глубиной очереди 64 | |
| При случайном чтении |  |
 |
 |
| При случайной записи |  |
 |
 |
| При смешанной нагрузке (70% чтение, 30% запись) |  |
 |
 |
Максимально зафиксированные параметры производительности для FlashSystem 820:
Запись:
- 180 000 IOPS при latency 0.2ms (блок 4KB sync)
- Bandwidth: 1520МБ/c для блока 1MB
Чтение:
- 306 000 IOPS при latency 0,8ms (блок 8KB async qd 32);
- 453 000 IOPS при latency 2.2ms (блок 4KB async qd 64);
- Bandwidth: 3150МБ/с для блока 1MB.
Смешанная нагрузка (70/30 rw)
- 280 000 IOPS при latency 0.8ms (блок 4KB async qd 32);
- 390 000 IOPS при latency 2.6ms (блок 4KB async qd 64);
- Bandwidth 2430МБ/с для блока 1MB
Минимально зафиксированная latency:
- При записи — 0,08ms для блока 4K, jobs=8 при производительности 100 000 IOPS;
- При чтении 0,166ms для блока 4K, jobs=16 при производительности 95 000 IOPS.
При выходе системы в режим насыщения на нагрузке чтения наблюдается снижения производительности СХД при увеличении нагрузки (вероятно это связанно с накладными расходами у СХД по обработке больших очередей ввода-вывода).
Выводы
По субъективным впечатлениям и сумме показателей FlashSystem 820 оказалась отличным рабочим инструментом. Полученные нами данные, в общем совпадают с заявленными производителем. Из значимых отличий можно отметить только более низкую производительность записи, что можно объяснить разной конфигурацией тестовых стендов. Мы использовали RAID-5. IBM, скорее всего, использует стандартный алгоритм RAID-0.
К недостаткам, пожалуй, отнесем отсутствие стандартных для СХД уровня предприятия дополнительных функций, таких как создание моментальных снимков (snapshot), репликации, дедупликации и т.п. С другой стороны, всё это лишь дополнительные преимущества, далеко не всегда необходимые.
Надеюсь, вам было так же интересно, как и мне.
Скоро напишу про Violin Memory 6000 и HDS HUS VM. На разных этапах — тестирование еще нескольких систем от разных производителей. Если позволят обстоятельства, рассчитываю вскорости ознакомить вас с их результатами.
P.S. Автор выражает сердечную благодарность Павлу Катасонову, Юрию Ракитину и всем другим сотрудникам компании участвовавшим в подготовке данного материала.
