Solución Dell EMC Ready para almacenamiento HPC PixStor: expansión de capacidad

Ninguno

Índice

1. Introducción
   1. Arquitectura de la solución
   2. Componentes de la solución
2. Caracterización del rendimiento
   1. Clientes N de rendimiento de IOzone secuenciales a archivos N
   2. Clientes N de rendimiento de IOR secuenciales a 1 archivo
   3. Clientes N de rendimiento de IOzone de bloques pequeños aleatorios a archivos N
   4. Rendimiento de metadatos con MDtest mediante archivos vacíos
   5. Rendimiento de metadatos con MDtest mediante el uso de archivos de 4 KiB
3. Conclusiones y trabajo a futuro

 

---

Introducción

Los entornos de HPC actuales tienen mayores exigencias de almacenamiento de muy alta velocidad que también requieren con frecuencia alta capacidad y acceso distribuido a través de varios protocolos estándar, como NFS, SMB y otros. Por lo general, esos requisitos de HPC de alta demanda están cubiertos por sistemas de archivos paralelos que proporcionan acceso simultáneo a un solo archivo o a un conjunto de archivos de varios nodos, distribuyendo de manera muy eficiente y segura los datos a múltiples LUN en varios servidores.

 

---

Arquitectura de la solución

Este blog es una solución de continuación del sistema de archivos paralelos (PFS) para entornos de HPC, DellEMC Ready Solution para almacenamiento HPC PixStor, donde los arreglos PowerVault ME484 EBOD se utilizan para aumentar la capacidad de la solución. Figura 1 presenta la arquitectura de referencia que representa las adiciones sas de expansión de capacidad a los arreglos de almacenamiento PowerVault ME4084 existentes.
La solución PixStor incluye el generalizado sistema de archivos paralelos general, también conocido como Spectrum Scale como el componente PFS, además de muchos otros componentes de software Arcastream, como análisis avanzados, administración y monitoreo simplificados, búsqueda eficiente de archivos, funcionalidades avanzadas de gateway y muchas otras.


Figura 1: Arquitectura de referencia.

 

---

Componentes de la solución

Se planea lanzar esta solución con las ÚLTIMAs CPU Xeon escalables Intel Xeon de 2.ª generación, también conocidas como CPU Cascade Lake, y algunos de los servidores utilizarán la RAM más rápida disponible para ellos (2933 MT/s). Sin embargo, debido al hardware actual disponible para trabajar en el prototipo de la solución a fin de caracterizar el rendimiento, los servidores con CPU Xeon escalables Intel Xeon de 1.ª generación también lo son. Se utilizaron procesadores Skylake y, en algunos casos, RAM más lenta para caracterizar este sistema. Dado que el cuello de botella de la solución se encuentra en las controladoras SAS de los arreglos Dell EMC PowerVault ME40x4, no se espera una disparidad de rendimiento significativa una vez que las CPU Skylake y la RAM se reemplazan con las CPU Cascade Lake previstas y la RAM más rápida. Además, la solución se actualizó a la versión más reciente de PixStor (5.1.1.4) que admite RHEL 7.7 y OFED 4.7 para caracterizar el sistema.

Debido a la situación descrita anteriormente, la Tabla 1 tiene la lista de componentes principales para la solución, pero cuando se presentaron discrepancias, la primera columna de descripción tiene componentes utilizados en el momento del lanzamiento y, por lo tanto, disponibles para los clientes, y la última columna son los componentes que realmente se utilizan para caracterizar el rendimiento de la solución. Las unidades enumeradas para los datos (NLS de 12 TB) y los metadatos (SSD de 960 Gb) son las que se utilizan para la caracterización del rendimiento, y las unidades más rápidas pueden proporcionar mejores IOPS aleatorias y pueden mejorar las operaciones de creación/eliminación de metadatos.

