Problema
Este artículo contiene un procedimiento para abordar el estado "failed" o "failed was" que informa vxdisk.
Mensaje de error
# vxdisk -o alldgs list
DEVICE TYPE DISK GROUP STATUS
disk_0 auto:cdsdisk - (vxfendg) online
disk_1 auto:cdsdisk - (vxfendg) online
disk_2 auto:cdsdisk - (vxfendg) online
disk_3 auto:cdsdisk datadg01 datadg online
disk_4 auto - - error
disk_5 auto:cdsdisk datadg03 datadg online
disk_6 auto:cdsdisk datadg04 datadg online
disk_7 auto:cdsdisk - (sambadg) online
disk_8 auto:cdsdisk - - online
disk_9 auto:cdsdisk - - online
sda auto:none - - online invalid
- - datadg02 datadg failed was:disk_4
Solución
Tabla de contenidos
1. Introducción
2. Discos "faileds" versus "failing"
3. Crear una copia de seguridad de emergencia de la configuración del grupo de discos
4. ¿El disco se excluyó en vxvm.exclude?
5. ¿Otra solución de administrador lógico de volúmenes sobrescribió el disco?
6. Determinar si se puede volver a adjuntar un disco
7. Verificar si el sistema operativo puede leer un disco
8. ¿Las rutas para el disco se deshabilitaron?
9. Restaurar la configuración del grupo de discos con vxconfigrestore
10. Restaurar la configuración del grupo de discos manualmente con UDID e identificadores de disco
11. Reiniciar el volumen
1. Introducción
(Volver arriba)
Este artículo contiene un procedimiento para abordar el estado "failed" o "failed was" que informa vxdisk.
El estado "failed" es el registro de un disco al que ya no se puede acceder. A menudo esto se debe a errores de E/S del disco que impiden que el sistema operativo (SO) lo lea. También puede ser el resultado de daños en la región de privada de Veritas.
La región privada es la parte del disco donde Veritas almacena registros sobre el grupo de discos, como discos, volúmenes, subdiscos y complejos. Esta se puede contrastar con la región pública, que contiene los volúmenes reales, incluidos los datos de usuario.
2. Discos "faileds" versus discos "failing"
(Volver arriba)
El estado "failed" no se debe confundir con el estado "failing". Este artículo habla principalmente del estado "failed" que informa vxdisk. Para obtener información a fin de abordar el estado "failed", consulte https://www.veritas.com/support/es_ES/article.000034531.
3. Crear una copia de seguridad de emergencia de la configuración del grupo de discos
(Volver arriba)
Antes de realizar algún otro cambio, use vxconfigbackup para crear una copia de seguridad de emergencia de la región privada para los discos restantes del grupo de discos afectado.
Vxconfigbackup no crea una copia de seguridad de los datos reales que se encuentran dentro de los volúmenes. En su lugar, crea una copia de seguridad de la base de datos de configuración de la región privada de Veritas que reside en los discos, además de cierta información acerca de estos. La base de datos de configuración almacena información acerca de qué discos forman parte del grupo de discos, las estructuras de volumen, los complejos y los subdiscos.
Si vxconfigbackup no está disponible, se puede usar vxprivutil para volcar una copia de la base de datos de configuración.
Puede encontrar más detalles acerca de vxconfigbackup y vxprivutil, incluida la sintaxis y diferentes ejemplos, en este artículo:
"Utilizar vxconfigbackup y vxprivutil para crear una copia de seguridad de la configuración del grupo de discos de la región privada de Veritas"
https://www.veritas.com/support/es_ES/article.000087431
4. ¿vxvm.exclude excluyó el disco?
/etc/vx/vxvm.exclude mantiene una lista de las rutas, los controladores y los productos excluidos. Compruebe si el disco, o la ruta o el controlador asociados, se incluye en este archivo.
Si el valor de "exclude_all" es 1, se excluirán todos los dispositivos.
Figura 1: contenidos predeterminados de /etc/vx/vxvm.exclude
|
exclude_all 0
paths
#
controllers
#
product
#
|
5. ¿Otra solución de administrador lógico de volúmenes sobrescribió el disco?
(Volver arriba)
Si vxdisk muestra que el tipo de disco incluye las palabras "LVM" o "ZFS", lo que significa que es posible otra solución de LVM (del inglés Logical Volume Manager: administrador lógico de volúmenes) haya sobrescrito el disco . También es posible que haya un problema con la zonificación de SAN que pueda haber provocado que los discos se presenten en los sistemas incorrectos. Antes de efectuar algún otro cambio, asegúrese de que el disco no se deba zonificar en otro sistema.
Para volver a colocar un disco en el grupo de discos original de Veritas, el disco se debe eliminar del control de la otra solución de LVM e inicializarse para Veritas con vxdisksetup. Consulte la documentación del proveedor apropiado para obtener información acerca de la eliminación de un disco del control de la solución de LVM.
6. Determinar si se puede volver a adjuntar un disco
Vxreattach se usa para restaurar el nombre de soporte original del disco y volver a adjuntar el disco al grupo de discos. Normalmente solo puede usase si el estado del disco es "en línea" (consulte la Figura 2).
Ejecute vxreattach con el argumento "-c" para determinar si un disco se puede volver a adjuntar al grupo de discos.
Figura 2: con el uso de vxreattach, con el argumento "-c", para comprobar si una reconexión es posible
Sintaxis: vxreattach -c <disk_media_name> Ejemplo, con la salida típica: # vxreattach -c disk_4
En este caso, "datadg" es el nombre del grupo de discos y "datadg02" es el nombre del soporte del disco, tal como lo muestra vxdisk. # vxdisk -o alldgs list |
Si vxreattach -c arroja un nombre de soporte de disco y grupo de discos, sin arrojar ningún error, proceda con la reconexión del disco (Figura 3). Si no es posible volver a adjuntar el disco, aparecerá el error V-5-2-238.
Figura 3: usar vxreattach para volver a adjuntar un disco al grupo de discos
Sintaxis: vxreattach -br <disk_media_name> Ejemplo, con salida típica: # vxreattach -br disk_4Tenga en cuenta que vxdisk ahora muestra un nombre de soporte de disco, "datadg02", para disk_4. # vxdisk -o alldgs list |
7. Verificar si el sistema operativo puede leer un disco
(Volver arriba)
Usar los comandos de SO nativos para confirmar si el SO puede leer el disco, incluida la etiqueta de disco.
- Usar comandos, tales como prtvtoc, fdisk, lspv o diskinfo, para leer la etiqueta de disco.
- Use dd para leer un bloque del disco.
Veritas depende de las unidades de dispositivos del SO para comunicarse con los discos. Si el SO no puede leer un disco, Veritas tampoco podrá hacerlo. Si un disco no cuenta con una etiqueta o la etiqueta se dañó, Veritas no reconocerá el disco. Completar estos pasos lo ayudará a identificar el origen de la desconexión de un disco.
"Verificar si el sistema operativo pueda leer un disco"
https://www.veritas.com/support/es_ES/article.000087435
8. ¿Se deshabilitaron las rutas del disco?
Use vxdmpadm para determinar el estado de las rutas de los discos (Figura 4).
Veritas deshabilitará una ruta si ocurren errores de E/S graves o prolongados. Si se deshabilitan todas las rutas de un disco, el servidor no podrá leer o escribir en el volumen. Si se deshabilitó una ruta, revise el syslog en busca de eventos informados por "vxdmp" o errores de E/S informados por "scsi".
Si bien una ruta se puede volver a habilitar con "vxdmpadm enable", vxdmp debe evaluar automáticamente el estado de una ruta en intervalos de cinco minutos mediante una consulta scsi. Si la consulta es satisfactoria, la ruta se rehabilita automáticamente. Si una ruta sigue deshabilitada luego de este intervalo, es posible que se sigan detectando errores de E/S, lo que justifica una investigación más profunda. Las rutas no se vuelven a habilitar automáticamente si se deshabilitó el grupo de discos o se detiene vxesd. Se puede modificar el comportamiento de vxdmp en respuesta a las rutas deshabilitadas mediante los parámetros sintonizables de DMP, que se pueden ver con "vxmpadm gettune".
Figura 4: ejemplo de una ruta deshabilitada, tal como lo informa vxdmpadm
Sintaxis: vxdmpadm getsubpaths Por ejemplo: # vxdmpadm getsubpathsNAME STATE[A] PATH-TYPE[M] DMPNODENAME ENCLR-NAME CTLR |
9. Restaurar la configuración del grupo de discos con vxconfigrestore
(Volver arriba)
Si un vxreattach no es posible, use vxconfigrestore para recuperar el grupo de discos.
Vxconfigrestore no restaura los datos reales que se encuentran dentro de los volúmenes. Solo restaura la base de datos de configuración de Veritas que se encuentra en la región privada de los discos. La base de datos de configuración almacena información acerca de qué discos forman parte del grupo de discos, las estructuras de volumen, los complejos y los subdiscos.
"Restaurar la configuración del grupo de discos con vxconfigrestore"
https://www.veritas.com/support/es_ES/article.000087440
10. Restaurar la configuración del grupo de discos manualmente con UDID e identificadores de disco
(Volver arriba)
Si no se puede usar vxconfigrestore, a fin de recuperar los discos, puede comparar los atributos de UDID o de identificador de disco con los registros incluidos en la base de datos de configuración de la región privada.
"Restaurar la configuración del grupo de discos manualmente con UDID e identificadores de disco"
https://www.veritas.com/support/es_ES/article.000087441
11. Reiniciar el volumen
(Volver arriba)
Una vez que el disco original se haya vuelto a agregar al grupo de discos, es posible que se necesiten pasos adicionales para recuperar el volumen. Use vxprint para determinar el estado actual (Figura 5).
- Para volúmenes duplicados:
- Si al menos un complejo no se ve afectado por la desconexión, se deben resincronizar los otros complejos cuando se vuelvan a adjuntar al volumen. Es posible que sea necesario usar vxrecover para iniciar este proceso (Figura 6).
- Si todos los complejos se ven afectados por la desconexión, puede ser necesario revisar manualmente cada complejo para determinar cuáles contienen las actualizaciones más recientes.
Advertencia: No fuerce el inicio de un volumen duplicado. Esto puede generar que un complejo que contiene bloques antiguos o dañados sobrescriba un complejo que contiene datos actualizados. Puede encontrar un procedimiento para determinar manualmente cuál es el complejo duplicado más actualizado en este artículo:
"Determinar manualmente qué complejo duplicado contiene los datos más recientes y resincronizar"
https://www.veritas.com/support/es_ES/article.000087709
- Para volúmenes no duplicados:
- Es posible que sea necesario reiniciar manualmente el volumen con vxvol después de agregar el disco al grupo de discos (Figura 5).
Figura 5: usar vxprint para determinar el estado de un volumen
Sintaxis: vxprint -g <disk_group> -ht Ejemplo, con la salida típica: En este caso, vxprint muestra que se deshabilitó el volumen "vol1". El estado de complejo es "IOFAIL", que indica que se produjo una interrupción de E/S prolongada en el volumen. Una vez que el disco asociado se haya vuelto a agregar al grupo de discos, el volumen tendrá que reiniciarse manualmente con vxvol. #vxprint -g datadg -htdg datadg default default 1000 1336573086.38.Server101 |
Figura 6: usar vxvol para iniciar un volumen y usar vxprint para revisar cualquier cambio en el estado del volumen.
Sintaxis: vxvol -f <disk_group> -fa startall Ejemplo, con la salida típica: # vxvol -g datadg -fa startallVxprint ahora muestra que se ha iniciado el volumen. #vxprint -g datadg -htdg datadg default default 1000 1336573086.38.Server101 |
Figura 7: usar vxrecover para finalizar la recuperación o iniciar la resincronización de un volumen
Sintaxis: vxrecover -sb <volume> Ejemplo, con la salida típica: # vxrecover -sb vol1Vxprint ahora muestra que "vol1" está "ACTIVE". # vxprint -g datadg -ht |
palabras clave: failed, failing, failed disk, failed disks, failing disk, failed disks
¿Fue útil este contenido?
Translated Content
Please note that this document is a translation from English, and may have been machine-translated. It is possible that updates have been made to the original version after this document was translated and published. Veritas does not guarantee the accuracy regarding the completeness of the translation. You may also refer to the English Version of this knowledge base article for up-to-date information.