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 Grid, доступной для восстановления. 
3. При выполнении задания обслуживания Avamar под названием Garbage Collection (GC) выполняется поиск всех уникальных частей или блоков данных, которые больше не нужны из-за истечения срока действия резервных копий. GC проверяет, что ни одно из текущих хранилищ резервных копий не использует эти же данные (из-за дедупликации), а затем удаляет или освобождает те блоки данных, которые больше не требуются для уменьшения емкости или использования Avamar Server.

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

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

1. Сборка мусора выполняется нерегулярно
2. Сборка мусора работает медленно или недостаточно долго
3. Оценки дедупликации до установки сети Avamar были недостаточно точными
4. На этом сервере Avamar выполняется резервное копирование данных, отличных от тех, которые были рассчитаны до установки сети 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 Integration Resolution Path

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

Шаг 5. Баланс чередования и баланс дисков ОС:

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

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

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

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

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

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

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

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

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

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

В идеале выходные данные должны показывать, что сборка мусора была завершена за последние 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?

a. Выполните следующую команду, чтобы узнать максимальное время, разрешенное для 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 означает неограниченность)

b. Выполните следующую команду, чтобы определить, как долго выполняется сборка мусора и сколько проходов выполнено:
(Проходы связаны со уровнями хранимых данных резервного копирования. Подумайте о 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 (секунд).

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

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

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

Шаг 8. Если есть подозрение, что GC удалил недостаточно или ожидаемые данные:

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

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

b. Используйте эту статью, чтобы найти клиентов с наибольшим коэффициентом изменений: Avamar. Управление емкостью с помощью сценария capacity.sh. (Просмотрите оба "% OF TOTAL" и "CHGRATE".)

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

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

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

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

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

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

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

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

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

dpnctl start sched

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

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

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

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