Por último, para la integridad, se incluyó la lista de posibles discos duros de datos y DISCOS SSD de metadatos, que se basa en las unidades compatibles, según se indica en la matriz de soporte de PowerVault ME4 de Dell EMC, disponible en línea.

Tabla 1 Componentes utilizados en el momento de la liberación y aquellos utilizados en el banco de pruebas

Componente de la solución		En la versión	Banco de pruebas
Conectividad interna		Dell Networking S3048-ON Gigabit Ethernet
Subsistema de almacenamiento de datos		De 1 a 4 Dell EMC PowerVault ME4084 De 1 a 4 Dell EMC PowerVault ME484 (uno por ME4084) De 80 a 12 TB Opciones de unidades de disco duro SAS3 NL de 3,5 in y 900 GB @15K, 1,2 TB @10K, 1,8 TB @10K, 2,4 TB @10K, NLS de 4 TB, NLS de 8 TB, NLS de 10 TB, NLS de 12 TB.     8 LUN, RAID 6 lineal de 8+2, tamaño de fragmento de 512 KiB. 4 SSD SAS3 de 1,92 TB para metadatos: 2 RAID 1 (o 4 discos duros globales de repuesto, si se utiliza el módulo de metadatos de alta demanda opcional)
Subsistema de almacenamiento de metadatos de alta demanda opcional		1 a 2 Dell EMC PowerVault ME4024 (4 ME4024 si es necesario, solo configuración grande) 24 unidades SSD SAS3 de 960 GB y 2,5" (opciones 480 GB, 960 GB, 1,92 TB) 12 LUN, RAID 1 lineal.
Controladoras de almacenamiento RAID		SAS de 12 Gbps
Capacidad según la configuración		Crudo: 8064 TB (7334 TiB o 7,16 PiB) con formato~ 6144 GB (5588 TiB o 5,46 PiB)
Procesador	Gateway	2 Intel Xeon Gold 6230 2.1G, 20C/40T, 10.4 GT/s, caché de 27.5 M, Turbo, HT (125 W) DDR4-2933	N/D
	Metadatos de alta demanda		2 Intel Xeon Gold 6136 a 3,0 GHz, 12 núcleos
	Nodo de almacenamiento		2 Intel Xeon Gold 6136 a 3,0 GHz, 12 núcleos
	Nodo de administración	2 Intel Xeon Gold 5220 de 2,2 G, 18C/36 T, 10,4 GT/s, caché de 24,75 M, Turbo, HT (125 W) DDR4-2666	2 Intel Xeon Gold 5118 a 2,30 GHz, 12 núcleos
Memoria	Gateway	12 RDIMM de 16 GiB y 2933 MT/s (192 GiB)	N/D
	Metadatos de alta demanda		24 RDIMM de 16 GiB y 2666 MT/s (384 GiB)
	Nodo de almacenamiento		24 RDIMM de 16 GiB y 2666 MT/s (384 GiB)
	Nodo de administración	12 DIMM de 16 GB, 2666 MT/s (192 GiB)	12 RDIMM de 8 GiB y 2666 MT/s (96 GiB)
Sistema operativo		Red Hat Enterprise Linux 7.6	Red Hat Enterprise Linux 7.7
Versión del kernel		3.10.0-957.12.2.el7.x86_64	3.10.0-1062.9.1.el7.x86_64
PixStor Software		5.1.0.0	5.1.1.4
Escala de espectro (GPFS)		5.0.3	5.0.4-2
Conectividad de red de alto rendimiento		Mellanox ConnectX-5 InfiniBand de dos puertos EDR/100 GbE y 10 GbE	Mellanox ConnectX-5 InfiniBand EDR
Switch de alto rendimiento		2 Mellanox SB7800 (HA: redundante)	1 Mellanox SB7700
Versión de OFED		Mellanox OFED-4.6-1.0.1.0	Mellanox OFED-4.7-3.2.9
Discos locales (SO y análisis/monitoreo)		Todos los servidores, excepto el nodo de administración 3 SSD SAS3 de 480 GB (RAID1 + HS) para so Controladora RAID PERC H730P Nodo de administración 3 SSD SAS3 de 480 GB (RAID1 + HS) para so Controladora RAID PERC H740P	Todos los servidores, excepto el nodo de administración 2 SAS3 de 300 GB y 15 000 r/min (RAID 1) para so Controladora RAID PERC H330 Nodo de administración 5 SAS3 de 300 GB y 15 000 r/min (RAID 5) para so y análisis/monitoreo Controladora RAID PERC H740P
Administración de sistemas		iDRAC 9 Enterprise + DellEMC OpenManage	iDRAC 9 Enterprise + DellEMC OpenManage

 

