Dell EMC Ready Solution para almacenamiento HPC PixStor

Artículo escrito por Mario Gallegos del Laboratorio de innovación en HPC e IA en octubre de 2019

Índice

1. Introducción
   1. Arquitectura de la solución
   2. Componentes de la solución
2. Caracterización del rendimiento
   1. Rendimiento de IOzone secuencial, N clientes para N archivos
   2. Rendimiento de IOR secuencial, N clientes para 1 archivo
   3. Bloques pequeños aleatorios de rendimiento de IOzone, N clientes para N archivos
   4. Rendimiento de metadatos con MDtest mediante archivos vacíos
   5. Rendimiento de metadatos con MDtest mediante el uso de archivos de 4 KiB
   6. Rendimiento de metadatos con MDtest con archivos 3K
3. Análisis avanzado
4. Conclusiones y trabajo a futuro

Introducción

Arquitectura de la solución

Componentes de la solución

Caracterización del rendimiento

•     IOzone N a N secuencial
•     IOR N a 1 secuencial
•     IOzone aleatorio
•     MDtest
  
  Para todos los parámetros de referencia mencionados anteriormente, el banco de pruebas tenía los clientes como se describe en la Tabla 2 a continuación. Dado que el número de nodos de cálculo disponibles para las pruebas era de 16, cuando se requería un mayor número de subprocesos, esos subprocesos se distribuían equitativamente en los nodos de cálculo (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) y, al mismo tiempo, se evitó que el cambio de contexto excesivo y otros efectos secundarios relacionados afectaran los resultados de rendimiento.
  
  Tabla 2 Banco de pruebas de cliente

  Cantidad de nodos de cliente	16
  Nodo de 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 con 16 GiB y 2400 MT/s
  BIOS	2.8.0
  Kernel de SO	3.10.0-957.10.1
  Versión del GPFS	5.0.3

   

  ---

  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. 
  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 ese ajuste establece la cantidad máxima de memoria utilizada para el almacenamiento en caché de datos, independientemente de la cantidad de RAM instalada y libre. Además, es importante tener en cuenta que, mientras que en las soluciones de HPC de Dell EMC anteriores el tamaño de bloque para 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, donde Threads era la variable con la cantidad de subprocesos utilizados (de 1 a 1024 incrementados en potencias de dos) y threadlist era el archivo que asignaba cada subproceso en un nodo diferente, mediante 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 N A partir de los resultados, podemos observar que el rendimiento aumenta muy rápido con el número de clientes utilizados y, a continuación, alcanza una meseta que es estable hasta que se alcanza el número máximo de subprocesos que permite IOzone y, por lo tanto, el rendimiento secuencial de archivos grandes es estable incluso para 1024 clientes simultáneos. Observe que el rendimiento máximo de lectura fue de 23 GB/s en 32 subprocesos y muy probablemente el cuello de botella fue la interfaz InfiniBand EDR, mientras que los arreglos ME4 aún tenían algo de rendimiento adicional disponible. De manera similar, observe que el rendimiento máximo de escritura de 16.7 se alcanzó un poco antes con 16 subprocesos y aparentemente es bajo en comparación con las especificaciones de los arreglos ME4.
  Aquí es importante recordar que el modo de operación preferido de GPFS es disperso, y la solución fue formateada para usarlo. En este modo, los bloques se asignan desde el principio de forma pseudoaleatoria, distribuyendo los datos por toda la superficie de cada disco duro. 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. 
  
   

  ---

  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 solo subproceso hasta 1024 subprocesos.
  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 bloques de 8 MiB para obtener un rendimiento óptimo. La sección anterior de la prueba de rendimiento tiene una explicación más completa de estos asuntos. 
  Se utilizaron los siguientes comandos para ejecutar el parámetro de referencia para escrituras y lecturas, donde Threads era la variable con la cantidad de subprocesos utilizados (de 1 a 1024 incrementados en potencias de dos) y my_hosts.$Threads es el archivo correspondiente que asignó cada subproceso en un nodo diferente, mediante round-robin para distribuirlos de manera homogénea entre 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/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 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/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 128G

  
  
  Figura 3: Rendimiento
  
  secuencial de N a 1 A partir de los resultados, podemos observar que el rendimiento aumenta de nuevo muy rápido con la cantidad de clientes utilizados y, a continuación, alcanza una meseta que es semiestable para las lecturas y muy estable para las escrituras hasta la cantidad máxima de subprocesos utilizados en esta prueba. Por lo tanto, el rendimiento secuencial de un solo archivo compartido grande es estable incluso para 1024 clientes simultáneos. Observe que el rendimiento máximo de lectura fue de 23,7 GB/s en 16 subprocesos y muy probablemente el cuello de botella fue la interfaz InfiniBand EDR, mientras que los arreglos ME4 aún tenían algo de rendimiento adicional disponible. Además, el rendimiento de lectura disminuyó desde ese valor hasta alcanzar la meseta en torno a los 20,5 GB/s, con una disminución momentánea a 18,5 GB/s en 128 subprocesos. De manera similar, observe que el rendimiento máximo de escritura de 16.5 se alcanzó con 16 subprocesos y aparentemente es bajo en comparación con las especificaciones de los arreglos ME4.
   

  ---

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

  El rendimiento de N clientes aleatorios a N archivos se midió con IOzone versión 3.487. Las pruebas ejecutadas variaron desde un solo subproceso hasta 1024 subprocesos. En esta prueba de referencia, se utilizaron bloques de 4 KiB para emular el tráfico de bloques pequeños.
  Los efectos del almacenamiento en caché se minimizaron mediante la configuración del grupo 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. 
  Se utilizó el siguiente comando para ejecutar el parámetro de referencia en modo de I/O aleatoria para escrituras y lecturas, donde Threads era la variable con la cantidad de subprocesos utilizados (de 1 a 1024 incrementados en potencias de dos) y threadlist era el archivo que asignaba cada subproceso en un nodo diferente, utilizando round robin para distribuirlos de manera homogénea en los 16 nodos de procesamiento.

  ./iozone -i2 -c -O -w -r 4K -s 32G -t $Threads -+n -+m ./threadlist

  
  Figura 4:  Rendimiento
  
  aleatorio de N a N: a partir de los resultados, podemos observar que el rendimiento de escritura comienza en un valor alto de casi 8,200 IOPS y aumenta de manera constante hasta 128 subprocesos, donde alcanza una meseta y se mantiene cerca del valor máximo de 16,200 IOPS. El rendimiento de lectura, por otro lado, comienza muy pequeño, con más de 200 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 rendimiento máximo de 20.4K IOPS en 512 subprocesos sin signos de alcanzar el máximo. Sin embargo, el uso de más subprocesos en los 16 nodos de cómputo actuales con dos CPU cada uno y donde cada CPU tiene 18 núcleos, tiene la limitación de que no hay suficientes núcleos para ejecutar el número máximo de subprocesos de IOzone (1024) sin incurrir en cambios de contexto (16 x 2 x 18 = 576 núcleos), lo que limita considerablemente el rendimiento. Una prueba futura con más nodos de computación podría comprobar qué rendimiento de lectura aleatoria se puede lograr con 1024 subprocesos con IOzone, o IOR podría usarse para investigar el comportamiento con más de 1024 subprocesos.
  
   

  ---

  Rendimiento de metadatos con MDtest mediante archivos vacíos

  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 (sin metadatos de directorios), obteniendo la cantidad de creaciones, estadísticas, lecturas y eliminaciones que la solución puede manejar.
  Para evaluar correctamente la solución en comparación con otras soluciones de almacenamiento de HPC de Dell EMC, se utilizó el módulo de metadatos de alta demanda opcional, pero con un solo arreglo ME4024, incluso la configuración grande y probada en este trabajo se designó para tener dos ME4024. 
  Este módulo de metadatos de alta demanda puede soportar 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 quizás para las operaciones de estadísticas (y lecturas para archivos vacíos), dado que los números son muy altos, en algún momento las CPU se convertirán en un cuello de botella y el rendimiento no continuará aumentando de manera lineal.
  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

  
  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 fijo el número total de archivos en 2 archivos MiB (2^21 = 2097152), el número de archivos por directorio fijado en 1024 y el número de directorios variado a medida que cambiaba el número de subprocesos, como se muestra en la Tabla 3.
  
  Tabla 3:  Distribución de 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íos En primer lugar, nótese que la escala elegida era logarítmica con base 10, para permitir comparar operaciones que tienen diferencias de varios órdenes 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 logarítmico con base 2 podría ser más apropiado, ya que el número de hilos aumenta en potencias de 2, pero el gráfico se vería bastante similar, y la gente tiende a manejar y recordar mejores números basados en potencias de 10.
  
  
  El sistema obtiene muy buenos resultados con las operaciones de Stat y Read que alcanzan su valor máximo en 64 subprocesos con 11,2 millones de op/s y 4,8 millones de op/s respectivamente. Las operaciones de eliminación alcanzaron el máximo de 169,4 000 op/s con 16 subprocesos y las operaciones de creación alcanzaron su máximo de 512 subprocesos con 194,2 000 op/s. 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 op/s para estadísticas y de 2 millones de op/s de lectura. La creación y la eliminación son más estables una vez que alcanzan una meseta y se mantienen por encima de 140 000 op/s para la eliminación y 120 000 op/s para la creación.
   

  ---

  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 4 KiB. 
  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.

  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

  
  Figura 6:  Rendimiento de metadatos: archivos pequeños (4K)
  
  El sistema obtiene muy buenos resultados para las operaciones de Stat y Removal, alcanzando su valor máximo en 128 subprocesos con 7,7 millones de op/s y 1 millón de op/s respectivamente. Las operaciones de eliminación alcanzaron el máximo de 37 300 op/s y las operaciones de creación alcanzaron su máximo con 55,5 000 op/s, ambas con 512 subprocesos. Las operaciones de estadísticas y eliminación tienen más variabilidad, pero una vez que alcanzan su valor máximo, el rendimiento no cae por debajo de 4 millones de operaciones para estadísticas y 200 mil operaciones para eliminaciones. La creación y la lectura tienen menos variabilidad y siguen aumentando a medida que crece la cantidad de subprocesos.
  Dado que estos números son para un módulo de metadatos con un solo ME4024, el rendimiento aumentará para cada arreglo ME4024 adicional; sin embargo, no podemos suponer simplemente 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 4000, 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 eso utilizará destinos de datos.
   

  ---

  Rendimiento de metadatos con MDtest con archivos 3K

  Esta prueba es casi exactamente idéntica a las anteriores, excepto que se utilizaron pequeños archivos de 3 KiB. La principal diferencia es que estos archivos caben completamente dentro del inodo. Por lo tanto, no se utilizan los nodos de almacenamiento ni sus ME4084, lo que mejora la velocidad general al usar solo medios SSD para el almacenamiento y menos accesos a la red. 
  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.

  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 3K -e 3K

   

  
  Figura 7: Rendimiento de metadatos: archivos pequeños (3K)
  
  El sistema obtiene muy buenos resultados para las operaciones de estadísticas y lectura, alcanzando su valor máximo en 256 subprocesos con 8,29 millones de operaciones y 5,06 millones de operaciones respectivamente. Las operaciones de eliminación alcanzaron el máximo de 609 000 op/s en 128 subprocesos y las operaciones de creación alcanzaron su pico con 78 000 op/s en 512 subprocesos. Las operaciones de estadísticas y lectura tienen más variabilidad que las operaciones de creación y eliminación. La eliminación tiene una pequeña disminución en el rendimiento para los dos puntos de subprocesos más altos, lo que sugiere que el rendimiento sostenido después de 128 subprocesos será ligeramente superior a 400 000 op/s. Las creaciones siguieron aumentando hasta 512 subprocesos, pero parece que están llegando a una meseta, por lo que el rendimiento máximo aún puede estar por debajo de 100K op/s.
  Dado que los archivos pequeños como estos se almacenan por completo en el módulo de metadatos basado en SSD, las aplicaciones que requieren un rendimiento superior de los archivos pequeños pueden utilizar uno o más módulos de metadatos de alta demanda opcionales para aumentar el rendimiento de los archivos pequeños. Sin embargo, los archivos que caben en el inodo son pequeños para los estándares actuales. Además, dado que los objetivos de metadatos utilizan RAID1 con SSD relativamente pequeñas (el tamaño máximo es 19,2 TB), la capacidad será limitada en comparación con los nodos de almacenamiento. Por lo tanto, se debe tener cuidado para evitar llenar los objetivos de metadatos, lo que puede causar fallas innecesarias y otros problemas.
   

  ---

  Análisis avanzado

  Entre las funcionalidades de PixStor, el monitoreo del sistema de archivos a través de análisis avanzados puede ser esencial para simplificar en gran medida la administración, lo que ayuda a encontrar problemas o problemas potenciales de manera proactiva o reactiva. A continuación, revisaremos brevemente algunas de estas funcionalidades.
  En la figura 8, se muestra información útil basada en la capacidad del sistema de archivos. En el lado izquierdo, el espacio total utilizado del sistema de archivos y los diez usuarios principales según la capacidad utilizada del sistema de archivos. En el lado derecho, una vista histórica con capacidad utilizada durante muchos años, luego los diez tipos de archivos principales utilizados y los diez conjuntos de archivos principales, ambos basados en la capacidad utilizada, en un formato similar a los diagramas de Pareto (sin las líneas para los totales acumulados). Con esta información, puede ser fácil encontrar usuarios que obtienen más de lo que les corresponde del sistema de archivos, tendencias de uso de la capacidad para ayudar a tomar decisiones sobre el crecimiento futuro de la capacidad, qué archivos están usando la mayor parte del espacio o qué proyectos están ocupando la mayor parte de la capacidad.
  
  
  Figura 8:  Análisis de PixStor: vista
  
  de capacidad La figura 9 proporciona una vista de recuento de archivos con dos maneras muy útiles de encontrar problemas. La primera mitad de la pantalla muestra los diez usuarios principales en un gráfico circular y los diez tipos de archivos y los diez conjuntos de archivos principales (piense en proyectos) en un formato similar a los diagramas de Pareto (sin las líneas para los totales acumulativos), todo en función del número de archivos. Esta información se puede utilizar para responder algunas preguntas importantes. Por ejemplo, qué usuarios están monopolizando el sistema de archivos mediante la creación de demasiados archivos, qué tipo de archivo está creando una pesadilla de metadatos o qué proyectos están utilizando la mayoría de los recursos.
  La mitad inferior tiene un histograma con el número de archivos (frecuencia) para tamaños de archivo usando 5 categorías para diferentes tamaños de archivo. Esto se puede utilizar para tener una idea de los tamaños de archivo utilizados en todo el sistema de archivos, los cuales, coordinados con los tipos de archivo, se pueden utilizar para decidir si la compresión será beneficiosa.
  
  
  Figura 9:  Análisis de PixStor: vista de conteo de archivos

  
  
   

  ---

  Conclusiones y trabajo a futuro

  La solución actual fue capaz de ofrecer un rendimiento bastante bueno, que se espera que sea estable independientemente del espacio utilizado (ya que el sistema se formateó en modo disperso), como se puede ver en la Tabla 4. 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 de alta demanda opcional. 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 compartir archivos a través de protocolos estándar ubicuos como NFS, SMB y otros a tantos clientes como sea necesario.
  
  Cuadro 4  Rendimiento máximo y sostenido
  
   

  	Rendimiento máximo		Rendimiento sostenido
  	Escritura	Lectura	Escritura	Lectura
  Secuencial grande de N clientes para N archivos	16,7 GB/s	23 GB/s	16,5 GB/s	20,5 GB/s
  Secuencial grande de N clientes a un único archivo compartido	16,5 GB/s	23,8 GB/s	16,2 GB/s	20,5 GB/s
  Bloques pequeños aleatorios de N clientes para N archivos	15,8 KIOps	20,4 KIOps	15,7 KIOps	20,4 KIOps
  Crear archivos vacíos de metadatos	169 400 IOps		127 200 IOps
  Archivos vacíos de estadísticas de metadatos	11,2 millones de IOps		3,3 millones de IOps
  Leer archivos vacíos de metadatos	4,8 millones de IOps		2,4 millones de IOps
  Eliminar archivos vacíos de metadatos	194 200 IOps		144,8 000 IOps
  Creación de archivos 4KiB de metadatos	55,4 000 IOps		55,4 000 IOps
  Archivos 4KiB de estadísticas de metadatos	6,4 millones de IOps		4 millones de IOps
  Archivos 4KiB de lectura de metadatos	37 300 IOps		37 300 IOps
  Eliminar archivos 4KiB de metadatos	1 millón de IOps		219,500 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.

  ---