2.9. Información sobre la reconstrucción de un clúster

El clúster de almacenamiento cuenta con autorreparación. Si un nodo o disco falla, un clúster intentará restaurar automáticamente los datos perdidos, es decir, reconstruirse.

El proceso de reconstrucción consta de varios pasos. Cada CS envía un mensaje de latido a un MDS cada 5 segundos. Si no se envía un latido, se considera que el CS está inactivo y el MDS informa a todos los componentes del clúster de que deben dejar de solicitar operaciones con sus datos. Si no se reciben latidos de un CS en 15 minutos, el MDS considera que está fuera de línea y comienza a reconstruir el clúster (siempre que se cumplan los siguientes prerrequisitos). Durante el proceso, el MDS busca los CS que no tienen partes (réplicas) de los datos perdidos y los restaura, una parte (réplica) cada vez, de la siguiente manera:

  • Si se usa la replicación, las réplicas existentes de un bloque degradado se bloquean (para garantizar que todas las réplicas se mantienen idénticas) y se copia una al nuevo CS. Si en este momento un cliente necesita leer datos que aún no se han reconstruido, lee la réplica existente de dichos datos.
  • Si se usa codificación de borrado, el nuevo CS solicita a casi todas las partes de datos que quedan que reconstruyan las que falten. Si en este momento un cliente necesita leer datos que aún no se han reconstruido, estos se reconstruyen de forma prioritaria para que puedan leerse.

Nota

Si un nodo o un disco quedan fuera de línea durante el mantenimiento, la autorreparación del clúster se retrasa para ahorrar recursos del clúster. El retraso predeterminado es de 30 minutos. Puede ajustarlo estableciendo el parámetro mds.wd.offline_tout_mnt (en milisegundos) con el comando vstorage -c <nombre_clúster> set-config.

La autorreparación requiere más recursos de tráfico de red y CPU si se usa la replicación. Por otra parte, la reconstrucción mediante codificación de borrado es más lenta.

Para que un clúster se pueda reconstruir, debe tener, como mínimo:

  1. Tantos nodos en buen estado como sea preciso en el modo de redundancia.
  2. Suficiente espacio libre para albergar tantos datos como pueda almacenar cualquier nodo.

El primer prerrequisito se puede explicar con el siguiente ejemplo. En un clúster que funciona en el modo de codificación de borrado 5+2 y tiene siete nodos (es decir, el mínimo), cada parte de los datos de usuario se distribuye en 5+2 nodos para garantizar la redundancia. Esto quiere decir que se usa cada nodo. Si uno o dos nodos fallan, los datos de usuario no se perderán, pero el clúster se degradará y no podrá reconstruirse hasta que haya al menos siete nodos en buen estado de nuevo (es decir, hasta que añada los nodos que faltan). En comparación con esto, en un clúster que funciona en el modo de codificación de borrado 5+2 y tiene diez nodos, cada parte de los datos de usuario se distribuye en 5+2 nodos aleatorios de diez para igualar la carga en CS. Si fallan hasta tres nodos, ese clúster seguirá teniendo suficientes nodos para reconstruirse.

El segundo prerrequisito se puede explicar con el siguiente ejemplo. En un clúster que tiene diez nodos de 10 TB, se debe mantener libre al menos 1 TB de cada nodo, de forma que si un nodo falla, sus 9 TB de datos se pueden reconstruir en los nueve nodos restantes. Sin embargo, si un clúster tiene diez nodos de 10 TB y uno de 20 TB, cada nodo de menor tamaño debe tener al menos 2 TB de espacio libre en caso de que el de mayor tamaño falle (mientras que el nodo de mayor tamaño debe tener 1 TB libre).

A continuación se ofrecen dos recomendaciones para suavizar la sobrecarga de reconstrucción:

  • Para simplificar la reconstrucción, mantenga recuentos uniformes de los discos y los tamaños de capacidad en todos los nodos.
  • La reconstrucción implica una carga adicional para la red y aumenta la latencia de las operaciones de lectura y escritura. Cuanto mayor sea el ancho de banda de red del clúster, más rápida será la reconstrucción y la liberación de ancho de banda.