about NetApp

Природа не терпит пустоты: там, где люди не знают правды, они заполняют пробелы домыслом.
Джордж Бернард Шоу

В прошлом посте я начал детальный разбор довольно объемного текста, написанного специалистами компании HP о том, как и в чем они видят недостатки систем хранения NetApp. Так как с их стороны это оказалось крайне субъективное и неточное изложение вопроса, грешащее многочисленными ляпами, более или менее неосознанными заблуждениями и непониманием ряда основополагающих технологий, использованных у NetApp, я счел себя обязанным не оставлять его без ответа, и написать эту комментрованную рецензию, которую и предлагаю вашему вниманию. Это – вторая половина текста, смотрите первую часть в предыдущем посте.

Я намеренно выбрал тут тактику “чистой обороны”, и ничего, или почти ничего не говорю о свойствах и недостатках систем “противной стороны”, хотя, безусловно, у NetApp есть что острого и ехидного спросить у HP на их счет. Я лично считаю жанр “говнилок”, в котором написан исследуемый текст, довольно-таки “грязным”, он пишется, как правило, анонимно, и, по законам жанра, изобилует полемическим передергиванием, лично я считаю, что писать такие тексты – западло (давайте я уже скажу это слово ;). Но – “с волками жить – по волчьи выть, иначе будешь сидеть без бонусов”, я понимаю что именно заставляет такое писать.

А теперь давайте продолжим разбор обсуждаемого документа.

Continue reading ‘Что HP думает о NetApp, и как все обстоит на самом деле. Часть 2’ »

Пару недель назад мне в руки попал текст, подготовленный специалистами компании HP, продававшей систему HP 3Par, или как она сейчас называется, StoreServ 7000 против предложенного уже этому клиенту midrange NetApp. Документ относится к популярному в российском IT жанру “говнилок”, или, выражаясь интеллигентно – FUD (Fear, Uncertainity and Doubt). Как правило такие документы мне приходится встречать со стороны пресейл-инженеров компании EMC, но впервые мне попадается в полном виде текст от HP, этим он особенно интересен. HP, как компания, находится в довольно-таки привелигированном положении на рынке, в особенности на российском. Это большая, крайне авторитетная компания “полного стека”, которая может предложить своим клиентам полный спектр оборудования, от серверов и систем хранения, активное сетевое оборудование, до шкафов и UPS.

Тем печальнее, что за последних 10 лет отдел систем хранения в компании был в явном “загоне”. Обладая в начале 90-х передовой и в чем-то даже революционной системой хранения EVA (Enterprise Virtual Array), компания “почивала на лаврах” и допочивалась до того, что EVA на рынке катастрофически морально устарела. Весь мир стораджей ушел вперед, за новыми модными фичами, а HP как продавала в мидрендже – EVA, в high-end ребрендированный Hitachi USP, а в энтрилевеле – DotHill, так и продавала. ?? допродавалась до катастрофических результатов. Сегодня из компаний в External Storage Top5 только HP теряет объемы продаж, все остальные растут.

Вовремя (надеюсь) спохватившись, HP активно занялась обновлением своего стораджевого портфолио, традиционно “взяв под крыло” несколько небольших компаний с их интересными продуктами, таких как LeftHand и 3Par, и которым явно не хватало веса “продавиться” на рынок. Однако атмосфера долгого застоя в отделе стораджей все еще явно дает о себе знать. Для меня очень показательным стал разбор приведенного ниже документа, как на ладони демонстрирующего текущие проблемы HP StorageWorks как отдела компании: устарелость использованных при подготовке инженеров материалов, крайняя узость эрудиции в области современных технологий, а как результат – низкая компетенция, по крайней мере в анализе продуктов конкурентов (я хочу думать о людях лучше, и верю, что в своих новых системах инженеры HP разбираются куда лучше, чем демонстрируют на системах конкурентов).

Документ сравнительно свежий, написан 11.09.2012 года в программе, зарегистрированной на имя Владимир Коробейников, это человек, работающий на позиции storage presale в HP с 2006 года (эту информацию можно почерпнуть в свойствах файла), я не утверждаю, что текст писал именно он, но эти данные в файле имеются.

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

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

