about NetApp

В обсуждении хранилок не раз сталкивался с тем, что многие пользователи, знакомые с продукцией других вендоров, пищут: “А что это он так похож на … (IBM Storwise V3700, HP MSA 1020, Dothill 3450, whatever)?”
Недавно, я, кажется, нашел простой и, кстати, похожий на правду ответ.
Дело в том, что нашем мире всеобщей международной интеграции и кооперации уже редко кто производит какой-то продукт целиком, от начала и до конца. Есть специалисты, которые производят некий “конструктор”, например у ноутбуков он называется barebone, он покупается промышленной партией, а затем дополняется выбранным процессором, памятью, контроллерами, и так далее, и выпускается уже под именем сборщика.

Нет смысла заниматься разработкой такого баребона “с нуля”, если компания-специалист, умеющий такие железки проектировать правильно (см недавний пост про вибрации, например), и делающий их хорошо и много, продает их дешевле, чем сможете “на круг” разработать и произвести вы своими силами. Ну вот и замечательно, это позволит снизить еще на несколько тысяч себестоимость полного стораджа, все в плюсе, в результате.
Ваша задача, как разработчика интеллектуального продукта - разработать “мозги”, например контроллер. В железке, которую вы покупаете как barebone для стораджа, есть слот под установку контроллера, в становящемся общепринятым формат-факторе SBB - Storage Bay Bridge.
В итоге, вы получаете barebone конструктив, разрабатываете и производите (или заказываете специализированным компаниям) производство контроллера по вашим спецификациям и чертежам, пишете софт, и получаете недорогой сторадж. А уж что он будет похож на несколько других стораджей, barebone-шасси для которых разработал какой-нибудь всеобщий Xyratex (хорошо известный OEM-бренд в отрасли стораджей), ну так суть-то стораджа не в креплении дисков и блоков питания, а в контроллере и софте.

В этом году на IT-рынке EMEA появился новый, интересный, и крайне зубастый игрок - Nutanix. В двух словах, это вычислительная кластерная платформа, позволяющая строить фермы виртуальных машин без использования SAN-хранилищ, это “сервер-и-сторадж”, интегрированный специальной IT-магией в единый “кирпичик”, из множества которых можно строить кластеры VM, легко масштабируемые.
Так уж получилось, что активное продвижение Nutanix на российском рынке постоянно сталкивает его с системами NetApp, и кастомеры довольно часто задают такой вопрос “А если слон на кита залезет, то кто кого сборет?” “Победит ли Nutanix NetApp, или наоборот?”

Поэтому вопрос, заданный в заголовке, имеет ответ, что они, конечно, конкуренты, но лишь на определенном участке рынка, таким образом, можно представить пересечение множества задач обоих вендоров в виде классической диаграммы окружностей пересечения множеств (для политкорректности я намеренно показываю размер окружностей равным ;)

Да, есть области у Nutanix и у NetApp, в которых они встречаются на рынке. Но и у того и у другого продукта область применения куда шире, чем то, чем они пересекаются. Вот почему я считаю, что Nutanix и NetApp - не являются взаимно конкурирующими продуктами, я уверен, что на рынке есть место как для одного, так и для другого. В этом блоге мы рассмотрим вопрос, почему Nutanix - не конкурент NetApp.

1. Nutanix - это решение для виртуализованных сред. Область применения NetApp гораздо шире. Nutanix - передовая платформа крутить гипервизор виртуализации, это, если угодно, server-oriented система. Это сервер, с некоторыми функциями хранилища, интегрированными в него. NetApp - это, наоборот, “хранилище-ориентированная” система, это сторадж, в который интегрированы некоторые функции сервера (NAS, репликация). Эти две системы идут “навстречу”, и вот, на каком-то нейтральном для них обоих поле, они встретились и пересеклись.
На этом (и только на нем) можно говорить о конкуренции.

2. Передовые технические решения это здорово. Но иногда хочется оставаться в рамках классических архитектур. Например, когда переход на новую архитектуру несет с собой существенные риски и затраты на полную переделку уже существующей, работающей и приносящей деньги системы. Которую обслуживают люди, с определенным уровнем квалификации, в которую вложены деньги через их обучение. Которая обвязана разнообразными работающими “3rd party” продуктами, такими как инструменты мониторинга, алертинга, оптимизации, аналитики. ?? которые просто с точки зрения защиты инвестиций нельзя просто взять и выкинуть (и купить новые).

3. Линейное масштабирование, о котором часто говорит Nutanix, работает только для определенного ряда задач. Это фермы веб-сервисов, это VDI-среды, это некоторые NoSQL и BigData приложения. Это там, где сама задача позволяет выполнять обработку своих данных параллельно. Это, однако, не работает для “классических” SQL-баз и ряда традиционных архитектур. А это, читай, биллинги, ERP, legacy-системы, и все такое прочее. Перенос с переписыванием таких приложений под масштабируемую архитектуру съест всю гипотетическую экономию и поэтому экономически бессмысленнен.
Если ваша задача не масштабируется и не параллелится на кластер нодов и мощность одного нода для нее недостаточна, то никаких способов увеличить производительность этой задачи, крутя ее на Nutanix, у вас нет. В наше время это не слишком частая ситуация, тем не менее это все еще встречается.

4. Существует ряд задач, связанных с чистым хранением (а не хранением ?? обработкой) больших объемов данных. Если вам нужно хранить массив данных в несколько сотен терабайт, причем в основном только хранить, то хранить его на вычислительных нодах, тем более таких недешевых и производительных, как старшие Nutanix (NX-6000) - это оверкилл.

5. NetApp, во многих случаях, выбирают ради его многочисленных сервисов хранения данных (FlexClone, SnapLock, компрессия и дедупликация данных), их защиты, интегрированных в приложения (SnapManager, SnapProtect, SnapCreator) и репликации (SnapMirror, Metrocluster). Nutanix пока такими возможностями не обладает.

6. Если ваша задача может быть уложена в, порой прокрустово, ложе серверной виртуализации - отлично. Если нет - Nutanix с этим не работает. К сожалению, до сих пор многие важные для отрасли производители софта крайне настороженно относятся к попыткам кастомеров переносить их системы с физических платформ в виртуальные машины, и, часто, не поддерживают штатным образом такие конфигурации (пример - Oracle, а значит, сразу, любые системы, его использующие).

Ну и остановимся пока.
Таким образом, как вы видите, Nutanix конкурирует не с NetApp как таковым. Он конкурирует, возможно, с NetApp/Cisco FlexPod. Но FlexPod - это совсем не весь NetApp, это лишь отдельный прикладной продукт для определенного рынка, использующий систему хранения NetApp как свой компонент.

Можно сказать даже более, в каком-то смысле ?? Nutanix, ?? NetApp местами даже играют вместе, в одной команде. Одной из ключевых тем push message у Nutanix есть тезис об устарелости и неэффективности SAN и использования LUN, шире - тупого “блочного доступа”, прежде всего для виртуализованных сред.
Но так ведь и NetApp продвигает эту идею ни больше, ни меньше как с 1993 года! Да, NetApp умеет SAN вместе с NAS c 2004 года, в рамках концепции Unified Storage, и умеет крайне неплохо, но тем не менее, с самого начала своего сотрудничества с VMware он всюду твердит, что SAN LUN это вынужденный метод для размещения датасторов виртуальных машин, что VMFS - костыль, красивый, сияющий, хайтек, но - костыль. Что NAS-концепция и NAS-протокол лучше чем что-либо подходит именно для такого применения (параллельного доступа к данным на дисках от разных его потребителей со стороны хоста). “Делаете облачный сторадж - выкиньте LUN-ы!” - пишет в своей колонке в Computerworld Джон Мартин, директор SNIA ANZ и главный специалист по технологиям в австралийском NetApp. ?? все это как нельзя лучше поддерживает и перекликается с тем, что говорит по этому поводу Nutanix.

Следящие за новостями IT в мире не могли пройти мимо нового баззворда, стремительно катящегося сейчас по англоязычным источникам - Big Data.

Согласно определению Википедии: “Big Data - это серия подходов, инструментов и методов обработки структурированных и неструктурированных данных огромных объёмов и значительного многообразия, для получения человеко-читаемых результатов, эффективных в условиях непрерывного прироста, распределения по многочисленным узлам вычислительной сети, альтернативных традиционным системам управления базами данных и решениями класса Business Intelligence. В данную серию включают средства массово-параллельной обработки неопределённо структурированных данных, прежде всего, решениями категории NoSQL, алгоритмами MapReduce, программными каркасами и библиотеками проекта Hadoop.” Сам же по себе термин “Big Data” (”Большие Данные”) родился в статье 2008 года в журнале Nature, и образован по аналогии с понятиями “Большая Нефть”, или “Большие Деньги”, символизирующие переход количества (объемов, скоростей обработки) данных в их некое новое качество.

Таким образом, в первую очередь, Big Data это то, что не помещается в базу данных, и методы работы с такими данными, когда нельзя “написать SQL-запрос” к ним.

В значительной степени, сложность работы с Big Data как раз и определяется сложностью нового подхода, для которого не получается применять эффективно привычные методы. Представьте, каково это, например, работать с несколькими миллионами или даже миллиардами файлов, искать в них, извлекать из них данные, записывать.
Сравнительно недавняя покупка компанией продуктовой линейки Engenio, и ряда программных продуктов стороних разработчиков, будучи слитой воедино, дала значительный толчок для работ в этом направлении. Так, NetApp активно занялся работами в области Hadoop, одного из открытых продуктов Apache Foundation (один из крупнейших клиентов NetApp - компания Yahoo! - как раз давний и активный пользователь и разработчик решений с Hadoop). ??звестны их работы в области высокопроизводительных решений с использованием Lustre (о использующей Lustre системе хранения для суперкомпьютера в Lowrence Livermore National Laboratory я уже писал ранее).

Другим продуктом, активно развиваемым в NetApp в области Big Data, является решение StorageGRID, объектное хранилище данных, позволяющее, используя высокий параллелизм, строить хранилища данных для миллионов и миллиардов файлов, с мультиплатформенным доступом, в сотни петабайтов объемом.
Недавно вышедшая версия StorageGRID 9.0 добавила к уже существующим возможностям доступа по NFS и CIFS и доступ по недавно описанному и стандартизированному в SNIA протоколу Cloud Data Management Interface (CDMI), который позволяет обращаться к объектному хранилищу с помощью HTTP-подобных запросов, создавать, администрировать и доступаться к данным облачного хранилища, с размерами, превышающими общепринятые сегодня.
Хотя на сегодня, уверен, большинству пользователей такие задачи, что решаются объектными стораджами и Big Data, все еще кажутся далеким будущим, многие вещи, казавшиеся далеким будущим еще три-пять лет назад, стали практически повседневностью сегодня, и готовиться вендорам к таким делам приходится заранее, чтобы не оказаться “на обочине” рынка.

