Cluster vs. Sentinel: wann welches Modell passt

1. Zwei verschiedene Probleme: High Availability vs. Sharding

Die Entscheidung zwischen Redis Sentinel und Redis Cluster wird häufig als reine Geschmacksfrage behandelt, dabei lösen beide Technologien grundsätzlich unterschiedliche Probleme. Sentinel adressiert ausschließlich Hochverfügbarkeit: Ein Master fällt aus, eine Replica wird automatisch befördert, die Anwendung bleibt verfügbar. Die Datenmenge, die dabei verarbeitet wird, ist durch die Kapazität eines einzelnen Redis-Prozesses begrenzt, denn Sentinel repliziert nur, es teilt nichts auf.

Redis Cluster löst dagegen zwei Probleme gleichzeitig: Es verteilt Daten über mehrere Knoten, sogenanntes Sharding, und bringt dabei automatischen Failover pro Shard gleich mit. Wer nur Hochverfügbarkeit braucht, aber keine horizontale Skalierung, bekommt mit Redis Cluster also eine Lösung, die mehr kann, als eigentlich gebraucht wird, und die dafür mit spürbar höherer operativer Komplexität bezahlt wird. Diese Unterscheidung ist der Ausgangspunkt jeder fundierten Entscheidung zwischen Cluster und Sentinel.

Ein verbreiteter Fehler in der Praxis ist, Redis Cluster einzuführen, weil es moderner oder skalierbarer klingt, ohne dass die zugrunde liegende Datenmenge das tatsächlich rechtfertigt. Das Ergebnis ist eine Infrastruktur mit signifikant mehr beweglichen Teilen, Slot-Verwaltung, Hash-Tag-Disziplin im Anwendungscode, cluster-fähigen Clients, für ein Problem, das ein einfaches Sentinel-Setup ebenso gut gelöst hätte. Die folgenden Abschnitte arbeiten die konkreten Unterschiede heraus, damit diese Entscheidung auf echten Kriterien statt auf Bauchgefühl basiert.

2. Redis Sentinel im Kurzüberblick: Failover ohne Sharding

Redis Sentinel überwacht ein klassisches Master-Replica-Setup mit einer Gruppe unabhängiger Sentinel-Prozesse. Erkennt eine ausreichende Anzahl von Sentinels per Quorum, dass der Master ausgefallen ist, befördert das System automatisch eine Replica zum neuen Master. Clients fragen bei Sentinel nach der aktuellen Master-Adresse, statt sie fest zu verdrahten. Die gesamte Datenmenge bleibt dabei immer vollständig auf einem einzelnen aktiven Knoten, nur repliziert auf mehrere weitere.

Der große Vorteil dieses Modells ist seine Einfachheit: Aus Anwendungssicht ändert sich praktisch nichts gegenüber einem einzelnen Redis-Server, bis auf die Adress-Auflösung über Sentinel. Sämtliche Redis-Befehle funktionieren uneingeschränkt, Multi-Key-Operationen, Transaktionen, alle 16 Datenbanken über SELECT. Diese Kompatibilität macht Redis Sentinel zur naheliegenden Wahl für Setups, die primär Ausfallsicherheit brauchen, aber deren Datenmenge deutlich innerhalb der Kapazität eines einzelnen Hosts bleibt.

3. Redis Cluster im Kurzüberblick: Sharding mit eingebauter HA

Redis Cluster verteilt die 16384 Hash Slots über mehrere Master-Knoten, jeder mit eigenen Replicas. Fällt ein Master aus, befördert das Cluster automatisch eine seiner Replicas, ohne separate Sentinel-Prozesse, diese Logik ist direkt in jeden Knoten eingebaut. Der entscheidende Unterschied zu Sentinel: Die Gesamtdatenmenge verteilt sich auf mehrere unabhängige Master, sodass die Kapazitätsgrenze eines einzelnen Hosts nicht mehr die Obergrenze des gesamten Systems ist.

Diese zusätzliche Fähigkeit kommt mit echten Einschränkungen: Multi-Key-Operationen funktionieren nur innerhalb desselben Hash Slots, SELECT ist deaktiviert, und Anwendungen benötigen zwingend einen cluster-fähigen Client. Redis Cluster ist damit keine Erweiterung von Sentinel um zusätzliche Features, sondern ein architektonisch anderes Modell mit eigenen Regeln, die von Anfang an im Anwendungsdesign berücksichtigt werden müssen.

4. Operative Komplexität im Vergleich

