about NetApp

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одной из специфических особенностей “инженерного мЫшления”, исторически присущего компании NetApp, является зачастую весьма странные и вызванные какими-то глубинными процессами названия фич. Зачастую они закрепляются как официальные, видимо выйдя из недр программистских групп, а создаватели брендов и торговых марок из программтстов – те еще.

Вспомните хотя бы загадочный Fractional Reserve, над которым сломал голову не один человек, включая в свое время и меня самого (сегодня он в документации постепенно заменяется на гораздо более понятный LUN Overwrite Reserve). Оттуда же, допустим, vif, и прочие загадочные аббревиатуры, последние были некоторое время назад официально переименованы в куда более понятный ifgrp.

Дошел черед и до VServer, краеугольного понятия Clustered ONTAP. Даже за вычетом того, что нынче в начале термина “V” – значит Вендетта почти что зарегистрированная торговая марка VMware, сам по себе термин “VServer” – крайне неясен и несамоописывающ.

?? вот, я с радостью отметил, что в новых материалах NetApp наметилось новое переименование – VServer теперь SVM – Storage Virtual Machines. Я давно, объясняя людям то, как работает Cluster-mode, делал это через аналогию с куда более знакомым и понятным кластером VM в VMware VSphere. Отрадно видеть, что теперь одним инженерным непонятным термином в лексиконе NetApp стало меньше.

Опять же, это торит интересную тропинку к новому баззворду индустрии – Software-defined Storage.

Процесс постепенного перехода и перевода пользователей с good ol’ 7-mode на shiny new Cluster-mode своей неторопливостью и неспешностью порой мне напоминает ту сердобольную семейку, которая своему щенку фокстерьера хвостик отрезала по кусочку. К меня такое ощущение, что я уже всю жизнь с NetApp провел в процессе transition-а продуктов компании с 7-моде на Кластер. Ну да впрочем хватит бухтеть. :)

На носу у нас Data ONTAP 8.2, с новыми интересными возможностями, а пока на глаза мне попался документ, посвященный изменениям в лицензировании. Как вы заметили, NetApp экспериментиует с лицензированием уже довольно давно, что-то явно получается неплохо, взять хотя бы модель Data ONTAP Essentials.

Начиная с Data ONTAP 8.2 NetApp меняет лицензионные ключи и всю схему лицензий на 7-Mode и Cluster-mode.

Во-первых, вводятся новые, единые лицензионные ключи, единые для 7-Mode и Cluster-mode. Если вы интересовались темой, то знаете, что в Cluster-mode были отдельные ключи, и до 8.2 вам приходилось явно, на этапе покупки системы выбирать, какую систему вы покупаете, чтобы получить нужный набор. Теперь вводятся новые лицензионные ключи софтварных фич, длиной аж 28 символов, которые будут работать на обоих mode Data ONTAP, начиная с 8.2.

Во-вторых, лицензии будут привязаны к серийнику контроллера. Это неприятная новость, но рано или поздно это должно было произойти. На практике, для честного приобретателя, это означает, что теперь, при замене контроллера (head swap), вам также потребуется получит под его серийник новый набор ключей. Соответственно усложняется и удлиняется эта, ранее довольно простая, процедура.

Наконец, лицензи могут существовать “не-cluster-wide”, например часть узлов в кластере может иметь один набор лицензий, а часть – другой, оставаясь при этом единым кластером.* (см комментарий). Напомню, что “кластером” с прошлого года в этом блоге я называю всегда только группу HA-пар контроллеров, работающих в Cluster-mode (C-mode), а то что иногда раньше называлось “кластером”, а именно пара контроллеров под управлением “старой” 7-mode, теперь называется HA-парой (High Availability pair). На HA-пару лицензии по-прежнему единые.

Впрочем, более интересные новости грядут с самим выходом Data ONTAP 8.2, не переключайте ваши браузеры :)

На прошлой неделе в группе communities.netapp.com был опубликован Virual Storage Console 4.2 beta.

VSC это основной инструмент для управления и использования стораджами NetApp в среде VMware vCenter, он позволяет управлять системой хранения “с точки зрения” администратора виртуальной инфраструктуры, создавать и удалять датасторы, настраивать их, управлять доступом, создавать резервные копии и клоны, и так далее.

К сожалению пока не поддерживается vCenter Web Client, поворот к которому уже окончательно наметился, VSC 4.2 все еще работает как плагин к “толстому клиенту” vCenter, но работа над новым VSC (вероятно он будет 5.0) уже идут, и близки к финишу. Он будет работать с vCenter Web Client, и использовать платформу Adobe FLEX. Но пока – про VSC 4.2 beta.

??з нового – полноценно поддерживается RBAC (Role-bsed Access Control). В VSC 4.1 RBAC использовать было тоже можно (нужно), и работать под специальным пользователем, а не “под рутом”, но это требовало довольно хлопотных и трудоемких операций по настройке прав такого пользователя. В VSC 4.2 в этом направлении сделаны большие подвижки, настроены templates и настройку можно проводить уже непосредственно из VSC. Вы можете создать отдельно Главного Администратора, отдельно Администратора с правами бэкапа и клонирования, например, отдельного админа для создания датасторов, отдельно юзера с правами readonly, и так далее. Это крайне востребовано в больших инфраструктурах, где, зачастую, на ферме виртуальных машин работает множество разных админов, с разными правами доступа и должностными обязанностями.

Переработана разбивка функций по модулям VSC. Когда-то VSC был надстройкой над разными продуктами, в частности отдельно существовал SnapManager for Virtual Infrastructure для бэкапов и восстановления из них, и утилита RCU – Rapid Cloning Utility, для клонирования датасторов и их провижнинга. Так как уже давно все эти продукты встроены внутрь VSC, давно назрела необходимость перетрясти организацию пользовательского интерфейса VSC.

Ну и, как всегда, поправлены баги (около 150), и добавлена поддержка новых систем в VDDK (например Windows Server 2012).

Бету (да, я осознаю, что такое бета-версия и как ее используют: [x]) можно брать тут:
https://communities.netapp.com/community/products_and_solutions/virtualization/vsc

Вчерашний пост про striped volume вызвал заметную реакцию. Не секрет, что ситуация с использованием концепции share nothing в NetApp FAS, и необходимостью разбивать диски между двумя контроллерами, это давний butthurt головная боль пользователей NetApp, особенно младших его систем. Да, действительно, когда дисков всего 12, допустим, то очень обидно отдавать половину на RAID и spare, по отдельности на каждый из пары контроллеров. Это не является существенной проблемой для людей, у которых дисков шкафы, сотни хостов, подключенных к системе, и так далее. В таких системах нет особенной необходимости для создания единого ресурса хранения, обычно в них LUN-ов и дисковых шар куда больше чем один. Но сомнение зудит. Все умеют, а нетапп не умеет, значит это проблема NetApp.

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

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

Striped Volume позволяет:

1. Потенциально может помочь увеличить производительность дискового ресурса, особенно если он такой на системе один, и не может быть распределен своими частями между контроллерами естественным образом.
2. Обеспечивает равномерную загрузку несущих его нодов.
3. Позволяет делать cross-bound ресурсы, например очень большие файловые шары (для LUN это, как правило, не столь важно, так как они сами по себе ограничены, например 2TB в MBR-LUN, или же  64TB VMFS5.

Это так, как я уже упомянул выше, прежде всего в случае, когда такой ресурс (том, LUN, сетевая шара) ровно один. Однако в реальной жизни очень редко когда сторадж несет на себе ровно один LUN, датастор, файловую шару. Обычно, в моей практике, таких ресурсов десяток, и не один. ??, в общем, проблема “одного дискового ресурса” на мой взгляд довольно надумана. Вручную, на маленьких системах, или с помощью имеющихся средств, типа Data Motion и OnCommand Balance, для больших, это сравнительно несложно сделать.

Проблема Cross-bound ресурсов сложнее, но тоже, на мой взгляд, довольно “бумажная”. В свое время, во времена ONTAP GX, когда контроллеры были не чета нынешним, ограничения на объем хранения на одном контроллере дествительно иногда создавали проблемы, и требовали найти пути выхода. Сегодняшние контроллеры часто имеют лимиты по объемам, превышающий реально эксплуатируемые, и, что немаловажно, имеющий смысл эксплуатировать на данном контроллере. Я очень редко вижу ситуацию, когда владелец контроллера NetApp добивает его дисками “под крышку”, до его лимита по объемам. Это просто довольно таки недальновидно с точки зрения производительности системы в целом.

??так, какие же есть “подводные камни” для Striped Volume, и какие ограничения с ним связаны.

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

Во-вторых, striped volume есть объективное ограничение для самой идеи scaled-out архитектуры. например он требует, чтобы все контроллеры в кластере, по крайней мере в пределах striped volume) были однотипны (одинаковые контроллеры было требованием в GX, но это уже не так в Clustered ONTAP, и именно это направление, по моим наблюдениям, активно развивается компанией). Представьте себе, что striped volume оказался на двух узлах кластера: FAS6240 и FAS2240. Что будет с производительностью такого тома?

