Data Domain Restorer e Long-Term Retention nel cloud. Domande frequenti

Questo articolo affronta le domande più frequenti sulla configurazione e sull'utilizzo dei Data Domain Restorer (DDR) e della funzione LTR (Long-Term Retention) o Cloud.
 

Che cos'è LTR?

• A partire da Data Domain Operating System (DD OS) 6.0 è stata introdotta una nuova funzione, denominata LTR.
• LTR consente a determinati modelli di DDR di migrare un sottoinsieme di file o dati in uno storage a oggetti o cloud storage, noto come Cloud Tier, da una serie di provider di public o private cloud supportati.
• Per eseguire fisicamente la migrazione di file o dati a uno storage a oggetti, viene eseguito un processo di spostamento dei dati sul DDR.
• Per liberare fisicamente i dati ridondanti dal Cloud Tier, viene eseguito un processo di pulizia del Cloud Tier sul DDR.
• LTR è una funzione concessa in licenza e richiede un file CLOUDTIER_CAPACITY license.
• LTR richiede uno storage locale per i metadati del Cloud Tier.

Per quali sistemi DDR è disponibile LTR?
Dipende dalla versione di DD OS installata insieme al tipo di modello di sistema. La maggior parte dei modelli presenta determinati requisiti hardware che devono essere soddisfatti in anticipo per la configurazione di LTR. Consultare la guida all'installazione hardware per i modelli specifici e la guida all'amministrazione di DD OS per i requisiti.

Quale licenza è richiesta per LTR?

• Poiché LTR è considerata una nuova funzionalità di DDOS 6.x e versioni successive, è necessaria una licenza elettronica. 
• Il tipo di elicense richiesto è denominato CLOUDTIER_CAPACITY license. Un esempio di CLOUDTIER_CAPACITY license è il seguente:

Capacity licenses:
##   Feature              Shelf Model   Capacity     Mode        Expiration Date
--   ------------------   -----------   ----------   ---------   ---------------
1    CLOUDTIER-CAPACITY   n/a           136.42 TiB   permanent   n/a
--   ------------------   -----------   ----------   ---------   ---------------

Come funzionano i diversi tier?

• I normali DDR (senza una licenza LTR) hanno un singolo tier, noto come Active Tier.
• L'Active Tier è il tier di storage tradizionale su tutti i DDR "standard".
• I sistemi LTR dispongono di un secondo tier di storage, noto come Cloud Tier.

La dimensione massima di ogni livello è determinata dai limiti supportati per la configurazione hardware e la versione di DD OS. Consultare la guida all'amministrazione di DD OS e la guida hardware per il modello specifico in questione.

Di seguito è riportato un esempio di configurazione LTR a due tier, Active e Cloud:   

Active Tier:
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   --------   --------   ---------   ----   --------------
/data: pre-comp           -    36674.6           -      -                -
/data: post-comp    65460.3      585.4     64874.8     1%              0.1
/ddvar                 29.5       24.7         3.3    88%                -
/ddvar/core            31.5        1.1        28.8     4%                -
----------------   --------   --------   ---------   ----   --------------

Cloud Tier
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB
----------------   --------   --------   ---------   ----   -------------
/data: pre-comp           -       33.1           -      -               -
/data: post-comp      912.2       42.3       869.9     5%             4.1
----------------   --------   --------   ---------   ----   -------------

Total:
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB
----------------   --------   --------   ---------   ----   -------------
/data: pre-comp           -    36674.6           -      -               -
/data: post-comp    65460.3      585.4     64874.8     1%             0.1
/ddvar                 29.5       24.7         3.3    88%               -
/ddvar/core            31.5        1.1        28.8     4%               -
----------------   --------   --------   ---------   ----   -------------

Come è strutturato un Cloud Tier?

• Un Cloud Tier è costituito da:   
  • Metadati in locale, archiviati in un'enclosure se viene utilizzato un DDR fisico o una LUN o un dispositivo se viene utilizzato DDVE.
  • Provider di storage a oggetti
• Entrambe le opzioni precedenti sono combinate in un'unità cloud.
• Se sono configurate più unità cloud, possono condividere i metadati in locale.
• È possibile configurare un massimo di due unità cloud per sistema. Ogni unità cloud può essere sottoposta a provisioning da un provider di storage a oggetti diverso.
• Ogni unità cloud può avere le stesse dimensioni massime supportate di Active Tier per il modello di DDR specificato. Per ulteriori informazioni, consultare la guida all'amministrazione di DD OS.

​​​​​​Cosa succede durante un tipico ciclo di vita di backup quando è configurata la funzione LTR?

