about NetApp

??з всей троицы продуктов, появившихся у NetApp этим летом, а именно: FAS2500, FAS8080EX и NetApp AFF, совершенно неожиданно для меня именно последний стал предметом преткновения, пост про который я пишу уже вторую неделю. Если про FAS2500 я написал сразу, и там, в целом, все ясно по прочтении техспек и  Technical FAQ / SE Presentation, если c FAS8080ES тоже все ясно, это “больше, выше, сильнее”, вот, в общем, и все что про него можно рассказать, я даже отдельно про него писать не стану, то вот в отношении All-Flash FAS такая ясность долго не наступала. ?? далее я попробую рассказать, в чем, собствено, состоял предмет затруднения.

Continue reading ‘NetApp AFF: All-Flash FAS’ »

Следует отметить, что новости про flash прошлой недели показывают, что для NetApp это не просто “ну еще один all-flash сторадж, раз у всех есть”, налицо стратегическая линия. Одновременно с EF540 был анонсирован продукт, который пока не выпущен, но о котором, что, в общем, необычно для NetApp, уже рассказывается: FlashRay.

Если вы уже начинаете запутываться в том, что где и для чего у NetApp на flash-рынке предназначено, то давайте посмотрим на схему:

На ней вы видите позиционирование всех на сегодняший момент flash-продуктов NetApp: Flash Cache находится в контроллере, Flash Pool -  во “встроенном” хранилище самого NetApp, его часть, Flash Accel – софтверное решение внутри хост-серверов, использующая их внутренние SSD. EF450 – это standalone-сторадж, никак, архитектурно, не связанный с FAS. А вот что будет в этой картине мира делать анонсированный FlashRay?

FlashRay – это компонент развивающейся силами Clustered ONTAP (Data ONTAP 8 Cluster-mode) архитектуры scale-out, или, если по-русски, “горизонтального масштабирования. Напомню, что такое “горизонтальное” и “вертикальное” масштабирование.

Если вы переросли ваш сторадж,  и меняете его на более мощный – это “вертикальное масштабирование”. Если вы увеличиваете мощность имеющегося стораджа, добавляя непосредственно в имеющуюся инфраструктуру новый контроллер и диски, которые не образуют новую, более мощную “сущность”, а расширяя емкость и производительность уже имеющейся системы – это “горизонтальное масштабирование”. В NetApp “горизонтальное”, или scale-out (в отличие от scale-up, “вертикального”) масштабирование – это Cluster-mode.

Хорошо знакомые с номенклатурой NetApp могут увидеть в FlashRay наследника NetApp SA, специальных кэширующих систем, нацеленных на ускорение работы NFS. Такие системы, представляющие собой контроллер соответствующей системы хранения и небольшой объем дисков, подключенных к нему для хранения закэшированных данных, устанавливаются на пути между клиентским приложением на хост-сервере, и собственно хранилищем данных, и ускоряют доступ к часто обращаемым данным, как, например, в рассмотренном выше по ссылке кейсе.

В отличие от NetApp SA, согласно анонсу, FlashRay это будут all-flash устройства, ускоряющие доступ к бэкэнд-стораджу FAS, он будет поддерживать кластерность, многопротокольность (а не только NFS), inline-компрессию и inline-дедупликацию данных с переменной длинной блока (неужели пригодились-таки разработки для VTL в этой области?), и ряд других, более обычных для NetApp опций, включая репликацию и автобалансировку нагрузки в кластере FlashRay.

Таким образом, если после анонса EF540 вам показалось, что NetApp начала отходить от своей парадигмы “во flash выгоднее кэшировать, чем хранить”, то анонс FlashRay показывает, что концепция жива, здорова, и передает всем пламенный привет с нового уровня своего развития. Ждем более подробных новостей с техническими деталями.

