Configuraciones RAID y LVM en Debian Linux

Hoy tengo una nueva batallita que contaros sobre configuraciones RAID y LVM en un Debian Lenny (testing). Ya tocaba porque hacia bastante que funcionaba sin ningún problema y eso "no puede ser normal".

Bromas aparte os recuerdo un poco como está configurada esta máquina:

El servidor incorpora 5 discos duros bastante variados: 1 de 300 GB, 2 de 320 GB y 2 de 500 GB.

El motivo de esta variedad es porque a medida que van fallando o puedo ir ampliando discos los voy sustituyendo por otros de mayor capacidad lo que me permite ir aumentando la capacidad disponible, sobre todo teniendo en cuenta que sobre el software RAID utilizao LVM para gestionar particiones.

El problema me lo he encontrado ahora que he reiniciado la máquina, pero se generó hace ya semanas con un cambio que realicé (y para el que no reinicié en su momento ya que no era necesario).

Antes de ese cambio tenia dos unidades software RAID, md0 y md1. La primera es un simple RAID 1 para /boot sobre 3 dispositivos. El segundo es más interesante, un RAID 5 sobre 5 particiones de cada uno de los discos.

El cambio fue sustituir 2 discos de 320 GB por los actuales 2 de 500 GB y para ir aprovechando el espacio (hasta que pueda disponer de todos en 500GB) utilizaré el espacio sobrante de los de 500GB para crear un RAID 1 de dos particiones.

Bueno, nada más facil. Creé el RAID con mdadm, lo convertí en unidad física LVM con pvcreate y lo añadí a un grupo existente (vg0). Todo funcionaba correctamente hasta que hoy he reiniciado la máquina y me he encontrado que no arranca quejándose de que no puede montar la partición raiz (y unas lineas más arriba el LVM se queja que le falta un dispositivo).

El problema está en que si bien LVM si que hace un escaneo total de todas las particiones y busca las unidades y dispositivos físicos, el software raid se basa en el fichero /etc/mdadm/mdadm.conf para construir los arrays aunque los pueda detectar automáticamente. El problema es que el arranque del Debian me deja un mínimo sistema (busybox) en el que no dispongo del LVM aunque si del mdadm.

Lo siguiente es arrancar con un CD (en este caso tras un kubuntu que no lleva mdadm ni lvm y un debian-installer antiguo que no me reconoce una controladora SATA PCI-Express) acabo consiguiendo arrancar con una imagen nueva del Debian-Installer para testing. Con eso consigo entrar por linea de comandos, construir la unidad y el lvm y acceder a mi /etc.

Una vez en /etc puedo ya editar el mdadm.conf y poner el nuevo array. Grabo fichero, rearranco, y sigue igual. ¡Claro! El mdadm.conf es una de las partes que se copian en la imagen de arranque en memoria (el llamado initramfs). Así que además de modificar el mdadm.conf tengo que actualizar ese initramfs.

Así que vuelta a arrancar con el CD, monto de nuevo la partición raiz y el /var que también necesito, y ejecuto update-initramfs -ut para actualizar la última versión del kernel. De momento no los actualizo todos para probar... no sea el caso que rompamos algo.

Reinicio para probar y arranco con el último kernel. Y ahora si, todo perfecto (aunque con tanto ir y venir el RAID se ha quejado y está reconstruyendo la unidad).

Así que la moraleja de hoy es: si añades un array con mdadm y quieres tenerlo disponible al arrancar, recuerda ejecutar update-initramfs.

Actualización 6/6/08: Para generar fácilmente el fichero mdadm.conf podemos utilizar el comando mdadm --examine --scan

Rendimiento de software RAID sobre Linux (2)

Continuamos las pruebas, ahora le toca el turno a el RAID10 sobre 4 discos (por si el número par afecta en algo):

Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
ns1 4G 64797 96 119486 21 48358 12 61408 95 98698 13 430.2 1
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 2734 7 +++++ +++ 2172 4 3093 10 +++++ +++ 1695 5

Rendimiento (E/L): +77% / +34%

Configuración con 4 discos en RAID1+0:

Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
ns1 4G 65864 98 114191 23 42419 11 59552 97 124150 21 495.5 1
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 3248 12 +++++ +++ 2530 7 3060 13 +++++ +++ 1801 6

