about NetApp

Когда, весной 2007 года, я начинал вести этот блог, я совершенно не представлял, что его жизнь протянется так надолго и так далеко. Тогда я просто экспериментировал с Wordpress, и, работая пресейлом в компании-партнере NetApp, захотел изложить то, что на тот момент знал о технических “фичах” этих систем хранения “человеческим языком”, для тех, кому это может быть тоже интересно. Но совершенно не предполагал, что все это растянется на 6 с лихом лет!

К сожалению, такая недальновидность предопределила ряд недостатков этого блога. Например, в нем практически отсутствуют средства “навигации” по старым постам, многие его читатели никогда не залезают “вглубь”, и даже не представляют, сколько там за шесть лет накопилось полезного. Как я вижу по статистике, основная масса моих читателей, свыше 90%, никогда не читают более двух-трех страниц блога за посещение. В “глубины” обычно попадают только те, кто пришел через поисковики, и которые ищут что-то конкретное, например мою популярную статью про IOmeter, или сравнительно недавний перевод Recoverymonkey про то, что такое IOPS. ??ли уж совсем древнюю, и в значительной мере утратившую актуальность заметку про то, что такое “кластер” (вот уже много лет из топа запросов этого блога не выходит поисковая строка “кластер это” ;), или “чем отличается NAS от SAN”.

Конечно здесь есть некое подобие рубрик, и даже теги, упорно мною расставляемые, но все равно, очень, очень мало людей читает что-то кроме “витирины” первой страницы. В этом я убедился, когда на прошлой неделе мне довелось поговорить с некоторыми моими читателями “пока-не-покупателями” на темы анти-нетапповского FUD-а наших коллег-конкурентов. ?? я даже загорелся написать статьи-ответы по каждой из таких тем, и даже начал писать, но вдруг понял, что все вот это, просто другими словами, я уже излагал тут раза четыре-пять. Темы FUD-а не меняются уже много лет, ничего нового к ним не добавляется уже давно (это плюс NetApp-у в каком-то смысле ;) раз ничего нового “плохого” даже злейшие конкуренты не находят). Все те же, все там же. Конечно же рассказывают про оверхед блочного доступа на WAFL, про низкий выход usable с данного объема raw, про “снижение производительности” при высокой заполненности тома, Как всегда педалируют “фрагментацию” и “отсутствие балансировки” и доступа к дискам одновременно с обоих контроллеров.

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

Про WAFL и гипотетическом оверхеде для блочного доступа стоит начать с того, что разобраться, что же такое WAFL. Поэтому, прежде всего, стоит начать с отлично написанной работы на тему, которая лежала в основе NetApp как компании, и опубликованной на самой заре ее истории “отцами основателями” ее, двумя инженерами Дейвом Хитцем и Джеймсом Лау: она в переводе опубликована на сайте компании Netwell, которая спонсировала огромную работу по переводам Best Practices. Работа эта, опубликованная впервые на научной конференции USENIX, называется Разработка файловой системы для специализированного файлсервера NFS. Напомню, тогда, в самом начале, NetApp занимался только серверами NFS, но впоследствии, десять лет спустя, в 2003 году, он достаточно легко добавил блочный доступ к данным поверх структур WAFL. То, как это было сделано, и почему WAFL, вопреки ее названию “не файловая система”, или, вернее, нечто, отличающееся от того, что обычно принято называть в IT “файловой системой”, можно прочитать в статье нетапповского инженера Костадиса Руссоса “Почему я считаю, что WAFL – это не файловая система”. Там, в частности, объясняется то, почему блочный доступ на WAFL не является “эмуляцией поверх файлов” (тоже популярная страшилка конкурентов), и почему оверхед в WAFL сравнительно невелик как для файлового, так и для блочного доступа.

О низком результате usable на данном объеме raw-дисков стоит начать чтение со статьи “О цене за гигабайт” и “цене за решение”, где я попытался объяснить, из чего складывается и как формируется итоговая емкость системы хранения NetApp. Полезным также будет прочитать о RAID-DP, и почему именно этот тип RAID используется в NetApp, и о том, как организована иерархия “объектов хранения”, что такое и как соотносятся между собой aggregate, физические диски, тома, LUN-ы, и так далее. Детальный расчет емкости покажет нам, что реальный usable space зачастую первышает таковой у систем, инженеры которых любят указывать на низкий уровень usable у систем NetApp. Наконец, фактические результаты 7 с лишним тысяч работающих у клиентов систем хранения, сообщающие свои данные через Autosupport, показывают весьма высокие результаты – 66,27% составляет фактическая величина usable от имеющегося объема raw-дисков. Это не теоретическая, рассчитанная величина, это фактическое среднее значение usable space реально работающих у клиентов стораджей. Хорошо резюмирующим тему usable space является текст инженера NetApp Dimitris K. “Что стоит за FUD о usable space?”