Долгожданный Flash Pool (AKA Hybrid Aggregate) наконец-то вышел в релиз с появлением версии Data ONTAP 8.1.1. О том, что это такое я уже писал, но для тех, кто все пропустил, и не желает посмотреть в поиске по этому блогу, вкратце: это технология, которая позволяет создать комбинированный aggregate на системе хранения NetApp, в которй добавленные в aggregate диски SSD (на flash memory) используются для кэширования данных, читающихся, а также пишущихся на тома этого aggregate. Эта технология расширяет и дополняет уже имеющуюся несколько лет у NetApp для систем его midrange  и highend линейки, технологию Flash Cache, выполненную в виде карты flashmemory, и устанавливаемую внутри контроллера системы хранения.

Однако, как слюбой новой технологией, у нее существуют некоторые тонкости применения, неочевидные места, а то и просто засады. Вот о них мы сегодня поговорим подробнее.

Continue reading ‘Flash Pool: некоторые тонкости применения’ »

Недавняя моя заметка о выходе Data ONTAP 8.1 и некоторых особенностях новой версии, вызвала довольно широкий отклик, поэтому, для уменьшения количества панических слухов, я решил написать это дополнение и разъяснение.

Проблема, как вы уже знаете, в том, что, согласно Release Notes, в новой версии Data ONTAP, не поддерживается устройство Flash Cache на младших моделях линейки midrange, то есть на 3140, и даже на сравнительно недавно вышедшей 3210, несмотря на то, что Flash Cache можно физически в эти системы поставить, и ранее такая конфигурация поддерживалась.

По этому поводу ТАСС уполномочен сообщить мой источник в NetApp сообщает:

1. Да, действительно, это так. Поддержка Flash Cache для 3210/3140 сохраняется для ранее выпущенных версий Data ONTAP, то есть для линейки 7.3.х, и для v8 вплоть до версии 8.0.3 (и далее, если линейка 8.0.х будет продолжена).
2. Ситуация связана с некими сложностями на системном уровне. Дабы не задерживать выпуск 8.1, было решено подготовить фиксы для этой проблемы к следующей версии, 8.1.1, которая запланирована к выпуску в начале лета.
3. В версии 8.1.1 вновь ожидается поддержка Flash Cache для 3210 в объеме 256GB на контроллер (полный объем одной платы на 256GB), и для 3140 – в половинном объеме от объема установленной платы 256GB (доступный объем для Flash Cache 256GB для 3140 будет виден размером 128GB).
4. Flash Cache для FAS/V3210 или FAS/V3140 более недоступен к заказу, соответствующая конфигурация недоступна в конфигураторе с декабря 2011 года, вне зависимости от версии OS.
5. Установка Flash Cache на купленные после этой даты FAS/V3210 или FAS/V3140 не разрешена и не поддерживается, вне зависимости от использованной версии DOT.
6. Версия 8.2, и далее, также не будет поддерживать Flash Cache на системах FAS/V3210 и FAS/V3140.

В свете всего вышеизложенного (это уже мое, romx, мнение), даже несмотря на обещанную временную починку в 8.1.1, я бы не рисковал использовать в продакшне систему, фича которой уже официально прекращена в последующих версиях OS.

UPD: Я говорю тут ТОЛЬКО о поддержке Flash Cache на 3210 и 3140, на всех остальных системах 3200/6200, а также 3100, Flash Cache по прежнему ПОДДЕРЖ??ВАЕТСЯ и работает как и раньше.

В качестве варианта замены стоит обдумать вариант с Hybrid Aggregate (использование SSD в составе обычного aggregate из HDD), который появится начиная с 8.1.1, и о котором подробнее позже.

Наверняка вы уже слышали о том, как NetApp использует flash-память в форме памяти, а не эмуляции диска (SSD), я уже не раз рассказывал о том, что такое Flash Cache (ранее PAM-II), как он работает и насколько значительное дает преимущество с точки зрения производительности. С использованием обширного кэша во flash-памяти построен также нетапповский метод Virtual Storage Tiering, по многим своим параметрам превосходящий “классический” tiering, путем физического переноса данных между разными типами дисков.

