lunes, 22 de febrero de 2016

Recuperar un sistema de almacenamiento basado en MD + LVM2


La semana pasada tuve un gran inconveniente en uno de los servidores de apoyo operacional, un rack server HP DL380 G5 (2009) el cual arrancaba desde una unidad HP de almacenamiento multiple de discos duros la cual ya cierto tiempo atras venia con un disco duro presentando fallo fisico el cual hacía parte de un arreglo de discos asociados a una storage pool ZFS. Este pool fue configurado con RAIDZ-2 (un RAIDZ reforzado con dual paridad para sostenerse en linea incluso con dos discos averiados o en fallo) La idea consistía en reemplazar el disco averiado por uno nuevo de repuesto. Pero eso es otra historia, para un próximo post lo dedicaré a compartir la experiencia del caso de uso acerca de reemplazar el disco averiado.

EL pasado viernes 12 de febrero, aseguré dicho host el cual para mi sorpresa desplegaba errores cíclicos en algunos sectores del disco de arranque, a pesar de la advertencia apagué el equipo y bueno retiré el disco pero había olvidado un juego de destornilladores especiales para poderlo soltar del caddy. Fui a colocarlo nuevamente y volver a encenderlo. He ahi que con gran sorpresa encuentro que el sistema no arranca! OMG!, no puede arrancar siquiera el grub boot. Con preocupación me retiré y el lunes siguiente (15 de febrero) empecé a revisar dicha novedad.  Retiré el disco del slot 1 del MSA2000 unit que es donde estaba ubicado el grub bootloader, lo coloco en mi equipo el cual previamente le habia instalado una PCIe HBA Card con  conector de cable multisata (4 puertos) que habia comprado unos 3 años atrás por eBay especifcamente para poder dumpear discos a bajo nivel con dd. Desafortunadamente el disco arrancó con sonido de cabeza atascada y traqueaba fuerte, clara señal de que algo no estaba bien en el. Ni siquiera era reconocido por la controladora asi que la situación se ponía color de hormiga. Para ese momento aun no acaba de recordar de que años atrás cuando preparé el sistema había configurado con RAID1 basado en "Linux MD". Fue entonces cuando procedí a desconectar el siguiente disco en orden del arreglo el cual efectivamente tendría la información del disco. Para verificar que estaba al menos bueno para su uso, procedi a colocarlo en el slot 1 y encenderlo. Intentaba bootearlo pero no tenía grub, fue cuando tomé ese disco y lo coloqué en la controladora instalada en mi estación de trabajo paara verificar que contenía en su interior al menos en los sectores de la cabecera del disco.  Allí terminé encontrando que encima del RAID1 (Linux MD) encontré una estructura basada en LVM2 !!!!!.  La titanica tarea iniciaba, lograr llegar al fondo de los datos y recuperar la información alli presente. Al tener RAID1 con 2 discos, y al tener el 1er disco fuera de linea fisicamente averiado y bloqueado, la unica forma era lograr acceder a las particiones que estaban por debajo de LVM y este por debajo de LinuxMD en ese disco de respaldo.   Estos fueron los pasos que llevé a cabo para lograrlo:  (desde mi equipo el disco ha sido dispuesto por el o/s desde /dev/sdd)

Primero que todo verificar la estructura de particionamiento de disco para saber en que parte se encuentra la información:

root@m0n0-PT1650:/home/m0n0lithic# sfdisk /dev/sdd
Checking that no-one is using this disk right now ...
OK

Disk /dev/sdd: 121601 cylinders, 255 heads, 63 sectors/track
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
Old situation:
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sdd1          0+     31-     31-    248832   83  Linux
/dev/sdd2         31+ 121601- 121570- 976510977    5  Extended
/dev/sdd3          0       -       0          0    0  Empty
/dev/sdd4          0       -       0          0    0  Empty
/dev/sdd5         31+ 121601- 121570- 976510976   fd  Linux raid autodetect
Input in the following format; absent fields get a default value.

Usually you only need to specify and (and perhaps ).

Se escanea entonces dicha partición para ubicar mas información al respecto de su estructura:

mdadm --examine --scan  /dev/sdd5 ARRAY /dev/md2 level=raid1 num-devices=2

ARRAY /dev/md/0 level=raid1 num-devices=2
 ↪UUID=9b6e03fe:b73c43f2:1a490486:daa901de

   devices=/dev/sdd5

Como podemos observar la partición asignada a Linux RAID MD es la número 5. Ahora es turno de poder invocar el driver y simular el RAID para que el o/s me permita ingresar a lo que está debajo de el. Con la siguiente instrucción escaneo preliminarmente dicha partición para que el driver md le reconozca y la disponga:


# mdadm --examine --scan level=raid1 /dev/sdd5 num-devices=2 ARRAY /dev/md/0 metadata=1.2 UUID=9b6e03fe:b73c43f2:1a490486:daa901de name=copiapo:0