В настоящее время интерес к Big Data, к работе с данными в этой парадигме, к используемыми для этого методам, к стораджам, пригодным для хранения таких данных, является одним из самых быстрорастущих в сегодняшнем IT. По исследованию Gartner, в 2011 году рыночный тренд Big Data был только слегка ниже, чем по теме виртуализации.

В связи же с тем, что, по некоторым смутным слухам, NetApp раздумывает о том, чтобы поставлять решения на базе стораджей E-series, в первую очередь под Big Data, и на российский рынок, вполне возможно, что StorageGRID, CDMI, Hadoop и прочие решения найдут свое место и среди российских компаний.

http://dilbert.com/strips/comic/2012-07-29/

Как вы знаете, я убежденный сторонник того, что системы хранения NetApp – это лучший выбор для использования в среде серверной и десктопной вируализации. А для самой этой виртуализации – использование протокола NFS, который для систем NetApp, более чем родной, в свою очередь, лучший способ подключить дисковое хранилище. Со мной согласны уже 36% пользователей систем виртуализации (согласно отчету Forrester за май прошлого года), причем процент использования NFS растет, и уже превысил процент использования iSCSI (23%) на этих задачах.

Я уже не раз писал в этом блоге про различные аспекты использования NFS (посмотрите старые статьи по тегу NFS), и даже переводил на этут тему Best Practices (про Ethernet Storage вообще и про VMware в частности), однако все это были разрозненные публикации “к случаю”. Мне захотелось собрать основные темы вопроса в одном месте, и обсудить их, наконец, “раз и навсегда”, или пока тема не изменилась значительно.

Но для начала несколько вводных слов, для тех, только что подключился к блогу.

NFS (Network File System) – это протокол “сетевой файловой системы” разработанной компанией Sun в глубокой исторически-компьютерной древности, и предназначенный для доступа к данным в файлах по сети, в том числе для совместного доступа к ним от нескольких клиентов. NFS, вследствие своей сравнительной простоты реализации, стал очень популярным в UNIX-мире, где работу по NFS поддерживают практически любые OS. Несмотря на то, что сегодня “файловой системой” обычно принято называть нечто иное, за протоколом доступа к файлам по сети, NFS, исторически закрепилось название “файловая система”.  С момента своего изобретения, NFS прошел большой путь, и на сегодня достиг версии 4.2, обретя множество важных на сегодня возможностей, таких как использование не только UDP, как первоначально в исходной версии протокола, но и TCP (в v3), улучшенные технологии разграничения доступа и безопасности (v4), поддержка распределенных кластерных и объектных хранилищ (v4.1) и различные методы offload-а (v4.2).

К сожалению, за NFS водится два своеобразных недостатка. Во-первых, он так и не появился в OS семейства Windows (если не считать крайне проблемной реализации, вышедшей в составе продуктов MS Services for UNIX) и остался “чужим и непонятным” для win-админов. ?? второе, но более важное, не все его реализации “одинаково полезны”. Многие пользователи, познакомившиеся с NFS через имеющую кучу проблем с производительностью и стабильностью, широкораспространенной реализацией в Vanilla Linux, считают, что “весь NFS такой, глючный, тормозной, для продакшна не пригодный”. А это не так.

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

А теперь о достоинствах. Во-первых следует отметить сравнительную простоту использования NFS. Его использование не требует внедрения и освоения сложной, особенно для новичка, FC-инфраструктуры, непростых процессов настроек зонинга, или разбирательства с iSCSI. ??спользовать NFS для доступа к датастору также просто и тем, что гранулярность хранения при этом равна файлу VMDK, а не целиком датастору, как в случае блочных протоколов. Датастор NFS это обычная монтируемая на хост сетевая “шара” с файлами дисков виртуальных машин и их конфигами. Это, в свою очередь, облегчает, например, резервное копирование и восстановление, так как единицей копирования и восстановления является простой файл, отдельный виртуальный диск отдельной виртуальной машины. Нельзя сбрасывать со счетов и то, что при использовании NFS вы “автоматически” получаете thin provisioning, а дедупликация высвобождает вам пространство непосредственно на уровень датастора, оно становится доступно непосредственно администратору и пользователям VM, а не на уровень стораджа, как в случае использования LUN-а. Это все также выглядит крайне привлекательно с точки зрения использования виртуальной инфраструктуры.

Наконец, используя датастор по NFS, вы не ограничены лимитом в 2TB, даже с VMFS ранее 5, а это очень полезно, например, если вам приходится администрировать большое количество сравнительно слабонагруженных вводом-выводом машин. ??х всех можно поместить на один большой датастор, бэкапить, и управлять которым гораздо проще, чем десятком разрозненных VMFS LUN-ов по 2TB(-512bytes) каждый.

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

Однако, какие у нас имеются минусы?

Ну, во-первых, это невозможность использовать RDM (Raw-device mapping), который может понадобиться, например, для реализации кластера MS Cluster Service, если вы его хотите использовать. С NFS нельзя загрузиться (по крайней мере простым и обычным способом, типа boot-from-SAN). ??спользование NFS сопряжено с некоторым увеличением нагрузки на сторадж, так как ряд операций, которые, в случае блочного SAN, реализуются на стороне хоста, в случае NFS поддерживатся стораджем. Это всяческие блокировки, разграничение доступа, и так далее. Однако, практика показывает, что оверхед отражается на производительности крайне незначительно.

