Zum Hauptinhalt springen

Drei Wege zum Failover: LoadBalancer, Sentinel und Cluster im Zaris-RESP-Frontend

· 6 Minuten Lesezeit
Clustron Team
Clustron Team
Engineering für verteilte Systeme

Drei Wege zum Failover im Zaris-RESP-Frontend

Zaris stellt ein Redis-Protokoll-Frontend (RESP) bereit, sodass jeder Redis-Client in jeder Sprache auf einen Zaris-Cluster zeigen und ihn als Drop-in-Store nutzen kann. Doch „jeder Redis-Client" verbirgt ein reales Problem: Die Redis-Client-Ökosysteme sind sich nicht einig, wie die Topologie ermittelt wird oder wie man reagiert, wenn ein Node verschwindet. Ein einfacher Client erwartet einen einzelnen, stabilen Endpunkt. Ein Sentinel-basierter Client erwartet, einen Discovery-Dienst fragen zu können: „Wer ist der Master?" Ein Client im Cluster-Modus erwartet Hash-Slots und MOVED/ASK-Redirects.

Würde ein Store nur einen dieser Dialekte sprechen, blieben ganze Client-Klassen außen vor. Deshalb unterstützt das Zaris-RESP-Frontend drei Failover-Modelle, die jeweils dazu passen, wie eine bestimmte Familie von Redis-Clients bereits arbeitet. Sie wählen das Modell pro Deployment; der Client verhält sich genau so, wie er es gegenüber echtem Redis tun würde.

Vorab ein ehrlicher Hinweis, der alles Folgende prägt: Alle drei Modelle sitzen vor demselben replizierten, partitionierten Zaris-Store. Das gewählte Modell ändert die Semantik von Discovery und Redirects — also wie ein Client einen Node findet und was er tut, wenn dieser ausfällt —, nicht aber, wo Ihre Daten tatsächlich liegen.

Ein Store, drei Client-Dialekte​

Ein Zaris-Cluster besteht aus mehreren Nodes mit partitionierten, replizierten Daten. Fällt der Node aus, mit dem ein Client spricht, muss der Client einen anderen finden und weitermachen — und Redis-Clients wurden gegen drei verschiedene Discovery-Mechanismen geschrieben:

  • Ein einfacher Client öffnet lediglich eine Verbindung zu Host und Port. Er kennt kein Konzept von Topologie.
  • Ein Sentinel-fähiger Client behandelt die Master-Ermittlung als eigenes Protokoll: Er fragt Sentinel nach dem aktuellen Master, verbindet sich und fragt nach einem Failover erneut ab.
  • Ein Client im Cluster-Modus lädt beim Verbindungsaufbau eine Slot-Map und routet jeden Key zu dem Node, der den zugehörigen Slot besitzt, wobei er MOVED/ASK-Redirects folgt.

Zaris beantwortet alle drei. Das Modell wird zur Deployment-Zeit über ZARIS_RESP_*-Umgebungsvariablen gewählt.

Modell 1 — LoadBalancer: der einfachste Drop-in​

Clients verbinden sich über einen einzigen, stabilen Endpunkt — einen Kubernetes-Service oder einen beliebigen L4-Load-Balancer —, und Zaris routet und leitet intern dahinter um. Jeder Node akzeptiert jeden Key. Fällt ein Node aus, verschwindet er aus der Rotation, und die nächste Verbindung landet auf einem gesunden Node. Das funktioniert mit jedem einfachen Redis-Client, weil es nicht mehr verlangt als „verbinde dich mit dieser Adresse", und das Failover hinter dem Endpunkt transparent bleibt.

# One stable endpoint in front of the whole cluster.
redis-cli -h redis.example.com -p 6379 SET user:42 "ada"
redis-cli -h redis.example.com -p 6379 GET user:42
apiVersion: v1
kind: Service
metadata:
  name: zaris-resp
spec:
  type: LoadBalancer
  selector:
    app: zaris
  ports:
    - name: resp
      port: 6379
      targetPort: 6379

Greifen Sie zuerst hierzu: die wenigsten beweglichen Teile, die breiteste Client-Unterstützung.

Modell 2 — Sentinel: für Stacks, die bereits auf Sentinel aufbauen​

