about NetApp

??з всей троицы продуктов, появившихся у NetApp этим летом, а именно: FAS2500, FAS8080EX и NetApp AFF, совершенно неожиданно для меня именно последний стал предметом преткновения, пост про который я пишу уже вторую неделю. Если про FAS2500 я написал сразу, и там, в целом, все ясно по прочтении техспек и  Technical FAQ / SE Presentation, если c FAS8080ES тоже все ясно, это “больше, выше, сильнее”, вот, в общем, и все что про него можно рассказать, я даже отдельно про него писать не стану, то вот в отношении All-Flash FAS такая ясность долго не наступала. ?? далее я попробую рассказать, в чем, собствено, состоял предмет затруднения.

Continue reading ‘NetApp AFF: All-Flash FAS’ »

Flash Pool - это способ использовать установленные в систему хранения SSD в качестве кэша для операций записи и чтения. При этом они составляют с обычными жесткими дисками так называемый hybrid aggregate, и активные операции, как записи, так и чтения, могут эффективно кэшироваться на пространстве этих SSD, позволяя использовать все преимущества flash на обычных дисковых системах хранения.
Об этой технологии я писал в блоге не раз, однако за эти несколько лет, что Flash Pool доступен к использованию на системах хранения NetApp, у некоторых потенциальных клиентов NetApp Flash Pool сложилось мнение, что для полноценного, эффективного использования возможностей Flash Pool нужно иметь достаточно мощный контроллер сам по себе, и что широко распространенные и очень популярные контроллеры класса FAS2200 не дают существенной выгоды от использования Flash Pool, просто потому что “силенок у них его раскачать не хватает”.
Для того, чтобы раз и навсегда ответить на этот вопрос, аналитическая компания ESG провела по просьбе NetApp сравнительное тестирование двух систем:

1. FAS2240-2, c 48 2.5″ 900GB 10Krpm дисками SAS, с общей емкостью 42TB raw
2. FAS2240-4, c 32 3.5″ 2TB 7.2Krpm дисками SATA, плюс 4 дисками SSD 200GB, и общей емкостью 64TB raw

В качестве нагрузки были протестированы типовые нагрузки, характерные для:

1. OLTP database (100% random, 66/33 read/write, мелкими блоками, чувствительный к responce time) MS SQL Server 2010.
2. Нагрузка, характерная для Exchange Server (2010).
3. Нагрузка файлового сервера (переменные размеры блоков, большой объем работы с метаданными)

Физический сервер, на котором под VMware vSphere 5.1 были развернуты две тестовые VM (Windows Server 2008R2), и которые были подключены одним каналом 10G Ethernet к системе хранения по протоколам iSCSI и NFS. Все три рабочих нагрузки генерировались с помощью IOmeter на тестовых VM вперемешку, одновременно.

