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 si trovano in Come individuare la documentazione di Avamar sul sito del Supporto Dell.

Obiettivi di questo articolo:
 

• Riepilogare i tipi di dati archiviati nelle partizioni /data*.
• Introdurre il concetto di "capacità del sistema operativo" e confrontarlo con il concetto di "capacità utente" (talvolta detto "GSAN Capacity").
• 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 "Managing Capacity" del manuale Avamar Operational Best Practices Guide.

Le guide relative all'ambiente operativo in uso si trovano in Come individuare la documentazione di Avamar sul sito del Supporto Dell.

I problemi comuni che interessano o sono sintomi di un valore elevato di "Operating System Capacity" sono i seguenti:

• La convalida del checkpoint (hfscheck) non riesce.
• La garbage collection non viene eseguita e restituisce il messaggio MSG_ERR_DISKFULL.
• Errori di creazione del checkpoint.

I sintomi più comuni strettamente associati a un valore elevato di User Capacity sono:

• 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.

Consultare la sezione Risoluzione.

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, ovvero:

• 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.

Per eseguire correttamente attività di manutenzione come le garbage collection e lo stripe crunching asincrono, è necessario disporre di spazio libero nelle partizioni di dati.

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

 

Come vengono archiviati i dati nelle partizioni di dati?

Nel diagramma precedente abbiamo visto una semplice rappresentazione della modalità di utilizzo dello spazio nelle partizioni dei dati.

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

Se una qualsiasi delle partizioni di dati utilizza più dell'85% dello spazio totale, non è possibile eseguire la garbage collection.

L'indicatore di User Capacity al 100% (limite read-only) indica che fino al 65% dello spazio totale nella partizione di dati è disponibile per lo storage di 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 archiviata in una partizione di dati su qualsiasi nodo raggiunge il 65%, il sistema Avamar diventa read-only e rifiuta ulteriori dati di backup.

Possiamo così comprendere che, dall'interfaccia utente di Avamar Administrator, l'utente ha visibilità sullo spazio utilizzato dai backup, ma non sullo spazio utilizzato nelle partizioni di 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.

Analizzare in dettaglio i motivi in merito a questa condizione non rientra nell'ambito dell'articolo, ma è importante tenere presente che: Più il valore di User Capacity di un sistema Avamar si avvicina al 100%, minore è la capacità disponibile del sistema operativo per l'overhead del checkpoint.

Su un sistema con spazio esaurito, come possiamo vedere nel diagramma precedente, l'overhead del checkpoint è limitato al 20% dello spazio totale del sistema operativo nelle partizioni di dati.

Affinché un sistema Avamar venga eseguito in modo affidabile con livelli elevati di "User Capacity", deve soddisfare i seguenti criteri:

• 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:

I seguenti fattori possono contribuire 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 di monitorare l'utilizzo della partizione di dati del sistema operativo è quello di utilizzare il seguente comando di Avamar da Avamar Utility Node.

Ad esempio:

admin@utilitynode:~/>: avmaint nodelist | grep fs-percent
        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 di un utente, la prima indicazione del fatto che l'utilizzo della partizione di dati è fuori controllo si verifica quando supera l'85%.

La garbage collection non è più eseguibile e ha esito negativo con messaggio di errore MSG_ERR_DISKFULL .

Qui si verificano spesso malintesi: L'utente spesso interpreta il messaggio MSG_ERR_DISKFULL come indicazione del fatto che il sistema non ha più spazio per i backup.

Questa interpretazione non è corretta: l'utente controlla in genere il valore di Server Utilization nell'interfaccia utente di Avamar Administrator e trova un valore accettabile, ad esempio 60%.

L'utente potrebbe tentare di eliminare i backup dall'interfaccia di gestione dei backup dell'interfaccia utente di Avamar. Anche se il livello di User Capacity è elevato, l'eliminazione dei backup non risolve la situazione, poiché non è possibile eseguire la garbage collection e i blocchi scaduti di dati non vengono rimossi dal sistema.

Se in un sistema si verifica un problema di alta capacità del sistema operativo e al contempo è presente un valore elevato di User Capacity, concentrarsi prima sulla risoluzione del problema di alta capacità 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?

La causa più tipica è un eccessivo overhead del checkpoint. Le cause tipiche di un overhead elevato del checkpoint potrebbero essere le seguenti:

• La convalida del checkpoint (hfscheck) non riesce ripetutamente.
• L'errore in hfscheck ha molte possibili root cause (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 lo scenario MSG_ERR_DISKFULL: Le attività di manutenzione Avamar non riescono con "MSG_ERR_DISKFULL" a causa della capacità della partizione "Data" del sistema operativo >89% (in inglese).

 

Azioni per analizzare e provare a ridurre l'elevata capacità del sistema operativo.

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

• In Avamar Administrator 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.

• 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

 

2. Verificare se HFScheck è stato eseguito o se non è riuscito.

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

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, acquisire un nuovo checkpoint ed eseguire hfscheck oppure attendere il completamento della successiva finestra di manutenzione pianificata.

Una volta completato correttamente hfscheck (dopo aver risolto eventuali problemi o riavviato lo strumento di manutenzione), il checkpoint meno recente viene "rimosso" e la capacità del sistema operativo dovrebbe ridursi considerevolmente.

• Se la capacità del sistema operativo è ancora troppo elevata e la garbage collection continua a non riuscire con il messaggio MSG_ERR_DISKFULL, richiedere l'assistenza del 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 Capacity del sistema operativo, 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 in un sistema di dimensioni adeguate il valore di User Capacity può aumentare rapidamente se la garbage collection non viene eseguita in modo regolare o affidabile.

Come illustrato in precedenza, verificare che la finestra di manutenzione sia abilitata e utilizzare gli script capacity.sh e sched.sh per verificare che la garbage collection sia in esecuzione e che stia rimuovendo i 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 in Avamar v7.x consente l'esecuzione di backup durante l'attività di manutenzione della garbage collection. La funzione richiede che queste "mappe" presentino almeno 5 minuti di tempo "inattivo" 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.
 

Una volta che un grid Avamar esaurisce quasi completamente la capacità, è opportuno interrompere immediatamente l'aggiunta di nuovi client per evitare che la situazione peggiori.

Se un altro grid Avamar è in esecuzione a un livello inferiore di utilizzo del server, valutare l'aggiunta di nuovi client al grid anziché al server con spazio quasi esaurito.


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

Per risolvere un problema di capacità, è opportuno identificare i client che aggiungono la maggior parte dei dati al sistema Avamar.

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

Gli utenti registrati Dell possono accedere al contenuto utilizzando il link all'articolo Avamar: come gestire la capacità con lo script capacity.sh per ulteriori dettagli su come utilizzare lo script capacity.sh.

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

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 è 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.

Se il livello di User Capacity è Severe (>90%), potrebbe essere necessario far scadere i backup meno recenti tramite l'interfaccia di Backup Management o con lo strumento 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 lo strumento "modify-snapups".

L'eliminazione dei backup non riduce 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 vengono sostituiti nei giorni successivi. Se i backup vengono eliminati, è essenziale anche regolare le retention policy.

Dopo aver eliminato i backup e modificato le retention policy, monitorare attentamente la quantità di modifiche dei dati sul sistema tramite lo script capacity.sh. Il valore dei dati "Removed" dovrebbe iniziare ad aumentare e il valore di "Net Change" dovrebbe 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 di Net Change non diventa negativo, controllare il registro della garbage collection per verificare la durata di esecuzione del processo e la quantità di attività eseguite durante la finestra di manutenzione.

Gli utenti Dell possono accedere al contenuto utilizzando il link all'articolo Avamar: Come gestire la capacità con lo script capacity.sh per ulteriori dettagli su come utilizzare lo script capacity.sh.

Spesso l'utilizzo elevato sul sistema Avamar è dovuto a una crescita naturale e prevista dei dati. È necessario rendere disponibile ulteriore spazio per continuare i backup di produzione.

Il modo in cui è possibile eseguire questa operazione dipende dal tipo di sistema Avamar.

• Sistemi a nodo singolo e sistemi 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 coinvolgere Professional Services tramite il Dell Account Manager.

Il nuovo sistema può essere un nodo singolo, un AVE o un sistema a più nodi, se fornisce più spazio di storage rispetto all'origine.

• Sistemi a più nodi

Questi sistemi possono essere espansi fino a 16 nodi di dati. Per ulteriori informazioni, contattare il Dell Account Manager. I canali di supporto normali non eseguono aggiunte di nodi, pertanto non aprire una Service Request per richiedere questa operazione.

• Integrare un 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
• Report DPN Summary
• replcnt.sh
• Avamar Client Manager

Best practice:

• 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.