El UUID tambien es posible sacarlo por el sistema de asignacion al dispositivo md/0 en /dev/disk/by-uuid/

El siguiente paso luego de scanear en el dispositivo es habilitar la unidad al sistema linux RAID:
# mdadm -A -s

Se verifica que este ya atado con:
# cat /proc/mdstat


Luego se procede a recuperar y renombrar el volumen LVM2, pero para ello como no se tiene información certera de la estructura LVM2, se procede a capturar los primeros 255 sectores del disco a recuperar. Dicha salida se almacena en un archivo temporal.  Es allí donde radica la información estructural:

# dd if=/dev/md0 bs=512 count=255 skip=1 of=/tmp/md2-raw-start

Parte de la información extraida es esta (para este ejemplo):

COP01 {
id = "jg3MRj-5TrS-wdBQ-IXCR-KJ0c-c1hF-hE3tTq"
seqno = 1
format = "lvm2" # informational
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192
max_lv = 0
max_pv = 0
metadata_copies = 0

physical_volumes {

pv0 {
id = "nKq99y-jngj-Aj0T-vw4O-nhsQ-2U1O-d0KVuC"
device = "/dev/md0"

status = ["ALLOCATABLE"]
flags = []
dev_size = 1952759424
pe_start = 2048
pe_count = 238373
}
}

# Generated by LVM2 version 2.02.95(2) (2012-03-06): Tue Jun 24 16:22:23 2014

contents = "Text Format Volume Group"
version = 1

description = ""

creation_host = "copiapo"       # Linux copiapo 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64
creation_time = 1403626943      # Tue Jun 24 16:22:23 2014

logical_volumes {

SWAP {
id = "qHXmbW-I9hG-IL2V-SKXi-LFPv-PUuO-Kw74eR"
status = ["READ", "WRITE", "VISIBLE"]
id = "qHXmbW-I9hG-IL2V-SKXi-LFPv-PUuO-Kw74eR"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
creation_host = "copiapo"
creation_time = 1403626970
segment_count = 1

segment1 {
start_extent = 0
extent_count = 2861

type = "striped"
stripe_count = 1        # linear

stripes = [
"pv0", 0

]
}
}
}
}
# Generated by LVM2 version 2.02.95(2) (2012-03-06): Tue Jun 24 16:22:50 2014

contents = "Text Format Volume Group"
version = 1

description = ""

creation_host = "copiapo"       # Linux copiapo 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64
creation_time = 1403626970      # Tue Jun 24 16:22:50 2014

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@COP01 {
id = "jg3MRj-5TrS-wdBQ-IXCR-KJ0c-c1hF-hE3tTq"
seqno = 3
format = "lvm2" # informational
status = ["RESIZEABLE", "READ", "WRITE"]


ROOT {
id = "3K3u2T-Srwh-Cy0D-AQz0-uVUY-dTyP-JtMYSu"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
creation_host = "copiapo"
creation_time = 1403627035
segment_count = 1

segment1 {
start_extent = 0
extent_count = 235512

type = "striped"


Como ya tenemos el nombre del grupo principal ("COP01") igualmente verificamos a través de vgscan (volume group) y pvscan (physical vol) asi:

# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "COP01" using metadata type lvm2

# pvscan
  PV /dev/md0   VG COP01   lvm2 [931,14 GiB / 0    free]
  Total: 1 [931,14 GiB] / in use: 1 [931,14 GiB] / in no VG: 0 [0   ]

Luego de identificado lógica y fisicamente el volumen LVM2, Se procede a activar el volume group "COP01" 

# vgchange COP01 -a y

  2 logical volume(s) in volume group "COP01" now active

Finalmente se habilita dicho VG (Volume Group) para que la capa de archivo del sistema operativo pueda reconocerlo como un dispositivo mas de I/O:



# mount /dev/COP01/ROOT /mnt/linux

root@m0n0-PT1650:/home/m0n0lithic# df
Filesystem              1K-blocks      Used Available Use% Mounted on
udev                      4052292        12   4052280   1% /dev
tmpfs                      812632      1184    811448   1% /run
/dev/sdc6               110560080   9857656  95063256  10% /
none                            4         0         4   0% /sys/fs/cgroup
none                         5120         0      5120   0% /run/lock
none                      4063152     29016   4034136   1% /run/shm
none                       102400        68    102332   1% /run/user
/dev/sdc1                  528112    191668    309616  39% /boot
/dev/sda1              1953521664 960410740 989882988  50% /home
/dev/mapper/COP01-ROOT  949389436 651391012 249749184  73% /mnt/linux

ó df -h

/dev/mapper/COP01-ROOT  906G  622G  239G  73% /mnt/linux

A partir de este punto es cuando el administrador fisico del sistema puede disponer de la información guardada bajo esa estructura para su respectivo aseguramiento.


Espero sea de su agrado, les guste y le sirva de soporte para alguien que tenga una situación similar. Hasta una pronta aparición.

No hay comentarios :