Pull to refresh
0

FlashCache. Как использовать Flash в СХД НЕ как SSD?

Reading time 8 min
Views 25K
image

Использование Flash-памяти для современных систем хранения стало уже почти повседневным делом, понятие SSD — Solid-State Disk, широко вошло в практику энтерпрайз-систем хранения и серверов. Более того, для многих понятия Flash и SSD стали едва ли не синонимами. Однако, NetApp не был бы собой, если бы не нашел для использования Flash лучший, свой собственный способ его использования.
Как же можно использовать Flash для системы хранения, но НЕ в виде SSD?


Начну, пожалуй, с определения того, что такое SSD.
SSD или Solid-State Disk (дословно: «Твердотельный диск», диск без движущихся, механических частей) это способ представить для OS пространство энергонезависимой памяти по технологии Flash как виртуальный, эмулированный жесткий диск.

Наиболее традиционным видом «non-volatile memory», то есть энергонезависимой памяти, для OS и приложений являются «жесткие диски», HDD. С жесткими дисками умеют работать все OS, поэтому вполне естественно было бы, для упрощения работы и укорочения «пути на стол потребителя», не городить для каждой OS поддержку какой-то своей архитектуры использования Flash, а на самой Flash-memory сэмулировать простой и понятный для драйвера любой OS псевдо-«жесткий диск», и работать в дальнейшем с ней как с жестким диском.

Плюсы такого подхода — это просто. Это позволяет использовать уже существующие драйвера в любой OS и не городить специфическую поддержку для каждой из них.
Минусы — эмуляция это все же эмуляция. Ряд особенностей Flash бывает достаточно непросто использовать и учитывать, работая с ним как с «диском». Пример — достаточно непростая организация перезаписи байта данных в Flash.

NetApp выбрал для использования Flash свой особый путь. Он использует Flash-memory не в виде эмулированного «диска» (storage), а непосредственно как память (memory).

image

Ни для кого не секрет, что в хранимых на дисках данных значительную часть занимают данные, к которым редко обращаются. В англоязычной литературе их принято называть «cold data», и, по оценке, объем cold data в общем объеме хранения может достигать 80%. То есть к примерно к 80% хранимых данных приложения обращаются сравнительно редко. Это значит, что примерно 80% денег, которые мы потратили на все еще очень дорогие SSD, потрачены зря, и не дают нам никакой фактической отдачи.

Cold-данные, которые лежат на SSD, могли бы точно также лежать на дешевых SATA, все равно они в данный момент лежат без движения. Оттого, что он лежат и занимают место на супердорогих SSD, наша система в целом быстрее работать не будет, ведь преимущество SSD проявляется лишь в момент обращения к данным, а «просто лежать» данные могут на любом диске. Зато мы теряем это место для тех активных данных, которые, будучи размещенными на SSD, дали бы прирост производительности. «Холодные данные» это классическая «собака на сене». И сами возможности SSD не используют, и другим, нуждающимся, не дают.

Казалось бы в чем проблема? Определи «холодные» данные, отдели их, и храни их на отдельном хранилище.
Но беда в том, что в эти 80% в каждый момент времени попадают разные данные. Данные в базе о проводках за прошлый квартал, весь следующий квартал будут лежать нетронутыми и «холодными», однако в период подготовки годового отчета они снова станут очень даже «горячими».

Было бы очень хорошо, если бы такое перемещение по «уровням хранения» происходило автоматически. Но такая система очень сильно усложнит всю архитектуру хранения. Ведь системе хранения придется не просто максимально быстро принимать и отдавать данные, но еще и оценивать активность фрагмента, перемещать его каким-то образом, и еще помнить о том, где нужный фрагмент сегодня располагается, чтобы соответствующим образом «перемаршрутизировать» обращение клиента.

Куча сложностей, и все из за того, что мы выбрали неправильный инструмент. Я уже как-то приводил эту забавную аналогию, про то, как трудно и непросто заколачиваются болты в гайки молотком. Можно для выполнения этой задачи брать все более тяжелый молоток, а можно просто сменить молоток на гаечный ключ, и использовать болты по назначению. :)

