Avamar: una coppia di replica mostra livelli diversi di uso della capacità. Come indagare le cause.

Cause e possibili motivi delle differenze tra i valori di "utilizzo del server":

Differenze logiche o fisiche tra le griglie:

• Numero diverso di nodi di dati nelle griglie di origine e di destinazione.
• I nodi dati di ciascuna griglia hanno configurazioni del disco diverse.
• Distribuzione adeguatamente bilanciata degli stripe tra i nodi di dati all'interno di ciascun sistema (entro il 2%)
• I requisiti di storage e parità variano a seconda delle versioni di Avamar. È possibile riscontrare una differenza nell'utilizzo se le versioni del software di origine e di destinazione differiscono.
• Il livello read-only del disco dell'Avamar Server potrebbe variare tra le due griglie.   
• Una griglia potrebbe essere configurata per la parità RAIN, a differenza dell'altra.

Configurazione della replica:

• I backup replicati nel sistema di destinazione possono avere una retention policy diversa rispetto all'origine. Per ulteriori informazioni, esaminare il flag expiredelta. In alternativa, i backup replicati possono coprire solo un determinato periodo di tempo. Ad esempio, le ultime 4 settimane di backup dall'origine.
• La replica può essere configurata in modo da riguardare solo un sottoinsieme di client dal sistema di origine al sistema di destinazione. Verificare se vengono utilizzate le impostazioni di inclusione o esclusione.
• I client e i backup associati potrebbero essere stati eliminati dal sistema di origine. L'eliminazione di un client o di backup sull'origine non rimuove gli stessi backup dal sistema di destinazione. I backup rimangono nella destinazione fino alla scadenza in base alle impostazioni di retention.
• Le retention policy possono essere modificate per i backup o i client sul sistema di origine. La modifica delle retention policy influisce solo sui nuovi backup. I nuovi backup vengono replicati nella destinazione e rispettano la retention policy aggiornata. I backup già esistenti nella destinazione conservano la retention policy applicata al momento della replica.

Precedente attività di capacity management:

• Spesso i clienti notano che uno dei sistemi della coppia di replica Avamar si sta avvicinando alla capacità massima e quindi intervengono per ridurla. Tenere presente che una coppia di repliche Avamar è costituita da due sistemi gestiti in modo indipendente. Se vengono effettuate azioni su un sistema, devono essere eseguite anche sull'altro. 
• Se nel sistema di origine vengono eliminati backup o ridotte le retention, è necessario apportare modifiche identiche nella destinazione. Il modo migliore per gestire la capacità in questo modo consiste nell'usare lo script modify-snapups. Questa operazione può essere eseguita su entrambi gli Avamar Server con le stesse opzioni di modifica/eliminazione di backup.  

Struttura di stripe diversa (ad esempio, più stripe di parità su un sistema):

• Essendo indipendenti, due sistemi Avamar possono avere come risultato strutture di stripe diverse. I sistemi a più nodi possono presentare differenze a causa dell'utilizzo di stripe di parità per proteggere i dati. A seconda della cronologia della capacità, due sistemi a più nodi contengono gli stessi backup, ma uno potrebbe avere un numero maggiore di stripe di parità rispetto all'altro.
• Come gli stripe normali, dopo la creazione, uno stripe di parità rimane sempre nel sistema. A differenza degli stripe normali, utilizza sempre una quantità fissa di spazio all'interno dell'Avamar Server. Ciò vale anche se gli stripe sicuri del gruppo di parità non contengono dati. La garbage collection non ha alcun effetto su questo comportamento.
• Un sistema di destinazione di replica è indirettamente protetto da gravi problemi di capacità su un'origine di replica. Tuttavia, la situazione potrebbe verificarsi su entrambi i computer se uno di essi è gestito in modo inadeguato dal punto di vista della capacità.
• Articolo correlato: Avamar mostra un utilizzo fino al 30%, anche dopo aver eliminato tutti i backup ed eseguito la Garbage Collection

Backup ancora presenti in MC_DELETED:

• Uno scenario raro da tenere presente è quello in cui un client viene eliminato sull'origine, ma i relativi backup vengono conservati. Ciò potrebbe comportare un utilizzo più elevato dell'origine rispetto alla destinazione, in cui i backup dovrebbero scadere naturalmente. L'utilizzo dello script dump_root_hashes.rb con l'opzione backupcompare consente di verificare questo scenario.

Dati sul sistema di destinazione da backup non replicati:

• Se il sistema esegue la replica in *una sola direzione*, verificare sulla destinazione che non esistano client al di fuori di /REPLICATE e MC_SYSTEM.

Altri comportamenti:

