about 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 не изменяют своего имени при создании новых.

SnapVault это “двухкомпонентная” система резервного копирования данных D2D, “с диска на диск”, основнанная на технологии снэпшотов.

Система SnapVault состоит из двух участников: системы хранения с лицензией SnapVault Primary, работающая “источником” данных, и системы с лицензией SnapVault Secondary, “получатель и хранитель” данных, в качестве которой может выступать как система NetApp FAS, так и специально разработанная для подобных применений, система Nearstore - емкое дисковое хранилище на недорогих SATA-дисках.

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

Использование же снэпшотов в NetApp удобно в том числе и для сравнительно долговременного хранения, делая из них своеобразный “дисковый бэкап”, для мгновенного восстановления данных пользователя, в случае необходимости. Просто дайте команду snap restore [мой том] [нужный снэпшот], или же просто скопируйте из снэпшота нужные файлы, созданные в желаемый момент времени, поверх испорченных в вашем томе.

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

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

При первой инициализации Primary SnapVault-система передает на Secondary полную копию своего содержимого, так называемую baseline. Это продолжительный и объемный процесс, сравнимый с классическим full backup. После этого, Secondary-система всегда передает только содержимое снэпшотов, “дифференциальные копии” системы, разницу между состоянием от предыдущего и нынешнего состояния и содержимого данных.

Пример:
У нас есть база данных размером 1GB. Мы делаем с нее ежечасный снэпшот, и этот снэпшот хранится на Secondary SnapVault-системе. Каждый час в системе накапливается примерно 2MB измененных данных. Это могут быть новые записи или изменения в старых.
При создании baseline copy, при первичной инициализации, Primary-система передает весь этот 1GB на вторичную систему. Когда передача завершена, первичная система начинает ежечасно передавать примерно 2MB в час. Однако, с точки зрения пользователя, на вторичной системе он видит, словно бы полную копию, созданную ежечасно. Видит, и может ее использовать и восстановить свой раздел и данные из нее, также как с обычным снэпшотом. Разница заключается только в том, что места на дисках используется всего 2MB*24h в день, не считая объема baseline copy, которая создается один раз в самом начале.

Подобная практика сейчас стала популярной и в традиционных системах резервного копирования, обычно под названием “forever incremental” и подобных ему, когда full backup создается один раз, а затем делается только incremental, а при необходимости восстановления восстанавливается Full и все необходимые Incremental с момента создания исходного Full, а для пользователя каждый бэкап представляется полной копией системы.
Удобство SnapVault в данном случае в том, что эта функция оказывается встроенной в систему хранения, и не требует использования внешних host-based систем резервного копирования.

Для не-NetApp систем хранения, возможно использование в качестве Primary и так называемой OSSV - Open Systems SnapVault, специального программного агента, стоящего на хост-сервере, к которому подключена сторонняя система хранения, или даже его локальные диски, и осуществляющего функции Primary SnapVault, как раассмотрено выше. Secondary SnapVault и в этом случае должен быть системой NetApp FAS или Nearstore. С помощью OSSV вы можете использовать возможности SnapVault и без необходимости использовать систему хранения NetApp в качестве Primary.

Любопытно, что сегодня в SnapVault интегрирована и дедупликация, так, если ваша Secondary-система имеет лицензию дедупликации, то процесс дедупликации будет запущен после окончания передачи baseline copy, и сможет, в ряде случаев заметно, уменьшить, хранимые на Secondary объемы baseline.