Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización: 27 de marzo de 2007 - Martes
ZFS es una auténtica virguería. Se podrían escribir libros sobre ZFS y sus funcionalidades.
En mi despliegue actual ZFS, utilizo discos en "mirror" para proporcionar redundancia hardware, y "snapshots" ZFS como seguridad ante errores humanos o lógicos. Por supuesto, mantengo una copia de seguridad remota, mediante "rdiff-backup", tal y como explico en otra página.
Pero todos los discos duros implicados están en la misma sala, cercanos físicamente, conectados a las mismas tomas de corriente y los mismos SAI's. Si hay un problema localizado en esa zona, como una sobrecarga eléctrica o un incendio, podemos perder tanto los discos en servicio como sus copias de seguridad. La opción más simple es seguir utilizando "rdiff-backup", pero almacenando los datos en un disco duro en una localización remota, a poder ser "offline". De hecho es lo que estoy haciendo ahora mismo, sobre un disco duro USB2 que desconecto físicamente cuando no estoy realizando un backup.
Pero en esta ocasión quiero explorar la posibilidad de mantener una unidad redundante del "zpool" de forma remota.
Lo ideal sería utilizar iSCSI, pero la versión actual de Solaris 10 no permite actuar como "target", y mis "target" linux ya no admiten más carga. La otra posibilidad es emplear NFS, que tiene la ventaja de la ubicuidad, pero utilizar un sistema de ficheros intermedio, en vez de bloques de almacenamiento.
El primer paso consiste en crear un fichero de tamaño adecuado en el servidor NFS. En este caso, el "zpool" tiene unos 160 gigabytes, así que creo un fichero un poco más grande. Para ello escribo:
# dd if=/dev/zero of=zpool-tesalia-datos seek=350000000 count=1
El siguiente paso consiste en montar el directorio donde se encuentra el fichero anterior en la máquina con ZFS.
En mi caso, debo lanzar el servidor NFS con la opción de "rw,no_root_squash,async" (mediante YAST), y abrir el cortafuegos dado que NFSv3 utiliza puertos dinámicos. Eso se hace con
# iptables -I INPUT -s 192.168.50.130 -j ACCEPT # iptables -I INPUT -s 192.168.50.132 -j ACCEPT
En Solaris 10 debemos montar el directorio con
# mount -F nfs -o vers=3 192.168.50.132:/media/usbdisk /mnt/castor
En Solaris hay que forzar el uso de NFSv3 (por defecto se usa NFSv4), por problemas de compatibilidad NFSv4 entre ambos sistemas. Cuando se resuelvan esos problemas, no se necesitará abrir el cortafuegos de forma tan masiva ni forzar el uso de NFSv3.
Una vez disponible en la máquina Solaris, añadimos el fichero NFS al "zpool"
# zpool attach datos c1d0s4 /mnt/castor/zpool-tesalia-datos
Una vez ejecutado el comando anterior, Solaris empieza a replicar el estado actual del "zpool" sobre el fichero remoto. Esta operación puede llevar varios minutos, pero lo grave es que mientras se está realizando esa replicación remota, el rendimiento de la máquina Solaris cae en picado, con tiempos de acceso a disco de varios minutos. La máquina es prácticamente inusable durante ese periodo.
Una vez completada la replicación, podemos desactivar el volcado remoto mediante
# zpool offline datos /mnt/castor/zpool-tesalia-datos
Bringing device /mnt/castor/zpool-tesalia-datos offline
# zpool status
pool: datos
state: DEGRADED
status: One or more devices has been taken offline by the adminstrator.
Sufficient replicas exist for the pool to continue functioning in a
degraded state.
action: Online the device using 'zpool online' or replace the device with
'zpool replace'.
scrub: resilver completed with 0 errors on Tue Mar 27 22:35:31 2007
config:
NAME STATE READ WRITE CKSUM
datos DEGRADED 0 0 0
mirror DEGRADED 0 0 0
c1d0s4 ONLINE 0 0 0
c2d0s4 ONLINE 0 0 0
/mnt/castor/zpool-tesalia-datos OFFLINE 0 0 0
errors: No known data errors
En este momento tenemos una réplica remota de los datos. Ahora podemos desactivar el servidor NFS, desenchufar el disco USB y guardarlo en un cajón, a poder ser en la ciudad de al lado :-).
De vez en cuando volvemos a montar el disco USB, reactivamos el servidor NFS y sincronizamos el "zpool" con los últimos cambios. Eso se hace con
# zpool online datos /mnt/castor/zpool-tesalia-datos
Bringing device /mnt/castor/zpool-tesalia-datos online
[root@tesalia castor]# zpool status
pool: datos
state: ONLINE
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scrub: resilver in progress, 0.02% done, 4h51m to go
config:
NAME STATE READ WRITE CKSUM
datos ONLINE 0 0 0
mirror ONLINE 0 0 0
c1d0s4 ONLINE 0 0 0
c2d0s4 ONLINE 0 0 0
/mnt/castor/zpool-tesalia-datos ONLINE 0 0 0
errors: No known data errors
Esta operación es bastante más rápida que el "resilvering" original, pero sigue machacando bastante el Solaris, con tiempos de acceso a disco de hasta 25 segundos.
El sistema funciona, pero el coste de rendimiento del "resilvering" es demasiado elevado. Consultando a los ingenieros de Sun, el consenso es que a) son conscientes de que el "resilvering" es demasiado agresivo y degrada significativamente el rendimiento del sistema, y en futuras revisiones Solaris tendrá un mejor comportamiento y b) el esquema propuesto funciona mientras todo va bien, pero no está soportado (por ejemplo, si el servidor NFS se desvanece, la versión actual de ZFS no lo detectaría, colapsando la máquina). Para hacer algo así, se requerirá iSCSI o similar.
Este esquema tiene otros problemas, como redirigir un tercio de los accesos a disco a través del servidor NFS, porque ZFS no tiene (de momento) ninguna noción de latencia o ancho de banda de disco a la hora de planificar los accesos a disco.
En resumidas cuentas, el sistema funciona pero su uso no es recomendable.
En el futuro volveré a hacer otra prueba cuando se cumpla algo de lo siguiente:
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
