Снимки (snapshot) в NetApp DataONTAP

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

Что есть снимки (snapshots) в NetApp DataONTAP?

Это моментальный, read-only снимок тома или aggregate.
Сам по себе снимок не содержит никаких данных, помимо данных о состоянии файловой системы в конкретный момент времени.

Снимки лежат в основе технологий SnapDrive, SnapRestore, FlexClone, SnapManager, SnapMirror, SnapVault
Цель снимков – моментальные резервные копии без проседания в производительности СХД и быстрое восстановление.

Как они работают?

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

В процессе модификации исходных данный снимки начинают “занимать” пространство. В примере выше мы перезаписали часть e файла file и дописали к нему часть s’. При этом меняется структура активной файловой системы и она начинает указывать на новые блоки e’ и s’. До тех пор пока существует снимок, указывающий на изначальные блоки они остаются неизменными и недоступными для другого использования.

Количество снимков ограничено 255 на том.
Inodes

Или индексные дескрипторы - структура, которая представляет такие объекты файловой системы как файлы и каталоги. Размером эта структура 192 байта и содержит в себе следующее:

• тип файла (файл, каталог)
• размер
• владелец
• указатель на xinode (ACL)
• в случае если размер файла 64 байта или меньше, то и сам файл
• указатели на блоки с данными

Inode file содержит остальные индексные дескрипторы, которые описывают все остальные файлы в файловой системе. Индексный дескриптор, который описывает сам inode file называется root inode и находится в определенном месте на диске.

Тут, наверное, в воздухе повис вопрос: “К чему я написал последний абзац?” 🙂

Снимок есть копия root inode тома. Inode в снимке read-only, указывает в точности на те же блоки, что и root inode активной файловой системы и занимает место только под себя.

Количество inode – величина конечная, посмотреть ее можно с помощью df -i, а увеличить с помощью maxfiles (не пытайтесь повторить это дома, делайте только под строгим надзором старших из NetApp Support).

Снимки можно создавать для aggregate (в процессе восстановления восстанавливаются все тома) и для тома (можно восстановить том, можно отдельные файлы). По умолчанию существует резерв под снимки и для того (5%) и для другого (20%), при чем если место под снимки израсходовано, то это не значит что вы будете не в состоянии больше их делать. После того. как резерв исчерпан место будет отниматься у полезного пространства тома/aggregate. Изменить процент резерва можно с помощью

snap reserve [ -A | -V ] obj_name percent

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

Если на томе хранятся LUN, то рекомендуется устанавливать резерв в 0%.

Снимки можно создавать и переименовывать руками:

snap create [ -A aggregate | -V volume ] snapshot
snap rename [ -A aggregate | -V volume ] oldsnapshot newsnapshot

и по расписанию:

snap sched vol1 1 2 3 @ 9, 13, 18

Что создает расписание, которое:
создает еженедельный снимок и хранит 1 ревизию
создает снимок в полночь и хранит 2 последних ревизии
создает снимок в начале рабочего дня, перед обедом и по его окончанию

Отключить создание снимков можно с помощью vol options volume nosnap [on|off].
Восстановление снимков

При использовании CIFS и NFS можно воспользоваться замечательной возможность восстанавливать из .snapshot каталога, о котором речь шла выше или с использованием SnapRestore.

LUN можно заменить или, создав его клон из снимка, смонтировать последний на инициаторе и восстановить необходимые файлы.
Удаление снимков

Посмотреть сколько места вы получите после удаления снимка можно с помощью

snap list
snap reclaimable
snap delta

Удалить можно либо отдельный снимок snap delete [ -A | -V] [aggregate | volume] snapshot

либо все целиком snap delete [-A | -V] -a [aggregate | volume]

Посмотрим детально но выхлоп snap list vol0:
?1
2
3
4
5
6
7
8
9
10
11
12
13 Volume vol0
working...

%/used %/total date name
---------- ---------- ------------ --------
1% ( 1%) 0% ( 0%) Jul 13 00:00 nightly.0
2% ( 1%) 0% ( 0%) Jul 12 00:00 nightly.1
14% (12%) 0% ( 0%) Jun 26 08:00 hourly.0
15% ( 1%) 0% ( 0%) Jun 25 08:00 hourly.1
16% ( 1%) 0% ( 0%) Jun 24 08:00 hourly.2
17% ( 1%) 0% ( 0%) Jun 23 08:00 hourly.3
17% ( 1%) 0% ( 0%) Jun 22 08:00 hourly.4
18% ( 1%) 0% ( 0%) Jun 21 08:00 hourly.5
Кто все эти люди?

%/used – показывает соотношение между местом занимаемым снимками и местом занимаемым активной файловой системой. Первое число – сумма всех снимков, (второе) – конкретно данный снимок.

%/total – показывает соотношение пространства занимаемого снимками к общему месту на томе. Включает в себя размер данных + резерв под снимки.

С date и name проблем возникнуть не должно 🙂

Снимки можно автоматически удалять snap autodelete volume option value

option > values
target_free_space > 1-100
delete_order oldest_first, newest_first
SnapRestore

Требует отдельной лицензии и позволяет восстанавливать том целиком, в том числе root (требует перезагрузку). Все снимки, созданные после снимка из которого вы восстановили том будут по понятным причинам удалены. SnapRestore тома нельзя откатить обратно.

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