Тестирование флеш СХД. IBM RamSan FlashSystem 820

    Основы темы мы рассмотрели ранее,  в статье "Тестирование флеш СХД. Теоретическая часть". Сегодня перейдем к практике. Нашим первым пациентом будет IBM RamSan FlashSystem 820. Отличная рабочая система, вышедшая в апреле 2013 года. Была топовой моделью до января этого года, уступив место FlashSystem 840.


    Методика тестирования


    В ходе тестирования решались следующие задачи:
    • исследовать процесс деградации производительности СХД при длительной нагрузке на запись (Write Cliff) и чтение;
    • исследовать производительность СХД IBM FlashSystem 820 при различных профилях нагрузки;

    Конфигурация тестового стенда


    Схема и конфигурация стенда приведены на рисунке.
    Рисунок 1 Структурная схема тестового стенда. (кликабельна)

    Посмотреть утомительные подробности и всякие умные слова.
    В качестве дополнительного программного обеспечения на тестовый сервер устанавливается Symantec Storage Foundation 6.1 с Hot Fix 6.1HF100, реализующий:
    • Логический менеджер томов (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 на тестируемой системе и презентованный тестовому серверу.

    Поинтересоваться подробностями

    Группа 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):
    1. случайная запись 100%;
    2. случайная запись 30%, случайное чтение 70%;
    3. случайное чтение 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. Автор выражает сердечную благодарность Павлу Катасонову, Юрию Ракитину и всем другим сотрудникам компании участвовавшим в подготовке данного материала.
    • +17
    • 11,1k
    • 4
    INLINE Technologies
    36,00
    Универсальный ИТ-интегратор
    Поделиться публикацией

    Комментарии 4

      +1
      Выглядит хорошо. Замечания по поводу тестов:
      * при подключении томов к линуксам не забывайте отключать дисковый скедулер (noop вместо cfq)
      * При тесте на случайную запись и чтение надо отключать readahead (hdparm -A 0 /dev/sd_iscsi_или_что_тут_у_вас)
      * latency на запись в 30мс для SSD — это состояние деградации. То есть даже для магнитного носителя 30мс — это точка отсечения, дальше трешинг, а в контексте SSD я бы разумным пределом ставил что-то порядка 5-6мс, а по совести — 1мс.

      Я не до конца понял конфигурацию самой хранилки. Шпинделей 12, из них два raid5? Или как-то иначе? В любом случае, мы получаем, что у нас идёт две независимые записи на группу зависимых шпинделей. У SSD глубина очереди обычно 32, то есть имеем общую длину очереди 64. У вас же 64*64 = 4096, то есть очевидное congestion ещё до того, как запросы дошли до SSD. Я бы предложил поставить что-то, что даст кратность 64 на выходе (iodepth=4, 16 потоков, например). Это должно очень сильно уменьшить latency.
        +1
        1. Scheduler отключили – это описано в методике.
        2. Полагаю, на рандомной нагрузке readahead не оказывает влияние, нет последовательных операций, но хуже от этого не будет. Спасибо за коммент.
        3. По latency: Конечно, 30ms — это насыщение. Начиная с определенного момента IOPS не растут, только очередь. Как следствие — latency. Одна из задач тестирования, как раз и заключалась в том, чтобы определить точку в которой это начинает происходить.
        4. По конфигурации: У 820 фиксированная конфигурация RAID5(10+1) & HS – возможности выбор нет. На RAID5 делалось несколько LUN, из которых на уровне OS собирался stripe – таким образом, получилась наиболее производительная конфигурация. Дисковый массив и OS параллелят ряд операций на уровне LUN. Увеличение их кол-ва в разумных пределах, позволяет поднять производительность.
        5. «У SSD глубина очереди обычно 32» — SSD за контроллером, у контроллера очередь значимо больше. Какая точно — не знаю. Iodepth=4 & 16 потоков по сути эквивалентно с точки зрения нагрузки sync в 64 потока. Такой тест есть.
        –1
        Классический вопрос, какая цена GPL на железку?..
          +1
          Откровенно говоря, я расчитывал избежать подобного рода вопросов. Но, раз уж вас это интересует — порядка $250K. Что, как понимает уважаемая публика, является сферическим конем в ваккуме.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое