PowerScale, Isilon OneFS: Prueba de rendimiento de HBase en Isilon (en inglés)

Introducción

Hicimos una serie de pruebas de análisis comparativo de rendimiento en un clúster Isilon X410 mediante el conjunto de análisis comparativo YCSB y CDH 5.10.

El ambiente de laboratorio de POC CAE se configuró con 5 nodos Isilon x410 que ejecutan OneFS 8.0.0.4 y versiones posteriores 8.0.1.1 Parámetros de streaming de bloques grandes de NFS debe esperar 5 escrituras de ~700 MB/s (3,5 GB/s) y 5 lecturas de ~1 GB/s (5 GB/s) para nuestros máximos de agregado teóricos en cualquiera de estas pruebas.

Los (9) nodos de procesamiento son servidores Dell PowerEdge FC630 que ejecutan CentOS 7.3.1611, cada uno configurado con CPU Intel Xeon® E5-2697 v4 de 2x18C/36T a 2,30 GHz con 512 GB de RAM. El almacenamiento local es 2xSSD en RAID 1 formateado como XFS para el sistema operativo y los archivos de espacio/derrame desde cero.

También había tres servidores edge adicionales que se utilizaron para impulsar la carga de YCSB.

La red de back-end entre los nodos de procesamiento e Isilon es de 10 Gbps con tramas jumbo configuradas (MTU=9162) para las NIC y los puertos de switch.

Pruebas iniciales

La primera serie de pruebas fue determinar los parámetros pertinentes en el lado de HBASE que afectaron la salida general. Utilizamos la herramienta YCSB para generar la carga para HBASE. Esta prueba inicial se ejecutó con un solo cliente (servidor perimetral) mediante la fase de "carga" de YCSB y 40 millones de filas. Esta tabla se eliminó antes de cada ejecución.
 

ycsb load hbase10 -P workloads/workloada1 -p table='ycsb_40Mtable_nr' -p columnfamily=family -threads 256 -p recordcount=40000000

hbase.regionserver.maxlogs : cantidad máxima de archivos de registro de escritura anticipada (WAL). Este valor multiplicado por el tamaño de bloque de HDFS (dfs.blocksize) es el tamaño de WAL que se debe repetir cuando un servidor se bloquea. Este valor es inversamente proporcional a la frecuencia de vaciados en el disco.

hbase.wal.regiongrouping.numgroups : cuando se usan varios WAL de HDFS como WALProvider, establece la cantidad de registros de escritura anticipada que debe ejecutar cada RegionServer. Da como resultado esta cantidad de canalizaciones de HDFS. Las escrituras para una región determinada solo van a una sola canalización, lo que propaga la carga total de RegionServer.

La filosofía aquí era paralelizar tantas escrituras como pudiéramos, por lo que aumentar la cantidad de WAN y luego la cantidad de subprocesos (canalización) por WAL lo logra. Los dos gráficos anteriores muestran que para un número determinado para "maxlogs" 128 o 256 no vemos ningún cambio real que indique que realmente no estamos ingresando a este número desde el lado del cliente. Oby varía la cantidad de "pipelines" por archivo, aunque vemos la tendencia que indica el parámetro que es sensible a la paralelización. La siguiente pregunta sería dónde se "interesó Isilon", ya sea con E/S de disco, red, CPU o OneFS, y podemos ver lo que informan las estadísticas de Isilon.


 
Los gráficos de red y CPU nos indican que el clúster Isilon está infrautilizado y tiene espacio para más trabajo. La CPU sería > del 80 % y el ancho de banda de red sería de más de 3 GB/s.



Estos trazados muestran las estadísticas del protocolo HDFS y la forma en que OneFS las traduce. Las operaciones de HDFS son múltiplos de dfs.blocksize, que es de 256 MB aquí. Lo interesante aquí es que el gráfico "Heat" muestra las operaciones de archivos de OneFS y puede ver la correlación de escrituras y bloqueos. En este caso, HBase realiza anexos a los WAL, de modo que OneFS bloquea el archivo de WAL para cada escritura que se agrega. Esto es lo que esperaríamos para escrituras estables en un sistema de archivos en clúster. Esto parece contribuir al factor limitante en este conjunto de pruebas.

Actualizaciones de HBase