Результат (слева - all-SAS FAS2240-2, справа - FAS2240-4 (SATA +4xSSD):

Резюмируя же “в цифрах”:

Система с Flash Pool вида SATA+SSD, показала существенно лучшую производительность, чем точно такой же контроллер, но работающий с 48 SAS-дисками. Величина выигрыша была различной для разных профилей, но выигрыш был всегда. (максимально - 48% - на OLTP, минимально - 15% - на fileserver). Одновременно с этим на 31% улучшился responce time.
При этом система с Flash Pool имела на 48% больше емкости хранения, и, одновременно, была на 18% дешевле, чем система с SAS-дисками.

Цена за GB и на IOPS улучшилась, соответственно, на 45 и 40 процентов, а общая пропускная способность улучшилась на 34%, причем при использовании более медленных “по природе” дисков SATA.

Как вы видите, даже на таком, сравнительно слабом контроллере, как контроллер самой младшей не сегодня системы хранения NetApp FAS, результат использования Flash Pool является более чем впечатляющим.

Подробно о методике тестирования и деталях можно прочитать тут: http://www.esg-global.com/lab-reports/netapp-fas2200-series-with-flash-pool/

Наконец-то опубликованы долгожданные результаты тестирования Flash Pool (гибридный aggregate с SSD в полке), показывающие эффект от его использования на задачах OLTP баз данных. Полностью отчет с описанием можно прочитать в соответствующем Technical Report, а для затравки просто картинка (а в отчете есть еще):

В работе также приводится подробное описание тестируемой конфигурации и настроек Oracle.

Следует отметить, что новости про 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 показывает, что концепция жива, здорова, и передает всем пламенный привет с нового уровня своего развития. Ждем более подробных новостей с техническими деталями.

В одном из предыдущих постов я начал описывать то, как, с помошью политик кэширования Flash Pool можно настроить индивидуально параметры кэширования для томов. Однако кроме кэширования чтения у Flash Pool появидлись средства и кэшировать запись. ??х немного, но они есть.

В настоящий момент имеется два варианта настройки кэширования записи (и один – и чтения и записи разом, который зачислен в “чтения”, и о котором я упомянул в предшествующем посте на эту тему):

• write-cache = none – тут нечего особенно рассказывать, это отключение кэширования записи, когда она включена в режиме кэширования во Flash Pool по умолчанию. Параметр этот может быть задан на каждый конкретный том, и использовать его стоит в тех случаях, когда кэширование записи не приносит пользы, например когда рабочая нагрузка не делает многочисленных и частых random-перезаписей данных тома (а напротив, записи идут секвентальные, большими блоками). С использованием такой опции данные пойдут непосредственно на HDD, собственно как они и записывались ранее, в обычных aggregates, без использования Flash Pool. В случае такого характера нагрузки данных тома, вы освободите место на кэше для тех, кому оно действительно необходимо.
• write-cache = random-write – эта опция, напротив, включает кэширование записей на aggregate для данного тома через flash. При этом данные сперва попадают в пространство SSD и кэшируются на нем. Такая политика должна хорошо работать для задач, когда данные, рандомно записываемые на том, часто перезаписываются, или перечитываются сразу после записи. Это значение политики записи по умолчанию.

Как я уже упоминал в предшествующей заметке, для управления настройкой кэширования томов на Flash Pool теперь используется новая команда priority, имеющая следующий синтаксис:

priority hybrid-cache set <volume name> read-cache=<value> write-сache=<value>

Долгожданный 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: некоторые тонкости применения’ »

В предыдущем посте я показал, как создать и начать использовать гибридный aggregate (flash pool) с использованием дисков SATA для хранения, и SSD для кэширования обращения.
Но aggregate может содержать на себе множество томов, и, часто, разные тома потребуют разных режимов использования. Flash Pool конечно имеет возможности индивидуальной настройки параметров кэширования для тома. Делается это так:
С помощью команды priority можно указать следующие варианты политик кэширования чтения:

• read-cache = none - эта политика отключает кэширование чтения для данного тома вовсе. Например мы хотим сэкономить место в кэше для более ценных данных, или чтение с этого тома редкое и длинными последовательными кусками, затем не перечитываемых повторно, и их кэширование просто непроизводительно замусорит кэш.
• read-cache = meta - эта политика кэширует операции чтения метаданных. Такая политика полезна для томов, на которых значительную часть операций составляют операции чтения метаданных. Например это операции с большим количеством сканирований директорий со значительным количеством (сотни и тысячи) файлов, поиска и выбора среди них.
  Операции чтения метаданных довольно затратны, так как представляют из себя рандомное чтение мелкими блоками, и кэширование таких операций очень эффективно (и при этом может не занимать больших объемов в кэше).
• read-cache = random-read - эта политика, что очевидно из названия, кэширует операции чтения, идущие в произвольном порядке. Причем кэшируются ?? метаданные, ?? собственно данные одновременно. Эта политика как бы включает в себя предыдущую, но расширяет кэш и на собственно считываемые данные. Это политика по умолчанию. Если вы не переопределите ее, то действовать будет именно она. Обратите внимание, что ‘random’ означает, что sequental-операции будут исключены из операций кэширования (оно и правильно).
• read-cache = random-read-write - несколько парадоксальным образом эта политика считается политикой кэширования чтения. С ее использованием к кэшированию операций чтения добавляется новый для NetApp процесс кэширования операций записи. Впрочем, о политиках по кэшированию операций записи мы поговорим в одном из следующих постов.

Командная строка настройки политик кэширования для тома выглядит так:
priority hybrid-cache set <volume name> read-cache=<value> write-сache=<value>

С выходом Data ONTAP 8.1.1 (сейчас он, для самых нетерпеливых, находится в состоянии Release Candidate) появляется долгожданная фича под названием Flash Pool (он же, ранее, Hybrid Aggregate)

??так, давайте посмотрим, как можно создать Flash Pool, то есть aggregate с дополнительными дисками SSD для кэширования данных.
Создадим для начала простой aggregate:

fas01> aggr create flashpool -B 64 -t raid_dp -T SATA -r 16 16

??мя aggregate: flashpool, формат: 64-bit, тип RAID: RAID-DP, тип дисков: SATA, размер RAID: 16

После успешного создания aggregate по имени ‘flashpool’ разрешим на нем собственно flashpool:

fas01> aggr options flashpool hybrid_enabled on

Несмотря на то, что коммерческое название фичи было изменено в релизе с ‘hybrid aggregate’ на ‘flash pool’, опция по прежнему называется ‘hybrid’. Аналогично с дедупликацией, которая когда-то называлась A-SIS (Advanced Single Instance Storage), и до сих пор так называется соответствующая опция в параметрах.

Теперь можно добавить к aggregate диски SSD в количестве 6 штук:

fas01> aggr add flashpool -T SSD 6

??з 6 штук два будет забрано под RAID parity (RAID-DP), а оставшиеся 4 - будут использованы как кэш. Обратите внимание, что сам aggregate не увеличится в емкости хранения! Добавленные SSD недоступны для непосредственного использования и записи на них данных, они будут использованы как кэш.

А теперь просто создадим на получившемся aggregate том (myvol) для хранения данных, емкостью 500GB:

fas01> vol create myvol flashpool 500g

Теперь получившийся том myvol, размером 500GB, можно использовать под данные, причем записываемые и считываемые данные будут автоматически использовать кэш на SSD.
В следующем посте мы посмотрим, какие средства есть для тонкой настройки режимов кэширования томов на Flash Pool.

Ну, так как до выхода 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, которая ожидается к выпуску в ближайшем месяце.