Про “снижение производительности при заполнении дисков данными” отвечает Richard J. Martin, сотрудник австралийского отделения NetApp в статье Как заполненность данными системы хранения влияет на ее производительность?. Кроме того, можно посмотреть и на официально опубликованный в 2007 году ответ NetApp, когда это утверждение впервые появилось в competitive-материалах компании EMC. Также очень показательным будет и тот факт, что тестирование по методике SPC-1 NetApp проводит с уровнем заполнения дисков данными в 84% от usable (и 60% от raw), а некоторые другие вендоры, показывющие свои результаты в этом бенчмарке – с уровнем 57% от usable и 29% от raw. Если они не боятся “снижения производительности при заполнении данными”, то отчего не покажут результат при 100% заполнения usable?

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

Про то, почему Flash Cache не используется на запись – в статье про устройство Flash Cache и того, как он взаимодействует с WAFL.

О том, почему у NetApp нет tiering-а, а также о том, почему flash-кэширование лучше, чем tiering – в статье про VST – Virtual Storage Tiering, использующий Flash Cache.

В следующих статьях – краткий индекс других полезных постов почитать, опубликованных в этом блоге за 6 лет. А пока же, в комментариях приветствуется, если кто вспомнит, какие еще темы FUD нынче у наших конкурентов актуальны. Может быть я и правда не на все темы написал?

??так, на днях был опубликован новый релиз Data ONTAP 8 – версия 8.2 RC1. Напомню, что в текущей модели релизов, релизы с названием RC (release candidate) являются версиями “готовыми в продакшн”, однако по ним могут быть не завершены различные внутренние compatibility тесты. Тем не менее статус RC у NetApp указывает, что код релиза стабилен, и, как правило, уже не будет меняться, а когда все внутренние процедуры сертификаций будут завершены, то этот код станет уже “не-RC”, как правило уже без фактических изменений. Поэтому RC в терминах NetApp это уже production-ready release.

Так что можно “начинать смотреть” что нам там приготовили. Если вы уже понемногу привыкли, что в мире браузеров теперь “мажорные версии” меняются каждые два месяца, что вызвано, прежде всего попсовыми маркетиговыми соображениями, то и тут у NetApp своя, олдскульная стратегическая модель. По ней 8.2 это мажорный релиз в OS Generation 8 с большими функционалными изменениями. Как вы уже знаете, DOT G7 и 8.х 7-mode в настоящий момент практически заморожены, и все развитие идет в Clustered ONTAP. Посмотрим что именно.

• В Clustered ONTAP появилась поддержка SnapVault
   
• Для уровней Vserver, LUN и файлов появился Quality of Service, который позволяет определять их лимиты по IOPS или MB/s
   
• Реализована поддержа SMB 3.0 для cDOT (Clustered Data ONTAP AKA Cluster-mode), включая Continuous Availability, Witness Node (для Hyper-V) и Referrals (для standard shares).
   
• Появилась поддержка для ODX (Offloaded Data Transfer), функции, появившейся в Windows Server 2012 и Hyper-V 3.0. Как и в случае VAAI, у NetApp ODX позволяет повысить не только скорость работы, но и эффективность хранения, копирование не только ускоряется, но, при наличии лицензии FlexClone, еще и не дублирует занятые блоки.
   
• Продолжется улучшение функциональности для SMB file services, в Clustered ONTAP появились Fpolicy, Remote VSS, Branch Cache, Access Based Enumeration, Roaming Profiles, Previous Versions для снэпшотов NetApp, Folder Redirection, поддержка локальных пользователей и групп, и т.д.)
   
• Поддерживаются Consistency Groups при создании снэпшотов.
   
• Появилась поддержка непрерывающего работу перемещения aggregate в HA-паре без перемещения данных.
   
• Улучшена производительность этапа сканирования при дедупликации.
   