Rendimiento (E/L): +69% / +69%

Para los interesados, esta configuración la he construido con estas órdenes:

mdadm --create -n 2 -l 1 /dev/md1 /dev/sdb2 /dev/sdd2 --size 5000000
mdadm --create -n 2 -l 1 /dev/md3 /dev/sdc2 /dev/sda2 --size 5000000
mdadm --create -n 2 -l 0 /dev/md4 /dev/md1 /dev/md3
mkfs.xfs /dev/md4 -f
mount /dev/md4 test

Y ahora una prueba que es la que realmente me ha pasado por la cabeza como candidata, y para la que he realizado las pruebas. Montar RAID1 + LVM con stripping para simular RAID0. Ya que de todas formas voy a utilizar LVM quizás pueda aprovecharlo para obtener un buen rendimiento con una excelente flexilibilidad:

Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
ns1 4G 66600 97 114477 24 44862 15 53496 95 120469 29 397.6 1
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 4115 24 +++++ +++ 4197 0 5103 28 +++++ +++ 1958 7

Rendimiento (E/L): +69% / +64%

Y finalmente poniendo todos los datos juntos, junto con la eficiencia de disco y el número de discos usados:

• RAID5(5): +47% / +113% / 80%
  
• RAID1(5): -17% / -9% / 20%
  
• RAID10(5): +108% / +77% / 50%
  
• RAID10(4): +69% / +69% / 50%
  
• RAID1+LVM(4): +69% / +64% / 50%
  

¿Adivináis el que he escogido?

Actualizado (9/2/07): adjunto tabla resumen.

Nivel RAID	Discos	Escritura	Lectura	% Espacio	% Escritura	% Lectura
N/A	1	67512	73633	100	100%	100%
5	5	99400	157120	80	147%	213%
1	5	55983	67411	20	83%	92%
10	5	140498	130574	50	208%	177%
10	4	119486	98698	50	177%	134%
1+0	4	114191	124150	50	169%	169%
1+lvm(0)	4	114477	120469	50	170%	164%

Estabilidad y rendimiento de software RAID en Linux

Ha llegado el momento de renovar un servidor linux que, entre otras tareas, actua de servidor de ficheros. Así que necesita mucha capacidad y también un buen rendimiento. Los ficheros son pocos pero grandes. Hablamos de centenares de gigas, así que se mueve mucha información mediante red gigabit.

Para el nuevo servidor quiero probar diferentes configuraciones de RAID y LVM en cuanto a rendimiento. Ya que he de hacerlo yo mismo, he pensado compartir los datos por si a alguien le sirven. Que quede claro que las pruebas no son en absoluto cientificas, sino una burda aproximación para ayudar a tomar una decisión sobre la configuración.

Primero, la configuración hardware de la nueva máquina:

• Placa base: Asus A8V-E SE
• Procesador: Athlon 64 X2 4600+ (2 x 2.4 GHz)
• Memoria: 2 GB DDR 400 (dual channel)

En cuanto a discos, la placa dispone de 2 conectores SATA y 2 PATA. He añadido una controladora PCI para 2 SATA adicionales (Conceptronic). Actualmente hay 5 discos duros, una mezcla variada. Como digo, la prueba dista de ser muy válida salvo como un ejemplo más. Hay discos de 300GiB y de 320GiB, de 8 y 16 MiB de cache y tanto PATA como SATA. Las marcas son Maxtor y Seagate.

Bien, lo primero es probar la estabilidad de la máquina para comprobar placa, procesador, memoria, discos y controladoras. Para ello, utilizo el paquete stress de Debian. Por cierto que el sistema instalado es Debian Etch (en testing actualmente) utilizando el instalador RC1. La arquitectura escogida es AMD64. He actualizado al último kernel, 2.6.18.

La prueba de stress con múltiples trabajos de CPU, memoria, IO y disco ha funcionado sin problemas durante 10 horas seguidas (aunque la caja y la fuente de alimentación se han calentado considerablemente).

Como sistema de ficheros utilizo XFS. Para las pruebas de rendimiento de disco hecho mano del paquete bonnie++.

Aquí van los primeros resultados:

Configuración con 5 discos en RAID5:

Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
ns1 4G 61606 95 99400 26 38831 16 53337 93 157120 43 511.5 1
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 1843 8 +++++ +++ 1732 7 1806 7 +++++ +++ 751 4

Configuración con 5 discos en RAID1:

Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
ns1 4G 54048 80 55983 9 27978 5 63971 95 67411 6 645.1 1
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 3070 3 +++++ +++ 2462 0 2960 2 +++++ +++ 1023 2

Configuración con 5 discos en RAID10:

Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
ns1 4G 66499 98 140498 24 48772 12 58759 90 130574 18 611.0 1
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 3313 9 +++++ +++ 2528 4 3658 9 +++++ +++ 2401 5

Bien. Obviamente en cuanto a espacio de disco RAID5 ofrece la mayor capacidad (N-1), RAID1 la peor (1) y RAID10 un término medio (aprox. N/2).

Para tener una referencia ejecuto el mismo test sobre uno sólo de los discos:

Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
ns1 4G 60706 92 67512 14 30783 5 55824 84 73633 5 212.6 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 375 2 +++++ +++ 299 1 358 2 +++++ +++ 208 1

En rendimiento un poco lo esperado. Para escritura / lectura:

• RAID5: +47% / +113%
  
• RAID1: -17% / -9%
  
• RAID10: +108% / +77%

Continuará...

RAID5 vs RAID10 (o RAID6...)

En mis lecturas de diversos documentos relacionados con sistemas RAID he encontrado algunos detractores de los sistemas RAID5 frente a sistemas como RAID10 o otros.

Por ejemplo, este artículo incluso viene en la documentación del paquete 'mdadm' de Debian: RAID5 vs RAID10.

Para los interesados en discusiones sobre la idoneidad de tal o cual sistema RAID os aconsejo la página web originaria del artículo, BAARF.

Yo de momento aún no me pronuncio... no lo veo del todo claro, pero estoy planteandome diversas opciones.

Discos de repuesto

Soy bastante paranoico, lo se. Quizás tenga razón. Así que al montaje que ya tenia en mi servidor he añadido recientemente otro disco duro más que actua como disco de repuesto (spare disk).

Previamente habian 3 discos de 300G y he añadido otro igual. Para hacer la partición idéntica he utilizado sfdisk. Con una orden para extraer la partición de un integrante actual del RAID:

sfdisk -d /dev/sda > sda

Y otra orden para aplicar el mismo esquema al nuevo disco (sdb):

sfdisk /dev/sdb <>

Y ahora tan sólo nos queda añadir las diferentes particiones. Se utiliza la misma orden siempre, tanto para añadir discos que reemplazan a defectuosos como en este caso discos de repuesto. El sistema mdadm conoce el tamaño del array y cualquier dispositivo adicional que se incluya se convierte automáticamente en un repuesto. Por tanto:

mdadm --add /dev/md0 /dev/sda1

El resultado final queda plasmado con la salida de /proc/mdstat:

Personalities : [raid5] [raid4] [raid1]
md0 : active raid1 sdb1[3](S) sda1[0] hdg1[2] hdc1[1]
96256 blocks [3/3] [UUU]

md1 : active raid5 sdb2[3](S) sda2[0] hdg2[2] hdc2[1]
979712 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

md2 : active raid5 sdb3[3](S) sda3[0] hdg3[2] hdc3[1]
584926464 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

unused devices:

Y falló un disco

O... la prueba real de la configuración RAID de mi servidor.

Pues si, el primer disco (hda) de los tres que componen el RAID5 (hda,hdc,hdg) ha dicho que no quiere trabajar más. Sin problemas, recibo un email del monitor de RAID avisándome que el disco está fallando y lo saca del RAID.

Bien, el siguiente paso lógico es comprar un nuevo disco para sustituir al afectado. Voy a comprar otro disco de 300G pero sólo encuentro SATA. No importa, le enchufo una controlador SATA PCI, le conecto el nuevo disco (sda), quito el defectuoso (hda) y arranco de nuevo la máquina... y no arranca.

Momento de pánico...

Bien, no aparece nada en pantalla, o sea no carga ni el bootloader (GRUB). Así que sospecho que el problema está en que justamente ha fallado el disco principal (hda). Lo vuelvo a conectar y por suerte el disco no estaba totalmente irrecuperable y logro arrancar el sistema de nuevo.