Continue reading ‘Что HP думает о NetApp, и как все обстоит на самом деле. Часть 1’ »

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

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

Бенчмарк SPC-1 это очень сложный тест. Это не fancy-приложение, которое запускается, что-то делает 10 минут, рисуя переливающиеся графики, а потом пишет: “О-о! Круто! 100500 супермарков!”, или, наоборот, “Фу-у! Отстооой! Всего 150 попугаев!”. Строго говоря, даже приводимые данные по достигнутым IOPS значат не слишком много сами по себе. Проведенные тесты по SPC-1 требуют внимательного чтения всего отчета. Хотя бы сокращенного Executive Report, но настоящие инженеры просто обязаны прочесть еще более интересный Full Disclosure, с полным описанием проведенного тестирования. ?? уж абсолютно точно совершенно недостаточно извлечь из всего отчета одну строчку с циферками IOPS (или $/IOPS), и ей оперировать где-либо, в отрыве от того, как она получена. Строго говоря, в таком сложном бенчмарке, как SPC-1 интересен даже не столько результат как таковой, сколько процесс его достижения, описанный как раз в Full Disclosure, и многочисленные сопутствующие результаты, latency, например, как самый очевидный. Но это совсем не одна строчка 3DMark, исходя из которой можно сделать вывод “фу-у, отстоой!”, или “вау, круто!”.

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

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

Бенчмарки, особенно такие “крутые”, как SPC-1, это гонки Формулы-1. Это красиво, зрелищно, захватывающе, но разумные люди понимают, что “Формула” – отдельно, а повседневная жизнь автовладельца и автомобилиста – отдельно. ??з того факта, что в очередной гонке болид Renault обошел болид Ferrari совершенно не следует, что в реальной жизни ваш Renault обгонит соседский Ferrari. :) Но почему-то в случае бенчмарков систем хранения это сплошь и рядом считается не так, и результаты восьмиконтроллерного кластера с 1920 дисками за 6 миллионов долларов, или Full Flash системы с тремястами SSD, в восприятии читателя (не без “дружеской” помощи вендора) проецируются на его, добрый милый сторадж entry-level с двумя полками по 15 дисков.

Да, безусловно, наличие результатов и участие в программе тестирования Storage Performance Counsil (SPC) это – хорошо. Это означает, что вендор готов “показывать свой товар лицом”, готов отвечать на “вопросы”, ему не стыдно за то, что он разработал и продает. За это не стыдно не всем, но очень многим, начиная от NetApp, HP, IBM, кончая даже Oracle и Huawei. Даже если результаты будут неидеальными и нерекордными в абсолютном исчислении, это уже само по себе подтверждает открытость вендора и отсутствие “засад” в его решениях. В тестах, куда как более, чем в Олимпиаде “важна не победа, а участие”. Однако неправильно будет пытаться любой ценой установить рекорд. ?? еще неправильнее будет строить рекламу “купите наш Рено Логан, наш автомобиль обогнал вчера Ferrari на GP!” в особенности понимая, где здесь манипуляция (а технари такого уровня, участвующие в написании подобных текстов не могут не видеть, где тут манипуляция).

Ну а теперь, позвольте перейти к FUD-у. На следующей неделе я опубликую подробный откомментированный разбор очередного текста “чем плох 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 нынче у наших конкурентов актуальны. Может быть я и правда не на все темы написал?

Вокруг ситуации с usable capacity на NetApp накручено очень много довольно низкопробного манипулирования и FUD-а, см. например мою же статью в блоге, посвященную разоблачению одного из таких текстов.

Как вы знаете, системы на поддержке отсылают в Support Center в NetApp данные о своем состоянии, в том числе и о конфигурации. ??нтересный график был обнаружен в одной из технических презентаций NetApp. Это анализ соотношения между raw и usable capacity для реальных, рабочих систем NetApp, установленных у клиентов компании, эксплуатирующихся в настоящее время и отсылающих сообщения autosupport. В среднем, для 7597 рассмотренных систем, их usable capacity, то есть доступная для использования емкость хранения, емкость дисков за вычетом RAID-penalty (parity drives), spares, WAFL-metadata, reservations и прочего, составила 66,27% от их raw.

