about NetApp

Недавно в новостях проскочил пресс-релиз NetApp, о том, что NetApp теперь поддерживает Thin Reclamation API компании Symantec. Эта новость имеет непосредственное отношение к теме Space Reclamation, которую я, кажется, в этом блоге еще не затрагивал.
Что такое Space Reclamation и зачем это вам нужно?

Задача Space Reclamation непосредственно соотносится с процессом использования так называемого Thin Provisioning.
Допустим, что мы создали в сети SAN на системе хранения LUN, на котором создана файловая система, и этот LUN постепенно заполняется данными. Мы решили использовать для этого LUN механизм Thin Provisioning, при котором место под LUN не выделяется сразу (хотя прикладная задача, использующая этот LUN "видит" сразу все заявленное место), а LUN может постепенно расти, по мере того, как на LUN записываются данные.
Настает момент, когда данные заполнили файловую систему, лежащую поверх LUN, и мы начали какую-то часть данных удалять, освобождая свободное место на диске.

Однако, у системы хранения НЕТ возможности понять, что ранее занятые блоки на LUN в созданной на нем файловой системе были освобождены. Вдобавок в современных файловых системах процесс освобождения блоков, использованных тем или иным файлом зачастую ограничивается пометкой в "таблице размещения файлов" (как бы она не называлась) блоков, занятых "удаленным" файлом, как "освобожденных", и только.

Таким образом, без "посредника" на уровне OS, драйвера файловой системы, или того или иного API к файловой системе, система хранения не имеет никаких средств, чтобы определить, что данный блок, ранее чем-либо занятый, больше не используется, и его можно не хранить, занимая место на диске.
Все что знает система хранения, что "вот эти" дисковые блоки были хотя бы раз "потроганы" со стороны хоста, а "вот эти" - нет. Понять, с какой целью они были "потроганы" система хранения не может.

По этой причине график использования места на LUN, с точки зрения системы хранения, почти всегда будет выглядеть примерно так:

Как вы видите, такая ситуация сильно снижает эффективность использования Thin provisioning, так как thin-provisioned LUN всегда однонаправленно растет, и единожды занятое место уже не освобождает, даже если фактически, со временем, он опустел.

Эта проблема присуща ВСЕМ системам хранения, независимо от того, как они работают, это не специфическая проблема NetApp, она присуща любым SAN-системам хранения, на которых хранятся LUN-ы в режиме thin provisioned.  
Повторюсь: без "посредника" на уровне OS узнать о том, что происходит на файловой системе поверх LUN, о том, какие из блоков ее теперь "пусты", и, значит, можно как-то их "оптимизировать" у системы возможности нет.

Так происходит с любыми LUN, в особенности это является проблемой при наличии thin provisioned LUN, так как, уверен, вы рассчитывали на то, что после удаления данных на LUN вы сможете использовать освободившееся место под распределение данных других LUN. Но не тут-то было.

То есть просто организовать использование thin provisioning в системе хранения зачастую недостаточно. Неплохо было бы как-то отрабатывать ситуацию с удаленными на LUN данными, иначе, как мы видим, LUN всегда "однонаправленно" растет в объеме, даже если в дальнейшем его содержимое и опустошается. Это, очень часто, сводит на нет все заманчивые перспективы использования thin provisioning в продакшне.

В 2007-м году в новой версии ПО SnapDrive for Windows появилась реализация механизма "hole punching" для файловой системы NTFS. Работая на уровне OS, SnapDrive "видит" содержимое файловой системы, лежащей на LUN, и коммуницирует с системой хранения, сообщая ей, какие из блоков более данных не содержат, и могут быть безболезненно освобождены.

Запуск процесса Space Reclamation в SnapDrive, может значительно уменьшить занимаемое LUN-ом место на дисках системы хранения, если мы создали его "нефиксированного размера", без "capacity guarantee", то есть в виде, который принято сегодня называть thin provisioned.

Недавно NetApp объявил, что он присоединился к инициативе компании Symantec, разработавшей в 2008 году Thin Reclamation API для своего продукта - Veritas File System (VxFS) и Veritas Volume Manager (VxVM). Ранее о реализации поддержки этого API объявили такие компании, как 3Par, IBM, EMC (Clariion), HP (XP), HDS.

Таким образом, пользователям NetApp теперь доступен механизм Space Reclamation для двух файловых систем - для NTFS через SnapDrive for Windows и для VxFS через Thin Reclamation API.