Al parecer lo que indiqué en el artículo anterior no es del todo correcto. Curiosamente creí haberlo probado convenientemente. Al final mediante el wiki de Gentoo (aunque uso Debian) probé el mecanismo alternativo de configurar GRUB. Arranqué y funcionó.

Así que tengo dos teorias:

• El procedimiento que utilicé originalmente no es correcto y lo probé mal.
• El procedimiento original era correcto pero con los cambios de kernel y actualizaciones automáticas del GRUB se debería volver a ejecutar con cada actualización de kernel.

¿Alguna idea?

Backups personales: ¿obsesión o necesidad?

Llego a través de Microsiervos a un artículo de Mark Pilgrim sobre copias de seguridad a largo plazo. Aunque yo no genero tanta información como esta persona (que básicamente veo que es un problema de video digital) estoy igualmente preocupado por el tema.

Sin embargo Mark enfoca el problema desde un punto de vista de archivo de datos. Si bien la persistencia de datos a largo plazo es importante, creo que vista la evolución de la tecnologia es más fácil (y económico) mantener siempre todos los datos disponibles.

La idea es no tanto ir haciendo copias de seguridad y guardarlas protegidas, como crear una infraestructura para ir acumulando los datos. Una infraestructura suficientemente escalable, por supuesto.

Mi complejo (creo que excesivamente a veces) sistema de copias de seguridad funciona más o menos así:

Dispongo de un equipo de trabajo habitual bajo Windows XP con un sólo disco duro de 74 GB (un WD Raptor). También un servidor doméstico bajo Linux que ofrece servicios de conexión a internet, cortafuegos, servidor de ficheros, etc. Este servidor funciona actualmente con 3 discos de 300 GB en RAID5 (o sea unos 600 GB de almacenamiento).

En el linux ejecuto el software BackupPC del que ya he hablado anteriormente. Eso mantiene copias de seguridad del PC con Windows sobre los discos RAID del Linux.

Mediante alertas en mi Palm Tungsten T3 programo copias de seguridad de este repositorio en DVD. Tengo dos alertas, una para copias que dejo en un armario y otra para copias que llevo a casa de mis padres. Actualmente hago una copia al mes y consume 4 DVD-R.

Con estas copias sólo cubro documentos y algunas otras cosas. Todo muy importante, por supuesto, pero no de gran tamaño. Es más la copia de seguridad útil para restaurar el sistema tras algún desastre.

En el servidor también guardo, por ejemplo, todas las fotos digitales que voy haciendo. Eso son más de 20 GB actualmente. Seria el equivalente a los videos de Mark pero en otra escala. La idea es no tener que grabarlos a DVD... ¿para que? Lo único que hago es, además de tenerlo en el Linux con RAID, replicar todo el directorio de fotos con rsync via internet a un servidor remoto.

Con lo cual para solucionar su problema sólo necesita 2 servidores. Puede configurarse un Linux con RAID + LVM. Con LVM podrá ir añadiendo discos en el futuro. Podria empezar por 3 discos de 750GB por ejemplo. Ya tendria 1'5 TB. Entre sí puede sincronizarse con rsync en segundo plano con ancho de banda controlado (para no saturar su conexión). Cuando llene los discos no tiene más que añadir 3 discos del tamaño que exista en ese momento y opcionalmente quitar los otros tras el cambio (es factible de hacer con LVM escogiendo un fs adecuado). Podria ser perfectamente posible disponer de 3 discos de 3 TB en unos pocos años, pasando de 1'5 TB a 6 TB. Por un precio "razonable".

¿Algún otro paranoico de las copias de seguridad?

Debian RAID

En mi despacho en casa dispongo de un servidor Debian Linux que hace multitud de tareas. Desde conexión a internet con cortafuegos (iptables), servidor de ficheros (samba), backups (backuppc), gestión de la red (bind, dhcp), copias de seguridad entre servidores (rsync), descargas p2p (mldonkey) y muchas más cosas que seguro que me olvido ahora mismo.

