Servidor cloud para Elasticsearch en Europa: hosting de búsqueda EU
Elasticsearch es la columna vertebral de la búsqueda de texto completo, la analítica de logs y los stacks de observabilidad en las aplicaciones modernas. Para las empresas que manejan datos sobre usuarios europeos, donde vive ese índice de búsqueda tiene implicaciones directas para el cumplimiento del RGPD y los tiempos de respuesta de las consultas.
Por que la residencia de datos en la UE importa para Elasticsearch
Los indices de Elasticsearch suelen contener contenido generado por usuarios, logs de comportamiento y datos de documentos vinculados a identidades individuales - todos datos personales bajo el RGPD. El alojamiento en un servidor EU de una empresa europea significa que tu índice de búsqueda nunca sale de la jurisdicción de la UE.
La proximidad de red también importa para la búsqueda. Un cluster de Elasticsearch en Europa Central responde a las consultas de una aplicación en Berlin en 2-5 ms. El mismo cluster en un centro de datos de EE.UU. añade 80-120 ms por consulta.
Especificaciones minimas para Elasticsearch
- Pequeño (dev/logging, hasta 50 GB de índice) - 4 vCPU, 16 GB RAM, 200 GB NVMe SSD
- Mediano (búsqueda de producción, 50-500 GB) - 8 vCPU, 32 GB RAM, 1 TB NVMe SSD
- Grande (analítica, índice multi-TB) - 16+ vCPU, 64 GB RAM, 2+ TB NVMe SSD
Configuración recomendada de DCXV
Los servidores cloud de DCXV proporcionan almacenamiento NVMe con IOPS consistente:
- 8 vCPU, 32 GB RAM, 1 TB NVMe - nodo de cluster de búsqueda de producción
- 16 vCPU, 64 GB RAM, 2 TB NVMe - analítica de logs u observabilidad
Contacta sales@dcxv.com para la configuración del cluster.
Comandos de configuración rápida
# Instalar Elasticsearch 8.x en Ubuntu 22.04
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list
sudo apt update && sudo apt install -y elasticsearch
sudo systemctl start elasticsearch && sudo systemctl enable elasticsearch
# Tamaño del heap JVM - 50% de RAM
-Xms16g
-Xmx16g
# Deshabilitar swap
sudo swapoff -a
echo 'vm.swappiness=1' | sudo tee -a /etc/sysctl.conf
echo 'vm.max_map_count=262144' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
Los cuatro números que deciden si se mantiene en pie
La RAM y el disco son la parte fácil. Estos son los ajustes que tumban un clúster, y tres de los cuatro son lo bastante contraintuitivos como para que más hardware los empeore:
| Ajuste | La regla | Por qué | Qué aspecto tiene cuando falla |
|---|---|---|---|
| Tamaño del heap | La mitad de la RAM, y nunca por encima de 31 GB | Por encima de ~32 GB la JVM pierde los punteros comprimidos | Un heap de 64 GB direcciona menos que uno de 31 GB |
| Shards por nodo | Menos de 20 por GB de heap | Cada shard cuesta heap, se consulte o no | Estado del clúster lento, luego nodos que se caen |
| Tamaño del shard | 10-50 GB cada uno | Más pequeños desperdician overhead, más grandes no rebalancean | La recuperación tras un reinicio tarda horas |
| Swap | Desactivado, con la memoria bloqueada | Un heap de JVM en swap detiene la recolección de basura | Pausas aleatorias de segundos sin carga real |
Donde más gente tropieza es en el número de shards, porque el instinto ante un clúster lento es añadir nodos y dividir más los índices. Eso gasta aún más heap en contabilidad y empeora el problema. Cuente primero los shards que tiene: un índice por día durante un año son 365 shards donde un índice mensual habría tenido 12.
Rendimiento esperado
En un nodo 8 vCPU / 32 GB RAM / NVMe con Elasticsearch 8.x:
- Rendimiento de indexación (API bulk) - 15.000-30.000 docs/s
- Consultas por segundo - 500-1.500 QPS
- Latencia P99 (consulta caliente) - menos de 10 ms
Son expectativas para hardware de esta clase, no mediciones de nuestro propio laboratorio. Tómalas como punto de partida para dimensionar y mide tu propia carga: los números reales dependen de tus datos, tus consultas y tu ajuste mucho más que del proveedor.
Conclusión
Elasticsearch en un servidor cloud de la UE mantiene tu índice de búsqueda bajo jurisdicción EU y ofrece búsqueda de baja latencia y alto rendimiento.
