Data Domain Operating System non supporta il ribilanciamento proattivo dei dati nello storage dopo l'espansione della capacità di Data Domain File System

Come per molti array di storage, la capacità della maggior parte dei modelli di Data Domain Restorer (DDR) può essere aumentata aggiungendo alloggiamenti di enclosure di storage esterno (ES30, DS60) al sistema, quindi espandendo il Data Domain File System (DDFS) su questi alloggiamenti di enclosure. Quando viene eseguita questa operazione:

• I nuovi alloggiamenti vengono fisicamente collegati (cablati accesi)
• Data Domain Operating System (DD OS) esegue nuovamente la scansione dello storage per identificare l'esistenza di nuovi alloggiamenti di enclosure
• Questi nuovi alloggiamenti di enclosure vengono quindi aggiunti a un tier di storage all'interno di DDR (Active Tier o un'unità di archiviazione specifica)
• Questo tier può quindi essere espanso online senza la necessità di un'interruzione dell'alimentazione a DDFS
• Tutti i nuovi dati scritti su tale tier di storage vengono scritti su alloggiamenti nuovi e esistenti
• Tuttavia, i dati sugli alloggiamenti esistenti non vengono ribilanciati tra i nuovi alloggiamenti di enclosure

In altre parole:

• All'interno di DD OS l'unità di storage dei dati è rappresentata da un container da 4,5 MB
• Man mano che vengono creati, i container da 4,5 MB vengono scritti su tutti gli alloggiamenti di enclosure nell'unità di archiviazione del tier corrispondente in formato Round Robin
• Quando vengono aggiunti ulteriori alloggiamenti di enclosure a un'unità di archiviazione del tier, DDFS inizia a scrivere nuovi container da 4,5 MB su queste enclosure, oltre alle enclosure esistenti (le nuove enclosure vengono incluse durante le scritture del container Round Robin)
• DD OS, tuttavia, non effettua alcun tentativo specifico (né offre funzionalità specifiche) per migrare i container esistenti nel tier dagli alloggiamenti di enclosure esistenti a quelli nuovi

Ciò significa che l'aggiunta di alloggiamenti di enclosure può lasciare i dati "sbilanciati" nello storage collegato. Ad esempio:

• Un DDR dispone inizialmente di una singola enclosure nell'Active Tier pieno al 90%
• Un'enclosure aggiuntiva viene aggiunta all'Active Tier e DDFS viene espanso su questa enclosure
• Le scritture dei container da 4,5 MB appena creati sono ora in formato Round Robin tra le enclosure esistenti e nuove
• L'enclosure esistente rimane a corto di spazio libero, mentre l'enclosure appena aggiunta è quasi vuota

In questo scenario, molti array di storage consentono a un amministratore di ribilanciare i dati tra enclosure collegate. Migrare in modo proattivo alcuni dati dalle enclosure esistenti alle enclosure appena aggiunte per garantire che la capacità utilizzata di tutte le enclosure sia approssimativamente uguale. Tuttavia, DD OS NON offre questa funzionalità e, per via della progettazione di DDFS, non è necessaria, poiché il ribilanciamento dei dati avviene naturalmente nel tempo.

Il ribilanciamento dei dati viene eseguito da due operazioni:

• Pulizia della garbage collection
• Riparazione della località

Ciascuna di queste operazioni e il modo in cui causano il ribilanciamento automatico dei dati sono descritti più dettagliatamente di seguito.

Pulizia della garbage collection

La pulizia della garbage collection (GC) è un'attività pianificata che viene eseguita regolarmente su un DDR (per impostazione predefinita, una volta alla settimana sull'Active Tier e, supponendo che il recupero dello spazio sia abilitato, quando necessario sulle unità di archiviazione). Quando viene eseguita:

• Identifica i dati fisici all'interno dell'unità di archiviazione del tier che sono "attivi" (utilizzati da uno o più file nel file system o da oggetti come le snapshot) o "inattivi" (non referenziati da alcun oggetto, quindi superflui per il sistema)
• Determina i container da 4,5 MB che contengono la maggior parte dei dati "inattivi" all'interno dell'unità di archiviazione del tier
• Legge questi container da 4,5 MB ed estrae tutti i dati "attivi" che contengono. I dati vengono copiati nei container da 4,5 MB appena creati, scritti su tutti gli alloggiamenti nell'unità di archiviazione del tier
• Elimina i container da 4,5 MB meno recenti, rimuovendo così i dati inattivi che contengono e liberando spazio sottostante sul disco per il riutilizzo

Quando la GC viene eseguita su un sistema con qualsiasi problema di bilanciamento dei dati, si prevede che la maggior parte dei dati obsoleti (e quindi la maggior parte dei dati inattivi) venga conservata su alloggiamenti di enclosure meno recenti all'interno dell'unità di archiviazione del tier. Di conseguenza, la maggior parte dei container che vengono letti, copiati ed eliminati si trova su alloggiamenti di enclosure meno recenti. I container appena creati, tuttavia, vengono scritti in formato round robin tra tutti gli alloggiamenti nel tier. Di conseguenza, la maggior parte dello spazio liberato dalla GC si trova su alloggiamenti meno recenti, mentre lo spazio appena utilizzato è distribuito su tutti gli alloggiamenti.

