Avamar: Concetti e formazione sulla capacity management

Per i problemi di capacity management correlati a Data Domain, consultare la sezione "Reclaiming storage on a full Data Domain system" nel manuale Avamar and Data Domain System Integration Guide.

Le guide relative all'ambiente operativo in uso sono disponibili qui: Come individuare la documentazione di Avamar sul sito del Supporto Dell.

• Riepilogare i tipi di dati archiviati nelle partizioni /data*.
• Introdurre il concetto di "capacità del sistema operativo (OS)" e confrontarlo con il concetto di "capacità utente" (a volte chiamata "GSAN Capacità.")
• Spiegare perché Avamar non deve essere eseguito in prossimità del limite di User Capacity.
• Elencare i fattori che contribuiscono all'aumento dell'overhead del checkpoint.
• Descrivere come monitorare l'utilizzo della partizione di dati.
• Descrivere i sintomi riscontrati se la capacità del sistema operativo diventa fuori controllo.
• Elencare le cause tipiche del messaggio MSG_ERR_DISKFULL .
• Delineare i metodi di ripristino utilizzati quando la capacità elevata del sistema operativo influisce sul funzionamento normale del sistema.
• Descrivere i sintomi riscontrati se il valore di User Capacity supera il limite impostato.
• Spiegare come eseguire il ripristino da una situazione con valore elevato di User Capacity.

Questo articolo presuppone che il lettore abbia familiarità con la sezione "Gestione della capacità" nella Guida alle best practice operative di Avamar.

Anche in questo caso, le guide relative al proprio ambiente operativo sono disponibili qui: Come individuare la documentazione di Avamar sul sito del Supporto Dell.

I problemi più comuni che influiscono o sono sintomi di un'elevata capacità del sistema operativo sono:

• Convalida dei checkpoint (hfscheck) sta fallendo.
• La garbage collection non viene eseguita e segnala MSG_ERR_DISKFULL.
• Errori di creazione del checkpoint.

• I backup non riescono.
• I processi di replica in ingresso hanno esito negativo.
• L'interfaccia di Administrator mostra il sistema in modalità 'Admin' durante la finestra di backup.

Questo articolo fornisce i concetti relativi alla formazione e ai concetti di capacity management di Avamar.

Come vengono archiviati i dati su una griglia Avamar?

La capacity management di Avamar riguarda i dati che si trovano nelle partizioni /data* di tutti i nodi di dati Avamar,

• Dati di backup deduplicati
• Dati di parità RAIN
• Dati di overhead del checkpoint

I dati di parità RAIN e i dati del checkpoint sono livelli di ridondanza disponibili per Avamar oltre a RAID e replica.

È inoltre necessario spazio libero nelle partizioni di dati per la corretta esecuzione di attività di manutenzione come Garbage Collection (GC) e striping asincrono.

Di seguito è riportata una rappresentazione grafica dello spazio di storage fisico disponibile all'interno delle partizioni dati sugli storage node Avamar.

Come vengono archiviati i dati nelle partizioni di dati?

Nel diagramma precedente è presente una semplice rappresentazione del modo in cui viene utilizzato lo spazio nelle partizioni dati.

Il valore 100% sulla sinistra è definito come la quantità totale di spazio fisico disponibile per il sistema operativo nelle partizioni di dati.

• L'indicatore 100% di capacità utente (limite read-only) indica che fino al 65% dello spazio totale nella partizione dati è disponibile per l'archiviazione dei dati deduplicati.
• Lo spazio al di sotto di questo indicatore di User Capacity al 100% è equivalente al valore di Server Utilization, visibile nell'interfaccia utente di Administrator.

Se la quantità di dati deduplicati archiviati in qualsiasi partizione dati in qualsiasi nodo raggiunge il 65%, Avamar diventa di sola lettura e rifiuta ulteriori dati di backup.

Sulla base di quanto sopra, è possibile comprendere che, dall'interfaccia utente di Avamar Administrator, l'utente ha visibilità dello spazio utilizzato dai backup, ma non ha visibilità dello spazio utilizzato nelle partizioni dati del sistema operativo.

Perché un sistema Avamar non deve essere eseguito in prossimità del limite di "User Capacity"

