Тестирование netapp e2700

Июнь 10, 2015

intellcity

Мне в далеком прошлом не попадался на тесты массив начального уровня, талантливый пропустить через один контроллер до 1.5 Гб/сек при потоковой нагрузке. NetApp E2700 именно справился с данной задачей. В июне я совершил Unboxing NetApp E2700. И сейчас готов поделиться с вами результатами тестирования данной совокупности хранения данных.

Ниже привожу результаты нагрузочных тестов и оказавшиеся количественные показатели производительности массива NetApp E-Series 2700 (IOps, Throughput, Latency).
Смотрите кроме этого: Unboxing NetApp E2700

Мы знакомим вас с оборудованием как оно имеется: крупно, со всех сторон и без обертки.В данной статье мы детально разглядим представительницу блочных совокупностей хранения данных NetApp E2700, которая пришла к нам семь дней назад на тестирование. Главными областями применения данных совокупностей являются: full motion видео, медиа контент, обработка сейсмических данных,видеонаблюдение , высокопроизводительные вычислительные кластера (HPC), D2D бэкап, геологоразведка и др.

Конфигурация дискового массива следующая:Схема подключения массива к серверу: И конфигурация тестового сервера:Методика проведения тестированияВ качестве генератора нагрузки я использую 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 и аккумуляторная=0 работа (запись) с файлами на уровне EXT4 показывает практически однообразные результаты с блочными устройствами по bandwith. Наряду с этим показатели latency при работе с файловой совокупностью выше на 15-20 процентов, чем при работе с raw devices Паттерн нагрузки для FIO сконфигурирован следующим образом: [global]description=seq-readsioengine=libaiobs= см. вышеdirect=1buffered=0rw=[write, read, rw, randwrite, randread, randrw]runtime=900thread [sdb]filename=/dev/sdciodepth=см. ниже [sdc]filename=/dev/sdbiodepth=см. нижеЕсли я верно осознал, 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 противопоказана.
В случае если сравнивать производительность аккумуляторная, 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».

Тестирование netapp e2700

Случайная статья:

SANtricity System Manager: Easy Setup and Configuration

Похожие статьи:

Закрепленное видео

Свежие

Записи

Рубрики