En este post voy a trastear un poco con el Software Raid de Linux (siguiendo el excelente tutorial de Ivan) y sobre todo voy a introducir la funcionalidad del “bitmap write-intent logging” (ver man md(4)) de los dispositivos Raid-1. Esta opcion permite optimizar mucho la resyncronizacion de un raid, al reañadirle un disco que habiamos quitado.
Primero vamos a crear un raid-1 (mirror), sin bitmap. Veremos cuanto tiempo tarda la reconstruccion del mismo. Despues, haremos lo mismo, pero con bitmap y compararemos.
* Antes de nada creo dos dispositivos (para la prueba, uso dos lvoles bajo LVM, funciona igual que si fueran discos duros o particiones de disco):
<pre>
alegrome# lvcreate -L 5g -n lv01 vg01
Logical volume “lv01″ created
alegrome# lvcreate -L 5g -n lv02 vg01
Logical volume “lv02″ created
</pre>
* Creamos el raid1, con mdadm(8):
<pre>alegrome# mdadm –force -C /dev/md0 -l1 -n2 /dev/vg01/lv0[12]
mdadm: -C would set mdadm mode to “create”, but it is already set to “manage”.
alegrome# mdadm -C /dev/md0 -l1 -n2 /dev/vg01/lv0[12]
mdadm: /dev/vg01/lv02 appears to be part of a raid array:
level=raid1 devices=2 ctime=Tue Jul 24 21:48:41 2007
Continue creating array? y
mdadm: array /dev/md0 started.
</pre>
* Enseguida, miramos el estado del raid1, en mdstat. Podemos ver que md(4) esta construyendo el raid. Lo cual es bastante absurdo, porque al principio estaria vario, pero bueno. El tiempo que tarde en construirlo depende del tamaño de los volumenes y de la velocidad de los discos.
<pre>
alegrome# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 dm-18[1] dm-17[0]
5242816 blocks [2/2] [UU]
[>....................] resync = 3.8% (202880/5242816) finish=5.7min speed=14491K/sec
unused devices: <none>
</pre>
Este proceso de reconstruccion occure, al iniciar el dispositivo raid1, al añadir un disco que habiamos quitado o al cambiar un disco fallido, en caso de arranque tras un crash,…
* Voy a simular actividad en el dispositivo raid. Para esto, lo que voy a hacer es montar el raid1 en /mnt/prueba, y lanzar en background un pequeño script que va escribiendo en el fichero /mnt/prueba/traza la fecha, eso cada 5 segundos:
<pre>
alegrome# mke2fs -j /dev/md0
[...]
alegrome# mkdir -p /mnt/prueba
alegrome# mount /dev/md0 /mnt/prueba
alegrome# while true; do date > /mnt/prueba/traza; sleep 5; done &
[1] 4368
alegrome# cat /mnt/prueba/traza
Thu Jul 26 18:46:35 CEST 2007
</pre>
Ok, ya esta, ahora tenemos un raid1 montado, con actividad (no mucha, pero eso da igual).
* Ahora vamos a simular en caliente el fallo del lv02, para despues re-añadirlo al raid1. Primero simulamos el fallo del lv02, y lo quitamos del raid1:
<pre>alegrome# mdadm /dev/md0 -f /dev/vg01/lv02 -r /dev/vg01/lv02
mdadm: set /dev/vg01/lv02 faulty in /dev/md0
mdadm: hot removed /dev/vg01/lv02
</pre>
Podemos ver en mdstat que el raid esta degradado:
<pre>
alegrome# mdadm –detail /dev/md0
/dev/md0:
Version : 00.90.03
Creation Time : Thu Jul 26 18:20:42 2007
Raid Level : raid1
Array Size : 5242816 (5.00 GiB 5.37 GB)
Device Size : 5242816 (5.00 GiB 5.37 GB)
Raid Devices : 2
Total Devices : 1
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Thu Jul 26 18:38:27 2007
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 0
Spare Devices : 0
UUID : 4fc731aa:23c9e12e:ef996995:ee57cd33 (local to host alegrome)
Events : 0.6
Number Major Minor RaidDevice State
0 253 17 0 active sync /dev/dm-17
1 0 0 1 removed
alegrome# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 dm-17[0]
5242816 blocks [2/1] [U_]
unused devices: <none>
</pre>
* Ahora, le volvemos a añadir el lv02 al raid1, y en seguida miramos el estado de la reconstruccion en mdstat:
<pre>
alegrome# mdadm /dev/md0 -a /dev/vg01/lv02
mdadm: re-added /dev/vg01/lv02
alegrome# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 dm-18[1] dm-17[0]
5242816 blocks [2/1] [U_]
[>....................] recovery = 0.5% (29184/5242816) finish=2.9min speed=29184K/sec
unused devices: <none>
</pre>
Podemos ver en la salida anterior que de nuevo el raid se esta reconstruyendo totalmente, lo cual tarda un tiempo. En este caso, el tiempo de reconstruccion estimado es de unos 3 minutos.
* Ahora <b>vamos a crear raid1 con bitmap de “write intent”</b>. Es decir una pequeña zona reservada en el dispositivo donde md(4) apunta los bloques modificados. En caso de necesitar reconstruccion, md(4) mirara el bitmap y resyncronizara unicamente los bloques modificados (mucho mas rapido. Cuanto menos se modifique el raid, mas rapido). Existen varias posibilidades respecto a donde colocar el bitmap, elijo la opcion “internal” (creo que es mejor que resida directamente en el dispositivo).
* Primero desmontamos nuestro filesystem de prueba y paramos el md0 (he parado antes el script de traza que escribia en el /mnt/prueba):
<pre>alegrome# umount /mnt/prueba/
alegrome# mdadm –stop /dev/md0
mdadm: stopped /dev/md0
</pre>
* Ahora creo de nuevo el raid1 md0:
<pre>alegrome# mdadm -C /dev/md0 -l1 -n2 -b internal /dev/vg01/lv0[12]
mdadm: /dev/vg01/lv01 appears to contain an ext2fs file system
size=5242816K mtime=Thu Jul 26 19:23:44 2007
mdadm: /dev/vg01/lv01 appears to be part of a raid array:
level=raid1 devices=2 ctime=Thu Jul 26 19:23:38 2007
mdadm: /dev/vg01/lv02 appears to contain an ext2fs file system
size=5242816K mtime=Thu Jul 26 19:23:44 2007
mdadm: /dev/vg01/lv02 appears to be part of a raid array:
level=raid1 devices=2 ctime=Thu Jul 26 19:23:38 2007
Continue creating array? y
mdadm: array /dev/md0 started.
</pre>
* Esta vez, podemos ver en el detalle del md0 que tiene un Intent Bitmap, de tipo Internal.
<pre>alegrome# mdadm –detail /dev/md0
/dev/md0:
Version : 00.90.03
Creation Time : Thu Jul 26 20:23:13 2007
Raid Level : raid1
Array Size : 5242816 (5.00 GiB 5.37 GB)
Device Size : 5242816 (5.00 GiB 5.37 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Thu Jul 26 20:23:13 2007
State : active, resyncing
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Rebuild Status : 16% complete
UUID : 033b325e:a16cc48f:ef996995:ee57cd33 (local to host alegrome)
Events : 0.1
Number Major Minor RaidDevice State
0 253 17 0 active sync /dev/dm-17
1 253 18 1 active sync /dev/dm-18
alegrome# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 dm-18[1] dm-17[0]
5242816 blocks [2/2] [UU]
[======>..............] resync = 31.4% (1648640/5242816) finish=3.7min speed=15863K/sec
bitmap: 160/160 pages [640KB], 16KB chunk
unused devices: <none>
</pre>
* Como podemos ver, esta primera reconstruccion del raid es total. Creamos de nuevo y montamos el filesystem y empezamos a generar actividad en el filesystem (para que se modifique el bitmap).
<pre>
alegrome# mke2fs -j /dev/md0
alegrome# mount /dev/md0 /mnt/prueba
alegrome# while true; do date > /mnt/prueba/traza; sleep 5; done &
[1] 7859
</pre>
Esperamos a que se haya acabado de construir el raid (ver mdstat), y probamos de nuevo el fallo de un lvol:
<pre>
alegrome# mdadm /dev/md0 -f /dev/vg01/lv02 -r /dev/vg01/lv02
mdadm: set /dev/vg01/lv02 faulty in /dev/md0
mdadm: hot removed /dev/vg01/lv02
</pre>
* Ahora reañadimos el lv02 que habiamos quitado: el raid se va a reconstruir. En seguida miramos el estado del mismo:
<pre>
alegrome# mdadm /dev/md0 -a /dev/vg01/lv02
mdadm: re-added /dev/vg01/lv02
alegrome# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 dm-18[1] dm-17[0]
5242816 blocks [2/2] [UU]
bitmap: 5/160 pages [20KB], 16KB chunk
unused devices: <none>
</pre>
<b>El raid esta casi instantaneamente reconstruido!</b>
Esto es gracias al bitmap de write intent: al escribir en el md0 degradado, el sistema ha marcado en ese mapa los bloques que modificaba. De este forma, al resyncronizarlo, solo ya sabia que no era necesario resyncronizar todo, sino solo estos bloques. Como podemos ver, el intent log optimiza mucho la resyncronizacion del raid!
Recent Comments