Data Domain : fonctionnement de NetWorker avec Data Domain et Cloud Tier

NetWorker (NW) prend en charge Data Domain Cloud Tier (DD CT). En d’autres termes, l’administrateur NW peut définir des politiques de hiérarchisation vers le Cloud : NW marque les images de sauvegarde individuelles afin que, ultérieurement, le déplacement des données DD vers le Cloud s’exécute et envoie ces fichiers à l’unité de Cloud configurée.

Premier fait important à souligner : NW ne déplace ni ne copie (clone) aucune donnée vers le Cloud. Il crée des copies (clones) des SSID à envoyer vers le Cloud, mais les clones se trouvent (initialement) dans le niveau DD Active. Ce n’est qu’après le lancement de la planification du déplacement des données DD configurée que le SSID marqué pour (hiérarchisé vers) le Cloud doit être envoyé au stockage Cloud.

Le processus complet, depuis la sauvegarde jusqu’au moment où ce SSID devient accessible sur le Cloud, se déroule de la façon suivante :

1. NW est configuré pour stocker les sauvegardes sur un DD (l’ingestion a toujours lieu au niveau DD actif). En général, il utilise une seule unité de stockage pour cela :

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. Dans NetWorker, chaque règle de sauvegarde est stockée sous ce que NetWorker appelle un « appareil ». Un appareil est simplement un sous-répertoire situé sous la racine de l’unité de stockage, par exemple :

/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

Ici, les règles ou les appareils seraient « DAILY-DB-DEV01 », « DAILY-DB-DEV02 », « MONTHLY-DB-DEV01 » et « MONTHLY-FS-DEV06 ».

3. Finalement, NW est configuré pour DD CT et provoque un mouvement de données géré par l’application dans le DD, par exemple :

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

La configuration du déplacement des données DD vers le Cloud prend une structure MTree source (l’unité de stockage NW), une unité de Cloud cible (CLOUD-UNIT) et une politique qui, pour NetWorker (et Avamar), doit être définie sur « app-managed » et non sur « age-threshold », car les fichiers à déplacer vers le Cloud sont déterminés (marqués) par NW et non choisis selon l’ancienneté des fichiers proprement dits.

4. Pour DD CT, NW ne « marque » pas les fichiers à déplacer vers le Cloud à leur emplacement d’origine : Si le client définit NW pour la hiérarchisation sur le Cloud, il doit créer un autre appareil au sein de la même unité de stockage, où les fichiers à envoyer au Cloud seront tout d’abord clonés par NW. Par exemple, un SSID donné, configuré pour être stocké dans DD CT, s’affiche sous forme de deux fichiers distincts (mais identiques) dans un rapport d’emplacement de fichier 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

Les informations ci-dessus montrent que :

• L’image de sauvegarde avec le SSID long « 365bdbce-00000006-3157c1bc-6657c1bc-32035000-e36c9c56 » a été écrite sur le niveau DD actif et écrite pour la dernière fois le « Thu May 30 04:00:59 2024 », sous le nom d’appareil « MONTHLY-FS-DEV05 ».
• Il existe une politique de hiérarchisation (avec un appareil cible) nommée « CLOUD-LONG-TERM-DEV04/ »
• Lors de l’exécution de la politique de hiérarchisation (qui se produit probablement dès la fin de la sauvegarde), une copie (un clone) du SSID a été créée de l’appareil d’origine vers l’appareil Cloud NW nommé « CLOUD-LONG-TERM-DEV04 ».
• Le déplacement de données DD a finalement été exécuté et le clone de la sauvegarde d’origine a été déplacé du DD actif vers l’unité de Cloud, le processus du fichier terminant le « Sat Jun  1 11:13:33 2024 ».
• Au moment de la collecte des informations d’emplacement du fichier ci-dessus, il existe une copie du même SSID long dans le niveau actif et le niveau Cloud DD.
• NW peut expirer et supprimer les copies individuelles à la date prévue. En théorie, la copie du niveau actif expire plus tôt que celle du niveau Cloud, qui doit être conservée plus longtemps (sinon, il serait inutile d’envoyer cette image de sauvegarde vers le Cloud en premier lieu).

5. La documentation NetWorker exige que l’appareil de niveau Cloud dans l’Assistant NW soit créé sous la même unité de stockage que les fichiers du niveau actif. La création de l’appareil Cloud sur une autre unité de stockage peut entraîner l’exécution des clones à l’aide d’une opération autre que « fastcopy », ce qui ralentit considérablement les temps de clonage. Voici la section applicable dans la documentation 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. L’une des implications de l’instruction ci-dessus de la documentation NW est que, dans une configuration NetWorker/Data Domain Cloud Tier, toutes les données sont généralement stockées dans la même unité de stockage au sein du DD, et qu’il n’existe aucun moyen pris en charge d’envoyer des images de sauvegarde NW à deux unités de Cloud distinctes. La configuration du déplacement des données DD ne peut pas avoir plus d’une politique pour la même structure MTree source, ce qui peut poser problème, notamment dans des situations telles que l’épuisement de la capacité de la première unité de Cloud.

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. En essayant de surmonter la limitation ci-dessus, un client peut créer une nouvelle unité de stockage NetWorker pour les sauvegardes à venir. Il peut également créer les clones à partir de l’unité de stockage existante vers un appareil de la nouvelle unité, en ajoutant ultérieurement une deuxième politique de déplacement des données DD de la nouvelle unité de stockage vers la nouvelle unité de Cloud. Cela produit une configuration comme ci-dessous :

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

En plus des exigences de la documentation NW, le problème est que le clonage sera relativement lent. En outre, vous pouvez voir quelque chose comme ce qui suit dans DD SSP (affichage des performances système) :

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

Lorsque NW utilise « fastcopy » pour les clones (c’est-à-dire pour les clones au sein de la même unité de stockage), aucune charge de lecture ne devrait se produire. Or, cette charge de lecture se produit ici, car le clone sur les unités de stockage est effectué par NW via l’opération « filecopy » ; mais la situation est ici encore pire :

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

Dans cet exemple, un clone pour le SSID « d2b98e7a-00000006-4f5a1067-665a1067-88e55000-e36c9c56 » est généré :

• À partir de l’appareil « MONTHLY-FS-DEV06 » dans l’unité de stockage d’origine nommée (NW-STORAGE-UNIT), la tâche READ étant effectuée à partir du nœud NW nommé « nw-node1.example.com »
• Vers l’appareil nommé « CLOUD-LONG-TERM02-DEV07 » sous la nouvelle unité de stockage (NW-STORAGE-UNIT-CT), la tâche WRITE étant effectuée sur le nœud NW nommé « nw-node2.example.com »

Lors de cette opération de lecture, les données sont acheminées du DD vers le réseau, traversent le réseau du client d’un nœud NW à un autre, puis utilisent le même flux d’octets pour écrire un nouveau fichier dans le même DD d’où elles proviennent.

8. Comme dans l’exemple fourni (configuration NW avec une seule unité de stockage et DD CT avec l’unité de Cloud déjà saturée), la configuration correcte pour NW consiste à créer une nouvelle unité de Cloud dans DD.
Cela évite de créer une deuxième unité de stockage dans DD et de créer une nouvelle politique de hiérarchisation sur le Cloud dans NW sur un autre appareil au sein de la même unité de stockage existante.
Cela évite par ailleurs de réorganiser la configuration du mouvement des données DD pour que les futurs cycles de déplacement des données disposent de la nouvelle unité de Cloud comme cible.
La dernière configuration côté DD est la suivante :

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

Lors de l’exécution des politiques de hiérarchisation NW existantes et nouvelles, elles créent des clones des jeux de sauvegarde à envoyer au Cloud ; ces clones sont créés dans la même unité de stockage sous un appareil (sous-répertoire) différent, et les fichiers au sein des « appareils Cloud » NW sont marqués pour le déplacement des données.

Lors de l’exécution planifiée du déplacement des données DD, tous les fichiers de l’unité de stockage NW unique sont répertoriés, et il sera déterminé s’ils sont éligibles (marqués) pour le déplacement des données et s’ils ne se trouvent pas encore dans une unité de Cloud. Quel que soit le sous-répertoire (appareil) dans lequel ils se trouvent dans le DD, tous les fichiers marqués pour le déplacement des données qui ne sont pas dans une unité de Cloud sont envoyés un par un à l’unité de Cloud cible (CLOUD-UNIT02).

Une fois un fichier copié dans le Cloud et vérifié par le DD, il est « installé » ; autrement dit, le DD modifie le CH (descripteur de contenu) du fichier pour indiquer l’emplacement physique du fichier (afin de lui permettre de localiser les données du fichier dans le niveau actif ou dans l’une des deux unités de Cloud).

Plus tard, lorsque l’application de sauvegarde tente de lire ou de rappeler des fichiers dans le Cloud, NW connaît explicitement l’emplacement physique des données du fichier, car le DD sait exactement où lire les données. Elle est dissociée de la configuration de mouvement des données DD actuelle.


9. Dans l’exemple fourni, le client n’a pas suivi la documentation NW au début (il a rencontré de graves problèmes de performances de clone NW) et s’est retrouvé avec un SSID stocké à trois reprises (une fois dans le niveau actif et une fois dans chacune des deux unités de Cloud), ce qui est tout à fait correct (bien qu’il puisse s’agir d’une perte d’espace en fonction des politiques de rétention configurées) :

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

Il existe trois copies du même fichier, dont deux ont été déplacées vers le Cloud, une vers chacune des unités de Cloud.
Lorsque NW tente de lire l’une d’elles, DD sait où la localiser et exécute l’opération nécessaire, de manière transparente, pour renvoyer les données à NW, exactement comme dans le cas où seul un niveau actif est présent.
Les trois fichiers finissent par expirer et sont supprimés par NW.

Il existe trois copies du même fichier, dont deux ont été déplacées vers le Cloud, une vers chacune des unités de Cloud.
Lorsque NW tente de lire l’une d’elles, DD sait exactement où la localiser et exécute l’opération nécessaire, de manière transparente, pour renvoyer les données à NW, exactement comme dans le cas où seul un niveau actif est présent.
Les trois fichiers finissent par expirer et sont supprimés par NW.