about NetApp

Тема магнитных лент не отпускает долго. Тем не менее, приближаемся к финалу.

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

Однако в комментариях подсказали и еще один кейс. Дело в том, что “оффлайновое” хранение данных в случае ленты облегчает неизменямое хранение сохраненных данных. Ведь в случае онлайн-хранения на дисках, при всех плючах такого хранения, сохраняется определенная опасность того, что онлайн-копия може быть случайно или злонамеренно повреждена. Особенно это важно в случаях, когда немодифицируемое долговременное хранение определено соответствующим законодательством страны. Так, например, такие условия хранения архивных данных определены в США для публичных компаний (акт Sarbanes-Oxley), для биржевых брокеров (SEC Rule 17a-4), компаний, работающих в области здравоохранения (HIPAA), правительственных учреждений (DOD 5015.2) и других случаях. Зачастую в этих требованиях фигурируют сроки такого хранения, исчисляемые десятками лет.

Для решеня этой залачи у NetApp есть сравнительно малоизвестная в России функция, и о которой я пока еще не писал, но которая, тем не менее, по понятным и описанным выше причинам, широко применятся в инсталляциях за рубежом – SnapLock.

Я уже рассказывал, что лежащая в основе всех систем хранения NetApp пециальная файловая структура – WAFL, имеет одну очень интересную особенность. Эта особенность, в свою очередь, определяет один из базовых приципов ее работы, используемой системой.

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

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

Таким образом, мы видим, что заблокировав в OS одну единственную функцию, которая помечает блоки данной файловой системы как неиспользуемые, мы легко превратим наш раздел на системе хранения в строгий WORM (write once, read many).
У системы хранения просто не будет никакой физической возможности внести изменения в уже записанные данные, а при необходимости, даже заблокировать удаление их.

Именно этот функционал в NetApp называется опцией SnapLock.

SnapLock существует в двух вариантах, отличающихся строгостью их использования: SnapLock Compliance и SnapLock Enterprise.

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

Менее строгая SnapLock Enterprise позволяет, также как и для SnapLock Compliance, задавать период неизменяемого хранения, однако “высший” администратор системы хранения, по-прежнему не имея возможности изменить хранимые данные, может, при необходимости, такой том удалить целиком.

Таким образом, использование SnapLock на системах хранения NetApp может помочь реализовать заведомо надежно защищенное от возможности удаления или изменения данных хранилище, в тех случаях, когда такие требования стоят во главе угла.

Совсем недавно я рассазывал о том, что такое Flash Cache (PAM-II) и как он работает, а вот уже и новости подоспели. NetApp объявила, что с сентября 2009 года, когда был объявлен Flash Cache и начались его поставки, c с системами хранения NetApp продан уже петабайт емкости на flash-памяти в Flash Cache.

Напомню, что Flash Cache это устройство в виде платы расширения, содержащее 256 или 512GB SLC NAND Flash, и устанавливаемое в системы хранения  FAS3×00 и FAS6000. Максимальная емкость  в самых старших системах линейки может достигать 4TB на систему. Использование Flash Cache позволяет значительно повысить быстродействи операций в IOPS, снизить время отклика (responce time, latency), увеличить энергоэффективность решения за счет отказа от многочисленных  “дисковых шпинделей” и можества дисковых полок, необходимых для обеспечения быстродействия системы, и заменяемых на Flash Cache.

В отличие от уже становящегося традиционным использования flash в форме SSD, то есть хранилища данных, дисков, Flash Cache работает как кэш “второго уровня”, в форме “памяти”, обеспечивая решение проблемы “холодных данных”, и повышая эффктивность использования дорогостоящего SLC Flash.

Подробнее о Flash Cache, как и о PAM-I, можно прочитать в переведенном руководстве Flash Cache (PAM-II) and PAM: наилучшие методы использования (PDF)

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

Свою программу сертификации имеет и NetApp. В этом посте я остановлюсь на “инженерских” сертификациях (кроме них существует еще сертификация для сотрудников компаний-партнеров и продавцов).

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

В настоящее время у NetApp есть два инжеренских “уровня” сертифиации:

• NCDA – NetApp Certified Data Administrator, “базовый”
• NCIE – NetApp Certified Implementation Engineer, “продвинутый”.

