Maximización del rendimiento de Elasticsearch al agregar nodos a un cluster

blog-thumb-elasticsearch-gears-light-blue.png

Agregar nodos a un cluster de Elasticsearch permite escalar a enormes cargas de trabajo. Es fundamental comprender las formas óptimas de expandir el cluster de Elasticsearch para no perjudicar el rendimiento.

Elasticsearch es una tecnología de búsqueda rápida y potente. A medida que tus datos crezcan, necesitarás aprovechar su impresionante escalabilidad. Agregar más nodos a un cluster no solo aumenta la cantidad de datos que puede contener el cluster, sino que también mejora el número de peticiones que gestiona a la vez y reduce el tiempo necesario para devolver los resultados,normalmente.

Es un fin de semana terrible intentar descubrir por qué agregar nodos a tu cluster de Elasticsearch causó inestabilidad, tiempo de inactividad, frustración creciente y pérdida de ingresos. Entonces, analicemos algunas configuraciones comunes en las que el escalado de un cluster puede generar importantes cuellos de botella en el rendimiento.

Tenemos un excelente webinar llamado Planificación del tamaño y la capacidad de Elasticsearch. Define cuatro recursos de hardware principales en un cluster:

  1. Computación: unidad central de procesamiento (CPU), qué tan rápido el cluster puede realizar el trabajo.
  2. Almacenamiento: unidades de disco duro (HDD) o unidades de estado sólido (SSD), la cantidad de datos que el cluster puede almacenar a largo plazo.
  3. Memoria: memoria de acceso aleatorio (RAM), la cantidad de trabajo que el cluster puede realizar a la vez.
  4. Red: ancho de banda, la velocidad a la que los nodos transfieren datos entre sí.

Los dos cuellos de botella de rendimiento más comunes son la computación y el almacenamiento. Cuando son escasos, impactan profundamente los nodos de datos del cluster. Otras funciones de los nodos, como maestro, ingesta o transformación, son un tema aparte.

Nota: Para simplificar, este artículo se centra en el escalado de un único cluster de Elasticsearch. La ejecución de varios clusteres en hardware compartido agrega otra capa de complejidad.

Los recursos de hardware se asignan de forma diferente según la plataforma. Por ejemplo: ¿los nodos son hardware, máquinas virtuales o sistemas basados en contenedores?

Casos donde agregar nodos de Elasticsearch es agregar capacidad

Agregar nodos de hardware dedicado

La forma más predecible de aumentar el rendimiento del cluster es agregar nuevo hardware. Agregar nuevo hardware dedicado aumenta los cuatro recursos principales. Con una excepción principal (que se tratará más adelante), agregar nuevos nodos de hardware mejora el rendimiento del cluster.

agregar nodo de hardware dedicado

Agregar nodos en máquinas virtuales o contenedores en nuevos hospedajes

Agregar nodos como máquinas virtuales (VM) o contenedores cambia la conversación. Al asignar nuevos nodos en nuevos hospedajes al cluster, se otorgan más recursos de hardware. Más CPU core, más RAM, más almacenamiento y más ancho de banda total.

agregar nodo de nuevo contenedor

Una razón para virtualizar (o usar contenedores) aplicaciones es mejorar la utilización del hardware. En este caso, agregar nodos solo aumentará la cantidad de hardware disponible para el cluster. El aumento de rendimiento resultante depende de los límites de los recursos compartidos.

Casos donde agregar nodos es dividir capacidad

Ya sea que dividan el hardware mediante VM o contenedores, los nodos de Elasticsearch terminan compartiendo hardware. Estas consideraciones se aplican a todos los modelos de despliegue; incluidos Elastic Cloud Enterprise (ECE) y Elastic Cloud on Kubernetes (ECK).

Creación de un cuello de botella informático

El uso de máquinas virtuales para asignar CPU es generalmente predecible: asigna a cada VM cuántos núcleos utilizar. Mediante los contenedores, el uso compartido de CPU es menos sencillo.

Los sistemas de contenedores como Kubernetes pueden medir los recursos de CPU en milésimas de CPU o milicores. Existe una diferencia significativa entre las solicitudes y los límites. Definir solo la CPU solicitada permite que el contenedor utilice hasta el 100 % de la CPU del hospedaje. Sin embargo, limitar demasiado la CPU deja inactivos recursos costosos.

> Sugerencia: Los grupos de subprocesos utilizan CPU core como punto de partida. Con los contenedores, es bueno verificar que la configuración de su grupo de subprocesos funcione como se esperaba.

En Kubernetes, los límites de CPU totales de los contenedores pueden exceder el hardware total disponible. Esto supone que todos los contenedores no estarán en plena utilización de la CPU al mismo tiempo.

cuello de botella de CPU compartida

