Para todos los parámetros de referencia mencionados anteriormente, el banco de pruebas incluía los clientes que se indican en la Tabla 2 a continuación. Debido a que la cantidad de nodos de procesamiento disponibles para las pruebas era solo 16, cuando se requería una mayor cantidad de subprocesos, esos subprocesos se distribuyeron por igual en los nodos de procesamiento (es decir, 32 subprocesos = 2 subprocesos por nodo, 64 subprocesos = 4 subprocesos por nodo, 128 subprocesos = 8 subprocesos por nodo, 256 subprocesos = 16 subprocesos por nodo, 512 subprocesos = 32 subprocesos por nodo, 1024 subprocesos = 64 subprocesos por nodo). La intención era simular una mayor cantidad de clientes simultáneos con la cantidad limitada de nodos de procesamiento disponibles. Dado que algunos parámetros de referencia soportan una gran cantidad de subprocesos, se utilizó un valor máximo de hasta 1024 (especificado para cada prueba), a la vez que se evita la conmutación excesiva del contexto y otros efectos secundarios relacionados que afecten los resultados de rendimiento.

Tabla 2 Banco de pruebas del cliente

Rendimiento de IOzone secuencial, N clientes para N archivos

El rendimiento secuencial de N clientes para N archivos se midió con la versión 3.487 de IOzone. Las pruebas ejecutadas variaron desde un solo subproceso hasta 1024 subprocesos en incrementos en potencias de dos.

Los efectos de almacenamiento en caché sobre los servidores se minimizaron mediante la configuración del pool de páginas GPFS ajustable en 16 GiB y el uso de archivos más grandes que el doble de ese tamaño. Es importante tener en cuenta que, para GPFS, la capacidad ajustable establece la cantidad máxima de memoria utilizada para almacenar datos en caché, independientemente de la cantidad de RAM instalada y libre. Además, es importante tener en cuenta que, si bien en las soluciones anteriores de HPC de Dell EMC, el tamaño de bloque para las transferencias secuenciales grandes es de 1 MiB, GPFS se formateó con bloques de 8 MiB y, por lo tanto, ese valor se utiliza en el parámetro de referencia para obtener un rendimiento óptimo. Eso puede parecer demasiado grande y aparentemente desperdiciar demasiado espacio, pero GPFS utiliza la asignación de subbloques para evitar esa situación. En la configuración actual, cada bloque se subdividió en 256 subbloques de 32 KiB cada uno.

Se utilizaron los siguientes comandos para ejecutar el parámetro de referencia para escrituras y lecturas, en el que $Threads era la variable con el número de subprocesos utilizados (de 1 a 1024 incrementos en potencias de dos), y threadlist era el archivo que asignaba cada subproceso en un nodo diferente, utilizando round robin para repartirlos homogéneamente entre los 16 nodos de computación.

Para evitar cualquier posible efecto de almacenamiento de datos en caché de los clientes, el tamaño total de los datos de los archivos era el doble de la cantidad total de RAM en los clientes utilizados. Es decir, dado que cada cliente tiene 128 GiB de RAM, para los conteos de subprocesos iguales o superiores a 16 subprocesos, el tamaño del archivo era de 4096 GiB dividido por la cantidad de subprocesos (la variable $Size a continuación se utilizó para administrar ese valor). Para aquellos casos con menos de 16 subprocesos (lo que implica que cada subproceso se ejecutaba en un cliente diferente), el tamaño del archivo se fijó en el doble de la cantidad de memoria por cliente, o 256 GiB.

iozone -i0 -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./threadlist
iozone -i1 -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./threadlist

Figura 2 Rendimiento N a N secuencial

