Введение Недавно, и ненадолго, я наткнулся на систему хранения данных VNXe3200, которую анонсировала компания EMC. 2 для клиентов 5 мая 2014 г.
VNXe3200 — второе поколение унифицированных систем хранения данных начального уровня от EMC. 2 .
В этой модели представлены технологии, ранее доступные только на старых и более дорогих массивах среднего класса.
В частности, технология FastCache — т.е.
кэш второго уровня на SSD-дисках, который стоит в промежутке между традиционным кэшем в оперативной памяти контроллера хранилища (в терминологии EMC — Storage Processor) и самими дисками.
Я решил проверить, как эта технология влияет на производительность ввода-вывода на самых младших СХД от EMC. 2 .
В отличие от более старых систем хранения EMC VNX, в этой модели как блочный, так и файловый доступ реализован на одних и тех же контроллерах (SP).
Система хранения данных в базе данных имеет по 4 медных порта 10Гбит/с (10GBASE-T) для каждого SP, через которые могут подключаться клиенты/хосты по протоколам CIFS/SMB, NFS и iSCSI. Эти порты имеют автосогласование 10G/1G/100Mb в секунду.
Дополнительно каждый SP может быть оснащен платой на 4 FC-порта 8 Гбит/с.
Было решено протестировать с помощью IOMETER. В этом, помимо прочего, помогла данная статья с Хабра: связь .
Описание стенда и испытаний
С профилем нагрузки я не заморачивался; Я взял стандартный шаблон базы данных (Intel/StorageReview.com).
Для тестирования мы взяли сервер Blade BL460c G7 (один ЦП 6 ядер + HT, 24ГБ ОЗУ), подключенный по FC к СХД через свитчи, встроенные в корзину Blade FC с портами 4Гбит/с.
На сервере установлена ОС Windows 2012 R2 с загрузкой FC от VNXe3200 (загрузка из SAN).
К серверу был подключен тестовый том (LUN) объемом 1Тб с файловой системой NTFS, также через FC. СХД имеет дисковый пул из 10 дисков (SAS 2,5" 10k RPM 600Gb) с двумя частными рейд-группами (RG) внутри, имеющими конфигурацию Raid5 (4+1).
Также на массиве из двух SSD-дисков (2,5").
100Гб) в сборе FastCache (зеркальная пара Raid1).
Тестирование проводилось в три этапа.
1) С помощью IOMETER создается небольшой тестовый файл размером 2Гб, в надежде, что он полностью поместится в Cache SP на СХД.
2) Предыдущий тестовый файл был удален и создан тестовый файл размером ~50Гб, в расчете на то, что он не влезет в Cache SP, а будет полностью включен в FastCache. 3) Предыдущий тестовый файл был удален и создан тестовый файл размером ~500Гб, в расчете на то, что он не влезет ни в один из кэшей и при 100% случайном доступе практически даст производительность существующему шпинделю диски.
Тесты были построены таким образом, что перед каждым прохождением была «разминка» 10 минут, затем тест 20 минут. Каждый тест проводился с экспоненциальным ростом потоков ввода-вывода (1-2-4-8-16) для каждого из 12 воркеров (6 ядер + HT).
При этом, помимо самих IOPS СХД, интересно было комфортное среднее время отклика < 10 milliseconds (ms).
I’ll make a reservation right away that I will give “pictures” with graphs from the VNXe3200 interface, but the quantitative indicators on them coincide with the results in the IOMETER csv files, which will be given links. Потом немного расчетов.
Если не учитывать влияние кэша на ввод-вывод, то для дисков SAS 10k EMC предлагает 150 IOPS на диск.
Наше общее количество на сервере с 10 дисками должно составлять 150*10=1500 IOPS. Если учесть нашу загрузку r/w 67%/33% и потерю работы с CRC в Raid5, то получим следующее уравнение с одной неизвестной.
1500=X*0,33*4+X*0,67, где X — количество операций ввода-вывода в секунду, которые хосты получат с наших дисков.
4 — это размер штрафа для Raid5. То есть в Raid5 для выполнения одной операции записи, идущей от хоста, требуется 4 операции ввода-вывода на бэкенде (на дисках хранения).
Для Raid1/Raid10 значение штрафа равно 2, для Raid6 — 6. В результате получаем X=1500/1,99= ~750 IOPS. На практике я заметил, что максимально достигнутые значения в 1,5-2 раза превышают расчетные.
Это означает, что при пиковой нагрузке мы можем получить 1125-1500 IOPS с наших 10 SAS-дисков.
Перейдем к реальным тестам и их результатам.
Тест 1
Как и ожидалось, тестовый файл почти полностью уместился в кэше SP.
В ходе тестирования мы получили следующую картину по IOPS и запросам ввода-вывода, попадающим в кеш.
Здесь нужно оговориться, что на этом графике фактически показаны все IO, проходящие через SP. Некоторые из них обрабатываются из SP-кеша (попадание), некоторые «пролетают» через SP-кэш (промах) и обрабатываются либо из FastCache, либо со шпиндельных SAS-дисков.
При этом среднее время ответа при максимальном количестве потоков в IOMETER (12 воркеров * 16 потоков ввода-вывода = 192 потока ввода-вывода) составило ~8 мс.
Файл результатов IOMETER здесь .
Первый тест проводился с увеличением количества потоков на одного работника с 4 до 32 (4-8-16-32).
Поздно заметил, что раскаиваюсь в этом, но переделывать времени не было.
Тест 2
Во время теста тестовый файл размером ~50 ГБ почти полностью уместился в FastCache, как и ожидалось.
В результате получается следующая картинка, на которой видно, что почти все запросы пролетают мимо кэша SP. 
Среднее время ответа на 192 потоках составило ~12,5 мс.
Комфортное время отклика составило ~8 мс для 8 потоков на воркера (96 потоков ввода-вывода).
Файл результатов IOMETER здесь .
Тест 3
Во время теста ввод-вывод произошёл случайным образом по всем ~500Гб и ни один кэш в теории здесь не мог помочь, как это видно на практике из графиков ниже.
В результате, как и планировалось, мы получили производительность 10 SAS-шпинделей в Raid5. При этом первые 4 диска в СХД, используемые в пуле, представляют собой так называемый VaultPack. То есть часть этих первых дисков (~82,5 ГБ с каждого) «отрезана» под системные нужды.
Среднее время ответа на 192 потоках оказалось достаточно высоким и составило ~149 мс.
Комфортное время отклика составило ~10 мс при 1 потоке на работника (12 потоков ввода-вывода).
Файл результатов IOMETER здесь .
Небольшое отступление о пулах
При проектировании пула дисков, если вы не знаете фактический размер «горячих» и «теплых» областей данных, EMC рекомендует следующие пропорции для трехуровневого пула: 10% — SSD-накопители 20% — диски SAS 70% — диски NL-SAS Кроме того, нужно учитывать, что при добавлении флеш-тира в пул автоматически все метаданные тонких лун, созданных в пуле, будут размещаться на SSD. Если для них достаточно места.Это позволяет повысить общую производительность тонких лун и бассейна.
Для этих метаданных необходимо запланировать дополнительное место на SSD из расчета 3Гб объема на каждый 1Тб, фактически занимаемый тонкими лунами в пуле.
При этом луны с политикой утомления «наивысшего доступного уровня» будут иметь приоритет при размещении на уровне SSD над любыми другими данными.
Использование политики «самого низкого доступного уровня» для тонких лун приводит к тому, что их метаданные размещаются на самых медленных дисках.
Полученные результаты
Тестирование показало, что все типы кэша в системах хранения в целом положительно влияют не только на общую производительность массива.А также на среднее время отклика операций ввода-вывода, особенно при высокой нагрузке.
И учитывая вышесказанное, самые «горячие» данные окажутся в кеше.
Можно сделать вывод, что FastCache в EMC VNXe3200 будет очень успешным и популярным дополнением даже при небольших конфигурациях.
Учитывая, что процесс «прогрева» (попадания данных в кэш) происходит довольно быстро.
Теги: #Хранение данных #Системное администрирование #Хранение данных #тестирование #Системы хранения #тестирование #системы хранения #производительность #производительность #тест #SAN #кэш #EMC #VNXe #Fast Cache #массив хранения #VNXe3200
-
Сплетите Свою Собственную Паутину
19 Oct, 24 -
Grddl Теперь Является Рекомендацией W3C.
19 Oct, 24 -
Coffeescript В Примерах. Проверка
19 Oct, 24
