Pull to refresh

Оценка влияния уровней Сache на производительность ввода/вывода в EMC VNX5400

Reading time 10 min
Views 5.5K

Введение


После тестирования и написания статьи о влиянии механизмов кэширования на производительность в младшей модели (entry level) СХД EMC VNXe3200, периодически начали чесаться руки проделать то же самое с ее старшими собратьями массивами VNX2. Недавно такая возможность представилась. Удалось прогонять тесты на VNX5400. Кроме того, помимо тестирования непосредственно VNX5400, получилось потестировать еще и решение EMC ExtremCache (PCI-E SSD карточка EMC XtremSF700 на eMLC чипах + софт EMC XtremSW). Но про EMC ExtremCache будет следующая статья. Пока же поговорим про массивы VNX2.

Линейку своих систем хранения среднего уровня (midrange level) компания EMC2 обновила осенью 2013 года. Массивы VNX второго поколения (VNX2) выглядели, на мой взгляд, как хорошо проделанная работа над ошибками, допущенными в первом поколении VNX (VNX1). Вендор же преподносил их как кардинальное и инновационное обновление midrenge линейки. Тем не менее сейчас, более чем через год после того как они появились на рынке, VNX2 все еще не потеряли своей актуальности. На характеристиках и возможностях самих массивов подробно останавливаться не буду, просто дам ссылки на официальные документы Data Sheet и Spec Sheet.

Описание стенда и тестов


Под спойлером
Тестирование проводилось при помощи IOMETER. Профиль нагрузки тот же самый, что и при тестировании VNXe3200. Cтандартный Database pattern (Intel/StorageReview.com).



В наличии был сервер HP DL360 G5 c 1 CPU (4-core) и ОЗУ 4GB. В сервере 2 слота PCI-E. В один из слотов была поставлена двухпортовая HBA Qlogic 4Gb/s, подключенная напрямую в VNX5400. Так как физических ядер в CPU сильно меньше чем было при тестировании VNXe3200, то пришлось изначально увеличивать число потоков ввода/вывода на каждый Worker IOMETER-а. Соотношение 1 Worker на 1 ядро CPU. На каждый Worker было выставлено изначально по 3 потока I/O c «множителем» 2. Т.е. каждый последующий прогон (15 мин) теста в цикле увеличивал количество потоков в 2 раза. Всего 5 последовательных прогонов и соответственно на Worker по 3/6/12/24/48 потоков IO. В целом на тестируемый файл получалось 12/24/48/96/192 потока. Т.е. максимум тот же, что был для VNXe3200. Время каждого теста 15x5=75 минут, не считая «Rump up time». Настройки в IOMETER при этом выглядят следующим образом.



На VNX5400 уже имелся дисковый FastVP пул с лунами на которых были установлены OS, поэтому мудрить и создавать все заново я не стал. В пул были включены 3-и 100Gb SSD диска (Extreme Perfomance Tier) и 15-ть 900Gb SAS 10K RPM дисков в Raid5 4+1 (Perfomance tier), т.е. 3 приватные (не видимые пользователю) Raid Groups в конфигурации 4+1. На пуле были созданы тестовые луны с политикой «Lowest Available Tier», для того что бы эти луны целиком разместились на SAS дисках и SSD диски из Extreme Perfomance Tier не влияли на результаты.





На сервере использовалась OS Win2012R2 SP1 и софт для управления путями доступа к лунам PowerPath от компании EMC2.

Немного расчетов.


EMC2 при расчетах производительности рекомендует для SAS 10k RPM дисков использовать значение в 150 IOPS (FC/SAS 15k RPM — 180 IOPS, SATA/NL_SAS — 90 IOPS, SSD eMLS — 3500 IOPS, SSD SLC — 5000 IOPS). То есть максимально в теории наши 15 дисков могут выдать 150х15=2250 IOPS. Нам необходимо посчитать сколько IOPS получат с этих дисков сервера, с учетом нашего профиля нагрузки чтение/запись в процентном соотношении 67/33 и накладных расходов на запись в RAID5. Получаем следующее уравнение с одной неизвестной 2250=X*0.33*4+X*0.67. Где X это у нас те IOPS, которые получат сервера с наших дисков, а 4 — это размер «пенальти» на запись для Raid5. В итоге получаем X=2250/1.99= ~1130 IOPS. Напомню, что на практике в пиковых нагрузках получаем обычно по IOPS цифры в 1,5-2 раза выше. То есть при правильном распределении данных по всем трем приватным Raid5 группам дисков можем рассчитывать на диапазон 1695-2260 IOPS.

