Тестирование флеш СХД. Violin 6232 Series Flash Memory Array

Продолжаем тему, начатую в статьях "Тестирование флеш СХД. Теоретическая часть ^[1]" и "Тестирование флеш СХД. IBM RamSan FlashSystem 820" ^[2]. Сегодня мы рассмотрим возможности одной из наиболее «массовых» моделей компании Violin Memory. Стартап, основанный выходцами из Fusion-io ^[3], стал первопроходцем и духовным лидером идеологии построения систем хранения данных исключительно на основе флеш-памяти. Массив Violin 6232 ^[4] был выпущен в сентябре 2011 года и пробыл флагманом вплоть до выхода модели 6264 в августе 2013 года.

Нас, как технических специалистов, в большей мере, заинтересовала архитектура массивов Violin Memory, являющаяся их отличительной особенностью и несомненным преимуществом по сравнению с конкурентами. Каждый компонент — это собственная разработка компании ^[5]:

• Собственные 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)

Программное обеспечение, используемое в процессе тестирования

Для создания синтетической нагрузки (выполнения синтетических тестов) на СХД используется утилита 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 с изменением размера блока операций ввода/вывода (в/в).

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.

Графики

(Все картинки кликабельны)

[6]

Разница IOPS и Latency между устройством с размером блока LUN 4КБ и 512Б при случайном чтении (показатели при размере блока LUN = 512Б приняты за 0)

[7]

Разница IOPS и Latency между устройством с размером блока LUN 4КБ и 512Б при случайной записи (показатели при размере блока LUN = 512Б приняты за 0)

[8]

Разница IOPS и Latency между устройством с размером блока LUN 4КБ и 512Б при смешанной нагрузке (70/30 r/w)(показатели при размере блока LUN = 512Б приняты за 0)

1. Влияние размера блока LUN на производительность при количестве jobs до 64 отсутствует.
2. При jobs > 64 на операциях записи наблюдается увеличение производительности до 20% по сравнению с размером блока LUN 512B
3. При jobs > 64 на операциях чтения средними и большими блоками наблюдается уменьшение производительности до 10-15%
4. При смешанной нагрузке маленькими и средними блоками (до 32K) массив показывает одинаковую производительность при обоих размерах блока LUN. Но при больших блоках (64К и 1М) производительность улучшается до 50% при использовании блока LUN 4KiB

Выводы

В целом, массив произвел впечатление полноценного устройства high-end уровня. Нам удалось получить очень неплохие результаты, тем не менее, осталось впечатление, что весь ресурс системы все же выбрать не удалось. Для создания нагрузки использовался один сервер с двумя процессорами, которые оказались перегружены в процессе тестирования. С большой вероятностью можно сказать, что мы скорее достигли предела возможностей нагрузочного сервера, чем испытываемой системы хранения.

P.S. Автор выражает сердечную благодарность Павлу Катасонову, Юрию Ракитину и всем другим сотрудникам компании участвовавшим в подготовке данного материала.

Автор: MrCleaner

Источник ^[9]