• Tutti i dati vengono inizialmente scritti nell'Active Tier, dove iniziano il loro ciclo di vita.
• I dati di breve durata che raggiungono il periodo di retention scadono o vengono eliminati come in un DDR normale.
• Tuttavia, un sottoinsieme di dati che richiedono la funzione Long-Term Retention viene migrato al Cloud Tier.
• Il file system mantiene un singolo namespace in tutti i tier e pertanto, quando un file migra al cloud, il namespace non cambia e, come tale, la migrazione risulta sostanzialmente trasparente per l'utente o per l'applicazione di backup.
• Quando un file già migrato al Cloud Tier raggiunge il periodo di retention, scade o viene eliminato come qualsiasi altro file.
• Lo spazio utilizzato da un file nel Cloud Tier non viene recuperato immediatamente, ma deve essere eseguita la pulizia del Cloud Tier.

​​​​​​Come vengono deduplicati i dati tra i tier?

• Ogni unità cloud è un volume standalone, ovvero un'unità di deduplica autonoma.
• Di conseguenza, i dati scritti in ogni unità cloud possono deduplicarsi solo rispetto ai dati nella stessa unità cloud.

​​​​​​Cosa si intendere per ora posizionamento (nota come ptime)?

• I file e le directory hanno vari indicato di data e ora associati.
• Ad esempio, un file o una directory ha un'ora di creazione, l'ora dell'ultimo accesso e l'ora di modifica.
• DD OS ha migliorato ulteriormente questa caratteristica per includere anche un'ora di posizionamento. La data e l'ora di migrazione sono la data e l'ora in cui il file è stato spostato dall'Active Tier al Cloud Tier.
• A seconda della versione di DD OS, l'ora di posizionamento può essere visualizzata quando si esamina il tier su cui risiede un file. Se il file è stato migrato al Cloud Tier, viene visualizzata l'ora di posizionamento, ad esempio:  

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-4        cloudunit2           Tue Sep 5 10:17:00 2017
/data/col1/mtree1/random-data-file-5        cloudunit2           Tue Sep 12 15:52:23 2017
/data/col1/mtree1/random-data-file-6        cloudunit2           Tue Sep 13 09:42:55 2017

• Il cosiddetto "ptime" è l'ultimo campo nell'output precedente, anche se non visualizza un'intestazione di campo.

​​​​​​Come si spostano i dati dall'Active Tier al Cloud Tier?

• Un processo denominato spostamento dei dati è responsabile dell'esame dei file all'interno di un MTree che risiedono nell'Active Tier.
• Lo spostamento dei dati inizia creando una snapshot di tutti gli MTree configurati per lo spostamento dei dati.
• Ogni file ha un'ora di modifica che archivia l'ultima volta in cui è stato modificato un file tramite scrittura.
• Se un file è stato precedentemente migrato nel Cloud Tier, viene impostato un campo orario aggiuntivo, ovvero l'ora di posizionamento. L'ora di posizionamento archivia la data e l'ora in cui il file è stato migrato al Cloud Tier. Se viene impostata l'ora di posizionamento, viene utilizzata al posto dell'ora di modifica. In questo modo si evita che un file venga continuamente migrato al Cloud Tier se viene richiamato (poiché il richiamo di un file non modifica l'ora di modifica).
• Le snapshot create in precedenza vengono attraversate dallo spostamento dei dati.
• Se il file esaminato ha raggiunto un valore di soglia definito, come impostato dalla policy di spostamento dei dati per l'MTree in questione, il file viene esaminato per verificare quali dati in tale file devono migrare dall'Active Tier al Cloud Tier. Viene impostata una policy di spostamento dei dati per singolo MTree.
• I segmenti univoci per il file selezionato vengono scritti o copiati nel Cloud Tier. 
• Una volta che i segmenti univoci sono stati copiati, il file viene verificato leggendo nuovamente i segmenti per assicurarsi che la migrazione abbia avuto esito positivo.
• Una volta verificato il file, i metadati vengono aggiornati per riflettere il fatto che ora il file risiede nel Cloud Tier.
• Il processo di spostamento dei dati può essere pianificato per l'esecuzione a una determinata frequenza o può essere avviato manualmente.

​​​​​​All'avvio dello spostamento dei dati, quali fasi si verificano e quali azioni esegue ciascuna fase?

• Esistono tre fasi associate allo spostamento dei dati: copia, verifica e installazione.
• La fase di copia è responsabile dell'identificazione dei segmenti che devono essere copiati nel cloud e della relativa migrazione.
• Una volta avviata la fase di copia, viene utilizzato il cloud storage o lo storage a oggetti, mentre i segmenti identificati vengono copiati dall'Active Tier al Cloud Tier.
• La fase di verifica è responsabile di garantire che i segmenti di un file siano stati migrati correttamente al cloud.
• La fase di installazione è responsabile dell'aggiornamento dei metadati, relativi al file migrato, per mostrare che ora risiedono nel cloud storage o nello storage a oggetti.
• Ogni file deve completare tutte e tre le fasi affinché lo spostamento dei dati sia considerato corretto per tale file. Pertanto, fino al completamento della fase di installazione per un file, il file rimane nell'Active Tier.

​​​​​​Quali policy di spostamento dei dati sono disponibili?

• Le policy di spostamento dei dati possono essere di uno dei tipi seguenti:   
  • Soglia temporale: se l'ora di posizionamento o modifica di un file è superiore all'intervallo temporale impostato, il file viene selezionato per la migrazione al Cloud Tier.
  • Intervallo temporale: se l'ora di posizionamento o modifica di un file rientra in un determinato intervallo, il file viene selezionato per la migrazione al Cloud Tier.
  • Definita dall'applicazione: l'applicazione di backup indica se un file deve essere selezionato per la migrazione al Cloud Tier.
• Le policy si escludono a vicenda, ovvero un MTree può avere una sola policy impostata alla volta.

​​​​​​In che modo è possibile impostare una policy di spostamento dei dati su un MTree?

• È possibile utilizzare il comando riportato di seguito. Ad esempio:   

data-movement policy set <policy name> <policy type values> totier cloud cloud-unit <cloud unit name> mtrees <mtree list>

sysadmin@dd4500 # data-movement policy set age-threshold 14 to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1
sysadmin@dd4500 # data-movement policy set age-range min-age 14 max-age 100 to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1
sysadmin@dd4500 # data-movement policy set app-managed to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1

​​​​​​Quali policy di spostamento dei dati sono già configurate?

• Il comando riportato di seguito fornisce un elenco degli MTree a cui sono assegnate policy di spostamento dei dati. Ad esempio:   

data-movement policy show

sysadmin@dd4500 # data-movement policy show
Mtree               Target(Tier/Unit Name)   Policy      Value      
-----------------   ----------------------   ---------   -----------
/data/col1/mtree1   Cloud/cloudunit1         age-range   14-100 days
-----------------   ----------------------   ---------   -----------

​​​​​​Come funziona una policy di spostamento dei dati gestita da app?

• La policy di spostamento dei dati per l'MTree in questione è impostata come gestita da app. Questa operazione viene eseguita manualmente oppure con l'applicazione di backup che utilizza l'interfaccia API REST di Data Domain.
• L'applicazione di backup deve essere compatibile con LTR.
• L'applicazione di backup deve utilizzare DD Boost e la versione di DD Boost deve essere compatibile con LTR.
• Utilizzando la libreria/API DD Boost, l'applicazione di backup imposterà l'ora di posizionamento per il file di cui eseguire la migrazione nel cloud tier su un valore speciale che indica che la prossima volta che verrà eseguito lo spostamento dei dati, il file deve essere migrato nel cloud.
• Quando lo spostamento dei dati avviene sul sistema Data Domain, viene controllata l'ora di posizionamento e, se è impostata su un valore speciale, come menzionato in precedenza, il file viene migrato al cloud.

​​​​​​In che modo è possibile avviare manualmente lo spostamento dei dati?

• È possibile utilizzare il comando riportato di seguito, ad esempio:   

data-movement start

sysadmin@dd4500 # data-movement start
Data-movement started.

​​​​​​In che modo è possibile monitorare lo spostamento dei dati?

• Il comando riportato di seguito può essere utilizzato per controllare lo stato dello spostamento dei dati. Ad esempio:   

data-movement status

sysadmin@dd4500 # data-movement status
Data-movement to cloud tier:
----------------------------
Data-movement is initializing..

Data-movement recall:
---------------------
No recall operations found. 

• Se lo spostamento dei dati è in esecuzione, è possibile utilizzare il comando riportato di seguito, ad esempio:   

data-movement watch 

sysadmin@dd4500 # data-movement watch
Data-movement: phase 1 of 3 (copying)
   92% complete; time: phase  0:08:04, total  0:08:14
      Copied (post-comp): 3.35 GiB, (pre-comp): 3.29 GiB,B,
      Files copied: 7, Files verified: 3, Files installed: 3

​​​​​​In che modo è possibile arrestare lo spostamento dei dati?

