IBM DS4700-70 проверка скорости работы КЭШа системы

Понятно что в любой дисковой системе, скорость работы КЭШа системы намного выше чем скорость работы дисков в этой системе. Обычно характеристик производительности дисковой системы в IOPS указываемые изготовителем в маркетинговых документов соответствуют скорости работы системы при максимально выгодной для неё нагрузке, чаще всего это последовательное чтение при удобном размере блока, близкого к размеру блока КЭШ памяти.

В информации по IBM DS 4700-70 заявленная производительность 112 000 IOPS, это я и попробую проверить в тестах. Также я буду смотреть на общее поведение системы при работе только на КЭШе.

Для такой задачи сперва было необходимо найти способ заставить систему работать только из КЭШ памяти. Как это было сделано я опишу ниже. Сначала несколько слов про схему кэш памяти в контроллере: в системе на каждый контроллер приходится по 1ГБ КЭШ памяти. По умолчанию используется полное зеркалирование КЭШ памяти контроллеров между собой, это необходимо для того чтобы в случае отказа одного контроллера система смогла переключить нагрузку на второй при этом не потеряв данные из КЭШа потерянного контроллера. У КЭШа есть две глобальные характеристики задающиеся на уровне всей системы: размер блока КЭШа и политика сброса содержимого КЭШа на диск.

Размер блока КЭШ памяти

Может выставляться значениями 4, 8, 16 кб. По умолчанию стоит по-моему 8кб. Я делал тест около полугода назад, проверяя отличия в производительности при разных значениях, у меня получилось что наилучшая скорость получается на блоке 16кб, независимо от типа нагрузки на систему. Посему в этот раз я тоже выставлю блок 16кб. Вполне вероятно, что в перспективе стоит попробовать уменьшить размер блока КЭШ и повторить тоже самое на 8кб.

Политика сброса КЭШа на диск

Когда размер данных в КЭШе превышает определенный порог он автоматически начинает скидываться на диск, пока не освободиться достаточно места в КЭШе. Эти два порога задаются в настройках системы. Если применить эти настройки к тестовой системе то это выглядит так: в ней 1ГБ КЭШ в каждом контроллере, 512МБ доступно для данных после вычета половины для зеркала.

Политика сброса КЭШ в тестовом случае выглядит так: начать сброс на диск – 95%; окончить сброс КЭШа на диск – 90%. Получается, что при заполнении 486МБ (95% от 512МБ) система начнет переписывать содержимое КЭШ на диск пока не останется заполненным 460МБ (90% от 512МБ) после этого система остановит переписывание и будет ждать того когда КЭШ опять заполнится до 486МБ.

В тестовой системе политика сброса КЭШ выбрана как описано выше, чтобы при маленьком LUN (для тестов делался LUN размером 200МБ) он мог быть полностью размещен в КЭШ и верхний порог для сброса КЭШ на диск был бы не достижим.

И еще надо уточнить один момент, в системе на политику сброса описанную выше накладывается еще политика сброса содержимого КЭШа по расписанию, с заданной частотой. Поскольку в тестовом случае это только мешает (мне было нужно свести влияние дисков к нулю) я отключил сброс КЭШа на диск по расписанию. Это делается через CLI следующей командой:

set logicalDrive ["lun2"] cacheFlushModifier= infinite ;

Такую процедуру я выполнил на обоих тестовых LUN.

Условия теста

На системе был создан массив из одного диска FC 15k 146GB, один диск выбрался специально, чтобы увидеть резкое понижение производительности если вдруг система начнет работать не через КЭШ а через диск. По большому счету тест планируется диского независимый поэтому количество значения не имеет. На массиве делалось два LUN по 200МБ, на них включался весь КЭШ, отключалось скидывание КЭШа на диск (см выше) и они назначались на разные контроллеры дисковой системы. Затем брался IOmeter и ставилась нагрузка, резульаты которой и записывались.

 
Настройки LUN.

 

 
Подключение дисковой системы к серверу.

 

Результаты

Чтение

 
Последовательное

Случайное

В обоих случаях на маленьком блоке цифры колеблются в районе 100 000 IOPS, случайность чтения оказывает минимальное влияние. Спад IOPS в районе 4кб блока вызван тем что сервер с нагрузкой подключен через один порт HBA, скорость у него 4ГБ. В данном случае меня это не напрягает, поскольку все цифры выше 4кб, превышают 400МБ/сек а это очень много. Поскольку график не падает, видно что система ведет себя отлично.

