RAID por software en el nuevo núcleo Linux 2.4, Parte 21. Configuración de RAID-1 en un entorno en producción En mi anterior artículo, introduje a la nueva funcionalidad del RAID por software en Linux 2.4, mostrando cómo configurar volúmenes lineales, RAID-0 y RAID-1. En este artículo, echamos un vistazo a todo lo que se necesita saber para incrementar la disponibilidad en un entorno en producción con RAID-1. Lo cual requiere muchos más conocimientos y comprensión que configurar RAID-1 en un servidor de prueba o en casa -- específicamente, debemos saber exactamente de qué puede protegernos un RAID-1, y cómo mantener nuestro volumen RAID en funcionamiento en caso de un fallo en un disco. En este artículo, cubriremos esos puntos, y empezaré mostrando qué es lo que RAID-1, 4 y 5 puede y no puede hacer por nosotros, para terminar con una completa simulación de prueba en la que se reemplazará una unidad que ha fallado bajo RAID 1 -- algo que realmente se debería hacer (con este artículo como guía) siempre que sea posible. Después de seguir esta simulación se adquiere toda la experiencia necesaria para afrontar un fallo RAID-1 en un entorno en producción en el mundo real. Las características de tolerancia a fallos de RAID están diseñadas para protegernos del impacto negativo de un fallo espontáneo en una unidad de disco. Esto es una muy buena cosa. Pero RAID no es una solución perfecta para cada tipo de problema con los datos que se pueda ocasionar. Antes de implementar un sistema RAID tolerante a fallos (1, 4, 5) en un entorno en producción, es de extraordinaria importancia saber lo que RAID hará y no hará por nosotros. Cuando nos encontremos en una situación en la que dependamos de RAID para desempeñar una labor, no podemos permitirnos asumir cosas falsas acerca de lo que hace. Empecemos desmitificando algunos mitos creados acerca de RAID 1, 4 y 5. Mucha gente piensa que si guardan todos sus datos importantes en un volumen RAID 1/4/5, entonces no tendrán que hacer copias de seguridad con regularidad. Esto es completamente falso -- he aquí el porqué. RAID 1/4/5 ayuda a prevenir un downtime no planificado a consecuencia de cualquier fallo aleatorio en una unidad. De todos modos, no ofrece ningún tipo de protección contra una corrupción de datos accidental o maliciosa. Si se teclea cd /; rm -rf * como administrador en un volumen RAID, se perderán muchísimos datos importantes en cuestión de segundos, y el hecho de que se disponga de diez unidades en una configuración RAID-5 no será de ninguna ayuda. Además RAID no nos ayudará si roban nuestro servidor o si hay un incendio en el edificio. Por supuesto, si no se sigue una estrategia de copias de seguridad, no se tendrá un archivo de datos del pasado -- por lo que si alguien en nuestra oficina borra un montón de archivos importantes, no habrá forma de poder recuperarlos. Esto, por sí solo, debería ser suficiente para hacer considerar implementar una estrategia de copias de seguridad, bajo cualquier circunstancia, antes de ni tan siquiera empezar a pensar en implantar RAID-1, 4, ó 5. Otro error suele ser implementar RAID por software en un sistema compuesto por elementos hardware de baja calidad. Si se va a crear un servidor que va a hacer algo importante, tiene mucho sentido comprar el hardware de mayor calidad que permita nuestro presupuesto. Si el sistema es inestable o no está ventilado adecuadamente tendremos problemas que RAID no podrá resolver. En otro aspecto similar, RAID no puede proporcionar un mayor tiempo de actividad a nuestro sistema en caso de un apagón. Si nuestro servidor va a estar haciendo algo relativamente importante, hay que asegurarse de que está equipado con un Sistema de Alimentación Ininterrumpida (SAI). Ahora, vamos con los problemas en el sistema de ficheros. El sistema de ficheros está "por encima" de nuestro volumen de RAID por software. Lo cual significa que usar RAID por software no nos permite escapar a problemas con el sistema de ficheros, como largas y potencialmente problemáticas comprobaciones del mismo con fsck, si no se está utilizando un sistema de ficheros con diario de transacciones o si es problemático. Por lo que el RAID por software no va a hacer mucho más fiable el sistema de ficheros ext2; por ello es tan importante que la comunidad Linux disponga de sistemas de ficheros como ReiserFS, JFS y XFS. El RAID por software y un sistema de ficheros con diario de transacciones hacen una gran combinación. RAID - Implementación inteligente Espero haber deshecho todos los mitos que pudieran tenerse acerca de RAID con la sección anterior. Cuando se implementa RAID-1, 4 ó 5, es muy importante ver esta tecnología como algo que permitirá incrementar el tiempo de actividad de la máquina. Cuando se implementa uno de estos niveles de RAID, nos estamos protegiendo ante una situación muy específica -- un fallo espontáneo y por completo de una o más unidades de disco. Si se experimenta esta situación, el RAID por software permitirá al sistema seguir realizando su actividad, mientras que se hacen los preparativos para cambiar la unidad que ha fallado por otra nueva. En otras palabras, si se implementa RAID 1, 4 ó 5 se está reduciendo el riesgo de tener un prolongado tiempo de inactividad no planificada debido a un fallo desastroso del disco. Por contra, se puede tener un breve tiempo de inactividad planificado -- el tiempo suficiente para reemplazar la unidad que ha fallado. Obviamente, esto significa que si tener un sistema con una gran disponibilidad no es una de nuestras prioridades, entonces no deberíamos estar pensando en implementar RAID por software, a menos que hayamos planificado usarlo principalmente para acelerar el rendimiento en la lectura de archivos. Un administrador de sistemas capacitado usa el RAID por software por una razón específica -- para mejorar la fiabilidad de un sistema que era ya muy fiable. Si se es un administrador de sistemas competente, seguramente lo más básico ya esté cubierto. Se ha protegido a nuestra organización de catástrofes implementando una política de copias de seguridad regulares. Proporcionamos la alimentación del servidor a través de un SAI y tenemos el software que lo monitoriza funcionando para que el servidor se apague de forma segura en caso de un apagón prolongado. Probablemente se esté utilizando un sistema de ficheros con diario de transacciones como ReiserFS para reducir el tiempo de las comprobaciones del sistema de ficheros con fsck e incrementar su fiabilidad y rendimiento. Y si el servidor se encuentra bien ventilado y está compuesto por hardware de la mejor calidad y si se ha prestado mucha atención a cualquier problema de seguridad. Entonces, y sólo entonces, se debería considerar implementar RAID por software 1, 4 ó 5 -- haciéndolo, otorgaremos al servidor un mayor porcentaje de tiempo de actividad, protegiéndolo contra un fallo por completo de la unidad de disco. El RAID por software es esa capa de protección añadida que hace a un buen servidor ser aún mejor. Ahora que hemos leído lo que RAID puede y no puede hacer, espero que se tengan la actitud y las ganas necesarias. En esta sección, guiaré en el proceso de simular un fallo en una unidad de disco, y después recuperaré el volumen RAID del modo degradado. Si existe la posibilidad de seguirme con una máquina de pruebas, recomiendo encarecidamente hacerlo. Este tipo de simulación puede ser divertida. Divirtiéndonos ahora nos aseguraremos estar listos para cambiar una unidad cuando falle realmente, de forma tranquila, al saber exactamente cómo y qué tenemos que hacer.
Bien, el primer paso es configurar un volumen RAID-1; puede consultarse en mi anterior artículo si se necesita recordar cómo hacerlo. Una vez que hayamos configurado nuestro volumen veremos algo así si tecleamos cat /proc/mdstat:
Hay que notar que estoy usando devfs, y por eso que aparecen los nombres de dispositivos tan largos que aparecen arriba. Estoy usando /dev/hda5 y /dev/hde1 como discos RAID-1. En este momento, el código del RAID por software del núcleo se encuentra sincronizando los discos para que sean completamente idénticos. Si el volumen RAID-1 se encuentra en este punto, podemos crear un sistema de ficheros en el mismo, y después lo podemos montar donde sea. Se copian algunos archivos en el mismo, y después configuramos /etc/fstab para que el volumen (/dev/md0) se monte cada vez que el sistema arranque. Esta es la línea que añadí a mi fstab; otras pueden variar ligeramente:
Bien; estamos casi listos para simular el fallo en una unidad, pero no del todo. Primero, hacemos un cat /proc/mdstat de nuevo, y esperamos hasta que todos los discos del volumen se encuentren sincronizados. Cuando lo estén, /proc/mdstat será como este:
Bien, ahora que la sincronización ha culminado, estamos listos para la simulación. Apagamos la máquina y la desconectamos de la alimentación eléctrica. Entonces, la abrimos y desconectamos uno de los discos que conformaban la estructura RAID-1. Por supuesto, evitamos desconectar el disco que contiene la partición raíz de nuestro sistema Linux -- ¡necesitaremos arrancar Linux de nuevo! Pues bien, ahora que se ha desconectado el disco duro, iniciamos la máquina de nuevo. En el momento en que ingresemos en el sistema, veremos que /dev/md0 está montado y que aún somos capaces de usar el volumen. Se advertirá el gran cambio cuando se ejecute cat /proc/mdstat :
Aquí, puede verse que el volumen /dev/md0 está funcionando en modo degradado. He desconectado la unidad /dev/hde, por lo que el núcleo no encontró /dev/hde1 cuando arrancó e intentó auto-iniciar la estructura RAID. Afortunandamente, el núcleo encontró /dev/hda5 y fue capaz de iniciar /dev/md0 en modo degradado. Como puede verse, la partición /dev/hde1 no aparece en /proc/mdstat , y uno de los discos RAID aparece como "desaparecido" (en [U_] en lugar de [UU]). Pero dado que /dev/md0 está operativo aún, el RAID-1 por software está haciendo lo que se suponía que debía hacer: mantener nuestros datos disponibles. En este preciso momento, estamos experimentando un fallo simulado en una unidad. Si la unidad a la que hemos desprovisto de electricidad hubiese fallado, esa sería la situación en la que nos encontraríamos ahora. Nuestro volumen RAID-1 estaría funcionando en modo degradado, lo cual quiere decir que nuestro volumen aún está disponible pero sin ninguna redundancia. En el momento adecuado debemos apagar el sistema, reemplazar la unidad que ha fallado, y reiniciar el sistema de nuevo cuanto antes. Nuestro volumen RAID-1 seguirá funcionando en modo degradado aún. Una vez que tengamos la nueva unidad en la máquina, deberíamos crear una nueva partición RAID autodetectable (FD) del tamaño adecuado en nuestro nuevo disco. Se requiere de un reinicio adicional para que Linux pueda leer otra vez la tabla de particiones. Una vez que la nueva partición sea reconocida por el sistema, estamos listos para recuperar nuestra estructura RAID-1 degradada -- entonces tendremos alguna redundancia de nuevo. Por supuesto, solamente estamos realizando una simulación. Para hacer prácticas añadiendo una partición a nuestra estructura RAID, podemos hacer una de estas dos cosas, dependiendo del tipo de escenario para el que uno quiera prepararse. Se puede apagar la máquina, conectar la unidad, arrancar y añadir la vieja partición de nuevo a la estructura; o se puede apagar la máquina, conectar la unidad, arrancar, vaciar la unidad, crear una nueva partición de RAID auto-detectable (FD) y añadirla a la estructura (con el tamaño adecuado, por supuesto -- al menos tan grande como la partición a la que está reemplazando) y después añadir esta nueva partición a estrenar a la estructura. La segunda elección será más parecida a lo que ocurriría en caso de un fallo real en un disco duro, mientras que la primera sería algo más parecido a lo que ocurriría en caso de un fallo en la controladora o en el de un mal cable -- lo cual ocasionaría que una de las unidades no estuviera disponible, causando que /dev/md0 funcionara en modo degradado, lo que haría necesario añadir una partición de nuevo al volumen después de resolver el problema. Sea cual sea el tipo de simulación que se escoja, la "solución" es la misma -- después de que la nueva partición esté lista, debemos volverla a añadir al volumen /dev/md0. Antes de añadir de nuevo la partición a la estructura, éste sería un buen momento para consultar los mensajes de inicio del núcleo. Si se teclea dmesg | more, seremos capaces de ver dichos mensajes. Debería verse gran cantidad de texto muy similar a este:
Este es el momento más adecuado para leer concienzudamente dichos mensajes, dado que los mismos nos ayudarán a comprender el proceso que el núcleo usa para auto-iniciar /dev/md0, proporcionando una información inapreciable acerca del funcionamiento del RAID por software bajo Linux. Si se leen los mensajes del núcleo listados anteriormente, veremos que mi núcleo ha encontrado /dev/hda5 y /dev/hde1, pero hde1 no estaba sincronizado con hda5. Por lo que el núcleo inició /dev/md0 en modo degradado, usando /dev/hda5 sin tocar /dev/hde1 en absoluto. Ahora, es el momento de añadir nuestra partición original (o recién creada) a nuestro volumen, he aquí cómo. Primero, si la partición de reemplazo tiene un nuevo nombre de dispositivo, hay que actualizar /etc/raidtab para que refleje esta nueva información. Después, añadimos la nueva partición al volumen usando el siguiente comando, reemplazando /dev/hde1 con el nombre de dispositivo de la partición que estemos añadiendo:
Los leds del disco duro deben empezar a iluminarse dado que la reconstrucción ha comenzado. Comprobemos cat /proc/mdstat para ver el estado de la reconstrucción RAID-1 en progreso:
En cuestión de minutos, el volumen RAID-1 habrá recuperado su estado normal:
¡Aquí está! Lo hemos recuperado con éxito de un fallo simulado en la unidad de disco, y estamos listos para empezar a usar RAID-1 en un entorno en producción. Podemos poner la pegatina hecha en casa "Certificado en RAID-1" en nuestra frente y empezar a agitar los brazos y a correr en nuestra oficina para disfrute de nuestros compañeros. Aunque puede que, actualmente, esta no sea una muy buena idea. Nos vemos en el siguiente artículo.
|
|
