PAM - Performance Acceleration Module

Вот уже пару лет как у NetApp в номенклатуре продуктов находится интересный, но все еще не слишком известный широкому кругу пользователей продукт – PAM – Performance Acceleration Module, а в прошлом году к нему в компанию добавился еще один вариант – PAM-II (ныне Flash Cache).

Давайте разберемся подробнее что это, чем полезно и как применяется.

Первое, что следует понимать, чтобы разобраться в том, что есть PAM и как его применяют:
PAM это не SSD!

PAMII

Широкое распространение SSD (даже этот пост пишется на ноутбуке с SSD) привело к тому, что любой продукт так или иначе использующий память для хранения данных называется “SSD”.

Давайте разберемся, что такое SSD, и чем PAM не SSD.

SSD – Solid State Disk, “твердотельный диск”, это такая организация памяти (обычно используется технология Flash), при которой микросхемы памяти эмулируют для обращающейся к ним системы “дисковое устройство”, позволяя OS и компьютеру в целом работать с ним привычным для них образом, словно с “жестким диском”, используя обычные для этого процедуры.

image

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

NetApp пошел тут вновь “своим путем”.

Хранимые на дисках данные можно охарактеризовать в зависимости от интенсивности к ним обращения. Существуют данные к которым активность обращения высока, и данные, к которым обращения редки. Последние принято называть “холодные” данные (cold data). Как показывают наблюдения, для значительного числа данных в “реальной жизни” процент “холодных” данных составляет до 70-80%. На “горячие”-же приходится не более 20-30%. То есть, если мы храним данные на SSD, всего лишь 20-30% этих данных получат преимущество от большего быстродействия SSD, остальные же 70-80% SSD будут занято непроизводительно, так как от того, хранятся ли данные, к которым никто не обращается, на сверхдорогом и сверхбыстром SSD, или на медленном и дешевом SATA, этим данным и нашей задаче абсолютно все равно. При цене Enterprise SSD достигающей 9-10 тысяч долларов (за один диск SSD!) использовать их на 20-30% (а то и менее) это поистине сумасшедшее расточительство.

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

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

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

Необходимость в кэш-памяти создана тем фактом, что жесткие диски это довольно медленные устройства. Я уже писал, что отдельный жесткий диск обрабатывает всего от нескольких десятков (SATA) до нескольких сотен (SAS/FC) операций считывания-записи в секунду. Это связано с тем, что жесткий диск это “механическое” устройство, для того, чтобы считать блок данных ему нужно спозиционировать головку, дождаться прохождения мимо нее нужного сектора, считать данные и передать запрошенный блок управляющему контроллеру, после чего вновь передвинуть магнитную головку для считывания следующего блока.
Отчасти эта проблема решается с помощью соединения множества дисков в RAID-группы, при этом различные блоки запрошенных данных оказываются на разных дисках, и они могут начать считывать их параллельно. Если ситуация близка к идеальной, то группа в 10 дисков будет иметь быстродействие в 10 раз выше одиночного диска. (Зачастую именно требования быстродействия заставляет увеличивать количество жестких дисков в системе, даже несмотря на то, что для собственно хранения данных нам было бы вполне достаточно гораздо меньшего их количества. Об этой проблеме я относительно недавно уже писал в блоге: (“вы платите только за быстродействие, терабайты- бесплатно!”)

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

image

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

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

Практически все системы хранения используют такую схему с кэш-памятью, от размера кэша как правило напрямую зависит быстродействие, а по-настоящему большие enterprise и high-end системы имеют объемы кэша в десятки гигабайт. От объема и алгоритмов работы с кэшем (тем, насколько ловко контроллер заполняет этот кэш и предугадывает какие запросы от сервера придут) напрямую зависит быстродействие системы.

Однако цена объема кэша весьма велика, именно этот параметр (а также мощность обслуживающего его контроллера) зачастую и ограничивает безудержный рост его объемов. Кроме того, управление большим кэшем сопряжено с рядом трудностей технического и алгоритмического плана.

Как я уже показал выше, данные в кэше характеризуются максимальной “температурой”. Следовательно, если мы используем память не для эмуляции жестких дисков, а напрямую, непосредственно как память, для “расширения кэша”, то мы достигнем максимально высокой эффективности ее использования.

Так и поступил NetApp.
Первым их продуктом был модуль под названием PAM – Performance Acceleration Module. Это плата расширения в стадартный слот PCIe, который имеется в контроллерах NetApp среднего (FAS3100) и верхнего (FAS6000) класса. Модуль представляет собой плату, на которой установлены DDR-DIMM оперативной памяти, объемом 16GB. В каждый из контроллеров, в зависимости от его модели, можно установить от 2 до 5 таких модулей. Их емкость образует своеобразный “кэш второго уровня”, о принципах работы которого чуть ниже.

image

Спустя год с момента выпуска PAM, был выпущен новый модуль – PAM-II, который недавно, для лучшего понимания, переименовали во Flash Cache.

Две версии этого модуля несут на себе 256GB или 512GB быстрого SLC NAND Flash, такого же, как применятся для создания Enterprise-class SSD, и, в зависимости от типа и мощности контроллера, их может быть установлено от 1 до 4 в каждый из контроллеров. Но как и в случае PAM, Flash Cache не эмулирует “жесткий диск”, а организован как обычная память, образовывая собой “кэш второго уровня” и расширяя его “оперативную емкость”. Принципиальным преимуществом такого варианта, как я уже рассказал выше, яляется максимальная эффективность использования его емкости только лишь для “горячих”, максимально в нем нуждающихся данных, без необходимости устраивать хитрые и дорогостоящие системы миграции, подобные EMC FAST.

PAMII 

Принцип работы как PAM, так и Flash Cache (PAM-II) идентичен.
Каждая система хранения NetApp, также как и все другие системы хранения, других производителей, использует традиционую схему с кэш-памятью, в которую попадают считываемые данные на случай, если эти данные потребуются повторно, в этом случае они не читаются с диска, а быстро отдаются непосредствено из кэша.
Емкость системного кэша варьируется в зависимости от модели от 1GB на контроллер в самой младшей системе FAS2020, до 32GB в самой старшей FAS6080.

Основным отличием от традиционного, используемого в других системах, принципа яляется то, что контроллеры NetApp практически не используют этот объем кэша для процесса записи. Это связано с тем, что используемая на дисках структура WAFL максимально оптимизирована для ускорения операций записи, и, в отличие от “традиционных систем хранения”, данные, которые поступают на запись на диски, записываются с максимально возможной скоростью, и использование кэша на запись уже не проведет этот процесс быстрее, чем он уже происходит.

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

image

Как я уже рассказал выше, принцип работы кэша “на пальцах” довольно прост. Кэш-память заполняется данными при чтении (так как NetApp не использует кэширование записи, то здесь и далее мы будем говорить только о чтении) в надежде, что какой-то из прочитанных блоков (а также какие-то из “предположений” контроллера, например в результате операций read-ahead, то есть “упреждающего чтения”) потребуется считать повторно, и тогда его можно будет отдать из кэша, в сотни раз быстрее, чем читать заново с диска.
По мере того, как кэш заполняется данными, его надо очищать. Контроллер делает ряд оценок и предположений (в первую очередь ориентируясь на срок нахождения и частоту обращения к данным в кэше) того, какие данные скорее всего не будут востребованы, и их можно “вытолкнуть” из кэша ради более нужных.
При этом чем интенсивнее обмен с дисками и трафик системы хранения, тем скорее будет наполняться кэш, тем чаще приходится его опустошать контроллеру, и тем меньше срок хранения блоков данных в нем.
Сокращение же времени нахождения блоков в кэше уменьшает вероятность Cache Hit, то есть нахождения нужного блока в кэше, и радикального ускорения работы системы за счет кэширования.

Таков штатный режим работы системного кэша NetApp.
Добавление же PAM/Flash Cache в виде “кэша второго уровня” позволяет иерархически расширить его объем. Теперь если данные, по оценке контроллера, необходимо вытолкнуть из системного кэша, они не удаляются совсем, а переносятся в более обширный и более емкий кэш, образованный из карт PAM.

image

Да, кэш в PAM не такой быстрый, как системный кэш самого контроллера. Но он все равно в десятки раз быстрее, чем считывание с дисков.

С установкой PAM/Flash Cache мы решаем задачу ускорения доступа и уменьшения латентности (времени задержки между запросом и ответом) при чтении данных, причем вся его емкость будет эффективно использована под по настоящему “горячие” данные.

“Но довольно слов”, скажете мне вы. “Дай нам цифры!”.

Извольте.

NetApp протестировала три варианта своей системы FAS3140, самой массовой системы “среднего уровня” (midrange) с помощью популярного теста SPECsfs2008, оценивающего быстродействие системы хранения при работе с сетевой файловой системой NFS или CIFS (подробное описание всех конфигураций, результатов, а также сравнение с аналогичными тестами других производителей вы можете посмотреть на сайте SPEC.org - http://www.spec.org/sfs2008/results/sfs2008.html
В качестве эталонной системы использовалась двухконтроллерная конфигурация с 15 полками 300GB 15K FC дисков (суммарно 224 диска).

И вот какие результаты получились

  Конфигурация Результат SPECsfs2008_cifs
ops/sec
Overall
Responce
time
Raw
емкость
Потребление
электричества
Места
в рэке
224 диска FC 2xFAS3140
16 полок 300GB 15K FC
(224 диска)
55 476 1,84ms ~64TB - -
56 дисков FC плюс
Flash Cache
2xFAS3140
4 полки 300GB 15K FC
(56 дисков)
2x Flash Cache (PAM-II)
55 398 лучше
(1,25 ms)
на 75% меньше
(~16TB)
на 67%
меньше
на 67%
меньше
96 дисков
SATA плюс
Flash Cache
2xFAS3140
4 полки 1TB 7,2K SATA
(96 дисков)
2x Flash Cache (PAM-II)
54 047 лучше
(1,50ms)
на 49% больше
(~96TB)
на 66%
меньше
на 59% меньше

 

Ранее NetApp протестировал и PAM-I на NFS, со сходными результатами, подробные результаты и полное описание процесса и использованного оборудования вы можете найти по приведеному выше адресу.

Как вы видите, с использованием Flash Cache (PAM-II) удалось достичь сходного с системой на 224 дисках FC быстродействия, для системы не только всего на 56 дисках FC (в четыре раза меньше!), но и системе на традиционно считающихся непригодными для построения быстродействующих решений дисках SATA.
В обоих случаях результатов бОльшей системы удалось достичь на системах почти втрое меньшего размера по размерам в рэке и энергопотреблению.
Результаты использования PAM/Flash Cache говорят сами за себя.

Несмотря на довольно значительную цену (enterprise-class flash никогда не стоил дешево) решение с использованием PAM явно достойно пристального внимания при планировании покупки midrange системы хранения, в особенности если уделяется значительно внимание быстродействию, эффективности, и экономии средств в условиях ограниченных ресурсов по электропитанию или объемам занятого/арендованного в датацентре места.

Для желающих углубленно разобраться в принципах и механизмах работы PAM и Flash Cache хочу прекомендовать недавно переведенный на русский язык официальный Technical Report (TR-3832), который, как и все наши переводы, доступен на странице российского дистрибутора NetApp, компании Netwell:

Flash Cache (PAM-II) and PAM: наилучшие методы использования

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

  1. vitaly:

    А каково среднее время хранения данных в таком кеше на среднестатистической системе ? Хотя бы порядок - секунды, минуты, десятки минут.

  2. Это зависит много от чего.
    В первую очередь от трафика с дисков, конечно. Потом следует учесть, что PAM имеет три разных режима кэширования: “только метаданные”, “обычный (метаданные+данные)” и “низкоприоритетные данные (метаданные+данные+низкоприоритетные данные)”, соответственно попадающий в PAM объем данных тоже будет разный.
    Ну и, наконец, сам объем PAM может быть разный. От 16GB одна плата PAM-I до 2TB в случае 4 плат PAM-II/Flash Cache. Это на каждый контроллер.
    Примерно можно рассчитать объем “прогрева кэша” по формуле, приведенной в TR, на который я сослался:
    (размер кэша) / (пропускная способность чтения в секунду) = время заполнения кэша
    Например:
    512GB/100MB в секунду = 5120 секунд = 85 минут
    Столько будет заполняться пустой PAM-II объемом 512GB.

    Текущее же состояние системного кэша (то есть того, что на “материнской плате” контроллера) можно посмотреть в выводе команды sysstat
    Про нее я писал тут: http://blog.aboutnetapp.ru/archives/199

  3. Marryhorse:

    Я так понял, что PAM исключительно на чтение?

  4. Любой кэш у NetApp работает только на чтение, что системный, что PAM. Запись у NetApp организована таким образом, что кэшировать ее бесполезно, она и так максимально быстро осуществляется, благодаря WAFL. Кэширование в том виде, в котором это делается в “обычных системах хранения” просто ее уже не ускорит больше чем уже есть.

    Впрочем, практика показывает, что использование PAM несколько увличивает и скорость записи тоже, так как снижает наргузку по физической IO с дисков, высвобождая часть IOPS дисков на осуществление операций записи.

  5. s1d:

    Добрый день.
    Спасибо, очень интересная статья. Единственное, мне кажется, что FlashCache скорее можно сравнить с EMC FAST Cache, а не с FAST VP. FAST Cache - тоже “кэш память второго уровня”, правда реализованная на SSD дисках, но все же.

  6. s1d:

    1. На момент выхода Flash Cache у EMC еще не было FAST Cache.

    2. Я напрямую нигде не приравниваю PAM/Flash Cache с EMC FAST, я только указываю, что обе эти системы решают одну задачу tiering-а данных, правда разным способом.
    Впрочем, далее в блоге я довольно подробно эту тему рассмотрел.

  7. Дмитрий:

    Добрый день.

    несколько вопросов.
    1. Будут ли отличия (функционально и по скорости) при использовании в 3240 PAM-II 512 от 2х256?
    2. PAMы ставят парами, одинаковые в каждый контроллер? или возможны несимметричные конфигурации?
    3. деградирует ли скорость работы FlashCache со временем? является ли значительная (какая?) деградация производительности гарантийным случаем?
    4. правильно ли понимаю, что FlashCache будет более производительным решением, чем FlashPool?

  8. Дмитрий:

    1. Да вроде нет. Ну кроме как во втором случае останется меньше PCIe. :)
    2. Нет, нельзя. Можно несимметричные, если они не в кластерной паре :)
    3. А чего ему деградировать-то?
    4. Пока неясно. Для Flash Cache есть опубликованные результаты тестов, а для Flash Pool пока нет. Теоретически Flash Cache архитектурно чуть более “прямое” для данных решение, не грузящее при кэшировании интерфейс от контроллера к дискам. Но зато умеет записи кэшировать. В общем, пока не вполне ясно, понятно только, что их сравнивать напрямую нельзя. Где-то лучше будет Flash Pool, где-то - Flash Cache. Их можно использорвать и вместе, кстати.

  9. Дмитрий:

    Спасибо большое!

    1. думал, может быть - от 2х256 будет больше иопсов:)
    2. ясно.
    3. ну, вроде как фдэш-память - при интенсивной записи ячейки портятся… или, т.к. кэшируется только чтение - то записей будет немного и проблемы нет?
    4. Их можно использорвать и вместе, кстати. - если я правильно понял этот документ: http://blog.aboutnetapp.ru/archives/1197#more-1197 , если поставить в 3240 512Гб ПАМы - то уже нельзя. ну и отдельно сказано, что не рекомендуется.
    кстати, ФлэшПул, при кэшировании интенсивной записи - уж точно будет деградировать? или опять неправ?:)

  10. Дмитрий:

    1. А я думаю, что вы переоцениваете свои возможности в данном вопросе :)

    3. Так нет “интенсивной записи”, в том-то и фокус. Для флэша вредна рандомная запись мелкими блоками, поскольку, вследствие его устройства, вынуждает переписывать ради одного байта целую страницу в пару мегабайт. Но в случае Flash Cache кэш заполняется и опорожняется не рандомными блоками, а довольно протяженными страницами, секвентально, и сравнительно редко и предсказуемо.
    Я уж не говорю о том, что пугало “записи на флэш” давно пора уже списать за устарелостью.

    > кстати, ФлэшПул, при кэшировании интенсивной записи - уж точно будет деградировать?

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

  11. Дмитрий:

    1. я просто высказал предположение:) знания свои не переоцениваю, просто задаю вопросы и благодарен за помощь.

    > кстати, ФлэшПул, при кэшировании интенсивной записи - уж точно будет деградировать?

    Это не ваша проблема, это проблема саппорта. Если они дают вам на SSD трехгодичную гарантию, то это уже их забота каким образом они ее будут соблюдать.
    - а гарантия распространяется на производительность? если через 2 года сказать саппорту - что-то у меня ССД работает медленнее, чем САТА диски - они будут менять? или ответят - ну так работает же!
    Вдруг Вы и это знаете:)

  12. Дмитрий:

    Извините, если ответы ненамеренно с моей стороны получаются резкими и даже, возможно, грубыми. Конец рабочего дня :-/
    Ну просто оцените производительность шины PCIe 2.0, и сопоставьте с реальной производительностью каналов на ввод-вывод. Я не думаю, что в мире существует много задач, реально прогружающих такой канал вводом-выводом до его потолка.
    Упираться будет в совсем других местах.

    > а гарантия распространяется на производительность? если через 2 года сказать саппорту - что-то у меня ССД работает медленнее, чем САТА диски - они будут менять? или ответят - ну так работает же!

    В таких случаях открывается кейс и долбается саппорт до победы. Уплочено. :)

  13. Дмитрий:

    Нет, я не обиделся:)

    если интересен ход мысли - то я не думал, что упрется в производительность интерфейса… а вот будет ли контроллер на 512Гб плате в 2 раза мощнее (или - есть ли у контроллера 2-кратный резерв, если он там одинаковый), больше ли в 2 раза число каналов к флэш памяти - этого я не знал.

    еще раз - спасибо большое!

  14. Ануар:

    Добрый день.
    Подскажите, есть ли возможность выяснить установлен модуль или нет из командной строки?

  15. Ануар:

    Наверняка должен быть представлен в sysconfig -v

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

20/0.159

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией 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.