Механизм работы в принципе довольно прост и стандартен, возможно, со временем, мы увидим его реализацию и для других файловых систем. Используется стандартизованная комитетом T10 (организацией, которая занимается разработкой и стандартизацией протокола SCSI) команда SCSI-3 WRITE_SAME с флагом UNMAP. Также предложена для введения в стандарт собственно команда UNMAP, которая облегчает взаимодействие между инициатором и таргетом, в том числе и в таких задачах.

Широкое распространение этого метода откроет новые перспективы использования динамически распределяемого пространства на системах хранения.

Тема якобы катастрофического уменьшения usable space по сравнению с raw space на системах хранения NetApp занимает, по популярности, у наших конкурентов, пожалуй, третье место, сразу за страшилкой про "ужасную фрагментацию", и пугалкой про "эмуляцию LUN-ов поверх файлов на файловой системе". Про первых две я уже писал, и не по разу, пришла пора разобраться и с этой.
Основой для поста послужил перевод статьи в блоге Recoverymonkey.

Ранее я уже рассматривал "первую часть" ситуации, то, как образуется usable disk space, то есть та емкость, которая остается для использования на дисках, после того, как мы вычтем из них parity, hot spare и ряд прочих "накладных расходов". Однако это еще не все, определенный объем на дисках также занимают различные структуры данных. Я называю получившееся пространство, после того, как из usable disk space вычтутся прочие накладные расходы - usable system space.

Во многих виденных мной у конкурентов "документах" такого рода постоянно рассказывается о том, что, якобы, usable system space на системах хранения NetApp составляет менее 50% от купленного raw, а у одного "последовательного борца" с NetApp даже доходила до анекдотичных 34%.
Это смешно для тех, кто знает, как оно обстоит на практике, но все еще производит впечатление на новичков, тех, кто еще не разобрался с тем, как дела обстоят на самом деле.
Ну хорошо, где же истина, которая, как всегда "где-то рядом"?

Цель данного поста - рассмотреть ситуацию с тем, как и из чего образуется usable space на системах NetApp по состоянию дел и технологий на весну 2010 года.
Так как системы NetApp используют свободное пространство на дисках разными способами, а не просто для "хранения LUN-ов" , это постоянно порождает множество непониманий в том, что означают те или иные понятия и параметры, относящиеся к распределению свободного пространства на дисках системы хранения. При этом ряд рекомендаций NetApp изменялись с течением времени, по мере выхода новых версий их OS и взросления используемых технологий. Наша цель - рассмотреть текущее положение дел и обновить понимание вопроса у тех, кто по тем или иным причинам "отстал".

Коротко, "для тех, кому лень читать все"
(то, что называется "Executive summary" ;)

В зависимости от количества и типа дисков и общего дизайна хранилища, исключая самые маленькие системы с очень небольшим количеством дисков, реальная величина usable space целиком системы NetApp может легко превышать 75% от usable space самих дисков. Я видел, например, величину в 78%. Такое значение, конечно же, обеспечивалось при использовании защиты от двойного сбой (RAID-6/DP) и включала spares. Эта величина показывает "честный" объем хранимых данных для NAS или SAN и не включает в себя дедупликацию, компрессию или клоны типа FlexClone; вместе со всеми перечисленными технологиями, эффективность может легко превысить и 1000%. Во многих случаях клиенты NetApp выбирают их системы хранения как раз именно потому, что системы NetApp настолько эффективны с точки зрения usable space. А теперь перейдем к подробностям…

Continue reading ‘Usable Space у NetApp – что стоит за FUD? (часть 2)’ »

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

Одной из самых популярных “страшилок-говнилок” в отношении NetApp является пугалка о том, как неэффективно расходуется пространство на системах хранения NetApp, как мало получается usable space из данного объема raw. Пожалуй, по популярности эта “говнилка” у наших конкуретнов идет сразу за страшилкой о фрагментации (и ее мифическим “катастрофическим влиянием на производительность”), и за пугалкой про “эмуляцию LUN поверх файловой системы”. Я уже писал ранее про то, как обстоит дело с первой, и рассказывал как устроена организация данных на “низком уровне” в WAFL, объясняющая ситуацию со со второй.

Пришла пора разобрать где правда в третьей.
Итак, правда ли, что usable space на NetApp получается значительно меньше на том же объеме raw, например при сравнении с “более традиционными” системами?

Давайте разберем пример, хоть и не исчерпывающий, но довольно зрелищный.

Continue reading ‘О расчете дискового пространства: NetApp FAS и EMC NS – что стоит за FUD (часть 1)’ »

Довольно долго наблюдаю, как некоторые конкуренты NetApp указывают на то, что системы хранения NetApp якобы лишены механизма Consistency Groups. Для начала, что такое Consistency Group как таковое.

