Posts tagged ‘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

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

FAS8040 2-node cluster: результаты SPC-1

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

Обновление линейки FAS - FAS8000

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

??спользование решений BigData в NetApp: ASUP

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

Оценочное тестирование EF540 и E5460 NL-SAS+SSD

Небольшая аналитическая компания 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.

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

Flash Accel v1.3.0

На днях вышла новая версия относительно нового продукта NetApp - системы flash-кэширования данных непосредственно на хост-сервере виртуальных машин - Flash Accel. Если вы следите за этим продуктом, то должны помнить, что это бесплатный для клиентов NetApp программный продукт (это НЕ код Data ONTAP, и он работает НЕ внутри стораджей NetApp, а устанавливается на хост-сервер VMware vSphere). Flash Accel постепенно обрастает функциональностью, и ему стоит поторопиться, так как на рынок локального SSD-кэщирования выходят разнообразные игроки, в том числе и сам VMware со своим vSAN vFlash.

В новой версии, доступной для бесплатного скачивания клиентам NetApp с обычного места получения нетапповского софта, появилось:

  • Поддерживается до 4TB SSD-кэша на сервер
  • Поддерживается sTEC SSD PCI-e
  • Наконец поддерживается Windows Server 2012 и 2012 R2, а также vSphere 5.5
  • Поддерживается Windows Server baremetal caching (2008 R2, 2012, 2012 R2) для FC и iSCSI.
  • Существенно уменьшился объем занимаемый FlashAccel в физической памяти хоста. Например для v1.2.0 он был равен 0,006GB физической памяти хоста на каждый его гигабайт памяти, плюс 0,006GB памяти VM на каждый гигабайт используемого SSD-кэша, то в этой версии эта величина снизилась почти вдвое, до 0,0035GB.
  • Увеличился также размер блока кэша по умолчанию, с 4 до 8 KB.

Как перенести данные с системы 7-mode на Cluster-mode?

В связи с тем, что, постепенно, Cluster-mode Data ONTAP, или как ее теперь правильно называть Clustered Data ONTAP, входит в жизнь, и все больше пользователей задумываются о ее использовании, возникает вопрос, как бы наиболее щадящим и простым способом перенести между двумя этими системами данные.
К сожалению, разница “в потрохах” между этими двумя OS, несмотря на схожесть названий, слишком велика, чтобы просто “запустить скрипт, и все сделается за час”. К сожалению пока нет реально работающего способа преобразовать уже имеющуюся 7-mode систему в C-mode. Поэтому, обычно, о Clustered ONTAP начинают думать в случае появления новой, “чистой” системы хранения, тем более, что сегодня есть возможность сделать Clustered Data ONTAP из всего пары контроллеров. Это интересно тем, что впоследствии вы уже сможете довольно свободно добавлять к этой паре контроллеров новые пары. Например старые (если они поддерживаются) контроллеры, работавшие в 7-mode, после завершения миграции данных с них, могут быть легко добавлены в такой кластер.

Довольно быстро в голову приходит идея использовать SnapMirror, штатную репликацию данных NetApp. Но поддерживает ли она репликацию между двумя “модами”? Да, поддерживает, хотя и с ограничениями. Наиболее существенным является невозможность перенести LUN-ы FCP или iSCSI. Увы, изменения в работе с метаданными LUN-ов в C-mode слишком значительны, чтобы это можно было просто реплицировать. В случае LUN-ов вы получите при попытке репликации сообщение в логах:

wafl.voltrans.lun.exists: Volume vmware_datastore1@vserver:a0cc5791-fd70-11e2-9f1f-123478563412 contains 7-Mode LUNs. It cannot be transitioned to Cluster-Mode.

В случае LUN-ов вам придется воспользоваться ручным переносом данных, либо через хост, либо через какой-то софт создания образа диска, хотя бы Norton Ghost или Acronis True Image.

Для разделов с файловыми данными, однако, можно все сделать собственными средствами SnapMirror.

Допустим, у нас есть две физических системы: 7-mode по имени NETAPP_7MODE (192.168.2.10) и Netapp Clustered ONTAP system по имени NETAPP_CMODE (192.168.1.10).

Создадим SnapMirror peer:
NETAPP_CMODE::> vserver peer transition create -local-vserver NETAPP_CMODE -src-filers-name NETAPP_7MODE

Transition peering created

Создадим том-получатель реплики данных:
NETAPP_CMODE::> volume create -volume vmware_datastore1 -aggregate aggr1 -size 100GB -type DP

[Job 16] Job succeeded: Successful

Создадим межкластерный интерфейс LIF:
NETAPP_CMODE::> network interface create -vserver NETAPP_CMODE -lif intcl_lif1 -role intercluster -home-node NETAPP_CMODE -home-port a0a-10 -address 192.168.1.10 -netmask 255.255.255.0

NETAPP_CMODE::> network routing-groups route create -vserver NETAPP_CMODE -routing-group i192.168.1.0/24 -destination 0.0.0.0/0 -gateway 192.168.1.1

Проверим, что связь есть:
NETAPP_CMODE::> network ping -lif intcl_lif1 -lif-owner NETAPP_CMODE -destination 192.168.2.10

192.168.2.10 is alive

Устанавливаем отношения репликации SnapMirror:
NETAPP_CMODE::> snapmirror create -source-path NETAPP_7MODE:vmware_datastore1 -destination-path NETAPP_CMODE:vmware_datastore1 -type TDP

Operation succeeded: snapmirror create the relationship with destination NETAPP_CMODE:vmware_datastore1

Проводим инициализацию репликации:
NETAPP_CMODE::> snapmirror initialize -destination-path NETAPP_CMODE:vmware_datastore1

Operation is queued: snapmirror initialize of destination NETAPP_CMODE:vmware_datastore1

Ждем завершения начальной полной передачи данных, проверяя статус:
NETAPP_CMODE::> snapmirror show

При необходимости обновляем данные на получателе, если они изменились на источнике:
NETAPP_CMODE::> snapmirror update -destination-path NETAPP_CMODE:vmware_datastore1

Отрезаем реплику от источника (quiesce):
NETAPP_CMODE::> snapmirror quiesce -destination-path NETAPP_CMODE:vmware_datastore1

При необходимость снова восстановить репликацию после отреза (quiesce):
NETAPP_CMODE::> snapmirror resume -destination-path NETAPP_CMODE:vmware_datastore1

Отрываем реплику (break):
NETAPP_CMODE::> snapmirror break -destination-path NETAPP_CMODE:vmware_datastore1

При необходимости повторять репликацию назначаем расписание:
NETAPP_CMODE::> job schedule cron create -name Every15mins -minute 15

NETAPP_CMODE::> snapmirror modify -destination-path NETAPP_CMODE:vmware_datastore1 -schedule Every15mins

После завершения репликации у вас на новой системе окажется копия данных системы с 7-mode, и их можно начинать использовать.

ВАЖНО: После репликации для тома-получателя будет автоматически выставлена опция fs_fixed_size, вы не сможете ее изменить командой vol options fs_fixed_size off, вместо этого воспользуйтесь командой: vol modify -vserver -volume -filesys-size-fixed false

Насколько выгоден Flash Pool для системы класса FAS2200?

Flash Pool - это способ использовать установленные в систему хранения SSD в качестве кэша для операций записи и чтения. При этом они составляют с обычными жесткими дисками так называемый hybrid aggregate, и активные операции, как записи, так и чтения, могут эффективно кэшироваться на пространстве этих SSD, позволяя использовать все преимущества flash на обычных дисковых системах хранения.
Об этой технологии я писал в блоге не раз, однако за эти несколько лет, что Flash Pool доступен к использованию на системах хранения NetApp, у некоторых потенциальных клиентов NetApp Flash Pool сложилось мнение, что для полноценного, эффективного использования возможностей Flash Pool нужно иметь достаточно мощный контроллер сам по себе, и что широко распространенные и очень популярные контроллеры класса FAS2200 не дают существенной выгоды от использования Flash Pool, просто потому что “силенок у них его раскачать не хватает”.
Для того, чтобы раз и навсегда ответить на этот вопрос, аналитическая компания ESG провела по просьбе NetApp сравнительное тестирование двух систем:

1. FAS2240-2, c 48 2.5″ 900GB 10Krpm дисками SAS, с общей емкостью 42TB raw
2. FAS2240-4, c 32 3.5″ 2TB 7.2Krpm дисками SATA, плюс 4 дисками SSD 200GB, и общей емкостью 64TB raw

В качестве нагрузки были протестированы типовые нагрузки, характерные для:

1. OLTP database (100% random, 66/33 read/write, мелкими блоками, чувствительный к responce time) MS SQL Server 2010.
2. Нагрузка, характерная для Exchange Server (2010).
3. Нагрузка файлового сервера (переменные размеры блоков, большой объем работы с метаданными)

Физический сервер, на котором под VMware vSphere 5.1 были развернуты две тестовые VM (Windows Server 2008R2), и которые были подключены одним каналом 10G Ethernet к системе хранения по протоколам iSCSI и NFS. Все три рабочих нагрузки генерировались с помощью IOmeter на тестовых VM вперемешку, одновременно.

