Detección y diagnóstico de pérdida de datos en LizardFS

¿Qué ocurre cuando LizardFS no puede reconstruir un fichero?

LizardFS tiene dos interfaces de administración: una interfaz por línea de comandos y una interfaz web.

Aquí vemos la página principal de la interfaz web mostrando una visión global del sistema. Abajo nos salen los primeros 500 ficheros irrecuperables:

En esta pestaña vemos la distribución de errores. El objetivo "2" es un espejo, mientras que "ec82" se refiere al esquema 8+2 descrito más arriba:

Aquí tenemos la distribución de discos duros y podemos ver en qué servidores está cada uno de ellos:

La interfaz de línea de comandos de LizardFS permite obtener fácilmente el listado de ficheros irrecuperables:

root@dmzjcea:/home/jcea# lizardfs-admin list-defective-files \
                                        --unavailable --limit=9999999 \
                                        192.168.128.106 9421
Files with error flag = unavailable
  file 23: jcea/black_1/0F/0FBC1B56981CD117598412310AF4AF8276B5743294B4D3AF6141B4A2A22D1FBA - unavailable
  file 70: jcea/black_1/0F/0FCD09BBC155A1E52576A5675A156FD02B14DF3D37A52A9C139AF5D65009FE76 - unavailable
  file 195: jcea/black_1/0F/0FEB41ADE83147C1077A9B9C17F9C1ABCDE75ECF67F2C0B4C54C8E82AF5F4EDD - unavailable
[...]

Aquí obtenemos la lista de ficheros irrecuperables. Es importante poner un límite explícito en cuántos ficheros mostrar, ya que por defecto solo se listarán mil ficheros y a nosotros nos están fallando bastantes más.

Podemos ver los detalles de un fichero determinado:

root@dmzjcea:/srv/datos# lizardfs fileinfo jcea/black_1/0F/0FBC1B56981CD117598412310AF4AF8276B5743294B4D3AF6141B4A2A22D1FBA
jcea/black_1/0F/0FBC1B56981CD117598412310AF4AF8276B5743294B4D3AF6141B4A2A22D1FBA:
        chunk 0: 000000000001FB58_00000002 / (id:129880 ver:2)
                copy 1: 192.168.128.11:9424:_ part 2/10 of ec(8,2)
                copy 2: 192.168.128.12:9423:HighCapacity part 1/10 of ec(8,2)
                copy 3: 192.168.128.12:9426:HighCapacity part 6/10 of ec(8,2)
                copy 4: 192.168.128.15:9424:_ part 5/10 of ec(8,2)
                copy 5: 192.168.128.15:9425:_ part 8/10 of ec(8,2)
                copy 6: 192.168.128.71:9424:_ part 7/10 of ec(8,2)
                not enough parts available

Aquí podemos ver el estado de los diez fragmentos que se almacenan con el objetivo ec82. Vemos que solo están disponibles seis de los ocho fragmentos necesarios para recuperar la información. Mala suerte (bueno, en realidad el problema no es la suerte, sino la mala configuración de este almacenamiento LizardFS en particular). Solo queda borrar esos ficheros y recuperarlos de la copia de seguridad.

Veamos un fichero correcto, sin pérdida de datos:

root@dmzjcea:/srv/datos/jcea# lizardfs fileinfo z-a_borrar.txt
z-a_borrar.txt:
        chunk 0: 00000000006F6C98_00000001 / (id:7302296 ver:1)
                copy 1: 192.168.128.15:9423:_ part 4/10 of ec(8,2)
                copy 2: 192.168.128.15:9425:_ part 1/10 of ec(8,2)
                copy 3: 192.168.128.15:9426:_ part 8/10 of ec(8,2)
                copy 4: 192.168.128.15:9427:_ part 3/10 of ec(8,2)
                copy 5: 192.168.128.17:9423:_ part 5/10 of ec(8,2)
                copy 6: 192.168.128.23:9423:_ part 10/10 of ec(8,2)
                copy 7: 192.168.128.71:9423:_ part 7/10 of ec(8,2)
                copy 8: 192.168.128.71:9428:_ part 6/10 of ec(8,2)
                copy 9: 192.168.128.71:9431:_ part 9/10 of ec(8,2)
                copy 10: 192.168.128.71:9432:_ part 2/10 of ec(8,2)

