about NetApp

Некоторые читатели все еще раздумывают о том, насколько производителен SMB 3.0, в сравнении с более привычными FC и iSCSI, в среде Hyper-V. Специально для них NetApp опубликовал короткий отчет со сравнением производительности протоколов на одной и той же конфигурации, отличающейся только способами подключения датасторов.

Результаты показательны:

Это – IOPS (за 100% принят FCP)

Это – latency.

Полный отчет с описанием конфигурации можно взять и посмотреть тут: TR-4175 Microsoft Windows Server 2012 Hyper-V Storage Performance: Measuring SMB 3.0, iSCSI, and FC Protocols

??нтересную визуализацию построили в Silverton Consulting (SCI) для результатов тестов SPC-1

Хотя придиры могли бы придраться, что SPC-1 это, мол, не совсем “OLTP”, и нельзя так их сопоставлять, но мы отметем эти реплики как неорганизованные, ведь общепризнанно, что SPC-1 тест по методике крайне жесткий, в чем-то куда жестче для стораджей, чем традиционный профайл, который принято считать “OLTP” (100% random, 75/25 R/W, 4-8KB block)

Полный текст весьма лестного для NetApp обзора можно посмотреть тут.

Результаты для SPECsfs2008 также есть в таком, “квадрантном”, представлении, например для NFSv3 и SMB.

Я чуть раньше уже упоминал о выходе нового продукта в семействе OnCommand - OnCommand Performance Manager (OPM). Несколько слов про него подробнее.
Это - Virtual Appliance, то есть образ преконфигуренной виртуальной машины, запускаемой в среде VMware ESXi, на базе ядра Linux (2.6.32) и с веб-интерфейсом, и предназначен для анализа и слежения за производительностью кластерной (clustered Data ONTAP) системы хранения. Обратите внимание, системы 7-mode - не поддерживаются, только для Clustered ONTAP.

OPM следит и анализирует состояние производительности кластерной системы хранения, отображая ее состояние на веб-дашборде.

Анализируется и отслеживается несколько ключевых точек и компонентов системы.

На рисунке выше показана потенциальная проблема в data processing.
Тут же можно посмотреть отчет о соответствующем инциденте.

?? посмотреть рекомендации по устранению.

В заключение следует отметить, что OnCommand Performance Manager бесплатен для клиентов NetApp, не требует покупки лицензий, и бесплатно доступен для загрузки из support.netapp.com.
Отметьте, что для многовендорных, больших инсталляций сходные задачи решаются другим продуктом, OnCommand Insight, который, будучи значительно более мощным и объемным, а также поддерживающим оборудование разных вендоров в составе IT-инфраструктуры, уже стоит существенных денег. Однако если ваши задачи ограничиваются анализом и контролем производительности одного кластера из контроллеров NetApp FAS, то этот продукт - прекрасный вариант решения.

UPD: В блоге Видада Коснока очень детальный Quick Install Guide, который поможет разобраться с установкой.

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

Раз уж тут мы много поговорили про бенчмарк 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, всегда обращайте внимание на то, сколько метров было в стометровке, которую пробежал участник с таким выдающимся результатом. :)

Одним из самых перспективных средств тестирования дискового перформанса на сегодняшний день является утилита fio.
??сторически я пользовался много лет для этого популярным IOmeter, и даже писал несколько подробных постов о нем, неизменно приводящих в этот блог читателей с поисковиков.

Однако IOmeter достаточно давно затормозился в развитии, и на сегодняшний день имеет stable в версии аж 2006(!) года, а собираемый community имеет версию 1.1RC1 и обновлялся аж летом 2011 года, что никак нельзя назвать приемлемым. К тому же отдельные версии (Linux x64, например) имеют крайне досадные баги, сводящие на нет его применимость под эти платформы.

Поэтому все больше людей для тестирования производительности ищут более современные инструменты. По этой причине несколько месяцев назад мне попался на глаза очень активно развивающийся проект такой утилиты измерения производительности - fio (flexible input-output tester).
О тестировании дисковой подсистемы с помощью fio можно почитать например вот в этой статье.

К сожалению до недавних пор fio существовал только под Linux, поэтому было очень любопытно обнаружить в блоге нетапповского инженера Neto статью о сборке fio под Windows x64.

Нет смысла перепощивать ее сюда, там коротенько и совершенно понятно как и что делать, даже без перевода, так что просто сошлюсь на нее здесь.

Мы уже весь этот год понемногу говорим о новой для пользователей NetApp “классической”, 7-mode архитектуры, схеме Cluster-mode. В отрасли все еще довлеет определенный груз недоверия, Cluster-mode считается, во-первых,  дорогим (но о цене и спецпредложении двухузловой cluster-mode по цене HA-пары 7-mode, и о “Cisco Nexus за 1$” мы уже говорили ранее), сложным в развертывании и установке (но рекомендую сделать поиск по Techlibrary по слову “cluster-mode”) и имеющим значительный оверхед по производительности, в сравнении с системой 7-mode. ?? вот об этом последнем мы поговорим сегодня.

К моему глубокому сожалению некоторые такие предрассудки о производительности системы в Cluster-mode  разделяли и отдельные знакомые мне специалисты самого NetApp.

Поэтому так интересно было посмотреть на официально опубликованный отчет по измерению и сравнению производительности системы Cluster-mode и 7-mode.

Была протестирована производительность работы системы хранения FAS6240 под задачи четырехнодового Oracle RAC на OLTP нагрузке, под всеми поддерживаемыми протоколами, в конфигурации хранилища как 7-mode, так и Cluster-mode, в максимально идентичной конфигурации OS, базы, настроек оборудования. Для затравки вам картинка, остальное по ссылке на полный отчет с описанием методики тестирования.

Как вы видите, согласно этому тесту производительность Cluster-mode ниже аналогичной системы 7-mode не более чем на 7% в наихудшем случае, при, безусловно, значительно большем количестве возможностей, “фич” и перспективах масштабирования решения Cluster-mode.

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

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

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

Надеюсь не нужно дополнительно объяснять, почему для современных многозадачных систем, для баз OLTP, для виртуализованных серверных сред почти 100% доступа к данным является рандомным? Последовательный, “секвентальный” доступ встречается в очень узком сегменте, это бэкапы (а у NetApp, к слову, задача бэкапа, как вы помните, решается другим способом, а не последовательным копированием и передачей данных), это базы с характером доступа DSS, и это, отчасти, логи баз данных. Вот, в общем, и все использование секвентального доступа. Остальное все – более или менее чистый рандом.

Поэтому я взял паттерн доступа VM-сервер (40%-write/60%-read, 45%-sequental/55%-random, 4KB block). Секвентальность в последнем случае берется вследствие работы локального кэша хоста. Паттерны эти определил не я, они довольно широко распространены. Вот его и будем кушать мерять.

Тестировал я с помощью IOmeter, который, несмотря на некоторые его недостатки, знаю и люблю. В качестве load-generator использовались виртуальные машины, работающие с достаточно мощного хоста (IBM 3850 X5), который был подключен к стораджу по NFS. Для OS в VM диск выглядел “физическим” LUN без файловой системы, который делался MBR-разделом и форматировался в NTFS со стандартным размером блока (4KB). Раздел делался размером 40GB, на нем создавался тестовый файл IOmeter (iobw.tst), размером 16GB (для гарантированного “пробоя кэша”). На каждой VM делался 4-процессорный vCPU, и, соответственно, запускались 4 Worker, на каждом из которых пускался тестовый паттерн на созданный диск, в 16 потоков ввода-вывода (Outstanding IOs) на каждый Worker, то есть 64 одновременных потока ввода-вывода на диски (контроллер NetApp). Загрузка хост-сервера тестом не превышала при этом 15% (мощная зверюга этот 3850), загрузка стораджа колебалась, но также не превышала 80%. То есть заведомо мы в “потолки” нигде не упирались.

Для минимизации эффектов “прогрева WAFL” (о котором еще будет пост, это также была одна из тем “исследовательской недели”) я делал длинный ramp-up (10 минут), а затем начинался собственно измеряемый тест, длиной 30 минут. Я брал для оценки значение в steady state, ближе к концу теста, и для оценки параллельно проверяемого эффекта “падения производительности” при прогреве – ближе к его началу.

Однако, перед исследователем, в моем лице, встала проблема: как обеспечить “фрагментацию” файла тестирования? Если создать последовательный, упорядоченный файл просто: запускай IOmeter на пустом диске – вот он и создаст свой iobw.tst, то с фрагментацией “на заказ” сложнее.

Для того, чтобы сделать фрагментированный файл я нашел любопытную утилитку, под названием MyDefragmenter, которая, как ясно из названия – дефрагментатор. Но у нее в комплекте есть также программка MyFragmenter :). Она делает вполне ожидаемую из названия вещь :)

Я взял созданный IOmeter тестовый файл и качественно замесил его с помощью этой утилитки. Я фрагментировал с ее помощью этот файл на 250 тысяч кусочков по 64KB каждый (ну, чтоб не было претензий, что гранаты у нас не той системы;), а потом повторно провел тестирование описанными выше паттернами.

Также я проанализировал ситуацию с фрагментацией не только файла на NTFS, но и в WAFL, а затем измерил эффект от работы reallocate в WAFL.

Хочу отдельно отметить, что в данном случае измеренные “попугаи”  не могут рассматриваться по абсолютной величине, я не проводил никакого (необходимого) тюнинга системы, и настройки ее “по уму” и по best practices (это я  сделаю позже, ту у меня есть некоторые бюрократические процедуры для этого). Целью теста было сравнить два достигнутых параметра производительности: “А” и”Б”, то есть их соотношение, а не достижение абсолютного рекорда, поэтому реплики с мест “чота как-то иопсев маловата!” мы отметем как неорганизованные ;).

Вот какие результаты я получил:

Continue reading ‘В последний раз о фрагментации файлов и производительности’ »

Сегодня очередной перевод одного из моих любимых авторов, инженера NetApp Dimitris Krekoukias, пишущего в блоге recoverymonkey.org. Текст крайне важный и заставляющий задуматься. Казалось бы, все мы знаем, что такое “IOPS”, но знаем ли мы это на самом деле, и не упускаем ли мы, говоря про IOPS-ы, нечто важное из виду? Насколько полнятие IOPS является однозначно идентифицируемым и можно ли показатели “в IOPS” трактовать однозначно, и сравнивать различные результаты, различных вендоров между собой?

IOPS: Возможно наиболее известный показатель производительности системы хранения.

IOPS означает Input/Output (operations) Per Second, "операций ввода-вывода в секунду". Смысл величины выглядит довольно очевидно. Он измеряет объем работы за определенный промежуток времени (и это не то же самое, что мегабайты в секунду, MB/s).

Кто из вас не видел вендоров, которые превозносят достоинства своих систем хранения, демонстрируя огромные величины IOPS ими достигнутые? Кто из вас не принимал решения покупки системы хранения, основываясь на обещаниях вендорами этих величин? Однако: как часто вендоры, приводя свои результаты, в действительности четко определяли то, что они понимали под аббревиатурой "IOPS", публикуя эти результаты?

Для нетерпеливых, скажу это с самого начала: Величина IOPS сама по себе бессмысленна, и именно так и должна рассматриваться. Без дополнительных метрик, таких как latency, процентное соотношение операций чтения и записи и размера блоков ввода-вывода, величина IOPS совершенно бесполезна.

А теперь подробнее…

Continue reading ‘Что такое IOPS?’ »

Я не первый раз рубликую тут переводы постов инженера NetApp – Dimitris Krekoukias, ведущего автономный, и крайне интересный блог http://recoverymonkey.org/ (другие мои переводы его постов вы можете найти в рубрике “переводы”)

После долгого молчания, Dimitris опубликовал пост, вызванный публикацией отличных результатов кластера FAS6240 в Data ONTAP 8.1.1 Cluster-mode в бенчмарке блочного (FC) доступа – SPC-1, о котором я уже написал в понедельник. Однако вопросу почему он так хорош, и насколько именно он хорош – посвящен сегодняшний перевод.

NetApp опубликовал великолепные результаты тестирования Cluster-Mode в бенчмарке SPC-1

Опубликовано June 20, 2012

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

Мы недавно выпустили ONTAP 8.1, которая, в Cluster-Mode, позволяет создать 24-узловой кластер (каждый узел которого может иметь до 8TB кэша) для задач NAS, и 4-узловой кластер для блочного доступа (FC и iSCSI).

А с выпуском ONTAP 8.1.1 (выпущенного 14 июня), мы увеличили лимит узлов для блочного доступа до 6, плюс добавили ряд дополнительных оптимизаций и возможностей. Между прочим, число узлов в кластере это пока только условный лимит официальной поддержки, это не жестко заданное ограничение.

После публикации нашего рекордного результата в бенчмарке NFS, люди спрашивали, как обстоит дело с производительностью блочного ввода-вывода в ONTAP Cluster-Mode, поэтому мы провели тестирование и опубликовали результаты бенчмарка SPC-1, используя часть той же системы, что уже была протестирована на SPEC sfs2008 NFS.

Для тех кто до сих пор думает, что NetApp не подходит для блочного доступа (это типичный FUD наших конкурентов): Это, на сегодня, лучший результат SPC-1 среди всех дисковых систем хранения, из расчета на уровень latency при достигнутом уровне IOPS (то есть возможно получить даже более высокие показатели IOPS на бОльших лимитах по latency, как я покажу далее в этом посте).

Вот ссылка на результаты и еще одна ссылка, на полную версию со всей доступной информацией.

В этом блоге я уже говорил о том, что представляет собой бенчмарк SPC-1 . Вкратце: Бенчмарк SPC-1 это общепринятый в индустрии, аудируемый, бенчмарк блочного доступа к системе хранения (по Fiber Channel) который проводит стресс-тестирование дисковой подсистемы большим объемом записей, перезаписей, локальных "хотспотов" и смешанной произвольно/последовательной, чтение-после-записи, запись-после-чтения нагрузкой. Около 60% рабочей нагрузки это операции записи. Размеры используемых в бенчмарке операций ввода-вывода различны, от маленьких до больших (таким образом IOPS в бенчмарке SPC-1 не идентичны и не могут быть сравнены напрямую с классическим тестом IOPS в full random блоками 4KB).

Если сторадж успешно работает на нагрузке SPC-1,, он, обычно, также крайне производительно работает на сложной, чувствительной к показателям latency, динамично изменяющейся нагрузке типа баз данных, в особенности OLTP. Полная спецификация для смертельно любопытных может быть найдена здесь.

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

Перед тем, как мы перейдем к анализу и сравнению результатов, несколько замечаний для неверующих:

1. В тестах NetApp не используется диски "с коротких ходом" (short-stroking), так часто любимые многими вендорами, проводящими тестирование, при котором используется только внешняя, наиболее быстродействующая часть диска, где сочетается максимальная линейная скорость и малый разбег механики коромысла жесткого диска, на чем можно показать наилучшие результаты. Вместо этого мы используем настройку параметров системы , чтобы использовать всю поверхность дисков, и не зависеть от того, насколько заполнены данными диски. Смотрите полный отчет здесь, страница 61. Для любителей распространять FUD: это эффективно "старит" состояние WAFL, приближая его к реальному состоянию реально эксплуатируемой системы. Мы также не используем оптимизацию размещения блоков путем их реаллокации.
2. Падения производительности в ходе продолжительного тестирования не наблюдалось.
3. Средняя величина latency (“All ASUs” в результатах) была плоской и оставалась ниже уровня 5ms на протяжении нескольких итераций теста, включая sustainability test в течение 10 часов (страница 28 полного отчета).
4. Не использовался дополнительный кэш, кроме того, который поставляется в базовой поставке FAS6240 (Контроллеры 6240 поставляются с Flash Cache емкостью 512GB, при максимальной возможной емкости данной модели 3TB на ноду (контроллер), то есть для работы с большими нагрузками есть еще значительный запас).
5. Это не "звездолет", построенный исключительно для завовевания победы и установления рекорда в бенчмарке. Мы использовали сравнительно немного дисков, в сравнении с конфигурациями других вендоров, и это не самая быстрая наша модель контроллера (еще есть 6280).

Анализ

Когда мы смотрим на результаты бенчмарка, следует сфокусироваться на следующих моментах:

1. Высокий уровень установившейся производительности в IOPS (нестабильность показателей показывает на наличие проблем).
2. IOPS/диск (это показатель эффективности – 500 IOPS/drive это вдвое лучше и эффективнее, чем 250 IOPS/drive, что, как следствие, означает меньше необходимых дисков в системе, снижает ее стоимость, уменьшает физический занимаемые в датацентре объем, и так далее.)
3. Стабильно низкая latency (пики показывают наличие проблем).
4. IOPS связан и зависит от latency (Получили ли вы высокие показатели IOPS вместе с высокой latency на максимуме? Это практически используемо?)
5. Какой тип RAID использовался (RAID6? RAID10? RAID6 обеспечивает значительно лучшую защиту данных и лучшие результаты эффективности использования дискового пространства, чем зеркалирование, что ведет к снижению стоимость даже более надежного хранилища данных).
6. Какие диски использовались? Хотите ли вы покупать такие диски?
7. ??спользовался ли autotiering? Если нет, то почему нет? Разве он не помог бы в такой сложной ситуации?
8. Какое оборудование потребовалось, чтобы получить стабильную производительность (сколько дисков и контроллеров потребовалось для построения системы? Означает ли это более сложную и дорогую систему? Как это все будет управляться?)
9. Цена (некоторые вендоры указывают цену уже с учетом дисконта, в то время как другие публикуют цену в list price, так что будьте тут внимательнее).
10. Цена/IOPS (наиболее полезная метрика – но следует сравнивать цену list price с list price).

SPC-1 это бенчмарк НЕ для измерения максимума потока данных; для измерения чистого GB/s смотрите другие бенчмарки. Большинство систем не дает больше 4GB/s в этом бенчмарке, так как много операций в нем рандомные (и 4GB/s это довольно много для рандомного ввода-вывода).

Сравнение систем

В этой части мы сравним дисковые системы хранения. Предсказуемо "чистые SSD" (или RAM) системы хранения имеют, конечно, очень высокие показатели производительности, и могут подойти, если ваша задача - обеспечивать работу с небольшим объемом данных очень быстро.

Но мы сосредоточимся на задачах высоконадежных систем общего применения, которые обеспечивают одновременно и высокую производительность, и низкую latency, и большую емкость, за разумную цену, а также, одновременно, большое количество функциональных фич(снэпшоты, репликация, кэширование в flash (megacaching), thin provisioning, дедупликация, компрессия, многопротокольность, включая NAS, и так далее). Опа – оказывается никто из конкурентов не может сделать сразу все что умеет делать NetApp.

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

• NetApp 6240
• IBM SVC with V7000
• IBM SVC with DS8700
• HDS VSP
• HP 3Par V800
• Huawei Symantec S8100

Также есть несколько других дисковых систем хранения, со значительными результатами по IOPS, но если мы посмотрим на их результаты sustained latency (“Sustainability – Average Response Time (ms) Distribution Data” в любом из полных отчетов) мы увидим, что общие показатели latency чересчур высоки и наблюдается значительная неравномерность, в особенности в начальной фазе, с пиками до 30ms (что крайне много), поэтому мы не взяли их в расчет.

Вот краткий перечень систем и их параметров, отсортированных в соответствии с latency. Кроме этого показана и их стоимость в ценах list price (это можно найти в полном отчете о тестировании) плюс стоимость операции $/IOPS, посчитанная исходя из list price (многие вендоры приводят в отчетах цену с уже введенной скидкой, чтобы цена выглядела пониже):

…но ведь тут показано, что некоторые системы быстрее NetApp… Как так?

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

Вот как это увидеть:

1. Выберите один из приведенных выше линков на полные отчеты Допустим это будет 3Par, так как он показывает одновременно и высокие показатели производительности, и высокие значения latency.
2. Найдем в отчете главу под названием "Response Time – Throughput Curve". Например это страница 13 в отчете по системе 3Par.
3. Проследим, как latency резко растет при повышении загрузки системы.

Например посмотрим на кривую 3Par:

Заметьте то, как latency резко растет после некоей точки.

Теперь сравним с результатом NetApp (страница 13):

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

Вот почему колонка“SPC-1 IOPS around 3ms” была добавлена в таблицу. Фактически это ответ на вопрос что бы было, если бы уровень latency был в тесте одинаков для всех протестированных систем?

Когда вы примете эту позицию, вы увидите, что система 3Par фактически медленнее, чем NetApp, если сравнить их на одинаково низком желаемом уровне latency.

Вы можете взять точные показатели latency из графика на странице 13, у NetApp таблица выглядит так (озаглавлено "Response Time – Throughput Data"):

Действительно, при сравнении результатов мы видим, что только IBM SVC (с кучей стораджей V7000 за ним) оказывается быстрее NetApp при столь же хороших показателях latency. Что плавно подводит нас к следующей главе…

