Un checkpoint Avamar è un set di directory di sola lettura nei nodi di dati Avamar.
È come un'istantanea point-in-time del sistema Avamar. Potrebbe essere utile ai fini del rollback se il sistema Avamar riscontra un problema grave che non può essere risolto.
Lo strumento
cplist crea un elenco di checkpoint esistenti in un sistema Avamar.
Lo strumento può essere eseguito da chiunque abbia accesso all'utility node Avamar.
Comprendere quali sono i checkpoint esistenti e le relative condizioni è fondamentale prima di prendere una decisione su come procedere su un sistema che sta riscontrando un problema o in fase di manutenzione.
Presupposti errati sullo stato dei checkpoint possono causare la perdita di dati o un sistema Avamar irrecuperabile.
Questo articolo aiuta il lettore a interpretare l'output dello strumento.
Di seguito è riportato un output di esempio del comando cplist.
cp.20130915110057 Sun Sep 15 12:00:57 2013 valid rol --- nodes 3/3 stripes 3530
cp.20130915110654 Sun Sep 15 12:06:54 2013 valid --- --- nodes 3/3 stripes 3530
Esaminiamo il primo checkpoint sopra e parliamo del significato di ogni campo dati.
Nome del tag checkpoint - cp.20130915110057
- Questo è il tag di identificazione per il checkpoint e corrisponde all'ora di avvio del checkpoint. Cp. YYYYMMDDHHMMSS
- Da Avamar v7.1, i checkpoint vengono assegnati con numeri di serie invece di essere contrassegnati con la data e l'ora di inizio del checkpoint.
Tempo impiegato - Dom 15 set 12:00:57
- Il giorno, la data e l'ora in cui è stato creato il checkpoint. Questo corrisponderà sempre al tag del checkpoint.
Validità - valida
- Se questo campo mostra "valid", il checkpoint è "wholesome".
- Validity indica se il checkpoint è utile per scopi di rollback.
- Se questo campo mostra "valid", ciò non significa che il checkpoint sia stato sottoposto alla convalida di HFSCheck.
- Il campo di validità è valido quando si esegue "cplist" poiché per impostazione predefinita il comando mostra checkpoint utilizzabili.
- L'esecuzione di "cplist --full" mostrerà tutti i checkpoint sul sistema, inclusi quelli non utilizzabili per scopi di rollback.
Tipo di convalida di HFScheck - "rol"
- Questo campo mostra il tipo di convalida del controllo HFS eseguita sul checkpoint.
- I tipi possibili sono "hfs", "rdc", "par", "rol"
- hfs o full: significa che la convalida è stata eseguita in tutti gli stripe nel checkpoint.
- roll - significa che la convalida ha verificato tutti gli stripe nuovi o modificati nel checkpoint.
- La ricerca ha dimostrato che quando si verificano problemi di integrità dei dati, in genere gli stripe interessati sono quelli appena creati o modificati di recente. Per questo motivo, Avamar Engineering consiglia che la convalida a rotazione sia considerata praticamente affidabile come una convalida HFScheck più lunga e completa.
- A seconda del tasso di acquisizione dei dati del sistema Avamar, un controllo HFS continuo può anche controllare una proporzione di stripe non modificate di un checkpoint. Ciò significa che, alla fine, tutti gli stripe, anche quelli che non sono stati modificati, possono essere controllati dall'integrità.
- rdc - indica che la convalida è stata completata, ma che un nodo non ha partecipato alla convalida. Tipo di convalida non specificato.
- L'integrità dei dati non può essere garantita per i checkpoint contrassegnati come rdc. Tale controllo fornisce una maggiore fiducia nell'integrità dei dati rispetto alla non convalida.
Eliminabile "---"
- Questo campo indica se il checkpoint può essere eliminato, in base alle impostazioni di retention dei checkpoint in vigore sull'Avamar Server.
- La retention dei checkpoint è controllata dai parametri "cphfschecked" e "cpmostrecent".
- La retention dei checkpoint deve essere lasciata come predefinita, a meno che non sia consigliato da un tecnico del supporto.
- Le impostazioni di retention dei checkpoint errate possono mettere un sistema Avamar a rischio di perdita di dati o possono causare problemi di capacità del sistema operativo.
REFCOUNT/NODECOUNT - "nodo 3/3"
- Il primo numero è il numero rif. Riporta il numero di nodi che hanno risposto al comando cplist. Questo valore non indica necessariamente il numero di nodi che sono online.
- Il secondo numero è il numero di nodi. Questo si riferisce al numero di nodi che hanno partecipato al momento in cui è stato originariamente effettuato il checkpoint. In altre parole, quanti nodi di dati contengono quella particolare directory di checkpoint.
- Annotare attentamente lo stato del sistema (numero totale di nodi e numero di nodi online) e il modo in cui è stato eseguito cplist, prima di prendere in considerazione il significato dell'output di questi due campi.
Campo conteggio stripe - "3530"
- Questo campo visualizza il numero totale di stripe acquisite nel checkpoint.
- Una convalida dei checkpoint in corso convalida un sottoinsieme di questo numero di stripe.
- Una convalida completa dei checkpoint li convalida tutti.
Esempi di output
cplist
Esempio 1:
cp.20130914190119 Sat Sep 14 20:01:19 2013 valid rol --- nodes 1/1 stripes 1401
cp.20130914192153 Sat Sep 14 20:21:53 2013 valid --- --- nodes 1/1 stripes 1401
Cosa ci dice questo?
- Si tratta di un sistema a singolo nodo.
- Esistono due checkpoint "interi" o utilizzabili.
- cp.20130914190119 è stato convalidato con un controllo HFS continuo, l'altro checkpoint non è stato convalidato.
- Entrambi i checkpoint hanno acquisito 1.401 stripe.
Esempio 2:
cp.20130911150620 Wed Sep 11 11:06:20 2013 valid rol --- nodes 9/9 stripes 121107
cp.20130911160421 Wed Sep 11 12:04:21 2013 valid --- --- nodes 9/9 stripes 121107
cp.20130912151051 Thu Sep 12 11:10:51 2013 valid --- --- nodes 8/9 stripes 121107
Cosa ci dice questo?
- Durante ogni checkpoint, nove nodi hanno partecipato al processo di creazione del checkpoint. Si potrebbe presumere che ci siano nove nodi nel sistema, ma non fare affidamento esclusivamente sull'output cplist per queste informazioni.
- Il meno recente dei tre checkpoint è stato convalidato con un controllo HFS continuo.
- Il checkpoint più recente (12 settembre) è attualmente inaccessibile su uno dei nove nodi che formano tale checkpoint.
Esempio 3:
cp.20130915110057 Sun Sep 15 12:00:57 2013 valid rol --- nodes 3/3 stripes 3530
cp.20130915110654 Sun Sep 15 12:06:54 2013 valid --- del nodes 3/3 stripes 3530
cp.20130916053830 Mon Sep 16 06:38:30 2013 valid --- --- nodes 3/3 stripes 3530
cp.20130916060236 Mon Sep 16 07:02:36 2013 valid --- --- nodes 2/2 stripes 3530
Cosa ci dice questo?
- cp.20130915110654 è idoneo per essere eliminato in base alle regole di retention dei checkpoint.
- cp.20130916060236 è stato preso mentre uno dei tre nodi era offline.
Esempio 4:
Se un sistema Avamar è integrato con Data Domain, cplist può mostrare che i checkpoint non sono validi se il sistema Data Domain diventa non disponibile. Esempio:
cp.20130830173413 Fri Aug 30 10:34:13 2013 valid hfs --- nodes 1/1 stripes 82
cp.20130831000113 Fri Aug 30 17:01:13 2013 valid hfs --- nodes 1/1 stripes 82
Se il dispositivo Data Domain è spento;
admin@utility:~/>: cplist
cplist: ERROR: ddrmaint: <4750>Datadomain get checkpoint list operation failed.
2013/09/17-14:28:06.79970 [cplist] ERROR: <0001> ddrmaint: <4750>Datadomain get checkpoint list operation failed.
cp.20130830173413 Fri Aug 30 10:34:13 2013 invalid --- --- nodes 1/1 stripes 82
cp.20130831000113 Fri Aug 30 17:01:13 2013 invalid --- --- nodes 1/1 stripes 82