NetApp: кэшируем в сервере

Всего пара месяцев прошла с момента официального объявления о сотрудничестве Fusion-io и NetApp с целью использования технологий Fusion-io в стеке NetApp Virtual Storage Tier.

На сегодняшний день в VST используются “родные” технологии NetApp – FlashCache и FlashPool, позволяющие эффективно повышать производительность системы посредством интеллектуального кэширования “горячих” данных на Flash-картах и SSD дисках.

И вот уже вчера NetApp анонсировал продукт Flash Accel, обеспечивающий кэширование данных на стороне сервера. Как несложно догадаться, Flash Accel это по факту PCI-e карта и соответствующий софт от Fusion-io. Кэширование на стороне сервера возможно только на чтение (что вполне логично). Доступность Flash Accel заявлена на декабрь 2012. Flash Accel является программной разработкой NetApp, позволяющей использовать в качестве кэша локальные устройства сервера (SSD или Flash PCI-e карты). В первой версии будут поддерживаться Windows Server 2003 и 2008, а также vSphere 5. Примечательно, что даже в первой версии обещают работу HA, vMotion и DRS. Формально есть привязка к системе хранения (пока только FAS, V- и N-серия), но не к кэширующему устройству (будет список официально поддерживаемых). На текущий момент NetApp будет перепродавать карты от Fusion-io. 

Но этим же пресс-релизом NetApp тонко намекает Fusion-io, что расслабляться не стоит – желающие производители аналогичных решений могут подать заявку на получение значка “NetApp Validated”. И в этом списке уже, помимо Fusion-io, отметились LSI, Micron, SanDisk, STEC и Virident.

Но пока только с Fusion-io заключен контракт, согласно которому будут перепродаваться Fusion-io ioMemory, ioTurbine и Direct Cache. 

К слову сказать, у нас уже доступен к заказу LSI Nytro XD. Это комплект из PCI-e карты с 400GB флэш-памятью (e-MLC) и специального софта, который и позволяет осуществлять кэширование данных (независимо от расположения – будь то СХД или DAS). Среди серьезных преимуществ – крайне низкие требования драйвера устройства к оперативной памяти (рассматривая в качестве альтернативы решение Fusion-io об этой особенности важно помнить). Пока еще, правда, не поддерживается работа в среде VMware, но и это тоже не за горами – работа активно ведется.

Кэширование данных на серверах перестает быть красивой идеей и уже может быть использован в реальных проектах с получением вполне очевидных преимуществ по производительности.

P.S. Спасибо Роману за уточнение!

Понравился пост? Подпишись через RSS, Email или twitter!

Кэшировать всегда, кэшировать везде!

Уже во время анонса системы IBM XIV Gen3 было объявлено о скорой поддержке SSD внутри модулей. “Скоро” уже настало и вот теперь можно не только заказать новый XIV Gen3 с установленными SSD дисками, но и установить SSD в уже инсталлированную систему XIV Gen3 (процедура не требует остановки – только обновления микрокода). В каждый узел XIV можно установить по одному диску SSD 400GB (суммарно это даст от 2.4ТБ до 6ТБ на систему, размер немного занизили – изначально обещали диски по 500GB). Почему так мало? Потому что это пространство может быть использовано только как кэш чтения, а не для хранения самих данных, а 6ТБ кэш памяти это не так уж и мало. Кэшируются только операции чтения – для кэширования операций записи используется оперативная память узлов XIV (суммарный объем которой достигает 360GB). Чтобы обеспечить для SSD модулей долгое и безоблачное существование под высокой нагрузкой используется специальный механизм оптимизации: изначально в оперативной памяти узла формируются блоки размером по 512КБ и уже именно эти блоки последовательно и циклично записываются на SSD. Таким образом, операции записи на SSD всегда идут последовательно, а ячейки используются равномерно. Обещают неплохой прирост в производительности:

Решение, предложенное в XIV безусловно не является технологическим прорывом – всем уже вспомнился и EMC FastCache, и NetApp FlashCache. Каждое из этих решений имеет и свои плюсы, и свои минусы. От EMC FastCache заказчик получает не только кэширование при чтении, но и кэширование операций записи. Платой за это является существенное сокращение кэша в оперативной памяти SP и сравнительно небольшой объем – для “топового” VNX7500 он составляет 2.1ТБ (при использовании 100GB дисков). В случае с NetApp FlashCache кэшируется только чтение, но зато кэш является дедублицированным и может достигать 16ТБ. Кроме того, FlashCache является PCI-e платой, поэтому “дорога” от кэша до процессора (а значит и до хоста) гораздо короче, чем при использовании SSD дисков. А это, в свою очередь, потенциально позволяет получить довольно низкую латентность. С другой стороны, если мы захотим получить 16ТБ кэша, то на придется задействовать 16 слотов расширения из 24х возможных, что существенно ограничит возможности расширения (как по дискам, так и по используемым протоколам подключения хостов).

EMC тоже отметились и с шумом выкатили свое решение для кэширования VFCache (Very Fast Cache). Что это и как “привязано” к дисковой системе? По факту VFCache это обычная PCI-e плата (как и аналоги у FusionIO, LSI и пр.) 300GB (производства Micron), которая используется не как супер-быстрый диск в операционной системе, но как кэш для операций чтения.

В принципе (насколько я понял из прочитанного/найденного), никто не мешает использовать VFCache с любой дисковой системой (и без нее в т.ч.). Можно даже часть VFCache “отрезать” и использовать как жесткий диск. Среди явных минусов – пока поддерживается только одна карта в сервере, так что использование части VFCache как DAS, не может обеспечить отказоустойчивость. Кроме того, поддержка в VMware серьезно ограничивает такой функционал как vMotion (а точнее он просто не поддерживается). В данном случае решение EMC тоже уникальным не назовешь. Один из пионеров в выпуске PCI-e SSD карт – FusionIO уже некоторое время предлагает аналогичный продукт ioCache (который, кстати, vMotion как раз поддерживает). Есть надежда, что в последующих релизах VFCache будет существенным образом доработан и появится не только более тесная интеграция с VMware, но и с собственными продуктами (FAST Cache/ FAST VP).

Понравился пост? Подпишись через RSS, Email или twitter!

еще про FusionIO

Прочитал довольные интересные выдержки из интервью с David Flynn. Рассказывает немного про то, как внутри устроен ioDrive: фактически внутри живет что-то типа RAID50. Бояться double failure, как утверждается, не нужно, так как ребилд занимает меньше секунды. Да и без пары камешков в чужой (производителей обычных SSD) огород тоже не обошлось конечно. Так что рекомендую прочесть - переводить смысла не вижу.

Понравился пост? Подпишись через RSS, Email или twitter!