PowerEdge: Dell 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 en noviembre de 2019

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

El equipo de HPC de Dell se enorgullece en anunciar el lanzamiento de "Dell EMC Ready Solutions para el almacenamiento HPC BeeGFS", que es la incorporación más reciente al portafolio de almacenamiento HPC. Esta solución utiliza servidores R740xd, cada uno con 24 NVMe Intel P4600 de 1,6 TB, unidades Express Flash de uso mixto y dos adaptadores Mellanox ConnectX-5 InfiniBand EDR. En esta configuración de 24 unidades NVMe, 12 SSD NVMe se conectan a un switch PCIe y cada switch se conecta a una CPU mediante una tarjeta de extensión PCIe x16. Además, cada interfaz de IB está conectada a una CPU. Esta configuración equilibrada con cada CPU conectada a un adaptador InfiniBand y el manejo de 12 SSD NVMe proporciona el máximo rendimiento, ya que garantiza que los procesadores estén igualmente ocupados en el manejo de las solicitudes de I/O hacia y desde las unidades NVMe.

El enfoque de la solución son las I/O de alto rendimiento y se diseñó como una solución de scratch de alta velocidad. El núcleo de la solución es el uso de SSD NVMe de alta velocidad que ofrecen un alto ancho de banda y baja latencia mediante la eliminación del programador y los cuellos de botella en la cola de la capa de bloques. El sistema de archivos de BeeGFS también es compatible con un alto rendimiento agregado de I/O.

Arquitectura de referencia de la solución

En la Figura 1, se muestra la arquitectura de referencia de la solución. El servidor de administración solo está conectado mediante Ethernet a los servidores de metadatos y almacenamiento. Cada servidor de metadatos y almacenamiento tiene dos vínculos InfiniBand y está conectado a la red privada a través de Ethernet. Los clientes tienen un enlace InfiniBand y están conectados a la interfaz privada a través de Ethernet.

Figura 1:  Soluciones listas de Dell para almacenamiento HPC BeeGFS: arquitectura de referencia

Configuración de hardware y software

En las tablas 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

La arquitectura de BeeGFS consta de cuatro servicios principales:

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

A excepción del servicio de cliente, que es un módulo de kernel, los servicios de administración, metadatos y almacenamiento son procesos de espacio de usuario. En la Figura 2, se ilustra cómo la arquitectura de referencia de Dell EMC Ready Solutions for HPC BeeGFS Storage se aplica a la arquitectura general del sistema de archivos BeeGFS.

Figura 2:  Sistema de archivos BeeGFS en PowerEdge R740xd con SSD NVMe

Servicio de administración

Cada espacio de nombres o sistema de archivos BeeGFS tiene solo un servicio de administración. El servicio de administración es el primer servicio que se debe configurar, porque cuando configuramos todos los demás servicios, estos deben registrarse en el servicio de administración. Se utiliza un PowerEdge R640 como el servidor de administración. Además de alojar el servicio de administración (beegfs-mgmtd.service), también aloja el servicio de monitoreo (beegfs-mon.service) que recopila estadísticas del sistema y las proporciona al usuario mediante la base de datos de series de tiempo InfluxDB. Para la visualización de datos, beegfs-mon ofrece paneles Grafana predefinidos que se pueden utilizar de inmediato. El servidor de administración tiene 6 HDD de 300 GB configurados en RAID 10 para el sistema operativo e InfluxDB.

Servicio de metadatos

El servicio de metadatos es un servicio de escalamiento horizontal, lo que significa que puede haber muchos servicios de metadatos en un sistema de archivos BeeGFS. Sin embargo, cada servicio de metadatos tiene exactamente un destino de metadatos para almacenar metadatos. En el destino de metadatos, BeeGFS crea un archivo de metadatos por cada archivo creado por el usuario. Los metadatos de BeeGFS se distribuyen por directorio. El servicio de metadatos proporciona la información de fraccionado de datos a los clientes y no está involucrado en el acceso a datos entre archivo abierto/cerrado.

Un PowerEdge R740xd con 24 unidades NVMe Intel P4600 de 1,6 TB que se utilizan para el almacenamiento de metadatos. Dado que los requisitos de capacidad de almacenamiento para los metadatos de BeeGFS son muy pequeños, en lugar de usar un servidor de metadatos dedicado, solo se utilizaron las 12 unidades en la zona NUMA 0 para alojar los Targets de metadatos (MDT), mientras que las 12 unidades restantes en los Targets (ST) de almacenamiento delhost de la zona NUMA.