Большим плюсом использования NFS на стораджах NetApp является то, что выбор NFS там не диктует вам “жесткого выбора” для вашей инфраструктуры в целом. Если вам понадобится также и блочный протокол для RDM, или для крайне критичной даже к возможному 10-15% падению производительности виртуальной машины, вы можете использовать для нее iSCSI или даже FCP, все на том же сторадже, параллельно с NFS, и всеми его плюсами, для основного датастора.

В следующем посте этой серии мы перейдемь к разбирательству основных недопониманий и мифов, которые имеются вокруг использования NFS в VMware.

Рекомендуется также почитать по теме:

• VMware: Best Practices for running VMware vSphere on Network Attached Storage
• NetApp (RU): Руководство по наилучшим способам использования систем NetApp
  с VMware vSphere
• NetApp (RU): ??спользование NFS в VMware
• NetApp (RU): Ethernet для систем хранения: наилучшие методы
• NetApp (EN): tr-3880 CLI Configuration Processes for NetApp and VMware vSphere.pdf
• NetApp (EN): tr-3697 Multiprotocol Performance Test of VMware ESX 3.5 on NetApp
• NetApp (EN): tr-3808 VMware vSphere 4.1 and ESX 3.5 Multiprotocol Performance Comparison Using FC iSCSI and NFS

В нескольких дискуссия заметил, что новые пользователи NetApp плохо и нетвердо представляют себе что такое есть такая структура организации дисковой иерархии в системах хранения NetApp, как QTree.

Q: Что такое этот QTree?

A: QTree (Quota Tree) это элемент структурной иерархии дисковых ресурсов на NetApp. По-простому, “по-крестьянски”, QTree это такая поддиректория-папка, находящаяся на томе-volume. Вы можете “зашарить” корень созданного тома, и хранить ваш файлы прямо в этом корне, или же создать в этом корне один или несколько QTree-поддиректориев, “шарить” как сетевой ресурс уже их, и хранить данные в них. Пример такой структуры: /vol/vol1/homedir и в нем qtree ???/user1’, ???/user2’ и так далее для домашних папок пользователей.

Q: Зачем он нужен?

A: Qtree это структурный элемент, на который можно назначить так называемые Quotas, то есть лимиты для пользователя или группы пользователей по объему занятого ими дискового пространства на системе хранения. Непосредственно на корень тома назначить квоты пользователям нельзя, а вот на qtree на этом томе – можно.

Q: Можно ли обойтись без него?

A: Нельзя сказать, что без QTree не прожить, сегодня это скорее некая дополнительная возможность, в первую очередь ориентированная на NAS-применение, но это хорошая дополнительная возможность, повышающая гибкость использования, к тому же знать что такое qtree, и как с ним работают вам понадобится, если вы надумаете сдавать сертификацию NCDA (NS0-154), в экзамене есть заметное количество вопросов, требующих этого понимания.

Q: Что это за возможности?

A: Кроме уже указанного квотирования места на пользователей, Qtree используется также для операций репликации SnapMirror, это так называемый режим QTree SnapMirror, в отличие от режима Volume SnapMirror. Отличаются эти режимы тем, что репликация Volume SnapMirror работает на уровне тома, и реплицирует том, именно как том, целиком, то QTree SnapMirror реплицирует данные на файловом уровне, “пофайлово”. Оба варианта имеют свои плюсы и минусы, достоинства и недостатки, и хорошо дополняют друг друга, полезно вам будет разобраться в их особенностях, если вы планируете использовать SnapMirror в своем решении.

Ранее я уже писал о том, что такое Multi-Path High Availability (MPHA) – методе подключения дисковых полок к контроллеру, сделав перевод официального FAQ. Однако обещал, что чуть позже напишу еще некоторые мои соображения на этот счет. Вот они.

Кратко, для “введения в суть”: MPHA это, на сегодня, настоятельно рекомендованный способ избыточного и отказоустойчивого подключения дисковых полок к контроллерам на системе хранения NetApp. Суть его состоит в том, что каждый “стек” полок подключается не просто парой избыточных кабелей в два порта каждого стека полок, но четырьмя кабелями, одной парой с одного конца стека, а второй – с противоположного конца, задействуя не два, а четыре инициатор-порта на каждом из кластерной пары контроллеров (поясняющие схемы можно посмотреть в статье по ссылке выше). ??того, на два контроллера, работающих с двумя стеками полок, получается восемь портов и восемь путей к дискам (с одним стеком, соответственно, четыре).

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

Проблема тут возникает для систем “малого класса”, а именно для FAS2040, у которой всего два порта SAS на систему (один на контроллер), и FAS3210, которая, как вы помните, имеет два порта SAS в контроллере и всего два слота расширения (и нет возможности поставить блок расширения портов IOXM, который есть только для 3240/3270).

FAS2040 совсем не может использовать “классический” рекомендованный вариант MPHA, а FAS3210 может его использовать только в варианте с дополнительной платой интерфейсов SAS, которая занимает один из двух слотов расширения.

(исправлено 30.09 romx, Теперь эта проблема в конфигураторе с неотключаемым для 3200 MPHA изменена)

