about NetApp

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

Как я уже отмечал когда-то в одном из постов, настоящий сисадмин готов неделями спорить до хрипа, сравнивая абстрактные цифры бенчмарков, преимущества IBM p-series перед HP Superdome, Lamborgini перед Ferrari, и AK-74 перед M16A4 (обычно никогда не видев, не ездив и не держав в руках ни того, ни другого;)
Вот и в моем блоге посты “про бенчмарки” собирают всегда “цвет аудитории”, и внимание, которое, по моему убеждению, тема совсем не заслуживает. Я бы с куда большим удовольствием увидел бы активность читателей в какой-нибудь куда более важной и осмысленной теме. Но… Что имеем.

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

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

Бенчмарки дают нам повод для оценки, пищу для ума, но совсем не являются этой конечной оценкой.
Я уже приводил в качестве сравнения пример, со сравнением автомобилей по крайней цифре на спидометре (даже если эта цифра и реальна, все равно). Берем, сравниваем малолитражку, представительский класс, микроавтобус и грузовой автомобиль по максимальной скорости, или по соотношению “скорость/цена”, и выбираем лучший! :)
На деле, конечно же, микроавтобус, допустим, не хуже и не лучше грузовика или лимузина. Прсто они разные, и задачи у них разные. ?? там, где хорош один - может быть плох другой, и наоборот. На лимузине неудобно возить картошку, на микроавтобусе - покорять девчонок, на спорткаре - ездить за грибами.
Более того, даже в пределах одного класса покупатель не ориентируется только на максимальную скорость и мощность двигателя, просто потому, что в “быту” обычно важнее совсем другое. Объем багажника, удобная АКПП, климат-контроль в салоне, регулировка сидений, стоимость сервиса и потребление бензина, удобство установки детского сиденья, и так далее, такие параметры индивидуальны для каждого покупателя. ?? где-то там, глубоко среди них, есть, возможно, максимальная скорость. Для машины для города, в основном перемещаюшейся от пробки к пробке и от светофора до сфетофора, разница между 220 и 260 километрами в час максимальной скорости - штука почти умозрительная.

Ну вот, а теперь давайте вернемся к исходной теме.
Оригинальный коммент, вызвавший большую дискуссию в комментах предыдущего поста звучал так:

Борис Аклименко:
Если сравнивать FAS8040 с IBM DCS3700 по Executive Summary, то последний выглядит более привлекательно (Price Performance, Total Price, количество юнитов в стойке; при очень близких показателях SPC-1 IOPS и Ramp Phase Response Time). Хотелось бы услышать Ваши комментарии по этому сравнению.

Давайте начнем с того, что, как я уже говорил выше, бенчмарки, в данном случае, “инструмент познания результата, но не результат как таковой”. Как правило почти невозможно сравнивать его данные между разными стораджами, игнорируя все остальные показатели. По этой причине говорить о “привлекательности” странно, сторадж - не девушка, чтобы выбирать его по этой характеристике. Это инструмент решения задачи. Никто же не говорит, что молоток - более привлекателен, чем отвертка, если стоящая задача - завинтить винт (хотя молотком это сделать тоже можно, на АвтоВАЗе знают ;)

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

Параметр $/IOPS конечно интересен, но сам по себе не дает нам ничего, даже если мы учтем популярную фишечку вендоров - указывать цену для его расчета - искусственно заниженной за счет “скидки”.
Например одной из лучших систем на сегодня, как по абсолютной производительности (1.2M IOPS), так и по $/IOPS (0,8$/SPC-1 IOPS) является сегодня система Kaminario K2. Знаете такую? Я вот тоже не знаю. Это такой стартап в отрасли.
Другой, долгое время державшей “топ” системой был TMS RamSAN, с ценой IOPS в районе доллара. Ну и конечно, нельзя обойти циклопические результаты стораджей Huawei OceanStor. Последний, к слову, не all-flash, как перечисленные выше, а вполне “дисковый”.

?? что теперь, многие покупатели посмотрели на результаты, да ну этот EMC (вообще не публикующий никаких результатов бенчмарков), HP, IBM, Hitachi! Купим-ка мы лучше вот этот Каминарио! Смотри-ка, какой он крутой! ??ли вот еще лучше - Хуавей!

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

Теперь же, если мы вернемся к сравнению NetApp FAS8040 2-node cluster, и IBM DCS3700 (AKA тот же NetApp E5660, к слову), то, посмотрев с этой точки зрения, а не с точки зрения “максимальной цифры на спидометре”, мы увидим, что это разные системы, для разных задач.

?? точно также, как никто не ставит all-flash storage, при всех их великолепных результатах $/IOPS на, допустим, хранение почты в Exchange, как никто не покупает (личную) “Газель”, ездить на ней на работу, также и в этом случае. Задачи - разные. Системы - разные. Скорость - не единственный параметр для системы хранения, выполняющей свою задачу в IT-подразделении компании.

Борис Аклименко:
Выходит очень странно - систему рассчитанную на большие конфигурации показывают чуть ли не в самом минимальном варианте

Это так, потому что пользователям, как правило, в подавляющем случае, интересны не столько результаты “звездолетов” на 1960 дисков, или all-flash системы сверхвысокой производительности. Обычно такой бизнес и без бенчмарков хорошо знает, что покупать, так как такие потребности в производительности не возникают на пустом месте одномоментно. Также, как покупатели Феррари не тусуются перед покупкой на форумах auto.ru, расспрашивая тамошних завсегдатаев ;)
Поэтому чаще всего интересны и покупаемы совсем не “топовые” конфигурации систем, напротив, большинстов продаж делают low-enterprise и midrange, в совсем не заоблачных конфигурациях. Не весь бизнес в России еще Газпром. :) Да и не в России - тоже.

Борис Аклименко:
а толку от этого “добавить” - если вы показываете результаты для нетапповского HighEnd и предлагаете “экстраполировать” его на Mid-Range?

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

Борис Аклименко:
Мы писали вендору с предложением показать производительность всей системы, с условием того, что если заказчика это устроит - заказчик приобретет половину этой конфигурации и будет, не опасаясь “сюрпризов” расти до полной. NetApp этот запрос не заинтересовал, но заинтересовал HP и EMC. Как-то так.

Вообще-то ничего удивительного. NetApp вообще крайне неохотно участвует в “тараканьих бегах”. Причины этому я описал в первой половине поста сверху. На практике “соревнование в скорости” у кастомера дело азартное, но по результатам бессмысленное. Счас скажу секретную штуку. На самом деле NetApp продает не IOPS-ы. Не диски, и не перформанс. Он продает фичи. А уж потом, довеском к фичам, идет скорость, диски, перформансы и прочее. На практике оказывается, что когда вы купите фичи, нужные вам, перформанс и емкость вы при этом тоже получите :)
Отсюда понятно отсутствие интереса. Это не пренебрежение вами. Это просто лучшее понимание вопроса :)

Борис Аклименко:
Для NetApp информации по “живым” 200000 ящикам инфы не нашел даже для 6240, не то что для 32xx.

Я ж вроде это постил в PS в пред-предшествующем посте:
http://www.netapp.com/us/media/tr-4268.pdf
Technical Report
200,000 Exchange Server 2013 Mailboxes on NetApp FAS8060
An Overview of Performance and Scalability
Wei Liu, NetApp
February 2014 | TR-4268

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

Еще по теме:
Про “культ бенчмарков”
Почем обходится производительность?
Про тестирования и про производительности
О “цене за гигабайт” и о “цене за решение”
Правильная интерпретация $/IOPS и IOPS/RAID для результатов SPC-1
Несколько слов про параметр $/IOPS в SPC-1

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

Ну вот, и результаты SPC-1, то есть для “тяжелого” блочного доступа, подоспели.
Правда, пока не готов Full Disclosure Report, а есть только Executive Summary, в котором многие важные детали опускаются.
Но посмотреть все равно интересно. Ждем выкладки детального отчета. - Опубликован и Full Disclosure Report

Новые контроллеры появились не просто так, а сопровождены публикацией тестов и обновлением документации и best practices.
Так, например, в день анонса были опубликованы результаты стандартного бенчмарка “файловый сервер NFS” - SPEC sfs2008, популярного и одного из наиболее “заслуженных” и общепринятых бенчмарков в индустрии хранения.

Так, продемонстрировано примерно 10% преимущество для FAS8020 перед заменяемым им FAS3250, который был промерян в 2012 году, после его анонса.
На вдвое меньшем количестве дисков SAS, но с Flash Cache на 512Gb, показаны лучшие результаты на бенчмарке, с почти в полтора раза лучшим responce time.

Что-ж, хорошее начало, ждем результатов SPC-1.

Вчера NetApp объявил новую серию моделей NetApp FAS - FAS8000. Вопреки банальной логике, выработанной принятой схемой нумерации моделей и линеек, это НЕ суперпупер-системы, стоящие НАД FAS6200, что было бы логично исходя из номера линейки, напротив, это “сайд-линейка”, заменяющая ряд моделей в мидрендже и нижнем-среднем хайэнде:
FAS8020 планируется как перспективная замена FAS3220, FAS8040 - FAS3250, а FAS8060 - замена для FAS6220. Почему NetApp решил перепахать всю схему нумерации моделей, и чем их не устраивали цифры 4000 и 5000, расположенные как раз в нужном и привычном диапазоне - непонятно.
Но, закончим с бухтежом, посмотрим же, что нам подготовили с технической стороны.
Continue reading ‘Обновление линейки FAS - FAS8000’ »

??нтересный пример использования решений 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.

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