Cloud-Server für Elasticsearch in Europa: EU-Such-Hosting
Elasticsearch ist das Rückgrat der Volltextsuche, Log-Analytik und Observability-Stacks in modernen Anwendungen. Für Unternehmen, die Daten über europäische Nutzer verarbeiten, hat der Standort des Such-Indexes direkte Auswirkungen auf die DSGVO-Compliance und Abfrage-Antwortzeiten.
Warum EU-Datenresidenz für Elasticsearch wichtig ist
Elasticsearch-Indizes enthalten haufig nutzergenerierte Inhalte, Verhaltens-Logs und Dokumentdaten, die mit einzelnen Identitaten verknupft sind - alles personenbezogene Daten gemas DSGVO. Hosting auf einem EU-Server eines EU-Unternehmens bedeutet, dass Ihr Such-Index die EU-Jurisdiktion nie verlasst.
Netzwerknahe ist auch für die Suche wichtig. Ein Elasticsearch-Cluster in Mitteleuropa antwortet auf Anfragen einer Berliner Anwendung in 2-5 ms. Derselbe Cluster in einem US-Rechenzentrum führt zu 80-120 ms pro Anfrage.
Mindestanforderungen für Elasticsearch
- Klein (Entwicklung/Logging, unter 50 GB Index) - 4 vCPU, 16 GB RAM, 200 GB NVMe SSD
- Mittel (Produktionssuche, 50-500 GB) - 8 vCPU, 32 GB RAM, 1 TB NVMe SSD
- Gros (Analytik, Multi-TB-Index) - 16+ vCPU, 64 GB RAM, 2+ TB NVMe SSD
Der JVM-Heap sollte auf 50% des verfugbaren RAMs gesetzt werden.
Empfohlene DCXV-Konfiguration
DCXV Cloud-Server bieten NVMe-Speicher mit konsistenten IOPS, der Elasticsearch-Segment-Merges im Zeitplan hält:
- 8 vCPU, 32 GB RAM, 1 TB NVMe - Produktions-Such-Cluster-Knoten
- 16 vCPU, 64 GB RAM, 2 TB NVMe - Log-Analytik oder Observability-Stack
Kontaktieren Sie sales@dcxv.com für Cluster-Topologie-Beratung.
Schnell-Setup-Befehle
# Elasticsearch 8.x auf Ubuntu 22.04 installieren
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
# JVM-Heap-Grosse - 50% des RAMs, max 31 GB
-Xms16g
-Xmx16g
# Swap deaktivieren
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
Die vier Zahlen, die über die Verfügbarkeit entscheiden
RAM und Platte sind der einfache Teil. Diese Einstellungen legen einen Cluster lahm, und drei der vier sind so unerwartet, dass mehr Hardware sie verschlimmert statt verbessert:
| Einstellung | Die Regel | Warum | Wie es aussieht, wenn es schiefgeht |
|---|---|---|---|
| Heap-Größe | Die Hälfte des RAM, und nie über 31 GB | Über ~32 GB verliert die JVM komprimierte Objektzeiger | Ein 64-GB-Heap adressiert weniger als ein 31-GB-Heap |
| Shards pro Knoten | Unter 20 pro GB Heap | Jeder Shard kostet Heap, ob abgefragt oder nicht | Träger Cluster-Status, dann fallen Knoten aus |
| Shard-Größe | Je 10-50 GB | Kleinere verschwenden Overhead, größere lassen sich nicht neu verteilen | Recovery nach einem Neustart dauert Stunden |
| Swap | Aus, mit gesperrtem Speicher | Ein ausgelagerter JVM-Heap blockiert die Garbage Collection | Zufällige Pausen von Sekunden ohne echte Last |
Woran die meisten scheitern, ist die Shard-Anzahl, denn der Reflex nach einem langsamen Cluster ist, Knoten hinzuzufügen und Indizes weiter zu teilen. Das gibt noch mehr Heap für Verwaltung aus und verschlimmert das Problem. Zählen Sie erst Ihre Shards: ein Index pro Tag über ein Jahr sind 365 Shards, wo ein monatlicher Index 12 gehabt hätte.
Erwartete Leistungswerte
Auf einem 8 vCPU / 32 GB RAM / NVMe-Knoten mit Elasticsearch 8.x:
- Indexierungs-Durchsatz (Bulk-API) - 15.000-30.000 Docs/s
- Suchanfragen pro Sekunde - 500-1.500 QPS
- P99-Abfrage-Latenz (warmer Cache) - unter 10 ms
Das sind Erwartungen für Hardware dieser Klasse, keine Messungen aus unserem Labor. Nehmen Sie sie als Ausgangspunkt für die Dimensionierung und messen Sie Ihre eigene Last: die echten Zahlen hängen von Ihren Daten, Ihren Abfragen und Ihrem Tuning weit mehr ab als vom Anbieter.
Fazit
Elasticsearch auf einem EU-Cloud-Server hält Ihren Such-Index unter EU-Gerichtsbarkeit und liefert die niedrige Latenz und den hohen Durchsatz, den Ihre Anwendung benötigt.
