about NetApp

Ну, так как до выхода 8.1.1 уже совсем немного времени, давайте я уже расскажу вам, что же такое Flash Pool, который появится у NetApp начиная с этой версии.

Я ранее уже несколько раз упоминал о новой идее NetApp – включении нескольких SSD непосредственно в дисковый aggregate системы хранения, и использования их под кэш “уровня aggregate”, в том числе и для записи. Эта конструкция дополняет возможности Flash Cache, может работать как с ним вместе, так и сама по себе, причем, отметьте, также и для систем, на которых Flash Cache, по тем или иным причинам, использовать уже нельзя, например FAS3210, 3140, и даже 2240.

К моменту выпуска, реализация Hybrid Aggregate в системах NetApp получила собственное, коммерческое имя-торговую марку Flash Pool, и далее я буду пользоваться именно им. Вы же знайте, что Flash Pool это название реализации NetApp Hybrid Aggregate в Data ONTAP 8.1.1 и новее.

К сожалению, вокруг Hybrid Aggregate/Flash Pool уже начало образовываться облако недопониманий и мифов, а моя задача в очередной раз внести ясность в тему.

Итак, начнем.

Прежде всего, я бы хотел сказать, что, вопреки домыслам, Flash Pool это НЕ tiering, в классическом его понимании (например в том виде, в каком он представлен в EMC FAST), это кэш. Этот момент понятен? НЕ disk tiering, not, nicht, nie. :) Это КЭШ.

Появление Flash Pool также не означает отказа от Flash Cache. Это независимое, но дополняющее решение. Он может работать с Flash Cache, может работать сам по себе. В случае работы с Flash Cache, кэширование не дублируется. Тома, работающие с Flash Pool (находящиеся в аггрегейте с SSD) не кэшируются в Flash Cache. Помните, что Flash Cache может работать со всеми aggregates и volumes системы в целом, а кэширование Flash Pool распространяется только на тома одного aggregate. Если у вас несколько aggregates, вам понадобится добавлять SSD для создания Flash Pool в каждый aggregate, который вы хотите кэшировать в Flash.

В гибридный aggregate, то есть Flash Pool вы можете преобразовать любой 64-bit aggregate, добавив в него несколько SSD NetApp, объединенных в RAID-группу, и указав для aggregate соответстующую опцию, также его можно создать “с нуля” обычным способом, как любой aggregate. Но в создании Flash Pool есть несколько тонких моментов, именно на них я хочу остановится подробнее.

Так как Flash Pool это кэш, то есть SSD, как таковые, не доступны для непосредственного хранения на них каких-то конкретных данных, а лишь кэшируют поступаюшие на и считываемые с томов aggregate данные, добавление в aggregate SSD не увеличивает его емкость. Есть и “побочный эффект” – если вы имеете aggregate, достигший максимального возможного для данного типа контроллеров размера, например 50TB для FAS3210, то вы все равно можете добавить в этот 50TB-аггрегейт диски SSD для Flash Pool.

Тип RAID-группы для дисков, добавляемых в aggregate должен быть одинаков для всего aggregate. Если вы используете RAID-DP, то добавляемые SSD тоже должны быть в RAID-DP. Нельзя в aggregate из HDD в RAID-DP добавить SSD в RAID-4, например.

Обратите внимание, что возможность добавления в aggregate дисков SSD НЕ означает возможности добавления в aggregate дисков HDD другого типа. Flash Pool може быть (по вашему выбору) из SAS/FC и SSD, или из SATA и SSD, но НЕ из SAS и SATA.

После добавления SSD в aggregate вы, как и в случае обычных дисков, добавленных в aggregate, не можете “вынуть” их оттуда (например чтобы использовать их позже в другом, более нуждающемся aggregate) не уничтожив aggregate.