• I processi di replica potrebbero non essere completati in modo affidabile. I dati inviati alla destinazione potrebbero essere in ritardo di diversi giorni rispetto all'origine.
• Entrambi i sistemi contengono la stessa quantità di dati deduplicati, ma la quantità di overhead di parità su ciascuno di essi è diversa. Questa situazione si presenta nel seguente scenario: 
  • Un sistema di origine Avamar è quasi pieno. 
  • Molti backup vengono eliminati dal sistema di origine per ridurne il livello di capacità. 
  • La replica dei dati deduplicati avviene quindi dall'origine alla destinazione. 
  • La quantità di dati deduplicati è la stessa in entrambi i sistemi.
  • Inizialmente, il sistema di origine archivia un overhead di parità maggiore rispetto alla destinazione.
• La replica non copia stripe fisici dalla griglia di origine a quella di destinazione. Invece, la griglia di destinazione è autorizzata a determinare autonomamente dove sono archiviati stripe e blocchi di dati.
• In alcuni casi, i sistemi Avamar di destinazione possono archiviare i dati in modo più efficiente rispetto a una griglia di origine, dove i dati vengono originariamente sottoposti a backup.

Conoscere l'ambiente di replica:

• Prendere nota del nome host completo della griglia Avamar di origine.
• Esaminare la configurazione di replica dei sistemi interessati per capire quali sistemi replicano determinati dati e conoscere la relativa destinazione. 
  • Può essere utile tracciare uno schema dell'ambiente se è più complicato della replica da un Avamar Server a un altro.
• Se l'origine si integra con Data Domain (DD), verificare se il problema del cliente riguarda i backup replicati tra dispositivi DD.
• Prendere nota del nome host completo della griglia Avamar di destinazione e di tutti i dispositivi DD associati che ricevono backup replicati.

Verificare l'integrità generale e la situazione della griglia:

• Eseguire lo script di controllo proattivo su entrambe le griglie, ottenere una copia del file hc_results.txt ed esaminarlo per conoscere la situazione generale del sistema. 

Qual è il livello di gravità del differenziale di capacità?

• Il cliente deve fornire uno screenshot dello scenario che lo induce a ritenere che esista un differenziale di consumo di capacità tra l'origine e la destinazione.
• Non consideriamo motivo di allarme una differenza di capacità inferiore al 5%.
• Controllare l'interfaccia utente di Avamar Administrator per comprendere i livelli di capacità di Avamar Server e (se Data Domain è integrato) di capacità dei metadati.
• Tenere presente come viene visualizzata la capacità nell'interfaccia utente (argomento discusso in Il dashboard dell'interfaccia utente di Avamar in v7.2 e versioni successive mostra Metadata Utilization anziché Avamar Utilization).
• Eseguire il seguente comando su entrambi i sistemi. Il valore di Server Utilization fornisce un valore complessivo dei livelli di capacità di Avamar Server (ma non di Data Domain):

admin@utility:~/>: mccli server show-prop | grep "utilization"

Server utilization               3.7%

Verificare che l'hardware sia identico su entrambe le griglie:

• Ha senso confrontare le differenze di capacità solo per sistemi "simili". 
• Utilizzando l'output del controllo proattivo, annotare il tipo di nodi presenti nel sistema.
• Il comando seguente mostra il numero complessivo, le dimensioni e il consumo dello spazio sui nodi fisici:

admin@utility:~/>: mccli server show-prop | grep "Capacity\|capacity\|nodes"

Total capacity                   23.3 TB
Capacity used                    858.5 GB
Number of nodes                  3

• Questo output consente di determinare facilmente il numero e la dimensione dei nodi nel sistema. Sono (23,3/3 = circa 7,8 TB). 
• Il numero e le dimensioni delle partizioni del disco rigido su ogni nodo devono confermare questa condizione.

admin@utility:~/>: mapall 'df -h' | grep data

(0.0) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.2 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   54G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   53G  1.8T   3% /data04
/dev/sde1       1.9T   52G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06
(0.1) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.3 'df -h'
/dev/sda3       1.8T   56G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   52G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   53G  1.8T   3% /data06
(0.2) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.4 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06

• Con queste informazioni, controllare quanto segue:

Controllare la versione e la configurazione del software:

• Utilizzando l'output del comando status.dpn, confrontare la versione di Avamar in esecuzione su ciascun sistema.
• Per i sistemi a più nodi, verificare che entrambi siano configurati con parità RAIN in base a quanto riportato in Avamar: come determinare se un server è di tipo RAIN o non RAIN.
• Controllare e confrontare i parametri di configurazione di Avamar Server correlati alla capacità dei due sistemi. Ad esempio:

admin@utility:~/>: avmaint config --ava | grep -i "capacity\|disk"

  disknocreate="90"
  disknocp="96"
  disknogc="85"
  disknoflush="94"
  diskwarning="50"
  diskreadonly="65"
  disknormaldelta="2"
  freespaceunbalancedisk0="20"
  diskfull="30"
  diskfulldelta="5"
  balancelocaldisks="false"

Controllare il bilanciamento degli stripe:

