Продолжаем тему, начатую в статьях "Тестирование флеш СХД. Теоретическая часть" и "Тестирование флеш СХД. IBM RamSan FlashSystem 820". Сегодня мы рассмотрим возможности одной из наиболее «массовых» моделей компании Violin Memory. Стартап, основанный выходцами из Fusion-io, стал первопроходцем и духовным лидером идеологии построения систем хранения данных исключительно на основе флеш-памяти. Массив Violin 6232 был выпущен в сентябре 2011 года и пробыл флагманом вплоть до выхода модели 6264 в августе 2013 года.
Нас, как технических специалистов, в большей мере, заинтересовала архитектура массивов Violin Memory, являющаяся их отличительной особенностью и несомненным преимуществом по сравнению с конкурентами. Каждый компонент — это собственная разработка компании:
- Собственные flash модули (VIMM);
- Собственная операционная система VMOS, оптимизированная для работы с flash;
- Собственный запатентованный RAID (vRAID), лишенный недостатков стандартных RAID 5,6.
Система без единой точки отказа, где все компоненты продублированы. Где замена компонентов или обновление прошивки ни только не требуют остановки работы, но и не снижают производительности: 4 контроллера, отсутствие внутреннего кэша, запись полными «страйпами», оптимальные алгоритмы «сбора мусора». Такая архитектура позволяет получить высочайшую производительность, минимизировать задержки и побочные явления (Write Cliff), обеспечивает доступность данных уровня 99,9999 и нивелирует потери производительности при возможном выходе компонентов из строя. Богатый, продуманный интерфейс управления гармонично добавляет удобства работы с оборудованием Violin.
Методика тестирования
В ходе тестирования решались следующие задачи:
- исследовать процесс деградации производительности СХД при длительной нагрузке на запись (Write Cliff) и чтение;
- исследовать производительность СХД Violin 6232 при различных профилях нагрузки;
- исследование влияния размера блока LUN на производительность.
Конфигурация тестового стенда
 |
| Рисунок 1. Структурная схема тестового стенда |
Тестовый стенд состоит из сервера, подключенного через FC фабрику четырьмя соединениями 8Gb FC к СХД Violin 6232. Характеристики сервера и массива следующие: Сервер IBM 3630 M4 (7158-AC1); СХД Violin Memory 6232
В качестве дополнительного программного обеспечения на тестовый сервер установлен Symantec Storage Foundation 6.1, реализующий:
- функционал логического менеджера томов (Veritas Volume Manager);
- функционал отказоустойчивого подключения к дисковым массивам (Dynamic Multi Pathing). (Для тестов группы 1 и 2. Для тестов группы 3 используется нативный Linux DMP)
- изменен планировщик ввода-вывода с
cfqнаnoopчерез присвоение значения noop параметру/sys/<путь_к_устройству_Symantec_VxVM>/queue/scheduler - добавлен параметр в
/etc/sysctl.confминимизирующий размер очереди на уровне логического менеджера томов Symantec:vxvm.vxio.vol_use_rq = 0; - увеличен предел одновременных запросов ввода-вывода на устройство до 1024 через присвоение значения 1024 параметру
/sys/<путь_к_устройству_Symantec_VxVM>/queue/nr_requests - отключена проверка возможности слияния операций в/в (iomerge) через присвоение значения 1 параметру
/sys/<путь_к_устройству_Symantec_VxVM>/queue/nomerges - увеличен размер очереди на FC адаптерах путем добавления в конфигурационный файл
/etc/modprobe.d/modprobe.confопцииql2xmaxqdepth=64 (options qla2xxx ql2xmaxqdepth=64);
На СХД выполнены конфигурационные настройки по разбиению дискового пространства: для всех тестов создаётся 8 LUN одинакового объема. Их суммарный объемом покрывает всю полезную емкость дискового массива. Для тестов группы 2 размер блока LUN устанавливается 512B, для тестов группы 3 размер блока LUN устанавливается 4KB. Созданные 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=10
Для снятия показателей производительности при синтетической нагрузке применяются следующие утилиты:
- 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с.
Программа тестирования.
Тестирование состояло из 3-х групп тестов. Тесты выполнялись путем создания синтетической нагрузки программой fio на блоковое устройство (block device), представляющее собой логический том типа «stripe» с расслоением по 8 дискам, размером блока данных — 1MiB, созданный с использованием Veritas Volume Manager или Native Linux LVM (в 3 группе) из 8-ми LUN, презентованных с тестируемой системы.
Группа 1: Тесты, реализующие длительную нагрузку типа random write с изменением размера блока операций ввода/вывода (в/в).
При создании тестовой нагрузки используются следующие дополнительные параметры программы fio:
- rw=randwrite
- blocksize=4K
- numjobs=64
- iodepth=64
Группа тестов состоит из четырёх тестов, отличающихся суммарным объемом LUN, презентуемых с тестируемой СХД, размером блока операций в/в и направлением в/в (write или read):
- тест на запись, выполняемый на полностью размеченном СХД, — суммарный объем презентуемых LUN равен полезной емкости СХД, длительность теста — 7.5 часов;
- тесты на запись с изменяющимся размером блока (4,32,1024K), выполняемый на полностью размеченном СХД, длительность каждого теста — 4.5 часа. Пауза между тестами — 2 часа.
По результатам тестов на основании данных выводимых командой vxstat формируются графики, совмещающие результаты тестов:
- IOPS как функция времени;
- Latency как функция времени.
Проводится анализ полученной информации и делаются выводы о:
- наличии деградации производительности при длительной нагрузке на запись и на чтение;
- производительности сервисных процессов СХД (Garbage Collection), ограничивающих производительность дискового массива на запись при длительной пиковой нагрузке;
- степени влияния размера блока операций в/в на производительность сервисных процессов СХД;
- объеме пространства, резервируемом на СХД для нивелирования сервисных процессов СХД.
Группа 2: Тесты производительности дискового массива при разных типах нагрузки, исполняемые на уровне блокового устройства, созданного средствами Symantec Volume Manager (VxVM) при размере блока LUN — 512байт.
В ходе тестирования исследуются следующие типы нагрузок:
- профили нагрузки (изменяемые параметры ПО 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, 160, 192 (изменяемый параметр ПО fio: numjobs);
- глубина очереди (для асинхронных операций ввода-вывода): 32, 64 (изменяемый параметр ПО fio: iodepth).
Группа тестов состоит из набора тестов, представляющего собой все возможные комбинации перечисленных выше типов нагрузки. Для нивелирования влияния сервисных процессов СХД (Garbage Collection) на результаты тестов, между тестами реализуется пауза равная отношению объема записанной в ходе теста информации к производительности сервисных процессов СХД (определяется по результатам выполнения 1-ой группы тестов).
По результатам тестов на основании данных, выводимых ПО fio по завершению каждого из тестов, формируются следующие графики для каждой комбинации следующих типов нагрузки: профиля нагрузки, способа обработки операций ввода-вывода, глубины очереди, совмещающие в себе тесты с разными значениями блока ввода-вывода:
- IOPS — как функция от количества процессов, генерирующих нагрузку;
- Bandwidth — как функция от количества процессов, генерирующих нагрузку;
- Latеncy (clat) — как функция от количества процессов, генерирующих нагрузку;
Проводится анализ полученных результатов, делаются выводы о нагрузочных характеристиках дискового массива при latency<1ms.
Группа 3: тесты производительности дискового массива при синхронном способе в/в, разных типах нагрузки, исполняемые на уровне блокового устройства, созданного средствами Linux LVM, при размере блока LUN — 4KiB.
Тесты проводятся аналогично тестам группы 2, но исследуется только синхронный способ в/в из-за ограниченного времени тестирования. По окончании каждого теста строятся графики, отображающие разницу в % полученных показателей производительности (iops, latency) от показателей, полученных при тестировании с размером блока LUN 512байт (группа тестов 2). Делаются выводы о влиянии размера блока LUN на производительность дискового массива.
Результаты тестирования
Группа 1: Тесты, реализующие длительную нагрузку типа random write с изменением размера блока операций ввода/вывода (в/в).
1. При длительной нагрузке на запись в определенный момент времени фиксируется значимая деградация производительности СХД. Падение производительности ожидаемо и является особенностью работы SSD (Write Cliff), связанной с включением процессов Garbage Collection (GC) и ограниченной производительностью обозначенных процессов. Производительность дискового массива, фиксируемую при работающих процессах GC, можно рассматривать как максимальную среднюю производительность дискового массива.
 |
| Изменение скорости операций в/в (iops) и задержек (Latency) при длительной записи блоком 4K |
2. Размер блока при длительной нагрузке на запись не влияет на производительность процесса GC. CG работает на скорости порядка 600Mib/s.
3. Разница в значениях максимального времени работы СХД на пиковой производительности, фиксируемой при первом длительном тесте и последующем эквивалентном тесте с блоком 4К, обусловлена не полной заполненностью СХД перед началом тестирования.
 |
| Изменение скорости в/в (iops) при длительной записи блоками 4K, 32K |
4. Максимальное время работы СХД на пиковой производительности значительно отличается при блоке 4K и всех остальных блоках, что с большой вероятностью обусловлено архитектурной оптимизации СХД под обозначенный блок (СХД Violin всегда пишет полными stripe размером 4K, используя конфигурацию flash модулей RAID5(4+P), stripe unit size 1K).
 |
| Изменение скорости передачи данных (bandwidth) при длительной запись различными размерами блока. |
 |
| Зависимость показателей СХД от размера блока при длительной нагрузке на запись. |
Группа 2: Тесты производительности дискового массива при разных типах нагрузки, исполняемые на уровне блокового устройства, созданного средствами Symantec Volume Manager (VxVM) при размере блока LUN — 512байт.
 |
| Производительность СХД при одном процессе, генерирующем нагрузку (jobs=1) |
 |
| Максимальная производительность СХД при задержках меньше 1мс |
 |
| Максимальная производительность СХД при различном профиле нагрузки. |
| Синхронным способом в/в | Асинхронным способом в/в с глубиной очереди 32 | Асинхронным способом в/в с глубиной очереди 64 | |
| При случайном чтении |
 |
 |
 |
| При случайной записи |
 |
 |
 |
| При смешанной нагрузке (70% чтение, 30% запись) |
 |
 |
 |
- Получена приблизительно одинаковая производительность массива на чтение и запись.
- Не удалось получить заявленную производителем производительность на операциях чтения (заявляется максимально 500 000IOPS).
- При смешанном вводе-выводе массив показывает производительность меньшую, чем отдельно при записи и чтении практически при любом профиле ввода-вывода.
- Фиксируется значимое снижение производительности при блоке 8K на смешенном профиле нагрузки при увеличении количества потоков ввода-вывода. (Причина обнаруженного феномена на текущий момент не понятна).
Максимально зафиксированные параметры производительности для Violin 6232
Запись:
- 307000 IOPS при latency 0.8ms (блок 4KB async qd32)
- Bandwidth: 2224МБ/c для больших блоков
Чтение:
- 256000 IOPS при latency 0,7ms (блок 4KB sync);
- 300000 IOPS при latency 6,7ms (блок 4KB async qd 32);
- Bandwidth: 2750МБ/с для средних блоков (16-32K).
Смешанная нагрузка (70/30 rw)
- 256000 IOPS при latency 0.7ms (блок 4KB sync);
- 305000 IOPS при latency 6,7ms (блок 4KB async qd 64);
- Bandwidth 2700МБ/с для средних блоков (16-32K)
Минимально зафиксированная latency:
- При записи – 0,146ms для блока 4K jobs=1
- При чтении — 0,21ms для блока 4K jobs=1
Группа 3: тесты производительности дискового массива при синхронном способе в/в, разных типах нагрузки, исполняемые на уровне блокового устройства, созданного средствами Linux LVM при размере блока LUN — 4KiB.
 |
| Разница IOPS и Latency между устройством с размером блока LUN 4КБ и 512Б при случайном чтении (показатели при размере блока LUN = 512Б приняты за 0) |
 |
| Разница IOPS и Latency между устройством с размером блока LUN 4КБ и 512Б при случайной записи (показатели при размере блока LUN = 512Б приняты за 0) |
 |
| Разница IOPS и Latency между устройством с размером блока LUN 4КБ и 512Б при смешанной нагрузке (70/30 r/w)(показатели при размере блока LUN = 512Б приняты за 0) |
- Влияние размера блока LUN на производительность при количестве jobs до 64 отсутствует.
- При jobs > 64 на операциях записи наблюдается увеличение производительности до 20% по сравнению с размером блока LUN 512B
- При jobs > 64 на операциях чтения средними и большими блоками наблюдается уменьшение производительности до 10-15%
- При смешанной нагрузке маленькими и средними блоками (до 32K) массив показывает одинаковую производительность при обоих размерах блока LUN. Но при больших блоках (64К и 1М) производительность улучшается до 50% при использовании блока LUN 4KiB
Выводы
В целом, массив произвел впечатление полноценного устройства high-end уровня. Нам удалось получить очень неплохие результаты, тем не менее, осталось впечатление, что весь ресурс системы все же выбрать не удалось. Для создания нагрузки использовался один сервер с двумя процессорами, которые оказались перегружены в процессе тестирования. С большой вероятностью можно сказать, что мы скорее достигли предела возможностей нагрузочного сервера, чем испытываемой системы хранения.
P.S. Автор выражает сердечную благодарность Павлу Катасонову, Юрию Ракитину и всем другим сотрудникам компании участвовавшим в подготовке данного материала.
Автор: MrCleaner
