Накопителя Intel DC S3700 100ГБ, а также тестирование массива RAID-0 на базе двух подобных накопителей, где размер Strip"а был выбран по умолчанию, то есть 128 КБ, но чипсет С226 позволяет изменять данный размер. В теории размер страйпа/полосы должен оказывать влияние на производительность массива - большой strip выгоден для последовательных операций, малый - при работе с маленькими файлами. Но это в теории, проверим это на практике.
RAID-контроллер Intel в чипсете С226 позволяет выбрать следующие размеры полосы: 4, 8, 16, 32, 64 и 128 КБ. Протестируем все возможные режимы.
Тестовый стенд: Intel Xeon E3-1276v3, Supermicro X10SAE, Kingston DDR3-1600 ECC 8GB, Intel DC S3700
Детализация
Процессор: (HT on; TB on);
- Материнская плата: ;
- Оперативная память: 4x (KVR16LE11/8);
- Накопители: 2x ;
- ОС: .
Методика тестирования
CrystalDiskMark v5.1 x64;
- ATTO Disk Benchmark v3.05;
- PCMark 7 v1.4;
- PCMark 8 v2.3.
CrystalDiskMark (500MB)
На последовательную запись без глубокой очереди размер strip"a не оказывает особого влияния - результаты находятся в рамках погрешности, а с последовательным чтением картина несколько иная: наиболее производительным оказываются массивы с размером страйпа 128 и 32 КБ, а наименее - 64 КБ. То есть для последовательных операций чтения всё-таки наиболее предпочтителен большой размер страйпа.
Операции с 4-килобайтными блоками без глубокой очереди не позволяют реализовать весь потенциал как отдельного накопителя, так и RAID-массива. Но главное здесь то, что на скорость записи размер страйпа имеет влияние - 16- и 64- килобайтные полосы показывают наихудшие результаты при чтении, а при записи худший результат за 8-килобайтной. Посмотрим как ситуация изменится с использованием очереди.
Использование очереди уровняло всех - ощутимой разницы между режимами нет: разница между самым быстрым (128 КБ) и самым медленным (8 КБ) режимами составила около 3,5% (что примечательно, наибольшую производительность при последовательных операциях показывает режим с большой полосой, а наименьшую - с малой).
А вот операции с 4-килобайтными блоками показывают иную картину - наибольшую производительность показывает массив с 8-килобайтным страйпом, а наименьшую - 128 (разница составила 5%), но... это касается лишь чтения, операции записи оказались равнодушными к размеру страйпа. То есть в операциях последовательного чтения выгодно смотрится большой размер strip, а в операциях с блоками 4КБ - малый размер strip.
ATTO Disk Benchmark
Бенчмарк ATTO более информативен - он показывает производительность на разных блоках. И здесь можно наблюдать резкие провалы производительности: наиболее стабильные кривые без резких провалов показывают режимы с 4- и 64- килобайтными полосами. Примечательно, что в области от 16 до 128 КБ 64-килобайтная полоса показывает меньшую производительность, чем 4-килобайтная, но отыгрывается после 256КБ.
График записи имеет немного другую зависимость - самым стабильным оказывается режим с 128-килобайтной полосой, который показывает лишь небольшой провал и лишь в области выше 32МБ.
PCMark 7
Бенчамарк PCMark 7 отдает предпочтение 4-килобайтной полосе. Причем данный бенчмарк эмулирует определенные сценарии работы... то есть является менее синтетическим, чем АТТО.
Основной вклад в победу малой полосы внесли сценарии starting applications и Windows Media Center. Но это RAW-результат...
Здесь ситуация в целом не меняется, разве что сами результаты стали на порядок меньше.
PCMark 8
PCMark 8 не заметил изменения параметров массива, уровняв всех в общем зачете. А замеренная пропускная способность отличается - наибольшая у 4-килобайтной полосы.
Заключение
Подводя итог... можно сказать, что в большинстве приложений, как ни странно, показал большую производительность массив с размером полосы 4 КБ. Но по большому счету разница не превысила 10%, то есть размер полосы нет такая уж и критичная величина. По крайней мере это можно сказать про сочетание чипсета C226 и двухдискового RAID-массива из накопителей Intel DC S3700 100 GB в выбранных бенчмарках.
Продолжение следует...
Остальные материалы по RAID-массивам на базе SSD - .
Данная статья подготовлена Николаем Ведяшкиным, экспертом Сервисного центра компании «Инфосистемы Джет».
Представим себе ситуацию: мы добавили на сервер базы данных новый instance БД или новое задание резервного копирования (РК), подключили дополнительный сервер к дисковому массиву и во всех этих случаях обнаружили снижение его производительности. Дальше можно пойти разными путями.
Например, добавить сервер БД и перенести на него экземпляр базы данных, добавить резервных накопителей для ускорения РК, сделать апгрейд процессоров и т.д. Однако стоит помнить, что простое наращивание аппаратных мощностей наименее выгодно с точки зрения материальных и временных затрат. Намного эффективнее решать такие проблемы на уровне логики работы ИТ-решений.
Причины пробуксовки
Проблемы с производительностью массива часто связаны с тем, что при изначальном конфигурировании не учитываются его архитектура, принципы функционирования и существующие ограничения. Например, ахиллесова пята массивов старого поколения – относительно невысокоая пропускная способность внутренних шин – около 200 Мб/сек. Не так давно один из заказчиков попросил нас проанализировать работу его дискового массива и дать рекомендации по оптимизации. По факту массив был не загружен, при этом его скорость периодически оставляла желать лучшего. Анализ выявил неправильную конфигурацию: в целом в течение суток внутренние диски были загружены примерно одинаково, но пики нагрузки распределялись по ним неравномерно. В итоге одна из внутренних шин перегружалась. То есть массив «буксовал» из-за превышения максимально допустимого порога у одной компоненты. Наша рекомендация – переразбить его для равномерной загрузки внутренних шин – помогла увеличить производительность на 30%.Ошибка может закрасться и при подключении серверов к СХД. Пример – неправильная конфигурация дисковой емкости, которая представляется хостам. Дело в том, что некоторые из современных массивов имеют ограничения по такому параметру, как очередь команд (Queue Depth, QD). Здесь стоит немного углубиться в историю. В стандарте SCSI-I SCSI-драйвер сервера должен был дождаться выполнения одной команды и только после этого отправлять следующую. Со стандарта SCSI-II и выше SCSI-драйвер может отправить SCSI-диску одновременно несколько команд (QD). Максимальное количество параллельно обслуживаемых SCSI-команд – одна из важнейших характеристик диска. Параметр IOPS (Input Output Operation per Second) показывает, сколько запросов (SCSI-команд) в секунду способен выполнить SCSI LUN. Получается, что QD и IOPS могут вступать в непримиримое противоречие друг с другом.
Вполне реальна ситуация, при которой характеристики ввода-вывода на стороне сервера неприемлемы, время отклика на запросы очень большое, а массив не нагружен. Причина кроется в – неправильной настройке очереди команд (выше допустимого) – команды зависают в буфере массива, пока не подойдёт их очередь на исполнение. На сервере же регистрируются большие service time.
Если же QD существенно ниже оптимального значения, производительность также будет хромать. При замечательном времени отклика и не загруженном массиве количество обрабатываемых им запросов будет очень маленьким. Виной всему – длительное ожидание в очереди перед отправкой запросов к СХД.
Ловим IOPS за хвост
Что предпринять, если время отклика зашкаливает, а массив не загружен? Или если просто хочется «выжать» из массива еще чуть-чуть?Можно:
- заглянуть в настройки Queue Depth на сервере и сравнить максимально допустимую очередь команд с LUN массива. Скорректировать настройки;
- посмотреть на статистику с массива. Возможно, на нем копится очередь команд к LUN;
- разбить один LUN на несколько и соединить на хосте в stripe или хотя бы в конкатенацию в зависимости от конфигурации. Конкатенация полезна в том случае, если нагрузка распределится по всем LUN.
- выбрать размер stripe unit size на массиве и хосте так, чтобы типичная операция со стороны приложения нагружала как можно меньше физических дисков в массиве.
Рис. 1. Stripe Unit Size
Пример из нашего опыта: связка «сервер–массив» у заказчика не показывала заявленный уровень производительности. В результате анализа выяснилось, что серверу был дан очень большой (на несколько терабайт) LUN – работа приложений была неудовлетворительной, а сам LUN был перегружен по очереди команд. Мы рекомендовали разбить этот LUN на несколько и разнести виды нагрузки на разные тома. На сервере «крутились» 4 instance баз данных, в итоге один из них начал работать в 6 раз быстрее, другой – в 2 раза.
Больше не значит лучше
ИТ-специалисты компаний-заказчиков не всегда понимают, какой тип RAID лучше подходит для того или иного профиля нагрузки со стороны приложений. Всем известно, что RAID 10 надежен, устойчив к потере нескольких дисков и показывает хорошую скорость на случайных операциях. Не удивительно, что чаще всего выбирают именно этот, весьма дорогостоящий вариант. Однако если профиль нагрузки приложения подразумевает мало операций случайной записи и много операций чтения или последовательной записи, оптимальнее использовать RAID 5. На том же количестве дисков он может работать в 1,5, а то и в 2 раза быстрее. Одна компания обратилась к нам с просьбой улучшить характеристики дискового ввода/ввода для одного из ее приложений. Приложение создавало много операций чтения и незначительное количество операций записи. На массиве был сконфигурирован RAID 10, а из статистики было видно, что практически половина дисков в RAID-группе простаивает. С переходом на RAID 5 из точно такого же количества физических дисков работа приложения улучшить более чем в 1,5 раза.Мы будем рады вашим конструктивным комментариям.
Проблемы производительности затрагивают практически каждую компанию, эксплуатирующую вычислительный комплекс. Приведённые здесь примеры не единственные. Множества проблем, связанных с неудовлетворительной работой массивов, можно избежать, если при конфигурировании оборудования учитывать его архитектуру и профиль нагрузки приложений. В то же время улучшение работы вычислительного комплекса не должно замыкаться на каком-то одном его компоненте – сервере, массиве, ПО или сети передачи данных. Наилучших результатов можно достичь после проведения анализа всего комплекса в целом и изменения конфигурации не только массива, но и сервера и приложений.
