about NetApp

Следует отметить, что новости про flash прошлой недели показывают, что для NetApp это не просто “ну еще один all-flash сторадж, раз у всех есть”, налицо стратегическая линия. Одновременно с EF540 был анонсирован продукт, который пока не выпущен, но о котором, что, в общем, необычно для NetApp, уже рассказывается: FlashRay.

Если вы уже начинаете запутываться в том, что где и для чего у NetApp на flash-рынке предназначено, то давайте посмотрим на схему:

На ней вы видите позиционирование всех на сегодняший момент flash-продуктов NetApp: Flash Cache находится в контроллере, Flash Pool -  во “встроенном” хранилище самого NetApp, его часть, Flash Accel – софтверное решение внутри хост-серверов, использующая их внутренние SSD. EF450 – это standalone-сторадж, никак, архитектурно, не связанный с FAS. А вот что будет в этой картине мира делать анонсированный FlashRay?

FlashRay – это компонент развивающейся силами Clustered ONTAP (Data ONTAP 8 Cluster-mode) архитектуры scale-out, или, если по-русски, “горизонтального масштабирования. Напомню, что такое “горизонтальное” и “вертикальное” масштабирование.

Если вы переросли ваш сторадж,  и меняете его на более мощный – это “вертикальное масштабирование”. Если вы увеличиваете мощность имеющегося стораджа, добавляя непосредственно в имеющуюся инфраструктуру новый контроллер и диски, которые не образуют новую, более мощную “сущность”, а расширяя емкость и производительность уже имеющейся системы – это “горизонтальное масштабирование”. В NetApp “горизонтальное”, или scale-out (в отличие от scale-up, “вертикального”) масштабирование – это Cluster-mode.

Хорошо знакомые с номенклатурой NetApp могут увидеть в FlashRay наследника NetApp SA, специальных кэширующих систем, нацеленных на ускорение работы NFS. Такие системы, представляющие собой контроллер соответствующей системы хранения и небольшой объем дисков, подключенных к нему для хранения закэшированных данных, устанавливаются на пути между клиентским приложением на хост-сервере, и собственно хранилищем данных, и ускоряют доступ к часто обращаемым данным, как, например, в рассмотренном выше по ссылке кейсе.

В отличие от NetApp SA, согласно анонсу, FlashRay это будут all-flash устройства, ускоряющие доступ к бэкэнд-стораджу FAS, он будет поддерживать кластерность, многопротокольность (а не только NFS), inline-компрессию и inline-дедупликацию данных с переменной длинной блока (неужели пригодились-таки разработки для VTL в этой области?), и ряд других, более обычных для NetApp опций, включая репликацию и автобалансировку нагрузки в кластере FlashRay.

Таким образом, если после анонса EF540 вам показалось, что NetApp начала отходить от своей парадигмы “во flash выгоднее кэшировать, чем хранить”, то анонс FlashRay показывает, что концепция жива, здорова, и передает всем пламенный привет с нового уровня своего развития. Ждем более подробных новостей с техническими деталями.

Как вы знаете, я мало и редко пишу тут про отдельное семейство продуктов NetApp - так называемые системы хранения E-series (они же знакомы многим из вас как IBM DS3500/3700, и ряд других), это продукты бывшего LSI Engenio, пару лет назад перешедшего “под крыло” NetApp. ?? хотя под этим самым крылом развитие их не остановилось, напротив, даже закоренелые скептики вынуждены были признать, что ресурсы NetApp сильно помогли Engenio в разработке новых фич и продвижении продукта, для меня эти системы довольно сторонний продукт, и пишу я о нем тут редко.

Причин этому две. Во-первых ни их самих, ни задач под них у меня нет нигде рядом, во-вторых сами по себе они мне не особенно интересны.

Последнее стоит чуть более развернуто объяснить.
Дело в том, что, если системы линейки FAS, это стораджи “широкого профиля” применения, создаваемые для использования под различные задачи, с широким набором разнообразной функциональности, как встроенной, так и дополнительной, то системы E-Series это крайне “узкопрофильный” сторадж. Это система хранения, строго говоря, под одну задачу: “скорость, скорость и ничего кроме скорости”. Причем “ничего кроме” это почти не фигура речи. Как следствие (а вы знаете мою позицию по данному вопросу), это системы хранения довольно ограниченны по своей области применения.
Это “болиды Формулы 1″, быстрые в условиях гоночного трека, но не очень полезные в городе или, например, на стройке.

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

Поэтому, по моему мнению (и по мнению NetApp), E-series это нишевое решение, для специализированных применений, таких как хранилища для Big Data под Hadoop, высокопроизводительные grid-системы, стораджи под Lustre для HPC, промышленных масштабов Video Surveillance, реалтайм аналитика, особо критичные к времени выполнения запросов OLTP-базы, и прочие подобные области применения.

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

Вот и кэширование в SSD (Performance Read Cache), поверхностно похожее на аналогичную функцию у NetApp FAS, довольно значительно отличается от NetApp Flash Pool (Hybrid Aggregate).

Во-первых, значительным отличием является использование переменного размера блока. Так как E-series это не-WAFL-based системы, они не привязаны к блоку “файловой системы” (в случае WAFL это 4 килобайта), и могут варьировать размер оперируемого блока от 2K до 8K. В ряде случаев это может дать эффект при специфических нагрузках ввода-вывода, прежде всего при процессе “прогрева кэша”, то есть первоначальном заполнении его данными. ??сследование NetApp утверждает, что правильная настройка размеров блока для Performance Read Cache на E-series может дать до 500% увеличения скорости первоначального наполнения кэша. А как вы понимаете, чем быстрее наполнится этот, довольно объемистый кэш на SSD, тем скорее он даст отдачу по ускорению работы с данными.

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

Наконец, значительным отличием от Flash Pool является то, что карта блоков кэша у E-series хранится в оперативной памяти контроллера, а не на диске, как у FAS. Это, конечно, позволяет ускорить выборку (по утверждению NetApp возможно до 700% ускорения), но значительно нагружает память контроллера и занимает в нем много места. Это оправданно для purpose-build стораджа, в котором производительности отдано все, но расточительно для стораджа, в котором память контроллера используется под множество различных задач и функций.

Минимальный доступный объем SSD cache для E-series это один SSD, а максимальный на сегодня - 5TB на сторадж. Причем предлагаются SSD объемом 800GB за “диск”.

Любопытная статья обнаружилась в веб-журнале The Register.

На конференции FAST’11 NetApp читал доклад о экспериментах в рамках проекта Mercury, где исследовалась интересная модель использования flash-памяти для кэширования данных серверов приложений.
Аналогичным работами также занимаются и другие участники “топа вендоров”, например о Project Lightning недавно на своей конференции рассказывал EMC, кроме этого аналогичные эксперименты проделывал Dell, активно прорывающийся в “самую высшую лигу”.

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

Отмечу, что пока речь идет лишь о концепции, научной работе и экспериментах, и до воплощения в коммерческом продукте пока неблизко. Но идея интересная.

Как мне тут не раз уже попеняли, некорректно сравнивать 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.

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