about NetApp

Новый документ в техбиблиотеке Netwell:

Microsoft Hyper-V с использованием SMB 3.0 в Clustered Data ONTAP: Рекомендации

Pavel Lobanov, John Reed, NetApp

Май 2013 | TR-4172

Этот документ предлагает основные рекомендации и наилучшие практики для использования Microsoft® Hyper-V™ на системе хранения NetApp® с использованием NAS-протокола SMB 3.0.

Скачать .pdf (21 страница)

??так, завершая наш цикл постов про переход с Data ONTAP 7-mode на Clustered Data ONTAP, принципиально новую версию OS Data ONTAP, переход на которую пользователей идет вот уже несколько лет, и вот, наконец, этой осенью выходит на финишную прямую, и компания NetApp, наконец, этой осенью выпускает очередную версию Data ONTAP, в которой уже не будет режима 7-mode, и будет только Clustered Data ONTAP.
Да, уже существующие системы и версии Data ONTAP продолжат поддерживаться, но все новые версии будут уже только Clustered, или C-mode (Cluster-mode).
Это значит, что именно этой осенью вам стоит решить, остаетесь ли вы на текущей версии, и отказываетесь от всех новых фич, которые уже появились, и еще появятся, или же идете вместе с NetApp.

Одной из основных проблем, среди нескольких, которые встают перед решившимся на такой переход, является невозможность перехода такого, который называется data-in-place, то есть с сохранением данных на дисках на их местах. Невозможность простой миграции - довольно привычная ситуация для пользователей систем других вендоров, стоит вспомнить, например, переход с EMC Clariion на EMC VNX, или с HP EVA на HP 3Par. Все такие переходы у большинства вендоров делается с “полной пересборкой” системы. Нельзя взять дисковую полку от EMC Celerra, со всеми лежащими на них данными, и подключить прямо к VNX, и сразу же продолжать с ними работу.
Не так было у NetApp. Много лет как апгрейд у NetApp делался с полным сохранением данных на диске. Вы могли взять FAS3040 с дисками FC в полках DS14MK4, системы, выпущенной лет 10 назад, и просто заменить ее контроллеры, или же установить на нее самую последнюю версию Data ONTAP и все заработает без необходимости делать бэкап данных, и восстанавливать их на новую систему, на новые, или те же самые диски.

К сожалению, для перехода с 7-mode на Clustered Data ONTAP такого простого перехода сделать нельзя. Структуры данных на дисках существенно и сильно поменялись, поэтому просто “сконвертировать” данные “на месте” - невозможно.

Незадолго до начала задуманной серии постов я встречался со специалистами дистрибуторской компании Netwell, компании, с сотрудниками которой меня связывает долгое сотрудничество по “переводному проекту”. Тогда же они мне рассказали, что они оказывают помощь российским пользователям NetApp по переходу на Clustered Data ONTAP, и миграции данных, предоставляя необходимое оборудование и помогая инженерами, то есть осуществляя Professional Service, как это называется “там”.
?? тогда мы договорились, что знакомый многим по нашему форуму Евгений Денисов, сотрудник Netwell, подробно расскажет про эту услугу в моем блоге.
Ниже - наш разговор.

romx: ??так, что же надо сделать, если мы “решились на переезд”?

ED: Вам нужно связаться с вашим партнером, через которого вы покупали систему, и, если вы покупали ее через нас, дистрибутора Netwell, то партнер связывается с нами и передает эту задачу нам. Мы контактируем с вами, узнаем, что за конфигурация у вас сейчас, каков объем мигрируемых данных, и прочие технические детали, согласуем сроки. Затем мы привозим к вам на сайт сторадж, собираем его в кластер, затем мигрируем ваши данные на него, затем разбираем и переконфигурируем ваш сторадж в кластер, затем мигрируем данные назад, очищаем наши диски от ваших данных, проверяем, что миграция успешна, и вы получаете готовую систему в Cluster-mode, и с вашими данными, перенесенными на нее.

romx: Этот сторадж, что это?

ED: Это “подменная” система из нашего демо-пула оборудования, которую мы держим для внутренних нужд, демонстраций у пользователей, и так далее. У нас есть также достаточный объем дисков. Впрочем, для очень больших объемов переноса могут быть сложности, так что - связывайтесь предварительно.