Таким образом у покупателя FAS3210, например, есть выбор поставить в оставшийся слот плату Flash Cache ??Л??, например, 10Gb Ethernet, но НЕ одновременно.
Проблема заключается в том, что, если ранее, MPHA в конфигураторе была отключаемой опцией, и можно было снять эту галку в чекбоксе, и при этом освобождался искомый слот, то теперь, увы, MPHA это обязательная опция конфигурирования, и, следовательно, в один слот из двух у 3210 в обязательном порядке будет поставлена карта SAS-портов, оставляя доступной пользователю и его выбору только один слот.
??менно этим объясняется отказ пресейла партнера NetApp отключить MPHA и сделать вам, допустим, FAS3210 с Flash Cache и 10Gb Ethernet одновеменно. Ему просто не дает это сделать конфигуратор.

Однако вариант подключения без MPHA, хотя MPHA и настоятельно рекомендуемый, навязываемый конфигуратором и “обязательный”, как о нем пишет переведенный ранее FAQ, все же работает, поддерживается NetApp, и, более того, именно такой вариант сконфигурирован, например, в конфигурации FlexPod (что можно посмотреть в опубликованной спецификации на FlexPod), где используется как раз 3210, как раз с Flash Cache ?? двухпортовой 10Gb Ethernet Unified Target card в одном контроллере (и без MPHA полок, соответственно).

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

Несколько A на различные Frequently Q:

Q: Означает ли, что отказавшись от MPHA мы получим не-multipath или не-high available подключение полок, а, следовательно, “единую точку отказа” и прочие корпоративные IT-ужасы?

A: Нет, не означает. Не-MPHA подключение также и отказоустойчивое и многопутевое, просто в некоторых специальных случаях сбоев для продолжения доступа к данным при подключении не-MPHA может потребоваться cluster failover, а MPHA сможет работать по дополнительному оставшемуся пути, не проводя cluster failover, и, тем самым, экономя время и не обрывая CIFS-сессии, например. Для небольших систем хранения, например на всего одну-четыре полки на систему, случаи такого вида сравнительно малораспространены. Стоит ли жертвовать ради потенциального устранения этих редких случаев одним слотом из двух на 3210 – решать вам.

Q: Обязательно ли использование MPHA?

A: NetApp считает что обязательно (см. FAQ) для тех систем, где MPHA может быть реализован (исключение, таким образом, только для 2040). Но варианты без MPHA по прежнему поддерживаются. Решение, как я понимаю, за пользователем.

Q: Как же нам все же получить FAS3210 с Flash Cache и 10G Ethernet?

A: Проблема с конфигуратором существовала, но сейчас ее нет. Сейчас в штатном режиме можно получить от партнера спецификацию 3210 с двумя любыми картами внутри, без MPHA. (исправлено 30.09 romx.)
Попросите сконфигурировать вам FAS3210 с Flash Cache и закажите в том же заказе дополнительно плату 10G Ethernet, которая придет отдельно, не установленная в контроллер. Далее вы сможете самостоятельно вынуть карту портов SAS и поставить на ее место карту 10G Ethernet, далее подключите дисковые полки в обычной, не-MPHA, в “традиционной” отказоустойчивой, двухпутевой конфигурации.

Q: Не даете ли вы в данном случае дурного совета?

A: Даю :) Помните, что вы читаете не официальный блог NetApp, а просто заведомо ложные, порочашие измышления на тему, данный пост написан не сотрудником NetApp, и NetApp не несет ответственности за что либо публикуемое в данном блоге. Вышеприведенный совет не является официальной рекомендацией NetApp. Хотя подключение не-MPHA в настоящее время по прежнему поддерживается в существующих системах хранения, и отказ он MPHA на системе хранения не является причиной отказа в поддержке.

Q: Но, все-таки…

A: См. спецификацию FlexPod, валидированную Cisco и NetApp, с использованием FAS3210 без MPHA, в как раз описываемой конфигурации с Flash Cache и 10G Ethernet.

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

Что на самом деле хочет купить пользователь, пришедший за системой хранения?

• Производительность в random IOPS. Это, пожалуй, определяющий фактор, который по праву занимает первое место в списке. Производительность – решает. В наше время трехтерабайтных дисков на рынке, емкость, как я уже и писал, зачастую, получается как “побочный эффект” достижения определенного уровня производительности в IOPS. Сперва надо удовлетворить требованию по производительности в random IOPS, читай по количеству физических дисков в системе, а там, глядишь, емкость и так получилась порядочная. Опять же, системы хранения, где емкость является определяющим фактором, когда производительность не важна совсем, это довольно узкая ниша архивных хранилищ. Уверен ли спрашивающий про “терабайты”, что ему совсем не нужна производительность в random IOPS на получившемся? Не дал ли он себя заморочить величинами “паспортной” производительности интерфейса SATA-II или Fibre Channel? Что это за задача, где производительность работы на получившемся сторадже не нужна?
• “Фичи”, возможности использования системы хранения. Современные системы хранения уже давно не просто “банки с байтами”. “Хранение” в них всего лишь одна из множества возможностей. Даже сама пресловутая емкость хранилища может сильно зависеть от того, какие возможности системы хранения пользователем задействуются. Дедупликация, снэпшоты, клоны, unified-концепция хранения, thin provisioning, storage tiering, очень часто эти функциональные возможности, позволяет значительно снизить так называемый data footprint, то есть занимаемый данными объем на хранилище. То, что без использования “фич” заняло бы куда больший объем, с “фичами” поместится в куда меньший. Что уж говорить про многие новые возможности использования хранилища, которые эти фичи дают, и о которых пользователь, покупающий “объем” часто еще просто не задумывался?
• Надежность хранения данных и их защиту. Что толку от производительной и фичастой системы хранения, если она при этом ненадежна, если жить с ней вы будете как на пороховой бочке? RAID-0 это, наверное, очень быстро. Но недолго :) “Жить быстро, умереть молодым” это для рокенрола хорошо. Но вряд ли это хорошо для данных вашей компании. А сегодня уже и RAID-5, судя по всему, уже стоит рассматривать в ряду ненадежных (в отличие от RAID-0, который ненадежный, но, хотя бы, быстрый, RAID-5 при этом еще и не быстрый;). Диски SATA, особенно большого размера, уже просто в обязательном порядке должны предполагать использование их в RAID-6. ?? не забывайте – надежность IT инфраструктуры компании, как и скорость эскадры, которая определяется скоростью самого медленного корабля, определяется надежностью наименее надежного ее компонента. ??ли как говорил один мой знакомый: “Неважно, насколько быстра ваша система хранения, если в данный момент она не работает”. Но надежность и защита данных это не только RAID, часто она не исчерпывается локальными возможностями стораджа. Это может быть и репликация, это и средства резервного копирования и восстановления данных, например снэпшоты уровня стораджа или приложения, и так далее. А как насчет гарантийного сервиса в вашем регионе и его стоимости?
• ??нтеграцию с используемым софтом. Несмотря на то, что “настоящий сисадмин пользуется исключительно консолью” на практике все гораздо сложнее. ?? выбор между тремя ничего не успевающими сисадминами, ежемесячно еще и требующими за свою напряженную работу прибавки зарплаты, и одним, который все успевает, пользуясь удобными инструментами, предоставляемыми вендором системы хранения, может также заметно повлиять на итоговую стоимость решения. ??нтеграция это не просто красивые маркетинговые слова. Поддержка специфических возможностей программного решения, в качестве примера могу привести поддержку VAAI для продуктов VMware, или “аппаратную” поддержку deploy/redeploy виртуальных машин на уровне возможностей стораджа, может напрямую отразиться и на производительности, и, в конечном счете, на цене решения.
• Поддержку и совместимость с используемыми софтовыми решениями. Важный аспект – наличие поддержки использования покупаемой системы хранения со стороны производителя программного решения, присутствия в Hardware Compatibility Lists (HCL), Support Matrix, существования описанных Best Practices применения, и так далее. В противном случае вы рискуете остаться со своими проблемами один на один, и пользоваться “помощью” только различных форумов. Наличие подтвержденной поддержки как со стороны разработчика софта данной модели стораджа, так и со стороны производителя стораджа – данного софта, обычно гарантирует минимальные проблемы на этапе внедрения. Также не забывайте, что supported (поддерживаемое) это не то же самое, что functional (работающее).
• Экономические аспекты. Долгосрочные затраты на эксплуатацию, поддержку, администрирование. Несмотря на то, что TCO (Total Cost of Ownership – “совокупная стоимость владения”) в России традиционно игнорируется, все больше пользователей начинает осмыслять тот факт, что заплатить за покупку – это еще не все затраты на систему хранения. Часто это только самое начало трат. Стораджем надо не только “завладеть”, но и “содержать” его. ??, часто, стоимость содержания (куда входят эксплуатационные расходы, сервис и прочее)бывает для пользователя очень неприятным сюрпризом. Это вам подтвердит любой владелец, например, дорогого и редкого (в вашей местности) автомобиля. Не забывайте также, что в сегодняшних датацентрах примерно половина потребляемого ими электричества, это потребление не связанное напрямую с IT-оборудованием. Это потребление кондиционеров и прочих “инфраструктурных элементов”. Половина! Снижение затрат на электропитание, охлаждение, затрат на инсталляцию, сервис, эксплуатационное обслуживание и warranty, отличающихся у разных вендоров и разных моделей, может отлиться во вполне полновесные доллары экономии.

Покупать систему хранения исходя из единственного аспекта – ее емкости, сегодня также нелепо, как покупать автомобиль в автосалоне, исходя из его максимальной скорости. “Мне нужен автомобиль, который может ехать со скоростью 140 километров в час” говорит покупатель в салоне. Даже если оставить в стороне то, что сегодня любой новый автомобиль может ехать со скоростью 140 километров в час, очевидно, что это не является для покупателя основным критерием покупки (даже если он сам, по непониманию темы, пока еще и не догадывается об этом). ??, разумеется, грамотный пресейл сегодня знает, что когда покупатель говорит, что хочет “сторадж на двадцать терабайт”, на самом деле он хотел сказать совсем не это. Он хотел сказать, что:

“Мы хотим развернуть виртуальную серверную инфраструктуру, ориентировочно на 20 серверов. Задачи переносимых в виртуальную инфраструктуру серверов сегодня это два файловых сервера, почта MS Exchange 2010, сервера баз данных MS SQL Server 2005 для бизнес-задач и девелоперский PostgreSQL, контроллер домена и около десятка разнообразных серверов для веб-разработчиков и тестировщиков. Ожидаемая нагрузка на хранилище по вводу-выводу, на этапе запуска, для текущих наших задач, около 7-15 тысяч IOPS в steady random read/write, при оценочном профиле read/write – 75%/25%. Мы ожидаем, в ближайшие год-два, минимум двукратный рост нагрузки по вводу-выводу и примерно 50-75% рост по емкости. Мы планируем использовать гипервизор VMware vSphere, и, возможно Xen Desktop или VMware View для планируемого VDI на 300 рабочих мест. В следующем году мы хотим также развернуть резервный датацентр, куда будем реплицировать данные с основного датацентра, для обеспечения отказоустойчивости и непрерывности бизнеса. Достаточные требования по RPO/RTO для наших бизнес-задач 4 часа RPO и 30 минут RTO.”

Но, против воли, у него вырвалось про “20 терабайт”. :)

PS. Вы должно быть заметили, что ни разу в этом посте я не сказал слово “NetApp”? :)

Прошло 3 месяца с момента объявления о покупке NetApp-ом у LSI его подразделения про разработке и продаже внешних дисковых систем, которое было известно под именем Engenio (ESG).

Я не собирался к этой теме возвращаться (по крайней мере часто), как и вообще к теме FC-систем "традиционной архитектуры", которые приобрела, вместе с Engenio, NetApp, так как, в целом, лично мне, они не очень интересны.

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

Что именно купил NetApp?

NetApp приобрел у компании LSI ее подразделение, занимавшееся разработкой, производством и продажей OEM-партнерам дисковых систем хранения "традиционной" архитектуры блочных FC-систем.

Подразделение носило название Engenio, и, в основном, было известно как OEM-поставщик. Напрямую Engenio эти системы, как я знаю, не продавало, однако являлось (и является), по всей видимости, крупнейшим OEM-производителем в этой области. Engenio производила и поставляла своим партнерам, для их продажи такие популярные и широкораспрстраненные системы, которые рынок знал, как IBM DS35xx, DS4700 и 4800, DS5xxx, Sun StorEdge 35xx и 6xxx, а также ряд систем Dell, SGI и Teradata.

Что НЕ купил NetApp?

Сама компания LSI, материнская, по отношению к своему дочернему подразделению Engenio, продолжает работать как и раньше. Все, что разрабатывала и производила сама LSI продолжает разрабатывать и производить она сама. Это: серверные RAID-контроллеры, прошивки для них, HBA, а также линейка продуктов ONStor. Все это НЕ было приобретено с Engenio, также как не была приобретена сама LSI. Компания LSI и относящиеся к ней продукты продолжают свое существование.

Что еще было приобретено, вместе с Engenio?

Вместе с Engenio были “приобретены” отношения Engenio с ее OEM-партнерами, например IBM, Oracle, и так далее.

Какие системы входят в линейку NetApp E-series?

Это E2600, E5400 и E7900.

Кто и как теперь будет разрабатывать и производить системы хранения Engenio?

??х по прежнему будет разрабатывать и производить команда, ранее работавшая как Engenio, и теперь вошедшая в состав NetApp.

Кто и как теперь будет продавать системы Engenio?

Несмотря на то, что системы Engenio теперь называются NetApp E-series, напрямую, через каналы NetApp и его партнеров, они продаваться не будут. Они будут продаваться через прежние каналы Engenio и его OEM-партнеров, а также через нескольких специализрованных VAR-реселлеров в США (только), которые будут продавать "коробочное решение" для Full-motion Video в US Public Sector.

Как это отразится на OEM-отношениях NetApp и бывшей Engenio с их партнерами?

Пока это не отразится никак. Все ранее заключенные соглашения о OEM продолжают действовать. Не в последнюю очередь (если не в первую) вместе с Engenio NetApp покупала и крупнейшее по объемам в отрасли портфолио OEM-контрактов.

Как это отразится на нынешних OEM-отношениях NetApp, например с IBM или Fujitsu?

Никак не отразится. Все нынешние отношения с партнерами и OEM, как NetApp, так и Engenio останутся и напрямую они не пересекаются.

Зачем это все?

Ну, во-первых, за 480 миллионов был куплен рынок, объемом 750 миллионов в год (2010). Что, по нынешним временам, само по себе неплохо.

Во-вторых, вместе с Engenio была приобретена большая, лояльная и объемная сеть OEM-отношений, которых у NetApp ранее почти не было (если не считать отношений с IBM).

В третьих, NetApp получила продукт, ориентированный на растущий нишевой рынок, в котором NetApp ранее не играл и имеющиеся у него системы туда плохо подходили (об этом подробнее ниже).

Что это за нишевой рынок?

Это рынок для "неинтеллектуальных" систем хранения традиционной блочной FC-архитектуры, для задач, требовательных по bandwidth (полосе пропускания).

Это сравнительно небольшой сегмент (по оценке NetApp это 5 миллиардов долларов к 2014 году, сравните с 47 миллиардами для unified systems самого NetApp, спрогнозированных на тот же 2014).

Пример таких систем - хранилища с большим bandwidth (полосой пропускания) для записи данных Full-motion Video, спутниковых потоковых данных, геосейсмики, науки, а также для специфических задач, например для использования в хранилище под проекты архитектуры Hadoop (о Hadoop – позже).

Еще раз напомню, что NetApp E-series не будет продаваться в традиционном канале продаж NetApp, и не будет конкурировать с привычными NetApp FAS, эти системы покупаются для расширения предложения в узком, ранее неохваченном сегменте рынка, под узкий круг заказчиков систем такого рода (причем, как я подозреваю, под уже существующего конкретного крупного госзаказчика из трех букв, уж больно много подробностей об этом решении), с которыми будут работать традиционные OEM-партнеры Engenio.