• Теперь в Clustered ONTAP реализована полная поддержка всех опций VMware VAAI для SAN.
   
• Про изменения в лицензиях я уже писал в четверг. Прежде чем планировать апгрейд – обязательно поговорите с вашими контактами в вендоре насчет необходимость получить новые лицензии и того, как это все будет происходить.
   
• Наконец-то появилась “безсвитчевая” конфигурация для двух нодового кластера. Как вы знаете, можно установить Cluster-mode на одну HA-пару контроллеров. Однако ранее это все равно требовало от вас иметь коммутатор 10G для этих двух контроллеров. Теперь воможна конфигурация для двух контроллеров в Clustered ONTAP без коммутатора для Cluster link. При добавлении в кластер второй и далее пары контроллеров, конечно, коммутатор понадобится.
   
• Появилась официальная поддержка для “однонодового кластера”, пример использования – “secondary” системы, например получатели репликации SnapMirror или SnapVault.
   
• Появилась поддержка Intracluster FlexCache.
   
• Вновь увеличены размеры Aggregate. Для старших систем они выросли до 400TB. В целом лимиты практически удвоены для всех платформ.
   
• Число поддерживаемых FlexVol на ноду увеличено с 500 to 1000, за исключением моделей ряда FAS2xxx и старых платформ (FAS3140 и FAS3210). Максимальное число FlexVols на кластер вцелом достигло 6000.
   
• Число LUN на ноду увеличено с 2048 до 8192, с максмальным числом на кластер нод 49.152 LUN.
   
• Infinite Volumes могут жить со стандартными FlexVol-ами и Vserver, добавлена поддержка SMB 1.0 (ранее только NFS), Flash Pool и Unified ACLs.
   
• Появилась возможность иметь разные типы RAID для SSD и HDD в Flash Pool Aggregate. Раньше, как вы помните, если Aggregate состоял из RAID-групп RAID-DP, то и на SSD два диска шли под party disks. Теперь можно сделать для HDD (например SATA) – RAID-DP, а для SSD – RAID-4 с одним parity disk.

Data ONTAP 8.2 RC1 опубликован на NetApp Support Site, и его уже можно качать оттуда.

Процесс постепенного перехода и перевода пользователей с good ol’ 7-mode на shiny new Cluster-mode своей неторопливостью и неспешностью порой мне напоминает ту сердобольную семейку, которая своему щенку фокстерьера хвостик отрезала по кусочку. К меня такое ощущение, что я уже всю жизнь с NetApp провел в процессе transition-а продуктов компании с 7-моде на Кластер. Ну да впрочем хватит бухтеть. :)

На носу у нас Data ONTAP 8.2, с новыми интересными возможностями, а пока на глаза мне попался документ, посвященный изменениям в лицензировании. Как вы заметили, NetApp экспериментиует с лицензированием уже довольно давно, что-то явно получается неплохо, взять хотя бы модель Data ONTAP Essentials.

Начиная с Data ONTAP 8.2 NetApp меняет лицензионные ключи и всю схему лицензий на 7-Mode и Cluster-mode.

Во-первых, вводятся новые, единые лицензионные ключи, единые для 7-Mode и Cluster-mode. Если вы интересовались темой, то знаете, что в Cluster-mode были отдельные ключи, и до 8.2 вам приходилось явно, на этапе покупки системы выбирать, какую систему вы покупаете, чтобы получить нужный набор. Теперь вводятся новые лицензионные ключи софтварных фич, длиной аж 28 символов, которые будут работать на обоих mode Data ONTAP, начиная с 8.2.

Во-вторых, лицензии будут привязаны к серийнику контроллера. Это неприятная новость, но рано или поздно это должно было произойти. На практике, для честного приобретателя, это означает, что теперь, при замене контроллера (head swap), вам также потребуется получит под его серийник новый набор ключей. Соответственно усложняется и удлиняется эта, ранее довольно простая, процедура.

Наконец, лицензи могут существовать “не-cluster-wide”, например часть узлов в кластере может иметь один набор лицензий, а часть – другой, оставаясь при этом единым кластером.* (см комментарий). Напомню, что “кластером” с прошлого года в этом блоге я называю всегда только группу HA-пар контроллеров, работающих в Cluster-mode (C-mode), а то что иногда раньше называлось “кластером”, а именно пара контроллеров под управлением “старой” 7-mode, теперь называется HA-парой (High Availability pair). На HA-пару лицензии по-прежнему единые.

