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

Summary: Ця стаття Шляху вирішення призначена для вирішення або усунення проблем із ємністю операційної системи (ОС) на Avamar.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Symptoms

Як вирішити або усунути проблеми з ємністю ОС на Avamar.

Ця стаття про шлях вирішення призначена для вирішення або виправлення проблем із ємністю ОС в Avamar.


Для початкових концепцій та розуміння ємності ОС дивіться навчальну статтю Avamar: Концепції управління потенціалом та навчання

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

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

 

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


Наслідки високої ємності ОС можуть включати:

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


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

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

 
Примітка: Очікується, що ємність ОС коливатиметься протягом дня. Перевірка того, що щоденні завдання з обслуговування виконуються безперебійно, є важливим і, як правило, найкращим рішенням для уникнення проблем із ємністю ОС, коли це можливо.
 
Примітка: Хоча вищезазначене розглядається як ємність ОС Avamar, можливо, можуть виникнути проблеми з ємністю ОС, не пов'язані безпосередньо з резервними розділами або контрольними точками. Це диски і розділи, на які встановлюється ОС Linux. Хоча ці проблеми менш поширені, вони можуть мати інші наслідки, які обговорюються нижче.

Cause

Ємність Avamar OS може збільшуватися з будь-якої комбінації наступних причин:

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

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

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

Resolution

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

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


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

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

Принцип роботи Avamar полягає в тому, що НАЙБІЛЬШЕ значення для fs-відсотків-заповнення, що відображається, є обмежуючим фактором для поточної ємності ОС. Залежно від типу вузла, генерації та розміру, кількість розділів даних, що зберігають дані резервних копій та контрольних точок, може варіюватися. Як видно з операційної системи 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. Перевірте, чи немає інших проблем з контрольно-пропускними пунктами:
 
Об'єкт cplist cOmmand Показує, скільки контрольно-пропускних пунктів знайдено та як нещодавно було перевірено контрольно-пропускний пункт. Як також показано в статті про збір даних, використовуйте 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, в іншому випадку перейдіть з кроку 7.

 
 

Як тільки ємність ОС буде вирішена, GSAN місткість або інші можливості Avamar можуть бути переглянуті. Дивіться Усунення несправностей Avamar Capacity Troubleing, Issues and Questions - All Capacity (Resolution Path)

 

Affected Products

Avamar, Avamar Server
Article Properties
Article Number: 000169014
Article Type: Solution
Last Modified: 12 Mar 2025
Version:  7
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.