Наверняка у многих уже вертится на языке вопрос: “Как же нам воспользоваться Flash Pool, если NetApp продает SSD только в составе полки на 24 диска?” Отвечаем: С появлением Flash Pool SSD NetApp будут продаваться паками по 4 штуки, что дает вам во Flash Pool 142GB кэша из 4 SSD. Диски имеют размер 100GB [84574 MiB], и когда они включаются в aggregate, построенный на RAID-DP, вы получите из 4 дисков два диска parity и два – data. Конечно, вы можее включить в Flash Pool и больше SSD.

Однако помните, что SSD имеют интерфейс SATA. Это значит, что вы НЕ МОЖЕТЕ добавить SSD непосредственно в полку с дисками SAS. Но можете – в полку с дисками SATA. Смешивать физические интерфейсы дисков в составе одной полки нельзя. Таким образом, если у вас система с “только-SAS/FC”, вам понадобится для установки SSD, даже всего 4 штук, например, дополнительная полка “только-SATA”. Не забывайте об этой сложности.

Вопрос, который я уже тоже слышу :) “Вы говорите – SSD работает на запись? А как же с исчерпанием ресурса на перезапись для SSD?”

Ну, это тема. Да, безусловно, с этой точки зрения Flash Cache был принципиально более надежен, так как работал только на чтение, а записи (заполнение кэша) в него делались сравнительно (по меркам компьютера) редко, и большими “порциями”, которые flash memory как раз обрабатывает довольно хорошо, это не random write мелкими блоками. Однако практика использования SSD enterprise-class показывает, что проблема пресловутого “исчерпания ресурсов SSD при записи” в значительной мере надумана, преувеличена, и присуща, в основном, “бытовым” SSD. Тем не менее, эта проблема возможна, так как Flash Pool действительно пишется, работая на запись (хотя, вы не забыли, записи в WAFL не рандомны, а секвентальны). Для защиты данных в случае выхода SSD из строя вы как раз и используете объединение SSD в RAID, а сами SSD, как устройства, покрыты общей трехлетней warranty на систему.

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

Отвечая на третий вопрос ;) : Да, TRIM для SSD поддерживается Data ONTAP на уровне системы.

Напомню, Flash Pool, новое название Hybrid Aggregate, появится в Data ONTAP 8.1.1, которая ожидается к выпуску в ближайшем месяце.

Недавняя моя заметка о выходе Data ONTAP 8.1 и некоторых особенностях новой версии, вызвала довольно широкий отклик, поэтому, для уменьшения количества панических слухов, я решил написать это дополнение и разъяснение.

Проблема, как вы уже знаете, в том, что, согласно Release Notes, в новой версии Data ONTAP, не поддерживается устройство Flash Cache на младших моделях линейки midrange, то есть на 3140, и даже на сравнительно недавно вышедшей 3210, несмотря на то, что Flash Cache можно физически в эти системы поставить, и ранее такая конфигурация поддерживалась.

По этому поводу ТАСС уполномочен сообщить мой источник в NetApp сообщает:

1. Да, действительно, это так. Поддержка Flash Cache для 3210/3140 сохраняется для ранее выпущенных версий Data ONTAP, то есть для линейки 7.3.х, и для v8 вплоть до версии 8.0.3 (и далее, если линейка 8.0.х будет продолжена).
2. Ситуация связана с некими сложностями на системном уровне. Дабы не задерживать выпуск 8.1, было решено подготовить фиксы для этой проблемы к следующей версии, 8.1.1, которая запланирована к выпуску в начале лета.
3. В версии 8.1.1 вновь ожидается поддержка Flash Cache для 3210 в объеме 256GB на контроллер (полный объем одной платы на 256GB), и для 3140 – в половинном объеме от объема установленной платы 256GB (доступный объем для Flash Cache 256GB для 3140 будет виден размером 128GB).
4. Flash Cache для FAS/V3210 или FAS/V3140 более недоступен к заказу, соответствующая конфигурация недоступна в конфигураторе с декабря 2011 года, вне зависимости от версии OS.
5. Установка Flash Cache на купленные после этой даты FAS/V3210 или FAS/V3140 не разрешена и не поддерживается, вне зависимости от использованной версии DOT.
6. Версия 8.2, и далее, также не будет поддерживать Flash Cache на системах FAS/V3210 и FAS/V3140.

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