Der Betriebsaufwand von Redis Sentinel beschränkt sich im Kern auf drei Dinge: die Sentinel-Prozesse selbst überwachen, Quorum und Timeouts richtig konfigurieren, und sicherstellen, dass Clients Sentinel-fähig sind. Ein Failover betrifft immer den gesamten Datensatz auf einmal, es gibt keine Teilausfälle einzelner Datenbereiche. Debugging ist vergleichsweise einfach, weil es nur einen aktiven Master zu einem Zeitpunkt gibt.

Redis Cluster addiert zur Sentinel-ähnlichen Failover-Logik pro Shard noch die gesamte Slot-Verwaltung: initiale Verteilung, Rebalancing bei Wachstum, Resharding beim Hinzufügen oder Entfernen von Knoten, Monitoring von cluster_state auf jedem einzelnen Knoten. Ein Teilausfall betrifft nur die Slots des ausgefallenen Masters, was einerseits gut ist, weil der Rest des Clusters weiterläuft, andererseits aber bedeutet, dass Monitoring und Alerting pro Shard granularer aufgebaut werden müssen. Die Anzahl der zu überwachenden Prozesse steigt bei Cluster deutlich schneller mit der Clustergröße als bei Sentinel.

# Sentinel: one command tells you the whole picture
redis-cli -p 26379 sentinel master orders-cache

# Cluster: health must be checked per node AND cluster-wide
redis-cli -c -p 7000 cluster info | grep cluster_state
redis-cli -c -p 7001 cluster info | grep cluster_state
redis-cli -c -p 7002 cluster info | grep cluster_state
redis-cli --cluster check 10.0.2.10:7000

# Cluster: verifying full coverage requires summing per-node slots
redis-cli -c -p 7000 cluster slots | wc -l

In Teams mit begrenzter dedizierter Datenbank-Betriebserfahrung ist dieser Unterschied oft der entscheidende Faktor. Ein gut dokumentiertes Sentinel-Setup lässt sich auch von einem generalistischen DevOps-Team zuverlässig betreiben, während ein Redis Cluster in Produktion tendenziell tieferes Verständnis der Slot-Mechanik erfordert, insbesondere bei Incident-Response unter Zeitdruck.

5. Datenmenge als Entscheidungskriterium

Die wichtigste einzelne Kennzahl für die Entscheidung zwischen Redis Sentinel und Redis Cluster ist die tatsächliche und die absehbar zukünftige Datenmenge im Verhältnis zur verfügbaren Hardware. Passt der komplette Datensatz mit ausreichend Reserve für Wachstum in den Arbeitsspeicher eines realistisch verfügbaren Hosts, etwa bis zu 100 bis 200 GB auf gängiger Cloud-Hardware, ist Sharding in der Regel unnötig, und Sentinel reicht aus.

Übersteigt die Datenmenge diese Grenze, oder ist absehbar, dass sie sie in den nächsten ein bis zwei Jahren übersteigen wird, sollte Redis Cluster ernsthaft in Betracht gezogen werden. Wichtig ist dabei, nicht nur die aktuelle Größe zu betrachten, sondern die Wachstumsrate, weil eine spätere Migration von Sentinel zu Cluster deutlich aufwändiger ist als eine frühzeitige, geplante Einführung von Cluster, da Migrationspfad, Hash-Tag-Disziplin und Client-Umstellung im laufenden Betrieb nachgezogen werden müssen. Auch der Schreib-Durchsatz zählt als Kriterium: Ein einzelner Redis-Master verarbeitet typischerweise mehrere hunderttausend einfache Operationen pro Sekunde, aber komplexere Operationen oder große Werte senken diesen Durchsatz erheblich, was ebenfalls für Sharding sprechen kann, auch bei moderater Datenmenge.

# Quick capacity check: current memory usage vs. host limits
redis-cli -p 6379 info memory | grep -E "used_memory_human|maxmemory_human"

# Estimate growth trend from historical INFO snapshots
# (collected periodically via cron/monitoring, then plotted)
redis-cli -p 6379 info memory | grep used_memory: >> /var/log/redis/mem-trend.log

# Rule of thumb for the decision:
# < 100-200 GB and steady growth  -> Sentinel is sufficient
# > 100-200 GB or fast growth     -> plan for Redis Cluster

Eine Faustregel, die sich in der Praxis bewährt hat: Wer die Frage "Wird dieser Datensatz jemals größer als ein einzelner gut ausgestatteter Server sein?" mit einem klaren Nein beantworten kann, sollte bei Redis Sentinel bleiben. Jede Unsicherheit bei dieser Frage ist ein Argument dafür, Redis Cluster zumindest zu evaluieren, auch wenn die aktuelle Datenmenge noch klein ist, denn ein frühzeitiges Hash-Tag-gerechtes Key-Design ist wesentlich günstiger als eine spätere Nachrüstung.