Увы, все это, про “преимущества и производительность”, лишь слова, так как “потрогать руками”, не купив, Flash Cache довольно сложно, ведь ни один из российских партнеров, как я знаю, не держит систему Flash Cache для триала и демонстраций.

Однако, есть хорошая новость – на любой системе хранения NetApp вы можете оценить эффект от работы Flash Cache даже не имея ее физически, с помощью встроенного средства, под названием PCS – Predictive Cache Statistics.

Continue reading ‘Predictive Cache Statistics (PCS)’ »

Хотел бы обратить внимание тех, кто планирует использование новой возможности на системах хранения NetApp – WAFL online compression, то есть сжатия данных “на лету”, для хранения их на диске в сжатом виде. В настоящий момент блоки, которые были компрессированы таким образом, не кэшируются в Flash Cache / PAM.

Как вы знаете, у NetApp есть сейчас две основных технологии снижения storage footprint, то есть объемов хранения, занимающих физическое дисковое пространство, это давно существующая и хорошо себя зарекомендовавшая во многих случаях дедупликация, и появившаяся сравнительно недавно онлайн-компрессия. Две эти технологии существуют и работают независимо друг от друга, и даже дополняют друг друга. Каждая из них имеет свои предпочтительные области применения. Например, дедупликация хорошо работает для сред виртуализации, где ее эффективность (величина экономии после ее применения) может достигать 70-85% от первоначально занятого на дисках, но в рядя других применений, например для баз данных, ее эффективность (по разным причинам, на которых мы не будем сейчас подробно останавливаться) значительно ниже, часто не более 10-20%.

Напротив, компрессия довольно неплохо уменьшает объем хранения для пользовательских файлов и баз данных (35-50%). Она также сравнительно неплохо работает даже и на уже дедуплицированных данных, что может еще повысить результаты экономии.

Сравнительно неплохая эффективность компрессии на датасетах типа баз, например, может натолкнуть вас на мысль использовать компрессию для ваших баз данных, на системах, которые часто используют Flash Cache для повышения производительности работы. Но тут вот стоит принять во внимание момент, который я вынес в заголовок заметки: Блоки, которые располагаются на томе, с включенной компрессией, и подверглись компрессии, не кэшируются во Flash Cache.

Это диаметральным образом противоположно ситуации с дедупликацией, так как дедуплицированные блоки, напротив, попадают в dedupe-aware кэш, который знает о их дедуплицированности, и умеет ее использовать (например блок, на который на диске имеется десять ссылкок из десяти разных VMDK, будет считан и находиться в кэше не в 10, как в традиционной форме кэширования, а всего в одном экземпляре, что, очевидно, увеличивает эффективную емкость кэша).

Если у вас система с Flash Cache, и вы одновременно собираетесь использовать компрессию для данных – то будьте внимательны. Компрессированные тома в системе с Flash Cache могут иметь значительно отличающуюся от некомпрессированных производительность, за счет того, что с некомпрессированными томами работа будет идти через Flash Cache, а с компрессированными – нет. Эта разница, не слишком заметная для систем без Flash Cache, за счет такого поведения для систем с Flash Cache, может быть неприятным сюрпризом.

Эта особенность работы компрессии описана в новом TR-3958 Compression and Deduplication for DataONTAP 8.1 operating in 7-Mode на странице 22:

7.6 PAM AND FLASH CACHE CARDS

In environments with high amounts of shared blocks that are read repeatedly, the PAM or Flash Cache card can significantly reduce the number of disk reads, thus improving the read performance. The PAM or Flash Cache card does not increase performance of the compression engine or of reading compressed data. The amount of performance improvement with the PAM or Flash Cache card depends on the amount of shared blocks, the access rate, the active dataset size, and the data layout. The PAM or Flash Cache card has provided significant performance improvements in VMware® VDI environments. These advantages are further enhanced when combined with shared block technologies, such as NetApp deduplication or NetApp FlexClone® technology.