UPD: Я говорю тут ТОЛЬКО о поддержке Flash Cache на 3210 и 3140, на всех остальных системах 3200/6200, а также 3100, Flash Cache по прежнему ПОДДЕРЖИВАЕТСЯ и работает как и раньше.

В качестве варианта замены стоит обдумать вариант с Hybrid Aggregate (использование SSD в составе обычного aggregate из HDD), который появится начиная с 8.1.1, и о котором подробнее позже.

Итак, 19 апреля наконец случилось долгожданное событие, дооооолгий путь версии 8.1 к пользователю, через казавшиеся бесчисленными Relelease Candidates (RC), завершился, наконец, выходом General Availability Release.

Напомню, это та самая версия, в которой, наконец-то, появился 4-нодовый Cluster-mode для блочных протоколов FC/iSCSI/FCoE. Плюс ряд новых возможностей.

К сожалению, не обошлось и без ряда неприятных потерь, о которых я хочу упомянуть отдельно (потому что про победы вы прочитаете в пресс-релизах, а о факапах придется читать мелким шрифтом, где нибудь в Release Notes).

Во-первых, и об этом я хочу сказать с недоумением и негодованием, не думайте, что фоннатство в отношении NetApp мне напрочь глаза застило, это то, что теперь более не поддерживается Flash Cache на младших моделях линейки 3100/3200, то есть для 3140 и 3210.

А вот так. Физически поставить можно, а в 8.1 не поддерживается. То есть человек покупает 3210, с Flash Cache и 8.0.2,  в котором она поддерживается. Платит за пару Flash Cache 40 тысяч баксов. Платит за Software Subscription сколько-то тысяч, расчитывая получить поддержку и новые версии. Спустя три месяца выходит новая версия, и человек внезапно осознает, что его система более не поддерживается. А вот так вот. Либо новая версия Data ONTAP, и девайс на 40 штук баксов в ведро, либо оставить Flash Cache и тогда стоимость Software Subscription в ведро, и новых версий Data ONTAP для вас нет.

Причины не ясны. То есть варианта два. Либо это сознательное решение, вызванное маркетинговой попыткой “сегментировать”, и повысить привлекательность 3240 для тех, кто при прочих равных выбрал бы систему подешевле. Либо это конструктивный просчет на этапе создания линейки (есть и такое мнение, что на что-то в новой версии перестало хватать памяти). Причем я даже искренне не знаю, что из этих двух причин хуже, то что впервые на моей памяти инженера NetApp так пролетают с расчетом, или что компания так жостко кинула своих клиентов 3210/3140 с Flash Cache и SSP, по схеме, описанной выше.

Напомню, что 3210 с Flash Cache это официальная, опубликованная и валидированная конфигурация FlexPod, как она опубликована, например, в Cisco Validated Design.

UPD: Как совершенно справедливо заметили мои читатели в комментах, читающие внимательно Release Notes (в отличие от меня, позор), на самом деле там написано:
Attention: If you have a 3210 or 3140 storage system with Flash Cache modules installed, do not upgrade your system to Data ONTAP 8.1 7-Mode. Flash Cache modules are not supported in 3210 or 3140 storage systems with Data ONTAP 8.1.
The issue is under investigation and a long-term strategy will be communicated as soon as possible.

Что-ж, будем надеяться на лучшее. Видимо и вправду косяк вылез неожиданно, а так как 8.1 давно уже отстала от графика выпуска, было, по-видимому, решено выпускать как есть, а не откладывать еще раз, а такую неприятную особенность править в последующих Patch Releases.

.

.

Остальное это уже мелочи, на мой взгляд.

Окончательно исчезла поддержка полочных интерфейсных модулей ESH2 (DS14mk2), то есть 2Gb/s FC к полкам. Это, что называется, “туда и дорога”, тем более, что системы с ESH2 не продаются уже лет пять минимум, и в живой системе они могут появиться только как глубокое legacy.