Впрочем, более интересные новости грядут с самим выходом Data ONTAP 8.2, не переключайте ваши браузеры :)

Надеюсь вы помните, что такое NetApp FlexPod. Это разработанный NetApp и Cisco, совместно валидированный “конструктор”, предлагаемый этими компаниями своим партнерам для использования в качестве базового инфраструктурного блока для IT-решений, например под системы виртуализации, баз данных, и прочих подобных задач.

NetApp FlexPod включает в себя систему хранения NetApp FAS3200 и серверную blade-ферму Cisco B-series, сетевое ядро построено с использованием коммутаторов Cisco Nexus 10Gb Ethernet.

NetApp и Cisco проделали большую работу по документированию решения и валидации дизайна, что позволяет, при необхдимости, построить такой FlexPod самостоятельно. В этом отличие FlexPod от других “конвергентных” продуктов на рынке – EMC vBlock и Oracle Exadata, которые продаются как законченные, зафиксированные, неизменные “ящики” от вендора.

В прошлом году был также представлен “FlexPod Lite”, под названием NetApp ExpressPod. Это та же идея, но построенная с использованием компонентов пониже классом, и ориентированная на тех, для кого FlexPod “больно жирно”, то есть NetApp FAS2200, сервера Cisco C-series, коммутаторы Cisco Nexus 3000.

Это решение также валидировано обоими компаниями, например под ферму виртуализации: ExpressPod Infrastructure Solution Implementation Guide
VMware vSphere on ExpressPod
http://media.netapp.com/documents/tr-4107-VMware-vSphere-ExpressPod.pdf

Но всегда было интересно посмотреть, какое же место занимает FlexPod на рынке, среди своих гораздо более именитых конкурентов? ?? вот на глаза мне попались такие результаты, взятые в отчетах Гарднера:

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

На этой неделе NetApp продолжил расширять свою E-линейку, пока еще не слишком известную на российском рынке (впрочем, наверняка вы некоторые продукты оттуда знаете как OEM, например IBM DS, Dell MDS, некоторые другие, менее известные вендоры, такие как SGI и даже Oracle, также продают системы NetApp E-series под своими марками).

Буквально недавно я уже писал про EF540, а вот уже выпущена и E5500, дисковая система классической архитектуры, ориентированная на HPC (High-Performance Computing), и на задачи extra-high bandwidth. Это, обычно, высокопроизводительные вычислительные кластеры, используемые для научных и нженерных расчетов, под задачи области big data, нефтегаз, сейсмика, геофизика, и прочие такие же специализированные штуки.

Основным конкурентом для E5500 в NetApp рассматривают продукты сравнительно малоизвестной в России компании DDN (Data Direct Network), специализированной на перечисленном выше рынке высокопроизводительных, bandwidth-oriented задач, а также столь же “специальный” EMC Isilon.

Отсюда вы уже поняли, как я надеюсь, что это не general purpose сторадж, которыми в линейке NetApp остаются FAS, но если вы работает с вычислительными кластерами, GPFS и Lustre, с big data, с DSS-аналитикой, со всяческими специализированными, скорее научно-инженерными решениями типа геофизики – вот тогда это для вас.

Как вы помните, в прошлом году NetApp активно развивала модели E-series, добавляя в них более привычные для пользователей FASфичи, такие как снэпшоты, thin provisioning, репликацию, и прочее. Всего этого пока, на момент выпуска в марте на E5500 нет, официальный выпуск версии SANtricity для этой модели, с поддержкой всех этих фич, уже доступных для E2600 и E5400, намечен на конец этого года, вероятно еще нужно время на отладку. Однако уже сейчас можно начать использовать с E-series обкатанный на семействе FAS сервис Autosupport.

Не могу также не отметить крайне меня радующий факт, что NetApp, представляя новую модель, очень часто демонстрирует не только маркетинговый булшит общие слова о “крутизне” нового “решения”, но подтверждает их открытыми тестами. В данном случае NetApp опубликовал тест для SGI InfiniteStorage 5600 – это та самая наша E5500, просто продаваемая SGI как OEM-партнером, и ее результаты можно рассматривать как vanilla-E5500. Опубликованы результаты SPC-2. Почему не SPC-1, спросите, возможно, вы? Дело в том, что SPC-2 это high-bandwidth бенчмарк, объемные, но преимущественно последовательные чтения-записи, в то время, как SPC-1 это IOPS-oriented, то есть random чтения-записи. таким образом для general purpose задач, для баз данных OLTP, и прочего, более показательны результаты SPC-1, а для big data, DSS-баз, и прочего, перечисленого выше как рынок E-класса – более показателен SPC-2.