Результат (слева - all-SAS FAS2240-2, справа - FAS2240-4 (SATA +4xSSD):

Резюмируя же “в цифрах”:

Система с Flash Pool вида SATA+SSD, показала существенно лучшую производительность, чем точно такой же контроллер, но работающий с 48 SAS-дисками. Величина выигрыша была различной для разных профилей, но выигрыш был всегда. (максимально - 48% - на OLTP, минимально - 15% - на fileserver). Одновременно с этим на 31% улучшился responce time.
При этом система с Flash Pool имела на 48% больше емкости хранения, и, одновременно, была на 18% дешевле, чем система с SAS-дисками.

Цена за GB и на IOPS улучшилась, соответственно, на 45 и 40 процентов, а общая пропускная способность улучшилась на 34%, причем при использовании более медленных “по природе” дисков SATA.

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

Подробно о методике тестирования и деталях можно прочитать тут: http://www.esg-global.com/lab-reports/netapp-fas2200-series-with-flash-pool/

pktt: встроенный сборщик ethernet dump

Внутри Data ONTAP зачастую находится много полезных штук, к сожалению, часто малоизвестных “рядовому админу”, особенное если “все и так работает”.
Одна из таких архиполезных для траблшутинга сети штук - встроенный сборщик дампа пакетов на сетевом интерфейсе. Особенно полезно то, что формат собираемого дампа позволяет напрямую открывать его в популярнейшем инструменте анализа дампов - Wireshark.
Если вы настроили CHAP authentification в iSCSI, и что-то пошло не так, или что-то странное творится при доступе к файлам по SMB, то лучший способ - собрать дамп и посмотреть что происходит в сети на стороне стораджа.

Для этого выясним сперва, на каком интерфейсе нас будет интересовать ethernet-трафик.

netapp> ifconfig -a

e0a: flags=0xe48867 mtu 1500
inet 10.10.10.140 netmask 0xffffff00 broadcast 10.10.10.255
ether 00:0c:29:89:3f:3c (auto-1000t-fd-up) flowcontrol full
e0b: flags=0xe08866 mtu 1500
ether 00:0c:29:89:3f:46 (auto-1000t-fd-up) flowcontrol full
e0c: flags=0xe08866 mtu 1500
ether 00:0c:29:89:3f:50 (auto-1000t-fd-up) flowcontrol full
e0d: flags=0xe08866 mtu 1500
ether 00:0c:29:89:3f:5a (auto-1000t-fd-up) flowcontrol full
lo: flags=0×1b48049 mtu 9188
inet 127.0.0.1 netmask 0xff000000 broadcast 127.0.0.1
losk: flags=0×40a400c9 mtu 9188
inet 127.0.20.1 netmask 0xff000000 broadcast 127.0.20.1

Запустим команду pktt, указав ей собирать дамп на заданном интерфейсе, и маркировать файл дампа датой сбора.

netapp> pktt start e0a -d /etc/log
e0a: started packet trace

netapp> pktt status
e0a: Packet tracing enabled; packets truncated at 1514 bytes.
e0a: Trace buffer utilization = 2% of 1048320 bytes, 258 packets
e0a: 0 bytes written to file /etc/log/e0a_20131108_173928.trc
e0a: Currently tracing to file /etc/log/e0a_20131108_173928.trc
e0a: 258 packets seen; 0 packets dropped; 24936 total bytes seen

lo: Packet tracing enabled; packets truncated at 1514 bytes.
lo: Trace buffer utilization = 99% of 130816 bytes, 1011 packets
lo: 1387 packets seen; 0 packets dropped; 160568 total bytes seen

losk: Packet tracing enabled; packets truncated at 1514 bytes.
losk: Trace buffer utilization = 99% of 130816 bytes, 282 packets
losk: 40901 packets seen; 0 packets dropped; 21761277 total bytes seen

Когда нужный интервал сбора пройден, остановим pktt.

netapp> pktt stop e0a
e0a: Tracing stopped and packet trace buffers released.
Fri Nov 8 17:42:25 EST [sim81:cmds.pktt.write.info:info]: pktt: 280 packets seen, 0 dropped, 32046 bytes written to /etc/log/e0a_20131108_173928.trc.

У нас по заданному пути окажется файл с дампом, который мы можем скопировать на машину с Wireshark.

Теперь откроем файл .trc, прямо в Wirrshark, и приступим к знакомому процессу разбора в этом замечательном инструменте.

Эффект от использования VAAI

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