Percorso di risoluzione relativo alla capacità GSAN o utente di Avamar

Per i concetti iniziali e la comprensione della capacità del sistema operativo, consultare Avamar: Formazione generale sulla capacità - Percorso di risoluzione

È spesso più facile considerare la capacità GSAN come lo spazio e l'utilizzo destinati ai backup dei client.

• Comprensione di base della deduplica
• Comprensione di base di checkpoint, convalida di checkpoint (hfscheck) e garbage collection, nonché dell'importanza di ciascuno di questi elementi
• Differenza tra capacità GSAN (o capacità utente) e capacità del sistema operativoChange Rate
• Change Rate
• Steady State

• Errore di backup o replica quando lo stato di accesso alla griglia è cambiato in "admin mode"

  • Un processo di backup dei client potrebbe avere esito negativo con un messaggio simile a:  ".avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
• Disabilitazione automatica dell'utilità di pianificazione dei backup (fino a quando non viene confermata e cancellata da un utente)

• 80%: avvertenza di capacità
• 95%: limite del controllo integrità raggiunto (a volte può disabilitare l'utilità di pianificazione dei backup, almeno fino a quando l'operazione non viene confermata manualmente)
• 100%: limite read-only del server raggiunto (la griglia passa in modalità amministratore)

1. Avamar deve salvare e archiviare solo modifiche e differenze meno significative tra ogni processo di backup del client grazie alla deduplicazione. Quando vengono eseguiti nuovi backup (o repliche in arrivo), è possibile aggiungere nuovi dati e aumentare la capacità o il valore di utilizzo di Avamar. 
2. Dopo un certo periodo, i backup scadono in base alla retention e alla scadenza configurate e non sono più disponibili sulla griglia Avamar per il ripristino. 
3. Quando il processo di manutenzione di Avamar chiamato garbage collection (GC) viene eseguito, individua tutte le porzioni uniche o i blocchi di dati non più necessari a causa dei backup scaduti. La GC verifica che nessun altro backup corrente condivida gli stessi dati (grazie alla deduplica) e quindi rimuove o libera i blocchi di dati non più richiesti, riducendo la capacità o l'utilizzo di Avamar Server.

Quando la quantità di dati giornalieri in ingresso aggiunti è circa la stessa della quantità di dati giornalieri che vengono puliti, questo stato è chiamato "Steady State". Questo è l'obiettivo di ogni griglia Avamar installata.

Prima che una nuova griglia Avamar venga configurata, vengono eseguiti calcoli di dimensionamento di preinstallazione generali per determinare la capacità necessaria ad archiviare i dati di backup. Questi calcoli si basano sui requisiti di retention del cliente e sulla quantità di dati da sottoporre a backup. Viene inoltre stimata la quantità di questi dati che potrebbe essere deduplicata in media e così via.

1. La garbage collection non viene eseguita in modo costante
2. Le prestazioni della garbage collection sono lente o con esecuzione non sufficiente
3. Le stime di deduplica prima dell'installazione della griglia Avamar non erano abbastanza precise
4. Vengono eseguiti backup su questo Avamar Server di dati diversi da quelli calcolati prima dell'installazione della griglia
5. Altri motivi

Verificare che ogni passaggio di risoluzione dei problemi riportato di seguito sia valido per l'ambiente:

Passaggio 1. Raccolta dei dati:

Assicurarsi che non ci siano altri problemi non legati alla capacità nella griglia Avamar. Se presenti, potrebbero richiedere attenzione PRIMA di procedere con la risoluzione dei problemi relativi alla capacità.

Sono inclusi errori hardware, problemi di integrità dei dati (inclusi nodi offline), stripe offline, errori di convalida dei checkpoint o processi di manutenzione non riusciti. Se uno di questi problemi è presente, la risoluzione dei problemi di capacità deve essere interrotta e devono essere risolti gli altri problemi. Una volta risolti, si può riprendere la risoluzione dei problemi di capacità.