Так что обратите внимание на этот момент, и не применять компрессию для томов, производительность которых для вашей задачи критична, и которые вы планируете ускорить с помощью Flash Cache

UPD: Попросили уточнить. По-прежнему кэшируются во Flash Cache НЕсжатые блоки на сжатом томе (например, если эти блоки были исключены из процесса сжатия в результате плохого compression rate на этапе estimate для этих блоков). Но, так как нет механизма управлять тем, какие именно блоки или файлы будут компрессированы на томе, а какие - нет (компрессия назначается на том целиком), то это, в общем, довольно теоретическая поправка, не меняющая моей итоговой рекомендации.

По сведениям вебсайта, распространяющего слухи, сплетни и жареные факты из мира IT, небезызвестного theregister, NetApp будет поставлять старшие модели своей линейки, то есть FAS6240 и FAS6280 с уже включенным за нулевую цену модулем Flash Cache 512GB, в качестве бонуса.

Официальное сообщение об этом состоится, по всей видимости, в сентябре.

Flash Cache (ранее также PAM II) это плата на внутренней шине PCIe, с установленной на ней Flash-памятью, объемом 256, 512GB и 1TB, которая используется как “кэш второго уровня” в системах NetApp. ??спользование такого “кэша” позволяет построить так называемый “Virtual Storage Tiering”, при котором самые активно считываемые данные системы хранения находятся в таком “мегакэше”, скорость обращения к которому примерно вдесятеро выше.

Опубликованы также подтвержденные результаты, показывающие высокую эффективность использования Flash Cache как для NAS-протоколов, так и для SAN.

UPD: Подтверждено. 1TB на двухконтроллерную систему (по одному 512GB Flash Cache в каждый контроллер) FAS6240/6280 за цену 0. В конфгураторе будет доступно с 12 сентября.

Проглядывая community.netapp.com обнаружил дискуссию о autotiering-е, откуда выдернул интересное мнение уже известного вам Dimitris K. (recoverymonkey). Хотя в оригинале это были три реплики-ответа в дискуссии в форуме, я слил их оформил их как отдельную “статью”.

Дискуссия идет о реализации autotiering в EMC FAST, а также о системах хранения Compellent, которые, до недавнего времени, были главным игроком на рынке tiering-а, и реализация прозрачного tiering-а в них была сделана ранее всех. В России они почти неизвестны, хотя сейчас, как я понимаю, они могут начать попадать в страну через каналы Dell.

Dimitris Kriekouvkas (recoverymonkey), сотрудник NetApp:

Autotiering это отличная концепция, но она также очень новая, и результаты ее работы не проверены и не подтверждены на подавляющем большинстве реальных нагрузок.

Посмотрите на опубликованные бенчмарки EMC – там нигде нет autotiering.

Вы также не найдете и показателей FASTcache. Все бенчмарки у EMC делаются на традиционных RAID-группах, без пулов.

Если вы посмотрите на руководство наилучших практик по производительности и доступности для EMC CLARiiON (ссылку на этот документ я давал в прошлом посте про “матчасть”), то вы увидите следующее:

• Вместо RAID-5 для больших пулов на SATA рекомендуется RAID-6 с размером группы в 10-12 дисков.
• Thin Provisioning снижает производительность
• Storage pools снижают производительность по сравнению с Traditional RAID
• Данные и ввод-вывод не распределяются на все диски пула, как вы, возможно, предполагали (см ссылку).
• Рекомендуется использовать drive ownership на только один контроллер
• Нельзя смешивать разные типы RAID в одном пуле
• Существуют ограничения по расширению пула дисками, в идеале расширение должно производиться увеличивая емкость пула вдвое (или, хотя бы, кратно количеству дисков в RAID-группе пула)
• Для пула недоступны reallocate/rebalancing (для MetaLUN вы можете сделать restripe)
• Процесс Tresspassing pool LUN (обычно при переключении LUN-а с одного контроллера на другой, например при выходе одного из них из строя, но, часто, и при других операциях) может приводить к снижению производительности, так как оба контроллера будут пытаться совершать операции ввода-вывода на LUN. Поэтому для pool LUN-ов важно оставаться закрепленными за тем контроллером, на котором они начали работать, иначе потребуется затратная миграция.
• Не рекомендуется использовать thin LUN для задач, требующих высокой производительности по bandwidth.