Esta siguiente prueba fue para hacer un poco más de experimentación en la búsqueda de lo que sucede a escala, por lo que creé una tabla de mil millones de filas, que tardó una buena hora en generarse, y luego hice una ejecución de YCSB que actualizó 10 millones de filas con la configuración "workloada" (lectura/escritura de 50/50). Esto se ejecutó en un solo cliente y también estaba buscando el mayor rendimiento que podía generar, por lo que lo ejecuté como una función de la cantidad de subprocesos de YCSB. Otra nota fue que hicimos algunos ajustes de Isilon y pasamos a OneFS 8.0.1.1, que tiene ajustes de rendimiento para el servicio de nodo de datos. Puede ver el aumento en el rendimiento en comparación con el conjunto anterior de ejecuciones. Para estas ejecuciones, se establece hbase.regionserver.maxlogs = 256 y hbase.wal.regiongrouping.numgroups = 20

Si observamos estas ejecuciones, lo primero que es evidente es la caída en un alto conteo de subprocesos. Tenía curiosidad sobre si se trataba de un problema de Isilon o un problema del lado del cliente. Vemos algunas pruebas adicionales con respecto a eso en los próximos párrafos. Pero puedo decir que impulsar más de 200 000 operaciones con una latencia de actualización de < 3 ms es impresionante. Cada una de estas ejecuciones de actualización fue rápida y podría hacerlos una tras otra y el gráfico que aparece a continuación muestra el equilibrio par entre los nodos de Isilon para estas ejecuciones.



Una vez más, puede ver en el gráfico De calor que las operaciones de archivos son escrituras y bloqueos correspondientes a la naturaleza anexada de los procesos de WAL.

Escalamiento del servidor de región

La siguiente prueba fue determinar cómo los nodos Isilon (cinco de ellos) se enfrentarían a una cantidad diferente de servidores de región. El mismo script de actualización que se ejecutó en la prueba anterior se ejecutó aquí. Una tabla de mil millones de filas y 10 millones de filas actualizadas mediante "workloada" con un solo cliente y subprocesos YCSB en 51, también mantuvimos el mismo ajuste en los registros máximos y las canalizaciones (256 y 20 respectivamente).

 
Los resultados son informativos, aunque no sorprenden. La naturaleza de escalamiento horizontal de HBase combinada con la naturaleza de escalamiento horizontal de Isilon y more==better. Esta es una prueba que recomendaría a los clientes ejecutar en sus entornos como parte de su propio ejercicio de dimensionamiento. Puede llegar a un punto de disminución de los rendimientos, pero aquí tenemos nueve servidores considerables que impulsan cinco nodos Isilon y parece que hay espacio para más.

Más clientes

La última serie de pruebas proviene de ese lugar oscuro profundo que hace que desee romper el sistema que está probando. Después de todo, es un método científico perfectamente válido para realizar una prueba hasta que las cosas se rompan y llamen, por lo tanto, saber cuál es el límite superior de los parámetros que se prueban. En esta serie de pruebas, tenía dos servidores adicionales que podía usar para ejecutar el cliente, además ejecuté dos clientes YCSB en cada uno, lo que me permitió escalar hasta seis clientes cada uno con 512 subprocesos, que serían 4096 subprocesos en general. Fui atrás y creé dos tablas diferentes, una con 4 mil millones de filas divididas en 600 regiones y otra con 400 millones de filas divididas en 90 regiones.  

 



 

Como puede ver, el tamaño de la tabla importa poco en esta prueba. Si observa los gráficos de Isilon Heat nuevamente, puede ver que hay algunas diferencias porcentuales en la cantidad de operaciones de archivos principalmente en línea, con las diferencias de una tabla de cuatro mil millones de filas a 400 millones de filas.

Conclusión

HBase es un buen candidato para ejecutarse en Isilon, principalmente debido al escalamiento horizontal a las arquitecturas de escalamiento horizontal. HBase realiza una gran cantidad de su propio almacenamiento en caché y está dividiendo la tabla en una buena cantidad de regiones en las que obtiene HBase para escalar horizontalmente con sus datos. En otras palabras, hace un buen trabajo para atender sus propias necesidades, y el sistema de archivos está ahí para la persistencia. No pudimos llevar las pruebas de carga al punto de romper las cosas, pero si observamos cuatro mil millones de filas en su diseño de HBase y esperamos 800 000 operaciones con menos de 3 ms de latencia, esta arquitectura lo admite. Si notan que no mencioné mucho más acerca de cualquiera de los innumerables otros ajustes del lado del cliente que podrían aplicar a HBase en sí, esperaría que todos esos ajustes aún sean válidos y que estén más allá del alcance de esta prueba.