Autor: Emilio
Florido
Fecha: 20/08/2004
Si se desea tener un servidor funcionando de forma ininterrumpida, las 24 horas del día y los 7 días de la semana, desde luego una máquina con FreeBSD es una inestimable ayuda. Si además queremos que cuando ocurra "un desastre", este afecte el menor tiempo posible a los usuarios de ese servidor, habrá que tomar ciertas precauciones. Ante "desastres" como que el administrador teclee rm -rf / solo una copia de seguridad previa hará que todo vuelva a la normalidad en no demasiado tiempo. Sin embargo, no nos engañemos; este tipo de acciones no suelen ocurrir a menudo y los administradores, al menos los más sensatos, no suelen conectarse a la máquina como administrador más que cuando es imprescindible. De lo que si que no se está a salvo, por sensato que uno sea, es de un fallo hardware. Si el disco donde residen nuestros datos decide un buen día dejar de funcionar, no quedará más remedio que sustituirlo por otro, reinstalar el sistema operativo y recuperar todos los datos de la copia de seguridad que tengamos.
Lo que a partir de aquí voy a comentar pretende conseguir que un fallo hardware en un disco duro no sea más que una pequeña "molestia" para el administrador y que los usuarios del servidor ni siquiera se enteren. Si, no me he equivocado en mi última afirmación; incluso si el servidor con FreeBSD no está montado más que en simple PC, para los usuarios del mismo, el fallo de un disco duro no debería afectarles más que el tiempo que se tarde en sacar el disco estropeado y sustituirlo por el nuevo... y si se dispone de un servidor que permite la extracción en caliente de sus discos (por ejemplo como ocurre con los nuevos discos Serial-ATA), los usuarios es más que probable que no se den ni cuenta de que ha ocurrido un fallo.
Incluso se puede llegar más allá. Si se estropeara completamente el sistema (por ejemplo que la placa base dejase de funcionar) se podría montar por separado cualquiera de los discos que se estaban usando en otra placa base y -siempre que el kernel que estemos usando no sea muy "exótico" o siempre que hayamos tenido la precaución de conservar el kernel.GENERIC- no debería haber problemas para poner un nuevo sistema en funcionamiento.
Para poder conseguir lo propuesto será imprescindible contar, además de con FreBSD, con -al menos- dos discos duros. No será necesario que sean del mismo tipo (me refiero a que pueden ser IDE, SCSI o uno de un tipo y el otro diferente) y ni siquiera del mismo tamaño (aunque si lo son, más sencillo nos será).
También necesitaremos usar vinum, aunque afortunadamente este viene "de serie" con FreeBSD. Es decir, no es necesario recurrir a ningún port ni a instalar nada adicional para disponer de él.
Desde un punto de vista más técnico, lo que aquí se va a comentar es como montar un RAID por software para FreeBSD, es decir, usar un par de discos duros de forma que uno "apoye" al otro y que ambos tengan el mismo contenido. Si ocurre un problema en uno de los dos discos, el otro tomará "las riendas" y hará todo el trabajo él solo en tanto no se sustituya el averiado... y de forma totalmente automática. Bueno, de vez en cuanto habrá que revisar /var/log/messages para darnos cuenta de si algo ha ocurrido, no vaya a ser que como externamente ante un fallo no se nota nada, se nos estropee un disco, pasen un par de meses sin darnos cuenta y luego se estropee el otro y nos quedemos sin ninguno.
Si has ojeado el enlace sobre RAID que proponía más arriba (o cualquier otro de los cientos que aparecen si buscas en google[RAID]), habrás visto que hay varios tipos de RAID. Por una parte están los RAID por hardware y por otra los RAID por software. Los primeros exigen que el hardware de la máquina ofrezca soporte para ellos (normalmente con algunas opciones en la BIOS para poder ajustar su comportamiento) y que además sea alguno de los varios que FreeBSD reconoce (ojo que al ser por hardware, FreeBSD deberá reconocerlo para saber como usarlo). Los segundos -los software-, únicamente nos exigirán disponer de un programa adecuado para crearlos y usarlos.
Además de vinum, en FreeBSD puedes usar también ccd. Personalmente me parece más "limitado" que vinum (incluso su mismo autor lo llama "el mirror de los pobres") y ya que vamos a tomarnos la molestia de instalar un RAID, porqué conformarnos con poco. De todas formas, para ciertos entornos, ccd no deja de ser una opción muy buena.
Además de los tipos de RAID, habrás visto que también hay niveles de RAID. Concretamente en este documento propongo un RAID-1 que es el que actualmente tengo instalado en mi máquina. Este se corresponde con la idea de discos "espejos" y busca mantener la seguridad de los datos por encima de otras consideraciones (bueno, en realidad el tiempo de lectura de los datos debería verse también disminuido, pero personalmente no puedo decir que haya notado mucha mejora en este aspecto). De todas formas vinum no se queda aquí. Con él es posible crear también RAID-0 y RAID-5 consiguiéndose la concatenación del tamaño de los discos o la rapidez (tanto en lectura como en escritura) y la seguridad ante fallos.
Aunque teóricamente es posible configurar vinum en un servidor que ya está en funcionamiento, yo nunca lo he hecho y no se si me atrevería a hacerlo. No suele ser una configuración conflictiva, pero como hay que tocar las particiones y el etiquetado de los discos duros, más vale prever desde un principio que se desea hacer y no "jugársela" con una máquina ya funcionando y de la que dependan muchos usuarios. Por tanto, consideraré que a partir de ahora el sistema sobre el que vas a instalar vinum está completamente "limpio" y así, poco podemos perder si algo sale mal durante el proceso (o al menos, yo no me sentiré responsable de que esto te ocurra).
En cuanto a los discos duros a usar, como decía antes, NO es imprescindible que sean idénticos, pero si son del mismo tamaño será más sencillo. De todas formas, si no tienes dos discos iguales, consideraré que el de menor tamaño es sobre el que primero trabajaremos y luego, el de mayor tamaño será el que se añada para formar el RAID. Es más, el posible tamaño extra de este segundo disco no formará parte del RAID, aunque si que será posible usarlo como una partición más (eso si, sin tener "asegurados" los datos que en ella residan) montada en cualquier parte de tu árbol de directorios.
Aunque no es excesivamente complicado hacer que vinum también incluya la partición de arranque ( / ) en el RAID, si que habrá que tener en cuenta más detalles para así hacerlo. Entre otros, el que de esta forma justo al arrancar -en el propio kernel- ya debería estar disponible vinum. Aunque es posible incluirlo en un kernel construido a medida y que así esté disponible desde el arranque, en la documentación NO se recomienda actuar de esta forma, si no dejar que se cargue como un módulo cuando haga falta. Esto nos llevaría a tener que añadir al fichero /boot/loader.conf un par de líneas como estas: vinum.drives="/dev/ad4 /dev/ad6" y vinum.root="root" para que el kernel sepa qué y donde buscarlo justo al arrancar.
Seguro que también sabrás que tampoco el instalador de FreeBSD (/stand/sysinstall) da ningún soporte para vinum, por lo que ante tantos "inconvenientes", creo que una mejor solución pasa por dejar tal cual la partición de arranque y duplicarla "a mano" cada cierto tiempo de un disco a otro. Afortunadamente, los datos de esta partición no deberían cambiar demasiado a menudo y tampoco es necesario hacer las cosas a mano (más adelante expondré como cron ayudará a esta tarea). Si de todas formas sigues empeñado en incluir vinum en la partición de arranque seguro que te interesará leer esto pues yo no lo he hecho y por tanto no puedo aportarte más detalles al respecto.
Por otra parte, vinum no permite crear un RAID sobre particiones de swap. De todas formas, sería bastante discutible que alguien quisiera hacer eso si sabe realmente para que usa el sistema una partición de swap... Lo que si es posible (y recomendable) es tener el swap dividido entre los dos discos que usemos para el RAID, y esto si es perfectamente posible conseguirlo.
Otra limitación, y en este caso no de vinum si no de lo que yo voy a comentar, es que como únicamente dispongo de dos discos duros (aunque afortunadamente son de igual tamaño), solo puedo dar los detalles para este caso concreto. Si tienes la suerte de tener más discos, además de leer lo que aquí cuento, tendrás que investigar un poco en el manual de vinum para configurarlos adecuadamente.... cosa que por otra parte no parece especialmente compleja (incluso tal vez te interese usar otro nivel de RAID en ese caso).
Aunque a vinum le es indiferente en que controladora tengas "pinchados" tus dos discos duros, el sentido común dice que si cada disco está en una controladora diferente las cosas irán mejor.
Por una parte, piensa que no siempre tiene por qué estropearse el disco duro... puede ocurrir que se estropee una de las controladoras y por tanto, si "pinchado" a ella tienes los dos discos de tu servidor, el sistema se detendrá (y no queremos que eso ocurra, pues pretendemos dar servicio 24x7 aún con un disco estropeado).
También debes considerar que si ambos discos están en la misma controladora (uno como maestro y el otro como esclavo) y usan tecnología IDE (lo más habitual todavía), cuando se esté usando un disco el otro tendrá que esperar (y esto es así por propio diseño del interfaz IDE, no por "culpa" de FreeBSD).
Por tanto, te recomiendo situar un disco en una controladora y el otro en una distinta. De esta forma conseguiremos que si una se estropea todo siga funcionando y que los accesos a los datos sean más rápidos.
Concretamente en mi caso, un disco lo tengo situado en /dev/ad4 y el otro en /dev/ad6. Ya se que lo habitual sería tener un disco en /dev/ad0 y el otro en /dev/ad2 pero nada más que cambiando unos números por los otros todo lo que voy a contar debería servirte.
Por cierto, y ahora que hablo de "nomenclatura", vinum da nombres muy "particulares" a los discos, a las particiones, a los volúmenes que incluyen RAID y a un largo etcétera... más que nada para dejar claro de que se habla en cada caso (basta con que des un vistazo a man 4 vinum para convencerte). Yo trataré de ser lo más concreto posible y dar los datos tal y como se ven realmente en mi máquina.
Los dos discos que estoy usando son de 80 GBytes y el esquema de particiones que he hecho es el siguiente:
/dev/ad4s1a 3G / swap 512M /dev/ad4s1e 4G /var /dev/ad4s1f 8G /tmp /dev/ad4s1g 60G /usr
como ves, el mismo esquema de particiones que sugiere /stand/sysinstall pero adaptado a mis preferencias (ya sabrás que el tamaño nunca resulta tan justo y luego al crear la partición real varía un poco... incluso si sumas los tamaños parciales verás que no son los 80 GBytes de que en teoría dispongo... aunque ya también sabrás que NO son realmente 80 GBytes y que el marketing "infla" los discos... en fin, dejémoslo en que aproximadamente esos son los tamaños que deseo para las particiones).
¿Y en el otro disco?, pues de esta forma:
/dev/ad6s1e 3G /rootback swap 512M /dev/ad6s1f 72G /NOFUTURE
como ves, tampoco tiene mucho misterio. Fíjate que he tenido la precaución de hacer que la primera partición (llamada aquí /rootback) mida 3 GBytes (idéntica en tamaño a la / del disco anterior), luego he reservado 512 MBytes de swap, y por último el resto del disco para otra única partición (llamada aquí /NOFUTURE).
Arrancando con el CD1 de FreeBSD y usando /stand/sysinstall no es nada difícil conseguir este esquema, pero hay varias cosas que se podrían aclarar.
En primer lugar, para crear el RAID, además de este esquema de particiones creado "a mano", usaremos luego un script facilitado con el propio vinum. Este script no tiene nada de particular (está escrito en Perl y es sencillo de comprender), pero parte de la premisa de que la partición del segundo disco llamada /rootback será la que luego sirva como alojamiento para la copia de la partición / del primer disco (de ahí que /rootback deba medir lo mismo -o ser más grande en todo caso- que la partición / del primer disco). Esta partición como ya comenté, NO formará parte del RAID.
En segundo lugar, la partición del segundo disco llamada /NOFUTURE será la que el script Perl que antes comentaba usará para generar el RAID. Por tanto, deberá medir al menos como la suma de las particiones /var, /tmp y /usr que hemos creado en el primer disco.
En tercer lugar, es imprescindible que cuando usemos /stand/sysinstall para crear todas estas estructuras, no se nos olvide decirle que queremos que el gestor de arranque nos lo instale en ambos discos (concretamente, en pantalla se indica como: Install the FreeBSD Boot Manager). Hay que pensar que ante un fallo del disco con el que normalmente arranquemos, usaremos el otro como sustituto y de ahí que ambos deban estar preparados para poder arrancar el sistema.
Si ya hemos configurado el hardware de forma óptima, hemos decidido el esquema, nombre y tamaño de las particiones y sabemos que necesitamos el gestor de arranque en todos los discos, es el momento de poner manos a la obra.
Para esto, arrancamos con el CD1 de FreeBSD y procedemos tal y como si fuésemos a instalar el sistema normalmente (¡que de hecho es lo que vamos a hacer!). Creamos el esquema de particiones mencionado (insisto nuevamente en no olvidar el gestor de arranque en ambos discos) y elegimos realizar una instalación mínima.
Doy por sentado que para un servidor como el que pretendemos montar es más que probable que con la instalación mínima no tengas suficiente... pero por ahora, nos vamos a concentrar en configurar vinum y luego ya tendremos tiempo de incluir todo lo demás. Piensa que si cometemos un error siempre da menos pereza empezar de nuevo si hay poco instalado que si tenemos ya un motón de programas instalados y configurados.
Terminada la instalación, rearranca y comprueba que todo va sin problemas. Da un vistazo a /etc/fstab y deberías ver algo como esto:
# Device Mountpoint FStype Options Dump Pass# /dev/ad4s1b none swap sw 0 0 /dev/ad6s1b none swap sw 0 0 /dev/ad4s1a / ufs rw 1 1 /dev/ad6s1f /NOFUTURE ufs rw 2 2 /dev/ad6s1e /rootback ufs rw 2 2 /dev/ad4s1f /tmp ufs rw 2 2 /dev/ad4s1g /usr ufs rw 2 2 /dev/ad4s1e /var ufs rw 2 2
(recuerda que ya he comentado que es probable que donde aquí ves /dev/ad4 y /dev/ad6 tu veas /dev/ad0 y /dev/ad2 y que tengas alguna línea más referente a otros posibles sistemas de ficheros).
También puedes si quieres teclear disklabel /dev/ad4s1 y debería ver algo como:
# /dev/ad4s1: type: ESDI disk: ad4s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 9728 sectors/unit: 156296322 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 6291456 0 4.2BSD 2048 16384 89 # (Cyl. 0 - 391*) b: 1048576 6291456 swap # (Cyl. 391*- 456*) c:156296322 0 unused 0 0 # (Cyl. 0 - 9728*) e: 8388608 7340032 4.2BSD 2048 16384 89 # (Cyl. 456*- 979*) f: 16777216 15728640 4.2BSD 2048 16384 89 # (Cyl. 979*- 2023*) g:123790466 32505856 4.2BSD 2048 16384 89 # (Cyl. 2023*- 9728*)
o para el otro disco, teclear disklabel /dev/ad6s1:
# /dev/ad6s1: type: ESDI disk: ad6s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 9728 sectors/unit: 156296322 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: # size offset fstype [fsize bsize bps/cpg] b: 1048576 6291456 swap # (Cyl. 391*- 456*) c:156296322 0 unused 0 0 # (Cyl. 0 - 9728*) e: 6291456 0 4.2BSD 2048 16384 89 # (Cyl. 0 - 391*) f:148956290 7340032 4.2BSD 2048 16384 89 # (Cyl. 456*- 9728*)
Si todo está correcto, el primer paso ya lo tenemos completado.
Ahora vamos a hacer que las particiones del primer disco /var, /tmp y /usr se integren con vinum. Esto, aunque puede hacerse "a mano", es mucho más cómodo hacerlo con ayuda de un script Perl que se facilita con vinum. Puedes conseguirlo de aquí o también de aquí. Incluso en tu propia máquina, en el directorio /usr/share/doc/en/articles/vinum/perl.html es posible que tengas una copia.
Para que todo quede más "recogido", crea un directorio, copia a él este script y ejecútalo. Poco más o menos, con estas órdenes:
# mkdir /bootvinum # cd /bootvinum # cp /desde_donde_hayas_puesto/bootvinum . # chmod u+x bootvinum # ./bootvinum
Si todo ha ido bien, NO deberías ver ningún mensaje. El script en Perl únicamente da mensajes cuando algo no va bien. Lo que si puedes hacer es teclear ls -la /bootvinum y verás que han aparecido una serie de ficheros nuevos. Concretamente, el resultado del listado debería ser algo así:
-rwxr-xr-x 1 root wheel 16659 Aug 15 12:49 bootvinum -rw-r--r-- 1 root wheel 592 Aug 15 12:54 create.UpWindow -rw-r--r-- 1 root wheel 625 Aug 15 12:54 create.YouCrazy -rw-r--r-- 1 root wheel 601 Aug 15 12:54 disklabel.ad4s1 -rw-r--r-- 1 root wheel 840 Aug 15 12:54 disklabel.ad4s1.b4vinum -rw-r--r-- 1 root wheel 579 Aug 15 12:54 disklabel.ad6s1 -rw-r--r-- 1 root wheel 687 Aug 15 12:54 disklabel.ad6s1.b4vinum
(también se habrán creado algunos otros ficheros en /etc, pero por ahora, nos despreocuparemos de ellos). Vamos a dar un vistazo a ver que son cada uno de estos ficheros:
- bootvinum: este fichero es el script en Perl que acabas de ejecutar.
- create.YouCrazy: con un nombre tan particular como "YouCrazy" vinum se referirá a tu primer disco. En realidad este fichero lo que contiene son las órdenes que habrá que pasar a vinum (de ahí lo de "create") para que de forma automática configure el primer disco del RAID. Puedes ojearlo sin problemas pues no es más que un simple fichero de texto.
- create.UpWindow: con el nombre "UpWindow" vinum se referirá a tu segundo disco. Al igual que antes, este fichero contiene las órdenes que habrá que dar a vinum para que sepa como tratar tu segundo disco.
- disklabel.ad4s1 y disklabel.ad6s1: en estos dos ficheros están los datos con los que luego "etiquetaremos" cada uno de los dos discos duros.
- disklabel.ad4s1.b4vinum y disklabel.ad6s1.b4vinum: en estos dos ficheros están los datos de las "etiquetas" de los discos justo antes de que vinum haya tocado nada en ellos.
Si te preguntas que porqué vinum da esos nombres tan raros a los discos ("YouCrazy" y "UpWindow") te diría que la idea es que los nombres de los discos no hagan ningún tipo de referencia a su alojamiento físico (es decir, que si un disco está en /dev/ad4 o /dev/ad6 no tengamos forma de saberlo por su nombre). ¿Y esto por qué? pues porque como ya comenté al principio, ambos discos serán completamente intercambiables (e incluso, funcionaran por separado como si nada) y así, aunque los cambiemos de controladora vinum los seguirá llamando con esos mismos nombres tan raros. De todas formas, y si eres un poco maniático, puedes editar el script en Perl y verás que está perfectamente indicado donde "tocar" para asignar a los discos los nombres que tu quieras.
Muy bien, pues ahora que tenemos estos ficheros creados es el momento de rearrancar en modo "monousuario" y comenzar a trabajar en serio. Para esto teclea:
# reboot
y cuando veas en pantalla:
Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel] in 10 seconds ...
teclea:
boot -s
Cuando te pregunte Enter full pathname of shell or RETURN for /bin/sh: simplemente pulsa "Intro" y todo estará preparado para continuar. Ahora cámbiate al directorio /bootvinum y etiqueta los discos con ayuda de los ficheros que antes nos ha creado el script en Perl. Para esto haz:
# cd /bootvinum # disklabel -R ad4s1 disklabel.ad4s1 # disklabel -R ad6s1 disklabel.ad6s1
Ya falta muy poco... pero para poder seguir habrá que hacer que la partición de arranque que se habrá montado como únicamente de lectura pase a montarse como de lectura y escritura (o si no, no nos permitirá cambiar nada de ella). Esto es tan sencillo como hacer:
# mount /
y todo listo. Ahora por fin vamos a pedir a vinum que configure el primer disco de nuestro RAID. Teclea esto:
# vinum create create.YouCrazy
este proceso tarda un poco pero sobre todo te informará de que vinum acaba de configurar tu primer disco y de que ya lo ha activado. De todas formas, no está de más que compruebes que todo ha ido correctamente. Si quieres hacerlo, esto te ayudará:
# fsck -n /dev/vinum/var # fsck -n /dev/vinum/tmp # fsck -n /dev/vinum/usr
Ninguna de estas órdenes debe dar el más mínimo error. Si lo diesen, no lo arregles (me refiero a que no contestes Y a la pregunta ...fix [yn]? que hace el comando fsck). En vez de eso, revisa tu esquema de particiones pues algo no ha ido bien. Compara la salida de los comandos disklabel que más arriba te facilitaba con los de tu sistema. Incluso en el peor de los casos, siempre puedes dejar todo "como estaba" tecleando:
# disklabel -R /bootvinum/disklabel.ad4s1.b4vinum # disklabel -R /bootvinum/disklabel.ad6s1.b4vinum
para poder volver a intentarlo.
Bueno, si como es seguro todo ha ido bien, es el momento de "quitar" el fichero /etc/fstab que hemos estado usando hasta ahora y sustituirlo por el que indicará a nuestra máquina como usar vinum. Esto también es muy sencillo, basta hacer:
# mv /etc/fstab /etc/fstab.b4vinum # cp /etc/fstab.vinum /etc/fstab
y ya está. Para terminar con el trabajo en modo "monousuario" basta con que teclees CNTRL+D. Esto hará que la máquina cambie al modo "multiusuario" de siempre. Aprovecha para conectarte como administrador y añade start_vinum="YES" a tu fichero /etc/rc.conf para que vinum se active de forma automática con cada arranque.
Pues ya está hecho lo más difícil. Vamos ahora con el segundo disco. Te aseguro que la cosa será bastante más sencilla. Simplemente tendrás que etiquetar este nuevo disco y pedir a vinum que lo integre en el RAID. Haz lo siguiente (por cierto, te recuerdo que ya estamos trabajando en modo "multiusuario"):
# cd /bootvinum # vinum create create.UpWindow
verás mensajes muy parecidos a los que viste cuando hiciste esto mismo para el primer disco, con la salvedad de que vinum dirá ahora que aunque ha aceptado incluir este segundo disco en el RAID, aún no tiene el mismo contenido que el primer disco. Pues hagamos que lo tenga:
# vinum start -w var.p1.s0 # vinum start -w tmp.p1.s0 # vinum start -w usr.p1.s0
Sin embargo, no querría dejar de avisarte de que cada una de estas órdenes implica que se realice una copia de cada una de esas particiones de un disco al otro. Quiero decir con esto que dependiendo de lo rápido que sean tus discos, este proceso tardará más o menos. Para que te hagas una idea, en mi sistema, como las particiones /var y /tmp no son muy grandes, las dos primeras órdenes no tardan mucho, pero la tercera, al tener la partición /usr unos 60 GBytes la cosa se dilata y unos 15 minutos no hay quien se los quite. De todas formas basta con tener paciencia y cuando termine tendrás tu RAID funcionando casi a pleno rendimiento... ¿casi?
En realidad la parte RAID del sistema está funcionando a pleno rendimiento, pero aún nos queda por tratar la partición de arranque. Desde el principio comenté que esta NO forma parte del RAID y que habrá que tratarla "a mano". Para hacer una copia completa de ella en /rootback (recuerda que esta partición pertenece al segundo disco) teclea:
# cd /rootback # dump 0f - / | restore rf - # rm restoresymtable
Me gustaría resaltar algunos detalles referentes al tratamiento de esta partición:
- Como cada cierto tiempo habrá que repetir las órdenes anteriores, mejor crear un script que lo haga de forma mecánica y llamarlo desde cron cuando estimemos oportuno.
- Como la partición /rootback solo deberíamos usarla para esto, lo más seguro es no montarla de forma automática desde /etc/fstab, si no hacerlo únicamente cuando vayamos a duplicar en ella el contenido de la partición de arranque.
Aquí tienes un posible script para hacer lo que he propuesto:
#!/bin/sh # hace una copia de / en /rootback # /sbin/mount /dev/ad6s1a /rootback /usr/bin/chflags -R noschg /rootback/* /usr/bin/chflags -R nosunlnk /rootback/* /bin/rm -rf /rootback/* /bin/rm -rf /rootback/.[a-z]* cd /rootback /sbin/dump -0f - / | restore rf - cd / /bin/rm /rootback/restoresymtable /sbin/umount /rootback
para que todo funcione correctamente, también deberás "comentar" -mejor que eliminar- la línea del fichero /etc/fstab que hace referencia al montaje automático de /dev/ad6s1a. Por cierto, los comandos chflags son para poder eliminar completamente el contenido de /rootback antes de llenarlo de nuevo (ten en cuenta que en esta partición hay algunos ficheros fundamentales para el sistema y por tanto, tratará de evitar que los borres accidentalmente).
Si te preguntas como de a menudo debes ejecutar este script, piensa en el uso que tiene tu máquina. En realidad, la partición de arranque no cambia demasiado frecuentemente pues los usuarios no tienen normalmente permiso para escribir nada en ella y solo el administrador es quien puede hacerlo... así que tu mismo serás quien mejor puede saber cuan frecuentemente cambia. Ah... y por cierto, no se te olvide incluir la ejecución de este script en cron no vaya a ser que justo el día que se estropee el disco duro sea cuando recuerdes que tenías que haber hecho las copias de la partición de arranque.
Una cosa más, si quieres hilar muy fino, puedes teclear:
# rmdir /NOFUTURE
pues este directorio ya no nos hará falta más.
Vamos a simular un "desastre" para quedarnos tranquilos de que si ocurre algo realmente sabremos como recuperarlo. Además, un poco de práctica no nos irá mal y será mejor hacerlas ahora que aún no tenemos datos de valor en los discos de nuestro RAID. Incluso diría más, creo que no hay nada peor que confiar en que tenemos un sistema que nos parece seguro y que luego resulte que esta sensación era falsa y en el momento de la verdad no podemos recuperarlo como esperábamos.
Por tanto, para no andarnos con "tonterías", te animaría a desconectar físicamente tu primer disco y ver que tal reacciona vinum. Esta situación simularía un fallo total del disco o de su controladora. Antes de que lo hagas, me gustaría comentar algunos detalles:
- Te propongo hacerlo con el primer disco (con /dev/ad4 en mi caso o con /dev/ad0 casi seguramente en el tuyo) para así asegurarte de que el segundo disco incluye -y funciona correctamente- el cargador de arranque.
- Si tienes la suerte de tener un hardware que soporte la "extracción en caliente" (es decir, que se puede quitar un disco con el ordenador funcionando) este es el momento de probarlo. Si no es así, tendrás que parar la máquina y realizar el proceso "sin corriente".
- Si no te gusta "hurgar" en el interior de la máquina (mejor que te vayas acostumbrando pues alguna vez tendrás que hacerlo quieras o no) puedes recurrir al comando atacontrol detach 2 (probablemente en tu caso el 2 deba ser un 0; puedes comprobarlo haciendo atacontrol list) para desconectar el disco pero desde un punto de vista software... el efecto será parecido a desconectarlo físicamente, pero ten en cuenta que al sistema esto le sentará "como un tiro", pues en ese disco están todos los datos que se están usando para funcionar en ese preciso instante, así que después de ejecutar ese comando es casi seguro que obtendrás un "kernel panic" (probablemente no llegues ni a ver ese mensaje antes de que tengas que pulsar reset) pero habrás conseguido que ese disco sea "desechado" por vinum sin tener que "hurgar" en el interior de la máquina.
Si has desconectado el disco, conecta de nuevo la alimentación y podrás comprobar si tu máquina te permite o no arrancar de un disco que no sea el maestro de la controladora primaria... Este tipo de opciones de arranque se configuran desde la BIOS y cada una suele tener su apartado particular para esto. Si tienes la suerte de que tu BIOS sea lo suficientemente moderna, ella sola sabrá que ahora no existe el primer disco y también ella sola arrancará desde el segundo disco. De todas formas, si tu máquina no permite este tipo de arranque no hay problemas. Bastará con que el que ahora es el segundo disco lo muevas al lugar del primero (y el primero lo guardes mientras en un cajón) pues afortunadamente, como ya comenté, vinum nombra a los discos de forma muy particular y por mucho que lo cambies de controladora, siempre sabrá como se llamaba y de que RAID formaba parte, además de reconocer todas las particiones que tenía sin mayores problemas.
Si ves que el arranque comienza pero que al poco se detiene con mensajes de error, tampoco debe cundir el pánico. Probablemente lo único que estará ocurriendo es que el kernel no sabe desde donde montar la partición de arranque (ten en cuenta que antes era /dev/ad4 y ahora debe ser /dev/ad6). Para resolver esto, cuando veas en pantalla:
Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel] in 10 seconds ...
teclea:
boot -as
y en el prompt que aparece escribe:
ufs:/dev/ad6s1a
y arrancarás en modo "monousuario". Ahora teclea esto:
# mount / # cp /etc/fstab /etc/fstab.org # cp /etc/fstab_only_have_ad6s1 /etc/fstab
y todo listo. Aunque no te lo creas, pulsa CNTRL+D para ir a modo "multiusuario" y verás como aún con un disco de menos, todo ha vuelto a la normalidad.
Si te preguntas que de donde ha salido el fichero /etc/fstab_only_have_ad6s1 te diría que teclees ls -la /etc/fstab* y verás algo así:
-rw-r--r-- 1 root wheel 379 Aug 14 10:09 fstab -rw-r--r-- 1 root wheel 507 Aug 15 11:54 fstab.b4vinum -rw-r--r-- 1 root wheel 302 Aug 15 11:21 fstab.org -rw-r--r-- 1 root wheel 299 Aug 15 11:54 fstab.vinum -rw-r--r-- 1 root wheel 380 Aug 15 11:54 fstab_ad4s1_root_bad -rw-r--r-- 1 root wheel 358 Aug 15 11:54 fstab_only_have_ad4s1 -rw-r--r-- 1 root wheel 379 Aug 15 11:54 fstab_only_have_ad6s1
todos estos ficheros los generó el script Perl que usamos hace tiempo en previsión de lo que pudiera pasar. Como ves, además de que falle el primer disco, está previsto que falle el segundo e incluso que falle la partición de arranque únicamente.
Date cuenta que a partir de aquí el servidor puede seguir con su trabajo normal, y que los usuarios en realidad únicamente se habrían "detenido" mientras tú rearrancabas y copiabas el par de ficheros que indicaba más arriba.
Ahora, y con el servidor ya nuevamente funcionando pero con un disco menos, será el momento de comprar un disco nuevo para sustituir al averiado. En nuestro caso, bastará con reinstalar el disco que antes habíamos quitado e indicarle a vinum que "replique" los datos en ese disco.
Si ya has instalado de nuevo el disco, conéctate como administrador y arranca /stand/sysinstall. Después, elige de sus menús las siguientes opciones:
- Do post-install configuration of FreeBSD - The disk Slice (PC-style partition) Editor - elige ad4 (o ad6 si es ahí donde está el disco nuevo) - pulsa 'A' (el disco entero) y 'W' (que escriba los cambios) - elige luego: Install the FreeBSD Boot Manager - termina la sesión con /stand/sysinstall
como ves, lo único que hemos hecho es decir a FreeBSD que todo el nuevo disco será para él y agregarle el cargador de arranque.
Ahora rearranca pero en modo "monousuario". Poco más o menos así:
# reboot
y cuando veas en pantalla:
Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel] in 10 seconds ...
teclea:
boot -s
Cuando te pregunte Enter full pathname of shell or RETURN for /bin/sh: pulsa "Intro" y todo estará preparado para continuar (recuerda que si tu sistema no encuentra él solo la partición de arranque deberás teclear boot -as y proceder como ya comenté más arriba).
Sitúate en el directorio /bootvinum y ejecuta los siguientes comandos:
# cd /bootvinum # disklabel -R ad4s1 disklabel.ad4s1 # vinum start # fsck -p
Terminados estos comandos ya puedes volver a modo "multiusuario" pues el servidor ya está casi listo otra vez. Pulsa por tanto CNTRL+D y a continuación teclea esto:
# vinum start -w tmp.p0 # vinum start -w var.p0 # vinum start -w usr.p0
Como ya comenté, estos comandos tardan "un ratito" (o al menos así ocurre con el último en mi sistema). De todas formas, no hay más que esperar a que terminen y hacer:
# cp /etc/fstab.org /etc/fstab # newfs /dev/ad4s1a # tunefs -n enable /dev/ad4s1a # mount /dev/ad4s1a /mnt # cd /mnt # dump 0f - / | restore rf - # rm restoresymtable # cd / # umount /mnt
con lo que también tendrás la partición de arranque salvaguardada.
Y hasta aquí la recuperación. Si quieres, rearranca, conéctate, y teclea vinum list. Verás tu nuevo disco funcionando como si nada hubiese ocurrido (por cierto, si tu BIOS no arrancaba más que desde el primer disco y tuviste que mover el segundo a la controladora del primero, sería el momento de dejar todo otra vez en su lugar... aunque ya sabes que a vinum no le preocupa donde estén los discos físicamente).
También, y ahora que ya has hecho una prueba y sabes como desenvolverte, podría ser un buen momento para añadir a tu sistema "mínimo" todo el resto de software que puedas necesitar.
Si en lugar del primer disco se te hubiese estropeado el segundo, el proceso es prácticamente el mismo... quizás algo más sencillo. En este caso, el sistema arrancará sin problemas (pues el disco que se ha "salvado" es el primario y de ahí es desde donde arranca normalmente). Cambia /etc/fstab por /etc/fstab_only_have_ad4s1 y repite lo mismo de antes pero cambiando donde ponía /dev/ad4 por /dev/ad6 y donde ponía tmp.p0, var.p0 y usr.p0 por tmp.p1, var.p1 y usr.p1.
En la documentación de vinum encontrarás más ejemplos de fallos que permiten recuperar "desastres", por ejemplo, de la partición de arranque únicamente. Personalmente creo que cuando un disco falla -sea la partición que sea- es el momento de cambiarlo, y máxime si estamos hablando de un servidor como en este caso, pues la experiencia demuestra que a un fallo acompaña otro y otro...hasta que ya no hay solución para ese disco.
Imagino que si ya has ojeado man vinum habrás tecleado:
# vinum list
Este comando muestra bastantes detalles sobre el estado actual de vinum y del RAID. Sin embargo, si tienes tu servidor funcionando con un nivel de seguridad mayor de 1 (es decir, tienes en /etc/fstab una línea como kern_securelevel="2"o más) no será posible usar esta orden (verás que el sistema no te deja).
Desafortunadamente no he encontrado una solución para este "problema". O bien bajas el nivel de seguridad a 1 -menos para un servidor tal vez no sea razonable-, o bien no usas ese comando (tal vez eso sea lo más sencillo).
También es probable que si tienes un nivel de seguridad "alto", el script que propuse para copiar la partición de arranque de un disco al otro se "queje" de que determinados ficheros no puede borrarlos ni sobreescribirlos. Estos errores no deberían preocuparnos demasiado pues es más que probable que esos ficheros no cambien frecuentemente.
Por supuesto, agradeceré cualquier otra posibilidad al respecto y estaré encantado de incluirla en este mismo documento.
Si algo de lo que he contado no te ha quedado claro, te rogaría que leyeses muy atentamente los documentos que podrás encontrar aquí. Su autor cuenta lo mismo que yo he contado y proporciona muchos ejemplos y detalles. Sobre todo te podrás enterar de la nomenclatura que usa vinum y verás un par de diagramas de como organizar los discos de forma muy parecida a la que yo he comentado. Tampoco debes dejar de leer esto así como las páginas del manual ( man vinum y man 4 vinum).
También te puede interesar saber que todo lo que aquí he contado lo he realizado sobre FreeBSD 4.10, pero imagino que no habrá demasiadas diferencias con respecto a otras versiones... aunque personalmente no lo he comprobado.
Ah... me gustaría decir que sé que lo que yo he llamado particiones a lo largo de todo este documento FreeBSD lo llama slices, pero es que no me acabo de acostumbrar... te ruego que me perdones y espero que no te haya confundido. Recuerda también que donde yo he usado /dev/ad4 y /dev/ad6 tú es probable que tengas que usar /dev/ad0 y /dev/ad2.
Si has leído este artículo habrás visto que únicamente con software libre y con FreeBSD como sistema operativo hemos conseguido nuestro objetivo de tener un servidor en funcionamiento 24x7.
En Internet podrás encontrar multitud de discusiones sobre si los RAID hardware son mejores o peores que los RAID software (como lo es vinum), pero desde luego vinum aporta un nivel de confianza y tranquilidad para el administrador de un servidor que lo hace una opción muy interesante a tener en cuenta.
Está claro que disponer de un RAID como el comentado no evitará hacer copias de seguridad, pero si que sabremos que solo las necesitaremos ante un error "humano" y no ante un fallo del hardware.
Finalmente, y como otras veces, no estará de más desde aquí mostrar mi agradecimiento a toda la gente que hace posible FreeBSD. Por supuesto acepto cualquier sugerencia al respecto y si tengo que aclarar algo o corregir cualquier error estoy dispuesto a hacerlo.