Что такое aggregate snapshot reserve и зачем он нужен?
Я уже несколько раз упоминал в этом блоге о aggregate snap reserve, пришла пора подробнее рассказать о том, что это, зачем использутся, и нужно ли это вам.
Вы уже наверняка знаете, что такое и зачем используется Snapshot reserve на уровне тома. Это некий зарезервированный объем общего пространства соответствующего тома, используемый для того, чтобы обеспечить доступность пространства на дисках при создании снэпшотов состояния тома. Это некая условная “граница”, которую может превысить снэпшот, но не может превысить содержимое тома, пользователю тома доступно для записи место, равное объем тома минус резервация на снэпшоты. Это резервирование гарантирует доступность места для хранения данных снэпшотов, а также упрошает администрирование тома, так как пока снэпшоты не вышли за пределы отведенного резерва, свободное пространство, доступное для записи на томе, стабильно и предсказуемо.
Подробнее и с поясняющими картинками про принцип работы Snap Reserve я писал в посте ранее.
Отмечу также, что величина резерва, заданная по умолчанию в 20% от объема тома может быть изменена, и 20% это не hardcoded value, а просто такая вот эмпирически выбранная когда-то величина “по умолчанию”. Можно сделать 50, 15, 10, и даже 0%. Например 0% сегодня рекомендованная величина Snapshot Reserve в случае использования тома для хранения SAN LUN-ов (вместо Snapshot Reserve используется Fractional (или LUN Overwrite) Reserve, о смысле которого я уже также ранее писал).
С Volume Snap Reserve мы более-менее разобрались, но что же такое и зачем нужен Aggregate Snap Reservation, равный, по умолчанию, 5% от объема aggregate?
Aggregate, по сути, представляет собой свообразный мета-volume, просто такой своеобразный том, находящийся в иерархии уровнем ниже обычного FlexVol-тома. Соответственно, задача у этой резервации точно такая же – хранить блоки, использованные в снэпшоте уровня aggregate.
Что же такое “снэпшот уровня aggregate”, кто его делает и зачем он используется?
Снэпшоты на aggregate использует, например, средство SyncMirror, это средство синхронной репликации, используемое, например, в решении MetroCluster.
Кроме того, такие снэпшоты используются для работы средства контроля целостности файловой структуры WAFL, аналога UNIX-ного fsck, ооочень редко на практике применяемого средства WAFL_check (я знаю немало админов NetApp, которые вообще не в курсе, что такое средство у NetApp есть).
WAFL как “файловая система”, вследствие своей архитектуры, поразительно устойчива, 99% админов NetApp действительно никогда не сталкиваются с необходимостью “лечить” WAFL. “Уронить” WAFL в принципе возможно (“Если один человек чего сделал, то другой завсегда сломать может”(с)) но это, как показывает моя практика, довольно нетривиальная задача.
Если вы “уронили” WAFL настолько, что потребовалось использование WAFL_check, то очень сильно сократить этот процесс может наличие автоматически создаваемых снэпшотов аггрегейта. Впрочем, как я знаю, он заработает и без них, однако, на большой системе, починка может занять на пару порядков больше времени, вместо десятков минут – несколько дней.
Также, с использованием снэпшотов уровня aggregate вы можете сделать SnapRestore для aggregate целиком, вместе со всеми томами и LUN-ами на нем, если зачем-то это вам понадобилось.
Кроме этого следует обратить внимание, что какой-то объем пространства на уровне aggregate (то есть не распределенного в volumes, а непосредственно в aggregate) используют следующие средства:
- Deduplication начиная с версии 7.3 хранит свою базу fingerprints непосредственно на уровне aggregate, таким образом, при использовании deduplication вам понадобится какое-то небольшое пространство на aggregate не занятое томами, обычно в зарезервированные 5% эта база помещается
- Синхронная версия репликации SnapMirror до версии 7.2.2 записывала данные, попадающие в NVRAM, в специальный файл на root volume по пути /etc/sync_snapmirror_nvlog/<dstfsid>.log[0|1]. Начиная с 7.2.7 эти данные пишутся также на уровне aggregate. Руководство Data ONTAP Online Data Backup and Recovery Guide рекомендует, в случае использования Sync SnapMirror иметь на aggregate место в объеме 20x емкости NVRAM на системе-получателе (destination).
(обратите внимание, что у NetApp есть два различных средства synchronous replication – SyncMirror и SnapMirror Synchronous mode) - Наконец, не стоит забывать, что запас незанятого места на aggregate довольно значительно снижает величину фрагментации, а правильнее “non-contiguous block factor”. Напомню, что файловая система (любая, NTFS, ext3, WAFL, почти любая современная файловая система), когда ей необходимо записать файл, сперва ищет у себя фрагмент непрерывно свободного пространства, куда и пишет содержимое этого файла. Если, как это обычно бывает при сильно заполненной файловой системе, такого места отдельным, непрерывным куском нет, то файловая система начинает дробить записываемые данные файла на более мелкие фрагменты, которые уже могут располагаться непоследовательно. В наихудшем случае, файловая система располагает свободным местом только в виде отдельных, непоследовательных блоков, разбросанных по файловой системе. Наличие запаса свободного места с точки зрения файловой системы резко улучшает эту ситуацию, и позволяет не накапливать фрагментацию.
Таким образом, как вы видите, идея держать гарантированно небольшое свободное пространство на уровне aggregate имеет определенные основания на системном уровне. Если вы уверены, что ничем из перечисленного вы не пользуетесь, а 5% зарезервированных на aggregate вам жалко, то вы можете уменьшить эту величину, аналогично ситуации с volume snap reservation, , например до 2-3%, практика показывает, что этого достаточно. Можно, хотя это и не рекомендуется, и вовсе отключить эту резервацию. Обратите также внимание, что, как и в случае с volume snap reserve, отключение reservation не отключает возможность использования snapshots, если на структуре (volume или aggregate, соответственно) есть свободное место. Это просто средство некоторого упрощения жизни и работы админа, и только.
Помните, тем не менее о том, что у NetApp за каждым default value стоит какая-то причина, и прежде чем вы не уясните эту причину, я бы не рекомендовал “твикать” не глядя, это все же не “реестр венды” ;).
Посмотреть текущее состояние резервирования и назначенное расписание создания снэпшотов на aggregate:
fas1> snap sched –A - установлено расписание создания снэпшота aggregate в 9, 14 и 19 часов, и хранение с ротацией одного дневного и 4 таких "почасовых" снэпшота.
Aggregate aggr0: 0 1 4@9,14,19
fas1> snap sched –A aggr0 0 0 0 - создание снэпшотов aggregate aggr0 отключено.
Для изменения величины или отключения резервирования на aggregate вам нужно использовать команду:
fas1> snap reserve –A aggr0 3 – устанавливаем величину резервирования для aggr0 равную 3%