?? результаты там говорят сами за себя:

Тут конечно нет главных игроков, уже упомянутых DDN и Isilon, которые предпочитают не подтверждать маркетинговые заявления открытыми бенчмарками, но и сравнение с уже опубликованными игроками также весьма показательно, в особенности для понимания, почему general-purpose массивы так посредственны и непропорционально дороги на специализированных применениях Big Data и High-bandwidth.

??з интерфейсов подключения поддерживается, как и в случае EF540, такие варианты, как восемь SAS 6Gbit/s, или же шесть Infiniband 40Gbit/s. Для конфигураций, куда нацелен E5500 это все крайне востребовано. С контроллерами E5500 будут также предлагаться несколько различных типов полок расширения, что позволяет стрить различные конфигурации, например много контроллеров для высокопроизводительного ввода-вывода, или же наоборот, много дисков (например уже знакомые вам 60 дисков NL-SAS в 4U полочные конструктивы) для сверхъемких систем. Поддерживаются и SSD для кэширования, как это уже опробовано на E5400.

Отмечу, что многим будет любопытно узнать, что кодовое название проекта E5500 в NetApp было – Soyuz, в честь знаменитой советской, ныне российской ракеты.

На прошлой неделе в группе communities.netapp.com был опубликован Virual Storage Console 4.2 beta.

VSC это основной инструмент для управления и использования стораджами NetApp в среде VMware vCenter, он позволяет управлять системой хранения “с точки зрения” администратора виртуальной инфраструктуры, создавать и удалять датасторы, настраивать их, управлять доступом, создавать резервные копии и клоны, и так далее.

К сожалению пока не поддерживается vCenter Web Client, поворот к которому уже окончательно наметился, VSC 4.2 все еще работает как плагин к “толстому клиенту” vCenter, но работа над новым VSC (вероятно он будет 5.0) уже идут, и близки к финишу. Он будет работать с vCenter Web Client, и использовать платформу Adobe FLEX. Но пока – про VSC 4.2 beta.

??з нового – полноценно поддерживается RBAC (Role-bsed Access Control). В VSC 4.1 RBAC использовать было тоже можно (нужно), и работать под специальным пользователем, а не “под рутом”, но это требовало довольно хлопотных и трудоемких операций по настройке прав такого пользователя. В VSC 4.2 в этом направлении сделаны большие подвижки, настроены templates и настройку можно проводить уже непосредственно из VSC. Вы можете создать отдельно Главного Администратора, отдельно Администратора с правами бэкапа и клонирования, например, отдельного админа для создания датасторов, отдельно юзера с правами readonly, и так далее. Это крайне востребовано в больших инфраструктурах, где, зачастую, на ферме виртуальных машин работает множество разных админов, с разными правами доступа и должностными обязанностями.

Переработана разбивка функций по модулям VSC. Когда-то VSC был надстройкой над разными продуктами, в частности отдельно существовал SnapManager for Virtual Infrastructure для бэкапов и восстановления из них, и утилита RCU – Rapid Cloning Utility, для клонирования датасторов и их провижнинга. Так как уже давно все эти продукты встроены внутрь VSC, давно назрела необходимость перетрясти организацию пользовательского интерфейса VSC.

Ну и, как всегда, поправлены баги (около 150), и добавлена поддержка новых систем в VDDK (например Windows Server 2012).

Бету (да, я осознаю, что такое бета-версия и как ее используют: [x]) можно брать тут:
https://communities.netapp.com/community/products_and_solutions/virtualization/vsc

Вчерашний пост про striped volume вызвал заметную реакцию. Не секрет, что ситуация с использованием концепции share nothing в NetApp FAS, и необходимостью разбивать диски между двумя контроллерами, это давний butthurt головная боль пользователей NetApp, особенно младших его систем. Да, действительно, когда дисков всего 12, допустим, то очень обидно отдавать половину на RAID и spare, по отдельности на каждый из пары контроллеров. Это не является существенной проблемой для людей, у которых дисков шкафы, сотни хостов, подключенных к системе, и так далее. В таких системах нет особенной необходимости для создания единого ресурса хранения, обычно в них LUN-ов и дисковых шар куда больше чем один. Но сомнение зудит. Все умеют, а нетапп не умеет, значит это проблема NetApp.