---

Caracterización del rendimiento

Para caracterizar esta nueva Ready Solution, se utilizó el hardware especificado en la última columna de la Tabla 1, incluido el módulo de metadatos de alta demanda opcional. A fin de evaluar el rendimiento de la solución, se utilizaron los siguientes parámetros de referencia:

• IOzone N a N secuencial
• IOR N a 1 secuencial
• Zona de IOzone aleatoria
• MDtest

 Para todos los parámetros de referencia mencionados anteriormente, el banco de pruebas tenía a los clientes como se describe en la Tabla 2 a continuación. Dado 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 distribuyeban 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. Dado que los parámetros de referencia admiten 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

Cantidad de nodos de cliente	16
Nodo cliente	C6320
Procesadores por nodo de cliente	2 Intel(R) Xeon(R) Gold E5-2697v4 de 18 núcleos a 2,30 GHz
Memoria por nodo de cliente	12 RDIMM de 16 GiB y 2400 MT/s
BIOS	2.8.0
Kernel del sistema operativo	3.10.0-957.10.1
Versión de GPFS	5.0.3

 

---

Clientes N de rendimiento de IOzone secuenciales a archivos N

El rendimiento de los clientes N secuenciales a N archivos se midió con IOzone versión 3.487. Las pruebas ejecutadas variaron de un subproceso a 1024 subprocesos, y los resultados de la solución ampliada de capacidad (4 ME4084 y 4 ME484) se contrastan con la solución de gran tamaño (4 ME4084). Los efectos de almacenamiento en caché 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 8 bloques de 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 subdividó en 256 subbloques de 32 KiB cada uno.

Los siguientes comandos se utilizaron para ejecutar el parámetro de referencia para escrituras y lecturas, donde Threads fue la variable con la cantidad de subprocesos utilizados (de 1 a 1024 incrementos en potencias de dos) y threadlist fue el archivo que asignó cada subproceso en un nodo diferente, utilizando round robin para distribuirlos de manera homogénea en los 16 nodos de procesamiento.

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

Figura 2:  Rendimiento


secuencial de N a NA partir de los resultados, podemos observar que el rendimiento aumenta muy rápido con la cantidad de clientes utilizados y luego alcanza una estancización estable hasta que se alcanza la cantidad máxima de subprocesos que IOzone permite y, por lo tanto, el rendimiento secuencial de archivos grandes es estable incluso para 1024 clientes simultáneos. Observe que el rendimiento de lectura y escritura se benefició de duplicar la cantidad de unidades. El rendimiento de lectura máximo estaba limitado por el ancho de banda de los dos enlaces EDR de IB utilizados en los nodos de almacenamiento a partir de 8 subprocesos, y los arreglos ME4 pueden tener un rendimiento adicional disponible. De manera similar, observe que el rendimiento máximo de escritura aumentó de un máximo de 16,7 a 20,4 GB/s en 64 y 128 subprocesos y está más cerca de las especificaciones máximas de los arreglos ME4 (22 GB/s).

