Трое в лодке: NVMe против SAS и SATA SSD

15 февраль, 2017 - 10:14Игорь Дражан

Мы поместили в одну платформу накопители на флэш-памяти трех типов и оценили их поведение под разными шаблонами нагрузки.

Гонка за производительностью дисковых операций в серверных приложениях начинается с выбора SSD, оптимальных в заданном профиле нагрузок. Предложение SATA SSD велико, иногда попадаются SAS SSD, совсем редко NVMe SSD. Последние представляют наибольший интерес – как устройства, напрямую подключаемые в шину PCI Express, без посредничества SAS/AHCI- стека. Их обычно и продают в виде карт для установки в слот PCIe. Интереснее другой их формат – U.2 (2.5” NVMe). Таких в дисковую корзину сервера можно поставить несколько и менять их на горячую.   

Как только в тестовую лабораторию Entry попали накопители U.2, просто протестировать их нам показалось мало. Решили впрячь в одну телегу коней и трепетную лань. Взяли двухпроцессорную 1U-платформу Supermicro 1028R-WC1R c 10-ю отсеками 2.5". К двум крайним справа отсекам в ней можно подвести по четыре линии PCIe (для этого нужна дополнительная плата-ретаймер с соединительными кабелями).

В состав платформы входит SAS RAID-контроллер (нам подошел вариант подключения SAS и SATA SSD через SAS HBA в слоте расширения PCIe), дисковых отсеков на передней панели много – вот и созрел план сравнительных тестов с одновременной установкой флэш-накопителей трех типов: U.2, SAS и SATA. Не самая блестящая идея: стравливать диски с заведомо разными возможностями. Тем не менее, простая в реализации постановка дала интересные результаты. 

Накопители

В тесты поставили те SSD, что добыли:

• 2 х U.2 NVMe        800 ГБ HGST Ultrastar SN100 {HUSPR3280ADP301}
• 2 х SAS 3.0 12 Гб/с    400 ГБ HGST Ultrastar 1600MM 12G {HUSMM1640ASS204}
• 2 х SATA 3.0 6 Гб/c    400 ГБ Intel 3710 Series {SSDSC2BA400G401}

Выписка из паспортного стола:

Тестовая платформа

SAS HBA добавили для прямого подключения SAS и SATA SSD: штатный RAID-контроллер в режим HBA перевести нельзя.

Базовое ПО и тестовые утилиты

Нам интересны не так отдельные диски, как системы хранения на их основе. Чтобы приблизить результаты тестов, пусть и синтетических, к реальным условиям, из каждой пары SSD cредствами Windows Server 2016 Storage Spaces создали программные RAID-массивы типа mirror.

Тестировали стандартной утилитой IOMeter, которая моделирует поведение приложений путем задания тестовых шаблонов. Как наиболее показательные для SSD, выбрали два из них: «сервер баз данных» (OLTP) и «сервер виртуальных рабочих столов» (VDI).

Тест «База данных»

Его стандартный шаблон

В шаблоне OLTP используется размер блока 8К. Поскольку базы данных могут работать с различными размерами блоков данных (например, SQL работает с блоком  64К), мы расширили диапазон до 4 … 64K.

Глубину очереди запросов ввода/вывода (Queue Depth, QD) меняли от 1 до 128 – чтобы охватить разную интенсивность нагрузок. Заодно посмотреть, как поведут себя при большой нагрузке SATA SSD, с максимальной длиной очереди команд QD=32 – как у всех SATA-устройств.

Тест VDI

Шаблон IOMeter под VDI:

Размер блока при реальной нагрузке изменяется между 512 байт и 1 мегабайт, но подавляющее большинство блоков - 4K. Таким размером и тестировали - IOMeter-е все равно не позволяет задавать смешанные размеры блоков.

Результаты тестирования. Тест «База данных»

Графики в осях IOPS/QD для всех трех типов SSD, при изменяемом размере блока данных.

На небольших нагрузках (QD=1…8) все трое ведут себя примерно одинаково. При QD=32 SATA «спекся», SAS замедлил рост, а NVMe продолжил почти линейный набор высоты и оторвался от обоих.

В серверах баз данных важнее не голая производительность в IOPS или МБ/с, а низкие задержки (latency, латентность), на которые SSD способны под нагрузкой. Результаты получены для cлабой (QD = 1) и интенсивной (QD= 128) нагрузки, с размером блока 4 – 8 – 64К.

Латентность при работе с блоками 64K почти в 15 раз превышает латентность при блоке 4K.

Сравнительное преимущество NVMe по уровню задержек хорошо видно на следующей диаграмме.

«Изменение латентности, ms (в %)» - это относительный перевес NVMe над оппонентами. Например, при QD=32 и блоке 64К задержки NVMe на 53% ниже, чем у SAS, и на 60% - чем у SATA. Производительность участников соотносится примерно так же.

Более высокая производительность NVMe не дается даром. При больших нагрузках расходуются дополнительные ресурсы процессоров и памяти. Это видно на графиках:

При одиночной нагрузке (QD=1) затраты процессора минимальны для всех устройств,  увеличение нагрузки (QD=128 и блок 4К) приводит к 40% утилизации процессоров при работе с NVMe. За все надо платить.

Результаты тестирования. Тест VDI

В предыдущем тесте преобладали операции чтения, в этом - операции записи (20R/80W).

SATA проигрывает оппонентам прямо со старта. SAS удерживает (правда, на малых нагрузках)  незначительный отрыв от NVMe (как видно из второго графика, при QD<16 задержки SAS и NVMe почти одинаковые), но с увеличением нагрузки (QD>16) картина резко меняется: SAS достигает своего потолка, а NVMe продолжает наращивать производительность.
Сравнительное преимущество NVMe по уровню задержек отражено на следующей диаграмме.

На одиночной нагрузке NVMe имеет на 10% меньшую латентность чем SAS и почти на 30% - чем SATA. На больших нагрузках отрыв еще сильнее: 40%  от SAS и 60% от SATA.
Какие же ресурсы процессоров потребовалось для такого типа нагрузки?

Как и в предыдущем тесте, при малых нагрузках утилизация процессоров составляет пару процентов, на больших нагрузках NVMe расходует до 45% ресурса процессоров. Проектируя сервер, об этом надо помнить.

Выводы

NVMe SSD подтвердили бесспорное превосходство над SAS SSD и SATA SSD, как в производительности, так и в латентности.

При условном делении нагрузки на три диапазона:

• слабая (QD=1…8)
• cредняя (QD=16…32)
• высокая (QD=64…128),

чем менее интенсивны запросы – тем меньше эффект от перехода на NVMe. К примеру, под нагрузкой VDI превосходство NVMe над SAS при коротких очередях запросов минимально, 12%. На больших очередях разрыв достигает 64%, а перевес над SATA - двух с лишним раз. В системах с пиковыми нагрузками (резким увеличением интенсивности запросов ввода/вывода) запас прочности по IOPS не помешает.

NVMe SSD особенно уместны там, где качество обслуживания привязано к параметру «максимальное время обработки запроса (латентность)». Предположим, время отклика системы хранения не должно превышать 2ms. Какое количество одновременных запросов можно обработать при определенном типе SSD? Размер блока ввода/вывода примем равным 64К – как в SQL.

В табличном выражении:

Получается, NVMe позволяет обслужить запросов в 2 раза больше, чем SAS SSD, и в 2.7 – чем SATA SSD. При это производительность в IOPs будет вдвое выше.

Препятствия широкому применению NVMe остаются:

• Для NVMe в формате HHHL PCIe никаких слотов расширения не напасешься, а для U.2 нужны платы-ретаймеры;
• Платформ U.2-ready мало и они, как правило, рассчитаны на установку 2-4 дисков;
• Диски U.2 нельзя объединить в аппаратный RAID (разработчики контроллеров планируют их выпуск до конца 2017-го года);
• Под них нет отказоустойчивых хранилищ (сами двухпортовые накопители U.2 есть, нет дисковых контейнеров на шине PCIe с дублированием путей);
• Крайне скудно предложение U.2 c повышенной устойчивостью к износу (интенсивные операции записи требуют DWPD 10+)

C выходом новых поколений серверных платформ эти ограничения уйдут, неизбежная популярность NVMe приведет к падению цен, а мы все станем более свободными в выборе инструментов.