Data Domain: Como o NetWorker funciona com o Data Domain e o Cloud Tier

O NetWorker (NW) tem suporte integrado para Data Domain Cloud Tier (DD CT). Isso significa que o administrador do NW pode definir políticas para armazenamento em camadas na nuvem: O NW marca imagens de backup individuais para que, posteriormente, a movimentação de dados do DD para a nuvem seja executada e envie esses arquivos para a unidade de nuvem configurada.

O primeiro fato importante a destacar é que o NW não move nem copia (clona) dados para a nuvem. Ele cria cópias (clones) de SSIDs a serem enviadas para a nuvem, mas os clones ficam (inicialmente) no nível ativo do DD. Somente depois que a programação configurada de movimentação de dados do DD entrar em vigor é que o SSID marcado para (em camadas para) nuvem deve ser enviado para o armazenamento em nuvem.

Todo o processo, desde fazer um backup até o ponto em que esse SSID está disponível na nuvem, funciona muito parecido com o abaixo:

1. O NW está configurado para armazenar backups em um DD (a ingestão sempre ocorre no nível ativo do DD). Normalmente, ele usa uma única unidade de armazenamento para isso:

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. No NetWorker, cada política de backup é armazenada no que o NetWorker chama de "dispositivo". Um dispositivo é apenas um subdiretório abaixo da raiz da unidade de armazenamento, por exemplo:

/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

Aqui, as políticas ou dispositivos seriam "DAILY-DB-DEV01", "DAILY-DB-DEV02", "MONTHLY-DB-DEV01" e "MONTHLY-FS-DEV06".

3. Por fim, o NW é configurado para o DD CT e resulta em uma configuração de movimentação de dados gerenciada pelo aplicativo de movimentação de dados:

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

A configuração de movimentação de dados do DD para a nuvem leva um MTree de origem (a unidade de armazenamento do NW), uma unidade de nuvem de destino (CLOUD-UNIT) e uma política, que para o NetWorker (e Avamar) deve ser "app-managed", em vez de "age threshold", pois os arquivos a serem movidos para a nuvem são determinados (marcados) pelo NW, e não escolhidos pela idade dos arquivos.

4. A maneira como o NW funciona para o DD CT não "marca" os arquivos a serem movidos para a nuvem em seu local original: Quando o cliente configura o NW para armazenamento em nuvem em camadas, ele deve criar outro dispositivo dentro da mesma unidade de armazenamento, onde os arquivos a serem enviados para a nuvem serão clonados pelo NW primeiro. Por exemplo, um determinado SSID configurado para ser armazenado no DD CT será exibido como dois arquivos separados (mas idênticos) em um relatório de localização do arquivo 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

As informações acima mostram que:

• A imagem de backup com SSID longo "365bdbce-00000006-3157c1bc-6657c1bc-32035000-e36c9c56" foi gravada no nível ativo do DD e gravada pela última vez em "Thu May 30 04:00:59 2024", sob o nome do dispositivo "MONTHLY-FS-DEV05"
• Existe uma política de armazenamento em camadas (com um dispositivo de destino) chamada "CLOUD-LONG-TERM-DEV04/"
• Quando a política de armazenamento em camadas foi executada (isso provavelmente acontece assim que o backup é concluído), uma cópia (clone) do SSID foi feita do dispositivo original para o dispositivo de nuvem NW chamado "CLOUD-LONG-TERM-DEV04"
• A movimentação de dados do DD acabou sendo executada e o clone do backup original foi movido de ativo para a unidade de nuvem, processo concluído para o arquivo em "Sat Jun 1 11:13:33 2024"
• No momento em que as informações de localização do arquivo acima foram coletadas, existia uma cópia do mesmo SSID longo nos níveis ativo e nuvem DD
• Caberá ao NW expirar e excluir as cópias individuais quando, em teoria, a cópia no nível ativo expirará mais cedo do que a da nuvem, o que deve ser retido por mais tempo (ou então seria inútil enviar essa imagem de backup para a nuvem em primeiro lugar)

5. A documentação do NetWorker solicita que o dispositivo do nível da nuvem no assistente do NW seja criado na mesma unidade de armazenamento que os arquivos no nível ativo. A criação do dispositivo de nuvem em uma unidade de armazenamento diferente pode fazer com que os clones sejam feitos usando algo diferente de "fastcopy", o que resulta em tempos de clonagem muito mais lentos. Esta é a seção aplicável na documentação do 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. Uma das implicações da declaração acima da documentação do NW é que, em uma configuração do NetWorker/Data Domain com nível de nuvem, geralmente todos os dados estão sendo armazenados na mesma unidade de armazenamento dentro do DD, e não há uma maneira compatível de enviar imagens de backup do NW para duas unidades de nuvem separadas. A configuração de movimentação de dados do DD não pode ter mais de uma política para o mesmo Mtree de origem, o que pode representar um problema em situações como, por exemplo, a capacidade da primeira unidade de nuvem a ser maximizada (veja abaixo um exemplo):

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. Ao tentar superar a limitação acima, um cliente pode criar uma nova unidade de armazenamento do NetWorker para os próximos backups. Ou eles podem fazer os clones da unidade de armazenamento existente para um dispositivo na nova e, posteriormente, adicionar uma segunda política de movimentação de dados do DD da nova unidade de armazenamento para a nova unidade de nuvem. Isso acaba com uma configuração como a abaixo:

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
-------------------------------   ----------------------   -----------   -------

Além da exigência da documentação do NW, o problema é que a clonagem será lenta. Além disso, você pode ver algo assim no SSP (desempenho de exibição do sistema) do DD:

                     -----------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 o NW usa "fastcopy" para os clones (que é o que acontece para clones dentro da mesma unidade de armazenamento), não devemos ver uma carga de leitura. Aqui vemos isso porque o clone entre as unidades de armazenamento é feito pelo NW por meio de "filecopy", e no caso deste exemplo, foi ainda pior do que isso:

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

Aqui, um clone para o SSID "d2b98e7a-00000006-4f5a1067-665a1067-88e55000-e36c9c56" está acontecendo:

• A partir do dispositivo "MONTHLY-FS-DEV06" na unidade de armazenamento original chamada (NW-STORAGE-UNIT), o trabalho de LEITURA sendo feito a partir do nó do NW chamado "nw-node1.example.com"
• Para o dispositivo chamado "CLOUD-LONG-TERM02-DEV07" na nova unidade de armazenamento (NW-STORAGE-UNIT-CT), o trabalho de GRAVAÇÃO sendo feito no nó do NW chamado "nw-node2.example.com"

Nessa leitura, os dados saíam do DD para a rede, atravessando a rede do cliente de um nó do NW para outro, que, em seguida, usa o mesmo fluxo de bytes para gravar um novo arquivo no mesmo DD de onde eles vieram em primeiro lugar.

8. Em um caso como no exemplo (configuração de NW com uma única unidade de armazenamento e DD CT com a unidade de nuvem já estando cheia), a configuração correta para o NW é criar uma nova unidade de nuvem no DD.
Isso evita a criação de uma segunda unidade de armazenamento no DD e cria uma nova política de armazenamento em nuvem em camadas no NW para um dispositivo diferente dentro da mesma unidade de armazenamento existente.
Em seguida, alterar a configuração de movimentação de dados do DD para as próximas execuções de movimentação de dados para ter a nova unidade de nuvem como destino.
A configuração final do lado do DD ficando assim:

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 as políticas de armazenamento em camadas do NW existentes e novas forem executadas, elas criarão clones dos savesets a serem enviados para a nuvem, os clones serão feitos na mesma unidade de armazenamento em um dispositivo diferente (subdiretório), e os arquivos dentro dos "dispositivos em nuvem" do NW serão marcados para movimentação de dados.

Quando a movimentação de dados do DD é executada conforme agendado, todos os arquivos na única unidade de armazenamento do NW serão listados e determinados se são elegíveis (marcados) para movimentação de dados e ainda não estão em nenhuma unidade de nuvem. Não importa o subdiretório (dispositivo), eles estão dentro do DD, todos os arquivos marcados para movimentação de dados que não estão em uma unidade de nuvem, mas serão enviados individualmente para a unidade de nuvem de destino (CLOUD-UNIT02), por sua vez.

Depois que um arquivo é copiado com sucesso para a nuvem e verificado pelo DD, o arquivo é "instalado", o que significa que o DD altera o CH (Content Handle, identificador de conteúdo) do arquivo para indicar a localização física do arquivo (para permitir que ele localize os dados para o arquivo no nível ativo ou em qualquer uma das duas unidades de nuvem).

Quando, posteriormente, o aplicativo de backup tentar ler ou recuperar arquivos na nuvem, o local físico dos dados do arquivo será transparente para o NW, pois o DD sabe exatamente de onde ler os dados. Isso é dissociado da configuração atual de movimentação de dados do DD.


9. Por fim, o cliente do exemplo não seguiu a documentação do NW no início (teve sérios problemas de desempenho do clone do NW) e acabou tendo algum SSID armazenado três vezes (uma vez no ativo e outra em cada uma das duas unidades de nuvem), o que é perfeitamente correto (embora possa ser um desperdício de espaço, dependendo das políticas de retenção configuradas):

--------------------------------                                                                                  ----------------------      -----         ---------------------------
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

Há três cópias do mesmo arquivo, duas das quais foram movidas para a nuvem, uma para cada uma das unidades de nuvem.
Quando o NW tenta ler qualquer um deles, o DD sabe onde cada um está e faz o que for necessário para entregar os dados de volta ao NW sem nenhuma diferença em comparação com uma situação com apenas um nível ativo.
Cada um dos três arquivos é eventualmente expirado e excluído pelo NW.

Há três cópias do mesmo arquivo, duas das quais foram movidas para a nuvem, uma para cada uma das unidades de nuvem.
Quando o NW tenta ler qualquer um deles, o DD sabe exatamente onde cada um deles está e faz o que for necessário para entregar os dados de volta ao NW sem nenhuma diferença em comparação com uma situação com apenas um nível ativo.
Cada um dos três arquivos será eventualmente expirado (e excluído) pelo NW.