В опеределенных задачах, например в базах данных, при репликации или создания снпшотов, необходимо оперировать двумя и более разделами данных (это могут быть, например, LUN-ы, или разделы NFS) как единой, логически связанной структурой данных.

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

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

Итак, Consistency Groups на NetApp. Какова же ситуация сегодня на самом деле?

Consistency Groups на системах NetApp FAS существуют с версии Data ONTAP 7.2, однако работа с ними со стороны хоста производится через специальный API (ZAPI), который предоставляет, например, ПО SnapDrive. Работать с Consistency Groups можно как непосредственно из SnapDrive (UNIX/Windows), так и вызывая средства API из скриптов, например на Perl.

В рамках этого API так называемый “агент” (это может быть или собственный “высокоуровневый” продукт NetApp, например SnapManager for Oracle, SnapCreator, или же оперирующий вызовами API самодельный скрипт):

• Отдает команду участвующим в процессе контроллеру (или контроллерам, если наша consistency group расположена на разных контроллерах): start-checkpoint.
• Контроллеры приостанавливают (fence) процесс записи на тома, входящие в заданную consistency group (CG).
• Контроллеры подготавливают snapshot для указанных томов.
• Агент получает уведомление fence-success от всех участвующих контроллеров
• Агент отдает команду commit-checkpoint всем участвующим контроллерам
• Приняв команду контроллеры производят одновременное создание снэпшотов томов в CG
• По завершении контроллеры рапортуют об успешном завершении и снимают блокирование записи (unfence).

В случае использования интефейса SnapDrive команда создания снэпшота, использующая CG очень проста.
Допустим, у нас есть база данных (/u01/oradata/prod), расположенная на LUN-ах, лежащая на томах двух контроллеров – filer1 и filer2 (filer1:/vol/prodvol1 и filer2:/vol/prodvol1). Тогда процесс создания консистентной копии в снэпшоте с использованием snapdrive будет прост:

> snapdrive snap create -fs /u01/oradata/prod -snapname snap_prod_cg

Эта команда автоматически инициирует все процессы для всех задействованных в файловой системе /u01/oradata/prod LUN-ов, скомандует их контроллерам, и создаст консистентную копию с именем snap_prod_cg.
Аналогичным образом сработает команда для консистентной копии двух разных файловых систем (u01 и u02):

> snapdrive snap create -fs /u01/oradata/prod /u02/oradata/prod -snapname snap_prod_cg

Так что утверждение, что, якобы, на NetApp нет consistency groups действительности не соответствует. Они есть, работают, и достаточно активно используются, а утверждающим это специалистам конкурентов стоит обновить свои знания о состоянии дел в продукции конкурентов.

Подробнее о Consisency Groups и работе с ними в контексте Oracle:
TR-3858: Using Crash-Consistent Snapshot Copies as Valid Oracle Backups
Очень полезный документ о работе со снэпшотами баз Oracle, использования их как резервных копий, восстановления из них, в том числе много рассматривается тема consistency groups.
Одним из авторов документа является “гуру” темы использования NetApp под Oracle, сотрудник бразильского офиса – Neto, автор весьма интересного (и что еще лучше – регулярно пополняемого) блога на сайте NetApp.

Иногда приходится сталкиваться с неполным пониманием того, что именно и как выводится в команде snap list.

Давайте на примерах разберем “что есть что”, где и как.

У нас есть том vol1 на 100G, практически пустой.

fas3020a> df -h vol1
Filesystem               total       used      avail capacity  Mounted on
/vol/vol1/               80GB       17MB       79GB       0%  /vol/vol1/
/vol/vol1/.snapshot      20GB       61MB       19GB       0%  /vol/vol1/.snapshot
 
fas3020a> snap list vol1
Volume vol1
working…
 
  %/used       %/total  date          name
———-  ———-  ————  ——–
31% (31%)    0% ( 0%)  Mar 08 00:00  nightly.0
47% (29%)    0% ( 0%)  Mar 07 20:00  hourly.0
57% (32%)    0% ( 0%)  Mar 07 16:00  hourly.1
64% (29%)    0% ( 0%)  Mar 07 12:00  hourly.2
69% (32%)    0% ( 0%)  Mar 07 08:00  hourly.3
73% (29%)    0% ( 0%)  Mar 07 00:01  nightly.1
76% (30%)    0% ( 0%)  Mar 06 20:00  hourly.4
78% (31%)    0% ( 0%)  Mar 06 16:00  hourly.5

В этом выводе, колонка %/used показывает объем, занятый снэпшотами, деленный на количество использованных в настоящий момент блоков на томе, независимо от того, заняты ли они в активной файловой системе, или снэпшотах. Первое число – накопительная сумма для всех показанных снэпшотов. Второе число (в скобках) – только для конкретного снэпшота.