Тесты и Результаты


1. Тест работы Cache контроллеров (SP — storage processor) VNX5400 файлом 2Gb


Данный тест проводился на файле размером 2GB (размер тестового LUN с NTFS — 10 Gb), из расчета что он полностью поместиться в SP Cache и в итоге весь ввод/вывод будет отрабатываться из оперативной памяти контроллеров СХД. То есть условно на массиве возникла небольшая «горячая» область данных. При этом FastCache на массиве был выключен.
В результате получили следующий график во встроенном в массив Unisphere Analyzer.



При этом SP Cache заполнялся следующим образом (cache работает как на чтение, так и на запись):



То есть в течении нескольких минут после начала теста все 2Gb тестового файла были загружены в Cache.

График зависимости средних значений IOPS от количества потоков ввода/вывода по результатам в IOMETER:



График зависимости средних значений времени отклика ввода/вывода от от количества потоков ввода/вывода по результатам в IOMETER:



Напоминаю, что принято считать комфортным значение среднего времени отклика для баз данных до 10 ms. По графику видно, что при 192 потоках IO, что является достаточно большим значением, мы получили чуть меньшее среднее время отклика чем в аналогичном тесте на VNXe3200 (было 8 ms). В абсолютных величинах разница не значительна, но тем не менее является одной из причин большого разрыва по количеству IOPS. У VNXe3200 было в среднем порядка 23800 IOPS на 192 потоках IO в аналогичном тесте. Если посчитать разницу в процентах для времени отклика и для IOPS получим и там и там примерно те же 20-25%.

2. Тест работы Cache контроллеров (SP — storage processor) VNX5400 файлом 15Gb


Тест проводился на файле размером 15GB (LUN c NTFS — 20Gb). FastCache по прежнему выключен. Размер оперативной памяти в SP в VNX5400 составляет 16 Gb. Но если опираться на логи с массива, то реально используемый под кэширование объем ОЗУ составляет порядка 4Gb для VNX5400. Все остальное видимо используется для обеспечения работы самой базовой OS контроллеров и другого, достаточно широкого, функционала СХД (tiering, thin provisioning, snapshots, clone, replication, fast cache и т.д.).



Таким образом наши 15 Gb высоко нагруженных (горячих) данных никак не поместятся в SP Cache. В целом именно это и видно на графике из Unisphere Analizer. Полностью рандомный ввод/вывод по всем 15 Gb не может быть полностью закэширован контроллерами, по-этому в данном тесте основной объем производительности дают физические шпиндели, т.е. непосредственно диски.



При этом SP Cache продолжает работать, хоть и не столь эффективно.



График зависимости средних значений IOPS от количества потоков ввода/вывода по результатам в IOMETER:



График зависимости средних значений времени отклика ввода/вывода от от количества потоков ввода/вывода по результатам в IOMETER:



По графику видно, что время отклика уже на 24 потоках составляет порядка 14 мс, т.е. вышло за комфортную зону. Еще меня удивило, что я так сильно промахнулся с оценкой пиковой дисковой производительности и я «пошел» разбираться. В итоге выяснил, что при проведении теста нагрузка не на все приватные RG в Perfomance Tier одинакова. Т.е. исходя из соображений производительности наш тестовый файл неравномерно распределился по всем 3-ём RG в Performance Tier. На графике это выглядит следующим образом (диски 5, 6 и 7 это SSD из Extreme Perfomance Tier).



То есть не все 15 шпинделей были задействованы при тесте «на полную». Что бы сгладить подобный эффект в FastVP пулах на массивах VNX2 есть технология, которая позволяет перераспределять «горячие» и «холодные» данные не только между дисками с разной производительностью (SSD, SAS, NL_SAS), но и между приватными RG в пределах одного Tier. Перераспределение данных между приватными RG происходит в то же время по расписанию, что и миграция данных между Tier-ами. В интерфейсе массива это можно увидеть в свойствах пула на вкладке «Tiering». В частности в моем случае сразу после теста это выглядело следующим образом.



Напомню, когда массив простаивал, то окно выглядело вот так.



Еще одну интересную картинку можно увидеть наложив друг на друга графики заполнения SP Cache и общей производительности тестируемого LUN.



По графику видно, что даже в достаточно неприятной ситуации, SP Cache позволяет выигрывать «дополнительные» IOPS.

