Data Domain: funzionamento di NetWorker con Data Domain e Cloud Tier

NetWorker (NW) dispone di supporto integrato per Data Domain Cloud Tier (DD CT). Ciò significa che l'amministratore NW può impostare policy per il tiering nel cloud: NW contrassegna le singole immagini di backup in modo che in un secondo momento lo spostamento dei dati DD nel cloud venga eseguito e invii tali file all'unità cloud configurata.

Il primo aspetto importante da evidenziare è che NW non sposta o copia (clona) i dati nel cloud. Crea copie (cloni) di SSID da inviare al cloud, ma i cloni si trovano (inizialmente) nell'Active Tier DD. È solo dopo l'avvio della pianificazione dello spostamento dei dati DD configurata che l'SSID contrassegnato per il cloud (con tiering) deve essere inviato al cloud storage.

Il processo completo, dalla creazione di un backup fino al momento in cui il relativo SSID diventa disponibile nel cloud, funziona in maniera estremamente simile a quanto illustrato qui sotto:

1. NW è configurato per archiviare i backup in un DD (l'acquisizione avviene sempre nell'Active Tier DD). A tale scopo, utilizza in genere una singola unità di storage:

DDBOOST Storage-Unit Show Type BoostFS
-------------------------

Name                   Pre-Comp (GiB)   Status   User            Report Physical   BoostFS
                                                                    Size (MiB)
--------------------   --------------   ------   -------------   ---------------   -------
NW-STORAGE-UNIT            25680542.0   RW       boostuser                    -    no
--------------------   --------------   ------   -------------   ---------------   -------

2. All'interno di NetWorker, ogni policy di backup viene archiviata in ciò che NetWorker chiama "dispositivo". Un dispositivo non è altro che una sottodirectory sotto la radice dell'unità di storage, ad esempio:

/data/col1/NW-STORAGE-UNIT/DAILY-DB-DEV01/00/80/ee140226-00000006-2b625ef6-66625ef6-0e095000-e36c9c56
/data/col1/NW-STORAGE-UNIT/DAILY-DB-DEV02/00/48/f8959462-00000006-3f775a89-66775a89-b8fa5000-e36c9c56
/data/col1/NW-STORAGE-UNIT/MONTHLY-DB-DEV01/03/93/30e0c543-00000006-3d5cac26-665cac26-f6f75000-e36c9c56
/data/col1/NW-STORAGE-UNIT/MONTHLY-FS-DEV06/92/30/05729157-00000006-cc5a6431-665a6431-9e685000-e36c9c56

Qui le policy o i dispositivi sono "DAILY-DB-DEV01", "DAILY-DB-DEV02", "MONTHLY-DB-DEV01" e "MONTHLY-FS-DEV06".

3. NW viene infine configurato per DD CT e determina una configurazione di spostamento dei dati gestita tramite app in DD, come indicato di seguito:

Cloud Data-Movement Configuration
---------------------------------
Mtree                             Target(Tier/Unit Name)   Policy        Value
-------------------------------   ----------------------   -----------   -------
/data/col1/NW-STORAGE-UNIT        Cloud/CLOUD-UNIT         app-managed   enabled
-------------------------------   ----------------------   -----------   -------

La configurazione dello spostamento dei dati DD nel cloud richiede un MTree di origine (l'unità di storage NW), un'unità cloud di destinazione (CLOUD-UNIT) e una policy, che per NetWorker (e Avamar) deve essere "gestita tramite app", anziché "soglia di età", in quanto i file da spostare nel cloud sono determinati (contrassegnati) da NW, non scelti in base all'età dei file stessi.

4. Il modo in cui funziona NW per DD CT è che non "contrassegna" i file da spostare nel cloud nella loro posizione originale: quando il cliente imposta NW per il cloud tiering, deve creare un altro dispositivo all'interno della stessa unità di storage, in cui i file da inviare al cloud vengono prima clonati da NW. Ad esempio, un determinato SSID configurato per lo storage in DD CT viene visualizzato come due file distinti (ma identici) in un report di posizione dei file DD:

# filesys report generate file-location tiering
--------------------------------                                                                                  ----------------------      -----         ---------------------------
File Name                                                                                                         Location(Unit Name)         Size          Placement Time
--------------------------------                                                                                  ----------------------      -----         ---------------------------
/data/col1/NW-STORAGE-UNIT/MONTHLY-FS-DEV05/85/72/365bdbce-00000006-3157c1bc-6657c1bc-32035000-e36c9c56                        Active         1.15 TiB      Thu May 30 04:00:59 2024
/data/col1/NW-STORAGE-UNIT/CLOUD-LONG-TERM-DEV04/85/72/365bdbce-00000006-3157c1bc-6657c1bc-32035000-e36c9c56               CLOUD-UNIT         1.15 TiB      Sat Jun  1 11:13:33 2024

Le informazioni precedenti mostrano che:

• L'immagine di backup con SSID lungo "365bdbce-00000006-3157c1bc-6657c1bc-32035000-e36c9c56" è stata scritta nell'Active Tier DD e l'ultima volta è stata scritta in "Thu May 30 04:00:59 2024", con nome del dispositivo "MONTHLY-FS-DEV05"
• Esiste una policy di tiering (con un dispositivo di destinazione) denominata "CLOUD-LONG-TERM-DEV04/"
• Quando è stata eseguita la policy di tiering (ciò si verifica probabilmente già al completamento del backup), è stata creata una copia (clone) dell'SSID dal dispositivo originale nel dispositivo cloud NW denominato "CLOUD-LONG-TERM-DEV04"
• È stato quindi eseguito lo spostamento dei dati DD e il clone del backup originale è stato spostato dall'Active Tier all'unità cloud, processo completato per il file da "Sat Jun 1 11:13:33 2024"
• Nel momento in cui sono state raccolte le informazioni sulla posizione dei file di cui sopra, esiste una copia dello stesso SSID lungo nell'Active Tier e nel Cloud Tier DD
• NW fa scadere ed elimina le singole copie quando necessario. In teoria, la copia nell'Active Tier scade prima di quella nel Cloud Tier, che deve essere conservata più a lungo (altrimenti sarebbe del tutto inutile inviare l'immagine di backup al cloud)

5. La documentazione di NetWorker richiede che il dispositivo nel Cloud Tier nella procedura guidata NW venga creato sotto la stessa unità di storage dei file nell'Active Tier. La creazione del dispositivo cloud su un'unità di storage diversa può causare l'esecuzione dei cloni utilizzando un'unità diversa da "fastcopy", con tempi di clonazione molto più lenti. Questa è la sezione applicabile nella documentazione NW:
https://www.dell.com/support/manuals/en-us/networker/nw_p_ddboostdedup_integration/configuring-networker-devices-for-dd-cloud-tier?guid=guid-680d906f-10c7-4266-822e-1a0f3ba3e201⟨=en-us
 

Configuring NetWorker devices for DD Cloud Tier
-----------------------------------------------
Use the Device Configuration Wizard to configure NetWorker devices for the DD Cloud Tier devices.

The Data Domain devices that contain the source backup data must reside on the same mtree as the DD Cloud Tier device that will store the clone data. The storage node that manages the Data Domain devices must be a NetWorker 19.7 storage node. 

6. Una delle implicazioni dell'istruzione riportata sopra dalla documentazione di NW è che in una configurazione NetWorker/Data Domain con Cloud Tier in genere tutti i dati vengono archiviati nella stessa unità di storage all'interno di DD e non esiste un modo supportato per inviare immagini di backup NW a due unità cloud distinte. La configurazione dello spostamento dei dati DD non può avere più di una policy per lo stesso MTree di origine, il che potrebbe rappresentare un problema in situazioni come, ad esempio, la capacità per la prima unità cloud di raggiungere il limite (vedere di seguito per un esempio):

Active Tier:                                                                                       
Resource           Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*                        
----------------   --------   ---------   ---------   ----   --------------                        
/data: pre-comp           -   8477328.0           -      -                -                        
/data: post-comp   944180.2    769927.8    174252.4    82%          90605.3                        
----------------   --------   ---------   ---------   ----   --------------                        

Cloud Tier unit-wise space usage                                                                   
--------------------------------                                                                   
CLOUD-UNIT                                                                                         
Resource             Size GiB     Used GiB   Avail GiB   Use%   Cleanable GiB                      
----------------   ----------   ----------   ---------   ----   -------------                      
/data: pre-comp             -   16935910.0           -      -               -                      
/data: post-comp   1572768.4*    1572755.0        13.4   100%             0.0                      
----------------   ----------   ----------   ---------   ----   -------------                      