romx: Как все это осуществляется физически? Каким образом переносятся данные?

ED: Если это файловые шары, то есть данные хранятся в NAS-режиме, по протоколам SMB/CIFS или NFS, то есть нетапповский инструмент: 7-Mode Transition Tool, 7MTT. Он в полуавтоматическом режиме переносит все данные с системы в 7-Mode на Clustered Data ONTAP. К сожалению такого средства нет для блочных данных, поэтому их мы мигрируем вручную, копированием через хост. На новой системе создается LUN, затем данные со старого LUN-а копируются в новый, затем, после пересборки пользовательской системы в кластер - назад.

romx: Сколько все это занимает времени?

ED: Мы укладывались в довольно большом проекте за выходные. Так что можно считать, что за два выходных дня и менее можно перенести практически любую систему. Бывают всякие случаи, поэтому нам и нужно заранее согласовать объемы работы и время.

romx: Со временем - понятно. А сколько это стоит?

ED: Для пользователей это бесплатно. Ну, то есть это, как любой professional service, стоит денег, но NetApp покрывает эти затраты нам, так как заинтересован в скорейшем и максимально массовом, беспроблемном переходе. Так что для пользователя это бесплатный сервис и бесплатный процесс.

romx: Это сейчас делаете только вы, из всех дистрибуторов в России?

ED: Насколько я знаю - да. Если вы - наши, то вам повезло. Если вы, допустим, “мерлионовские”, то спрашивайте о такой услуге у них. У них также есть необходимые ресурсы это сделать для вас.

romx: Технический вопрос: Получается, что на дисках системы, которую вы привозите для проведения миграции, после нее остается копия пользовательских данных?

ED: Нет, конечно мы уважаем секьюрность пользовательских данных, после миграции все данные на наших дисках уничтожаются в присутствии клиентов. Это может быть или простое удаление всех томов и LUN-ов после обратной миграции (это уже необратимый процесс), либо, если действуют особые требования по информационной безопасности, то делается процесс disk sanitization, это полное затирание содержимого дисков. Это, впрочем, существенно дольше, чем простое удаление.

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

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

romx: Спасибо, в целом на все вопросы есть ответы. Если у читателей будут еще какие-то уточнения и конкретные вопросы, то их можно задавать?

ED: Конечно, например в комментарии к посту, я их, да и вообще тебя читаю регулярно.

??так, в прошлый раз мы начали трогать тему перехода с Data ONTAP 7-mode, на Clustered Data ONTAP, и все что с этим связано.

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

Если вы уже последовали намеченным путем, то есть прочитали TR-3982 Clustered Data ONTAP 8.2: Введение, доступный в переводе на сайте Netwell. Посмотрели учебные материалы про Clustered Data ONTAP, почитали документацию, поставили и покрутили симулятор, то следующий шаг - планирование перехода.

?? тут я бы хотел напомнить, какие у нас есть сложные моменты.

Прежде всего - это ограничение, которое накладывается на число узлов кластера, с использованием старых и слабых контроллеров.
Как я уже не раз тут говорил и приводил эту пословицу: “Скорость эскадры определяет скорость самого медленного в ней корабля”. Так и в случае кластера. Да, с использованием самых топовых контроллеров, например FAS8060 или FAS6200, вы можете построить кластер вплоть до 24 узлов для NAS и 8 узлов для SAN, верно.
Но если у вас в кластер включены FAS3160 или FAS2200, то тогда максимальные размеры кластера определят эти “медленные корабли”. Это стоит помнить, и сразу здраво оценивать, хотите ли вы пихать в новый кластер старые контроллеры, которые, в теории, может быть, и могут быть в него включены, но своим включением существенно его ограничат.

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

Хотя определенный смысл от перехода на Clustered Data ONTAP есть и в этом случае, например облегчается миграция, даже однократная и односторонняя, со старых контроллеров на новые.

Таким образом вот ваши лимиты, по контроллерам разных моделей:

FAS3140 - 2 узла.
Такая же ситуация у FAS2520 - 2 узла максимум.
Это, фактически, ровно HA-пара и все. К этой паре больше никого не подлючить. Но эта пара будет, тем не менее, кластером.
Далее.

FAS2220, FAS2240, FAS3160, FAS3170, FAS3210, FAS3240, - 4 ноды максимум.