Come semplice esempio:

• L'Active Tier di un DDR contiene due alloggiamenti: il primo contiene 10.000 container da 4,5 MB, mentre il secondo 100 container da 4,5 MB (per ogni container nel secondo alloggiamento sono presenti 100 container nel primo)
• La GC esegue e copia i dati da 5.000 container sul primo alloggiamento
• I dati attivi all'interno di questi 5.000 container determinano la creazione di 1.000 nuovi container da 4,5 MB
• Questi 1.000 nuovi container da 4,5 MB vengono scritti su entrambi gli alloggiamenti
• Una volta completata la GC, il primo alloggiamento contiene quindi 5.500 container da 4,5 MB, mentre il secondo 600 container (per ogni container sul secondo alloggiamento sono presenti circa nove container sul primo)
• In un'unica esecuzione di GC, il problema di bilanciamento dei container tra il primo e il secondo alloggiamento è stato ridotto di un fattore 10 e dovrebbe ridursi ulteriormente durante le successive esecuzioni della GC, il che significa che i dati vengono ribilanciati naturalmente tra gli alloggiamenti nel corso del tempo

Riparazione della località

Quando un file viene scritto in un DDR, vengono eseguite le seguenti operazioni generali:

• Il file viene suddiviso in blocchi logici (chiamati segmenti) con dimensioni comprese tra 4 e 12 KB
• Ogni segmento viene controllato per verificare se già esiste sul disco all'interno del tier in cui viene scritto il file
• Se il segmento esiste già, si tratta di dati duplicati e il segmento all'interno del file appena scritto viene sostituito con un puntatore ai dati esistenti su disco
• Se il segmento non esiste, si tratta di dati univoci che vengono quindi compressi in un nuovo container da 4,5 MB e scritti su disco

Tutti i file hanno il concetto di "località", ovvero la sequenzialità dei segmenti di dati a cui fa riferimento tale file sul disco in DDR. Ovviamente, i file che presentano un elevato rapporto di deduplica (ovvero che contengono una grande quantità di dati duplicati) hanno probabilmente una località peggiore rispetto a un file univoco, poiché quando vengono acquisiti i dati vengono sostituiti con puntatori ai dati esistenti che potrebbero essere sparsi tra container/dischi all'interno dell'unità di archiviazione del tier corrispondente.

Per ottenere buone prestazioni di lettura dei dati su un DDR, il file deve avere una buona "località" (i dati sono relativamente sequenziali su disco) in modo che gli algoritmi read-ahead di DDFS possano funzionare in modo ottimale. DDFS presuppone inoltre che il file da cui è più probabile la lettura (per il ripristino o la replica) sia la copia più recente di un determinato backup. Di conseguenza, per alcuni tipi di dati (ad esempio, sintetici virtuali) viene eseguito un processo denominato "riparazione della località" per "ottimizzare" la località dei dati dei file appena scritti. Durante l'esecuzione, la riparazione della località:

• Esamina i dati a cui fa riferimento il file alla ricerca di sezioni in cui i dati non sono sequenziali sul disco (con scarsa località)
• Legge i dati non sequenziali dal disco e li scrive nuovamente in sequenza (come dati duplicati) nei nuovi container da 4,5 MB

Si prevede quindi che la copia meno recente (non sequenziale) dei dati duplicati venga identificata come "inattiva" durante la successiva esecuzione della GC e rimossa dal sistema. Di conseguenza:

• Nei sistemi in cui si verifica un problema di bilanciamento dei dati, si prevede che la maggior parte dei dati non sequenziali meno recenti si trovi sugli alloggiamenti di enclosure obsoleti e più popolati
• Quando questi dati vengono riscritti in sequenza come dati duplicati, vengono inseriti in nuovi container da 4,5 MB in formato Round Robin su tutte le enclosure nel tier corrispondente
• Pertanto, la maggior parte dei dati "inattivi" (dati duplicati meno recenti) creati dalla riparazione della località si trova sugli alloggiamenti obsoleti e più popolati
• Quando viene eseguita la GC, la maggior parte dei dati "inattivi" viene quindi individuata sugli alloggiamenti e più popolati (liberando spazio su questi alloggiamenti) come descritto in precedenza

Conclusione

Di conseguenza, grazie al normale utilizzo della funzionalità di riparazione della località e pulizia (GC), un DDR può ribilanciare in modo trasparente i dati tra gli alloggiamenti nel corso del tempo. Ciò si verifica senza ulteriori input da parte degli amministratori e significa che non è necessaria alcuna operazione dedicata di ribilanciamento dei dati, come talvolta si verifica su altri array di storage. Al fine di accelerare il processo di ribilanciamento, è quindi opportuno:

• Aumentare la velocità di "abbandono" dei dati sul DDR
• Aumentare la quantità di dati riparati localmente sul DDR

Per ulteriori informazioni su queste opzioni, contattare il fornitore del supporto a contratto indicando i dettagli di questo articolo.