Домен даних: Як NetWorker працює з Data Domain і Cloud Tier

NetWorker (NW) має вбудовану підтримку Data Domain Cloud Tier (DD CT). Це означає, що адміністратор NW може встановлювати політики для багаторівневого переходу в хмару: NW позначає окремі резервні зображення, щоб потім переміщення даних DD у хмару запускалося та надсилало ці файли до налаштованого хмарного блоку.

Першим важливим фактом, на який слід звернути увагу, є те, що NW не переміщує і не копіює (не клонує) дані в хмару. Він створює копії (клони) SSID для відправки в хмару, але клони знаходяться (спочатку) на рівні DD Active. Лише після того, як запрацює налаштований графік переміщення даних DD, SSID, позначений для (багаторівневої) хмари, має бути відправлений у хмарне сховище.

Весь процес від створення резервної копії до моменту, коли цей SSID доступний у хмарі, працює дуже схоже на наведене нижче:

1. NW налаштований на зберігання резервних копій на DD (ingest завжди відбувається на рівень DD Active). Як правило, він використовує один блок зберігання для того, щоб:

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 storage unit), цільовий хмарний блок (CLOUD-UNIT) і політика, яка для NetWorker (і Avamar) повинна бути "app-managed", а не "вік-threshold", так як які файли переміщати в хмару визначаються (позначаються) NW, а не вибираються за віком самих файлів.

4. Принцип роботи NW для DD CT не «маркує» файли, які потрібно перемістити в хмару, на їх початковому місці: Коли клієнт встановлює NW для хмарного рівня, він повинен створити інший пристрій у тому самому сховищі, де файли, які будуть надіслані в хмару, спочатку будуть клоновані NW. Наприклад, даний SSID, налаштований на зберігання в DD CT, відображатиметься як два окремі (але ідентичні) файли у звіті про розташування файлу 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 Active і востаннє записано в "Чт травня 30 04:00:59 2024", під назвою пристрою "MONTHLY-FS-DEV05"
• Існує політика багаторівневого розподілу (з цільовим пристроєм) під назвою "CLOUD-LONG-TERM-DEV04/"
• Коли політика багаторівневості була запущена (це, швидше за все, станеться вже після завершення резервного копіювання) копія (клон) SSID була зроблена з оригінального пристрою на хмарний пристрій NW під назвою «CLOUD-LONG-TERM-DEV04»
• Зрештою було запущено рух даних DD, і клон оригінальної резервної копії було переміщено з Active до хмарного блоку, процес для файлу завершився "Сб 1 червня 11:13:33 2024"
• На момент збору наведеної вище інформації про розташування файлу існувала копія одного і того ж довгого SSID як на рівні Active, так і на рівні Cloud DD
• Термін дії NW закінчиться і ви видалите окремі копії, коли настане термін, теоретично, копія в активному рівні буде закінчена раніше, ніж копія в хмарі, яка повинна зберігатися довше (або в іншому випадку було б безглуздо відправляти цей резервний образ у хмару в першу чергу)

5. Документація NetWorker просить, щоб пристрій рівня Cloud у майстрі 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, проблема полягає в тому, що клонування буде повільним. Також, ви можете побачити щось подібне в 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 використовує "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) виконується завдання WRITE на вузол NW з іменем "nw-node2.example.com"

Це зчитування показало, що дані виходили з DD у мережу, переходячи через мережу клієнта від одного NW-вузла до іншого, який потім використовує той самий потік байтів для запису нового файлу в той самий DD, звідки вони прийшли спочатку.

8. У випадку, як у прикладі (конфігурація NW з одним блоком зберігання даних і DD CT з уже заповненим хмарним блоком), правильна конфігурація для NW полягає в створенні нового хмарного блоку в DD.
Це дозволяє уникнути створення другого блоку зберігання даних у ДД і створити нову політику хмарного рівня в NW на інший пристрій у межах того ж існуючого сховища.
Потім змініть конфігурацію переміщення даних 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 сховищі будуть перераховані та визначені, чи дозволені (позначені) для переміщення даних, і ще не в жодному хмарному блоці. Незалежно від того, в якій піддиректорії (пристрої) вони знаходяться в межах ДД, всі відмічені файли для переміщення даних не в хмарному блоці поки будуть окремо відправлені на цільовий хмарний блок (CLOUD-UNIT02) по черзі.

Після успішного копіювання файлу в хмару та перевірки за допомогою DD файл стає «встановленим», що означає, що DD змінює файловий CH (Content Handle) для позначення фізичного розташування файлу (щоб дозволити йому знайти дані для файлу на активному рівні або в будь-якому з двох хмарних блоків).

Коли пізніше програма резервного копіювання намагається прочитати або викликати файли в хмарі, фізичне розташування даних файлу є прозорим для 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.