Avamar: Comportamento e teoria delle prestazioni di backup

Lo scopo di questo articolo è quello di descrivere cosa accade durante un backup di Avamar, aiutando il lettore a comprendere il comportamento delle prestazioni di backup.

Questo articolo è complementare ai seguenti articoli:

• Avamar: Risoluzione dei problemi relativi alle prestazioni di backup lente
• Avamar: Ottimizzazione dei backup per un rapido completamento

Cosa succede durante un backup Avamar?

Processo di backup avtar :

1) Carica i file e i file della cache hash in memoria

2017-06-09 23:00:25 avtar Info <5586>: Loading cache files from C:\Program Files\avs\var
2017-06-09 23:00:25 avtar Info <8650>: Opening filename cache file 'C:\Program Files\avs\var\f_cache2.dat'
2017-06-09 23:00:25 avtar Info <5573>: - Loaded filename cache file (6,532,792 bytes)
2017-06-09 23:00:26 avtar Info <8650>: Opening hash cache file 'C:\Program Files\avs\var\p_cache.dat'
2017-06-09 23:00:28 avtar Info <5573>: - Loaded hash cache file (402,653,728 bytes)
2017-06-09 23:01:01 avtar Info <6426>: Done loading cache files

2) Crea istantanee VSS (su Windows):

2017-06-09 23:04:32 avtar Info <19008>: Obtaining available VSS providers
2017-06-09 23:04:32 avtar Info <8776>: Freezing volumes now...
2017-06-09 23:04:32 avtar Info <8780>: Creating the shadow copy set (DoSnapshotSet) ... 
2017-06-09 23:14:33 avtar Info <8781>: Shadow copy set successfully created.
2017-06-09 23:14:34 avtar Info <6074>: VSS snapshot set creation successful

3) Esamina tutti i file definiti dal set di dati Per tutti i file all'interno del set di dati di
origine, avtar prende il percorso completo e lo combina con i metadati simili a statistiche per calcolare un hash per identificare in modo univoco il file.

Per ulteriori dettagli, vedere Avamar: Cosa succede quando avtar legge un file durante la fase di scansione dei file.

4) Confronta gli hash calcolati con quelli nella cache del client locale:

Avtar cerca l'hash del file nella cache del file. Verifica se è nuovo o se è stato modificato dal backup precedente.

Se la ricerca nella cache dei file ha esito positivo, il file esiste e non viene modificato.

Se la ricerca non riesce, il file è nuovo o è stato modificato. Deve essere letto ed elaborato.

Per ulteriori dettagli, vedere Avamar Client - Cosa deve cambiare prima che avtar consideri un file come modificato?

5) Elaborare file nuovi e modificati Per qualsiasi file

nuovo o modificato avtar deve:

• Leggi l'intero file
• Suddividilo in blocchi di dimensioni variabili
• Comprimere ogni blocco
• Calcolare un hash per ogni blocco

6) Verificare se sono presenti hash mancanti sull'Avamar Server.

Avtar invia i dati per eventuali hash mancanti sulla rete ad Avamar Server per verificare se esistono già. Queste sono note come richieste

"ispresent".7) I dati vengono scritti sull'Avamar Server (e, se appropriato, su Data Domain). 

Per un flusso di lavoro più dettagliato, consultare il Avtarprocess.pdf allegato.


Panoramica di un backup Avamar dal punto di vista delle prestazioni:

Prendendo in considerazione le fasi precedenti, le suddividiamo in "fasi" che hanno il maggiore impatto sulle prestazioni di backup:

Fase 0. Creare snapshot VSS.

Il Servizio Shadowcopy del volume (VSS) crea snapshot dei volumi specificati nel dataset di origine. Le applicazioni possono continuare a scrivere sul volume durante l'esecuzione del backup.
Avamar esegue il backup dell'istantanea "congelata" di sola lettura del volume anziché del volume scrivibile. In questo modo si ha la certezza di disporre di un set coerente di dati di cui eseguire il backup.

Il completamento delle istantanee VSS richiede secondi. Se un client riscontra problemi VSS, questo ritardo impedisce l'esecuzione del backup.

Fase 1. Fase di scansione dei file. Il processo avtar certifica tutte le statistiche di tutti i file nel dataset

di destinazionePer i client con milioni di file, questa fase può richiedere più tempo.
Poiché i dati del database contengono pochi file di grandi dimensioni, la fase di scansione dei file richiede poco tempo. I client di database in genere consumano il loro tempo durante la fase #2.

Per un client con dischi a rotazione in configurazione RAID 5, sono tipiche prestazioni di scansione di ~1 milione di file all'ora. Questo varia da 300.000 a 3 milioni all'ora. Dipende dall'ambiente client e dalle caratteristiche dei dati di cui viene eseguito il backup.

A partire dalla versione 7.3, i client Linux che eseguono il backup su Data Domain possono sfruttare la funzionalità Fast Incremental (LFI) di Linux. In questo modo si evita di eseguire la scansione dell'intero dataset ogni volta che viene eseguito il backup.