Использовав Flash не в качестве storage, а в качестве memory, NetApp очень элегантно решила проблему cold data.

Все вы, уверен, знаете, о принципах работы RAM-кэша в современных системах хранения данных.
Кэш — это промежуточное оперативное хранилище данных в быстрой RAM.
Если клиент запрашивает блок данных из хранилища, то он читается и при этом попадает в кэш.
image

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

Таким образом мы видим, что данные в кэше это всегда, «по определению», 100% hot data!

Теперь давайте представим, что мы используем flash не как диск, а как память, как некоторого рода «кэш второго уровня», дополнительное пространство. Обычно у нас в системе хранения есть сравнительно медленное дисковое пространство, и значительно более быстрый RAM-кэш. Увы, мы не можем бесконечно увеличивать размеры RAM-кэша. Это, по меньшей мере, очень дорого. Однако если у нас есть довольно емкая, пусть и не такая быстрая как DDR DRAM память Flash, мы можем ее поставить «кэшем второго уровня» к уже имеющемуся RAM-кэшу.

Теперь механизм кэша работает следующим образом: данные попадают в RAM-кэш (обычно его размер, в зависимости от типа и мощности контроллера составляет от 1 до 96GB), и находятся там, пока не, будут вытеснены более актуальными данными. Вытесняясь из RAM-кэша, они не удаляются, а переносятся в Flash-кэш (размером, обычно, в зависимости от мощности контроллера, его типа и количества возможных модулей, от 256GB до 4TB). Там закэшированные блоки находятся до тех пор, пока они не «устареют», в свою очередь, и не будут вытеснены актуальными данными. И только тогда считывание пойдет с дисков. Но пока эти данные находятся во FlashCache, чтение их происходит примерно в 10 раз быстрее чем с дисков!
image

image

* Обратите внимание, что картинки взяты из руководства по использованию FlashCache, и там он называется PAM — Performance Acceleration Module, это его «старое» и «внутреннее» название, то есть «PAM» это не «RAM».

Каковы же результаты использования FlashCache? Насколько заявленная эффективность показывает себя на практике?
Для сравнения производительности NetApp участвует в программе тестирования с помощью стандартного и широко принятого индустрией теста SPECsfs. Это тест «сетевых файловых систем», то есть NAS, по протоколам NFS и CIFS, результаты которых легко экстраполировать и на другие задачи.

В качестве эталонной системы взята midrange модель FAS3140 с 224 дисками FC (это 16 полок по 14 дисков в каждой, полный 48U-шкаф дисков FC!).
Не секрет, что очень часто в систему высокой производительности по вводу-выводу, при ее конфигурировании, вынуждены ставить много дисков (у нас принято выражаться «дисковых шпинделей» — disk spindles). И очень часто именно производительность в IOPS, а не емкость хранения, диктует количество используемых системой дисков. Много дисков в такой системе это вынужденная мера обеспечения высокого быстродействия ввода-вывода.

Вы видите, что такая система показала на тесте SPECsfs2008 CIFS 55476 спекмарковских «попугаев» по производительности ввода-вывода.

Возьмем теперь такую же систему, но теперь с платой FlashCache внутри, но на этот раз всего с 56 такими же дисками FC (это всего 4 полки дисков, в четыре раза меньше дисковых «шпинделей», обычно определяющих производительность в IOPS)
Мы видим, что для системы, стоящей (суммарно диски, полки, плюс FlashCache) на 54% дешевле, при том же уровне производительности в «попугаях» достигнут заметно меньший уровень задержек, а за счет меньшего количества дисков на 67% улучшились показатели энергопотребления и занимаемого системой места в стойке.

image

Но и это еще не все. Третья система содержит вместо FC-дисков 96 дисков SATA, обычно характеризующиеся невысокой производительностью в IOPS, и снова FlashCache.
Мы видим, что даже с использованием сравнительно «небыстрых» SATA на 1TB, наша система показывает все те же показатели быстродействия, обеспечив при этом на 50% больше доступной емкости, чем система на дисках FC без FlashCache, и на 66% меньше энергопотребление, при примерно равном уровне задержек.

