Data Domain: Cómo funciona NetWorker con Data Domain y Cloud Tier
Summary: NetWorker (NW) tiene soporte incorporado para Data Domain Cloud Tier (DD CT). Este artículo aborda conceptos erróneos y discrepancias terminológicas.
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.
Symptoms
NetWorker (NW) tiene soporte incorporado para Data Domain Cloud Tier (DD CT). Esto significa que el administrador de NW puede establecer políticas para la organización en niveles en la nube: NW marca imágenes de respaldo individuales para que, más adelante, se ejecute la transferencia de datos de DD a la nube y se envíen esos archivos a la unidad de nube configurada.
Lo primero para destacar es que NW no transfiere ni copia (clona) datos a la nube. Crea copias (clones) de SSID para enviar a la nube, pero los clones se encuentran (inicialmente) en el nivel activo de DD. Recién después de iniciar el programa de transferencia de datos data-movement de DD configurado, el SSID marcado para la nube (en niveles) debe enviarse al almacenamiento de nube.
Todo el proceso, desde el respaldo hasta el momento en que el SSID queda disponible en la nube, funciona de forma muy similar a la siguiente:
Lo primero para destacar es que NW no transfiere ni copia (clona) datos a la nube. Crea copias (clones) de SSID para enviar a la nube, pero los clones se encuentran (inicialmente) en el nivel activo de DD. Recién después de iniciar el programa de transferencia de datos data-movement de DD configurado, el SSID marcado para la nube (en niveles) debe enviarse al almacenamiento de nube.
Todo el proceso, desde el respaldo hasta el momento en que el SSID queda disponible en la nube, funciona de forma muy similar a la siguiente:
Cause
1. NW está configurado para almacenar respaldos en un DD (la ingesta siempre se produce en el nivel activo de DD). Por lo general, utiliza una sola unidad de almacenamiento para ese fin:
2. Dentro de NetWorker, cada política de respaldo se almacena en lo que NetWorker denomina un "dispositivo". Un dispositivo es solo un subdirectorio debajo de la raíz de la unidad de almacenamiento, por ejemplo:
3. NW finalmente se configura para DD CT y da como resultado una configuración de transferencia de datos app-managed data-movement en DD, como se muestra a continuación:
4. En la forma en que NW funciona para DD CT, no se "marcan" los archivos que se moverán a la nube en su ubicación original: Cuando el cliente establece NW para la organización de la nube en niveles, debe crear otro dispositivo dentro de la misma unidad de almacenamiento, en el cual NW primero clonará los archivos que se enviarán a la nube. Por ejemplo, un SSID cualquiera configurado para almacenarse en DD CT aparecerá como dos archivos independientes (pero idénticos) en un informe de ubicación de archivo de DD:
5. La documentación de NetWorker solicita que el dispositivo en el nivel de nube en el asistente de NW se cree en la misma unidad de almacenamiento que los archivos en el nivel activo. La creación del dispositivo de nube en una unidad de almacenamiento diferente puede provocar que los clones no se realicen con "fastcopy", lo que deriva en tiempos de clonación mucho más lentos. Esta es la sección correspondiente en la documentación de 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
6. Una de las implicaciones de la declaración anterior de la documentación de NW es que, en una configuración de NetWorker o Data Domain con nivel de nube, por lo general, todos los datos se almacenan en la misma unidad de almacenamiento dentro de DD y no hay ninguna manera soportada de enviar imágenes de respaldo de NW a dos unidades de nube independientes. La configuración de transferencia de datos de DD no puede tener más de una política para el mismo MTree de origen, lo que puede plantear un problema en situaciones como, por ejemplo, que se llegue al máximo de la capacidad de la primera unidad de nube (consulte un ejemplo a continuación):
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. Dentro de NetWorker, cada política de respaldo se almacena en lo que NetWorker denomina un "dispositivo". Un dispositivo es solo un subdirectorio debajo de la raíz de la unidad de almacenamiento, por ejemplo:
/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-e36c9c56En este caso, las políticas o dispositivos serían "DAILY-DB-DEV01", "DAILY-DB-DEV02", "MONTHLY-DB-DEV01" y "MONTHLY-FS-DEV06"
3. NW finalmente se configura para DD CT y da como resultado una configuración de transferencia de datos app-managed data-movement en DD, como se muestra a continuación:
Cloud Data-Movement Configuration --------------------------------- Mtree Target(Tier/Unit Name) Policy Value ------------------------------- ---------------------- ----------- ------- /data/col1/NW-STORAGE-UNIT Cloud/CLOUD-UNIT app-managed enabled ------------------------------- ---------------------- ----------- -------La configuración data-movement de DD a la nube requiere un MTree de origen (la unidad de almacenamiento de NW), una unidad de nube de destino (CLOUD-UNIT) y una política, que para NetWorker (y Avamar) debe ser "app-managed" y no "age-threshold", ya que NW determinará (marcará) los archivos que se moverán a la nube; no se escogerán por su antigüedad.
4. En la forma en que NW funciona para DD CT, no se "marcan" los archivos que se moverán a la nube en su ubicación original: Cuando el cliente establece NW para la organización de la nube en niveles, debe crear otro dispositivo dentro de la misma unidad de almacenamiento, en el cual NW primero clonará los archivos que se enviarán a la nube. Por ejemplo, un SSID cualquiera configurado para almacenarse en DD CT aparecerá como dos archivos independientes (pero idénticos) en un informe de ubicación de archivo de 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 2024La información anterior muestra lo siguiente:
- La imagen de respaldo con el SSID largo "365bdbce-00000006-3157c1bc-6657c1bc-32035000-e36c9c56" se escribió en el nivel activo de DD y se escribió por última vez en "Thu May 30 04:00:59 2024" con el nombre de dispositivo "MONTHLY-FS-DEV05".
- Existe una política de organización en niveles (con un dispositivo de destino) denominada "CLOUD-LONG-TERM-DEV04/"
- Cuando se ejecutó la política de organización en niveles (suele ocurrir no bien se completa el respaldo), se realizó una copia (clon) del SSID del dispositivo original al dispositivo de nube de NW denominada "CLOUD-LONG-TERM-DEV04".
- Finalmente, se ejecutó data-movement de DD y el clon del respaldo original se transfirió de Active a la unidad de nube. El proceso se completó para el archivo antes de "Sat Jun 1 11:13:33 2024".
- En el momento en que se recopila la información de ubicación del archivo anterior, existe una copia del mismo SSID largo tanto en los niveles Active como de la nube de DD.
- Dependerá de NW hacer caducar las copias individuales y eliminarlas cuando llegue el momento. En teoría, la copia en el nivel activo vencerá antes que la de la nube, que se conservará por más tiempo (o no tendría sentido enviar esa imagen de respaldo a la nube en primer lugar).
5. La documentación de NetWorker solicita que el dispositivo en el nivel de nube en el asistente de NW se cree en la misma unidad de almacenamiento que los archivos en el nivel activo. La creación del dispositivo de nube en una unidad de almacenamiento diferente puede provocar que los clones no se realicen con "fastcopy", lo que deriva en tiempos de clonación mucho más lentos. Esta es la sección correspondiente en la documentación de 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 de las implicaciones de la declaración anterior de la documentación de NW es que, en una configuración de NetWorker o Data Domain con nivel de nube, por lo general, todos los datos se almacenan en la misma unidad de almacenamiento dentro de DD y no hay ninguna manera soportada de enviar imágenes de respaldo de NW a dos unidades de nube independientes. La configuración de transferencia de datos de DD no puede tener más de una política para el mismo MTree de origen, lo que puede plantear un problema en situaciones como, por ejemplo, que se llegue al máximo de la capacidad de la primera unidad de nube (consulte un ejemplo a continuación):
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. Al intentar superar la limitación anterior, un cliente puede crear una nueva unidad de almacenamiento de NetWorker para los próximos respaldos. O bien, puede realizar la clonación de la unidad de almacenamiento actual a un dispositivo en la nueva y, posteriormente, agregar una segunda política de transferencia de datos de DD de la nueva unidad de almacenamiento a la nueva unidad de nube. Esto concluye con una configuración como la siguiente:
Además del requisito de la documentación de NW, el problema es que la clonación será lenta. Es posible que también vea algo similar a esto en DD SSP (rendimiento lento del sistema):
Cuando NW utiliza "fastcopy" para los clones (que es lo que sucede con los clones dentro de la misma unidad de almacenamiento), no deberíamos ver una carga de lectura. Aquí lo vemos porque NW realiza la clonación en todas las unidades de almacenamiento a través de "filecopy" y, en el caso de este ejemplo, fue incluso peor que eso:
8. En un caso como el del ejemplo (configuración de NW con una sola unidad de almacenamiento y DD CT con la unidad de nube ya llena), la configuración correcta para NW es crear una nueva unidad de nube en DD.
Esto evita la creación de una segunda unidad de almacenamiento en DD y crea en NW una nueva política de organización de la nube en niveles en un dispositivo diferente dentro de la misma unidad de almacenamiento existente.
A continuación, se cambia la configuración de transferencia de datos de DD para las próximas ejecuciones de data-movement para tener la nueva unidad de nube como destino.
La configuración paralela final del DD sería la siguiente:
Cuando la transferencia de datos de DD se ejecute según lo programado, se enumerarán todos los archivos en la única unidad de almacenamiento de NW y se determinará si son elegibles (marcados) para la transferencia de datos sin estar aún en ninguna unidad de nube. Independientemente del subdirectorio (dispositivo) en el que se encuentren dentro de DD, todos los archivos marcados para la transferencia de datos que aún no están en una unidad de nube se enviarán individualmente a la unidad de nube de destino (CLOUD-UNIT02).
Después de que DD copia correctamente un archivo a la nube y lo verifica, el archivo se "instala", lo que significa que DD cambia el CH (Content Handle) del archivo para indicar la ubicación física del archivo (para permitirle localizar los datos del archivo en el nivel activo o en cualquiera de las dos unidades de nube).
Más adelante, cuando la aplicación de respaldo intenta leer o recuperar archivos en la nube, la ubicación física de los datos del archivo es transparente para NW, ya que DD sabe exactamente desde dónde leer los datos. Esto está desacoplado de la configuración de transferencia de datos actual de DD.
9. Por último, el cliente del ejemplo no siguió la documentación de NW al principio (experimentó graves problemas de rendimiento de clones de NW) y terminó almacenando SSID tres veces (una vez en el nivel activo y una vez en cada una de las dos unidades de nube), lo cual está perfectamente bien (aunque puede ser un desperdicio de espacio según las políticas de retención configuradas):
Hay tres copias del mismo archivo, dos de las cuales se transfirieron a la nube, una a cada una de las unidades de nube.
Cuando NW intenta leer desde cualquiera de ellas, DD sabe dónde se encuentra cada una y, de manera transparente, hace lo necesario para devolver los datos a NW sin ninguna diferencia en comparación con solo un nivel activo.
NW finalmente hace caducar y elimina cada uno de los tres archivos.
Hay tres copias del mismo archivo, dos de las cuales se transfirieron a la nube, una a cada una de las unidades de nube.
Cuando NW intenta leer cualquiera de ellas, DD sabe exactamente dónde se encuentra cada una y, de manera transparente, hará lo necesario para entregar los datos a NW sin ninguna diferencia en comparación con solo un nivel activo.
NW eventualmente hará caducar (y eliminará) cada uno de los tres archivos.
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 ------------------------------- ---------------------- ----------- -------
Además del requisito de la documentación de NW, el problema es que la clonación será lenta. Es posible que también vea algo similar a esto en DD SSP (rendimiento lento del sistema):
-----------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
Cuando NW utiliza "fastcopy" para los clones (que es lo que sucede con los clones dentro de la misma unidad de almacenamiento), no deberíamos ver una carga de lectura. Aquí lo vemos porque NW realiza la clonación en todas las unidades de almacenamiento a través de "filecopy" y, en el caso de este ejemplo, fue incluso peor que eso:
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-e36c9c56Aquí se está produciendo un clon para el SSID "d2b98e7a-00000006-4f5a1067-665a1067-88e55000-e36c9c56":
- Desde el dispositivo "MONTHLY-FS-DEV06" en la unidad de almacenamiento original denominada "NW-STORAGE-UNIT", la tarea READ se realiza desde el nodo de NW denominado "nw-node1.example.com"
- Hacia el dispositivo denominado "CLOUD-LONG-TERM02-DEV07" en la nueva unidad de almacenamiento (NW-STORAGE-UNIT-CT), la tarea WRITE se realiza en el nodo de NW denominado "nw-node2.example.com"
8. En un caso como el del ejemplo (configuración de NW con una sola unidad de almacenamiento y DD CT con la unidad de nube ya llena), la configuración correcta para NW es crear una nueva unidad de nube en DD.
Esto evita la creación de una segunda unidad de almacenamiento en DD y crea en NW una nueva política de organización de la nube en niveles en un dispositivo diferente dentro de la misma unidad de almacenamiento existente.
A continuación, se cambia la configuración de transferencia de datos de DD para las próximas ejecuciones de data-movement para tener la nueva unidad de nube como destino.
La configuración paralela final del DD sería la siguiente:
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" ------------------------------- ---------------------- ----------- -------Cuando se ejecuten las políticas de organización en niveles de NW existentes y nuevas, se crearán clones de los savesets que se enviarán a la nube; los clones se realizarán dentro de la misma unidad de almacenamiento en un dispositivo diferente (subdirectorio) y los archivos dentro de los "cloud devices" de NW se marcarán para la transferencia de datos.
Cuando la transferencia de datos de DD se ejecute según lo programado, se enumerarán todos los archivos en la única unidad de almacenamiento de NW y se determinará si son elegibles (marcados) para la transferencia de datos sin estar aún en ninguna unidad de nube. Independientemente del subdirectorio (dispositivo) en el que se encuentren dentro de DD, todos los archivos marcados para la transferencia de datos que aún no están en una unidad de nube se enviarán individualmente a la unidad de nube de destino (CLOUD-UNIT02).
Después de que DD copia correctamente un archivo a la nube y lo verifica, el archivo se "instala", lo que significa que DD cambia el CH (Content Handle) del archivo para indicar la ubicación física del archivo (para permitirle localizar los datos del archivo en el nivel activo o en cualquiera de las dos unidades de nube).
Más adelante, cuando la aplicación de respaldo intenta leer o recuperar archivos en la nube, la ubicación física de los datos del archivo es transparente para NW, ya que DD sabe exactamente desde dónde leer los datos. Esto está desacoplado de la configuración de transferencia de datos actual de DD.
9. Por último, el cliente del ejemplo no siguió la documentación de NW al principio (experimentó graves problemas de rendimiento de clones de NW) y terminó almacenando SSID tres veces (una vez en el nivel activo y una vez en cada una de las dos unidades de nube), lo cual está perfectamente bien (aunque puede ser un desperdicio de espacio según las políticas de retención 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
Hay tres copias del mismo archivo, dos de las cuales se transfirieron a la nube, una a cada una de las unidades de nube.
Cuando NW intenta leer desde cualquiera de ellas, DD sabe dónde se encuentra cada una y, de manera transparente, hace lo necesario para devolver los datos a NW sin ninguna diferencia en comparación con solo un nivel activo.
NW finalmente hace caducar y elimina cada uno de los tres archivos.
Hay tres copias del mismo archivo, dos de las cuales se transfirieron a la nube, una a cada una de las unidades de nube.
Cuando NW intenta leer cualquiera de ellas, DD sabe exactamente dónde se encuentra cada una y, de manera transparente, hará lo necesario para entregar los datos a NW sin ninguna diferencia en comparación con solo un nivel activo.
NW eventualmente hará caducar (y eliminará) cada uno de los tres archivos.
Affected Products
Data DomainArticle Properties
Article Number: 000226881
Article Type: Solution
Last Modified: 19 Aug 2024
Version: 2
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.