about NetApp

Несомненно одна из “горячих тем” 2008-09 года это SSD - Solid State Disks - “твердотельные” диски на технологии Flash. Они появились повсеместно, от недорогих нетбуков “до 300$” до дорогих серверных систем. В прошлом году использование SSD в системах хранения данных было анонсировано EMC для их линейки Symmetrix.
Часто приходится отвечать на вопросы: “А что же NetApp не реагирует, и не поддержит свое реноме передовой инновационной инженерной компании? Где же у NetApp SSD?”

А NetApp, как всегда, движется своим путем.

Что есть SSD? SSD это flash, знакомый нам уже много лет, но организованный таким образом, чтобы “обманывать” прочие устройства, чтобы те думали, что они работают с обычным HDD.
Этакий аппаратный “эмулятор HDD”. Кроме этого чем SSD отличается от знакомых нам, уже сто лет как, USB-”брелков”? Да по сути ничем. Ну да, SATA это в принципе более производительная шина, чем USB2.0. Да, в современных контроллерах Flash используется чередование и wear-leveling, но все то же самое используется и в современных высокоскоростных USB-”флешках”.

То есть в чем инновационность SSD? Только в том, что мы можем ставить его в те, ранее выпущенные устройства, которые знают и умеют работать только с жесткими дисками.
Некая аналогия с VTL - Virtual Tape Library. Мы можем поставить их там, где софт умеет работать только с ленточными библиотеками, как, например, какние-нибудь запрограммированные на Коболе мэйнфреймы 70-80-х годов. ?? при этом нам не надо ничего менять на стороне остальной системы.
Но в том случае, когда нас не заботит “обратная совместимость” с прежним оборудованием, если мы можем создать IT-систему с нуля, тогда нам, скорее всего, незачем эмулировать поведение ленточных библиотек, мы можем поддерживать диски нативно.
По моему наблюдению, именно это причина плохих продаж VTL в России, по сравнению со всем миром, где VTL совершенно явные фавориты, выпускаемые многими вендорами дисковых систем.
В России просто незначительна проблема “унаследованного оборудования” и “унаследованных решений” (legacy solutions), и проблема совместимости для “начисто” создаваемой IT-инфраструктуры минимальна.
Конечно конкретно NetApp VTL это не только эмуляция, но также множество других, зачастую уникальных фич, таких как Direct Tape Creation и дедупликация, но в основном все так.

Таким образом, EMC решило эту задачу минимально затратным и наименее “умным” способом, просто сэмулировав на высокоскоростных Flash-устройствах обычные диски, подобно тому, как VTL эмулирует “ленточные библиотеки” на дисковых массивах.
Если здоровый человек хорошо размахнется и ударит отбойным молотком, то, конечно, сможет использовать его в качестве обычной кувалды, но нативное его применение может быть гораздо эффективнее.

Возможен ли другой путь? Очевидно, что да.
Эмуляция дисков не единственный способ использования flash-памяти.

Вот, что пишет у себя в блоге уже знакомый вам инженер-разработчик NetApp Костадис Руссос:

“Существует три возможных варианта ситуации с доступом к датасету:
1. Низкий уровень IOPS, малая нагрузка
2. Высокая нагрузка по IOPS, когда датасет помещается в кэш
3. Высокая нагрузка по IOPS, когда датасет НЕ помещается в кэш

Очевидно, что из этих трех сценариев только третий - кандидат на использование Flash-дисков.”

Однако NetApp выбрал иной путь, создав PAM - Performance Acceleration Module, модуль расширения кэша. Своеобразный “SSD”, но не в виде эмуляции дисков, как принято сейчас делать, а на уровне архитектуры системы в целом.

Он же:

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

Я довольно давно собираюсь развернуто написать про PAM и его устройство, те, кто был в этом году на NetApp Innovation 2009 наверняка слышал рассказ специалиста московского отделения компании, Романа Ройфмана, о Performance Acceleration Module.

Надеюсь в скором времени и я напишу подробный рассказ про PAM для читателей этого блога.

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

Вопрос: А как понять величину фрагментированности? Это много, или мало? А если много, то что делать? ?? насколько оно влияет, если много?

Ответ: Давайте разберем по порядку.

В документации, в разделе, посвященном команде reallocate говорится:
reallocate measure [-l logfile] [-t threshold] [-i inter_val] [-o] pathname | /vol/volname

Запуск измерения реаллокации для LUN, больших файлов или томов.

threshold - порог, ниже которого LUN, файл или том считаются неоптимизированными (фрагментированными) достаточно, для того, чтобы запустилась реаллокация, величина от 3 (средне оптимизирован) до 10 (очень сильно неоптимизирован). Значение порога по умолчанию равно 4.

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

Но пока непонятно что же стоит за этой величиной, какой “физический смысл”?

Хочу еще раз привлечь внимание админов NetApp к существованию на NOW большой подборки техдокументации. NOW сегодня не такой плюшевый как, например, MSDN, но пользоваться можно.

“Еще раз”, потому что знаю, что многие админы, пользуясь тем, что системы NetApp на самом деле очень просты в эксплуатации, “настроил раз, за 15 минут, и они работают”, мало внимания уделяют копанию в документации, особенно англоязычной. А зря. В ней много интересного.

Вот, например, статья в Knowledge Base
What do the the WAFL scan measure_layout ratio and measure_layout numbers mean?
“Что означают цифры measure_layout ratio и measure_layout при выполнении операции WAFL scan?”

Для Data ONTAP versions 6.5 и позднее

measure_layout ratio: Это отношение между числом записанных “чанков” (”chunks”, “кусков”) которые занял файл, и теоретическим минимумом числа таких чанков, которые были бы записаны для этой операции на полностью пустой файловой системе. Если ей ничто не помешает, то WAFL запишет данные в последовательные чанки размером 256 KB на каждый диск тома. Но если система не найдет куска последовательных 256 KB свободного места, то она запишет кусок меньшего размера.

measure_layout считает число чанков, в которые попали данные, и делит это число на их минимально необходимое количество. Таким образом наилучший возможный результат равен 1 (число записанных чанков равно числу минимально необходимых для размещения данных), а наихудшее - 64 (когда только один блок данных WAFL, равный 4 KB, попадает в каждый чанк). Основное оценочное правило, если том имеет 1/N свободных блоков (включая 10% WAFL reserve, служебного резервирования файловой системы под ее собственные структуры), то ожидаемая величина будет близка к N (на практике, обычно лучше). Пример (romx): Половина диска пусты (1/2), то следует ожидать величину rate до 2. Четверть (1/4) свободна - до 4.

Наихудшая возможная величина для систем с менее чем 3 GB RAM равна 16 (Sic! romx), исключая системы типа FAS250, FAS270 и FAS270c. Для этих систем наихудшая величина равна 64.

Не спрашивайте меня почему так, я просто разместил объяву я просто перевел статью в KB.

На практике вполне можно достичь значительных величин фрагментации, если поставить такую цель, например при тестировании, ссылку на статью о котором я давал раньше, человек создавал том с fragmentation rate равным 22. При этом, с помощью программы Iometer, в течении 6 часов проводилась непрерывная случайная запись в файл размером 100GB 64-мя одновременными потоками
При этом, ухудшение производительности на фрагментированном с величной rate: 10 (как называет эту величину документация по reallocate - very unoptimized) составило примерно 15 процентов.

Таким образом, наихудшего значения фрагментации для записываемых данных (не для уже записанных!) можно достичь интенсивно записывая на почти заполненный том, с объемом свободного пространства на нем менее 1/16 от общего пространства.

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

На следующей неделе мы продолжим “сеанс черной магии с последующим ея разоблачением”, и рассмотрим другие темы, поднимающиеся нашими коллегами-конкурентами, в отношении продукции NetApp.

Начнем с “классики”. Ни один наш конкурент не обходит вниманием “проблему” фрагментированности записи на том файловой системы WAFL.

Будем считать, что люди здесь собрались взрослые, поэтому я уже могу рассказать вам правду откуда берутся дети как обстоит дело с фрагментацией на WAFL на самом деле.

Вопрос: Правда ли, что запись, даже последовательных фрагментов данных, происходит на системе хранения NetApp в “рандомном” порядке, и записанная порция данных оказывается фрагментированна по пространству диска?

Ответ: Да, в общем случае это так. Это прямое следствие того, что запись на WAFL (Write Anywhere File System) происходит “Anywhere”, повсюду, где это возможно, а не в строго заданные участки, как это происходит у практически всех других файловых систем.

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

Во первых значительную часть проблемы снимает кэширование. Не секрет, что кэширование чтения есть гораздо более эффективный и “прямой” процесс. А за счет того, что данные на запись практически не задерживаются в кэше (можно считать, что кэша “на запись” как такового, такого, какой он есть у конкурирующих систем, у NetApp нет вовсе. Все записываемые данные незамедлительно уходят на диск) весь объем кэш-памяти систем NetApp это кэш чтения, и он не заполняется постоянно висящими в нем данными, ждущими очереди сброса на диск, как это происходит у “обычных^tm систем хранения”.
Все пространство памяти - это кэш чтения.

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

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

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

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

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

Необходимым элементом IT-шного ландшафта, не только в нашей стране, являются, как мы их называем у себя “говнилки”, на языке же наших партнеров (они же “вероятные противники”) это зовется более интеллигентно - “FUD” или “Fear, uncertainty and doubt” - “Страх, неопределенность и сомнения”.
Это сведения, которые выставляют продукцию конкурента “в нелучшем свете”, заставляя клиента беспокоиться и сомневаться в своем мнении, причем зачастую это именно намеренное представление каких-либо свойств как отрицательных.
Обычное дело, манипулировать впечатлением зачастую не слишком компетентного клиента.

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

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

Казалось бы, ну что с того, что какие-то компоненты системы производятся на заводах компании-партнера. В наше время никто не делает ничего в одиночку, все компании связаны сотнями партнерских отношений между собой. Огромное количество оборудования производится по ODM-соглашениям. Наверное 95% ноутбуков, а то и все 100% производится 8-10 заводами малоизвестных массовому кругу китайских компаний, таких как Quanta, Compal, EliteGroup, Twinhead, а затем продаются как Apple, Toshiba, Compaq, Dell.

Межбрэндовая интеграция это давно уже ежедневная реальность.
Но мы же об этом умолчим, предоставляя додумывать клиенту. Вот уже и неопределенность, и сомнения.

“Да у них внутри, не поверите, Винда! Да-да та самая ЭксПи, как вот на этом компьютере!”
“Действительно”, думает клиент, “о какой надежности можно говорить, если уменя сынишка на прошлой неделе “повалил” домашнюю машину свежим видеодрайвером для своей новой дурацкой “стрелялки”. Винда - масдай, это понятно”.

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

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

Я намеренно в примерах привел говнилки на разные компании (sapienti sat), чтобы никому обидно не было. :) В последующх статьях я подробнее остановлюсь на основных темах FUD для NetApp, распространяемых нашими коллегами-конкурентами. Возможно это даст будущим клиентам NetApp, которые, я не сомневаюсь, читают этот блог, достойные аргументы в диалоге с ними.