Guía de buenas prácticas con ZFS y Solaris

Después de 3 meses peleándome con 20 servidores Solaris, utilizando ZFS y iSCSI como solución de almacenamiento, creo que he aprendido unas cuantas cosas que os pueden servir si un día de estos os encontráis con esta tecnología en alguna empresa.

ZFS es un sistema de archivos creado por Sun para su sistema operativo Solaris, que fue adoptado por muchas compañías debido a que estaba también disponible en la versión open source de Solaris (Open Solaris). Durante muchos años se ha considerado como el sistema de archivos más avanzado, debido a sus features como los snapshots, detección y corrección de errores, gestión de volúmenes, etc. Hoy día, sin embargo, no tiene un futuro muy claro, dado que Oracle ha descontinuado la publicación de la rama Open Solaris.

ZFS no puede ser portado a Linux de forma nativa, debido a una incompatibilidad de licencias, aunque algunos ya han conseguido utilizarlo en Ubuntu y otras distribuciones.  ZFS, aunque ya ha sido portado con éxito a FreeBSD y es utilizado por algunas soluciones de almacenamiento como FreeNAS, no creo que FreeBSD+ZFS se convierta en una solución muy extendida en la empresa. De cualquier manera, hoy día sigue habiendo bastantes empresas que utilizan Solaris + ZFS o las últimas versiones de OpenSolaris + ZFS.

Guía de buenas prácticas con ZFS y Solaris

– Utiliza una buena controladora enterprise.  La controladora, a pesar de que todos los discos se han de configurar como Single para dejar que ZFS se encargue del Raid, soporta bastate trabajo en producción, por lo que es frecuente encontrarse con corrupción de datos, sobrecalentamiento o cuelgues del sistema debidos a la controladora.

– Deja siempre un 10% mínimo de espacio libre en cada pool.  ZFS necesita espacio en disco para las operaciones de cálculo de Raid y el borrado de grandes snapshots.  Operaciones en las que ZFS se queda sin espacio, unido a una mala configuración te pueden hacer incluso perder el pool completamente.

– Raidz2 vs Raidz3. Raidz es el equivalente en ZFS al raid5, y permite perder un disco (z1), dos discos (z2) o tres discos (z3) sin pérdida de datos.  En mi experiencia raidz3 pierde bastante performance, en especial cuando el número de discos es elevado.  Las operaciones de reconstruccción del raid también se enlentecen de forma considerable.  Un pool de  13 discos de 1.0TiB en raidz3 tarda unos 7 días en el proceso de resilvering -reconstrucción- de un disco, por lo que recomiendo buscar otras soluciones como dos pool en raidz2 o una tira de mirrors (~raid10).  No utilizar raidz en pools de más de 8 ó 9 discos.

– Snapshots y autosnapshots.  Una de las cosas más oscuras cuando se trabaja con ZFS es el cálculo del espacio libre.  Podemos decir que a veces ni siquiera ZFS sabe cuánto espacio libre tiene, porque los snapshots se pueden guardar dentro de los propios volúmenes o en el espacio libre restante.  Cuando ZFS se queda sin espacio en el segmento asignado puede tratar de escribir en espacio que considera libre, lo que a veces puede llevar a la corrupción de datos.  Para evitar esto, hay que controlar los parámetros RESERVATION y REFRESERVATION de cada volúmen, para reservar espacio para los datos+snapshots (reservation) o datos sólamente (refreservation).  Reservation garantiza que los datos y los snapshots tienen un espacio físico asignado, por lo que debemos tener cuidado si después creamos volúmenes que luego presentaremos con iSCSI.  Para entendernos, si creamos un volumen de 1.0TiB con Reservation de 1.0TiB, no podemos presentar más de 700GiB con iSCSI, porque los snapshots se escribirán dentro de ese Tera y necesitarán esos 300GiB. Por tanto mi consejo es definir Refreservation de 1.0TiB (reservation=none) para garantizar espacio para los datos (más importantes que los snapshots), haciendo que los snapshots se escriban fuera del volumen y poder presentar un volumen de 1.0TiB con iSCSI.  Aseguraros de que queda suficiente espacio para los snapshots fuera de los volúmenes y además, otro 10% restante para las operaciones de ZFS.

– HotSwap.  El cambio de discos en caliente depende exclusivamente de la capacidad de la controladora.  A veces los drivers que existen para Solaris no son muy buenos, y hacen que Solaris se cuelgue o se quede permanententemente leyendo la configuración de los pool.  Todos estos fallos son atribuibles a la controladora y sus drivers.  Si los drivers no te permiten avisar a la controladora de que ha habido un cambio de disco, Solaris detectará un fallo y será imprescindible reiniciar para que la controladora lea la configuración de discos en el proceso de arranque, y de este modo Solaris pueda actuar en consecuencia.

– Recuerda que la configuración del pool se guarda en los propios discos.  Si tienes dificultades para leer la configuración del pool, puedes llevarte los discos a otra máquina con Solaris e importar el pool:

$ zpool import -f nombre-pool

«Zpool export» es como un umount y sirve para que cuando queramos importar en otra máquina no nos avise de que el pool está ya previamente montado.  Habitualmente cuando nos llevamos el pool a otra máquina es porque ha quedado inaccesible, por lo que tampoco es posible ejecutar el comando zpool export.

– Programa un script para que te envíe diariamente un «zpool status», «zfs list», etc. a tu e-mail.  Esto te ayudará a tener un histórico de estado de los pools a mano, imprescindible cuando entras en disaster recovery mode.  Solaris tiene una fantástica herramienta llamada fmstat para conocer el estado de todo el hardware.  Ante problemas, utiliza fmdump para consultar el histórico de avisos.

Bueno, después de este post me gustaría aclarar, que ZFS es un excelente sistema de archivos, que se recupera automáticamente de errores en disco, y que se considera uno de los sistemas de archivos más fiables que existen en la actualidad.  Mi experiencia está basada a una mala configuración de los pools, pools llenos, controladoras defectuosas, hardware de mala calidad, etc, y no es el día a día habitual con ZFS y Solaris.  Espero que, de cualquier modo, esta guía os ayude a localizar errores o a prevenirlos en entornos en producción.