[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [OT] Raid por hardware



El Mon, 12 Jan 2015 13:12:00 +0100, José Miguel (sio2) escribió:

> El Sun, 11 de Jan de 2015, a las 04:29:13PM +0000, Camaleón dijo:
> 
>>> Sí, era el que usaba para comprobar el estado del RAID, antes de
>>> descubrir que también existía la utilidad lsiutil. Lo único que indica
>>> es el modelo también. De hecho, ni siquiera da información del
>>> progreso de la sincronización: sólo de que los discos no están
>>> sincronizados y de que se está en proceso de sincronización. Pero del
>>> tanto por ciento, nada de nada.
>> Pues no lo entiendo, la verdad. LSI no es precisamente un fabricante de
>> los considerados malillos, no tiene sentido que disponga de
>> herramientas para la gestión del raid tan "pobres", la menos la suya
>> (lsiutil) debería ser más completa pero parece que no :-?
> 
> Quizás me has entendido mal: es mpt-status el que no devuelve el
> porcentaje de la sincronización: lsiutil, sí. Lo que fui incapaz de
> encontrar con lsiutil fue la identificación del disco.

No me refería al estado de la sincronización sino al nº de serie de los 
discos, que no se entiende que ninguna de las dos herramientas te diga 
cuáles son. Sinceramente, incomprensible.

El hecho de que mpt-status no te diga el porcentaje de la reconstrucción 
no me extraña porque por la propia descripción del paquete parece más 
bien una herramienta de control y no tanto de gestión del raid, es decir, 
una especie de demonio que monitoriza el estado del raid y en caso de 
caída te informa de alguna manera (e-mail, wall), algo que las 
herramientas CLI convencionales que proporcionan los fabricantes no 
suelen disponer ya que se ejecutan una vez para trabajar con el raid pero 
poco más. Es decir, que mpt-status vendría a ser el complemento perfecto 
de lsiutil, cada una con funciones bien definidas.

>> No, no... qué va, no vale. Recuerda que en el supuesto que estamos
>> tratando estás "deshaciendo" el raid 1: pinchas un disco únicamente en
>> una controladora de disco duro distinta. Lo normal en ese caso es que
>> si se tratara de un volumen de inicio no pudiera arrancar.
>> > La definición del RAID en sí puede estar almacenada en memoria flash
>> > y no hay que guardar metadatos del RAID en los discos duros.
>> ¿En qué memoria flash?
> 
> En la de la propia controladora RAID, que tiene su propia BIOS
> actualizable por lo que debe tener memoria flash.

Mucho esperas... Me extrañaría que tuviera memoria flash con capacidad 
suficiente para albergar los datos más allá de los que necesita (firmware 
y metadatos). Salvo que la controladora sea buena (pero de las buenas de 
verdad que tienen un batería y todas esas gaitas) y aún así tendría mis 
dudas.

>> Los datos del RAID quedan en los discos duros y la controladora RAID es
>> la que se encarga de interpretarlos, de ahí que mientras conectes los
>> discos a una controladora igual no haya problemas pero no sucede lo
>> mismo si los discos se conectan a una controladora distinta (sea RAID o
>> no).
> 
> Pues he probado a conectar el otro disco a otro ordenador y arranca sin
> problemas. Como uno lo conecté al servidor pero no a través de la
> controladora y otro a otro ordenador sin ella, ambos discos han
> arrancado y funciona su sistema perfectamente sin la controladora. 

Si el kernel donde tienes instalado el sistema ya tiene en su imagen el 
driver de la nueva controladora donde has conectado el disco, no tienes 
que hacer nada, lo cargará al iniciarse. 

> Así que los datos de definición del RAID deben de estar en la propia
> controladora, porque el único lugar libre que se me ocurre en los discos
> es el espacio que hay entre el MBR y el principio de la primera
> partición. Pero ese espacio ya lo usa grub, al menos en parte. Además el
> RAID se puede inicializar antes de tener hecha ninguna partición. He
> mirado con fdisk la definición de las particiones del disco (que ya no
> gestiona la controladora) y no hay nada raro en ellas. La primera
> empieza en el sector 2048.

Creo que tienes un error de concepto. Cuando inicializas los discos desde 
la utilidad de la controladora raid para empezar a definir el nivel de 
raid que quieres y el resto de datos del array, lo que estás haciendo es 
grabar esa información en los discos duros que hayas seleccionado para 
formar parte del array. Los datos se almacenan en lo que llama 
"superbloques persistentes" (igual que cuando usas raid por software o 
"md").

Lo que no tenía tan claro es que se pudiera iniciar un sistema que tenía 
un raid 1 (definido por una controladora hardware raid) con un único 
disco, no sé por qué pero algo me dice que en windows te encontrarías con 
un bonito pantallazo azul, pero quizá en linux sea diferente :-)

>>> El driver no lo estoy usando para nada ahora mismo. De hecho acabo de
>>> hacer unos rmmod para eliminar todos los drivers mtp* y los he
>>> descargado sin problemas.
>> Pues la salida que enviaste de lspci decía que estaban en uso:
> 
> La salida dice que lo está usando la controladora, lo cual es normal
> porque sigue pinchada y no la he deshabilitado. Como es software plug
> and play, durante el arranque se detecta que hay una controladora y se
> carga su driver para usarla.

Es que no tienes más que una controladora de disco sata y es la LSI.
 
> Pero no estoy usando la controladora para acceder a disco porque el
> disco lo pinché directamente a la placa base. De hecho, he descargado
> los módulos mpt* y se hizo sin problemas. Si hago ahora un lspci -v no
> sale la línea esa que indica que ese driver está usando el módulo. En
> concreto esta que citas:
> 
>>  	Kernel driver in use: mptsas

Pues repito que los discos tienen que estar usando algún módulo del 
kernel, ya me dirás cuál ;-)

>> > O incluso puedo pinchar unos de los discos en un ordenador
>> > completamente diferente y mirar a ver si en ese ordenador el sistema
>> > tiene los lapsus que tiene en el servidor.
>> 
>> Bueno, con eso cuidado porque es posible que no inicie a la primera y
>> que (dependiendo de cómo tengas detectados los discos duros) tengas que
>> hacer cambios en el gestor de arranque o cargar el módulo del kernel
>> que se encargue de la controladora de los discos duros en el nuevo
>> equipo.
> 
> Ha funcionado sin problemas. 

Habrá usado algún módulo que ya tenía cargado el kernel.

> Como la placa exige tarjetas PCI de perfil
> bajo, no he podido pincharle tarjetas de red para que haga exactamente
> la labor del servidor y dejarlo un par de días, que sería lo suyo. Lo
> que si hice fue actualizar paquetes, que es una tarea que el servidor
> hace siempre anormalmente lenta, y la velocidad fue la normal. Si
> pudiera hacer una prueba definitiva haciendo que se tire unos días
> sustituyendo al servidor, podría descartar algún fallo de configuración,
> y buscar entre el hardware del servidor el culpable. Pero tengo el
> problema de la caja.

Ya vi que la placa donde tienes la controladora raid tenía unas cuantas 
tarjetas de red O:-)

> Mañana por la tarde haré algunas cosillas que tengo pendientes (chequear
> la memoria y deshabilitar la controladora RAID en la BIOS si es
> posible).

También sería interesante que vieras qué driver del kernel usa ahora el 
disco duro que tengas pinchado en la placa donde tienes la controladora 
LSI.

Saludos,

-- 
Camaleón


Reply to: