Data Domain: Come risolvere i problemi relativi all'eccessivo utilizzo dello spazio o alla mancanza di capacità disponibile sui Data Domain Restorer (DDR)

 

• Si tratta dell'area del disco in cui risiedono i file e i dati appena acquisiti e, nella maggior parte dei DDR, i file restano in quest'area fino alla scadenza/eliminazione da parte di un'applicazione di backup del client.
• Nei DDR configurati con la retention estesa (ER, Extended Retention) o la retention a lungo termine (LTR, Long Term Retention), è possibile eseguire il processo di spostamento dei dati periodicamente per la migrazione dei file obsoleti dal tier Active ai tier Archive o Cloud.
• L'unico modo per recuperare spazio nel tier Active utilizzato dai file eliminati/spostati è tramite un processo di pulizia/garbage collection (GC)

• Il tier Active può iniziare a esaurire lo spazio disponibile, causando la visualizzazione di avvisi/messaggi come il seguente:

• Se il tier Active si riempie completamente, non si potranno scrivere nuovi dati sul DDR e i backup o la replica potrebbero interrompersi. In questo scenario potrebbero essere visualizzati avvisi/messaggi come il seguente:

• In alcune circostanze, se il tier Active esaurisce lo spazio, il Data Domain File System (DDFS) potrebbe diventare read-only. A questo punto, non sarà possibile eliminare i file esistenti

• Spiegare perché il tier Active può esaurire lo spazio
• Descrivere un semplice set di controlli che può essere eseguito per determinare la causa di un eccessivo utilizzo del tier Active, nonché le misure correttive da adottare

• Questo articolo non è esaustivo, ad esempio esistono rare situazioni in cui il tier Active di un DDR raggiunge un utilizzo eccessivo o si esaurisce per motivi non trattati in questo documento. Tuttavia, l'articolo copre la maggior parte delle cause/problemi più comuni
• Questo articolo non tratta dell'utilizzo eccessivo dei tier Archive o Cloud

  Il tier Active di un DDR può presentare un utilizzo più alto del previsto per diversi motivi:

• La scadenza o l'eliminazione dei file di backup/save set non viene gestita correttamente dalle applicazioni di backup del client a causa di una configurazione errata dei criteri di retention o delle applicazioni di backup
• Il ritardo di replica causa la conservazione di una grande quantità di dati obsoleti sul tier Active in attesa della replica nelle repliche
• I dati scritti sul tier Active hanno un rapporto di compressione complessivo inferiore al previsto
• Il sistema non è stato dimensionato correttamente, in altre parole è troppo piccolo per la quantità di dati che si sta tentando di archiviare.
• I backup sono costituiti da un numero elevato di file di dimensioni molto ridotte, che consumano molto più spazio di quanto previsto al momento della scrittura iniziale. Tuttavia, questo spazio può essere recuperato durante la pulizia e la garbage collection
• Lo spostamento dei dati non viene eseguito regolarmente nei sistemi configurati con ER/LTR, di conseguenza i file obsoleti che dovrebbero essere spostati nei tier Archive/Cloud restano sul tier Active
• Pulizia/garbage collection non eseguita regolarmente
• Istantanee di mtree superflue o obsolete sul DDR che impediscono di recuperare lo spazio ottenuto con la pulizia dei file/dati eliminati

Passaggio 1. Determinare se è necessario pulire il tier Active

Data Domain Operating System (DDOS) cerca di mantenere un contatore chiamato "Cleanable GiB" per il tier Active. Si tratta di una stima della quantità di spazio fisico (post-comp) che può essere recuperato nel tier Active eseguendo la pulizia/garbage collection. Questo contatore viene visualizzato con i comandi 'filesys show space'/'df':
 
Se:

• Il valore di "Cleanable GiB" è elevato
• DDFS raggiunge il 100% (ed è pertanto read-only)

Sarà necessario eseguire la pulizia completa prima di passare agli altri passaggi descritti in questo documento. Per iniziare la pulizia, è necessario utilizzare il comando 'filesys clean start', ad esempio:
 