Снэпшоты тома vol1 занимают 78% всех занятых на томе блоков, каждый из снэпшотов занимает примерно 29-32% занятых блоков.

Колонка %/total показывает объем занятый снэпшотами, деленный на общий объем диска. Он включает в себя пространство для данных, плюс snapshot reserve, то есть все использованные и свободные блоки тома. На томе 100GB занято примерно 61MB в снэпшотах, что составляет менее 1% общего объема (поэтому значение – 0).
Значение (в скобках) вычисляется аналогично вышеприведенному для %/used.

Давайте посмотрим, как все изменится, если мы уменьшим размер тома vol1 со 100GB до 1GB.

fas3020a> df -h vol1
Filesystem               total       used      avail capacity  Mounted on
/vol/vol1/              819MB       17MB      801MB       2%  /vol/vol1/
/vol/vol1/.snapshot     204MB       61MB      143MB      30%  /vol/vol1/.snapshot

fas3020a> snap list vol1
Volume vol1
working…
 
  %/used       %/total  date          name
———-  ———-  ————  ——–
31% (31%)    1% ( 1%)  Mar 08 00:00  nightly.0
47% (29%)    1% ( 1%)  Mar 07 20:00  hourly.0
57% (32%)    2% ( 1%)  Mar 07 16:00  hourly.1
64% (29%)    3% ( 1%)  Mar 07 12:00  hourly.2
69% (32%)    4% ( 1%)  Mar 07 08:00  hourly.3
73% (29%)    4% ( 1%)  Mar 07 00:01  nightly.1
76% (30%)    5% ( 1%)  Mar 06 20:00  hourly.4
78% (31%)    6% ( 1%)  Mar 06 16:00  hourly.5

Теперь мы видим, что снэпшоты заняли большее относительное пространство на томе в целом (%/total), то есть занятых И пустых, но процент блоков в снэпшотах, относительно всех только занятых блоков на томе (%/used) остался неизменным.

Как всем этим полагается правильно пользоваться?

Величины %/used и %/total полезны при оценке того, насколько правильно выбрана величина snapshot reserve. Нехватка резерва приводит к тому, что снэпшоты “вылезают” за пределы резерва, и начинают занимать место в пространстве данных. Когда команда df показывает величину заняости диска больше 100% – это как раз такой случай: снэпшоты переполнили пространство резерва и начали заполнять пространство собственно данных. Это не страшно, особенно если для тома работает autogrow (и есть место на aggregate) или autodelete (и вы можете безболезненно удалить некоторые старые снэпшоты), но, тем не менее, этого следует избегать для более однозначной организации данных.

Когда вы решаете удалить тот или иной снэпшот, рекомендуется пользоваться командой snap delta или snap reclaimable, чтобы выбрать наиболее эффективный с точки зрения освобождения места снэпшот.
Число после точки в имени снэпшота увеличивается со взятием нового снэпшота. Например, сли вы берете снэпшот каждый час, то hourly.1 взятый в 9 утра, станет hourly.5 в 13:00. Также это работает и в случае daily- или weekly-снэпшотов.
Обратите внимание, что снэпшоты с явно заданным именем (то есть не те, что создаются по расписанию), а также снэпшоты, созданные SnapMirror и SnapVault не изменяют своего имени при создании новых.

Любая сложная электронная система подвержена аппаратным сбоям и ошибкам в ПО. Для того, чтобы предотвратить ее фатальное “зависание”, традиционно используется метод, под названием watchdog, или “сторожевой таймер”. Это аппаратное устройство, которое непрерывно “сбрасывается” в ходе нормальной работы устройства, а в случае его зависания, в свою очередь, сбрасывается им, либо выполняются какие-то специальные действия по немаскируемому прерыванию.

Таким устройством оснащен и NetApp. Его встроенный watchdog непрерывно мониторит состояние системной платы, памяти и карт ввода-вывода. Каждые 10ms Data ONTAP сбрасывает го таймер. Если таймер не сброшен в течение 1,5 секунд, то отдается команда Level 1, по которой формируется прерывание высокого приоритета, и начинается операция core dump. Если и на перывание Level 1 не получено реакции, то через полсекунды инициируется hard reset и перезагрузка системы. В случае перезагузки по Level 2 core dump уже не создается, так как перезагрузка происходит “жестко”.

В случае, если ваш контроллер оснащен RLM или BMC, то эти события регистрируются, и отсылается сообщение Autosupport.

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

