PowerProtect DD: El sistema de archivos se deshabilita si hay una alerta ambiental crítica establecida en DD

PowerProtect DDOS incluye una protección que deshabilita el sistema de archivos DD (DDFS) si

1: La hora del sistema retrocede más de 60 segundos. Si se produce dicho cambio en la hora del sistema, y/O 

2: Si algún otro componente de hardware falla y el sistema establece una alerta ambiental crítica para el gabinete 1

Se lleva a cabo lo siguiente:   

• DDFS se deshabilita y no se reinicia automáticamente
• Se publica una alerta (EVT-ENVIRONMENT-00052), que es la siguiente:    

Event posted: p0-32 -EVT-ENVIRONMENT-00052: File system is disabled due to a critical condition.EVT-OBJ::Enclosure=1 EVT-INFO::Cause=System Time backward jumped
Event posted: p0-32 -EVT-ENVIRONMENT-00052: File system is disabled due to a critical condition.EVT-OBJ::Enclosure=1 EVT-INFO::Cause=System has Critical alert

Cuando se detecta este problema:    

• DDFS no se puede reiniciar manualmente (entra en modo de alarma durante el arranque)
• La restauración de la fecha y la hora (para revertir el salto hacia atrás) no permite que se inicie DDFS
• La resolución del problema de hardware no permite que se inicie DDFS

El sistema de archivos Data Domain no se puede habilitar hasta que solucionemos la condición crítica del entorno solo para proteger DD y otras aplicaciones integradas a DD

Este resguardo se implementó como un retroceso en el tiempo del sistema que puede afectar negativamente a ciertas aplicaciones de respaldo que almacenan datos en el DDR. Como resultado, está diseñado de modo que el administrador del DDR debe permitir el cambio en la hora del sistema antes de que se pueda volver a habilitar DDFS.

Nota: Una vez que se detecta este problema, DDFS no se puede habilitar porque se niega a iniciarse, por ejemplo:    

# filesys enable
Please wait...
01/01 20:32:10.217 (tid 0xxxxxxx): INFO: Event posted: m0-28 (2100001c:553648156): EVT-FILESYS-00008: Filesystem has encountered an error and is restarting.
**** There was a problem bringing up the filesystem. Status: The filesystem is aborting due to a problem.

Además, invertir el salto hacia atrás en la hora del sistema no permite volver a habilitar DDFS (el problema persiste).

Para habilitar DDFS, siga estos pasos. Si el DD afectado es el nodo activo en un par de DD HA, aplique estos pasos a ambos nodos antes de habilitar el sistema de archivos (FS).

Desde la UI de:

1. Asegúrese de que la fecha y la hora del sistema sean correctas. Si cambia la zona horaria, es posible que el DDR solicite un reinicio.
    Realice este reinicio inmediatamente para asegurarse de que todos los procesos reconozcan la nueva zona horaria. Vaya a Administration>Settings >FECHA Y HORA

• Si tiene NTP habilitado, deshabilítelo temporalmente para corregir el reloj. Vaya a MÁS TAREAS>Configurar ajustes de hora

• A continuación, vuelva a configurar los ajustes de hora para volver a habilitar NTP si es necesario

2. Borre la alerta de emergencia correspondiente al error "sistema de archivos deshabilitado debido a una condición crítica". Vaya a Alertas de > estado > ALERTAS ACTUALES

• Espere un minuto hasta que se borre la alerta y se actualice el estado del sistema. De lo contrario, es posible que el estado del sistema no se actualice completamente antes de que se inicie el proceso de DDFS, lo que podría causar un bloqueo y una alerta únicos de FS.

3. Habilite el sistema de archivos si aún no está habilitado después de borrar la alerta. Vaya a Administración de datos > Resumen > del sistema > de archivos Haga clic en Habilitar en la parte inferior de la página.

