- PVSM.RU - https://www.pvsm.ru -
Мне давно не попадался на тесты массив начального уровня, способный пропустить через один контроллер до 1.5 Гб/сек при потоковой нагрузке. NetApp E2700 как раз справился с этой задачей. В июне я провёл Unboxing NetApp E2700 [1]. И теперь готов поделиться с вами результатами тестирования этой системы хранения данных. Ниже привожу результаты нагрузочных тестов и получившиеся количественные показатели производительности массива NetApp E-Series 2700 (IOps, Throughput, Latency).
Конфигурация дискового массива следующая:
Схема подключения массива к серверу:
И конфигурация тестового сервера:
В качестве генератора нагрузки я использую FIO benchmark, как самый «true» benchmark под Linux. Я хочу получить данные по средней скорости (bandwith, Mb/s) и усредненным задержкам (latency, ms) при следующих типах нагрузки:
При этом я буду использовать два 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. Потом можно написать скрипт, который в двойном цикле (меняем значения двух параметров) выполнит прогон всех наших паттернов с сохранением нужных нам показателей в отдельные файлы.
Да, чуть не забыл пару моментов. На уровне массива я конфигурировал параметры кэша следующим образом:
На уровне 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) для того, чтобы Segment Size для томов, создаваемых на DDP и на обычной VolumeGroup, был одинаковым.
Безусловно, я поиграл с размером Segment Size, чтобы понять, как он влияет на производительность операций записи (для примера). Результаты вполне стандартные:
Итого, полезность этого параметра очевидна, и если мы предполагаем, что у нас будет много рандомных операций, то имеет смысл задать его равным 32 Кб (если, конечно, мы не используем DDP). Для потоковых операций я не вижу смысла задавать значение SS по максимуму, т.к. кардинального прироста скорости передачи данных я не наблюдал, а показатели latency могут быть критичными для приложения.
Результаты тестов по DDP
Результаты тестов на RAID6
Результаты тестов на RAID10
Мне давно не попадался на тесты массив начального уровня, способный пропустить через один контроллер до 1.5 Гб/сек при потоковой нагрузке. Можно предположить, что двухконтроллерная конфигурация сможет обработать до 3 Гб/сек. А это поток данных до 24 Гбит/сек.
Конечно, тесты, использованные нами, являются синтетическими. Но показанные результаты очень неплохие. Как и предполагалось, массив слабо держит смешанную нагрузку при рандомных операциях, но чудес не бывает :-).
В плане юзабилити и возможностей оптимизации настроек под конкретный шаблон нагрузки для массива начального уровня E2700 показал себя на высоте. SANTricity имеет понятный и достаточно простой интерфейс, минимум глюков и тормозов. Нет излишних настроек значений, которые зачастую не понятны (вспоминаю управляющий интерфейс IBM DS 4500 — это было что-то)). В целом все на твердую «4».
Автор: it_man
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/shd/67851
Ссылки в тексте:
[1] Unboxing NetApp E2700: http://habrahabr.ru/company/it-grad/blog/224701/
[2] Источник: http://habrahabr.ru/post/233865/
Нажмите здесь для печати.