Per verificare che la pulizia sia stata avviata come previsto, è possibile utilizzare il comando 'filesys status', ad esempio:
 
Importante:

• Se la pulizia non si avvia, contattare il fornitore del supporto per ulteriore assistenza. Potrebbe essersi verificato un errore di tipo "segmento mancante" che causa la disattivazione della pulizia.
• Se la pulizia è già in esecuzione, viene visualizzato il seguente messaggio quando si tenta di avviarla:

• Non verrà liberato/recuperato spazio nel tier Active finché la pulizia non raggiunge la fase di copia (per impostazione predefinita, la fase 9 in DDOS 5.4.x e versioni precedenti e la fase 11 in DDOS 5.5.x e versioni successive). Per ulteriori informazioni sulle fasi utilizzate dalla pulizia, consultare: https://support.emc.com/kb/446734
• La pulizia potrebbe non recuperare la quantità di spazio indicata da "Cleanable GiB" perché questo valore è essenzialmente una stima. Per ulteriori informazioni, consultare: https://support.emc.com/kb/485637
• La pulizia potrebbe non recuperare tutto lo spazio stimato in un'unica esecuzione perché, nei DDR che contengono set di dati di dimensioni molto grandi, l'operazione viene eseguita sulla parte del file system che contiene i dati meno necessari (ad esempio, per ottenere il miglior rapporto tra lo spazio liberato e il tempo di esecuzione della pulizia). In alcuni scenari, potrebbe essere necessario eseguire la pulizia più volte prima che venga recuperato tutto lo spazio stimato.
• Se il valore di "Cleanable GiB" era molto elevato, è probabile che la pulizia non sia stata eseguita a intervalli regolari. Verificare che sia stata impostata una pianificazione della pulizia:

Una volta completata la pulizia, utilizzare i comandi 'filesys show space'/'df' per determinare se i problemi di utilizzo sono stati risolti. Se l'utilizzo è ancora alto, continuare con i passaggi rimanenti in questo articolo.

Passaggio 2. Verificare la presenza di significativi ritardi di replica nei contesti di replica di origine

La replica nativa di Data Domain è stata progettata sulla base del concetto dei "contesti di replica". Ad esempio, quando i dati devono essere replicati tra i sistemi:

• I contesti di replica vengono creati sui DDR di origine e di destinazione
• I contesti vengono inizializzati
• Una volta completata l'inizializzazione, la replica invierà periodicamente aggiornamenti/delta dall'origine alla destinazione per mantenere sincronizzati i dati sui sistemi

Se un contesto di replica di origine è in ritardo, i dati obsoleti potrebbero restare sul disco nel sistema di origine (i contesti con ritardo di replica non possono causare un eccessivo utilizzo nel sistema di destinazione):

• Contesti di replica della directory (utilizzati durante la replica tra sistemi di una singola struttura delle directory in /data/col1/backup):

•  Contesti di replica dell'mtree (utilizzati durante la replica tra sistemi di qualsiasi mtree diverso da /data/col1/backup):