?? вот, кажется, что NetApp услышал наши молитвы, вот оно, в точности то, что нужно. Все не так просто, погодите. ?? мне стоит сразу дополнить вчерашний пост рядом фактов, которые являются не просто ложкой дегтя, но порядочным таким ведерком его.

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

Striped Volume позволяет:

1. Потенциально может помочь увеличить производительность дискового ресурса, особенно если он такой на системе один, и не может быть распределен своими частями между контроллерами естественным образом.
2. Обеспечивает равномерную загрузку несущих его нодов.
3. Позволяет делать cross-bound ресурсы, например очень большие файловые шары (для LUN это, как правило, не столь важно, так как они сами по себе ограничены, например 2TB в MBR-LUN, или же  64TB VMFS5.

Это так, как я уже упомянул выше, прежде всего в случае, когда такой ресурс (том, LUN, сетевая шара) ровно один. Однако в реальной жизни очень редко когда сторадж несет на себе ровно один LUN, датастор, файловую шару. Обычно, в моей практике, таких ресурсов десяток, и не один. ??, в общем, проблема “одного дискового ресурса” на мой взгляд довольно надумана. Вручную, на маленьких системах, или с помощью имеющихся средств, типа Data Motion и OnCommand Balance, для больших, это сравнительно несложно сделать.

Проблема Cross-bound ресурсов сложнее, но тоже, на мой взгляд, довольно “бумажная”. В свое время, во времена ONTAP GX, когда контроллеры были не чета нынешним, ограничения на объем хранения на одном контроллере дествительно иногда создавали проблемы, и требовали найти пути выхода. Сегодняшние контроллеры часто имеют лимиты по объемам, превышающий реально эксплуатируемые, и, что немаловажно, имеющий смысл эксплуатировать на данном контроллере. Я очень редко вижу ситуацию, когда владелец контроллера NetApp добивает его дисками “под крышку”, до его лимита по объемам. Это просто довольно таки недальновидно с точки зрения производительности системы в целом.

??так, какие же есть “подводные камни” для Striped Volume, и какие ограничения с ним связаны.

Во-первых, как мне уже тут указали “за кадром”, это в настоящий момент фича “положенная на холд”, она не развивается и скорее всего будет выпилена вовсе. Почему – ниже.

Во-вторых, striped volume есть объективное ограничение для самой идеи scaled-out архитектуры. например он требует, чтобы все контроллеры в кластере, по крайней мере в пределах striped volume) были однотипны (одинаковые контроллеры было требованием в GX, но это уже не так в Clustered ONTAP, и именно это направление, по моим наблюдениям, активно развивается компанией). Представьте себе, что striped volume оказался на двух узлах кластера: FAS6240 и FAS2240. Что будет с производительностью такого тома?

Соответственно использование striped volume естественным образом убивает возможность миграции тома между узлами кластера, крайне важной и нужной фичи Clustered ONTAP. Как результат, это делает невозможность миграцию такого тома в пределах кластера, например если вам нужно выполнить обслуживание или отключение одного из кластеров, содержащих striped volume. Соответственно это потенциально понижает общую availability кластерной системы в целом.

Наконец, люди, пользовавшиеся striped volume отмечали странное поведение и глюки, в особенности в области производительности, а так как, см. выше, эта фича явно идет в разрез с основным движением Clustered ONTAP в компании, то, вероятнее всего, эта фича будет вскоре просто убрана как таковая, и уж точно доделывать и вылавливать баги из нее не будут.

?? последнее, задача сверхбольших томов в  настоящее время решается с помощью Infinite Volume, и не требует поддержки striped volume.

Таким образом, несмотря на то, что фича striped volume в Data ONTAP Cluster-mode и имеется, использовать ее в реальной жизни, иначе, как  если у вас абсолютносовершенноточноиникакиначе имеется такое требование для ее использования, объективно не стоит.

Следует отметить, что новости про 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 (по разным причинам, не буду вдаваться в детали, уже писал неоднократно почему), но как-то так, в насмешку над моими словами, жизнь заставляет писать о них почаще. А сегодня есть повод еще раз поднять тему 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, от своего имени, в России их не продавал.

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