Вузол метрополітену: Після оновлення до 8.0.x резервна копія метаданих перестає функціонувати

Summary: У цій статті розглядається проблема, коли після оновлення коду до 8.0.x резервна копія метаданих стає непрацездатною. У цій статті наведено кроки з обходу для відновлення функції резервного копіювання метаданих. ...

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

Апаратне забезпечення, що вплинуло на Dell:
Вузол метрополітену mn114
Вузол метрополітену mn215
Вузол метрополітену-Місцевий/Метрополітен

Програмне забезпечення, що вплинуло на Dell:
Вузол метрополітену ОС 8.0.0.0.267
Вузол метрополітену ОС 8.0.0.1.0.21
Вузол метрополітену ОС 8.0.1.0.220

Зміни в діяльності вплинули:
Оновлення до вузла метро OS 8.0.x

Випуск:

Об'єкт ndu pre-check команда повідомляє про наведену нижче помилку для кожного кластера в конфігурації вузла метро:

Приклад для Кластера-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

Приклад для Кластера-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

Коли команда ll ~system-volumes виконується команда, дата обсягу резервного копіювання метаданих відображає попередню дату.

У наведеному нижче прикладі резервна копія метаданих припиняє роботу на обох кластерах у середовищі 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

Симптоми:

Резервна копія метаданих припиняє роботу на обох кластерах у середовищі Metro.
Резервна копія метаданих припиняє роботу на будь-якому з кластерів у середовищі Metro
Резервна копія метаданих перестає працювати в локальному кластері

Cause

Під час запланованого щоденного резервного копіювання метаданих сервіс "daily_metadata_backup.service" періодично зависає в стані активації на директорі-1-1-А, директорі-2-1-А або на обох.

Resolution

Постійна постанова:

Компанія Metro Node Engineering досліджує це питання. Коли з'явиться виправлення, цю статтю буде оновлено.

Спосіб вирішення:

Щоб перевірити стан служби "daily_metadata_backup.service", у Shell Prompt виконайте команду, sudo systemctl status daily_metadata_backup.service на А-вузлі, наприклад, директор-1-1-А або директор-2-1-А. Перевірте та переконайтеся, що атрибут "Активний: активація (пуск)" присутній і він працює довше хвилини. Якщо так, це означає, що цей сервіс застряг на цьому конкретному А-вузлі.

Наведений нижче приклад показує, що director-1-1-A та director-2-1-A мають атрибут служби "daily_metadata_backup.service" "Активний: активація (запуск)" і працюють довше хвилини, що означає, що ця служба застрягла на цих вузлах, як показано нижче.

Кластер-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>

Кластер-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>

Далі перевірити статус служби "daily_metadata_backup.timer" на А-вузлі наприклад, директор-1-1-А, директор-2-1-А, виконати команду sudo systemctl status daily_metadata_backup.timer і переконайтеся, що атрибут "Trigger:" відображається як "n/a". Якщо так, це означає, що цей сервіс застряг на цьому конкретному А-вузлі.

Наведений нижче приклад показує, що director-1-1-A та director-2-1-A мають атрибут служби "daily_metadata_backup.timer" "Trigger:", який відображається як "n/a", що означає, що ця служба застрягла на цих вузлах.

Кластер-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:~>

Кластер-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:~>

Як тільки буде підтверджено, у якого вузла або, можливо, обох вузлів зависли дві згадані служби, зупиніть служби «daily_metadata_backup.service» і «daily_metadata_backup.timer», а потім запустіть службу для «daily_metadata_backup.timer», щоб вирішити цю ситуацію і почати функціонувати резервна копія метаданих.

ПРИМІТКА. Не використовуйте опцію команди «перезавантажити».

У наведеному нижче прикладі, оскільки це стосується обох А-вузлів, послуги зупиняються та запускаються наступним чином:
```
sudo systemctl stop daily_metadata_backup.service
```
```
sudo systemctl stop daily_metadata_backup.timer
```
```
sudo systemctl start daily_metadata_backup.timer
```

Виконайте наведену нижче команду, щоб перевірити статус, щоб переконатися, що він більше не зависає, як описано нижче:

У наведених нижче прикладах показано запуск команди status для "daily_metadata_backup.service" для перевірки, чи є рядок "Active: 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:~>

Наведений нижче приклад показує, що служба "daily_metadata_backup.timer" має бути "активна (очікує)", а "Тригер" має бути встановлений на поточний або поточний день, що означає, що служба тепер працює так, як очікувалося:

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

Зачекайте та спостерігайте за завершенням наступного резервного копіювання метаданих, запустивши ll ~system-volumes , щоб підтвердити, що проблему вирішено, а резервне копіювання метаданих успішно виконується наступним чином.

Приклад:

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 Number: 000264665

Article Type: Solution

Last Modified: 22 Apr 2025

Version: 4

Check if your device is covered by Support Services.

Вузол метрополітену: Після оновлення до 8.0.x резервна копія метаданих перестає функціонувати

Symptoms

Cause

Resolution

Постійна постанова:

Affected Products

Products

Article Properties

Find answers to your questions from other Dell users

Support Services

Article Properties

Find answers to your questions from other Dell users

Support Services

Вузол метрополітену: Після оновлення до 8.0.x резервна копія метаданих перестає функціонувати

Detailed Article

Symptoms

Cause

Resolution

Affected Products

Symptoms

Cause

Resolution

Постійна постанова:

Affected Products

Products

Article Properties

Find answers to your questions from other Dell users

Support Services

Article Properties

Find answers to your questions from other Dell users

Support Services