The long tomorrow

Sigo con el montaje del RAID5 + 1 para el Labsys en Santiago de Compostela.

Estos días no ha habido entradas porque, sinceramente, esperaba poder hacer uno de esos post de gran relumbrón en los que se cuenta lo listo que se es y lo grande que se tiene.

Bien, al grano. Después de pelearme un rato con el paquete nbd-client y nbd-server comprobé que lo único que faltaba en la inicialización era crear los dispositivos nbd en el sistema cliente. Son dispositivos de bloque con mayor 43. Así que ya sabéis, un pequeño mknode y queda el asunto arreglado.

El uso de nbd-client es trivial después, pero por si acaso, siempre que falle, conviene empezar comprobando:

0. Iptables configuradas en modo NO draconiano, no olvidemos que esto es un servicio de red, señores.
1. Que el servido está en activo (no es coña, puede pasar)
2. Que la conexión se ha levantado correctamente (netstat -tp | grep nbd)
3. Que el fichero de dispositivo bloque 43:x está correctamente creado.

Respecto de la seguridad de conexión en el servicio, existe un fichero asociado a nbd-server que identifica los clientes permitidos, no lo empleo porque soy un macarra pero en principio creo recordar que sigue el nombrado clásico, acabado en .allow ó algo por el estilo.

Bien una vez tienes todos los detalles estos resueltos es posible y fácil hacer algo así como un:

nbd-client host puerto dispositivo
cfdisk dispositivo — en este momento no estoy del todo seguro de que sea necesario, hazlo que no molesta mucho.
mkfs -foo -bar -temp dispositivo
mount dispositivo

Y tendrás un disco duro añadido al sistema. Bien, esta es la primera etapa del viaje.

RAID

Lo primero que hace falta es un kernel que soporte RAID, esto es fácil ahora que el kernel compila casi solito. Después necesitas instalar este kernel en la máquina que vaya ha hacer de concentrador principal.

La idea es instalar el servicio nbd-client únicamente en una máquina y mapear todas las unidades que planees emplear como parte del RAID. Luego se crea el RAID. A partir de este punto empieza el pantano. Los howtos que se encuentran en internet están en su mayoría enfocados al uso de las raidtools y no del mdadm, herramienta más reciente y que unifica la capacidad del raidtools en un único ejecutable.

Notar que a partir de aquí empieza el terreno pantanoso: en mi opinión para hablar con cierto criterio de esto hay que ser un experto en sistemas de almacenamiento y temas de arquitectura de buses. Pero en fin ahí voy a la piscina.

1. Lo primero que se hace es crear el RAID, se ejecuta un mdadm –create, se elige el nivel de RAID que se está buscando (0,1,5,linear,…) y quedan preparados los dispositivos. Bien en este punto un experto diría que hay que ajustar los tamaños de “chunk” del RAID para afinar el rendimiento, que depende del número y tamaño del fichero medio que vayamos a emplear en el mismo.

2. A partir de aquí lo lógico es hacer algunas pruebas de desmontado y ajustar el fichero de configuración de mdadm (/etc/mdadm/xxx.yyy) Si tienes dudas acerca de cómo está montado el raid prueba a hacerle un cfdisk al dispositivo RAID, poco ortodoxo pero funciona.

En este punto llega el dolor: una vez tienes el RAID montado, dispones de un dispositivo de bloques, generalmente un /dev/md0 ó algo por el estilo. Para usarlo hay que crear un sistema de ficheros sobre él. El propio gestor de RAID se debe encargar de la gestión de los chunks, replicación coherencias, etc. En general dependiendo de cuándo se escribió el howto se encuentra ext2 / ext3 / reiser. Siempre creado a lo macho mkfs.ext3 /dev/md0.

Pues bien, si has llegado hasta aquí, ejecutas el mkfs y te funciona, quiero saber cómo lo has montado porque en mi caso, comienza la ejecución del creador de sistemas de ficheros y se cuelga tras una intensa actividad de red. Supongo que la palabra colgarse sonará a rookie, pero no: ni top ni ssh ni nada, sospecho que el sistema de ficheros se queda más frito que un churro. Y a partir de aquí todo es bruma y duda:

1. ¿La relación nbd + RAID es excesiva con volúmenes de 100GB?
2. ¿Es un problema únicamente del módulo de RAID?
3. ¿Funcionará empleando una capa intermedia de LVM ó sólo complica las cosas?

Os iré contando conforme vaya sabiendo. Ánimo que este negocio puede ser a veces muy muy frustrante.

Flame: Un paquete personal, abusivo que se dirige contra el autor de un mensaje de Usenet. Lamentablemente los flames son bastantes comunes y largos. La gente que se dedica a esta “actividad” es conocida como flamer y puede llegar a ser ignorada por toda la comunidad Internet. [Google]

¿Usenet? … náh, los tiempos han cambiado, Internet y sus costumbres toman las calles conforme los geeks van saliendo del armario de sus aficiones y se reunen, tanto en garitos como a través del hilo para comunicarse entre sí, ….

No es que yo sea un provocador ni me guste discutir, ni mucho menos, …. lamentablemente he tenido la desgracia de contemplar 3 tipos de flames:

1. De bar
2. De foro online
3. De lista de correo

Está claro que el tipo [2 y 3] no presentan novedad alguna, siempre surge el típico gilipollas que se hace llamar D.Vader; pero, ¿qué ocurre cuando el flamer se sienta a tu lado en el curro, en clase, … ó es tu hermano? Eso sí es un marronazo. Se supone que somos personas razonables y no nos dejamos llevar por el primer impulso, por Dios, usamos Linux, vestimos camisetas molonas y bebemos Mecca-Cola, ¿qué podría salir mal?

La primera clase tiene unas características únicas, suelen empezar mientras se bebe, generalmente sin medida y son verbales. Una gestión adecuada de estas dos circunstancias permite a los flambeadores excusarse de mil maneras: “no me entendiste bien”, “bebimos demasiado”, “no quería tirarte la cerveza a la cara, se me escapó”. Curiosamente es el único tipo de flame en el que la escalada de injundios puede resolverse en el campo del honor. También son los que pueden cerrarse con un apretón de manos ó una disculpa justo tras haber cometido el error de decir esa frase de más. El peor tipo de flamer de bar es el que se caga en tu madre y acto seguido se disculpa invitándote a un chupito infecto de algo que sabe que no te gusta. Está claro que no puedes majarlo justo después de su invitación, serías un bárbaro.

Son fáciles de encontrar, cualquier visita un viernes tarde al 24h en Zaragoza, acompañado de Púlsar garantiza como mínimo 1 ó 2 por noche.

Respecto al flame online queda muy poco que decir que no haya sido ya objeto de chanza, anécdota e historia. Voy a centrarme en un tipo específico de flame: el flame combinado. Partimos de un grupo de personas que deciden montar una lista de correo para coordinar sus actividades pero que viven en la misma ciudad, de este modo queda constancia documental de sus actos. Y es que somos unos chicos estupendos cuando nos lo proponemos.

Todos los miembros del equipo reciben los mensajes de la lista puntualmente y todos son felices. Hasta que algo ocurre: una discusión mortal. Y entonces a tomar por culo las buenas formas y los emails jocosos con links golfos a la lista. Nos ponemos todos la careta de soy-más-ingenioso-malévolo-y-borde-que-tú y a flambear se ha dicho. ¿Qué nos hace olvidar que los mensajes de texto permanecen en todos y cada uno de los discos de los miembros del equipo?

Me voy a aventurar y diré que este comportamiento está relacionado con el mismo que nos hace adoptar otras identidades en los IRCs: el anonimato. [Falso, como todos sabemos, pero lo importante es la percepción de anonimato no el anonimato como tal] Recibes un mensaje de alguien que conoces porque acabas de tomarte con él unas cañas. Y el email es “demasiado”, ¡clama al cielo! ¿Qué hacer? … lo lógico: abrir el mutt y enviarle el mayor flame que la humanidad haya visto jamás.

Y es que una vez pulsado el botón de enviar poco queda por hacer. Ya está montada. Me sigue fascinando esta actitud porque está claro que se volverá a ver al tipo: cara a cara. Y toda la violencia que la lista de correo evitaba estallará pero bien enveneada y aumentada por cada respuesta cruzada.

Ahora, unos amiguetes de Santiago están precisamente en esa situación. Conociendolos más bien poco me pregunto si esta escalada de provación / insulto se hubiera producido en una reunión en persona o no. Quiero creer que no.

¿Provoca el anonimato la sensación de que nuestros actos serán impunes? ¿Incluso cuando tenemos claro que el estamos lanzándonos pedradas sin vernos las caras pero sabiendo perfectamente quiénes somos?

Seguimos con el problema de los discos distribuídos en red: se busca crear un “disco virtual” único sobre unos appliances usados para renderizar mágenes. Sé que la idea no suena bien y mezcla máquinas de producción con máquinas de servicio; pero es lo que hay. Cuando no hay ni un leuro a la vista se aprende a ser pragmático y asumir unos riesgos completamente suicidas.

Comencé echándole un ojo a las soluciones que se habían propuesto para almacenamientos y redes de almacenamiento de tipo SAN, vayan aquí unos links: Redes de almacenamiento explicadas. Si te lees el artículo, completamente recomendable, llegarás a la conclusión siguiente:

SAN = SUN = $SUN = (SCSI + fiber + multiproccesor) …

A partir de ahí me desinflé un poco y me tiré de cabeza a google, seguimos con NAS (Network attached storage)

Donde ya aparecen algunos conceptos familiares algo menos $únnico$, NFS, IP, CIFS, palabritas muy queridas por todos nosotros. Quedaba claro que existía una solución software para resolver el problema pero Wikipedia no afinaba más la búsqueda. De vuelta a Google.

La tercera búsqueda en Google me lleva a una página tope de divertida, un “Alien vs. Predator” del almacenamiento: . Hay que
joderse, podría haber empezado por ahí y me habría ahorrado un buen rato de búsqueda.

Pero no todo es tan sencillo: aparece aquí otro contendiente “AoE”
, ¡esto era de lo más prometedor!

Ya que las máquinas de las que disponía admitían SATA. Y, … todo marchaba bien … pero, súbitamente: Artículo Coraid

La clave de este artículo está en la palabra Coraid que, como habrás adivinado, sagaz lector, es el cerebro detrás del appliance que cubre el artículo de Linux Journal. Le doy algunas vueltas más pero no he encontrado modo humano de emular AoE mediante software y cada día que pasa más convencido estoy de que era una soberana chorrada.

Así que me decido a volver al segundo candidato: NAS. Buscando buscando averiguo
(vía Slashdot) que existe un servicio nbd (network block device) capaz de compartir un dispositivo de bloques sobre TCP y hacerlo ver como local a una máquina tercera (en el clásico ejemplo de cliente / servidor).

Como si hubiese visto la luz me tiro a por nbd como un kafre: y he aquí lo que encuentro: resumen RAID , ¡joder pero si hay un mogollón de recursos!

Mientras llego a esta conclusión estoy montando un Debian en uno de los appliances destino, compruebo, aterrado, que el hardware entre las máquinas difiere levemente, el mapeo de las unidades SATA, por poner un ejemplo, no está coincide en las IDES, las tarjetas gráficas son distintas, el kernel base que
reconoce los dispositivos es el 2.4, … esas cositas. Pero tampoco pasa nada, te armas de paciencia bajas la 2.6.13 y a compilar, … curiosamente la compilación es limpia y fácil.

Una vez tengo un kernel nuevo (y esto empieza a parecer una receta de cocina) le echo un ojete al sistema de paquetería de Debian (stable/Sarge) y los ojitos se me ponen de colores cuando veo que nbd y nbd-server están como paquetes deb, todo bonitos, todo chequeados, ¡aúpa Debian! que viva la madre que los parió!
Los instalo sin pensarlo mucho, ahora creo que eso ha sido un error ya que se me han acumulado demasiados servicios en la instalación base.

Hago una pequeña consulta a Warp networks http://www.warp.es/ porque tengo la memoria hecha un queso y no me acordaba del nombre de la herramienta de sysadmin por excelencia (sí, más allá de quota y rm -Rf /home/encefalopower), partimage. Que sirve, como todos recordaréis, para clonear particiones. Me bajo las dos distribuciones la binaria estática y las fuentes.

Hagamos un pequeño recuento hasta el momento:

Y me faltaba una cosa: … el RAID! de vuelta a wikipedia para tener una visión histórica de lo que estaba haciendo: este artículo sí es muy interesante. Le doy un par de vueltas y tras echar mano del howto me doy cuenta de que estaría de cojones tener un LVM que agrupase todo el RAID junto y lo hiciese más sencillo.

Este esquema te lleva a tener una GIGA-LAN sobre la que vas a montar un montón de máquinas haciendo una especie de NAS. Agrupas estos dispositivos en un tercer equipo donde montas los nbd’s y les creas un RAID, sobre el RAID un LVM y cuando lo tienes todo ya montado publicas este LVM como particiones por red,
específicamente en CIFS / Samba / NFS (esto depende de lo exigente que sea tu público) En mi caso tendrá que ser un diskote compatible con Windozes así que no me quedan más pelotas.

Me falta por contaros: creación (rápida y fácil) de un arranque por USB más todo el proceso de cloneado más el montaje del RAID, dadme algo de tiempo.

Sólo un par de cosas porque no tengo mucho tiempo:

1. Parece ser que me voy a pegar una temporada en la Universidad de Santiago de Compostela (instituto tecnológico)

2. Uno de mis primeros curres va a molar porque se trata de montar una red de almacenamiento. Llevo mirando unas mañanas y parece ser que la opción más viable va a ser nbd ya que tengo varias máquinas (serán Debian) que necesito enganchar mediante RAID, también me estoy planteando sobre el RAID un LVN, pero en fin, esto ya se verá. Está claro que aún soy un novatillo en esto, …

Una lástima tener que dejar la inteligencia artificial de momento, espero haber terminado esto en unas 2 semanas.