Archive for Март 2013

NetApp E5500 - новый сторадж для HPC и Bandwidth-related задач

На этой неделе NetApp продолжил расширять свою E-линейку, пока еще не слишком известную на российском рынке (впрочем, наверняка вы некоторые продукты оттуда знаете как OEM, например IBM DS, Dell MDS, некоторые другие, менее известные вендоры, такие как SGI и даже Oracle, также продают системы NetApp E-series под своими марками).

Буквально недавно я уже писал про EF540, а вот уже выпущена и E5500, дисковая система классической архитектуры, ориентированная на HPC (High-Performance Computing), и на задачи extra-high bandwidth. Это, обычно, высокопроизводительные вычислительные кластеры, используемые для научных и нженерных расчетов, под задачи области big data, нефтегаз, сейсмика, геофизика, и прочие такие же специализированные штуки.

image

Основным конкурентом для E5500 в NetApp рассматривают продукты сравнительно малоизвестной в России компании DDN (Data Direct Network), специализированной на перечисленном выше рынке высокопроизводительных, bandwidth-oriented задач, а также столь же “специальный” EMC Isilon.

Отсюда вы уже поняли, как я надеюсь, что это не general purpose сторадж, которыми в линейке NetApp остаются FAS, но если вы работает с вычислительными кластерами, GPFS и Lustre, с big data, с DSS-аналитикой, со всяческими специализированными, скорее научно-инженерными решениями типа геофизики – вот тогда это для вас.

Как вы помните, в прошлом году NetApp активно развивала модели E-series, добавляя в них более привычные для пользователей FASфичи, такие как снэпшоты, thin provisioning, репликацию, и прочее. Всего этого пока, на момент выпуска в марте на E5500 нет, официальный выпуск версии SANtricity для этой модели, с поддержкой всех этих фич, уже доступных для E2600 и E5400, намечен на конец этого года, вероятно еще нужно время на отладку. Однако уже сейчас можно начать использовать с E-series обкатанный на семействе FAS сервис Autosupport.

Не могу также не отметить крайне меня радующий факт, что NetApp, представляя новую модель, очень часто демонстрирует не только маркетинговый булшит общие слова о “крутизне” нового “решения”, но подтверждает их открытыми тестами. В данном случае NetApp опубликовал тест для SGI InfiniteStorage 5600 – это та самая наша E5500, просто продаваемая SGI как OEM-партнером, и ее результаты можно рассматривать как vanilla-E5500. Опубликованы результаты SPC-2. Почему не SPC-1, спросите, возможно, вы? Дело в том, что SPC-2 это high-bandwidth бенчмарк, объемные, но преимущественно последовательные чтения-записи, в то время, как SPC-1 это IOPS-oriented, то есть random чтения-записи. таким образом для general purpose задач, для баз данных OLTP, и прочего, более показательны результаты SPC-1, а для big data, DSS-баз, и прочего, перечисленого выше как рынок E-класса – более показателен SPC-2.

?? результаты там говорят сами за себя:

image

image

Тут конечно нет главных игроков, уже упомянутых DDN и Isilon, которые предпочитают не подтверждать маркетинговые заявления открытыми бенчмарками, но и сравнение с уже опубликованными игроками также весьма показательно, в особенности для понимания, почему general-purpose массивы так посредственны и непропорционально дороги на специализированных применениях Big Data и High-bandwidth.

??з интерфейсов подключения поддерживается, как и в случае EF540, такие варианты, как восемь SAS 6Gbit/s, или же шесть Infiniband 40Gbit/s. Для конфигураций, куда нацелен E5500 это все крайне востребовано. С контроллерами E5500 будут также предлагаться несколько различных типов полок расширения, что позволяет стрить различные конфигурации, например много контроллеров для высокопроизводительного ввода-вывода, или же наоборот, много дисков (например уже знакомые вам 60 дисков NL-SAS в 4U полочные конструктивы) для сверхъемких систем. Поддерживаются и SSD для кэширования, как это уже опробовано на E5400.

Отмечу, что многим будет любопытно узнать, что кодовое название проекта E5500 в NetApp было – Soyuz, в честь знаменитой советской, ныне российской ракеты.

image

Опубликован VSC 4.2 beta

На прошлой неделе в группе 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 – необходимые дополнения

Вчерашний пост про 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 и имеется, использовать ее в реальной жизни, иначе, как  если у вас абсолютносовершенноточноиникакиначе имеется такое требование для ее использования, объективно не стоит.

Striped Volume в Cluster-mode

Как вы уже знаете, архитектура системы хранения NetApp не позволяет, при наличии двух контроллеров, организовать один общий дисковый раздел, доступ к которому имели бы оба контроллера одновременно. Почему так было сделано, отчего, и что это дает полезного – об этом мы уже в блоге говорили, не будем отвлекаться. А сегодня я покажу, как это ограничение может быть снято при использовании Data ONTAP Cluster-mode, новой модели работы со стораджем, которая активно развивается компанией уже не первый год.

В Data ONTAP 8.x Cluster-mode вы можете использовать так называемый режим Striped Volume, при котором доступ к данным на томе может быть осуществлен параллельно с любых контроллеров кластера, в частности с двух контроллеров, составляющих HA-пару.

Для начала надо убедиться, что лицензия Striped Volume введена, что позволяет системе такой том создать.

f3240-sqltest::> license show
(system license show)
Feature Cluster SN Limit Description
————— ———– ——- ———–
Base 1-80-000011 666 Base License w/cluster size limit (nodes)
iSCSI 1-80-000011 666 iSCSI License
Striped_Volume 1-80-000011 666 Striped Volume License
FCP 1-80-000011 666 FCP License
4 entries were displayed.

Раз лицензия есть, то можно создать striped aggregate:

f3240-sqltest::> aggr create -aggregate myAggr -nodes f3240-sqltest-01,f3240-sqltest-02 -diskcount 16 -disktype SAS -raidtype raid_dp -maxraidsize 16
[Job 818] Job succeeded: DONE

Создан aggregate, распределенный (striped) на два узла кластерной системы - f3240-sqltest-01 и fas3240-sqltest-02.

Посмотреть, что получилось можно командой aggr show myAggr.

w680

Данный aggregate распределен на два узла, состоит из 16  дисков, 8 из которых на узле 01, и 8 – на узле 02. Создано также два плекса и две RAID-группы. Это означает, что такой striped aggregate состоит, по сути, из двух “обычных” aggregate. Обратите также, что Volume Style указан как striped.

Понятнее про состав striped aggregate станет после вывода команды aggr member show.

f3240-sqltest::> aggr member show
Aggregate     Size Available Used% State    #Vols Node             RAID Status
——— ——– ——— —– ——- —— —————- ————
myAggr_000 2.15TB    2.15TB    0% online       0 f3240-sqltest-01 raid_dp,normal
myAggr_001 2.15TB    2.15TB    0% online       0 f3240-sqltest-02 raid_dp,normal
2 entries were displayed.

Как видите, striped aggregate myAggr состоит из двух “мемберов”, myAggr_000 и myAggr_001, каждый на своем узле. Если бы мы создали такой aggregate на трех, четырех, и так далее узлах кластера – мы бы получили три, четыре, и так далее под-“аггрегейта”. Созданный же на таком aggregate, поверх него том (volume) и данные на нем, окажутся равномерно распределенными по доступу между несколькими узлами, и операции доступа к ним более или менее равномерно нагрузят все входящие в группу контроллеры.