3. Тест работы FastCache в VNX5400 файлом 15Gb


После включения FastCache на массиве (два SSD 100Gb в Raid1) был проведен тест на том же самом файле в 15Gb (LUN c NTFS — 20Gb). FastCache в массивах компании EMC2 — это дополнительный уровень кэширования на базе SSD дисков, который встраивается между SP Cache и непосредственно дисками массива. Файл в 15Gb (или условно «горячая» область данных) должна полностью поместиться в FastCache размером 100Gb, что должно улучшить результаты предыдущего теста.
Получили следующий график из Unisphere Analizer (в IOPS).



FastCache заполнялся следующим образом (в %).



Read Hits/s — операции чтения, которые отрабатывались из FastCache.
Read Misses/s — операции, данные для которых не были найдены в FastCache и были запрошены с дисков массива.



Write Hits/s — операции записи в FastCache, которые не требовали предварительного сброса «устаревших» данных на диски (предварительной очистки места в кэш), либо операции, которые запрашивали данные, записанные в кэш, но еще не перемещенные на диски.
Write Misses/s — операции записи не отработанные через FastCache или требующие принудительного (экстренного) освобождения места в кэше.



SP Cache тоже не простаивал и отрабатывал часть ввода/вывода.



Со стороны сервера в IOMETR все выглядело следующим образом.
График зависимости средних значений IOPS от количества потоков ввода/вывода по результатам в IOMETER:



График зависимости средних значений времени отклика ввода/вывода от от количества потоков ввода/вывода по результатам в IOMETER:



По последнему графику видно, что после загрузки «горячей» области в FastCache, время отклика даже снижается и начинает расти только по мере увеличения потоков ввода/вывода. При этом график «пробивает» потолок в 10 ms далеко за значением в 100 потоков IO.

4. Тест работы FastCache в VNX5400 файлом 150Gb


Следующий тест проводился на файле размером 150Gb (Тестовый LUN c NTFS 200Gb). Т.е. наша «горячая» область данных в данном тесте превышала размер FastCache на массиве примерно в 1,5 раза. Получены были следующие результаты.
График из Unisphere Analizer (в IOPS).



Заполнение FastCache данными шло, но достаточно медленно. К концу 75 минутного теста заполнено было около 20% (условно около 20Gb из 150Gb тестового файла).



Графики попаданий и не попаданий операций чтения в FastCache.



Графики hits/s и misses/s для операций записи в FastCache.



SP Cache тоже не простаивал.



Как это выглядело со стороны сервера и IOMETR.
График зависимости средних значений IOPS от количества потоков ввода/вывода по результатам в IOMETER:



График зависимости средних значений времени отклика ввода/вывода от от количества потоков ввода/вывода по результатам в IOMETER:



По графикам видно, что значения IOPS несколько выше, чем были при тестировании файла размером в 15Gb без FastCache. Значит можно было бы сделать вывод, что и в данной неудобной ситуации FastCache помогает выжать дополнительные IOPS из конфигурации. Но на практике все оказалось не совсем так.

Во первых в данном тесте все приватные Raid Group (Raid5 4+1) в «Perfomance Tier» были нагружены более равномерно.



Во вторых я решил провести дополнительный тест с файлом в 150Gb, но выключенным FastCache. Подробно расписывать его я не буду, вот графики из IOMETR (я не поверил сначала и провел тест дважды).

График зависимости средних значений IOPS от количества потоков ввода/вывода по результатам в IOMETER:



График зависимости средних значений времени отклика ввода/вывода от от количества потоков ввода/вывода по результатам в IOMETER:



То есть в ситуации, когда объем горячих данных превышает размер FastCache и при высоком проценте случайных запросов, заполнение FastCache требует некоторого времени. В таких ситуациях FastCache вносит, пусть небольшую, но тем не менее дополнительную задержку в Response time. В данной ситуации можно предложить использовать в пуле дополнительный Extreme Perfomance Tier на SSD дисках. Часть горячих данных в таком случае «поселится» на нем и не будет отрабатываться через FastCache. Соответственно объем горячих данных, отрабатываемых через FastCache уменьшится и будет находиться в более комфортном диапазоне. Что бы не быть голословным я провел еще один тест.

5. Тест работы FastCache в VNX5400 файлом 80Gb