¿Qué pasa si intentamos leer un fichero ilegible?

root@dmzjcea:/srv/datos# time cat jcea/black_1/0F/0FBC1B56981CD117598412310AF4AF8276B5743294B4D3AF6141B4A2A22D1FBA >/dev/null
cat: jcea/black_1/0F/0FBC1B56981CD117598412310AF4AF8276B5743294B4D3AF6141B4A2A22D1FBA: Input/output error

real    5m2.803s
user    0m0.000s
sys     0m0.000s

Por defecto (esto es configurable), LizardFS dará un error de lectura tras intentar leer el fichero durante cinco minutos.

¿Qué error exacto se produce? Veámoslo en Python:

>>> import errno
>>> try:
...     open("jcea/black_1/0F/0FBC1B56981CD117598412310AF4AF8276B5743294B4D3AF6141B4A2A22D1FBA").read()
... except Exception as e:
...   exc = e
...
>>> exc.errno == errno.EIO
True

La descripción de ese error es:

EIO I/O error. This will happen for example when the process is in a background process group, tries to read from its controlling terminal, and either it is ignoring or blocking SIGTTIN or its process group is orphaned. It may also occur when there is a low-level I/O error while reading from a disk or tape. A further possible cause of EIO on networked filesystems is when an advisory lock had been taken out on the file descriptor and this lock has been lost. See the Lost locks section of fcntl(2) for further details.

Básicamente, LizardFS está simulando un error de lectura de bajo nivel, como si un sector de un disco duro estuviese corrupto de forma irrecuperable. Semánticamente este error es el más apropiado y otros sistemas de ficheros como NFS (en el modo soft mount) optan por mostrar el mismo error si no son capaces de entregarte la información solicitada.

¿Cómo limpiar de errores un almacenamiento LizardFS?

Lo ideal sería volver a reconectar los discos duros desaparecidos. No es necesario que estén en el mismo servidor antiguo o, incluso, que estén todos enchufados en la misma máquina. Si LizardFS encuentra los fragmentos desaparecidos, los utilizará; le da igual cómo ha llegado a ellos.

Puede ser que el servidor sea irrecuperable y que los demás servidores tengan los puertos de disco duro completos. En ese caso se podría hacer algo similar a lo siguiente:

1. Enchufamos uno de los discos duros desaparecidos por USB, por ejemplo, y configuramos LizardFS para darle visibilidad.

   Por muy llenos que estén los servidores, seguro que podemos enchufarles algún disco por USB de forma temporal. En el peor de los casos, hasta podríamos usar una Raspberry PI durante unas horas para esta tarea.

2. En cuanto LizardFS vea alguno de los discos duros que habían desaparecido, podremos recuperar algunos de los ficheros (los que hayan pasado de tres fragmentos desaparecidos a solo dos). Pero, en vez de dedicarnos a recuperar los ficheros rescatados, que serán una minoría de todos los perdidos, es mejor proceder a la baja controlada de ese disco duro.

3. Para ello, configuramos LizardFS para reconocer que ese disco duro por USB se quiere retirar. Una vez activada esa función, LizardFS se dedicará a mover los datos de ese disco duro al resto del almacenamiento LizardFS. Este proceso puede llevar varias horas, dependiendo de la carga del almacenamiento, la velocidad USB, la velocidad de la red y el volumen de datos a mover.

4. Una vez que se ha vaciado ese disco duro (sus datos se habrán repartido por el resto del almacenamiento LizardFS), podemos desenchufarlo del USB. Enchufamos otro disco duro de los desaparecidos y repetimos desde el paso 3.

5. Cuando nos queden dos discos duros por vaciar, LizardFS verá que ya tiene al menos ocho fragmentos de datos (de los diez totales de una configuración 8+2) y ya se habrá dedicado a reconstruir ficheros y regenerar la redundancia. Si no hacemos nada más, LizardFS será capaz de recuperar todos los ficheros cuyo objetivo era ec82 y reconstruir de nuevo su redundancia 8+2.

