about NetApp

Я уже пару раз писал в этом блоге о чрезвычайно полезной программке IOmeter, предназначенной для нагрузочного тестирования и измерения производительности серверов, систем хранения и сети. К моему удивлению, эти две статьи приводят на мой скромный блог громное количство народу, так как, как оазалось, подробного описания использования IOmeter (а тем более на русском) в интернете просто нет. Программа же не вполне “интуитивно понятна”, и, зачастую, именно этим объясняется то, что такой замечательный, гибкий и удобный, и при этом абслютно бесплатный инструмент тестирования находится в определенном “загоне”.

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

Недавно я пролистывал чрезвычайно полезный сам по себе блог Антонио Хосе Родригеса Нето, системного инженера бразильского отделения NetApp, специализрующегося на вопросах использования систем хранения NetApp и баз данных Oracle. В одном из постов я углядел любопытную рекомендацию относительно установки и использования параметра Align I/Os, которую обычно всегда оставлял по умолчанию. Этот параметр устанавливает смещение паттернов ввода-вывода, и значение по умолчанию его – 512 байт (sector boundary).

Neto справедливо указывает, что для современных систем хранения имеет смысл устанавливать его значение в 4096 байт, как более соответствующего структурам и нормам работы дискового хранилища, обычно располагающегося не на физическом диске как таковом, а на RAID-группе, имеющей более крупный размер элемента данных. В частности, в случае NetApp это блок WAFL, как раз и имеющий размер 4KB.

Кстати, по ссылке Neto демонстрирует тест FAS3140A на 96 дисках FC 300G 15K, при трех серверах load-generator под RedHat Linux, подключенных по 4Gb FC, и показывающего свыше 100K IOPS на нагрузке 4KB блоками и 100% random write. Очень впечатляющий результат.

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

Однако, для того, чтобы полученные результаты были сравнимы с результатами другой системы, следует тщательно разработать и последовательно использовать при измерении методику тестирования, ведь очевидно, что измерения в различных условиях дадут на выходе и несравниваемые результаты.
Именно по этой причине так важно использовать для тестирования общепринятый метод, адекватно отражающий практические условия использования. “Скорость копирования файла avi в тотал коммандере” мало что даст, например, для понимания того, что следует ожидать от системы, используемой для хранения OLTP-базы банных.

Я уже писал в свое время два поста о использовании для оценки проиводительности свободно распространяемой программы IOmeter, однако в мире “больших” систем использутся другие системы тестирования.

Так, NetApp официально использует для оценки производительности своих систем и публикует результаты для следующих тестовых пакетов:

Тест быстродействия сетевых файловых систем NFS  и CIFS (NAS): SPECmark’s SPEC SFS2008

Широко принятый и апробированный индустрией тестовый комплекс с большой историей, для имитации “приближенной к реальной жизни” нагрузки NAS-систем.

Storage Performance Counsil standard test (SPC-1, SPC-1/E)

Стандартный тест блочного (FC SAN) хранилища. Также, в соответствии с последними требованиями, разработан и тест оценки энергоэффективности системы хранения (SPC-1/E)

Microsoft ESRP (Exchange 2010 Solution Reviewed Program – Storage 3.0)

Не вполне “тест” (не позволяет валидное сравнение между различными вендорами, но широко поддержанный множеством производителей) тест “прикладного” уровня, с использованием MS Exchange 2007/2010, имитирующий использование системы для хранения почтовой базы MS Exchange.

Во всех этих тестах вы сможее найти системы NetApp, в том числе и самой новой, представленной в прошлом месяце серии FAS3200/FAS6200.

“Добро померяться” :)

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

Вот, например, недавно обнаружил набор утилиток для снятия и реалтайм-контроля производительности системы, особенно полезной в том случае, когда у вас “на хозяйстве” ни DFM, ни Performance Advisor не имеется.

Утилитки написаны на Perl, и существуют в двух вариантах: для Linux в виде Perl-скрипта, и для Windows, в виде исполняемого файла (просто с уже вкомпилированным интерпретатором Perl, как я понял)

