Data Domain: Una panoramica delle fasi di Data Domain file System (DDFS) clean/Garbage Collection (GC)

Il file System di Data Domain (DDFS) è diverso da molte implementazioni di file System comuni in quanto, quando un file viene eliminato dallo spazio di file System utilizzato dal file, non è immediatamente disponibile per il riutilizzo. La ragione di ciò è che il Restore di Data Domain (DDR) non conosce immediatamente se i dati a cui è stato fatto riferimento dal file eliminato vengono deduplicati rispetto ad altri file e pertanto se è sicuro rimuovere o meno i dati.

La pulizia (talvolta definita Garbage Collection/GC) è il processo tramite il quale un DDR:

• Determina i dati su disco superflui (ad esempio, non è più possibile fare riferimento a Object come file o snapshot)
• Rimuove fisicamente i dati superflui facendo spazio su disco sottostante disponibili per il riutilizzo (ad es. acquisizione di nuovi dati)

Clean/GC è comunemente programmato per l'esecuzione a intervalli regolari (per impostazione predefinita inizia alle 6 di ogni martedì) e può essere:

• Funzionamento lungo
• A costi informatici

Si noti, tuttavia, che non vi è alcun modo diverso da eseguire clean/GC in cui i dati possono essere rimossi/spazio fisicamente liberato su un Restorer di Data Domain (ad esempio, non vi sono collegamenti per accelerare il processo).

Questo articolo descrive in dettaglio clean/GC:

• Le fasi che vengono pulite in genere vengono eseguite
• I diversi algoritmi clean utilizzati nelle varie versioni di DDOS

None

Ogni volta che viene eseguito clean/GC ha due scopi principali: in primo luogo deve trovare i dati superflui sul DDR-una breve panoramica di come questo viene fatto è la seguente:

• Clean/GC enumera il contenuto del file System DDFS alla ricerca di Object come file, snapshot e log di replica attualmente presenti sul sistema.
• Determina quindi tutti i dati fisici su disco a cui questi Object fanno riferimento attivamente.
• I dati a cui viene fatto riferimento in maniera attiva sono "Live" e non possono essere rimossi dal DDR in caso contrario, gli Object che fanno riferimento a questi dati potrebbero essere danneggiati (non saranno più in grado di essere letti poiché i dati sottostanti su cui essi dipendono non esisterebbero più sul disco)
• I dati a cui non viene fatto riferimento in modo attivo da alcun oggetto sono detti "morti" ed è superfluo: questi dati possono essere rimossi dal sistema.
• Tutti i dati di un DDR vengono imballati in Object di 4,5 MB in formato noto come container
• Tramite l'enumerazione clean/GC è possibile determinare quali contenitori da 4,5 MB contengono dati inattivi e la quantità di dati morti in ogni
• Per impostazione predefinita clean/GC seleziona i contenitori da 4,5 MB che tengono > 8% di dati inattivi per ' elaborazione '.

In secondo luogo, deve rimuovere i dati inattivi sul DDR-una breve spiegazione del modo in cui viene eseguita è la seguente:

• I contenitori selezionati per l'elaborazione sono controllati nuovamente per confermare che mantengono una buona quantità di dati inattivi
• I dati in tempo reale vengono estratti da questi contenitori e scritti in nuovi contenitori da 4,5 MB al termine del file System.
• Una volta completati i contenitori selezionati (inclusi i dati inattivi che contengono) vengono eliminati dal disco che libera fisicamente lo spazio su disco

Il processo di pulizia viene suddiviso in una serie di ' fasi ' con il numero totale di fasi dipendente da:

• La versione di DDOS utilizzata sul DDR (da cui l'algoritmo clean utilizzato, per impostazione predefinita, da tale versione di DDOS)
• La configurazione/il contenuto del sistema

In generale, tuttavia, il processo di ricerca dei dati "morti" e la selezione di contenitori corrispondenti avviene in diverse fasi, mentre la rimozione dei dati inattivi avviene in un'unica fase denominata "copia". Ad esempio, alcune versioni di DDOS eseguiranno le fasi pulite come segue:

1. Pre-enumerazione-enumerare il contenuto del file System DDFS
2. Pre-merge: eseguire l'Unione di un indice DDFS per garantire che l'ultima copia delle informazioni di indice sia scaricata su disco
3. Prefiltro-determinare se sono presenti dati duplicati nel file System DDFS e in tal caso dove
4. Preselezione-determinare quali contenitori da 4,5 MB devono essere "elaborati" pulendo
5. Copia-estrarre fisicamente i dati in tempo reale dai contenitori selezionati, scriverli in nuovi contenitori, quindi eliminare i contenitori selezionati
6. Riepilogo-ricostruire i vettori di riepilogo (che vengono utilizzati come ottimizzazione durante l'acquisizione di nuovi dati)

Nell'esempio precedente, le fasi 1-4 vengono utilizzate per determinare dove esistano i dati "morti" sul DDR (definiti "fasi di enumerazione" nel resto di questo documento) mentre la fase 5 (copia) viene utilizzata per rimuovere fisicamente questi dati.

Si noti che nessuno spazio verrà fisicamente liberato sul sistema finché clean/GC non raggiunge la fase di copia. Di conseguenza, potrebbe verificarsi un significativo ritardo tra l'avvio di clean e lo spazio che inizia a essere liberato (a causa del processo di enumerazione che deve essere eseguito per la prima volta al completamento). Per questo motivo i sistemi non devono essere consentiti di riempire il 100% completo prima dell'avvio di clean/GC.

Le fasi di enumerazione tendono a essere costose in termini di utilizzo della CPU (ad esempio, sono generalmente associate alla CPU) mentre la fase di copia è costosa in termini di CPU e I/O (ad esempio, sono generalmente CPU e I/O collegati). In sintesi, tuttavia, è possibile affermare che:

• La lunghezza totale delle fasi di enumerazione dipende dalla quantità di dati presenti sul DDR che è necessario enumerare.
• La lunghezza totale della fase di copia dipende dalla quantità di dati morti sul DDR che devono essere rimossi e su come "frammentati" che i dati sono su disco (discusso più avanti)

Il numero/funzionalità delle fasi di enumerazione dipende dalla release di DDOS utilizzata su un DDR.

DDOS 5,4 (e versioni precedenti)-algoritmo clean completo: Esegue 6 o 10 fasi (come mostrato in precedenza):

• Il contenuto del file System DDFS viene enumerato in alto verso il basso (ad esempio, è incentrato su file)
• DDFS esegue la Discovery di tutti i file presenti sul DDR quindi esegue la scansione di ciascun file, a sua volta, per individuare i dati a cui fa riferimento il file.
• Ciò consente a clean/GC di determinare quali dati su disco sono "Live"

DDOS 5,5 (e versioni successive)-Physical clean Algorithm (PGC): Esegue 7 o 12 fasi:

• Il contenuto di DDFS è enumerato in basso (ad esempio, non esegue più scansioni di singoli file)
• DDFS esegue la Discovery dei metadati di file System che fanno riferimento a dati fisici su disco e esegue la scansione di tali metadati per determinare quali dati sono a cui si fa riferimento
• Ciò consente a clean/GC di determinare quali dati su disco sono "Live"
• Ciò si ottiene aggiungendo una fase di ' analisi ' (pertanto, l'aumento del numero di fasi rispetto all'algoritmo full clean)
• Nella maggior parte dei casi, tuttavia, la durata totale del Clean fisico dovrebbe essere più breve rispetto alla pulizia completa per lo stesso sistema (nonostante costituiti da fasi più singole)

DDOS 6,0 (e versioni successive)-Perfect Physical clean Algorithm (PPGC):

• Si tratta semplicemente di un'ottimizzazione per l'algoritmo clean fisico e viene discussa più avanti

Si noti che DDOS è passato dall'algoritmo clean completo all'algoritmo clean fisico per migliorare la scalabilità e le prestazioni del processo di enumerazione-a causa della natura top-down dell'algoritmo clean completo, non ha scalato bene su DDR con:

• Un numero elevato di file di piccole dimensioni (come l'opzione di contesto in cui lo spostamento dall'enumerazione di un file al successivo era costoso/lento)
• Elevato rapporto di deduplica (come più file a cui si fa riferimento gli stessi dati fisici per cui gli stessi dati sono stati enumerati più volte)

DDR passa da Full a Physical clean Algorithm automaticamente quando viene eseguito l'upgrade da DDOS 5,4 (o versioni precedenti) a 5,5 (o versioni successive). L'unica eccezione è costituita dai sistemi configurati con la retention estesa, in cui è necessario verificare il contenuto del file System DDFS per i file "spanning" prima di poter abilitare la pulizia fisica: una discussione di questo processo esula dall'ambito di questo documento, tuttavia, questo controllo viene eseguito automaticamente dopo l'aggiornamento e la pulizia fisica è abilitata al termine di questo controllo senza

Analogamente, DDR passa da Physical a perfect Physical clean Algorithm automaticamente in caso di upgrade da DDOS 5. x a 6,0 (o versioni successive). Si noti, tuttavia, che l'algoritmo Perfect Physical Clean richiede che gli indici siano nel formato "index 2,0" prima di poter essere utilizzati. Importante:

• Il formato "index 2,0" è stato introdotto con DDOS 5,5 (quindi tutti i file System creati su 5,5 o versioni successive utilizzano già l'indice 2,0)
• Il file System creato su 5,4 o versioni precedenti avrà inizialmente avuto indici nel formato index 1,0. Dopo l'aggiornamento a DDOS 5,5 (o versioni successive) gli indici verranno convertiti nel formato index 2,0-la conversione avviene ogni volta che viene eseguita la pulitura, tuttavia, solo l'1% degli indici vengono convertiti durante ogni pulitura, per poter richiedere fino a 2 anni (supponendo che la funzione Clean venga eseguita settimanalmente) per convertire completamente 2,0 gli indici nel formato

DDR inizialmente con DDOS 5,4 (o versioni precedenti), ma che sono stati successivamente aggiornati a DDOS 5,5 (o versioni successive), può essere obbligato a convertire gli indici nel formato index 2,0 per una volta "rebuilding index". Si noti, tuttavia, che un indice di ricostruzione richiede un periodo di tempo di inattività mentre gli indici sono fisicamente ricostruire: questa operazione richiede generalmente 2-8 ore per il completamento a seconda delle dimensioni/quantità di dati presenti sul DDR. Per discutere l'esecuzione di una ricostruzione degli indici, contattare il fornitore del supporto contratto.

Come menzionato in precedenza, a prescindere dall'algoritmo clean/GC utilizzato, clean potrebbe richiedere un numero variabile di fasi: ad esempio, l'algoritmo clean completo può richiedere 6 o 10 fasi. La ragione di ciò è che:

• Quando DDFS viene avviato, riserva una quantità di memoria fissa che deve essere utilizzata da Clean/GC
• All'interno di questa memoria clean/GC crea strutture di dati per descrivere i risultati dell'enumerazione (ad esempio, descrivere il luogo in cui esistono dati Live vs Dead su disco)
• Quando un DDR contiene una quantità di dati relativamente ridotta, è possibile descrivere l'intero contenuto del file System DDFS in questa area di memoria.
• Su molti sistemi, tuttavia, ciò non è possibile e questa area di memoria si esaurisce prima che venga enumerato l'intero contenuto del file System DDFS
• Di conseguenza, questi sistemi eseguono "sampling", aumentando il numero di fasi pulite richieste

Quando si utilizza la funzione di campionamento clean/GC:

• Eseguire una passata di campionamento di enumerazione in tutto il file System-si noti che questa enumerazione non è' completata ' (ad esempio, non registra le informazioni complete su ogni parte del file System, ma invece approssima le informazioni per ogni parte del file System)
• Utilizzare queste informazioni di campionamento per determinare quale parte del file System DDFS trarrebbe maggiormente vantaggio dal fatto che clean/GC venga eseguito contro di essa (ad esempio, quale parte del file System darebbe i migliori rendimenti in termini di spazio che viene liberato se venisse pulita)
• Eseguire una seconda fase di enumerazione completa rispetto alla parte selezionata del file System, il cui contenuto può ora essere completamente descritto in memoria riservata per GC

Se necessario, il campionamento viene attivato automaticamente durante l'ambiente clean/GC:

• Aumento del numero di fasi che devono essere eseguite da Clean/GC
• Un aumento corrispondente della durata totale di clean/GC

Prima di DDOS 6,0 la maggior parte delle DDR esegue il campionamento durante la pulitura/GC (a meno che non contengano un DataSet relativamente piccolo). L'algoritmo clean Physical clean, tuttavia, include diverse ottimizzazioni per ridurre la quantità di memoria richiesta da Clean/GC durante l'enumerazione dei dati all'interno del file System. Ciò significa che molti sistemi che stavano eseguendo il campionamento durante la pulitura/GC su DDOS 5. x non richiederanno più il campionamento su DDOS 6,0: ciò riduce quindi il numero di fasi effettuate da Clean e causa una riduzione corrispondente del tempo di esecuzione totale di pulizia (ad es. miglioramento delle prestazioni pulite).

Non vi sono informazioni disponibili per determinare direttamente che un sistema è passato dall'algoritmo clean fisico a un algoritmo di pulizia fisico perfetto diverso da:

• Quando il sistema era in esecuzione Physical clean su DDOS 5,5-5,7 stava eseguendo 12 fasi durante la pulizia
• Dopo l'aggiornamento del sistema a DDOS 6,0 (o versioni successive), esegue solo 7 fasi durante la pulitura

Se un sistema in cui è in esecuzione DDOS 6,0 deve comunque eseguire il campionamento, questo verrà attivato automaticamente durante la pulitura e tornerà in esecuzione 12 fasi durante la pulitura.

Indipendentemente dall'algoritmo clean utilizzato, la fase di copia (in cui i dati morti vengono fisicamente rimossi dal sistema) funziona in maniera simile in tutte le release. Le prestazioni della fase di copia sono generalmente dipendenti da:

• La quantità di dati ' Dead ' che deve essere rimossa
• "Frammentazione" di questi dati inattivi (ad esempio, come vengono distribuiti su disco)

Come descritto in precedenza, la funzione Copy opera selezionando contenitori da 4,5 MB che contengono dati inattivi, estrazione di tutti i dati in tempo reale da questi contenitori e scrittura dei dati in tempo reale su nuovi contenitori, quindi eliminazione dei contenitori selezionati in origine. Gli esempi riportati di seguito descrivono perché la frammentazione dei dati inattivi è importante:

esempio 1:

• 10 contenitori sono selezionati per la copia (45Mb Total Data)
• Tutto se questi contenitori non contengono dati in tempo reale (ad esempio, i dati in essi contenuti sono completamente senza riferimenti/morti)
• Poiché una copia di risultato deve semplicemente contrassegnare questi contenitori come eliminati per liberare spazio fisico 45Mb su disco

Esempio 2:

• i contenitori 100 sono selezionati per la copia (450Mb Total Data)
• Ciascuno di questi contenitori contiene 90% dati in tempo reale/10% di dati inattivi
• Per elaborare questi contenitori, la copia deve:

Chiaramente una quantità significativamente maggiore di I/O e della CPU è richiesta per eseguire la copia descritta nell'esempio 2 rispetto a quella nell'esempio 1, pertanto, richiederà molto più tempo per liberare lo spazio fisico 45Mb nel disco in questo esempio.

Gli utenti in genere non hanno alcun controllo sulla "frammentazione" dei dati inattivi su disco su un DDR poiché questo dipende molto dal tipo di use case/tipo di dati scritti nel sistema. Si noti, tuttavia, che clean/GC mantiene le statistiche che contribuiscono a determinare la "frammentazione" dei dati guasti riscontrati durante la fase di copia (che consente quindi agli utenti di determinare se questa frammentazione possa spiegare una fase di copia potenzialmente a lungo in corso). Tali statistiche dall'ultima fase di clean/GC vengono raccolte in supporti AUTOSUPPORTATI. Ad esempio, la seguente mostra una fase di copia in cui i dati inattivi erano piuttosto contigui (ad esempio, la maggior parte dei contenitori selezionati per la copia per la maggior parte dei dati morti):

percentuale dei dati in tempo reale in copiati:              3,6% 4,3%

Al contrario, la seguente mostra una fase di copia in cui i dati morti sono stati frammentati (ad esempio, la maggior parte dei contenitori selezionati per la copia per lo più dati in tempo reale):

percentuale dei dati in tempo reale in copiati:             70,9% 71,5%

Come descritto in precedenza, clean/GC dovrà eseguire un lavoro relativamente più lungo nel secondo scenario per liberare spazio fisicamente sul DDR, in modo da ridurre il throughput della fase di copia.

Il throughput delle fasi di copia può anche essere influenzato negativamente da:

• L'uso della crittografia: Durante la copia, potrebbe essere necessario decrittografare/crittografare i dati che aumentano in modo significativo la quantità di CPU richiesta.
• L'utilizzo di una bassa ottimizzazione della larghezza di banda: I container potrebbero dover generare informazioni di sketch durante la copia, il che causa anche un significativo aumento della quantità di CPU richiesta.

Si noti che, se l'ottimizzazione e/o la crittografia a bassa larghezza di banda è stata abilitata di recente, tutti i contenitori esistenti (indipendentemente dal fatto che siano selezionati per la copia o meno) potrebbero dover essere crittografati e/o disporre di informazioni di sketch generate contro di esse durante la pulitura successiva. ciò potrebbe causare un'operazione di pulizia più lunga del normale.

Ulteriori note sulla verifica/modifica di clean Schedule e throttle sono disponibili nel seguente articolo della KB: https://support.emc.com/kb/306100

Nota tuttavia:

• In circostanze normali, la funzione Clean deve essere pianificata per essere eseguita al massimo una volta all'anno, in modo che i dati su disco vengano eccessivamente "frammentati" (ad esempio, mostrano una scarsa località spaziale), il che può comportare scarse prestazioni di lettura/replica/trasferimento dati.
• La funzione Clean throttle non influisce sulla quantità totale di CPU e sulla larghezza di banda di I/O consumata da clean. Ad esempio:

• Per impostazione predefinita, clean throttle è impostato su 50: è responsabilità dell'utente testare l'esecuzione di clean con impostazioni di regolazione diverse, mentre il DDR avverte un normale workload per determinare l'impostazione di un throttle che consente di:

• Si noti che un'operazione di pulizia a lungo termine non è necessariamente un problema, purché:

• Il sistema che utilizza la funzionalità Extended retention deve essere configurato in modo da:

• Le informazioni complete della più recente operazione clean sono incluse in supporti e dettagli: