about 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

Специально свое мнение вынесу из комментов, так как читают меня в основном из RSS, и в комменты мало кто ходит.

Я не считаю, что Fibre Channel это плохо. FC это замечательная технология. Но любая технология лучше всего работает на своем месте, там, где она нужнее, там, где ее преимущества наиболее проявляются.

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

В прошлом своем посте я не столько пытался “опустить” FC, сколько донести мысль, что когда клиент покупает на “последние деньги” какой-нибудь Xyratex или Infortrend (все совпадения с реальным торговыми марками случайны;), при этом наполняет его дисками c “митина”, потому что “нет денег на родные”, но при этом собирается половину, а то и две трети цены массива потратить просто на “провод” для подключения, то это, мне кажется, крайний случай несбалансированности.

Приводя аналогии из полюбившегося автопрома: человек покупает какую-нибудь вазовскую “классику”, возить тещу и помидорную рассаду на дачу. Ну что, вполне себе задача, практическая. Не гонки Формулы, но не всем же, в конце концов, нужна Формула? Вот такая наша жизнь, в ней тоже надо ездить на дачу.
И вот, вместо покупки, например, более новой и безопасной машины, или вместо того, чтобы потратить деньги, например, на перебор двигателя, юстировку колес и промывку карбюратора-инжектора, покупатель тратит деньги, выкроенные из семейного бюджета на дачный автомобиль, на установку в “классику” ксеноновых фар, гоночных “ковшей”-сидений из красной кожи, низкопрофильной резины и брызговиков Sparco, на остатки.

По моему мнению, FC в entry (да зачастую и не только entry) level это типичный пример гаражного тюнинга и “синих писалок” в IT. Это эффектно, но, как и дырки в глушителе, выдающие мощный рев на светофоре, нисколько не помогают с него уехать быстрее.

Наверняка многие слышали за последний год-два о новом направлении развития протокола FC, по замыслу Cisco (и, отчасти Brocade) его транспортом станет “нативный” Ethernet, что неудивительно при таком успехе стремительно дешевеюшего 10G Ethernet. По видимому на сегодня будущее FC в конвергенции транспорта из собственного проперитарного в широкодоступный Ethernet.

И вот, NetApp снова на острие. По сообщению SearchStorage
14 октября объявлено о нативной поддержке FCoE в системах хранения NetApp моделей FAS и V.

Ожидается, что доступные к концу года native FCoE target cards, устанавливаемые в систему хранения, будут стоить сравнимо с нынешними 8GB FC.

Интерес к этой технологии у NetApp не случаен, компания давно и прочно удерживает лидерство среди стремительно набирающих популярность систем хранения протокола iSCSI или (IP-SAN), конвергирующего SAN в транспорт IP обычно over того же Gigabit и 10G Ethernet. Теперь сюда логично прибавится FCoE.

Напомню, что в отличие от iSCSI, использующего транспортные возможности протокола IP, FCoE транспортируется не поверх IP, а уровнем ниже, непосредственно на “канальном” (в терминах ISO/OSI) уровне Ethernet. Это позволяет преодолеть ряд недостатков, присущих iSCSI, передающегося на “сетевом” уровне, инкапсулированного в IP-пакеты, однако получающего свои недостатки, характерные для работы на таком уровне.

Думаю подробный разбор FCoE как такового я напишу чуть позже, тогда станет понятнее место и назначение этого “новичка” в команде протоколов, поддерживаемых NetApp.

Статья “Уменьшение стоимости хранения за счет экономии дискового пространства” о использовании сравнительно новой и все еще пока малоизвестной опции 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.