Для сертификации NCDA необходимо сдать или два экзамена, NS0-153 (Storage Networking) и NS0-163 (Data Protection Solutions), или один недавно объявленный NS0-154 (Data ONTAP 8.0 7-Mode Data Administrator), про который мало что пока известно (и дампов нет;). После успешной их сдачи (75 вопросов каждый, полтора часа, проходной 80%, стоимость одного экзамена – 150$) вы получаете уровень NCDA (Professional). Сертификация действительна на протяжении 2 лет, после чего ее надо либо подтвердить новыми на тот момент экзаменами того же уровня, либо сертифицироваться с повышением уровня.

Сдавать экзамены можно до 4 раз на протяжении 12 месяцев, интерал между сдачами - 10 дней

Следующая ступень – NCIE (Specialist), существует на сегодня в двух версиях: NCIE-SAN, по которой сдается экзамен NS0-501 (SAN), а c 1 июня вместо него сдается новый экзамен NS0-502 (SAN+Virtualization), и NCIE-BR, на который сдается экзамен NS0-510 (Backup and Recovery).

Ранее еще существовали экзамены NS0-520 – Disaster Recovery и NS0-530 – Storage Security, которые на сегодня уже не заказываются и соответствующие специализации NCIE не сдаются.

Главный официальный источник информации о программах сертификации и подготовке – вебстраничка на сайте NetApp University: http://www.netapp.com/us/services/university/certification.html
FAQ по сертификации и экзаменам: http://www.netapp.com/us/services/university/certification-faq.html

В помошь готовящимся к NCDA существует два полезных материала:

• официальный NCDA Bootcamp Training Review
• и неофициальный NetApp Study Notes

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

К сожалению у меня тут в блоге правило – не публиковать данные, доступные мне из “закрытых источников”. Поэтому приходится ждать, пока кто-нибудь в интернете их опубликует до меня, после чего со спокойной совестью можно публиковать их и мне, не светя мои “источники”. Так как “платные” отчеты IDC и Gartner мне дают “на поглядеть”, несмотря на то, что данные там очень любопытные, приходится ждать, пока они не “утекут” у кого-нибудь еще. :)

Не раз у меня спрашивали подтверждение того моего утврждения, что “NetApp входит в “символическую пятерку”, Top-5, мировых производителей систем хранения”, а, например, Sun или HDS в нее не входят.

IDC приводит по этому поводу следующие данные:

Как вы видите в этом списке второе и третье место, с весьма неплохим ростом и увеличивающимся отрывом от, например, HP, занимают NetApp и, между прочим, его OEM-партнер IBM, довольно неплохо продающий NetApp под своей маркой IBM N-series. По объемам же счисленных не в долларах, а в “петабайтах проданного пространства” (это другой отчет IDC)  NetApp уже давно и прочно сидит на втором месте, периодически поджимая саму EMC (разница между позициями “в долларах” и “в петабайтах” отчасти определяется спецификой методики измерения IDC, отчасти тем, что “терабайт” у NetApp покупателю обходится дешевле).

По поводу же приметного роста выручки стоит упомянуть тот реально фантастический рывок, который NetApp сделала, согласно недавнему финансовому отчету компании, удвоив чистую прибыль за IV квартал 2009 года, закончившегося 30 апреля (то есть, по сути, в первом квартале календарного года).
Весьма эффектно, кстати, на это отрегировал фондовый рынок:

Стоимость акций компании после публикации финансового отчета за считаные часы выросла на 20%.

Недавно вышедшая в релиз Data ONTAP 8.0, среди всего прочего, принесла с собой новые, расширенные аггрегейты, так называемые 64-bit aggregates.

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

Однако, в версии Data ONTAP 7 максимальный размер aggregate не мог превышать 16TB даже на самых мощных системах FAS6000, что определенным образом снижало возможную производительность на дисковых операциях. Например, в случае использования дисков SATA 2TB, уже поставляемых NetApp, это ограничивает размер aggregate всего восемью такими дисками, что, очевидно, сегодня совершенно недостаточно.