Соответственно использование striped volume естественным образом убивает возможность миграции тома между узлами кластера, крайне важной и нужной фичи Clustered ONTAP. Как результат, это делает невозможность миграцию такого тома в пределах кластера, например если вам нужно выполнить обслуживание или отключение одного из кластеров, содержащих striped volume. Соответственно это потенциально понижает общую availability кластерной системы в целом.

Наконец, люди, пользовавшиеся striped volume отмечали странное поведение и глюки, в особенности в области производительности, а так как, см. выше, эта фича явно идет в разрез с основным движением Clustered ONTAP в компании, то, вероятнее всего, эта фича будет вскоре просто убрана как таковая, и уж точно доделывать и вылавливать баги из нее не будут.

?? последнее, задача сверхбольших томов в  настоящее время решается с помощью Infinite Volume, и не требует поддержки striped volume.

Таким образом, несмотря на то, что фича striped volume в Data ONTAP Cluster-mode и имеется, использовать ее в реальной жизни, иначе, как  если у вас абсолютносовершенноточноиникакиначе имеется такое требование для ее использования, объективно не стоит.

На проходящей сейчас в Лас-Вегасе конференции Amazon Web Services re:Invent было объявлено, что Amazon Web Services (AWS, крупный облачный провайдер) начнет предлагать услуги “гибридного облака”, то есть решения, сочетающего private cloud, располагающегося закрыто у клиента, и public cloud, то есть традиционное “провайдерское облако”, аналогичное уже хорошо знакомым продуктам AWS, RackSpace, или, допустим, Selectel и ??Т-Град. Строить такую услугу он будет с использованием систем NetApp FAS.

Обычно услуги public cloud больших объемов строятся с использованием commodity hardware, то есть “обычного” компьютерного железа и самостоятельно разрабатываемого (или модифицируемого) софта, наподобие OpenStack. ??менно так поступил и Amazon со своими S3 и EDB (официально о выборе поставщика большие компании предпочитают не растпространяться, но по ряду косвенных признаком можно сделать вывод именно о commodity-based решении). Однако, во многих случаях выбор commodity, при внешней простоте и дешевизне, сопряжен со значительными затратами на разработку и тестирование, причем со своими проблемами вы рискуете оказаться наедине, а vendor lock вы заменяете на developer lock.
Кроме того, часто, могут возникнуть проблемы с взаимодействием с имеющимся клиентским оборудованием, и, часто, это клиенты, которым нельзя сказать “у вас пулеметы не той системы, поменяйте на Linux, иначе нормально не заработает.”

С этой точки зрения подход AWS по интеграции пользовательских сервисов, в рамках такого “гибридного облака”, с использованием технологий NetApp, выглядит вполне здраво.
Для взаимодействия с уже имеющимися сервисами AWS public cloud для установленных в AWS datacenter (AWS availability zones) систем NetApp FAS разработаны средства Amazon Direct Connect к EC2 и S3, а имеющееся оборудование NetApp клиента взаимодействует с таким “колокейшном” обычным образом, с помощью того же SnapMirror, и так далее.

В настоящий момент решение AWS-NetApp разворачивается в регионе US, и в планах в дальнейшем предлагать его в EMEA и APAC.

Отдельной строкой хочу уточнить для читающих по диагонали: в новости не идет речь про переход AWS на NetApp, или замену имеющихся у AWS услуг, типа S3, и прочих, на решения NetApp. Речь идет про дополнительное предложение для компаний, уже использующих NetApp для построения своих датацентров и частных облаков, и желающих интегрировать эти сервисы с сервисами public cloud, предоставляемых AWS для создания “гибридного облака”, например для резервного хранения данных в S3 или Glacier, или для удаленной обработки их в динамически создаваемых инстансах EC2.

Мы уже весь этот год понемногу говорим о новой для пользователей 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.

??з журнала drugoi:

“30.10.2012, США | Вчера меня в твиттере спрашивали по поводу этой фотографии — что это здание такое, всё в огнях, когда весь остальной Манхэттен сидел без света? Отвечаю: это штаб-квартира одной из крупнейших в мире финансовых групп Goldman Sachs. Банкиры просто заранее озаботились установкой хорошей системы аварийных генераторов.”

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

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

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

Надеюсь не нужно дополнительно объяснять, почему для современных многозадачных систем, для баз 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 ‘В последний раз о фрагментации файлов и производительности’ »