X
  • ZFS
    June 1, 2008

Espejos ahumados

Guest Author

Restauración -- reparación, reconstrucción o recomposición -- es el proceso de reparar un dispositivo dañado utilizando el contenido de otros dispositivos en buen estado. Y esto es, exactamente, lo que cada administrador de volúmenes o matriz RAID debe hacer cada vez que uno de sus discos muere, se cambia o sufre un corte de corriente transitorio.

Para un espejo, la restauración puede ser tan sencilla como hacer una copia de todo el disco. Para RAID-5 es un poco más complicada: en lugar de copiar un disco en otro, todos los demás discos de la banda RAID-5 deben someterse juntos al proceso XOR. Pero la idea de partida es la misma.

En un sistema de almacenamiento tradicional, la restauración se produce en el administrador de volúmenes o en el hardware RAID. En cualquier caso, siempre por debajo del sistema de archivos.

Pero esto es ZFS y, por supuesto, tenía que ser diferente.

En una entrega anterior he comentado que la restauración de RAID-Z requiere un enfoque distinto puesto que necesita los metadatos del sistema de archivos para determinar la geometría RAID-Z. En efecto, ZFS hace un 'cp -r' del árbol de bloques de almacenamiento de un disco a otro. Suena menos eficiente que una copia directa de un disco completo en otro, y atravesar a salvo un almacenamiento vivo es, sin la menor duda, una operación arriesgada (hablaremos de ello en próximas entregas), pero resulta que la restauración dirigida por metadatos ofrece tantas ventajas que hemos decidido utilizar este procedimiento incluso con espejos sencillos.

La razón más importante es la integridad de los datos. Con una copia de disco no hay forma de saber si el disco original devuelve datos en buen estado o no. La integridad de los datos de extremo a extremo requiere que cada bloque de datos se verifique con respecto a una suma de comprobación independiente; no basta con saber que cada bloque es coherente consigo mismo ya que no se capturan los fallos comunes de hardware y firmware, como pueden ser escrituras erróneas o lecturas fantasmas.

Al atravesar los metadatos, ZFS puede utilizar sus propias sumas de comprobación de extremo a extremo para detectar y corregir la corrupción silenciosa, exactamente igual que durante una lectura normal. Si un disco devuelve datos dañados, ZFS los detectará y repetirá su lectura. Si se trata de un espejo de tres vías y uno de los dos discos supuestamente sanos estuviera dañado, ZFS utilizará la suma de comprobación para determinar cuál de ellos es el correcto, copiar los datos en el nuevo y reparar el disco dañado.

Una simple copia de un disco completo omitiría todo este proceso de protección de datos. Por esta única razón, la restauración dirigida por metadatos debería ser deseable incluso aunque su aplicación pueda tener un coste importante en términos de rendimiento.

Afortunadamente, en la mayoría de los casos no es así; de hecho, la restauración dirigida por metadatos ofrece varias ventajas:

Sólo bloques vivos. ZFS no pierde tiempo ni ancho de banda de E/S copiando bloques de disco que están libres porque no forman parte del árbol de bloques de almacenamiento. Si su almacenamiento está sólo al 10-20% de su capacidad, es una gran victoria.

Poda transaccional. Si un disco sufre un corte de luz transitorio no hace falta restaurarlo por completo, sólo las partes que hayan cambiado. Trataré este asunto con más detalle en una entrega próxima, pero, de momento: ZFS utiliza el tiempo de nacimiento de cada bloque para determinar si es necesario restaurar alguna de las ramas más bajas del árbol. Esto le permite saltarse las ramas más grandes para descubrir rápidamente los datos que han cambiado desde que comenzara el corte de luz.

En la práctica, esto significa que si un disco sufre un corte de luz de cinco segundos, la restauración tardará sólo cinco segundos. Y no tendrá que pagar ninguna cantidad extra por arreglarlo - ya sea en metálico o en rendimiento - igual que como cuando cambia algo en Veritas. La poda transaccional es una capacidad intrínseca de la arquitectura de ZFS.

Restauración de arriba abajo. Un lugar de almacenamiento es un árbol de bloques. Cuanto más se asciende en el árbol peor es el desastre que supone perder un bloque, porque se pierde el acceso a todo lo que queda por debajo.

El proceso a través de metadatos permite a ZFS hacer una restauración de arriba abajo. Es decir, lo primero que ZFS restaura es el bloque superior y las etiquetas del disco. A continuación, restaura los datos de todo el lugar de almacenamiento, luego cada metadatos del sistema de archivos... y así hasta que llega a la base del árbol. En todo este proceso, ZFS respeta rigurosamente la regla siguiente: no se restaura ningún bloque hasta haber restaurado todos sus antecesores.

No hace falta destacar la importancia de la regla. Con una copia completa de disco, incluso aunque se haya llegado a alcanzar el 909% existe la posibilidad de que siga pendiente de copiarse uno de los 100 bloques principales del árbol. Esto significa que, desde una punto de vista MTTR, no se ha conseguido el menor progreso: un segundo fallo del disco en este punto sería una auténtica catástrofe.

Con la restauración de arriba abajo, cada bloque que se copia aumenta la cantidad de datos detectables. Y si hubiera un segundo fallo del disco... todo lo restaurado hasta ese punto seguiría estando restaurado y disponible.

Restauración basada en prioridad. ZFS no lo hace todavía, pero ya lo tiene en los conductos. La restauración ZFS sigue la estructura lógica de los datos y sería muy fácil etiquetar cada sistema de archivos o cada archivo en función de su prioridad para una restauración concreta. Por ejemplo, en un servidor de archivos puede ser necesario restaurar primero los calendarios (son importantes aunque sean pequeños), luego los directorios /var/mail, después los de inicio, y sucesivamente.


Lo que espero que se transmita con cada una estas entregas no es sólo la parte mecánica de cómo se implementa una función o característica específica, sino ilustrar el modo en que cada parte de ZFS forma un todo integrado. No es evidente a primera vista, por ejemplo, que la semántica transaccional tenga algo que ver con la restauración - literalmente, incluso la poda transaccional hace más rápida la restauración de órdenes importantes en cortes de luz transitorios. Habrá más sobre eso en la próxima entrega.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.