about NetApp

??нтересный пример использования решений BigData внутри компании NetApp приводится в одном из ее корпоративных блогов. В 2011 году для поддержки решений AutoSupport, службы NetApp по сбору статистики, ее анализу и проактивному реагированию, было развернута система хранения и обработки с использованием ПО Apache Hadoop, одного из наиболее известных открытых решений для BigData. Вы должны помнить, что несколько лет назад NetApp приобрел и развивает продуктовую линейку LSI/Engenio, ныне выпускающуюся под маркой NetApp E-series, а также поставляемую нескольким традиционным OEM-партнерам, например IBM (DS-series systems) и Dell (MDS). ??мея возможность непосредственного (а не через SAN) подключения дисков массива (по протоколу SAS) к серверам-узлам Hadoop, стораджи E-series оптимально подходят для построения BigData-решений, так, например, NetApp совместно разрабатывает подобные продукты совместно с HortonWorks, одним из разработчиков “коммерческого дистрибутива” на базе открытого Hadoop.

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

Чтобы была яснее проблема, просто приведу примеры, что на момент начала разработки BigData решения, база ASUP собирала около 1,1 миллиона присылаемых ей от систем хранения записей данных, каждая размером около 3-5 мегабайт, причем 40% этих 1,1 миллиона присылается в выходные, во время традиционного “weekend call home” систем NetApp, с отчетом за неделю.
Некоторые запросы к этим данным могли выполняться недели (!).

Проблема усугублялась тем, что 90% получаемых данных можно назвать unstructured, что крайне усложняет их обработку, например затрудняя размещение их в “классических” реляционных базах данных. Объемы хранения в ASUP удваиваются каждые 18 месяцев, и на момент написания заметки они составляли около 200 миллиардов записей.
Хранить все эти данные необходимо, так как большой объем позволяет точнее выявлять тренды и анализировать возможные проблемы.

Как вы видите, NetApp столкнулся с классическим случаем работы с BigData - огромным объемом постоянно пополняемых данных, имеющих неструктурированную природу. Попытка решить ее “традиционным”, не-big data, путем была сочтена слишком дорогостоящей, поэтому, когда возникла идея построить BigData решение, это сразу было реализовано.
В результате удалось реализовать SLA для ETL-процедур (extract, transform, load) с очень жесткими рамками: 15 минут для обычных данных, и 2 минуты для высокоприоритетных. Сокращение затрат времени на построение подобной системы по сравнению с ранее рассматривавшейся “классической” составило 47-60%.

Небольшая аналитическая компания Demartek Lab провела недавно оценочное тестирование ряда технологий и продуктов NetApp, использующих Flash memory, в частности были протестированы и оценены all-flash storage EF540 и система хранения NetApp E5460 с дисками NL-SAS (SATA), дополненных SSD-кэшем (обратите внимание, кстати, что это результат для “предыдущего” поколения, а не для текущего, EF550 и E5500). В другом тесте был померян сравнительный результат Flash Accel и Flash Cache.

Так, например, было установлено, что на 100% random read EF540 с 24 дисками SSD на 800GB достиг результата в 330 000 IOPS при менее 1ms latency.

Не стоит сразу и безоговорочно верить любому такому тесту, но как источник данных “на подумать” - очень интересно.

Недавно в одном блоге(внезапно блог этот умер буквально на неделе, поэтому мне пришлось сохраненный текст того поста перенести в документ Google Docs, смотрите содержимое цитируемого поста там) увидел результаты эксперимента, в котором пользователь тестировал FAS3210 на эффект от включенной и выключенной поддержки VAAI, на таких операциях, как создание нового thick eager zeroed диска, клонирование VM, и Storage VMotion.
Я часто встречал какие-то завышенные ожидания от использования VAAI. ?? очень часто люди, не получая ожидаемого ими сногсшибательного результата, начинают думать, что делают что-то не так. А на самом деле этот эффект и правда, по видимому, не слишком велик (по крайней мере не так велик, как о нем думают, и чего ожидают, начитавшись маркетинговых материалов VMware).
Так, например, в рассматриваемом эксперименте, максимальный эффект от поддержки VAAI был на операции Storage VMotion, и представлял собой всего лишь тридцатипроцентное улучшение по времени операции, при пропорциональном увеличении загрузки CPU контроллера.
Сравнивая со сделанными ранее тестами FAS2040, автор вполне резонно делает вывод, что эффект от VAAI, по видимому, тем больше, чем мощнее контроллер, и упирается в контроллер и его процессор. Отсюда вывод, что на entry-level стораджах (любого производителя), эффект от поддержки VAAI в его контроллере, скорее всего незначителен, и нет особого смысла бороться за него, или надеяться на его чудодейственность.

Что-то мы с вами все про технику и про технику. Отвлечемся на сегодня. Несколько лет назад, еще в 2009 году, один из сооснователей компании NetApp – Дейв Хитц, о котором я тут несколько раз уже упоминал, написал книгу под несколько шокирующим названием “HOW TO CASTRATE A BULL: Unexpected Lessons on Risk, Growth, and Success in Business” – “Как кастрировать быка: Неожиданные уроки риска, роста и успеха в бизнесе”. Книга, как вы понимаете, рассказывает историю основания и развития компании NetApp, ну и на примере разнообразных набитых в процессе шишек рассматриваются какие-то “уроки жизни” в этом бизнесе. Название взялось вот откуда: Хитц после колледжа подрабатывал на ранчо с ковбоями (в Америке они существуют и по сей день), и вспоминает, что многие из простых жизненных уроков и историй оттуда хорошо подошли и к миру IT-бизнеса.

Эта книжка (на английском) у меня есть целиком, но я бы не хотел заниматься откровенным пиратством, поэтому не буду выкладывать ее в открытый доступ (и вас бы просил этого не делать), но если кто хочет почитать – пришлите мне весточку в комменты или на romx@mail.ru, я пришлю вам текст. Книжка на английском, но, в принципе, читается неплохо.

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

Вот эту главу для вас на днях я и решил перевести.

Continue reading ‘Оффтопик: Глава из How to Castrate a Bull’ »

??ногда роясь в старых постах коллег по блоггингу удается находить что-нибудь интересное. Я помнил тот занимательный факт, что системы NetApp MetroCluster вот уже много лет очень хорошо продаются в Германии. Вот уж не знаю почему так, видимо продавцы хорошие, знают подход, но вот прямо очень хорошо. Но никогда не видел фактических цифр. А вот недавно, просматривая снимки сессий прошлогоднего VMworld 2012, нашел вот такой кадр:

Более 6000 систем MetroCluster проданы в одной только Германии, из около 11 тысяч по всему миру!

??нтересные тут картинки почта в клювике принесла. Как вы знаете, компания IDC делает регулярные обзоры рынка, оценивая рыночные доли разных брендов. Сам эти отчеты платные и дорогие, поэтому приходится перебиваться тем, что кто-то выложит в паблик. Обычно это делает та компания, которой хочется похвастаться :)

Частенько есть чем у нас похвастаться и NetApp. Поэтому сегодня извлеченные из отчета IDC рыночные доли по суммарному рынку NAS и SAN.

Вот как выглядит обычно широко публикуемый отчет по выручке:

А вот так куда менее публикуемый отчет по доле от поставленной емкости хранения.

Сопоставив их можно попытаться сделать некоторые любопытные выводы. Например они очень хорошо показывают мифичнность утверждения про “дорогие диски у NetApp”, так, видно, что терабайт на NetApp продается, и, следовательно, обходится покупателю, существенно ниже рынка в среднем (причем у IDC суммируется тупой raw capacity проданных дисков, так что с учетом использования RAID-DP выигрыш будет и еще выше).

Видно, как EMC, с выходом VNX, переломила негативную тенденцию падения поставляемых объемов (читай – числа поставляемых стораджей, по видимому), существенная же разница в долях “в терабайтах” и “в миллионах долларов” скорее всего объясняется дорогими hi-end массивами, крайне дорого обходящихся покуателям из расчета “за терабайт”. Видно также, что по росту объемов поставляемых терабайт сегодня NetApp вот уже третий год не имеет равных среди всей шестерки.

Ну и, чтобы два раза не вставать, доли на рынке средств репликации данных в системах хранения. Немножко растет IBM, видимо за счет Storwise.

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

Тем не менее вот такие у нас есть упрямые штуки, вне зависимости от того, как вы относитесь к IDC.

Совсем немного времени остается до того момента, когда, по регулярно знакомой владельцам техники Apple схеме, гордые владельцы передовых систем хранения от лидера рынка увидят, как их недавнее приобретение превращается в тыкву становится вчерашним днем.
Ведь в VNX2, новом поколении midrange-систем EMC, и “в 4 раза выше производительность” (с) EMC), и новое кэширование во flash, и обновленный софт управления, и даже долгожданная блочная дедупликация.
Вот только все это - для новых систем, которые придется заново купить. А старые… Старые уже будут не столь передовыми и не столь ведущими, на фоне новых. Они останутся теми, прежними, да, но вряд ли это обрадует клиентов EMC, наконец-то получивших свой долгожданный VNX полгода назад.

http://searchstorage.techtarget.com/news/2240203615/Photobucket-expands-environment-with-NetApps-clustered-Data-Ontap

Расположенная в Денвере веб-компания Photobucket , занимающаяся хранением пользовательских фото и видео, накопила с 2003 года около 17 петабайт данных. Это потребовало от нее, ранее в этом году, запустить новый, уже второй датацентр, который позволит увеличить объемы хранения и обеспечить высокий уровень аптайма для их 100 миллионов зарегистрированных пользователей.

Компания хранит более 13 миллиардов изображений и видеороликов, а еждневно на системы хранения компании загружается еще около 5 миллионов. Компания входит в список 200 крупнейших вебсайтов ??нтернета (по подсчетам Alexa), и является хранилищем по умолчанию для изображений для пользователей сервиса Twitter (tinypic.com - это сервис компании Photobucket) “Одной из серьезнейших проблем, с которой нам пришлось столкнуться при создании системы - это огромное количество файлов, потому что мы, кроме всего, храним по нескольку копий каждого пользовательского изображения: оригинал, копию пониженного разрешения для web, и эскиз-thumbnail” - говорит Майкл Кларк, CTO компании.

Photobucket использует системы хранения NetApp с самых ранних лет работы компании, поясняет Кларк, но решил, что переезд в новый датацентр в Финиксе будет хорошим поводом сделать переоценку решений и поискать альтернативные варианты: “Мы решили, что это время для того, чтобы заново оценить предложения рынка”, - объясняет он. “Мы просто захотели посмотреть, кто сегодня работает с NFS лучше, чем это есть у нас, а также кто позволит нам выполнять репликацию данных лучше и эффективнее с точки зрения затрат”

Датацентры в Денвере и Финиксе практически идентичны, на обоих работают системы хранения NetApp в конфигурации Clustered Data ONTAP и Data ONTAP 8, используются контроллеры NetApp FAS3210, 3240, 6040 и 6240. Системы хранения обеспечивают данными 1100 физических и 500 виртуальных серверов, организованных в соответствии с архитектурой FlexPod, и использующих гипервизор KVM.

Компания использует самописанную объектную файловую систему хранения для сервиса TinyPic.com, в которой хранится сегодня около 2 миллиардов медиа-объектов.

До покупки NetApp Clustered Data ONTAP, Photobucket тестировал системы хранения от Hitachi Data Systems и несколько коммерческих платформ объектного хранения. Но после того, как IT-отдел компании столкнулся с проблемами производительности у объектного хранилища и сравнении общих затрат на датацентр, Photobucket остановился на NetApp.

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

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

Майкл Кларк, CTO компании, также упомянул, что инструмент репликации данных SnapMirror оказался для них очень востребованным и полезным, когда им пришлось делать резервную копию больших объемов данных. “Когда мы пробовали работу других систем хранения в ходе их тестирования, одной из проблем, с которыми мы тогда на них столкнулись было то, что ни одна из имеющихся систем репликации не работала нормально с таким гигантским числом файлов”, рассказал он.

С использованием SnapMirror, Photobucket может реплицировать свои данные как снэпшоты на несколько массивов FAS2240 и FAS3210 каждые 30 минут, и хранить их там все в течение месяца.

В дополнение к продолжающейся миграции данных на Clustered ONTAP, Photobucket также запускает в работу и свою новую инфраструктуру объектного хранилища.

Раз уж тут мы много поговорили про бенчмарк SPC-1, хотелось бы добавить, в завершение темы, еще несколько слов.

В этом бенчмарке, кроме, так сказать, самого результата в достигнутых IOPS, а также сопутствующих ему параметров, таких как latency, есть в принципе очень полезная метрика – результат “цены за IOPS”, или $/IOPS. Этот параметр позволяет оценить, во сколько обошелся результат в денежном выражении. Методика SPC-1 требует раскрывать стоимость протестированой конфигурации. К сожалению, что считать “стоимостью” системы определено недостаточно четко, что тут же стало предметом, если не открытого мошенничества, то достаточно жульнических махинаций многих вендоров. Дело в том, представляя результаты своих систем на тест, они искусственно занижают ее цену, указывая эту цену с произвольной скидкой с “цены листа” (listprice), и, тем самым, уменьшая значение “в числителе”, улучшают результаты $/IOPS совершенно искусственным образом.

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

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

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

Я уже как-то, было дело, писал текст, несколько лет бывший очень популярным на этом блоге – “Как просить и получать скидки”. Рекомендую, в особенности, если вы только недавно на наш базар пришли. :)

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

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

Ситуация, в которой Вендор А показывает на тесте в спецификации цену листпрайса, а Вендор B – цену листпрайса с дисконтом 45%, и считает от нее результат $/IOPS, напоминает мне соревнования по бегу, в которой один спортсмен пробегает сотню за 10 секунд, а другой – за 4, но если у первого под “сотней” – понимается сотня метров, то у второго – сотня футов (ну или сто метров с дисконтом 70% от листа ;). Можно ли считать второго – рекордсменом и победителем только на основании того, что у него результат его “забега” – меньше, чем у первого? По-моему ответ очевиден.

К сожалению, спецификация с ценами в бенчмарке SPC-1 находится в длинном и нудном Full Disclosure Report, а результат $/IOPS, из него получаемый – в самом начале Executive Report, в красивой цветной табличке, на которую все смотрят в первую очередь. Это, к сожалению, порождает повод для, ну, скажем так, не вполне честного поведения в “серой” зоне. Официальное описание бенчмарка не определяет то, какую цену вендор обнародует и берет при расчете, нужно только указать полную спецификацию, поэтому на совести вендора остается то, как именно он эту цену показывает. Не удивительно, что многие пользуются этой лазейкой, чтобы показать результат в $/IOPS лучше, чем у конкурента, особенно если конкурент, как честная маша, пишет в своем расчете единственную свою официальную (и самую высокую по факту) цену – листпрайс.

Поэтому, сравнивая системы по $/IOPS, всегда обращайте внимание на то, сколько метров было в стометровке, которую пробежал участник с таким выдающимся результатом. :)

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

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

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

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

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