Avamar GSAN або шлях вирішення User Capacity

Для початкових понять та розуміння ємності операційної системи (OS) див. Avamar: Загальна підготовка спроможності — шлях вирішення

Це часто найпростіше врахувати GSAN Місткість як простір і використання резервних копій клієнтів.

• Базове розуміння дедуплікації
• Базове розуміння контрольної точки, валідація контрольних пунктів (hfscheck), а також «Збір сміття» та важливість кожного з них.
• Різниця між GSAN (або Користувач) Місткість та ємність ОС
• Швидкість зміни
• Стійкий стан

• Помилка резервного копіювання або реплікації, коли стан доступу до мережі змінився на «режим адміністратора»

  • Завдання резервного копіювання клієнта може провалитися через повідомлення, подібне до наступного:  "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 під назвою Garbage Collection (GC), воно знаходить усі унікальні частини або фрагменти даних, які більше не потрібні через ці прострочені резервні копії. GC перевіряє, що жодна інша поточна резервна копія не ділиться тими ж даними (через дедуплікацію), а потім видаляє або звільняє ті шматки даних, які більше не потрібні для зменшення потужності або використання сервера Avamar.

Коли кількість щоденних вхідних даних приблизно дорівнює обсягу щоденних даних, це називається «Сталий стан». Це мета кожної встановленої сітки Avamar.

Перед тим, як налаштувати та налаштувати нову сітку Avamar, проводяться загальні розрахунки розмірів перед встановленням для визначення місткості, необхідної для зберігання резервних даних. Ці розрахунки базуються на вимогах клієнта щодо збереження даних і обсягу даних для резервного копіювання. Вона також оцінює, скільки цих даних може в середньому дедуплікуватися тощо.

1. Збір сміття працює нестабільно
2. Продуктивність Garbage Collection повільна або працює недостатньо довго
3. Оцінки дедуплікації до встановлення сітки Avamar були недостатньо точними
4. Дані, відмінні від тих, що були розраховані до встановлення Avamar grid, резервуються на цей сервер Avamar.
5. Інші причини

Перевірте, що кожен нижче крок усунення несправностей відповідає дійсності для середовища:

Крок 1. Збір даних:

Переконайтеся, що в мережі Avamar немає інших проблем, не пов'язаних із пропускною здатністю. Якщо вони є, вони можуть вимагати уваги ПЕРЕД тим, як встановити здатність до усунення несправностей.

Це включає апаратні помилки, проблеми з цілісністю даних (включно з офлайн-вузлами), офлайн-смуги, збої перевірки контрольних точок або невдалі завдання з обслуговування. Якщо будь-яка з цих проблем виникає, слід припинити діагностику з пропускною здатністю та усунути інші проблеми. Після вирішення інших питань об'єм можна буде переглянути знову.

