La semana pasada me preguntaban acerca de multipathing, y he recordado que prometí un artículo que no he llegado a publicar hasta ahora.El contenido de este post se basa en una de mis vivencias con mdadm y Linux Redhat, aunque hay muchas otras posibilidades (como por ejemplo sdd de IBM).
Imaginemos que tengo un disco LVM que mi SO puede ver a través de dos caminos (FC, SCSI...), pongamos /dev/sdb1. La redundancia de caminos provoca que este mismo disco también quede identificado con otro nombre, por ejemplo /dev/sdf1:
[nouser@nohost ~]# pvdisplay
...
Found duplicate PV XcEAZDd9J3UD3fhwfP1Cfn6QQqf3KAQZ: using /dev/sdf1 not /dev/sdb1
Found duplicate PV XcEAZDd9J3UD3fhwfP1Cfn6QQqf3KAQZ: using /dev/sdb1 not /dev/sdf1
Found duplicate PV XcEAZDd9J3UD3fhwfP1Cfn6QQqf3KAQZ: using /dev/sdf1 not /dev/sdb1
--- NEW Physical volume ---
PV Name /dev/sdf1
VG Name
PV Size 200.00 GB
Allocatable NO
PE Size (KByte) 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID XcEAZD-d9J3-UD3f-hwfP-1Cfn-6QQq-f3KAQZ
...
Problema, el SO inicialmente cree ver dos dispositivos distintos, pero tras comprobar su PV UUID se da cuenta de que en realidad son el mismo.
Si en este punto intentara incorporar este disco a algún Volume Group, el sistema me devolvería distintos errores derivados de esta cuestión.
Para solucionar este conflicto, las herramientas de multipathing incorporan una capa de abstracción que permite administrar dispositivos virtuales a los que agregamos aquellos devices físicos susceptibles de dar problemas cuando son manejados directamente por el SO. De esta forma el sistema se olvida de los "dispositivos conflictivos" y pasa a gestionar los nuevos dispositivos "abstractos". En fin, seguro que las documentaciones respectivas lo explican mucho mejor que yo, así que me voy a centrar en el ejemplo en sí, que es a lo que había venido:
Antes de empezar necesito conocer qué PVs tengo "duplicados". Esto lo averiguo con el pvdisplay de antes, que me muestra las siguientes "parejas":
/dev/sdf - /dev/sdb
/dev/sdi - /dev/sde
/dev/sdh - /dev/sdd
/dev/sdg - /dev/sdc
Empiezo con cualquiera. Creo un dispositivo virtual /dev/md0 compuesto de dos dispositivos cuyos nombres son /dev/sdg y /dev/sdc
[nouser@nohost etc]# mdadm -C /dev/md0 --level=multipath --raid-devices=2 /dev/sdg /dev/sdc
mdadm: /dev/sdg appears to be part of a raid array:
level=-4 devices=2 ctime=Thu May 15 16:29:24 2008
mdadm: /dev/sdc appears to be part of a raid array:
level=-4 devices=2 ctime=Thu May 15 16:29:24 2008
Continue creating array? y
mdadm: array /dev/md0 started.
Esto también "arranca" el array que acabo de crear.
Consulto...
[nouser@nohost etc]# mdadm -detail
-d does not set the mode, and so cannot be first.
... pero aún tengo en las manos mantequilla del bocadillo. Voy a probar de escribirlo bien:
[nouser@nohost etc]# mdadm --detail
mdadm: No devices given.
Vale, pues escanea a ver que encuentras:
[nouser@nohost etc]# mdadm --detail --scan
ARRAY /dev/md0 level=multipath num-devices=2 UUID=0b116450:bff1928b:367cca7b:8709649c
devices=/dev/sdg,/dev/sdc
Si quisiera conocer los detalles de este /dev/md0 lanzaría lo siguiente:
[nouser@nohost etc]# mdadm --detail /dev/md0
/dev/md0:
Version : 00.90.01
Creation Time : Thu May 15 17:41:08 2008
Raid Level : multipath
Array Size : 68157376 (64.100 GiB 69.79 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Thu May 15 17:41:08 2008
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Number Major Minor RaidDevice State
0 8 96 0 active sync /dev/sdg
1 8 32 1 active sync /dev/sdc
UUID : 58e3c63b:89d1c2a3:07d02528:f87e5887
Events : 0.1
[nouser@nohost etc]#
Y si no me gusta algo y quiero borrarlo:
[nouser@nohost etc]# mdadm -r /dev/md0
[nouser@nohost etc]#
Suponemos que no he lanzado el comando anterior y sigo teniendo el /dev/md0 (si ya lo habías lanzado, lo vuelves a crear y punto).
Sigo el mismo procedimiento para crear el resto de dispositivos virtuales /dev/md* con las parejas de discos restantes. Una vez he acabado puedo consultar que dispositivos he creado con...
[nouser@nohost etc]# mdadm --detail --scan
ARRAY /dev/md3 level=multipath num-devices=2 UUID=587af9fa:97e19b3f:a04eaed1:9bdd3f34
devices=/dev/sdf,/dev/sdb
ARRAY /dev/md2 level=multipath num-devices=2 UUID=710e657f:a654e038:d776a3bc:021562e6
devices=/dev/sdi,/dev/sde
ARRAY /dev/md1 level=multipath num-devices=2 UUID=b0936429:e865370a:d73bd534:1b607145
devices=/dev/sdh,/dev/sdd
ARRAY /dev/md0 level=multipath num-devices=2 UUID=58e3c63b:89d1c2a3:07d02528:f87e5887
devices=/dev/sdg,/dev/sdc
... o bien preguntar por uno en concreto, como ya he hecho antes:
[nouser@nohost etc]# mdadm --detail /dev/md0
/dev/md0:
Version : 00.90.01
...
Si quiero que en el siguiente reinicio, la máquina reconozca los diferentes dispositivos que defino, necesito plasmar esa información en el fichero /etc/mdadm.conf. Redhat no crea este fichero de forma automática al instalar el paquete mdamd (muy mal, la debi sí lo hace, y además incluye info adicional en forma de comentarios):
ladebi:~# aptitude install mdadm
....
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
W: mdadm: no arrays defined in configuration file.
W: mdadm: falling back to emergency procedure in initramfs.
Starting MD monitoring service: mdadm --monitor.
...
ladebi:~# cat /etc/mdadm/mdadm.conf
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#
# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes
# automatically tag new arrays as belonging to the local system
HOMEHOST
# instruct the monitoring daemon where to send mail alerts
MAILADDR root
# definitions of existing MD arrays
# This file was auto-generated on Sun, 10 Aug 2008 14:11:07 +0200
# by mkconf $Id: mkconf 261 2006-11-09 13:32:35Z madduck $
ladebi:~#
Atención, la ruta del .conf es distinta en Debian.


Inglés a castellano
Anglès a català
Deja tu comentario