Categoría: Bases de datos
Elasticsearch y OpenSearch gestionados: búsqueda y logs sin caídas por disco o memoria
Vuestro clúster de búsqueda o de registros con la memoria, los shards y el disco bajo control, copias que restauran y versiones al día, en vuestra cuenta.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
- Licencia
- OpenSearch: Apache 2.0. Elasticsearch: AGPLv3, Elastic License 2.0 o SSPL, a elegir
En resumen
Elasticsearch y OpenSearch son motores de búsqueda y análisis que indexan documentos y registros para consultarlos en milisegundos. Gestionarlos es evitar que el clúster se ponga en rojo por falta de disco o de memoria. Ajustamos memoria y shards, automatizamos el ciclo de vida de los índices, hacemos snapshots que restauramos en pruebas y planificamos actualizaciones, siempre en vuestra cuenta.
¿Qué nos encargamos de mantener?
Un clúster de búsqueda o de registros puede ir bien meses y ponerse en rojo una mañana porque un nodo pasó la marca de agua del disco o la JVM se quedó sin memoria. Nuestro trabajo es que el crecimiento esté previsto y que cada índice tenga su ciclo de vida desde el primer día.
Nodos y roles
Maestros elegibles, nodos de datos y, si hace falta, coordinadores, repartidos en máquinas distintas.
Memoria
Heap de la JVM ajustado y memoria libre para la caché del sistema de archivos.
Shards
Tamaño y número de shards por índice según el volumen y las consultas.
Ciclo de vida
ILM o ISM para rotar, mover a nodos más baratos y borrar lo que ya no se consulta.
Alertas
Disco, memoria, estado del clúster, rechazos de escritura y consultas lentas.
Seguridad
TLS, roles por aplicación y nada expuesto a internet.
¿Qué arquitectura recomendamos?
Para producción, tres nodos maestros elegibles en máquinas distintas, para que el clúster mantenga el quórum si cae uno, y nodos de datos según el volumen. En clústeres pequeños los tres nodos hacen ambos papeles. Con registros que se consultan sobre todo los últimos días, separamos nodos calientes con disco rápido y templados con más capacidad, y el ciclo de vida mueve los índices de unos a otros.
| Situación | Lo que montamos | Por qué |
|---|---|---|
| Búsqueda de una aplicación | Tres nodos con todos los roles y una réplica por índice | Sencillo y aguanta la caída de un nodo |
| Registros con mucho volumen | Nodos calientes y templados con ILM o ISM | El disco rápido solo para lo que se consulta a diario |
| Vuestra nube tiene el servicio gestionado | Amazon OpenSearch Service, Elastic Cloud o el de DigitalOcean u OVHcloud | Menos mantenimiento; nosotros ajustamos shards, ciclo de vida y alertas |
Como referencia, apuntamos a shards de unas decenas de gigabytes y evitamos miles de shards pequeños: cada uno consume memoria aunque nadie lo consulte.
¿Qué problemas encontramos más a menudo?
- Disco por encima de las marcas de agua: el clúster deja de asignar shards y termina con los índices en solo lectura.
- Heap mal puesto: demasiado pequeño y la JVM pausa sin parar; demasiado grande y no queda memoria para la caché.
- Demasiados shards: un índice diario con cinco shards por costumbre, multiplicado por meses de retención.
- Sin ciclo de vida: los registros de hace dos años ocupan el mismo disco caro que los de ayer.
- Snapshots sin restaurar: configurados una vez y nunca probados.
- Clúster abierto a internet: sin seguridad activada, una de las fugas de datos más repetidas.
¿Cómo probamos que la copia funciona?
Configuramos un repositorio de snapshots en S3, o en un almacenamiento compatible de otra cuenta o proveedor, y una política que los hace a diario y borra los antiguos. Cada cierto tiempo restauramos índices en un clúster de prueba, comprobamos que las consultas devuelven lo esperado y apuntamos cuánto tarda. Los mapeos, plantillas y políticas están en el repositorio, así que un clúster nuevo se reconstruye desde código y se rellena con el último snapshot.
¿Cómo hacemos una actualización de versión?
Revisamos las notas de la versión, las API obsoletas que usan vuestros clientes y la compatibilidad de los plugins. Ensayamos con una copia y después actualizamos nodo a nodo: desactivamos la reasignación de shards, actualizamos, esperamos a que el clúster vuelva a verde y pasamos al siguiente. Entre versiones mayores comprobamos antes que los índices antiguos se pueden leer o los reindexamos.
¿Cómo migramos de Elasticsearch a OpenSearch, o al revés?
Montamos el clúster de destino en paralelo, reindexamos desde el antiguo o volvemos a ingerir los datos, y cambiamos la aplicación cuando las consultas dan los mismos resultados. Revisamos clientes, plugins y paneles, porque Kibana y OpenSearch Dashboards ya no son intercambiables. Si el motivo es el coste del servicio gestionado, lo comparamos con vuestras facturas en migraciones y costes cloud.
¿Cómo es el soporte día a día?
Las métricas del clúster van a Prometheus y Grafana, como contamos en monitorización con Grafana y Prometheus. La vigilancia automática es continua; la respuesta humana, el siguiente día hábil en horario laboral, dentro del SRE como servicio. Cada mes recibís un informe con estado, crecimiento del disco, última restauración y cambios.
- IngestaAplicación, Logstash o agentes
- Nodos coordinadoresOpcionales, para consultas pesadas
- Nodos de datosCaliente y templado
- Maestros elegiblesTres, para el quórum
- SnapshotsS3 o compatible, fuera del clúster
¿Dónde lo montamos?
En vuestra cuenta, en el proveedor que ya uséis o en el que mejor encaje. Si los datos tienen que quedarse en la UE, Hetzner y OVHcloud son las opciones europeas.
Proveedores en los que lo montamos
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Servidores dedicados o cloud con Elasticsearch u OpenSearch, discos NVMe locales y snapshots en Object Storage. | Sin servicio gestionado: los nodos, las copias y las actualizaciones las ponemos nosotros. Mucho disco por poco coste. |
| AWS | Amazon OpenSearch Service, o Elastic Cloud en AWS; si no encajan, EC2 o EKS con el operador correspondiente. | En Amazon OpenSearch Service revisamos tipos de instancia, shards, ISM y snapshots manuales además de los automáticos. |
| Google Cloud | Elastic Cloud en Google Cloud, o Compute Engine y GKE con Elasticsearch u OpenSearch. | Google Cloud no tiene un servicio propio de Elasticsearch u OpenSearch. |
| Azure | Elastic Cloud integrado en Azure, o máquinas virtuales y AKS con Elasticsearch u OpenSearch. | Azure no tiene un OpenSearch gestionado propio. |
| DigitalOcean | OpenSearch gestionado de DigitalOcean, o Droplets con el clúster montado por nosotros. | |
| OVH | OpenSearch gestionado de Public Cloud Databases de OVHcloud, o instancias propias. | |
| Servidor propio | Elasticsearch u OpenSearch en vuestros servidores, con snapshots a un almacenamiento S3 externo. | Tres nodos en una sola máquina física no aguantan su caída: el quórum necesita máquinas distintas. |
Qué incluye
- Clúster con tres nodos maestros elegibles y nodos de datos dimensionados para vuestro volumen.
- Memoria de la JVM ajustada y margen para la caché del sistema de archivos.
- Shards y réplicas por índice calculados según el tamaño y las consultas, no por defecto.
- Ciclo de vida de índices con ILM (Elasticsearch) o ISM (OpenSearch): rotación, niveles caliente y templado, y borrado.
- Snapshots a S3 o a un almacenamiento compatible, con una restauración de prueba documentada.
- Alertas de disco antes de las marcas de agua, memoria, estado del clúster y consultas lentas.
- TLS, usuarios y roles por aplicación, y el clúster sin acceso desde internet.
- Actualizaciones y migración entre Elasticsearch y OpenSearch ensayadas antes con una copia.
Preguntas frecuentes
¿Elasticsearch u OpenSearch?
Si ya usáis Elasticsearch con funciones propias de Elastic, como algunas de seguridad o de aprendizaje automático, seguir en Elasticsearch suele ser lo razonable. Si queréis una licencia Apache 2.0 sin matices o vuestra nube ofrece OpenSearch gestionado, OpenSearch es buena opción. Para registros y búsqueda normales, los dos funcionan bien.
¿Podemos migrar de Elasticsearch a OpenSearch?
Sí, pero no siempre restaurando un snapshot: depende de la versión de origen. Desde versiones antiguas, un snapshot puede servir; desde las recientes, lo habitual es reindexar desde el clúster antiguo o volver a ingerir los datos. Revisamos antes plugins, mapeos y clientes, porque las API han ido divergiendo.
¿Qué pasa con la licencia de Elasticsearch?
Desde 2024 Elasticsearch puede usarse bajo AGPLv3, además de la Elastic License 2.0 y la SSPL. Para usarlo en vuestra propia empresa no suele haber problema. Lo operamos siempre en vuestra cuenta y para vuestro uso, nunca como un servicio compartido entre clientes.
¿Por qué se pone el clúster en rojo?
Casi siempre por disco o por memoria. Al pasar las marcas de agua de disco, el clúster deja de asignar shards y acaba bloqueando la escritura; con poca memoria, las pausas de la JVM tiran nodos. Las dos cosas se ven venir con alertas y retención bien puesta.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Documentación oficial consultada
Los datos técnicos de esta página se basan en:
Revisado el