• DDFS ahora debe arrancar/ejecutarse de manera normal. Si no pudo esperar un tiempo suficiente después de borrar la alerta antes de iniciar el proceso de FS, es posible que reciba una alerta en la CLI acerca de que FS encontró un problema; sin embargo, FS continuará intentando iniciarse y, si el problema era como se describe en este artículo de la base de conocimientos, el proceso de FS finalmente se habilitará.

Desde la CLI:

1a. Asegúrese de que la fecha y la hora del sistema sean correctas. Si cambia la zona horaria, es posible que el DDR solicite un reinicio.
    Realice este reinicio inmediatamente para asegurarse de que todos los procesos reconozcan la nueva zona horaria.

1b. Asegúrese de que todos los componentes de hardware en DD estén en buen estado

2. Borre la alerta de emergencia correspondiente al error "filesystem disabled due to a critical condition":    

# alert clear alert-id [alert id]

     Por ejemplo, si se tratara de la alerta p0-32 (como se muestra arriba):    
 

# alert clear alert-id p0-32

3. Espere un minuto hasta que se borre la alerta y se actualice el estado del sistema. De lo contrario, es posible que el estado del sistema no se actualice completamente antes de que se inicie el proceso de FS, lo que podría causar un bloqueo y una alerta únicos de FS.

4. Ahora DDFS debería estar en línea automáticamente, puede verificar el estado del sistema de archivos con "# filesys status". si no es así, habilite DDFS:    

# filesys enable

• DDFS ahora debe arrancar/ejecutarse de manera normal. Si no pudo esperar un tiempo suficiente después de borrar la alerta antes de iniciar el proceso de FS, es posible que reciba una alerta en la CLI acerca de que FS encontró un problema; sin embargo, FS continuará intentando iniciarse y, si el problema era como se describe en este artículo de la base de conocimientos, el proceso de FS finalmente se habilitará.

Para obtener más información acerca de esta protección o de la información contenida en este artículo, comuníquese con el soporte técnico de Dell.

A continuación, se muestra un ejemplo del problema:    

• Inicialmente, DDFS se ejecuta de manera normal:    

# filesys status
The filesystem is enabled and running.

• El DDR tiene una fecha y hora del sistema de 13:28 del 7 de marzo de 2017:    

# date
Sun Mar  7 13:28:24 PST 2017

• La fecha se establece manualmente hacia atrás al 1 de enero de 2017 (el protocolo de hora de red/NTP debe estar deshabilitado antes de que este cambio sea posible):    

# system set date 01012017

• Los registros en el DDR (messages.engineering) indican que la fecha o la hora del sistema se cambiaron hacia atrás y que DDFS se está deshabilitando:

Mar  7 13:28:24 rtp-ddr30 ddsh: NOTICE: MSG-DDSH-00009: (tty=ttyS0, session=15703) root: command "system set date 01012017"
...
Jan  1 20:17:04 rtp-ddr30 ddr_stated: Availability stats: Invalid time interval -5591476. Probably the system clock was changed.
Jan  1 20:17:51 rtp-ddr30 platmon: INFO: Found a system time jump: -5591485
Jan  1 20:17:51 rtp-ddr30 platmon: INFO: Before Jump: system time: Tue Mar  7 13:28:15 2017 , rtc time: Tue Mar  7 13:28:16 2017 , ntp last sync time: Unknown
Jan  1 20:17:51 rtp-ddr30 platmon: INFO: After  Jump: system time: Sun Jan  1 20:17:51 2017 , rtc time: Sun Jan  1 20:17:51 2017 , ntp last sync time: Unknown
...
Jan  1 20:17:51 rtp-ddr30 platmon: NOTICE: post_alert: Generating alert EVT-ENVIRONMENT-00052
Jan  1 20:17:52 rtp-ddr30 platmon: INFO: Event posted: p0-32 (11000020:285212704): EVT-ENVIRONMENT-00052: File system is disabled due to a critical condition.EVT-OBJ::Enclosure=1 EVT-INFO::Cause=System Time backward jumped
Jan  1 20:17:52 rtp-ddr30 platmon: NOTICE: evaluate_symbol_node: taking action(s) on error_indict(1)
Jan  1 20:17:52 rtp-ddr30 platmon: INFO: System time jumped, needs service now
Jan  1 20:17:52 rtp-ddr30 platmon: ERROR: Fatal error in platform monitor, DDFS shall be disabled
...
Jan  1 20:17:55 rtp-ddr30 ddr_procmon: ERROR: Critical error is detected by platform monitoring, filesystem is shutdown.
...
Jan  1 20:17:55 rtp-ddr30 ddr_stated: INFO: change_state(): shutdown requested
Jan  1 20:17:55 rtp-ddr30 ddfs[3761]: NOTICE: MSG-DDR-00003: Shutting down ddfs

