Мне давно не попадался на тесты массив начального уровня, способный пропустить через один контроллер до 1.5 Гб/сек при потоковой нагрузке. NetApp E2700 как раз справился с этой задачей. В июне я провёл Unboxing NetApp E2700. И теперь готов поделиться с вами результатами тестирования этой системы хранения данных. Ниже привожу результаты нагрузочных тестов и получившиеся количественные показатели производительности массива NetApp E-Series 2700 (IOps, Throughput, Latency).
И конфигурация тестового сервера:
- 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=см. ниже |
- для потоковой записи я выключал кэш на чтение;
- для потокового чтения, выключал, соответственно, кэш на запись, и не использовал алгоритм dynamic read prefetch;
- для смешанных операций чтения и записи активировал кэш полностью.
- Для паттерна File system = 128 Kb;
- Для паттерна Database = 128 Kb;
- Для паттерна Multimedia = 256 Kb.
- При самом малом размере, SS = 32 Кб, я получаю более высокие показатели производительности при операциях с небольшим размером блоков;
- При самом большом размере, SS = 1024 Кб, я получаю более высокие показатели производительности при операциях с большим размером блоков;
- Если я выравниваю размер SS и размер блока, которым оперирует FIO, то результаты получаются еще лучше;
- Есть одно «но». Я обратил внимание, что при потоковой записи большими блоками и SS = 1024 Кб значения latency получаются выше, чем при размере SS = 128 Кб или 256 Кб.
Итого, полезность этого параметра очевидна, и если мы предполагаем, что у нас будет много рандомных операций, то имеет смысл задать его равным 32 Кб (если, конечно, мы не используем DDP). Для потоковых операций я не вижу смысла задавать значение SS по максимуму, т.к. кардинального прироста скорости передачи данных я не наблюдал, а показатели latency могут быть критичными для приложения.
Результаты (оценка и сравнение результатов)
Результаты тестов по DDP
- Первый момент, на который я сразу обратил внимание, это 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 Кб.
Выводы
Предыдущая статья
