Software-RAID HOWTO

Jakob Østergaard jakob@unthought.net y Emilio Bueso bueso@vives.org v.0.97, 23 de Diciembre de 2003

Este HOWTO ilustra el uso del RAID por software en sistemas Linux. Se basa en una versión específica de la capa de RAID por software (concretamente, la 0.90), diseñada por Ingo Molnar y otros. Hablamos de la capa standard en Linux-2.4, también utilizada en los núcleos 2.2 de algunos distribuidores. Además, esta versión 0.90 que vamos a tratar aquí también puede dar soporte (mediante el uso de varios parches) a los viejos núcleos 2.0 y 2.2 de Linux, puesto que, a menudo, resulta "bastante más estable" que todas las implementaciones RAID anteriores.

Contents

1 Introducción

Este HOWTO ilustra el uso del "nuevo estilo" de RAID que podemos encontrar en los núcleos 2.4. Y no cubre el "viejo estilo" de soporte RAID que venía con los núcleos 2.0 y 2.2 standard.

El web oficial de este documento está en http://unthought.net/Software-RAID.HOWTO/ , donde podréis encontrar las versiones más actualizadas. Este HOWTO fue originalmente escrito por Jakob Østergaard, a raíz de un considerable número de e-mails que cruzados entre él y gente como Ingo Molnar

(uno de los desarrolladores del soporte RAID de Linux) o algunos miembros de la linux-raid mailing list . Finalmente, Emilio Bueso coescribe la versión 1.0 y la traduce al castellano.

Los que queráis usar este soporte moderno de RAID por software con los núcleos 2.0 o 2.2, sólo tenéis que conseguir un parche adecuado para vuestro núcleo en http://people.redhat.com/mingo/ , puesto que los núcleos standard 2.2 no poseen un soporte directo para esta nueva generación de RAID que vamos a tratar en el presente documento. Además, el antiguo soporte RAID de los núcleos 2.0 y 2.2 standard es defectuoso y carece de varias funcionalidades relevantes que podéis encontrar en los soportes modernos de RAID.

Una cosa más para los que ya sabéis algo de sistemas RAID: encontrareis que aquí vamos a abordar todo cuanto cabe esperar de un HOWTO que no presupone en ningún momento que el lector ya está familiarizado con la tecnología que nos atañe. Así que si alguna sección os parece trivial, simplemente pasad a la siguiente. El objetivo final de este documento es cubrir absolutamente todo lo que un administrador de sistemas necesita saber si quiere implementar una solución RAID por software sobre Linux, empleando lo último en tecnología a tal efecto, así que los que ya conocéis RAID a fondo, también encontrareis material interesante, como el soporte a herramientas como mdadm o las nuevas raidtools.

1.1 Advertencia

La consabida advertencia

Toda la información aquí presente no implica ni supone garantía alguna, así que si alguno de vosotros pierde todos sus archivos, pierde su empleo, pierde a su novia, es atropellado por un camión de ocho ejes... no es culpa nuestra. No es culpa de los autores de este documento ni de los desarrolladores del software RAID que estéis usando. Os damos por informados de que estáis usando este HOWTO por vuestra cuenta y riesgo, sin garantía alguna que os respalde. Tampoco podéis suponer que en este documento no hay error alguno (aunque nosotros los autores, hemos ido con cuidado que no equivocarnos demasiado) o que aquí vais a encontrar cobertura documental a todas vuestras demandas (aunque hayamos ido con cuidado de no dejarnos nada importante en el tintero).

Es extremadamente importante que hagáis un backup entero de vuestros ordenadores antes de poneros manos a la obra con esto del RAID. Y si creéis que esto lo pone en todos los HOWTO, sabed que para montar un sistema RAID por software vais a trabajar con sistemas de archivos y particiónes enteras... y en ese contexto, un fallo tonto y, zas! ...acabáis de hacer desaparecer el sistema al completo.

1.2 ¿Qué es RAID?

En 1987, la Universidad de Berkeley (California), publicó un artículo describiendo varios tipos de arrays de discos, acuñando en el proceso el término RAID (acrónimo de Redundant Array of Inexpensive Disks). Básicamente, la idea era combinar múltiples discos [duros] independientes y pequeños en un array (o matriz) de disco capaz de alcanzar un rendimiento superior al de un sólo disco grande y caro... en otros términos, se pretendía hacer trabajar varios discos modestos como un disco profesional de alto rendimiento. Adicionalmente, el array de discos aparece ante el sistema como un disco lógico único.

El tiempo transcurrido entre errores (MTBF) para el array de discos es, en el modelo teórico de la Universidad de Berkeley, igual al MTBF de un disco individual dividido por el número de discos presentes en el array. Esto se consigue alcanzando una cierta tolerancia a errores que pasa por guardar la información redundantemente de varios modos.

En aquel documento original, también nacieron cinco tipos de arquitecturas RAID: desde RAID-1 hasta RAID-5 fueron definidas entonces, cada una de ellas proporcionando diferentes niveles de tolerancia a errores de disco y rendimientos. Después de aquello, también se ha ido poniendo de moda el término RAID-0 para designar los arrays de discos no redundantes.

Hoy en dia, algunos de los niveles RAID originalmente definidos (concretamente, los niveles 2 y 3) son solo utilizados en sistemas muy especializados (hasta el extremo de que el RAID por software de Linux ni siquiera los soporta!). También ha ido apareciendo un nuevo nivel denominado "lineal", y se ha ido haciendo frecuente esto de ver el nivel 0 combinado con el nivel 1... pero nos estamos desviando.

1.3 Términos

La palabra "RAID" aquí significa "RAID por software de Linux". Este documento no trata ningún aspecto de RAID por hardware.

Cuando se describen configuraciones, es útil referirse al número de discos y sus tamaños. En todos los casos se usa la letra N para denotar el número de discos activos en el array (sin contar los discos de reserva). La letra S es el tamaño del disco más pequeño en el array, a menos que se diga otra cosa. La letra P representa el rendimiento de un disco en el array, en MB/s. Cuando se use, supondremos que los discos son igual de rápidos, que no siempre puede ser cierto.

Note que se supone que las palabras "dispositivo" y "disco" significan lo mismo. Normalmente, los dispositivos usados para construir un dispositivo RAID son particiónes de discos, no necesariamente discos enteros. Pero, normalmente, combinar varias particiónes de un disco no tiene sentido, por lo que las palabras dispositivo y disco simplemente significan "particiónes de discos diferentes".

1.4 Niveles RAID

Ahora viene una breve descripción de los niveles RAID que soporta la capa de RAID por software de Linux. Buena parte de esto que vamos a ver son sólo los fundamentos teóricos de los sistemas RAID. Y ahora es cuando os saltáis esta sección los que ya conocéis RAID. Ya volveréis luego, cuando tengáis problemas, malditos. :)

El soporte RAID de Linux incorpora los siguientes niveles:

• Modo lineal

– Dos o más discos se combinan en un único dispositivo físico. Los discos se suceden marcialmente unos detrás de otros de tal manera que las escrituras en el dispositivo RAID primero llenarán el disco 0, a continuación el disco 1 y así sucesivamente. Los discos no tienen por qué ser del mismo tamaño. Ya se sabe, el tamaño no importa. :)

– No existe redundancia alguna en este nivel. Si un disco falla perderéis todos vuestros datos con toda probabilidad. También puede ser que os toque la lotería y podáis recuperar algunos datos, ya que el sistema de ficheros simplemente habrá perdido un gran puñado de datos consecutivos.

– El rendimiento de las lecturas y las escrituras no mejora en las lecturas/escrituras individuales, pero si varios usuarios usan un mismo dispositivo, tal vez tengáis la suerte de que un usuario use efectivamente el primer disco y otro usuario acceda a ficheros que por casualidad residan en el segundo disco. Si esto ocurre, es de esperar una mejora significativa en los rendimientos.

• RAID-0

– También llamado modo "stripe" o "rayado". Es como el anterior, salvo que las lecturas y escrituras se realizan en paralelo en los dispositivos. Los dispositivos deben tener aproximadamente el mismo tamaño. Puesto que todos los accesos se realizan en paralelo, los discos se llenan por igual. Si un dispositivo es mucho mayor que los otros dispositivos, el espacio extra todavía se utilizará en el dispositivo RAID durante las escrituras en el extremo superior del dispositivo RAID, aunque sólo se accederá a este disco más grande. Naturalmente, esto perjudica el rendimiento.

– Como en el modo lineal, tampoco hay redundancia en este nivel. A diferencia del modo lineal, no vais a recuperar ningún dato si un disco os falla aquí. Si elimina un disco de un grupo RAID-0, el dispositivo RAID no perderá simplemente un bloque consecutivo de datos, sino que se llenará con pequeños agujeros por todo el dispositivo. Imaginad vuestro disco duro raíz convertido en un colador (e2fsck no es capaz de recuperar gran cosa de ahí, os lo aseguro) y ahora es cuando corréis todos a hacer esos backups. Por fin.

– El rendimiento de las lecturas y las escrituras mejora siempre, ya que las lecturas y las escrituras se realizan en paralelo sobre los dispositivos. Normalmente, ésta es la razón principal para usar RAID-0. Si los buses a los discos son suficientemente rápidos, puede obtener casi N*P MB/seg.

• RAID-1

– Este es el primer modo que incorpora redundancia. RAID-1 se puede usar en dos o más discos con cero o más discos de reserva. Este modo mantiene en un disco un duplicado exacto de la información en el otro(s) disco(s). Por supuesto, los discos deben ser del mismo tamaño. Si un disco es mayor que otro, su dispositivo RAID será del tamaño del disco más pequeño.