Слід провести медичну перевірку (Авамар: Як запустити скрипт перевірки здоров'я proactive_check.pl на сервері Avamar, але принаймні status.dpn Command дає швидкий огляд і перевірку більшості тих самих проблем. Див. Авамар: Як зрозуміти результат, створений командою status.dpn

Дивіться наступну статтю для додаткової інформації: Авамар: Як правильно застосувати підхід «ієрархія усунення несправностей Avamar».

Якщо потрібна допомога для вирішення проблем із непропускною здатністю, створіть запит на сервіс у команді підтримки Dell Technologies Avamar.

Крок 2. Збір інформації про спроможність: 

Зверніться до наведення нижче для всієї необхідної інформації для усунення проблем з пропускною здатністю Avamar: Авамар: Як зібрати інформацію для усунення проблем з пропускною здатністю

Принаймні, status.dpn command або значення в інтерфейсі Avamar Administration показують 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 Administration.

• Авамар: Шлях розв'язання пропускної здатності метаданих
• Домен даних: Висока пропускна здатність через шлях розв'язання інтеграції 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 не вдається, спочатку розгляньте це за допомогою наступної статті як джерела: Авамар: Усунення несправностей при зборі сміття (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. Виконайте наступну команду, щоб визначити, скільки часу працює 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 (секунди).

c. Припускаючи, що maxtime ненульова, обчисліть 2/3 maxtime, і порівняйте це з минулим часом.
(У наведеному вище прикладі 2/3 з 14400 дорівнює 9600, і всі вихідні дані за час пробігу значно нижчі за цю цифру.)

Різні проблеми можуть призвести до повільної роботи GC або не сканування всього. Це може включати недостатню кількість часу на роботу протягом значного часу або днів у минулому, неправильну конфігурацію, помилки тощо.

Якщо є занепокоєння щодо maxtime, або кількість пропусків, створіть запит на сервіс разом із командою підтримки Dell Technologies Avamar для подальшого дослідження.

Крок 8. Якщо він підозрював, що GC не видалив достатньо або очікуваних даних:

Якщо підтверджено, що GC працює достатньо довго, можливо, дані не збираються з причин, що виходять за межі контролю Garbage Collection. Ось список задокументованих причин, які зазвичай слід перевірити:

a. Перевірте, чи налаштовані резервні копії принаймні так, щоб вони зрештою або регулярно закінчувалися. Якщо резервні копії не трапляються часто, GC не матиме багато роботи.

b. Скористайтеся цією статтею, щоб знайти клієнтів з найвищою частотою змін: Авамар: Як керувати пропускною здатністю за допомогою capacity.sh скрипта. (Огляд обох "% OF TOTAL" і "CHGRATE".)

c. Перевірте пропущені хеші за Avamar: Avamar Garbage Collection повідомляє про «пропущені хеші», які не можна очистити. Якщо це трапляється, але рідко, це нормально, і це можна пропустити.

d. Існує прапорець або опція, яка змушує сервер Avamar зберігати останню і найсвіжішу резервну копію з кожного клієнта. Це використовується з міркувань безпеки, щоб клієнт випадково не втратив термін дії кожної резервної копії. Однак це може спричинити інші проблеми з очищенням даних і збором сміття. Команда підтримки Dell Technologies Avamar може підтвердити, чи це увімкнено.

e. Якщо резервні копії нещодавно були переключені з GSAN у DD-бекенд або сталася випадковість GSAN Підкріплення, але GSAN Пропускна здатність не зменшується, створіть запит на сервіс до команди підтримки Dell Technologies Avamar для подальшого дослідження.

Крок 9. Сітка Avamar є недостатньою для обсягу поточних або очікуваних даних, які потрібно додати:

Після того, як усі інші рішення та можливі причини будуть розглянуті на предмет великої пропускної здатності, і це не проблема конфігурації чи випадкових даних:

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

Крок 10. Підтверджуйте будь-які події пропускної здатності та за потреби відновіть резервний планувальник:

a. Після вирішення проблем з пропускною здатністю підтверджуйте всі події, пов'язані з ними, у інтерфейсі адміністративного інтерфейсу Avamar.

b. Продовжуйте роботу планувальника резервного копіювання:

dpnctl start sched

Для будь-яких інших питань, навчання, усунення несправностей та іншого щодо Avamar Capacity дивіться: Авамар: Діагностика несправностей, проблеми та питання з повністю — всі можливості (шлях вирішення)

• Ця дія сама по собі може «маскувати» і приховати справжні проблеми, змушуючи їх знову з'являтися через кілька днів або тижнів, через що ця ручна робота стає марною тратою часу.
• Крім того, ручний GC може працювати не так ефективно, бо він вичерпає графік.
  • Іноді це може погіршити інші проблеми. Для детальнішої інформації дивіться: Авамар: Про використання ручного збору сміття

• Ця зміна або дія зазвичай не виконується і не повинна розглядатися за замовчуванням. Інженер Avamar L2 або експерт з предметної галузі (SME) повинен затвердити цю зміну.
• На жаль, такі дії часто можуть завдати постійних пошкоджень сітці Avamar різними способами, які можна усунути лише додаванням додаткових вузлів зберігання або повторним розгортанням.

Розумійте, що жодна з перелічених вище дій не виконується тому, що команда підтримки хоче допомогти вирішити проблеми з Capacity найкориснішим способом.