Data Domain: Linee guida sui metadati di PowerProtect DD Virtual Edition ("DDVE")

Sinossi

PowerProtect DD Virtual Edition offre prestazioni ineguagliabili e TCO per i clienti che desiderano beneficiare di un appliance Data Domain in un fattore di forma virtuale. Tuttavia, è necessario prestare attenzione prima di implementare PowerProtect DDVE in alcuni tipi di ambienti, in quanto ciò potrebbe causare un aumento dell'utilizzo dei metadati rispetto alla guida prescritta, in modo da influire sul TCO sperimentato dall'utente. L'aumento dei metadati derivanti dagli scenari descritti di seguito è una conseguenza naturale dell'elevata deduplica in quanto il prodotto sta funzionando per progettazione e si consiglia vivamente di valutare l'impatto potenziale degli scenari seguenti sul TCO prima dell'implementazione.
Questo documento esamina tali scenari noti che potrebbero causare un maggiore utilizzo dei metadati durante l'utilizzo di DDVE writing in un Object Store.

Scenario 1: Backup di file System sintetici virtuali

La protezione dei backup di file System su PowerProtect DDVE utilizzando un'applicazione di backup (ad esempio Avamar) con backup sintetici virtuali abilitati può portare a una situazione in cui il cliente sperimenta un rapporto di deduplica elevato, al costo di un maggiore utilizzo dei metadati. Un alto tasso di deduplica efficace esercita una pressione verso il basso su TCO, mentre un maggiore utilizzo dei metadati esercita una pressione verso l'alto. La risoluzione di queste forze determina la TCO complessiva che l'utente ha sperimentato. È importante valutare prima dell'implementazione, se l'ambiente dell'utente dispone di questo tipo di workload.
Se non è possibile disattivare i backup sintetici virtuali nell'applicazione di backup o scegliere uno che non utilizza i materiali sintetici virtuali, l'unica soluzione nota a tali casi è che l'utente possa aggiungere ulteriori dischi di metadati per mantenere il sistema operativo.

Scenario 2: Contenitori parziali

La scrittura di contenitori parziali nell'Object Store, che possono essere causati a causa di frequenti commit o scrivendo file di piccole dimensioni (< 1 MB) aumenta l'overhead dei metadati del sistema. In questo scenario, questo picco è temporaneo e il sistema può essere portato allo stato stazionario eseguendo la pulitura, che copierà in avanti i contenitori parziali ed eliminerà la frammentazione. Tuttavia, va osservato che esiste un costo associato all'esecuzione della pulizia, che potrebbe influire TCO troppo spesso. La Guida alle Best Practice prevede l'esecuzione della pulizia una volta alla settimana e la dimensione dei dischi di metadati di conseguenza.

Scenario 3: File di piccole dimensioni

Nei casi in cui l'ambiente dell'utente disponga di milioni di file di piccole dimensioni (< 1 MB), l'overhead dei metadati è elevato rispetto ai dati. Si tratta di un workload non supportato e DDVE potrebbe non essere la soluzione giusta per proteggere tali workload.

Scenario 4: Indicatori densi

Alcune app come Oracle o CommVault introducono indicatori nel flusso di backup. DDVE deduplica questi indicatori, causando alti tassi di deduplica. Ancora una volta, l'utente si trova di fronte a un compromesso tra un tasso di deduplica elevata, a scapito del maggiore utilizzo dei metadati. L'utente può scegliere di disattivare l'ottimizzazione in-app nell'app di backup e di ridurre l'utilizzo di DDVE Metadata oppure scegliere le frequenze di deduplica più elevate, a scapito dell'aumento dell'utilizzo dei metadati.
Se non è possibile disattivare l'ottimizzazione in-app nell'applicazione di backup, l'unica soluzione nota in tali casi è che l'utente possa aggiungere ulteriori dischi di metadati per mantenere il sistema operativo.

Scenario 5: Backup sintetici non virtuali con alti tassi di deduplica

Questo scenario non è comune e l'utente deve essere consapevole dell'impatto potenziale per TCO a causa dell'elevato
tasso di deduplica, il che potrebbe causare un significativo aumento dell'utilizzo dei metadati. L'unica soluzione nota a questi
casi è che l'utente possa aggiungere ulteriori dischi di metadati per mantenere il sistema operativo.

Riepilogo:

Negli scenari specifici descritti in precedenza, ci aspettiamo che ci sia un aumento significativo del consumo di metadati
e che la soluzione consigliata a questi casi sia l'aggiunta di ulteriori dischi di metadati per mantenere
il sistema operativo. Il prodotto è in funzione per la progettazione e si consiglia vivamente di valutare l'
impatto potenziale degli scenari di cui sopra sul TCO prima dell'implementazione.
Per i workload con un rapporto di deduplica più elevato, sono necessari più metadati. Lo storage dei metadati può essere
espanso dinamicamente. Quando l'utilizzo dello spazio di archiviazione dei metadati supera 80%, verrà generato un alert. Un nuovo disco di metadati
deve essere aggiunto immediatamente al DDVE per evitare di esaurire lo spazio. Seguire la Guida di amministrazione per la
procedura di espansione dello storage. Si consiglia di utilizzare sempre un disco da 1TB.
La CLI riportata di seguito (documentata nella Guida all'amministrazione di DDVE Installation &) Mostra l'utilizzo di localmetadata attivo
.
Per esempio:

sysadmin@atos-ddve # filesys Mostra lo spazio Active Tier Active local-Metadata Active Tier: local-dimensioni di utilizzo dei metadati GIB utilizzati GIB uso GiB%------------------------------24290,4 4390,2 19900,2 18,0%------------------------------