Dell EMC Ready Solutions para almacenamiento de alto rendimiento HPC BeeGFS

Artículo escrito por Nirmala Sundararajan del Laboratorio de innovación en HPC e IA de Dell EMC en noviembre de 2019

Dell EMC Ready Solutions para almacenamiento de alto rendimiento HPC BeeGFS

Tabla de contenido

1. Introducción
2. Arquitectura de referencia de la solución
3. Configuración de hardware y software
4. Detalles de configuración de la solución
   • Servicio de administración
   • Servicio de metadatos
   • Servicio de almacenamiento
   • Servicios de cliente
5. R740xd, 24 unidades NVMe, detalles sobre la asignación de CPU
6. Caracterización del rendimiento
   • N-N de lecturas y escrituras secuenciales
   • N-N de lecturas y escrituras aleatorias
7. Conclusión y trabajo a futuro
    

Introducción

Arquitectura de referencia de la solución

Configuración de hardware y software

En la Tabla 1 y 2, se describen las especificaciones de hardware del servidor de administración y del servidor de metadatos/almacenamiento, respectivamente. En la Tabla 3, se describen las versiones de software utilizadas para la solución.

Detalles de configuración de la solución

• Servicio de administración
• Servicio de metadatos
• Servicio de almacenamiento
• Servicios de cliente

Servicio de administración

Servicio de metadatos

Figura 3:  Servidor de metadatos

En la Figura 4, se muestra la configuración de RAID del servidor de metadatos. Destaca cómo en el servidor de metadatos, las unidades de la zona NUMA 0 alojan los MDT y aquellas de la zona NUMA 1 alojan los datos de almacenamiento, mientras que los servidores de almacenamiento alojan los ST en ambas zonas NUMA.

Servicio de almacenamiento

1. El rendimiento de escritura se midió a través del comando dd mediante la creación de un archivo de 10 GiB de tamaño de bloque de 1 MiB e I/O directa para los datos. Para los dispositivos RAID 0, el promedio fue de aproximadamente 5,1 GB/s para cada dispositivo, mientras que para los dispositivos RAID 10, el promedio fue de 3,4 GB/s para cada dispositivo.
2. Las pruebas de parámetro de referencia de StorageBench mostraron un rendimiento máximo de 5,5 GB/s para la configuración de RAID 0, en comparación con 3,4 GB/s para una configuración de RAID 10. Estos resultados son similares a los que se obtuvieron con los comandos dd.
3. RAID 10 proporciona un 50 % de utilización de la capacidad de disco y una reducción similar del 50 % en el rendimiento de escritura. El uso de RAID 10 es una manera costosa de obtener redundancia de almacenamiento.
4. Las unidades NVMe son costosas y ofrecen velocidades que se aprovechan mejor en una configuración de RAID 0

Servicios de cliente

$ cat /etc/beegfs/beegfs-mounts.conf
/mnt/beegfs-medium /etc/beegfs/beegfs-client-medium.conf
/mnt/beegfs-small /etc/beegfs/beegfs-client-small.conf

R740xd, 24 unidades NVMe, detalles sobre la asignación de CPU

# cat /proc/sys/kernel/numa_balancing
0

Caracterización del rendimiento

N-N de escrituras y lecturas secuenciales

Para evaluar lecturas y escrituras secuenciales, se utilizó el parámetro de referencia IOzone en el modo de lectura y escritura secuencial. Estas pruebas se realizaron en múltiples conteos de subprocesos, que comenzaron con 1 subproceso y aumentaron en potencias de 2 hasta llegar a 1024 subprocesos. En cada conteo de subprocesos, se generó una cantidad igual de archivos, ya que esta prueba funciona en un archivo por subproceso o en el caso de N clientes a N archivo (N-N). Los procesos se distribuyeron en 32 nodos de clientes físicos de manera round robin o cíclica, de modo que las solicitudes se distribuyen por igual y hay equilibrio de carga. Se seleccionó un tamaño de archivo agregado de 8 TB, el cual se dividió en partes iguales entre la cantidad de subprocesos dentro de una prueba determinada. Se eligió un tamaño de archivo agregado lo suficientemente grande como para minimizar los efectos del almacenamiento en caché de los servidores, así como de los clientes de BeeGFS. IOzone se ejecutó en un modo combinado de escritura, luego, lectura (-i 0, -i 1) para permitirle coordinar los límites entre las operaciones. Para estas pruebas y resultados, se utilizó un tamaño de registro de 1 MiB para cada ejecución. Los comandos usados para las pruebas de N-N secuenciales se indican a continuación:

Escrituras y lecturas secuenciales: iozone -i 0 -i 1 -c -e -w -r 1m -I -s $Size -t $Thread -+n -+m /path/to/threadlist

Las cachés del SO también se eliminaron o limpiaron en los nodos del cliente entre iteraciones, así como entre pruebas de escritura y lectura mediante la ejecución del comando:

# sync && echo 3 > /proc/sys/vm/drop_caches

El conteo de secciones predeterminado para Beegfs es 4. Sin embargo, el tamaño del fragmento y la cantidad de destinos por archivo se pueden configurar por directorio. Para todas estas pruebas, se eligió un tamaño de sección de BeeGFS de 2 MB y un conteo de secciones de 3, ya que tenemos tres destinos por zona NUMA, como se muestra a continuación:

$ beegfs-ctl --getentryinfo --mount=/mnt/beegfs /mnt/beegfs/benchmark --verbose
EntryID: 0-5D9BA1BC-1
ParentID: root
Metadata node: node001-numa0-4 [ID: 4]
Stripe pattern details:
+ Type: RAID0
+ Chunksize: 2M
+ Number of storage targets: desired: 3
+ Storage Pool: 1 (Default)
Inode hash path: 7/5E/0-5D9BA1BC-1

Se deshabilitaron las páginas enormes transparentes y se implementaron las siguientes opciones de ajuste en los servidores de almacenamiento y metadatos:

• vm.dirty_background_ratio = 5 
• vm.dirty_ratio = 20 
• vm.min_free_kbytes = 262144 
• vm.vfs_cache_pressure = 50
• vm.zone_reclaim_mode = 2 
• kernel.numa_balancing = 0

Además de lo anterior, se utilizaron las siguientes opciones de ajuste de BeeGFS: 

• El parámetro tuneTargetChooser se estableció en “roundrobin” en el archivo de configuración de metadatos 
• El parámetro tuneNumWorkers se estableció en 24 para los metadatos y 32 para el almacenamiento 
• El parámetro connMaxInternodeNum se estableció en 32 para los metadatos, 12 para el almacenamiento y 24 para los clientes

En la Figura 9, vemos que el rendimiento pico de lectura es de 132 GB/s en 1024 subprocesos y el pico de escritura es de 121 GB/s en 256 subprocesos. Cada unidad puede proporcionar un rendimiento máximo de lectura de 3,2 GB/s y un rendimiento máximo de escritura de 1,3 GB/s, lo que permite un máximo teórico de 422 GB/s para lecturas y 172 GB/s para escrituras. Sin embargo, en este caso la red es el factor limitante. Tenemos un total de 11 enlaces InfiniBand EDR para los servidores de almacenamiento en la configuración. Cada enlace puede proporcionar un rendimiento pico teórico de 12,4 GB/s, lo que permite un rendimiento pico teórico de 136,4 GB/s. El rendimiento pico alcanzado de lectura y escritura es del 97 % y el 89 % respectivamente del rendimiento pico teórico.

Se observa que el rendimiento de escritura de un solo subproceso es de aproximadamente 3 GB/s y el de lectura es de aproximadamente 3 GB/s. Podemos ver que el rendimiento de escritura escala de manera lineal, alcanza un pico de 256 subprocesos y, a continuación, comienza a disminuir. En conteos de subprocesos más bajos, el rendimiento de lectura y escritura es el mismo. Puesto que para hasta 8 subprocesos, tenemos 8 clientes que escriben 8 archivos en 24 destinos, lo que significa que no todos los destinos de almacenamiento se utilizan por completo. Tenemos 33 destinos de almacenamiento en el sistema y, por lo tanto, se necesitan al menos 11 subprocesos para utilizar completamente todos los servidores. El rendimiento de lectura registra un aumento lineal constante con el incremento en la cantidad de subprocesos simultáneos y observamos un rendimiento casi similar en 512 y 1024 subprocesos.

También podemos ver que el rendimiento de lectura es menor que las escrituras para los conteos de subprocesos de 16 a 128 y, a continuación, el rendimiento de lectura comienza a escalar. Esto se debe a que, si bien una operación de lectura de PCIe es una operación no publicada, que requiere una solicitud y una finalización, una operación de escritura de PCIe es una operación de tipo “enviar y olvidar”. Una vez que el paquete de capa de transacción se entrega a la capa de enlace de datos, se completa la operación. Una operación de escritura es una operación “Publicada” que consiste solo en una solicitud.