A partir de los resultados, podemos observar que el rendimiento de escritura aumenta con la cantidad de subprocesos utilizados y, a continuación, alcanza un estancamiento en alrededor de 64 subprocesos para escrituras y 128 subprocesos para lecturas. A continuación, el rendimiento de lectura también aumenta rápidamente con la cantidad de subprocesos y, luego, se mantiene estable hasta que se alcanza la cantidad máxima de subprocesos permitidos por IOzone; por lo tanto, el rendimiento secuencial de archivos grandes es estable incluso para 1024 clientes simultáneos. El rendimiento de escritura disminuye alrededor de un 10 % con 1024 subprocesos. Sin embargo, dado que el clúster del cliente tiene menos que esa cantidad de núcleos, no está claro si la disminución en el rendimiento se debe al intercambio y a una sobrecarga similar que no se observa en los medios giratorios (ya que la latencia de NVMe es muy baja en comparación con los medios giratorios) o si la sincronización de datos de RAID 10 está generando un cuello de botella. Se necesitan más clientes para aclarar ese punto. Se observó una anomalía en las lecturas con 64 subprocesos, donde el rendimiento no escaló a la velocidad que se observó para los puntos de datos anteriores y, luego, en el siguiente punto de datos, pasó a un valor muy cercano al rendimiento sostenido. Se necesitan más pruebas para encontrar la razón de tal anomalía, pero está fuera del alcance de este blog.

El rendimiento de lectura máximo para lecturas estuvo por debajo del rendimiento teórico de los dispositivos NVMe (~102 GB/s) o el rendimiento de los enlaces EDR, incluso suponiendo que un enlace se utilizó principalmente para el tráfico de NVMe over Fabrics (4 EDR con un ancho de banda aproximado de 96 GB/s).
Sin embargo, esto no es una sorpresa, ya que la configuración de hardware no está equilibrada con respecto a los dispositivos NVMe y los HCA IB en cada conector de la CPU. Un adaptador CX6 está asignado a la CPU1, mientras que la CPU2 dispone de todos los dispositivos NVMe y del segundo adaptador CX6. Todo el tráfico de almacenamiento que utilice el primer HCA debe usar las UPI para acceder a los dispositivos NVMe. Además, cualquier núcleo de la CPU1 utilizado debe acceder a los dispositivos o la memoria asignados a la CPU2, por lo que la localidad de los datos se ve afectada y se utilizan enlaces UPI. Esto puede explicar la reducción del rendimiento máximo, en comparación con el rendimiento máximo de los dispositivos NVMe o con la velocidad de línea de los adaptadores CX6 HCA. La alternativa para solucionar esa limitación es contar con una configuración de hardware equilibrada, lo que implica reducir la densidad a la mitad mediante el uso de un R740 con cuatro ranuras x16 y el uso de dos expansores PCIe x16 para distribuir equitativamente los dispositivos NVMe en dos CPU y tener un adaptador CX6 HCA en cada CPU.

Rendimiento de IOR secuencial, N clientes para 1 archivo

El rendimiento secuencial de N clientes en un único archivo compartido se midió con la versión 3.3.0 de IOR, con la ayuda de OpenMPI v4.0.1 para ejecutar la prueba en los 16 nodos de computación. Las pruebas ejecutadas variaron desde un subproceso hasta 512 subprocesos, ya que no había suficientes núcleos para 1024 subprocesos o más. En estas pruebas de parámetro de referencia, se utilizaron bloques de 8 MiB para obtener un rendimiento óptimo. La sección anterior de pruebas de rendimiento ofrece una explicación más completa de por qué es importante.

Los efectos del almacenamiento de datos en caché se minimizaron configurando el parámetro ajustable de grupo de páginas de GPFS en 16 GiB, y el tamaño total del archivo fue el doble de la cantidad total de RAM en los clientes utilizados. Es decir, dado que cada cliente tiene 128 GiB de RAM, para los conteos de subprocesos iguales o superiores a 16 subprocesos, el tamaño del archivo era de 4096 GiB, y se dividió la misma cantidad de este total por la cantidad de subprocesos (la variable $Size a continuación se utilizó para administrar ese valor). Para aquellos casos con menos de 16 subprocesos (lo que implica que cada subproceso se ejecutaba en un cliente diferente), el tamaño del archivo era el doble de la cantidad de memoria por cliente utilizado por el número de subprocesos, o en otras palabras, se solicitó que cada subproceso usara 256 GiB.

Se utilizaron los siguientes comandos para ejecutar el parámetro de referencia para escrituras y lecturas, en el que $Threads era la variable con el número de subprocesos utilizados (de 1 a 1024 incrementos en potencias de dos), y my_hosts.$Threads es el archivo correspondiente que asignaba cada subproceso en un nodo diferente, utilizando round robin para repartirlos homogéneamente entre los 16 nodos de computación.

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -w -s 1 -t 8m -b $ G

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -r -s 1 -t 8m -b $ G

Figura 3 Rendimiento N a 1 secuencial

A partir de los resultados, podemos observar que el rendimiento de lectura y escritura es alto, independientemente de la necesidad implícita de mecanismos de bloqueo, ya que todos los subprocesos acceden al mismo archivo. El rendimiento aumenta de nuevo de manera muy rápida con el número de subprocesos utilizados y, luego, alcanza un estancamiento que es relativamente estable para lecturas y escrituras hasta el número máximo de subprocesos utilizados en esta prueba. Observe que el rendimiento máximo de lectura fue de 51,6 GB/s con 512 subprocesos, pero el estancamiento en el rendimiento se alcanza en aproximadamente 64 subprocesos. De manera similar, observe que el rendimiento máximo de escritura de 34,5 GB/s se alcanzó con 16 subprocesos y alcanzó un estancamiento que se puede observar hasta la cantidad máxima de subprocesos utilizados.

Bloques pequeños aleatorios de rendimiento de IOzone, N clientes para N archivos

El rendimiento aleatorio de N clientes para N archivos se midió con la versión 3.487 de IOzone. Las pruebas ejecutadas variaron desde un solo subproceso hasta 1024 subprocesos en incrementos en potencias de dos.

Las pruebas ejecutadas variaron desde un solo subproceso hasta 512 subprocesos, ya que no había suficientes núcleos de clientes para 1024 subprocesos. Cada subproceso usaba un archivo diferente y a los subprocesos se les asignaba round robin en los nodos de cliente. En estas pruebas de parámetro de referencia se utilizaron bloques de 4 KiB para emular el tráfico de bloques pequeños y usar una profundidad de línea de espera de 16. Se comparan los resultados de la solución de gran tamaño y la expansión de capacidad.

Los efectos del almacenamiento de datos en caché se minimizaron nuevamente mediante la configuración del grupo de páginas de GPFS ajustable en 16 GiB y, para evitar cualquier posible efecto de almacenamiento de datos en caché de los clientes, el tamaño total de los datos de los archivos era el doble de la cantidad total de RAM en los clientes utilizados. Es decir, dado que cada cliente tiene 128 GiB de RAM, para los conteos de subprocesos iguales o superiores a 16 subprocesos, el tamaño del archivo era de 4096 GiB dividido por la cantidad de subprocesos (la variable $Size a continuación se utilizó para administrar ese valor). Para aquellos casos con menos de 16 subprocesos (lo que implica que cada subproceso se ejecutaba en un cliente diferente), el tamaño del archivo se fijó en el doble de la cantidad de memoria por cliente, o 256 GiB.

iozone -i0 -I -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./nvme_threadlist                                     <= Create the files sequentially
iozone -i2 -I -c -O -w -r 4k -s $ G -t $Threads -+n -+m ./nvme_threadlist                                      <= Perform the random reads and writes.

Figura 4 Rendimiento N a N aleatorio

A partir de los resultados, podemos observar que el rendimiento de escritura comienza en un valor alto de 6000 IOps y aumenta constantemente hasta 1024 subprocesos, donde parece alcanzar un estancamiento con más de 5 millones de IOPS si se pudieran usar más subprocesos. El rendimiento de lectura, por otro lado, comienza en 5000 IOps y aumenta continuamente con el número de subprocesos utilizados (hay que tener en cuenta que el número de subprocesos se duplica para cada punto de datos) y alcanza el rendimiento máximo de 7,3 millones de IOPS a 1024 subprocesos, sin señales de alcanzar un estancamiento. El uso de más subprocesos requerirá más de los 16 nodos de procesamiento para evitar la inanición de recursos y un intercambio excesivo que pueda reducir un rendimiento aparente, donde los nodos NVMe podrían, de hecho, mantener el rendimiento.

Rendimiento de metadatos con MDtest mediante el uso de archivos de 4 KiB

El rendimiento de los metadatos se midió con MDtest versión 3.3.0, con la ayuda de OpenMPI v4.0.1 para ejecutar el parámetro de referencia en los 16 nodos de computación. Las pruebas ejecutadas variaron desde un subproceso hasta 512 subprocesos. El parámetro de referencia se utilizó solo para archivos (no para metadatos de directorios) y se obtuvo la cantidad de creaciones, estadísticas, lecturas y eliminaciones que la solución puede manejar, y los resultados se compararon con la solución de gran tamaño.

Se utilizó el módulo opcional de metadatos de alta demanda, pero con un solo arreglo ME4024, aun cuando la configuración de gran tamaño probada en este trabajo estaba destinada a contar con dos ME4024. El motivo para usar ese módulo de metadatos es que, actualmente, estos nodos NVMe se utilizan como destinos de almacenamiento solo para los datos. Sin embargo, los nodos se pueden utilizar para almacenar datos y metadatos, o incluso como una alternativa flash al módulo de metadatos de alta demanda, si las demandas extremas de metadatos lo requieren. Esas configuraciones no se probaron como parte de este trabajo.

Dado que se utilizó el mismo módulo de metadatos de alta demanda para el análisis comparativo anterior de la solución de almacenamiento DellEMC Ready Solution para HPC PixStor, los resultados de metadatos serán muy similares en comparación con los resultados del blog anterior. Por esa razón, no se realizó el estudio con archivos vacíos, sino que se utilizaron archivos de 4 KiB. Dado que los archivos de 4 KiB no caben en un inodo junto con la información de metadatos, se utilizarán nodos NVMe para almacenar los datos de cada archivo. Por lo tanto, MDtest puede dar una idea aproximada del rendimiento de los archivos pequeños para las lecturas y el resto de las operaciones de metadatos.

Se utilizó el siguiente comando para ejecutar el parámetro de referencia, en el que $Threads fue la variable con la cantidad de subprocesos utilizados (de 1 a 512 incrementos en potencias de dos) y my_hosts.$Threads es el archivo correspondiente que asignó cada subproceso en un nodo diferente, utilizando round robin para distribuirlos de manera homogénea en los 16 nodos de computación. De manera similar al parámetro de referencia de I/O aleatoria, la cantidad máxima de subprocesos se limitó a 512, ya que no hay suficientes núcleos para 1024 subprocesos y la conmutación de contexto afectaría los resultados, lo que informa un número menor que el rendimiento real de la solución.

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F -w 4K -e 4K

Dado que los resultados de rendimiento pueden verse afectados por la cantidad total de IOPS, la cantidad de archivos por directorio y la cantidad de subprocesos, se decidió mantener fija la cantidad total de archivos en 2 archivos MiB (2^21 = 2097152), la cantidad de archivos por directorio fijo en 1024 y la cantidad de directorios varió a medida que cambió la cantidad de subprocesos, como se muestra en la Tabla 3:

Tabla 3 Distribución MDtest de archivos en directorios

Figura 5 Rendimiento de los metadatos: archivos de 4 KiB

