Skip to main content
Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Identifique y desmonte los volúmenes de almacenamiento que han fallado

Colaboradores netapp-pcarriga netapp-lhalbert
PDF

Al recuperar un nodo de almacenamiento con volúmenes de almacenamiento con fallos, se deben identificar y desmontar los volúmenes con errores. Debe verificar que solo los volúmenes de almacenamiento con errores se hayan reformateado como parte del procedimiento de recuperación.

Antes de empezar

Ha iniciado sesión en Grid Manager mediante una "navegador web compatible".

Acerca de esta tarea

Debe recuperar Lo antes posible. de volúmenes de almacenamiento con errores.

El primer paso del proceso de recuperación es detectar volúmenes que se han desvinculado, se deben desmontar o se producen errores de I/O. Si los volúmenes con fallos siguen conectados pero tienen un sistema de archivos dañado de forma aleatoria, es posible que el sistema no detecte ningún daño en partes del disco que no estén en uso o no estén asignados.

Nota Debe finalizar este procedimiento antes de realizar los pasos manuales para recuperar los volúmenes, como añadir o volver a conectar los discos, detener el nodo, iniciar el nodo o reiniciar. De lo contrario, al ejecutar reformat_storage_block_devices.rb el script, es posible que se produzca un error del sistema de archivos que provoque que el script se bloquee o falle.
Nota Repare el hardware y conecte correctamente los discos antes de ejecutar reboot el comando.
Precaución Identifique cuidadosamente los volúmenes de almacenamiento fallidos. Utilizará esta información para verificar qué volúmenes se deben reformatear. Una vez reformateado un volumen, no se pueden recuperar los datos del volumen.

Para recuperar volúmenes de almacenamiento fallidos, debe conocer tanto los nombres de los dispositivos de los volúmenes de almacenamiento fallidos como sus ID de volumen.

Durante la instalación, a cada dispositivo de almacenamiento se le asigna un identificador único universal (UUID) de sistema de archivos y se monta en un directorio rangedb en el nodo de almacenamiento utilizando ese UUID de sistema de archivos asignado. El UUID del sistema de archivos y el directorio rangedb se enumeran en el /etc/fstab archivo. El punto de montaje, el nombre del dispositivo y el tamaño del volumen se muestran en el Administrador de cuadrícula.

Pasos

  1. Complete los siguientes pasos para registrar los volúmenes de almacenamiento que han fallado y sus nombres de dispositivo:

    1. Seleccione Nodos > sitio > Nodo de almacenamiento fallido > Almacenamiento.

    2. Desplácese hacia abajo para ubicar la tabla Volúmenes y la tabla Almacenes de objetos y registre la siguiente información para cada volumen con un estado Desconocido o Fuera de línea.

      • Desde la tabla Volúmenes, registre el punto de montaje, el dispositivo y el tamaño.

      • Desde la tabla de almacenes de objetos, registre el object_store_ID .

        El object_store_ID es el ID del volumen de almacenamiento con errores. Por ejemplo, especifique 0 en el comando de un almacén de objetos con ID 0000.

  2. Inicie sesión en el nodo de almacenamiento con errores:

    1. Introduzca el siguiente comando: ssh admin@grid_node_IP

    2. Introduzca la contraseña que aparece en el Passwords.txt archivo.

    3. Introduzca el siguiente comando para cambiar a raíz: su -

    4. Introduzca la contraseña que aparece en el Passwords.txt archivo.

      Al iniciar sesión como root, la petición de datos cambia de $ a #.

  3. Ejecute el siguiente script para desmontar un volumen de almacenamiento con errores:

    sn-unmount-volume object_store_ID

  4. Si se le solicita, pulse y para detener el servicio Cassandra en función del volumen de almacenamiento 0.

    Nota Si el servicio Cassandra ya está detenido, no se le preguntará. El servicio Cassandra se ha detenido solo para el volumen 0. 
    root@Storage-180:~/var/local/tmp/storage~ # sn-unmount-volume 0
Services depending on storage volume 0 (cassandra) aren't down.
Services depending on storage volume 0 must be stopped before running this script.
Stop services that require storage volume 0 [y/N]? y
Shutting down services that require storage volume 0.
Services requiring storage volume 0 stopped.
Unmounting /var/local/rangedb/0
/var/local/rangedb/0 is unmounted.

    En unos segundos, el volumen se desmonta. Aparecen mensajes que indican cada paso del proceso. El mensaje final indica que el volumen no está asociado.

  5. Si el desmontaje falla porque el volumen está ocupado, puede forzar un desmontaje con la --use-umountof opción:

    Nota Al forzar un desmontaje mediante la --use-umountof opción, los procesos o los servicios que utilizan el volumen se comportan de forma inesperada o se bloquean. 
    root@Storage-180:~ # sn-unmount-volume --use-umountof /var/local/rangedb/2
Unmounting /var/local/rangedb/2 using umountof
/var/local/rangedb/2 is unmounted.
Informing LDR service of changes to storage volumes