Por lo general, el rendimiento de lectura es menor que el rendimiento de escritura, ya que las lecturas requieren dos transacciones en lugar de una sola escritura para la misma cantidad de datos. PCI Express utiliza un modelo de transacción dividida para las lecturas. La transacción de lectura incluye los siguientes pasos:

• El solicitante envía una solicitud de lectura de memoria (MRR).
• El agente finalizador envía la confirmación de la MRR.
• El agente finalizador devuelve una finalización con datos.

El rendimiento de lectura depende del retraso entre el tiempo en que se emite la solicitud de lectura y el tiempo que tarda el agente finalizador en devolver los datos. Sin embargo, cuando la aplicación emite una cantidad suficiente de solicitudes de lectura para cubrir este retraso, se maximiza el rendimiento. Por ese motivo, si bien el rendimiento de lectura es menor que el de las escrituras de 16 subprocesos a 128 subprocesos, medimos un mayor rendimiento cuando aumenta la cantidad de solicitudes.  Se mide un rendimiento menor cuando el solicitante espera su finalización antes de emitir solicitudes posteriores. Se registra un mayor rendimiento cuando se emiten varias solicitudes para resolver el retraso después de que se devuelvan los primeros datos.

N-N de escrituras y lecturas aleatorias

Para evaluar el rendimiento de I/O aleatorio, se utilizó IOzone en el modo aleatorio. Se realizaron pruebas en conteos de subprocesos a partir del 4 hasta 1024. Se utilizó la opción de Direct IO (-I) para ejecutar IOzone, de modo que todas las operaciones omitan la caché del búfer y vayan directamente al disco. Se utilizó el conteo de secciones de BeeGFS de 3 y el tamaño de fragmento de 2 MB. Se utiliza un tamaño de solicitud de 4 KiB en IOzone. El rendimiento se mide en operaciones de I/O por segundo (IOPS). Se descartaron las cachés del SO entre las ejecuciones en los servidores de BeeGFS, así como en los clientes de BeeGFS. El comando utilizado para ejecutar las escrituras y lecturas aleatorias se indica a continuación:

Lecturas y escrituras aleatorias: iozone -i 2 -w -c -O -I -r 4K -s $Size -t $Thread -+n -+m /path/to/threadlist

Figura 10:  Rendimiento de lectura y escritura aleatorias mediante IOzone con un tamaño de archivo agregado de 8 TB

El pico de escrituras aleatorias es de aproximadamente 3,6 millones de IOPS en 512 subprocesos y el pico de lecturas aleatorias es de aproximadamente 3,5 millones de IOPS en 1024 subprocesos, como se muestra en la Figura 10. El rendimiento de lectura y escritura muestra un mayor rendimiento cuando hay una mayor cantidad de solicitudes de I/O. Esto se debe a que el estándar de NVMe soporta hasta 64 000 colas de I/O y hasta 64 000 comandos por cola. Este gran pool de colas de NVMe proporciona niveles más altos de paralelismo de I/O y, por lo tanto, observamos IOPS que superan los 3 millones.

Conclusión y trabajo a futuro

En este blog, se anuncia el lanzamiento de la solución de almacenamiento BeeGFS de alto rendimiento de Dell EMC y se destacan sus características de rendimiento. La solución tiene un rendimiento pico de lectura y escritura secuenciales de aproximadamente 132 GB/s y aproximadamente 121 GB/s, respectivamente, y el pico de escrituras aleatorias es de aproximadamente 3,6 millones de IOPS y el de lecturas aleatorias es de aproximadamente 3,5 millones de IOPS.

Este blog es la primera parte de la “Solución de almacenamiento BeeGFS”, que se diseñó con un enfoque en el espacio temporal con alto rendimiento. Manténgase atento a la segunda parte de la serie de blogs, en la que se describirá cómo se puede escalar la solución aumentando la cantidad de servidores para incrementar el rendimiento y la capacidad. En la tercera parte de la serie de blogs, se analizarán las características adicionales de BeeGFS y se destacará el uso de “StorageBench”, el parámetro de referencia de destinos de almacenamiento incorporado de BeeGFS.

Como parte de los próximos pasos, publicaremos una documentación técnica más adelante con el rendimiento de metadatos y el rendimiento de OIR de N subprocesos a un archivo, así como con detalles adicionales sobre las consideraciones de diseño, el ajuste y la configuración.

Referencias