EMC FASTcache и NetApp Flash Cache
Как мне тут не раз уже попеняли, некорректно сравнивать tiering-as-datamoving и tiering-as-caching, то есть, например, NetApp Flash Cache и EMC FAST VP. Допустим, как я ни старался в соответствующей статье, я вас не убедил, что обе эти формы повышения эффективности системы хранения для пользователя есть суть одно.
Хорошо, давайте рассмотрим отдельно особенности, достоинства и недостатки только Flash Cache (PAM-II) и FASTcache.
Во первых, конечно, вы бы могли вместе со мной поехдничать о извилистом пути достижения цели у EMC. Сперва превратить flash-память в "диски" в форме SSD, а затем из этих дисков эмулировать "память" кэша. Ну ладно, допустим не смогли напрямую, оказалось проще через "двойную эмуляцию".
Во-вторых если мы посмотрим на то, как у EMC предполагается использовать SSD диски под FASTcache, вы, уверен, вместе со мной поразитесь неффективности.
Допустим, мы разворачиваем систему хранения для 1000 рабочих мест под десктопную виртуализацию на XenDesktop. Рекомендуемая схема включает в себя три диска SSD, из которых один - hotspare, а два других образуют "зеркало" RAID-1. Таким образом, очевидно, что эффективность использования flash в такой конструкции будет примерно 33%, то есть одна треть от купленной емкости flash. Да, при увеличении объема FASTcache, кроме роста цены будет расти и эффективность использования, но она никогда не превысит 50%, за счет использования RAID-1 (плюс hotspare). Больше половины затраченных на SSD денег будут простаивать. По контрасту, если вы покупаете 256GB Flash Cache, вы можете использовать под кэширование и ускорение работы с данными все 256GB, сто процентов от затраченных на них денег.
В третьих, стоит обратит внимание, что использование SSD как дисков вынуждает EMC разместить этот кэш "снаружи" контроллера, в "петле" дискового ввода-вывода на интерфейсе SAS. В то время, как у NetApp плата Flash Cache располагается непосредственно на системной шине контроллера, на PCIe (PCIe v2.0 x8 в моделях 3200/6200, пропускная способность 32Gbit/s в каждом направлении). То есть взаимодействие контроллера с кэшем в случае FASTcache такое: данные пришли через ввод-вывод на контроллер, по каналу SAS к дискам, вышли через другой порт и записались на SSD по интерфейсу SAS. Затем, если к данным кэша обращение, они должны считаться через дисковый канал ввода-вывода по SAS обратно в контроллер, и отдаться через третий канал ввода-вывода, собственно инициатору запроса, по FC или iSCSI, или NFS/CIFS. Все это, безусловно, нагружает и так не бесконечные возможности дискового канала ввода-вывода к полкам, и, потенциально, может привести к ограничению производительности.
Наконец, стоит помнить, что, хотя в FASTcache удалось значительно снизить размер оперируемого "чанка" до 64KB, против гигабайта в FAST-"просто", все же этот размер достаточно велик для многих задач, работающих в random read/write, размер блока кэша, значительно превышающий рабочий для соответствующей файловой системы или задачи, например блока базы данных, также снижает эффективность использования такого кэша, если, допустим, только 4KB из блока в 64KB нам действительно нужны (при 100% random это довольно обычная ситуация), то это значит, что эффективность кэша составляет лишь 1/16 от своего фактического объема.
Что же в плюсах? Очевидно, что это активно "педалируемая" EMC возможность работы такого кэша на запись. Особенно на это нажимают в сравнении с NetApp Flash Cache, который на запись не работает, и эта возможность действительно производит впечатление на тех людей, которые не особенно разбираются как там у NetApp все устроено, и знают только то, что "что-то иметь это гораздо лучше чем не иметь", и уж все знают, что запись надо кэшировать, без кэширования запись на диски очень медленная, это знает даже начинающий пользователь, впервые покупающий кэш-контроллер в сервер.
Чем прежде всего занимается кэш на запись?
Давайте рассмотрим на примере.
Когда клиент записывает блок данных на систему хранения, то, при наличии кэша на запись, этот блок максимально быстро в него помещается, и клиенту отдается сообщение “OK, принято”, клиент не ждет физического помещения блока в сектор жесткого диска, а может продолжать работать, словно записываемый блок уже записан, например отправить следующий блок.
Запись ускоряется путем ее буферизации, и, в дальнейшем, сортировкой и упорядочением процессов записи.
Хотя современный жесткий диск и позволяет обращаться к произвольным фрагментам записанной на него информации, чем отличается от, например, магнитной ленты, которая позволяет считывать и записывать ее только последовательно, однако не позволяет эту произвольно размещенную (random) информацию считывать и записывать _одновременно_, поскольку это физически ограничено возможностями магнитных головок диска.
Если у нас есть жесткий диск, и мы не используем кэширование, то три клиента, пишущих на этот диск, будут вынуждены выстроиться в очередь. Сперва диск спозиционирует головки и дождется подхода нужного сектора для записи блока данных клиента A, а пославшие на запись свой блок клиенты B и C будут вынуждены ждать, затем головки будут переставлены в новое место, диск дождется, когда мимо головок проедет блок, который требуется перезаписать клиенту B, и перезапишет его, а если за это время у клиента A появился еще один блок на запись, то он поставится в очередь следом за блоком клиента C, и будет ожидать, пока выполнятся все операции перед ним.
Все эти процессы, как вы понимаете, механические, неспешны, и занимают не микросекунды, как операции в памяти, а миллисекунды, иногда десятки миллисекунд. Несмотря на то, что жесткий диск - устройство произвольной записи, эти произвольные записи не могут быть осуществлены одновременно.
Ради создания хотя бы иллюзии одновременности и организуется кэш на запись. Приложения записывают свои данные в кэш записи, получают сразу же ответ "готово" и идут сочинять новые блоки на запись, не дожидаясь того, что данные физически поместятся на диск.
Кэш же внутри себя удерживает блок, ожидая подходящего момента на запись, а также оптимизирует записи, с тем, чтобы уменьшить "пробег" магнитных головок по диску, и возможно оптимальным образом перекомпонует записи так, чтобы уложить их максимально эффективным, с точки зрения head seek-а, способом.
Принципиальное отличие WAFL тут состоит в том, что WAFL не перезаписывает блоки уже записанные на диске, и значит при записи клиенты гораздо меньше ожидают seek-а. Вы помните, что в WAFL записи можно провести "чохом", в выделенный сегмент, а не переписывать по одному блоку, мечась по всему диску, здесь и там, ожидая, когда подъедет под головку тот или иной блок. Поэтому даже без традиционного кэширования записи на WAFL клиентские записи быстро оказываются на дисках.
Строго говоря, большой кэш означает, что, используя транспортную аналогию, записи быстро встают в очередь на посадку, но совсем не значит, что при этом они быстро сядут и поедут.
WAFL оптимизирован именно на минимальное время от момента прихода данных "на остановку" и до входа их "в автобус" жесткого диска, превращая записи в записи последовательного порядка (sequental) из поступающих записей в произвольном порядке (random).
Результат хорошо иллюстрируется экспериментом, в котором один aggregate, состоящий из трех дисков SATA 1TB 7200rpm, в RAID-DP (2p+1d), то есть, фактически, из одного действующего диска, показывает при random write блоком 4KB не типичные для SATA 70-80 IOPS, а более 4600!
Объяснение этому простое - записи, поступающие на диск теряют свою "рандомность", и "секвентализируются". Около четырех с половиной тысяч IOPS random-записи на один диск SATA - это как раз то, отчего в системах NetApp нет свойственной для "классических систем" острой необходимости в кэше записи на уровне контроллера.
Таким образом запись действительно надо кэшировать для "классических" систем, да, безусловно, это так. Но это совсем не так безусловно для "неклассических" дисковых структур, используемых, например, в NetApp.
Вот почему NetApp Flash Cache не используется на запись данных, работая всем своим объемом только на чтение. Вот почему необходимость кэширования записи для WAFL не столь безоговорочна, как для "классических" дисковых структур.
Потому, что в WAFL необходимость обязательного кэширования данных при записи существенно ниже, чем для "традиционных" систем.
Это позволило, среди прочего, кстати, значительно упростить алгоритмическую составляющую процесса кэширования, ведь не секрет, что правильная обработка кэширования на запись часто создает значительные проблемы, особенно в наиболее эффективном режиме write-back.
А это, в свою очередь, снизило количество возможных ошибок (как программного кода реализации, так и ошибок при использовании) удешевило устройство и упростило использование.
>Как мне тут не раз уже попеняли, некорректно сравнивать tiering-as-datamoving и tiering-as-caching, то есть, например, NetApp Flash Cache и EMC FAST VP. Допустим, как я ни старался в соответствующей статье, я вас не убедил, что обе эти формы повышения эффективности системы хранения для пользователя есть суть одно.
Как минимум, у Netapp неполучится сделать уровней больше двух. У EMC это вполне разумный вариант.
ZW:
Опять же скажу, для этого надо, чтобы это было нужно. Если два уровня на NetApp обеспечивают то же, что три уровня EMC, то зачем излишняя сложность?
Я думаю, что в целях экономии. Если на SSD посадить требовательную базу данных для SAP(при этом только актуальные данные), на SAS - часть SAP + базы для веб + аналитика, на SATA файловый архив, на SATA 5400 архивы. Другой разговор, насколько подобная конфигурация используется в реальности. Надо статистику собирать. Но впрямую сложно сравнивать SSD кэш и FAST. ??МХО слишком разные вещи.
PS. В плане cache есть свои заморочки, посадили бы диски для кэша на отдельные контроллеры. Но, отмечу, не тратить кэш на запись - это заманчиво.
Экономия получается сомнительная.
Проблема, как я уже писал, в так называемых “холодных данных” и неэффективности с ними связанной.
Если в базе данных, лежащей на SSD, в данный момент только 20% данных активны (довольно обычное дело), значит из 500 тысяч долларов, потраченных на SSD, 400 тысяч бухнуты впустую. Они не приносят ни грамма пользы. 80%-м “холодных” данных все равно где лежать, на SSD или на SATA, на производительность системы в целом это не отражается. Пока они холодные”. Но проблема в том, что 20% “горячих” данных все время разные.
Напротив, так как в кэш попадают всегда только активные данные, то кэширование вместо статического tiering-а эффективно использует все 100% объема флэша, все 100% потраченных на него денег.
>Напротив, так как в кэш попадают всегда только активные данные, то кэширование вместо статического tiering-а эффективно использует все 100% объема флэша, все 100% потраченных на него денег.
Это бесспорно.
Но в принципе идея многоуровневых хранилищ заключается в разбитии стораджа на, фактически, разные уровни SLA. Чем-то напоминает SLA для трафика(видео, база данных, vpn, ftp и торренты).
> Но в принципе идея многоуровневых хранилищ заключается в разбитии стораджа на, фактически, разные уровни SLA. Чем-то напоминает SLA для трафика(видео, база данных, vpn, ftp и торренты).
Верно. Но ради чего все это затеяно?
Попробуйте встать на точку зрения не “технократическую”, как продавца стораджа, а на точку зрения клиента, посмотреть на проблему “сверху”.
Уровни SLA делаются не для того, чтобы они существовали “сами по себе”, чтобы настраивать нескучно было, их использование диктуется какими-то бизнес-требованиями.
Для стораджей это, как я уже писал в статье ранее, необходимость повысить эффективность использования, улучшить соотношение IOPS/$, то есть распределить затраты на хранилище более оптимальным путем, с большей результативностью. Потратить больше на то, что дает больше результата. Я считаю, что именно это и есть причина использования и как tiering в форме физического data moving, и в форме кэширования. То есть у задачи, улучшения соотношения IOPS/$, есть два решения, с точки зрения достижения результата, для клиента, эквивалентные. ?? в том и в другом случае соотношение IOPS/$ улучшается.
Тогда зачем сложное многоуровневое хранилище, если результат с кэшем, с точки зрения пользователя - тот же?
Читаю дискуссии по поводу EMC FAST VP и никак не могу понять одного: никто вообще не интересовался какие требования нужны для него, и как это выглядит на практике? Поясню: для EMC FAST VP необходимо, чтобы диски были в RAID Pool. В RAID Pool можно запихнуть только RAID группы одинакового типа. Добавим сюда рекомендации EMC на длину RAID 5 (4 + 1) и RAID 6 (6 + 2) получаем полный абзац. Другими словами, нам либо все на RAID 10 придется делать, либо и SSD, и SAS, и SATA загонять в RAID 5 (что для SATA дисков как-то стремно), либо и SSD, и SAS, и SATA загонять в RAID6 и убить производительность на запись на всех уровнях + получить немеряную потерю usable space на четность. Может для кого-то это приемлимо, но у меня это отбило всякий интерес как к способу “оптимизации” использования дискового пространства и затрат. Жалко, забанили выступавшего в защиту FAST VP человека, было бы интересно, что он скажет.
Nikita:
Он не забанен, а поставлен на премодерацию. Если найдет в себе силы уважать правила места, где пишет, и о которых я ему говорил, и не превращаться в тролля - с удовольствием верну.
Про пулы - я интересовался, но оставил на сладкое. Там вообще дофига еще “чудес”, если не надоел я тут с этими “страданиями по тиерингу”, то может как-нибудь еще возобновлю тему.
Мне кажется в статье есть ошибка. В системах NetApp есть NVRAM. Почему о нем ничего не сказано? На мой взгляд его вполне можно считать кешем на запись.
firehunter:
Нет, хотя в NVRAM действительно пишутся данные до их попадания на диски, способы его использования в системе принципиально другие, чем у “классического” кэша на запись.
romx:
??з TechOnTap http://www.netapp.com/us/communities/tech-ontap/fas3100-0708.html :
“NVRAM to temporarily cache writes to disk. Batching writes allows most data to be written in efficient stripes, including parity, rather than performing a much slower read-modify-write operation.”
Возможно есть лучшее описание способов использования NVRAM в каких либо документах. Но с точки зрения конечного пользователя СХД NetApp, как мне кажется, лучшее объяснение основной функции NVRAM - кеш на запись. Да он умнее чем у других производителей, но все равно кеш, т.к. как только данные в него попали, контроллер возвращает пользователю что данные записаны.
firehunter:
Это все зависит от того, что именно называть “кэшем на запись”. NVRAM по принципу работы сильно отличается от подавляющего большинства кэшей записи, поэтому называть его “кэш записи” и ставить между ним и “классическими кэшами” знак равенства может привести к серьезной путанице в дальнейшем. Лучше эту путаницу не создавать. Кэш это не только “буфер записи”.
romx:
Я решил упомянуть про NVRAM, так как его описание отсутствует в статье. В то же время WAFL без него существовать не может, т.к. его наличие требуется для реализации алгоритма записи. Я ошибаюсь?
firehunter:
> В то же время WAFL без него существовать не может.
Вот процитированное верно, но NVRAM это все же не кэш, в том понимании этого понятия, как его трактуют в других системах. Это, скорее, “журнал журналируемой файловой системы” на отдельном физическом устройстве.
romx:
Я удивился не увидев описание NVRAM в статье. Она какая то неполная без него, на мой взгляд. В то получается “litle dirty secret” :)
firehunter:
Дело в том, что я пишу в этом блоге уже более четырех лет, и о многом уже писал ранее.
Глупо каждую заметку сюда писать ab ovo, начиная “с зарождения жизни на Земле”.
Про NVRAM я писал, например в статье про WAFL: http://blog.aboutnetapp.ru/archives/19
Достаточно подробно про NVRAM и его работу рассказывается также в переведенной мной статье про устройство WAFL, которая выложена на сайте Netwell, в библиотеке переводов:
http://www.netwell.ru/docs/netapp/wp3002_wafl.pdf
К тому же, повторюсь, NVRAM это НЕ кэш, поэтому вполне логично, по крайней мере с моей стороны, в статье про КЭШ, про NVRAM как раз и не писать.
romx:
Здесь надо определятся с терминологией.
Конечно NVRAM это не кеш, если кешем считать реализацию энергонезависимой памяти и алгоритмов работы с ней в других системах. Но как это не называйте, при попадании данных от клиента в NVRAM, ему сообщается об успешной записи.
Статья ваша, Вам решать что в ней писать. Я лишь высказал свое мнение, что на мой взгляд, краткое упоминание NVRAM в ней не было бы лишним. Ведь именно NVRAM позволяет делать все трюки с записью, такие как отложенное выделение места под запись, CP и пр. В противном случае у читателя может сложиться неверное впечатление.
firehunter:
Ну я уже даже не знаю, что вам еще написать, все свои аргументы за то, почему это так, я привел, даже не по разу, дискуссия, на мой взгляд, зашла в тупик (вернее вошла в рекурсию).
Действительно, лучше всего начать с определения терминологий, так как с моей точки зрения NVRAM кэшем не является, и к теме не относится, но вы, по-видимому, со мной не согласны.
romx:
Собственно я предполагаю, что следующее предложение в статье может ввести в заблуждение неподготовленного читателя: “Около четырех с половиной тысяч IOPS random-записи на один диск SATA - это как раз то, отчего в системах NetApp нет свойственной для “классических систем” острой необходимости в кэше записи на уровне контроллера.” Он, читатель, может сделать вывод, что все операции происходят исключительно в RAM и ONTAP сообщает о успешном завершении записи только тогда, когда она реально упала на диски. А это, как мы с Вами знаем - не так.
firehunter:
Дело в том, что 4000 IOPS это довольно обычная величина для sequental write на SATA. Она получается оттого, что random в процссе записи на диски становтся sequental. Отсюда и такие величины на random-запись
Как вы, возможно, знаете, записи, хотя и попадают в NVRAM на пути к дискам, но не задерживаются там надолго, каждые 10 секунд NVRAM делает flush на диски (либо при заполнении более 50% половины суммарной емкости памяти, одного из двух банков, NVRAM).
То есть фактическая емкость “кэша” в NetApp, если вы настаиваете на том, чтобы называть NVRAM кэшем, составляет 25% от его “паспортной емкости”. Это совсем немного для кэша (но достаточно для NVRAM).
Таким образом, диски на самом деле “потребляют” поток как указано, так как, в противном случае, емкость кэша быстро бы переполнилась, и производительность на запись бы упала. Данным просто некуда было бы поместиться.
А раз она не падает, а вполне себе steady, значит один диск SATA на самом деле успевает прожевывать 100% random write на такой скорости.
romx:
Я не настаиваю NVRAM называть как либо. Мне просто кажется, что NVRAM достоин упоминания о нем в статье. Так или иначе это устройство является важной частью всей системы. ?? несколько фраз про WAFL и отсутствии необходимости классического кеширования записи для нее я бы дополнил “… потому что WAFL использует NVRAM”.
romx:
плюс к последней фразе: “и алгоритмы, которые позволяют наиболее эффективно производить запись”.
Это в качестве варианта. Это мое предложение, основанное на личном мнении о статье, точнее о том, как ее прочтут неподготовленные читатели. Конечно Вы можете со мной не согласится. Я ни на чем не настаиваю.
Думаю что дискуссию можно сворачивать.
Картинки отвалились, - какая жалость.
>если, допустим, только 4KB из блока в 64KB нам действительно нужны
А вот интересно где-то бы получить базовый размер блока которым оперирует СХД VNX/VNXe.
bbk:
Вы про FASTcache? 64KB.