Acerca de...
El equipo
Encuestas
Política de privacidad
WinTablets

Encuesta

¿Cual crees que triunfará?

Ver Resultados

Cargando ... Cargando ...

últimas entradas importantes

Categorías

Archivos

30
Ene 2018
Podcast

Synology NAS, su formato RAID y algunos trucos cuando añadas discos

RAID o no RAID, esa es la cuestión, y no, no es un spray para matar mosquitos. Eso es otra cosa que se llama igual, aunque no sé qué fue lo primero, si el RAID o el RAID.

Bueno, si has estado al loro de mi podcast o del Slack de Wintablet, te habrás percatado que he tenido un problema con mi NAS.

Como ya lo he contado antes en el podcast, aquí lo resumo rápidamente: tengo un NAS de Synology de cuatro bahías al que originalmente le puse dos discos de 4 TB en modo SHR (que es un RAID específico de Synology) y dejé dos huecos para una futura expansión.

Bueno, pues hace un par de semanas llegó el momento de la expansión, y compré dos discos duros de 8 TB para añadirlos  al NAS y llegar a tener, gracias al SHR, 16 TB en lugar de los 12TB que ofrece en esta situación un RAID común.

Es decir, dos discos de 4 TB más dos discos de 8TB con tolerancia a fallos de un disco en un RAID normal son 12 TB, que, simplificando, se corresponde a la combinación 4 TB + 8TB como imagen primaria y lo mismo para la secundaria.

Así, si se rompe un disco, digamos que uno de 4 TB, el otro hace de respaldo y da tiempo a que reemplaces el roto de 4 TB. E igualmente, si se rompe uno de 8 TB, lo puedes cambiar también porque el otro hace de respaldo.

Sin embargo, Synology te da 16 TB de espacio con esa configuración y la misma tolerancia a fallos: es decir, que se te puede romper un disco y no pierdes datos.

¿Cómo?

A primera vista a uno le vienen a la cabeza dos conclusiones: o bien la gente que estandariza los RAID está tonta del culo por aprovechar mal los discos, o la gente de Synology flipa caracoles y realmente nos están mintiendo o al menos existe una combinación de rotura de un disco que te va a convertir en un desahuciado.

Una de las dos debe ser cierta, pero no las dos… ¿O sí? Pues realmente no sé cómo será de inteligente la gente que construye los RAID, lo que sí sé es que Synology no nos miente y realmente tenemos esos 4 TB gratis (en este caso particular, en otras combinaciones la ganancia de espacio es otra, y hay algunas en las que el uso de disco no es óptimo, pero siempre lo es más que con un RAID tradicional y equivalente).

Repetimos: ¿Cómo?

Fácil: divide cada disco en tantas particiones como la del disco menor.

Con mi combinación de discos, 4+4+8+8, cada disco de 4 tiene una partición de 4, y cada disco de 8, dos de cuatro. Eso hacen un total de 6 particiones de 4 TB.

Usemos ahora uno de los discos de 8 para guardar el control de paridad, pero en dos particiones. Nos quedan dos discos de 4 y uno de 8. Si sumamos, obtenemos 16 GB (2 x 4 + 1 x 8).

Por lo tanto, si se nos rompe cualquiera de los discos que guardan los datos, el de paridad recupera la información, y si se rompe el de paridad, pues cuando cambiemos el disco, se volverá a generar.

Vale, pero resulta que estamos guardando 16 Teras de paridad en un disco de 8 Teras. Bueno, realmente no es así, y lo siento pero tenemos que ponernos algo técnicos, pero no mucho:

Supongamos una vaca esférica, digo supongamos que tenemos cuatro discos duros de 1 bit. Sí, solo un bit y vamos a guardar 3 bits en ellos, y el cuarto lo dejamos para almacenar la paridad, 1 bit. Si os fijáis, es tres a 1.

La paridad es el número de bits a 1 que hay en un número. Supongamos que estamos guardando en los discos duros de un bit el número binario 110, un dígito en cada disco. Tiene paridad par, pues tiene dos unos. Ahora en el cuarto disco duro guardamos un 0 para mantener la paridad par.

Suponemos ahora que se nos rompe el disco de en medio, por lo que nuestro 1100 (con el bit de paridad) se ha convertido en 1×00. La x representa al valor que hemos perdido. Pero como sabemos que la paridad total es par, y solo tenemos un 1, sabemos a ciencia cierta que el valor que nos falta es un uno.

Cualquiera de los discos que se nos rompa, podemos reconstruir el número perdido gracias a la paridad, y si se nos rompe el que contiene la paridad, pues la reconstruimos y listo.

Ahora ampliamos esto a cuatro discos de 4T. Tenemos tres discos que nos guardan la información dividida en tres partes, y el cuarto nos guarda la paridad. Eso hacen 3 discos por 4 teras cada uno, 12 teras. Más el disco de paridad.

Si nos fijamos, esto es válido también para los sistemas RAID, y más o menos es como funcionan. Cuando un disco se rompe, entran en “modo degradado” y te van dando la información correcta porque son capaces de reconstruirla, y cuando cambias el disco roto, la reconstruyen y guardan la parte que se perdió.

De hecho este tipo de tolerancia puede recuperar sectores defectuosos de un disco, e incluso diferentes sectores defectuosos de varios discos sin perder la integridad de los datos. Lo único que tienes que hacer es correr como un loco y reemplazar discos como si no hubiera un mañana, pero uno a uno.

Vale, volviendo a lo nuestro, hemos consegido 12 Teras con nuestros cuatro discos, no 16 como nos promete Synology. Ya, pero es que tenemos dos discos de 8 Teras, de los que estamos usando solo 4 de cada uno o, dicho de otra forma, una de sus dos particiones. Por lo tanto, las otras dos particiones de 4T se combinan como un disco RAID normal, duplicando la información en ambas particiones y, por tanto 12T + 4T, 16T.

Listo. Construyendo un sistema híbrido podemos tener 4 Teras “extra”. E incluso no hay mucha degradación del rendimiento porque si estamos escribiendo en la parte de los 4 Teras común, ya sea la paridad o los valores, la parte extra no está siendo usada y viceversa.

Otra cosa es cómo vamos a dividir 8 bits entre tres discos. De hecho la parte técnica de todo esto es bastante más técnica y compleja de lo que parece, pero para entender el concepto nos basta.

Bien. Si ahora se nos rompe un disco de 4T, la paridad del último reconstruye el roto, y si se nos rompe uno de 8, la parte híbrida se reconstruye de la partición “hibrida” del otro, y la paridad también se puede reconstruir.

De todos modos, os he hecho un cutre-dibujo. Para los oyentes del podcast, os podéis acercar por el blog de WinTablet y echadle un vistazo.

Otra cosa que os quiero contar sobre el NAS y sus discos duros. Añadir un disco nuevo o sustituir uno dañado por otro es algo que requiere mucho tiempo. En mi caso, añadir dos discos de 8 Teras hubiera supuesto unos diez días, o unos cinco por disco a añadir, pero como lo interrumpí, no puedo estar seguro del tiempo que hubiera tardado, pero puedo estimar el proceso:

  • Verificación de paridad de cada disco (cinco días por disco).
  • Expandir el volumen a 12 TB (las particiones compartidas). Ignoro el tiempo porque al tener el fallo de corriente la operación se interrumpió.
  • Añadir los otros 4 TB “extra” de las dos particiones en espejo (de nuevo ignoro el tiempo que hubiera tardado).

En resumen, mínimo una semana. De ahí para arriba. Aunque al final hubiera tenido un sistema funcional.

En este momento, después de instalar como un sistema nuevo, lo que hizo fue crear todo el volumen de una tacada y ahora lo está verificando. Cinco días o así.

¿Se puede acelerar el proceso? Sí, pero a costa del rendimiento general del sistema. De hecho, según mis cálculos, se puede reducir bastante el tiempo, quizás a la mitad.

Hay que tener en cuenta que los NAS no son precisamente Xeon corriendo a millones de petaherzios. El mío al menos es un triste ARM con la potencia justa para no morir en sus tareas, corriendo un linux modificado.

Y aquí está el truco del almendruco: linux.

Podemos entrar dentro de él y cambiar algunos parámetros.

También podemos “ralentizar” el proceso de verificación. ¿Para qué? Paraguayo, digo para poder sacar tus putos datos del NAS a una velocidad medio decente, que fue mi caso antes de reinstalar. Y lo mismo, para meter mis tropecientos terabaites a una velocidad aceptable.

Vayamos al tajo. Lo siento por los que escuchéis el podcast, porque no creo que os enteréis mucho de esta parte, así que si os interesa el tema, daos una vuelta por WinTablet.

Primero hay que activar el servicio de Telnet del NAS, preferiblemente con SSH. Entráis a través del navegador en vuestro NAS como administrador y abrís el Panel de Control. En la sección de Terminal y SNP (que suele ser la última de todas), marcáis “Habilitar servicio Telnet” y “Habilitar servicio SSH”. Guardáis y listo, ya podemos entrar por ese servicio a nuestro NAS.

Ahora os tenéis que instalar algún cliente de telnet. El más habitual, al menos en Windows, es PuTTY, como suena pero con dos tes. P.U.T.T.Y. Sí, ya sé que parece una palabrota, pero es su nombre.

Lanzamos ese cliente y apuntamos a la IP de nuestro NAS, que en general será la que veamos en nuestro navegador. Os pedirá una cuenta de usuario y su contraseña.

Pues nada, ponéis los datos de la de administrador de vuestro NAS. La misma con la que habéis entrado en la interfaz web hace un momento.

Si todo ha ido bien, tenéis una consola de comandos tipo UNIX dentro de vuestro NAS. Ojo que podéis liarla parda, así que con cuidado.

¿Qué comandos uso?

Para ver el estado de la actualización de los discos,

cat /proc/mdstat

Os saldrá un texto con un montón de información. La interesante es la que dice “resyinc …”, que te da el porcentaje que lleva realizado y el tiempo estimado que falta. En minutos. También te da la velocidad del disco.

¿Para acelerarlo o frenarlo? Primero miramos cuál es el valor actual:

cat /proc/sys/dev/raid/speed_limit_min

Y os devolverá un número. En mi caso es 10000 (diez mil). Ese parámetro, que es del núcleo, no es un archivo de configuración ni nada similar, le está diciendo al sistema que la actualización no ha de bajar de diez mil… pero diez mil ¿qué? Pues bytes por segundo. O 10K por segundo, que por cierto es el tercer valor de la línea del comando de antes. Me refiero a que el valor de la línea de “resync” es la velocidad actual a la que se está procesando la actualización.

Pues solo tenemos que bajar o subir ese valor, y el efecto es inmediato. En mi caso, cuando estaba copiando ficheros, lo dejé en 5:

echo 5 >/proc/sys/dev/raid/speed_limit_min

Sí, 5 bytes por segundo. No me atreví a poner menos, o incluso poner cero por si la jodía. Después de terminar lo he devuelto a su valor por defecto, pero tu puedes poner el que quieras siempre que sea inferior al valor de /proc/sys/dev/raid/speed_limit_max, que en mi caso es de cien mil.

¿Y cómo sé yo todo esto? Pues por ciencia infusa. No, a ver, tras mucho buscar encontré esta página, que más o menos lo explica todo, pero en inglés. Para los oyentes, os digo lo mismo: si os interesa, pasaos por WinTablet.info (tal y como suena) y veréis el enlace.

¿Habéis probado el comando “echo bla bla” y no os funciona? Pues eso, no os funciona porque tenéis que ejecutarlo con la cuenta de “root” y no la de administrador, y es lo que no os voy a contar cómo se hace. Lo único que os puedo decir es que yo “sudo” mucho en verano. :-D

PS: Quiero agradecer a Mahjong la edición de la mayoría de mis entradas. Sin él esto sería un campo de nabos un erial de letras sin imágenes. Y encima son chulas. Gracias, tío.

 

Por RFOG | 3 Comentarios | Enlaza esta entrada
contacto@wintablet.info tema WinTablet.info por Ángel García (Hal9000)