• Se publica una alerta de emergencia que indica que DDFS se ha deshabilitado "debido a una condición crítica":    

Cuando DD forma parte de Windows Active Directory o está unido a este, utiliza la controladora de dominio (DC) como origen de hora del sistema. DD sincroniza periódicamente su fecha y hora con la DC. Si cambian la fecha y la hora del controlador de dominio de Windows, las actualizaciones se envían a DD a través de CIFS. Un salto de tiempo hacia atrás de más de 60 s desencadena este comportamiento.

Para saber si este podría ser el caso, comience con la comprobación de si DD está configurado para CIFS y enlazado o unido a un dominio de Active Directory específico:   

# cifs show config
Mode                 Active-Directory
Realm                realm.example.com
Domain Controllers   *
WINS Server          not specified
NB Hostname          DD9300
Max Connections      Not Available
Max Open Files       Not Available

• Si es así, revise el archivo "cifs.log" para ver entradas como las siguientes:   

# log view debug/cifs/cifs.log
Mar 28 22:03:16 DD9300 lsass: ALWAYS: [24497/1585429396.001947087] [lsass] ADSyncTimeToDC: Attempting to change System Time, from [Sat Mar 28 22:03:16 2020 ] to [Sat Mar 28 22:54:38 2020 ]
Mar 28 23:44:38 DD9300 lsass: ALWAYS: [24497/1585435478.001799190] [lsass] ADSyncTimeToDC: Attempting to change System Time, from [Sat Mar 28 23:44:38 2020 ] to [Sat Mar 28 22:53:15 2020 ]
Mar 29 22:04:38 DD9300 lsass: ALWAYS: [24497/1585512278.002014016] [lsass] ADSyncTimeToDC: Attempting to change System Time, from [Sun Mar 29 22:04:38 2020 ] to [Sun Mar 29 22:55:53 2020 ]
Mar 29 23:25:53 DD9300 lsass: ALWAYS: [24499/1585517153.001946740] [lsass] ADSyncTimeToDC: Attempting to change System Time, from [Sun Mar 29 23:25:53 2020 ] to [Sun Mar 29 22:34:37 2020 ]
Mar 29 23:25:53 DD9300 lsass: ALWAYS: [24497/1585517153.001946645] [lsass] ADSyncTimeToDC: Attempting to change System Time, from [Sun Mar 29 23:25:53 2020 ] to [Sun Mar 29 22:34:37 2020 ]
Mar 30 22:00:53 DD9300 lsass: ALWAYS: [24497/1585598453.002161373] [lsass] ADSyncTimeToDC: Attempting to change System Time, from [Mon Mar 30 22:00:53 2020 ] to [Mon Mar 30 22:52:01 2020 ]
Mar 30 23:12:01 DD9300 lsass: ALWAYS: [24497/1585602721.002275775] [lsass] ADSyncTimeToDC: Attempting to change System Time, from [Mon Mar 30 23:12:01 2020 ] to [Mon Mar 30 22:20:52 2020 ]