Avamar: Capacità del sistema operativo (OS) (percorso di risoluzione)

Come gestire o risolvere i problemi di capacità del sistema operativo su Avamar.

Questo articolo sul percorso di risoluzione è progettato per risolvere i problemi di capacità del sistema operativo su Avamar.


Per i concetti iniziali e la comprensione della capacità del sistema operativo, consultare l'articolo di formazione Avamar: Concetti e formazione

sul capacity managementCome riepilogato dall'articolo di formazione, è necessaria una comprensione ragionevole dei seguenti argomenti per procedere con il resto di questo articolo:

• Una conoscenza di base dei checkpoint (cp), della convalida dei checkpoint (hfscheck)e Garbage Collection (GC) e l'importanza di ciascuno di essi
• La differenza tra GSAN (nota anche come "capacità utente" e capacità del sistema operativo)
• Dati di overhead del checkpoint
• Se una qualsiasi delle partizioni dati supera l'89% dello spazio totale della capacità fisica del sistema operativo, non è possibile eseguire la garbage collection.
• Più una griglia Avamar è vicina al 100% della capacità utente, minore è la capacità del sistema operativo disponibile per l'overhead dei checkpoint.
• Fattori che contribuiscono all'overhead dei checkpoint, tra cui crunching asincrono, numero di checkpoint archiviati, HFSCheck e l'importanza della convalida dei checkpoint e così via.
• Come trovare i livelli di capacità del sistema operativo
• Azioni di base per ridurre la capacità del sistema operativo

Spesso è più semplice considerare la capacità del sistema operativo come la dimensione di GSAN dati (più specificamente, lo spazio allocato per questi dati) e l'overhead generato dai checkpoint Avamar. Maggiore è il numero di checkpoint e maggiore è la frequenza di modifica, maggiore è l'overhead del checkpoint.

L'impatto di un'elevata capacità del sistema operativo può includere:

• Errore di garbage collection: GC ha esito negativo con MSG_ERR_DISKFULL se la capacità del sistema operativo supera l'89%
• Errore di backup o replica: I backup o la replica in ingresso potrebbero non riuscire con MSG_ERR_STRIPECREATE se la capacità del sistema operativo supera il 90%. (Questo solo se è necessario creare un nuovo stripe di dati. Se non è necessario un nuovo striping, i backup e la replica potrebbero comunque essere eseguiti correttamente.
• Errore del checkpoint: Un checkpoint ha esito negativo con MSG_ERR_DISKFULL se la capacità del sistema operativo supera il 96%

Come indicato sopra, la capacità del sistema operativo è spesso il primo tipo di capacità Avamar da affrontare quando anche altre capacità Avamar sono elevate. Come minimo, la garbage collection non può essere eseguita quando la capacità del sistema operativo raggiunge determinati livelli anche quando il GSAN o anche la capacità dell'utente è elevata.

In genere, la capacità del sistema operativo è considerata elevata quando GC ha esito negativo con MSG_ERR_DISKFULL se la capacità del sistema operativo supera l'89%. Se la capacità del sistema operativo è inferiore all'89%, nessun processo di manutenzione viene influenzato. 

La capacità del sistema operativo Avamar può aumentare a causa di una combinazione dei seguenti motivi:

• Tasso di modifica elevato dei dati di backup, aggiunta di "too much too fast"
• Alto GSAN o "Capacità utente", che lascia meno spazio per la capacità del sistema operativo e talvolta può anche comportare tassi di modifica più elevati
• Il checkpoint non viene completato correttamente, con conseguente stato "MSG_ERR_DISKFULL", come mostrato nell'output.
• Una convalida del checkpoint (hfscheck) ha avuto esito negativo o non è stato eseguito di recente, in modo che i checkpoint meno recenti non possano essere eliminati o rimossi
• I checkpoint non vengono sottoposti a rollback per altri motivi, tra cui impostazioni di retention dei checkpoint troppo elevate

L'elevata capacità del sistema operativo su altri partizionamenti del disco può derivare da varie cause, tra cui un posizionamento errato dei dati, file di registro troppo grandi e così via.

• Per un rapido background, i checkpoint di Avamar sono un'istantanea read-only e un collegamento ai dati in tempo reale. Poiché questo viene creato con i link, un checkpoint utilizzerà zero spazio su disco aggiuntivo subito dopo la creazione. Se non vengono apportate modifiche ai dati in tempo reale, il checkpoint non utilizza spazio aggiuntivo.
• Questo cambia man mano che i dati in tempo reale vengono modificati mentre il checkpoint rimane invariato. A quel punto, esiste una copia originale dei dati nel checkpoint e la Live Copy aggiornata dei dati modificati. Questo è completamente intenzionale e intenzionale. Questo è il motivo per cui c'è spazio riservato alla capacità del sistema operativo.
• Tuttavia, se la quantità o la velocità di modifica dei dati aumenta drasticamente e improvvisamente, ciò può causare un picco non comune nelle dimensioni della capacità del sistema operativo ed essere considerati "troppo e troppo veloci"
• La colonna capacity.sh mostra questa come causa quando si confronta l'output su diversi giorni.

Se i processi di manutenzione, inclusa la garbage collection, non riescono a causa di un'elevata capacità del sistema operativo Avamar, attenersi alla seguente procedura:

1. Raccogliere tutte le informazioni sulla capacità Avamar per illustrare il quadro della situazione: Avamar: Come raccogliere le informazioni necessarie per risolvere i problemi di capacità.

2. Successivamente, verificare a quanto ammonta la capacità del sistema operativo e quali azioni potrebbero essere necessarie. Dall'articolo sulla raccolta dei dati, questo può essere trovato utilizzando il seguente comando: 

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

Come funziona Avamar, il valore PIÙ ALTO per fs-percent-full mostrato è il fattore limitante per la capacità corrente del sistema operativo. A seconda della generazione e delle dimensioni del tipo di nodo, il numero di partizioni dati che archiviano i dati di backup e dei checkpoint può variare. Come si vede dal sistema operativo Linux, possono essere dischi o partizioni come "/data0*", dove "*" può essere una cifra singola. Il numero di partizioni dati dipende dal tipo di nodo, dalla generazione dell'hardware e dalle dimensioni (e non può essere modificato).

3. Esaminare il numero di checkpoint trovati e l'ultima convalida del comando:

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. Verificare se le operazioni dei checkpoint hanno esito negativo da "MSG_ERR_DISKFULL" eseguendo il seguente comando:

dumpmaintlogs --types=cp --days=4 | grep "\<430"

Se i checkpoint sono stati completati correttamente, viene visualizzato un output simile al seguente:

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

In caso di errore a causa di MSG_ERR_DISKFULL, viene visualizzato questo output:

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

6. Determinare il tasso di modifica:

capacity.sh  

Esempio di output:

  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

A volte, se l'alto tasso di modifiche o la situazione di "troppo e troppo veloce" si ripresentano, questo può essere alleviato abbassando il GSAN o la capacità dell'utente. Con una riduzione GSAN capacità, c'è un po' più di spazio per l'overhead della capacità del sistema operativo e si traduce anche in un minor numero di modifiche del contenitore di storage dei dati. Per assistenza in questo scenario, aprire una Service Request con il team di supporto Dell Technologies Avamar, altrimenti continuare dal passaggio 7.

7. I problemi con elevate capacità del sistema operativo su altre partizioni del disco hanno varie cause, ma le soluzioni richiedono supporto tecnico. Aprire una Service Request con il team di supporto Dell Technologies Avamar, altrimenti continuare dal passaggio 7.

Una volta risolta la capacità del sistema operativo, GSAN o altre capacità Avamar possono essere riviste. Vedere Risoluzione dei problemi, problemi e domande sulla capacità di Avamar - Tutta la capacità (percorso di risoluzione)