Проблемы и решения Usable Space. Часть 5.

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

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

Итак, 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.
Окончание (надеюсь) в следующий понедельник (надеюсь).

5 комментариев

  1. А для чего применяется резервирование на уровне агрегата?

  2. ivs:

    На счет кол-ва снапшотов, к примеру для самого “младшенького” из HDS AMS:

    Snap per source 32
    Snap source volumes per system 1023
    Snap volume clone per system 2046

    …так что на счет 14-30 на систему я бы поостерегся. На счет младшего из CX4 - того самого CX4-120:

    Snap per source 8
    Snap source volumes per system 128
    Snap volume clone per system 512

  3. Да, спасибо, счас поправлю.

  4. > А для чего применяется резервирование на уровне агрегата?

    Про резервирование на софтверном уровне я еще отдельно напишу.
    А что имеется ввиду под “на уровне агрегата”?

  5. sas-2:
    Спасибо, кстати, за хороший вопрос про agregate level snap reservation, вещь это так редко упоминаемая, что пришлось покопаться в доках :)

    В двух словах и на пальцах: так как в каком-то смысле aggregate это тоже такой псевдо-volume, то на нем тоже возможны снэпшоты.
    Однако в реальной жизни они почти не применяются, места их использования можно посчитать по пальцам одной руки. Это такие операции, как aggr copy - внутрисистемное копирование содержимого агрегата, а также RAID SyncMirror, используемый, например, в системах MetroCluster, а также можно сделать snapshot (и, соответственно, snap restore) для всего aggr целиком. Также снэпшоты используются при некоторых операциях проверки WAFL, при его неконсистентности.
    При них действительно создаются snapshots на уровне aggregate, но в _реальной_, моей и вашей жизни ;) они не используются, поэтому резервирование на уровне aggregate чаще всего не нужно, и его смело можно обнулить:
    > snap sched -A [aggrname] 0

    Параноики могут оставить процента 2-3. :)

    Напомню также, что _резервирование_ для снэпшотов играет роль только в том случае, если ваш aggregate полностью заполнен (и поэтому места под снэпшот может не найтись), резервирование дает гарантию того, что место найдется в любом случае. Если aggregate не заполняется на все 100% своего объема, беспокоиться о переполнении нечего.

Оставить комментарий

20/0.138

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией 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.