about NetApp

Несмотря на то, что я уже не раз в этом блоге обещал не слишком писать про NetApp E-series (по разным причинам, не буду вдаваться в детали, уже писал неоднократно почему), но как-то так, в насмешку над моими словами, жизнь заставляет писать о них почаще. А сегодня есть повод еще раз поднять тему E-Series, потому что в ней появился интересный продукт – Flash Array.

??з названия нетрудно догадаться, что это становящийся сегодня все более популярным так называемый all-flash массив, то есть сторадж сделанный только на flash SSD, без классических, “вращающихся” дисков вовсе. На рынке уже несколько лет как присутствуют такие устройства, прежде всего это системы хранения производства компании Violin Memory, пионера подобных систем, и Texas Memory Systems (ныне принадлежащая IBM).

Если вы читаете этот блог достаточно давно, то вы уже знаете, что в линейке NetApp есть самые разнообразные продукты с использованием Flash, можно даже сказать, что NetApp имеет вообще все возможные варианты, и в этом по своему уникальна. Считайте сами: FlashCache, встроенный в систему хранения кэш на flash memory, Flash Pool, гибридный дисково-flash-евый массив, прозрачный для пользователя и его задач, FlashAccel – софтверное решение, позволяющее использовать диски SSD на стороне сервера интегрировано, в общей инфраструктуре хранения, и вот, наконец, четвертый возможный вариант использования flash, all-flash array, “дисковый” массив состоящий из чистых SSD.

Как показывает нам его название, он построен на базе весьма удачных массивов “классической” архитектуры, досташихся NetApp вместе с приобретенным несколько лет назад подразделением компании LSI под названием Engenio, производящей крайне удачные блочные массивы по OEM-контрактам, вы их, уверен, хорошо знаете как дисковые массивы IBM DS, а также ряд других систем хранения от других компаний. Это все – Engenio, ныне подразделение NetApp.

Под крышей NetApp Engenio получила “второе дыхание” и дисковые массивы “традиционной” блочной архитектуры используются NetApp для ряда специальных проектов, например для grid-систем под Hadoop, или для систем video surveilance, а также поставляются всем прежним OEM-клиентам Engenio.

Вот на базе дисковой полки и контролллеров 5400-серии и был сделан EF540 Flash Array.

Вид контроллеров сзади:

Система поставляется в двух вариантах: с 12 и с 24 дисками MLC SSD на 800GB raw (то есть с суммарной емкостью 9,6 и 19,2 TB raw) и обеспечивает в максимуме около 300 тысяч установившихся IOPS чтения (100% random read, 4K) при менее 1 ms latency (или же около 6GB/s throughput большими блоками, то есть, конечно, не одновременно с 300K IOPS).

На контроллерах в стандартном форм-факторе SBB v2.0, слева направо:

Порт USB для диагностики и обслуживания. Два порта Ethernet для управления (это НЕ для передачи данных! Только для админнистрирования! Ни iSCSI в базе, ни NAS тут нет!), далее 4 независимых порта 8Gb/s FC. Правее находится схемный модуль, так называемый Host Interface card, в котором располагается, на рисунке, последовательная консоль и порт SAS 6Gb/s drive expansion, который в EF540 НЕ ??СПОЛЬЗУЕТСЯ, подключить к EF540 дополнительные полки НЕЛЬЗЯ.

Кроме показанного на рисунке также возможны иные варианты такого Host interface module, например с еще плюс 4x 8G FC, 4x 6G SAS (не для расширения, а для IO, например для подключения в SAS Switch и доступа по ним от сервера), 2x 10G iSCSI или же 2x 40G Infiniband (в последнем случае штатные порты FC отключены). На контроллере также располагается 12GB кэш-памяти. Поддерживаются типы RAID – 0,1,5,6,10.

