Cómo diseñar la arquitectura de tu almacén de datos de Elasticsearch para escalar
Elasticsearch te permite almacenar, buscar y analizar grandes cantidades de datos estructurados y no estructurados. Esta velocidad, escala y flexibilidad hacen que el Elastic Stack sea una solución poderosa para una amplia variedad de casos de uso, como observabilidad del sistema, seguridad (búsqueda y prevención de amenazas), búsqueda empresarial y más. Debido a esta flexibilidad, es sumamente importante diseñar de forma efectiva la arquitectura del almacenamiento de datos de tu despliegue para escalar.
Ahora, es lógico que cada caso de uso de Elasticsearch sea diferente. Tu propio caso de uso, despliegue o situación empresarial tendrán ciertas tolerancias y umbrales para cuestiones como las siguientes: costo total de propiedad, rendimiento de ingesta, rendimiento de búsqueda, cantidad o tamaño de backups, tiempo promedio hasta la recuperación y más.
Entonces, mientras comienzas a pensar sobre estos diversos factores, hay tres preguntas que podrías considerar para ayudar a evitar lo que de otro modo podría ser una matriz de decisión compleja:
- ¿Cuánta pérdida de datos puede soportar tu caso de uso o despliegue?
- ¿Qué importancia tiene el rendimiento en tus objetivos empresariales?
- ¿Cuánto tiempo de inactividad puede manejar tu proyecto?
En este blog revisaremos varias opciones de almacenamiento de datos que puedes usar y hablaremos sobre las distintas ventajas y desventajas de cada una. Para el final de este blog, comprenderás mejor cómo diseñar la arquitectura del almacén de datos de tu propio (y exclusivo) despliegue de Elasticsearch para escalar.
¿No quieres preocuparte por nada de esto? Tenemos buenas noticias: adoptar Elasticsearch Service en Elastic Cloud significa que nosotros nos encargaremos de diseñar la arquitectura para escalar por ti.
Un vistazo de las opciones
A continuación encontrarás una referencia rápida de las opciones para diseñar la arquitectura de tu almacenamiento de datos con Elasticsearch que abarcaremos en este blog. Describiremos en más detalle las ventajas y desventajas, y qué esperar con respecto a la pérdida de datos, el rendimiento y el tiempo de inactividad a continuación.
| RAID 0 | RAID 1 | RAID 5 | RAID 6 | Varias rutas de datos | |
| Protección de datos | Ninguna | 1 falla de disco | 1 falla de disco | 2 fallas de disco | Ninguna |
| Rendimiento* | NX | X/2 | (N - 1)X | (N - 2)X | 1X a NX |
| Capacidad | 100 % | 50 % | 67 % a 94 % | 50 % a 88 % | 100 % |
| Ventajas |
• Configuración fácil • Alto rendimiento • Alta capacidad • Elasticsearch solo detecta 1 disco |
• Alta protección de datos • Recuperación fácil • Elasticsearch solo detecta 1 disco |
• Protección de datos media • Recuperación fácil • Capacidad de media a alta • Ganancias de rendimiento de medias a altas • Elasticsearch solo detecta 1 disco |
• Alta protección de datos • Recuperación fácil • Capacidad de media a alta • Ganancias de rendimiento de medias a altas • Elasticsearch solo detecta 1 disco |
• Configuración fácil • Agregar discos • Alta capacidad |
| Desventajas |
• Sin tolerancia a fallas • Recuperación larga • Posibilidad de pérdida de datos permanente si no hay shards de réplica |
• Baja capacidad • Sin ganancias de rendimiento para escrituras • Solo se pueden usar 2 discos |
• Cierta pérdida de capacidad • Solo puede fallar 1 disco antes de que falle la matriz • Recuperación potencialmente larga • Si falla más de 1 disco, existe la posibilidad de pérdida de datos • Durante la recuperación, disminuye el rendimiento de las matrices |
• Pérdida de capacidad de pequeña a mediana • Recuperación potencialmente larga • Durante una recuperación, disminuye el rendimiento de las matrices |
• Shards no equilibrados entre rutas • La marca de agua de un solo disco afecta todo el nodo • El rendimiento no es consistente • Los discos no son intercambiables en caliente • Agregar un disco puede llevar a crear puntos calientes |
Cuando empieces a considerar el escalado de la capacidad de tu disco, existen varias opciones buenas para elegir. Veamos algunas y hablemos sobre las ventajas y desventajas de cada una. Como cada situación es única, no hay un camino que funcione para todos.
RAID 0
RAID ha sido la pieza clave para combinar varios discos durante décadas. RAID tiene tres componentes: creación de reflejos, fragmentación y paridad. Cada número en RAID indica una combinación única de estos componentes.
El número 0 representa la fragmentación en RAID. La fragmentación consiste en dividir los datos en partes y escribir estas partes en todos los discos del volumen.
Rendimiento y capacidad
La fragmentación mejora el rendimiento de lectura/escritura debido a que todos los discos pueden escribir en paralelo. De hecho, esto multiplicará tus escrituras y lecturas por la cantidad de discos que tengas en la matriz. Por lo tanto, si tienes 6 discos en una matriz de RAID 0, tendrías aproximadamente 6 veces más velocidad de lectura y escritura.
Recuperación
RAID 0 no ofrece recuperación, por lo tanto, Elasticsearch debe encargarse de la recuperación a través de snapshots o réplicas. Según el tamaño de los discos y el mecanismo de transporte usado para copiar los datos a la matriz, puede tomar mucho tiempo. Durante el paso de recuperación se verán afectados el tráfico de red y el rendimiento de otros nodos.
Advertencias
Como los índices de Elasticsearch están compuestos por muchos shards, cualquier índice con un shard en un volumen RAID 0 en el que falla un disco también se puede dañar si no existen otras réplicas. Esto resultará en una pérdida de datos permanente si no tienes gestión de ciclo de vida de snapshots (SLM) para administrar backups o si no has configurado Elasticsearch para tener réplicas.
Ventajas y desventajas
| Ventajas (+) | Desventajas (-) |
|
|
RAID 1
Rendimiento y capacidad
La creación de reflejos se representa en RAID con el número 1. La creación de reflejos es el proceso de escribir los mismos datos en otro disco. Esto crea de hecho una copia de los datos. Si bien los datos se escriben en ambos discos, la mayoría de las implementaciones de RAID no usan los dos discos para leer. Por lo tanto, el rendimiento de lectura y escritura se reduce efectivamente a la mitad. Como los mismos datos se escriben en ambos discos, también pierdes la mitad de la capacidad.
Recuperación
RAID 1 está hecho para abarcar solo dos discos. Por lo tanto, si un disco falla, los datos aún se conservan en el otro. Esto crea una alta redundancia de datos a expensas del rendimiento y la capacidad. Cuando falla uno de los discos, simplemente lo reemplazas y los datos se copian al disco nuevo.
Advertencias
En la mayoría de los casos, RAID 1 se empareja con RAID 0 dado que RAID 1 solo soporta dos discos. Esto significa que emparejarías varios volúmenes RAID 1 con un RAID 0 fragmentado. Esto se denomina RAID 10 y se usa cuando tienes cuatro o más discos.
Esto significa que tienes algunos de los beneficios de rendimiento de RAID 0 emparejados con la redundancia de RAID 1. El rendimiento de RAID 0 depende de la cantidad de discos en la matriz. El rendimiento de RAID 10 es Nx/2.
Ventajas y desventajas
| Ventajas (+) | Desventajas (-) |
|
|
RAID 5, 6
Rendimiento y capacidad
La paridad se representa en RAID con varios números: 2, 3, 4, 5, 6. Nos enfocaremos en 5 y 6, ya que 2, 4 y 3 generalmente se reemplazan con otros RAID. La paridad es una forma de que las computadoras corrijan o calculen datos faltantes debido a una falla del disco. La paridad agrega protección de datos a la realización de la fragmentación. La recuperación de datos tiene un costo. RAID 5 usa la capacidad de un disco para paridad, y RAID 6 usa la de dos discos.
Recuperación
Otros puntos para tener en cuenta con RAID 5 y 6 son los tiempos de reconstrucción de la recuperación. Una reconstrucción sucede cuando un disco nuevo se agrega a la matriz para reemplazar un disco anterior en ella. En el caso de medios giratorios, agrega más discos en lugar de más capacidad de disco. Más discos aumentarán los tiempos de lectura y escritura, y los de reconstrucción. En el caso de los SSD, deberás ver si los discos de mayor capacidad también tienen rendimientos de lectura y escritura más veloces. Muchos discos SSD de mayor capacidad tienen un mayor rendimiento de lectura y escritura. Si este es el caso, los discos de mayor capacidad ayudarán con el rendimiento de lectura y escritura. RAID 5 puede sufrir una falla de disco antes de perder datos de la matriz. RAID 6 puede sufrir dos fallas de disco.
Advertencias
Si bien RAID 5 y 6 pueden soportar una falla de disco, esto tiene consecuencias. En el caso de RAID 5, esto significa que eres efectivamente tan frágil como RAID 0 hasta que se agregue un disco nuevo. De hecho, si falla otro disco, se perderán todos los datos de la matriz y se deberán recuperar de otros shards o de una snapshot. Es por esto que muchos recomiendan ejecutar RAID 6 ya que los batches de discos pueden fallar casi al mismo tiempo. Como mencionamos al inicio, comprender la tolerancia de tu proyecto al rendimiento y la integridad de datos es clave para decidir entre estas dos opciones.
Perder un disco también afectará en gran medida el rendimiento tanto de RAID 5 como de RAID 6 debido a que la matriz deberá usar la paridad para recalcular los datos que se leen de los discos.
Ventajas y desventajas
| Ventajas (+) | Desventajas (-) |
|
|
Varias rutas de datos (MDP) en Elasticsearch
Elasticsearch tiene una configuración llamada path.data, que se usa para configurar las ubicaciones del sistema de archivos de los archivos de datos de Elasticsearch. Cuando se especifica una lista para path.data, Elasticsearch usará varias ubicaciones para almacenar los archivos de datos. Por ejemplo, si tu elasticsearch.yml contuviera lo siguiente:
path.data: [ /mnt/path1, /mnt/path2, /mnt/path3 ]
Entonces Elasticsearch escribiría en varias ubicaciones del sistema de archivos. Cada una de estas rutas podría ser un disco distinto.
Definir varias rutas de datos permite a un usuario configurar Elasticsearch para trabajar con varios almacenes de datos.
Rendimiento y capacidad
Elasticsearch divide los datos por shards, y los shards se escriben en la ruta de datos con más espacio libre. Si un shard recibe la mayoría de las escrituras, tu rendimiento se limita a la velocidad de una ruta de datos. Sin embargo, si tus datos se escriben con una distribución uniforme en las rutas de datos, entonces obtendrás la velocidad de escritura de todos los discos que se usan. Elasticsearch no garantiza que las escrituras abarquen muchas rutas de datos, así que el rendimiento es variable e inconsistente.
MDP no incluye la creación de reflejos ni paridad de datos. Esto significa que toda la capacidad de los discos se puede usar para alojar datos, excepto en el caso de alcanzar una marca de agua, lo cual se explica más en la sección de ventajas y desventajas. Para usar la capacidad total de los discos necesitarás como mínimo la misma cantidad de shards que de rutas de datos.
Cuando agregas una ruta de datos nueva a un nodo que ya tiene datos en otras rutas, esto puede llevar a convertir el disco nuevo en un punto caliente. Como Elasticsearch no equilibrará los shards entre las rutas de datos, todos los shards nuevos se enviarán a la ruta nueva debido a que tiene más espacio libre. Como Elasticsearch solo lee las actualizaciones de elasticsearch.yml al iniciarse, agregar cualquier disco requerirá reiniciar el nodo por completo.
Recuperación
Los discos se dañarán. Cuando un dispositivo de almacenamiento que es parte de varias rutas de datos deja de funcionar, el nodo se volverá amarillo y no se podrá acceder a los datos ubicados en ese dispositivo. Sin embargo, Elasticsearch puede continuar escribiendo en esta ruta de datos con fallas que arroja IOExceptions. Para evitar que ocurra esto, es importante eliminar la ruta de datos problemática desde la configuración del nodo de Elasticsearch haciendo lo siguiente:
- Deshabilita la asignación de shards.
- Detén el nodo.
- Elimina la ruta de datos dañada desde la configuración de Elasticsearch.
- Reinicia el nodo.
- Vuelve a habilitar la asignación de shards.
Para evitar la pérdida de datos permanente, asegúrate de tener Elasticsearch configurado con la replicación habilitada, la opción predeterminada es una réplica por shard.
Elasticsearch volverá a equilibrará entonces los shards desde otros nodos. Elasticsearch no equilibra los shards entre rutas de datos, consulta la sección de advertencias para conocer más detalles. Si el cluster no tiene capacidad suficiente para volver a equilibrarse, el nodo permanecerá amarillo.
Para reemplazar un disco nuevo, asegúrate de desmontar el disco y desactivar cualquier grupo LVM. Esto ayuda a asegurar que el SO pueda manejar correctamente el disco nuevo. Una vez que el disco nuevo esté instalado, tendrás que agregar la ruta nuevamente en la configuración path.data de Elasticsearch. Después de reemplazar el disco con fallas, Elasticsearch comenzará a usar la ruta nueva.
Advertencias
Cuando un dispositivo especificado en una de las varias rutas de datos deja de funcionar, la ruta se ignora en la próxima asignación de shards. Sin embargo, las rondas siguientes volverán a considerar la ruta como elegible para asignaciones de shards. Esto puede llevar a errores IOException a menos que se sigan los pasos mencionados anteriormente.
Elasticsearch maneja las marcas de agua por nodo. Es importante tener esto en cuenta porque si una ruta de datos alcanza la marca de agua alta, el nodo completo la alcanzará. Esto sucederá incluso si otras rutas de datos tienen espacio libre suficiente. Significará que el nodo que alcance la marca de agua dejará de aceptar shards nuevos, sacará de forma activa los shards del nodo o pasará el nodo a un estado de solo lectura.
Tomemos, por ejemplo, un nodo con seis rutas de datos de 500 GB con una capacidad total de aproximadamente 3 TB. Es posible que una ruta de datos única alcance el 90 % de uso del disco. Esto haría que el nodo completo alcance la marca de agua de nivel de desbordamiento y colocaría el nodo en estado de solo lectura. Esto sucedería incluso con otros discos en el nodo con un uso inferior al 50 %.
Elasticsearch no maneja el equilibrio de shards en un solo nodo, es decir, no equilibrará shards entre rutas de datos. Así que si un usuario usa varias rutas de datos, Elasticsearch colocará shards en el disco con más espacio disponible en ese momento. Si un shard recibe más datos que otros y llena un disco, Elasticsearch no equilibrará los shards. Esto puede llevar a cierta distribución despareja de la carga de E/S si no lo tienes en cuenta. Además, agregar un disco nuevo a un nodo con datos en otras rutas puede llevar a una carga de E/S alta en la ruta nueva.
Ventajas y desventajas
| Ventajas (+) | Desventajas (-) |
|
|
Conclusión
Es emocionante llegar al punto en el que necesitas aumentar tus datos. Si bien hemos hablado sobre muchas opciones y herramientas en este blog, recuerda que no hay una solución “única” para diseñar la arquitectura de tu almacenamiento de datos para escalar.
Si aún tienes preguntas o inquietudes sobre cómo diseñar la arquitectura del almacenamiento de tu despliegue de Elasticsearch para escalar, puedes encontrarnos a nosotros y una comunidad de usuarios en continuo crecimiento esperando para ayudarte en nuestros foros de debate.
Mejor aún... si no tienes ganas de administrar todo esto tú mismo, te recordamos la novedad que mencionamos antes: Elastic Cloud administrará todo por ti. Crecer es tan fácil como agregar otro nodo. No necesitas desempaquetar nodos, colocarlos en un rack ni administrarlos. Y funciona donde (probablemente) ya estás: en Amazon Web Services, Google Cloud Platform y Microsoft Azure. ¿Por qué no probarlo de forma gratuita hoy?