Viele Teams greifen bereits über Sentinel-fähige Clients auf Redis zu, konfiguriert mit Sentinel-Adressen und einem Master-Namen. Deshalb beantwortet Zaris das Redis-Sentinel-Protokoll: Der Client fragt „Wer ist der Master?", Zaris antwortet, und der Client verbindet sich mit diesem Node. Bei einem Failover löst der Client den Master über denselben Codepfad neu auf, den er ohnehin verwendet, und verbindet sich erneut. An der Failover-Logik des Clients ändert sich nichts.

redis-cli -h zaris-sentinel.example.com -p 26379 \
  SENTINEL get-master-addr-by-name zaris-primary

Wählen Sie dieses Modell, wenn Ihr Stack bereits auf Sentinel basiert.

Modell 3 — Cluster: CRC16-Slot-ausgerichtet​

Für Clients, die das Redis-Cluster-Protokoll sprechen, beantwortet Zaris CLUSTER SLOTS und CLUSTER NODES und sendet MOVED/ASK-Redirects mit CRC16-Hash-Slot-ausgerichtetem Routing — dieselbe Slot-Berechnung CRC16(key) % 16384, die ein Redis-Cluster-Client verwendet. Da das interne Routing von Zaris und die Redis-Slot-Berechnung aufeinander abgestimmt sind, deckt sich die Vorstellung des Clients davon, zu welchem Slot ein Key gehört, mit der eigenen Platzierung von Zaris, sodass er jeden Key direkt zum zuständigen Node routet.

Dadurch sind redis-cli --cluster und Bibliotheken im Cluster-Modus ein Drop-in. Bei einem Rebalancing oder Failover wechselt die Zuständigkeit für einen Slot, und der Node antwortet mit einem Redirect; der Client aktualisiert seine Slot-Map und folgt.

redis-cli -c -h 10.0.0.10 -p 6379 SET user:42 "ada"
redis-cli -h 10.0.0.10 -p 6379 CLUSTER SLOTS

Wählen Sie dieses Modell, wenn Sie Clients im Cluster-Modus betreiben oder clientseitige Slot-Kenntnis wünschen, damit Clients direkt zu den zuständigen Nodes routen.

Getestet mit Kill und Rejoin​

Alle drei Modelle wurden mit einem Node-Kill und anschließendem Rejoin validiert. In jedem Fall erholen sich die Clients — der LoadBalancer-Client verbindet sich über den Endpunkt neu, der Sentinel-Client löst den Master neu auf, und der Cluster-Client aktualisiert seine Slot-Map — und der Datenverkehr läuft gegen die verbleibenden Nodes weiter. Ein Failover-Modell, das nie unter realem Node-Verlust erprobt wurde, ist reine Vermutung.

Ein Modell auswählen​

Das Modell ist eine Entscheidung pro Deployment und wird über ZARIS_RESP_*-Flags gesetzt:

env:
  - name: ZARIS_RESP_ENABLED
    value: "true"
  - name: ZARIS_RESP_FAILOVER_MODEL
    value: "cluster"   # or "loadbalancer" / "sentinel"

Der Entscheidungsleitfaden​

  • LoadBalancer für den einfachsten Drop-in. Funktioniert mit jedem einfachen Redis-Client und verbirgt das Failover hinter einem Endpunkt. Beginnen Sie hier, sofern nichts dagegen spricht.
  • Sentinel, wenn Ihr Stack bereits auf Sentinel aufbaut — die Clients behalten ihren bestehenden Code für Master-Discovery und Failover.
  • Cluster, wenn Sie Clients im Cluster-Modus betreiben oder clientseitige Slot-Kenntnis wünschen, damit Clients direkt zum zuständigen Node routen und bei Rebalancing und Failover Redirects folgen.

Die ehrliche Grenze​

Alle drei Modelle stehen vor demselben replizierten, partitionierten Zaris-Store. Welches Sie auch wählen: Ihre Daten werden darunter stets gleich platziert und repliziert — das Modell ändert nur, wie Clients Nodes ermitteln und bei Ausfällen umgeleitet werden, nicht die Dauerhaftigkeit oder Platzierung der Daten. Es ist eine Entscheidung zur Client-Kompatibilität, aufgesetzt auf einen konsistenten Store.

Zu den Routing-Interna — wie die CRC16-Ausrichtung Cluster-Clients ohne Proxy zu den zuständigen Nodes führt — lesen Sie wie Zaris das Redis-Protokoll spricht.