Означает ли это отказ от развития и продвижения FAS и Unified-архитектуры?

Нет, не означает. Просто предложение расширяется в те сегменты рынка, где нынешние возможности систем NetApp избыточны, и экономически неоправданны.

Означает ли это признание неудачи в развитии Unified Architecture?

Нет, не означает. Приобретенная линейка E-series ориентирована на специализированный рынок с узким набором специфических требований. Для прежних сегментов рынка по прежнему будет развиваться и продвигаться unified архитектура и системы с ее использованием.

В чем преимущества существующих систем unified-архитектуры, NetApp FAS?

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

Основное направление развития систем NetApp FAS – увеличения возможностей по управлению данными и переход к виртуализированному “облачному” хранению.

В чем преимущества существующих систем "классической" архитектуры, NetApp E-series?

Высокая линейная производительность на запись и чтение, сверхбольшая производительность по полосе пропускания и IOPS, высокая плотность “упаковки” хранилища (1,8PB в 40U).

Основное направление развития систем NetApp E-series – увеличение производительности на специальных типах нагрузки и повышение плотности хранения.

Существуют ли планы по слиянию этих платформ?

Нет, таких планов нет. Две платформы будут существовать независимо, как, например, существовали в продуктовом portfolio NetApp, в свое время, FAS и VTL.

Существуют ли планы по отказу от развития Unified Architecture (FAS)?

Нет, таких планов нет. Системы Unified Architecture (FAS) по прежнему будут развиваться и продвигаться.

Существуют ли планы по закрытию и прекращению развития продуктов Engenio?

Ну а вы бы, купив за 480 миллионов "живыми деньгами" успешный бизнес, принесший в прошедшем году около 750 миллионов, стали бы его убивать ради удовлетворения каких-то своих амбиций? Нонсенс.

Означает ли возникновение в продуктовой линейке решений на базе E-series отказ от систем NetApp C-mode?

Нет, не означает, они нацелены на разные рынки, как и FAS 7-mode.

Ожидаются ли изменения в поддержке продуктов LSI/Engenio в системах NetApp V-series?

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

Существую ли планы по переносу Data ONTAP/WAFL на системы E-series?

Нет, таких планов нет.

Есть ли планы использовать аппаратные RAID LSI в системах NetApp?

Нет, таких планов нет.

С какими системами будет конкурировать новое решение NetApp для Full-motion Video? EMC? HP?

На самом деле нет. Это конкурент для систем Data Direct Network (если вы такого производителя знаете), а также, отчасти, для BlueArc и Isilon. Это, повторюсь, нишевое специализированное решение, традиционные системы EMC или HP для него не подходят также, как не подходит NetApp FAS.

Что там за возня с Hadoop, и что это вообще такое?

Скоро расскажу. :)

Что я еще не знаю интересного об этой сделке? ;)

Нынешний CEO NetApp, Tom Georgens, до прихода в NetApp был руководителем Engenio.

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

Лучше то, что лучше работает на ваших данных и ваших задачах.

Обратите внимание, что использование дедупликации или компрессии не исключает одно другого. Вы вполне можете использовать ?? дедупликацию ?? компрессию на одном и то же томе. ??ли же выбрать что-то одно. Зависит от вашей задачи и характера даных.

Вот какой рисунок приводит NetApp по поводу эффективности дедупликации и компрессии в одном из своих документов (выше – лучше):

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

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

Несколько слов о недавно засветившейся в новостях “новинке”, под названием Data ONTAP-v, которая появилась в blade-системах компании Fujitsu. 
Fujitsu Computer Systems является многолетним ресселлером, а также технологическим партнером NetApp (напомню, что NetApp продает “от себя” их систему дискового резервного копирования ETERNUS CS800).

Как я уже писал ранее, NetApp имеет очень интересный “внутренний”, но доступный для клиентов и партнеров продукт – симулятор, представляюшй из себя код Data ONTAP, исполняемый в среде Linux, и реализующий значительную часть функциональности Data ONTAP, за небольшим исключением возможностей, таких как работа по FC (но есть все Ehernet-протоколы,такие как iSCSI, NFS и CIFS), а также с некторыми ограничениями на поддерживаемый объем. В качестве дисков на эмуляторе использованы “витуальные диски” в виде файлов, лежаших на файловой системе Linux. Такая схема, конечно, не позволяет достичь значительной производительности, но от эмулятора это и не нужно.

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

Однако, что получится, если вместо “виртуальных дисков” использовать реальные физические диски? Проэкспериментировала в этом направлении компания Fujitsu для компонентов своей blade-системы PRIMERGY BX400, ориентированной на SMB-решения (ну, не надо хмыкать, в мире под SMB традиционо понимается значительно более мощный бизнес, чем российский “малый бизнес”, таковыми считаются компании “менее 500 сотрудников”). сделав из эмулятора любопытное решение – virtual appliance, работающий в среде EX 4.1 код Data ONTAP 8.0.1 и находящийся внутри их модулей хранения – storage blades модели SX960.

Как я уже сказал выше, так как система BX400 ориентирована, прежде всего на SMB, то не стоит от этого решения ждать сверхпроизводительности, задача его другая. ??спользование VSA (Virtual Storage Apliance) на базе Data ONTAP, позволяет недорого реализовать простоту управления и богатую функциональность, характерную для продукции NetApp, и которая особенно ценится в SMB, где, увы, после неудачи со Storvault, NetApp практическ не играла.

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