Risoluzione dei problemi relativi a un rapporto di deduplica e compressione insufficiente dei file su Data Domain Restorer (DDR)

I DDR (Data Domain Restorer) sono progettati per contenere grandi quantità di dati logici (precompressi) utilizzando uno spazio su disco fisico minimo (postcompresso). Questa operazione viene eseguita utilizzando:

• Deduplica dei dati acquisiti per rimuovere blocchi duplicati di dati già archiviati su disco nel DDR, lasciando solo i dati univoci
• Compressione dei dati univoci prima che i dati siano scritti fisicamente su disco.

Il rapporto di compressione complessivo dei dati che un DDR può acquisire varia a causa di diversi fattori, ad esempio:

• Use case
• Tipi di dati acquisiti
• Configurazione dell'applicazione di backup

Quando sono configurati in modo ottimale, i DDR in genere raggiungono un rapporto di compressione complessivo di 10-20 volte (e a volte possono mostrare rapporti superiori a questo). Al contrario, tuttavia, in alcuni ambienti il rapporto di compressione complessivo può essere inferiore a questo, il che può causare:

• DDR per esaurire rapidamente la capacità utilizzabile
• Impatto sulle prestazioni di backup, restore o replica
• Incapacità del DDR di soddisfare le aspettative dei clienti

Questo articolo ha lo scopo di illustrare:

• Una breve panoramica della deduplica e della compressione dei dati su un DDR
• Come determinare il rapporto di compressione complessivo per il sistema e i singoli file
• Fattori che possono causare un peggioramento del rapporto di compressione complessivo

In che modo un data domain restorer acquisisce nuovi dati?

