GSAN Avamar o percorso di risoluzione della capacità utente

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

Spesso è più facile da considerare GSAN Capacità come spazio e utilizzo per i backup dei client.

• Conoscenze di base sulla deduplica
• Conoscenza di base del checkpoint e della convalida dei checkpoint (hfscheck) e Garbage Collection, e l'importanza di ciascuno di essi.
• La differenza tra GSAN (o Utente) Capacità e capacità del sistema operativo
• Tasso di modifica
• Stazionario

• Errore di backup o replica quando lo stato di accesso alla griglia è cambiato in "modalità amministratore"

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

• 80% - avviso di capacità
• 95% - È stato raggiunto il limite del controllo integrità (questo a volte può disabilitare l'utilità di pianificazione del backup, almeno fino a quando non viene riconosciuto manualmente)
• 100% - È stato raggiunto il limite read-only del server (la griglia passa alla modalità amministratore)

1. Avamar deve salvare e archiviare solo le modifiche e le differenze minori tra ogni processo di backup del client a causa della deduplica. Man mano che vengono eseguiti nuovi backup (o replica in ingresso), può aggiungere nuovi dati e aumentare il valore di capacità o utilizzo di Avamar. 
2. Dopo un certo periodo di tempo, i backup scadono in base alla retention e alla scadenza configurate e non vengono trovati nella griglia Avamar disponibile per il ripristino. 
3. Quando viene eseguito il processo di manutenzione di Avamar denominato Garbage Collection (GC), trova tutte le parti o i blocchi di dati univoci che non sono più necessari a causa di questi backup scaduti. GC verifica che nessun altro backup corrente condivida gli stessi dati (a causa della deduplica) e quindi rimuove o libera quei blocchi di dati non più necessari per ridurre la capacità o l'utilizzo dell'Avamar Server.

Quando la quantità di dati giornalieri in ingresso aggiunti è all'incirca uguale alla quantità di dati giornalieri puliti, si parla di "stato stazionario". Questo è l'obiettivo di ogni griglia Avamar installata.

Prima di configurare e configurare una nuova griglia Avamar, vengono effettuati calcoli generali di dimensionamento pre-installazione per determinare la capacità richiesta per archiviare i dati di backup. Questi calcoli si basano sui requisiti di retention dei clienti e sulla quantità di dati di cui è necessario eseguire il backup. Viene inoltre stimata la quantità media di tali dati deduplicabili e così via.

1. Garbage Collection non in esecuzione coerente
2. Le prestazioni di Garbage Collection sono lente o non vengono eseguite abbastanza a lungo
3. Le stime di deduplica prima dell'installazione della griglia Avamar non erano sufficientemente accurate
4. Viene eseguito il backup di dati diversi da quelli calcolati prima dell'installazione della griglia Avamar su questo Avamar Server.
5. Altri motivi

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

Passaggio 1. Raccolta dei dati:

Assicurarsi che non vi siano altri problemi di mancata capacità con la rete Avamar. In caso affermativo, potrebbero richiedere attenzione PRIMA della risoluzione dei problemi relativi alla capacità.

Sono inclusi errori hardware, problemi di integrità dei dati (inclusi i nodi offline), stripe offline, errori di convalida dei checkpoint o job di manutenzione non riusciti. Se si verifica uno di questi problemi, è necessario interrompere la risoluzione dei problemi di capacità e risolvere altri problemi. Una volta risolti altri problemi, è possibile rivedere la capacità.

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

Per ulteriori informazioni, consultare il seguente articolo: Avamar: Come applicare correttamente l'approccio "Avamar troubleshooting hierarchy".

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

Passaggio 2. Raccolta informazioni sulla capacità: 

Fare riferimento a quanto segue per tutte le informazioni necessarie per risolvere i problemi di capacità di Avamar: Avamar: Come raccogliere le informazioni per la risoluzione dei problemi di capacità

Per lo meno, il status.dpn o i valori all'interno dell'interfaccia utente di amministrazione di Avamar mostrano il GSAN capacità.

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

Il comando seguente aiuta a mostrare il valore corrente della capacità del sistema operativo per ogni partizione del disco. Se uno qualsiasi dei valori ha raggiunto o superato l'85%, come nel secondo output di esempio, si parla di capacità del sistema operativo elevata:

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

Esempi di output:

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% GSAN Continua la risoluzione dei problemi relativi alla capacità. 

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

È possibile che i backup dei client non riescano per motivi di "capacità", ma piuttosto di "quota". Questi a volte possono essere fraintesi come capacità.

Questa situazione può essere confermata dalla status.dpn o uno qualsiasi degli altri output raccolti che mostrano una capacità inferiore.

È inoltre possibile che i backup dei client non siano riusciti o che non siano stati eseguiti a causa di altri Non-GSAN Motivi di capacità. Le informazioni raccolte dovrebbero confermarlo o possono essere visualizzate anche nell'interfaccia utente di amministrazione di Avamar.

• Avamar: Percorso di risoluzione della capacità dei metadati
• Data Domain: Alta capacità dal percorso di risoluzione dell'integrazione di Avamar

Se GSAN La capacità è elevata, e anche queste altre capacità sono elevate, la risoluzione dei problemi può essere eseguita in qualsiasi ordine (ad eccezione della capacità del sistema operativo che deve essere sempre la prima).

Passaggio 5. Bilanciamento stripe e bilanciamento del disco del sistema operativo:

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

L'aspettativa è che le stripe siano "bilanciate" o distribuite uniformemente tra i diversi dischi e nodi all'interno della griglia, tuttavia, a volte possono diventare sbilanciate.

Per impostazione predefinita in Avamar, il nodo o la partizione del disco più grande è il fattore limitante per la capacità Avamar.

Questo è intenzionale, quindi nessuno dei dischi o dei nodi crea più stripe di quelle che può gestire (o consentire), pertanto avere stripe bilanciate è importante per Capacity.

Ad esempio, quando si aggiungono ulteriori nodi di dati per l'espansione della griglia Avamar, è necessario eseguire il bilanciamento per distribuire uniformemente le stripe ai nuovi nodi per ridurre la percentuale complessiva della capacità di Avamar.

Un altro tipo di bilanciamento che richiede comprensione è il bilanciamento del disco del sistema operativo. Questa operazione è limitata solo alle partizioni di dati sullo stesso nodo, non alle partizioni su più nodi. 

Se sullo stesso nodo di dati, una partizione è molto più grande o più piccola di un'altra partizione dello STESSO nodo, è possibile superare un limite chiamato "freespaceunbalance". Sebbene questo sia generalmente sul sistema operativo e non sul GSAN Capacità, può essere segnalata come GSAN Problema di capacità.

Passaggio 6. Verificare se la garbage collection è in fase di completamento: 

Eseguire il comando seguente per ottenere informazioni sulla garbage collection:

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

Idealmente, l'output mostrerà che GC è stato completato negli 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 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 GC presenta errori, risolvere prima questo problema utilizzando il seguente articolo come riferimento: Avamar: Risoluzione dei problemi relativi agli errori di Garbage Collection (GC) (percorso di risoluzione)
(Se eventuali problemi sono già stati risolti, andare al passaggio successivo).

Passaggio 7. GC è in esecuzione abbastanza a lungo?

un. Eseguire il comando seguente per verificare il tempo massimo consentito per 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 maxtime che in questo esempio è 14400 (secondi).
(un valore pari a 0 significa illimitato)

b. Eseguire il comando seguente per determinare la durata di esecuzione del GC e il numero di "passaggi" completati:
(i passaggi hanno a che fare con i livelli dei dati di backup archiviati. Pensa al GSAN Capacità come strati di una cipolla. Gli strati esterni devono essere staccati o rimossi prima che si vedano gli strati interni. Ogni passaggio è un livello del GSAN dati memorizzati.)

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 passaggi e del elapsed-time (secondi).

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

Vari problemi possono rallentare l'esecuzione di GC o impedire la scansione di tutto. Ciò può includere il fatto di non aver avuto abbastanza tempo per l'esecuzione per una quantità significativa di tempo o giorni in passato, una configurazione errata, errori e altro ancora.

In caso di dubbi in merito alla maxtimeo il numero di passaggi, creare una Service Request con il team di supporto Avamar di Dell Technologies per ulteriori indagini.

Passaggio 8. Se si sospetta che GC non abbia rimosso dati sufficienti o previsti:

Se si conferma che GC è in esecuzione per un periodo sufficientemente lungo, è possibile che i dati non vengano raccolti per motivi che esulano dal controllo di Garbage Collection. Questo è un elenco dei motivi documentati che in genere dovrebbero essere controllati:

un. Verificare che i backup siano configurati in modo da scadere almeno alla fine o regolarmente. Se non sono presenti backup con scadenza frequenti, GC non avrà molto lavoro da fare.

b. Utilizzare questo articolo per trovare i client "Top Change Rate": Avamar: Come gestire la capacità con lo script capacity.sh. (Esamina sia il "% OF TOTAL" e "CHGRATE".)

c. Verificare la presenza di hash ignorati per Avamar: Avamar Garbage Collection segnala "hash ignorati" che non possono essere puliti. Se questi si verificano ma raramente, questo è normale e questo può essere saltato.

d. È presente un flag o un'opzione che forza l'Avamar Server a conservare l'ultimo e più recente backup di ogni client. Viene utilizzato per motivi di sicurezza in modo che ogni backup non sia scaduto accidentalmente. Tuttavia, questo può causare altri problemi quando si tratta di pulizia dei dati e Garbage Collection. Il team di supporto di Dell Technologies Avamar può verificare se questa opzione è abilitata.

e. Se di recente sono stati commutati i backup da GSAN back-end DD o si è verificato un errore GSAN backup, ma il GSAN La capacità non diminuisce, creare una Service Request con il team di supporto Avamar di Dell Technologies per ulteriori indagini.

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

Una volta esaminate tutte le altre soluzioni e le possibili cause per l'alta capacità, e non si tratta di un problema di configurazione o di dati accidentali:

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

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

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

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

dpnctl start sched

Per altre domande, formazione, risoluzione dei problemi e altro su Avamar Capacity, consultare: Avamar: Risoluzione dei problemi, problemi e domande relative alla capacità - Tutta la capacità (percorso di risoluzione)

• Questa azione di per sé può "mascherare" e nascondere i problemi reali, facendoli riapparire solo dopo pochi giorni o settimane dopo, facendo perdere tempo a questo lavoro manuale.
• Inoltre, il GC manuale potrebbe non essere eseguito in modo efficiente poiché è in esecuzione fuori pianificazione.
  • A volte, può peggiorare altri problemi. Per ulteriori informazioni, consultare: Avamar: Informazioni sull'utilizzo della Garbage Collection manuale

• Questa modifica o azione in genere non viene eseguita e non deve essere presa in considerazione per impostazione predefinita. Una modifica deve essere approvata da un tecnico L2 di Avamar o da un esperto in materia (SME).
• 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 reimplementando.

Tenere presente che nessuna delle azioni elencate in precedenza viene eseguita perché il team di supporto desidera contribuire a risolvere i problemi di capacità nel modo più vantaggioso.