Aquí es importante recordar que el modo de operación preferido de GPFS es disperso y que la solución se formateó para usar dicho modo. En este modo, los bloques se asignan desde el comienzo de la operación de manera pseudo random, lo que distribuye los datos en toda la superficie de cada HDD. Si bien la desventaja obvia es un rendimiento máximo inicial más pequeño, ese rendimiento se mantiene bastante constante, independientemente de la cantidad de espacio que se utiliza en el sistema de archivos. A diferencia de otros sistemas de archivos paralelos que inicialmente utilizan las pistas externas que pueden contener más datos (sectores) por revolución de disco y, por lo tanto, tienen el mayor rendimiento posible que pueden proporcionar los discos duros, pero a medida que el sistema utiliza más espacio, se utilizan segmentos internos con menos datos por revolución, con la consiguiente reducción del rendimiento.

 

---

Clientes N de rendimiento de IOR secuenciales a 1 archivo

El rendimiento de los N clientes secuenciales a un único archivo compartido se midió con IOR 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 procesamiento. Las pruebas ejecutadas variaron de un subproceso a 512 subprocesos (ya que no había suficientes núcleos para 1024 subprocesos) y los resultados se contrastan con la solución sin la expansión de la capacidad.
Los efectos de almacenamiento en caché 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. En estas pruebas de parámetro de referencia, se utilizaron 8 bloques de MiB para obtener un rendimiento óptimo. La sección de prueba de rendimiento anterior tiene una explicación más completa de esos asuntos.

