Введение
Недавно и не надолго ко мне в руки попала система хранения данных (СХД) VNXe3200, которая была анонсирована компанией EMC2 для заказчиков 5 мая 2014 года. VNXe3200 — это второе поколение entry-level Unified СХД компании EMC2. В данной модели появились технологии доступные ранее только на более старших и более дорогих midrange массивах. В частности технология FastCachе — т.е. кэш второго уровня на SSD дисках, который встает в разрез между традиционным кэшем в оперативной памяти контроллера СХД (в терминологии EMC — Storage Processor) и собственно дисками. Я решил проверить, как данная технология влияет на производительность ввода/вывода на самых младших СХД компании EMC2.
В отличии от старших СХД EMC VNX, в данной модели как блочный, так и файловый доступ реализован на одних и тех же контроллерах (SP). СХД в базе имеет на каждый SP по 4 медных порта 10Gbit/s (10GBASE-T), через которые реализуется подключение клиентов/хостов по протоколам CIFS/SMB, NFS и iSCSI. Порты эти с autonegotiation 10G/1G/100Mb в секунду. LДополнительно в каждый SP можно поставить плату на 4 порта 8Gb/s FC. Тестировать решено было при помощи IOMETER. В этом помогла, в том числе, вот эта статья с Хабра: ссылка.
Описание стенда и тестов
С профилем нагрузки мудрить не стал, взял стандартный Database pattern (Intel/StorageReview.com).
Для тестирования был взят Blade BL460c G7 сервер (один CPU 6 ядер + HT, 24GB ОЗУ), подключенный по FC к СХД через встроенные в блэйдовую корзину FC коммутаторы c портами на 4Gbit/s. На сервере была установлена OS Windows 2012 R2 c загрузкой по FC с VNXe3200 (boot from SAN). К серверу был подключен, так же по FC, тестовый том (LUN) размером в 1Tb c файловой системой NTFS. На СХД собран дисковый пул из 10 дисков (SAS 2,5" 10k RPM 600Gb) с двумя приватными рэйд группами (RG) внутри, которые имеют конфигурацию Raid5 (4+1). Так же на массиве их двух SSD дисков (2,5" 100Gb) собран FastCache (зеркальная пара Raid1).
Тестирование проводилось в три этапа.
1) При помощи IOMETER создается маленький тестовый файл размером в 2Gb, в расчете что он полностью поместиться в Cache SP на СХД.
2) Предыдущий тестовый файл удалялся и создается тестовый файл размером ~50Gb, в расчете на то что он не поместится в Cache SP, но зато полностью войдет в FastCache.
3) Предыдущий тестовый файл удалялся и создается тестовый файл размером ~500Gb, в расчете на то что он не поместиться ни в один из кэшей и при 100% рандомном доступе практически даст производительность имеющихся шпиндельных дисков.
Тесты были настроены таким образом, чтобы перед каждым проходом был «разогрев» в 10 минут, потом тест 20 минут. Каждый тест выполнялся с экспоненциальным ростом потоков ввода/вывода (1-2-4-8-16) на каждый из 12-ти workers (6 ядер + HT). При этом, помимо собственно выдаваемых СХД IOPS-ов, было интересно комфортное среднее время отклика < 10 миллисекунд (ms). Сразу оговорюсь, что приведу «картинки» с графиками из интерфейса VNXe3200, но количественные показатели на них совпадают с результатами в csv файлах IOMETER, которые будут приведены ссылками.
Дальше немного расчетов.
Если не учитывать влияние cache на ввод/вывод, то для дисков 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 это у нас те IOPS, которые получат хосты с наших дисков. A 4 — это размер «пенальти» для Raid5. То есть в Raid5 для выполнения одной операции записи, приходящей с хоста, требуется 4 операции ввода/вывода на бэкенде (на дисках СХД). Для Raid1/Raid10 значение пенальти — 2, для Raid6 — 6. В итоге получаем X=1500/1,99= ~750 IOPS. На практике я замечал что максимальные достигаемые значения бывают больше расчетных в 1,5-2 раза. Значит в пиковой нагрузке можем получить 1125-1500 IOPS с наших 10 SAS дисков.
Перейдем собственно к тестам и их результатам
Тест 1
Как и предполагалось тестовый файл практически полностью поместился в cache SP.
При тестировании мы получили следующую картину по IOPS и попаданиям запросов ввода/вывода в кэш. Тут нужно оговориться о том, что данный график показывает на самом деле все IO проходящие через SP. Часть из них отрабатывается из SP cache (hit), часть «пролетает» SP cache на сквозь (miss) и отрабатывается либо из FastCache, либо со шпиндельных SAS дисков.
При этом среднее время отклика при максимальном количестве потоков в IOMETER (12 workers * 16 потоков IO = 192 потока ввода/вывода) составило ~8 ms. Файл с результатами IOMETER тут. Первый тест был проведен с увеличением количества потоков на worker от 4 до 32 (4-8-16-32). Заметил поздно в чем каюсь, но переделывать уже было некогда.
Тест 2
В процессе теста тестовый файл на ~50GB почти полностью поместился в FastCache, как и ожидалось.
В результате получилась следующая картинка, на которой видно, что практически все запросы пролетают мимо SP cache.
Среднее время отклика на 192 потоках было ~12.5 ms. Комфортное время отклика было на 8 потоках на worker ~8 ms (96 потоков IO). Файл с результатами IOMETER тут.
Тест 3
В процессе теста ввод/вывод рандомно «бегал» по всем ~500Gb и ни один cache в теории тут помочь не мог, что и видно на практике по графикам ниже.
В результате, как и планировалось, получили производительность 10 SAS шпинделей в Raid5. При этом 4 первых в СХД диска из использованных в пуле — это так называемый VaultPack. То есть часть от этих первых дисков (~82,5 GB с каждого) «отрезана» под системные нужды.
Среднее время отклика на 192 потоках было довольно большим и составило ~149 ms. Комфортное время отклика было при 1 потоке на worker (12 потоков IO) ~10 ms. Файл с результатами IOMETER тут.
Итоги
Принято считать, что активные («горячие») данные составляют не более 3-5% от общего объема данных, еще 15-20% «теплые» данные, а весь остальной объем ~75-80% бывает редко востребован хостами (серверами/пользователями).
Тестирование показало, что все типы Cache в СХД в целом оказывают положительное влияние не только на общую производительность массива. Но и на среднее время отклика операций ввода/вывода, особенно под высокой нагрузкой. А учитывая выше сказанное, в кэш как раз будут попадать наиболее «горячие» данные.
Можно сделать вывод, что FastCache в EMC VNXe3200 будет являться вполне удачным и востребованным дополнением даже при небольших конфигурациях. Учитывая что процесс его «разогрева» (попадания данных в кэш) происходит достаточно быстро.
Автор: ximik13
