Это гостевой пост компании ИТ-ГРАД - облачного провайдера инфраструктур в аренду VMware vSphere.
Мне давно не попадался на тесты массив начального уровня, способный пропустить через один контроллер до 1.5 Гб/сек при потоковой нагрузке. NetApp E2700 как раз справился с этой задачей. В июне я провёл Unboxing NetApp E2700. И теперь готов поделиться с вами результатами тестирования этой системы хранения данных. Ниже привожу результаты нагрузочных тестов и получившиеся количественные показатели производительности массива NetApp E-Series 2700 (IOps, Throughput, Latency).
Конфигурация дискового массива следующая:
Схема подключения массива к серверу:
И конфигурация тестового сервера:
Методика проведения тестирования
В качестве генератора нагрузки я использую FIO benchmark, как самый «true» benchmark под Linux. Я хочу получить данные по средней скорости (bandwith, Mb/s) и усредненным задержкам (latency, ms) при следующих типах нагрузки:
100% последовательное чтение, блоками по 256 kb, 512 Kb и 1024 Kb;
100% последовательная запись, блоками по 256 kb, 512 Kb и 1024 Kb;
Смешанные последовательные чтение/запись (50/50), блоками по 256 kb, 512 Kb и 1024 Kb;
100% случайное чтение, блоками по 4 kb, 8 Kb и 16 Kb;
100% случайная запись, блоками по 4 kb, 8 Kb и 16 Kb;
Смешанные случайные чтение/запись (50/50), блоками по 256 kb, 512 Kb и 1024 Kb;
При этом я буду использовать два LUN с массива, каждый размером по 1 Тб, которые доступны на уровне сервера как RAW устройства: sdb и sdc.
Важным моментом моих тестов является сравнение производительности различных уровней RAID, которые поддерживает массив. Поэтому я буду поочередно подавать нагрузку на LUN, созданные на: DDP, RAID6, RAID10. И Dynamic Disk Pool и Volume Groups я буду создавать на базе всех 24 дисков.
Для того чтобы не ставить результаты в зависимость от алгоритма работы пресловутого «Linux memory cache», я использую именно блочные устройства, без организации поверх них файловой системы. Безусловно, это не самая стандартная конфигурация для потоковых приложений, но мне важно понять, на что способен именно массив. Хотя, забегая вперед, скажу, что при использовании в паттерне нагрузки FIO параметров direct=1 и buffered=0 работа (запись) с файлами на уровне EXT4 показывает почти одинаковые результаты с блочными устройствами по bandwith. При этом показатели latency при работе с файловой системой выше на 15-20 процентов, чем при работе с raw devices
Паттерн нагрузки для FIO сконфигурирован следующим образом:
[global]
description=seq-reads
ioengine=libaio
bs= см. выше
direct=1
buffered=0
rw=[write, read, rw, randwrite, randread, randrw]
runtime=900
thread
[sdb]
filename=/dev/sdc
iodepth=см. ниже
[sdc]
filename=/dev/sdb
iodepth=см. ниже
Если я правильно понял, man по fio, параметр iodepth, определяет количество независимых потоков, работающих с диском одновременно. Соответственно, в конфигурации я получаю количество потоков равное X*2 (4, 8, 16).
В результате набор тестов у меня получился следующий:
С методиками разобрались, паттерны определили, даем нагрузку. Для облегчения труда админа можно нарезать набор паттернов FIO в виде отдельных файлов, в которых будут меняться значения двух параметров – bs и iodepth. Потом можно написать скрипт, который в двойном цикле (меняем значения двух параметров) выполнит прогон всех наших паттернов с сохранением нужных нам показателей в отдельные файлы.
Да, чуть не забыл пару моментов. На уровне массива я конфигурировал параметры кэша следующим образом:
для потоковой записи я выключал кэш на чтение;
для потокового чтения, выключал, соответственно, кэш на запись, и не использовал алгоритм dynamic read prefetch;
для смешанных операций чтения и записи активировал кэш полностью.
На уровне Linux я менял штатный планировщик I/O на noop при потоковых операциях и на deadline при рандомных. Кроме этого, для грамотной балансировки трафика на уровне HBA я установил multipath-драйвер от NetApp, MPP/RDAC. Результаты его работы меня приятно удивили, балансировка потока данных между портами HBA выполнялась почти 50-на-50, чего я никогда не наблюдал ни у Qlogic, ни у штатного linux multipathd.
SANTricity имеет ряд настроечных параметров (я уже писал выше, например, про управление кешированием данных на уровне тома). Еще один потенциально интересный параметр это Segment Size, который можно задавать и изменять на уровне тома. Segment Size – это блок, который контроллер записывает на один диск (данные внутри сегмента записываются блоками по 512 байт). Если я использую DDP, то размер этого параметра для всех томов, созданных в пуле, одинаков, (128k) и изменить его нельзя.
Для томов, создаваемых на базе VolumeGroup, я могу выбирать преднастроенные шаблоны нагрузки для тома (FileSystem, Database, Multimedia). Кроме этого, я могу выбрать размер SegmentSize самостоятельно в диапазоне от 32 Кб до 512 Кб.
Вообще для встроенных Volume I/O characteristics type размер Segment Size не отличается особой разнообразностью:
Для паттерна File system = 128 Kb;
Для паттерна Database = 128 Kb;
Для паттерна Multimedia = 256 Kb.
Я не изменял предлагаемый по умолчанию при создании тома паттерн (File system) для того, чтобы Segment Size для томов, создаваемых на DDP и на обычной VolumeGroup, был одинаковым.
Безусловно, я поиграл с размером Segment Size, чтобы понять, как он влияет на производительность операций записи (для примера). Результаты вполне стандартные:
При самом малом размере, SS = 32 Кб, я получаю более высокие показатели производительности при операциях с небольшим размером блоков;
При самом большом размере, SS = 1024 Кб, я получаю более высокие показатели производительности при операциях с большим размером блоков;
Если я выравниваю размер SS и размер блока, которым оперирует FIO, то результаты получаются еще лучше;
Есть одно «но». Я обратил внимание, что при потоковой записи большими блоками и SS = 1024 Кб значения latency получаются выше, чем при размере SS = 128 Кб или 256 Кб.
Итого, полезность этого параметра очевидна, и если мы предполагаем, что у нас будет много рандомных операций, то имеет смысл задать его равным 32 Кб (если, конечно, мы не используем DDP). Для потоковых операций я не вижу смысла задавать значение SS по максимуму, т.к. кардинального прироста скорости передачи данных я не наблюдал, а показатели latency могут быть критичными для приложения.
Результаты (оценка и сравнение результатов)
Результаты тестов по DDP
Результаты тестов на RAID6
Результаты тестов на RAID10
Оценка результатов
Первый момент, на который я сразу обратил внимание, это 0% использования кэша на чтение при любом паттерне (и даже при полностью выключенном кэше на запись). С чем это было связано, понять так и не удалось, но результаты по операциям чтения проседали по сравнению с операциями записи ощутимо. Возможно, это связано с одноконтроллерной конфигурацией тестового массива, так как кэш на чтение должен зеркалироваться между двумя контроллерами.
Второй момент, это достаточно низкие показатели по рандомным операциям. Объясняется это тем, что размер Segment Size (как я писал выше) по умолчанию использовался равным 128 Кб. Для небольших размеров блоков такой размер SS не подходит. Для проверки я запускал рандомную нагрузку на томах в RAID6 и RAID10 с SS = 32 Кб. Результаты получались гораздо более интересными. Но в случае с DDP мы не имеем возможности менять размер SS, поэтому рандомная нагрузка на DDP противопоказана.
Если сравнивать производительность DDP, RAID6 и RAID10 при размере SS = 128 Кб, то можно отследить следующие закономерности:
В целом большой разницы между тремя разными логическими представлениями блоков не выявлено;
RAID10 стабильнее держит нагрузку, даже смешанную, выдавая при этом лучшие показатели latency, но проигрывает в скорости потоковой записи и чтения RAID6 и DDP;
RAID6 и DDP при рандомных операциях при увеличении размера блока показывают лучшие значения latency и IOps. Скорее всего, это связанно с размером SS (см. выше). Однако RAID10 не показал такого эффекта;
Как я уже написал выше, рандомная нагрузка для DDP противопоказана, во всяком случае при размерах блоков меньше 32 Кб.
Выводы
Мне давно не попадался на тесты массив начального уровня, способный пропустить через один контроллер до 1.5 Гб/сек при потоковой нагрузке. Можно предположить, что двухконтроллерная конфигурация сможет обработать до 3 Гб/сек. А это поток данных до 24 Гбит/сек.
Конечно, тесты, использованные нами, являются синтетическими. Но показанные результаты очень неплохие. Как и предполагалось, массив слабо держит смешанную нагрузку при рандомных операциях, но чудес не бывает :-).
В плане юзабилити и возможностей оптимизации настроек под конкретный шаблон нагрузки для массива начального уровня E2700 показал себя на высоте. SANTricity имеет понятный и достаточно простой интерфейс, минимум глюков и тормозов. Нет излишних настроек значений, которые зачастую не понятны (вспоминаю управляющий интерфейс IBM DS 4500 — это было что-то)). В целом все на твердую «4».
RSS