Los siguientes comandos se utilizaron para ejecutar el parámetro de referencia para escrituras y lecturas, donde Threads fue la variable con la cantidad de subprocesos utilizados (de 1 a 1024 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 procesamiento.

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/fund /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 128G 

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/fund /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 128G

Figura 3: N a 1 Rendimiento

secuencial A partir de los resultados, podemos observar nuevamente que las unidades adicionales benefician el rendimiento de lectura y escritura. El rendimiento aumenta de nuevo muy rápido con la cantidad de clientes utilizados y, luego, alcanza una estancamiento bastante estable para lecturas y escrituras hasta la cantidad máxima de subprocesos utilizados en esta prueba. Tenga en cuenta que el rendimiento máximo de lectura fue de 24,8 GB/s en 16 subprocesos y que el cuello de botella fue la interfaz infiniBand EDR, con arreglos ME4 que aún tenían un rendimiento adicional disponible. A partir de ese punto, el rendimiento de lectura disminuyó de ese valor hasta alcanzar la estancamiento en alrededor de 23,8 GB/s. De manera similar, observe que el rendimiento máximo de escritura de 19,3 se alcanzó en 8 subprocesos y alcanzó una estancamiento.
 

---

Clientes N de rendimiento de IOzone de bloques pequeños aleatorios a archivos N

El rendimiento aleatorio de N clientes a N archivos se midió con FIO versión 3.7 en lugar de la Iozone tradicional. La intención, como se indica en el blog anterior, era aprovechar una profundidad de cola más grande para investigar el máximo rendimiento posible que pueden ofrecer los arreglos ME4084 (las pruebas anteriores para diferentes soluciones ME4 mostraron que los arreglos ME4084 necesitan más presión de I/O que Iozone puede ofrecer para alcanzar sus límites de I/O aleatorios).

Las pruebas ejecutadas variaron de un subproceso a 512 subprocesos, ya que no había suficientes núcleos de cliente para 1024 subprocesos. Cada subproceso usaba un archivo diferente y a los subprocesos se les asignaba round robin en los nodos del cliente. En estas pruebas de parámetro de referencia se utilizaron 4 bloques 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 de almacenamiento en caché se minimizaron nuevamente mediante la configuración del pool de páginas GPFS ajustable en 16 GiB y el uso de archivos dos veces ese tamaño. La primera sección de prueba de rendimiento tiene una explicación más completa sobre por qué esto es eficaz en GPFS.

 
Figura 4:  N a N Rendimiento

aleatorio En los resultados, podemos observar que el rendimiento de escritura comienza en un alto valor de 29,100 IOps y aumenta continuamente hasta 64 subprocesos donde parece llegar a una estancamiento de alrededor de 40 000 IOps. Por otro lado, el rendimiento de lectura comienza con 1400 IOps y aumenta el rendimiento casi linealmente con la cantidad de clientes utilizados (tenga en cuenta que la cantidad de subprocesos se duplica para cada punto de datos) y alcanza el máximo rendimiento de 25,600 IOPS en 64 subprocesos, donde parece estar cerca 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 rendimiento aparente más bajo, donde los arreglos podrían, de hecho, mantener el rendimiento.

 

---

Rendimiento de metadatos con MDtest mediante archivos vacíos

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

Para evaluar correctamente la solución en comparación con otras soluciones de almacenamiento HPC de Dell EMC y los resultados del blog anterior, se utilizó el módulo de metadatos de alta demanda opcional, pero con un solo arreglo ME4024, incluso cuando se designó la configuración grande y se probó en este trabajo para tener dos ME4024. Este módulo de metadatos de alta demanda puede admitir hasta cuatro arreglos ME4024 y se sugiere aumentar la cantidad de arreglos ME4024 a 4, antes de agregar otro módulo de metadatos. Se espera que los arreglos ME4024 adicionales aumenten el rendimiento de los metadatos de manera lineal con cada arreglo adicional, excepto tal vez para las operaciones de estadísticas (y las lecturas para archivos vacíos), ya que las cifras son muy altas, en algún momento las CPU se convertirán en un cuello de botella y el rendimiento no continuará aumentando linealmente.

Se utilizó el siguiente comando para ejecutar el parámetro de referencia, donde 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 procesamiento. De manera similar al parámetro de referencia de E/S 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/nw --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

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 de 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

Cantidad de subprocesos	Cantidad de directorios por subproceso	Cantidad total de archivos
1	2048	2,097,152
2	1024	2,097,152
4	512	2,097,152
8	256	2,097,152
16	128	2,097,152
32	64	2,097,152
64	32	2,097,152
128	16	2,097,152
256	8	2,097,152
512	4	2,097,152
1024	2	2,097,152

Figura 5: Rendimiento de metadatos: archivos

vacíosEn 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 un gráfico normal. Un gráfico de registro con base 2 podría ser más apropiado, ya que la cantidad de subprocesos aumenta en potencias de 2, pero el gráfico se vería muy similar y las personas tienden a manejar y recordar mejores números en función de las potencias de 10.
El sistema obtiene muy buenos resultados con operaciones de lectura y estadísticas que alcanzan su valor máximo en 64 subprocesos con casi 11 millones de operaciones y 4,7 millones de operaciones, respectivamente. Las operaciones de eliminación alcanzaron el máximo de 170,600 op/s en 16 subprocesos y las operaciones de creación lograron su máximo en 32 subprocesos con 222,100 operaciones por segundo. Las operaciones de estadísticas y lectura tienen más variabilidad, pero una vez que alcanzan su valor máximo, el rendimiento no disminuye por debajo de los 3 millones de operaciones para estadísticas y de 2 millones de operaciones de lectura. La creación y la extracción son más estables una vez que alcanzan una estancamiento y permanecen por encima de los 140 000 op/s para la eliminación y 120 000 operaciones para crear. Observe que las unidades adicionales no afectan gran parte de las operaciones de metadatos en archivos vacíos según lo esperado.
 

---

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

Esta prueba es casi idéntica a la anterior, excepto que, en lugar de archivos vacíos, se utilizaron archivos pequeños de 4KiB. 
Se utilizó el siguiente comando para ejecutar el parámetro de referencia, donde 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 procesamiento.

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/nw --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

Figura 6:  Rendimiento de metadatos: archivos pequeños (4K)

El sistema obtiene muy buenos resultados para las operaciones de estadísticas y extracción que alcanzan su valor máximo en 256 subprocesos con 8,2 millones de operaciones y 400,000 operaciones, respectivamente. Las operaciones de lectura alcanzaron el máximo de 44,8 K op/s y las operaciones de creación lograron su máximo con 68,100 operaciones, ambas en 512 subprocesos. Las operaciones de estadísticas y extracción tienen más variabilidad, pero una vez que alcanzan su valor máximo, el rendimiento no disminuye por debajo de 3 millones de operaciones para estadísticas y de 280 000 operaciones para eliminación. La creación y la lectura tienen menos variabilidad y siguen aumentando a medida que crece la cantidad de subprocesos. Como se puede observar, las unidades adicionales de las expansiones de capacidad solo proporcionan cambios marginales en el rendimiento de los metadatos.
Dado que estos números corresponden a un módulo de metadatos con un único ME4024, el rendimiento aumentará por cada arreglo ME4024 adicional; sin embargo, no podemos simplemente suponer un aumento lineal para cada operación. A menos que todo el archivo se ajuste dentro del inodo para dicho archivo, los destinos de datos en los ME4084 se utilizarán para almacenar los archivos 4K, lo que limitará el rendimiento hasta cierto punto. Dado que el tamaño del inodo es de 4 KiB y aún necesita almacenar metadatos, solo los archivos de alrededor de 3 KiB caben dentro y cualquier archivo mayor que el que utilizará destinos de datos.
 

---

Conclusiones y trabajo a futuro

La solución con capacidad ampliada pudo mejorar el rendimiento, no solo para los accesos aleatorios, sino también para el rendimiento secuencial. Eso se esperaba, ya que el modo disperso se comporta como accesos aleatorios y tener más discos permite la mejora. Se espera que ese rendimiento, que se puede ver en la Tabla 4, sea estable desde un sistema de archivos vacío hasta que esté casi lleno. Además, la solución escala en capacidad y rendimiento de manera lineal a medida que se agregan más módulos de nodos de almacenamiento, y se puede esperar un aumento de rendimiento similar a partir del módulo de metadatos opcional de alta demanda. 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

	Rendimiento máximo		Rendimiento sostenido
	Escribir	Lectura	Escribir	Lectura
Clientes N secuenciales grandes a archivos N	20,4 GB/s	24,2 GB/s	20,3 GB/s	24 GB/s
Clientes N secuenciales grandes a un único archivo compartido	19,3 GB/s	24,8 GB/s	19,3 GB/s	23,8 GB/s
Bloques pequeños aleatorios N clientes a N archivos	40KIOps	25.6KIOps	40.0KIOps	19.3KIOps
Metadatos Crear archivos vacíos	169,400 IOps		123,500 IOps
Archivos vacíos de estadísticas de metadatos	11 millones de IOps		3,2 millones de IOps
Metadatos Leer archivos vacíos	4,7 millones de IOps		2,4 millones de IOps
Metadatos Eliminar archivos vacíos	170,600 IOps		156,500 IOps
Creación de metadatos de archivos 4KiB	68,100 IOps		68,100 IOps
Archivos Stat 4KiB de metadatos	8,2 millones de IOps		3 millones de IOps
Archivos 4KiB de lectura de metadatos	44,800 IOps		44,800 IOps
Metadatos Eliminar archivos de 4 KiB	400 000 IOps		280 000 IOps

Dado que la solución está diseñada para lanzarse con CPU Cascade Lake y RAM más rápida, una vez que el sistema tenga la configuración final, se realizarán algunas comprobaciones de puntos de rendimiento. Y pruebe el módulo de metadatos de alta demanda opcional con al menos 2 archivos ME4024s y 4KiB necesarios para documentar mejor cómo se escala el rendimiento de los metadatos cuando se involucran los destinos de datos. Además, el rendimiento de los nodos de gateway se medirá e informará junto con cualquier resultado relevante de las comprobaciones de puntos en un nuevo blog o en una documentación técnica. Por último, se prevé que se probarán y lanzarán más componentes de la solución para proporcionar aún más capacidades.