about NetApp

Уже цитировавшийся в этом блоге специалист по Oracle и блоггер NetApp с ником Neto (ранее из Бразилии, а теперь сотрудник датацентра NetApp в Triangle Park, USA), опубликовал результаты интересного эксперимента, демонстрирующие возможности и производительность NFS на системах хранения NetApp. Ниже перевод его заметки.

Не могу поверить… Еще остались люди, которые не верят в производительность на NFS

Posted by neto on Oct 8, 2011 5:23:41 AM

Многие годы я получаю много вопросов и FUD на тему того, что, якобы, NFS не обеспечивает достаточно  хорошую производительность.

Давайте смотреть.

Linux CentOS 6 с двумя портами 10Gb Ethernet (Jumbo Frames ON)

NFS v3

NetApp Cluster – каждый с одним интерфейсом 10Gb Ethernet (Jumbo Frames ON)

Cisco Nexus Switch

Я создал  4 файла на каждой mountpoint:

Запускаем ORION…

http://www.oracle.com/technetwork/topics/index-089595.html

ORION (Oracle I/O Calibration Tool) это инструмент для тестирования и калибровки показателей производительность ввода-вывода системы хранения, намеченной для использования под базы Oracle. Результаты полезны для понимания возможностей системы хранения по производительности, а таже для поиска проблем, которые могут отражаться на производительности базы Oracle, или же для сайзинга нвой инсталляции. Так как ORION это отдельный инструмент, то для проведения измерений пользователям не требуется создавать и запускать базу Oracle.
ORION генерирует синтетичекую нагрузку ввода-вывода максмально приближенную к работе базы данных Oracle, и использует тот же I/O software stack, что и Oracle. ORION может быть сконфигурирован на генерирование широкого диапазона нагрузки ввода-вывода, включая нагрузки характерные для OLTP и data warehouse.

./orion_linux_x86-64 -run advanced -testname disk1 -num_disks 64 -matrix point -num_small 0 -num_large 1 -size_large 1024 -type seq -num_streamIO 8 -write 0 -simulate raid0 -cache_size 0 -duration 60 &

./orion_linux_x86-64 -run advanced -testname disk2 -num_disks 64 -matrix point -num_small 0 -num_large 1 -size_large 1024 -type seq -num_streamIO 8 -write 0 -simulate raid0 -cache_size 0 -duration 60 &

./orion_linux_x86-64 -run advanced -testname disk3 -num_disks 64 -matrix point -num_small 0 -num_large 1 -size_large 1024 -type seq -num_streamIO 8 -write 0 -simulate raid0 -cache_size 0 -duration 60 &

./orion_linux_x86-64 -run advanced -testname disk4 -num_disks 64 -matrix point -num_small 0 -num_large 1 -size_large 1024 -type seq -num_streamIO 8 -write 0 -simulate raid0 -cache_size 0 -duration 60 &

Копируем скриншоты…

Controller 1

Controller 2

Server

Я полагаю, что 2 гигабайта (БАЙТА!) в секунду, этого должно хватить! Так-то. :-)

NFS это хорошо (на NetApp, конечно же).

Всех благ!

Neto

Интересный отчет опубликовала сегодня тестовая лаборатория NetApp, анализировавшая производительность Oracle 11g на RHEL и системе хранения NetApp.

Для затравки вам картинка:

Полностью читать – там:
Red Hat Enterprise Linux Protocol Performance Comparison with Oracle Database 11g Release 2
http://www.netapp.com/us/library/technical-reports/tr-3932.html

В моем блоге очередной перевод поста в блоге Recoverymonkey (Dimitris Kr.)

Я бы хотел обратить внимание читателей, что то, что публикуется по средам, это переводы. Я стараюсь сохранять манеру и стиль оригинального автора, потому что это – перевод. Лично я могу быть несогласен (или согласен, как получится) с излагаемой позицией, но, так как это не мои собственные тексты, за исключением небольших сокращений, я стараюсь их не править, и переводить в том виде, в котором они были опубликованы их авторами. Если у вас есть возражения по существу написанного, то не нужно писать их в комментариях к этому посту, и вообще к “средовым” переводным постам мне, сюда. Если вы хотите подискутировать с автором – напишите непосредственно ему, я всегда оставляю ссылки на оригинальные публикации. Спасибо за понимание. А теперь – как всегда острая и полемическая статья Recoverymonkey, с очередной шпилькой в адрес EMC VNX.

