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.

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.

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.

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.