about NetApp

Вчера мы разбирали вопрос “существует ли фрагментация данных на дисках систем хранения 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, которые, я не сомневаюсь, читают этот блог, достойные аргументы в диалоге с ними.