EMC conclusively proves that VNX bottlenecks NAS performance

Posted on February 24, 2011 by Dimitris

Немного провокативный заголовок, не правда ли?

Позвольте мне объяснить.

EMC опубликовала новые результаты SPEC SFS в рамках своей маркетинговой кампании (которая работает, смотрите чем я занят – я говорю о них).

Если по-простому, то EMC получила почти 500 тысяч SPEC SFS NFS IOPS (уточню последнее, чтобы не спутать с “блочными” IOPS в SPC-1) на следующей конфигурации:

• Четыре (4) полностью независимых массивах VNX, каждый на дисках SSD (всего 8 контроллеров, так как каждый массив имеет 2 контроллера).
• Пять (5) Celerra VG8 NAS heads/gateways (1 как spare), по одному поверх каждого VNX
• Две (2) Control Station
• Восемь (8) экспортов  файловых систем (по две на каждую голову VG8/VNX)
• Несколько пулов хранения (по крайней мере один на каждую VG8) – без совместного доступа, например с других контроллеров, без переноса данных с других контроллеров.
• Всего 60TB пространства NAS под RAID5 (или по 15TB с каждого массива)

Этот пост не о том, что приведенная конфигурация нереальная и дорогая (никто не заплатит 6 миллионов долларов за 60TB в NAS). Как я понял, EMC старается опубликовать наилучший результат теста путем объединения в кучу нескольких отдельных массивов с SSD. Это в принципе нормально, если понимать детали.

Претензии мои тут в том, как это подается.

EMC говорит о тестируемой конфигурации очень расплывчато (за деталями приходится идти непосредственно на сайт SPEC). В рекламных материалах просто говорится, что EMC VNX показала результат 497623 SPECsfs2008_nfs.v3 операций в секунду. Это что-то типа того, как если бы вы сказали, что нормально пройти четверым первоклассникам на сеанс в кино “до 18”, потому что, дескать, “всем четырем вместе больше 18”.

Нет, более правильно и корректно было бы сказать, что четыре массива VNX, работающих отдельно и независимо друг от друга, показали результат 124405 SPECsfs2008_nfs.v3 IOPS  - каждый.

EMC просто сложила результаты четырех отдельных, независимых устройств вместе!

У NetApp уже есть результат SPEC SFS для FAS6240, где всего два контроллера выдают 190675 SPEC NFS IOPS, в одной системе, настоящем unified, без нагромождения отдельных контроллеров, без использования SSD (на обычных SAS, плюс большой кэш), то есть на реальной, практической конфигурации, которую мы продаем ежедневно, а не на каком-то там лабораторном “звездолете”.

Если сделать также, как поступил EMC, то есть сложить четыре таких системы вместе (в случае NetApp, у нас при этом можно использовать Cluster-mode, с общим файловером между этими четырьмя нодами ), то мы получим следующие результаты:

• 762700 SPEC SFS NFS операций
• 8 экспортируемых файловых систем
• 334TB usable пространства в RAID-DP (в тысячи раз надежнее RAID-5)

Какой вариант, по вашему, более выгодная покупка? Та что более быстрая, 343TB с большей надежностью, или та, что медленнее, 60TB и меньше надежности? ;)

Пользователи других систем также могут легко проделывать такой же трюк с умножением их результатов измерений, вперед!

Если же говорить серьезно, то, что побудило меня так озаглавить пост, это факт того, что тестирование EMC убедительно продемонстрировало, что VNX сам по себе является узким местом. Фактически мы видим, что VNX может обслуживать только одну “голову” VG8 на максимальной для себя скорости, зачем и понадобилось четыре отдельных системы для демонстрации нужного результата. Таким образом, факт того, что VNX может иметь над собой до 8 “голов” Celerra ничего не значит, так как в такой системе back-end это и есть ограничивающий производительность фактор.

Но с одной “головой” NAS вы будете ограничены доступным объемом в 256TB, столько одна голова Celerra может адресовать на момент написания статьи. Впрочем, этого достаточно для обычного пользователя.

Любопытно, а те “головы” NAS, которые продаются вместе с VNX, медленнее, чем VG8, и насколько? Понятно, что большинство пользователей будут использовать те “головы”, что идут в комплекте, так как это обходится дешевле. Как быстро работают они? Уверен, клиенты хотели бы знать как быстро работает именно то, что они, обычно, покупают.

Также очень интересно, как быстро работает RAID6.

А вообще было бы здорово измерять бенчмарки именно того, что пользователь на самом деле покупает, а не абстрактных “болидов Formula 1”!

Как правило, для файлового доступа к системе хранения NetApp с Windows используется протокол CIFS, однако его можно реализовать и через более традиционный для UNIX-сред протокол NFS. Простейший пример зачем: ну например у вас просто нет лицензии CIFS, но есть NFS, и покупать довольно дорогую лицензию ради нескольких Windows-компьютеров вы не хотите, а NFS – уже есть. Или, допустим, ваша задача более подходит под stateless-протокол NFS.

Для поддержки NFS под Windows, Microsoft выпускает бесплатный продукт Services for UNIX (SFU), куда входит и клиент NFS. Рассмотрим как правильно все настроить, в случае использования системы NetApp FAS с лицензией NFS, клиентского компьютера Windows и пакета SFU.

Описание найдено тут, я его просто перевел.

Continue reading ‘Как настроить доступ PCNFS (SFU) на NetApp’ »

“Ethernet storage” принято называть все системы хранения, использующие ethernet для передачи данных. Это могут быть NFS или CIFS NAS, а также iSCSI или FCoE SAN.

Использование Ethernet как среды передачи данных систем хранения становится все популярнее, однако задачи создания “сети хранения данных” с использованием ethernet предъявляют особые требования к стабильности и надежности работы сети. То что “прокатит” для раздачи интернета в офисе может “не прокатить” при создании сети IP-SAN или NFS для критически важных для бизнеса задач.

Если перед вами стоит задача организации такой сети передачи данных, хочу обратит ваше внимание на свежий перевод в библиотеке Netwell: TR-3802 Ethernet Storage Best Practices.

Как организовывать и настраивать транкинг VLAN? Как работает и чем полезен протокол Spanning Tree? Что такое, и как работает VIF – Virtual Interfaces в NetApp? Чем отличаются Single mode и Multi-mode VIF? Static и Dynamic Multimode VIF? Почему объединенные в etherchannel (ethernet-транкинг) порты могут не давать ожидаемой от этого объединения увеличения полосы пропускания? Как работают Jumbo Frames и Flow Control на уровне Ethernet, и как правильно его применять?

Все это в исключительно полезном документе техбиблиотеки NetApp доступном теперь и на русском языке:

TR-3802 Ethernet Storage Best Practices.

PS. Кстати может быть полезен и не только пользователям 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

Я уже не раз в этом блоге расказывал о плюсах и преимуществах развертывания хранилища данных для VMware ESX/VSphere на системе хранения по NFS.
(раз, два, три, четыре)
Это все еще не так широко распространенный среди пользователей вариант решения, как FC или, например, iSCSI, но он завоевывает все большую популярность, так как ряд преимуществ такого варианта безусловно полезны в работе и эксплуатации, а потери производительности по сравнению с FC сравнительно невелики (при значительно большем удобстве и более низкой цене решения).

О таком варианте часто пишут и NetApp и EMC, так как они являются двумя основными производителями NAS-систем c NFS.

Появился и “вендоронейтральный” документ от самой VMware.

Скачать можно тут:
http://vmware.com/files/pdf/VMware_NFS_BestPractices_WP_EN.pdf

Статья “Уменьшение стоимости хранения за счет экономии дискового пространства” о использовании сравнительно новой и все еще пока малоизвестной опции Space Reclamation в SnapDrive.

Статья “Oracle на NFS”, о некоторых аспектах все еще пока не слишком распространенного способа хранения данных баз Oracle на NAS-системе, с использованием NFS.

О плюсах и преимуществах использования дедупликации NetApp в задачах построения катастрофоустойчивых конфигураций на VMware Virtual Infrastructure.

О некоторых аспектах отказоустойчивого использования Exchange 2007 и его встроенных средств репликации LCR и CCR.

Вторая часть серии про работу Oracle на NetApp, на этот раз на FC.

Руководство по правильному выравниванию структур создаваемых виртуальных дисков виртуальных машин в среде VMware, относительно блоков данных систем хранения NetApp.

Руководство Best Practices по развертыванию хранилища MS Exchange 2007 SP1 на системе хранения NetApp.

Статья о том, почему при использовании Oracle на системах NetApp протокол доступа, FC, iSCSI или NFS, на самом деле не важен, и как добиться этого.

Руководство по интеграции средств системы NetApp VTL и ПО NetBackup Vault.

Статья “A-SIS созрела”, о том, как устроена, как работает, и что может вам дать технология дедупликации в системах хранения NetApp.

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

О использовании систем хранения NetApp для резервного копирования Disk-to-Disk, и какие преимущества имеет такая система перед традиционными решениями.

О том, как создавалась FAS3100, какие цели были поставлены, и как удалось создать экономически эффективную систему хранения midrange-класса.

А подписаться на получение новых выпусков можно на странице компании Verysell Distribution.

Любопытные цифры приведены в аналитическом отчете ESG (Enterprise Strategy Group Inc.), опубликованном в начале этого года (доступен на сайте NetApp).

Более половины (54%) из 329 опрошенных ответило, что, после внедрения решеня серверной виртуализации, объемы хранения увеличились (причем ответ “свыше 20%” дали 18% от этого количества).

68% ответивших считают, что FibreChannel есть “технология, предлагающая максимальную производительность” (и всего 22% ответили так для NFS).

Всего 19% считают о NFS, что она “наилучшим образом оптимизирована для задач виртуализации серверов” (против 49% FC и 45% iSCSI)

При этом среди тех, кто уже использует то или иное решение, ситуация обратная.
“Мы уже используем эту технологию и она нас полностью устраивает” 65% назвали NFS, и уже только 53% FC.

Еще несколько деталей о NFS, чаще неспецифических для NetApp, но не менее важных и интересных.

Очереди Ввода-вывода.

Если вы используете в качестве datastore LUN под VMFS, то ввод-вывод вашего ESX, неважно FC или iSCSI, будет ограничен одной очередью ввода-вывода на LUN, для всех VM хранящих свои виртуальные диски в VMFS data store на нем. Ведь ESX обращается к одному единственному LUN, с точки зрения ввода-вывода это одно SCSI-устройство, и параллельность ввода-вывода тут невозможна или очень ограничена.
В случае NFS вы можете использовать произвольное количество очередей ввода-вывода. Каждая VM, хранящая свои виртуальные диски на data store на NFS-шаре, будет иметь индивидуальную и независимую от других очередь ввода-вывода (IO queue).

VMFS LUN. Одна очередь ввода-вывода ко всем VM на data store.

NFS Data Store. Каждая VM имеет собственную очередь ввода-вывода.

Bandwidth Is not a Speed

В значительном количестве случаев при переходе с FC на NFS вы, как ни странно, можете даже выиграть в скорости.
“Как же так?” - наверняка спросите вы, “Ведь всем известно, что скорость FC это 4 GB/s, а NFS в случае 1GB Ethernet работает на 1GB/s, значит NFS просто обязана работать вчетверо медленнее!”
Ответить нетрудно. “Полоса пропускания” (англ. “bandwidth”) не равно “Скорость” (англ. “Speed”). И, к слову, не всегда равно “Производительность” (англ. “Performance”). Смешивать эти понятия будет большой ошибкой.
Я уже писал об этой “смысловой коллизии” раньше, процитирую себя вкратце:

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

Ввод-вывод VMware ESX производится мелким блоками (4-8kb), и при этом предельно рандомно (что неудивительно для системы, хостящей множество независимых процессов множества виртуальных машин). При таком характере ввода-вывода роль играет не bandwith интерфейса, а его латентность и производительность в IOPS. А вот тут уже NFS имеет очень хорошие показатели, за счет чего и выигрывает в этих гонках. Так что, если при переходе с 4Gb/s FC на 1Gb/s NFS вы еще и выиграете в производительности, то не ищите, где же вы ошиблись. Это вполне вероятный поворот дела.

Увеличивать и уменьшать datastore без необходимости ковырять приложения и ESX.

Интересной особенностью использования datastore на NFS-томе NetApp является то, что вы можете не только увеличивать его размер, но, при необходимости и уменьшать, причем и то и другое без какого-либо колдовства с сервером ESX или виртуальными машинами, чтобы они могли это увидеть и использовать.
Если увеличение это частая и в целом довольно обычная процедура, то вот уменьшение для LUN задача не из простых, а порой и вовсе нерешаемая.
Зато для NFS-тома NetApp вы вольны делать изменение в обе стороны.