• È possibile utilizzare il comando riportato di seguito. Ad esempio:   

data-movement stop 

sysadmin@dd4500 # data-movement stop
Data-movement stop initiated. Run the status command to check its status.

​​​​​​Se sono presenti più unità cloud, lo spostamento dei dati può essere eseguito in parallelo su entrambe le unità cloud?

• No. Essenzialmente, lo spostamento dei dati può eseguire la migrazione dei dati solo a un'unità cloud alla volta.

Come si configura la funzione LTR?

• Questo documento è una panoramica generale. Consultare il processo dettagliato nella guida all'amministrazione di DD OS.
• Aggiungere il file CLOUDTIER_CAPACITY license.
• Impostare la passphrase di sistema, se non è già impostata.
• Abilitare la funzione cloud.
• Aggiungere lo storage dei metadati per il Cloud Tier.
• Configurare un profilo cloud o un profilo per il fornitore di cloud storage o storage a oggetti appropriato.
• Aggiungere un'unità cloud.
• Configurare una policy di spostamento dei dati per uno o più MTree che richiedono lo storage dei dati nel cloud.
• Avviare manualmente lo spostamento dei dati o attendere l'avvio di uno spostamento automatico o pianificato dei dati.

​​​​​​È possibile eliminare un'unità cloud? In caso affermativo, come?

• Attenzione: questa operazione elimina tutti i dati contenuti nell'unità cloud, senza che possano essere ripristinati. Pertanto, procedere con cautela.
• Consultare la sezione di questo documento della Knowledge Base denominata "​​​​​​In che modo un utente verifica il tier su cui si trova un file?" per capire quali file risiedono sull'unità cloud che deve essere eliminata.
• Questi file dovrebbero essere eliminati se non sono più necessari oppure richiamati nell'Active Tier se devono essere conservati.
• Se è necessario conservare i file, assicurarsi che tutti vengano richiamati prima di continuare.
• Non devono esserci file eliminati ancora presenti sull'unità cloud.
• Reimpostare eventuali policy di spostamento dei dati per uno o più MTree che utilizzano questa unità cloud.
• Disabilitare il file system.
• Eliminare l'unità cloud. In questo modo l'unità cloud viene contrassegnata in uno stato DELETE_PENDING, come previsto.
• Abilitare il file system.
• Una volta avviato, il file system inizia a eliminare in modo asincrono tutti gli oggetti nel provider del cloud storage o dello storage a oggetti utilizzati da questa unità cloud. Una volta eliminati tutti gli oggetti, vengono eliminati anche i bucket utilizzati da questa unità cloud. Se sono presenti molti oggetti, l'unità cloud può rimanere in uno stato DELETE_PENDING per un periodo di tempo prolungato.
• Una volta rimossi correttamente tutti gli oggetti e i bucket, l'unità cloud scompare dall'elenco delle unità cloud.

​​​​​​Cosa succede se non si riesce a eliminare un'unità cloud poiché lo storage a oggetti non è più disponibile o si verifica un problema di connettività?

• Contattare il Supporto Dell per ulteriore assistenza.

È possibile configurare LTR ed ER (Extended Retention) sullo stesso sistema?

• No, ER e LTR sono funzioni che si escludono a vicenda.

​​In che modo vengono liberati o puliti i dati dal Cloud Tier?

• In modo simile ai file che risiedono nel Cloud Tier.
• Una volta raggiunto il periodo di retention, un file viene eliminato dal namespace del file system.
• La pulizia del Cloud Tier viene eseguita in base a una pianificazione. Per impostazione predefinita, la pulizia del Cloud Tier viene eseguita dopo ogni quattro sessioni di pulizia dell'Active Tier.
• Affinché la pulizia del Cloud Tier venga eseguita, l'unità cloud da pulire deve avere almeno l'1% di dati superflui o pulibili. Ciò è dovuto al fatto che qualsiasi traffico di rete cloud potrebbe essere a pagamento, quindi il DDR tenta di limitare il traffico di rete laddove possibile.
• Il Cloud Tier viene eseguito con un'impostazione predefinita del 50% di limitazione della pulizia.
• È possibile modificare sia la pianificazione della pulizia del Cloud Tier che la limitazione della pulizia.
• La pulizia dell'Active Tier e quella del Cloud Tier non possono essere eseguite in parallelo.
• Se è in esecuzione la pulizia automatica o pianificata del Cloud Tier, viene annullata dalla pulizia dell'Active Tier.
• Se viene avviata una pulizia manuale del Cloud Tier, la pulizia dell'Active Tier non può essere avviata fino al completamento della pulizia del Cloud Tier.
• Se un Cloud Tier include due unità cloud, viene pulita una sola unità cloud in base alla pulizia automatica o pianificata del Cloud Tier. Le unità cloud vengono utilizzate in modalità Round Robin dal punto di vista della pulizia del Cloud Tier. Quando sono presenti due unità cloud, è necessario specificare quella da pulire in caso di esecuzione dalla riga di comando (cloud clean start <unit-name>)
• Se la pulizia di un Cloud Tier non si avvia su un'unità cloud, ad esempio, se l'unità cloud corrente non dispone di dati pulibili sufficienti per ritenerla utile, il sistema tenta automaticamente di eseguire la pulizia dall'unità cloud successiva.
• Per ulteriori informazioni sulla pulizia del cloud tier, consultare il seguente articolo Data Domain: introduzione alla funzione Long Term Retention, alla pulizia del Cloud Tier e alla garbage collection su Data Domain Restorer (DDR)

