Flash Cache 1TB
Без особого шума обновилась информация о доступной конфигурации плат Flash Cache (PAM II), нетапповского средства Virtual Tiering, представляющего собой плату с SLC Flash, между дисками и собственно системным кэшем контроллера, и позволяющего значительно повысить производительность в IOPS, без необходимости увеличивать количество дисковых шпинделей.
От SSD это решение отличается тем, что его емкость занимают только “горячие”, активные данные, то есть высокопроизводительный объем flash занимается максимально эффективно, а от auto-tiering, наподобие EMC FAST это отличается полностью автоматической работой, быстротой заполнения и гибкостью использования, так как минимальный “квант” tiering-а равен блоку WAFL – 4KB, в отличие от огромного, размером 1Gb, сегмента, которым оперирует EMC FAST.
Результаты производительности систем хранения с платами Flash Cache широко опубликованы, например в тестах SPEC SFS (NFS/CIFS) и в тестах SPC-1/E (SAN), и они широко продаются с системами хранения NetApp, утверждается, что ныне каждая четвертая система из всех, продаваемых NetApp идет с Flash Cache..
До сих пор были доступны платы с объемом 256 и 512Gb SLC Flash, теперь к ним добавилась плата с 1Tb, доступная для самых старших систем – 6200 и 3270. Доступность к заказу объявлена с 13 июня.
Как побочный результат это также означает, что к 13 июня должна также выйти система Data ONTAP 8.0.2, которая необходима для работы этих модулей.
Сравнение некорректно, аналога FAST у NetApp’a нет, FlashCache является аналогом FASTCache.
deepblue:
Об этом мы обязательно поговорим несколько позже.
А пока же, в качестве анонса: с точки зрения “сверху”, то есть пользователя (и программы, использующей систему хранения), любой tiering суть одно и тоже, если смотреть со стороны функциональности. А уж как он реализован, с переносом данных на другие диски, или с переносом данных “не в диски” а на кэш-пространство, это уже детали реализации. С точки зрения пользователя (и программы, использующей сторадж) и то и другое имеет одну цель - увеличение производительности работы с “горячими” данными, за счет снижения latency и увеличения показателей в IOPS. А уж какими средствами это достигается - дело второе.
Не совсем верно. Цель FASTCache и FlashCache - увеличение производительности с помощью кеширования данных. Цель FAST - оптимальное размещение данных между разными типами дисков (не только SSD). Например, FAST позволяет агрессивно использовать SATA или SAS-NL диски (75-80% от общей ёмкости), алгоритм сам позаботится о том, что на эти диски будут перемещены только “холодные” данные.
deepblue:
> Цель FAST - оптимальное размещение данных между разными типами дисков
Да, но _зачем_ нужно это “оптимальное размещение”? Я считаю, что цель этого - увеличение производительности, и, как конечный результат, эффективности использования пространства хранения, когда “горячие” данные отдаются с более произвдительного и дорогого хранилища, а “холодные” (или “не такие горячие”) отдаются с менее производительного, и, обычно, более дешевого в эксплуатации.
То есть конечный критерий использования у нас все тот же показатель IOPS/$.
Он повышается в случае использования как FAST, так и FASTcache.
С этой точки зрения (улучшения показателя IOPS/$) все системы tiering-а занимаются одним и тем же.
Заказчики используют автоматический tiering, чтобы не заниматься переносом данных между разными типами носителей вручную. Например, какое-то время мой проект активный и его данные лежат на более дорогих 15к SAS или FC дисках. Через пол-года этот проект закрывается и хотя данные всё ещё нужны в “онлайне”, производительность больше не критична, и файлы можно перенести на недорогие, но медленные SAS-NL или SATA. ?? таких проектов, допустим сотни. Как эту задачу решит FASTCache или FlashCache? SSD для такой задачи может оказаться слишком дорогим решением.
Вообще то, что PAM карты назвали virtual tiring - это прекрасный маркетинговый трюк. Господа маркетологи осознали, что tiering - это одна из “горячих” тем в индустрии (см, например Compellent - компания добилась колоссального успеха у сервис провайдеров за счет одной этой фичи), которая пока не реализована на НетАппе. Но надо же было чем-то крыть. А не назвать ли наши старые добрые PAM карты tiering’om? Пускай это не совсем тоже самое, ну так назовём его “виртуальным”, чтобы никому не было обидно.
На протяжении нескольких лет FAS был супер успешным продуктом, во многих случаях это был лучший выбор по сравнению с заточенными под блоковые данные массивами. К сожалению, это не могло продолжаться вечно, и как только NetApp столкнулся с серьёзной конкуренцией, это вызвало очень некрасивую реакцию в медиа и на блогах NetApp. “Это не настоящий юнифайд!” - как же это похоже на риторику EMC трех-пяти летней давности “Это не настоящий fibre channel!”. EMC сделали вывод из своих ошибок, закатали рукава, вложились в разработку и сделали достойный продукт. Посмотрим, чем теперь ответит NetApp, пока что вся эта волна FUD’a выгладит совсем неубедительно. В любом случае конечный пользователь оказывается в выигрыше, конкуренция никому никогда не вредила.
Вообще в ответ на серию постов про EMC на этом и других NetApp блогах, я бы посоветовал всему менеджменту NetApp’a, отвечающему за стратегию компании, прочитать замечательную книгу Спенсера Джонсона “Who Moved My Cheese”.
> 256 и 512Mb SLC Flash, теперь к ним добавилась плата с 1Gb
Порядок не потерян? ;)
dmarck:
Потерян, конечно, спасибо, что внимательно читаете. :)
deepblue:
> Заказчики используют автоматический tiering, чтобы не заниматься переносом данных между разными типами носителей вручную.
Не-не-не, вы опять ставите телегу впереди лошади.
Ответьте на вопрос ЗАЧЕМ они “занимаются переносом данных между разными типами носителей”.
Чего они таким образом стараются достичь в результате?
Не мыслите “технократически”, мыслите в терминах задач клиента!
Я утверждаю, что единственная цель этих действий - в повышении величины эффективности, то есть увеличения выдачи полезного результата, прежде всего величин производительности, на вложенную единицу затрат. Цель - получить больше результата, с того же бюджета.
Отсюда и перемещения менее важных, менее критичных к быстродействию данных, на объемы хранения с меньшей ценой хранения, и более важных - на более быстродействующие, но и более дорогостоящие, получая, в результате, улучшение показателя IOPS/$.
Вот ради чего все.
?? если подойти к задаче с точки зрения клиента, то совершенно неважно, какими именно средствами это будет достигнуто. “Неважно какого цвета кошка, если она хорошо ловит мышей”. Неважно, будет ли это real fibe… э-э… простите ;) real tiering, или virtual tiering, если в результате клиент получит то, что он хочет в результате получить - повышение эффективности в терминах бюджета.
ЗЫ. ??ногда мне кажется, что вы совсем не читаете, что я вам пишу. :(
> как же это похоже на риторику EMC трех-пяти летней давности
Ах, если бы “трех-пяти”… Еще в октябре 2010 года Чак писал об этом-же самом. Я же давал ссылку.
“I think that’s been one of the advantages of EMC’s Celerra over the years — the FC SAN connects to an underlying EMC CLARiiON (and is not emulated by the file system). When you need a real SAN, you’ve got a real SAN.”
> В любом случае конечный пользователь оказывается в выигрыше, конкуренция никому никогда не вредила.
Вот тут не могу не согласиться. Пример - прекрасный продукт NetApp, многие годы не имевший никакого конкурирующего решения на рынке - Metrocluster, находится сегодня, с точки зрения разработки, в откровенном застое, и хоть сколько-нибудь начал шевелиться только с появлением VPLEX.
Конкуренция, безусловно, это благо.
Но вы вообще странно реагируете на критику. Вы считаете, что любой продукт надо только хвалить и гладить? Пусть этим занимается отдел маркетинга, это их профессиональные скиллы.
Кстати наберитесь терпения, у нас с вами в серии про VNX впереди еще один пост, и, надеюсь, до каких-либо крупных изменений у EMC (надеюсь, в положительную сторону), пока надолго все с ними.
Ок,
Наверное я “непонятно объяснил”. Ответьте мне на простой вопрос. Если в реальных конфигурациях, поставляемых сегодня, объём Flash составляет 2-5% от общего объёма (не важно, в виде PAM или в виде FASTCache), то что прикажете делать пользователям с остальными 98-95% данных? Сегодня тут собственно есть 3 варианта:
1. Заполнить остальное пространство FC (SAS) дисками. Это дорого.
2. Заполнить остальное пространство SATA (SAS-NL). Если это рекомендация NetApp, то я свой вопрос снимаю. В реальной жизни я не знаю проектов, где только 3% данных активные, а все остальные можно было бы положить на SATA, ни один из известных мне заказчиков это сделать не рискнул бы.
3. Заполнить остальное пространство комбинацией SAS/SAS-NL дисков. Это, то, что я вижу в реальных проектах сегодня. Раз NetApp заявляет, что имеет некий функционал для tiering’a, то каким образом предполагается _автоматически_ пареносить данные между этими двумя уровнями хранения? Ответ простой - такого функционала в NetApp нет, и пользователям либо приходится переносить данные ручками, либо покупать больше FC/SAS дисков, чем нужно. $/IOPS сам по себе не даёт полной картины о производительности системы, если все IOPS’ы можно получить только с 3% данных. ??, ещё раз, FlashCache и FASTCache занимаются копированием данных (кешированием) на SSD диски, FAST занимается переносом данных между 3 уровнями хранения (EFD/SAS/SAS-NL). Я продолжаю утверждать, что здесь есть принципиальная разница, и, например, сравнения размеров блока у FlashCache и FAST некорректно.
Кстати, если это здесь кому интересно (romx’a помнится очень интересовали конкретные цифры), ЕМС вчера сделал несколько анонсов по этой теме:
* Сегодня 60% VNX поставляется с SSD дисками.
* На сегодня ЕМС поставил 14 Петабайт Flash памяти, что больше, чем любой другой производитель систем хранения.
* ЕМС будет поддерживать MLC диски - более дешевый вариант SLC SSD, который используется в системах хранения ЕМС сегодня. FAST-VP здесь придется очень кстати.
* Самое интересное - раскрыли некоторые детали проекта “Lightning”. EMC будет поставлять PCIe Flash карты для серверов (а ля FusionIO) + софт который будет отвечать за tiering между этими картами и кешем в системах хранения.
Больше деталей здесь:
http://virtualgeek.typepad.com/virtual_geek/2011/05/understanding-project-lightning.html
deepblue:
> Ответьте мне на простой вопрос. Если в реальных конфигурациях, поставляемых сегодня, объём Flash составляет 2-5% от общего объёма (не важно, в виде PAM или в виде FASTCache), то что прикажете делать пользователям с остальными 98-95% данных?
Ответить несложно. Это ведь кэш! Это _динамические_ “3%”!
У вас ведь не возникает такого вопроса, например, к процессору Intel Xeon, в котором кэша 8Mb, а объем памяти в сервере, в котором он работает, допустим - 48Gb, что составляет куда меньше, чем даже 3%, но все же он эффективно работает, и значительно увеличивает его быстродействие, и быстродействие системы в целом.
В отличие от “статического” tiering-а, например FAST, эти 3% всегда заполнены только активно доступаемыми данными, которые постоянно меняются, если к данным перестали обращаться, то через какое-то время они окажутся безболезненно “вытесненными” из этого пространства, и их место займут более активные. В том-то и дело, что данные в этих “3%” не “лежат”, в отличие от FAST!
Это принцип кэша, конечно всегда хочется, чтобы кэш был побольше, но даже кэш, размером в единицы, и даже доли процента от общего объема данных, является средством, повышающим эффективность работы и скорость доступа к данным.
ЗЫ. Прошу простить за долгий ответ. Мои комменты тут - малопригодное место для развернутой дискуссии, я вполне могу пропустить появившийся комментарий :(
Вы продолжаете сравнивать яблоки с апельсинами, сравнивая FlashCache и FAST, хотя у ЕМС есть FASTCache, который и является аналогом FlashCache (с некоторыми различиями в реализации). Чувствую, что беседа в очередной раз зашла в тупик, на мой вопрос вы так и не ответили, как-будто идет разговор слепого с глухим. Можно ли на NetApp каким-то образом динамически перемещать данные между ВСЕМ?? уровнями хранения, в зависимости от активности использования этих данных, что в простонародье называется tiering’ом? (а не только кешировать активные данные в flash для повышения производительности, чем занимается NetApp FlashCache и EMC FASTCache).
??менно динамическим перемещением данных между ВСЕМ?? уровнями хранения занимается EMC FAST. Это позволяет не только увеличить производительность IOPS/$, но и упростить администрирование (не нужно возиться с несколькими агрегатами, достаточно иметь всего один пул на всю систему), снизить стоимость хранения статических данных, автоматически перемещая их на SAS NL/SATA диски (tier-3) и т.д.
deepblue:
Да, правда, диалог пошел по кругу. Я не могу понять вашу аргументацию, в свою очередь мне не удается понятно объяснить вам, отчего я считаю, что если достигнута конечная цель применения tiering-а, улучшение показателей эффективности (IOPS/$) использования хранилища, то совершенно неважно, каким образом физически он реализован, с помощью перемещения данных или с помощью кэширования.
Давайте закруглим на этом наш пока бесплодный спор. Будем считать, что мне перед вами защитить мою позицию не удалось. :)
Вообще-то актуальный размер блока под FAST - 64 Kb, а в остальном , ну ооочень много безобразного флуда, такое ощущение, что NetApp очень хочет хотя бы в блогах показать себе на одном уровне с ЕМС. Будучи ЕМС-сторажистом и поработав немного с NetApp-ом ,крайне рад,что я EMC-сторажист))
11:
Вообще-то 64KB размер блока не у FAST, а у FASTcache, и удивительно, что их путает “EMC-сторажист”, а поправляет его “NetApp-сторажист”, что-то надо в SE-подготовке у EMC править :)