• Contesti di replica della raccolta (utilizzati durante la replica dell'intero contenuto di un DDR su un altro sistema):

 Per determinare se i contesti di replica sono in ritardo, seguire questa procedura:

• Individuare il nome host del sistema corrente:

• Individuare la data/ora del sistema corrente:

• Elencare i contesti di replica configurati sul sistema insieme al momento della sincronizzazione (Sync'ed-as-of-time). I contesti di interesse sono quelli in cui la destinazione NON contiene il nome host del sistema corrente (che indica che il sistema corrente è l'origine) e in cui il momento della sincronizzazione (Sync'ed-as-of-time) è molto indietro nel tempo:

I contesti in cui il sistema corrente è l'origine e che presentano ritardi significativi oppure i contesti non più necessari devono essere interrotti. Per farlo, utilizzare il comando seguente nel sistema di origine e di destinazione:
 
Ad esempio, per interrompere i contesti "di interesse" mostrati in precedenza, utilizzare i comandi seguenti nell'origine e nella destinazione:
 
Importante:

• Una volta interrotti i contesti, sarà necessario eseguire la pulizia nel tier Active per recuperare lo spazio stimato
• Se si utilizza la replica di mtree dopo l'interruzione dei contesti, le relative istantanee potrebbero rimanere sul disco. Verificare l'esecuzione del passaggio 5 per rimuovere eventuali istantanee superflue prima di eseguire la pulizia.
• Se l'mtree di origine/destinazione è configurato per la migrazione dei dati nel tier Archive o Cloud, si deve prestare attenzione quando si interrompono i contesti di replica dell'mtree corrispondenti perché si rischia che non vengano più ricreati/inizializzati. Il motivo è che, quando un contesto di replica dell'mtree viene inizializzato, viene creata un'istantanea dell'mtree sul sistema di origine che contiene i dettagli di tutti i file dell'mtree (indipendentemente dal tier). Questa istantanea viene quindi replicata interamente nel tier Active della destinazione. Di conseguenza, se il tier Active della destinazione non dispone di spazio libero sufficiente per acquisire tutti i dati degli mtree dall'origine, l'inizializzazione non verrà completata. Per ulteriori informazioni su questo problema, contattare il fornitore del supporto
• Se viene interrotto un contesto di replica della raccolta, non potrà essere ricreato/inizializzato senza eliminare prima l'istanza di DDFS sul DDR di destinazione (perdendo tutti i dati presenti nel sistema). Di conseguenza, un'inizializzazione successiva richiederà molto tempo/larghezza di banda della rete perché tutti i dati provenienti dall'origine dovranno essere di nuovo replicati fisicamente nella destinazione.

Passaggio 3. Verificare la presenza di mtree non più richiesti

Il contenuto di DDFS è suddiviso in mtree in modo logico. I singoli client/applicazioni di backup scrivono spesso su un unico mtree. Se un'applicazione di backup viene ritirata, non sarà più in grado di scrivere/eliminare i dati dal DDR. Di conseguenza, potrebbero restare mtree obsoleti/superflui sul sistema. I dati in questi mtree continueranno a esistere a tempo indeterminato, occupando spazio su disco in DDR. Ne consegue che questi mtree superflui devono essere eliminati. Ad esempio:

• Ottenere un elenco di mtree sul sistema:

• Eventuali mtree superflui devono essere eliminati con il comando 'mtree delete', ad esempio:

• Lo spazio su disco dell'mtree eliminato viene recuperato al successivo avvio della pulizia/garbage collection nel tier Active.

Importante:

• Gli mtree di destinazione per la replica (ad esempio, con lo stato RO/RD nell'output dell'elenco degli mtree) devono avere il contesto di replica corrispondente interrotto per poter essere eliminati
• Gli mtree utilizzati come Logical Storage Unit (LSU) di DDBoost o come pool di Virtual Tape Library (VTL) potrebbero non essere eliminati con il comando 'mtree delete'. Consultare la guida all'amministrazione di Data Domain per ulteriori informazioni sull'eliminazione di tali mtree
• Gli mtree configurati per il Retention Lock (ad esempio, con lo stato RLCE o RLGE) non possono essere eliminati, ma si può rimuovere il Retention Lock sui singoli file all'interno dell'mtree per eliminarli singolarmente. Consultare la guida all'amministrazione di Data Domain per ulteriori dettagli

Passaggio 4. Verificare la presenza di istantanee degli mtree obsolete/superflue

Un'istantanea di Data Domain mostra l'mtree corrispondente in un dato momento. Di conseguenza:

• Tutti i file presenti all'interno dell'mtree al momento della creazione dell'istantanea vengono inclusi nell'istantanea
• Sebbene l'istantanea continui a esistere anche quando questi file vengono rimossi/eliminati, non sarà possibile recuperare lo spazio fisico che utilizzano sul disco dopo la pulizia perché i dati devono rimanere sul sistema nel caso in cui venga eseguito l'accesso alla copia del file nella istantanea

Per determinare se un mtree ha istantanee obsolete/superflue, procedere come segue:

• Ottenere un elenco di mtree sul sistema utilizzando il comando 'mtree list', come mostrato nel passaggio 3
• Elencare le istantanee esistenti per ogni mtree utilizzando il comando 'snapshot list':

• Se sono presenti istantanee, utilizzare l'output 'snapshot list mtree [mtree name]' per determinare le istantanee che:

• Se il comando snapshot list viene eseguito nuovamente, queste istantanee verranno elencate come scadute:

Importante:

• Non è possibile determinare la quantità di dati fisici che una singola istantanee o un set di istantanee contiene sul disco. L'unico valore 'space' associato a un'istantanea è un'indicazione della dimensione (logica) precompressa dell'mtree al momento della creazione dell'istantanea (come mostrato nell'output precedente)
• Le istantanee denominate 'REPL-MTREE-AUTO-YYYY-MM-DD-HH-MM-SS' sono gestite dalla replica dell'mtree e, in circostanze normali, non devono essere impostate manualmente sullo stato scaduto (la replica imposterà automaticamente questo stato quando le istantanee non sono più richieste). Se queste istantanee sono molto vecchie, è probabile che il contesto di replica corrispondente mostrerà un ritardo significativo (come descritto nel passaggio 2)
• Le istantanee denominate 'REPL-MTREE-RESYNC-RESERVE-YYYY-MM-DD-HH-MM-SS' vengono create con la replica dell'mtree quando un contesto di replica dell'mtree viene interrotto. Il loro scopo è essere utilizzate per evitare una risincronizzazione completa dei dati di replica se il contesto interrotto viene ricreato successivamente (ad esempio, se il contesto è stato interrotto per errore). Se la replica non viene ristabilita, questi contesti possono essere impostati manualmente sullo stato scaduto come descritto in precedenza.
• Le istantanee scadute continueranno a esistere sul sistema fino a quando non verrà eseguita la successiva operazione di pulizia/garbage collection. A questo punto, saranno fisicamente eliminate e verranno rimosse dall'output di 'snapshot list mtree [mtree name]'. La pulizia potrà quindi recuperare lo spazio che queste istantanee utilizzano sul disco

Passaggio 5. Verificare la presenza di un numero imprevisto di file obsoleti sul sistema

I supporti automatici del DDR contengono istogrammi che mostrano la suddivisione dei file sul DDR in ordine cronologico, ad esempio:
 
Questo può essere utile per determinare se sul sistema sono presenti file non scaduti/eliminati come previsto dall'applicazione di backup del client. Ad esempio, se il sistema precedente è stato scritto da un'applicazione di backup che ha impostato il periodo di retention massimo per un singolo file a 6 mesi, è evidente che tale applicazione non sta impostando i file sullo stato scaduto, né li sta eliminando come previsto, visto che ci sono circa 80.000 file che risalgono a oltre 6 mesi fa sul DDR.

Nota:

• È responsabilità dell'applicazione di backup eseguire tutte le operazioni di scadenza/eliminazione dei file
• Un DDR non imposterà mai la scadenza/eliminerà automaticamente i file. A meno che l'applicazione di backup non abbia impostato esplicitamente l'eliminazione di un file, questo resterà sul DDR utilizzando lo spazio a tempo indeterminato

Di conseguenza, il team di supporto dei vendor delle applicazioni di backup deve innanzitutto esaminare i problemi di questo tipo.

Se necessario, il supporto Data Domain può fornire report aggiuntivi per:

• Ordinare cronologicamente il nome/ora di modifica di tutti i file su un DDT (in modo da determinare il nome/la posizione dei dati obsoleti)
• Suddividere gli istogrammi sulla durata dei file in report distinti per il tier Active/Archive/Cloud (in cui sono attivate le funzionalità ER/LTR)

Per eseguire questa operazione:

• Raccogliere le prove come descritto nel paragrafo sulla raccolta di sfs_dump nella sezione Note di questo documento.
• Aprire una Service Request con il fornitore del supporto

Una volta eliminati i file obsoleti/superflui, sarà necessario eseguire la pulizia/garbage collection del tier Active per recuperare fisicamente lo spazio in questo tier

Passaggio 6. Verificare la presenza di backup che includono un numero elevato di file di piccole dimensioni

A causa della progettazione di DDFS, i file di piccole dimensioni (essenzialmente qualsiasi file di dimensioni inferiori a circa 10 MB) possono occupare uno spazio eccessivo quando vengono scritti inizialmente nel DDR Ciò dipende dall'architettura "SISL" (Stream Informed Segment Layout), che consente ai file di piccole dimensioni di utilizzare più blocchi di spazio su disco da 4,5 MB. Ad esempio, un file di 4 KB può arrivare a consumare fino a 9 MB di spazio su disco fisico quando viene scritto inizialmente.

Questo spazio superfluo viene successivamente recuperato con la pulizia/garbage collection (perché i dati dei file di piccole dimensioni vengono aggregati in un numero inferiore di blocchi da 4,5 MB), ma nei modelli più ridotti di DDR può causare un utilizzo eccessivo e una saturazione quando vengono eseguiti i backup.

I supporti automatici contengono istogrammi dei file suddivisi per dimensioni, ad esempio:
 
Se si rileva che i backup scrivono un numero molto elevato di file di piccole dimensioni, il sistema potrebbe essere soggetto a un aumento dell'utilizzo significativo, anche se temporaneo, tra le varie esecuzioni della pulizia/garbage collection. In questo scenario, è preferibile modificare la metodologia di backup per raccogliere tutti i file di piccole dimensioni in un singolo archivio più ampio (ad esempio un file tar) prima di scriverli sul DDR. Non comprimere né crittografare gli archivi di questo tipo, perché il rapporto di compressione/deduplicazione dei dati potrebbe essere danneggiato.

Passaggio 7. Verificare se il rapporto di deduplicazione è inferiore al previsto

Lo scopo principale di un DDR è deduplicare e comprimere i dati acquisiti dal dispositivo. Il rapporto tra deduplicazione e compressione dipende in larga misura dal caso d'uso del sistema e dal tipo di dati che contiene. Tuttavia, in molti casi, viene individuato un rapporto di compressione complessivo "previsto", basato sui risultati ottenuti tramite test con modelli di prova o simili. Per determinare il rapporto di compressione complessivo corrente del sistema (e, quindi, se soddisfa le aspettative), è possibile utilizzare il comando 'filesys show compression'. Ad esempio:
 
Nell'esempio precedente, il sistema raggiunge un rapporto di compressione complessivo di 65,3 volte per il tier Active (un valore ottimo). Se invece questo valore indica che il rapporto di compressione complessivo non soddisfa le aspettative, è probabile che sia necessario eseguire ulteriori indagini. L'analisi di un rapporto di compressione inferiore al previsto è un argomento complesso, che può avere molte root cause. Per ulteriori informazioni a riguardo, consultare il seguente articolo: https://support.emc.com/kb/487055

Passaggio 8. Verificare se il sistema è un'origine per la replica della raccolta

Quando si utilizza la replica della raccolta, se il sistema di origine è fisicamente più grande di quello di destinazione, la dimensione del sistema di origine sarà limitata artificialmente in modo da corrispondere a quella di destinazione (ad esempio, un'area del disco di origine verrà contrassegnata come inutilizzabile). Il motivo di questa misura è che, quando si utilizza la replica della raccolta, la destinazione deve essere una copia a livello di blocchi dell'origine. Tuttavia, se l'origine è fisicamente più grande della destinazione, è possibile che nell'origine vengano scritti troppi dati, che non possono poi essere replicati nella destinazione perché è già piena. Questo scenario può essere evitato limitando le dimensioni dell'origine in modo che corrispondano a quelle della destinazione.

• Utilizzando i comandi del passaggio 2, verificare se il sistema è un'origine per la replica della raccolta. A questo scopo, eseguire "replication status" e determinare se sono presenti contesti di replica che iniziano con 'col://' (che indica la replica della raccolta) e che non contengono il nome host del sistema locale nella destinazione (che indica che il sistema deve essere un'origine per il contesto di replica)
• Se il sistema è un'origine per la replica della raccolta, verificare le dimensioni del tier Active di ciascun sistema effettuando l'accesso a entrambi, eseguendo il comando 'filesys show space' e confrontando le dimensioni di 'post-comp' del tier Active in ogni sistema
• Se l'origine è molto più grande della destinazione, la dimensione del tier Active sarà limitata artificialmente.
• Per consentire l'utilizzo di tutto lo spazio sull'origine per i dati, è necessario:

Passaggio 9. Verificare che lo spostamento dei dati venga eseguito regolarmente

Se il DDR è configurato con la retention estesa (ER, Extended Retention) o la retention a lungo termine (LTR, Long Term Retention), sarà associato un secondo tier di storage (tier Archive per ER o Cloud per LTR). In questo scenario, i criteri di spostamento dei dati sono probabilmente configurati in base agli mtree per eseguire la migrazione dei dati obsoleti/non modificati che richiedono la retention a lungo termine dal tier Active a un tier di storage alternativo, in modo che lo spazio utilizzato da questi file nel tier Active possa essere recuperato fisicamente con la pulizia/garbage collection. Se i criteri di spostamento dei dati non sono configurati correttamente o se il relativo processo non viene eseguito regolarmente, i dati obsoleti restano nel tier Active più a lungo del previsto e continueranno a utilizzare lo spazio fisico sul disco.

• Verificare per prima cosa se il sistema è configurato per ER o LTR eseguendo "filesys show space" e verificando la presenza di un tier Archive o Cloud. Per essere utilizzabili, la dimensione "post-comp" di questi tier di storage alternativi deve essere > 0 GB:

• Se il sistema è configurato con ER/LTR, verificare i criteri di spostamento dei dati in base agli mtree per controllare che siano quelli previsti, quindi impostare il sistema in modo che i dati obsoleti vengano inviati al tier di storage alternativo:

• Se il sistema è configurato con ER/LTR, verificare che lo spostamento dei dati sia pianificato in modo da eseguire a intervalli regolari la migrazione fisica dei file/dati dal tier Active allo storage alternativo:

• Se il sistema è configurato per ER/LTR, controllare l'ultima data di esecuzione dello spostamento dei dati:

• Una volta completato lo spostamento dei dati, è necessario eseguire la pulizia del tier Active (che può essere configurata per l'avvio automatico al termine dello spostamento dei dati) per garantire che lo spazio utilizzato dai file spostati nel tier Active venga fisicamente liberato:

Passaggio 10. Aggiungere ulteriore storage al tier Active

Se sono stati eseguiti tutti i passaggi precedenti, inclusa la pulizia del tier Active, ma lo spazio disponibile sul tier Active è ancora insufficiente, è probabile che il sistema non sia stato dimensionato correttamente per il carico di lavoro che sta ricevendo. In questo caso, è necessario attenersi a una di queste procedure:

• Ridurre il carico di lavoro sul sistema, ad esempio:

• Aggiungere ulteriore storage al tier Active del sistema ed espanderne le dimensioni:

Il supporto di Data Domain può generare diversi report che mostrano informazioni quali:

• Un elenco di tutti i file in un tier specifico, ad esempio Active/Archive/Cloud, ordinati cronologicamente
• Dimensioni stimate e rapporto di compressione tra mtree e struttura delle directory principale
• Un elenco di tutti i file in un particolare mtree ordinati cronologicamente
• e così via.

Per consentire questa operazione, è necessario raccogliere le seguenti informazioni:

• Un nuovo bundle di supporto dal DDR. Per ulteriori informazioni, consultare: https://support.emc.com/kb/323283
• L'output di 'sfs_dump' o 'sfs_dump -c':

• Un report della posizione del file (richiesto se il sistema è configurato per ER o LTR):

Per assistenza con la raccolta delle informazioni o con le altre procedure descritte in questo archivio, contattare il fornitore del supporto.