Нацелены данные системы, прежде всего, как и все E-series в линейке NetApp, на определенную узкую “нишу” крайне высокопроизводительных приложений, это, прежде всего, энтерпрайзные базы данных, где latency играет решающую роль, и за что, следует специально подчеркнуть, компании готовы платить, и платить много. Это НЕ системы “для всех”, это нишевое решение для тех, у кого предельно низкие значения IO latency это решающий фактор.

Ну и, конечно же, как правило, EF540 будет использоваться не столько сама по себе, сколько как компонент более высокоуровневого решения, включающего в себя не только стораджи E-series, но и те же FAS, например уже готов TR, посвященный построению высокопроизводительной базы данных на Sybase ASE, с использованием FAS6200 для хранения данных, и EF540 для ускорения определенных операций, работающих вместе.

??, “чтобы два раза не вставать”, по некоторым слухам, NetApp в России намеревается в ближайшее время начать продавать стораджи семейства E5400 по своему обычному каналу, через партнеров, ранее, напомню, эти системы хранения можно было купить только как OEM-продукт, например через IBM, как  DS35xx, сам NetApp, от своего имени, в России их не продавал.

Долгожданный Flash Pool (AKA Hybrid Aggregate) наконец-то вышел в релиз с появлением версии Data ONTAP 8.1.1. О том, что это такое я уже писал, но для тех, кто все пропустил, и не желает посмотреть в поиске по этому блогу, вкратце: это технология, которая позволяет создать комбинированный aggregate на системе хранения NetApp, в которй добавленные в aggregate диски SSD (на flash memory) используются для кэширования данных, читающихся, а также пишущихся на тома этого aggregate. Эта технология расширяет и дополняет уже имеющуюся несколько лет у NetApp для систем его midrange  и highend линейки, технологию Flash Cache, выполненную в виде карты flashmemory, и устанавливаемую внутри контроллера системы хранения.

Однако, как слюбой новой технологией, у нее существуют некоторые тонкости применения, неочевидные места, а то и просто засады. Вот о них мы сегодня поговорим подробнее.

Continue reading ‘Flash Pool: некоторые тонкости применения’ »

На днях NetApp довел до коммерческого использования и выкатил в паблик фишку, которой давно занимался на уровне исследований и перспективных разработок: Flash Accel.
Это софтовая реализация идеи создания и использования кэш-памяти во flash на стороне хост-сервера. В прошлом году я уже немного упоминал о этой штуке, в связи опубликованным Advanced Technology Group, подразделением NetApp, разрабатывающем перспективные направления и идеи, на конференции USENIX FAST’11 докладом о Project Mercury.

Вкратце о том, что это и зачем.
Если о кэшировании во flash на стороне стораджа слышали уже наверное все, и многие уже даже это успешно применяют, то вариант кэшировать обращения к данным поближе к собственно работающим с этими данными процессорам, а не на другой стороне длинного “провода”, сперва кажется еще более интересным, производительным и многообещающим. Но тут же возникает масса вопросов.
Как управлять этим кэшированием? Как обеспечить “когерентность” кэшей между хост-системой и системой хранения, и между данными в таком кэше и данными, хранимыми на дисках системы хранения? Что делать в случае миграции данных между хост-серверами, например при использовании средств High Availability и кластеризации? Наконец, как быть в случае перезагрузки или “падения” сервера с данными в его локальном кэше?

Многие вендоры систем хранения сейчас занимаются этим направлением, это и EMC, и Dell, и, конечно NetApp, в концепцию Virtual Storage Tiering (VST) которого такая схема ложится как нельзя лучше. Так что появление релиза было в даном случае вопросом времени, я уверен, что остальные вендоры быстро подтянутся.

Пока же кратко о Flash Accel, самое важное:

1. Это полностью программная реализация, поддерживающая VMware ESX и MS Windows 2003/2008, которая работает с любым сторонним продуктом, с любой flash-картой PCIe (Например от FusionIO или LSI), а также и с SSD-диском в сервере, вариантом, становящимся сейчас очень распространенным.
2. Это открытая реализация, она не ограничивает пользователя какими-то определенными вендорами flash-устройств, и не требует для своего использования какого-то железного продукта от самого NetApp. ??нтеграция с Flash Accel каких-то дополнительных сторонних продуктов это открытая “экосистема”, сейчас, например, NetApp объявил о партнерстве с FusionIO, и рядом других вендоров (LSI, Virident).
3. В настоящий момент эта фишка явственно нацелена, в первую очередь, на область систем серверной виртуализации, на интеграцию с хост-серверами виртуальных машин (например VMware vSphere: поддерживаются HA, vMotion, DRS).
4. Поддерживается до 2TB кэша flash на хост, с примерно 0,5% оверхедом по памяти для сервера.
5. В публичную доступность Flash Accel выйдет в декабре этого года.
6. Flash Accel объявлен бесплатным продуктом.

Несомненно, Flash Accel не является продуктом “сам по себе”, а будет интегрирован в общую концепцию NetApp Virtual Storage Tier (VST), вместе с Flash Cache и Flash Pool, решениями кэширования на стороне стораджа, и позволит, своим применением, еще улучшить ситуацию с latency и производительностью по IOPS для виртуальных машин.

Ну, так как до выхода 8.1.1 уже совсем немного времени, давайте я уже расскажу вам, что же такое Flash Pool, который появится у NetApp начиная с этой версии.

Я ранее уже несколько раз упоминал о новой идее NetApp – включении нескольких SSD непосредственно в дисковый aggregate системы хранения, и использования их под кэш “уровня aggregate”, в том числе и для записи. Эта конструкция дополняет возможности Flash Cache, может работать как с ним вместе, так и сама по себе, причем, отметьте, также и для систем, на которых Flash Cache, по тем или иным причинам, использовать уже нельзя, например FAS3210, 3140, и даже 2240.

К моменту выпуска, реализация Hybrid Aggregate в системах NetApp получила собственное, коммерческое имя-торговую марку Flash Pool, и далее я буду пользоваться именно им. Вы же знайте, что Flash Pool это название реализации NetApp Hybrid Aggregate в Data ONTAP 8.1.1 и новее.

К сожалению, вокруг Hybrid Aggregate/Flash Pool уже начало образовываться облако недопониманий и мифов, а моя задача в очередной раз внести ясность в тему.

??так, начнем.

Прежде всего, я бы хотел сказать, что, вопреки домыслам, Flash Pool это НЕ tiering, в классическом его понимании (например в том виде, в каком он представлен в EMC FAST), это кэш. Этот момент понятен? НЕ disk tiering, not, nicht, nie. :) Это КЭШ.

Появление Flash Pool также не означает отказа от Flash Cache. Это независимое, но дополняющее решение. Он может работать с Flash Cache, может работать сам по себе. В случае работы с Flash Cache, кэширование не дублируется. Тома, работающие с Flash Pool (находящиеся в аггрегейте с SSD) не кэшируются в Flash Cache. Помните, что Flash Cache может работать со всеми aggregates и volumes системы в целом, а кэширование Flash Pool распространяется только на тома одного aggregate. Если у вас несколько aggregates, вам понадобится добавлять SSD для создания Flash Pool в каждый aggregate, который вы хотите кэшировать в Flash.

В гибридный aggregate, то есть Flash Pool вы можете преобразовать любой 64-bit aggregate, добавив в него несколько SSD NetApp, объединенных в RAID-группу, и указав для aggregate соответстующую опцию, также его можно создать “с нуля” обычным способом, как любой aggregate. Но в создании Flash Pool есть несколько тонких моментов, именно на них я хочу остановится подробнее.

Так как Flash Pool это кэш, то есть SSD, как таковые, не доступны для непосредственного хранения на них каких-то конкретных данных, а лишь кэшируют поступаюшие на и считываемые с томов aggregate данные, добавление в aggregate SSD не увеличивает его емкость. Есть и “побочный эффект” – если вы имеете aggregate, достигший максимального возможного для данного типа контроллеров размера, например 50TB для FAS3210, то вы все равно можете добавить в этот 50TB-аггрегейт диски SSD для Flash Pool.