Такие дела. Как видите, в реальной жизни достигнутая на системах NetApp средняя величина usable всего на 3% хуже теоретически рассчитанной мной в посте с разоблачением FUD-а.

Так что же там на самом деле происходит с фрагментацией на NetApp?

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

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

Поэтому официальная позиция состоит в рекомендации, в случае, если влияние фрагментации в вашем конкретном случае, проявляется негативно (она, кстати, может и не проявляться), то включать wafl reallocate ( reallocate on / reallocate start [/vol/volname]) и спать счастливо.

Вообще же FUD вокруг non-contiguous wafl blocks allocation построен (впрочем, как и почти любой FUD) вокруг плохого представления технических деталей процесса и иногда чистосердечного, а чаще злонамеренного “непонимания” этих деталей. Давайте, для начала, разберем как же записываются данные в WAFL, по крайней мере на том уровне, на котором нам этот процесс показывает NetApp.

Но начать придется издалека.

Continue reading ‘Откуда вообще берется фрагментация?’ »

В сегодняшнем переводе у нас будет еще один активный блоггер NetApp, Larry Freeman, пишущий с ником Dr.Dedupe. Его основная тема в блоге – технология дедупликации в системах хранения NetApp, а поводом для переведенного поста – “Неспровоцированная агрессия” в отношении NetApp со стороны HP, которая выпустила в свет документ, под названием “Understanding the Challenges Associated with NetApp’s Deduplication” – “Разбор проблем, связанных с технологией дедупликацией NetApp”.

Ну что-ж, ответом на неспровоцированную агрессию будет наше принуждение к миру. ;)

HP Launches an Unprovoked Attack on NetApp Deduplication

By Larry Freeman AKA Dr.Dedupe

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

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

Утверждение HP:

“Первичные данные (здесь и далее я буду переводить слово primary как “первичные”, этим словом принято называть основные, активные, “боевые” данные приложений, в противоположность данным резервных копий и архивов, например. Прим. romx) имеют случайный характер  доступа по своей природе. Дедупликация приводит к тому, что различные блоки данных записываются в различные места диска. NetApp WAFL усугубляет проблему, записывая данные в свободные места, ближайшие к головке записи дисков. Чтение данных вызывает пересборку этих блоков, в формат пригодный для чтения приложением. Оверхед, вызываемый этой пересборкой данных, оказывает влияние на производительность, обычно на 20-50%”

Ответ Dr.Dedupe:

NetApp WAFL (Write Anywhere File Layout) – это структура размещения произвольно расположенных данных на диске, оптимизированная на производительность доступа к ним. Дедупликация еще более “рандомизирует” эту структуру, переназначая указатели на блоки данных и удаляя дубликаты. После дедупликации производительность на чтении иногда слегка возрастает, иногда слегка падает, однако подавляющее большинство пользователей говорят, что не заметили никакой разницы вообще. Важным моментом является то, что мы не перемещаем данные как таковые, просто переставляем на их блоки указатели. Если вы хотите получше разобраться в том, как работает наша технология, то я рекомендую посмотреть пример работы дедупликации.

Утверждение HP:

“Когда клиенты NetApp испытывают проблемы с производительностью, первая рекомендация NetApp это не использовать дедупликацию”

Ответ Dr.Dedupe:

На самом деле, когда наши клиенты испытывают проблемы с производительностью, первая рекомендация это обнаружить причину, вызвавшую проблемы с производительностью. Зачем выключать дедупликацию, если не она вызвала проблему? Полагаю, что HP поступает точно также, сперва надо найти причину, прежде чем советовать какие-то действия по исправлению ситуации. ??ли тут HP случайно выстрелила сама в себя? Эй, HP, давайте вы не будете строить предположений, что мы советуем нашим клиентам, пока на самом деле не позвоните в нашу поддержку?

Утверждение HP:

“Снижение темпов роста емкостей хранения имеет большое значение, и экономит затраты пользователя. Однако для первичных данных другие технологии, например Thin Provisioning обеспечивают сходные результаты уменьшения объемов, но без сопутствующего снижения производительности; эти возможности имеются у HP P4000 и HP InServ.”

Ответ Dr.Dedupe:

Заметьте, HP не сказала “эти возможности имеются только у HP P4000 и HP InServ.” Потому что у систем NetApp тоже есть Thin Provisioning, а также много других технологий уменьшения занимаемых объемов хранения и повышения их эффективности, которые могут использоваться как по по отдельности, так и друг с другом, одновременно:

• Дедупликация
• Thin Provisioning
• Эффективно расходующие место снэпшоты
• Виртуальные клоны данных
• Thin-репликация
• RAID-DP
• Онлайн-компрессия данных
• Автоматический виртуальный tiering c дисками SATA

Я знаю, это кажется очевидным, но напрашивается тема для статьи “Проблемы, связанные с технологиями экономии пространства хранения у HP”.

Утверждение HP:

“Метод с фиксированными участками [используемый NetApp] означает, что изменения в данных могут привести к очень плохому результату дедупликации… ??спользование метода с переменной длиной участка позволяет HP StorOnce D2D обеспечить более интеллектуальный и эффективный подход к дедупликации.”

Ответ Dr.Dedupe:

Ох, черт. Неужели мне так и придется писать это, снова и снова? NetApp записывает все данные в блоки (ну, то есть “участки”), размером 4KB. За прошедшие 20 лет мы сделали довольно неплохую работу по оптимизации того, насколько быстро мы можем писать и читать эти “участки”. Наиболее простой и быстрый способ дедупликации в нашем случае, это получать “цифровой отпечаток пальца” каждого такого участка, и сканировать базу этих “отпечатков” на дубликаты. Это лучший вариант для одновременного использования дедупликации в обоих сферах применения, как для первичных данных, так и для резервных копий. Достаточная экономия пространства хранения и минимальное влияние на производительность. В HP читают хоть что-нибудь в моем блоге? Переменные участки это хорошо для экономии места, но совсем не так здорово для производительности. Кто более интеллектуален и эффективен? Судите сами.

Утверждение HP:

“NetApp так обеспокоен производительностью своей технологии дедупликации, что Крис Каммингс, старший директор решений защиты данных в NetApp, сказал в интервью CRN, что пользователи должны понимать “возможности падения производительности при использовании этой технологии”, когда они решат ее использовать.
HP обычно находит 95% дублирующихся данных в резервных копиях и дедуплицирует их без воздействия на производительность первичного хранилища”

Ответ Dr.Dedupe:

Ну, HP, вот тут вы меня по настоящему разозлили. Прежде всего вы привели цитату из слов Криса Каммингса, сказанную еще в августе 2008 года, я уверен, что если бы вы могли вернуться назад во времени, вы бы могли найти консервативный комментарий о любой новой технологии от того, кто заботится о клиенте. Но фактом является то, что сегодня для нас это уже не новая технология, и мы рекомендуем ее использование нашим клиентам без каких-либо опасений.
Насчет того, что дедупликация на устройстве хранения резервных копий не влияет на производительность первичного хранилища – дык! :)

Утверждение HP:

“Когда вы покупаете решение HP – это как симфонический оркестр; каждая часть специализирована, но стандартизована по компонентам, оптимизирована, но идет в ногу со всей остальной системой. Это не коробка, подходящая для всего, это Конвергентная ??нфраструктура HP.”

Ответ Dr.Dedupe:

Вместо того, чтобы писать труд о проблемах технологии другого производителя, лучше бы HP исследовала проблемы, с которыми сталкиваются пользователи сегодня – а именно о том, что они борются с постоянным ростом объемов данных в условиях сокращающегося IT-бюджета. Может тогда бы стало понятно лицемерие сравнения с оркестром. Когда HP хочет продать пользователям оркестр в 120 человек, NetApp продает компактный, но эффективный джаз-бенд.

Утверждение HP:

“NetApp не обеспечивает достаточной гибкости для сложных сред резервного копирования сегодняшнего дня”

Ответ Dr.Dedupe:

Погодите минутку, что произошло? Кажется я что-то пропустил? Я думал, что мы говорим о проблемах дедупликации у NetApp, как это мы вдруг перескочили на гибкость резервного копирования? Это что, такой способ сбить читателя перепрыгивая с темы на тему?

Утверждение HP:

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

Ответ Dr.Dedupe:

Снэпшоты? А теперь мы говорим про снэпшоты? ??звините меня, HP, не могли бы вы все же не скакать с темы на тему? “Разбор проблем, связанных с технологией дедупликацией NetApp”, вы помните? Ну, с другой стороны, я так понял, что просто “проблемы” у нас закончились…

Dr.Dedupe (http://blogs.netapp.com/drdedupe)

Несколько слов по поводу того, что пост этот случайно появился в понедельник, а затем исчез из блога. Как вы догадываетесь, я не в 8 утра в понедельник пишу посты, они у меня обычно написаны в некотором количестве впрок, обычно на месяц вперед, с “автопостилкой”, которая их “раскрывает” по мере наступления соответствующего дня и времени. Случайно оно взглючило и расскринился пост за четверг. Так что не надо conspiracy theory привлекать, это просто глюки базы блога. Вот вам этот текст, раз уж он все равно в rss-ленту для многих утек.

Любопытный эксперимент провел John Fullbright отвечая на вопрос, являющийся, пожалуй, второй по популярности темой FUD наших конкурентов: “Производительность NetApp (якобы) падает с течением времени, из-за увеличения фрагментации WAFL на дисках, при постоянной случайной записи”.

У него дома стоит сравнительно небольшая система “позапрошлого” поколения – FAS3050, с двумя полками дисков SATA 320GB 5400RPM, которую он использует под домашнюю лабораторию для хранения виртуальных машин MS Hyper-V.

Система эта, к слову, имеет свой собственный твиттер, и пишет туда, с помощью скрипта на Powershell, новости своей жизни :)

Вот каковы были исходные данные:

The Test Platform:

• FAS3050
• ONTAP 7.3.4
• (2) DS14MK2-AT drive shelves – dual looped
• (28) 320GB Maxtor MaxLine II 5400RPM SATA drives
  • Storage for Checksums ~8%
  • Right-sized (for hot-swap) = ~2% across the industry
  • WAFL Formatted = 26.8 GB per drive (reserved for storage virtualization)
  • 11ms average seek time
  • 2MB buffer
  • Internal data rate 44MBps
  • Drive transfer rate of 133 MBps
• Storage Efficiency/Virtualization Technologies Employed:
  • Volume-level Deduplication
  • Thin Provisioning
  • RAID-DP
• RAID-DP RG size = 24
• Tuning options:
• optimize_write_once = off
• read_reallocate = on

??з 28 имеющихся дисков, на 3 расположен root volume, 1 диск hot spare, остальные 24 целиком собраны в одну группу RAID-DP, на которой расположен один aggregate.

Общая usable space системы равна 5,18TB (5.18 TB = 5304 GB = 22 drives * 241.2 GB). Кроме тестовых данных на системе расположены 26 виртуальных машин Hyper-V (показатели дедупликации для данного тома – 78%), а также шара CIFS с образами ISO.

Для теста на пространстве хранения было создано 3 LUN по 1,5TB размером каждый, которые по iSCSI были подключены к трем виртуальным машинам, с запущеным на них IOmeter Dynamo.
Таким образом, пространство хранения системы было заполнено тестировочными LUN-ами примерно на 88%.

В IOmeter был конфигурирован тестовый паттерн с 100% random write блоками по 4KB (также было выставлено выравнивание по границе 4KB, о нужности и смысле чего я писал ранее).
Для тестирования были сконфигурированы три workers, каждый на своей виртуальной машине.

Каждый worker создал на своем LUN тестовый файл на всю его длину.
Тестирование продолжалось 240 часов (10 суток) для того, чтобы гарантировать полную многократную перезапись содержимого тестового файла.

Спустя 15 часов после начала теста IOmeter демонстрировал следующие результаты:

Вы видите показатель производительности, равный 11248 IOPS при 4,2ms latency.
Довольно неплохо для 24 дисков SATA.

Спустя 60 часов:

Результат вырос до 12063 IOPS, а latency незначительно снизилась до 3,97ms.

На протяжении 10 дней тестирования на 4,5TB суммарного объема трех LUN было записано примерно 36TB тестового потока данных. В ходе тестирования был зарегистрирован рост показателя IOPS на 18% при незначительных изменениях latency в районе 4ms.

Общая картина изменений IOPS в ходе тестирования:

По вертикали – IOPS, по горизонтали – часы. В дальнейшем, до конца тестирования, показатели не менялись.

UPD: Также упомяну, что еще в 2008-м году NetApp публиковала в SPC-1 результат 48-hours Sustainability Test системы FAS3040. Результаты и описание можно посмотреть на сайте SPC и по приведенной ссылке на PDF.

Тема якобы катастрофического уменьшения usable space по сравнению с raw space на системах хранения NetApp занимает, по популярности, у наших конкурентов, пожалуй, третье место, сразу за страшилкой про "ужасную фрагментацию", и пугалкой про "эмуляцию LUN-ов поверх файлов на файловой системе". Про первых две я уже писал, и не по разу, пришла пора разобраться и с этой.
Основой для поста послужил перевод статьи в блоге Recoverymonkey.

Ранее я уже рассматривал "первую часть" ситуации, то, как образуется usable disk space, то есть та емкость, которая остается для использования на дисках, после того, как мы вычтем из них parity, hot spare и ряд прочих "накладных расходов". Однако это еще не все, определенный объем на дисках также занимают различные структуры данных. Я называю получившееся пространство, после того, как из usable disk space вычтутся прочие накладные расходы - usable system space.

Во многих виденных мной у конкурентов "документах" такого рода постоянно рассказывается о том, что, якобы, usable system space на системах хранения NetApp составляет менее 50% от купленного raw, а у одного "последовательного борца" с NetApp даже доходила до анекдотичных 34%.
Это смешно для тех, кто знает, как оно обстоит на практике, но все еще производит впечатление на новичков, тех, кто еще не разобрался с тем, как дела обстоят на самом деле.
Ну хорошо, где же истина, которая, как всегда "где-то рядом"?

Цель данного поста - рассмотреть ситуацию с тем, как и из чего образуется usable space на системах NetApp по состоянию дел и технологий на весну 2010 года.
Так как системы NetApp используют свободное пространство на дисках разными способами, а не просто для "хранения LUN-ов" , это постоянно порождает множество непониманий в том, что означают те или иные понятия и параметры, относящиеся к распределению свободного пространства на дисках системы хранения. При этом ряд рекомендаций NetApp изменялись с течением времени, по мере выхода новых версий их OS и взросления используемых технологий. Наша цель - рассмотреть текущее положение дел и обновить понимание вопроса у тех, кто по тем или иным причинам "отстал".

Коротко, "для тех, кому лень читать все"
(то, что называется "Executive summary" ;)

В зависимости от количества и типа дисков и общего дизайна хранилища, исключая самые маленькие системы с очень небольшим количеством дисков, реальная величина usable space целиком системы NetApp может легко превышать 75% от usable space самих дисков. Я видел, например, величину в 78%. Такое значение, конечно же, обеспечивалось при использовании защиты от двойного сбой (RAID-6/DP) и включала spares. Эта величина показывает "честный" объем хранимых данных для NAS или SAN и не включает в себя дедупликацию, компрессию или клоны типа FlexClone; вместе со всеми перечисленными технологиями, эффективность может легко превысить и 1000%. Во многих случаях клиенты NetApp выбирают их системы хранения как раз именно потому, что системы NetApp настолько эффективны с точки зрения usable space. А теперь перейдем к подробностям…

Continue reading ‘Usable Space у NetApp – что стоит за FUD? (часть 2)’ »

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

Одной из самых популярных “страшилок-говнилок” в отношении NetApp является пугалка о том, как неэффективно расходуется пространство на системах хранения NetApp, как мало получается usable space из данного объема raw. Пожалуй, по популярности эта “говнилка” у наших конкуретнов идет сразу за страшилкой о фрагментации (и ее мифическим “катастрофическим влиянием на производительность”), и за пугалкой про “эмуляцию LUN поверх файловой системы”. Я уже писал ранее про то, как обстоит дело с первой, и рассказывал как устроена организация данных на “низком уровне” в WAFL, объясняющая ситуацию со со второй.

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

Давайте разберем пример, хоть и не исчерпывающий, но довольно зрелищный.

Continue reading ‘О расчете дискового пространства: NetApp FAS и EMC NS – что стоит за FUD (часть 1)’ »