Утилита использует доступ через ssh или rsh к вашему файлеру и собирает вывод команды stats  консоли, отображая его в удобной, “человекочитаемой” форме.

В комплект утилит входят:

• na_stats_viewer – выводит информацию о различных объектах команды stats, в удобной читаемой форме, пример фрагмента вывода утилиты на скриншоте.

• na_diskstats_viewer – выводит статистику загрузки индивидуально по физическим дискам. Может быть полезна в поиске причин проблем произвдительности и ненормального поведения системы, например выявления hot spindles.

• na_protostats_viewer – выводит статистику по протоколам (NFS, iSCSI, FC, CIFS)

Более подробное описание в приложенном к утилитам PDF.

Скачать можно тут: NA_STATS
Источник на сайте NetApp: тут (для того, чтобы скачать с сайта, надо быть залогиненным)

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

По результатам недавно опубликованного отчета о тестировании производительности работы базы данных MySQL 5.0.56 (InnoDB) на сервере HP DL580 G5 под RHEL4, с использованием трех протоколов доступа – FC, iSCSI и NFS, к системе хранения FAS3070 можно оценить эффективность использования передачи данных по этим трем протоколам.

MySQL 5.0 Performance Protocol Comparison

При тестировании использовался открытый тестовый пакет генерации нагрузки DBT-2 Rel.40 (Database Test Suite), генерировавший нагрузку профиля OLTP (16K random read/write в пропорции 57% read/43% write) для базы объемом 100GB. Больше подробностей можно узнать из приведенного документа. Также приведены подробные описания конфигов и использованных настроек всех компонентов.

Для затравки – один из измеренных результатов.

Тестировние показало, что использование iSCSI дало снижение всего на 9%, а NFS – всего на 16% относительно взятой за максимум производительности на FC. Результаты показывают, что широко распространившееся во времена MySQL 3.23 мнение, что NFS в базах MySQL непригоден для использования, уже не соответствует действительности. 
Любопытно, что того же мнения теперь придерживаются и “с той стороны баррикад”, в Sun/Oracle:
”for MySQL on Linux over NFS, performance is great, right out of the box.”

Интересущимся рекомендую тщательно просмотреть отчет, там есть над чем подумать. Есть основания предполагать, что с более новым железом (все же FAS3070 это уже довольно старая система, c ONTAP 7.2.4) и с новым клиентским софтом (RHEL4, использовавшийся на хосте, имел ядро 2.6.9-42.EL.smp) разница может оказаться еще менее значительной.

Также интересующимся рекомендую обратить внимание на документы:

Linux (RHEL 4) 64-Bit Performance with NFS, iSCSI, and FCP Using an Oracle Database on NetApp Storage

Best Practices Guidelines for MySQL

Компания NetApp опубликовала результаты тестирования 4Gb FC и Software iSCSI по 1Gb Ethernet и 10Gb Ethernet в среде MS Hyper-V R2 с использованием своей системы хранения NetAp FAS3160A (система midrange-класса).

Тестирование производилось с помощью IOmeter (о котором я уже не раз писал в блоге), с 4 хост-серверов IBM x3550 (1x Quad-core Intel Xeon E5420, 2,5GHz), на каждом из которых бы установлен Windows 2008 R2 c Hyper-V role и 8 виртуальными машинами в каждом, с Windows 2008 64-bit Enterprise edition (итого 32 виртуальных машины). Интерфейсы каждого сервера: FC – QLogic QLE2462, Gigabit Ethernet – Intel PRO/1000 PT dual port, 10G Ethernet – Intel Ethernet Server Adapter X520, включались в коммутаторы Brocade 200E, Cisco 4948 Ethernet Switch и Fujitsu XG1200 соотвественно.
Особое внимание при тестировании уделялось получению результатов, приближенных к “боевым”, позволяющим использовать их для оценки реальной, “живой” инфраструктуры Hyper-V.

Использовался паттерн: 100% Random, 75% Read, 4KB и 8KB Request size.

Тесты показали сравнительно незначительную разницу между всеми тремя вариантами (4Gb FC, 1Gb software iSCSI, 10Gb software iSCSI) как в IOPS, так и в Latency. Дополнительная загрузка задачи softwre iSCSI initiator составила 3-5 процентов, в том числе и на 512 outstanding IOs (очень высокая загрузка), и разница со значением загрузки при использовании FC уменьшалась с повышением объемов загрузки (Outstanding IOs).

Показательно почти полное отсутствие значимого отличия по быстродействию между 4Gb FC и 1Gb iSCSI на рассматриваемой задаче.
Отсутствие значительной разницы между 1Gb Ethernet и 10Gb Ethernet по видимому связано с тем, что Software iSCSI initiator на 10G Ethernet перестал быть эффективен, и, возможно, следует рассмотреть использование iSCSI HBA для таких высокоскоростных решений.
Также сравнительно небольшую разницу дает включение и использование Jumbo Frames как на 1G Ethernet, так и на 10G Ethernet, что скорее всего говорит о специфике Hyper-V R2 в этом вопросе.

Лимит по производительности системы хранения FAS3160A для такой конфигурации не был достигнут.

Подробности и полный документ по результатам –тут:
http://www.netapp.com/us/library/technical-reports/tr-3846.html

Компания Demartek, совместно с NetApp провела измерения производительности системы FAS3170, и опубликовала результаты в виде отчета.
Измерялся FCoE и iSCSI по 10G Ethernet.

Не бог весть какое тестирование с точки зрения методологии и всякого хайэнда, но почитать для общего образования может быть интересно.
http://www.netapp.com/us/library/research-papers/rp-unified-networking-evaluation.html

Отметьте, в документе авторы отчего-то называют парметр IOmeter - “# of outstanding IOs” как “queue depth”, кривые на графиках вызваны изменением его значения от 4 до 48 с шагом 4, для каждого из измерямых размеров блока.

На днях EMC выкатило на тесты SPECmark (тесты производительности NAS enterprise-уровня), впервые с 2007 года, свой “суперболид” на базе симметрикса и “всех порвала!!!11″.
Впрочем, как выяснилось довольно скоро, не то чтобы совсем порвала, а так, понадрывала по краю ;)
По этому поводу блоггеры NetApp вовсю ехидничают.
Судите сами:
EMC Symmetrix V-MAX, 4x V-engines, 264GB cache total
96 штук 400GB EFD flash drives (это EMC-шные SSD) в двух RAID-1
3 штуки (2 active + 1 passive) Celerra NS-G8 Datamovers в качестве NAS Gateway, 8GB cache в каждой.
24-портовый коммутатор FC, чтобы всю эту кухню пересоединять между собой
Наддув, впрыскивание закиси азота, ксеноновые фары и брызговики Sparco.

И все это счастье сисадмина, стоимостью не менее чем 6 миллионов долларов в ценах американского лиспрайса набирает аж 110621 спекмарковских попугаев по SPECsfs2008 в NFS (и 118463 в CIFS, которые никто почти и не меряет из участников).

Круто типа.
Но при этом еще в прошлом году NetApp публиковал результаты FAS6080, с ценой проекта едва ли вполовину EMC-шной, на обычных дисках (не SSD), и даже без Performance Accelerator, показавшей 120011 спекмарковских попугаев.
А результат в районе 60 тысяч, то есть вполовину EMC-шного “устройства для завоевания превосходства в датацентре” показывает довольно таки средненькая midrange FAS3160, причем при использовании PAM делает она это на всего лишь 96 дисках SATA (!)

Я уж не говорю, что по абсолютной величине их обгоняет, например система производства Huawei Symantec ;)

Материалы по теме:
Все опубликованные результаты SPECsfs2008
Ник Триантос: “Как потратить побольше, а получить поменьше”
Вон Стюарт: “Бенчмаркинг-жульничество*”
* “Жульничество”(Shenanigans) - один из любимых терминов Чака Холлиса, блоггера EMC, обычно в отношении NetApp.
Комменты к обоим вышеприведенным постам не только доставляют, но и служат интересными источниками подробностей, рекомендую.

В блогах MSDN найден любопытный документ тестирования iSCSI на 10G Ethernet, с использованием MS Windows Server 2008, Hyper-V, и системы хранения NetApp FAS3070.
Даже несмотря на то, что использовался довольно старенький сторадж (3070 это топовая модель предыдущей midrange-линейки, в настоящий момент уже не выпускаемая, вся серия 3000 уже целиком заменена на 3100), и чисто “софтверный” iSCSI, результаты могут показаться любопытными тем, кто еще раздумывает “А насколько быстр на самом деле этот непонятный iSCSI?”

http://download.microsoft.com/download/F/B/3/FB38CA2C-6694-4D25-8452-4A28668A87F2/MSFT-NetApp-10G.docx

Следует отметить, что карты 10G Ethernet, например рассматриваемая в этом тестировании двупортовая Intel 10 Gigabit AF DA dual port Server Adapter по ценам Price.ru стоит ~770$, а вообще 10G адаптеры начинаются уже от 500$.

В одном из постов, опубликованных ранее, посвященному “мнимой дешвизне” дисков SATA, и проблемами при построении системы хранения заданной производительности в IOPS, меня спрашивали об источниках приведенных показателей IOPS отдельных дисков в зависимости от их типа.

Нашлась вот такая картинка, с графиками тестирования различных типов дисков.

Часто приходится отвечать на вопрос: "Насколько использование дедупликации снижает производительность системы хранения NetApp?"

Официальное мнение, подтверждаемое отчетами пользователей: "Снижение производительности либо практически не заметно, либо находится в пределах 5-7% , в зависимости от нагрузки и характера доступа к системе"

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

Простой пример. Вы используете систему хранения FAS3140, с размером кэш-памяти на контроллере в 8GB (на два контроллера - 16GB, по 8 на каждом), для хранения множества однотипных виртуальных машин.
Не секрет, что системные разделы виртуальных машин Windows, в том случае если вы, как оно обычно и бывает, используете одну и ту же версию OS и сервиспаков, отличаются между собой очень незначительно. Допустим, что 90% всего содержимого OS, установленного на раздел виртуального диска, размером 4GB, идентичны для всех 20 имеющихся у вас виртуальных машин (данные у них, разумеется, различные, но мы говорим сейчас только о системных разделах).
Легко видеть, что, в этом случае, после проведения дедупликации, на разделе, ранее занятом на 4GB*20=80GB высвободится 90%  места, и все данные поместятся в 11,6GB (4GB + (0,4GB*19)).

Такой результат означает, что практически все содержимое наших системных разделов виртуальных машин поместится в кэш системы хранения (16GB), что в разы поднимет ее результирующее быстродействие после проведения дедупликации.

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

Вопрос: Почему вы считаете, что кэш в данном случае не сможет точно также эффективно  закэшировать одинаковые блоки, даже если они лежат в разных местах?

Ответ: Потому что кэш не знает ничего о содержимом блоков, он знает только о расположении его. Кэш помещает в себя "блок номер 12037", "блок номер 34560" и "блок номер 545200". Даже если они полностью идентичны внутри, каждый из трех займет место в кэше, потому что для кэша они разные, они  их видит только “по номеру”.
В случае же дедупликации "виртуальный уровень хранения", при необходимости считать их содержимое, запросит из них только один.
Ситуацию пояснят рисунки:

Кстати следующий подготовленный перевод, который можно будет найти, как всегда, на страничке технической библиотеки российского дистрибутора NetApp, компании Netwell, это большое руководство Best Practices о использовании и настройке дедупликации на системах FAS и V-series . Думаю, что вскоре вы сможете подробно прочитать обо всех аспектах применения дедупликации "от производителя"