Введение После тестирования и написания статьи о влиянии механизмов кэширования на производительность в СХД EMC начального уровня.
VNXe3200 , периодически у меня чесались руки сделать то же самое со старшими братьями, массивами VNX2. Недавно такая возможность представилась.
Нам удалось провести тесты на VNX5400. Кроме того, помимо непосредственного тестирования VNX5400, нам также удалось протестировать решение EMC ExtremCache (PCI-E SSD-карта EMC XtremSF700 на чипах eMLC + программное обеспечение EMC XtremSW).
Но следующая статья будет про EMC ExtremCache. А пока поговорим о массивах VNX2. Линейка систем хранения данных среднего уровня EMC 2 обновлено осенью 2013 года.
Массивы VNX второго поколения (VNX2) показались мне хорошо выполненной работой по исправлению ошибок, допущенных в VNX первого поколения (VNX1).
Производитель представил их как радикальное и инновационное обновление линейки среднего класса.
Однако и сейчас, спустя более года после появления на рынке, VNX2 все еще не потеряли своей актуальности.
Я не буду подробно останавливаться на характеристиках и возможностях самих массивов, просто приведу ссылки на официальные документы.
Техническая спецификация И Спецификация .
Описание стенда и испытаний
Под спойлером Тестирование проводилось с помощью IOMETER. Профиль нагрузки такой же, как и во время тестирования.VNXe3200 .
Стандартный шаблон базы данных (Intel/StorageReview.com).
У нас был сервер HP DL360 G5 с 1 процессором (4-ядерным) и 4 ГБ оперативной памяти.
Сервер имеет 2 слота PCI-E. В один из слотов был установлен двухпортовый HBA Qlogic 4 Гбит/с, подключенный напрямую к VNX5400. Поскольку физических ядер в ЦП гораздо меньше, чем было при тестировании VNXe3200, нам пришлось изначально увеличить количество потоков ввода-вывода на каждый рабочий процесс IOMETER. Соотношение составляет 1 Worker на 1 ядро ЦП.
Каждый Worker изначально был настроен на 3 потока ввода-вывода с «множителем» 2. То есть.
Каждый последующий запуск (15 мин) теста в цикле увеличивал количество потоков в 2 раза.
Итого 5 последовательных запусков и соответственно 3/6/12/24/48 потоков IO на Worker. В целом тестируемый файл получил 12/24/48/96/192 потока.
Те.
максимум такой же, как и для VNXe3200. Время каждого теста 15х5=75 минут, не считая «Время разгона».
Настройки в IOMETER выглядят так: 
В VNX5400 уже был пул дисков FastVP с лунами, на которых была установлена ОС, поэтому я не стал создавать все заново.
В пул вошли 3 SSD-диска по 100 Гбит (Extreme Performance Tier) и 15 дисков SAS по 900 Гбит/с со скоростью вращения 10 000 об/мин в Raid5 4+1 (уровень Performance), т.е.
3 частных (невидимых пользователю) Raid-группы в конфигурации 4+1. В пуле были созданы тестовые луны с политикой «Lowest Available Tier», чтобы эти луны полностью располагались на SAS-дисках, а SSD-диски из Extreme Performance Tier не влияли на результаты.
На сервере использовалась ОС Win2012R2 SP1 и программное обеспечение для управления путями доступа к лунам PowerPath от EMC. 2 .
Несколько расчетов.
ЭМС 2 При расчете производительности рекомендуется использовать значение 150 IOPS для дисков SAS 10 тыс.
об/мин (FC/SAS 15 тыс.
об/мин — 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 - процессора хранения) VNX5400 с файлом 2Гб
Данный тест проводился на файле размером 2Гб (размер тестового LUN с NTFS 10Гб), исходя из предположения, что он полностью поместится в SP Cache и в результате все операции ввода-вывода будут обрабатываться из ОЗУ контроллеров хранения.То есть на массиве возникла небольшая «горячая» область данных.
При этом FastCache на массиве был отключен.
В результате мы получили следующий график во встроенном в массив анализаторе Unisphere. 
В данном случае SP Cache заполнялся следующим образом (кэш работает как на чтение, так и на запись): 
То есть в течение нескольких минут после начала теста все 2Гб тестового файла были загружены в Cache.
График зависимости средних значений IOPS от количества потоков ввода-вывода по результатам в IOMETER: 
График зависимости среднего времени ответа ввода-вывода от количества потоков ввода-вывода на основе результатов в IOMETER: 
Напомню, комфортным считается среднее время отклика баз данных до 10 мс.
На графике видно, что при 192 потоках ввода-вывода, что является достаточно большим значением, мы получили несколько меньшее среднее время отклика, чем в аналогичном тесте на VNXe3200 (оно составило 8 мс).
В абсолютном выражении разница незначительна, но тем не менее она является одной из причин большого разрыва в количестве IOPS. В аналогичном тесте VNXe3200 в среднем показал около 23 800 операций ввода-вывода в секунду при 192 потоках ввода-вывода.
Если посчитать разницу в процентах по времени отклика и по IOPS, то получим примерно одинаковые 20-25% в обоих случаях.
2. Тест работы контроллеров Cache (SP - процессора хранения) VNX5400 с файлом 15Gb
Тест проводился на файле 15Гб (LUN с NTFS - 20Гб).FastCache по-прежнему отключен.
Размер оперативной памяти в SP в VNX5400 составляет 16 Гб.
Но если опираться на логи из массива, то объем оперативной памяти, реально используемый для кэширования, составляет около 4Gb для VNX5400. Все остальное, судя по всему, используется для обеспечения работы самых базовых контроллеров ОС и другого достаточно широкого функционала хранилища (tiering, Thin Provisioning, снапшоты, клонирование, репликация, быстрый кэш и т.д.).
Таким образом, наши 15 Гб высоконагруженных (горячих) данных не поместятся в SP Cache. В общем, именно это и видно на графике из Unisphere Analyser. Полностью произвольный ввод-вывод по всем 15 Гб не может быть полностью кэширован контроллерами, поэтому в этом тесте основная часть производительности обеспечивается физическими шпинделями, т.е.
непосредственно дисками.
При этом SP Cache продолжает работать, хотя и не так эффективно.
График зависимости средних значений IOPS от количества потоков ввода-вывода по результатам в IOMETER: 
График зависимости среднего времени ответа ввода-вывода от количества потоков ввода-вывода на основе результатов в IOMETER: 
На графике видно, что время отклика уже на 24 потоках составляет около 14 мс, т.е.
вышло за зону комфорта.
Еще я был удивлён, что так сильно промахнулся с оценкой пиковой производительности диска, поэтому «пошёл» разбираться.
В результате я выяснил, что во время теста нагрузка на не все частные RG в Performance Tier одинакова.
Те.
Из соображений производительности наш тестовый файл был неравномерно распределен по всем третьим RG на уровне производительности.
На графике это выглядит так (диски 5, 6 и 7 — SSD из Extreme Performance Tier).
То есть во время теста не все 15 шпинделей были задействованы «на полную катушку».
Чтобы сгладить этот эффект, в пулах FastVP на массивах VNX2 реализована технология, позволяющая перераспределять «горячие» и «холодные» данные не только между дисками с разной производительностью (SSD, SAS, NL_SAS), но и между частными RG внутри одного Уровень.
Перераспределение данных между частными RG происходит одновременно по расписанию с миграцией данных между Tier. В интерфейсе массива это можно увидеть в свойствах пула на вкладке «Tiering».
В частности, в моем случае сразу после теста это выглядело так.
Напомню, что когда массив простаивал, окно выглядело вот так.
Еще одну интересную картину можно увидеть, если наложить графики заполнения SP Cache и общей производительности тестируемого LUN. 
На графике видно, что даже в довольно неприятной ситуации SP Cache позволяет выиграть «дополнительные» IOPS.
3. Тест работы FastCache в VNX5400 с файлом размером 15Гб.
После включения FastCache на массиве (два SSD по 100Гб в Raid1) был проведен тест на том же файле 15Гб (LUN с NTFS - 20Гб).
FastCache в массивах EMC 2 — это дополнительный уровень кэширования на основе SSD-дисков, который выстраивается между SP Cache и самими дисками массива.
Файл размером 15Гб (или условно «горячая» область данных) должен полностью уместиться в 100Гб FastCache, что должно улучшить результаты предыдущего теста.
Мы получили следующий график от Unisphere Analyser (в 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 мс далеко за пределы значения в 100 потоков ввода-вывода.
4. Тест работы FastCache в VNX5400 с файлом размером 150Гб.
Следующий тест проводился с файлом размером 150Гб (Тестовый LUN с NTFS 200Гб).
Те.
наша «горячая» область данных в этом тесте превышала размер FastCache на массиве примерно в 1,5 раза.
Были получены следующие результаты.
График из Unisphere Analyser (в IOPS).
FastCache заполнялся данными, но довольно медленно.
К концу 75-минутного теста было заполнено около 20% (относительно около 20Гб из тестового файла в 150Гб).
Графики попаданий и промахов операций чтения в FastCache. 
Графики попаданий и промахов для записи в FastCache. 
SP Cache тоже не простаивал.
Как это выглядело с сервера и IOMETR.
График зависимости средних значений IOPS от количества потоков ввода-вывода по результатам в IOMETER: 
График зависимости среднего времени ответа ввода-вывода от количества потоков ввода-вывода на основе результатов в IOMETER: 
На графиках видно, что значения IOPS немного выше, чем при тестировании файла 15Гб без FastCache. Значит, можно сделать вывод, что в этой неудобной ситуации FastCache помогает выжать из конфигурации дополнительные IOPS. Но на практике все оказалось не совсем так.
Во-первых, в этом тесте все частные Raid Groups (Raid5 4+1) в «Perfomance Tier» были загружены более равномерно.
Во-вторых, я решил провести дополнительный тест с файлом размером 150Гб, но FastCache был отключен.
Подробно описывать не буду, вот графики с IOMETR (сначала не поверил и провел тест дважды).
График зависимости средних значений IOPS от количества потоков ввода-вывода по результатам в IOMETER: 
График зависимости среднего времени ответа ввода-вывода от количества потоков ввода-вывода на основе результатов в IOMETER: 
То есть в ситуации, когда объем горячих данных превышает размер FastCache и при высоком проценте случайных запросов заполнение FastCache занимает некоторое время.
В таких ситуациях FastCache вносит пусть и небольшую, но все же дополнительную задержку во Время отклика.
В этой ситуации можно предложить использовать дополнительный уровень Extreme Performance Tier на SSD-накопителях в пуле.
В этом случае часть горячих данных «осядет» на нем и не будет обработана через FastCache. Соответственно, объем горячих данных, обрабатываемых через FastCache, уменьшится и окажется в более комфортных пределах.
Чтобы не быть голословным, я провел еще один тест.
5. Тест работы FastCache в VNX5400 с файлом размером 80Гб.
Данный тест проводился на размере файла 80Гб (Тестовый LUN с NTFS 100Гб), что достаточно близко к объему FastCache в тестируемом массиве.
То есть «горячая» область данных была довольно большой, но тем не менее полностью умещалась в FastCache. График из Unisphere Analyser (в IOPS).
FastCache заполнялся активнее, чем на файле размером 150Гб.
SP Cache также обрабатывал часть операций ввода-вывода.
Со стороны сервера и IOMETR все выглядело гораздо радужнее, чем на файле 150Гб.
График зависимости средних значений IOPS от количества потоков ввода-вывода по результатам в IOMETER: 
График зависимости среднего времени ответа ввода-вывода от количества потоков ввода-вывода на основе результатов в IOMETER: 
Начиная примерно с 24 потоков ввода-вывода (около 15 минут от начала теста) данные стали все чаще попадать в FastCache. Соответственно, общая производительность в тесте стала расти так же, а время отклика при увеличении потоков ввода-вывода выросло не так значительно, как в тесте с файлом 150Гб.
Небольшое отступление о дисковых пулах
Под спойлером При проектировании пула дисков, если вы не знаете фактический размер «горячих» и «теплых» областей данных, EMC рекомендует следующие пропорции для трехуровневого пула: 10% — SSD-накопители 20% — диски SAS 70% — диски NL-SAS Кроме того, нужно учитывать, что при добавлении флеш-тира в пул автоматически все метаданные тонких лун, созданных в пуле, будут размещаться на SSD. Если для них достаточно места.Это позволяет повысить общую производительность тонких лун и бассейна.
Для этих метаданных необходимо запланировать дополнительное место на SSD из расчета 3Гб объема на каждый 1Тб, фактически занимаемый тонкими лунами в пуле.
При этом луны с политикой утомления «наивысшего доступного уровня» будут иметь приоритет при размещении на уровне SSD над любыми другими данными.
Использование политики «самого низкого доступного уровня» для тонких, дедуплицированных или сжатых лун приводит к тому, что их метаданные размещаются на самых медленных дисках.
Что негативно влияет на работоспособность этих лун.
Для корректной работы Tiering вам необходимо свободное место в пуле.
На каждом стрельбище рекомендуется иметь не менее 10 % свободного места.
В противном случае система не сможет «перекладывать» куски (куски) данных между разными типами дисков в пуле.
выводы
По результатам проведенных испытаний можно сказать следующее.Как бы странно это ни звучало, FastCache не всегда хорош.
В неправильно спроектированной системе это может повлиять на производительность, в том числе ухудшить ее.
Чтобы не промахнуться на этапе проектирования, лучше запустить копию или часть ваших реальных нагрузок на демо-массиве.
Демо-массив можно запросить у поставщика.
Если такой возможности нет, то нужно исходить из соотношений горячих/теплых/холодных данных, которые предлагает использовать в расчетах тот же поставщик (исходя из статистических данных и некоторых собственных соображений).
Первый вариант с демо-массивом, на мой взгляд, предпочтительнее.
В целом, при правильно спроектированном массиве дополнительный уровень кэширования (FastCache) в VNX2 обеспечивает приличный прирост производительности.
Производительность VNX5400 не намного превосходит производительность VNXe3200, по крайней мере, в небольших и сопоставимых конфигурациях (количество дисков, размер FastCache).
Это может быть связано с тем, что младший массив был выпущен только в этом, 2014 году.
Те же выводы можно применить и к VNX5200, SP (контроллеры) которого ничем не отличаются от VNX5400 (номер запасной сервисной детали тот же).
.
VNX5200 имеет только ограничение на максимальное количество дисков (125 против 250 у VNX5400), ограничение на максимальный размер FastCache (600Gb против 1000Gb у VNX5400) и имеет на один слот меньше для дополнительных карт расширения с портами для подключения серверов.
.
Все проведенные тесты являются «синтетическими» и не имеют никакого отношения к вашим реальным нагрузкам.
Однако, на мой взгляд, такое моделирование помогает понять общие тенденции поведения систем хранения в тех или иных ситуациях.
Как
Если вам нужно хранилище для потоковой нагрузки (например: запись и обработка больших видеопотоков), то никакой кэш вам здесь не поможет. Наступит момент, когда он переполнится и в этой ситуации будет решать количество шпинделей (дисков) в вашей системе хранения данных.Если у вас очень высокая транзакционная нагрузка.
Если у вас большая база данных OLTP или VDI для тысяч или десятков тысяч пользователей, вам, вероятно, понадобится флэш-массив, а не классическая система хранения и многоуровневое хранение.
Теги: #Хранение данных #Системное администрирование #Хранение данных #тестирование #Системы хранения #тестирование #системы хранения #производительность #производительность #тест #SAN #кэш #EMC #VNX #VNX2 #Fast Cache #массив хранения #VNX5200 #VNX5400
-
Цифровые Вывески – Их Преимущества
19 Oct, 24 -
Несколько Советов Фрилансерам
19 Oct, 24