​​​​​​In che modo viene avviata una pulizia manuale del Cloud Tier?

• È possibile utilizzare il comando riportato di seguito. Ad esempio:   

cloud clean start <cloud unit> 

sysadmin@dd4500 # cloud clean start cloudunit2
Cloud tier cleaning started for cloud unit "cloudunit2". Use 'cloud clean watch' to monitor progress.

​​​​​​In che modo è possibile monitorare una pulizia del Cloud Tier?

• Il comando riportato di seguito può essere utilizzato per verificare se la pulizia cloud è in esecuzione. Ad esempio:   

cloud clean start <cloud unit> 

sysadmin@dd4500 # cloud clean status
Previous cloud tier cleaning attempt was unsuccessful.
 Failure reason:
cloud unit "cloudunit2" did not have sufficient cleanable data.
Cloud tier cleaning finished at 2017/03/15 12:16:06.

• Se il processo di pulizia cloud è in esecuzione, può essere monitorato utilizzando il comando seguente:

cloud clean watch

​​​​​​È possibile eseguire contemporaneamente la pulizia dell'Active Tier e del Cloud Tier?

• No. La pulizia dell'Active Tier e quella del Cloud Tier utilizzano entrambe le stesse strutture di dati interne condivise comuni che richiedono l'accesso esclusivo.

​​​​​​In che modo è possibile visualizzare o modificare una pianificazione di pulizia del Cloud Tier?

• È possibile utilizzare il comando riportato di seguito per visualizzare la pianificazione di pulizia cloud attuale. Ad esempio:   

cloud clean frequency show

sysadmin@dd4500 # cloud clean frequency show
Cloud tier cleaning frequency is set to run after every 4 active tier cleaning cycles.

• Il comando riportato di seguito viene utilizzato per modificare una pianificazione. Ad esempio:  

cloud clean frequency set <value>

sysadmin@dd4500 # cloud clean frequency set 3
Cloud tier cleaning frequency is set to run after every 3 active tier cleaning cycles.

​​​​​​In che modo è possibile modificare o visualizzare la limitazione di pulizia del Cloud Tier?

• Per impostazione predefinita, la limitazione di pulizia del Cloud Tier è impostata al 50%. È possibile utilizzare il comando riportato di seguito per reimpostarla sulla percentuale di limitazione predefinita.

cloud clean throttle reset

• È possibile utilizzare il comando riportato di seguito per visualizzare la limitazione di pulizia cloud attuale. Ad esempio:   

cloud clean throttle show

sysadmin@dd4500 # cloud clean throttle show
Cloud tier cleaning throttle is set to 28 percent

• È possibile utilizzare il comando riportato di seguito per modificare la limitazione di pulizia. Ad esempio:   

cloud clean throttle set <value> 

sysadmin@dd4500 # cloud clean throttle set 20
Cloud tier cleaning throttle set to 20 percent

​​Che cosa controlla il limite di pulizia del Cloud Tier?

• La limitazione di pulizia del Cloud Tier funziona in modo simile a quella dell'Active Tier, in quanto limita le risorse di I/O e CPU che la pulizia del Cloud Tier può utilizzare.
• Non limita il trasferimento sulla rete.

​​​​​​Perché la pulizia del Cloud Tier non libera/elimina il numero di oggetti previsto?

• La pulizia è sempre considerata una stima. Consultare i seguenti articoli della Knowledge Base che descrivono gli aspetti di questo argomento, in quanto si applicano allo stesso modo ai dati che risiedono nel Cloud Tier:  

• Inoltre, sono disponibili ulteriori dettagli specifici su come viene implementato il Cloud Tier.
• Sono stati implementati vari metodi per limitare la quantità di traffico di rete verso un provider di cloud storage o storage a oggetti, in quanto potrebbe comportare costi associati.
• Come accennato in precedenza, è necessario almeno l'1% di varianza dei dati per l'esecuzione della pulizia.
• Quando il file system viene attraversato per cercare file che soddisfino la policy di spostamento dei dati, vengono esaminate solo le copie locali dei metadati.
• Tutti i segmenti contenuti nel cloud storage o nello storage a oggetti che contengono solo dati dell'utente vengono contrassegnati per l'eliminazione asincrona.
• Tutti i segmenti contenenti almeno un segmento attivo vengono ignorati, poiché DD OS non combina piccole quantità di dati a causa del traffico di rete coinvolto.

​​​​​​In che modo un utente verifica il tier su cui si trova un file?

• Utilizzare il comando riportato di seguito per un esempio dell'output generato da questo comando:  

filesys report generate file-location

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-1        Active
/data/col1/mtree1/random-data-file-2        Active
/data/col1/mtree1/random-data-file-4        cloudunit2
/data/col1/mtree1/random-data-file-5        cloudunit2
/data/col1/mtree1/random-data-file-6        cloudunit2

È possibile leggere o accedere a un file direttamente dopo la migrazione al Cloud Tier?

• Dipende dalla versione di DD OS in uso insieme al provider di cloud:   

• Il ripristino diretto dei file è possibile senza dover prima richiamare un file. Questa funzione, nota come "Direct Restore", è limitata a ECS come provider di cloud storage o storage a oggetti.
• Per ulteriori dettagli su "Direct Restore" da Avamar, consultare il white paper "Avamar Granular or File Level Restore from Data Domain Cloud Tier".
• La funzione Avamar GLR/FLR (Direct Restore) richiede una combinazione minima di Avamar 18.1 o DD OS 6.1 con ECS come provider di cloud. 

• È prima necessario richiamare un file. Ciò significa che i dati vengono migrati nuovamente dal Cloud Tier all'Active Tier.
• Il file deve essere richiamato dal Cloud Tier all'Active Tier utilizzando il comando data-movement recall per consentire qualsiasi lettura da un file o modifica in un file che risiede nel Cloud Tier.
• Qualsiasi tentativo di lettura o modifica di un file che risiede nel Cloud Tier comporta la restituzione di un errore di I/O a chi tenta di leggere il file, ovvero l'applicazione di backup, se il file non viene prima richiamato.
• Alcune applicazioni di backup compatibili con il cloud possono avviare richiami di file, altrimenti i file devono essere richiamati manualmente.
• Da DD OS 7.7:
  • Il ripristino diretto consente alle applicazioni non integrate di leggere i file direttamente dal Cloud Tier senza passare attraverso l'Active Tier.
  • Le considerazioni chiave nella scelta di utilizzare il ripristino diretto includono quanto segue:
  • Il ripristino diretto non richiede un'applicazione integrata ed è automatico per le applicazioni non integrate.
  • La lettura dal Cloud Tier non richiede prima la copia nell'Active Tier.
  • Istogrammi e statistiche sono disponibili per monitorare le letture dirette dal Cloud Tier.
  • Il ripristino diretto è supportato solo per provider di cloud AWS ed ECS.
  • Le applicazioni sperimentano la latenza del Cloud Tier.
  • La lettura diretta dal Cloud Tier non è ottimizzata per la larghezza di banda.

Quanti file possono essere richiamati in parallelo?

• DD OS 6.0 supporta quattro file da mettere in coda e richiamare in parallelo.
• DD OS 6.1 supporta 1.000 file da mettere in coda e 4 file nella coda di richiamo da richiamare in parallelo.

In base al documento Data Domain Admin Guide 7.9:

• I sistemi con almeno 256 GB di memoria possono richiamare fino a 16 file contemporaneamente.
• I sistemi con meno di 256 GB di memoria possono richiamare fino a otto file contemporaneamente.
• Le istanze di DDVE possono richiamare fino a quattro file contemporaneamente.

​​​​​​Come si può richiamare un file?

• È possibile richiamare un file utilizzando il comando riportato di seguito. Ad esempio:   

data-movement recall path <path-name> 

sysadmin@dd4500 # data-movement recall path /data/col1/mtree1/file1

​​​​​​Come si possono richiamare tutti i file in un MTree?

• A seconda della versione di DD OS, tutti i file nel Cloud Tier possono essere richiamati eseguendo un singolo comando, ad esempio:   

sysadmin@dd4500 # data-movement recall mtree /data/col1/mtree1

