Avamar v7 і пізніші версії - Збір сміття повідомляє про "пропущені хеші", які не можуть бути очищені через "Hash Referenced Bit Maps" під час використання даних

Функція Hash Referenced Bit Maps — це функція, представлена з функцією Avamar v7.x, яка дозволяє створювати резервні копії під час обслуговування збирання сміття (GC). 

До появи цієї функції збір сміття не міг запускатися одночасно через можливість конфліктів даних. 

Під час фази збору сміття нова функція зберігає в пам'яті інформацію про дані, які додаються або змінюються («карта прив'язаних хешів»). Збір сміття перевіряє цю інформацію, щоб знати, які хеші (і дані, на які вони посилаються) не слід видаляти.  

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

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

Термін дії резервних копій закінчився, але збір сміття не відновив усі дані, які можна було видалити, оскільки деякі дані використовувалися на той час.

Щоб перевірити це, виконайте команду нижче:
Команда скидає журнал обслуговування збору сміття протягом 7 днів і аналізує його, щоб показати.

• Скільки хешів було пропущено,
• Скільки даних було видалено
• Скільки проходів вивезення сміття відбулося
• Скільки часу тривало вивезення сміття

dumpmaintlogs --types=gc --days=7 | grep passes | cut -d ' ' -f1,10,14,15,17

2014/02/11-11:03:23.01310 skipped-hashes="3118" megabytes-recovered="120" passes="10" elapsed-time="134"
2014/02/12-11:05:33.78790 skipped-hashes="4051" megabytes-recovered="88" passes="10" elapsed-time="264"
2014/02/12-16:18:16.79236 skipped-hashes="5098" megabytes-recovered="199" passes="16" elapsed-time="268"
2014/02/12-16:28:20.35698 skipped-hashes="5099" megabytes-recovered="0" passes="1" elapsed-time="97"
2014/02/12-17:14:22.88473 skipped-hashes="5452" megabytes-recovered="26" passes="20" elapsed-time="162"
2014/02/12-20:46:06.80518 skipped-hashes="6789" megabytes-recovered="83" passes="21" elapsed-time="184"
2014/02/12-21:09:30.70374 skipped-hashes="89139" megabytes-recovered="9432" passes="26" elapsed-time="536"
2014/02/12-23:30:13.07016 skipped-hashes="96510" megabytes-recovered="604" passes="21" elapsed-time="210"
2014/02/12-23:34:15.11324 skipped-hashes="96511" megabytes-recovered="1" passes="3" elapsed-time="99"
2014/02/13-13:41:02.20624 skipped-hashes="97301" megabytes-recovered="0" passes="1" elapsed-time="81"
2014/02/14-11:03:45.31704 skipped-hashes="98220" megabytes-recovered="131" passes="2" elapsed-time="157"
2014/02/14-16:49:14.94905 skipped-hashes="98220" megabytes-recovered="67" passes="2" elapsed-time="105"
2014/02/14-21:15:27.77268 skipped-hashes="98224" megabytes-recovered="0" passes="1" elapsed-time="106"
2014/02/14-21:25:51.71154 skipped-hashes="98224" megabytes-recovered="0" passes="1" elapsed-time="101"
2014/02/14-22:07:19.81136 skipped-hashes="98229" megabytes-recovered="0" passes="1" elapsed-time="125"
2014/02/14-22:15:21.50825 skipped-hashes="98275" megabytes-recovered="1" passes="5" elapsed-time="115"
2014/02/14-22:27:13.88500 skipped-hashes="98278" megabytes-recovered="0" passes="1" elapsed-time="98"
2014/02/14-23:58:47.70116 skipped-hashes="102294" megabytes-recovered="1" passes="4" elapsed-time="110"
2014/02/15-11:02:29.45054 skipped-hashes="102538" megabytes-recovered="0" passes="1" elapsed-time="82"
2014/02/16-00:56:27.25596 skipped-hashes="0" megabytes-recovered="900395" passes="59" elapsed-time="17417"
2014/02/17-11:32:42.66479 skipped-hashes="0" megabytes-recovered="57540" passes="28" elapsed-time="1890"

Аналіз:

Вихідні дані показують, що кількість пропущених хешів збільшується з часом, поки карта з посиланнями на хеш не буде скинута 16 лютого 2014 року.
Ми також можемо побачити, що обсяг очищених даних «мегабайт-відновлених» стрибає після того, як хеші звільняються, і збір сміття може обробити їх для прострочених даних.

Негайне рішення

1. Переконайтеся, що карти можуть скидатися та дозволяти повторний збір сміття.
2. Переконайтеся, що немає запущених сеансів avtar, які додають дані в систему (резервні копії або вхідні дані реплікації). Скористайтеся монітором активності графічного інтерфейсу і перевірте, чи не видно завислі сеанси лише за допомогою команди "avmaint sessions --full".
3. Зупиніть усі резервні копії та вхідні сеанси реплікації.
4. Зачекайте принаймні п'ять хвилин, щоб бітові карти з посиланням на хеш мали достатньо часу для скидання.  
5. Коли GC знову запуститься, перевірте журнал обслуговування GC, щоб переконатися, що skipped-hashes=0

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

Довгострокове рішення

Побудуйте графіки резервного копіювання та обслуговування таким чином, щоб був доступний регулярний "простой" для скидання бітової карти,

на яку посилається хеш.Іншими словами, графіки резервного копіювання не повинні працювати 24/7. Побудуйте графік, який дає короткий проміжок часу, коли в систему не записуються резервні копії або вхідні дані реплікації. 

Нотатки: 

• Єдиний випадок, коли бітові карти з посиланнями на хеш перевіряють, чи можна їх скинути, це відразу після завершення сеансу avtar. Якщо сеанси avtar не тривають, карту буде скинуто, лише якщо:

• Однією з причин того, що кількість пропущених хешів може бути тимчасово високою, є розщеплення індексної смуги. Це відбувається тому, що хеші, які переміщуються до розділеної цілі, захищені. Розбиття індексної смуги відбувається в системах, які все ще ростуть або заповнюються даними. 
• Збір сміття також може не працювати з MSG_ERR_TRYAGAINLATER при розщепленні індексних смуг:  
• MCS не обов'язково знає про всі сеанси avtar, які відбуваються на сервері Avamar.