– Si se eliminan (o fallan) hasta N-1 discos, todos los datos todavía permanecerán intactos. Si existen discos de reserva disponibles y el sistema (es decir, las controladoras SCSI o los chipsets IDE, etc.) sobreviven al desastre, comenzará inmediatamente la reconstrucción de un duplicado en uno de los discos de reserva, después de la detección del fallo del disco.

– Normalmente, el rendimiento de las lecturas aumenta hasta casi N*P, mientras que el rendimiento de las escrituras es el mismo que el de un único dispositivo o, tal vez, incluso menos. Las lecturas se pueden hacer en paralelo pero, cuando se escribe, la CPU debe transferir N veces la cantidad de datos que normalmente transferiría (recordad, se deben enviar N copias idénticas de todos los datos a los discos). Esto último es un problema cuando el array RAID-1 es grande de verdad, puesto que el bus PCI puede saturarse al transportar todas esas copias redundantes de datos (apunte interesante: el colapso del bus PCI es uno de esos escasos problemas que se pueden resolver mediante el uso de soluciónes RAID por hardware).

• RAID-4

– Este nivel de RAID es raro de ver. Se puede usar sobre 3 o más discos. En lugar de duplicar completamente la información, se guarda información de paridad en un único disco y escribe datos a los otros discos de forma parecida a un RAID-0. Ya que uno de los discos se reserva para información de paridad, el tamaño del array será (N-1)*S, donde S es el tamaño del disco más pequeño del array. Como en un RAID-1, los discos deben ser del mismo tamaño o de lo contrario tendrá que aceptar que el valor de S en la fórmula (N-1)*S anterior será el tamaño del disco más pequeño del array.

– Si un disco falla, se puede usar la información de paridad para reconstruir todos los datos. Si dos discos fallan, se perderán todos los datos.

– La razón por la que este nivel no se usa con mucha frecuencia es que la información de paridad se guarda en un único disco. Esta información se debe actualizar cada vez que se escribe en uno de los otros discos. Por eso, el disco de paridad se convertirá en un cuello de botella si no es mucho más rápido que los otros discos. Sin embargo, si por pura casualidad tuviera muchos discos lentos y un disco muy rápido, este nivel de RAID podría ser muy útil.

• RAID-5

– Este es quizás el modo RAID más útil cuando buscamos combinar un mayor número de discos físicos y todavía conservar alguna redundancia. RAID-5 se puede usar sobre 3 o más discos, con cero o más discos de reserva. El tamaño del dispositivo RAID-5 resultante será (N-1)*S, justo como en RAID-4. La gran diferencia entre RAID-5 y RAID-4 es que la información de paridad se distribuye uniformemente entre los discos participantes, evitando el problema del cuello de botella del RAID-4.

– Si uno de los discos falla, los datos sobreviven, gracias a la información de paridad. Si existen discos de reserva disponibles, la reconstrucción comenzará inmediatamente después del fallo del dispositivo. Si dos discos fallan simultáneamente, todos los datos se perderán. RAID-5 puede sobrevivir a un fallo de disco, pero no a dos o más.

– Lo normal sería que el rendimiento general de acceso a disco mejore sensiblemente en RAID-5, pero es difícil predecir en qué medida. Las velocidad en los accesos de lectura suele mejorar en la misma proporción que tenemos con los sistemas RAID-0, mientras que las lecturas pueden llegar a aproximarse a las cifras en RAID-1 o, por el contrario, más lentas (se requiere una lectura previa a la escritura para así poder calcular la información de paridad!). En definitiva, que la eficiencia en lecturas depende determinantemente de la cantidad de memoria RAM en la máquina y del uso que se haga del array... obviamente, un servidor donde cientos de usuarios escriban constantemente datos a disco lo va a pasar más mal que bien con RAID-5.

1.5 Requerimientos

Este HOWTO asume que estáis usando Linux 2.4 o superior. De todos modos, como decíamos antes, es posible usar RAID por software en núcleos 2.2.x o 2.0.x con los parches RAID y la versión 0.90 de las raidtools. Tanto los parches como las raidtools deberían de estar disponibles en http://people.redhat.com/mingo/ .

Los que uséis una distribución reciente basada en el núcleo 2.4 o superior probablemente descubriréis que ya tenéis una versión de las raidtools compatible con vuestro núcleo.

2 ¿Por qué RAID?

Los pájaros vuelan, el cielo es azul, seis por seis son treinta y seis, y los discos de ordenador dan problemas. Unas veces los discos se llenan (quedándose sin espacio libre y, por tanto, perdiendo la capacidad de almacenar información), y otras sencillamente dejan de funcionar (a veces, esto último supone la pérdida de cientos de archivos importantes).

Hablando en términos de informática de usuario convencional... de todos los componentes que hay en vuestros ordenadores, el que más sufre siempre es el pobre disco duro. Hablamos de un dispositivo que gira a algo así como diez mil vueltas por minuto durante horas y horas... se trata, sin lugar a dudas de lo primero que vais a tener que reemplazar en toda la vida útil del equipo, puesto que os durará bastante menos que cualquier otra pieza. También se os quedará pequeño rápidamente. Y ahí no terminan los males del disco duro convencional... resulta que también suele ser el componente más lento de toda la computadora, responsable habitual de esos relojes de arena con los que se os premia tan a menudo.

RAID pretende resolver toda esta problemática. Y, si se hacen las cosas bien, lo consigue. RAID puede acelerar vuestro acceso a disco, puede ahorraros la pérdida de datos cuando los discos fallen y puede proporcionar amplitud de espacio de almacenamiento a vuestros ordenadores aun cuando sólo dispongáis de discos pequeños.

Aún así, es muy importante comprender que RAID no es una alternativa a las copias de seguridad. Puede que algunas configuraciones RAID inmunicen a vuestros ordenadores de los fallos de un sólo disco, pero no sirven de nada contra un simple "rm -rf /". Tampoco os cubrirá las espaldas ninguna configuración RAID si la fuente de alimentación de vuestro ordenador se os vuelve loca y les suministra a todos esos discos duros redundantes tensión suficiente como para que ardan como una tea. Los cinco a la vez.

Y no nos hagáis hablar de lo que le pasa a una hermosa batería de discos duros redundantes en caso de incendio, inundación, terremoto, embestida por camión de ocho ejes, meteorito, guerra global termonuclear o usuario.

Insistimos una vez más, RAID casi nunca hace que una buena política de copias de seguridad sea menos necesaria.

2.1 Soporte de dispositivos y sistemas de archivos

El RAID de Linux puede trabajar en la mayoría de dispositivos de bloques. No importa si usáis dispositivos IDE o SCSI. Algunas personas han probado a usarlo con el Network Block Device (NBD) con más o menos éxito.

Y puesto que un dispositivo RAID por software de Linux es, en si mismo, un dispositivo por bloques, podéis crear RAIDs de otros dispositivos RAID. Esto es lo que hace posible soportar RAID-10 (RAID-0 de varios dispositivos RAID-1), simplemente combinando las funcionalidades de RAID-0 y RAID-1. También son posibles algunas configuraciones realmente exóticas, como las matrices de RAID-5 sobre RAID-5.

A ver, esto es importante de cara a la buena comprensión de los fundamentos sobre los que nos estamos moviendo... hay que disociar por capas: la capa RAID no tiene absolutamente nada que ver con la capa del sistema de archivos. Podéis meter cualquier sistema de archivos en un dispositivo RAID de la misma manera que lo haríais si trabajarais con cualquier otro dispositivo.

2.2 Rendimiento

A veces se aplica RAID a modo de solución a los problemas de rendimiento. Aunque es probable que RAID sea la solución que estéis buscando para acelerar el acceso a disco de vuestros sistemas, RAID tampoco es un bólido. Hay muchas formas de resolver los problemas de rendimiento de un ordenador, y RAID es sólo una más.

Echad, además, un vistazo al capítulo uno. Allí se abordaba el tema de los rendimientos de cada nivel RAID.

2.3 Swapping sobre RAID

No hay motivo alguno que justifique el uso de RAID para albergar las particiónes swap (memoria de intercambio) con la esperanza de así ganar rendimiento neto: el propio núcleo ya se las ingenia solito para bascular la carga de lectura/escritura a disco a lo largo de varios dispositivos, sólo tenéis que darles la misma prioridad en el /etc/fstab.

Un bonito ejemplo:

/dev/sda2       swap           swap    defaults,pri=1   0 0
/dev/sdb2       swap           swap    defaults,pri=1   0 0
/dev/sdc2       swap           swap    defaults,pri=1   0 0
/dev/sdd2       swap           swap    defaults,pri=1   0 0
/dev/sde2       swap           swap    defaults,pri=1   0 0
/dev/sdf2       swap           swap    defaults,pri=1   0 0
/dev/sdg2       swap           swap    defaults,pri=1   0 0

Esta configuración permite que el sistema haga swapping en paralelo a lo largo de nueve dispositivos SCSI. No hace falta RAID, entonces. Y, por cierto, que esto de la memoria de intercambio en paralelo ha sido una prestación del núcleo de Linux desde hace bastante tiempo ya.

Otro tema diametralmente distinto es la alta disponibilidad que queráis alcanzar... cuando se produce un fallo físico de consideración en el disco que alberga una partición swap activa y en funcionamiento, Linux simplemente se queda colgado. Aquí es donde hacer swap sobre una partición RAID-1 (con todas las consecuencias, recordad que RAID-1 ralentiza las operaciones de escritura con respecto a una configuración normal, sin RAID) os puede mantener el sistema en marcha. Dicho sea de paso, algunos administradores de sistemas no son partidarios de las soluciónes como esa: los sistemas de misión crítica (donde la tolerancia a un error de disco en el área de swapping es necesaria) pueden diseñarse para no necesitar de una partición swap nunca. Para eso "basta" con no quedarse sin memoria física jamás.