Данный тест проводился на файле размером 80Gb (Тестовый LUN c NTFS 100Gb), что достаточно близко к объему FastCache в тестируемом массиве. То есть «горячая» область данных была достаточно большой, но тем не менее полностью помещалась в FastCache.
График из Unisphere Analizer (в IOPS).



FastCache заполнялся более активно чем на файле в 150Gb.



SP Cache так же отрабатывал часть ввода/вывода.



Со стороны сервера и IOMETR все выглядело то же гораздо более радужно чем на файле в 150Gb.
График зависимости средних значений IOPS от количества потоков ввода/вывода по результатам в IOMETER:



График зависимости средних значений времени отклика ввода/вывода от от количества потоков ввода/вывода по результатам в IOMETER:



Начиная примерно с 24 потоков IO (около 15 минут от начала теста) данные начали все больше попадать в FastCache. Соответственно общая производительность в тесте начала так же расти, при этом время отклика, по мере увеличения потоков IO, росло не так значительно как в тесте с файлом на 150Gb.

Небольшое отступление про дисковые пулы


Под спойлером
При проектировании диского пула, если вы не знаете реальные размеры области «горячих» и «теплых» данных, то EMC рекомендует придерживаться следующих пропорций для трехуровнего пула:
10% — SSD диски
20% — SAS диски
70% — NL-SAS диски
Кроме того нужно учитывать, что при добавлении flash tier в пул автоматически все метаданные thin лунов, созданных на пуле, будут размещены на SSD. Если там хватает для них места. Это позволяет поднять общую производительность thin лунов и пула. Под эти метаданные нужно планировать дополнительно место на SSD из расчета 3Gb объема на каждый 1Tb реально занятый тонкими лунами на пуле. При всем этом луны имеющие политику тиринга «highest available tier» будут иметь приоритет при размещении на SSD-тире перед любыми другими данными.

Использование политики «lowest available tier» для thin, deduplicated, или compressed лунов приводит к размещению их метаданных на самых медленных дисках. Что негативно сказывается на производительности данных лунов.

Для корректной работы тиринга нужно свободное пространство в пуле. Рекомендуется не менее 10% свободного места на каждом тире. Иначе система не сможет «перекладывать» куски (чанки) данных между разными типами дисков в пуле.


Выводы


Опираясь на проведенные тесты можно сказать следующее. Как бы это странно не звучало, но FastCache — это не всегда хорошо. В неправильно спроектированной системе он может влиять на производительность, в том числе и в сторону ухудшения. Для того что бы не промахнуться на стадии проектирования, лучше погонять копию или часть своих реальных нагрузок на демо массиве. Демо массив может быть запрошен у вендора. Если такой возможности нет, то нужно исходить из тех соотношений горячих/теплых/холодных данных, которые предлагает использовать все тот же вендор при расчетах (исходя из статистических данных и каких то своих соображений). Первый вариант с демо массивом, на мой взгляд, предпочтительнее. В целом, на правильно спроектированном массиве, дополнительный уровень кеширования (FastCache) на VNX2 дает приличный прирост производительности.

Производительность VNX5400, не сильно превосходит производительность VNXe3200, как минимум в небольших и сравнимых конфигурациях (количество дисков, размер FastCасhe). Возможно это связано с тем, что младший массив вышел только в этом 2014 году. Эти же выводы можно применить и для VNX5200, у которой SP (контроллеры) ничем от не отличаются VNX5400 (сервисный партномер для замены одинаковый). VNX5200 имеет только ограничение на максимальное количество дисков (125 шт. против 250 шт. у VNX5400), ограничение на максимальный размер FastCache (600Gb против 1000Gb у VNX5400) и имеет на один слот меньше под дополнительный платы расширения с портами для подключения серверов.

Все проведенные тесты это «синтетика», не имеющая ни какого отношения к вашим реальным нагрузкам. Однако, на мой взгляд, подобное моделирование помогает понять общие тенденции поведения СХД в тех или иных ситуациях.

Как P.S.


В случае если вам нужна СХД под потоковую нагрузку (Н-р: запись и обработка больших видеопотоков), то никакой кэш вам тут не поможет. Настанет момент когда он переполниться и решать в данной ситуации будет количество шпинделей (дисков) в вашей системе хранения данных.
Если у вас очень высокая транзакционная нагрузка. Большая OLTP база данных или VDI на тысячи или десятки тысяч пользователей, то вам скорее нужен all flash array, а не классическая СХД и Tiering.
Tags:
Hubs:
+3
Comments 2
Comments Comments 2

Articles