В середине 2012-го года EMC заплатила $430 миллионов за открытый 3-мя годами ранее израильский стартап. Еще на стадии разработки, фактически за полгода до предполагаемого появления первого XtremIO устройства. К заказу, первые устройства стали доступны только в конце 2013-го.
Основная отличительная особенность XtremIO заключена в его архитектуре и функциональности. Во-первых, в архитектуру изначально заложены постоянно работающие и неотключаемые сервисы, такие как инлайн-дедупликация, компрессия и thin provisioning, которые позволяют экономить место на SSD. Во-вторых, XtremIO — это горизонтально-масштабируемый кластер из модулей (X-Bricks), между которыми автоматически равномерно распределяются данные и нагрузка. При этом, используется стандартное x86-оборудование и SSD, а функциональность реализована программно. В итоге, получается не просто быстрый диск, а массив, который позволяет экономить емкость за счет дедупликации и компрессии, особенно в таких задачах, как серверная виртуализация, VDI или базы данных с несколькими копиями.
Любовь к различного рода тестам не является сильной стороной компании EMC. Тем не менее, благодаря инициативной помощи локального офиса, для нас, в недрах удаленной лаборатории, был собран стенд включавший 2 X-Brick системы. Что позволило нам провести ряд тестов максимально приближенных к разработанной нами методике.
Тестирование проводилось на версии кода 2.4, сейчас доступна версия 3.0, в которой заявлены вдвое меньшие задержки.
В ходе тестирования решались следующие задачи:
Тестовый стенд состоит из 4 серверов, каждый из которых подключен четырьмя 8Gb соединениями к 2 FC коммутаторам. Каждый коммутатор имеет по 4 соединения 8Gb FC к СХД EMC Xtream-IO. На FC коммутаторах созданы зоны таким образом, что каждый инициатор находится в зоне с каждым портом СХД.
Сервер;
СХД
В качестве дополнительного программного обеспечения на тестовый сервер установлен Symantec Storage Foundation 6.1, реализующий:
Тесты выполнялись посредством создания синтетической нагрузки одновременно с четырех серверов программой fio на блочное устройство (Block Device), представляющее собой логический том типа
Тестирование состояло из 2-х групп тестов:
Исследование производительности дискового массива на синтетических тестах.
Результаты тестов представлены в виде графиков (рисунок 2 и 3).
Основные выводы:
При длительной нагрузке падения производительности со временем не зафиксировано. Такое явление, как «Write Cliff» отсутствует. Следовательно, при выборе дисковой подсистемы (sizing) можно рассчитывать на стабильную производительность вне зависимости от длительности нагрузки (истории использования дискового массива).
Результаты тестов приведены в виде графиков (Рис. 4-9) и сведены в таблицы 1-3
Запись:
Чтение:
Смешанная нагрузка (70/30 rw)
В качестве дополнительного бонуса нам продемонстрировали производительность «моментальных снимков». 32 snapshot снятые одновременно с 32-вух, максимально нагруженных на запись, лунов не оказали видимого влияния на производительность, что не может не вызывать восхищения архитектурой системы.
Подводя итог можно сказать, что массив произвел благоприятное впечатление и продемонстрировал заявленные производителем iops. На фоне других flash решений его выгодно отличает:
Уникальная архитектура и алгоритмы обработки данных массива позволяют реализовать великолепный функционал (дедупликацию, снапшоты, тонкие луны).
К сожалению, тестирование получилось не полным. Ведь максимальная производительность ожидается от системы состоящей из 4 X-Brick. К тому-же, нам была предоставлена версия 2.4, в то время, как уже вышла версия 3.0, где заявлены вдвое меньшие задержки. По прежнему неясными остались вопросы работы массива с большими блоками (его максимальной пропускной способности) и работы с синхронным вводом-выводом, где критична задержка. Надеемся что в вскоре мы сможем закрыть все эти «белые пятна» дополнительными исследованиями.
P.S. Автор выражает сердечную благодарность Павлу Катасонову, Юрию Ракитину и всем другим сотрудникам компании участвовавшим в подготовке данного материала.
Основная отличительная особенность XtremIO заключена в его архитектуре и функциональности. Во-первых, в архитектуру изначально заложены постоянно работающие и неотключаемые сервисы, такие как инлайн-дедупликация, компрессия и thin provisioning, которые позволяют экономить место на SSD. Во-вторых, XtremIO — это горизонтально-масштабируемый кластер из модулей (X-Bricks), между которыми автоматически равномерно распределяются данные и нагрузка. При этом, используется стандартное x86-оборудование и SSD, а функциональность реализована программно. В итоге, получается не просто быстрый диск, а массив, который позволяет экономить емкость за счет дедупликации и компрессии, особенно в таких задачах, как серверная виртуализация, VDI или базы данных с несколькими копиями.
Любовь к различного рода тестам не является сильной стороной компании EMC. Тем не менее, благодаря инициативной помощи локального офиса, для нас, в недрах удаленной лаборатории, был собран стенд включавший 2 X-Brick системы. Что позволило нам провести ряд тестов максимально приближенных к разработанной нами методике.
Тестирование проводилось на версии кода 2.4, сейчас доступна версия 3.0, в которой заявлены вдвое меньшие задержки.
Методика тестирования
В ходе тестирования решались следующие задачи:
- исследования процесса деградации производительности СХД при длительной нагрузке на запись (Write Cliff);
- исследование производительности СХД EMC XtremIO при различных профилях нагрузки;
Конфигурация тестового стенда
 |