6. Podemos seguir vaciando los dos discos duros desaparecidos que faltan, sin mayor problema. Técnicamente no sería necesario, pero si hay algún otro disco duro que está dando guerra, así nos aseguramos de recuperarlo todo.

   Se generará redundancia redundante (valga la... ¡redundancia!), pero no pasa nada. LizardFS irá viendo que le sobra información para el objetivo de 8+2 e irá borrando fragmentos innecesarios por su cuenta. Basta con darle unas horas para que haga limpieza. Por supuesto, durante ese tiempo los datos almacenados en LizardFS estarán disponibles, simplemente habrá más espacio ocupado que el objetivo buscado. Ese espacio se irá liberando poco a poco, sin hacer nada especial.

6. Los ficheros con objetivo "espejo" que hayan tenido mala suerte y ambas copias estén en los dos discos duros perdidos que aun no hemos vaciado, seguirán inaccesibles. Habrá que enchufar y desalojar al menos uno de los discos duros que faltan. Cuando haya una copia de los datos disponible, LizardFS regenerará automáticamente la otra copia en otro disco duro para recuperar la redundancia en espejo.

7. Por todo lo anterior, aunque técnicamente no sea necesario, yo recomendaría evacuar todos los discos duros desaparecidos, si es posible. Saber qué es lo mínimo a evacuar depende de conocer los detalles de configuración de objetivos de los diferentes ficheros contenidos en LizardFS. Esto puede ser algo esotérico si no entiendes cómo se configuró LizardFS. Lo más sencillo sería evacuar todos los discos duros y que LizardFS se encargue tanto de reconstruir la redundancia cuando tiene información suficiente, como de destruir redundancia si está por encima de los objetivos de disponibilidad configurados. [2]

   [2]

   Los objetivos de redundancia en LizardFS se pueden configurar de manera casi arbitraria y cada fichero del sistema de ficheros puede tener un objetivo diferente. Un fichero creado nuevo heredará los objetivos de redundancia de su directorio padre, pero su objetivo se puede cambiar en cualquier momento, tanto para subir como para reducir redundancia.

En este caso concreto, nada de esto es posible: El propietario de esta instalación LizardFS borró y reutilizó los discos duros para otros usos cuando falló el servidor en el que estaban alojados. No tuve ocasión de evacuar los datos antes del borrado de discos. En esas circunstancias no hay nada que yo o LizardFS podamos hacer más allá de borrar esos ficheros inaccesibles y recuperarlos de una copia de seguridad.

Para borrar esos ficheros hice algo similar a:

root@dmzjcea:/srv/datos# for i in `lizardfs-admin list-defective-files \
                                   --unavailable --limit=9999999 192.168.128.106 9421 \
                                   | tail +2 | grep ": jcea/" \
                                   | cut -d " " -f 5`; \
                         do echo $i; \
                         rm "$i"; \
                         done

Este código lista los ficheros inaccesibles bajo el directorio jcea/, mi responsabilidad, y los va borrando uno a uno. Funciona correctamente porque sé que los nombres de mis ficheros bajo ese directorio no contienen espacios u otros caracteres considerados separadores. Si no pudiéramos garantizarlo, habría que complicar un poco el código. Yo no lo he necesitado.

En total borro 12.338 ficheros de un total de 1.935.696. He perdido un 0.637% de los ficheros, lo que no está mal tras haber perdido cinco discos duros de un total de treinta. Afortunadamente, esos discos eran relativamente pequeños comparados con los que quedaron, así que se llevaron por delante menos ficheros de lo que podría parecer.

Una vez que mi area LizardFS estuvo limpia, volví a subir a LizardFS los ficheros destruidos desde otras réplicas remotas, dejando todo como estaba. Tener esos datos disponibles en otros lugares no fue suerte, fue... experiencia :-).

Objetivos de redundancia de LizardFS

En LizardFS se pueden configurar hasta cuarenta objetivos de redundancia diferentes y cada fichero puede configurarse con cualquiera de ellos y cambiarse en cualquier momento. En esta instalación en concreto de LizardFS hemos configurado tres objetivos diferentes:

root@dmzjcea:/srv/datos# lizardfs-admin list-goals 192.168.128.106 9421
Goal definitions:
Id      Name    Definition
1       1       1: $std _
2       2       2: $std {HighCapacity _}
3       3       3: $std {_ _ _}
4       4       4: $std {_ _ _ _}
5       5       5: $std {_ _ _ _ _}
6       6       6: $std {_ _ _ _ _}
7       7       7: $std {_ _ _ _ _}
8       xor2h   xor2h: $xor2 {HighCapacity _ _}
9       9       9: $std {_ _ _ _ _}
10      10      10: $std {_ _ _ _ _}
11      11      11: $std {_ _ _ _ _}
12      12      12: $std {_ _ _ _ _}
13      13      13: $std {_ _ _ _ _}
14      14      14: $std {_ _ _ _ _}
15      15      15: $std {_ _ _ _ _}
16      16      16: $std {_ _ _ _ _}
17      17      17: $std {_ _ _ _ _}
18      18      18: $std {_ _ _ _ _}
19      19      19: $std {_ _ _ _ _}
20      ec82    ec82: $ec(8,2) {_ _ _ _ _ _ _ _ _ _}
21      21      21: $std {_ _ _ _ _}
22      22      22: $std {_ _ _ _ _}
23      23      23: $std {_ _ _ _ _}
24      24      24: $std {_ _ _ _ _}
25      25      25: $std {_ _ _ _ _}
26      26      26: $std {_ _ _ _ _}
27      27      27: $std {_ _ _ _ _}
28      28      28: $std {_ _ _ _ _}
29      29      29: $std {_ _ _ _ _}
30      30      30: $std {_ _ _ _ _}
31      31      31: $std {_ _ _ _ _}
32      32      32: $std {_ _ _ _ _}
33      33      33: $std {_ _ _ _ _}
34      34      34: $std {_ _ _ _ _}
35      35      35: $std {_ _ _ _ _}
36      36      36: $std {_ _ _ _ _}
37      37      37: $std {_ _ _ _ _}
38      38      38: $std {_ _ _ _ _}
39      39      39: $std {_ _ _ _ _}
40      40      40: $std {_ _ _ _ _}

La primera columna es el identificador del objetivo y la segunda es su nombre. Los primeros cinco objetivos son espejos con diferentes números de replicas, desde una (en realidad no hay redundancia) hasta cinco copias. Obsérvese que hemos reconfigurado el objetivo 2 (espejo simple) para que una de las copias se almacene en un disco duro que esté etiquetado como HighCapacity [3]. Esta etiqueta no tiene contenido semántico para LizardFS, es una etiqueta que hemos puesto nosotros en los discos duros más grandes de esta instalación LizardFS. Es decir, estamos especificando tanto el nivel de redundancia como indicando información topológica. Con técnicas así se podría enseñar a LizardFS que evite ciertos discos duros o ciertos servidores si ya ha almacenado fragmentos en discos duros vecinos.

Otro objetivo configurado, que utilizamos para las pruebas, pero que ya no usamos, es el objetivo 8 o xor2h. Este objetivo divide un fichero en dos fragmentos y genera un fragmento nuevo de redundancia [1]. Teniendo acceso a dos de esos tres fragmentos, LizardFS podría reconstruir el fichero. Este formato permite perder un disco y recuperar la información teniendo una sobrecarga de solo el 50%, en vez del 100% que supone un espejo tradicional. Obsérvese que le estamos indicando también que queremos que al menos uno de los tres fragmentos se almacene en un disco duro etiquetado como HighCapacity [3].

El tercer objetivo que tenemos configurado es el 20 o ec82. Este objetivo genera dos fragmentos de redundancia a partir de ocho fragmentos de datos. Es capaz de recuperar los datos aunque hayamos perdido dos discos duros y su sobrecarga de espacio es de solo un 25%.