Avamar. Емкость GSAN или пользовательская емкость, алгоритм решения

Для первоначальных концепций и понимания возможностей емкости операционной системы (ОС) см. Avamar. Общее обучение по емкости — алгоритм решения

Зачастую проще всего рассматривать емкость GSAN как пространство и коэффициент использования для резервного копирования клиентов.

• Базовое понимание дедупликации
• Базовое понимание контрольных точек, валидации контрольных точек (hfscheck) и очистки памяти, а также их важности.
• Разница между емкостью GSAN (или пользовательской) и емкостью ОС
• Скорость изменения
• Устойчивое состояние

• Сбой резервного копирования или репликации, когда состояние доступа к сети изменилось на «admin mode»

  • Задание резервного копирования клиента могло завершиться сбоем с сообщением, аналогичным следующему:  »avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
• Автоматическое отключение планировщика резервного копирования (до подтверждения и удаления кем-либо)

• 80% — предупреждение о емкости
• 95% — Достигнут предел диагностики системы (это иногда может отключать планировщик резервного копирования, по крайней мере до тех пор, пока не будет вручную подтверждено)
• 100% — Достигнут предел только для чтения сервера (сеть переходит в режим администратора)

1. Из-за дедупликации Avamar необходимо сохранить и хранить только незначительные изменения и различия между каждым заданием резервного копирования клиента. По мере запуска новых резервных копий (или входящей репликации) они могут добавлять новые данные и увеличивать емкость или коэффициент использования Avamar. 
2. По истечении определенного времени срок действия резервных копий истекает в зависимости от настроенного срока хранения и истечения срока действия, и их не удастся найти в сети Avamar для восстановления. 
3. Когда выполняется задание обслуживания Avamar, называемое очисткой памяти (GC), оно находит все уникальные части или фрагменты данных, которые больше не нужны из-за истечения срока действия этих резервных копий. GC проверяет, что никакие другие текущие резервные копии не используют эти же данные (из-за дедупликации), а затем удаляет или освобождает эти фрагменты данных, которые больше не требуются, для сокращения потребляемой емкости или коэффициента использования Avamar Server.

Если количество ежедневно добавляемых входящих данных примерно равно количеству ежедневно очищаемых данных, это называется «устойчивым состоянием». Это цель каждой установленной сети Avamar.

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

1. Очистка памяти выполняется несогласованно
2. Производительность очистки памяти низкая или она выполняется недостаточно долго
3. Оценки дедупликации до установки сети Avamar были недостаточно точными
4. На этот Avamar Server выполняется резервное копирование данных, отличных от тех, которые были рассчитаны перед установкой сети Avamar.
5. Другие причины

Убедитесь, что каждое из приведенных ниже действий по поиску и устранению неисправностей подходит для среды.

Шаг 1. Сбор данных

Убедитесь, что в сети Avamar нет других проблем, не связанных с емкостью. Если такие проблемы есть, то им нужно уделить внимание ДО ТОГО, как начать устранение проблем с емкостью.

В эту категорию входят ошибки оборудования, проблемы целостности данных (включая автономные узлы), сбои полосы в автономном режиме, сбои проверки контрольных точек или сбои заданий обслуживания. Если присутствует какая-либо из этих проблем, необходимо остановить поиск и устранение неисправностей емкости и устранить другие проблемы. После устранения других проблем можно вернуться к проблеме емкости.

Необходимо выполнить диагностику системы (Avamar. Как запустить сценарий диагностики системы proactive_check.pl на Avamar Server), но как минимум команда status.dpn может быстро выдать общее представление и проверить большинство из этих проблем. См. Avamar. Как понять выходные данные, сгенерированные командой status.dpn

Дополнительные сведения см. в следующей статье. Avamar. Правильное применение подхода «иерархия поиска и устранения неисправностей Avamar».

Если для решения проблем, связанных с отсутствием емкости, требуется помощь, создайте сервисную заявку в службе поддержки Dell Technologies по Avamar.

Шаг 2. Сбор информации о емкости 

Все необходимые сведения для устранения проблем с емкостью Avamar см. в следующих документах: Avamar. Как собрать информацию для устранения проблем с емкостью

По крайней мере команда status.dpn или значения в пользовательском интерфейсе администрирования Avamar показывают емкость GSAN .

Шаг 3. Проверка заполнения емкости ОС

Приведенная ниже команда помогает отобразить текущее значение емкости ОС для каждого раздела диска. Если какое-либо из значений достигло или превысило 85%, как во втором образце выходных данных, это считается высоким уровнем заполнения емкости ОС:

avmaint nodelist | egrep 'nodetag|fs-percent-full'

Примеры выводов:

nodetag="0.2"
        fs-percent-full="56.6"
        fs-percent-full="54.7"
        fs-percent-full="54.4"
        fs-percent-full="54.6"
        fs-percent-full="54.7"
        fs-percent-full="54.7"
      nodetag="0.1"
        fs-percent-full="56.2"
        fs-percent-full="54.6"
        fs-percent-full="54.6"
        fs-percent-full="54.8"
        fs-percent-full="54.8"
        fs-percent-full="54.5"
      nodetag="0.0"
        fs-percent-full="56.2"
        fs-percent-full="54.7"
        fs-percent-full="54.8"
        fs-percent-full="54.7"
        fs-percent-full="54.6"
        fs-percent-full="54.6"

nodetag="0.2"
        fs-percent-full="94.5"
        fs-percent-full="94.4"
        fs-percent-full="94.2"
        fs-percent-full="94.1"
        fs-percent-full="94.0"
        fs-percent-full="94.0"
      nodetag="0.1"
        fs-percent-full="94.5"
        fs-percent-full="94.3"
        fs-percent-full="94.1"
        fs-percent-full="93.6"
        fs-percent-full="94.0"
        fs-percent-full="93.9"
      nodetag="0.0"
        fs-percent-full="94.4"
        fs-percent-full="94.4"
        fs-percent-full="94.0"
        fs-percent-full="94.1"
        fs-percent-full="92.7"
        fs-percent-full="92.5"

Только если емкость ОС ниже 85%, следует продолжать поиск и устранение неполадок емкости GSAN . 

Шаг 4. Проблемы, не связанные с емкостью, которые иногда могут быть неправильно поняты как проблемы с емкостью

Резервное копирование клиента может завершаться сбоем не по причинам «емкости», а по причинам «квоты». Иногда их могут неправильно интерпретировать как проблемы емкости.

Эту ситуацию можно подтвердить с помощью команды status.dpn или некоторых других собранных выходных данных, показывающих более низкую емкость.

Кроме того, возможно, что резервное копирование клиента завершилось сбоем или не было выполнено из-за других причин, связанных с емкостью Non-GSAN . Собранная информация должна подтвердить это, или это можно увидеть в пользовательском интерфейсе администрирования Avamar.

• Avamar. Алгоритм решения емкости метаданных
• Data Domain. Высокая занимаемая емкость из интеграции Avamar, алгоритм решения

Если занимаемая емкость GSAN высокая, а другие занимаемые емкости также высоки, поиск и устранение неисправностей можно выполнять в любом порядке (за исключением емкости ОС, с которой всегда нужно начинать).

Шаг 5. Баланс страйпа и баланс диска ОС

«Страйпы» в Avamar — это файлы контейнеров, в которых хранятся данные резервного копирования на узлах данных (за исключением одноузловой сети Avamar).

Ожидается, что страйпы «сбалансированы» или равномерно распределены между различными дисками и узлами в сети, однако иногда они могут стать несбалансированными.

По замыслу в Avamar самый большой узел или раздел диска является ограничивающим фактором, когда речь идет о емкости Avamar.

Это сделано преднамеренно, чтобы ни один из дисков или узлов не создавал больше страйпов, чем они могут обработать (или разрешено), поэтому сбалансированные страйпы важны для емкости.

Например, при добавлении дополнительных узлов данных для расширения сети Avamar необходимо выполнить балансировку, чтобы равномерно распределить страйпы на новые узлы и уменьшить общую емкость Avamar в процентах.

Другой тип баланса, требующий понимания, — это баланс диска ОС. Он ограничивается только разделами данных на одном узле, а не разделами на нескольких узлах. 

Если на одном узле данных один раздел намного больше или меньше другого раздела ТОГО ЖЕ узла, может быть превышено ограничение, называемое «freespaceunbalance». Хотя обычно это происходит с емкостью ОС, а не с емкостью GSAN , это может быть воспринято как проблема емкости GSAN .

Шаг 6. Проверьте, завершается ли очистка памяти 

Выполните следующую команду, чтобы получить информацию об очистке памяти:

dumpmaintlogs --types=gc --days=30 | grep "4201\|2402"

В идеале в выходных данных будет показано, что GC завершалась за последние 30 дней:

2025/10/07-12:00:35.24911 {0.1} <4201> completed garbage collection
2025/10/08-12:00:34.61185 {0.1} <4201> completed garbage collection
2025/10/09-12:00:35.14874 {0.1} <4201> completed garbage collection
2025/10/10-12:00:34.67986 {0.1} <4201> completed garbage collection
2025/10/11-12:00:34.73284 {0.1} <4201> completed garbage collection
2025/10/12-12:00:33.23205 {0.1} <4201> completed garbage collection
2025/10/13-12:00:33.41448 {0.1} <4201> completed garbage collection
2025/10/14-12:00:35.70726 {0.1} <4201> completed garbage collection
2025/10/15-12:00:35.08316 {0.1} <4201> completed garbage collection
2025/10/16-12:00:34.82681 {0.1} <4201> completed garbage collection
2025/10/17-12:00:35.29262 {0.1} <4201> completed garbage collection
2025/10/18-12:00:35.24618 {0.1} <4201> completed garbage collection
2025/10/19-12:00:34.56531 {0.1} <4201> completed garbage collection
2025/10/20-19:06:45.15574 {0.1} <4201> completed garbage collection
2025/10/21-12:00:34.21062 {0.1} <4201> completed garbage collection
2025/10/22-12:00:35.29770 {0.1} <4201> completed garbage collection
2025/10/23-12:00:36.13041 {0.1} <4201> completed garbage collection
2025/10/24-12:00:35.52502 {0.1} <4201> completed garbage collection
2025/10/25-12:00:35.93730 {0.1} <4201> completed garbage collection
2025/10/26-12:00:35.55037 {0.1} <4201> completed garbage collection
2025/10/27-12:00:36.12049 {0.1} <4201> completed garbage collection
2025/10/28-12:00:35.75633 {0.1} <4201> completed garbage collection
2025/10/29-12:00:34.85499 {0.1} <4201> completed garbage collection
2025/10/30-12:00:34.96325 {0.2} <4201> completed garbage collection
2025/10/31-12:00:35.39840 {0.0} <4201> completed garbage collection
2025/11/01-12:00:35.11248 {0.0} <4201> completed garbage collection
2025/11/02-13:00:34.39202 {0.0} <4201> completed garbage collection
2025/11/03-13:00:34.70587 {0.0} <4201> completed garbage collection
2025/11/04-13:00:34.18799 {0.0} <4201> completed garbage collection
2025/11/05-13:00:34.44950 {0.0} <4201> completed garbage collection

Сообщения о сбое GC могут включать, помимо прочего, следующее:

2025/11/04-13:00:01.62234 {0.1} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR

2025/11/01-12:35:06.62868 {0.2} <4202> failed garbage collection with error MSG_ERR_BACKUPSINPROGRESS

2025/10/13-12:20:07.35498 {0.7} <4202> failed garbage collection with error MSG_ERR_TRYAGAINLATER

2025/10/27-12:07:44.35485 {0.0} <4202> failed garbage collection with error MSG_ERR_DISKFULL

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_MISC

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_TIMEOUT

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_GARBAGECOLLECT

Если происходили сбои GC, сначала устраните эту проблему, используя следующую статью в качестве справки: Avamar. Поиск и устранение сбоев очистки памяти (GC) (алгоритм решения)
(Если какие-либо проблемы уже устранены, перейдите к следующему шагу.)

Шаг 7. GC выполняется достаточно долго?

а. Чтобы проверить максимально допустимое время для GC, выполните следующую команду:

dumpmaintlogs --types=gc --days=30 | grep gcflags 

Пример вывода:

2025/10/07-12:00:20.05509 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/08-12:00:20.09141 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/09-12:00:20.42307 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/10-12:00:20.47775 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
...
2025/11/02-13:00:19.76100 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/03-13:00:19.92093 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/04-13:00:19.42781 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/05-13:00:19.74984 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>

Запишите значение maxtime , которое в данном примере составляет 14400 (секунд).
(Значение 0 означает неограниченное количество)

б. Выполните следующую команду, чтобы определить, как долго выполняется GC и сколько завершено «проходов»:
(Проходы относятся к уровням сохраненных данных резервного копирования. Представьте емкость GSAN как слои лука. Внешние слои должны быть очищены или удалены до того, как будут видны внутренние слои. Каждый проход представляет собой слой сохраненных данных GSAN .)

dumpmaintlogs --types=gc --days=30 | grep passes | cut -d ' ' -f1,14-20

Пример вывода:

2025/10/07-12:00:35.24463 passes="24" start-time="1758283220" elapsed-time="250" end-time="1758283235"/>
2025/10/08-12:00:34.60779 passes="3" start-time="1758369620" elapsed-time="70" end-time="1758369627"/>
2025/10/09-12:00:35.14232 megabytes-recovered="1" passes="4" start-time="1758456020" elapsed-time="85" end-time="1758456028"/>
2025/10/10-12:00:34.67590 passes="3" start-time="1758542420" elapsed-time="72" end-time="1758542427"/>
...
2025/11/02-13:00:34.38348 megabytes-recovered="2" passes="18" start-time="1762088419" elapsed-time="89" end-time="1762088427"/>
2025/11/03-13:00:34.69743 passes="18" start-time="1762174819" elapsed-time="9" end-time="1762174828"/>
2025/11/04-13:00:34.17943 megabytes-recovered="8" passes="22" start-time="1762261219" elapsed-time="134" end-time="1762261228"/>
2025/11/05-13:00:34.44187 megabytes-recovered="2" passes="16" start-time="1762347619" elapsed-time="119" end-time="1762347628"/>

Запишите количество проходов и elapsed-time (секунд).

в. При условии, что maxtime не равно нулю, вычислите 2/3 от maxtime, и сравните его с прошедшим временем.
(В приведенном выше примере 2/3 из 14400 равно 9600, и все выходные данные за прошедшее время значительно ниже этой цифры.)

Из-за различных проблем GC может работать медленно или сканировать не все данные. К таким проблемам относится недостаточное время для выполнения в течение значительного количества времени или дней в прошлом, неправильная конфигурация, ошибки и многое другое.

Если есть опасения по поводу maxtimeили количества проходов, создайте сервисную заявку в службе поддержки Dell Technologies по Avamar для дальнейшего изучения.

Шаг 8. Если предполагается, что GC не удалила достаточно данных или ожидаемый объем данных:

Если будет подтверждено, что GC работает достаточно долго, возможно, данные не собираются по причинам, не зависящим от очистки памяти. Ниже приведен список задокументированных причин, которые обычно необходимо проверить.

а. Убедитесь, что для резервных копий настроено регулярное или любое истечение срока действия. Если срок действия резервных копий не истекает часто, у GC будет не много работы.

б. Используйте эту статью для поиска клиентов с самым высоким коэффициентом изменений: Avamar. Как управлять емкостью с помощью сценария capacity.sh. (Просмотрите «% OF TOTAL» и «CHGRATE».)

в. Проверьте наличие пропущенных хэшей по инструкции в статье Avamar. Очистка памяти Avamar сообщает о «skipped-hashes», которые нельзя очистить. Если они встречаются редко, это нормально, и это действие можно пропустить.

г. Существует флаг или параметр, который заставляет Avamar Server сохранять последнюю и самую актуальную резервную копию от каждого клиента. Он используется в целях безопасности, чтобы срок действия всех резервных копий случайно не истек. Однако это может привести к другим проблемам при очистке данных и очистке памяти. Служба поддержки Dell Technologies по Avamar может подтвердить, включен ли этот параметр.

д. Если резервные копии были недавно переключены с GSAN на внутренний сервер DD или случайно создана резервная копия GSAN , но емкость GSAN Не уменьшается, создайте сервисную заявку в службе поддержки Dell Technologies по Avamar для дальнейшего изучения.

Шаг 9. Размер сети Avamar слишком мал для объема текущих или ожидаемых добавляемых данных

Когда все другие решения и возможные причины высокой занимаемой емкости будут рассмотрены, и не выявлена проблема конфигурации или случайных данных:

Это означает, что для данных может потребоваться удаление, или такие варианты, как перенос определенных клиентов в другие сети Avamar, добавление новых узлов данных и т. д.

Шаг 10. Подтвердите любые события емкости и при необходимости возобновите работу планировщика резервного копирования

a. После устранения проблем с емкостью подтвердите все события, связанные с емкостью, в пользовательском интерфейсе администратора Avamar.

б. Возобновите работу планировщика резервного копирования:

dpnctl start sched

Любые другие вопросы о емкости Avamar, обучение, поиск и устранение неисправностей и многое другое см. в статье: Avamar. Поиск и устранение неисправностей емкости, проблемы и вопросы — вся емкость (алгоритм решения)

• Это действие само по себе может «маскировать» и скрывать реальные проблемы, чтобы они снова появились через несколько дней или недель, а значит время на выполнение этого задания вручную было потрачено зря.
• Кроме того, ручная GC может работать не так эффективно, как если бы она выполнялась в соответствии с расписанием.
  • Иногда это может усугубить другие проблемы. Подробнее см. в статьях: Avamar. Об использовании ручной очистки памяти

• Это изменение или действие, как правило, не выполняется и не должно рассматриваться по умолчанию. Это изменение должно быть утверждено инженером Avamar L2 или профильным специалистом (SME).
• К сожалению, подобные действия часто могут привести к различным необратимым повреждениям в сети Avamar, которые можно устранить только путем добавления дополнительных узлов хранения или повторного развертывания.

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