Data Domain. Работа NetWorker с Data Domain и Cloud Tier

В NetWorker (NW) предусмотрена встроенная поддержка Data Domain Cloud Tier (DD CT). Это означает, что администратор NW может задавать политики для распределения по уровням в облаке: NW отмечает отдельные образы резервных копий, чтобы в дальнейшем при перемещении данных DD в облако эти файлы отправлялись в настроенное облачное устройство.

Прежде всего нужно подчеркнуть следующий важный факт: NW не перемещает и не копирует (не клонирует) данные в облако. NW создает копии (клоны) SSID для отправки в облако, но клоны находятся (изначально) на активном уровне DD. Только после активации настроенного расписания перемещения данных DD SSID, отмеченный для облака (распределенный в облако), отправляется в облачное хранилище.

Весь процесс от резервного копирования до обеспечения доступности SSID в облаке выполняется следующим образом.

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, в результате чего в 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) должна находиться под управлением приложения, а не «возрастного порога», поскольку файлы для перемещения в облако определяются (отмечаются) NW, а не выбираются по возрасту самих файлов.

4. В силу особенностей своей работы NW для облачного уровня DD не «отмечает» файлы, которые необходимо переместить в облако, в их исходном расположении. Во время настройки NW для хранения на облачном уровне заказчик должен создать в том же устройстве хранения другое устройство, где файлы, которые необходимо отправить в облако, сначала будут клонированы NW. Например, в отчете о расположении файлов DD идентификатор 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 был скопирован (клонирован) из исходного устройства в облачное устройство NW с именем «CLOUD-LONG-TERM-DEV04».
• В конечном счете было выполнено перемещение данных DD, и клон исходной резервной копии был перемещен с активного уровня в облачное устройство. Этот процесс был завершен для файла в «Sat Jun 1 11:13:33 2024».
• На момент сбора указанной выше информации о расположении файла на активном и облачном уровнях DD существует копия одного и того же длинного идентификатора SSID.
• NW принимает решение о завершении срока хранения и удалении отдельных копий в установленный срок. Теоретически срок хранения копии на активном уровне истекает раньше, чем срок хранения копии в облаке, где она должна храниться дольше (иначе отправлять этот образ резервной копии в облако было бы бессмысленно).

5. В соответствии с документацией NetWorker устройство облачного уровня в мастере NW следует создать в том же устройстве хранения, что и файлы на активном уровне. Создание облачного устройства в другом устройстве хранения может привести к тому, что клоны будут создаваться методом, отличным от «fastcopy». В результате клонирование сильно замедлится. Соответствующий раздел документации 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 в два отдельных облачных устройства не предусмотрены. В конфигурации перемещения данных DD к одному исходному устройству MTree нельзя применить несколько политик. Это может представлять проблему в таких ситуациях, как, например, максимальное заполнение первого облачного устройства (пример см. ниже).

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. При попытке преодолеть указанное выше ограничение заказчик может создать новое устройство хранения 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, но и в том, что клонирование будет выполняться медленно. Кроме того, в SSP (system show performance) 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

Когда NW использует для клонов метод «fastcopy» (что происходит в случае клонов в одном устройстве хранения), нагрузка чтения не должна быть видна. Здесь она видна, потому что NW выполняет клонирование между устройствами хранения с помощью «filecopy», а в этом примере ситуация даже хуже:

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

• Из устройства «MONTHLY-FS-DEV06» в исходном устройстве хранения с именем «NW-STORAGE-UNIT» задание ЧТЕНИЯ выполняется с узла NW с именем «nw-node1.example.com».
• В адрес устройства с именем «CLOUD-LONG-TERM02-DEV07» в новом устройстве хранения («NW-STORAGE-UNIT-CT») выполняется задание ЗАПИСИ на узел NW с именем «nw-node2.example.com».

В результате чтения данные, поступающие из DD в сеть, передаются по сети заказчика с одного узла NW на другой, который затем использует тот же поток байтов для записи нового файла в тот же DD, откуда этот поток был получен.

8. В нашем примере (конфигурация NW с одним устройством хранения и облачным уровнем DD с уже заполненным облачным устройством) корректная конфигурация 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 завершит срок хранения каждого из трех файлов (и удалит их).