about NetApp

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

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

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

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

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

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

Преимуществом такого подхода является простота использования, не ведущая к переделке внутреннего устройства 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 раз выше одиночного диска. (Зачастую именно требования быстродействия заставляет увеличивать количество жестких дисков в системе, даже несмотря на то, что для собственно хранения данных нам было бы вполне достаточно гораздо меньшего их количества. Об этой проблеме я относительно недавно уже писал в блоге: (“вы платите только за быстродействие, терабайты- бесплатно!”)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, кэш в 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 диска).

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

Ранее 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: наилучшие методы использования