about NetApp

Предыдущие посты серии:

Первый
Второй
Третий
Четвертый

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

На каждом томе можно создать 254 снэпшота. С учетом максимального количества томов, возможных на системе, получается суммарно около 51 тысячи. Впрочем это скорее теоретическая величина, поэтому заостряться на ней не будем, что же касается снэпшотов то вам их, я полагаю, хватит в любом случае. Напомню, что решения, называющие себя “снэпшот”, у конкурентов обычно заметно ограничивают их количество в 14-30 на всю систему в целом (см. комментарии). Такое ограничение вызвано не в последнюю очередь тем, что использование snapshots у таких систем резко влияет на производительность, и, обычно, снэпшоты на них массово просто не применяются, так как весьма значительно “сажают” производительность системы в целом.

Раз мы добрались до тома и его снэпшотов, позвольте подробнее остановиться на непростой, и вызывающей множество непонимания теме “резервирования” или snapshot reserve.

Когда-то, давным давно, когда NetApp был только NAS системой, было эмпирическим путем определено количество места, которые отводятся и резервируются под снэпшоты, в 20% от общего объема тома. То есть, для простоты понимания на конкретном примере: из тома в 100MB на блоки, зафиксированные в снэпшоте, мы отводим 20MB (на основные данные остается, соответственно, 80MB).

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

В ней, для простоты изображения и понимания, данные, записываемые на том, прирастают снизу.

Блоки, попавшие в снэпшоты, прирастают сверху.

Граница “резерва под снэпшоты” это линия, отделяющая верхние 20% емкости, в которых прирастают (условно сверху вниз) данные снэпшотов.
При этом, граница эта “проходима” сверху вниз, но не снизу вверх. То есть, если случилось так, что снэпшотов создалось больше, чем на 20% резерва, например на 25, то будет заняты “сверху” 20, и плюс еще кусочек на 5% “сверху” от активного тома.

Однако, когда мы попытаемся записать активных данных больше 80MB на 100MB-том с резервом в 20%, даже если это резерв и не используется снэпшотами, мы получим сообщение о нехватке места. То же самое произойдет и если двигающиеся “навстречу” данные “активной файловой системы” и снэпшотов встретятся.

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

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

Можно ли изменять величину снэпрезерва? Разумеется да.
Можно ли поставить ее в 0%? Да.
Отключит ли это возможность создавать снэпшоты на томе? Нет, просто снэпшоты сразу будут занимать место в пространстве “активной файловой системы” тома. Представьте, что граница с рисунка поднята до упора вверх, но она по прежнему проходима для снэпшота, растущего сверху вниз.
Чем это грозит? Да по сути ничем, просто вам надо будет либо не пользоваться снэпшотами (опрометчивый, но имеющий право на существование способ использования стораджа NetApp), либо внимательно контролировать заполнение тома и величину пространства, занятую снэпшотами, чтобы они случайно не исчерпали собой доступное для данных место.
Зачем вообще нужно это резервирование? Ну это просто удобно. Сисадмин системы хранения знает, что у него всегда есть специальный запас места для создания снэпшотов, что туда никто кроме них не залезет и не займет, и снэпшоты, пока это место не переполнится, всегда на томе будет где создать. То есть это просто такое средство немного облегчить жизнь и снизить количество мест, которые надо контролировать.

Традиционно решение ставить snapreserve в 0% применяется при использовании системы NetApp в качестве чистого SAN, когда на volume создается LUN, равный ему по размерам, а создание снэпшотов не используется, и не планируется.
Однако чаще для такой конфигурации, в особенности когда планируется _использовать_ снэпшоты, рекомендуется устанавливать резервирование в 100%. Тогда, даже в самом наихудшем случае, когда все блоки LUN-а изменены, то места на снэпшот хватит.

Я уже писал подробно про этот вопрос в посте про использование “Fractional Reserve”.
Там же я рассказывал про другой способ решения проблемы снэпшота для тома с LUN - автоматическое увеличение тома, опция “autogrow”, в том случае если на aggregate, где он расположен, есть свободное пространство.
Вы можете не резервировать место при создании тома, а просто в свойствах тома сказать, что, когда понадобится, он может расти, занимая под себя свободное место в aggregate.

??так, мы создали том, и задали ему snapshot reservation ту, какую захотели, например 20, или 15% в случае планов использования данного тома под хранение файлов (NAS), 0 или 100%, или определили fractional reserve, опции autogrow и autodelete, при использовании его для размещения на нем LUN-а.

…и почти добрались до конца. Теперь давайте посмотрим, что же у нас получилось с usable.
Окончание (надеюсь) в следующий понедельник (надеюсь).