Надо отметить, что здесь показаны средние цифры за 5 минут работы, после проведения тестов внутренний монитор дисковой системы показал что максимальная скорость в IOPS составляла около 116 000 IOPS, то есть обещанная производителем скорость в 112 000 достигнута.

Запись

 
Последовательная запись на одном диске

 
Последовательная запись на двух дисках

При последовательной записи картина похожая на ожидаемую, с той лишь оговоркой, что скорость снижается на большом блоке. Я стал думать почему так и пришел к выводу, что это связанно с количеством дисков в массиве. Все же скорость около 100МБ/сек очень напоминает скорость одного диска.

Специально для того чтобы можно было понять влияние дисков на запись в кэш, был проведен второй тест, в котором в массив был добавлен еще один диск (то есть массив стал состоять из двух дисков) и проведена такая же нагрузка. На нижнем графике видно, что динамика полностью прежняя, тогда как скорость на большом блоке поднялась примерно в два раза. Поскольку в системе изменилось только количество дисков, из этого прямо следует, что алгоритмы кэширования последовательной записи связаны с физическими дисками в системе и даже имея тестовый лун объемом меньше чем доступный КЭШ и отключив сброс на диск, система все равно будет писать IO в диски, при последовательной записи.

Очень интересно что порог перехода записи в диск разный в массивах из одного и из двух дисков. Видимо система имеет заложенный алгоритм который определяет когда начинать писать КЭШ в диск исходя из критериев: какие диски включены в массив и какого объема, какой размер блока, какова последовательность нагрузки.

Логика прослеживается абсолютно четкая – если мы пишем последовательно и блоком большого объема, то диск не будет здесь узким местом, он себя должен показать лучше, чем КЭШ. Это дает максимальные результаты в нормальных средах на реальной нагрузке, все же LUN объемом 200МБ на который последовательно пишут 45ГБ за 5 минут в реальности не будет существовать.

 

После этого было проведено еще два теста: в одном проводилась последовательная запись на массив расширенный до 16 дисков, а во втором случайная запись в тех же условиях. Конфигурация LUN оставалась прежней.

 
Последовательная запись на 16 дисков

 
Случайная запись на 16 дисков

Динамика последовательной записи несколько сгладилась, что еще раз показало что система работает тем лучше, чем больше дисков в массиве. Системы кэширования не могут работать полностью независимо от дисков.

Поведение случайной записи получается существенно ниже чем последовательной, таким образом можно сказать что система кэширования при случайной записи наибольшим образом зависит от дисков, независимо от реального объема данных. Это сказывается даже на том, что при последовательной записи система больше ориентируется на КЭШ и в результате не достигает возможного потолка (в нашем случае 400 мб/сек), а при случайной записи система независимо от реального объема данных активно пишет их на диск и даже при полностью случайном характере нагрузки достигает потолка в 400мб/сек.

Выводы

1. Ну и собственно идеи о том, что было бы круто разместить все данные в КЭШ памяти и писать/читать из неё меня покинули, абсолютно очевидно что для последовательной записи объем КЭШа не будет играть большой роли и для достижения максимальных результатов не будет требоваться. Для случайной записи он играет еще меньшую роль.

Нужно добавить, что в ходе тестов было сделано несколько прицельных прогонов в которых я отключал зеркалирование КЭШ чтобы сориентироваться насколько это будет сильно влиять на производительность. Так вот влияние было порядка 2-3%, таким образом ответ на вопрос “снижает ли зеркалирование производительность?” – отрицательный. По результатам же этого теста можно сказать, что при нагрузках преимущественно записи длительное время, размер КЭШ не будет выполнять ключевую роль для общей производительности. Также нужно не забывать, что отключая зераклирование КЭШа мы теряем отказоустойчивость системы.

2. Система показала свою полную адекватность с точки зрения максимальной производительности работы из КЭШа, цифры заявлены в маркетинге – получены, остальные результаты выглядят реалистично.

 

Ну и в результате интересно посмотреть в подобном тесте влияние настроек блока КЭШа системы, в максимально нагружающей его конфигурации – 2 LUN по 200МБ на 16 дисках.