Eseguire un controllo integrità (Avamar: Come eseguire lo script di controllo integrità proactive_check.pl su Avamar Server, ma almeno il comando status.dpn può fornire una rapida panoramica e una verifica di quasi tutti questi problemi. Vedere Avamar: Come comprendere l'output generato dal comando status.dpn

Consultare l'articolo seguente per maggiori informazioni: Avamar: Come applicare correttamente l'approccio della gerarchia di risoluzione dei problemi Avamar.

Se è necessaria assistenza per risolvere eventuali problemi non relativi alla capacità, creare una Service Request con il team di supporto Avamar di Dell Technologies.

Passaggio 2. Raccolta di informazioni sulla capacità: 

Fare riferimento ai seguenti articoli per tutte le informazioni necessarie per risolvere i problemi di capacità di Avamar Server: Avamar: Come raccogliere le informazioni per risolvere i problemi di capacità

Al minimo, il comando status.dpn o i valori all'interno dell'interfaccia utente Avamar Administration mostrano la capacità GSAN .

Passaggio 3. Verificare se la capacità del sistema operativo è piena:

Il comando seguente consente di visualizzare il valore corrente della capacità del sistema operativo per ciascuna partizione del disco. Se uno qualsiasi dei valori ha raggiunto o superato l'85%, come mostrato nel secondo output di esempio, la capacità del sistema operativo è considerata elevata:

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

Output di esempio:

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"

Solo se la capacità del sistema operativo è inferiore all'85% la risoluzione dei problemi della capacità GSAN dovrebbe continuare. 

Passaggio 4. Problemi non di capacità che a volte possono essere fraintesi come problemi di capacità:

È possibile che i backup dei client possano non riuscire non per motivi di "capacità", ma per motivi di "quota". Questi possono talvolta essere interpretati erroneamente come problemi di capacità.

Questa situazione può essere confermata con il comando status.dpn o tramite alcuni degli altri output raccolti che mostrano una capacità inferiore.

È anche possibile che i backup dei client possano non essere riusciti o non essere stati eseguiti per altri motivi non legati alla capacità Non-GSAN . Le informazioni raccolte dovrebbero confermarlo oppure possono essere visualizzate anche nell'interfaccia utente di Avamar Administration.

• Avamar: Percorso di risoluzione della capacità dei metadati (in inglese)
• Data Domain: Capacità elevata dal percorso di risoluzione dell'integrazione Avamar

Se la capacità GSAN è elevata e anche queste altre capacità lo sono, la risoluzione dei problemi può essere eseguita in qualsiasi ordine (eccetto la capacità del sistema operativo, che deve essere sempre affrontata per prima).

Passaggio 5. Bilanciamento di stripe e bilanciamento dei dischi del sistema operativo:

Le "stripe" in Avamar sono file contenitore in cui vengono archiviati i dati di backup sui nodi dati (ad eccezione di una griglia Avamar a nodo singolo).

Ci si aspetta che le stripe siano "bilanciate", ovvero distribuite uniformemente tra i diversi dischi e nodi all'interno della griglia, tuttavia a volte possono diventare sbilanciate.

Per progettazione di Avamar, il nodo o la partizione disco più grande è il fattore limitante quando si tratta di capacità Avamar.

Questo è intenzionale, in modo che nessuno dei dischi o nodi crei più stripe di quante ne possa gestire (o di quante siano consentite); quindi avere stripe bilanciate è importante per la capacità.

Ad esempio, quando si aggiungono ulteriori nodi dati per l'espansione della griglia Avamar, deve essere eseguito il bilanciamento per distribuire uniformemente le stripe sui nuovi nodi e ridurre la percentuale complessiva della capacità Avamar.

Un altro tipo di bilanciamento che richiede attenzione è il bilanciamento dei dischi del sistema operativo. Questo è limitato solo alle partizioni dati sullo stesso nodo, non alle partizioni su più nodi. 

Se sullo stesso nodo dati una partizione è molto più grande o più piccola di un'altra partizione dello STESSO nodo, può essere superato un limite chiamato "freespaceunbalance". Sebbene questo riguardi generalmente il sistema operativo e non la capacità GSAN , può essere riportato come problema di capacità GSAN .

Passaggio 6. Verificare se la garbage collection viene completata: 

Eseguire il seguente comando per ottenere informazioni sulla garbage collection:

dumpmaintlogs --types=gc --days=30 | grep "4201\|2402"

Idealmente, l'output mostrerà che GC è stata completata per gli ultimi 30 giorni:

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

I messaggi di errore della GC possono includere, a titolo esemplificativo, quanto segue:

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

Se la GC ha smesso di funzionare, affrontare prima questo problema utilizzando l'articolo seguente come riferimento: Avamar: Risoluzione dei problemi relativi agli errori di garbage collection (GC) (percorso di risoluzione)
Se alcuni problemi sono già stati risolti, andare al passaggio successivo.

Passaggio 7. La GC funziona abbastanza a lungo?

a. Eseguire il seguente comando per controllare il tempo massimo consentito per la GC:

dumpmaintlogs --types=gc --days=30 | grep gcflags 

Output di esempio:

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"/>

Prendere nota del valore maxtime , che in questo esempio è 14.400 (secondi).
Un valore pari a 0 significa illimitato.

b. Eseguire il seguente comando per determinare la durata dell'esecuzione della GC e quante "passate" vengono completate:
Le passate riguardano gli strati dei dati di backup archiviati. Si pensi alla capacità GSAN come agli strati di una cipolla. Gli strati esterni devono essere rimossi prima che gli strati interni possano essere raggiunti. Ogni passata corrisponde a uno strato dei dati archiviati in GSAN .

dumpmaintlogs --types=gc --days=30 | grep passes | cut -d ' ' -f1,14-20

Output di esempio:

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"/>

Prendere nota del numero di passate e del valore elapsed-time (secondi).

c. Supponendo che maxtime sia diverso da zero, calcolare 2/3 di maxtimee confrontarlo con il tempo trascorso.
Nell'esempio precedente, 2/3 di 14.400 è 9.600 e tutti gli output di elapsed-time sono ben al di sotto di questa cifra.

Diversi fattori possono causare l'esecuzione lenta della garbage collection o il mancato esame di tutti i dati. Ciò può includere il fatto che in passato non sia stato dedicato abbastanza tempo per l'esecuzione, configurazioni errate, errori e altro.

In caso di dubbi su maxtimeo sul numero di passate, creare una Service Request con il team di supporto Avamar di Dell Technologies per ulteriori indagini.

Passaggio 8. Se si sospetta che la garbage collection non abbia rimosso una quantità sufficiente di dati o i dati previsti:

Se è confermato che la garbage collection è in esecuzione per un tempo sufficiente, è possibile che i dati non vengano raccolti per motivi al di fuori del controllo della garbage collection. Questo è un elenco dei motivi documentati che dovrebbero generalmente essere verificati:

a. Verificare che i backup siano configurati per scadere almeno una volta o regolarmente. Se non ci sono backup che scadono frequentemente, la garbage collection non avrà molto lavoro da fare.

b. Utilizzare questo articolo per individuare i client con la dicitura "Top Change Rate": Avamar: come gestire la capacità con lo script capacity.sh. Esaminare "% OF TOTAL" e "CHGRATE".

c. Controllare eventuali hash saltati secondo Avamar: La garbage collection di Avamar segnala "skipped-hashes" che non possono essere puliti. Se si verificano ma sono rari, questo è normale e può essere ignorato.

d. Esiste un flag o un'opzione che forza Avamar Server a mantenere l'ultimo e più recente backup di ogni client. Questo viene utilizzato per motivi di sicurezza, affinché un client non abbia accidentalmente tutti i backup scaduti. Tuttavia, questo può causare altri problemi relativi alla pulizia dei dati e alla garbage collection. Il team di supporto Avamar di Dell Technologies può confermare se questa opzione è abilitata.

e. Se i backup sono stati recentemente spostati da GSAN al backend DD o se è stato eseguito accidentalmente un backup GSAN , ma la capacità GSAN non diminuisce, creare una Service Request con il team di supporto Avamar di Dell Technologies per ulteriori indagini.

Passaggio 9. La griglia Avamar è sottodimensionata rispetto alla quantità di dati correnti o previsti da aggiungere:

Una volta che tutte le altre soluzioni e possibili cause di capacità elevata sono state esaminate e non si tratta di un problema di configurazione, né di dati inseriti accidentalmente:

Ciò significa che potrebbe essere necessario eliminare dei dati oppure esplorare opzioni come la migrazione di alcuni client ad altre griglie Avamar, l'aggiunta di nuovi nodi dati e così via.

Passaggio 10. Confermare eventuali eventi di capacità e riprendere l'utilità di pianificazione dei backup, se necessario:

a. Una volta risolti i problemi di capacità, confermare tutti gli eventi relativi alla capacità nell'interfaccia utente di Avamar Administration.

b. Riprendere l'utilità di pianificazione dei backup:

dpnctl start sched

Per qualsiasi altra questione relativa alla capacità Avamar, alla formazione, alla risoluzione dei problemi e ad altri argomenti, consultare: Avamar: Risoluzione dei problemi di capacità, problemi e domande - Tutta la capacità (percorso di risoluzione)

• Questa azione, di per sé, può "mascherare" e nascondere i problemi reali, facendoli riapparire dopo pochi giorni o settimane, vanificando così il lavoro manuale svolto.
• Inoltre, la GC manuale potrebbe non funzionare con la stessa efficienza rispetto all'esecuzione programmata.
  • In alcune occasioni, può addirittura aggravare altri problemi. Per ulteriori informazioni, consultare: Avamar: Informazioni sull'utilizzo della garbage collection manuale

• Questa modifica o azione generalmente non viene eseguita e non dovrebbe essere considerata per impostazione predefinita. Un ingegnere Avamar L2 o un esperto in materia (SME) deve approvare questa modifica.
• Sfortunatamente, tali azioni possono spesso causare danni permanenti a una griglia Avamar in vari modi, che possono essere risolti solo aggiungendo ulteriori storage node o ripetendo l'implementazione.

È importante comprendere che nessuna delle azioni elencate sopra viene eseguita perché il team di supporto vuole semplicemente risolvere i problemi di capacità nel modo più efficace possibile.