Пример сообщения о срабатывании watchdog (из логов RLM):

Sat Feb 20 14:51:49 MST [slcsdcna02: mgr.boot.reason_abnormal:ALERT]: System
rebooted due to a watchdog reset.
System Alert from RLM of slcsdcna02 (REBOOT (watchdog reset)) CRITICAL
Record 600: Sun Oct 18 13:02:50 2009 [Agent Event.warning]: FIFO 0×8FFF - Agent
DrWho, L1_WD_TIMEOUT asserted.

ALUA, или Asymmetric Logical Unit Access это протокол внутри спецификаций SCSI-2 и SCSI-3, позволяющий правильно организовывать доступ к данным, доступным по различным путям с различными характеристиками доступа. Для его использования, понимать ALUA должны все участники, как система хранения, так и OS хоста.

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

Рассмотрим подробнее на рисунке.

Вы видите, что хост, подключающийся к LUN A по пути A, получает данные наиболее “прямым” образом. А хост, подключающийся через второй контроллер, по пути B, хотя и тоже может видеть данные LUN, но получает его данные неоптимально. Его запрос на данные проходит через второй контроллер (FAS B), кластерный интерконнект между контроллерами, попадает на первый контроллер, обрабатывается им, и отправляется к его “owned” дискам. Данные пойдут в адрес запросившего хоста в обратном порядке, с дисков к контроллеру-owner, затем по интерконнекту, на второй контроллер, и через его порты к запросившему хосту. В результате загружаются работой оба контроллера вместо одного, данные загромождают интерконнект, и производительность снижается.

В этом случае вы сможете наблюдать в логах сообщение вида:

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

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

Из операционных систем его поддерживают свежие Linux, MS Windows 2008 со своим DSM и VMware ESX4 (vSphere). Поддержка ALUA есть и в Data ONTAP от 7.3.1.

Рассмотрим, как включить использование ALUA в vSphere.

Убедитесь, что на системе хранения вы используете версию Data ONTAP от 7.3.1 и выше.

FAS1> version
NetApp Release 7.3.1.1: Mon Apr 20 22:58:46 PDT 2009

Включите флаг ALUA  для igroups ESX на каждом из контроллеров системы хранения

FAS1> igroup show -v vmesx_b
    vmesx_b (FCP):
        OS Type: vmware
        Member: 21:00:00:1b:32:10:27:3d (logged in on: vtic, 0b)
        Member: 21:01:00:1b:32:30:27:3d (logged in on: vtic, 0a)
        ALUA: No

FAS1> igroup set vmesx_b alua yes

FAS1> igroup show -v vmesx_b
    vmesx_b (FCP):
        OS Type: vmware
        Member: 21:00:00:1b:32:10:27:3d (logged in on: vtic, 0b)
        Member: 21:01:00:1b:32:30:27:3d (logged in on: vtic, 0a)
        ALUA: Yes

С помощью VMotion переместите все VM с данного хоста ESX на другие хосты кластера и перезагрузите данный сервер ESX.

После перезагрузки значение SATP (Storage Array Type) изменится на VMW_SATP_ALUA, а PSP (Path Selection Policy) на VMW_PSP_MRU. Вам нужно изменить PSP с VMW_PSP_MRU на VMW_PSP_RR. Сделать это можно двумя способами.

1. С помощью NetApp ESX Host Utilities Kit 5.1
#/opt/netapp/santools/config_mpath –m -a CtlrA:username:password -a CtlrB:username:password

После изменений вы получите соответствующее собщение и предложение перезагрузить ESX

2. Вручную
# esxcli nmp satp setdefaultpsp –satp VMW_SATP_ALUA –psp VMW_PSP_RR

Перезагрузка сервера ESX

Проверьте получившеся настройки

#esxcli nmp device

naa.60a9800050334b356b4a51312f417541
    Device Display Name: NETAPP Fibre Channel Disk (naa.60a9800050334b356b4a51312f417541)
    Storage Array Type: VMW_SATP_ALUA
    Storage Array Type Device Config: {implicit_support=on;explicit_support=off;explicit_allow=on;alua_followover=on;{TPG_id=2,TPG_state=AO}{TPG_id=3,TPG_state=ANO}}
    Path Selection Policy: VMW_PSP_RR
    Path Selection Policy Device Config: {policy=rr,iops=1000,bytes=10485760,useANO=0;lastPathIndex=3: NumIOsPending=0,numBytesPending=0}
    Working Paths: vmhba2:C0:T2:L1, vmhba1:C0:T2:L1

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

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

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

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

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

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

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

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

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

Continue reading ‘PAM - Performance Acceleration Module’ »