• Per ulteriori informazioni, consultare il documento "Dell DDOS Command Reference Guide" per la versione di DD OS in uso

​​​​​​In che modo è possibile monitorare un'operazione di richiamo?

• Un'operazione di richiamo può essere monitorata utilizzando il comando riportato di seguito o se è necessario un file specifico. Ad esempio:   

data-movement status path all

data-movement status path /data/col1/mtree/file1

sysadmin@dd4500 # data-movement status path /data/col1/mtree1/file1
Data-movement recall:
---------------------
Data-movement for  /data/col1/mtree1/file1 : phase 2 of 3
(Verifying)
80% complete; time: phase XX:XX:XX total XX:XX:XX
Copied (post-comp): XX XX, (pre-comp) XX XX 

​​​​​​La ridenominazione di un file ne determina il richiamo dal Cloud Tier all'Active Tier?

• No. Se un file viene rinominato, rimane nel suo tier corrente.

​​​​​​Quali provider di cloud sono supportati?

•  A seconda della versione in uso, DD OS supporta i seguenti provider di cloud:   
• Amazon Web Services (AWS).
• Microsoft Azure Cloud
• Dell Elastic Cloud Storage (ECS)
• Virtustream
• Per ulteriori informazioni, consultare la guida all'amministrazione di DD OS.

​​​​​​La crittografia è supportata sul Cloud Tier e deve essere concessa in licenza?

• Sì, la crittografia è supportata nel Cloud Tier. Non richiede una licenza aggiuntiva, a differenza della crittografia dell'Active Tier.
• È configurabile quando la funzione cloud viene abilitata o modificata in un secondo momento. 
• Al momento della stesura di questo articolo, solo il Key Manager integrato è supportato per la crittografia del Cloud Tier e può essere utilizzato un solo algoritmo di crittografia per l'intero sistema LTR.

​​​​​​Quali bucket vengono creati nell'archivio oggetti dei provider di cloud?

• DD OS crea tre bucket
• I bucket terminano con la stringa:

'-d0'

'-c0' 

'-m0'

• Il bucket che termina con la stringa "-d0" viene utilizzato per i segmenti di dati.
• Il bucket che termina con la stringa "-c0" viene utilizzato per i dati di configurazione.
• Il bucket che termina con la stringa "-m0" viene utilizzato per i metadati.
• Prima di DD OS 6.1 venivano creati tre bucket, ma solo il bucket che terminava con "-d0" veniva utilizzato. Tuttavia, tutti e tre i bucket sono necessari, quindi assicurarsi che non vengano rimossi.

È possibile utilizzare nomi di bucket esistenti, creati in precedenza?

• No, non è possibile.

​​​​​​Oltre ai requisiti hardware, sono necessari altri requisiti obbligatori prima di configurare la funzione LTR?

• Sì
• Se si utilizza ECS, un sistema di bilanciamento del carico è un requisito obbligatorio. Senza un sistema di bilanciamento del carico, Data Domain comunica con ECS su un singolo nodo e si disconnette una volta effettuate più richieste.
• Una rete da 1 GB tra il DDR e il provider di cloud

​​​​​​Sono richiesti certificati e, in tal caso, quali devono essere utilizzati?

• Dipende dall'oggetto o dal provider di cloud utilizzato e anche dalla configurazione.
• AWS, Virtustream o Azure richiedono un certificato. Per ulteriori informazioni, consultare la guida all'amministrazione di DD OS.
• Se ECS è configurato utilizzando un endpoint http, non è richiesto un certificato.
• Se ECS è configurato utilizzando un endpoint https, è richiesto un certificato. Poiché il sistema di bilanciamento del carico è un requisito obbligatorio, il certificato richiesto proviene dal sistema di bilanciamento del carico anziché dal sistema ECS. Per ulteriori dettagli, contattare il fornitore del sistema di bilanciamento del carico.
• Quando si importa il certificato, deve essere in formato PEM. Alcuni provider non forniscono il certificato in formato PEM, quindi deve essere convertito prima dell'importazione.

​​​​​​Quali topologie di replica sono supportate?

• La replica di raccolta _non_ è supportata.
• La replica di directory è supportata, tuttavia può essere utilizzata solo dall'MTree "/data/col1/backup"; questo MTree non supporta lo spostamento dei dati.
• La replica di MTree è completamente supportata.
• La replica di MFR o VSR è completamente supportata.

​​​​​​Quali aspetti è opportuno considerare quando si configura/inizializza/reinizializza la replica su un sistema con la funzione LTR già configurata?

