Data Domain：NetWorker 如何与 Data Domain 和 Cloud Tier 协同工作

Summary: NetWorker (NW) 内置了对 Data Domain Cloud Tier (DD CT) 的支持。本文将讨论某些误解和术语冲突。

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Check out other resources

Symptoms

NetWorker (NW) 内置了对 Data Domain Cloud Tier (DD CT) 的支持。这意味着 NW 管理员可以设置分层到云的策略：NW 会标记各个备份映像，以便稍后在指向云的 DD 数据移动运行时，将这些文件发送到配置的云单元。

要强调的第一个重要事实是，NW 不会将数据移动或复制（克隆）到云。它会创建要发送到云的 SSID 的拷贝（克隆），但克隆（最初）位于 DD 活动层中。只有在配置的 DD 数据移动计划生效后，才会将标记用于（分层到）云的 SSID 发送到云存储。

从备份到 SSID 在云中可用的整个过程与下面非常相似：

Cause

1.NW 已配置为将备份存储到 DD（接收始终发生在 DD 活动层）。通常，它使用单个存储单元来实现该操作：

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.在 NetWorker 中，每个备份策略都存储在 NetWorker 所称的“设备”下。设备只是存储单元根目录下的子目录，例如：

/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

在这里，策略或设备是“DAILY-DB-DEV01”、“DAILY-DB-DEV02”、“MONTHLY-DB-DEV01”和“MONTHLY-FS-DEV06”。

3.NW 最终配置用于 DD CT，并在 DD 中生成由应用程序管理的数据移动配置，如下所示：

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

指向云的 DD 数据移动配置需要源 MTree（NW 存储单元）、目标云单元 (CLOUD-UNIT) 和策略，对于 NetWorker（和 Avamar）来说，策略必须是“app-managed”，而不是“age-threshold”，因为哪些文件要移动到云是由 NW 决定（标记）的，而不是根据文件本身的年限来选择的。

4.按照 NW 为 DD CT 工作的方式，它不会在文件的原始位置上“标记”要移动到云的文件：当客户为云分层设置 NW 时，必须在同一存储单元内创建另一个设备，NW 会首先将要发送到云的文件克隆到该设备中。例如，配置为存储在 DD CT 中的给定 SSID 将在 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

以上信息表明：

具有长 SSID“365bdbce-00000006-3157c1bc-6657c1bc-32035000-e36c9c56”的备份映像已写入 DD 活动层，上次写入时间为“Thu May 30 04:00:59 2024”，写入的设备名称为“MONTHLY-FS-DEV05”
存在目标设备名为“CLOUD-LONG-TERM-DEV04/”的分层策略
运行分层策略时（这可能早在备份完成时就发生了），会将 SSID 从原始设备复制（克隆）到名为“CLOUD-LONG-TERM-DEV04”的 NW 云设备中
最终运行 DD 数据移动，并将原始备份的克隆从活动层移至云单元，文件的流程在“Sat Jun 1 11:13:33 2024”之前完成
在收集上述文件位置信息时，活动层和云 DD 层中都存在相同长 SSID 的拷贝
当各个拷贝到期时，将由 NW 决定是否使它们过期并将其删除，从理论上讲，活动层中的拷贝将比云中的拷贝更早过期，云中的拷贝将保留更长时间（否则，起初将备份映像发送到云就毫无意义了）

5.NetWorker 文档要求在 NW 向导中将云层设备创建在活动层中文件所在的同一存储单元内。在其他存储单元上创建云设备可能会导致使用非“快速拷贝”功能完成克隆，从而导致克隆速度变慢。这是 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.NW 文档中上述陈述的含义之一是，在具有云层的 NetWorker/Data Domain 设置中，所有数据通常都存储在 DD 内的同一存储单元中，并且没有支持的方法可将 NW 备份映像发送到两个单独的云单元。对于同一个源 Mtree，DD 数据移动配置不能有多个策略，在诸如第一个云单元的容量将用尽之类的情况下，这可能会造成问题（请参阅下面的内容以获得示例）：

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

Resolution

7.尝试克服上述限制时，客户可以为即将进行的备份创建新的 NetWorker 存储单元。或者，他们可以从现有存储单元克隆到新存储单元中的设备，然后将第二个 DD 数据移动策略从新存储单元添加到新的云单元。这最终会得到如下配置：

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

除了 NW 文档中的要求之外，问题在于克隆速度会很慢。此外，您可能会在 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

当 NW 使用“快速拷贝”功能进行克隆时（这是同一存储单元中的克隆发生的情况），我们应该不会看到读取负载。在这里，我们可以看到它，原因是跨存储单元的克隆是由 NW 通过“文件拷贝”功能完成的，在此示例中，情况甚至比这更糟糕：

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

此处发生了 SSID 为“d2b98e7a-00000006-4f5a1067-665a1067-88e55000-e36c9c56”的克隆：

克隆起始设备：名为“NW-STORAGE-UNIT”的原始存储单元中的设备“MONTHLY-FS-DEV06”— 正在从名为“nw-node1.example.com”的 NW 节点执行读取作业
克隆目标设备：新存储单元“NW-STORAGE-UNIT-CT”中名为“CLOUD-LONG-TERM02-DEV07”的设备 — 正在对名为“nw-node2.example.com”的 NW 节点执行写入作业

此读取将数据从 DD 传入网络，遍历客户网络，从一个 NW 节点到达另一个 NW 节点，然后使用相同的字节流将新文件写入起初数据来自的同一个 DD。

8.像示例中的情况（NW 配置有单个存储单元，DD CT 的云单元已填满），NW 的正确配置是在 DD 中创建新的云单元。
这样可避免在 DD 中创建第二个存储单元，并在 NW 中为同一个现有存储单元内的其他设备创建新的云分层策略。
然后，为即将进行的数据移动运行更改 DD 数据移动配置，以将新的云单元作为目标。
最终 DD 端配置如下所示：

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

当现有的和新的 NW 分层策略运行时，它们将创建要发送到云的存储集的克隆，在同一存储单元中的其他设备（子目录）下进行克隆，并且将 NW“云设备”中的文件标记用于数据移动。

当 DD 数据移动按计划运行时，将列出单个 NW 存储单元中的所有文件，并确定它们是否符合数据移动条件（已标记），以及是否不在任何云单元中。无论它们在 DD 的哪个子目录（设备）中，所有尚未在云单元中的已标记用于数据移动的文件都将会依次单独地发送到目标云单元 (CLOUD-UNIT02)。

文件成功复制到云并经过 DD 验证后，该文件将会被“安装”，这意味着 DD 会更改文件 CH（内容句柄），以指示文件的物理位置（从而使它可以在活动层或两个云单元中的任何一个中找到文件的数据）。

以后，当备份应用程序尝试读取或重新调用云中的文件时，该文件数据的物理位置对 NW 来说是透明的，因为 DD 清楚地知道从何处读取该数据。这与当前 DD 数据移动配置脱钩。

9.最后，示例中的客户在开始时没有遵循 NW 文档进行操作（遇到严重的 NW 克隆性能问题），结果将一些 SSID 存储了三次（在活动层中存储一次，在两个云单元中各存储一次），尽管根据配置的保留策略，可能会浪费空间，但这是完全没有问题的：

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

同一个文件有三个拷贝，其中两个拷贝已移至云，每个云单元各有一个拷贝。
当 NW 尝试从其中任何拷贝读取数据时，DD 知道每个拷贝的位置，并根据需要透明地将数据传送回 NW，与只有一个活动层的情况相比没有任何区别。
NW 最终会使这三个文件中的每一个都过期并将其删除。

同一个文件有三个拷贝，其中两个拷贝已移至云，每个云单元各有一个拷贝。
当 NW 尝试从其中任何拷贝读取数据时，DD 清楚地知道每个拷贝的位置，并根据需要透明地将数据传送回 NW，与只有一个活动层的情况相比没有任何区别。
NW 最终会使这三个文件中的每一个都过期（并将其删除）。

Affected Products

Data Domain

Article Number: 000226881

Article Type: Solution

Last Modified: 19 Aug 2024

Version: 2

Check if your device is covered by Support Services.

Data Domain：NetWorker 如何与 Data Domain 和 Cloud Tier 协同工作

Summary: NetWorker (NW) 内置了对 Data Domain Cloud Tier (DD CT) 的支持。本文将讨论某些误解和术语冲突。

Symptoms

Cause

Resolution

Affected Products

Article Properties

Find answers to your questions from other Dell users

Support Services

Article Properties

Find answers to your questions from other Dell users

Support Services

Data Domain：NetWorker 如何与 Data Domain 和 Cloud Tier 协同工作

Summary: NetWorker (NW) 内置了对 Data Domain Cloud Tier (DD CT) 的支持。本文将讨论某些误解和术语冲突。

Detailed Article

Symptoms

Cause

Resolution

Affected Products

Symptoms

Cause

Resolution

Affected Products

Article Properties

Find answers to your questions from other Dell users

Support Services

Article Properties

Find answers to your questions from other Dell users

Support Services