Archive for июня 2010

SnapLock – неизменяемое сохранение данных на дисках

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

В прошлой и позапрошлой статье под заголовком “Так ли незаменимы магнитные ленты для бэкапов” я рассмотрел два популярных “кейса”, считающихся классической “вотчиной” ленточного метода хранения, а именно: удаленное хранение копии и “длиные” 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 может помочь реализовать заведомо надежно защищенное от возможности удаления или изменения данных хранилище, в тех случаях, когда такие требования стоят во главе угла.

Так ли незаменимы магнитные ленты для бэкапа? Часть 4

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

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

Давайте посмотрим, насколько длинный цикл retention мы можем организовать с помощью систем NetApp FAS и их возможности создавать снэпшоты.

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

  • “Часовой” снэпшот, с интервалом каждые 6 часов круглосуточно, с хранением затем в течении суток.
  • “Дневной” снэпшот, каждый день, всю неделю, в 10 вечера, с хранением в течении 4 месяцев
  • “Недельный” снэпшот, каждое воскресенье в 10 вечера, с хранением на 2 года
  • “Месячный” снэпшот, каждое первое воскресенье месяца, с хранением на 7 лет

Example   Schedule

Retention

Schedule

Frequency

Time

Hourly

Every 6 hours

4AM, 10AM, 4PM

24

Hours

Daily

Mon-Sun

10PM

90

Days

Weekly

Every Sunday

10PM

104

Weeks

Monthly

1st Sunday in Month

10PM

84

Months

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

Итого такая схема ротации всего в 245 снэпшотов на том позволит нам иметь цикл непрерывной ротации бэкапов данного тома, ни много ни мало – 7 лет!

Петабайт флэша

Совсем недавно я рассазывал о том, что такое 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)

Так ли незаменимы магнитные ленты для бэкапа? Часть 3

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

Continue reading ‘Так ли незаменимы магнитные ленты для бэкапа? Часть 3’ »

Так ли незаменимы магнитные ленты для бэкапа? Часть 2

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

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

Разберем их чуть детальнее:

Continue reading ‘Так ли незаменимы магнитные ленты для бэкапа? Часть 2’ »

Так ли незаменимы магнитные ленты для бэкапа? Часть 1

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

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

Тем не менее давайте посмотрим на нынешнее положение в отрасли и оценим, возможно не все кругом – гвозди, и есть возможность не заколачивать шурупы молотком.

Continue reading ‘Так ли незаменимы магнитные ленты для бэкапа? Часть 1’ »

Сертификация по NetApp

Сертификация по продуктам есть хорошо известная среди 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 существует два полезных материала:

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

Про Top-5 производителей систем хранения

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

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

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

 

I кв. 2010

I кв. 2009

Годовой рост выручки

Выручка

Доля рынка

Выручка

Доля рынка

1. EMC

$1 222

24,6%

$888

21,0%

37,6%

2. IBM

$579

11,7%

$476

11,2%

21,6%

3. NetApp

$550

11,1%

$373

8,8%

47,4%

4. HP

$506

10,2%

$482

11,4%

5,0%

5. Dell

$500

10,1%

$410

9,7%

21,8%

Другие

$1 601

32,3%

$1 605

37,9%

-0,3%

Всего

$4 959

100,0%

$4 235

100,0%

17,1%

 

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

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

ntap-finance2

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

 

64-bit aggregates в Data ONTAP 8

Недавно вышедшая в релиз 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

18/0.176

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

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.