| Рисунок 1. Структурная схема тестового стенда. |
Сервер;
СХД
В качестве дополнительного программного обеспечения на тестовый сервер установлен Symantec Storage Foundation 6.1, реализующий:
- Функционал логического менеджера томов (Veritas Volume Manager);
- Функционал отказоустойчивого подключения к дисковым массивам (Dynamic Multi Pathing).
Посмотреть утомительные подробности и всякие умные слова.
На тестовом сервере выполнены следующие настройки, направленные на снижение латентности дискового ввода-вывода:
На СХД выполняются следующие конфигурационные настройки по разбиению дискового пространства:
Для создания синтетической нагрузки (выполнения синтетических тестов) на СХД используется утилита Flexible IO Tester (fio) версии 2.1.4. При всех синтетических тестах используются следующие конфигурационные параметры fio секции [global]:
Для снятия показателей производительности при синтетической нагрузке применяются следующие утилиты:
- Изменен планировщик ввода-вывода с «cfq» на «noop» через присвоение значения noop параметру;
/sys/<путь_к_устройству_Symantec_VxVM>/queue/scheduler - Добавлен следующий параметр в
/etc/sysctl.confминимизирующий размер очереди на уровне логического менеджера томов Symantec:«vxvm.vxio.vol_use_rq = 0»; - Увеличен предел одновременных запросов ввода-вывода на устройство до 1024 через присвоение значения 1024 параметру
/sys/<путь_к_устройству_Symantec_VxVM>/queue/nr_requests - Отключена проверка возможности слияния операций в/в (iomerge) через присвоение значения 1 параметру
/sys/<путь_к_устройству_Symantec_VxVM>/queue/nomerges - Отключено упреждающее чтение через присвоение значения 0 параметру
/sys/<путь_к_устройству_Symantec_VxVM>/queue/read_ahead_kb - Использован принятый по умолчанию (30) размер очереди на FC HBA;
На СХД выполняются следующие конфигурационные настройки по разбиению дискового пространства:
- На СХД по умолчанию размечено все пространство и есть возможность только логического разбиения физической емкости.
- На СХД создаются 32 LUN одинакового размера, совокупно занимающие 80% емкости СХД, луны презентуются по 8 каждому серверу.
Программное обеспечение, используемое в процессе тестирования
Для создания синтетической нагрузки (выполнения синтетических тестов) на СХД используется утилита Flexible IO Tester (fio) версии 2.1.4. При всех синтетических тестах используются следующие конфигурационные параметры fio секции [global]:
- direct=1
- size=3T
- ioengine=libaio
- group_reporting=1
- norandommap=1
- time_based=1
- randrepeat=0
Для снятия показателей производительности при синтетической нагрузке применяются следующие утилиты:
- интерфейс и средства мониторинга и диагностики СХД;
- fio версии 2.1.4, для формирования сводного отчета по каждому профилю нагрузки
Программа тестирования.
Тесты выполнялись посредством создания синтетической нагрузки одновременно с четырех серверов программой fio на блочное устройство (Block Device), представляющее собой логический том типа
stripe, 8 column, stripewidth=1MiB, созданный с использованием Veritas Volume Manager из 8-ми LUN, презентованных с тестируемой системы, на каждом сервере. Созданные тома предварительно полностью заполняются данными. Тестирование состояло из 2-х групп тестов:
Поинтересоваться подробностями
При создании тестовой нагрузки используются следующие дополнительные параметры программы fio:
Длительность тестирования — 18 часов.
По результатам тестов, на основании данных выводимых командой vxstat, формируются графики, совмещающие результаты тестов:
Проводится анализ полученной информации и делаются выводы о:
В ходе тестирования исследуются следующие типы нагрузок:
Тесты производятся в 3 этапа:
Подобный алгоритм тестирования позволяет определить предельную производительность дискового массива при заданном профиле нагрузки, а также зависимость latency от нагрузки.
По результатам тестов строятся графики и таблицы полученных iops и latency, производится анализ результатов и делаются выводы о производительности СХД.
Группа 1: Тесты, реализующие длительную нагрузку типа random write.
При создании тестовой нагрузки используются следующие дополнительные параметры программы fio:
- rw=randwrite
- blocksize=4K
- numjobs=10
- iodepth=8
Длительность тестирования — 18 часов.
По результатам тестов, на основании данных выводимых командой vxstat, формируются графики, совмещающие результаты тестов:
- IOPS как функция времени;
- Latency как функция времени.
Проводится анализ полученной информации и делаются выводы о:
- Наличие деградации производительности при длительной нагрузке на запись и на чтение;
- Производительности сервисных процессов СХД (Garbage Collection) ограничивающих производительность дискового массива на запись при длительной пиковой нагрузке;
Группа 2: Тесты производительности дискового массива при разных типах нагрузки.
В ходе тестирования исследуются следующие типы нагрузок:
- профили нагрузки (изменяемые параметры ПО fio: randomrw, rwmixedread):
- случайная запись 100%;
- случайная запись 30%, случайное чтение 70%;
- случайное чтение 100%.
- размеры блока: 1КБ, 8КБ, 16КБ, 32КБ, 64КБ, 1МБ (изменяемый параметр ПО fio: blocksize);
- способы обработки операций ввода-вывода: асинхронный (изменяемый параметр ПО fio: ioengine);
Тесты производятся в 3 этапа:
- для каждой комбинации перечисленных выше типов нагрузки путем вариации параметров fio numjobs и iodepth находится точка насыщения СХД, то есть такая комбинация jobs и iodepth, при которой достигается максимум iops, но задержка минимальна. Фиксируются программой fio показатели iops, latency, numjobs и qdepth.
- затем тесты проводятся аналогично предыдущему этапу, только ищется точка, при которой достигается приблизительно вдвое меньшая производительность.
- затем проводятся аналогичные тесты, ищется точка еще вдвое меньшей производительности.
Подобный алгоритм тестирования позволяет определить предельную производительность дискового массива при заданном профиле нагрузки, а также зависимость latency от нагрузки.
По результатам тестов строятся графики и таблицы полученных iops и latency, производится анализ результатов и делаются выводы о производительности СХД.
Результаты тестирования
Исследование производительности дискового массива на синтетических тестах.
Группа 1: Тесты, реализующие длительную нагрузку типа random write.
Результаты тестов представлены в виде графиков (рисунок 2 и 3).
Посмотреть графики.
 |
