about NetApp

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

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

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

Для ряда приложений, таких как, например, MS SQL Server, MS Exchange, MS Sharepoint, Oracle DB, SAP, существует “коробочный продукт” - Snap Manager для соответствующего приложения.

Но что делать, если приложение есть, а Snap Manager для него нет?

Вот тут на помощь может прийти Snap Creator, в котором можно создать соответствующий процесс, с пре- и пост-процессными скриптами, взаимодействующими с приложением, и помогающими создать конситстентный, корректный и непротиворечивый снэпшот данных.

Продукт интересный, и, как мне показалось, на него NetApp многое ставит, так как разных приложений много, и под все SnapManager не напишешь.

Недавно Snap Creator обновился до версии 3.6.0, и в нем появились новые возможности:

• Появилась поддержка для DOT 8.1 Cluster-mode и 7-mode.
• Поддерживается VMware vSphere 4.1 и 5.0, VMware vCloud Director 1.5.0 и 1.5.1, Red Hat KVM, Citrix Xen.
• Расширены имеющиеся возможности плагинов для Domino Server
• Улучшена поддержка в Protection Manager и взаимодействие со SnapVault
• Улучшен GUI и CLI

Берут его там же, где обычно, на сайте support.netapp.com

Рекомендую также посмотреть несколько видео-скринкастов, чтобы лучше разобраться что к чему.
Например:
Introduction to the NetApp Snap Creator Framework - Version 3.6
Snap Creator Agent Installation on Linux
Snap Creator Installation on Windows
Introduction to the Snap Creator GUI - Working with Backup Profiles and Configuration Files
Snap Creator GUI and SnapMirror
Snap Creator GUI and SnapVault

Остальные видео можно поискать тут: тег snap_creator в communities.netapp.com

Если у вас стоит задача интегрировать какое-то приложение со снэпшотным механизмом NetApp, и для которого нет уже готового SnapManager, или функциональность того, что делает SnapManager вас не устраивает, то Snap Creator для вас, несомненно, первый выбор.

На днях, 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.

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

Не секрет, что с уходом крайне популярной в стране FAS2020 (популярной, прежде всего, за счет цены), и грядущем, вот уже в этом месяце, уходе из продажи FAS2040, в продуктовой линейке опять обнаружился слабый “левый фланг”. FAS2240-2 и FAS2240-4 это, конечно, прекрасные продукты, сами по себе, но они никак не укладываются в психологически важные для данного сегмента лимиты 10-15 тысяч USD.

При этом на рынке обострилась борьба именно в “дешевом” сегменте, в котором нынче заиграли почти все “гранды”, тут и EMC VNXe, и HP MSA2000 и P2×00, и Dell Equallogic PS4100 и Dell Compellent S30. Снизу же сегмент теснят из крайнего low-end и SOHO продукты, широко известные в определенных кругах, QNAP, IOmega и Synology, пытающиеся выбраться из своего “гетто” домашних торрентокачалок.

Поэтому сложившаяся ситуация с исчезновением предложения на “дешевом” конце не могла продолжаться слишком долго. ?? вот ситуация исправлена: FAS2220.

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

Это система “младше” FAS2240, но имеющая контроллер, построенный на той же платформе FAS2200. Разумеется, ради удешевления системы потребовалось чем-то пожертвовать.

В первую очередь, это возможность установки расширения, в контроллере FAS2220 не поддерживаются mezzanine card (по крайней мере на момент объявления системы, но “физически” эта возможность не убита, может быть решение и будет пересмотрено в будущем), на которой расположены порты 10G Ethernet или 8G FC. Зато остались 4 порта Gigabit Ethernet, которые были и на FAS2240, аналогично FAS2040. На HA-пару вы получаете 8 портов GigE, что, в общем, для бюджетного стораджа, вполне неплохо.

Во-вторых, корпус, хотя  представляет собой 2U модуль, не может быть переконвертирован в DS2246, как это можно сделать с FAS2240. В корпус можно установить 12 расположенных горизонтально дисков SAS или SATA (а также и SSD, в составе нового Flash Pool!). Однако, обратите внимание, что диски SAS по какой-то причине нельзя при будущем апгрейде снять и переставить в отдельную дисковую полку. Однако можно это проделать с дисками SATA и SSD.

