Administración de ZFS en Solaris 11.4: pools, datasets, snapshots y scrubs

Qué es

ZFS es el sistema de archivos predeterminado de Oracle Solaris 11.4 y el único compatible como sistema de archivos raíz (UFS sigue siendo compatible para datos, pero los boot environments requieren ZFS). Dos comandos cubren casi toda la administración: zpool gestiona los pools de almacenamiento (los dispositivos físicos y la redundancia) y zfs gestiona los datasets (sistemas de archivos, volúmenes y snapshots) que residen dentro de un pool.

Por qué importa

A diferencia de una pila de Linux basada en LVM más un sistema de archivos, los pools y datasets de ZFS se gestionan como un único sistema, con sumas de verificación integradas, snapshots y, con send/receive, replicación nativa. Como los boot environments (véase el artículo sobre beadm de esta serie) son a su vez datasets de ZFS, entender zfs y zpool es un requisito previo para aplicar parches de forma segura, y no solo para administrar el almacenamiento.

Cómo aplicarlo

• Comprueba primero el estado de los pools: zpool status muestra los dispositivos de cada pool, su estado (ONLINE, DEGRADED, FAULTED) y cualquier acción de reparación necesaria; zpool status -x informa solo de los pools con problemas; zpool list ofrece un resumen en una línea con el tamaño, la asignación y el estado de cada pool.
• Lista e inspecciona los datasets: zfs list muestra los sistemas de archivos montados, los volúmenes y su uso de espacio; zfs list -t snapshot limita la vista a los snapshots.
• Crea un dataset con una propiedad definida en el momento de la creación: zfs create -o compression=on tank/data; para cambiar más adelante una propiedad de un dataset existente, usa zfs set compression=on tank/data.
• Crea una copia en un instante determinado: zfs snapshot tank/data@before-change. Los snapshots son de solo lectura y solo consumen espacio por los bloques que cambian después.
• Deshaz un cambio volviendo a un snapshot: zfs rollback tank/data@before-change. Se descartan todos los datos escritos desde ese snapshot; por defecto, el comando solo permite volver al snapshot más reciente y se niega a ejecutarse si existen otros más nuevos.
• Replica o respalda un dataset: zfs send tank/data@snap | zfs receive backuppool/data envía el flujo de datos de un snapshot como envío completo; el subcomando send también admite flujos incrementales entre dos snapshots.
• Comprueba la integridad de los datos de forma proactiva: zpool scrub <pool> lee y verifica cada bloque contra su suma de verificación y repara lo que permita la redundancia; zpool status informa del progreso del scrub y de cuándo terminó el último.
• Supervisa la E/S a nivel de pool: zpool iostat -v <pool> <interval> (véase también el artículo sobre rendimiento de esta serie) muestra las operaciones de lectura/escritura y el ancho de banda por dispositivo, repetido en el intervalo indicado.

Trampas

• Forzar un rollback más allá de snapshots más recientes: -r destruye todos los snapshots más recientes y -R destruye además sus clones, así que confirma antes qué existe con zfs list -t snapshot. Para los datasets de boot environment del pool raíz, usa beadm en lugar de zfs rollback o destroy directamente.
• Tratar zpool scrub como una copia de seguridad: verifica y repara según la redundancia, pero no protege frente al borrado de un dataset ni frente a un pool sin ninguna redundancia configurada.
• Olvidar que destruir un snapshot con clones dependientes requiere una opción de cascada explícita: lista siempre los dependientes antes de destruir nada.