Metro node : Après la mise à niveau vers la version 8.0.x, la sauvegarde des métadonnées cesse de fonctionner
Summary: Cet article traite du problème suivant : après la mise à niveau vers le code 8.0.x, la sauvegarde des métadonnées devient non opérationnelle. Cet article présente les étapes de contournement pour restaurer la fonctionnalité de sauvegarde des métadonnées. ...
Symptoms
Matériel Dell concerné :
Nœud Metro mn114
Nœud Metro mn215
Nœud Metro local/Metro
Logiciels Dell concernés :
OS Metro node 8.0.0.0.0.267
OS Metro node 8.0.0.1.0.21
OS Metro node 8.0.1.0.0.220
Modifier les activités concernées :
Après la mise à niveau vers le système d’exploitation Metro Node 8.0.x
Problème :
-
L’option
ndu pre-checksignale l’erreur ci-dessous pour chaque cluster dans une configuration Metro Node :Exemple pour le cluster-1 :
VPlexcli:/> ndu pre-check Warning: During the NDU process, multiple directors will be offline for a portion of the time. This is non-disruptive but is dependent on a host-based multipathing solution being installed, configured, and operating on all connected hosts. ================================================================================ Performing NDU pre-checks ================================================================================ Verify NDU is not in progress.. OK Verify that the directors have been running continuously for 15 days.. OK Verify director communication status.. OK . . . Verify meta-volume backup configuration.. ERROR . . . ================================================================================ Errors (x errors found) ================================================================================ cluster-1 Metadata backups are NOT created according to schedule Last backup: Mon Aug 19 00:00:00 UTC 20xx Current time: Fri Dec 13 03:41:33 UTC 20xx There has been no metadata backup for 116 day(s) Run 'metadatabackup local' on cluster-1
Exemple pour le cluster-2 :
VPlexcli:/> ndu pre-check Warning: During the NDU process, multiple directors will be offline for a portion of the time. This is non-disruptive but is dependent on a host-based multipathing solution being installed, configured, and operating on all connected hosts. ================================================================================ Performing NDU pre-checks ================================================================================ Verify NDU is not in progress.. OK Verify that the directors have been running continuously for 15 days.. OK Verify director communication status.. OK . . . Verify meta-volume backup configuration.. ERROR . . . ================================================================================ Errors (x errors found) ================================================================================ cluster-2 Metadata backups are NOT created according to schedule Last backup: Sat Mar 16 01:30:00 UTC 20xx Current time: Fri Dec 13 03:41:33 UTC 20xx There has been no metadata backup for 272 day(s) Run 'metadatabackup local' on cluster-2
-
Lorsque la commande
ll ~system-volumesest exécutée, la date du volume de sauvegarde des métadonnées reflète une date précédente.Dans l’exemple ci-dessous, la sauvegarde des métadonnées cesse de fonctionner sur les deux clusters d’un environnement Metro :
VPlexcli:/> ll ~system-volumes /clusters/cluster-1/system-volumes: Name Volume Type Operational Health Active Ready Geometry Component Block Block Capacity Slots --------------------------------------- -------------- Status State ------ ----- -------- Count Count Size -------- ----- --------------------------------------- -------------- ----------- ------ ------ ----- -------- --------- -------- ----- -------- ----- meta_C1_xxxxxx meta-volume ok ok true true raid-1 2 20971264 4K 80G 64000 meta_C1_xxxxxxx_backup_20xx-11-21_01-30 meta-volume ok ok false true raid-1 1 20971264 4K 80G 64000 \------------/ date and time the last backup was run /clusters/cluster-2/system-volumes: Name Volume Type Operational Health Active Ready Geometry Component Block Block Capacity Slots --------------------------------------- -------------- Status State ------ ----- -------- Count Count Size -------- ----- --------------------------------------- -------------- ----------- ------ ------ ----- -------- --------- -------- ----- -------- ----- meta_C2_xxxxxx meta-volume ok ok true true raid-1 2 20971264 4K 80G 64000 meta_C2_xxxxxxx_backup_20xx-11-20_12-43 meta-volume ok ok false true raid-1 1 20971264 4K 80G 64000 \------------/ date and time the last backup was run
Symptômes :
- La sauvegarde des métadonnées cesse de fonctionner sur les deux clusters dans un environnement Metro.
- La sauvegarde de métadonnées cesse de fonctionner sur l’un ou l’autre des clusters dans un environnement Metro
- La sauvegarde de métadonnées cesse de fonctionner dans un cluster local
Cause
Lors de la sauvegarde quotidienne planifiée des métadonnées, le service « daily_metadata_backup.service » est parfois bloqué à l’état d’activation sur director-1-1-A, director-2-1-A ou les deux.
Resolution
Solution définitive :
L’équipe d’ingénierie de Metro node enquête actuellement sur ce problème. Lorsqu’un correctif sera disponible, cet article sera mis à jour.
Solution de contournement :
-
Pour vérifier l’état du service « daily_metadata_backup.service », à l’invite du shell, exécutez la commande suivante :
sudo systemctl status daily_metadata_backup.servicesur un nœud A, par exemple, director-1-1-A ou director-2-1-A. Vérifiez que l’attribut « Active : activating (start) » est présent et qu’il fonctionne pendant plus d’une minute. Si oui, cela signifie que ce service est bloqué sur ce nœud A particulier.L’exemple ci-dessous montre que director-1-1-A et director-2-1-A ont tous deux l’attribut de service « daily_metadata_backup.service » « Active : activating (start) » et qu’il s’exécute depuis plus d’une minute, ce qui signifie que ce service est bloqué sur ces nœuds, comme indiqué ci-dessous.
Cluster-1 :
service@director-2-1-a:~> sudo systemctl status daily_metadata_backup.service ● daily_metadata_backup.service - metronode automated daily metadata backups Loaded: loaded (/etc/systemd/system/daily_metadata_backup.service; static) Active: activating (start) since Sat 2024-10-xx 01:30:18 UTC; 1 month 3 days ago <--------------------------- TriggeredBy: ● daily_metadata_backup.timer Main PID: 22553 (daily_metadata_) Tasks: 1 CGroup: /system.slice/daily_metadata_backup.service └─22553 /usr/bin/python3 /opt/dell/vplex/sbin/daily_metadata_backup.py Oct xx 01:30:18 director-2-1-a systemd[1]: Starting metronode automated daily metadata backups... . . . <truncated>Cluster-2 :
service@director-1-1-a:~> sudo systemctl status daily_metadata_backup.service ● daily_metadata_backup.service - metronode automated daily metadata backups Loaded: loaded (/etc/systemd/system/daily_metadata_backup.service; static) Active: activating (start) since Sat 2024-10-xx 01:30:18 UTC; 1 month 2 days ago <--------------------------- TriggeredBy: ● daily_metadata_backup.timer Main PID: 22553 (daily_metadata_) Tasks: 1 CGroup: /system.slice/daily_metadata_backup.service └─22553 /usr/bin/python3 /opt/dell/vplex/sbin/daily_metadata_backup.py Oct xx 01:30:18 director-1-1-a systemd[1]: Starting metronode automated daily metadata backups... . . . <truncated> -
Ensuite, pour vérifier l’état du service « daily_metadata_backup.timer » sur le nœud A, par exemple, director-1-1-A, director-2-1-A, exécutez la commande
sudo systemctl status daily_metadata_backup.timeret vérifiez que l’attribut « Trigger : » s’affiche comme « n/a ». Si oui, cela signifie que ce service est bloqué sur ce nœud A particulier.L’exemple ci-dessous montre que director-1-1-A et director-2-1-A ont tous deux l’attribut de service « daily_metadata_backup.timer » « Trigger : » affiché sous la forme « n/a », ce qui signifie que ce service est bloqué sur ces nœuds.
Cluster-1 :
service@director-1-1-a:~> sudo systemctl status daily_metadata_backup.timer ● daily_metadata_backup.timer - metronode automated daily metadata backups Loaded: loaded (/etc/systemd/system/daily_metadata_backup.timer; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/daily_metadata_backup.timer.d └─daily_backup.conf Active: active (running) since Wed 2024-11-20 12:46:10 UTC; 18h ago Trigger: n/a <<<<<<<<<<<< Triggers: ● daily_metadata_backup.service Nov 20 12:46:10 director-1-1-a systemd[1]: Started metronode automated daily metadata backups. service@director-1-1-a:~>
Cluster-2 :
service@director-2-1-a:~> sudo systemctl status daily_metadata_backup.timer ● daily_metadata_backup.timer - metronode automated daily metadata backups Loaded: loaded (/etc/systemd/system/daily_metadata_backup.timer; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/daily_metadata_backup.timer.d └─daily_backup.conf Active: active (running) since Wed 2024-11-xx 12:46:10 UTC; 18h ago Trigger: n/a >>>>>>>>>>>>>>>>>>>>>>> Triggers: ● daily_metadata_backup.service Nov xx 12:46:10 director-2-1-a systemd[1]: Started metronode automated daily metadata backups. service@director-2-1-a:~>
-
Une fois qu’il est confirmé quel nœud, ou éventuellement les deux nœuds, les deux services mentionnés sont bloqués, arrêtez les services « daily_metadata_backup.service » et « daily_metadata_backup.timer », puis démarrez le service pour « daily_metadata_backup.timer » afin de résoudre cette situation et pour que la sauvegarde des métadonnées recommence à fonctionner.
Remarque : N’utilisez pas l’option de commande « restart ».Dans l’exemple ci-dessous, étant donné que les deux nœuds A sont affectés, les services sont arrêtés et démarrés comme suit :
sudo systemctl stop daily_metadata_backup.service
sudo systemctl stop daily_metadata_backup.timer
sudo systemctl start daily_metadata_backup.timer
-
Exécutez la commande ci-dessous pour vérifier l’état afin de confirmer qu’il n’est plus bloqué comme suit :
Les exemples ci-dessous montrent l’exécution de la commande status pour « daily_metadata_backup.service » pour vérifier si la ligne « Active : inactive (dead) », cela signifie que le service n’est effectivement pas en cours d’exécution et qu’en attendant le prochain cycle de sauvegarde des métadonnées, elle est « inactive (dead) » :
service@director-2-1-a:~> sudo systemctl status daily_metadata_backup.service ● daily_metadata_backup.service - metronode automated daily metadata backups Loaded: loaded (/etc/systemd/system/daily_metadata_backup.service; static) Active: inactive (dead) since Fri 2024-11-22 21:07:41 UTC; 1min 49s ago >>>>>>>>>>>> TriggeredBy: ● daily_metadata_backup.timer Process: 9183 ExecStart=/opt/dell/vplex/sbin/daily_metadata_backup.py (code=exited, status=0/SUCCESS) Main PID: 9183 (code=exited, status=0/SUCCESS) Nov 22 21:07:36 director-2-1-a systemd[1]: Starting metronode automated daily metadata backups... Nov 22 21:07:41 director-2-1-a systemd[1]: daily_metadata_backup.service: Succeeded. Nov 22 21:07:41 director-2-1-a systemd[1]: Finished metronode automated daily metadata backups. service@director-2-1-a:~>service@director-1-1-a:~> sudo systemctl status daily_metadata_backup.service ● daily_metadata_backup.service - metronode automated daily metadata backups Loaded: loaded (/etc/systemd/system/daily_metadata_backup.service; static) Active: inactive (dead) since Fri 2024-11-22 21:07:41 UTC; 1min 49s ago >>>>>>>>>>>> TriggeredBy: ● daily_metadata_backup.timer Process: 9183 ExecStart=/opt/dell/vplex/sbin/daily_metadata_backup.py (code=exited, status=0/SUCCESS) Main PID: 9183 (code=exited, status=0/SUCCESS) Nov 22 21:07:36 director-1-1-a systemd[1]: Starting metronode automated daily metadata backups... Nov 22 21:07:41 director-1-1-a systemd[1]: daily_metadata_backup.service: Succeeded. Nov 22 21:07:41 director-1-1-a systemd[1]: Finished metronode automated daily metadata backups. service@director-2-1-a:~>L’exemple ci-dessous montre que le service « daily_metadata_backup.timer » doit être « active(waiting) » et que « Trigger » doit être défini sur current ou present day, ce qui signifie que le service fonctionne désormais comme prévu :
service@director-2-1-a:~> sudo systemctl status daily_metadata_backup.timer ● daily_metadata_backup.timer - metronode automated daily metadata backups Loaded: loaded (/etc/systemd/system/daily_metadata_backup.timer; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/daily_metadata_backup.timer.d └─daily_backup.conf Active: active (waiting) since Fri 2024-11-22 21:09:24 UTC; 14s ago >>>>>>>>>>> Trigger: Sat 2024-11-23 01:30:00 UTC; 4h 20min left >>>>>>>>>>> Triggers: ● daily_metadata_backup.service Nov 22 21:09:24 director-2-1-a systemd[1]: Started metronode automated daily metadata backups. service@director-2-1-a:~>service@director-1-1-a:~> sudo systemctl status daily_metadata_backup.timer ● daily_metadata_backup.timer - metronode automated daily metadata backups Loaded: loaded (/etc/systemd/system/daily_metadata_backup.timer; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/daily_metadata_backup.timer.d └─daily_backup.conf Active: active (waiting) since Fri 2024-11-22 21:09:24 UTC; 14s ago >>>>>>>>>>> Trigger: Sat 2024-11-23 01:30:00 UTC; 4h 20min left >>>>>>>>>>> Triggers: ● daily_metadata_backup.service Nov 22 21:09:24 director-1-1-a systemd[1]: Started metronode automated daily metadata backups. service@director-2-1-a:~> -
Attendez la fin de la prochaine sauvegarde de métadonnées et surveillez-la en exécutant
ll ~system-volumespour confirmer que le problème a été résolu et que la sauvegarde des métadonnées a bien été effectuée, procédez comme suit.Exemple :
VPlexcli:/> ll ~system-volumes /clusters/cluster-1/system-volumes: Name Volume Type Operational Health Active Ready Geometry Component Block Block Capacity Slots --------------------------------------- -------------- Status State ------ ----- -------- Count Count Size -------- ----- --------------------------------------- -------------- ----------- ------ ------ ----- -------- --------- -------- ----- -------- ----- meta_C1_xxxxxx meta-volume ok ok true true raid-1 2 20971264 4K 80G 64000 meta_C1_xxxxxxx_backup_2024-11-23_01-30 meta-volume ok ok false true raid-1 1 20971264 4K 80G 64000 meta_C1_4UQT429_backup_2024-11-24_01-30 meta-volume ok ok false true raid-1 1 20971264 4K 80G 64000 /clusters/cluster-2/system-volumes: Name Volume Type Operational Health Active Ready Geometry Component Block Block Capacity Slots --------------------------------------- -------------- Status State ------ ----- -------- Count Count Size -------- ----- --------------------------------------- -------------- ----------- ------ ------ ----- -------- --------- -------- ----- -------- ----- meta_C2_xxxxxx meta-volume ok ok true true raid-1 2 20971264 4K 80G 64000 meta_C2_xxxxxxx_backup_2024-11-23_12-43 meta-volume ok ok false true raid-1 1 20971264 4K 80G 64000 meta_C2_xxxxxxx_backup_2024-11-24_12-43 meta-volume ok ok false true raid-1 1 20971264 4K 80G 64000