Nodo metro: Después de la actualización a 8.0.x, el respaldo de metadatos deja de funcionar
Summary: En este artículo, se aborda el problema después de la actualización al código 8.0.x, el respaldo de metadatos deja de funcionar. En este artículo, se proporcionan los pasos de solución alternativa para restaurar la funcionalidad de respaldo de metadatos. ...
Symptoms
Hardware afectado de Dell:
Nodo metro mn114
Nodo metro mn215
Nodo metro: local/metro
Software de Dell afectado:
SO del nodo metro 8.0.0.0.0.267
SO del nodo metro 8.0.0.1.0.21
SO del nodo metro 8.0.1.0.0.220
Actividades de cambio afectadas:
Después de la actualización al SO 8.0.x del nodo metro
Problema:
-
El comando
ndu pre-checkinforma el siguiente error para cada clúster en una configuración de nodo metro:Ejemplo para el clúster 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
Ejemplo para el clúster-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
-
Cuando se ordena el comando
ll ~system-volumescomando se ejecuta, la fecha del volumen de respaldo de metadatos refleja una fecha anterior.En el siguiente ejemplo, el respaldo de metadatos deja de funcionar en ambos clústeres en un entorno 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
Indicios:
- El respaldo de metadatos deja de funcionar en ambos clústeres en un entorno metro.
- El respaldo de metadatos deja de funcionar en cualquiera de los clústeres en un entorno metro
- El respaldo de metadatos deja de funcionar en un clúster local
Cause
Durante el respaldo de metadatos diario programado, el servicio "daily_metadata_backup.service" ocasionalmente se bloquea en el estado de activación en director-1-1-A, director-2-1-A o ambos.
Resolution
Resolución permanente:
El equipo de ingeniería del nodo metro está investigando este problema. Cuando haya una corrección disponible, este artículo se actualizará.
Solución alternativa:
-
Para comprobar el estado del servicio "daily_metadata_backup.service", en el símbolo del sistema del shell, ejecute el comando,
sudo systemctl status daily_metadata_backup.serviceen un nodo A, por ejemplo, director-1-1-A o director-2-1-A. Compruebe y confirme que el atributo "Active: activating (start)" esté presente y que se esté ejecutando durante más de un minuto. Si es así, esto significa que este servicio se bloqueó en ese nodo A en particular.En el siguiente ejemplo, se muestra que director-1-1-A y director-2-1-A tienen el atributo "daily_metadata_backup.service" del servicio "Active: activando (inicio)" presente y han estado en ejecución durante más de un minuto, lo que significa que este servicio se bloqueó en estos nodos, como se muestra a continuación.
Clúster 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>Clúster 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> -
A continuación, para comprobar el estado del servicio "daily_metadata_backup.timer" en el nodo A, por ejemplo, director-1-1-A, director-2-1-A, ejecute el comando
sudo systemctl status daily_metadata_backup.timery confirme que el atributo "Trigger:" se muestre como "n/a". Si es así, esto significa que este servicio se bloqueó en ese nodo A en particular.En el siguiente ejemplo, se muestra que director-1-1-A y director-2-1-A tienen el atributo "daily_metadata_backup.timer" del servicio "Trigger:" que se muestra como "n/a", lo que significa que este servicio se bloqueó en estos nodos.
Clúster 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:~>
Clúster 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:~>
-
Una vez que se confirme qué nodo, o posiblemente ambos nodos, tienen los dos servicios mencionados bloqueados, detenga los servicios "daily_metadata_backup.service" y "daily_metadata_backup.timer" y, a continuación, inicie el servicio para que "daily_metadata_backup.timer" resuelva esta situación y para que el respaldo de metadatos comience a funcionar.
NOTA: No utilice la opción del comando "restart".En el siguiente ejemplo, dado que ambos nodos A se ven afectados, los servicios se detienen y se inician de la siguiente manera:
sudo systemctl stop daily_metadata_backup.service
sudo systemctl stop daily_metadata_backup.timer
sudo systemctl start daily_metadata_backup.timer
-
Ejecute el siguiente comando para comprobar el estado y confirmar que ya no está atascado de la siguiente manera:
En los siguientes ejemplos, se muestra la ejecución del comando de estado para "daily_metadata_backup.service" a fin de comprobar si la línea "Active: inactive (dead)", que significa que el servicio realmente no se está ejecutando, cuando se espera el próximo ciclo de respaldo de los metadatos 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:~>En el siguiente ejemplo, se muestra que el servicio "daily_metadata_backup.timer" debe ser "active(waiting)" y "Trigger" debe estar establecido en el día actual o actual, lo que significa que el servicio ahora está funcionando según lo esperado:
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:~> -
Espere y monitoree hasta que se complete el próximo respaldo de metadatos mediante la ejecución de
ll ~system-volumespara confirmar que el problema se resolvió y que el respaldo de metadatos se realiza correctamente, como se indica a continuación.Ejemplo:
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