Больше нет FilerView (веб-интерфейса, открывающегося по адресу http://filer/na_admin). Ну я понимаю, что он в своем нынешнем виде уже был позорно анахроничен внешне, и непригоден для Cluster-mode (хотя, наверное, можно было и обновить, и что-нибудь придумать). Но кому он мешал в качестве стандартного инструмента, по-прежнему годного для администрирования 7-mode? Ну то есть я понимаю, у нас теперь всюду Cluster-mode “шагает впереди”, но тем не менее, будем смотреть правде в глаза, в ближайшие пару лет 7-mode все еще будет занимать подавляющее число инсталляций.

Так что теперь у нас для администрирования осталась лишь командная строка и творение развеселого бангалорского гения – System Manager 2.0, который… ну-у… неоднозначный продукт, скажем обтекаемо.

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

На прошлой неделе NetApp выпустил в свет мобильное приложение под iOS и Android, для доступа к информации Autosupport вашей системы. Приложение пока на самой ранней стадии, но идея очень правильная и нужная.

Берут здесь: http://www.netapp.com/us/support/asup-app.html

Есть, как я уже сказал, версии для iPhone, iPad и Android tablets/phones.

Некоторое время назад по IT-новостям прокатилось сообщение что “Система хранения Oracle 7320 победила в тестах NetApp FAS3270!! адинадин”. На прошлой неделе у меня дошли руки посмотреть все же что там, как, кто, и кого победил. О результатах рассказываю.

Тема “тестирований производительности” (кавычки мои, romx) есть любимая тема любого сисадмина.

Допустим, вы читаете в новостях сообщение, что “Мотоцикл Honda CBR150 обошел на стометровке с места болид Formula1 Ferrari!”. “Ну, круто” – подумаете вы, “но кому интересно соревнование с формульным болидом на стометровке с места? Они бы еще соревновались по параметру “экономия бензина” с велосипедом!” А вот нет, оказывается, прекрасная новость и информационный повод проспамить прессрелизом IT-издания.

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

Но, для начала, несколько вводных слов.

Тестирование – тема очень непростая. Очень важный аспект в любом бенчмарке это создание повторяемой среды, отражающей реальные условия использования тестируемого предмета. Результаты процесса “копирования ISO в тотал коммандере”  совершенно неприменимы для оценки быстродействия системы хранения на задаче OLTP database, а данные чисто “синтетического” теста могут не отражать адекватно ваши реальные рабочие результаты, на вашей реальной рабочей задаче, в жизни.

Но если в том что касается бенчмарка, то есть создания повторяемой среды тестирования идентичной для всех тестирующихся систем, можно положиться на авторитет общепризнанных тестов, каковыми на сегодня являются, например SPECsfs2008 для файловых протоколов (NFS и CIFS), и SPC-1 для блочных протоколов (FC и iSCSI), то вот в подготовке тестируемой системы есть некоторая свобода, которой иногда (довольно часто, к сожалению) пользуются некоторые производители с целью создать “систему хранения”, единственная цель которой – победа в тестировании. В англоязычном сегменте такое называется lab queen, по-русски я слышал название “звездолет”.

Вариантов как построить звездолет есть масса. Например можно взять хай-энд систему и набить ее SSD, получив систему за шесть миллионов долларов на 19TB usable . Можно поставить вместе четыре стораджа, и в результатах тупо просуммировать показанные ими по отдельности результаты. Можно, наконец, тестировать систему на голых дисках без RAID или на RAID-0. Использовать множество дисков малого объема. Разбить пространство тестирование на большое количество мелких разделов, снижая “разбег” random access seek, и так далее. Полученные таким образом результаты окажутся неприменимыми в реальной жизни и в реальной эксплуатации того, что вы можете купить, однако очень эффектно смотрятся в пресс-релизах об очередной победе.

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

А теперь перейдем собственно к теме. Что же скрывает за собой барабанная дробь прессрелиза?

Согласно требованиям проведения тестирования SPECsfs2008, протестированная конфгурация должна быть хорошо и детально документирована и описана. Эти данные доступны на сайте SPEC.org всем желающим. Пожелаем и мы проверить, какую же в точности конфигурацию тестировали в Oracle.

Вот как описывает протестированную конфигурацию сайт SPEC.org:
http://www.spec.org/sfs2008/results/res2012q1/sfs2008-20120206-00207.html

Система Oracle Sun ZFS storage 7320

136 дисков SAS 15K на 300GB в 6 дисковых полках, обшим usable space емкостью 37,1TB и общей экспортируемой емкостью в 36,96TB были поделены на 32 файловые системы, по 16 на каждый из двух контроллеров (каждая экспортируемая FS имела размер примерно 1,1TB), доступ к которым осуществлялся с трех loadgenerator Sun Fire X4270 M2, подключенных по 10G Ethernet.

Также тестированный сторадж оснащен 8 дисками SSD по 512GB каждый, для кэширования чтения, (так называемый L2ARC), общей емкостью 4TB, пополам на каждом из двух контроллеров, и 8 дисками SSD 73GB в качестве кэша записи (ZIL), суммарно 584GB, без RAID в обоих случаях. Кроме этого, два контроллера системы хранения имели RAM емкостью 288GB (ARC, по 144GB на контроллер), что дает 4968GB суммарной емкости кэша (SSD и RAM).

Суммарная, участвующая в тестировании емкость (fileset) составила 15587,3 GB, то есть емкость кэша составила примерно треть от используемого файлсета.

Далее цитата:
The storage configuration consists of 6 shelves, 4 with 24 disk drives, 2 with 20 disk drives and 4 write flash devices. Each controller head has 4 read flash accelerators. Each controller is configured to use 68 disk drives, 4 write flash accelerator devices and 4 read flash accelerator devices. The controller is then set up with pools by dividing the disk drives, write flash accelerators and read flash accelerators into 4 pools. Each of the controller’s pools is configured with 17 disk drives, 1 write flash accelerator and 1 read flash accelerator. The pools are then set up to stripe the data (RAID0) across all 17 drives. The write flash accelerator in each pool is used for the ZFS Intent Log (ZIL) and the read flash accelerator is used as a level 2 cache (L2ARC) for the pool. All pools are configured with 4 ZFS filesystems each.

“Конфигурация системы хранения содержала 6 дисковых полок, 4 полки на 24 диска и 2 полки на 20 дисков, плюс 4 SSD-кэша на запись. Каждый контроллер использовал 4 SSD-диска в качестве кэша чтения. Каждый контроллер был сконфигурирован на работу с 68 дисками, 4 SSD кэша на запись и 4 SSD кэша на чтение. Каждый контроллер использовал пулы дисков, между которыми были разделены диски, по одному SSD-кэшу на чтение и на запись на каждый пул. Пулы были настроены таким образом, чтобы данные страйпились на все входящие в него 17 дисков (RAID-0). Write flash accelerator (SSD емкостью 73GB) в каждом пуле использовался в качестве ZFS Intent Log (ZIL), а read flash accelerator (SSD емкостью 512GB) как level 2 cache (L2ARC). На каждом из пулов было создано по 4 файловые системы.”

Как мы видим, несмотря на использование ZFS, для организации дисков в пулах был выбран простой stripe, без RAID (фактически RAID-0!). Кроме того стоит отметить, что общая тестируемая емкость дисков была поделена на сравнительно маленькие файловые системы, всего около 1,1TB каждая, числом 32 (зачем такой финт – см. выше).

Очевидно, что такая конфигурация довольно далека от реально эксплуатируемой на такого рода системах. Кто в здравом уме будет класть данные на 17-дисковую группу в RAID-0?! А как планируется использовать пространство, разбитое на 32 отдельных FS для хранения, например, больших объемов? А каковы 512GB write cache на SSD, без малейшей защиты от сбоя?

Кстати интересный вопрос: Если ZFS так хороша и производительна, и так хорош RAID-Z и RAID-Z2, то почему его не использует при выкатке систем на тестирование даже сам Oracle? Что за засада с ним, господа из Oracle? Вот NetApp показывает свой результат на реальных, эксплуатируемых конфигурациях, с RAID-DP и даже со включенным thin provisioning, а в результатах Oracle в SFS2008 – Stripe (RAID-0), а в SPC-1 – mirror (RAID-1). Почему не RAID-Z(2)? Почему бы не показать результаты с ними? Может быть они совсем не так хороши?

Для сравнения давайте посмотрим на упомянутую конфигурацию NetApp FAS3270, которую “побеждали”.

FAS3270 в конфигурации с SAS-дисками и без Flash Cache, поставки таких систем начались в ноябре 2010 года, около полутора лет назад.

360 дисков 450GB 15K, общая usable емкость дисков 125,7TB (в RAID-DP), экспортированная емкость равна 110,08TB (88% от usable) в 2 файловых системах (по одной на контроллер). Диски организованы в два aggregate из 11 RAID-групп 14d+2p в RAID-DP (RAID-6),  тестовая нагрузка генерировалась с помощью 12 Loadgenerators типа IBM 3650M2.

Exported capacity равна 110TB, файлсет, на котором проводилос тестирование - 11749.7 GB  Размер RAM, используемого как кэш на системе хранения, равен 36GB, что составляет 1/326 от fileset.

SPECsfs2008_nfs.v3=101183 Ops/Sec (Overall Response Time = 1.66 msec)

У “победившей” его полтора года спустя системы с RAID-0, с кэшами разного уровня, составляющими суммарно до трети тестируемого файлсета, включая около 4,5TB на SSD, с в шесть раз большим RAM контроллера и с тестируемым пространством побитым на 32 кусочка-FS:

SPECsfs2008_nfs.v3=134140 Ops/Sec (Overall Response Time = 1.51 msec)

На 32,5% больше IOPS и на 8,5% лучше latency.

Ребята из Oracle, что называется "при всем уважени”, но вы правда считаете, что таким результатом, при описанном выше устройстве тестируемой системы, и способе проведения тестирования, это победа и этим стоит гордиться? Нет, ну правда?

Оно дешевле стоит? Ну, согласен, дешевле. Мотоцикл порвал Феррари на стометровке. Но кто гоняет на Феррари на стометровке? Какой смысл сравнивать по цене лоу-мидрендж (“Entry-level cluster option for high availability”, цитата из техспеков на 7320), ZFS-сервер, со стораджем, в максимуме тянущем в 6,6 раз большую чем 7320 емкость, используещем RAID-6, и демонстрируемом даже близко не на пределе своих возможностей по тестируемой емкости?

Впрочем, несколько слов и о цене. В тесте SPECsfs2008 условия тестирования не требуют называния цены тестируемой системы, поэтому спекуляции о цене делаются на довольно мутном базисе “нашли гуглом какой-то прайс нетаппа, где-то в интернете, и прикинули”. Однако в случае SPC-1 требуется указывать такой параметр, как IOPS/$ и цена всей тестируемой конфигурации называется. Тут, однако, тоже есть поле для… ну-у… скажем так, для “оптимизации” :). Например на тестировании SPC-1 NetApp называет цену листпрайса (см стр. 18 отчета), а Oracle, ничуть не смущаясь приводит цену с “вшитой” 30% скидкой по всем позициям (см. стр. 14 отчета) и именно ее берет в расчете IOPS/$ в SPC-1.

