about NetApp

Хотел бы обратить внимание тех, кто планирует использование новой возможности на системах хранения 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’ »