Hot-Warm-Cold-Architektur fuer wachsende Datenmengen

1. Warum eine Hot-Warm-Cold-Architektur ueberhaupt noetig ist

Log- und Zeitreihendaten haben ein typisches Zugriffsmuster: die letzten Stunden oder Tage werden intensiv abgefragt, aeltere Daten dagegen selten bis gar nicht, muessen aber aus Compliance- oder Analysegruenden trotzdem vorgehalten werden. Ein Cluster, der alle Daten gleich behandelt und auf identischer, durchgehend teurer SSD-Hardware speichert, verschwendet Budget fuer Performance, die fuer aeltere Daten niemand mehr braucht. Genau dieses Problem loest eine Hot-Warm-Cold-Architektur.

Das Grundprinzip einer Hot-Warm-Cold-Architektur: Data-Nodes werden in mehrere Tiers unterteilt, jeweils mit unterschiedlicher Hardware-Ausstattung, und Indizes wandern im Laufe ihres Lebenszyklus automatisch vom teuren, schnellen Hot-Tier ueber guenstigere Zwischenstufen bis hin zu sehr kostenguenstigem Cold- oder Frozen-Storage. Diese Migration erfolgt nicht manuell, sondern ueber Index-Lifecycle-Management-Policies, die Zeit- oder Groessenkriterien in konkrete Aktionen uebersetzen.

Fuer Unternehmen mit wachsenden Logvolumen, etwa aus Anwendungsmonitoring, Security-Auditing oder IoT-Sensordaten, ist eine Hot-Warm-Cold-Architektur meist kein optionales Nice-to-have, sondern eine wirtschaftliche Notwendigkeit: ohne Tiering waechst die Infrastrukturrechnung linear mit dem Datenvolumen, mit Tiering deutlich langsamer, weil nur ein kleiner, aktueller Anteil der Daten auf teurer Hardware liegt.

2. Der Hot-Tier: schnelle Hardware fuer frische Daten

Der Hot-Tier hostet die aktuell beschriebenen Indizes und traegt die gesamte Schreiblast einer Hot-Warm-Cold-Architektur. Diese Nodes brauchen die schnellste verfuegbare Hardware: NVMe-SSDs fuer hohen Indexierungsdurchsatz, ausreichend CPU-Kerne fuer parallele Segment-Merges und genug RAM fuer Heap und Dateicache gleichermassen. Da hier sowohl geschrieben als auch am haeufigsten gelesen wird, ist der Hot-Tier meist die teuerste Komponente pro Gigabyte im gesamten Cluster.

Die Verweildauer eines Index im Hot-Tier haengt vom Anwendungsfall ab, liegt bei Log-Daten aber typischerweise zwischen wenigen Stunden und wenigen Tagen. Waehrend dieser Phase profitiert ein Index maximal von der schnellen Hardware, sowohl fuer eingehende Schreiblast als auch fuer die Dashboards und Alerts, die meist auf den aktuellsten Daten operieren. Eine gut dimensionierte Hot-Warm-Cold-Architektur haelt den Hot-Tier bewusst klein, weil jeder zusaetzliche Tag auf teurer Hardware direkt die Kosten erhoeht.

3. Der Warm-Tier: guenstigere Hardware fuer seltenere Zugriffe

Der Warm-Tier nimmt Indizes auf, die nicht mehr beschrieben werden, aber noch regelmaessig fuer Suchanfragen und Analysen gebraucht werden, etwa fuer Wochenberichte oder Trendanalysen ueber die letzten dreissig Tage. Diese Nodes koennen mit langsameren, aber deutlich guenstigeren SSDs oder sogar leistungsfaehigen HDDs ausgestattet sein, da keine Schreiblast mehr anfaellt und Leselatenzen weniger kritisch sind als im Hot-Tier.

Ein wichtiger Bestandteil beim Uebergang in den Warm-Tier innerhalb einer Hot-Warm-Cold-Architektur ist das sogenannte Force-Merge: abgeschlossene, nicht mehr beschriebene Indizes werden auf ein einzelnes Lucene-Segment pro Shard komprimiert, was Speicherplatz spart und Leseoperationen beschleunigt, da weniger Segmente durchsucht werden muessen. Auch die Replica-Anzahl wird im Warm-Tier haeufig reduziert, weil das Ausfallrisiko fuer historische, unveraenderliche Daten anders bewertet werden kann als fuer aktiv beschriebene Hot-Daten.

4. Cold- und Frozen-Tier: Langzeitarchivierung

Der Cold-Tier speichert Daten, die selten, aber gelegentlich noch abgefragt werden, etwa fuer Compliance-Audits oder juristische Anfragen mit langem Aufbewahrungszeitraum. Hier kommt oft besonders komprimierter, guenstiger Storage zum Einsatz, teilweise mit reduzierter Replica-Anzahl oder sogar Searchable-Snapshots, bei denen die eigentlichen Daten in einem Object Store wie S3 liegen und nur bei Bedarf temporaer in den Cluster geladen werden.