Тип RAID-группы для дисков, добавляемых в aggregate должен быть одинаков для всего aggregate. Если вы используете RAID-DP, то добавляемые SSD тоже должны быть в RAID-DP. Нельзя в aggregate из HDD в RAID-DP добавить SSD в RAID-4, например.

Обратите внимание, что возможность добавления в aggregate дисков SSD НЕ означает возможности добавления в aggregate дисков HDD другого типа. Flash Pool може быть (по вашему выбору) из SAS/FC и SSD, или из SATA и SSD, но НЕ из SAS и SATA.

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

Наверняка у многих уже вертится на языке вопрос: “Как же нам воспользоваться Flash Pool, если NetApp продает SSD только в составе полки на 24 диска?” Отвечаем: С появлением Flash Pool SSD NetApp будут продаваться паками по 4 штуки, что дает вам во Flash Pool 142GB кэша из 4 SSD. Диски имеют размер 100GB [84574 MiB], и когда они включаются в aggregate, построенный на RAID-DP, вы получите из 4 дисков два диска parity и два – data. Конечно, вы можее включить в Flash Pool и больше SSD.

Однако помните, что SSD имеют интерфейс SATA. Это значит, что вы НЕ МОЖЕТЕ добавить SSD непосредственно в полку с дисками SAS. Но можете – в полку с дисками SATA. Смешивать физические интерфейсы дисков в составе одной полки нельзя. Таким образом, если у вас система с “только-SAS/FC”, вам понадобится для установки SSD, даже всего 4 штук, например, дополнительная полка “только-SATA”. Не забывайте об этой сложности.

Вопрос, который я уже тоже слышу :) “Вы говорите – SSD работает на запись? А как же с исчерпанием ресурса на перезапись для SSD?”

Ну, это тема. Да, безусловно, с этой точки зрения Flash Cache был принципиально более надежен, так как работал только на чтение, а записи (заполнение кэша) в него делались сравнительно (по меркам компьютера) редко, и большими “порциями”, которые flash memory как раз обрабатывает довольно хорошо, это не random write мелкими блоками. Однако практика использования SSD enterprise-class показывает, что проблема пресловутого “исчерпания ресурсов SSD при записи” в значительной мере надумана, преувеличена, и присуща, в основном, “бытовым” SSD. Тем не менее, эта проблема возможна, так как Flash Pool действительно пишется, работая на запись (хотя, вы не забыли, записи в WAFL не рандомны, а секвентальны). Для защиты данных в случае выхода SSD из строя вы как раз и используете объединение SSD в RAID, а сами SSD, как устройства, покрыты общей трехлетней warranty на систему.

На самом деле в отношении записи вы можете столкнуться с другой, более важной, чем мифическое “исчерпание ресурса на запись” неприятностью. Дело в том, что устройство flash таково (это так для любого flash-устройства”), что его производительность на запись падает, по мере активной записи (и пере-записи) данных на нем. Производительность SSD на запись максимальна, когда он полностью пуст и только пришел с завода.  После того, как данные на SSD записываются, перезаписываются, и он постепенно заполняется данными, его производительность постепенно снижается, и стабилизируется на более низком, чем начальный, уровне, после того, как все его ячейки будут перезаписаны. С этим эффектом знакомы все владельцы SSD. Так что не экстраполируйте результаты первого испытания пустых SSD на всю его работу.

Отвечая на третий вопрос ;) : Да, TRIM для SSD поддерживается Data ONTAP на уровне системы.

Напомню, Flash Pool, новое название Hybrid Aggregate, появится в Data ONTAP 8.1.1, которая ожидается к выпуску в ближайшем месяце.

