Introducción
Resumen: En el Episodio del Blog-1 hemos cubierto RHCS, introducción de BlueStore, detalles de hardware de laboratorio, metodología de evaluación comparativa y comparación de rendimiento entre la configuración predeterminada de Ceph y la configuración ajustada de Ceph
Este es el segundo episodio de la serie de blogs de rendimiento en RHCS 3.2 BlueStore que se ejecuta en el clúster all – flash. No existe una regla general para clasificar los tamaños de bloque en una categoría pequeña, mediana y grande. Como tal, hemos designado la categoría de tamaño de bloque de 4K a pequeño, de 8K a 64K a mediano y de 1M a 4M a la categoría de tamaño de bloque grande. En este episodio, aprenderá sobre la caracterización del rendimiento del almacenamiento de bloques Ceph para tamaños de bloques pequeños (4K), medianos (8K-32K) y grandes (1M-4M) en patrones de carga de trabajo de lectura, escritura y lectura y escritura aleatorias.
Resumen ejecutivo
- Carga de trabajo de bloque pequeño 4K, entregada hasta 2.2 Millones de lecturas aleatorias, 691K de lectura y escritura aleatorias (70/30) y 463K de IOPS de escritura aleatoria hasta que estén limitadas por la contención de CPU y medios.
- Similar a la carga de trabajo de bloques pequeños, se encontró que el rendimiento de bloques medianos estaba limitado por la contención de CPU y medios.
- Rendimiento máximo de carga de trabajo de bloque grande 4M registrado a 10,9 GB / s para los tres patrones de prueba, es decir, mezcla aleatoria de lectura, escritura y lectura-escritura (70/30) hasta que esté limitado por el ancho de banda de la red del cliente.
Parte 1: Rendimiento de tamaño de bloque pequeño (4 KB)
Conclusiones clave
- Carga de trabajo de lectura aleatoria mostrada 2.Latencia media de 2 millones de IOPS a 3 ms hasta que la saturación de los medios se vea afectada por el embotellamiento.
- La carga de trabajo de mezcla de lectura y escritura aleatoria (70/30) mostró una latencia media de 691 K IOPS a 6 ms hasta que la contención de recursos de CPU del nodo Ceph se viera afectada por el embotellamiento.
- Escritura aleatoria: 463K IOPS@11 ms latencia media hasta que se bloquee la contención de recursos de CPU del nodo Ceph.
Resumen
En esta parte de la prueba, la interfaz de almacenamiento de bloques Ceph se ejerció con una carga de trabajo de tamaño de bloque pequeño (4 KB) en patrones de mezcla de lectura aleatoria, escritura aleatoria y lectura y escritura aleatorias (70/30). Las métricas clave capturadas durante las pruebas incluyen IOPS, promedio, latencia, CPU de nodo Ceph y utilización de medios.
El gráfico 1 muestra el rendimiento de primera línea para el tamaño de bloque 4K en diferentes patrones de acceso con 5 nodos all-flash. Como tal, se encontró que el máximo rendimiento era
- Lectura aleatoria: 2,2 Millones de IOPS a 3 ms latencia media
- Mezcla de Lectura y escritura aleatoria (70/30): 691K IOPS a 6 ms latencia media
- Escritura aleatoria: Latencia media de 463K IOPS a 11 ms
H La utilización de CPU y medios capturada en graph-2 y graph-3 nos ayudó a comprender los cuellos de botella para diferentes patrones de carga de trabajo.
- Se encontró que el rendimiento de lectura aleatoria estaba bloqueado por la contención de recursos de la CPU, sin embargo, la utilización de los medios también se encontró en el lado superior. Como tal, hemos agregado nodos Ceph adicionales (CPU y medios), el rendimiento de lectura aleatoria podría haber aumentado.
- Tanto para la mezcla de escritura aleatoria como de lectura y escritura aleatorias (70/30), el rendimiento se vio obstaculizado por un mayor consumo de CPU. Curiosamente, al mismo tiempo, los medios tenían suficiente rendimiento de repuesto que permaneció sin usar debido a la falta de potencia computacional. Por lo tanto, una mayor asignación de núcleos de CPU a Ceph OSD podría haber proporcionado un mayor rendimiento para cargas de trabajo de mezcla de lectura y escritura aleatorias &.
La utilización del dispositivo de datos OSD (P4500 NVMe) se mantuvo por debajo del 50% de utilización, el dispositivo Intel Optane P4800 que alojaba metadatos BlueStore WAL y Rocksdb resultó estar muy ocupado al 90%. El parámetro bluestore_min_alloc_size_ssd se estableció en 16 KB, por lo que todas las escrituras por debajo de 16 KB se aplazaron, la escritura primero va al dispositivo WAL y luego se escribe de forma asíncrona en los datos de OSD, por lo que el dispositivo Optane P4800 había absorbido las escrituras para todos los OSD en el host. A pesar de la alta utilización en el dispositivo RocksDB/WAL, no hemos visto ningún signo de contención en el dispositivo de datos OSD P4500. Pero basándonos en esta experiencia, no recomendaríamos poner más de 7 dispositivos NVMe P4500 detrás de un solo Intel Optane P4800 para WAL / RocksDB.
Gráfico 2
Gráfico 3
Otra interesante prueba que corrió fue cliente de prueba de barrido, donde tenemos linealmente ampliado el número de clientes a partir del 20 y hasta 140. A medida que aumentábamos la carga de clientes, observamos una mejora lineal del rendimiento hasta que llegamos a la congestión de la CPU en Ceph OSD. Con 100 clientes, hemos observado ~445K IOPS de escritura 4K agregados. Después de este punto, la congestión de los recursos del sistema dio lugar a altas latencias de cola. Intel Optane utilizado como metadatos ayudó a absorber el pico de latencia con un alto número de clientes paralelos, ya que la latencia promedio se mantuvo por debajo de los 40 ms.
G
Parte 2: Rendimiento de tamaño de bloque medio
Conclusiones clave
- Hasta que el rendimiento se vio limitado por la saturación de la CPU y los medios, 5 nodos Ceph todo flash entregaron ~1,8 Millones de lecturas aleatorias, ~636K de lectura aleatoria (70/30) y ~410K de IOPS de escritura aleatoria.
- Para escalar el rendimiento, se tuvieron que agregar nodos Ceph OSD adicionales en el clúster de Ceph existente.
Resumen
En los siguientes gráficos, hemos intentado representar varios puntos de datos diferentes, como IOPS, latencia media, latencia de cola, CPU de nodo Ceph y utilización de medios. Y todo esto en un rango de tamaño de bloque, es decir, desde 4K hasta 64K para mezcla de escritura aleatoria, lectura aleatoria y lectura y escritura aleatorias (70/30).
Algunos puntos de datos interesantes incluyen
- Como se esperaba, los tamaños de bloques pequeños mostraron IOPS más altos y latencias medias y de cola más bajas, en comparación con los tamaños de bloques medianos. Como tal, observamos ~1,8 millones, ~636K, ~410K IOPS para Lectura Aleatoria, Mezcla de Lectura Aleatoria y carga de trabajo de escritura aleatoria, respectivamente.
- Se observó una alta utilización de CPU y dispositivos multimedia en nodos Ceph OSD. Se encontró que la utilización era tan alta como ~90% y ~80%, respectivamente, para CPU y medios, respectivamente. Como tal, el rendimiento podría haber aumentado si hubiéramos agregado nodos Ceph OSD al clúster de Ceph existente.
G
Parte 3: Rendimiento de tamaño de bloque grande
Conclusiones clave
- El rendimiento de bloque grande 4M alcanzó un máximo de 10.9 GB/s para mezcla aleatoria de lectura, escritura y lectura-escritura (70/30).
- Se encontró que la red de clientes era el factor limitante y causaba un cuello de botella de rendimiento.
- El rendimiento podría haber sido mayor, si hubiéramos tenido más nodos de cliente o tuberías de red más grandes.
Resumen
Todos los diferentes patrones que hemos probado, es decir, mezcla aleatoria de lectura, escritura y lectura-escritura (70/30) para cargas de trabajo de 4 M de gran tamaño de bloque con un rendimiento agregado de 10,9 GB/s. Se descubrió que la red de clientes era el factor limitante que causaba el cuello de botella de rendimiento. Aparte de la red, el segundo recurso más utilizado eran los medios, sin embargo, tenía suficiente espacio disponible para ofrecer más rendimiento, si la red no era el cuello de botella.
G
Up Next
Continuando con la serie de blogs de benchmarking, en la siguiente sección, explicaremos los resultados asociados con las pruebas de escalabilidad de RHCS 3.2. Responder algunas preguntas clave como «cómo cambia el rendimiento al pasar de un clúster de 3 nodos a 5 nodos». Estén Atentos.