Практический результат получается настолько мощный и убедительный, что NetApp продала своим клиентам петабайт флэша в виде FlashCache, всего через полгода после объявления этого продукта, и, насколько я знаю, объемы продаж продолжают расти (NetApp даже утверждает что сегодня они являются вторым по объемам продавцом Flash-памяти в мире, после Apple, с их iPod/iPad/iPhone).

Но FlashCache не работал бы так эффективно, если бы не (вновь!) возможности лежащей ниже, под ним структуры WAFL. Помните, рассказывая про WAFL, а затем про те или иные «фишки» систем хранения NetApp я несколько раз повторил уже, что WAFL это самый «фундамент», основа всего того, что умеет NetApp.
Что же «сыграло» в данном случае?

Те, кто всерьез и глубоко занимается перспективами использования SSD в производительных приложениях уже знает одну, крайне неприятную особенность Flash как технологии — очень низкую производительность на случайной записи (random write).
Почти всегда, когда заходит речь о производительности SSD, производители показывают грандиозные результаты случайного чтения, однако почти всегда так или иначе обходят стороной вопрос производительности случайной записи мелкими блоками, а ведь это, в типичной рабочей нагрузке, примерно 30% всех операций.

Это показатели по IOPS у популярного высокопроизводительного enterprise-class SSD FusionIO
image

А это — табличка по производительности в IOPS для популярного Intel X25M, «спрятанная» в документации «для партнеров». Обратите внимание на выделенное и подчеркнутое.
image

Такие «сюрпризы» встречаются почти у любого SSD, любого производителя.
Связано это с непростой процедурой записи в ячейку Flash, организованных в блоки. Для (пере)записи даже небольшого блока, надо полностью стереть и записать снова всю содержащую его «страницу» Flash. Операция эта небыстрая и сама по себе, даже если не брать во внимание ограниченность этих циклов.

Как же в данном случае «играет» WAFL?
Дело в том, что в системах NetApp, использующих WAFL, которая «оптимизирована на запись», а если подробнее, то записи, как я уже рассказывал, пишутся длинными последовательными «страйпами», а за счет того, что такая схема позволяет не держать записи в кэше, а записывать их непосредственно на диски, на максимально возможной для этих дисков скорости, кэш в системах NetApp практически не используется на запись. Соответственно не используется на запись и FlashCache, сильно упрощается и алгоритмическая часть, и решается проблема с низкой производительностью Flash на запись. Flash в данном случае вообще не используется на запись, записи прямиком, через буфер RAM, идут на диски, держать их в кэше просто не нужно, то есть мы используем Flash только в самом эффективно работающем у него режиме — random read (иногда наполняя его новыми данными, взамен выбывших, с помощью также неплохо переживаемой им операцией sequental write).

Таким образом, нетрудно видеть, что использовав Flash «как память» в виде кэша, мы автоматически храним в ней только активные, горячие данные, те данные, повышение скорости доступа к которым по настоящему дает выгоду использования, и устраняем проблемы с низкой производительностью и конечностью ресурса записи во Flash.
Да FlashCache тоже недешев. Но вы гарантированно используете в дело потраченные на него деньги, все, а не только 20%. И это именно то, что называет NetApp «эффективностью хранения».

Подробнее и на русском о FlashCache, можно почитать в технической библиотеке компании Netwell, публикующей переводы на русский язык официальных технических руководств NetApp.

Идея использовать Flash-память более эффективным и «прямым» способом, чем просто эмулировать на ней «жесткие диски», по моему наблюдению распространяется в индустрии все шире. В ряду занявшихся этим направлением и практичный Adaptec, представивший свой MaxIQ, и CacheZilla в ZFS, и Microsoft Research, опубликовавший интересную научную работу Speeding Up Cloud/Server Applications Using Flash Memory (краткий обзор в виде презентации )

На фотографии в начале статьи — установка FlashCache (некоторое время он назывался PAM-II — Performance Acceleration Module, Generation 2, был еще PAM-I, на DRAM, и использовавшийся для кэширования метаданных NAS )
Tags:
Hubs:
+22
Comments 65
Comments Comments 65

Articles

Information

Website
www.netapp.com
Registered
Founded
Employees
1,001–5,000 employees
Location
Россия