Data Domain: Se produjo un reinicio inesperado de DDFS (sistema de archivos de Data Domain) con la alerta EVT-FILESYS-00008/FILESYS-00008 o EVT-FILESYS-00010/FILESYS-00010 o EVT-FILESYS-00011/FILESYS-00011

Yhteenveto: En este artículo de la base de conocimientos, se explica lo que sucede cuando se produce un reinicio inesperado del sistema de archivos, las posibles alertas encontradas y la información que se debe capturar con fines de triage. ...

Tämä artikkeli koskee tuotetta Tämä artikkeli ei koske tuotetta Tämä artikkeli ei liity tiettyyn tuotteeseen. Tässä artikkelissa ei yksilöidä kaikkia tuoteversioita.
Tutustu muihin resursseihin

Oireet



El proceso de DDFS es el proceso principal responsable de la operación del sistema de archivos de deduplicación de DDOS (Data Domain Operating System).

Si este proceso encuentra un problema, se crea una alerta que será una de las siguientes:
  • EVT-FILESYS-00008/FILESYS-00008
  • EVT-FILESYS-00010/FILESYS-00010
  • EVT-FILESYS-00011/ FILESYS-00011
Las alertas anteriores indican que el problema detectado fue inesperado y se requiere más información para determinar la causa.

La alerta se enviará a través del mecanismo de alerta configurado en el sistema Data Domain, es decir, a través de correo electrónico/snmp. La alerta también aparecerá en la salida "alerts show history".

Syy

Este proceso puede reiniciarse de varias maneras, por ejemplo:
  • Un estado de alarma directo, es decir, un error de código explícito.
  • Se encuentra un tiempo de espera interno. DDFS tiene un subproceso de monitor de latido interno (llamado hmon) que supervisa el estado de los diversos subsistemas dentro del proceso de DDFS. Si hmon determina que un subsistema ha suspendido o ha estado esperando demasiado tiempo, finaliza el proceso de DDFS.
  • Se encuentra un tiempo de espera externo. Un proceso denominado ddr_stated es responsable de monitorear externamente el proceso de DDFS mediante un mecanismo de latido. Si DDFS no envía un latido a ddr_stated dentro de un período determinado, ddr_stated supone que DDFS ha suspendido y finaliza el proceso de DDFS.
  • El proceso solicita más memoria de la que se permite.
  • Falló una comprobación de sanidad interna.
Cuando se encuentra cualquiera de estas condiciones, el sistema de archivos intenta reiniciarse automáticamente para reanudar el funcionamiento normal. 

Durante el reinicio de DDFS, todas las operaciones que estaban en curso, como restauraciones/respaldos, es decir, lecturas/escrituras, se interrumpirán y deberán reiniciarse. La mayoría de las aplicaciones de respaldo pueden reconocer que las lecturas/escrituras se interrumpieron y reiniciar estas operaciones automáticamente.

Cuando se produce un reinicio inesperado de DDFS, suceden las siguientes cosas:
  • El proceso se detiene.
  • El espacio físico de memoria que el proceso estaba utilizando se escribe en un "archivo principal" que se escribirá en un dispositivo de volcado de memoria, que es un área especial en uno de los discos de la unidad principal. Un archivo principal contiene la información necesaria para depurar por qué se produjo el reinicio inesperado.
  • Una vez que se completa el paso anterior, el proceso de DDFS puede reiniciarse.
  • En paralelo, es decir, una vez que DDFS se reinicia, el archivo principal se debe extraer del dispositivo de volcado principal a un sistema de archivos de DDOS, de modo que se pueda acceder a él. El proceso que realiza esta tarea se denomina "savecore".
  • Savecore crea un directorio temporal inicial en /ddvar/core. El nombre del directorio se denominará "app-<date and time the core file>".
  • Dado que DDFS utiliza la mayoría de la memoria en el sistema, el espacio físico de la memoria para DDFS puede ser grande. Para minimizar la cantidad de datos escritos en el archivo principal, savecore lee desde el dispositivo de volcado principal, transmite esta información a través de gzip, para asegurarse de que el archivo principal sea lo más pequeño posible y comienza a escribir en un archivo llamado "core-incomplete.gz".
  • Una vez que se complete este proceso, se eliminará el directorio temporal, el archivo principal se colocará en /ddvar/core y se cambiará el nombre. La convención de asignación de nombres para un archivo principal es la siguiente:
    • El nombre del proceso.
    • El ID del proceso.
    • La cadena "core".
    • La fecha y hora en que se generó el núcleo en un formato unix epoch.
    • Por ejemplo, un archivo principal para DDFS podría denominarse "ddfs.core.14226.1469256407.gz".
Debido a que el espacio físico de la memoria es grande, la creación de un archivo principal no es inmediata y puede tardar varios minutos en completarse por completo.

Tarkkuus

Como se mencionó anteriormente, la creación del archivo principal no es inmediata, el directorio /ddvar/core se puede comprobar periódicamente a través de un recurso compartido NFS o CIFS para determinar cuándo se completó la creación del archivo principal. 

Una vez finalizada la creación del archivo principal, se requieren dos elementos de información para clasificar lo que causó el reinicio inesperado. Estos son los siguientes:
  1. Un nuevo paquete de soporte. Consulte el siguiente artículo sobre cómo capturar y cargar un paquete de soporte: https://support.emc.com/kb/323283
  2. El archivo principal generado cuando se produjo el problema. Consulte el siguiente artículo de la base de conocimientos sobre los diversos métodos que se pueden utilizar para cargar y acceder a un archivo principal: https://support.emc.com/kb/457974
Cargue los elementos anteriores en el caso de soporte.

Tuotteet, joihin vaikutus kohdistuu

Data Domain

Tuotteet

Data Domain, DD OS, Data Domain Virtual Edition
Artikkelin ominaisuudet
Artikkelin numero: 000064290
Artikkelin tyyppi: Solution
Viimeksi muutettu: 19 syysk. 2022
Versio:  4
Etsi vastauksia kysymyksiisi muilta Dell-käyttäjiltä
Tukipalvelut
Tarkista, kuuluuko laitteesi tukipalveluiden piiriin.