Тестирование флеш СХД. IBM FlashSystem 840
В прошлом году писали о тестировании IBM RamSan FlashSystem 820. Н, а этот раз, благодаря одному крупному заказчику, в наши руки попала IBM FlashSystem 840. Системе около года от роду, «детские болезни» уже позади т.е. самое время оценить её профессиональные возможности.
Методика тестирования
В ходе тестирования решались следующие задачи: исследования процесса деградации производительности СХД при длительной нагрузке на запись (Write Cliff) и влияния заполненности СХД;
исследование производительности СХД IBM FlashSystem840 при различных профилях нагрузки;
Конфигурация тестового стенда
Для проведения тестирования, на объекте Заказчика, последовательно собирались 2 разных стенда.Для тестов групп 1 и 2 нагрузка генерируется одним сервером, и стенд имеет вид, отображенный на рисунке:
Рисунок 1. Структурная схема тестового стенда 1.
Сервер: IBM 3850×5, подключенного напрямую восемью соединениями 8Gb FC к .СХД IBM FlashSystem 840Для тестов группы 3 к описанному стенду добавляется сервер IBM 3650M4, так же подключенный напрямую к СХД IBM Flash System 840. На данном этапе, каждый сервер соединяется с СХД посредством четырех оптических линков.
Рисунок 2. Структурная схема тестового стенда 2.
В качестве дополнительного программного обеспечения на тестовый сервер установлен Symantec Storage Foundation 6.1, реализующий: Функционал логического менеджера томов (Veritas Volume Manager);
Функционал отказоустойчивого подключения к дисковым массивам (Dynamic Multi Pathing)
Посмотреть утомительные подробности и всякие умные слова.
На тестовом сервере выполнены следующие настройки, направленные на снижение латентности дискового ввода-вывода: Изменен планировщик ввода-вывода с cfq на noop через присвоение значения noop параметру scheduler тома Symantec VxVolume
Добавлен следующий параметр в /etc/sysctl.conf минимизирующий размер очереди на уровне логического менеджера томов Symantec: vxvm.vxio.vol_use_rq = 0;
Увеличен предел одновременных запросов ввода-вывода на устройство до 1024 через присвоение значения 1024 параметру nr_requests тома Symantec VxVolume;
Отключена проверка возможности слияния операций в/в (iomerge) через присвоение значения 1 параметру nomerges тома Symantec VxVolume;
Увеличен размер очереди на FC адаптерах путем добавления в конфигурационный файл /etc/modprobe.d/modprobe.conf опции ql2xmaxqdepth=64 (options qla2xxx ql2xmaxqdepth=64);
На СХД выполняются следующие конфигурационные настройки по разбиению дискового пространства: Реализуется конфигурация Flash модулей RAID5;
Для тестов групп 1 и 2 на СХД создается 8 LUN одинакового объема с суммарным объемом, покрывающим всю полезную емкость дискового массива. Размер блока LUN — 512byte. Созданные LUN презентуются одному тестовому серверу. Для тестов группы 3, создается 16 LUN одинакового объема с суммарным объемом, покрывающим всю полезную емкость дискового массива. Созданные LUN презентуются по 8 штук каждому из 2-х тестовых серверов.
Программное обеспечение, используемое в процессе тестирования
Для создания синтетической нагрузки (выполнения синтетических тестов) на СХД используется утилита 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с.
Программа тестирования.
Тесты выполняются посредством создания синтетической нагрузки программой fio на блоковое устройство (block device), представляющее собой логический том типа stripe, 8 column, stripe unit size=1MiB, созданный с использованием Veritas Volume Manager из 8-ми LUN, презентованных с тестируемой системы.Тестирование состояло из 3-х групп тестов: Поинтересоваться подробностями
Группа 1: Тесты, реализующие длительную нагрузку типа random write с изменением размера блока операций ввода/вывода (в/в).
При создании тестовой нагрузки используются следующие параметры программы fio (в дополнение к определенным ранее): rw=randwrite;
blocksize=4K;
numjobs=64;
iodepth=64.
Группа тестов состоит из трех тестов, отличающихся суммарным объемом LUN презентуемых с тестируемой СХД и размером блока операций в/в: Тест на запись, выполняемый на полностью размеченной СХД — суммарный объем презентуемых LUN равен полезной емкости СХД, длительность теста — 18 часов;
Тесты на запись с изменяющимся размером блока (4,8,16,32,64,1024K), выполняемый на полностью размеченной СХД, длительность каждого теста — 1 час. Пауза между тестами — 2 часа.
Тесты на запись с изменяющимся размером блока (4,8,16,32,64,1024K), выполняемый на СХД, заполненной на 70% длительность каждого теста — 1 час. Пауза между тестами — 2 часа. Для этого теста на тестируемой СХД создаются 8 LUN, суммарная емкость которых составляет 70% полезной емкости СХД. Созданные LUN презентуются тестовому серверу, где из них средствами Symantec VxVM собирается том, на который ложится тестовая нагрузка.
По результатам тестов на основании данных выводимых командой vxstat формируются следующие графики, совмещающие результаты тестов: IOPS как функция времени;
Пропускная способность (BandWidth) как функция времени.
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, о максимальных показателях производительности массива о производительности массива при однопоточной нагрузке. Так же определяется оптимальный размер блока для работы с массивом, как блок, при котором возможно осуществить максимальное количество операций в/в, передав при этом максимальное кол-во данных.Группа 3: Тесты производительности дискового массива при разных типах нагрузки, генерируемой двумя серверами, исполняемые на уровне блокового устройства;.
Для выполнения тестов этой группы к конфигурации стенда добавляется ещё один сервер. Дисковый массив разбивается на 16 LUN одинакового размера, суммарно занимающих весь объем СХД. Каждому серверу презентуется 8 LUN. Тесты проводятся аналогично тестам группы 2, исключение составляет то, что нагрузка генерируется одновременно двумя серверами. Оценивается суммарная производительность, полученная обоими серверами за время каждого теста. По окончании тестов делается вывод о влиянии количества серверов, генерирующих нагрузку, на производительность СХД.
Результаты тестирования
Группа 1: Тесты, реализующие длительную нагрузку типа random write с изменением размера блока операций ввода/вывода (в/в).
Заключения:1. При длительной нагрузке на запись в определенный момент времени фиксируется значительная деградация производительности СХД (Рисунок 3). Падение производительности ожидаемо и является особенностью работы SSD (write cliff), связанной с включением процессов garbage collection (GC) и ограниченной производительностью этих процессов. Производительность дискового массива, фиксируемую после эффекта write cliff (после падения производительности), можно рассматривать как максимальную среднюю производительность дискового массива.
.JPG)
Рисунок 3. Изменение скорости операций в/в (iops), скорости передачи данных (bandwidth) и задержек (Latency) при длительной записи блоком 4K.
2. Размер блока при длительной нагрузке на запись влияет на производительность процесса GC. Так при маленьких блоках (4К) скорость работы GC — 640Мбайт/c, на средних и больших блоках (16К-1М) CG работает на скорости порядка 1200Mбайт/s.3. Разница в значениях максимального времени работы СХД на пиковой производительности, фиксируемой при первом длительном тесте и последующем эквивалентном тесте с блоком 4К обусловлена тем, что СХД не было до конца заполнено перед началом тестирования.
4. Максимальное время работы СХД на пиковой производительности значимо отличается при блоке 4K и всех остальных блоках, что с большой вероятностью вызвано ограничением места СХД, резервируемом для выполнения процессов GC.
5. Для выполнения служебных процессов на СХД резервируется около 2Тбайт.
6. При тестах на СХД заполненном на 70%, падение производительности наступает незначительно позже (примерно на 10%). Изменений скорости работы процессов GC не зафиксировано.
Графики и таблицы. (Все картинки кликабельны)
Графики производительности блочного устройства при разных типах нагрузки, генерируемой одним сервером.
Таблица 1 Зависимость показателей СХД от размера блока при длительной нагрузке на запись.
Группа 2: Тесты производительности дискового массива при разных типах нагрузки, генерируемой одним сервером, исполняемые на уровне блокового устройства.
Основные результаты тестов представленных на графиках сведены в таблицы.Таблицы и графики. (Все картинки кликабельны)
Таблица 2 Производительность СХД при одном процессе, генерирующем нагрузку (jobs=1)
Таблица 3 Максимальная производительность СХД при задержках меньше 1 мс
Таблица 4. Максимальная производительность СХД при задержках до 3 мс
Таблица 5 Максимальная производительность СХД при различном профиле нагрузки.
Графики производительности блочного устройства при разных типах нагрузки, генерируемой двумя серверами.(Все картинки кликабельны)
Заключения:
1. Максимально зафиксированные параметры производительности для СХД (из средних за время выполнения каждого теста — 3 мин): Запись:
415000 IOPS при latency 4,9ms (блок 4KB async qd64) при синхронном в/в — 263000 IOPS при latency 0,2ms (блок 4К) Bandwidth: 3600МБ/c для больших блоков Чтение:475000 IOPS при latency 4,3ms и 440000 IOPS при latency 2,3 (блок 8KB async qd64); при синхронном в/в — 225000 IOPS при latency 0,26ms (блок 4К) Bandwidth: 6290МБ/с для больших блоков Смешанная нагрузка (70/30 rw)475000 IOPS при latency 4,3ms (блок 4KB async qd64); при синхронном в/в — 220000 IOPS при latency 0,27ms (блок 4К) Bandwidth 5135МБ/с для больших блоков. Минимально зафиксированная latency: При записи — 0,177ms для блока 4K jobs=32 sync При чтении — 0,25ms для блока 4K jobs=32 sync 2. СХД входит в режим насыщения при
асинхронном способе в/в при 8 jobs на больших блоках (32К-1М) и при 16 jobs на маленьких и средних блоках (4–16К). синхронном способе в/в при 64 jobs. 3. На операциях чтения большими блоками (16К-1М) получена пропускная способность более 6 Гбайт/с, что примерно соответствует суммарной пропускной способности интерфейсов, используемых при подключении сервера к СХД. Таким образом, ни контроллеры СХД, ни флэш-накопители, не являются «узким местом» системы.4. Массив при асинхронном способе в/в выдает в 1,5 — 2 раза большую производительность на маленьких блоках (4–8К), чем при синхронном способе в/в. На больших и средних блоках (16К-1М) производительность при синхронном и асинхронном в/в примерно равна.
5. На приведенных ниже графиках отображена зависимость максимальных полученных показателей производительности тестируемой СХД (IOPS и скорости передачи данных) от размера блока операций в/в. Характер графиков позволяет сделать следующие выводы:
при записи наиболее эффективным блоком для работы с СХД является блок 8К.
при чтении синхронным способом в/в выгоднее работать блоком 16К и 32К при чтении асинхронным способом в/в лучший блок — 16К.
Максимальные показатели производительности при чтении и записи синхронным способом в/в различным размером блока.
Максимальные показатели производительности при чтении и записи асинхронным способом в/в (qd32) различным размером блока.
Группа 3: Тесты производительности дискового массива при разных типах нагрузки, генерируемой двумя серверами, исполняемые на уровне блокового устройства.
По каждому из тестов была получена производительность, совпадающая в пределах погрешности 5% с результатами тестов группы 2, когда нагрузка генерировалась одним сервером. Мы не стали приводить графики и данные о производительности по тестам группы 3, в следствии их идентичности результатам 2-й группы.Иными словами, исследование показало, что сервер не является «узким местом» тестового стенда.Выводы
В целом, система показала великолепные результаты. Нам не удалось выявить очевидных «узких мест» и явных проблем. Все результаты стабильны и прогнозируемы. Сравнивая с нашим предыдущим тестированием IBM FlashSystem 820 стоит отметить отличия интерфейсов управления. 820-я модель управляется, порой вызывающим неудобства, java апплетом, доставшимся в наследство от RamSan 820 производства Texas Instruments. В то время, как 840-я имеет уже привычный для продуктов IBM web-интерфейс напоминающий XIV Storage System и Storwize. Работать с ними заметно приятнее и, в конечном счете, быстрее.Кроме этого, IBM FlashSystem 840 обзавелся необходимыми для устройств enterprise класса возможностями горячей замены всех компонентов и обновления микрокода «на лету». Существенно расширился выбор возможных интерфейсов подключения и конфигураций флэш-модулей.К недостаткам, пожалуй, можно отнести наличие деградации производительности при длительной записи. Хотя, это скорее недостаток сегодняшних технологий флэш-памяти, проявляющийся в следствие того, что производитель не стал искусственно ограничивать скорость работы системы. Даже при длительной максимальной нагрузке на запись и после падения производительности, СХД показывала замечательные результаты.
P.S. Автор выражает сердечную благодарность Павлу Катасонову, Юрию Ракитину и всем другим сотрудникам компании участвовавшим в подготовке данного материала.