Cloud Data-Movement Configuration                                        
---------------------------------                                        
Mtree                      Target(Tier/Unit Name)   Policy        Value  
------------------------   ----------------------   -----------   -------
/data/col1/NW-STORAGE-UNIT Cloud/CLOUD-UNIT         app-managed   enabled
------------------------   ----------------------   -----------   -------

7. Quando si tenta di superare la limitazione di cui sopra, un cliente può creare una nuova unità di storage NetWorker per i backup futuri. In alternativa, può eseguire i cloni dall'unità di storage esistente a un dispositivo nella nuova unità, aggiungendo successivamente una seconda policy di spostamento dei dati DD dalla nuova unità di storage alla nuova unità cloud. Il risultato è una configurazione simile a quella riportata di seguito:

Cloud Unit List
---------------
Name           Profile              Status   Reason
------------   ------------------   ------   -------------------------------
CLOUD-UNIT     CLOUD-UNIT_profile   Active   Cloud unit connected and ready.  <<-- existing Cloud Unit
CLOUD-UNIT02   CLOUD-UNIT_profile   Active   Cloud unit connected and ready.  <<-- new Cloud Unit
------------   ------------------   ------   -------------------------------

Cloud Data-Movement Configuration
---------------------------------
Mtree                             Target(Tier/Unit Name)   Policy        Value
-------------------------------   ----------------------   -----------   -------
/data/col1/NW-STORAGE-UNIT          Cloud/CLOUD-UNIT         app-managed   enabled
/data/col1/NW-STORAGE-UNIT-NEW      Cloud/CLOUD-UNIT02       app-managed   enabled
-------------------------------   ----------------------   -----------   -------

Oltre al requisito della documentazione NW, il problema principale è che la clonazione è un processo particolarmente lento. Inoltre, è possibile che venga visualizzato qualcosa di simile in DD SSP (system show performance):

                     -----------Throughput (MB/s)----------- ---------------Protocol-----------------  Compression  ------Cache Miss--------  -----------Streams-----------  -MTree Active-  ----State---  -----Utilization-----  --Latency-- 
                                                                                                                                                                       Repl
Date       Time      Read  Write Repl Network  Repl Pre-comp ops/s    load    data(MB/s)    wait(ms/MB)  gcomp lcomp  thra unus ovhd data meta    rd/  wr/  r+/  w+/  in/ out      rd/wr      'CDPVMSFIRL'     CPU        disk       in ms     stream   
---------- --------  ----- ----- ----in/out--- ----in/out--- -----    --%--   --in/out---   --in/out---  ----- -----  ---- ---- ---- ---- ----  ----------------------------- --------------  -----------  -avg/max---- --max---  --avg/sdev-  -----------
2024/06/13 18:27:00    0.0    0.0   0.00/  0.00   0.00/  0.00     2   NaN%   0.00/  0.00  20.97/ 37.46    1.7   1.7    0%   0%  21%   0%   2%     0/   0/   0/   0/   0/   0       0/ 0       ---V---I---    6%/  8%[13]  7%[28]  2.1/  7.5  116.0/  2.2 
2024/06/13 18:37:00    0.0    0.0   0.00/  0.00   0.00/  0.00    89   NaN%   0.01/  0.01  19.45/ 68.12    2.8   2.1    0%   0%  21%   0%   1%     0/   0/   0/   0/   0/   0       0/ 0       ---V---I---    5%/  6%[4]   7%[28]  0.7/  3.7  115.8/  3.0 
2024/06/13 18:47:00   39.6   39.5   0.00/  0.00   0.00/  0.00  1160   NaN%   0.54/ 37.82   4.27/  0.42   62.5   1.7    0%   0%  11%   0%   1%     1/   1/   0/   0/   0/   0       1/ 1       ---V---I---    5%/  7%[4]   7%[28]  0.4/  3.0  118.8/  3.4 
2024/06/13 18:57:00  215.5  215.5   0.00/  0.00   0.00/  0.00   825   NaN%   0.93/205.66   4.29/  0.30  291.2   1.2    0%   0%   7%   0%   1%     1/   1/   0/   0/   0/   0       1/ 1       ---V---I---    7%/  9%[14]  8%[28]  0.1/  3.8  118.8/  3.7 
2024/06/13 19:07:00  223.9  223.9   0.00/  0.00   0.00/  0.00   856   NaN%   0.94/213.74   4.32/  0.29  327.5   1.1    0%   0%   7%   0%   1%     1/   1/   0/   0/   0/   0       1/ 1       ---V---I---    7%/  9%[14]  8%[28]  0.1/  0.8  118.5/  4.4 
2024/06/13 19:17:00  218.5  218.5   0.00/  0.00   0.00/  0.00  1916   NaN%   1.01/208.56   5.34/  0.32  278.3   1.3    0%   0%   9%   0%   1%     1/   1/   0/   0/   0/   0       1/ 1       ---V---I---    7%/  9%[4]   8%[28]  0.2/  3.7  118.2/  3.6 
2024/06/13 19:27:00  174.3  174.3   0.00/  0.00   0.00/  0.00   696   NaN%   2.25/166.37   2.02/  0.30   64.7   1.5    0%   1%  19%   0%   1%     1/   1/   0/   0/   0/   0       0/ 2       ---V---I---    8%/ 12%[13]  9%[28]  0.4/  6.5  121.5/  4.6 
2024/06/13 19:37:00  182.6  183.5   0.00/  0.00   0.00/  0.00   719   NaN%   5.40/174.31   1.24/  0.29   34.8   1.1    2%   6%  28%   0%   3%     1/   3/   0/   0/   0/   0       0/ 2       ---V---I---    8%/ 11%[43] 12%[28]  0.3/  6.0  121.8/  6.9 
...
2024/06/20 15:39:00  150.4  293.6   0.00/  0.00   0.00/  0.00   6716  NaN%  25.47/146.12   1.39/  0.59   11.8   1.0    1%   0%  19%   0%   4%     0/   2/   0/   0/   0/   0       0/ 2       ---V---I---    7%/ 13%[15]  5%[14]  0.2/  1.0  119.2/  4.0 
2024/06/20 15:49:00  215.9  298.8   0.00/  0.00   0.00/  0.00  12448  NaN%  31.55/212.33   1.60/  0.65    9.8   1.0    2%   0%   0%   0%   2%     0/   2/   0/   0/   0/   0       0/ 2       ---V---I---    8%/ 15%[15]  4%[21]  0.2/  0.5  117.5/  2.7 
2024/06/20 15:59:00  186.5  344.3   0.00/  0.00   0.00/  0.00   1854  NaN%  24.07/178.14   1.04/  0.33   14.6   1.0    5%   0%  21%   0%   2%     1/   2/   0/   0/   0/   0       0/ 2       ---V---I---    6%/ 14%[15]  5%[ 3]  0.4/  4.4  119.2/  2.3 
2024/06/20 16:09:00  205.3  426.2   0.00/  0.00   0.00/  0.00    808  NaN%  18.73/196.08   1.09/  0.30   24.4   1.0    4%   5%  27%   0%   3%     0/   2/   0/   0/   0/   0       0/ 2       ---V---I---    6%/ 14%[47]  5%[ 3]  0.3/  0.3  117.5/  2.6 
2024/06/20 16:19:00  211.7  399.3   0.00/  0.00   0.00/  0.00    843  NaN%  17.86/202.10   1.09/  0.29   23.5   1.0    2%   0%   0%   0%   2%     1/   2/   0/   0/   0/   0       0/ 2       ---V---I---    6%/ 13%[15]  3%[ 3]  0.3/  4.8  119.2/  1.8 
...                                                                                        
2024/06/23 18:21:00  470.3  484.6   0.00/  0.00   0.00/  0.00   1807  NaN%   9.85/448.86   2.59/  0.30   50.2   1.1    1%  21%  34%   0%   0%     4/   5/   0/   0/   0/   0       0/ 2       ---V---I---    7%/ 11%[9]   9%[13]   0.2/  1.5  126.8/  8.8 
2024/06/23 18:31:00  477.2  494.6   0.00/  0.00   0.00/  0.00   1846  NaN%   8.99/455.44   2.69/  0.29   57.3   1.1    1%  13%  27%   0%   0%     4/   5/   0/   0/   0/   0       0/ 2       -------I---    5%/  9%[0]   7%[17]   0.2/  1.7  127.0/  6.8 
2024/06/23 18:41:00  458.9  481.3   0.00/  0.00   0.00/  0.00   2913  NaN%  10.17/438.07   2.57/  0.30   48.3   1.1    1%  12%  28%   0%   0%     4/   5/   0/   0/   0/   0       0/ 2       -------I---    5%/  8%[0]   7%[ 3]   0.2/  1.2  127.0/  5.8 
2024/06/23 18:51:00  468.7  481.2   0.00/  0.00   0.00/  0.00   1807  NaN%  10.60/447.40   2.27/  0.29   46.5   1.1    1%  19%  34%   0%   1%     4/   5/   0/   0/   0/   0       0/ 2       -------I---    7%/  9%[9]   9%[ 3]   0.2/  1.5  127.0/  5.6 
2024/06/23 19:01:00  474.0  485.5   0.00/  0.00   0.00/  0.00   1814  NaN%  14.32/452.44   1.99/  0.29   33.6   1.1    2%  26%  39%   0%   0%     4/   5/   0/   0/   0/   0       0/ 2       ---V---I---    6%/ 10%[15] 11%[ 3]   0.2/  1.5  126.2/  6.4

