Buscar con el tamaño de rendimiento del cluster OpenSearch

El proceso de dimensionamiento y determinación de la capacidad de un cluster OpenSearch implica equilibrar el costo y el rendimiento. Varios factores influyen tanto en el rendimiento como en las decisiones de tamaño, por lo que es esencial recopilar datos sobre estos aspectos para ajustar el proceso de planificación de la capacidad.

Puede agrupar estos factores en las siguientes categorías: consideraciones específicas del caso de uso, relacionadas con datos y relacionadas con recursos.

• Específico del caso de uso: estos factores son la finalidad prevista del despliegue de OpenSearch. Por ejemplo, ¿se está utilizando el cluster para el análisis de logs o la observabilidad, que normalmente implica un mayor volumen de escrituras en comparación con las lecturas? ¿O se está utilizando para la búsqueda de aplicaciones, donde los datos se escriben una vez y se leen muchas veces? De manera alternativa, ¿el cluster está diseñado para soportar cargas de trabajo de Machine Learning que hacen un uso intensivo de los recursos? Comprender el caso de uso ayuda a determinar la latencia y el rendimiento de lectura y escritura necesarios, los patrones de consulta y los tipos de consultas, como filtros, agregaciones o búsquedas básicas, que se deben optimizar.
• Relacionado con los datos: este factor incluye el volumen de datos que se van a almacenar, el tipo de datos (estructurado o no estructurado), el tamaño del documento, la cardinalidad, los tipos de campo y si se han definido asignaciones de campo. Además, el códec de compresión en uso y el tamaño y el número de índices, particiones horizontales y réplicas, todos contribuyen al tamaño y el rendimiento generales del cluster.
• Relacionado con los recursos: estos factores implican la configuración y el número de nodos del cluster, incluidos los nodos del gestor de cluster, los nodos de datos y los nodos del panel de control. Estos recursos afectan directamente a la capacidad del cluster para manejar la carga de trabajo definida y garantizar el mejor rendimiento.

Aunque inicialmente la planificación de la capacidad puede parecer abrumadora, se vuelve más manejable a medida que experimenta y aborda las preocupaciones de manera incremental. La clave es comenzar con una estimación inicial basada en las mejores prácticas establecidas, evaluar continuamente si se están cumpliendo sus indicadores clave de rendimiento (KPI) e iterar hasta lograr el equilibrio ideal entre costo y rendimiento. Los siguientes pasos describen el proceso de planificación de capacidad:

1. Estimar requisitos de almacenamiento.
2. Defina la estrategia de fragmentación.
3. Estimar la configuración del nodo de datos.
4. Estimar la configuración del nodo del gestor de clusters.
5. Estimar la configuración del nodo del panel de control.
6. Pruebe el cluster e itere.

En esta sección, puede aplicar los principios descritos a un ejercicio de tamaño de cluster realista. Imagine que tiene un caso de uso de análisis de logs en el que ingiere datos en varios índices de un cluster OpenSearch a una velocidad de 10 GB por día. Su objetivo es conservar los datos durante un máximo de 90 días, después de lo cual puede descartarlos de forma segura.

La ingesta de datos puede ser por lotes o continua, según el caso de uso. En muchos escenarios de búsqueda de aplicaciones e inteligencia empresarial, los datos se cargan de forma masiva durante los procesos por lotes y, a continuación, se consultan varias operaciones, como el filtrado, la agregación y la búsqueda. Estos tipos de índices se consideran de larga duración, y sus requisitos de almacenamiento normalmente se pueden estimar mediante el análisis de los datos de origen, que tienden a cambiar con poca frecuencia.

Para otros casos de uso, como análisis de logs, análisis de series temporales y supervisión de usuarios reales, los datos se ingieren continuamente en el cluster, con índices que se acumulan después de alcanzar un determinado tamaño o umbral de tiempo. Para estos tipos de índices, es esencial calcular el volumen de datos ingeridos durante un período de tiempo específico y, a continuación, multiplicarlo por el período de retención necesario para estimar los requisitos de almacenamiento.

Además del volumen total de datos que se ingieren, otros factores influyen en la cantidad de almacenamiento necesario:

• Período de retención (r): la duración durante la que los datos se retienen en el cluster decide la cantidad máxima de datos que se almacenan en un momento determinado. Esta figura ayuda a estimar la capacidad del cluster para manejar el peor de los casos, donde está presente la mayor cantidad de datos, lo que garantiza un rendimiento ideal incluso en condiciones de almacenamiento máximas.
• Recuento de réplicas (rc): cada réplica es una copia exacta de su partición horizontal principal y sirve para fines de fiabilidad y rendimiento. Para evitar la pérdida de datos, le recomendamos que tenga al menos una réplica, que es el valor por defecto para cada índice. Si su caso de uso implica grandes volúmenes de lectura, puede ser útil configurar más de una réplica. Esto permite que varias particiones horizontales de réplica manejen consultas de búsqueda simultáneas, distribuyendo así la carga y mejorando el rendimiento de las consultas.
• Ratio de compresión (cr): los datos almacenados en el disco no son idénticos al volumen de datos raw que se ingiere. En cambio, suele ser más pequeño debido a la compresión aplicada durante el proceso de indexación. OpenSearch soporta varios códecs de compresión, cada uno de los cuales ofrece una compensación diferente entre el ratio de compresión y el rendimiento. Puede seleccionar el códec más adecuado para su caso de uso durante la creación del índice.

  El ratio de compresión alcanzado depende de varios factores, incluido el tipo de datos (estructurados frente a no estructurados), el número de valores de campo repetidos o vacíos, la cardinalidad de los datos y el tamaño general de los datos. Una suposición inicial razonable para la compresión suele estar entre el 25% y el 40%. Por ejemplo, 10 GB de datos raw ocuparían entre 6 GB (cr=1,67) y 7,5 GB (cr=1,33) en el disco. Sin embargo, es importante validar esta suposición con pruebas reales para su caso de uso específico.

• OpenSearch Sobrecarga de indexación (o1): OpenSearch incurre en hasta un 10 % de sobrecarga de almacenamiento para indexar datos no procesados. Después de la indexación, puede utilizar la API /_cat/indices?v junto con el valor pri.store.size para calcular el valor exacto en real.
• OpenSearch Sobrecarga de servicio (o2): OpenSearch reserva hasta el 20% del espacio de almacenamiento en cada instancia, con un máximo de 20 GB, para fusiones de segmentos, logs y otras operaciones internas.
• Sobrecarga del sistema operativo (o3): de manera predeterminada, Linux reserva el 5% del sistema de archivos para que el usuario root garantice que los procesos críticos del sistema, como el registro y la creación temporal de archivos, sigan funcionando cuando el disco esté casi lleno. Este espacio reservado también ayuda con la recuperación del sistema y evita la fragmentación del disco, evitando así interrupciones operativas.
• Buffer para incluir el margen de error (b): le recomendamos que agregue un buffer del 5 al 10 % para tener en cuenta los errores humanos y las suposiciones excesivamente optimistas, ya que el recuento de particiones horizontales no se puede cambiar después de definir un índice. Puede ajustar o eliminar este buffer más adelante a medida que recopila datos de uso reales.
• Fórmula:

  Required Storage = Source Data * r * (1 + rc) * (1/cr) * (1 + o1) * (1/1-o2) * (1/1-o3) * (1+b)

  La aplicación de esta fórmula al ejercicio de ejemplo da como resultado lo siguiente:

  • Datos de origen = 10 GB por día
  • r = 90, considerando un período de retención de 90 días
  • rc = 1, teniendo en cuenta que queremos 1 réplica
  • cr = 1,33, teniendo en cuenta que alcanzamos una relación de compresión del 25%
  • o1 = 0,1 (10% de sobrecarga de indexación)
  • o2 = 0,2 (20% de sobrecarga de servicio)
  • o3 = 0,05 (5 % de sobrecarga del sistema operativo)
  • b = 0,1 (búfer de margen de error del 10 %)
  • Almacenamiento necesario = 10 * 90 * 2 * 0,75 * 1,1 * 1/0,8 * 1/0,95 * 1,1 = 2150 GB = 2,2 TB (redondeado)

Una vez que haya establecido sus requisitos de almacenamiento, el siguiente paso es definir su estrategia de fragmentación. Esto incluye determinar el tamaño, el número y la distribución de las particiones horizontales. Las particiones horizontales OpenSearch son particiones independientes de los datos de índice, diseñadas para distribuir los datos entre los nodos del cluster a fin de garantizar un alto rendimiento y tolerancia a fallos.

Hay dos tipos de particiones horizontales: primaria y réplica. Una partición horizontal primary es la copia autorizada de una partición de datos y gestiona las operaciones de lectura y escritura. En cambio, una partición horizontal replica es una copia exacta de la partición horizontal principal y se utiliza únicamente para operaciones de lectura. Todas las solicitudes de escritura se dirigen primero a la partición horizontal principal, después de lo cual los datos se replican en las particiones horizontales de réplica.

OpenSearch asigna automáticamente particiones horizontales principales y de réplica entre nodos para garantizar que las particiones horizontales principales se distribuyan de la forma más uniforme posible y que las particiones horizontales principales y de réplica no se coloquen en el mismo nodo. Por ejemplo, un índice con tres particiones horizontales principales y una réplica cada una da como resultado seis particiones horizontales totales: tres particiones horizontales principales y tres réplicas. En esta configuración, cada solicitud de escritura es manejada por dos particiones horizontales (una principal y una réplica), mientras que las solicitudes de lectura pueden ser atendidas por cualquier combinación de particiones horizontales principales y de réplica, lo que proporciona redundancia y equilibrio de carga.

Después de determinar los requisitos de almacenamiento y decidir el tamaño y el número de particiones horizontales, puede comenzar a tomar decisiones de hardware. Aunque los requisitos de hardware pueden variar en función de la carga de trabajo, estas son algunas recomendaciones generales.

Para mejorar la estabilidad y el rendimiento del cluster, recomendamos utilizar nodos dedicados del gestor de clusters. Estos nodos descargan tareas de gestión críticas de los nodos de datos, lo que les permite centrarse únicamente en el almacenamiento de datos y el manejo de consultas. Los nodos del gestor de clusters no almacenan datos ni gestionan solicitudes de carga de datos. En su lugar, gestionan el estado general y el estado del cluster. Realizan un seguimiento de todos los nodos del cluster, supervisan el número de índices y supervisan la distribución de particiones horizontales para cada índice.

Los nodos de gestor mantienen la información de enrutamiento, actualizan el estado del cluster durante los cambios (como la creación de índices o la adición o eliminación de nodos) y replican las actualizaciones de estado en todos los nodos. También envían señales de latido para supervisar el estado y la disponibilidad de los nodos de datos, lo que garantiza que el cluster siga funcionando.

Le recomendamos que tenga al menos tres nodos del gestor de clusters para obtener la mejor fiabilidad. Tener un solo nodo de gestor es arriesgado, ya que el cluster podría dejar de estar disponible si ese nodo falla. Además, el uso de un número par de nodos de gestor no es ideal, ya que impide que el cluster forme el quórum necesario para elegir un nuevo gestor en caso de fallo. Tres nodos de gestor proporcionan dos nodos de copia de seguridad en caso de fallo y garantizan un quórum para elegir un nuevo gestor.

El aumento del número de nodos de gestor en incrementos impares (5, 7, etc.) puede mejorar la tolerancia a fallos, lo que permite al cluster soportar más fallos de nodo de gestor mientras permanece operativo. Sin embargo, agregar más de tres nodos de gestor es excesivo y solo se debe tener en cuenta para clusters excepcionalmente grandes o casos de uso especiales después de un análisis exhaustivo.

Aunque los nodos dedicados del gestor de clusters no gestionan las solicitudes de búsqueda y consulta, sus requisitos de recursos están estrechamente vinculados al número de nodos de datos, índices y particiones horizontales que necesitan gestionar. Las siguientes directrices pueden servir de punto de partida:

• 4 vCPU y 8 GB de memoria: hasta 16
• 8 vCPU y memoria de 16 GB: de 17 a 32
• 8 vCPU y memoria de 32 GB: de 33 a 64
• 16 vCPU y memoria de 64 GB: de 65 a 128

Para nuestro ejercicio, dado que tenemos cinco nodos de datos, podemos empezar por tener tres nodos de gestor de clusters cada uno con 4 vCPU y 8 GB de memoria.

Los nodos del panel de control son el tipo de nodo de tamaño más sencillo, ya que no indexan ni buscan directamente datos localmente y tienen requisitos de almacenamiento mínimos. Estos nodos funcionan principalmente como servidores de API, emitiendo solicitudes al cluster y manejando la E/S de datos. Los recursos clave necesarios para los nodos del panel de control son CPU y memoria, que dependen del número de solicitudes simultáneas del panel de control.

Si bien es común utilizar un único nodo de panel de control en clusters de producción más pequeños o incluso más pequeños, para la aplicación de panel de control OpenSearch de alta disponibilidad (HA), le recomendamos que utilice al menos dos nodos. Un buen punto de partida es desplegar uno o dos nodos del panel de control, en función de sus necesidades de alta disponibilidad. Para escenarios de bajo rendimiento, asigne 4 vCPUs y 8 GB de memoria por nodo, y para escenarios de alto rendimiento, asigne 8 vCPUs y 16 GB de memoria por nodo. Después del despliegue, supervise el uso de CPU y la presión de JVM para ajustar los recursos en función del rendimiento real.

Dado que la aplicación de análisis de logs la utiliza principalmente un número limitado de profesionales para el análisis de la causa raíz, la depuración y la revisión y generación de informes ocasionales, puede comenzar con un único nodo del panel de control con 8 vCPUs y 16 GB de memoria. A continuación, puede ajustar los recursos (escalando o reduciendo verticalmente) en función de los patrones de uso y el rendimiento de esta configuración inicial.

Realice las siguientes pruebas y ajuste la configuración según sea necesario:

• Usar datos de prueba similares a los de producción: asegúrese de que los datos de prueba reflejen de cerca los datos de producción que se ingieren en el cluster. Esto incluye hacer coincidir la estructura de los documentos (campos, tipos de dato, etc.) y su tamaño con el que se utiliza en la producción.
• Simular la carga del mundo real: realiza pruebas de rendimiento en condiciones reales. Comience por crear un cluster pequeño que simule la carga esperada y, a continuación, extrapole los resultados para estimar el rendimiento de los clusters más grandes. Los datos de prueba deben ser de un volumen significativo (en GB) para reflejar con precisión la carga.
• Supervisar y analizar métricas clave: supervise continuamente métricas críticas como el uso de CPU, la presión de JVM, el uso del disco, la latencia de búsqueda e indexación, las tasas de búsqueda e indexación y la disponibilidad general. Ajuste la configuración del cluster según sea necesario para cumplir con los KPI deseados.
• Supervisión continua en producción: la supervisión continua del cluster de producción es esencial. Compruebe regularmente estos KPI y tome medidas correctivas si el rendimiento se desvía de los umbrales esperados. Confiar únicamente en las pruebas de una sola vez antes de la puesta en marcha no es suficiente. La validación continua es fundamental para mantener el mejor rendimiento.

El tamaño de un cluster OpenSearch requiere un enfoque reflexivo que equilibre el rendimiento y el costo, tenga en cuenta factores como el caso de uso, el volumen de datos y la asignación de recursos. En este tema, se proporcionan directrices clave, mejores prácticas y reglas básicas para ayudarle a comenzar con la planificación de la capacidad. Al seguir un proceso estructurado y realizar iteraciones basadas en pruebas de rendimiento, puede asegurarse de que el cluster está optimizado tanto para la eficiencia como para la escalabilidad. La supervisión regular y los cambios en respuesta a la carga del mundo real son esenciales para mantener el máximo rendimiento. La configuración óptima del cluster evoluciona a medida que recopila información de sus patrones de uso y carga de trabajo específicos.