Aunque ha habido cierto debate acerca de si el swapping es estable sobre dispositivos RAID, a nosotros nos gustaría zanjar eso diciendo que hacer swap sobre RAID debería, en teoría, de ser perfectamente estable. Para salir de dudas os basta con correr tests de stress sobre un sistema ejemplo.

Vamos, que podéis hacer swap sobre RAID o RAID sobre swap, como os parezca. Nosotros insistimos con lo nuestro, esos dispositivos RAID son solo dispositivos por bloques.

2.4 ¿Por qué mdadm?

Las raidtools llevan siendo toda la vida el software standard para gestionar RAID en Linux, así que mdadm no es una herramienta estrictamente necesaria.

De todos modos, los que encontrais las raidtools enrevesadas o limitadas, encontrareis a mdadm (multiple devices administrator) extremadamente útil para gobernar los sistemas RAID. Lo podéis usar como una alternativa a las clásicas raidtools, o como suplemento, para llegar con él a donde no llegan las herramientas de siempre.

Hablamos de una herramienta escrita por Neil Brown , ingeniero de software en la Universidad de Nueva Gales del Sur y desarrollador del núcleo de Linux. Mdadm se encuentra en este momento en su versión 1.4.0 y se muestra agradablemente estable, habiendo recibido una respuesta muy positiva por parte de la linux-raid mailing list. Es bastante probable que mdadm se convierta en un futuro no muy lejano en una herramienta de uso generalizado a la hora de gestionar RAID en Linux.

Estas son las diferencias principales entre mdadm y las raidtools:

• mdadm es una herramienta de diagnóstico que proporciona informes detallados sobre los arrays del sistema

• mdadm puede funcionar como un daemon, monitorizando dispositivos RAID y enviando alertas de seguimiento a los administradores del sistema

• mdadm es un programa único y centralizado y no una colección dispersa de programas independientes, con todo lo bueno y lo malo que esto conlleva

• mdadm puede hacer su trabajo, gestionando todo cuanto necesitáis en vuestra plataforma de RAID por software sin tener que usar forzosamente un archivo de configuración

• ...y si queréis usar un archivo de configuración, mdadm os ayudará a mantener sus contenidos

3 Dispositivos

Insistimos, los dispositivos de RAID por software en Linux son dispositivos por bloques, al igual que los discos convencionales y cualquier partición que establezcamos sobre estos. Un dispositivo RAID se construye sobre un número determinado de otros dispositivos por bloques. Por ejemplo, un sistema RAID-1 podría levantarse usando dos discos ordinarios, dos particiónes de disco o dos sistemas RAID.

No hay requerimientos especiales para los dispositivos sobre los que construyáis vuestros sistemas RAID, y esto os da libertad total a la hora de diseñar vuestra propia solución RAID. Y puesto que, desde esta perspectiva, RAID es sólo un conjunto -o agrupación- de dispositivos, podéis dejar volar vuestro ingenio y crear auténticos conjuntos y subconjuntos de acorde con las necesidades que se os planteen.

En este documento nos vamos a referir mediante el término "dispositivo" a elementos como "discos", "particiónes" o incluso "dispositivo RAID". Vamos que un "dispositivo" en este HOWTO es simplemente un "dispositivo por bloques de Linux". Podría tratarse cualquier cosa, desde un disco SCSI a un dispositivo de red por bloques. A menudo, nos referiremos a este rango de "dispositivos" como "discos", porque, no nos engañemos, eso es lo que serán en la inmensa mayoría de los casos. De hecho, casi siempre se trata de discos duros.

Aun así, los dispositivos de vuestros sistemas, pueden jugar varios papeles distintos en esto del RAID. Puede ser "discos libres", podría tratarse de "discos erróneos" o podrían ser los habituales discos funcionales y sanos, en su actividad usual dentro del array.

Y ahora vamos a entrar en detalle acerca de los "discos libres" y los "discos erróneos".

3.1 Discos libres

Los discos libres (también denominados "discos de reserva") son los que no toman parte en un conjunto RAID hasta que falla uno de los discos activos. Cuando se detecta un fallo de dispositivo, el disco erróneo se marca como tal y es apartado de modo que no se vuelva a utilizar, a continuación el proceso de reconstrucción comienza en el primer disco libre disponible.

De esta forma, los discos libres aportan una bonita seguridad extra ante los errores de disco. Esto puede llegar a resultar muy interesante en las configuraciones más vulnerables ante los fallos de un disco, como la RAID-5, donde dos errores de disco consecutivos dan al traste con la información de todo el conjunto entero.

Os podéis también, gracias a los discos libres, relajar un poco más: esto de aportarle un disco libre de apoyo al conjunto RAID os permite dejar al sistema en funcionamiento durante algún tiempo con un disco erróneo, puesto que la redundancia la proporciona el antaño disco libre que toma el relevo de manos del disco que os haya fallado, asumiendo sus funciones.

Aun así, es muy importante que tengáis presente que vuestros ordenadores tal vez no sigan funcionando después de un fallo de disco. La capa RAID de Linux debería de ser capaz de gestionar los fallos de disco correctamente, pero tal vez el resto de componentes del sistema no lo hagan. Es posible que vuestros drivers SCSI tengan errores (quizás diseñarlos para resolver correctamente los miles de errores de disco posibles no haya sido algo prioritario!) a la hora de resolver los fallos físicos de disco. También es muy probable que esos chipsets IDE tan baratos que os habéis comprado :( respondan a un error de disco bloqueando todo el ordenador. Etc.

Más cosas a tener en cuenta, una vez la reconstrucción comienza, el sistema inserta un disco libre en la posición en la que se ha producido una baja. Para que el reemplazo sea efectivo, la capa RAID se pondrá a leer de los discos activos para regenerar la recién perdida redundancia. Si con el uso de los discos se han ido formando bloques erróneos (un fallo de disco habitual, chequead vuestros sistemas de archivos y lo veréis por vosotros mismos), el propio proceso de reconstrucción puede, a raíz de toda la agresiva lectura que conlleva, provocar un fallo en uno de los discos "buenos". Esto nos llevará de cabeza a un fallo RAID total. ¿Ahora es cuando os volvéis a plantear lo de hacer copias de seguridad con frecuencia? Nosotros os premiamos con más de lo mismo: recordad, RAID no es un sustituto de las copias de seguridad.

3.2 Discos erróneos

Cuando la capa RAID gestiona los fallos de dispositivos correctamente, los discos fallidos son etiquetados como tales y la reconstrucción empieza inmediatamente en el primer disco libre que se presente.

Los discos erróneos constan (si no son manualmente retirados del array) como miembros del conjunto RAID. La capa RAID se limita a tratar a los dispositivos marcados como erróneos como parte inactiva del array.

4 Aspectos relativos al hardware

En esta sección vamos a cubrir algunos de los aspectos relativos al hardware cuando se está aplicando una solución de RAID por software.

Los que estáis interesados en ganar rendimiento, deberíais de aseguraros de que los buses de vuestros discos sean lo bastante rápidos. No es buena idea eso de tener 14 discos UW-SCSI en un sólo bus si cada disco alcanza los 20 MB/s y el bus "sólo" puede sostener un total de 160 MB/s. Además, deberíais de poner un sólo dispositivo por bus IDE, puesto que la combinación maestro/esclavo de los buses IDE tiene un rendimiento lamentable, y es que IDE es una tecnología de disco realmente mala cuando tienes más de un disco por bus. Lo bueno es que las placas base de hoy en día vienen con dos buses IDE, y eso os permite montar un RAID de dos discos sin tener que comprar controladoras adicionales, que, por cierto, resulta que son muy baratas... así que, finalmente, montar un sistema con 6-8 discos es muy fácil y barato.

4.1 Configuración IDE

Es perfectamente posible (y habitual) implementar soluciónes RAID sobre discos IDE. Y se puede obtener también un rendimiento excelente con ellos. De hecho, el precio al que van los dispositivos y controladoras IDE hace que IDE sea una tecnología a tener en consideración cuando se trata de montar nuevos sistemas RAID.

• Estabilidad física: los dispositivos IDE han sido tradicionalmente componentes de menor calidad mecánica que los SCSI. Incluso hoy en día la garantía de los discos IDE es, generalmente, de uno o dos años, mientras tanto, es posible toparse con discos SCSI que ofrecen entre tres y cinco años de garantía. Aunque no está bien decir decirlo, por norma general, los discos IDE tienden a ser productos de baja calidad; basta con decir que los discos IDE de determinados fabricantes suelen fallar más a menudo que sus homólogos SCSI. Mientras tanto, otros fabricantes ya usan exactamente la misma configuración mecánica para los SCSI y los IDE. En cualquier caso, todo esto se reduce a una sola cosa: todos los discos fallan, más pronto o más tarde, y hay que estar preparado para asumir eso.

• Integridad de datos: abreviando, la ingeniería IDE no dispone de mecanismos para garantizar que los datos que se han enviado a través del bus serán exactamente los mismos que terminen por escribirse en el disco. Esto es porque la implementación de la que hablamos carece totalmente de chequeos de paridad. Con la aparición del standard Ultra-DMA, los dispositivos IDE modernos efectúan comprobaciones de integridad en los datos que reciben, y eso hace que esquive con mayor facilidad el fantasma de la corrupción de datos... aún así, el bus PCI no dispone de resortes para chequear la integridad de datos, y ese es el bus que usarán tanto las controladoras IDE como las SCSI.

• Rendimiento: no vamos a extendernos demasiado sobre el rendimiento IDE por ahora. Mejor lo dejamos en un breve resumen:

– Los dispositivos IDE son rápidos, aunque no tanto como sus contrapartidas en el mundo SCSI – IDE consume mayores recursos en vuestras CPU que SCSI (¿esto es importante?)

– Usad solamente un dispositivo IDE por bus IDE, los discos esclavos derrochan recursos

• Tolerancia a errores: el driver IDE de Linux generalmente sobrevive al fallo de un dispositivo. La capa RAID marcará entonces el disco como erróneo, y, si estáis empleando los niveles de RAID-1 o superior, el sistema debería de responder correctamente hasta que podáis ejecutar las tareas de mantenimiento correspondientes (como, por ejemplo, cambiar el disco erróneo por otro correcto).

Somos tan pesados que insistiremos hasta la saciedad: es muy importante que sólo uséis un disco IDE por bus IDE. No es sólo porque dos discos en un mismo bus rinden muy mal, sino porque el fallo de un disco, a menudo, supone el fallo del bus entero, y eso implica que fallan todos los discos del bus. En una configuración RAID tolerante a errores (niveles RAID 1,4 y 5) el fallo de un disco puede subsanarse, pero el fallo de dos discos en cadena motivado por un fallo general del bus IDE, arrastrará al array entero al desastre. Además, cuando el maestro del bus es quien falla, el disco esclavo (o la controladora) pueden quedar horriblemente confundidos, y eso tiene consecuencias aun más devastadoras. Un bus, un disco. Esa es la regla. Sin paliativos.

Hay a la venta controladoras IDE PCI baratas por ahí. A menudo, podéis encontrar tarjetas con dos o cuatro buses por unos 50 Euros. Si tenemos en cuenta que los discos IDE son mucho más baratos que los SCSI, un array de discos IDE puede fácilmente ser una solución apta si podéis conformaros con esas cifras relativamente bajas (sobre los ocho discos o así) en materia del número de dispositivos que podéis conectar a un sistema convencional.

IDE presenta serios problemas de cable cuando se trata de arrays grandes. Incluso si tenéis suficientes bancos PCI, es poco probable que podáis meter más de ocho discos en un sistema y mantenerlo en funcionamiento correctamente sin que se produzcan problemas de corrupción de datos debido a la longitud de los discos IDE.

Para colmo de males, algunos de los nuevos discos IDE que están saliendo a mercado ahora, vienen con restricción de disponibilidad, de forma que sólo pueden usarse un número determinado de horas al día. Estos discos están diseñados para su uso en entornos domésticos o de oficina (jornada laboral de ocho horas diarias), y esto os puede llevar a problemas severos (pérdida de la garantía del fabricante) si los usáis en un entorno de servidor, dentro de un array RAID 24/7.

4.2 Reemplazo en caliente (Hot swap)

Aunque el intercambio en caliente de los dispositivos está soportado hasta cierto punto, todavía no es algo que se pueda hacer fácilmente.

4.2.1 Reemplazo en caliente de dispositivos IDE

¡No lo hagáis! IDE no soporta en absoluto el reemplazo en caliente. Aunque podría funcionaros si compilarais vuestro driver IDE como módulo (sólo posible en la serie 2.2 del núcleo) y lo volvierais a cargar después de reemplazar el dispositivo, lo más probable es que terminarais con una controladora IDE frita y un tiempo de inactividad mucho mayor que el que simplemente habría consumido el reemplazar el dispositivo en un sistema apagado.

El principal problema, a parte de los temas eléctricos que pueden destruir vuestro hardware, es que se debe reexplorar el bus IDE después de que se hayan reemplazado los discos. El driver IDE actual no puede hacer eso. Si el nuevo disco es 100% idéntico al antiguo (geometría, etc.) puede que funcione incluso sin volver a explorar el bus pero, que os quede bien claro que, aun así, os la estáis jugando tontamente.

4.2.2 Reemplazo en caliente de dispositivos SCSI

El hardware SCSI normal tampoco es capaz de realizar un reemplazo en caliente. Sin embargo, puede que funcione. Si vuestro driver SCSI soporta la reexploración del bus y la conexión y desconexión de dispositivos, puede ser capaz de intercambiar dispositivos en caliente. Sin embargo, en un bus SCSI normal probablemente no deberíais desenchufar dispositivos mientras el sistema esté todavía encendido. Pero, insistimos, puede que funcione simplemente (y también puede que terminéis ¡friendo vuestro hardware!).

La capa SCSI debería sobrevivir si un disco muere, pero no todos los drivers SCSI soportan eso. Si vuestro driver SCSI muere cuando un disco cae, el sistema se caerá con él y la conexión en caliente no es que resulte muy interesante entonces.

4.2.3 Reemplazo en caliente con SCA

Con SCA, es posible reemplazar dispositivos en caliente. Desafortunadamente, esto no es tan sencillo como debería, aunque si que es posible y seguro.

Veamos un ejemplo:

• Volcamos la tabla de particiónes del disco, si es legible:

     sfdisk -d /dev/sdb > partitions.sdb

• Sacamos el disco que vamos a reemplazar en el array:

     raidhotremove /dev/md0 /dev/sdb1

• Echamos un vistazo al Host, Canal, ID y Lun del dispositivo a reemplazar, mirando en

     /proc/scsi/scsi

• Sacamos el disco del bus:

     echo "scsi remove-single-device 0 0 2 0" > /proc/scsi/scsi

• Comprobamos que el disco haya sido correctamente extraído, de nuevo miramos en

     /proc/scsi/scsi

• Desconectamos el disco de la bahía SCA, e insertamos uno nuevo

• Añadimos el nuevo dispositivo al bus:

     echo "scsi add-single-device 0 0 2 0" > /proc/scsi/scsi

¿Ya estáis oyendo como se enciende el disco?

• Reparticiónamos el disco, usando para ello la partición previamente salvada:

     sfdisk /dev/sdb < partitions.sdb

• Insertamos el disco en el array:

     raidhotadd /dev/md0 /dev/sdb2

Los argumentos del comando "scsi remove-single-device" son: Host, Canal, Id y Lun. Esos números los podéis encontrar en "/proc/scsi/scsi" El procedimiento descrito lo hemos ensayado en un sistema con discos IBM SCA y una controladora Adaptec SCSI. Si encontráis problemas o formas mejores de resolver esta cuestión, por favor, discutidlo en la linux-raid mailing list .

5 Configuración RAID

5.1 Configuración general

Esto es lo que necesitáis para cualquiera de los niveles RAID:

• Un núcleo. Preferiblemente, uno de la serie 2.4. Alternativamente la versión 2.0.36 o un núcleo 2.2.x reciente. No tenemos ni idea de qué es lo que hay con el nuevo núcleo 2.6.

• El paquete de herramientas RAID (raidtools). También podéis usar mdadm en lugar de raidtools.

• Calma, paciencia, buenos alimentos y cafeína. Todo esto, salvo lo último, lo podéis encontrar en la última versión de vuestra distribución Linux favorita. Si vuestro sistema soporta RAID, debería de existir un archivo en /proc/mdstat. Recordad, ese archivo es vuestro amigo. Si no está ahí puede que vuestro núcleo no soporte RAID. Podéis ver los contenidos de ese archivo ejecutando

  cat /proc/mdstat

Eso debería de aportar datos sobre las personalidades RAID presentes (modos RAID a tener en cuenta en el sistema) y, en este caso, que no hay dispositivos RAID activos. Todavía. Cread, en este momento, las particiones que queréis incluir en los conjuntos RAID que vayáis a necesitar.

5.2 Descargando e instalando mdadm

Podéis descargar el tarball mas reciente de mdadm en http://www.cse.unsw.edu.au/˜ neilb/source/mdadm/ . Ejecutad a continuación make install y eso bastará para compilar e instalar mdadm, su configuración, páginas del manual y archivos de ejemplo.

tar xvf ./mdadm-1.4.0.tgz
cd mdadm-1.4.0.tgz
make install

Si usáis una distribución basada en RPM, podéis descargar e instalar el paquete que hay en http://www.cse.unsw.edu.au/˜ neilb/source/mdadm/RPM .

rpm -ihv mdadm-1.4.0-1.i386.rpm

Si estáis usando Debian Woody (3.0 o superior), podéis probar a ejecutar

apt-get install mdadm

Gentoo tiene este paquete disponible en el árbol de ports. Sólo tenéis que emplear estas instrucciones

emerge mdadm

Otras distribuciones probablemente también tendrán este paquete a tiro. Y ahora vamos con los distintos modos RAID.

5.3 Modo lineal

De acuerdo, tenéis dos o más particiones, probablemente de distintos tamaños, y queréis juntarlas todas en un gran bloque único, donde se sucederán, una detrás de otra.

Configuramos el /etc/raidtab para describir la configuración que pretendemos. Un /etc/raidtab para poner dos discos en modo lineal se ve así de bonito:

raiddev /dev/md0
        raid-level      linear
        nr-raid-disks   2
        chunk-size      32
        persistent-superblock 1
        device          /dev/sdb6
        raid-disk       0
        device          /dev/sdc5
        raid-disk       1

Este modo no soporta discos libres: si un disco se os muere, el array se muere con él. Así de claro.

Los que estáis más despiertos, probablemente os estéis preguntando porque especificamos un chunk-size (tamaño de porción) aquí cuando resulta que el modo lineal solo empalma los discos en un gran array sin paralelismos... bueh, tenéis toda la razón, es un poco raro. Pero mejor dejémoslo correr por ahora, declarad ahí ese chunk-size y no os volváis a hacer esa pregunta. Gracias.

Vamos a crear el array.

  mkraid /dev/md0

Esto inicializa el array, escribe los superbloques persistentes y arranca el array.

Si usáis mdadm, el comando es

  mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2  /dev/sdb6 /dev/sdc5

Y con eso habéis, también, creado el array. Los parámetros son lo que parecen. Y la salida con la que os premiará mdadm será como esta:

  mdadm: chunk size defaults to 64K
  mdadm: array /dev/md0 started.

Echad ahora, el consabido vistazo al /proc/mdstat. Veréis que el array ya está en marcha. Final feliz.

Ahora podéis crear un sistema de archivos, como haríais en cualquier otro dispositivo, montarlo, incluirlo en el /etc/fstab y disfrutarlo.

5.4 RAID-0

En este caso, tenéis dos o más dispositivos, de aproximadamente el mismo tamaño, y queréis combinar sus capacidades de almacenamiento y también combinar sus rendimientos accediéndolos en paralelo.

Preparad el fichero /etc/raidtab para describir su configuración. Un raidtab de ejemplo se parece a esto:

raiddev /dev/md0
        raid-level      0
        nr-raid-disks   2
        persistent-superblock 1
        chunk-size     4
        device          /dev/sdb6
        raid-disk       0
        device          /dev/sdc5
        raid-disk       1

Como en el modo lineal, los discos de reserva tampoco tienen sentido aquí. Un RAID-0 no tiene redundancia, por lo que cuando un disco muere, el array le acompaña al otro mundo.

Una vez más, ejecutad simplemente:

  mkraid /dev/md0

para inicializar el array. Esto debe de inicializar los superbloques y poner en funcionamiento el dispositivo RAID. Echad un vistazo a /proc/mdstat para ver qué sucede. Deberíais ver que el dispositivo ahora está en funcionamiento.

Ahora, /dev/md0 está listo para ser formateado, montado, usado y abusado.

5.5 RAID-1

Tenéis dos dispositivos de aproximadamente el mismo tamaño y queréis que cada uno de los dos sea un duplicado del otro. Además tenéis más dispositivos que vais a querer declarar como discos libres preparados, que automáticamente formarán parte del duplicado si uno de los dispositivos activos se rompe.

Configurad el fichero /etc/raidtab tal que así:

raiddev /dev/md0
        raid-level      1
        nr-raid-disks   2
        nr-spare-disks  0
        chunk-size     4
        persistent-superblock 1
        device          /dev/sdb6
        raid-disk       0
        device          /dev/sdc5
        raid-disk       1

Si tenéis discos libres, podéis añadirlos al final de la especificación de dispositivo mediante el uso de esta sintaxis:

        device          /dev/sdd5
        spare-disk      0

Recordad configurar la entrada nr-spare-disks adecuadamente.

De acuerdo, ahora estáis listos para comenzar la inicialización del RAID. Se debe construir el duplicado, es decir, los contenidos (de todos modos, sin importancia ahora, ya que el dispositivo todavía está sin formatear) de los dos dispositivos se deben sincronizar.

Dad la orden

  mkraid /dev/md0

para comenzar la inicialización del duplicado.

Comprobad el fichero /proc/mdstat. Debería deciros que se ha puesto en funcionamiento el dispositivo /dev/md0, que está siendo reconstruido el duplicado y una estimación del tiempo que falta para el final de la reconstrucción.

La reconstrucción se realiza usando el ancho de banda ocioso de E/S. De esta manera, vuestro sistema todavía debería ser capaz de responder en gran medida, aunque los LEDs de vuestros discos deben estar destelleando alegremente.

El proceso de reconstrucción es transparente, por lo que podéis usar tranquilamente el dispositivo en pleno proceso de reconstrucción del duplicado.

Intentad formatear el dispositivo mientras la reconstrucción se está realizando. Funcionará. También podéis montarlo y usarlo mientras la reconstrucción se esté realizando. Eso si, si el disco equivocado se rompe mientras se está realizando la reconstrucción, no hay solución.

5.6 RAID-4

Importante: No hemos comprobado esta configuración por nosotros mismos. La configuración que vamos a describir aquí es sólo un modelo teórico, no algo que realmente hayamos puesto en producción. Si alguno de vosotros usa RAID-4, que nos envíe unos e-mails y comparta su experiencia con nosotros.

Tenéis tres o más dispositivos de aproximadamente el mismo tamaño, un dispositivo es significativamente más rápido que los otros dispositivos y por ello queréis combinarlos todos en un único dispositivo más grande, conservando todavía alguna información de redundancia. Además, contáis varios dispositivos que queréis usar como discos de reserva.

Configurad el fichero /etc/raidtab así:

raiddev /dev/md0
raid-level      4
nr-raid-disks   4
nr-spare-disks  0
persistent-superblock 1
chunk-size      32
device          /dev/sdb1
raid-disk       0
device          /dev/sdc1
raid-disk       1
device          /dev/sdd1
raid-disk       2
device          /dev/sde1
raid-disk       3

Si tenéis discos de reserva, los insertáis de esta forma, siguiendo las especificaciones de discos RAID;

device         /dev/sdf1
spare-disk     0

como de costumbre.

El array se puede inicializar con la orden

mkraid /dev/md0

como es habitual.

Deberíais de consultar la sección de opciones especiales de mke2fs antes de formatear el dispositivo.

5.7 RAID-5

Tenéis tres o más dispositivos de aproximadamente el mismo tamaño, queréis combinarlos en un dispositivo mayor, pero conservando todavía cierto grado de redundancia para la seguridad de datos. Además, contáis con varios dispositivos para usar como discos de reserva, que no tomarán parte en el array antes de que otro dispositivo falle.

Si estáis usando N dispositivos donde el tamaño del más pequeño es S, el tamaño de todo el array será (N-1)*S. El espacio "perdido" se usa para información de paridad (redundancia). De esta manera, si cualquier disco falla, todos los datos permanecerán intactos. Pero si dos discos fallan, todos los datos se perderán.

Preparad el siguiente fichero /etc/raidtab:

raiddev /dev/md0
raid-level      5
nr-raid-disks   7
nr-spare-disks  0
persistent-superblock 1
parity-algorithm        left-symmetric
chunk-size      32
device          /dev/sda3
raid-disk       0
device          /dev/sdb1

        raid-disk       1
        device          /dev/sdc1
        raid-disk       2
        device          /dev/sdd1
        raid-disk       3
        device          /dev/sde1
        raid-disk       4
        device          /dev/sdf1
        raid-disk       5
        device          /dev/sdg1
        raid-disk       6

Y para insertar discos libres, como siempre;

        device         /dev/sdh1
        spare-disk     0

Un tamaño de porción de 32KB es un buen valor por defecto para muchos sistemas de ficheros de propósito general de este tamaño. El array sobre el que se utiliza el raidtab anterior es un dispositivo de 7 por 6 GB = 36 GB (recuerde que (N-1)*S = (7-1)*6 = 36). Contiene un sistema de ficheros ext2 con un tamaño de porción de 4KB. Podría incrementar tanto el tamaño de porción del array como el tamaño de bloque del sistema de ficheros si su sistema de ficheros fuera o bien mucho mayor o bien si simplemente contuviera ficheros muy grandes.

Vale, ya hemos hablado bastante. Configurad ese raidtab y veamos si funciona. Ejecutad esto,

  mkraid /dev/md0

y observad lo que pasa. Es de esperar que esos discos comiencen a trabajar como locos para poder empezar con la reconstrucción de su array. Echadle, como siempre, un vistazo a /proc/mdstat para ver qué está sucediendo.

Si el dispositivo se ha creado correctamente, el proceso de reconstrucción comenzará ahora. El array no será consistente hasta que la fase de reconstrucción haya terminado. No obstante, el array es totalmente funcional (excepto, por supuesto, para la respuesta ante fallos de dispositivos) y podéis formatearlo y usarlo incluso mientras se esté reconstruyendo.

Consultad la sección de opciones especiales de mke2fs antes de formatear el array.

Bueno, y ahora que ya tenéis esos dispositivos RAID funcionando, siempre podéis pararlo o rearrancarlo usando las órdenes

  raidstop /dev/md0

o

  raidstart /dev/md0

respectivamente.

Si usáis mdadm, los equivalentes son

  mdadm -S /dev/md0

y

  mdadm -R /dev/md0

En lugar de colocar estos comandos en los ficheros de inicio y rearrancar un número astronómico de veces hasta que todo os funcione, seguid leyendo y haréis funcionar la autodetección.

5.8 El superbloque persistente

Antiguamente, las herramientas RAID (raidtools) leían su fichero /etc/raidtab y a continuación inicializaban el array. Sin embargo, esto requería que el sistema de ficheros sobre el que reside /etc/raidtab estuviera montado. Esto no es buena idea si quiere arrancar a partir de un RAID.

Además, la anterior aproximación producía complicaciones al montar sistemas de ficheros sobre dispositivos RAID. éstos no se podían colocar en el fichero /etc/fstab como era usual, sino que tenían que ser montados en los scripts de inicio.

Los superbloques persistentes solucionan estos problemas. Cuando un array se inicializa con la opción persistent-superblock en el fichero /etc/raidtab, se escribe un superbloque especial al principio de todos los discos participantes en el array. Esto permite al núcleo leer la configuración de los dispositivos RAID directamente de los discos involucrados, en lugar de leerla de algún fichero de configuración que puede no estar disponible en todo momento.

De todos modos, si no vais a usar mdadm, todavía deberéis de mantener un fichero /etc/raidtab consistente, ya que podéis necesitar este fichero para una reconstrucción posterior del array.

Los superbloques persistentes son obligatorios si vais a emplear la autodetección de dispositivos RAID durante el arranque del sistema. Esto se describe en la sección de autodetección.

5.9 Tamaños de porción

El tamaño de porción (chunk size) merece que entremos en detalles: no se puede escribir de forma totalmente paralela a un grupo de discos. Si tuvierais dos discos y quisierais escribir un byte, tendríais que escribir cuatro bits en cada disco, con lo que todos los segundos bits irían al disco 0 y los otros al disco 1. Sencillamente, el hardware no soporta eso. En su lugar, elegimos algún tamaño de porción que definimos como la masa "atómica" más pequeña de datos que puede ser escrita en los dispositivos. Una escritura de 16 KB con un tamaño de porción de 4 KB provocaría que la primera y tercera porción de 4KB se escribieran en el primer disco y la segunda y la cuarta porción en el segundo, en el caso de un RAID-0 de dos discos. De esta manera, para grandes escrituras, podríais observar una sobrecarga más pequeña teniendo porciones lo bastante grandes, mientras que los arrays que contuvieran principalmente ficheros pequeños se podrían beneficiar más de un tamaño de porción más pequeño.

Los tamaños de porción se pueden especificar para todos los niveles de RAID excepto para el modo lineal.

Para un rendimiento óptimo, deberíais de experimentar con el valor, así como con el tamaño de bloque del sistema de ficheros que pusiera en el array.

El argumento de la opción chunk-size en /etc/raidtab especifica el tamaño de porción en kilobytes. Por tanto, "4" significa "4 KB".

5.9.1 RAID-0

Los datos se escriben "casi" en paralelo en todos los discos del array. En realidad, se escriben chunk-size bytes en cada disco, en serie (o sea, de forma consecutiva).

Si especificais un tamaño de porción de 4 KB para escribir 16 KB a un array de 3 discos, el sistema RAID escribirá 4 KB a los discos 0, 1 y 2, en paralelo, y a continuación los 4 KB restantes al disco 0.

Un tamaño de porción de 32 KB es un punto de inicio razonable para la mayoría de los arrays. Pero el valor óptimo depende muchísimo del número de discos implicados, del contenido del sistema de ficheros que coloca y de muchos otros factores. Experimentad con él para obtener el mejor rendimiento.

5.9.2 RAID-1

Para las escrituras, el tamaño de porción no afecta al array, ya que se deben escribir todos los datos a todos los discos y punto. Para las lecturas, sin embargo, el tamaño de porción indica cuántos datos leer consecutivamente de los discos participantes. Ya que todos los discos activos del array contienen la misma información, las lecturas se pueden hacer en paralelo al estilo de un RAID-0.

5.9.3 RAID-4

Cuando se realiza una escritura en un array RAID-4, también se debe actualizar la información de paridad en el disco de paridad. El tamaño de porción es el tamaño de las porciones de paridad. Si se escribe un byte a un array RAID-4, entonces se leerán chunk-size bytes de los N-1 discos, se calculará la información de paridad y se escribirán chunk-size bytes al disco de paridad.

El tamaño de porción afecta al rendimiento de las lecturas de la misma forma que en un RAID-0, ya que las lecturas de un RAID-4 se realizan exactamente igual en ambos modos.

5.9.4 RAID-5

En RAID-5 el tamaño de porción tiene exactamente el mismo significado que en un RAID-0. Escribir en RAID-5 es un poco más complicado: cuando una porción se escribe en un array RAID-5, la porción de paridad correspondiente debe ser actualizado también. Actualizar una porción de paridad requiere una de estas dos cosas:

• La porción original, la nueva, y la vieja porción de paridad

• Todas las porción, salvo la de paridad

La implementación RAID escogerá la forma más fácil de actualizar cada porción de paridad a medida que se van sucediendo los accesos de lectura.

Un tamaño de porción razonable para un RAID-5 es 128 KB pero, como siempre, podéis experimentar con éste.

Consultad también la sección de opciones especiales de mke2fs. Esto afecta al rendimiento de un RAID-5.

5.10 Opciones de mke2fs

Hay disponible una opción especial cuando se formatean dispositivos RAID-4 y RAID-5 con mke2fs. La opción -R stride=nn permitirá a mke2fs situar mejor diferentes estructuras de datos específicas de ext2 en un dispositivo RAID de forma inteligente.

Si el tamaño de porción es 32 KB significa que 32 KB de datos consecutivos residirán en un único disco. Si queremos construir un sistema de ficheros ext2 con un tamaño de porción de 4KB, nos damos cuenta de que habrá 8 porciones del sistema de ficheros en una porción del array. Podemos pasar esta información a la utilidad mke2fs cuando se cree el sistema de ficheros:

  mke2fs -b 4096 -R stride=8 /dev/md0

El rendimiento de un RAID-{4,5} se ve fuertemente influido por esta opción. No estamos seguros de cómo la opción stride afectará a otros niveles RAID. Si alguien tiene información sobre esto, por favor, que nos la envíe.

El tamaño de bloque de ext2fs influye severamente en el rendimiento del sistema de archivos. Deberíais de usar siempre un tamaño de porción de 4KB en cualquier sistema de archivos más grande que unos pocos cientos de megabytes... a no ser que se guardéis en él un número muy grande de archivos minúsculos.

6 Detectando, consultando y testando

Esta sección trata sobre la vida con un sistema RAID por software, veremos como podemos comunicarnos con los arrays y cómo podemos trastear con ellos.

Es importante señalar que cuando se trata de manipular dispositivos RAID, deberíais siempre de tener presente que estáis trabajando con sistemas de archivos enteros. Ante eso siempre hay que extremar las precauciones.

6.1 Detectando los fallos de disco

Sin misterios. Basta con echar un vistazo rápido a los logs habituales para percatarse de que ha fallado un disco. Cuando un disco falla, /var/log/messages revelará varios errores del núcleo. Algunos ejemplos, para los masocas:

   kernel: scsi0 channel 0 : resetting for second half of retries.
   kernel: SCSI bus is being reset for host 0 channel 0.
   kernel: scsi0: Sending Bus Device Reset CCB #2666 to Target 0
   kernel: scsi0: Bus Device Reset CCB #2666 to Target 0 Completed
   kernel: scsi : aborting command due to timeout : pid 2649, scsi0, channel 0, id 0, lun 0 Write (6) 18 33 11 24 00
   kernel: scsi0: Aborting CCB #2669 to Target 0
   kernel: SCSI host 0 channel 0 reset (pid 2644) timed out - trying harder
   kernel: SCSI bus is being reset for host 0 channel 0.
   kernel: scsi0: CCB #2669 to Target 0 Aborted
   kernel: scsi0: Resetting BusLogic BT-958 due to Target 0
   kernel: scsi0: *** BusLogic BT-958 Initialized Successfully ***

Y más frecuentemente,

   kernel: sidisk I/O error: dev 08:01, sector 1590410
   kernel: SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 28000002

o también

   kernel: hde: read_intr: error=0x10 { SectorIdNotFound }, CHS=31563/14/35, sector=0
   kernel: hde: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }

Y, como es de esperar, /proc/mdstat revelará la presencia de problemas,

   Personalities : [linear] [raid0] [raid1] [translucent]
   read_ahead not set
   md7 : active raid1 sdc9[0] sdd5[8] 32000 blocks [2/1] [U_]

Luego aprenderemos a monitorizar RAID con mdadm de forma que nos envíen informes de alerta sobre fallos en disco. Ahora lo que procede es aprender más sobre el formato de /proc/mdstat.

6.2 Consultando el estado de los arrays

Podéis mirar siempre lo que hay en /proc/mdstat. No duele. Aprendamos a interpretar sus contenidos. Por ejemplo.

              Personalities : [raid1]
              read_ahead 1024 sectors
              md5 : active raid1 sdb5[1] sda5[0]
                    4200896 blocks [2/2] [UU]
              md6 : active raid1 sdb6[1] sda6[0]
                    2104384 blocks [2/2] [UU]
              md7 : active raid1 sdb7[1] sda7[0]
                    2104384 blocks [2/2] [UU]
              md2 : active raid1 sdc7[1] sdd8[2] sde5[0]
                    1052160 blocks [2/2] [UU]
              unused devices: none

Para identificar los dispositivos libres, buscad el primer valor [#/#] de una línea. El primer número es el número que define el número de dispositivos para un RAID completo. Digamos que es "n". El numero de posición [#] que viene a después de cada uno de los dispositivos integrantes indica la situación que ocupa dentro del conjunto. Los dispositivos con "n" o más son los discos libres, mientras que 0,1,...,n-1 son los dispositivos que están trabajando en el array.

Si hay un dispositivo erróneo, el disco roto estará marcado con una (F) después del [#]. El disco libre que reemplace a este disco erróneo será el dispositivo con el número de posición n o superior que no esté marcado como defectuoso (F). Una vez la operación de resincronización se termina, los números de posición de los dispositivos cambian.

Ah, y el orden en que aparecen los dispositivos RAID en /proc/mdstat no importa.

Por último, recordad que siempre podéis usar las raidtools o mdadm para consultar con detalle los arrays:

        mdadm --detail /dev/mdx
        lsraid -a /dev/mdx

Estos comandos dejan bien claro en que situación se encuentra cada dispositivo en todo momento.

6.3 Simulando un fallo en disco

Si estáis planeando usar RAID para obtener tolerancia a fallos, es buena idea que comprobéis que vuestra configuración funciona correctamente, no sea que tengáis alguna sorpresa desagradable en el momento menos oportuno. El tema es, ¿cómo se las apaña uno para simular el fallo de un disco?

Pues mirad, uno no se las apaña. No se puede simular el fallo de un disco si no es dándole al pobre trasto un buen hachazo mientras rueda.

Esto puede parecer de locos, pero la verdad es que no es posible saber qué es exactamente lo que pasará cuando un disco duro se nos muere de la misma forma que no es posible saber qué es exactamente lo que pasará cuando un coche deje de funcionar. El fallo de un chisme tan complicado como es un disco duro moderno puede deberse a miles de motivos distintos (calor, erosión mecánica, exceso en las presiones magnéticas soportadas, fallo en el suministro de intensidades eléctricas... todo a la vez...) y adoptar miles de comportamientos distintos. Podría ser que un fallo eléctrico se propagara a través de todo el bus, alcanzando a todos los dispositivos conectados a él. Y también podría ser que el dispositivo sencillamente informara a la controladora de un error de entrada/salida, lo cual pondría en marcha los resortes que hacen que la capa RAID gestione estas situaciones correctamente. Y eso es lo que pretendemos al usar RAID, y eso es lo que suele suceder, afortunadamente.

En fin, que se han tomado medidas y realizado esfuerzos para que todo salga bien cuando un miembro de vuestros conjuntos RAID falle, pero RAID no es La Virgen de Lourdes. RAID no hace milagros y no puede resolver situaciones catastróficas. Es vuestra decisión apostar por RAID o no cuando os enfrentéis a la necesidad de aportar un determinado nivel de tolerancia a errores, y deberéis de asumir las consecuencias de vuestros actos por vosotros mismos.

Dicho esto, vamos con lo de simular fallos. Recordad, solamente RAID 1,5 y 5 aportan tolerancia a errores. Los modos 0 y lineal no sobreviven cuando un disco se rompe.

6.3.1 Forzando el fallo por hardware

Si queréis simular el fallo de un disco, podéis, sencillamente, desenchufarlo. Sólo hay que apagar el equipo y desconectar los cables que alcanzan el dispositivo que queráis usar como cobaya. Ni se os ocurra hacer esto mientras el sistema está funcionando, podríais quemar varios componentes de vuestro ordenador. Sólo apagad la máquina, desenchufadla, desconectad ese disco y entonces, si, arrancáis de nuevo.

Cuando hayáis arrancado el sistema, observad los logs y echad un vistazo a /proc/mdstat para ver cómo le va al array. ¿Ha funcionado? ¿Tenéis ahora un array "cojo"?

Los discos erróneos deberían de aparecer marcados con un (F) mi miráis /proc/mdstat. Además, los usuarios de mdadm veréis al dispositivo marcado con un faulty. Repasad lo que hemos dicho aquí en la sección de consultas de estado, hace sólo unas pocas líneas.

Bien, y ahora apagad el ordenador, volved a conectar el disco y arrancad de nuevo. Podréis, entonces, añadir de nuevo el disco cobaya usando el comando raidhotadd.

6.3.2 Forzando el fallo por software

Aquí es donde vamos a divertirnos. Las nuevas versiones de las raidtools incorporan el comando raidsetfaulty, que nos permitirá simular el fallo de un disco sin tener que desenchufar nada ni reiniciar el sistema.

Hale, forzamos el fallo de un disco sin más,

    raidsetfaulty /dev/md1 /dev/sdc2

y eso hace el disco /dev/sdc2 falle en el array /dev/md1. El equivalente a esto en mdadm es

    mdadm --manage --set-faulty /dev/md1 /dev/sdc2

Ahora veréis esto el los logs del sistema,

    kernel: raid1: Disk failure on sdc2, disabling device.

y esto si tenéis algún disco libre en la reserva

    kernel: md1: resyncing spare disk sdb7 to replace failed disk

Si miráis ahora /proc/mdstat veréis cómo le va al array, que ahora es un array degradado. Y ahí también veréis si ha empezado la reconstrucción en algún disco libre que tengáis.

Otra herramienta maja de las nuevas raidtools es lsraid. Probad esto,

    lsraid -a /dev/md1

los que tengáis mdadm, el equivalente a ese comando es esto de aquí,

    mdadm --detail /dev/md1

y ahora es cuando tanto los unos como los otros podéis disfrutar de la visión de vuestro sistema soportando un fallo en disco.

Y ahora que hemos visto cómo es cuando falla un disco, vamos a arreglar las cosas y dejarlo todo como estaba.

Lo primero es sacar el disco erróneo del conjunto RAID. Al fin y al cabo, en este estado no aporta nada al array. Ejecutad este comando

    raidhotremove /dev/md1 /dev/sdc2

Es importante no perder de vista el hecho de que raidhotremove no es capaz de sacar un disco válido de un array en marcha. Por razones obvias, sólo los discos erróneos pueden arrancarse del array (¡ejecutar raidstop o similares en el array y desmontar entonces el dispositivo no os ayudará!).

Bien, lo que tenéis ahora es un /dev/md1 en el que falta un dispositivo. Terminamos ya, devolviendo ahora a /dev/sdc2 de vuelta a casa.

    raidhotadd /dev/md1 /dev/sdc2

o, con mdadm,

    mdadm /dev/md1 -a /dev/sdc2

y podemos ver, ahora, como el hijo pródigo vuelve a casa, tal vez reincorporándose a /dev/md1 cómo un elemento activo del conjunto o (si su antiguo lugar ya fue ocupado por un disco de reserva en su momento y después de ejecutar raidsetfaulty) tal vez como un disco libre.

6.4 Simulación de una corrupción de datos

Un sistema RAID (ya sea hardware o software) asume que si una escritura en disco no devuelve un error, entonces es que ha tenido éxito. Por tanto, si vuestro disco corrompe datos (escribe algo diferente a lo que le han pedido que escriba) sin devolver un error, los datos del array se verán comprometidos también. Es muy improbable que algo así os ocurra, pero es posible, y la verdad es que como resultado, os quedaría un lamentable sistema de ficheros corrupto.

Un sistema RAID no puede y no está pensado para garantizar la integridad de datos de vuestro medio de almacenaje. Por tanto, tampoco tiene ningún sentido corromper a propósito los datos de un disco (usando dd, por ejemplo) para ver cómo resolverá el sistema RAID esa situación. Es más probable (¡a menos que corrompáis el superbloque del RAID!) que la capa RAID no descubra nunca que sus ficheros se han intervenido, vulnerando así la integridad de datos del sistema. Al final de todo eso os quedáis con que el sistema de ficheros contenido en el dispositivo RAID cuya integridad habéis violado queda corrupto. Simplemente.

Así es como se supone que funcionan las cosas. Un RAID, insistimos, no es una garantía para la integridad de datos, simplemente os permite conservar vuestros datos si un disco muere (naturalmente, con RAIDs de niveles iguales o superiores a 1).

6.5 Monitorizando arrays RAID

Podéis ejecutar mdadm como demonio, solo hay que usar el modo de seguimiento (follow-monitor). Si se tercia la ocasión, eso hará que mdadm envíe alertas al administrador del sistema cuando los arrays detecten errores o fallen. Además, el modo de seguimiento puede utilizarse para desatar planes de contingencia en caso de que un disco falle.

Veamos un ejemplo básico.

   mdadm --monitor --mail=root@localhost --delay=1800 /dev/md2

Esto pone a un demonio mdadm a vigilar a /dev/md2. Las alertas administrativas se librarán contra root@localhost. Los chequeos se sucederán en intervalos de 1800 segundos.

También tenéis que recordar a los parámetros como –program o –alert, que se usan para especificar el programa que queráis ejecutar en caso de que suceda un evento.

También es importante mencionar que el demonio mdadm no terminará su ejecución mientras hayan arrays que monitorizar, así que deberiáis de ejecutarlo como un proceso de fondo... estáis lanzando un demonio, no un comando del shell. Usad el ampersand final y un bonito nohup:

   nohup mdadm --monitor --scan --daemonise --mail=root@localhost /dev/md0 /dev/md1 &

Usar mdadm para monitorizar un array RAID es simple y efectivo. Aun así, es evidente que es una forma de monitorizar que también tiene sus problemas. ¿Qué pasa, por ejemplo, si el demonio mdadm se detiene? Para poder sacar adelante problemas como ese, es buena idea que consultéis soluciones de monitorización "reales". Hay varias soluciones (tanto libres como comerciales) disponibles que podéis usar para monitorizar vuestros arrays de RAID por software sobre Linux. Una búsqueda en FreshMeat basta para encontrar varios ejemplos.

7 Reconstrucción

Si habéis leído hasta aquí ya deberíais de ser capaces de haceros una idea de cómo evoluciona la reconstrucción de un RAID degradado. Hagamos un breve resumen:

• Apagad el sistema

• Reemplazad el disco que ha fallado

• Arrancad el sistema

• Usad raidhotadd /dev/mdX /dev/sdX para reinsertar el disco en el array

• Esperad a que la reconstrucción automática termine

Y ya está.

O, al menos, debería. A no ser que el array se haya declarado inutilizable debido a un fallo general (fallan más discos de los que el array puede soportar). Esto sucede, por ejemplo, si un disco arrastra en su caída a todo su bus: los otros discos colgando del mismo cable quedarán inalcanzables para toda la capa RAID y, por tanto, serán declarados erróneos sin estar averiados en absoluto.

Lo que viene ahora es la explicación que Martin Bene nos dio, y describe una hipotética recuperación del horroroso escenario descrito en el párrafo anterior. Para esto hay que usar la directiva failed-disk en el /etc/raidtab estratégicamente, y eso sólo podréis hacerlo si usáis núcleos 2.2.10 o posteriores.

7.1 Sobreviviendo a un error de varios discos

Estas pueden ser las causas del empastre:

• Una controladora se suicida, aislando en el proceso a dos (o más) discos a la vez

• Todos los discos que hay en un mismo bus SCSI quedan inaccesibles cuando un disco muere

• Un cable deja de funcionar

O sea, que os habéis quedado temporalmente sin el servicio de varios discos de golpe, y después de que los superbloques RAID pierdan su sincronía ya no podréis reinicializar vuestro array. Pinta mal, ¿eh?

Esta es vuestra última esperanza: reescribir los superbloques RAID mediante el uso de la instrucción mkraid

–force

Para que esto funcione, necesitareis tener actualizado y mano vuestro /etc/raidtab - si el mencionado archivo no encaja A LA PERFECCIóN con la configuración y el orden exacto de vuestros arrays, esto os saldrá terriblemente mal, y, en lugar de recuperar nada lo más probable es que arruinéis totalmente cualquier posibilidad de recuperación que os quede.

Si observáis el syslog que obtenéis cuando intentáis inicializar el array normalmente, veréis el contador de eventos para cada superbloque; lo mejor será que abandonéis (aquí el uso de failed-disk) el disco con el menor número ahí, generalmente el más viejo.

Si ejecutáis mkraid sin failed-disk, la hebra de recuperación empezará inmediatamente a reconstruir las porciones de paridad, tal vez eso no es lo que queráis hacer inmediatamente.

Con el uso de failed-disk podéis especificar exactamente cuales son los discos que queréis que sean activos y cuales no; y tal vez así ir probando diferentes combinaciones para terminar por quedaros con la que mejor os vaya... y no os olvidéis de montar el sistema en modo solo lectura mientras hacéis esto último.

8 Rendimiento

Queremos ofreceros información útil en esta sección. Queremos mostrar datos fidedignos acerca de cual es el rendimiento de un sistema usando RAID por software sobre Linux. Y para eso necesitamos que nos ayudéis.

Así que, por favor, si implementáis alguna solución RAID radicalmente diferente a las que constan en este documento, enviadnos los datos relativos a vuestro hardware, la carga que soporta la máquina cuando ejecutáis pruebas de medición en ella, y, por supuesto, los resultados de vuestros benchmarks (usando, por favor, software válido a tal efecto).

Nosotros, por nuestra parte, trataremos de publicar las muestras que nos parezcan interesantes, ilustrativas o especialmente significativas, siempre siguiendo nuestro criterio personal.

Gracias, por adelantado, por vuestra ayuda. Y ahora vamos con los datos que nosotros mismos hemos obtenido en nuestras máquinas.

Tamaño de porción Tamaño de bloque Lectura kB/s Escritura kB/s
4k  1k  19712  18035
4k  4k  34048  27061
8k  1k  19301  18091
8k  4k  33920  27118
16k  1k  19330  18179
16k  2k  28161  23682
16k  4k  33990  27229
32k  1k  19251  18194
32k  4k  34071  26976

Esta sección contiene varias pruebas de evaluación de prestaciones ("benchmarks") de un sistema real y en producción en donde se ha implementado una solución de RAID por software. También hay algo de información general sobre benchmarking.

Las mediciones las hemos tomado usando el programa bonnie y siempre con ficheros dos o más veces más grandes que el tamaño de la RAM física de la máquina.

Estas mediciones sólo miden el ancho de banda de entrada y de salida sobre un único gran fichero. Esto es interesante conocerlo si estáis interesados en obtener buen rendimiento de E/S para grandes lecturas/escrituras. Sin embargo, tales números nos dicen poco sobre cuál sería el rendimiento si el array se usara para un almacén temporal de noticias, un servidor web, etc. etc. Tened siempre en cuenta que los números de las evaluaciones son el resultado de ejecutar un programa "sintético". Pocos programas del mundo real hacen lo que bonnie hace y, aunque es interesante mirar estos números de E/S, no son indicadores en última instancia del rendimiento de los dispositivos del mundo real. Ni lo parecen ni lo pretenden.

Por ahora, sólo disponemos de los resultados de una máquina. Ahí va su configuración:

• Dual Pentium Pro 150 MHz

• 256 MB RAM (60 MHz EDO)

• Tres IBM UltraStar 9ES 4.5 GB, SCSI U2W en una controladora Adaptec 2940U2W

• Un IBM UltraStar 9ES 4.5 GB, SCSI UW en una cntroladora Adaptec 2940 UW

• Kernel 2.2.7 con parches RAID

Parece casi imposible sacarle más de 30 MB/s a los buses SCSI de este sistema, usando RAID o no. Suponemos que eso es porque, como se trata de un ordenador bastante antiguo, el ancho de banda de la memoria RAM es muy pobre, y eso limita lo que puede moverse a través de las controladoras de disco.

8.1 RAID-0

Lectura significa entrada de bloques secuencial y Escritura significa salida de bloques secuencial. El tamaño de fichero fue de 1GB en todas las pruebas. Las pruebas se realizaron en modo monousuario. Se configuró el driver SCSI para que no encolara órdenes etiquetadas ("tagged command queuing", TCQ).

Con esto vemos que el tamaño de porción del RAID no importa mucho. Sin embargo, el tamaño de bloque del sistema de ficheros ext2 debería ser tan grande como fuera posible, lo cual significa 4KB (es decir, el tamaño de página) en una Arquitectura Intel de 32 bits.

Tamaño de porción Tamaño de bloque Lectura kB/s Escritura kB/s
32k  4k  33617  27215

Tamaño de porción Tamaño de bloque Lectura kB/s Escritura kB/s
8k  1k  11090  6874
8k  4k  13474  12229
32k  1k  11442  8291
32k  2k  16089  10926
32k  4k  18724  12627

8.2 RAID-0 con TCQ

Esta vez, el driver SCSI se configuró para usar TCQ, con una longitud de cola de 8. Por lo demás, todo es lo mismo de antes.

No se realizaron más pruebas. TCQ pareció incrementar ligeramente el rendimiento de las escrituras, pero la verdad es que apenas se notó la diferencia.

8.3 RAID-5

El array se configuró para funcionar en el modo RAID-5 y se hicieron pruebas similares.

En este caso, tanto el tamaño de porción como el tamaño de bloque son mucho más significativos.

8.4 RAID-10

Un RAID-10 no es más que un array RAID-1 de dos arrays RAID-0. El tamaño de porción es tanto el tamaño de las porciones del array RAID-1 como del array RAID-0. No se realizaron pruebas en las que esos tamaños de porción fueran diferentes, aunque esa debería ser una configuración perfectamente válida.

No se realizaron más pruebas. El tamaño de fichero fue de 900MB debido a que las cuatro particiones involucradas eran de 500 MB cada una, lo cual no deja espacio para un fichero de 1GB en esta configuración (RAID-1 sobre dos arrays de 1000MB).

8.5 Nuevas herramientas de benchmarking

No uséis hdparm para testar el rendimiento de vuestros sistemas RAID, eso no hará evaluaciones reales de vuestros arrays.

En lugar de hdparm, echad un vistazo a las herramientas que describimos aquí: IOzone y Bonnie++.

Tamaño de porción Tamaño de bloque Lectura kB/s Escritura kB/s
32k  1k  13753  11580
32k  4k  23432  22249

IOzone es una herramienta pequeña, versátil y moderna. Saca benchmarks de rendimiento de E/S sobre

ficheros para operaciones como read, write, re-read, re-write, read backwards, read strided,
fread, fwrite, random read, pread, mmap, aio_read y aio_write. Y corre sobre ext2, ext3, reiserfs,

JFS y XFS.

Podéis usar IOzone para expresar el rendimiento de E/S en función del número de procesos y número de discos del sistema de archivos, algo útil cuando se trata de medir soluciones de RAID-0.

Aunque la documentación de IOzone está disponible en PDF, PostScript, nroff y MS Word, vamos a cubrir aquí un bonito ejemplo de IOzone en acción:

iozone -s 4096

Eso ejecuta unos tests usando un archivo de 4096KB.

Y este es un resultado de muestra

        File size set to 4096 KB
        Output is in Kbytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 Kbytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                            random  random    bkwd  record  stride
              KB  reclen   write rewrite    read    reread    read   write    read rewrite    read   fwrite frewrite   fread  freread
            4096       4   99028  194722   285873   298063  265560  170737  398600  436346  380952    91651   127212  288309   292633

NOTA: las funciones que hacen a IOzone útil para el benchmarking de RAID son las operaciones sobre

ficheros read strided.

Bonnie++ parece más orientado a hacer pruebas de rendimiento en dispositivos sueltos que en un conjunto RAID, pero puede pasarle benchmarks a más de 2GB de datos en máquinas de 32 bits, y testar operaciones sobre archivos como creat, stat, unlink.

9 Herramientas de apoyo

Aunque no lo hayamos tratado hasta ahora en este documento, han ido apareciendo a lo largo del tiempo varias herramientas útiles para los sistemas RAID por software.

9.1 Conversión RAID y manipulación de tamaños

No es fácil añadir otro disco a un array existente, así que ha aparecido una herramienta para eso, podéis encontrarla en http://unthought.net/raidreconf . Esta aplicación os permitirá convertir distintos niveles RAID entre sí. Por ejemplo, podéis convertir un RAID-1 de dos discos en un array RAID-5 de cuatro discos (!). También ofrece soporte a la conversión de tamaños de porción y la inserción simple de discos.

Es importante señalar que esta herramienta no es apta para su uso en producción. Aunque parece hacer el trabajo bastante bien, se trata de un software que gestiona procesos muy largos que, de fallar, diseminarán caóticamente vuestros datos por todos los discos de forma totalmente irrecuperable. ¡Es absolutamente imprescindible que hagáis un buen juego de copias de seguridad antes de experimentar con esta herramienta!

9.2 Copias de seguridad

Recordad, somos terriblemente pesados, pero RAID no es un sustituto de las buenas copias de seguridad. Es imperativo proteger esos datos, no sólo mediante un RAID, sino con una política habitual y constante de copias de seguridad bien hechas. Un sistema excelente de backup es Amanda , software libre.

10 Créditos

Nos gustaría agradecer su apoyo a las personas que han colaborado en la creación del presente documento: • Mark Price and IBM

• Michael,

• Damon Hoggett

• Ingo Molnar

• Jim Warren

• Louis Mandelstam

• Allan Noah

• Yasunori Taniike

• Martin Bene

• Bennett Todd

• Kevin Rolfes

• Darryl Barlow

• The Linux-RAID mailing list people

• Juan Piernas Cánovas

• ...y todos a los que hemos olvidado. ¡Esperamos que nos perdonen! :) Por favor, enviad correcciones, sugerencias... y lo que se os pase por la cabeza a los autores. Esa es la única forma de que este HOWTO pueda irse desarrollando.