Quando NW utilizza "fastcopy" per i cloni (ovvero ciò che accade per i cloni all'interno della stessa unità di storage), non dovrebbe essere visualizzato un carico di lettura. Qui è visibile perché il clone tra le unità di storage viene eseguito da NW tramite "filecopy" e, nel caso di questo esempio, non è tutto:

06/19 08:24:14.178358 [7fbbf6b4a390] ddboost-<nw-node1.example.com-52424>: JOB START IMAGE_READ ip=10.20.30.40 pid=1727382 cd=1 enc=off //NW-STORAGE-UNIT/MONTHLY-FS-DEV06/03/54/d2b98e7a-00000006-4f5a1067-665a1067-88e55000-e36c9c56

06/19 08:24:14.286608 [7facd6691b70] ddboost-<nw-node2.example.com-58788>: JOB START IMAGE_WRITE ip=10.20.30.40 pid=18392 cd=1 enc=off //NW-STORAGE-UNIT-CT/CLOUD-LONG-TERM02-DEV07/03/54/d2b98e7a-00000006-4f5a1067-665a1067-88e55000-e36c9c56

Qui è in corso un clone per l'SSID "d2b98e7a-00000006-4f5a1067-665a1067-88e55000-e36c9c56":

• Dal dispositivo "MONTHLY-FS-DEV06" nell'unità di storage originale denominata (NW-STORAGE-UNIT), il processo READ viene eseguito dal nodo NW denominato "nw-node1.example.com"
• Al dispositivo denominato "CLOUD-LONG-TERM02-DEV07" nella nuova unità di storage (NW-STORAGE-UNIT-CT), il processo WRITE viene eseguito sul nodo NW denominato "nw-node2.example.com"

Questa lettura conteneva dati provenienti dal DD nella rete, che attraversavano la rete del cliente da un nodo NW a un altro. Veniva utilizzato lo stesso flusso di byte per scrivere un nuovo file nello stesso DD di origine.

8. In un caso come nell'esempio (configurazione NW con una singola unità di storage e DD CT con l'unità cloud già piena), la configurazione corretta per NW è quella di creare una nuova unità cloud in DD.
In questo modo si evita di creare una seconda unità di storage in DD e di creare una nuova policy di cloud tiering in NW su un dispositivo diverso all'interno della stessa unità di storage esistente.
Quindi, la configurazione dello spostamento dei dati DD viene modificata per le successive esecuzioni di spostamento dei dati per avere la nuova unità cloud come destinazione.
La configurazione finale lato DD è simile alla seguente:

Cloud Unit List
---------------
Name           Profile              Status   Reason
------------   ------------------   ------   -------------------------------
CLOUD-UNIT     CLOUD-UNIT_profile   Active   Cloud unit connected and ready.  <<-- existing Cloud Unit
CLOUD-UNIT02   CLOUD-UNIT_profile   Active   Cloud unit connected and ready.  <<-- new Cloud Unit
------------   ------------------   ------   -------------------------------

Cloud Data-Movement Configuration
---------------------------------
Mtree                             Target(Tier/Unit Name)   Policy        Value
-------------------------------   ----------------------   -----------   -------
/data/col1/NW-STORAGE-UNIT        Cloud/CLOUD-UNIT02       app-managed   enabled  <<-- target cloud unit changed from "CLOUD-UNIT"
-------------------------------   ----------------------   -----------   -------

Quando vengono eseguite le policy di tiering NW esistenti e nuove, vengono creati cloni dei save set da inviare al cloud e i cloni vengono creati all'interno della stessa unità di storage in un dispositivo diverso (sottodirectory) e i file all'interno dei "dispositivi cloud" NW vengono contrassegnati per lo spostamento dei dati.

Quando lo spostamento dei dati DD viene eseguito come da pianificazione, vengono elencati tutti i file nella singola unità di storage NW, determinando se sono idonei (contrassegnati) per lo spostamento dei dati e non in alcuna unità cloud. Indipendentemente dalla sottodirectory (dispositivo)in cui si trovano all'interno di DD, tutti i file contrassegnati per lo spostamento dei dati non in un'unità cloud vengono comunque inviati singolarmente all'unità cloud di destinazione (CLOUD-UNIT02) a loro volta.

Dopo che un file è stato copiato nel cloud e verificato da DD, viene "installato", il che significa che DD modifica il file CH (Content Handle) per indicare la posizione fisica del file (per consentirgli di individuare i dati per il file nell'Active Tier o in una delle due unità cloud).

Quando in un secondo momento l'applicazione di backup tenta di leggere o richiamare i file nel cloud, la posizione fisica dei dati del file è trasparente per NW, in quanto DD sa esattamente da dove leggere i dati. Questo processo viene disaccoppiato dalla configurazione di spostamento dei dati DD corrente.


9. Infine, il cliente nell'esempio non ha inizialmente seguito la documentazione NW (ha riscontrato gravi problemi di prestazioni del clone NW) e si è ritrovato con alcuni SSID archiviati tre volte (una volta nell'Active Tier e una volta in ciascuna delle due unità cloud), il che non è un problema (anche se potrebbe essere uno spreco di spazio a seconda delle policy di retention configurate):

--------------------------------                                                                                  ----------------------      -----         ---------------------------
File Name                                                                                                         Location(Unit Name)         Size          Placement Time
--------------------------------                                                                                  ----------------------      -----         ---------------------------
/data/col1/NW-STORAGE-UNIT/MONTHLY-FS-DEV05/85/72/365bdbce-00000006-3157c1bc-6657c1bc-32035000-e36c9c56                        Active         1.15 TiB      Thu May 30 04:00:59 2024
/data/col1/NW-STORAGE-UNIT/CLOUD-LONG-TERM-DEV04 /85/72/365bdbce-00000006-3157c1bc-6657c1bc-32035000-e36c9c56              CLOUD-UNIT         1.15 TiB      Sat Jun  1 11:13:33 2024
/data/col1/NW-STORAGE-UNIT-CT/CLOUD-LONG-TERM02-DEV07/85/72/365bdbce-00000006-3157c1bc-6657c1bc-32035000-e36c9c56        CLOUD-UNIT02         1.15 TiB      Tue Jun 18 10:49:10 2024

Esistono tre copie dello stesso file, due delle quali sono state spostate nel cloud, una per ciascuna unità cloud.
Quando NW tenta di leggere da uno qualsiasi di essi, DD ne conosce la posizione ed esegue il possibile in modo trasparente per restituire i dati a NW senza alcuna differenza rispetto a una situazione con solo un Active Tier.
Infine, NW fa scadere ed elimina ciascuno dei tre file.

Esistono tre copie dello stesso file, due delle quali sono state spostate nel cloud, una per ciascuna unità cloud.
Quando NW tenta di leggere da uno qualsiasi di essi, DD ne conosce la posizione ed esegue il possibile in modo trasparente per restituire i dati a NW senza alcuna differenza rispetto a una situazione con solo un Active Tier.
Infine, NW fa scadere (ed elimina) ciascuno dei tre file.