Risorse critiche: prestazioni di ricerca casuale del disco in cui sono archiviati i dati di backup.

Fase 2. Inoltre, legge i file modificati, quindi suddivide in blocchi, comprime ed esegue l'hashing dei dati.

Durante questa fase viene eseguita una grande quantità di calcolo. Per ogni file nuovo o modificato, avtar lo suddivide in piccoli blocchi. Comprime ogni blocco e calcola un hash come "impronta digitale" per identificare il blocco.

I file nei backup dei database sono spesso di grandi dimensioni e tendono a cambiare ogni giorno. Avtar trascorre la maggior parte del suo tempo in questa fase. È consigliabile utilizzare i plug-in del database Avamar ufficiali per garantire che il database venga gestito in modo efficiente, sfruttando funzionalità di backup incrementali, registri delle transazioni e così via.

Le prestazioni tipiche di elaborazione dei file sono di circa 100 GB all'ora, ma possono variare fino a 300 GB all'ora. Questa operazione dipende dall'ambiente.

Risorse critiche: Disco client e CPU

Per i backup LAN in cui non sono presenti colli di bottiglia nell'invio di dati ad Avamar Server, le fasi #1 e #2 richiedono più tempo.

Nel grafico seguente, tenere presente che la quantità di area nelle barre del grafico corrisponde al tempo necessario per il backup. I file modificati possono aumentare drasticamente la quantità di tempo richiesta, soprattutto se sono file di grandi dimensioni.

Per i dataset del file system, si prevede che ~0-3% di file cambi su base giornaliera.

Avtar deve eseguire 'stat()' ogni file che viene modificato eseguendo due operazioni di I/O, una per controllare gli attributi del file, un'altra per gli attributi di sicurezza.

Per ottenere le prestazioni della velocità di scansione di benchmark di ~1 milione di file/ora per i backup del file system, avtar richiede circa due milioni di operazioni di ricerca all'ora o 600 operazioni di ricerca al secondo.

Ad esempio: Se un backup ha un tasso di modifica del 3%, 97 file su 100 richiedono due operazioni di ricerca del disco per identificare se sono stati modificati. I restanti tre elementi che sono stati modificati devono essere sottoposti a scansione, suddivisione in blocchi, compressione e hashing.

Viene considerata solo la fase di scansione dei file e non vengono prese in considerazione le risorse di I/O necessarie per l'elaborazione dei file modificati.
Maggiore è la quantità di dati all'interno dei file modificati, maggiore sarà il lavoro necessario per completare il backup.

Fase 3. Verifica dell'esistenza di hash sull'Avamar Server

Le fasi #1 e #2 producono hash che puntano a elementi del backup. Questi elementi possono essere blocchi di file univoci, file system o interi backup.

Gli hash vengono scritti nei file della cache del client e confrontati con gli hash presenti sull'Avamar Server per verificare se è necessario aggiungere nuovi dati. Ciò vale se lo storage di destinazione è un Avamar Server o Data Domain.

I confronti hash tra Avamar Client e Server sono in genere rapidi. Non devono creare colli di bottiglia nel backup se l'Avamar Server è;

• Sano
• Sotto livelli di carico normali
• Si trova sullo stesso segmento LAN del client

Poiché gli hash hanno una dimensione di soli 20 byte, questa fase è influenzata più dalla latenza di rete che dalla larghezza di banda della rete. Quando l'hash arriva all'Avamar Server, il carico generale e le prestazioni di ricerca casuale del sottosistema del disco dei nodi di dati determinano la velocità con cui l'hash viene recuperato e confrontato con quello inviato dal client.

Risorse critiche: Tempo di risposta della rete e prestazioni di ricerca casuale del nodo dati Avamar.

Le prestazioni di ricerca casuale di una bilancia Avamar fisica con il numero e la dimensione dei nodi di dati. Le prestazioni dei sistemi AVE sono inferiori, paragonabili a quelle di un sistema a singolo nodo.

Fase 4. Invio del nuovo blocco in rete ad Avamar Server o a Data Domain

Quando un client invia un blocco nuovo e univoco (fino a 64 KB) al server, le prestazioni si basano principalmente sulla larghezza di banda della rete. Ciò riguarda principalmente i client basati su WAN che generano una grande quantità di dati modificati ogni giorno. Può anche influire su quelli che operano su collegamenti di rete congestionati. 

Di seguito sono riportati gli schemi che mostrano il flusso di dati in cui un client invia i dati a un sistema Avamar e a un sistema integrato Avamar-Data Domain.






Risorse critiche: Larghezza di banda di rete tra client e server

Fase 5. Dati scritti su Avamar Server o Data Domain

I dati di backup devono essere scritti sull'Avamar Server o sul sistema Data Domain.

Risorse critiche: Prestazioni di scrittura su disco e caricamento generale di Avamar Server.