En primer lugar, tenga en cuenta que la escala elegida fue logarítmica con base 10, para permitir la comparación de operaciones que tienen diferencias en varios pedidos de magnitud; de lo contrario, algunas de las operaciones se verían como una línea plana cercana a 0 en una escala lineal. Un gráfico logarítmico con base 2 podría ser más apropiado, ya que el número de subprocesos aumenta en potencias de 2, pero el gráfico se vería muy similar y la gente tiende a manejar y recordar mejor los números basados en potencias de 10.

El sistema obtiene muy buenos resultados, como se informó anteriormente, con las operaciones de estadísticas que alcanzan el valor máximo en 64 subprocesos con casi 6,9 millones de op/s y, luego, se reduce para obtener recuentos de subprocesos más altos que alcanzan un estancamiento. Las operaciones de creación alcanzan el máximo de 113 000 op/s en 512 subprocesos, por lo que se espera que continúe aumentando si se utilizan más nodos de cliente (y núcleos). Las operaciones de lecturas y eliminaciones alcanzaron su máximo con 128 subprocesos, alcanzando su máximo en casi 705 000 op/s para lecturas y 370 000 op/s para eliminaciones, y, luego, alcanzan estancamientos. Las operaciones de estadísticas tienen más variabilidad, pero una vez que alcanzan su valor máximo, el rendimiento no disminuye por debajo de los 3,2 millones de op/s para estadísticas. La creación y la extracción son más estables una vez que alcanzan un estancamiento y permanecen por encima de los 265 000 op/s para eliminación y 113 000 op/s para creación. Por último, las lecturas alcanzan un estancamiento con un rendimiento superior a 265 000 op/s.

Conclusiones y trabajo a futuro

Los nodos NVMe son una adición importante a la solución de almacenamiento HPC, ya que proporcionan un nivel de muy alto rendimiento, con buena densidad, muy alto rendimiento de acceso aleatorio y muy alto rendimiento secuencial. Además, la solución escala horizontalmente en capacidad y rendimiento de manera lineal a medida que se agregan más módulos de nodos NVMe. El rendimiento de los nodos NVMe, que se presenta en la Tabla 4, se considera estable y dichos valores pueden emplearse para estimar el rendimiento con una cantidad distinta de nodos NVMe.
Sin embargo, tenga en cuenta que cada par de nodos NVMe proporcionará la mitad de cualquier número que se muestre en la Tabla 4.
Esta solución proporciona a los clientes de HPC un sistema de archivos paralelos muy confiable utilizado por muchos de los 500 clústeres de HPC principales. Además, proporciona funcionalidades de búsqueda excepcionales, monitoreo y administración avanzados, y la adición de gateways opcionales permite el uso compartido de archivos a través de protocolos estándar omnipresentes, como NFS, SMB y otros, a tantos clientes como sea necesario.

Tabla 4 Rendimiento máximo y sostenido para dos pares de nodos NVMe

Dado que los nodos NVMe solo se usaban para datos, es posible que el trabajo futuro incluya su uso para datos y metadatos, y que tengan un nivel basado en flash autónomo con un mejor rendimiento de metadatos debido al mayor ancho de banda y menor latencia de los dispositivos NVMe en comparación con las SSD SAS3 detrás de las controladoras RAID. Como alternativa, si un cliente tiene demandas de metadatos extremadamente altas y requiere una solución más densa que la que puede proporcionar el módulo de metadatos de alta demanda, algunos o todos los dispositivos RAID 10 distribuidos se pueden usar para metadatos de la misma manera que se usan ahora los dispositivos RAID 1 en los arreglos ME4024.
Otro blog que se publicará pronto caracterizará los nodos Gateway de PixStor, los cuales permiten conectar la solución PixStor a otras redes mediante protocolos NFS o SMB y pueden escalar el rendimiento. Además, la solución se actualizará a HDR100 muy pronto, y se espera que otro blog aborde ese trabajo.