• Controllare l'output di status.dpn e prendere nota del numero totale di stripe su ciascun nodo di dati. Il numero di stripe è indicato tra parentesi quadre (ad esempio, onl:xxx). 
• Dovrebbe essere rilevata una differenza inferiore al 2% tra il numero totale di stripe su ogni nodo di dati.  

Verificare che la Garbage Collection sia stata eseguita correttamente su entrambi i sistemi:

• Se la Garbage Collection non funziona in modo costante ed efficace, non rimuove i dati scaduti. Il sistema segnala un uso della capacità superiore al previsto. 
  • Per ulteriori informazioni, consultare l'articolo del percorso di risoluzione con GC nelle note con limitazioni.  

Verificare che la replica sia stata completata correttamente:

• Verificare che tutte le attività di replica dall'origine alla destinazione vengano completate. In caso contrario, è possibile che vi siano ancora dati da replicare dall'origine alla destinazione.  

Controllare la configurazione di replica:

• Cercare nella configurazione di replica (nella GUI, nella CLI o nei registri) uno qualsiasi dei seguenti flag:  

--before
--after
--include
--exclude

--expiredelta

--retention-types

--retention-types=none,daily,weekly,monthly,yearly

Controllare i tassi di acquisizione e rimozione dei dati di entrambi i sistemi:

• Eseguire proactive_check.pl --capacity su entrambi i sistemi e confrontare i tassi di acquisizione dei sistemi di origine e di destinazione.
• Se la destinazione è essenzialmente un sistema di destinazione e riceve TUTTI i backup dall'origine, il suo tasso di acquisizione dovrebbe seguire da vicino quello dell'origine.
• Le colonne Avamar NEW o DDR NEW mostrano la quantità di nuovi dati aggiunti a tali sistemi.
• Prestare inoltre molta attenzione alle colonne "removed", "mins" e "pass" per comprendere il comportamento della Garbage Collection su entrambi i sistemi.
• Queste informazioni forniscono una visione chiara di ciò che accade su entrambi i sistemi.
• Per ulteriori informazioni sull'interpretazione dell'output, consultare Avamar: come gestire la capacità con lo script capacity.sh  

Eseguire il dump di un elenco di backup esistenti su ciascun sistema:

• Lo script dump_root_hashes.rb è un'utilità che consente di confrontare la differenza nei backup archiviati tra un sistema Avamar di origine e uno di destinazione, anche se i backup sono in hosting sullo storage Data Domain.   
• Vedere Avamar: Avamar: come utilizzare lo script dump_root_hashes.rb per generare un elenco di client e backup per informazioni sul download dell'utilità e sui casi d'uso, incluso il confronto del contenuto di due sistemi Avamar.
  • Eseguire lo strumento. Verificare la presenza di incoerenze nei numeri dei backup su tutti i client. Prestare attenzione alle differenze di +/-2.  
• Come illustrato nella sezione relativa alle cause, il capacity management asimmetrico comporta differenze tra i due sistemi. Esaminare l'output per determinare se potrebbe essere questo il caso.
• Inoltre:
  • Controllare la destinazione per i dati sul sistema di destinazione da backup non replicati.
  • Controllare l'origine per i dati non replicati nella destinazione.  

Verificare se le strutture di stripe sono diverse (ad esempio, più stripe di parità su un sistema):

• Essendo indipendenti, i due sistemi Avamar possono avere strutture di stripe diverse. I sistemi a più nodi possono presentare differenze a causa dell'utilizzo di stripe di parità per proteggere i dati. A seconda della cronologia della capacità, due sistemi a più nodi contengono gli stessi backup, ma uno potrebbe avere un numero maggiore di stripe di parità rispetto all'altro.  
• Come gli stripe normali, dopo la creazione, uno stripe di parità rimane nel sistema. A differenza degli stripe normali, utilizza sempre una quantità fissa di spazio all'interno di Avamar, anche se gli stripe sicure del gruppo di parità non contengono dati. La garbage collection non ha alcun effetto su questo comportamento.
• Un sistema di destinazione di replica è indirettamente protetto da gravi problemi di capacità su un'origine di replica. Tuttavia, la situazione potrebbe verificarsi su entrambi i computer se uno di essi è gestito in modo inadeguato dal punto di vista della capacità.
• Articolo correlato:  Avamar mostra un utilizzo fino al 30%, anche dopo aver eliminato tutti i backup ed eseguito la Garbage Collection  

Backup ancora presenti in MC_DELETED:

• Uno scenario raro da tenere presente è quello in cui un client è stato eliminato sull'origine, ma i relativi backup sono stati conservati. Ciò comporta un utilizzo più elevato dell'origine rispetto alla destinazione, in cui i backup dovrebbero scadere naturalmente. L'utilizzo dello script dump_root_hashes.rb con l'opzione backupcompare consente di verificare questo scenario.