Я хочу еще раз привлечь внимание к простому факту: дьявол кроется в деталях. Читайте мелкий шрифт.

Вам говорят: Autotiering волшебным образом, автоматически, решит ваши проблемы, без вашего участия, не беспокойтесь об этом. В реальности все не совсем так.

При работе autotiering, значительная часть вашего working set, рабочего набора данных, находящегося в активном использовании в данный момент, должно быть перемещено на быстрое хранилище.

Допустим у вас есть хранилище ваших данных, емкостью 50TB. Правило оценки, которым руководствуются инженеры EMC,  что 5% рабочего набора данных пользователя – “горячие данные”. Они перемещаются на SSD (в виде tier или cache). Таким образом вам нужно 2,5TB usable space на SSD, или примерно одна полку дисками SSD по 200GB, может быть больше, в зависимости от типа использованного RAID.

Принято считать, что объем “средней” нагрузки составляет 20% от объема, то есть 10TB, который размещается на дисках SAS или FC.

Остальное размещается на дисках SATA.

Вопрос на 10 миллионов долларов:

Что обойдется дешевле, autotiering и софт кэширования (он небесплатен) плюс 2,5TB SSD, плюс 10TB SAS, плюс 37,5TB SATA, или…

50TB SATA плюс NetApp FlashCache,или, например, 50TB SAS и Flash Cache?

Вопрос на 20 миллионов долларов:

Какая из этих двух конфигураций будет иметь более предсказуемую производительность?

Compellent – это еще одна интересная история.

Большинство обсуждающих Compellent не задумывается о том, что tiering-у у него подвергаются “снэпшоты”, а не непосредственно рабочие данные!

То есть принцип там такой: берется снэпшот, данные делятся на страницы, размеров 2MB (по умолчанию, может быть меньше, но тогда нельзя будет увеличить емкость хранилища). Далее, если оценивается, что обращений на чтение с данной страницы мало, то она переносится на уровень SATA.

О чем не знают большинство интересующихся Compellent-ом:

Если вы изменяете содержимое данных на странице, то происходит это следующим образом:

1. Перенесенная на SATA страница, содержащая данные, которые мы изменяем, остается на SATA.
2. Новая страница, объемом 2MB создается на Tier1 (SAS/FC), куда реплицируется содержимое страницы с SATA, и где делается запись изменения. Даже если меняется в данных один байт.
3. Когда с этой страницы будет сделан снэпшот, то он, в свою очередь, также может быть впоследствии перенесен на SATA, заменив прежнюю.
4. ??того: 4MB занятого места для того, чтобы сохранить 2MB данных и один измененный байт.

?? снова укажу: дьявол кроется в деталях. Если вы изменяете свои данные произвольным образом (random), вы получите множество “заснэпшоченных” страниц, и очень неэффективное использование пространства. Вот почему я всегда предупреждаю пользователей, которые интересуются Compellent-ом, задавать эти вопросы, и уяснить себе эти моменты, получив ясное описание от инженеров того, как используется пространство снэпшотов.

На NetApp мы имеем предельно гранулярное пространство, благодаря WAFL. Минимально возможный снэпшот по своему объему очень мал (это указатель, немного метаданных, плюс один измененный блок, размером 4KB). Поэтому на NetApp некоторые наши пользователи могут хранить сотни тысяч  снэпшотов на одной системе (например именно так делает один всем известный банк, использующий наши системы хранения).