Se trata de un simple PC, concretamente mi antiguo PC ahora que tengo mi flamante Athlon. Dispone de un disco duro de 160G pero que esta muy justo y ya lo he tenido que cambiar una vez porque petó (y perdí los datos tuve que recurrir a las copias de seguridad, que le vamos a hacer).

Por eso he optado por reinstalar el sistema con mayor capacidad y, sobre todo, fiabilidad. He comprado 3 discos duros de 300G y la idea es montarlo todo sobre RAID.

Antes de ponerme con el servidor, he pillado un PC que había por aquí y lo he utilizado para hacer pruebas (con los 3 discos intentar instalar un Debian).

Tras muchas búsquedas por internet parece que lo de poner un RAID para todas las partes del sistema, especialmente el arranque, no es fácil. Más aún ya que yo quiero RAID 5 para disponer de 600G efectivos de capacidad.

Bien, la configuración que me ha quedado finalmente es la siguiente:

Todos los discos con estas 3 particiones:

• 100M
• 500M
• resto (unos 298G)

Con esto construyo tres unidades RAID:

• /dev/md0 en RAID1 con las tres particiones de 100M para /boot (100M)
  
• /dev/md1 en RAID5 con las tres particiones de 500M para swap (1G)
• /dev/md2 en RAID5 con las tres particiones de 298G para / (597G)
  

Bien, la primera en la frente: pese a lo que podáis leer por ahí, el Debian Installer no lo tiene tan sencillo para instalar un sistema sobre RAID. Primero probé con el último nightly build que en este momento era la beta 2 de Etch. Lo instalaba pero no arrancaba (al parecer generaba mal el initrd). El instalador de la versión Sarge (estable) tampoco funciona, parecía que si pero al arrancar no podia montar los RAIDs. Finalmente el instalador que me ha funcionado ha sido el Etch beta 1.

¿Cual es el problema de instalar y arrancar sobre RAID?

El problema está básicamente en que habitualmente el kernel carga los módulos de RAID (md, raid1, raid5) como eso... módulos. Por tanto, ha de leerlos de disco... círculo vicioso. Hay dos soluciones posibles: compilar un kernel con soporte incluido de RAID o crear un ramdisk con los módulos para que se pueda cargar.

Otro problema es que tanto la imagen del kernel como el ramdisk estan en /boot así que ... ¿como vamos a poner eso en RAID?
La respuesta es que en realidad no podemos... Sin embargo, tanto LILO como GRUB tienen soporte básico para RAID1 porque en realidad un RAID1 hace que todos los discos tengan lo mismo. De ahí que /boot sea un RAID1 y no un RAID5. Y sí, RAID1 no es exclusivo de 2 discos... puedes hacerlo sobre el número de discos que quieras.

Así que lanzando el Debian Installer simplemente hemos de particionar manualmente los discos con, según mi ejemplo, las tres particiones iguales en los tres discos. Luego, generamos los 3 dispositivos md y les asignamos los sistemas de ficheros correspondientes.

Con esto ya tenemos la redundancia que queríamos. Sin embargo, el gestor de arranque (en mi caso GRUB) sólo está instalado en el MBR del primer disco. Eso hace que si falla el primer disco, no podamos arrancar el sistema. Para solucionar esto nada más sencillo que marcar los otros MBR con el grub. Simplemente al arrancar el sistema normalmente entramos en el prompt de grub (ejecutando 'grub' como root) y ejecutamos los siguientes comandos:

• root (hd1,0)
• setup (hd1)
• root (hd2,0)
• setup (hd2)
• quit

Lo único que nos falta es que, según las prueba de stress que he ido realizando (en plan parar discos) hay veces que el RAID parece 'olvidar' un disco pese a que lo volvemos a reconectar. Supongo que es un mecanismo de seguridad. El procedimiento para añadir una partición a un dispositivo es, sin embargo, muy sencillo:

Lo primero es comprobar el estado en /proc/mdstat o con la orden

mdadm -QD /dev/mdX

Y para añadir las particiones que nos falten:

mdadm --manage -a /dev/md2 /dev/hda3

¡Suerte con vuestros intentos!

La importancia de un buen RAID

O la desgracia de no tener uno. Ayer estuvimos de traslado de servidor por el fallo inminente del un disco duro. Por suerte esta página (y el resto de servicios alojados en esa web) no sufrieron más que un corte de pocas horas.