• Il sistema di origine acquisisce una snapshot dell'MTree (questa snapshot include i dettagli dei file sull'Active Tier e sul Cloud Tier).
• Il sistema di origine replica la snapshot sull'Active Tier del sistema di destinazione.
• Solo quando la snapshot è stata completamente replicata viene esposta nel sistema di destinazione (a quel punto i file diventano disponibili nel namespace del file system del sistema di destinazione).
• Solo dopo l'esposizione dei file è possibile eseguire lo spostamento dei dati sulla destinazione (supponendo che sia configurata per LTR).
• Di conseguenza, se l'Active Tier delle destinazioni non è sufficientemente grande da contenere una snapshot completa dall'origine, la snapshot non viene mai esposta e la replica non può completare l'inizializzazione.

​​​​​​Quali aspetti è opportuno considerare se si configura la replica MFR/VSR su un sistema con la funzione LTR già configurata?

• Se i dati già migrati al Cloud Tier su un DDR di origine devono essere replicati, vengono richiamati automaticamente dal provider di cloud all'Active Tier prima di poter essere inviati in rete.
• Il richiamo dei file dal Cloud Tier all'Active Tier può comportare costi aggiuntivi o ritardi.

​​​​​​Perché l'output del comando "file system show space" di Data Domain non riflette le dimensioni effettive del cloud storage o dello storage a oggetti?

• Per via della natura intrinseca del cloud storage o dello storage a oggetti, un sistema Data Domain non ha modo di eseguire query sulla dimensione fisica di un dispositivo cloud, poiché questa potrebbe apparire come virtualmente infinita.
• Tuttavia, DD OS ha dovuto sviluppare un modo per visualizzare le statistiche di utilizzo/deduplica correnti dal punto di vista di DD OS.
• Pertanto viene utilizzato uno dei due approcci seguenti:

1. Il Cloud Tier viene dimensionato in base al file CLOUDTIER_CAPACITY license
2. Le dimensioni del Cloud Tier vengono visualizzate come più dimensioni di Active Tier per il tipo specifico di modello a seconda del numero di unità cloud configurate. Per ulteriori informazioni sulle dimensioni degli Active Tier, consultare la guida all'installazione hardware per il modello in questione.

​​​​​​In che modo è possibile avviare il file system se un'unità cloud è non disponibile?

• Assicurarsi che il file system sia disabilitato.
• Disabilitare l'unità cloud non disponibile utilizzando il comando riportato di seguito:

cloud unit disable <cloud unit name>

• Abilitare il file system.

​​​​​​Se un'unità cloud è disabilitata, come può essere abilitata?

• Assicurarsi che il file system sia disabilitato.
• Abilitare l'unità cloud utilizzando il comando seguente:

cloud unit enable <cloud unit name>

• Abilitare il file system.

​​​​​​​Perché sono ancora presenti file nel file system che si trovavano su un'unità cloud eliminata?

•  Se non sono stati rimossi file da un MTree prima dell'eliminazione di un'unità cloud, i file continuano a esistere all'interno del namespace del file system.
• Di conseguenza, il report sulla posizione dei file mostra che i file fanno parte di un'unità cloud eliminata. Ad esempio:  

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-3  Deleted cloud-unit
/data/col1/mtree1/random-data-file-4  Deleted cloud-unit

• I file possono comunque essere visualizzati nel namespace del file system accedendo a una condivisione CIFS/NFS per l'MTree.
• Tuttavia, i file non sono leggibili perché l'unità cloud in cui si trovavano è stata eliminata.
• Pertanto, l'unica opzione è eliminare questi file, poiché i relativi dati a cui fanno riferimento non esistono più.

È possibile modificare l'endpoint del protocollo o le porte per un provider di cloud ECS o S3 Flexible dopo che un'unità cloud è stata creata?

• Ad esempio, potrebbe essere un'operazione necessaria se si passa da http a https o viceversa, eseguendo la migrazione a un nuovo sistema di bilanciamento del carico.
• Al momento della stesura di questo articolo, non esiste alcun modo per un amministratore di Data Domain di eseguire questa modifica. Questa funzionalità è in fase di valutazione per una versione futura di DD OS.
• Tuttavia, questa operazione può essere eseguita dal supporto o dal reparto Engineering.
• Il file system deve essere disabilitato per poter eseguire questa modifica.
• Se ciò è necessario, la configurazione all'esterno del sistema Data Domain viene eseguita per prima perché, una volta apportata questa modifica, quando il file system viene abilitato, si aspetta di poter comunicare utilizzando il protocollo o la porta aggiornata e leggere i bucket o gli oggetti come in precedenza.