Гранулярность, на самом деле, это только часть проблемы (производительность – другая ее часть). Сейчас страница у Compellent имеет размер 2MB (можно уменьшить до 512K, но это не позволит изменять размер стораджа). Если они перейдут, как обещают, на 64-битную арифметику в ПО, то они смогут получит  размер страницы 64K (это пока не подтверждено), однако тут есть вот какая проблема. Запись этой страницы на RAID может быть двумя способами.

Если это RAID-1, то тогда мы записываем две копии страницы, размером 64KB на каждый из дисков.

Если это RAID-5/6, то тогда нам надо поделить объем записываемой страницы, размером 64KB, поровну между всеми дисками данных, входящих в RAID. Допустим используется RAID-5 в варианте 4d+1p. Тогда на каждый диск в операции записи получится всего 16KB (и меньше). ?? если для RAID-1 размер записи в 64KB это довольно типичный размер записи сегмента в RAID, и запись таким размером достаточно производительна, то для RAID-5/6 это очень маленький кусочек для операции записи, что будет неизбежно отражаться на производительности.

В Data ONTAP мы не перемещаем снэпшоты, поэтому у нас нет такой проблемы, у других же вендоров она очень остра. Получить предсказуемую производительность при использовании autotiering это очень, очень сложная задача. Всякий раз когда мы у клиентов меняем нашими системами сторадж от Compellent, это происходит не потому что им не хватает каких-то фич, а только оттого, что у клиентов с ними проблемы с производительностью. Всякий раз.

Мы ставим 1-2 вида дисков плюс Flash Cache, и проблема решена (в большинстве случаев производительность становится в 2-3 раза выше, как минимум). Часто это получается даже не дороже.

Вот такие дела.

Совсем недавно я рассазывал о том, что такое Flash Cache (PAM-II) и как он работает, а вот уже и новости подоспели. NetApp объявила, что с сентября 2009 года, когда был объявлен Flash Cache и начались его поставки, c с системами хранения NetApp продан уже петабайт емкости на flash-памяти в Flash Cache.

Напомню, что Flash Cache это устройство в виде платы расширения, содержащее 256 или 512GB SLC NAND Flash, и устанавливаемое в системы хранения  FAS3×00 и FAS6000. Максимальная емкость  в самых старших системах линейки может достигать 4TB на систему. ??спользование Flash Cache позволяет значительно повысить быстродействи операций в IOPS, снизить время отклика (responce time, latency), увеличить энергоэффективность решения за счет отказа от многочисленных  “дисковых шпинделей” и можества дисковых полок, необходимых для обеспечения быстродействия системы, и заменяемых на Flash Cache.

В отличие от уже становящегося традиционным использования flash в форме SSD, то есть хранилища данных, дисков, Flash Cache работает как кэш “второго уровня”, в форме “памяти”, обеспечивая решение проблемы “холодных данных”, и повышая эффктивность использования дорогостоящего SLC Flash.

Подробнее о Flash Cache, как и о PAM-I, можно прочитать в переведенном руководстве Flash Cache (PAM-II) and PAM: наилучшие методы использования (PDF)

Вот уже пару лет как у NetApp в номенклатуре продуктов находится интересный, но все еще не слишком известный широкому кругу пользователей продукт – PAM – Performance Acceleration Module, а в прошлом году к нему в компанию добавился еще один вариант – PAM-II (ныне Flash Cache).

Давайте разберемся подробнее что это, чем полезно и как применяется.

Первое, что следует понимать, чтобы разобраться в том, что есть PAM и как его применяют:
PAM это не SSD!

Широкое распространение SSD (даже этот пост пишется на ноутбуке с SSD) привело к тому, что любой продукт так или иначе использующий память для хранения данных называется “SSD”.

Давайте разберемся, что такое SSD, и чем PAM не SSD.

Continue reading ‘PAM - Performance Acceleration Module’ »