Некоторые новости с прошедшего в Риме NetApp Insight 2011, главного мирового мероприятия NetApp, на котором, обычно, представляются все новинки года. На этот раз я обратил внимание на объявленную любопытную технологию, которая появится в Data ONTAP 8.1.1, под названием Hybrid Aggregate.
Вот что это такое.

Как вы знаете, NetApp использует flash, прежде всего, в форме “расширения кэш-памяти”, а не как “эмуляцию диска” – SSD – Solid State Disk, у такого решения множество преимуществ на практике, и широкий успех Flash Cache, устройства для систем хранения NetApp, представляющего собой плату с 256/512/1024GB flash на ней, и устанавливаемую внутрь контроллера FAS3200/6200, тому подтверждение.

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

Hybrid Aggregate это, как нетрудно догадаться из названия, “составной” aggregate, состоящий из обычных “врашающихся” дисков и SSD. В такой структуре диски SSD обеспечивают “кэш на запись” для традиционных, “вращающихся” дисков в составе этого aggregate.

Основные отличия Hybrid Aggregate от Flash Cache следующие:

• Работает в том числе и на запись. В тех случаях, когда характер нагрузки системы пользователя представляет собой, преимущественно, большое количество операций записи сравнительно небольшими блоками, Flash Cache неэффективен, так как практически не ускоряет записи (в определенной степени он их ускоряет, но только за счето того, что, высвобождая ресурсы дисков за счет кэширования чтения, оставляет больше на обработку операций записи). Следует отметить, что рабочая нагрузка, представляющая собой, главным образом, объемный random write мелкими блоками, это довольно специфическая и не слишком массовая задача.
• Hybrid Aggregate может быть несколько на одной системе, каждый из них может быть настроен индивидуально и независимо от других. Flash Cache работает на все aggregate разом, хотя и можно политиками FlexCache настроить приоритеты и политики кэширования для разных томов.

Как мне видится, преимущества от Hybrid Aggregate получат прежде всего большие и очень большие системы, с сотнями дисков, с большими aggregates и очень большим трафиком ввода-вывода, или же системы со специфической рабочей нагрузкой (большой объем преимущественно записей мелкими блоками), кроме того следует помнить, что Hybrid Aggregate не исключает использование и Flash Cache, он вполне может использоваться вместе с Hybrid Aggregate на той же системе. Таким образом, появление Hybrid Aggregate не стоит трактовать как “отказ от Flash Cache” (я специально делаю это замечание для “паникеров” ;) или признание его неэффективности, это, скорее дополнение в ранее незакрытом сегменте рабочих нагрузок и специфических решений.

Любопытная статья обнаружилась в веб-журнале 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.

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

Совсем недавно я рассазывал о том, что такое Flash Cache (PAM-II) и как он работает, а вот уже и новости подоспели. NetApp объявила, что с сентября 2009 года, когда был объявлен Flash Cache и начались его поставки, c с системами хранения NetApp продан уже петабайт емкости на flash-памяти в Flash Cache.

Напомню, что Flash Cache это устройство в виде платы расширения, содержащее 256 или 512GB SLC NAND Flash, и устанавливаемое в системы хранения  FAS3×00 и FAS6000. Максимальная емкость  в самых старших системах линейки может достигать 4TB на систему. ??спользование Flash Cache позволяет значительно повысить быстродействи операций в IOPS, снизить время отклика (responce time, latency), увеличить энергоэффективность решения за счет отказа от многочисленных  “дисковых шпинделей” и можества дисковых полок, необходимых для обеспечения быстродействия системы, и заменяемых на Flash Cache.

В отличие от уже становящегося традиционным использования flash в форме SSD, то есть хранилища данных, дисков, Flash Cache работает как кэш “второго уровня”, в форме “памяти”, обеспечивая решение проблемы “холодных данных”, и повышая эффктивность использования дорогостоящего SLC Flash.

Подробнее о Flash Cache, как и о PAM-I, можно прочитать в переведенном руководстве Flash Cache (PAM-II) and PAM: наилучшие методы использования (PDF)