Metro-Node: Nach dem Upgrade auf 8.0.x funktioniert das Metadatenbackup nicht mehr

Summary: In diesem Artikel wird das Problem behandelt, bei dem das Metadatenbackup nach dem Upgrade auf 8.0.x-Code nicht mehr betriebsbereit ist. Dieser Artikel enthält die Workaround-Schritte zur Wiederherstellung der Metadatenbackupfunktion. ...

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.
Check out other resources

Symptoms

Betroffene Hardware von Dell:
Metro Node mn114
Metro Node mn215
Metro Node Local/Metro

Betroffene Software von Dell:
Metro-Node-Betriebssystem 8.0.0.0.0.267
, Metro-Node-BS 8.0.0.1.0.21
, Metro-Node-Betriebssystem 8.0.1.0.0.220

Betroffene Änderungsaktivitäten:
Nach dem Upgrade auf Metro Node OS 8.0.x

Problem:

  1. Das Skript ndu pre-check meldet den folgenden Fehler für jedes Cluster in einer Metro Node-Konfiguration:

    Beispiel für 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

    Beispiel für 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. Wenn der Befehl ll ~system-volumes ausgeführt wird, wird das Datum des Metadatenbackup-Volumes einem früheren Datum entsprechen.

    Im folgenden Beispiel funktioniert das Metadatenbackup auf beiden Clustern in einer Metro-Umgebung nicht mehr:

    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

Symptome:

  • Das Metadatenbackup funktioniert nicht mehr auf beiden Clustern in einer Metro-Umgebung.
  • Das Metadatenbackup funktioniert auf keinem der Cluster in einer Metro-Umgebung mehr
  • Das Metadatenbackup funktioniert in einem lokalen Cluster nicht mehr

 

Cause

Während des geplanten täglichen Metadatenbackups bleibt der Service "daily_metadata_backup.service" gelegentlich im Aktivierungsstatus auf director-1-1-A, director-2-1-A oder beiden hängen.

 

Resolution

Dauerhafte Lösung:

Metro Node Engineering untersucht das Problem. Dieser Artikel wird aktualisiert, sobald eine Korrektur verfügbar ist.

Problemumgehung:

  1. Um den Status des Dienstes "daily_metadata_backup.service" an der Shell-Eingabeaufforderung zu überprüfen, führen Sie den folgenden Befehl aus: sudo systemctl status daily_metadata_backup.service auf einem A-Node, z. B. director-1-1-A oder director-2-1-A. Prüfen und bestätigen Sie, dass das Attribut "Aktiv: Aktivierung (Start)" vorhanden ist und länger als eine Minute ausgeführt wird. Wenn ja, bedeutet dies, dass dieser Service auf diesem bestimmten A-Node hängen bleibt.

    Das folgende Beispiel zeigt, dass sowohl director-1-1-A als auch director-2-1-A den Service "daily_metadata_backup.service"-Attribut "Active: activating (start)" aufweisen und länger als eine Minute ausgeführt werden, was bedeutet, dass dieser Service auf diesen Nodes hängen bleibt, wie unten gezeigt.

    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. Um den Status des Service "daily_metadata_backup.timer" auf A-Node zu überprüfen, z. B. director-1-1-A, director-2-1-A, führen Sie den folgenden Befehl aus: sudo systemctl status daily_metadata_backup.timer und vergewissern Sie sich, dass das Attribut "Trigger:" als "n/a" angezeigt wird. Wenn ja, bedeutet dies, dass dieser Service auf diesem bestimmten A-Node hängen bleibt.

    Das folgende Beispiel zeigt, dass sowohl director-1-1-A als auch director-2-1-A das Serviceattribut "daily_metadata_backup.timer" "Trigger:" als "n/a" anzeigen, was bedeutet, dass dieser Service auf diesen Nodes hängen bleibt.

    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. Sobald bestätigt wurde, bei welchem Node oder möglicherweise bei beiden Nodes die beiden genannten Services hängen geblieben sind, beenden Sie die Services "daily_metadata_backup.service" und "daily_metadata_backup.timer" und starten Sie dann den Service für "daily_metadata_backup.timer", um dieses Problem zu beheben und das Metadatenbackup wieder auszuführen.

    HINWEIS: Verwenden Sie nicht die Option für den Neustartbefehl.

    Da im folgenden Beispiel beide A-Nodes betroffen sind, werden die Services wie folgt beendet und gestartet:

    sudo systemctl stop daily_metadata_backup.service
    sudo systemctl stop daily_metadata_backup.timer
    sudo systemctl start daily_metadata_backup.timer

  4. Führen Sie den folgenden Befehl aus, um den Status zu überprüfen und zu bestätigen, dass er nicht mehr hängen bleibt:

    Die folgenden Beispiele zeigen die Ausführung des Statusbefehls für "daily_metadata_backup.service", um zu überprüfen, ob die Zeile "Active: inactive (dead)" bedeutet, dass der Service tatsächlich nicht ausgeführt wird, was beim Warten auf den nächsten Backupzyklus der Metadaten "inactive (dead)" ist:

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

    Das folgende Beispiel zeigt, dass der Service "daily_metadata_backup.timer" "active(waiting)" sein sollte und "Trigger" auf den aktuellen oder aktuellen Tag eingestellt werden sollte, was bedeutet, dass der Service jetzt wie erwartet funktioniert:

    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. Warten Sie und überwachen Sie, bis das nächste Metadatenbackup abgeschlossen ist, indem Sie Folgendes ausführen: ll ~system-volumes , um zu bestätigen, dass das Problem behoben wurde und das Metadatenbackup erfolgreich wie folgt durchgeführt wird.

    Beispiel:

    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.