Server cloud per Elasticsearch in Europa: hosting ricerca EU
Elasticsearch e la spina dorsale della ricerca full-text, dell'analisi dei log e degli stack di osservabilita nelle applicazioni moderne. Per le aziende che gestiscono dati sugli utenti europei, dove vive quell'indice di ricerca ha implicazioni dirette per la conformità al GDPR e i tempi di risposta alle query.
Perché la residenza dei dati in UE e importante per Elasticsearch
Gli indici Elasticsearch contengono spesso contenuti generati dagli utenti, log comportamentali e dati di documenti collegati a identità individuali - tutti dati personali ai sensi del GDPR. L'hosting su un server EU gestito da un'azienda europea significa che il tuo indice di ricerca non lascia mai la giurisdizione UE.
La vicinanza di rete e anche importante per la ricerca. Un cluster Elasticsearch nell'Europa centrale risponde alle query di un'applicazione berlinese in 2-5 ms. Lo stesso cluster in un data center statunitense aggiunge 80-120 ms per query.
Specifiche minime per Elasticsearch
- Piccolo (dev/logging, fino a 50 GB di indice) - 4 vCPU, 16 GB RAM, 200 GB NVMe SSD
- Medio (ricerca di produzione, 50-500 GB) - 8 vCPU, 32 GB RAM, 1 TB NVMe SSD
- Grande (analytics, indice multi-TB) - 16+ vCPU, 64 GB RAM, 2+ TB NVMe SSD
Configurazione DCXV raccomandata
I server cloud DCXV forniscono storage NVMe con IOPS consistenti:
- 8 vCPU, 32 GB RAM, 1 TB NVMe - nodo di cluster di ricerca di produzione
- 16 vCPU, 64 GB RAM, 2 TB NVMe - analytics dei log o stack di osservabilita
Contatta sales@dcxv.com per la configurazione del cluster.
Comandi di configurazione rapida
# Installare Elasticsearch 8.x su 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
# Dimensionamento heap JVM - 50% della RAM
-Xms16g
-Xmx16g
# Disabilitare 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
I quattro numeri che decidono se resta in piedi
RAM e disco sono la parte facile. Queste sono le impostazioni che mettono giù un cluster, e tre delle quattro sono abbastanza controintuitive perché più hardware le peggiori invece di migliorarle:
| Impostazione | La regola | Perché | Come si presenta il guasto |
|---|---|---|---|
| Dimensione heap | Metà della RAM, e mai oltre 31 GB | Oltre ~32 GB la JVM perde i puntatori compressi | Un heap da 64 GB indirizza meno di uno da 31 GB |
| Shard per nodo | Meno di 20 per GB di heap | Ogni shard costa heap, interrogato o no | Stato del cluster lento, poi nodi che cadono |
| Dimensione shard | 10-50 GB ciascuno | Più piccoli sprecano overhead, più grandi non si ribilanciano | Il recovery dopo un riavvio richiede ore |
| Swap | Disattivato, con memoria bloccata | Un heap JVM finito in swap blocca il garbage collector | Pause casuali di secondi senza carico reale |
Quello che frega è il numero di shard, perché l'istinto davanti a un cluster lento è aggiungere nodi e spezzare ancora gli indici. Così si spende ancora più heap in contabilità e il problema peggiora. Conta prima gli shard che hai: un indice al giorno per un anno fa 365 shard dove un indice mensile ne avrebbe avuti 12.
Prestazioni attese
Su un nodo 8 vCPU / 32 GB RAM / NVMe con Elasticsearch 8.x:
- Throughput di indicizzazione (API bulk) - 15.000-30.000 doc/s
- Query al secondo - 500-1.500 QPS
- Latenza P99 (query calda) - meno di 10 ms
Queste sono aspettative per hardware di questa classe, non misurazioni dal nostro laboratorio. Prendile come punto di partenza per il dimensionamento e misura il tuo carico: i numeri reali dipendono dai tuoi dati, dalle tue query e dal tuo tuning molto più che dal fornitore.
Conclusione
Elasticsearch su un server cloud EU mantiene il tuo indice di ricerca sotto la giurisdizione UE offrendo ricerca a bassa latenza e alto throughput.