La relazione tra un valore elevato di "User Capacity" e l'overhead del checkpoint è tale che, man mano che un sistema esaurisce lo spazio, anche piccoli incrementi di dati di backup possono causare notevoli aumenti nel valore di overhead del checkpoint.

Una discussione completa del motivo per cui questo è il caso va oltre lo scopo di questo articolo, tuttavia la cosa importante da ricordare è: Quantopiù un sistema Avamar si avvicina al 100% della capacità utente, tanto minore è la capacità del sistema operativo disponibile per l'overhead dei checkpoint.

In un sistema completo, come illustrato nel diagramma precedente, l'overhead dei checkpoint è limitato al 20% dello spazio totale del sistema operativo nelle partizioni dati.

• Il sistema deve avere un tasso ridotto di dati modificati giornalmente (non superiore all'1%).
• La capacità deve essere in stato stazionario (come descritto nella sezione "Managing Capacity" del manuale Avamar Operational Best Practices Guide). Le guide relative all'ambiente operativo in uso sono disponibili qui: Come individuare la documentazione di Avamar sul sito del Supporto Dell.
• Le attività di manutenzione devono essere completate ogni giorno.

Se una di queste istruzioni passa da true a false, è possibile che l'overhead del checkpoint aumenti gradualmente o all'improvviso e causi gravi problemi operativi.

Fattori che contribuiscono all'aumento dell'overhead del checkpoint:

• Stripe crunching asincrono (abilitato per impostazione predefinita)
• Numero di checkpoint archiviati sul sistema
• Convalida del checkpoint non completata correttamente ogni giorno
• Modalità degli stripe vuoti quando vengono riutilizzati da Avamar Server (il livello di gravità aumenta contestualmente all'incremento del valore di Server Utilization)
• Tasso di modifica dei backup giornalieri

Un System Administrator ha un certo grado di controllo su questi fattori. La configurazione del crunching asincrono è destinata solo al supporto, ma gli amministratori possono rimuovere i checkpoint in eccesso, analizzare gli errori dei checkpoint e influenzare l'utilizzo del server e il tasso di modifica dei dati giornaliero.

Come monitorare l'utilizzo della partizione di dati

Il modo corretto per monitorare l'utilizzo della partizione dei dati del sistema operativo consiste nell'utilizzare il seguente comando Avamar da Avamar Utility Node:

avmaint nodelist | grep fs-percent        

Esempio di output:

fs-percent-full="7.8"
fs-percent-full="6.3"
fs-percent-full="6.4"
fs-percent-full="6.4"
fs-percent-full="7.6"
fs-percent-full="6.2"
fs-percent-full="6.1"
fs-percent-full="6.6"
fs-percent-full="7.8"
fs-percent-full="6.4"
fs-percent-full="6.5"
fs-percent-full="6.8"

• • Questo output fornisce una lettura reale dell'utilizzo della capacità del sistema operativo.
  • In un grid in cui i nodi di dati utilizzano un file pool, il comando Linux df non è significativo, perché gli stripe vengono preallocati nel file pool e molti stripe potrebbero non essere in uso.

Che cosa accade se l'utilizzo della capacità del sistema operativo diviene fuori controllo?

Dal punto di vista dell'utente, la prima indicazione che l'utilizzo della partizione dati è fuori controllo si verifica quando supera l'89%.

La garbage collection non è più in grado di essere eseguita e ha esito negativo con un MSG_ERR_DISKFULL software.

È qui che spesso si verificano le incomprensioni: L'utente spesso interpreta il messaggio MSG_ERR_DISKFULL messaggio indicante che il sistema non dispone più di spazio per i backup.

Questa interpretazione non è corretta, tuttavia, l'utente in genere controlla il valore di utilizzo del server nell'interfaccia utente di Avamar Administrator e trova il valore accettabile, ad esempio 60%.

L'utente può tentare di eliminare i backup dall'interfaccia utente di Avamar Backup Management. Anche se il livello di capacità utente è elevato, l'eliminazione dei backup non allevia la situazione poiché la garbage collection non è in grado di eseguire e rimuovere blocchi di dati scaduti dal sistema.

Se in un sistema si verifica sia un problema di capacità elevata del sistema operativo che un'elevata capacità utente, concentrarsi prima sulla risoluzione del problema di capacità elevata del sistema operativo. 

In caso di elevato utilizzo della capacità del sistema operativo, il sistema potrebbe non avere spazio sufficiente per creare i checkpoint.

Che cosa determina il messaggio MSG_ERR_DISKFULL?

• Convalida dei checkpoint (hfscheck) ha fallito ripetutamente.
• L' hfscheck L'errore ha molte possibili cause principali (annullamento improvviso, errore del software e così via).
• Lo spazio del sistema è quasi esaurito ed è presente un tasso elevato di modifica dei dati giornaliero.
• Il sistema richiede più nodi di dati per gestire il tasso di modifica e archiviare i dati.
• Il sistema è configurato per eseguire il backup di più dati o client rispetto al dimensionamento.
• Vengono archiviati troppi checkpoint (Avamar archivia due checkpoint per impostazione predefinita, uno dei quali convalidato).
• Il System Administrator ha creato checkpoint in eccesso.
• La manutenzione è stata eseguita di recente, ma le retention dei checkpoint predefinite non sono state ripristinate.

Consultare l'articolo seguente per risolvere il problema MSG_ERR_DISKFULL Scenario: Avamar: Le attività di manutenzione hanno esito negativo con MSG_ERR_DISKFULL a causa della capacità del sistema operativo di una o più partizioni dati che supera l'89%

Azioni per analizzare e contribuire a ridurre l'elevata capacità del sistema operativo:

1. Determinare quando l'ultimo hfscheck Finito. A tale scopo, utilizzare Avamar Administrator o la riga di comando su Avamar Utility Node:

• Nell'interfaccia utente Java Administrator di Avamar:
  • Passare alla scheda Server > Checkpoint Management
  • Controllare la data e l'ora più recenti elencate nella colonna Checkpoint Validation. Il controllo dovrebbe essere stato eseguito nelle ultime 24 ore.

-- Oppure --

• Utilizzando la riga di comando di Avamar Utility Node:
  • Eseguire il comando: cplist.

admin@utilitynode:~/>: cplist

cp.20110114111419 Fri Jan 14 11:14:19 2011   valid rol ---  nodes   3/3 stripes   1131
cp.20110114194457 Fri Jan 14 19:44:57 2011   valid --- ---  nodes   3/3 stripes   1131

• • • • Il checkpoint convalidato più recente elencato qui è quello del 14 gennaio alle ore 11:14.
      • È identificato dalla bandierina direttamente dopo l'indicatore "valido".
      • A seconda dei tipi di convalide dei checkpoint impostate nel sistema, il flag potrebbe essere rol oppure hfs.
      • Questo è un esempio di rol (a rotazione) hfscheck.

Se i risultati mostrano che il checkpoint più recente convalidato è precedente a 24 ore, scoprire il motivo. Ciò potrebbe essere dovuto al fatto che il HFScheck non è stato eseguito o perché non è riuscito.

2. Confermare se HFScheck eseguito o in caso di errore:

Sull'Avamar Utility Node, eseguire il comando status.dpn comando e trova la riga che inizia con "Ultimo hfscheck".

Esempio:

Last hfscheck: finished Sat Jan 15, 11:07:17 2011 after 06m 41s >> checked 528 of 528 stripes (OK)

Prendere nota dell'orario di completamento e dello stato (nella riga precedente, lo stato viene visualizzato come "OK").

se hfscheck I lavori hanno avuto esito negativo, questo dovrebbe essere esaminato immediatamente.

se hfscheck non è stato eseguito di recente, verificare che l'utilità di pianificazione della manutenzione sia abilitata eseguendo il comando "dpnctl status maint" sull'Avamar Utility Node: .

admin@utilitynode:~/>: dpnctl status maint

Identity added: /home/admin/.ssh/dpnid (/home/admin/.ssh/admin_key)
dpnctl: INFO: Maintenance windows scheduler status: enabled.

• Se l'utilità di pianificazione delle finestre di manutenzione è inattiva, disabilitata o sospesa, abilitarla con il comando: dpnctl start maint
• Facoltativamente, eseguire un nuovo checkpoint hfschecko attendere il completamento della successiva finestra di manutenzione pianificata.

Una volta che un hfscheck è stato completato correttamente (dopo aver risolto eventuali problemi o riavviato l'utilità di pianificazione della manutenzione), il checkpoint meno recente verrà sottoposto a rolloff e la capacità del sistema operativo dovrebbe ridursi notevolmente.

• Se la capacità del sistema operativo è ancora troppo elevata e la garbage collection continua a non riuscire con MSG_ERR_DISKFULL e chiedere assistenza al team del supporto tecnico Dell.
• In caso contrario, se la capacità del sistema operativo è sufficientemente bassa da consentire il completamento della garbage collection, è necessario ridurre i valori di "User Capacity" e "Server Utilization".

Azioni per ridurre un valore elevato di User Capacity

A differenza dei livelli di System Capacity, i livelli di User Capacity sono più facilmente e direttamente influenzati dal System Administrator di Avamar.

1. Accertarsi che la garbage collection venga eseguita ogni giorno e che non venga interrotta dai backup.

Questo è il punto più cruciale, in quanto anche un sistema adeguatamente dimensionato sperimenta rapidamente un'elevata capacità utente se la garbage collection non viene eseguita regolarmente o in modo affidabile.

Come illustrato in precedenza, verificare che la finestra di manutenzione sia abilitata e utilizzare il comando capacity.sh e sched.sh Script per verificare che la garbage collection sia in esecuzione e che stia rimuovendo dati.

Prima di Avamar v7.x, i backup non potevano essere eseguiti durante la finestra di "restrizione" della garbage collection.

La funzione Hash Referenced Bit Maps introdotta con la funzione Avamar v7.x consente l'esecuzione dei backup durante l'attività di manutenzione del GC. Questa funzione richiede che queste "mappe" presentino almeno 5 minuti di tempo "silenzioso" al giorno, durante il quale non vengono eseguiti backup, in modo che possano essere reimpostate.

È possibile accedere al contenuto relativo a questa funzione utilizzando il link all'articolo Avamar: a partire da Avamar v7, la garbage collection segnala "skipped-hashes" che non è possibile pulire per via di "Hash Referenced Bit Maps" quando i dati sono in uso.

2. Interrompere l'aggiunta di nuovi client alla griglia.

Quando una griglia Avamar sta raggiungendo la capacità, interrompere immediatamente l'aggiunta di nuovi client per evitare che la situazione peggiori.

Se è presente un'altra griglia Avamar in esecuzione a un livello inferiore di utilizzo del server, prendere in considerazione l'aggiunta di nuovi client a tale griglia anziché al server che si sta riempiendo.

3. Individuare i client che utilizzano la maggiore quantità di spazio di storage.

Per risolvere un problema di capacità, identificare i client responsabili dell'aggiunta della maggior parte dei dati al sistema Avamar.

La colonna capacity.sh script (eseguito dalla riga di comando di Avamar Utility Node) può essere utilizzato anche per identificare i client con il tasso di modifica più elevato.

Scopri Avamar: Come gestire la capacità con capacity.sh script per ulteriori informazioni su come utilizzare il capacity.sh copione.

Si riscontra spesso che i client che utilizzano più spazio sono quelli che eseguono il backup del database SQL o dei server e-mail, quindi prestare particolare attenzione a questi client.

4. Rivalutare le retention policy.

Dopo aver identificato i client con elevato tasso di modifica, rivalutare le retention policy per verificare se è possibile diminuirle al fine di ridurre i requisiti di storage a un livello accettabile.

Se il sistema è abbastanza vecchio da aver iniziato a far scadere i backup conservati da più tempo, dopo aver ridotto le policy di retention, si prevede di vedere un aumento della quantità di dati rimossi ogni giorno dalla garbage collection. Monitorare questa tendenza con capacity.sh.

Se il sistema Avamar non ha ancora iniziato a far scadere i backup, potrebbe essere necessario modificare le retention policy per iniziare a far scadere i backup meno recenti.

Se non è possibile ridurre le retention policy a causa di requisiti normativi, prendere in considerazione l'espansione del sistema Avamar o la migrazione dei client a un altro Avamar, meno utilizzato.

5. Migrare i client a un sistema Avamar alternativo.

Se è disponibile un altro sistema Avamar, valutare la possibilità di migrare i client con un elevato tasso di modifica da sistemi più utilizzati ad altri meno utilizzati mediante l'interfaccia di Avamar Client Manager.

6. Eliminare i backup meno recenti.

Se il livello di capacità utente è grave (>90%), potrebbe essere necessario far scadere i vecchi backup tramite l'interfaccia Backup Management o con modify-snapups . 

Gli utenti Dell possono accedere al contenuto utilizzando il link all'articolo Avamar: Capacity Management: come eliminare o far scadere i backup in blocco con "modify-snapups" strumento

L'eliminazione dei backup non abbassa immediatamente il livello di utilizzo del server. ma consente alla garbage collection di iniziare la rimozione dei dati alla successiva esecuzione. L'eliminazione dei backup meno recenti è una soluzione alternativa a breve termine. I backup verranno sostituiti nei giorni successivi. Se i backup vengono eliminati, è essenziale anche regolare le retention policy.

7. Monitoraggio della modifica dei dati mediante capacity.sh.

Dopo l'eliminazione dei backup e la modifica delle policy di retention, monitorare attentamente la quantità di dati modificati nel sistema utilizzando il comando capacity.sh copione. Il valore dei dati "removed" deve aumentare e il valore "Net Change" deve diventare negativo. Nel momento in cui i dati in eccesso vengono eliminati dal sistema, il valore "Removed" inizia a tornare a livelli più normali. Continuare a monitorare il valore "Removed".

Se il valore della modifica netta non diventa negativo, controllare il registro GC per vedere per quanto tempo è in esecuzione la Garbage Collection e quanto lavoro sta svolgendo all'interno della finestra di manutenzione.

Scopri Avamar: Come gestire la capacità con capacity.sh script per ulteriori informazioni su come utilizzare il comando capacity.sh copione.

8. Espansione del sistema Avamar

Spesso un utilizzo elevato sulla griglia Avamar è dovuto alla crescita naturale e prevista dei dati. È necessario rendere disponibile più spazio per continuare i backup di produzione.

• Griglie a singolo nodo e Avamar Virtual Edition (AVE):

  • Questi sistemi non possono essere espansi. Eseguire il commissioning di un secondo sistema Avamar di dimensioni maggiori e richiedere a Dell Professional Services di eseguire una migrazione dal sistema più piccolo a quello più grande.
    • È possibile contattare Professional Services tramite il Dell Account Manager.
  • Il nuovo sistema può essere a singolo nodo, AVE o multinodo, se fornisce più spazio di storage rispetto all'origine.
• Griglie a più nodi:

  • Questi sistemi possono essere espansi fino a 16 nodi di dati.
    • Per ulteriori informazioni, contattare l'Account Manager Dell (i normali canali di supporto non eseguono aggiunte di nodi, pertanto non è necessario aprire una Service Request per richiedere questo lavoro).
• Integrazione di Data Domain:
  • L'integrazione di un sistema Data Domain come dispositivo di storage back-end è un modo utile per espandere la capacità disponibile per i client che eseguono il backup in Avamar.
    • Valutare le varie opzioni con il Dell Account Manager.

Strumenti utili

• status.dpn
• capacity.sh
• Avalanche
• DPN Summary Report
• replcnt.sh
• Avamar Client Manager

• Tentare di evitare che il valore di utilizzo (User Capacity) di Avamar Server superi l'80%.
• Un valore inferiore di User Capacity fornisce resilienza rispetto a modifiche impreviste nella quantità di dati aggiunta e può evitare che il sistema diventi inutilizzabile in caso di guasti imprevisti o problemi a breve termine con le attività di manutenzione.
• Un sistema Avamar in esecuzione con un valore di User Capacità superiore all'80% richiede un monitoraggio più diligente da parte del System Administrator per garantire che le attività di manutenzione vengano completate correttamente e che il sistema non diventi read-only.