FAS2550, FAS3220, FAS3250, FAS3270, FAS6040, FAS6210 - 8 нод - максимум, и под NAS, и под SAN.

Наконец, топовые системы:
FAS6080, FAS6220, FAS6240, FAS6250, FAS6290, FAS8020, FAS8040, FAS8060, FAS8080EX - 24 ноды под NAS и 8 нод под SAN.

Это для нас значит, что мы не можем в нашей гипотетической конфигурации включить в уже собранный кластер из пары FAS2240 еще четыре FAS8040, потому что лимит для кластера с участием FAS2240 равен 4 нодам. Но еще пару FAS8040 - можем, безусловно.

Какой же у нас есть путь “в кластер”, для уже существующей системы?

Наиболее простой вариант - пересборка вашей пары контроллеров, работающей в 7-mode в HA-пару так называемого 2-node switchless cluster. При этом вам не требуется строить Cluster Network с использованием выделенного 10G Ethernet коммутатора, но вы можете его добавить позднее, если вам потребуется перейти на кластер, превышающий 2 узла, это не потребует больших затрат сил, а при использовании отказоустойчивой пары соединений 10G для межнодового кластерного интерконнекта, то и вовсе может быть выполнена без прерывания нормальной работы. Просто одно соединение, идущее из одного контроллера в другой напрямую, разрывается, переключается в подготовленный коммутатор, затем, после того, как ноды увидели друг друга через коммутатор, можно разорвать и перенести в коммутатор и вторую пару соединений Cluster Interconnect.

Конечно, как и всегда, для любой кластерной системы, вам обязательно нужно иметь выделенные порты 10G под Cluster Network, и для стандартной отказоустойчивой схемы с избыточностью их нужно по два порта на контроллер.
Да, для FAS2240 вы, в результате, вынуждены отдать оба имеющихся порта 10G под кластерную сеть. Ну и, конечно, в любых других контроллерах, вам тоже надо будет иметь по паре 10G портов только под эту выделенную сеть.

Как вы видите, в двухнодовый кластер вы можете (при наличии в нем пары 10G-портов) перевести почти любой из “ныне живущих” (в данном случае это понимается как “поддерживаемый”) контроллеров. Нужно ли - отвечать вам.

К сожалению, пока по-прежнему нет решения, которое бы перенесло данные из системы 7-mode в систему Clustered Data ONTAP, в data-in-place, то есть в столь привычном разбалованным юзерам NetApp варианте апгрейда, когда “перетыкаешь кабеля, и поехало”. Напомню, сегодня по-прежнему для перехода на Cluster надо полностью разобрать имеющуюся систему и переинициализировать диски, с потерей data-in-place, то есть либо через “бэкап и рестор”, либо через миграцию.

?? вот как мы будем из этой ситуации выкручиваться, вот про это будет пост “Часть 3″.

Несколькими месяцами ранее я уже проводил опрос, на тему перспектив перехода пользователей на Clustered Data ONTAP на их стораджах. Опрос это обозначил несколько основных групп пользователей по отношению к Clustered Data ONTAP.

Если с примерно третью, теми, кто ответил, что они уже перешли, или переходят до конца этого года (ну или в обозримое время, главное, что решение уже принято), все понятно, я могу их только поздравить с их решением, то вот с оставшимися двумя третями все сложнее. Конечно, я трезво понимаю, что среди оставшхся некоторое (значительное) количество составляют владельцы младших и старых систем, для которых переход на Clustered Data ONTAP закрыт по техническим причинам (например – старости, слабости и непригодности контроллеров предшествующих поколений стораджей). Но наверняка среди них также есть и люди, которые, возможно, могли бы перейти на Clustered Data ONTAP, но либо не понимают как и когда это проделать, либо недостаточно осведомлены о том, от каких плюшек они, в результате, отказываются. Мне бы хотелось, в серии постов, котрые я запланировал и написал для ближайших нескольких недель, детально разобрать эти новые и полезные возможности Clustered Data ONTAP.

Continue reading ‘Переход на Clustered Data ONTAP. Часть 1’ »

