Tengo un zpool de 24 unidades compuesto por 3 vdev RAIDZ1 que ejecutan 8 unidades Seagate Exos X18 de 16 TB por vdev. Esto está en un Supermicro MB con AMD Threadripper Pro de 64 núcleos (128 subprocesos) y 256 GB de RAM ECC.
La utilización del sistema durante las depuraciones muestra como máximo 2 CPU utilizadas a la vez, y el tiempo total de depuración parece que podría tardar entre cinco y siete días.
¿Hay alguna manera de que todos los núcleos de la CPU funcionen en paralelo en el fregado para acelerarlo?
Respuesta1
Es muy probable que la CPU no sea el factor limitante del rendimiento. Los husillos de 7200 RPM tienen entre 60 y 70 IOPS aleatorios. Incluso 24 discos no dejan mucho rendimiento adicional para una verificación de integridad de menor prioridad.
Planifique el desempeño actual de tal vez un lavado por semana. Si su objetivo de punto de recuperación es una copia de seguridad nocturna, la fuente de restauración no se habrá eliminado por completo. Quizás alguna instantánea. Lo cual puede resultarle aceptable.
Considere hacer que las copias de seguridad se alineen con los matorrales. Si realizara una copia de seguridad completa cada semana y comenzara una limpieza en ese momento, podría finalizar antes de que se complete la semana siguiente. Brinda seguridad adicional de la integridad de la matriz y, por proxy, de la copia de seguridad. Sin embargo, no es mucho tiempo para tener una copia de seguridad con una buena verificación de la integridad del sistema de archivos. Considere mantener convenientes varias copias de seguridad completas. La utilidad de los archivos de hace varios días para sus objetivos de restauración depende de usted, pero al menos se debe completar la limpieza asociada.
Respuesta2
Parece que se está trabajando en la paralelización de las operaciones de lectura/escritura de disco para ZFS, pero el trabajo no está listo para ser probado.
Parámetros y un poco de matemáticas para guiar las respuestas:
Capacidad por unidad: 16.000.000.000.000 Bytes (no 16 TB).
Lectura/escritura sostenida: 270 MB/s (258 MiB/s).
Tiempo medio entre fallos: 285 años.
Errores de lectura de sector no recuperables por bit leído: error de 1 bit por 116,415 TB de datos leídos.
Lectura aleatoria 4K QD16 QCD: 170 IOPS.
Escritura aleatoria 4K QD16 QCD: 550 IOPS.
Cada vdev RAIDZ1 de 8 unidades está conectado a un HBA PCIe 3.0x de 8 canales que admite un rendimiento sostenido de 512 MB/s por unidad conectada.
El HBA está conectado a una ranura PCI4.0 x16 en una placa base de 128 carriles.
Al ejecutarse en paralelo, el sistema admite una lectura completa de las 24 unidades de 16 TB en 22 horas.
Mi expectativa es que el lavado se complete en menos de 24 horas; por lo tanto, el cuello de botella es la utilización de la CPU para la verificación de la suma de comprobación. Dada la disponibilidad de 5 subprocesos computacionales/unidad (este es un sistema de 128 subprocesos/24 unidades), la paralelización de las sumas de comprobación debería resolver el problema del cuello de botella.
Por confiabilidad:
La teoría estocástica predice que es poco probable que falle la unidad, dado el MTBF del fabricante de 285 años y suponiendo un intervalo de confianza de seis desviaciones estándar. No obstante, tengo 4 unidades comprometidas con la corrección de errores y la recuperación ante desastres.
La descomposición de bits (errores de lectura de sector no recuperables por bit leído) es una preocupación aparte, por lo que me preocupan las operaciones de limpieza. La tasa de error esperada es de 1 bit de error por cada 116.415 TB de datos leídos. Eso sugiere un error de lectura de un bit cada 14 años. Las lecturas continuas IFF con un rendimiento total de 270 MB/s se mantienen las 24 horas del día, los 7 días de la semana durante 14 años.
Esta máquina forma parte de un clúster de 1 petabyte y 1024 nodos de conmutación por error en caliente.