Equilibrio de carga en múltiples matrices de raid de hardware: ¿soft raid 0 es aceptable?

Question

We have a central storage server (PowerEdge R720) serving shared files to an HPC cluster, and it has two hardware RAID controllers attached (PERC H810, each driving 2 MD1200 enclosures filled with 7200rpm 4TB disks). As with typical HPC workload, the access pattern is expected to be highly parallel sequential reads/writes. I suppose striping files to the two arrays would give better total throughput, but the idea of software RAID 0 on top of hardware RAID sounds crazy to me.

I came up with two options:

1. NFS on XFS on software RAID 0 on hardware RAID 6
2. lustre on each hardware RAID 6

XFS pros: project quota.

XFS cons: NFS on XFS showed very bad metadata performance (would degrade to nearly unusable when there's large throughput on it, did I tune it wrong?).

lustre pros: significantly better metadata performance.

lustre cons(?): we have no dedicated metadata device, have to partition an array. Sounds like not a recommended practice.

We considered metadata performance, because while sequential R/W is the primary workload, we have some programs working with something like ~40k 1GB files. Managing these files interactively does require an acceptable metadata performance.

And a question at last, what stripe sizes to use on the hardware and the software?

Answer 1

We settled on this setup:

• Hardware RAID-6 in each MD1200 enclosure
• Two LVM LVs on the four hardware arrays, each combining the two arrays on the two cards, without striping
• XFS on the two LVs, striping options the same as for bare hardware arrays
• A gluster volume on the two bricks, without striping

Investigamos todas las aplicaciones de nuestros usuarios y descubrimos que todas funcionan con muchos archivos. Por lo tanto, no es la situación en la que muchos clientes acceden a un único archivo grande, donde se desea crear bandas al nivel de gluster; en lugar de eso, simplemente distribuir archivos aleatoriamente a los bloques puede proporcionar un rendimiento total suficiente.

Si bien el rendimiento de los metadatos de esta configuración es peor que el de lustre (aproximadamente la mitad), no se degrada cuando hay un gran rendimiento. Resultó aceptable.

Gluster configura cuotas en directorios, además es mucho más fácil de configurar que lustre, por lo que requiere significativamente menos esfuerzos de administración que lustre. En mis pruebas (aproximadas), el rendimiento secuencial de esta configuración está a la par con el brillo, por lo que decidimos cambiar esa parte del rendimiento de los metadatos para facilitar la administración.