Начиная с версии Data ONTAP 8 поддерживается новая структура под названием 64-bit aggregate, его предельный размер зависит от типа контроллера системы хранения, и варьируется от 30TB на самой младшей из поддерживающих его систем – FAS2040, до 100TB на системах FAS6080. В числе прочего это позволяет создать на таком aggregate непрерывный том данных такого размера.

Для использования 64-bit aggregates необходимо помнить следующее:

• Из систем FAS2000 они поддерживаются только на FAS2040.
• По умолчанию aggregate создается “старого” типа. Для создания именно 64-bit aggregate, необхдимо создавать его с использованием специального ключа –B
  fas1> aggr create aggr_64 –B 64 24@868  - создать aggregate под названием aggr_64, тип “64-bit aggregate”, и включить в него 24 диска размером минимум 868GB
• Преобразовать “старый” aggregate в новый, 64-bit - нельзя.
• Aggregate для root volume должен по прежнему быть “32-bit”.
• Использование 64-bit aggregate ведет к увеличению расхода памяти на метаданные. Это может вести, в ряде отдельных случаев, к ухудшению производительности на некоторых типах нагрузки. В этом случае очень эффективно может проявить себя PAM в режиме кэширования metadata only.
• Операции Volume Snapmirror, vol copy и aggr copy могут осуществляться только для aggregates одинакового типа. Однако QTree Snapmirror, SnapVault и ndmpcopy, не зависяшие от “геометрии” продолжают работать и на aggregates разного типа.
• Дедупликация по прежнему ограничена размером тома 16TB максимум (и далее в зависимости от типа контроллера, например 4TB для FAS3140)
• Ограничения на размер отдельного файла и LUN сохраняются теми же, что и в Data ONTAP 7.3

Подробноее про 64-bit aggregate можно почитать тут:
A Thorough Introduction to 64-Bit Aggregates
http://www.netapp.com/us/library/technical-reports/tr-3786.html

Несколько ранее я рассказывал уже о средствах анализа нагрузки системы по протоколу CIFS, например с помошью команды cifs top. Для анализа статистики нагрузки протокола NFS пригодится команда nfsstat.

В своем обычном виде команда nfsstat показывает общую статистику по всму трафику NFS и RPC, и полезна при настройке и поиске ошибок сетевой передачи. Однако, если вы включите в системных опциях Data ONTAP по умолчанию выключенную опцию nfs.per_client_stats.enable, то вам будет доступна статистика отдельно по каждому клиенту NFS (под клиентом понимается хост, но не пользователь).

Включим учет статистики раздельно по клиентам:

fas1> options nfs.per_client_stats.enable on

fas1> nfsstat –h [ip | hostname] – покажет статистику отдельно по конкретному клиенту

fas1> nfsstat –l – покажет статистику по 256 клиентам по убыванию NFS-активности

Подробнее о команде:
http://now.netapp.com/NOW/knowledge/docs/ontap/rel732_vs/html/ontap/cmdref/man1/na_nfsstat.1.htm

FlexShare это технология управления приоритетами в обслуживании томов данных, своеобразный квази-QoS (хотя и не QoS в чистом виде). Эта технология входит во все современные версии Data ONTAP, бесплатна, однако сравнительно малоизвестна.
FlexShare задает отноительный приоритет (а не абсолютный, как в “чистом” QoS) обслуживания для томов данных. Если с ее помощью вы зададите пониженный приоритет томам данных, используемым для, например, хранения дистрибутивов, образов виртуальных машин, резервных копий, и прочих данных, время доступа к которым не является для ваших задач критичным, и наоборот, повысите приоритет для томов с базой данных или критичными для бизнеса виртуальными машинами, то контроллер будет распределять свое “внимание” и процессорные “тики” не равномерно, как по умолчанию, а в соответствии с заданными приоритетами. В результате вы сможете несколько улучшить показатели быстродействия для критичных данных.

no FlexShare

with FlexShare

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

fas> priority on

Для более детального управления следует воспользоваться командой priority set:

fas> priority set volume vol1 level=high system=low cache=reuse

Эта команда указывает высокий приоритет обслуживания тома vol1 для операций пользователей и приложений, устанавливает для данного тома пониженный приоритет системным задачам его обслуживания, а также задает политику использования кэша с более быстрым сбросом (flush) его содержимого, по сравнению c политикой по-умолчанию.
Уже установленные приоритеты можно посмотреть с помощью команды:
fas> priority show volume

Остальные опции команды priority вы как всегда можете найти во встроенном хелпе и в выводе команды help priority.

Компания NetApp опубликовала результаты тестирования 4Gb FC и Software iSCSI по 1Gb Ethernet и 10Gb Ethernet в среде MS Hyper-V R2 с использованием своей системы хранения NetAp FAS3160A (система midrange-класса).

Тестирование производилось с помощью IOmeter (о котором я уже не раз писал в блоге), с 4 хост-серверов IBM x3550 (1x Quad-core Intel Xeon E5420, 2,5GHz), на каждом из которых бы установлен Windows 2008 R2 c Hyper-V role и 8 виртуальными машинами в каждом, с Windows 2008 64-bit Enterprise edition (итого 32 виртуальных машины). Интерфейсы каждого сервера: FC – QLogic QLE2462, Gigabit Ethernet – Intel PRO/1000 PT dual port, 10G Ethernet – Intel Ethernet Server Adapter X520, включались в коммутаторы Brocade 200E, Cisco 4948 Ethernet Switch и Fujitsu XG1200 соотвественно.
Особое внимание при тестировании уделялось получению результатов, приближенных к “боевым”, позволяющим использовать их для оценки реальной, “живой” инфраструктуры Hyper-V.

Использовался паттерн: 100% Random, 75% Read, 4KB и 8KB Request size.

Тесты показали сравнительно незначительную разницу между всеми тремя вариантами (4Gb FC, 1Gb software iSCSI, 10Gb software iSCSI) как в IOPS, так и в Latency. Дополнительная загрузка задачи softwre iSCSI initiator составила 3-5 процентов, в том числе и на 512 outstanding IOs (очень высокая загрузка), и разница со значением загрузки при использовании FC уменьшалась с повышением объемов загрузки (Outstanding IOs).

Показательно почти полное отсутствие значимого отличия по быстродействию между 4Gb FC и 1Gb iSCSI на рассматриваемой задаче.
Отсутствие значительной разницы между 1Gb Ethernet и 10Gb Ethernet по видимому связано с тем, что Software iSCSI initiator на 10G Ethernet перестал быть эффективен, и, возможно, следует рассмотреть использование iSCSI HBA для таких высокоскоростных решений.
Также сравнительно небольшую разницу дает включение и использование Jumbo Frames как на 1G Ethernet, так и на 10G Ethernet, что скорее всего говорит о специфике Hyper-V R2 в этом вопросе.

Лимит по производительности системы хранения FAS3160A для такой конфигурации не был достигнут.

Подробности и полный документ по результатам –тут:
http://www.netapp.com/us/library/technical-reports/tr-3846.html

При выходе из строя жесткого диска система начинает процесс RAID reconstruction. Время его завершения зависит от загрузки системы задачами ввода-вывода и установленного приоритета задачи реконструкции. Это приоритет (вернее степень влияния на производительность системы в целом задачей реконструкции) может быть настроен с помощью системной опции:

fas1> options raid.reconstruct.perf_impact [high | medium | low]

Обратите внимание, эта опция и ее изменение глобально (для всех RAID-групп системы в целом), и, что важно, не работает для уже запустившейся reconstruction. То есть увидеть слишком долгий процесс восстановления, поменять ее на high и ждать, что процесс ускорится, не стоит.

По умолчанию она установлена в medium, и менять ее стоит только если вы в самом деле хорошо представляете зачем вы это делаете.

Вот уже пару лет как у NetApp в номенклатуре продуктов находится интересный, но все еще не слишком известный широкому кругу пользователей продукт – PAM – Performance Acceleration Module, а в прошлом году к нему в компанию добавился еще один вариант – PAM-II (ныне Flash Cache).

Давайте разберемся подробнее что это, чем полезно и как применяется.

Первое, что следует понимать, чтобы разобраться в том, что есть PAM и как его применяют:
PAM это не SSD!

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

Давайте разберемся, что такое SSD, и чем PAM не SSD.

Continue reading ‘PAM - Performance Acceleration Module’ »