Avamar v7 e versioni successive - Garbage Collection che segnala "skipped-hashes" che non può essere pulito a causa di "Hash Referenced Bit Maps" quando i dati sono in uso

La funzionalità Hash Referenced Bit Maps è una funzionalità introdotta con la funzionalità Avamar v7.x che consente di eseguire backup durante l'attività di manutenzione della Garbage Collection (GC). 

Prima di questa funzione, la garbage collection non poteva essere eseguita contemporaneamente a causa della possibilità di conflitti di dati. 

Durante la fase di garbage collection, la nuova funzionalità mantiene in memoria le informazioni sui dati che vengono aggiunti o modificati (una "mappa di hash di riferimento"). La Garbage Collection controlla queste informazioni per sapere quali hash (e i dati a cui fanno riferimento) non devono essere rimossi.  

Un requisito di questa funzione è che queste "mappe" richiedono almeno 5 minuti di tempo "silenzioso" durante il quale non si verificano backup per poter essere reimpostati. Una volta eseguito questo ripristino, i dati bloccati in essi possono essere analizzati durante il successivo ciclo di garbage collection, purché rimangano invariati.

Questo tempo di attesa deve essere considerato durante la progettazione del programma di backup e manutenzione giornaliero di Avamar. 
L'impossibilità di reimpostare le mappe può impedire alla garbage collection di pulire i dati scaduti.
Se la mappa di riferimento dell'hash non ha l'opportunità di eseguire il reset, i dati che dovrebbero essere idonei per la rimozione da garbage non vengono elaborati e l'utilizzo della capacità potrebbe aumentare. Se la mappa non è in grado di eseguire il reset per un periodo di tempo prolungato, il log della garbage collection potrebbe mostrare una quantità crescente di "hash ignorati".

I backup sono scaduti, ma la garbage collection non ha ripristinato tutti i dati idonei per l'eliminazione perché alcuni dei dati erano in uso in quel momento.

Per verificare questa condizione, eseguire il comando riportato di seguito:
Il comando esegue il dump del registro di manutenzione della garbage collection per 7 giorni e lo analizza per visualizzarlo.

• Quanti hash sono stati ignorati,
• Quantità di dati eliminati
• Quanti passaggi di garbage collection sono stati eseguiti
• Per quanto tempo è stata eseguita la garbage collection per

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"

Analisi:

L'output mostra il numero di hash ignorati che aumentano nel tempo fino a quando la mappa di riferimento hash non viene reimpostata il 16 febbraio 2014.
È inoltre possibile visualizzare la quantità di dati puliti "megabyte-recovered" che saltano dopo che gli hash vengono liberati e la garbage collection può elaborarli per i dati scaduti.

Soluzione immediata

1. Assicurarsi che le mappe possano essere reimpostate e consentire la nuova esecuzione della garbage collection.
2. Assicurarsi che non vi siano sessioni avtar in esecuzione che aggiungono dati al sistema (dati di backup o di replica in ingresso). Utilizzare Monitoraggio attività GUI e controllare le sessioni bloccate visualizzate solo con il comando
"avmaint sessions --full".3. Arrestare tutti i backup e le sessioni di replica in ingresso.
4. Attendere almeno cinque minuti per consentire il ripristino di Hash Referenced Bit Maps.  
5. Quando il GC viene eseguito nuovamente, controllare il registro di manutenzione del GC per verificare che gli hash ignorati=0

Se gli hash ignorati non sono stati reimpostati su zero, utilizzare il supporto per controllare due volte i passaggi precedenti. Se i report di garbage collection MSG_ERR_TRYAGAINLATER, il supporto può verificare se ciò è dovuto all'attività di suddivisione dello stripe dell'indice. 
 

Soluzione a lungo termine

Progettare le pianificazioni di backup e manutenzione in modo che sia disponibile un normale "inattivo" per la mappa dei bit di riferimento dell'hash da reimpostare.

In altre parole, le pianificazioni di backup non devono essere in esecuzione 24 ore su 24, 7 giorni su 7. Creare una pianificazione che fornisca una breve quantità di tempo quando non vengono scritti backup o dati di replica in ingresso nel sistema. 

Note: 

• L'unica volta che le mappe di bit di riferimento dell'hash verificano se possono essere reimpostate è subito dopo il termine di una sessione avtar. Quando non è in corso alcuna sessione avtar, la mappa viene reimpostata solo se:

• Uno dei motivi per cui il conteggio degli hash ignorati può essere temporaneamente alto è dovuto alla suddivisione dello stripe dell'indice. Ciò si verifica perché gli hash spostati nella destinazione di divisione sono protetti. La suddivisione degli stripe degli indici si verifica nei sistemi che sono ancora in crescita o che vengono riempiti di dati. 
• La garbage collection potrebbe anche avere esito negativo con MSG_ERR_TRYAGAINLATER quando gli stripe degli indici si divideno:  
• MCS potrebbe non essere necessariamente a conoscenza di tutte le sessioni avtar che si verificano su Avamar Server.