Categoria: Bases de dades
Elasticsearch i OpenSearch gestionats: cerca i logs sense caigudes per disc o memòria
El vostre clúster de cerca o de registres amb la memòria, els shards i el disc sota control, còpies que es restauren i versions al dia, al vostre compte.
- On es munta
- Al vostre compte, a nom vostre
- Còpies
- Amb restauració provada
- Actualitzacions
- Planificades i documentades
- Llicència
- OpenSearch: Apache 2.0. Elasticsearch: AGPLv3, Elastic License 2.0 o SSPL, a triar
En resum
Elasticsearch i OpenSearch són motors de cerca i anàlisi que indexen documents i registres per a consultar-los en mil·lisegons. Gestionar-los és evitar que el clúster es pose en roig per falta de disc o de memòria. Ajustem memòria i shards, automatitzem el cicle de vida dels índexs, fem snapshots que restaurem en proves i planifiquem actualitzacions, sempre al vostre compte.
De què ens encarreguem?
Un clúster de cerca o de registres pot anar bé durant mesos i posar-se en roig un matí perquè un node va passar la marca d’aigua del disc o la JVM es va quedar sense memòria. La nostra feina és que el creixement estiga previst i que cada índex tinga el seu cicle de vida des del primer dia.
Nodes i rols
Mestres elegibles, nodes de dades i, si cal, coordinadors, repartits en màquines diferents.
Memòria
Heap de la JVM ajustat i memòria lliure per a la memòria cau del sistema d’arxius.
Shards
Mida i nombre de shards per índex segons el volum i les consultes.
Cicle de vida
ILM o ISM per a rotar, moure a nodes més barats i esborrar el que ja no es consulta.
Alertes
Disc, memòria, estat del clúster, rebuigs d’escriptura i consultes lentes.
Seguretat
TLS, rols per aplicació i res exposat a internet.
Quina arquitectura recomanem?
Per a producció, tres nodes mestres elegibles en màquines diferents, perquè el clúster mantinga el quòrum si en cau un, i nodes de dades segons el volum. En clústers xicotets els tres nodes fan tots dos papers. Amb registres que es consulten sobretot els últims dies, separem nodes calents amb disc ràpid i temperats amb més capacitat, i el cicle de vida mou els índexs d’uns a altres.
| Situació | El que muntem | Per què |
|---|---|---|
| Cerca d’una aplicació | Tres nodes amb tots els rols i una rèplica per índex | Senzill i aguanta la caiguda d’un node |
| Registres amb molt de volum | Nodes calents i temperats amb ILM o ISM | El disc ràpid només per al que es consulta cada dia |
| El vostre núvol té el servei gestionat | Amazon OpenSearch Service, Elastic Cloud o el de DigitalOcean o OVHcloud | Menys manteniment; nosaltres ajustem shards, cicle de vida i alertes |
Com a referència, apuntem a shards d’unes desenes de gigabytes i evitem milers de shards xicotets: cadascun consumeix memòria encara que ningú no el consulte.
Quins problemes trobem més sovint?
- Disc per damunt de les marques d’aigua: el clúster deixa d’assignar shards i acaba amb els índexs en només lectura.
- Heap mal posat: massa xicotet i la JVM fa pauses sense parar; massa gran i no queda memòria per a la memòria cau.
- Massa shards: un índex diari amb cinc shards per costum, multiplicat per mesos de retenció.
- Sense cicle de vida: els registres de fa dos anys ocupen el mateix disc car que els d’ahir.
- Snapshots sense restaurar: configurats una vegada i mai provats.
- Clúster obert a internet: sense la seguretat activada, una de les fugues de dades més repetides.
Com provem que la còpia funciona?
Configurem un repositori de snapshots a S3, o en un emmagatzematge compatible d’un altre compte o proveïdor, i una política que els fa cada dia i esborra els antics. Cada cert temps restaurem índexs en un clúster de prova, comprovem que les consultes tornen el que s’espera i anotem quant tarda. Els mapatges, plantilles i polítiques són al repositori, així que un clúster nou es reconstrueix des del codi i s’omple amb l’últim snapshot.
Com fem una actualització de versió?
Revisem les notes de la versió, les API obsoletes que fan servir els vostres clients i la compatibilitat dels plugins. Assagem amb una còpia i després actualitzem node a node: desactivem la reassignació de shards, actualitzem, esperem que el clúster torne a verd i passem al següent. Entre versions majors comprovem abans que els índexs antics es poden llegir o els reindexem.
Com migrem d’Elasticsearch a OpenSearch, o a l’inrevés?
Muntem el clúster de destí en paral·lel, reindexem des de l’antic o tornem a ingerir les dades, i canviem l’aplicació quan les consultes donen els mateixos resultats. Revisem clients, plugins i panells, perquè Kibana i OpenSearch Dashboards ja no són intercanviables. Si el motiu és el cost del servei gestionat, el comparem amb les vostres factures en migracions i costos cloud.
Com és el suport dia a dia?
Les mètriques del clúster van a Prometheus i Grafana, com expliquem en monitoratge amb Grafana i Prometheus. La vigilància automàtica és contínua; la resposta humana, el següent dia feiner en horari laboral, dins de l’SRE com a servei. Cada mes rebeu un informe amb l’estat, el creixement del disc, l’última restauració i els canvis.
- IngestaAplicació, Logstash o agents
- Nodes coordinadorsOpcionals, per a consultes pesades
- Nodes de dadesCalent i temperat
- Mestres elegiblesTres, per al quòrum
- SnapshotsS3 o compatible, fora del clúster
On ho muntem?
Al vostre compte, al proveïdor que ja feu servir o al que encaixe millor. Si les dades s'han de quedar a la UE, Hetzner i OVHcloud són les opcions europees.
Proveïdors on ho muntem
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propi
| Proveïdor | Com ho muntem | A tindre en compte |
|---|---|---|
| Hetzner | Servidors dedicats o cloud amb Elasticsearch o OpenSearch, discos NVMe locals i snapshots en Object Storage. | Sense servei gestionat: els nodes, les còpies i les actualitzacions les posem nosaltres. Molt de disc per poc cost. |
| AWS | Amazon OpenSearch Service, o Elastic Cloud a AWS; si no encaixen, EC2 o EKS amb l'operador corresponent. | En Amazon OpenSearch Service revisem tipus d'instància, shards, ISM i snapshots manuals a més dels automàtics. |
| Google Cloud | Elastic Cloud a Google Cloud, o Compute Engine i GKE amb Elasticsearch o OpenSearch. | Google Cloud no té un servei propi d'Elasticsearch o OpenSearch. |
| Azure | Elastic Cloud integrat en Azure, o màquines virtuals i AKS amb Elasticsearch o OpenSearch. | Azure no té un OpenSearch gestionat propi. |
| DigitalOcean | OpenSearch gestionat de DigitalOcean, o Droplets amb el clúster muntat per nosaltres. | |
| OVH | OpenSearch gestionat de Public Cloud Databases d'OVHcloud, o instàncies pròpies. | |
| Servidor propi | Elasticsearch o OpenSearch en els vostres servidors, amb snapshots a un emmagatzematge S3 extern. | Tres nodes en una sola màquina física no aguanten la seua caiguda: el quòrum necessita màquines diferents. |
Què inclou
- Clúster amb tres nodes mestres elegibles i nodes de dades dimensionats per al vostre volum.
- Memòria de la JVM ajustada i marge per a la memòria cau del sistema d'arxius.
- Shards i rèpliques per índex calculats segons la mida i les consultes, no per defecte.
- Cicle de vida d'índexs amb ILM (Elasticsearch) o ISM (OpenSearch): rotació, nivells calent i temperat, i esborrat.
- Snapshots a S3 o a un emmagatzematge compatible, amb una restauració de prova documentada.
- Alertes de disc abans de les marques d'aigua, memòria, estat del clúster i consultes lentes.
- TLS, usuaris i rols per aplicació, i el clúster sense accés des d'internet.
- Actualitzacions i migració entre Elasticsearch i OpenSearch assajades abans amb una còpia.
Preguntes freqüents
Elasticsearch o OpenSearch?
Si ja feu servir Elasticsearch amb funcions pròpies d'Elastic, com algunes de seguretat o d'aprenentatge automàtic, continuar amb Elasticsearch sol ser el raonable. Si voleu una llicència Apache 2.0 sense matisos o el vostre núvol ofereix OpenSearch gestionat, OpenSearch és una bona opció. Per a registres i cerca normals, tots dos funcionen bé.
Podem migrar d'Elasticsearch a OpenSearch?
Sí, però no sempre restaurant un snapshot: depén de la versió d'origen. Des de versions antigues, un snapshot pot servir; des de les recents, l'habitual és reindexar des del clúster antic o tornar a ingerir les dades. Abans revisem plugins, mapatges i clients, perquè les API han anat divergint.
Què passa amb la llicència d'Elasticsearch?
Des de 2024 Elasticsearch es pot fer servir sota AGPLv3, a més de l'Elastic License 2.0 i la SSPL. Per a usar-lo en la vostra pròpia empresa no sol haver-hi problema. L'operem sempre al vostre compte i per al vostre ús, mai com un servei compartit entre clients.
Per què es posa el clúster en roig?
Quasi sempre per disc o per memòria. En passar les marques d'aigua de disc, el clúster deixa d'assignar shards i acaba bloquejant l'escriptura; amb poca memòria, les pauses de la JVM tomben nodes. Totes dues coses es veuen vindre amb alertes i una retenció ben posada.
Expliqueu-nos el vostre cas
En una trucada gratuïta de 20 minuts veiem on sou i per on començar. Sense compromís.
Documentació oficial consultada
Les dades tècniques d'aquesta pàgina es basen en:
Revisat el