Dentro Avamar


Global Client Deduplication


A cura di Luca Musumeci,


Dentro Avamar

Mi è spesso capitato, per lavoro, di parlare di Avamar. Penso sia una grande soluzione che, grazie alla sua architettura, rivoluziona radicalmente il concetto di backup.
Avamar è stato uno dei primi prodotti a portare sul mercato una vera soluzione di deduplica basata su disco.
Spesso si associa Avamar al solo concetto di deduplica, ma è vero che Avamar fa anche due cose a livello di client sostanzialmente uniche. Non è solo la deduplica, ma è la durata e l'utilizzo delle risorse del client Avamar che sono impressionanti. Non solo la deduplica riduce la quantità di dati da sottoporre a backup del 99%, ma, in molti casi, la durata di un backup di Avamar è del 90% inferiore alla durata di un backup tradizionale.
Chi è attento alla crescente quantità di dati e l'impatto sulle finestre di backup/restore, questa è una caratteristica di fondamentale importanza. Questo post ha lo scopo di rispondere a una domanda lecita: se Avamar sta facendo deduplica a livello di client, come può deduplicare a livello "globale"? Come può la deduplica essere cross-client nell'architettura Avamar?
La risposta è che Avamar utilizza un algoritmo di deduplica a segmentazione variabile.
La deduplica a lunghezza variabile è un metodo di segmentazione intelligente di un file in subfile. Come suggerisce il suo nome, la lunghezza dei segmenti varia, creando così rapporti di deduplica più elevati. La prima volta che il client Avamar esegue il processo di deduplica i dati del sistema sottoposti a backup vengono spezzati in segmenti (chunks). Questi chunks sono di lunghezza variabile, la cui dimensione dipende dal tipo di dati e da dove, all'interno della struttura del dato, risiede il segmento. La dimensione del blocco dell'inizio di un file può essere differente dalla dimensione del segmento della metà del file. Non a caso, questa variabile è in parte responsabile dei rapporti molto elevati di deduplica che Avamar può raggiungere.
Quando tutti i segmenti a lunghezza variabile sono stabiliti, a questi viene applicato un algoritmo SHA-1 (secure hash algorithm). Così ogni segmento ottiene un ID hash univoco che può essere utilizzato per identificare il segmento in futuro. Ogni hash associato ad un segmento su un client è in realtà memorizzato in due luoghi: una volta sul client (in un file chiamato p-cache.dat) e una volta sul server (come parte dei meta-dati che il server conserva).
Ed è questa la chiave! Prima che i dati effettivi vengano inviati al server per il backup, vengono inviati gli hash per quei chunks. In sostanza, il client chiede al server: avete già questo blocco di dati? Se il server determina che sta già mantenendo un blocco di dati che è presente sul client confrontando gli hash, allora non c'è bisogno per il client di inviare i dati al server. Solo quando il chunks è globalmente univoco, quindi  non presente e non già inviato da nessun client, i dati vengono trasmessi al server per il backup. Normalmente, questi hash sono raggruppati in grandi gruppi dal client per ridurre la complessità del processo di backup e ridurre il numero di pacchetti IP generati durante un backup.
Quindi, per esempio, se ho effettuato il backup di una presentazione e un collega esegue il backup della stessa presentazione il giorno successivo, il server informa l’agent che i chunks associati con la presentazione sono già presenti sul server e non sarà necessario eseguire il backup di nuovo. Tutto ciò che verrà inviato saranno i meta-dati associati con la presentazione in modo da permettere la reidratazione del dato per il restore.
In questo modo Avamar è in grado di eseguire i backup in locale, ma deduplica a livello globale. Il risultato è la riduzione del traffico di rete tra client di backup e il server Avamar di ben il 99% o più. A sua volta, questo rende Avamar estremamente efficace per il backup di uffici remoti e ambienti desktop/laptop.