После выхода FAS8000 и Data ONTAP 8.2.1, обновилась рекомендация NetApp по использованию и числу портов 10G Ethernet, задействованных в кластерном интерконнекте, закрытой внутренней сети обмена данными между контроллерами, входящими в один кластер (тот, что именно кластер, в терминах clustered Data ONTAP, или, по старому, C-mode).
Если раньше для подключения в Interconnect использовались два порта 10G на каждом контроллере (каждый - в свой коммутатор, конечно, для надежности и отказоустойчивости, то новая рекомендация - использовать для старших систем по два таких порта, итого - четыре на контроллер. Так как onboard портов у FAS8040/8060 как раз четыре на контроллер, то эта рекомендация не будет создавать особенных сложностей.

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

Трафик интерконнекта состоит, в первую очередь, из трафика между LIF, то есть логического интерфейса SVM, Stotage Virtual Machine (или, по старому, VServer), и ее данными, которые могут оказаться, например в результате миграции SVM, на дисках, обслуживаемых другими контролерами. В этом случае трафик, входя через физические порты, привязанные к LIF с одного контроллера, достигнет своих данных, расположенных на дисках другого контроллера, пройдя через кластерный интерконнект (в терминах NetApp это называется remote workload).
А так как увеличившаяся мощность контроллера и объем NVRAM существенно лучше обрабатывают ряд “трудных” для контроллеров NetApp нагрузок, например linear-типа, способных нагрузить интерконнект трафиком, возникла необходимость рекомендовать решение, снимающее это потенциальное узкое место.

Конечно, если вы используете 7-mode и младшие модели, то вас это все пока не очень касается, но если вы строите по настоящему мощную систему, то советую заранее присмотреться к этой рекомендации. Кстати, следует отметить, что сама процедура добавления дополнительных портов в интерконнект сравнительно проста, доступна для уже построенной системы, и никаких значительных перенастроек в ней не требуется, все внутренние компоненты Data ONTAP, использующие интерконнект, самостоятельно перебалансируются, обнаружив дополнительный интерфейс.

Если вам в скором времени предстоит переход на Clustered Data ONTAP, или если вы админ системы хранения, хорошо знакомый с Data ONTAP 7-mode, которому предстоит администрировать Cluster-mode, то рекомендую посмотреть документ, недавно опубликованный в библиотеке NetApp:

Clustered Data ONTAP® 8.2
Command Map for 7-Mode Administrators

В нем в таблицу собраны команды Cluster-mode, соответствующие, по выполняемым действиям, командам 7-mode. То есть если вы знаете как, допустим, создать том на aggregate в 7-mode, и не знаете какой командой это делается в Clustered ONTAP, то вот этот документ вам поможет.

Брать можно здесь: https://library.netapp.com/ecm/ecm_download_file/ECMP1196780

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

Как вы уже знаете, архитектура системы хранения 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.

Данный 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) и данные на нем, окажутся равномерно распределенными по доступу между несколькими узлами, и операции доступа к ним более или менее равномерно нагрузят все входящие в группу контроллеры.

Следует отметить, что новости про flash прошлой недели показывают, что для NetApp это не просто “ну еще один all-flash сторадж, раз у всех есть”, налицо стратегическая линия. Одновременно с EF540 был анонсирован продукт, который пока не выпущен, но о котором, что, в общем, необычно для NetApp, уже рассказывается: FlashRay.

Если вы уже начинаете запутываться в том, что где и для чего у NetApp на flash-рынке предназначено, то давайте посмотрим на схему:

На ней вы видите позиционирование всех на сегодняший момент flash-продуктов NetApp: Flash Cache находится в контроллере, Flash Pool -  во “встроенном” хранилище самого NetApp, его часть, Flash Accel – софтверное решение внутри хост-серверов, использующая их внутренние SSD. EF450 – это standalone-сторадж, никак, архитектурно, не связанный с FAS. А вот что будет в этой картине мира делать анонсированный FlashRay?

FlashRay – это компонент развивающейся силами Clustered ONTAP (Data ONTAP 8 Cluster-mode) архитектуры scale-out, или, если по-русски, “горизонтального масштабирования. Напомню, что такое “горизонтальное” и “вертикальное” масштабирование.