Сколько железа обеспечивает такую производительность?

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

• 8 SVC контроллеров (virtualization engines) плюс…
• …16 отдельных систем V7000…
• …каждая состоящая из еще 2 контроллеров SVC и 2 контроллеров RAID
• 1920 дисков 146GB 15K RPM (не так-то просто такие купить нынче, не так ли?)
• ??того 40 контроллеров SVC (8 больших и 32 поменьше), 32 RAID-контроллера, и все это битком наполнено дисками.

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

Сравним эту кухню с вариантом конфигурации NetApp:

• 6 контроллеров в одном кластере
• 432 диска 450GB 15K RPM (самый распространенный и массовый наш диск по состоянию на июнь 2012).

Вопросы (с удовольствие увижу ответы на них от других вендоров):

1. Что произойдет при использовании RAID6 у других вендоров? NetApp всегда тестирует системы с использованием своей версии RAID6 (RAID-DP). RAID6 значительно надежнее, чем зеркалирование, особенно в больших пулах (не говоря уже о более эффективном использовании пространства дисков). Большинство клиентов не хотят покупать большую систему в конфигурации только-RAID10… (пользователи - задавайте вопросы вашим вендорам. Тут нет никакого волшебства – ручаюсь, у них есть внутренние результаты для RAID6, попросите показать их вам).
2. Autotiering это одна из самых раскрученных сегодня фич, с признаками того, что это достижение, превосходящее изобретение пенициллина, или даже колеса, а может даже и огня… Однако никто из дисковых массивов не рассматривает использование SSD для autotiering (IBM опубликовала однажды результат – не впечатляет, делайте выводы). Это при том, что бенчмарк, по своей спецификации активно создающий "горячие точки" (hotspots) нагрузки, должен бы быть здесь идеальным кандидатом для демонстрации эффективности…
3. Почему EMC и Dell не желают публиковать результаты SPC-1? (Они оба, кстати, члены SPC, Storage Performance Council). Только два этих вендора, из крупных игроков на рынке, кто еще не опубликовали свои результаты. EMC ранее говорила, что SPC-1 это нереалистичный тест – ну, типа только ваше приложение с вашими данными на вашем сторадже может показать по-настоящему реальные результаты. Это так, однако SPC-1 это общепринятый индустрией стандартный бенчмарк для блочного доступа произвольного характера, и отличная "лакмусовая бумажка".
4. Для системы, которая регулярно позиционируется для нагрузки Tier-1, IBM XIV, результаты бенчмарков, увы, отсутствуют также, даже для самой новой ее Gen3. Неужели IBM стесняется показать свои результаты SPC-1 для этой системы?
5. Наконец – некоторые наши конкуренты продолжают утверждать, что NetApp, дескать, это "не настоящий SAN", что это, якобы "эмуляция SAN", и так далее. Что бы это все ни значило на самом деле – может быть подход NetApp, с такой "эмуляцией" оказывается, по факту, лучше?… Максимальная write latency в этом тесте составила 1.91ms для в основном записываемой нагрузки!

??тоговые мысли

В накануне опубликованном результате бенчмарка SPC-1, NetApp показала вновь, что Data ONTAP в Cluster-Mode это высокопроизводительная и масштабируемая система, одинаково подходящая как для SAN, так и для NAS задач. Суммируя все вышесказанное, можно сказать, что ONTAP Cluster-Mode:

• Позволяет строить высокопроизводительные и динамически-масштабируемые кластеры хранения для FC, iSCSI, NFS и CIFS.
• Демонстрирует низкую latency при высокой производительности.
• Предлагает исключительно хорошее соотношение price/performance.
• Позволяет доступ к данным одной ноды с любых других нод.
• Перемещает данные между нодами, не прерывая работы с ними (включая CIFS, что ранее не было практически невозможно).
• Поддерживает традиционные для NetApp возможности (оптимизацию процессов записи, взаимодействие с приложениями, снэпшоты, дедупликацию, компрессию, репликацию, thin provisioning, и кэширование во flash (megacaching).
• Может работать на в точности тех же самых контроллерах FAS, что и в 7-mode, что защищает инвестиции.
• Может виртуализовывать системы хранения, расположенные за ними.

??сточник <http://recoverymonkey.org/2012/06/20/netapp-posts-great-cluster-mode-spc-1-result/>