Так что, повторю сказанное мной в начале поста: Читайте мелкий шрифт, не ленитесь разбираться в конфигурациях и их деталях, и оставьте пресс-релизы (и выводы только на их основании) для С*O-менеджеров. :)

Для начала несколько слов о том, что такое собственно этот VASA Provider.

VASA – это новая придумка VMware для больших сред виртуализации. Когда у вас всего один-два стораджа и всего несколько датасторов, то вам это не надо. Вы и так помните что у вас где. А вот когда систем хранения у вас будет с десяток, и несколько сотен датасторов,  несколько человек админов в три смены, вот тогда вам захочется как-то разбираться, что у вас где, и, по-возможности, быстро.

Continue reading ‘Установка NetApp VASA Provider’ »

В марте 2012 года, по всей видимости, пройдет окончательную ратификацию “в органах” новая версия протокола NFS – NFSv4.2.

Я уже рассказывал о том, как пару лет назад была выпущена v4.1, главным нововведением которой стал протокол pNFS или Parallel NFS (вопреки модным тенденциям сегодняшнего IT, даже такие значительные изменения, как pNFS, не удостоились v5.0, а считаются всего лишь минорными изменениями версии 4). Про pNFS я тоже уже писал немного, если кому интересно – отсылаю к прошлым постам, если вкратце, то это модификация файловой системы NFS, позволяющей ей работать на параллельном кластере связанных хранилищ, подобно Lustre, Hadoop или GPFS. А сегодня мы собрались для того, чтобы посмотреть на то, что появилось в v4.2. Добавления не настолько глобальные, как в 4.1, но достаточно интересные.