Considera el rendimiento máximo de un cluster. En cargas de trabajo con uso de computación intensivo, los nodos a menudo necesitan la totalidad de los límites de CPU asignados para la indexación. La carga de trabajo de indexación intensiva más común es un cluster de logging de gran volumen.

> Sugerencia: Considera el uso máximo y típico de la CPU al determinar los límites de esta. Considera también cuánta aceleración de la CPU es aceptable.

Creación de un cuello de botella de almacenamiento

Los cuellos de botella de almacenamiento pueden ser difíciles de prevenir. Esto se debe a que el almacenamiento se asigna por espacio y no por rendimiento. Cuando un nodo de Elasticsearch se queda sin espacio de almacenamiento, alcanza la marca de nivel de disco bajo y detiene la asignación de shards.

Ya sea VM o contenedor, la mayoría de las plataformas no tienen una manera fácil de limitar la utilización de los dispositivos de almacenamiento. La mayoría de los entornos no tienen límites configurables en las operaciones de entrada/salida por segundo (IOPS) o rendimiento de lectura/escritura. Incluso el sistema de archivos XFS recomendado solo permite cuotas de disco basadas en el espacio en disco.

Sin límites, cualquier contenedor con una carga de trabajo de almacenamiento intensivo puede saturar el hardware de almacenamiento. Esto hace que otros nodos que comparten ese hardware se queden sin recursos. Los despliegues a gran escala pueden fallar con sus directorios/datos. Cuando varios nodos montan su directorio/datos en el mismo hardware de red de área de almacenamiento (SAN), el rendimiento total de todos los nodos puede saturar el dispositivo.
capacidad de cuello de botella de almacenamiento frente a utilización

Con una configuración de contenedor como esta, agregar más nodos asigna más CPU y memoria al cluster. Sin embargo, divide aún más el rendimiento del almacenamiento existente. Esto hace que las operaciones de disco demoren más, por lo que el rendimiento empeora agregando nodos.

> Sugerencia: Cuando los nodos carecen de rendimiento de almacenamiento, una señal de advertencia temprana es un tiempo de espera de E/S de la CPU superior al 10 %. Comprueba si se trata de VM u hospedajes de contenedores, ya que los contenedores individuales no reportan esta métrica.

Casos donde agregar nodos es netamente neutral

Hay un último problema para escalar de manera efectiva. Este cuello de botella en la configuración se produce incluso cuando se agrega hardware físico.

Limitación del rendimiento de los índices si no hay suficientes shards

Agregar nodos, independientemente del método, no cambia la cantidad de shards en un índice. Si un índice tiene 2 shards primarios y 1 conjunto de réplicas, hay 4 shards en total. En un cluster de 4 nodos, tener solo un shard por nodo es una excelente manera de maximizar el rendimiento de la indexación.

A medida que aumenta el volumen de datos entrantes, agregamos otros 2 nodos al cluster. Este es un aumento del 50 % en los recursos totales del cluster, pero podemos ver exactamente una mejora del 0 % en la tasa de ingesta. ¿Por qué?

no hay suficientes shards primarios

En este caso, los nuevos nodos no pueden contribuir a la indexación, debido a que todos los shards ya están asignados. Para que un índice pueda aprovechar más nodos, el número de shards primarios también debe aumentar. Si tienes muchos índices activos en un cluster (lo cual es común), agregar nodos aumentará el rendimiento total del cluster, pero el índice más activo aún podría estar restringido debido a los shards primarios limitados. Seleccionar un buen número de shards para Elasticsearch es una parte importante de la planificación de la capacidad.

Así, en el ejemplo anterior, si se aumenta de 2 a 3 shards primarios, más 1 réplica por shard, se obtiene un total de 6 shards para asignar entre los 6 nodos.

> Sugerencia: Configurar index.routing.allocation.total_shards_per_node [docs] puede ser una red de seguridad. Sin embargo, fijar este límite demasiado bajo puede dejar shards atascados sin asignar.

Conclusión

¿Agregar nodos a un cluster de Elasticsearch mejorará su rendimiento? Depende. Si los nodos comparten hardware, debes estar atento a los cuellos de botella de los recursos compartidos. Dos cuellos de botella comunes son la sobreutilización de la CPU y el almacenamiento. Una planificación cuidadosa y una buena estrategia de shards garantizarán que agregar nodos aumente el rendimiento.

Uno de los muchos beneficios de ejecutar Elastic Cloud es la dedicación de nuestro equipo para identificar y abordar exactamente este tipo de problemas de rendimiento de recursos compartidos. No dudes en iniciar una prueba en la nube hoy mismo: https://www.elastic.co/es/cloud/.

También puedes profundizar en la comprensión del rendimiento de Elasticsearch observando Planificación del tamaño y la capacidad de Elasticsearch.