Авамар: Ємність операційної системи (ОС) (шлях роздільної здатності)

• Базове розуміння контрольних точок (cp), валідація контрольних пунктів (hfscheck), а також Garbage Collection (GC), і важливість кожного з них
• Різниця між GSAN (також відомий як «Об'єм користувача» та «Ємність ОС»)
• Дані про накладні витрати на контрольних пунктах
• Якщо будь-який із розділів даних становить понад 89% загального фізичного простору ОС, збір сміття не може працювати.
• Чим ближче мережа Avamar до 100% споживацької місткості, тим менше ОС доступно для накладних витрат контрольних пунктів.
• Фактори, що впливають на накладні витрати контрольних пунктів, включно з асинхронним кранчуванням, кількістю збережених контрольних пунктів, HFSCheck і важливість валідації контрольних точок тощо.
• Як знайти рівні ємності ОС
• Базові дії для зменшення ємності ОС

Часто найпростіше розглядати ємність ОС як розмір GSAN дані (точніше, простір, виділений для цих даних) та накладні витрати, які генерують контрольні точки Avamar. Чим більша кількість контрольних пунктів і чим вища швидкість зміни, тим вищі накладні витрати на контрольні пункти.

• Збій зі збором сміття: GC провалюється з MSG_ERR_DISKFULL якщо ємність ОС перевищує 89%
• Збій резервного копіювання або реплікації: Резервні копії або вхідна реплікація можуть відмовитися з MSG_ERR_STRIPECREATE, якщо ємність ОС перевищує 90%. (Це відбувається лише якщо потрібно створити нову смугу даних. Якщо нова смуга не потрібна, резервні копії та реплікація все одно можуть успішно працювати.)
• Відмова контрольної точки: Контрольна точка не працює з MSG_ERR_DISKFULL, якщо ємність ОС перевищує 96%

Як може свідчити вищезазначено, ємність ОС часто є першим типом Avamar Capacity, який вирішується, коли інші Avamar Capacity теж високі. Принаймні, Garbage Collection не може бути запущений, коли ємність ОС досягає певного рівня, навіть якщо GSAN Або також висока кількість користувачів.

Зазвичай ємність ОС вважається високою, коли GC виходить з ладу, MSG_ERR_DISKFULL якщо ємність ОС перевищує 89%. Якщо ємність ОС менша за 89%, жодна робота з обслуговування не зачіпається. 

• Висока швидкість зміни резервних даних, додавання «занадто багато, занадто швидко»
• Високий GSAN або «User Capacity», що залишає менше простору для OS Capacity і іноді може призвести до вищих частот змін
• Контрольний пункт не завершився успішно, що призводить до статусу «MSG_ERR_DISKFULL», як видно на результаті.
• Валідація контрольної точки (hfscheck) нещодавно не працював або не працював, тому найстаріші контрольні пункти не можуть відкотитися або бути видалені
• Контрольні точки не скасовуються з інших причин, зокрема надто високих налаштувань утримання контрольних точок

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

• Для короткого розуміння: контрольні точки Avamar — це лише знімок для читання та посилання на живі дані. Оскільки це створюється за допомогою посилань, контрольна точка не займе зайвого місця на диску одразу після створення. Якщо живі дані не змінюються, контрольна точка не використовує додаткового місця.
• Це змінюється, оскільки живі дані змінюються, а контрольна точка залишається незмінною. У цей момент у контрольній точці зберігається оригінальна копія даних і оновлена жива копія змінених даних. Це повністю зроблено навмисно і навмисно. Ось чому існує резервований простір для потужності ОС.
• Однак, якщо кількість або швидкість змін даних різко і раптово зростає, це може спричинити незвичний стрибок у розмірі ємності ОС і вважатися «занадто швидким»
• The capacity.sh Інструмент показував це як причину при порівнянні результатів за кілька днів.

Якщо завдання з обслуговування, включно зі збором сміття, виходять з ладу через високу ємність Avamar OS, дотримуйтесь цих кроків:

1. Зберіть усю інформацію про Avamar Capacity, щоб уявити ситуацію: Авамар: Як зібрати інформацію, необхідну для усунення проблем з пропускною здатністю.

2. Далі перевірте, наскільки висока ємність ОС і які дії можуть знадобитися. Зі статті про збор даних це можна знайти за допомогою наступної команди: 

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

Як працює Avamar: НАЙВИЩЕ значення для fs-percent-full є обмежуючим фактором поточної ємності ОС. Залежно від генерації та розміру типу вузла, кількість розділів даних, що зберігають дані резервної копії та контрольних точок, може варіюватися.

Як видно з операційної системи Linux, це можуть бути диски або розділи на кшталт "/data0*", де "*" може бути однозначною цифрою.

Кількість розділів даних залежить від типу вузла, генерації апаратного забезпечення та розміру (і не може бути змінена).

3. Перегляньте кількість знайдених контрольних точок і наскільки нещодавно вони були підтверджені командою:

cplist

cp.20290310080041 Mon Mar 10 08:00:41 2025   valid rol ---  nodes   4/4 stripes   5980
cp.20290310080649 Mon Mar 10 08:06:49 2025   valid --- ---  nodes   4/4 stripes   5980

4. Перевірте, чи не працюють операції контрольної точки з "MSG_ERR_DISKFULL", виконавши наступну команду:

dumpmaintlogs --types=cp --days=4 | grep "\<430"

Якщо контрольні точки успішно виконані, видно результат, подібний до наступного:

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> completed checkpoint maintenance
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance

Якщо не вдалося через MSG_ERR_DISKFULL, цей вихід видно:

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance

Якщо операції контрольних пунктів не працюють з MSG_ERR_DISKFULL помилки, відкрити запит на сервіс у команді підтримки Dell Technologies Avamar, інакше продовжуйте з кроку 5.

5. Перевірте, чи є інші проблеми з контрольними точками:

The cplist cомманд показує, скільки контрольних точок виявлено і як нещодавно перевірено контрольну точку. Як також показано у статті про збір даних, використовуйте Avamar: Як зрозуміти результат, створений командою cplist, щоб зрозуміти cplist Вихід

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

Якщо за останні 24 години є більше трьох контрольних точок або немає перевірених контрольних точок, це потрібно вирішити спочатку, оскільки це може бути єдиним способом зменшити ємність ОС. Якщо виникає така ситуація, відкрийте запит на сервіс у Dell Technologies, інакше продовжуйте з кроку 6.

6. Визначте швидкість зміни:

capacity.sh  

Приклад результату:

  DATE     AVAMAR NEW     #BU    SCANNED       REMOVED     MINS PASS AVAMAR NET      CHG RATE
========== ============= ==== ============= =============  ==== ==== ============= ==========
2020-02-25       1066 mb    8     302746 mb       -641 mb     0   23        425 mb      0.35%
2020-02-26       1708 mb    8     303063 mb       -518 mb     0   23       1189 mb      0.56%
2020-02-27       3592 mb    8     304360 mb       -413 mb     0   23       3178 mb      1.18%
2020-02-28       1086 mb    8     304892 mb       -372 mb     0   23        713 mb      0.36%
2020-03-01       1002 mb    8     305007 mb      -7469 mb     0   25      -6467 mb      0.33%
2020-03-02        585 mb    7     197874 mb          0 mb     0    9        585 mb      0.30%
2020-03-03        348 mb    7     199305 mb          0 mb     0   10        348 mb      0.17%
2020-03-04        775 mb    7     198834 mb         -2 mb     0   10        773 mb      0.39%
2020-03-05        380 mb    4     196394 mb         -5 mb     0   10        375 mb      0.19%
2020-03-06       1068 mb    4     159960 mb          0 mb     0    9       1067 mb      0.67%
2020-03-07        443 mb    4     197132 mb        -18 mb     0   17        424 mb      0.23%
2020-03-08        348 mb    4     197231 mb        -48 mb     0   20        300 mb      0.18%
2020-03-09        370 mb    4     196506 mb          0 mb     0    9        370 mb      0.19%
2020-03-10        349 mb    4     197292 mb        -17 mb     0   20        332 mb      0.18%
2020-03-11        974 mb    2      77159 mb          0 mb     0    0        974 mb      1.26%
=============================================================================================
 14 DAY AVG       940 mb    5     222517 mb       -634 mb     0   15        306 mb      0.42%
 30 DAY AVG      1121 mb    5     195658 mb       -771 mb     0   14        349 mb      0.59%
 60 DAY AVG       994 mb    4     128657 mb      -1165 mb     0   17       -170 mb      0.98%

Top Change Rate Clients.  Total Data Added 14103mb

     NEW DATA % OF TOTAL CHGRATE TYPE CLIENT
============= ========== ======= ====
      6803 mb     48.24   0.91%  AVA /Windows/testing/Hyper-V/hyperv1
      3218 mb     22.82   0.61%  AVA /clients/exchange1
      2932 mb     20.80   0.44%  AVA /BMR/server1
       983 mb      6.97   0.10%  AVA /Windows/testing/SQL/sql1
        97 mb      0.69   1.13%  AVA /REPLICATE/grid2.company.com/MC_BACKUPS

Іноді, якщо повторюється ситуація з високим темпом зміни або «занадто швидко», це можна полегшити, знизивши загальну GSAN або користувацька ємність.

З нижнім GSAN Є трохи більше простору для накладних витрат на ОС і також призводить до меншої кількості змін у контейнерах зберігання даних.

Для допомоги в такій ситуації відкрийте запит на сервіс у команді підтримки Dell Technologies Avamar, інакше продовжуйте з кроку 7.

7. Проблеми з високою ємністю ОС на інших розділах диска мають різні причини, але рішення потребують технічної підтримки. Відкрийте запит на сервіс у команді підтримки Dell Technologies Avamar для отримання допомоги.

Після того, як ємність операційної системи буде адресована, GSAN ємність або інші можливості Avamar можуть бути переглянуті. Див. Авамар: Діагностика несправностей, проблеми та питання з повністю — всі можливості (шлях вирішення)