Некоторые данные о производительности EMC FASTcache и FAST VP
Несмотря на то, что EMC наотрез отказывается публиковать результаты производительности систем с FASTcache и FAST VP, храня по этому поводу многозначительное и загадочное молчание, невозможно запретить частным лицам анализировать и делиться своими результатами приобретенных ими систем.
Недавно в интернете удалось раскопать вот такие результаты.
Некто проследил и опубликовал результаты real world-работы системы NS480 (CX4-480), объемом 480 SAS, SATA и EFD дисков, на 28TB block и 100TB NAS data, оснащенной как FAST VP, так и FASTcache (4 диска EFD по 100GB, общей usable capacity в FASTcache – 183GB).
Пожалуйста, примите во внимание, что это Real World data, то есть реальная производительность системы, используемой под реальную пользовательскую работу (в рассмотренном случае – ERP, VMware, SQL server databases, CIFS shares), а не какие-то специальные тестовые условия. В этом и сила и слабость приведенных результатов. Сила в том, что это реальные, практические данные. Слабость – в том, что, вполне вероятно, мы не видим всех возможностей FAST/FASTcache.
Тем не менее “чем богаты – тем и рады”. Пока EMC хранит загадочное молчание, приходится перебиваться тем, что подарят сердобольные пользователи. Подробно о системе и полученных результатах – по ссылке выше.
Напомню, что, в отличие от EMC, NetApp результаты своих систем с Flash Cache не только не таит, а наоборот, активно пропагандирует и публикует, потому что, по справедливости, там есть чем гордиться.
UPD: В комментариях к посту также нашлось упоминание еще одних результатов.
http://sudrsn.wordpress.com/2011/03/19/storage-efficiency-with-awesome-fast-cache/
http://sudrsn.wordpress.com/2011/04/16/emc-fast-cache-increase-performance-while-reducing-disk-drive-count/
Правда там человек темнит о конфигурации.
А можно ли как-то получить схожий разрез производительности в IOPS для NetApp? увидеть сколько идет с FlashCache, а сколько с SAS дисков? Operation Manager показывает только суммарный график по IOPS’ам.
p.s. ?? для 480 шпинделей (правда нету соотношения сколько из них SAS, сколько SATA) наверно это не самые большие попугаи :) зато реальные цифры.
Стоит отметить, что не просто кто-то, а работник EMC: http://storagesavvy.com/about/ :)
Я думаю, что ценность графика, приведенного в статье, станет больше, если вписать комментарий из оригинала:
I didn’t graph it here but the total array IO Response time through this window is averaging 2.5 m
Dmitriy:
Можно было бы попробовать сперва сделать замеры в варианте с кэшем, а потом отключить его (>options flexscale.enable off , если не ошибаюсь) и посмотреть разницу.
Dmitriy:
Если у Вас в системе стоит FlashCache - то мой взгляд проще всего промониторить командой “stats show -p flexscale-access -i 1″ *) под реальной нагрузкой. Там есть статистика по “Hit Rate”, т.е. по эффективности кеша. Если грубо, то если система в среднем делает за период измерения 10,000 iops всего, при этом эффективность кеша 80% значит 8,000 iops до дисков не дошли, а обслужились из кеша.
Наверное это не самый лучших способ и наверняка у производителя есть скрипты на эту тему :)
*) цифру один в команде меняем на время, за которое хотим посмотреть агрегированную статистику.
Dmitriy:
Можно еще вот так попробовать посмотреть статистику: “stats start ext_cache_obj:*:disk_reads_replaced ext_cache_obj:*:hit_percent system:*:read_ops”. Статистика начнет собираться. Посмотреть результаты - “stats stop”.
Есть подозрение, что статистика не очень точная, возможно потому что значительная часть запросов обслуживается из первичного кеша, а может и по другой причине.
Для более точной статистики наверное лучше собрать вместо system:*:read_ops счетчики disk:*:user_reads, но данные придется обрабатывать внешним скриптом, т.к. статистика будет по каждому диску отображаться отдельно и ее надо суммировать.
На самом деле эти результаты очень показательны для тех, кто в данной сфере разбирается.
Самое важное - это механизм работы FASTcache, его нельзя включать для всех возможных видов данных и операций, иначе результыты будут сильно отличаться от ожидаемых. Кроме того, размер кэша должен быть рассчитан исходя из размера горячих данных, и я никогда не поверю, что для 28Tb данных горячими являются 183Гб :) По своему опыту работы могу назвать число 10%, то есть 3Тб данных, которые постоянно читаются и обрабатываются. Теоретически это может означать, что шанс попадания в FASTCache в данном случае равен 6% (Hit Ratio). Поэтому неудивительно, что на картинке только 2500 операций вращаются в кэше (хотя на самом деле удивительно, потому что должно быть меньше!)
firehunter:
Спасибо за полный и подробный ответ, кстати (а то тут в основном все я, да я отвечаю;)