Skip to main content
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products

Dell EMC Ready Solution para almacenamiento HPC PixStor

Summary: Arquitectura de referencia para la solución junto con la evaluación de rendimiento inicial.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Symptoms

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

Cause

.

Resolution

Í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

Los entornos HPC actuales exigen cada vez más un almacenamiento de muy alta velocidad que también requiere a menudo una alta capacidad y un 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 Parallel File System que proporcionan acceso simultáneo a un solo archivo o a un conjunto de archivos de múltiples nodos, lo que distribuye de manera muy eficiente y segura los datos a múltiples LUN en varios servidores.

 

Arquitectura de la solución

En este blog, presentamos la incorporación más reciente de Dell EMC a las soluciones de sistema de archivos paralelos (PFS) para entornos de HPC, la solución lista de Dell EMC para el almacenamiento HPC PixStor. En la figura 1, se presenta la arquitectura de referencia, que aprovecha los servidores Dell EMC PowerEdge R740 y los arreglos de almacenamiento PowerVault ME4084 y ME4024 con el software PixStor de nuestra empresa asociada Arcastream.
PixStor incluye el extendido sistema de archivos paralelos generales, también conocido como Spectrum Scale, como componente PFS, además de los componentes de software de Arcastream, como análisis avanzados, administración y supervisión simplificadas, búsqueda eficiente de archivos, capacidades avanzadas de puerta de enlace y muchos otros.

SLN318841_en_US__1image(11979)
Figura 1: Arquitectura de referencia.

 

Componentes de la solución

Está previsto que esta solución salga al mercado con las últimas CPU Intel Xeon de 2.ª generación Scalable Xeon, también conocidas como CPU Cascade Lake, y que algunos de los servidores utilicen la memoria RAM más rápida disponible (2933 MT/s). Sin embargo, debido al hardware disponible para crear prototipos de la solución y caracterizar su rendimiento, los servidores con CPU escalables Xeon Intel Xeon de 1.ª generación, también conocidas como Se utilizaron procesadores Skylake y una RAM más lenta. Dado que el cuello de botella de la solución se encuentra en las controladoras SAS de los arreglos PowerVault ME40x4 de Dell EMC, no se espera una disparidad de rendimiento significativa una vez que las CPU y la RAM Skylake se reemplacen por las CPU Cascade Lake previstas y una RAM más rápida. Además, a pesar de que la última versión de PixStor que soportaba RHEL 7.6 estaba disponible en el momento de configurar el sistema, se decidió continuar con el proceso de control de calidad y utilizar Red Hat® Enterprise Linux® 7.5 y la versión secundaria anterior de PixStor para caracterizar el sistema. Una vez que el sistema se actualice a las CPU Cascade Lake, el software PixStor también se actualizará a la versión más reciente y se realizarán algunas comprobaciones puntuales de rendimiento para verificar que el rendimiento permanezca cerrado a las cifras informadas en este documento.

Debido a la situación descrita anteriormente, en la tabla 1 se incluye la lista de componentes principales de la solución. La columna central tiene los componentes planificados que se utilizarán en el momento del lanzamiento y, por lo tanto, están disponibles para los clientes, y la última columna es la lista de componentes que realmente se utiliza para caracterizar el rendimiento de la solución. Las unidades enumeradas o datos (NLS de 12 TB) y metadatos (SSD de 960 GB) son los 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 metadatos de creación/eliminación.

Por último, para mayor exhaustividad, se incluyó la lista de posibles HDD y SSD de metadatos, que se basa en las unidades compatibles según lo especificado en la matriz de soporte de Dell EMC PowerVault ME4, disponible en línea.

Tabla 1 Componentes que se utilizarán en el momento de la liberación y los utilizados en el banco de pruebas

SLN318841_en_US__2image(12041)
 

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

    SLN318841_en_US__3image(11984)
    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

    SLN318841_en_US__4image(11985)

    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

    SLN318841_en_US__5image(11987)
    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




    SLN318841_en_US__6image(11988)
    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

    SLN318841_en_US__7image(11989)
    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

     

    SLN318841_en_US__8image(11990)
    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.

    SLN318841_en_US__9image(11993)
    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.

    SLN318841_en_US__10image(11994)
    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.


     

Affected Products

High Performance Computing Solution Resources, Dell EMC PowerVault ME4012, Dell EMC PowerVault ME4024, Dell EMC PowerVault ME4084
Article Properties
Article Number: 000130962
Article Type: Solution
Last Modified: 23 Sep 2024
Version:  6
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.