• L'applicazione di backup invia i dati (ovvero i file) al DDR.
• Il DDR suddivide questi file in blocchi di dimensioni da 4 a 12 KB: ogni blocco è visto come un "segmento".
• Il DDR genera un 'impronta digitale' univoca (simile a un checksum) per ogni segmento a seconda dei dati contenuti all'interno del segmento.
• Le impronte digitali dei segmenti appena arrivati vengono verificate sugli indici dei dischi sul DDR per determinare se il DDR contiene già un segmento con lo stesso impronta digitale.
• Se la DDR contiene già un segmento con la stessa impronta digitale, il segmento corrispondente nei dati appena ricevuti è un duplicato e può essere eliminato (deduplicato).
• Una volta rimossi tutti i segmenti duplicati dai dati appena ricevuti, rimangono solo i segmenti univoci o nuovi.
• Questi segmenti univoci o nuovi vengono raggruppati in "aree di compressione" da 128 Kb, quindi compressi (utilizzando l'algoritmo lz per impostazione predefinita).
• Le aree di compressione compresse sono imballate in unità di storage da 4,5 Mb, conosciute come "contenitori", che vengono quindi scritte sul disco rigido.

In che modo la DDR tiene traccia di quali segmenti costituiscono un determinato file?

Oltre alla deduplica/compressione dei dati appena ricevuti, il DDR crea anche una "struttura ad albero dei segmenti" per ogni file ingerito. Si tratta essenzialmente di un elenco di "impronte digitali" del segmento che costituiscono tale file. Se il DDR deve leggere nuovamente il file in un secondo momento, è possibile:

• Determinare la posizione della struttura ad albero del segmento di file.
• Leggere la struttura ad albero dei segmenti per ottenere un elenco di tutte le impronte digitali dei segmenti che costituiscono l'area del file da leggere.
• Utilizzare gli indici dei dischi per determinare la posizione fisica (che è il contenitore) dei dati su disco.
• Leggere i dati del segmento fisico dai contenitori sottostanti su disco.
• Utilizzare i dati del segmento fisico per ricostruire il file.

Le strutture ad albero dei segmenti di file vengono archiviate anche in contenitori da 4,5 Mb su disco e rappresentano la maggior parte dei "metadati" di ciascun file (discussi più avanti in questo articolo).

In che modo è possibile determinare il rapporto di compressione generale su un DDR?

L'utilizzo complessivo di un DDR (e del rapporto di compressione) può essere visualizzato utilizzando il comando "filesys show space". Ad esempio:

Active Tier:
Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 115367.8 - - -
/data: post-comp 6794 .2 6242.4 551,8 92% 202.5
/ddvar 49.2 9.1 37,6 20% -


---------------- -------- -------- --------- ---- --------------In questo caso, vediamo che:

• Dati logici o precompressi conservati su DDR: 115367,8 Gb
• Spazio post-compresso o fisico utilizzato su DDR: 6242,4 Gb
• Il rapporto di compressione complessivo è 115367,8/6242,4 = 18,48 volte

L'output del comando "filesys show compression" conferma i dati conservati, lo spazio utilizzato e il rapporto di compressione. Ad esempio:

                   Fattore
del fattore di compressione (GiB) dopo la compressione globale della compressione globale
(GiB) (GiB) (riduzione %)
---------------- -------- --------- ----------- ---------- -------------
utilizzato attualmente:*   115367.8 6242.4 - - 18,5x (94.6) <
                                                                          
  Ultimi 7 giorni 42214.7 1863.2 11.0x 2.1x 22.7x (95.6)
  Le ultime 24 ore 4924,8 274,0 8,8x 2,0x 18,0x (94,4)
---------------- -------- --------- ----------- ---------- -------------

Immagine di utilizzo totale sulla DDR sono calcolate come segue:

• Dati precompressi totali: La somma della dimensione precompressa (logica) di tutti i file conservati dal DDR.
• Dati totali post-compressi: Il numero di "contenitori" in uso su disco moltiplicato per 4,5 Mb (le dimensioni di un singolo contenitore).
• Dimensione totale postcompressa: Il numero massimo di "contenitori" creati, dato lo spazio disponibile su disco nel sistema.

Le statistiche relative al numero massimo di contenitori in uso sono disponibili in supporto automatico. Ad esempio:

Container set 73fcacadea763b48:b66f6a65133e6c73:
...
    attrs.psize = 4718592 <= dimensione contenitore in byte
...
    attrs.max_containers = 1546057 <un numero massimo di contenitori
possibili attrs.free_containers = 125562 <; Attualmente i contenitori
liberi attrs.used_containers = 1420495 <" Contenitori attualmente in uso
...

Vedere:
 
In che modo è possibile determinare i rapporti di deduplica e compressione per un singolo file, directory o struttura ad albero di directory?

Quando un file viene inserito, il DDR registra le statistiche relative al file, tra cui:

• Byte precompressi (logici)
• Dimensione dei segmenti univoci dopo la deduplica
• Dimensione dei segmenti univoci dopo la deduplica e la compressione
• Dimensione dei metadati del file (ovvero la struttura ad albero del segmento e così via)

È possibile eseguire il dump di alcune di queste statistiche utilizzando il comando 'filesys show compression [path]', ad esempio per segnalare statistiche per un singolo file:

SE@DDVE60_JF## filesys show compression /data/col1/backup/testfile
Total files: 1;  byte/storage_used: 2.9
Byte originali:        3.242.460.364
compressi a livello globale:        1.113.584.070
compressione locale:        1.130.871.915
metadati:            4.772.672

Per segnalare le statistiche per un intero albero di directory:

SE@DDVE60_JF## filesys show compression /data/col1/backup
Total files: 3;  byte/storage_used: 1.4
Byte originali:        7.554.284.280
compressi a livello globale:        5.425.407.986
compressione locale:        5.510.685.100
metadati:           23.263.692

Si noti, tuttavia, che vi sono un paio di avvertenze sull'utilizzo di queste statistiche:

• Le statistiche vengono generate al momento dell'acquisizione di file o dati e, successivamente, non vengono aggiornate. A causa del modo in cui funziona un DDR, l'acquisizione di nuovi file o l'eliminazione di file che fanno riferimento agli stessi dati e così via possono modificare il modo in cui un file deduplica nel tempo causando l'impossibilità di visualizzare queste statistiche.
• Inoltre, alcuni use case sul DDR (ad esempio fastcopy di un file e quindi eliminazione del file originale) possono far sì che queste statistiche diventino fuorvianti o errate.

Di conseguenza, queste cifre devono essere considerate solo come stime.

I byte precompressi non sono necessariamente la dimensione precompressa/logica del file. Si tratta invece del numero totale di byte scritti in un file nella sua durata. Di conseguenza, in alcuni ambienti i file esistenti vengono comunemente sovrascritti (ad esempio quelli che utilizzano la funzionalità di libreria a nastro virtuale), la figura può essere maggiore della dimensione logica dei file corrispondenti.

L'acquisizione di dati di "scarsa qualità" può causare un peggioramento del rapporto di compressione complessivo?

Sì, affinché un DDR raggiunga un buon rapporto di compressione complessivo dei dati acquisiti, deve essere in grado di deduplicare e comprimere tali dati. Esistono vari tipi di dati che possono impedire questo problema, come illustrato di seguito:

Dati precompressi/pre-crittografati:

questi sono tipi di dati compressi o crittografati nel sistema client o dall'applicazione di backup. Ciò può includere anche file specifici dell'applicazione compressi o crittografati per progettazione (ad esempio file multimediali) e file di database compressi o crittografati o che incorporano oggetti binari come i file multimediali.

A causa del modo in cui l'algoritmo di compressione o crittografia funziona, una modifica relativamente piccola dei dati sottostanti di un file determina modifiche a "ripple out" in tutto il file. Ad esempio, un client può contenere un file crittografato da 100 Mb all'interno del quale vengono modificati i 10 KB. Normalmente, il file risultante sarà identico prima e dopo la modifica oltre alla sezione 10 Kb che è stata modificata. Quando si utilizza la crittografia, anche se solo 10 KB di dati non crittografati sono stati modificati prima e dopo la modifica, l'algoritmo di crittografia fa sì che l'intero contenuto del file cambi.

Quando tali dati vengono regolarmente modificati e inviati a un DDR, questo effetto a catena fa sì che ogni generazione del file abbia un aspetto diverso rispetto alle generazioni precedenti dello stesso file. Di conseguenza, ogni generazione contiene un set univoco di segmenti (e impronte digitali dei segmenti), quindi mostra un rapporto di deduplica debole.

Si noti inoltre che, anziché i file precompressi, è improbabile che l'algoritmo lz sia in grado di comprimere ulteriormente i dati del segmento costitutivo in modo che i dati non possano essere compressi prima di essere scritti su disco.

Come linea guida generale, la precompressione/pre-crittografia causa quanto segue:

• Dati pre-crittografati: Tasso di deduplica scadente, ma rapporto di compressione accettabile
• Dati precompressi: Rapporto di deduplica e rapporto di compressione scadenti

Quando gli stessi dati (invariati) precompressi/pre-crittografati vengono acquisiti più volte da un DDR, il rapporto di deduplica dei dati migliora in quanto, nonostante l'utilizzo di algoritmi di compressione o crittografia, durante ogni backup viene visualizzato un set simile di segmenti (e impronte digitali dei segmenti).

Laddove possibile, i dati inviati a un DDR non devono essere crittografati o compressi. Ciò potrebbe richiedere la disabilitazione della crittografia o della compressione sul client finale o all'interno dell'applicazione di backup corrispondente.

Per assistenza nel controllo, nella modifica delle impostazioni di crittografia o compressione all'interno di un determinato backup, applicazione client o sistema operativo, contattare il provider di supporto appropriato.

File multimediali:

Per impostazione predefinita, alcuni tipi di file contengono dati precompressi o pre-crittografati. Ad esempio:

• File PDF
• Alcuni file audio (mp3, wma, ogg e così via)
• File video (avi, mkv e così via)
• File di immagine (png, bmp, jpeg e così via)
• File specifici dell'applicazione (Microsoft Office, Open Office, Libre Office e così via)

I dati all'interno dei file vengono compressi o crittografati dal codec del file e, di conseguenza, causano gli stessi problemi quando vengono acquisiti in un DDR come descritto in precedenza per i dati precompressi o pre-crittografati.

File con un'elevata "univocità":

Il raggiungimento di un buon rapporto di deduplica dipende dal fatto che il DDR veda più volte lo stesso set di segmenti (e impronte digitali dei segmenti). Alcuni tipi di dati, tuttavia, contengono solo dati transazionali univoci che, per progettazione, contengono dati "univoci".

Se questi file vengono inviati a un DDR, ogni generazione di backup contiene un set univoco di segmenti o impronte digitali dei segmenti e, di conseguenza, rileva un rapporto di deduplica danneggiato.

Esempi di questi file sono:

• Log delle transazioni del database (ad esempio, registri di archiviazione Oracle).
• Log delle transazioni di Microsoft Exchange

Anche il primo backup di un "nuovo" client su un DDR può causare questo problema (poiché i dati non sono stati prima visualizzati dal DDR, pertanto i segmenti o le impronte digitali dei segmenti corrispondenti nel backup sono univoci). Nel corso del tempo, tuttavia, man mano che le generazioni future dello stesso backup vengono inviate alla DDR, il rapporto di deduplica dei backup migliora in quanto un numero inferiore di segmenti in ogni nuovo backup è univoco. Per questo motivo, si prevede che il rapporto di deduplica o compressione complessivo su un DDR appena installato che riceve per lo più nuovi backup sia danneggiato, ma migliorato nel tempo.

File di piccole dimensioni:

I file di piccole dimensioni causano vari problemi quando vengono scritti in un DDR. tra cui:

• bloat di metadati: il DDR inizia a contenere una quantità di metadati di file superiore al previsto rispetto ai dati fisici.
• Utilizzo insufficiente dei container: per progettazione (a causa del layout del segmento Stream Informed di Data Domain o dell'architettura SISL - oltre l'ambito di questo documento) un contenitore da 4,5 Mb su disco contiene solo i dati da un singolo file. Di conseguenza, il backup di un singolo file da 10 KB, ad esempio, causa la scrittura di almeno un contenitore completo da 4,5 Mb per quel file. Ciò può significare che, per tali file, il DDR utilizza molto più spazio post-compresso (fisico) rispetto alla quantità corrispondente di dati precompressi (logici) sottoposti a backup, il che a sua volta causa un rapporto di compressione complessivo negativo.
• Basso rapporto di deduplica: i file di dimensioni inferiori a 4 Kb (la dimensione minima del segmento supportata su un DDR) sono costituiti da un singolo segmento, che viene imbottito a 4 Kb. Tali segmenti non sono deduplicati, ma vengono scritti direttamente su disco. Ciò può causare la presenza di più copie DDR dello stesso segmento (visualizzate come segmenti duplicati).
• Scarse prestazioni di backup, restore o pulizia: si verificano overhead di grandi dimensioni durante il backup, il restore o la pulizia quando si passa da un file all'altro (poiché è necessario commutare il contesto dei metadati in uso).

Vedere:

• L'impatto sulle prestazioni di pulizia quando si utilizzano file di piccole dimensioni è stato in una certa misura mitigato dall'introduzione di pulizia fisica o garbage collection in DDOS 5.5 e versioni successive.
• La pulizia tenta di "annullare" un utilizzo errato dei contenitori aggregando i dati provenienti dai contenitori con un utilizzo ridotto in contenitori più strettamente imballati durante la fase di copia.
• La pulizia tenta di rimuovere segmenti duplicati eccessivi durante la fase di copia.

Nonostante quanto sopra, è necessario evitare l'utilizzo di un numero elevato di file di piccole dimensioni o di carichi di lavoro costituiti principalmente da file di piccole dimensioni. È preferibile combinare un numero elevato di file di piccole dimensioni in un unico archivio non compresso/non crittografato prima del backup rispetto all'invio dei file di piccole dimensioni al DDR nello stato nativo. Ad esempio, è molto meglio eseguire il backup di un singolo file da 10 GB contenente 1048576 singoli file da 10 KB rispetto a tutti i 1048576 file singolarmente.

Multiplexing eccessivo da parte delle applicazioni di backup:

Le applicazioni di backup possono essere configurate per eseguire il multiplexing dei dati tra i flussi inviati al backup device, ovvero i dati dai flussi di input (client diversi) vengono inviati in un singolo flusso al backup device. Questa funzionalità è principalmente utilizzata per la scrittura su dispositivi a nastro fisici come:

• Un dispositivo a nastro fisico può supportare solo un singolo flusso di scrittura in ingresso.
• L'applicazione di backup deve mantenere un throughput sufficiente per il dispositivo a nastro per impedire l'avvio, l'arresto o il riavvolgimento del nastro (noto anche come ciabatta- - Questo è più semplice se il flusso diretto al dispositivo a nastro contiene dati letti da più di un client.

Nel caso di un DDR, tuttavia, questo fa sì che un singolo file sul DDR contenga dati di più client con interleaving in ordine arbitrario o dimensioni di blocchi. Ciò può causare un rapporto di deduplica danneggiato, in quanto la DDR potrebbe non essere in grado di notare con precisione i segmenti duplicati di ogni generazione di un determinato backup di client. In generale, minore è la granularità del multiplexing, peggiore è l'impatto sul rapporto di deduplica.

Inoltre, le prestazioni di restore potrebbero essere scarse in quanto per ripristinare alcuni dati dei client, il DDR deve leggere molti file o contenitori in cui la maggior parte dei dati nei file o nei contenitori è dispendiosa in quanto si riferisce ai backup di altri client.

Le applicazioni di backup non devono utilizzare il multiplexing durante la scrittura in un DDR in quanto i DDR supportano un numero di flussi in ingresso superiore rispetto ai dispositivi a nastro fisici e ogni flusso è in grado di scrivere a velocità variabile. Di conseguenza, il multiplexing da parte delle applicazioni di backup deve essere disabilitato. Se le prestazioni di backup vengono influenzate dopo la disabilitazione del multiplexing, procedere come segue:

• Le applicazioni di backup che utilizzano CIFS, NFS o OST (DDBoost) devono aumentare il numero di flussi di scrittura (in modo che più file possano essere scritti in parallelo sul DDR).
• Gli ambienti che utilizzano VTL devono aggiungere ulteriori unità al DDR in quanto ogni unità consente il supporto di un ulteriore flusso di scrittura parallelo.

Se è necessaria assistenza per disabilitare il multiplexing o si desidera discutere della configurazione multiplexing consigliata per un'applicazione di backup specifica, contattare il provider di supporto con contratto.

Applicazioni di backup che inseriscono un numero eccessivo di indicatori a nastro:

Alcune applicazioni di backup possono inserire strutture di dati ripetute in un flusso di backup noto come "marker". Gli indicatori non rappresentano i dati fisici all'interno del backup, ma vengono invece utilizzati come sistema di indicizzazione o posizionamento dall'applicazione di backup.

In alcune circostanze, l'inclusione di indicatori in un flusso di backup può ridurre il rapporto di deduplica, ad esempio:

• Nella prima generazione di un backup, c'erano 12 KB di dati contigui, riconosciuti dal DDR come un singolo segmento.
• Nella seconda generazione del backup, tuttavia, gli stessi 12 KB di dati sono suddivisi per l'inclusione di un indicatore di backup che può essere rappresentato da 6 Kb di dati, indicatore di backup, 6 Kb di dati.
• Di conseguenza, i segmenti creati durante la seconda generazione del backup non corrispondono a quelli generati durante la prima generazione del backup, pertanto non vengono deduplicati correttamente.

Quanto più gli indicatori sono disposti nello spazio, peggiore è l'impatto sul rapporto di deduplica (ad esempio, un'applicazione di backup che inserisce gli indicatori ogni 32 Kb causa più problemi rispetto a un'applicazione di backup che inserisce gli indicatori ogni 1 Mb).

Per evitare questo problema, la DDR utilizza la tecnologia di riconoscimento degli indicatori che consente:

• Gli indicatori di backup devono essere rimossi in modo trasparente dal flusso di backup durante l'acquisizione del backup.
• Indicatori di backup da inserire nuovamente nel flusso di backup durante il ripristino del backup

Ciò consente di evitare la frammentazione dei dati o dei segmenti da parte degli indicatori di backup e migliora il rapporto di deduplica dei backup corrispondenti.

Per sfruttare al meglio questa tecnologia, tuttavia, è importante che il DDR sia in grado di riconoscere correttamente gli indicatori inseriti nei flussi di backup. La DDR cerca gli indicatori a seconda dell'impostazione dell'opzione 'marker type', ad esempio:

SE@DDVE60_JF## filesys option show
Option Value
-------------------------------- --------
...
Tipo di indicatore automatico
...


-------------------------------- --------Se questo valore deve essere lasciato impostato su "auto" in quanto consente al DDR di abbinare automaticamente i tipi di indicatori più comuni. Se il sistema acquisisce dati da una sola applicazione di backup che inserisce gli indicatori, potrebbe esserci un vantaggio in termini di prestazioni derivante dalla specifica di un tipo di indicatore specifico, ovvero:

# filesys option set marker-type {auto | nw1 | cv1 | tsm1 | tsm2 | eti1 | fdr1 | hpdp1 | besr1 | ssrt1 | ism1 | bti1| none}

Vedere:

• È probabile che qualsiasi vantaggio derivante dalla selezione di un tipo di indicatore specifico sia minimo.
• La selezione di un tipo di indicatore errato può causare un ulteriore peggioramento significativo delle prestazioni di backup o ripristino e del rapporto di deduplica.

Di conseguenza, Data Domain consiglia in genere di lasciare il tipo di indicatore impostato su "auto". Per ulteriori informazioni sulla modifica del tipo di indicatore, contattare il fornitore del supporto con contratto.

Per i sistemi che acquisiscono dati da applicazioni che utilizzano gli indicatori di backup ma che non vengono riconosciuti dalla tecnologia di gestione degli indicatori automatizzata (ad esempio prodotti del software BridgeHead), contattare il provider di supporto che può quindi collaborare con il supporto di Data Domain per determinare le impostazioni richieste sulla DDR al fine di rilevare l'indicatore non standard.

Indicazioni di dati di "scarsa qualità" ricevuti da un DDR:

Nella tabella seguente sono elencati i rapporti di deduplica e compressione previsti per i diversi tipi di dati elencati in precedenza. Questo elenco non è esaustivo e ovviamente possono esserci alcune variazioni nelle cifre esatte visualizzate in un determinato sistema a causa del carico di lavoro o dei dati acquisiti dalla DDR:
 

Compressione globale	Compressione locale	Causa probabile
Basso (1x - 4x)	Basso (1x - 1,5x)	Dati precompressi o crittografati
Basso (1x - 2x)	Alto (>2x)	Dati univoci ma comprimibili, ad esempio i log di archiviazione del database
Basso (2x - 5x)	Alto (>1,5 volte)	Indicatori che non vengono rilevati o che non presentano un elevato tasso di modifica dei dati o che eseguono lo streaming di multiplexing.
Alto (>10x)	Basso (<1,5x)	Backup degli stessi dati compressi o crittografati. Non si tratta di un'operazione frequente.

Esistono alcuni fattori su un DDR che possono influire sul rapporto di deduplica generale?

Sì. Esistono diversi fattori che possono causare il mantenimento di dati obsoleti/superflessi su disco in un DDR, determinando un aumento dello spazio su disco (fisico) post-compresso e una riduzione del rapporto di compressione complessivo. Tali fattori sono discussi di seguito.

Errore durante l'esecuzione regolare di pulizia del file system:

La pulizia del file system è l'unico modo per rimuovere fisicamente i dati obsoleti/superflessi sul disco a cui non fanno più riferimento i file del DDR. Di conseguenza, un utente potrebbe eliminare diversi file dal sistema (causando un calo nell'utilizzo precompresso) ma non eseguire la pulizia (lasciando elevato l'utilizzo postcompresso/fisico). Ciò causerebbe un calo del rapporto di compressione complessivo.

Data Domain consiglia di pianificare l'esecuzione pulita a intervalli regolari come segue:

• DDR normale: Una volta a settimana
• DDR con retention estesa: Una volta ogni due settimane

La pulizia non deve essere eseguita più di una volta alla settimana in quanto ciò può causare problemi di frammentazione dei dati sul disco che si manifesta come scarse prestazioni di restore/replica.

Numero eccessivo di snapshot obsolete nel sistema:

I DDR possono creare snapshot mtree che rappresentano il contenuto di un mtree nel momento in cui è stata creata la snapshot. Si noti, tuttavia, che lasciare snapshot obsolete in un sistema può causare un aumento dell'utilizzo post-compresso/fisico causando un calo del rapporto di compressione complessivo. Ad esempio:

• Esiste un mtree contenente molti file (pertanto l'utilizzo precompresso è elevato).
• Viene creata una snapshot dell'mtree.
• Molti file vengono eliminati (causando un calo dell'utilizzo precompresso).
• La pulizia del file system viene eseguita. Si noti, tuttavia, che lo spazio minimo sul disco rigido viene liberato in quanto una copia dei file eliminati rimane nella snapshot mtree, il che significa che i dati a cui fanno riferimento tali file non possono essere rimossi dal disco.
• Di conseguenza, l'utilizzo post-compresso/fisico rimane elevato

Data Domain consiglia che, se vengono utilizzate snapshot mtree (ad esempio per il ripristino dall'eliminazione dei dati accidentali), vengano gestite utilizzando pianificazioni di snapshot automatizzate in modo che le snapshot vengano create a intervalli regolari con un periodo di scadenza definito (la quantità di tempo prima che la snapshot venga rimossa automaticamente). Inoltre, il periodo di scadenza dovrebbe essere il più breve possibile (tuttavia, ciò può ovviamente dipendere dallo use case delle snapshot o dal livello di protezione fornito da queste snapshot). In questo modo si impedisce l'accumulo di snapshot obsolete con un lungo periodo di scadenza.

Ulteriori informazioni sull'utilizzo di snapshot e pianificazioni di snapshot sono disponibili nel seguente articolo: Data Domain - Gestione delle pianificazioni delle

snapshotRitardo di replica eccessivo:

La replica nativa di Data Domain utilizza un log di replica o snapshot mtree (a seconda del tipo di replica) per tenere traccia dei file o dei dati in sospeso per la replica su un DDR remoto. Il ritardo di replica è il concetto di replica che è in ritardo rispetto alle modifiche apportate alla DDR di origine. Ciò può verificarsi a causa di vari fattori, tra cui:

• Contesto di replica disabilitati
• Larghezza di banda di rete insufficiente tra DDR
• Frequenti disconnessioni di rete.

Un ritardo di replica di grandi dimensioni può far sì che il log di replica continui a contenere riferimenti a file che sono stati eliminati sul DDR di origine o snapshot mtree obsolete o non aggiornate sui DDR di origine e di destinazione. Come descritto in precedenza, i dati a cui fanno riferimento queste snapshot (o il log di replica) non possono essere rimossi fisicamente dal disco sul DDR anche se i file corrispondenti sono stati eliminati dal sistema. Ciò può causare l'aumento dell'utilizzo post-compresso o fisico del DDR, che quindi causa un peggioramento del rapporto di deduplica.

Se i DDR subiscono un utilizzo elevato e si ritiene che ciò sia dovuto al ritardo nella replica, contattare il provider di supporto con contratto per ulteriore assistenza.

Sono presenti modifiche alla configurazione o determinati fattori su un DDR in grado di aumentare il rapporto di compressione complessivo?

Sì: la rimozione o la risoluzione dei problemi discussi in precedenza in questo documento dovrebbe consentire a un DDR di mostrare un miglioramento del rapporto di compressione complessivo nel tempo. Esistono anche vari fattori o carichi di lavoro su un DDR che possono portare a un aumento del rapporto di deduplica. In genere si tratta di:

• Riduzione della quantità di spazio su disco rigido utilizzata dai file sul DDR (ad esempio aumentando l'aggressività dell'algoritmo di compressione utilizzato dalla DDR)
• Aumento improvviso della quantità di dati precompressi (logici) sul DDR senza un corrispondente aumento dell'utilizzo post-compresso/fisico

Modifica dell'algoritmo di compressione:

Per impostazione predefinita, i DDR comprimeno i dati scritti su disco con l'algoritmo lz . Come accennato in precedenza, lz viene utilizzato in quanto presenta overhead relativamente bassi in termini di CPU necessari per la compressione o la decompressione, ma mostra una ragionevole efficacia nella riduzione delle dimensioni dei dati.

È possibile aumentare l'aggressività dell'algoritmo di compressione per fornire ulteriori risparmi nell'utilizzo post-compresso o del disco rigido (e di conseguenza migliorare il rapporto di compressione complessivo). Gli algoritmi di compressione supportati, in ordine di efficacia (da basso ad alto), sono i seguenti:

• Lz
• gzfast
• Gz

Un confronto generale di ciascun algoritmo è il seguente:

• lz rispetto a gzfast offre una compressione migliore di circa il 15% e utilizza 2 CPU.
• lz rispetto a gz offre una compressione migliore di circa il 30% e consuma 5 volte la CPU.
• gzfast rispetto a gz offre una compressione migliore di circa il 10-15%.

È anche possibile disabilitare completamente la compressione (specificare un algoritmo nessuno), tuttavia questo non è supportato per l'utilizzo sui sistemi del cliente ed è solo per test interni.

Come indicato nella tabella precedente, più aggressivo è l'algoritmo di compressione, maggiore è la CPU richiesta durante la compressione o la decompressione dei dati. Per questo motivo, le modifiche a un algoritmo più aggressivo devono essere effettuate solo sui sistemi che sono leggermente caricati sotto il normale carico di lavoro. La modifica dell'algoritmo su sistemi altamente caricati può causare un deterioramento estremo delle prestazioni di backup o ripristino e possibili errori o riavvii del file system (causando un'interruzione dell'alimentazione DDR).

Per ulteriori informazioni sulla modifica del tipo di compressione, consultare il seguente articolo: Impatto sulle prestazioni del sistema Data Domain e della pulizia della conversione alla compressione

GZA causa del potenziale impatto della modifica dell'algoritmo di compressione, si consiglia ai clienti interessati a farlo contattare il fornitore del supporto per approfondire la modifica prima di procedere.

Utilizzo di fastcopy del file system:

I DDR consentono l'utilizzo del comando "file system fastcopy" per copiare rapidamente un file (o una struttura ad albero di directory). Questa funzionalità crea un file clonando i metadati di un file esistente (o gruppo di file) in modo che, sebbene i nuovi file non siano fisicamente connessi al file originale, fanno riferimento esattamente agli stessi dati sul disco del file originale. Ciò significa che, indipendentemente dalle dimensioni del file originale, il nuovo file consuma poco spazio sul disco (in quanto deduplica perfettamente rispetto ai dati esistenti).

Il risultato di questo comportamento è che quando si utilizza fastcopy del file system, la dimensione precompressa (logica) dei dati sul DDR aumenta rapidamente, ma l'utilizzo post-compresso/fisico del DDR rimane statico.

Ad esempio, il seguente DDR utilizza il DDR come indicato di seguito (che indica il rapporto di compressione complessivo di circa 1,8x):

Active Tier:
Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 12.0 - - -
/data: post-comp 71.5 6.8 64.7 10% 0.0
/ddvar 49.2 1.1 45.6 2% -
/ddvar/core 158.5 0.2 150.2 0% -
---------------- -------- -------- --------- ---- --------------

Contiene un file di grandi dimensioni (/data/col1/backup/testfile):

!!! DDVE60_JF I DATI SONO A RISCHIO !!! # ls -al /data/col1/backup/testfile-rw-r
--r-- 1 root root 3221225472 lug 29 04:20 /data/col1/backup/testfile

Il file viene fastcopy più volte:

sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/col1/backup/testfile_copy1
sysadmin@DDVE60_JF# filesys fastcopy source /data /col1/backup/testfile destination /data/col1/backup/testfile_copy2
sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/col1/backup/testfile_copy3

Ciò causa un aumento dell'utilizzo precompresso per modifiche minime nell'utilizzo post-compresso:

Active Tier:
Resource Size GiB Used GiB Used GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 21.0 - - - -
/data: post-comp 71.5 6.8 64.7 10% 0.0
/ddvar 49.2 1.1 45.6 2% -
/ddvar/core 158.5 0.2 150.2 0% -
---------------- -------- -------- --------- ---- --------------

Di conseguenza il DDR ora mostra un rapporto di compressione complessivo di circa 3,1 volte.

Come accennato in precedenza, le statistiche di compressione delle copie mostrano che deduplicano perfettamente:

sysadmin@DDVE60_JF# filesys mostrano i file totali di compressione /data/col1/backup/testfile_copy1
: 1;  byte/storage_used: 21331976.1
Byte originali:        3.242.460.364
compressi a livello globale:                    0
Compresso in locale:                    0 Metadati
:                  152

La funzionalità Fastcopy non può essere utilizzata per migliorare il rapporto di compressione complessivo riducendo l'utilizzo fisico del DDR, tuttavia può essere la causa di un elevato rapporto di compressione complessivo (soprattutto in ambienti che utilizzano ampiamente fastcopy come Avamar 6.x).