Server-Side Copy (SSC) – это механизм, который позволяет организовывать копирование данных между двумя серверами, не через инициировавшего копирование клиента (чтение на клиента блока с сервера A – запись этого блока на сервер Б, и так далее, пока весь файл не скопирован), а непосредственно. Это чем-то напоминает возможно знакомое кому-нибудь копирование FXP, для двух поддерживающих эту функцию серверов FTP, когда клиент, по командному каналу, указывает для двух серверов, что они должны передать друг-другу файл, после ченго может отключиться, коммуницировать и передавать файл будут два сервера без участия инициировавшего клиента.

Такая возможность значительно снижает нагрузку на канал к клиенту для объемных копирований, например для операций, подобных Storage vMotion, когда содержимое одной VM c одного стораджа, должно быть перенесено на другой сторадж. Теперь это смогут сделать два стораджа, поддерживающие NFS v4.2, самостоятельно, без участия клиента, средствами самого протокола NFS.

Guaranteed Space Reservation – несмотря на то, что thin provisioning для больших инфраструктур это благо с точки зрения эффективности расходования пространства, это большая забота администраторов, в особенности для быстро и непредсказуемо растущих сред. Хотя Thin Provisioning и дает большой выигрыш в расходовании места, за ним “нужен глаз да глаз”. К сожалению до сих пор NFS не предлагал возможности зарезервировать пространство для файлов. Размещение файлов на NFS всегда было thin. Если вы по каким-то своим причинам не хотели использовать thin-модель, то есть занятие места по фактически записанному в файл, а хотели заранее зарезервировать пространство на NFS-хранилище, то у вас не было выбора, а теперь он есть. Guaranteed Space Reservation позволяет, в рамках протокола и файловой системы NFS, создать зарезервированный объем файла, даже не осуществляя в него фактической записи.

Hole-punching. Как вы знаете, одной из наиболее значительных проблем thin provisioning, является проблема “разрастания” thin-файла или раздела (например файла диска виртуальной машины), внутри которого удаляются данные. К сожалению, не имея “арбитра” на уровне приложения, OS, или файловой системы, сторадж не может узнать, вот эти вот блоки, они стерты и больше не нужны, или просто в них давн не пишется, а на самом деле данные в них ценные и их освобождать нельзя. Отчасти эту проблему можно решить, принудительно записывая нули (что, кстати, нынешние файловые системы не делают сами, просто помечая файл у себя как “удаленный”), и считать, что то, где принудительно записаны нули – стерто, и ег можно освободить, и не держать внутри thin-тома, а отдать такое “зануленное” место желающим. Однако общего, стандартного механизма пока не было. А теперь он есть. Начиная с v4.2 при работе по NFS можно обнаруживать такие разрозненные пустые пространства от стертых данных, и освобождать его, “сжимая” файл.

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

Application Data Blocks (ADB) – это механизм для приложений определить некие блоки данных, чтобы затем можно будет заполнять “по шаблону”. Например приложение желает заполнить выделенную область данных определенной сигнатурой. “Классическим образом” вам пришлось бы передать по сети и записать на диск ровно столько блоков, сколько нужно для заполнения нужных областей. Теперь же приложение может определить блок данных как Application Data Block, и заполнить область (с точки зрения приложения) просто указав на этот блок как предопределенный ADB для этой области. Физическое заполнение при этом не происходит, но приложение, обратившись к области данных, получит именно ожидавшееся содержимое.

