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

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

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 :

  1. L’option ndu pre-check signale 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
  2. Lorsque la commande ll ~system-volumes est 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 :

  1. 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.service sur 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>
  2. 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.timer et 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:~>
  3. 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
  4. 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:~>
  5. Attendez la fin de la prochaine sauvegarde de métadonnées et surveillez-la en exécutant ll ~system-volumes pour 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

 

Affected Products

metro node

Products

metro node mn-114, metro node mn-215
Article Properties
Article Number: 000264665
Article Type: Solution
Last Modified: 22 Apr 2025
Version:  4
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.