Помните также, что вы не можете в один корпус включить диски SAS и SSD, так как интерфейс NetApp SSD в настоящее время SATA, а смешивать разные интерфейсы в одной полке нельзя. Таким образом, конфигурация с дисками SATA (и, возможно, SSD), плюс, при необходмости, SAS в полке расширения, в этом случае представляет наибольший интерес. Вы получаете емкое и недорогое хранилище, возможно ускоренное с помощью Flash Pool, плюс, при необходимости, производительное пространство на SAS во внешней полке. При необходимости апгрейда вы сможете перенести диски SATA (и SSD) в полки новой системы, сохранив данные, а дисковую полку просто переключить на новый контроллер, также с сохранением всех данных на них.

В третьих, следует помнить, что емкость новой сстемы составляет всего 60 дисков. Для некоторых, особенно в бюджетном сегменте это не “всего 60”, а “целых 60!”, тем не менее об этом нужно помнить. Это только 12 дисков в “голове”, плюс две полки DS4243 (24+24). Кому-то этого хватит на многое, а кому-то – нет. Здраво оценивайте перспективы роста вашей компании и ее требования к объемам и “шпиндельной” производительности системы.

Плюсы новой системы весьма значительны.

Во-первых это новый контроллер, идентичный FAS2240 по процесору (по-видимому) и по емкости кэш-памяти (6GB/контроллер). Это дает от 3х до 7х прирост производительности на операциях контроллера, по сравнению с FAS2020 (я специально отметил, что прирост контроллера за счет более производительного процессора возможен только для операций контроллера. Если вы используете FAS2020 c 12 дисками SATA, и его производительность ограничена bottleneck-ом этих дисков, то, конечно, просто за счет более быстрго процессора в контроллере 12 дисков быстрее не закрутятся.

Обратите также внимание, что минимальная версия Data ONTAP для FAS2220 – 8.1.1 (как 7-mode, так и Cluster-mode). Все, G7, то есть OS ветки 7.x, на нем не поддерживается.

Во-вторых это поддержка Flash Pool, то есть кэша на дисках SSD, поддержка которого появляется в ближайшие месяцы для систем хранения NetApp, что расширяет возможности очень хорошо принятого рынком Flash Cache, и позволяет использовать возможности кэширования во Flash даже для не поддерживавших Flash Cache систем 2240 и 2220.

В третьих, несмотря на то, что в FAS2220 нет 10G Ethernet, она будет поддерживать Cluster Mode, примерно как он поддерживался в FAS2040, то есть с использованием Gigabit Ethernet. Если вы ориентированы на Cluster mode, это может быть вам особенно интересно. ??спользование для Cluster Interconnect портов Gigabit Ethernet конечно влечет за собой некоторые ограничения, но сама возможность, например включить FAS2220 в качестве вспмогательной системы в “большой” кластер может быть полезна.

Емкость памяти, как и на 2240 – 6GB, из которых 1,5GB – NVMEM. Процессор, как и у 2240, новый Intel, 64bit, 2 процессорных ядра (4 ядра в HyperThreading), 1,7GHz. Для пары контроллров все это богатство, понятно, удваивается.

Модель лицензирования аналогична FAS2240. То есть ВСЕ протоколы в “базе”, плюс Data ONTAP Essentials. За допденьги SnapManager Suite (на все applications разом), SnapMirror, SnapVault, FlexClone и SnapRestore. Либо все разом в составе Complete Bundle по цене дешевле чем “поштучно”.

С “морды”, крышкой, система идентична FAS2240-2.

Под крышкой – 12 дисков, расположенных горизонтально.

Сзади – как FAS2240-2.

Ну, так как до выхода 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, то в этих продуктах новые возможности будут реализованы в скором времени после ратификации стандарта. Насколько будут востребованы новые фичи на стороне клиента – ну тут решать стороне клиента, то есть, в конечном счете – вам.