En la figura 3, se muestra el servidor de metadatos. Las 12 unidades dentro del rectángulo amarillo son los MDT en la zona NUMA 0, mientras que las 12 unidades dentro del rectángulo verde son los ST en la zona NUMA 1. Esta configuración no solo evita los problemas de NUMA, sino que también proporciona suficiente almacenamiento de metadatos para facilitar el escalamiento de la capacidad y el rendimiento según sea necesario.

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.

Figura 4:  Configuración de unidades en el servidor

de metadatos Las 12 unidades que se utilizan para los metadatos se configuran como un grupo de discos RAID 1 6x de dos unidades, cada una de las cuales funciona como un MDT. Hay seis servicios de metadatos en ejecución, cada uno de los cuales maneja un MDT. Las 12 unidades de almacenamiento restantes están configuradas en 3 grupos de discos RAID 0 de cuatro unidades cada uno. Hay tres servicios de almacenamiento que se ejecutan en la zona NUMA 1, un servicio para cada ST. Por lo tanto, el servidor que aloja conjuntamente los metadatos y los destinos de almacenamiento tiene 6 MDT y 3 ST. También ejecuta seis servicios de metadatos y tres servicios de almacenamiento. Cada MDT es un sistema de archivos ext4 basado en una configuración de RAID 1. Los ST se basan en un sistema de archivos XFS configurado en RAID 0.
 

Servicio de almacenamiento

Al igual que el servicio de metadatos, el servicio de almacenamiento también es un servicio de escalamiento horizontal. Puede haber muchas instancias del servicio de almacenamiento en un sistema de archivos BeeGFS. Sin embargo, a diferencia del servicio de metadatos, puede haber varios destinos de almacenamiento por servicio de almacenamiento. El servicio de almacenamiento almacena el contenido de los archivos de usuario fraccionados, también conocidos como archivos de fragmentos de datos.

La Figura 5 muestra los 5 servidores PowerEdge R740xd utilizados como servidores de almacenamiento.

Figura 5:  Servidores

de almacenamiento dedicados Cada servidor de almacenamiento está configurado con 6 grupos RAID 0, cada uno de cuatro unidades, lo que aloja 6 ST por servidor (3 por zona NUMA), como se muestra en la Figura 6 que aparece a continuación:

Figura 6:  Configuración de unidades en los servidores

de almacenamiento En total, la configuración de la arquitectura de referencia base aloja 6 MDT y 33 ST. Tener cinco servidores de almacenamiento exclusivos proporciona una capacidad cruda de 211 TB y una capacidad útil de 190 TiB. La capacidad útil estimada en TiB = cantidad de unidades x capacidad por unidad en TB x 0,99 (sobrecarga del sistema de archivos) x (10^12/2^40). Esto sería ideal como una solución temporal de rango medio con suficiente almacenamiento de metadatos para facilitar la adición de más servidores de almacenamiento a medida que aumentan los requisitos de capacidad.

En vista de los siguientes factores, se eligió una configuración de RAID 0 para los destinos de almacenamiento sobre la configuración de RAID 10.

1. El rendimiento de escritura se midió mediante el comando dd mediante la creación de un archivo de 10 GB con un tamaño de bloque de 1 MB 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 referencia de StorageBench mostraron que el rendimiento máximo fue de 5,5 GB/s para la configuración RAID 0, mientras que es de 3,4 GB/s para una configuración 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 aceleraciones que se utilizan mejor en una configuración RAID 0

Servicios de cliente

El módulo de cliente de BeeGFS se debe cargar en todos los hosts que deben acceder al sistema de archivos de BeeGFS. Cuando se carga beegfs-client , monta los sistemas de archivos definidos en el archivo/etc/beegfs/beegfs-mounts.conf en lugar del enfoque habitual basado en /etc/fstab. La adopción de este enfoque inicia beegfs-client como cualquier otro servicio de Linux a través del script de inicio de servicio. También permite la recompilación automática del módulo de cliente de BeeGFS después de instalar las actualizaciones del sistema. 

Cuando se carga el módulo de cliente, monta los sistemas de archivos definidos en beegfs-mounts.conf. Es posible montar varias instancias de beegfs en el mismo cliente, como se muestra a continuación:

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

En el ejemplo anterior, se muestran dos sistemas de archivos diferentes montados en el mismo cliente. Para esta prueba, se utilizaron 32 nodos C6420 como clientes.

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