6. Client-Anbindung: Unterschiede in der Praxis

Aus Sicht des Anwendungscodes unterscheiden sich Redis Sentinel und Redis Cluster deutlich mehr, als die Konfigurationsebene vermuten lässt. Ein Sentinel-fähiger Client kennt eine Liste von Sentinel-Adressen und fragt bei Bedarf nach der aktuellen Master-Adresse, alle übrigen Redis-Befehle funktionieren danach exakt wie bei einer normalen Verbindung. Bestehender Code, der gegen einen Standalone-Redis geschrieben wurde, lässt sich meist mit minimalen Änderungen auf Sentinel umstellen.

Ein cluster-fähiger Client für Redis Cluster muss dagegen erheblich mehr Logik beherrschen: Slot-Berechnung, MOVED- und ASK-Redirects folgen, Multi-Key-Befehle vor der Ausführung auf Slot-Kompatibilität prüfen, und mit Fehlern umgehen, die es bei Sentinel gar nicht gibt, etwa der Ablehnung von Pipeline-Befehlen über mehrere Slots hinweg. Bestehender Anwendungscode, der Multi-Key-Befehle ohne Hash Tags nutzt, funktioniert nach einer Migration auf Cluster häufig nicht mehr ohne Anpassung, was den Migrationsaufwand in der Praxis regelmäßig unterschätzt wird.

# Sentinel-aware client setup: minimal change from standalone
client = RedisSentinelClient(
  sentinels=[("10.0.1.11", 26379), ("10.0.1.12", 26379)],
  service_name="orders-cache"
)
client.mget(["order:1", "order:2", "order:3"])  # works fine

# Cluster-aware client setup: additional constraints apply
cluster_client = RedisClusterClient(
  startup_nodes=[("10.0.2.10", 7000), ("10.0.2.11", 7001)]
)
# This fails unless all three keys share the same hash tag
cluster_client.mget(["order:1", "order:2", "order:3"])
# CROSSSLOT Keys in request don't hash to the same slot

# Correct cluster pattern requires a shared hash tag
cluster_client.mget(["{orders}:1", "{orders}:2", "{orders}:3"])

7. Migrationspfade: von Sentinel zu Cluster wechseln

Ein späterer Wechsel von Redis Sentinel zu Redis Cluster ist möglich, aber nie ein reiner Infrastrukturwechsel. Der übliche Weg führt über einen neu aufgesetzten Cluster, in den Daten aus dem bestehenden Sentinel-Setup migriert werden, etwa per redis-cli --cluster import oder über anwendungsseitiges Dual-Write während einer Übergangsphase. Ein direktes In-Place-Upgrade eines laufenden Sentinel-Setups zu Cluster existiert nicht, weil sich die grundlegende Datenverteilung ändert.

Der eigentliche Aufwand liegt selten in der reinen Datenmigration, sondern in der Überarbeitung des Anwendungscodes: Jede Stelle, die Multi-Key-Operationen ohne Hash Tags nutzt, jede Transaktion über mehrere unabhängige Keys, jede Abhängigkeit von mehreren Datenbanken über SELECT, muss identifiziert und angepasst werden. Teams, die frühzeitig mit Hash-Tag-freundlichem Key-Design arbeiten, auch wenn sie aktuell noch Sentinel nutzen, reduzieren diesen Migrationsaufwand erheblich, falls ein späterer Wechsel zu Cluster nötig wird.

# Import existing standalone/Sentinel data into a fresh cluster
redis-cli --cluster import 10.0.2.10:7000 \
  --cluster-from 10.0.1.10:6379 \
  --cluster-copy

# Alternative: dual-write from the application during cutover
# 1. Application writes to both the old Sentinel-backed master
#    and the new Cluster in parallel
# 2. Read traffic stays on the old master until parity is verified
# 3. Cutover reads to the cluster once replication lag is zero
# 4. Decommission the old Sentinel setup

# Audit existing code for CROSSSLOT-incompatible patterns before
# migrating: search for multi-key commands without hash tags
grep -rn "MGET\|MSET\|SINTERSTORE\|MULTI" ./src | grep -v "{.*}"

Ein oft übersehener Punkt bei der Migration ist die Testphase: Ein Lastenheft, das gegen Sentinel entwickelt und getestet wurde, deckt CROSSSLOT-Fehler in der Regel nicht auf, weil sie in einem Standalone- oder Sentinel-Setup schlicht nicht existieren. Ein dedizierter Testlauf gegen einen temporären Redis Cluster in der Staging-Umgebung, mit demselben Anwendungscode wie in Produktion, ist die zuverlässigste Methode, um diese Klasse von Fehlern vor dem eigentlichen Umzug zu finden.

8. Kombinierte Architekturen und wann sie Sinn ergeben

In größeren Systemlandschaften ist es üblich, Redis Sentinel und Redis Cluster parallel für unterschiedliche Zwecke einzusetzen, nicht als konkurrierende, sondern als komplementäre Lösungen. Ein Session-Store mit begrenzter, gut vorhersagbarer Datenmenge läuft oft effizienter auf einem Sentinel-Setup, während ein Produktkatalog-Cache mit stark wachsender Datenmenge auf Redis Cluster besser aufgehoben ist. Diese Aufteilung nach Anwendungsfall statt nach unternehmensweitem Standard ist in der Praxis oft die pragmatischste Lösung.

Ein weiteres Muster ist der Einsatz von Redis Cluster für den primären Datenspeicher kombiniert mit einer separaten, kleineren Sentinel-Instanz für spezifische Anwendungsfälle wie verteilte Locks oder Rate-Limiting, wo die Kompatibilitätsgarantien von Standalone-Redis, etwa uneingeschränkte Transaktionen, wichtiger sind als horizontale Skalierung. Wichtig ist dabei, dass diese Kombination bewusst getroffen wird, nicht als Ergebnis historisch gewachsener, unkoordinierter Infrastrukturentscheidungen.

# Example: two logical Redis deployments serving different needs

# deployment "sessions" - small, predictable, needs full command set
# -> Sentinel, 1 master + 2 replicas, 3 sentinel processes
redis-cli -p 26379 sentinel master sessions

# deployment "catalog-cache" - large, fast growing, read heavy
# -> Cluster, 6 masters + 6 replicas, sharded via hash slots
redis-cli -c -p 7000 cluster info | grep cluster_size

# Application config keeps both endpoints explicit and separate
# REDIS_SESSIONS_SENTINELS=10.0.1.11:26379,10.0.1.12:26379
# REDIS_CATALOG_CLUSTER_NODES=10.0.2.10:7000,10.0.2.11:7001

Diese bewusste Trennung nach Anwendungsfall verhindert auch ein häufiges Antipattern: alle Redis-Workloads pauschal in dieselbe Infrastruktur zu zwingen, nur um ein einziges Betriebsmodell pflegen zu müssen. Kurzfristig spart das Koordinationsaufwand, langfristig führt es entweder zu einem überdimensionierten Cluster für kleine Workloads oder zu einem Sentinel-Setup, das an seine Kapazitätsgrenze stößt, obwohl ein Teil der Daten dort nie hätte liegen müssen.

9. Entscheidungsmatrix für die Praxis

Zusammengefasst lässt sich die Entscheidung zwischen Redis Sentinel und Redis Cluster auf wenige klare Leitfragen reduzieren. Passt der Datensatz mit Reserve auf einen Host, reicht Sentinel. Braucht die Anwendung uneingeschränkte Multi-Key-Operationen und mehrere logische Datenbanken, spricht das ebenfalls für Sentinel, selbst bei größerer Datenmenge, da eine Migration zu Cluster diese Features einschränken würde.

Wächst der Datensatz absehbar über die Kapazität eines einzelnen Hosts hinaus, oder ist der Schreib-Durchsatz bereits jetzt ein limitierender Faktor, überwiegen die Vorteile von Redis Cluster die zusätzliche operative Komplexität. Entscheidend ist, diese Bewertung nicht einmalig, sondern regelmäßig zu wiederholen, denn Datenmengen wachsen selten linear, und eine Architektur, die heute passt, kann in zwei Jahren die falsche Wahl sein.

10. Zusammenfassung

Die Entscheidung zwischen Redis Cluster und Redis Sentinel ist keine Frage von alt gegen neu oder einfach gegen fortgeschritten, sondern eine Frage danach, welches konkrete Problem gelöst werden muss. Sentinel löst Hochverfügbarkeit für Datensätze, die auf einem Host bleiben. Cluster löst Hochverfügbarkeit für Datensätze, die diese Grenze sprengen, und bezahlt dafür mit signifikant höherer operativer Komplexität und eingeschränkter Befehlskompatibilität.

Datenmenge und deren Wachstumsrate sind die verlässlichsten Entscheidungskriterien, ergänzt um die Frage, ob die Anwendung auf uneingeschränkte Multi-Key-Operationen angewiesen ist. Wer diese Kriterien früh und ehrlich bewertet, vermeidet sowohl die unnötige Komplexität eines zu früh eingeführten Clusters als auch die schmerzhafte Nachrüstung eines Sentinel-Setups, das an seine Kapazitätsgrenze gestoßen ist.

11. FAQ: Cluster vs. Sentinel