Про tiering: EMC FAST, FASTcache, NetApp Flash Cache

Несколько постов назад, в комментах, разгорелась нешуточная дискуссия о том, можно ли считать Flash Cache “истинно православным” средство tiering-а, и ставить его в ряд с множеством других аналогичных средств, например с EMC FAST.
Для разъяснения моей позиции на этот счет я и написал этот пост.

Для начала давайте определим что такое tiering вообще.

Tiering-ом (увы, русскоязычного термина пока не прижилось, будем использовать такое) принято называть механизм перемещения данных между “уровнями” (tiers) хранения, характеризующимися теми или иными свойствами, например ценой, быстродействием, защищенностью, и так далее. Обычно tiering-ом принято называть механизмы, для перемещения данных между дисками разных типов, или дисками и магнитными лентами, или же ROM-хранилищем, часто он используется для организации ILM – Information Lifecycling Management – хранилища данных в соответствии с их статусом и уровнями QoS.

Но давайте отвлечемся от физической реализации, и посмотрим на задачу с функциональной точки зрения, с точки зрения пользователя или приложения, использующего систему хранения.

Что есть tiering с точки зрения приложения или пользователя? Зачем мы его применяем?

Целью tiering-а для пользователя является возможность повысить эффективность (в первую очередь экономическую) использования его системы хранения. Когда “цена значения не имеет”, то все просто – надо купить Symmetrix. Однако в реальной жизни цена очень даже имеет значение, и пользователь вынужден идти на компромиссы между ценой решения и необходимой пользователю производительностью.

Используемые в системах хранения диски сегодня имеют различную производительность, емкость и цену, причем производительность и емкость обычно величины обратно пропорциональные: больше емкость – меньше производительность (SATA), меньше емкость – выше производительность  (SAS), еще выше производительность и цена, и меньше емкость – Flash. Система хранения-же целом характеризуется соотношением IOPS/$, то есть количества единиц производительности с “вложенного доллара”.  Повысить этот параметр стремится любой вендор и любой покупатель системы хранения.

Согласно широкоизвестному Закону Парето (“20 процентов сотрудников делает 80 процентов всей работы”) сравнительно небольшая часть данных ответственна за значительную долю быстродействия системы. Напротив, значительная часть данных относится к так называемым “холодным”данным, скорость доступа к которым в принципе не критична.
Было бы неплохо, если бы эти 20% активных данных, скорость доступа к которым напрямую влияет на общую производительность, располагались на максимально быстром разделе хранилища, пусть он дорогой, но его емкость будет всего 20% от емкости хранилища, зато прирост мы получим во все 80%!

Именно эта идея лежала в основе идеи tiering-а. Если этот тип данных – активный, то автоматически перенесем его на более дорогие и быстродействующие диски, и повысим производительность доступа к ним, а менее активные данные – перенесем на менее производительные дешевый тип дисков. И настанет счастье, в виде повысившегося соотношения IOPS/$.

К такому, “классическому” типу tiering-а относится продукт EMC FAST – (Fully-Automated Storage Tiering). Он позволяет прозрачно для пользователя переносить фрагменты его данных между “уровнями” хранилища, например между разделами на дисках SAS и SATA.

image

Увы, дьявол кроется в деталях, и “всегда читайте написанное мелким шрифтом”. Первая версия FAST была весьма сырой, например, позволяла переносить только LUN-ы целиком, что, очевидно, неприемлемый на практике уровень “гранулярности” данных. Только в FASTv2 появилась возможность суб-LUN-овой миграции, впрочем, по-прежнему, мигрируемый минимальный фрагмент данных весьма велик (1GB!), да и еще окружен множеством ограничений использования (не поддерживается компрессия для данных, которые подлежат миграции, например).

К тому же, к сожалению, принадлежность данных к той или иной группе не фиксирована. Так, бухгалтерские проводки за прошлый квартал могут лежать “холодными”, до момента составления квартального или годового отчета, когда обращение к ним резко увеличится. Значит пока мы не распознаем и не смигрируем ставшие активными данные на быстрое хранилище, мы рискуем значительно терять в быстродействии, а если наш алгоритм выявления активных данных не обладает достаточным быстродействием, мы рискуем и вовсе не получить прироста, если “пики” доступа окажутся менее “разрешающей способности” анализирующего алгоритма, и не будут им распознаны как активность. Это же относится и к “устойчивости к помехам”, так, например, регулярный бэкап может свести с ума алгоритм анализа активности, ведь к данным обращаются каждую ночь!

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

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

Большой плюс метода кэширования заключается, во-первых, в полной “автоматизации процесса”, ни пользователю, ни его программе не надо предпринимать какие-то дополнительные действия при его использовании. Если они часто читают этот участок данных, он оказывается в кэше, и скорость доступа к нему повышается, если они перестают его читать, то он вытесняется более активными данными, и остается только в основном хранилище.

image

Во-вторых, в область дорогого, но высокопроизводительного хранения – “кэша” – попадают “по определению” только “горячие” данные. Место в кэше всегда занимают только данные, к которым сейчас идет активное обращение. Все 100% дорогостоящего объема кэша используются для повышения производительности системы, а не просто “хранения”. Следствием этого является более высокая эффективность работы кэша. Процессор Intel Xeon имеет всего 8Mb кэша, что не мешает ему работать с в тысячи раз большими объемами ОЗУ на сервере, и, за счет этого, сравнительно небольшого, по относительной величине, кэша, эффективно ускорять доступ к размещенным в обширной памяти данным.

В третьих – процесс ускорения доступа и улучшения результата IOPS/$ путем кэширования есть, с алгоритмической точки зрения, процесс тривиальный. А раз так, он имеет минимум побочных эффектов и ограничений использования, а работать (и давать результат в виде повышения производительности) начинает сразу же, а не когда накопится статистика использования и, наконец, в соответствии с ней произойдет миграция данных с одних дисков на другие.

Минусы? Ну как же в нашей жизни и без минусов. Эффективность кэша, действительно высокая при чтении, сильно падает на операциях записи. Ведь если мы изменяем данные в их копиях в кэше, нам надо регулярно и своевременно обновлять их непосредственно по месту их размещения (этот процесс имеет название “сброса содержимого кэша” или “flush”). Значит, если мы изменяем содержимое блока, нам надо это изменение распознать и переписать его содержимое в основном хранилище, чтобы, когда блок будет вытеснен по неактивности из кэша, его новое, измененное содержимое не потерялось. Кэширование записи, хоть и ускоряет собственно процесс записи, сильно усложняет ситуацию алгоритмически, и, как следствие, может вести к значительному снижению эффективности работы.

Таким образом, взглянув на задачу “со стороны пользователя”, мы видим два эквивалентных по результатам решения. Оба решают задачу в нужном пользователю русле, а именно, распределяют данные по “уровням” хранения с различной ценой и производительностью, в зависимости от их активности, улучшая, в результате, экономическую эффективность хранилища, повышая производительность и снижая затраты, то есть улучшая уже названный выше ключевой экономический  параметр хранилища – IOPS/$.

Да, действительно, “метод кэширования” имеет в основе другой механизм, чем “метод переноса”, но если результат для пользователя – тот же самый: изменение характеристик доступа к данным, ведущее к улучшению параметра IOPS/$ и эффективности хранилища, то “неважно, какого цвета кошка, если она хорошо ловит мышей”. Будет ли это tiering как перенос данных между двумя типами дисков, или в виде переноса между диском и кэшем, для пользователя и его задач это, по большому счету, безразлично, если это дает эквивалентный прирост эффективности.

Вот почему я считаю, что как EMC FAST, так и EMC FASTcache и NetApp FlashCache, все они являются формами организации tiering-а, и их можно рассматривать вместе, как формы одного решения.

38 комментариев

  1. Киселев Сергей:

    Tiering сейчас горячая тема. Аналога EMC FAST к сожалению у NetApp нет, использование PAM больше похоже на FASTcahce. В любом случае, использование любой из этих технологий будет эффективно, естественно если их правильно применять. На данный момент, по стоимости реализации tiering-а, по выбору метода организации tiering-а, у EMC есть преимущество.
    Заказчики поиграются этими технологиями и решат … проще купить память в сервера - дешевле и эффективнее.

  2. Роман, регулярно читаю ваш блог. Интересно и воодушевленно пишите, спасибо.
    Уже несколько раз использовал ваши посты против EMC в беседах с Заказчиками. Очень эффективно показать на реальном примере, что о EMC думают конкуренты (сори, независимые эксперты) и выдержками из документации показать, где они непреднамеренно ошибаются.

    В этом посте вы, кажется, немного запутались в том, что критикуете. Думаю вам стоит почитать о принципиальных отличиях FAST VP на массивах Symmetrix и Clariion, о гранулярности (между 8KB и 1GB, согласитесь, есть некоторая разница) и том, как работает шедулер переноса данных. Знание предмета, однозначно, придаст компетишн-постам большую весомость.

    Теперь, собственно, основной вопрос. Не могли бы вы пояснить следующую фразу?
    “Кэширование записи, хоть и ускоряет собственно процесс записи, сильно усложняет ситуацию алгоритмически, и, как следствие, может вести к значительному снижению эффективности работы.”
    Вы имеете ввиду какую-то особенность NetApp FlashCache или алгоритмическое усложнение ситуации так ведет себя во всех решениях по кэшированию на flash?

    Удачи
    Василий

  3. Александр:

    Я бы немного поправил, это FASTcahce похож на PAM. По моему мнению FAST имеел бы применение, когда мы точно знаем начало периодически повторяющегося отчетного периода и шедулим к этому времени переезд базы на более быстрое пространство. В остальных случаях. У NetApp’а можно руками перенести.
    По поводу фаста он действительно автоматический и такой опции не дает, о чем я выше написал. Посмотрел на CX4, чтобы не соврать http://habreffect.ru/files/60f/87723c23a/FAST.png

  4. Киселев Сергей:

    Для меня пока остаётся открытым вопрос, как при использовании этих технологий работает обычный кэш СХД.
    Насколько я понимаю, в случае FASTCache, система определяет горячие данные, расположенные на дисках (FC, SATA) и копирует их на SSD диски, но когда работает ещё и стандартный кэш системы, то и в этом кэше также будут горячие блоки данных и при обращении к ним, чтение с дисков не идёт, соответственно эти блоки (хранимые в кэше) не будут копироваться на SSD?

  5. deepblue:

    Вроде как тему закрыли, но раз уж romx решил к ней вернуться, придется мне повторить мои “постулаты”:

    ФАКТ: FAST не является аналогом FlashCache. Аналогa FAST в настоящий момент у NetApp нет. Для динамического кеширования данных на Flash у EMC есть FASTCache, использующий 64кб блоки и работающий как на чтение, так и на запись. Сравнивать размер блоков, которыми оперирует FAST и блоки на NetApp PAM картах некорректно, так как это совершенно разные продукты.

    ФАКТ: Преимущества tiering’a (FAST) не ограничиваются достижением более высоких IOPS/$. Смысл использования FAST - наиболее оптимальное использование ВСЕХ уровней хранения. Например, FAST автоматически перемещает “холодные” блоки на sata диски, что снижает общую стоимость хранения данных и повышает TB/$. Это позволяет более агрессивно использовать SATA диски, все известные мне конфигурации VNX с FAST поставляются с минимум 60-70% SATA ёмкостью. Кроме того FAST упрощает администрирование - на VNX с FAST можно использовать ОДИН fast-vp пул на всех типах дисков, в отличии от NetApp’a, где, насколько я знаю, приходится лепить несколько агрегатов, каждый для своего контроллера и своего типа дисков.

    По поводу примера базы с отчетами в конце квартала. Во-первых, когда FAST работает в автоматическом режиме, отдельные LUNы можно привязать к определенному уровню хранения. То есть если у нас есть хитрая база, которой нужно отдать приоритет, независимо от того, насколько активно она используется в обычное время, FAST можно настроить так, чтобы эта база всегда была на наиболее быстрых дисках. Во-вторых, перед вами не стоит выбор использовать FAST ИЛИ FASTCache, в большинстве случаев используется и то и другое одновременно. То есть ваша база, даже находясь на меделенных дисках, будет динамически кешироваться в FASTCache, так же как это работало бы на NеtApp PAM картах.

    ФАКТ: Весь прошлый год NetApp рассказывал, что tiering вообще не нужен, для этого даже придумали термин “tierless storage” . Осознав, что все основные конкуренты уже имеет эту функцию, что от неё есть прямая экономическая выгода и что на неё реально есть спрос на рынке, маркетинговую машину развернули на 180 градусов и назвали PAM карты “виртуальным” tiering’ом, хотя к tiering’у это прямого отношения не имеет.

    ФАКТ: NetApp начал терять долю рынка, -1.3% за последний квартал (было 11.6% в Q3 2010 стало 10.3% в Q4 2010 по данным IDC). Становится понятна причина такого количества “разоблачений” конкурентов, устроенных на блогах NetApp в последнее время. В краткосрочной перспективе это может сработать, посмотрим что будет дальше.

  6. Alex:

    deepblue, [вы неправы] /модерировано romx.. График с рыночными долями по данным IDC можно посмотреть хоть здесь: http://shop.nag.ru/uploads/NetApp%20NAG.pdf

    Доля NetApp в деньгах больше, чем вы указали и более того, никогда за время мониторинга не падала.

    По емкости же, несмотря на ваши разговоры о поставке все большего количества SATA дисков, доля EMC неуклонно падает.

    romx: использовать “левые” адреса email - лучший способ закончить в папке спама акисмета. Лучше у меня пользоваться настоящими адресами, у меня не спамят.

  7. deepblue:

    +Апдейт по моему последнему пункту: NetApp только что анонсировал положительные результаты за последний квартал. Посмотрим как это отразится на цифрах IDC

  8. Всем:

    О, сколько вы тут понаписали, пока меня не было в онлайне. Пойдем по-порядку.
    Первым делом я бы хотел указать, как стороне “за”, так и стороне “против”, что очень тяжело разговаривать с людьми, которые спорят с тобой не с тем, что ты написал, а с тем, что они _думают_ что ты написал. Прежде всего я бы призвал все спорящие стороны не “вчитывать”то, что автор не писал.
    В данном посте я стремился абстрагироваться от конкретных реализаций, и рассмотреть один вопрос. НЕ сравнение FASTwhatever с Flash Cache, а аргументировать сам подход, разобраться, что такое tiering ДЛЯ КОНЕЧНОГО ПОТРЕБИТЕЛЯ. Вне зависимости от его реализации.

    Теперь по авторам.
    Киселев Сергей:

    Мое мнение, что tiering в форме перемещения данных - тема раздуваемая искусственно.
    Тут параллельно в соседнем блоге мне человек утверждал, что, якобы, GB/$ есть более важная характеристика, чем IOPS/$, я с этим не согласен, так как при нынешних темпах роста (высоких) емкости дисков и (невысоких) их производительности, многие системы имеют избыток емкости, просто потому что определяющим параметром при их создании явился IOPS.
    Я уже писал по этому поводу раньше пост, о том, что “вы платите только за IOPS, гигабайты бесплатно”.
    Согласен со мной и, например, тест SPC-1, который измеряет IOPS/$, но игнорирует GB/$.
    В общем, мне кажется, что нынешняя возня вокруг tiering-как-перемещение есть довольно таки marketing inspired. По моему людей искусственно “делают несчастными” (”Маркетинг - искусство делать людей несчастными” (с)) рассказывая им как много они теряют, оттого что у них чего-то нет. :)

    Да, у NetApp _пока_ нет средства tiering-как-перемещение, зато есть много другого, и, например, есть средство, из которого такой tiering может, в случае необходимости, быстро появиться (я про vMotion for volumes).
    Ситуация аналогичная истории с SSD.

    Да, я согласен, что “иметь” это всегда лучше чем “не иметь”, но с экономической позиции все упирается в вопрос “готов ли клиент заплатить” за этот пир духа?
    А то получается история как в форумах люди ищут ноутбук “чтобы обязательно с USB 3.0!” при этом подключать к этому 3.0 нечего, да и не будет он его подключать.
    Или чтобы обязательно “тридэ летало”, а на офисном ноуте, для ворда, IE и “косынки” это “три дэ” только жрет электричество, греет воздух и стоит денег. Которые можно было бы потратить более разумно, с большей отдачей.

    Вот и вопрос, стоит ли этот tiering тех денег, или за его цену проще просто дополнительных дисков купить? Вот и я сомневаюсь. :)

    ЗЫ. А денег для клиента он стоит всегда, даже если им не пользоваться.

    ЗЗЫ. Еще раз обращу внимание: тема поста - мое мнение о том, что термин tiering правомочно примениить как к модели tiering-как-перемещение, так и к tiering-как-кэширование, так как с точки зрения конечного для клиента результата они идентичны.
    “Усы как у кошки, лапы как у кошки, хвост как у кошки, и ловит мышей - значит кошка”

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

  9. Василий Пантюхин:

    Василий, я бы хотел обратить ваше внимание на то, что для ваших целей вам бы стоило цитировать не меня, а официальные источники NetApp, которых хватает. Я для NetApp - “никто”, я в нем не работаю, и даже вовсе не имею формального отношения к компании. Поэтому высказываемое тут мной мнение, какое бы оно ни было, это мнение частного лица, а не NetApp.
    Если вас на этом поймают - вы “потеряете лицо” как специалист. Не знаю, насколько для вас это важно.

    > В этом посте вы, кажется, немного запутались в том, что критикуете.

    Еще раз вынужден отметить уже сказанное в ответе выше: в данном посте я вообще ничего не критикую, я показываю, что, по моему мнению, “tiering-as-datamoving” и “tiering-as-caching” есть для клиента продукты, делающие одно и то же, в его, кастомерском видении ситуации, поэтому и то и другое можно рассматривать как tiering.
    Это все, о чем я писал в данном посте. Если там в паре мест прорывается слово FAST, то оно появилось там по недосмотру, можно заменить его на EasyTier, или любой другой продукт, смысла поста оно не поменяет.

    PS/ Симметриксом я вряд ли когда-то займусь, и не просите :)
    Не мое поле, да и не интересное мне.

    > Не могли бы вы пояснить следующую фразу? …

    Я правда не думаю, что вы не в курсе того, чем кэширование записи, с точки зрения алгоритмической, сложнее операций кэширования чтения. Если у вас есть фига в кармане, заставляющая вас задать этот странный вопрос, лучше вам будет ее сразу показать :)

    UPD: Кстати, Василий, если вы считаете, что в своем посте про EMC (про VNX, как я понимаю) я где-то исказил истину, то, мне кажется, будет правильным вам мне на это искажение указать. Я уже говорил там, повторю еще раз: в системах EMC я не специалист, могу ошибаться, и с удовольствием ошибки исправлю. Думаю, что “и вашим, и нашим” будет только выгодно, чтобы ошибок было поменьше. В мои цели совершенно не входит распространять FUD (и тем более быть обвиненным в этом кем-либо). Мне кажется, что взвешенный и адекватный подход к продуктам конкурента пойдет на пользу обеим сторонам спора.

  10. Киселев Сергей:

    > Для меня пока остаётся открытым вопрос, как при использовании этих технологий работает обычный кэш СХД.

    Это описано в TR-3832: http://www.netwell.ru/docs/netapp/tr-3832_rus_flashcache_pam_best_practices.pdf

    Flash Caсhe является “кэшем второго уровня”, куда сносятся блоки данных, вытесняемые из “кэша первого уровня” - RAM контроллера. При чтении контроллер проверяет сперва обычный кэш в RAM, затем пространство Flash Cache, если блока нет ни там, ни там, то тогда начинается обращение к дискам и загрузка блока в “кэш первого уровня”.

  11. deepblue:

    > Вроде как тему закрыли

    Мой блог, что хочу, то и открываю :)

    > ФАКТ:

    О-о, маркетинговым духом запахло. :)
    Ваша ошибка в том, что вы называете словом “ФАКТ” его интерпретацию. Это нормально для
    специалиста по маркетингу, но порицается для инженера. :)

    > Аналогa FAST в настоящий момент у NetApp нет.

    …и весь пост я объясняю почему.

    > Преимущества tiering’a (FAST) не ограничиваются достижением более высоких IOPS/$.

    …но клиента, как правило, интересует только оно.

    > Например, FAST автоматически перемещает “холодные” блоки на sata диски

    Вот проблема в том, что не “блоки”, а “чанки”, содержащие эти блоки (и многие другие). Чанки, размером 1GB. Целый гигабайт!

    > ФАКТ: Весь прошлый год NetApp рассказывал, что tiering вообще не нужен, для этого даже придумали термин “tierless storage” .

    …и продолжает это говорить. Я - не NetApp, я высказываю свое личное мнение. Мнение это состоит в том, что tiering-as-datamoving для клиента, по достигнутому результату, идентичен tiering-as-datacaching,что позволяет их рассматривать как разные решения одной задачи, вместе. Поэтому я их и рассматриваю, со всеми их плюсами и минусами - вместе.

    > ФАКТ: NetApp начал терять долю рынка, -1.3%

    Фантастика! Паника, паника! Один и три десятых процента! (PS. При этом купил огромный кусок OEM-рынка с LSI (около 800 миллионов в revenue), не хотите подождать с предсказаниями? ;)

  12. deepblue:

    romx

    >> Преимущества tiering’a (FAST) не ограничиваются достижением более высоких IOPS/$.

    >…но клиента, как правило, интересует только оно.

    Бред. Если бы клиента интересовало только соотношение IOPS/$, то все использовали бы исключительно SSD диски, ведь на них можно получить больше всего IOPS в расчете на деньги. Но требования к ОБЪЁМАМ хранимых данных растут так же, как растут требования к производительности, в то время, как бюджеты на IT либо не меняются, либо вообще сокращаются. Как раз весь смысл динамического tiering’a в том, чтобы получить наибольшую производительность И наибольший объём в расчете на $. Следуя вашему же закону Парето, 80% данных можно считать “пассивными” и уложить на SATA диски. Сегодня EMC позволяет это сделать автоматически, а NetApp не может. Всё, чем в этой ситуации может ответить NetApp - это критиковать техонологию EMC (слишком большие “чанки” и т.д.). Ничего нового, короче.

  13. deepblue:

    Поспокойнее, пожалуйста, следите за своей речью, вы не в жежешечек, и не в форуме, здесь приличные люди. Оставьте свой тон для тех мест. Это вам второе предупреждение на этот счет.

    > Если бы клиента интересовало только соотношение IOPS/$, то все использовали бы исключительно SSD диски, ведь на них можно получить больше всего IOPS в расчете на деньги.

    Это не так, простая арифметика.

    > Но требования к ОБЪЁМАМ хранимых данных растут так же, как растут требования к производительности

    При выполнении требований по производительности, обычно требования по объемам получатся сами собой.

    Вы совсем не читаете меня, продолжая твердить свое. С вами трудно спорить, не думайте, что это хорошая тактика в споре - не слушая оппонента долбить свое.
    Нет смысла вам отвечать, если вы все равно это не читаете.

    > Следуя вашему же закону Парето, 80% данных можно считать “пассивными” и уложить на SATA диски. Сегодня EMC позволяет это сделать автоматически, а NetApp не может.

    Может. В том-то и дело. Мы их там и храним. Сразу же. “Где вы храните картошку? - На базаре”.
    NetApp показал, кстати, свои результаты такой системы, с SATA в качестве основного хранилища, и с Flash Cache, в качестве “оперативного”. Они весьма хороши.

    Хотелось бы увидеть результаты FAST/FASTcache.
    Если он хороши, то отчего бы их не показать? Это был бы убойный аргумент.

    > Всё, чем в этой ситуации может ответить NetApp - это критиковать техонологию EMC (слишком большие “чанки” и т.д.).

    Но чанки в самом деле слишком большие. К чему придуывать что-то еще для критики, поборите сперва эту проблему. На сегодня чанк у Clariion в FAST - _самый_ большой из _всех_ систем tiering-а на рынке!

  14. deepblue:

    >> Если бы клиента интересовало только соотношение IOPS/$, то все использовали бы исключительно SSD диски, ведь на них можно получить больше всего IOPS в расчете на деньги.

    >Это не так, простая арифметика.

    Это так, по крайней мере для систем ЕМС. SSD диски заметно упали в цене за последние пару лет и в расчете IOPS/$ они более выгодны, чем остальные виды носителей. Поэтому они и получили такое распространение, особенно после появления FAST/FASTCache. На сегодня ЕМС поставил 14 Петабайт Flash памяти, что больше, чем любой другой производитель систем хранения.

    >> Следуя вашему же закону Парето, 80% данных можно считать “пассивными” и уложить на SATA диски. Сегодня EMC позволяет это сделать автоматически, а NetApp не может.

    >Может. В том-то и дело. Мы их там и храним. Сразу же. “Где вы храните картошку? - На базаре”. NetApp показал, кстати, свои результаты такой системы, с SATA в качестве основного хранилища, и с Flash Cache, в качестве “оперативного”. Они весьма хороши.

    Вы готовы рекомендовать такую систему, построенную ТОЛЬКО на SATA дисках и PAM картах для нагруженной продакшен системы со стандартным набором из баз данных, файловых данных, виртуализации и т.д. ? Если да, то исходя из вашего закона Парето, сколько flash памяти вам придётся в эту систему запихать, чтобы уместить там 20% активных данных?

  15. > Вы готовы рекомендовать такую систему, построенную ТОЛЬКО на SATA дисках и PAM картах для нагруженной продакшен системы со стандартным набором из баз данных, файловых данных, виртуализации и т.д. ?

    Вы не поверите, ее рекомендует к такому использованию даже сам NetApp (что там я, куда мне;). Естественно есть тонкие моменты, которые, в отдельных случаях, помешают использовать систему хранения именно так, но это единичные, частные случаи.

    > Если да, то исходя из вашего закона Парето, сколько flash памяти вам придётся в эту систему запихать, чтобы уместить там 20% активных данных?

    (Устало) Я об этом уже говорил дважды, вам же и говорил. Это же кэш, это динамическое хранилище. В этом его преимущество перед статическим перемещением данных.
    Вот в терабайтном диске кэш - 16 _мегабайт_, это тысячные доли процента от объема, и ничего, кэширует, ускоряет доступ, еще как!

    Но если надо на самом деле _много_ кэша, то по максимуму, в самую старшую - 8 плат в контроллер, по 512GB плата, то есть 8TB на HA-пару контроллеров. С выходом плат на 1TB и новой версии Data ONTAP, подозреваю, что будет вдвое больше. Поверьте, это дофига и больше.

  16. deepblue:

    >Вы не поверите, ее рекомендует к такому использованию даже сам NetApp (что там я, куда мне;). Естественно есть тонкие моменты, которые, в отдельных случаях, помешают использовать систему хранения именно так, но это единичные, частные случаи.

    Что-то мне подсказывает, что таких “частных” случаев большинство. Какой бы ни был быстрый и динамический кеш, если он составляет Но если надо на самом деле _много_ кэша, то по максимуму, в самую старшую - 8 плат в контроллер, по 512GB плата, то есть 8TB на HA-пару контроллеров. С выходом плат на 1TB и новой версии Data ONTAP, подозреваю, что будет вдвое больше. Поверьте, это дофига и больше.

    Получается, что NetApp собирается компенсировать недостатки функционала добавлением таких больших PAM-плат, удачи NetApp’у в попытках продать ЭТО заказчикам.

  17. deepblue:

    Наш спор переходит в неконструктивную фазу. Я привожу аргументы, ссылки на результаты, а вы встали в “глухой партер” вида “а мне кажется, что это все не так, сплошной обман, и работать не будет. Потому что я не верю.”

    FAS3140 (SATA Disks with Flash Cache) - SPECsfs2008v3 CIFS
    FAS3210 (SATA Disks with Flash Cache) - SPECsfs2008v3 CIFS

    NetApp FAS3270A with Flash Cache in SPC-1/E

    Flash Cache and PAM Best Practices Guide
    Flash Cache in File Services Workloads
    NetApp Flash Cache in Windows File Services Workloads
    Using NetApp Flash Cache (PAM II) in Online Transaction Processing
    Using Flash Cache for Exchange 2010
    NetApp FAS3210 6000 Mailbox Exchange 2010 Mailbox Resiliency Storage Solution

    > удачи NetApp’у в попытках продать ЭТО заказчикам.

    Вы знаете, даже никакой особенной удачи при этом не нужно, продается - “тока в путь”, даже в России, вовсю, не первый год.

  18. Александр:

    > удачи NetApp’у в попытках продать ЭТО заказчикам.

    Сам пока не пользую, но встречался с ТАКИМ заказчиком. Людям помогло.

    deepblue: Я не понимаю как можно спорить против фактов (предоставленных romx) и против логичности подхода организации PAM…

    Кстати, товарищи из Ингосстраха на VMax’e используют FAST - судя по лицам счастливы (на EMC Forum 2010 рассказывали).
    Я в FAST не верю т.к. на OLTP задачах все же лучше работать с кэшем (чем по сути и является PAM) т.к. пока там FAST перетащит данные они могут уже протухнуть.

    по поводу замечания Василия.
    Залез на Powerlink и почитал доки. Да FAST у Symmetrix’a отличается от Calriion’a

    Про Clariion:
    FAST works at a granularity of 1GB. Each 1GB block of data is referred to as a slice. When FAST relocates data, it will move the entire slice to a different storage tier.

    Про Symmetrix FAST VP:
    The size of data movement can be as small as 768Kb, representing a single allocated thin device extent, but will more typically be an entire extent group, which is 7680Kb in size.

    Про Symmetrix FAST:
    Есть забавный параметр “Maximum Moves Per Day” можно установить от 2 до 200… не такой он уж и “Fully Automated” ;)
    Не нашел только какими “блоками” обычный FAST кидается на VMax’e

  19. Александр:
    > Да FAST у Symmetrix’a отличается от Calriion’a

    Вот в том-то и путаница, что две довольно различные реализации называются похоже “до смешения”, и всегда приходится уточнять, о каком именно FAST говорит оппонент, о том, что для Symmetrix, или о том, что для Claeiion?

    > Есть забавный параметр “Maximum Moves Per Day” можно установить от 2 до 200… не такой он уж и “Fully Automated” ;)

    Злые языки уже иронизировали про PAST - Partially-Automated Storage Tiering, в первой версии еще и вручную аппрувить перемещения в консоли надо было. ;)

    > Не нашел только какими “блоками” обычный FAST кидается на VMax’e

    768KB в слайсе.

  20. deepblue:

    Александр:

    >Сам пока не пользую, но встречался с ТАКИМ заказчиком. Людям помогло.
    >Я не понимаю как можно спорить против фактов (предоставленных romx) и против логичности подхода организации PAM…

    Я ж не спорю, что кеширование на flash помогает увеличить производительность. Просто я считаю абсурдной идею, что PAM карты могут заменить tiering и что с PAM картами можно удовлетворить потребности в производительности ВСЕХ заказчиков, используя ТОЛЬКО SATA диски, особенно это касается транзакционных задач. Сам NetApp это косвенно подтверждает, посмотрите детали SPC теста, который выше привел romx, SATA дисками там не пахнет:

    http://www.storageperformance.org/benchmark_results_files/SPC-1E/NetApp/AE00004_NetApp_FAS3270A/ae00004_NetApp_FAS3270A_SPC1E_executive-summary.pdf

    Непонятно, в чем меня здесь пытаются убедить, раз сам NetApp продолжает использовать FC/SAS 15k диски для таких тестов.

  21. deepblue:

    > Сам NetApp это косвенно подтверждает, посмотрите детали SPC теста, который выше привел romx, SATA дисками там не пахнет:

    Ну так там и задача совсем другая, и контроллер - FAS3270 это ж почти хайэнд, самый старший в мидрендже, он практически равен по мощности самому младжшему hiend FAS6210.
    Было бы более чем странно нагружать на тест производительности такой мощный контроллер полками SATA, это дало бы явную несбалансированность, потому и SAS.

    Почему вы решили, что Flash Cache должен обязательно работать с SATA? Он и SAS также успешно ускоряет. В данном случае - SAS, в более простых и с меньшими запросами задачах - SATA. Очень гибко.

    Вы не выдергивайте ФАКТ(tm) из контекста, нехорошо ;)

  22. deepblue:

    Вы же сами только что утверждали, что NetApp рекомендует оперативные данные прямо сразу на SATA класть и таким образом обходиться без динамического tiering’a. И тут вдруг выясняется, что такая конфигурация с PAM картами и с одними SATA дисками - несбалансированная. Вы уж как-нибудь определитесь для начала со своими рекомендациями.

    > Почему вы решили, что Flash Cache должен обязательно работать с SATA? Он и SAS также успешно ускоряет. В данном случае - SAS, в более простых и с меньшими запросами задачах - SATA. Очень гибко.

    В том то и дело, что когда _или_ SAS _или_ SATA - это совсем не гибко, а динамически перемещать данные NetApp не умеет. Денег на разработку не хватило, как вы сказали тут в одном из комментариев.

  23. deepblue:

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

    Вам правда непонятно, отчего мощный контроллер системы хранения на тестирование производительности выставляют не с SATA-дисками, а с SAS?

    Почему бы вам все же не проявить минимальную конструктивность, и хотя бы не попытаться понять то, о чем я вам тут уже битый день толкую? К чему это упорство? Это троллинг такой? Или вы правда тупите?
    Скажите, я пойму, я тоже бывает иногда туплю.

  24. deepblue:

    romx:
    Спасибо, к этому всё и шло. Мне действительно не понятно, как “мощный контроллер с SAS дисками” может сэкономить кому-то денег без возможности динамически перекладывать холодные данные на SATA. [...] /модерировано romx.

  25. deepblue:

    В таком случае мой вам совет - подумать над этим и постараться понять. Пока воздержитесь от написания новых комментариев, прочтите все то, что было написано тут ранее, свои соображения можете написать мне на romx@mail.ru, тут их писать не нужно. Спасибо за понимание.

  26. Andrey:

    Fight, fight :)

    Romx: расскажите лучше, какие пути апгрейда с FAS3020 на новые головы.
    Есть ли какие программы апгрейда?
    Две петли, на одной SAS полки, на другой SATA.

  27. Andrey:

    Да тут не fight, к сожалению, а trolling. :(

    А что рассказывать-то, существует стандартная процедура.
    http://www.box.net/shared/dj2bb0f4iinbh360746m
    Целиком не покажу, потому что она почему-то считается NetApp confidential, но она есть, 6 страниц пошагового руководства замены “голов” 3020/50 на 32xx (как и для других систем, кстати говоря).
    Она доступна тем, кому это приходится делать.

    PS. Повторно намекаю, что использование в качестве email в данном блоге адреса вида xxx@xxx.com его автор может счесть проявлением неуважения к себе, как автору, и блогу в целом, и в следующий раз может уже и не вытаскивать ваш комментарий из кучи спама, отфильтрованного акисметом.

  28. Andrey:

    Обязательный email в форме не есть хорошо. Может я не хочу его сообщать.
    Выглядит как сбор мейлов :)

    У нас уже старая голова (FAS3020). Интересно сравнение ее с новыми системами, насколько они более производительные, какие benefits получим.
    Интересует сравнение 2020 vs 3120 vs 32×0, etc
    Куда имеет смысл двигаться ?

    И есть ли программы апгрейда, когда старая голова идет в зачет.
    Технические детали перехода, конечно, тоже важны. Если придется пересоздавать агрегаты - то это жжжж.

    Может статейку по сравнению поколений ? :)

    Дедупликация больше всего выигрыша даст на vmfs, если VM машинки одного типа ОС.

    Блог читаю набегами. Я бы назвал Вас - NetApp евангелист ;-)
    Спасибо за интересные статьи, многие вещи узнаешь от Вас.

  29. > У нас уже старая голова (FAS3020). Интересно сравнение ее с новыми системами, насколько они более производительные, какие benefits получим.

    В первую очередь, конечно, поддерживаемость железа, FAS3020, насколько я помню, уже EOL.

    Производительность, конечно же. Data ONTAP 8.x, карты расширения PCIe.

    > Интересует сравнение 2020 vs 3120 vs 32×0, etc
    > Куда имеет смысл двигаться ?

    С 2020 смысла сравнивать нет, во первых это, с точки зрения дальнейшего развития, тупиковая система. Если стоит задача получить просто новую, поддерживаемую систему из старой 3020, то по производительности ее ближайший аналог, пожалуй, FAS2040.
    Однако если есть планы по дальнейшему росту, то надо ориентироваться на 32хх, безусловно.

    > И есть ли программы апгрейда, когда старая голова идет в зачет.

    В Америке - да, есть такое. В России это связано с реэкспортом, что, как вы понимаете, создает такое немыслимое количество гемороя, что заниматься этим никто не будет.
    Уж не говоря, что EOL-система уже не нужна никому, она на eBay стоит тыщи три долларов сейчас.

    > Технические детали перехода, конечно, тоже важны. Если придется пересоздавать агрегаты - то это жжжж.

    aggregates придется пересоздавать (до появления “конвертера”) при переходе на 8.х c 64-bit aggregates. При оставлении в рамках линейки 7.x или при использовании 8.x c 32-bit aggregates пересоздавать аггрегейты не нужно.

    > Обязательный email в форме не есть хорошо. Может я не хочу его сообщать.
    > Выглядит как сбор мейлов

    Ну в каждом доме свои правила. В моем - вот такие. Если вы не согласны - можете не писать сюда, всех и делов. Ваш email нигде не публикуется, разве только вы так изящно, между делом назвали меня спаммером.
    Я уже объяснил вам, что комментарии с такими “емэйлами” немедленно валятся в спам, откуда их приходится восстанавливать руками, если успею обнаружить до автоочистки. Меня это утомило, и больше я их спасать оттуда не буду.

  30. [sidenote] Жалко, что-то RSS тормозит, приходится раз в пару недль сюда прямиком заходить[/sidenote]

    Кстати, мне с самого начала было интересно: как FlashCache борется с таким характерным паттерном размывания кэша, как линейное чтение больших объёмов (типа потоковой обработки видео или полного бэкапа LUN)? Информации об этом я пока нигде не нашёл, но, может, искал плохо.

  31. По производительности официальные документы, кроме тестирований SPEC SFS и SPC-1 не публиковались, но частным образом могу сказать, что 3140 производительнее 3020 вдвое, на почти любом типе нагрузки. 3210 производительнее 3140 примерно процентов на файловой, примерно равен на OLTP, и процентов на 40 быстрее на DSS (large sequental read).
    3240 быстрее 3140 всюду и всегда (примерно в 1,7..2,0 раза).

    Но это неофициальные данные, и за руку меня (или NetApp) не ловите :)

    > Дедупликация больше всего выигрыша даст на vmfs, если VM машинки одного типа ОС.

    Не обязательно. Она дает выигрыш в случае идентичных данных, а уж будут это VM, файлы с “нулями” или “единицами”, или каким-то чередующимся паттерном - это уже детали.

  32. > Жалко, что-то RSS тормозит, приходится раз в пару недль сюда прямиком заходить

    Это какой такой RSS тормозит? Я вот сам на себя подписан в Google Reader, так все приходит сразу после публикации.

    > Кстати, мне с самого начала было интересно: как FlashCache борется с таким характерным паттерном размывания кэша, как линейное чтение больших объёмов (типа потоковой обработки видео или полного бэкапа LUN)? Информации об этом я пока нигде не нашёл, но, может, искал плохо.

    На таком паттерне просто не рекомендуется изпользовать Flash Cache, и NetApp вообще.
    В принципе, если такая задача есть только на каких-то определенных томах системы, то можно FlexCache (софтверный компонент кэширования на уровне Data ONTAP) отключить, или же, если необходимо, есть три разных режима кэширования: “Только метаданные”, “high-priority данные” (по умолчанию) или “все данные” (полное кэширование, включая все данные, в том числе low-priopity. sequental read это как раз low-priority data.
    Некоторое описание есть в соответствующем TR, есть по нему даже перевод.

  33. > Это какой такой RSS тормозит?

    Наврал, это не RSS, это сторонний транслятор

    http://aboutnetapp.livejournal.com/profile?mode=full

    И он не тормозит, он сломался 5 мая совсем.

    > то можно FlexCache отключить, или же, если необходимо, есть три разных режима кэширования

    Ага, это уже существенно лучше, спасибо.

  34. > И он не тормозит, он сломался 5 мая совсем

    Это в жеже глюки, посмотрю при случае. Но лучше, если уж нужен RSS, то подписаться на этот вот:
    http://blog.aboutnetapp.ru/rss

  35. Andrey:

    Грустно, что голова 3 года отработала и нужно ее выкидывать (а так же еще 100 штук). Обьемы растут, iops-ов требуется тоже больше.

    Btw насколько будет больше оверхед от раздачи файлов через смонтированный lun на файлсервере по iSCSI vs cifs ? Насколько будет больше busy cpu, iops ?

  36. bbk:

    2romx
    У вас в этом посте очепятка http://blog.aboutnetapp.ru/archives/926#comment-1431
    вместо Flash Cache, получился “FlexCache”. Блин я сам иногда их путаю, надо ж было их так назвать похоже. По-моему НетАпу стоило отставить название PAM II - оно и более логично (типа кэш второго уровня) и нет пересечений в названии.

  37. Люба:

    “Tiering-ом (увы, русскоязычного термина пока не прижилось, будем использовать такое)”

    На форуме NetApp Innovation EMEA - 2012 термин “virtual tiering” на русский переводился как “виртуальное эшелонирование” (видимо, по аналогии с авиацией).

  38. Люба:

    Спасибо, действительно, “эшелонирование” или же “ранжирование” будет, наверное, наилучшим вариантом, но во мне, как в переводчике, все равно все восстает от такого перевода.

Оставить комментарий

20/0.191

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.