Aplication I/O Hints – это указание приложением стораджу, средствами протокола, на характер считывания данных с диска. Например: следующие данные будут читаться последовательно, поэтому, пожалуйста, включите на сторадже read ahed. Или, наприме: следующие данные мы будем читать несколько раз подряд. Поэтому включите их постоянное хранение в кэше. Или данные будут записаны, но читать пока мы их не планируем, поэтому не занимайте место в кэше под них. И так далее.

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

А тем временем, в выходные, выкатилась, наконец, Phase 2 обновления самого важного для пользователя сайта NetApp – NetApp Support Site (http://support.netapp.com/), бывшего “NetApp on Web”, NOW (http://now.netapp.com/).

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

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

По работе с новым порталом выпущен специальный 111-страничнй документ, в котором многое расписано подробно и детально. Но начать использовать его можно и “методом тыка”. Попробуйте, нам теперь с этим жить.

Если вы уже используете в админской работе NetApp PowerShell Toolkit, то вы уже знаете, что это такое. Для тех же, кто только подключился, поясню, что NetApp POSH Toolkit это набор разработанных в NetApp так называемых коммандлетов (commandlets), с помощью которых можно расширить и управлять системой хранения с использованием командной оболочки Microsoft Powershell.

Взять текущую версию, недавно обновившуюся до v1.7 можно на сайте NetApp Community (для скачиваня нужно залогиниться):
https://communities.netapp.com/docs/DOC-6138

Полезный документ о использовании средств NetApp Powershell Toolkit , с описанием коммандлетов и способов их использования, можно взять тут:
https://communities.netapp.com/docs/DOC-10684

Также, пользуясь случаем, хочу пригласить вас, раз уж вы завели себе логин в Communities.netapp, в недавно созданную группу для русскоязычных пользователей NetApp-RU на серверах Communities.

На днях увидел в блогах, которые я читаю, интересную статью специалиста Microsoft, о использовании SMI-S провайдера. SMI-S поддерживается системами NetApp FAS уже несколько лет, и я уже очень давно собираюсь написать на эту тему пост. Но как-то он все отодвигается и отодвигается более актуальными темами, я просто приведу вам “для затравки” цитату из той статьи, и предлагаю идти читать остальное уже там:

Storage Management Initiative – Specification или SMI-S, это стандарт управления дисковыми хранилищами, разрабатываемый с 2002 года Storage Networking Industry Association. SMI-S является ANSI и ISO стандартом. Актуальная версия SMI-S 1.5. Более 800 различных аппаратных и 75 программных решений поддерживают данный стандарт. Основная идея стандарта – унификация управления дисковыми хранилищами через веб-запросы.

System Center Virtual Machine Manager 2012 позволяет подключить SMI-S хранилища, так чтобы администратор имел возможность из консоли VMM получать информацию о LUN, группах RAID, свободном месте на хранилище и так далее.

Подробнее – там:

http://blogs.technet.com/b/vm/archive/2012/02/15/smi_2d00_s-support-in-vmm2012.aspx

Несмотря на то, что в оригинальной статье рассматриваются системы EMC, напомню, что SMI-S для NetApp FAS есть, совместим c VMM2012, поддерживаем в MS и NetApp , и работает. Берут SMI-S provider на NetApp Support, где он доступен бесплатно (нужен логин на NOW).

Вид EMC Clariion CX4 из VMM2012 через SMI-S: