Su estratificación es subóptima porque poner el raid 5 encima del cifrado significa que aumenta la cantidad de operaciones de cifrado/descifrado en un 25 %, ya que se cifran 4 * 4 TB.
Al poner el cifrado encima del raid 5, solo se cifran 3 * 4 TB.
El razonamiento detrás de esto es:no tiene que cifrar datos de paridad (que ocupa 4 TB en su ejemplo) de datos cifrados porque no aumenta su seguridad.
Su presunción sobre múltiples procesos de kcrypt es solo eso. A la hora de basar decisiones en él, se trata de una optimización prematura que puede tener todo el efecto contrario. Su i7 es bastante robusto, probablemente incluso incluya algunas instrucciones especiales que ayudan a acelerar AES, y el kernel de Linux incluye varias variantes optimizadas de primitivas criptográficas que se seleccionan automáticamente durante el arranque.
Puede verificar si las rutinas optimizadas para su CPU se utilizan mirando /proc/cpuinfo (por ejemplo, marca aes allí), /proc/crypto , lsmod (a menos que los módulos aes estén compilados en el kernel) y el registro del kernel.
Debe comparar el rendimiento de kryptd sin involucrar ningún disco lento para ver cuál es realmente el límite superior (es decir, en un disco RAM usando iozone).
Para poder diagnosticar posibles problemas de rendimiento más adelante, también es útil comparar la configuración RAID de su elección sin ningún tipo de cifrado para obtener un límite superior en ese extremo.
Además del tema criptográfico, RAID 5 implica más operaciones de E/S que RAID 1 o 10. Dado que el almacenamiento es algo económico, tal vez sea una opción comprar más discos duros y usar otro nivel de RAID.
Yo haría Raid 1+0 [a2,b2]+[c2,d2], luego LVM sobre LUKS.
Ejemplo
$ sudo mdadm --create /dev/md0 -v --raid-devices=4 \
--level=raid10 /dev/sdb1 /dev/sdc1 /dev/sde1 /dev/sde1
También creo que este esquema es significativamente más rápido porque se sabe que RAID5 perjudica el rendimiento, pero tendrá menos espacio disponible.
También puede verificar el cifrado, aunque creo que aes-cbc-essiv es el predeterminado y razonablemente rápido, pero podría usar aes-xts-plain, que debería ser más rápido.