Der Frozen-Tier ist die letzte Stufe einer vollstaendigen Hot-Warm-Cold-Architektur: Daten liegen fast vollstaendig im Object Storage, lokale Node-Ressourcen werden nur minimal fuer Caching genutzt. Suchanfragen gegen Frozen-Daten sind spuerbar langsamer, weil Daten erst vom Object Store nachgeladen werden muessen, aber die Speicherkosten pro Gigabyte sind ein Bruchteil dessen, was derselbe Datenbestand im Hot-Tier kosten wuerde. Fuer Daten, die praktisch nie, aber theoretisch doch einmal abgefragt werden muessen, ist das ein sinnvoller Kompromiss.

5. Node-Attribute und Data-Tier-Rollen konfigurieren

Technisch wird eine Hot-Warm-Cold-Architektur ueber Node-Rollen abgebildet, die seit neueren Elasticsearch-Versionen direkt als data_hot, data_warm, data_cold und data_frozen in node.roles gesetzt werden koennen. In aelteren Setups oder fuer feinere Kontrolle lassen sich zusaetzlich benutzerdefinierte Node-Attribute vergeben, etwa node.attr.data_tier: hot, kombiniert mit Shard-Allocation-Filtering, um Indizes gezielt auf bestimmte Node-Gruppen zu lenken.

Wichtig bei der Konfiguration: jeder Tier braucht mindestens einen, besser mehrere Nodes fuer Redundanz, und die Netzwerktopologie sollte beruecksichtigen, dass Daten beim Tier-Wechsel physisch zwischen Nodes kopiert werden, was bei grossen Indizes Zeit und Netzwerkbandbreite braucht. Eine Hot-Warm-Cold-Architektur mit zu wenigen Warm-Nodes fuer das anfallende Datenvolumen fuehrt zu Engpaessen bei der Migration, selbst wenn Hot- und Cold-Tier ausreichend dimensioniert sind.

# elasticsearch.yml - warm tier data node
node.name: warm-node-01
node.roles: [ data_warm, data_cold ]

# Slower, cheaper storage class is expected here, not NVMe
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

discovery.seed_hosts:
  - master-node-01:9300
  - master-node-02:9300
  - master-node-03:9300

6. ILM-Policies: den Lebenszyklus automatisieren

Index Lifecycle Management ist das Werkzeug, das eine Hot-Warm-Cold-Architektur erst praktikabel macht. Eine ILM-Policy definiert Phasen, hot, warm, cold, frozen und delete, jeweils mit Bedingungen, wann ein Index in die naechste Phase wechselt, und Aktionen, was in dieser Phase passieren soll, etwa Rollover, Force-Merge, Shrink oder das Verschieben auf andere Node-Attribute. Einmal definiert, laeuft die gesamte Migration automatisch im Hintergrund, ohne manuelles Eingreifen.

Die Policy wird einem Index-Template zugewiesen, sodass jeder neu erzeugte Index einer Zeitreihe automatisch derselben Hot-Warm-Cold-Architektur folgt. Das ist besonders wichtig fuer Log-Pipelines mit taeglich oder stuendlich neuen Indizes: ohne zentrale Policy muesste jeder einzelne Index manuell verwaltet werden, was bei hunderten oder tausenden Indizes praktisch unmoeglich ist.

PUT _ilm/policy/logs-hot-warm-cold-policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": { "max_primary_shard_size": "40gb", "max_age": "1d" },
          "set_priority": { "priority": 100 }
        }
      },
      "warm": {
        "min_age": "3d",
        "actions": {
          "shrink": { "number_of_shards": 1 },
          "forcemerge": { "max_num_segments": 1 },
          "allocate": { "number_of_replicas": 1, "require": { "data_tier": "warm" } },
          "set_priority": { "priority": 50 }
        }
      },
      "cold": {
        "min_age": "30d",
        "actions": {
          "allocate": { "number_of_replicas": 0, "require": { "data_tier": "cold" } },
          "set_priority": { "priority": 0 }
        }
      },
      "delete": {
        "min_age": "365d",
        "actions": { "delete": {} }
      }
    }
  }
}

7. Rollover-Kriterien richtig waehlen

Die Rollover-Aktion in der Hot-Phase ist die Basis jeder zeitbasierten Hot-Warm-Cold-Architektur: statt einen einzelnen, unbegrenzt wachsenden Index zu beschreiben, erzeugt Rollover automatisch einen neuen Index, sobald definierte Kriterien erreicht sind. Die gaengigsten Kriterien sind max_primary_shard_size fuer Shard-Sizing und max_age fuer eine zeitliche Obergrenze, wobei das zuerst erreichte Kriterium den Rollover ausloest.

Ein haeufiger Fehler ist, nur auf max_age zu setzen, etwa taeglicher Rollover unabhaengig vom tatsaechlichen Datenvolumen. An Tagen mit ungewoehnlich hohem Traffic entstehen dann uebergrosse Shards, an ruhigen Tagen unnoetig kleine. Die Kombination aus Groessen- und Zeitkriterium macht eine Hot-Warm-Cold-Architektur robust gegenueber schwankendem Datenvolumen, ohne dass Shard-Groessen manuell nachjustiert werden muessen.

GET logs-2026.07.20-000003/_ilm/explain

// Shows exactly which phase and action an index is currently in,
// invaluable for debugging why a migration has not happened yet
{
  "indices": {
    "logs-2026.07.20-000003": {
      "index": "logs-2026.07.20-000003",
      "phase": "warm",
      "action": "forcemerge",
      "step": "wait_for_forcemerge_step",
      "age": "3.2d"
    }
  }
}

8. Kostenersparnis konkret berechnen

Der wirtschaftliche Nutzen einer Hot-Warm-Cold-Architektur laesst sich grob abschaetzen, indem man die Speicherkosten pro Gigabyte auf jedem Tier gegen die Verteilung des Datenvolumens ueber die Zeit rechnet. Ein typisches Log-Setup mit sieben Tagen im Hot-Tier, dreiundzwanzig Tagen im Warm-Tier und weiteren dreihundertfuenfunddreissig Tagen im Cold-Tier verschiebt den grossen Anteil des Gesamtvolumens auf die guenstigste Stufe, waehrend nur ein kleiner, aktueller Anteil die teure Hot-Hardware belegt.

Bei Cloud-Infrastruktur laesst sich dieser Effekt besonders klar messen: NVMe-optimierte Instanztypen kosten pro Gigabyte deutlich mehr als HDD-basierte oder Object-Storage-gestuetzte Alternativen. Fuer ein Datenvolumen, das ueber ein Jahr kontinuierlich anwaechst, kann eine konsequent umgesetzte Hot-Warm-Cold-Architektur die Gesamtspeicherkosten um einen erheblichen Anteil senken, verglichen mit einem einheitlichen Cluster auf durchgehend teurer Hardware.

GET _cat/allocation?v&h=node,disk.indices,disk.used,disk.total,disk.percent

// Compare disk usage across tiers to verify the cost distribution
// matches expectations, most volume should sit on warm and cold nodes
node           disk.indices disk.used disk.total disk.percent
hot-node-01    180gb        210gb     500gb      42
warm-node-01   1.2tb        1.3tb     2tb        65
cold-node-01   4.8tb        4.9tb     8tb        61

9. Typische Fallstricke bei der Umsetzung

Ein haeufiger Fehler bei der Einfuehrung einer Hot-Warm-Cold-Architektur ist, die Migration zwischen Tiers zu unterschaetzen: das Kopieren grosser Shards vom Hot- zum Warm-Tier braucht Netzwerkbandbreite und Zeit, was bei zu knapp getakteten Rollover-Intervallen zu Staus fuehrt, wenn mehrere Indizes gleichzeitig migriert werden sollen. Eine realistische Kapazitaetsplanung fuer die Migrationsbandbreite gehoert deshalb von Anfang an zum Design.

Ein zweiter Fallstrick ist eine zu aggressive Verkleinerung der Replica-Anzahl in spaeteren Tiers: null Replicas im Cold-Tier bedeuten, dass ein einzelner Node-Ausfall zu echtem Datenverlust fuehrt, nicht nur zu temporaerer Nichtverfuegbarkeit. Fuer Daten mit Compliance-Anforderungen sollte diese Entscheidung bewusst getroffen und idealerweise durch Snapshots in einem separaten Object Store abgesichert werden, statt sich allein auf die im Cluster gehaltenen Replicas zu verlassen.

// Register a snapshot repository as a safety net for zero-replica cold data
PUT _snapshot/cold-tier-backup
{
  "type": "s3",
  "settings": {
    "bucket": "es-cold-tier-snapshots",
    "region": "eu-central-1"
  }
}

// Automate daily snapshots so zero replicas do not equal zero durability
PUT _slm/policy/cold-daily-snapshots
{
  "schedule": "0 30 1 * * ?",
  "name": "<cold-snap-{now/d}>",
  "repository": "cold-tier-backup",
  "config": { "indices": ["*-cold-*"] },
  "retention": { "expire_after": "90d", "min_count": 5, "max_count": 30 }
}

10. Zusammenfassung

Eine Hot-Warm-Cold-Architektur passt Hardware-Kosten an das tatsaechliche Zugriffsmuster von Zeitreihen- und Log-Daten an: schnelle, teure Nodes fuer frische, aktiv beschriebene Daten, guenstigere Nodes fuer seltene Zugriffe, und minimale Object-Storage-Kosten fuer Daten, die praktisch nie, aber theoretisch doch noch gebraucht werden. ILM-Policies automatisieren die gesamte Migration ueber Rollover, Shrink, Force-Merge und Allocation-Umzuege, ohne manuelles Eingreifen bei jedem einzelnen Index.

Der groesste Hebel liegt in der Kombination aus realistischen Rollover-Kriterien, ausreichend dimensionierten Zwischen-Tiers fuer die Migration und einer bewussten Entscheidung ueber Replica-Reduzierung in spaeteren Phasen. Wer diese drei Aspekte von Anfang an mitplant, erreicht mit einer Hot-Warm-Cold-Architektur spuerbare Kosteneinsparungen, ohne die Suchbarkeit historischer Daten aufzugeben.

11. FAQ: Hot-Warm-Cold-Architektur in Elasticsearch