| Рисунок 2. IOPS при длительной записи (блок 4К) |
 |
| Рисунок 3. Задержка при длительной записи (блок 4К) |
Основные выводы:
При длительной нагрузке падения производительности со временем не зафиксировано. Такое явление, как «Write Cliff» отсутствует. Следовательно, при выборе дисковой подсистемы (sizing) можно рассчитывать на стабильную производительность вне зависимости от длительности нагрузки (истории использования дискового массива).
Группа 2: Тесты производительности дискового массива при разных типах нагрузки.
Результаты тестов приведены в виде графиков (Рис. 4-9) и сведены в таблицы 1-3
Посмотреть графики и таблицы.
 |
| Рисунок 4. IOPS при случайной записи. |
 |
| Рисунок 5. Задержка при случайной записи. (ms) |
 |
| Таблица 1. Производительность при случайной записи |
 |
| Рисунок 6. IOPS при смешанном в/в (70% чтение 30% запись) |
 |
| Рисунок 7. Задержка при смешанном в/в (70% чтение 30% запись) (ms) |
 |
| Таблица 2. Производительность при смешанном в/в (70% чтение 30% запись) |
 |
| Рисунок 8. IOPS при случайном чтении. |
 |
| Рисунок 9. Задержка при случайном чтении. (ms) |
 |
| Таблица 3. Производительность при случайном чтении. |
Максимально зафиксированные параметры производительности СХД:
Запись:
- 160000 IOPS при latency 1.2ms (блок 4K);
Чтение:
- 455000 IOPS при latency 1,4ms (блок 4K jobs=10 qd=16 );
Смешанная нагрузка (70/30 rw)
- 264000 IOPS при latency 1,15ms (блок 4K jobs=8 qd=10);
- СХД обеспечивает заявленную производительность при приемлемых задержках.
- Полученные значения задержек нельзя считать минимальными, т.к. тестирование производилось только асинхронным способом в/в с глубиной очереди больше 1.
- На блоке 1МБ производительность ниже ожидаемой. Дальнейшие исследования показали, что при тестах 1МБ блоком на СХД происходили операции блоками 256КБ. Это значит, что блоки данных перед отправкой делились на сервере, что и привело к падению производительности. Причиной тому послужило использование параметра swidth=1m вместо stripeunit=1m при создании тома Symantec VxVM.
- При случайной записи, изменение производительности с увеличением размера блока происходит линейно, что позволяет сделать вывод об ограничении пропускной способности (bandwidth) СХД на запись на уровне примерно 700-750МБ/с.
В качестве дополнительного бонуса нам продемонстрировали производительность «моментальных снимков». 32 snapshot снятые одновременно с 32-вух, максимально нагруженных на запись, лунов не оказали видимого влияния на производительность, что не может не вызывать восхищения архитектурой системы.
Выводы
Подводя итог можно сказать, что массив произвел благоприятное впечатление и продемонстрировал заявленные производителем iops. На фоне других flash решений его выгодно отличает:
- Отсутствие деградации производительности на операциях записи (write cliff)
- Онлайн дедупликация, позволяющая не только экономить в объеме, но и выигрывать в скорости записи.
- Функцилонал snapshot и их впечатляющая производительность.
- Масштабируемость от 1 до 4 узлов (X-brick)
Уникальная архитектура и алгоритмы обработки данных массива позволяют реализовать великолепный функционал (дедупликацию, снапшоты, тонкие луны).
К сожалению, тестирование получилось не полным. Ведь максимальная производительность ожидается от системы состоящей из 4 X-Brick. К тому-же, нам была предоставлена версия 2.4, в то время, как уже вышла версия 3.0, где заявлены вдвое меньшие задержки. По прежнему неясными остались вопросы работы массива с большими блоками (его максимальной пропускной способности) и работы с синхронным вводом-выводом, где критична задержка. Надеемся что в вскоре мы сможем закрыть все эти «белые пятна» дополнительными исследованиями.
P.S. Автор выражает сердечную благодарность Павлу Катасонову, Юрию Ракитину и всем другим сотрудникам компании участвовавшим в подготовке данного материала.