Если вы переросли ваш сторадж,  и меняете его на более мощный – это “вертикальное масштабирование”. Если вы увеличиваете мощность имеющегося стораджа, добавляя непосредственно в имеющуюся инфраструктуру новый контроллер и диски, которые не образуют новую, более мощную “сущность”, а расширяя емкость и производительность уже имеющейся системы – это “горизонтальное масштабирование”. В NetApp “горизонтальное”, или scale-out (в отличие от scale-up, “вертикального”) масштабирование – это Cluster-mode.

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

В отличие от NetApp SA, согласно анонсу, FlashRay это будут all-flash устройства, ускоряющие доступ к бэкэнд-стораджу FAS, он будет поддерживать кластерность, многопротокольность (а не только NFS), inline-компрессию и inline-дедупликацию данных с переменной длинной блока (неужели пригодились-таки разработки для VTL в этой области?), и ряд других, более обычных для NetApp опций, включая репликацию и автобалансировку нагрузки в кластере FlashRay.

Таким образом, если после анонса EF540 вам показалось, что NetApp начала отходить от своей парадигмы “во flash выгоднее кэшировать, чем хранить”, то анонс FlashRay показывает, что концепция жива, здорова, и передает всем пламенный привет с нового уровня своего развития. Ждем более подробных новостей с техническими деталями.

На днях, NetApp официально опубликовал результаты бенчмарка SPC-1, главного бенчмарка по демонстрации производительности на блочном (SAN) доступе.

Как вы знаете, в Data ONTAP 8.1.x Cluster-mode появилась новая возможность – кроме доступа к системе хранения как к NAS, по протоколу NFS или CIFS/SMB, теперь возможна и работа с блочным стораджем, то есть как SAN-утройства. В версии 8.1 кластер SAN был ограничен 4 узлами (2 HA-парами), но, как я и предполагал, этот размер будет постепенно увеличиваться, и вот уже в 8.1.1 он был увеличен до 6 узлов (нод) в кластере. Напомню, что для NAS (NFS) максмальный размер кластера составляет 24 узла.

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

?? если для NAS NetApp достаточно давно показывал свои результаты в бенчмарке SPEC sfs2008, в том числе и для Cluster-mode, то для блочных протоколов, таких как FC или iSCSI, или FCoE, таких данных не было. А отсутствие результатов бенчмарков всегда тревожит, как же оно там, на самом деле, не на бумаге маркетинговых буклетов?

Наконец, на прошлой неделе, NetApp показал свои (почти)топовые результаты, для 6-узлового кластера, с использованием контроллеров FAS6240, под управлением Data ONTAP 8.1.1.

??нтересно, что бенчмарк SPC-1 требует публиковать цену тестируемой конфигурации (в терминах SPC-1 – TSC, Tested Storage Configuration), и, следовательно, вычислять параметр $/IOPS, “цену транзакции”. Но тут следует обратить внимание, что не запрещается искусственно занижать “листовую” цену продукта (например указав в цене уже некий “дисконт” относительно листпрайса), получая более “выгодно выглядящие” $/IOPS. Показатель $/IOPS приводится вместе с показателем IOPS, достигнутым на тестировании, даже в короткой версии результата, так называемом executive summary, в то время, как за полной конфигурацией тестируемой системы и за опубликованными на нее ценами, надо идти в full disclosure report.

NetApp на тестировании SPC-1 всегда приводит в качестве цены на систему полный, официальный листпрайс на момент тестирования, без дисконтов, и, что интересно, со включенным SupportEdge 24×7х4h на 3 года. Специально хочу напомнить, что листпрайс в реальной жизни не является реальной ценой продажи, так как в подавляющем числе случаев при продаже для конечного пользователя из цены вычитаются разнообразные, порой значительные, в десятки процентов, дисконты (скидки).

Поэтому если вы хотите просто тупо сравнить циферку $/IOPS системы одного вендора, с опубликованным $/IOPS у NetApp, обязательно посмотрите, исходя из какой цены было это значение вычислено, и, соответствующим образом, скорректируйте результаты.

18 июня 2012 года NetApp опубликовал официальный отчет о тестировании 6-узлового кластера в SAN, на протоколе доступа FC 8Gb/s и тестируемом объеме ~72TB (~193TB raw, 36% от raw), 432 диска SAS 450GB в 18 полках, показав результат 250 039,67 IOPS, и, при листпрайсе $1 672 602, показатель $/IOPS составил 6,69$/IOPS SPC-1.

За подробностями – в executive summary и в full disclosure report.