En la configuración de 24 NVMe del servidor PowerEdge R740xd, hay dos tarjetas puente de NVMe x16 que alimentan el switch PCIe en el backplane que distribuye las unidades (x4) de forma ramificada y las alimenta en la parte frontal, como se muestra en la Figura 7 a continuación:


Figura 7:  R740xd, 24 NVMe, detalles sobre la asignación de CPU

En acceso de memoria no uniforme (NUMA), la memoria del sistema se divide en zonas denominadas nodos, que se asignan a CPU o conectores. El acceso a la memoria local de una CPU es más rápido que a una memoria conectada a CPU remotas en el sistema. Por lo general, una aplicación con subprocesos funciona mejor cuando los subprocesos acceden a la memoria en el mismo nodo NUMA. El efecto en el rendimiento de las fallas de NUMA es significativo y, normalmente, comienza con un 10 % de impacto en el rendimiento o más. Para mejorar el rendimiento, los servicios están configurados para utilizar zonas NUMA específicas a fin de evitar el uso innecesario de enlaces UPI entre conectores, lo que reduce la latencia. Cada zona NUMA maneja 12 unidades y emplea una de las dos interfaces InfiniBand EDR en los servidores. Para realizar esta separación de NUMA, se debe configurar manualmente el equilibrio de NUMA mediante la creación de archivos de unidad systemd personalizados y el ajuste de alojamiento múltiple. Por lo tanto, el equilibrio automático de NUMA está deshabilitado, como se muestra a continuación:

# cat /proc/sys/kernel/numa_balancing
0

En la figura 8, se muestra el banco de pruebas donde se resaltan las conexiones InfiniBand a la zona NUMA. Cada servidor tiene dos vínculos IP y el tráfico a través de la zona NUMA 0 es entregado por la interfaz IB0, mientras que el tráfico a través de la zona NUMA 1 es manejado por la interfaz IB1.

Figura 8:  Configuración de banco de prueba
 

Caracterización del rendimiento

En esta sección, se presenta la evaluación de rendimiento que ayuda a caracterizar la solución Dell EMC lista para HPC BeeGFS de almacenamiento de alto rendimiento. Para obtener más detalles y actualizaciones, busque la documentación técnica que se publicará más adelante. El rendimiento del sistema se evaluó mediante el parámetro de referencia IOzone. La solución se probó en cuanto al rendimiento de lectura y escritura secuenciales, y las IOPS de lectura y escritura aleatorias. En la tabla 4, se describe la configuración de los servidores C6420 que se utilizaron como clientes de BeeGFS para los estudios de rendimiento de este blog.
 

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 llevaron a cabo en varios conteos de subprocesos, comenzando en un subproceso y aumentando en potencias de 2, hasta 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ó el tamaño de archivo agregado lo suficientemente grande como para minimizar los efectos del almacenamiento en caché de los servidores y 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 esta prueba y los resultados, se utilizó un tamaño de registro de 1 MB 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 descartaron o limpiaron en los nodos del cliente entre iteraciones y entre las 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ó el tamaño de sección de BeeGFS en 2 MB y el conteo de secciones en 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: 

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

Figura 9:  Tamaño de archivo agregado secuencial de 8 TB de zona I/O.

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. Porque hasta ocho subprocesos, tenemos ocho clientes que escriben ocho 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 usar completamente todos los servidores. El rendimiento de lectura registra un aumento lineal constante con el aumento en la cantidad de subprocesos simultáneos, y observamos un rendimiento casi similar con 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 completador envía la confirmación a MRR.
• El agente finalizador devuelve una finalización con datos.

El rendimiento de lectura depende del retraso entre el momento en que se emite la solicitud de lectura y el tiempo que tarda la completadora 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). Las cachés del SO se descartaron entre las ejecuciones en los servidores de BeeGFS y los clientes de BeeGFS. El comando utilizado para realizar las escrituras y lecturas aleatorias se muestra 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.

Las escrituras aleatorias alcanzan un máximo de ~3,6 millones de IOPS en 512 subprocesos y las lecturas aleatorias alcanzan un máximo de ~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 NVMe proporciona niveles más altos de paralelismo de I/O y, por lo tanto, se observa que las IOPS 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 parte 3 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 objetivos de almacenamiento incorporado de BeeGFS.

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

Referencias

[1] Documentación de BeeGFS:  https://www.beegfs.io/wiki/
[2] How to connect two interfaces on the same subnet:  https://access.redhat.com/solutions/30564