Dies kann ein Serverfehler oder eine Stack Overflow-Frage sein, ich bin noch nicht sicher:
Ich habe ein einfaches Redis-System mit drei Knoten eingerichtet, mit einem Master- und zwei Replikationsknoten, und verwalte das Failover mit Redis Sentinel. Der Netzwerkverkehr von Redis und Sentinel wird durch die integrierte TLS-Unterstützung von Redis und reguläre, von der Zertifizierungsstelle ausgestellte Zertifikate gesichert.
Jede Sentinel-Instanz ist so konfiguriert, dass sie ihren Hostnamen bekannt gibt und DNS auflöst:
sentinel resolve-hostnames yes
sentinel announce-hostnames yes
sentinel announce-ip "redistest2.mydomain.com"
Wir haben einen Webdienst, der Servicestack verwendet, um eine Verbindung zu den Sentinel-Instanzen herzustellen. Solange wir TLS-Zertifikate und Hostnamen nicht validieren, funktioniert alles gut: Der Webdienst kann die Redis Sentinel-Listener sehen, und wenn wir den aktuellen Master beenden, stimmt der Redis-Cluster über einen neuen ab, und der Webdienst wechselt zum neuen beschreibbaren Redis-Knoten.
Während sich der ursprüngliche Masterknoten jedoch mit seinem FQDN meldet, scheinen die beiden Backup-Knoten immer nur ihre IP-Adressen bei ServiceStack zu melden.
Ein Auszug aus dem Sentinel-Protokoll zeigt, dass die Backup-Knoten offenbar ihre Hostnamen verwenden:
28011:X 15 Feb 2023 15:23:10.817 * +sentinel sentinel <hex-string> redistest2.mydomain.com 26379 @ redistest redistest1.mydomain.com 6379
28011:X 15 Feb 2023 15:23:10.821 * Sentinel new configuration saved on disk
28011:X 15 Feb 2023 15:23:10.897 * +sentinel sentinel <other-hex-string> redistest3.mydomain.com 26379 @ redistest redistest1.mydomain.com 6379
28011:X 15 Feb 2023 15:23:10.901 * Sentinel new configuration saved on disk
ServiceStack besteht jedoch darauf, dass es nur die Server-IP-Adressen von der Servergruppe zurückerhält:
Starting with sentinel.
Sentinel hosts: redistest1.mydomain.com:26379?ssl=true, redistest2.mydomain.com:26379?ssl=true, redistest3.mydomain.com:26379?ssl=true
Sentinel created
Host filter set.
Hostfilter: redistest1.mydomain.com:6379
Hostfilter: 10.100.60.72:6379
Hostfilter: 10.100.60.73:6379
RedisManager started.
Redis sentinel info: redistest primary: redistest1.mydomain.com:6379, replicas: 10.100.60.72:6379, 10.100.60.73:6379
Hostfilter: 10.100.60.72:6379
Hostfilter: 10.100.60.73:6379
Ping error with read only client: ServiceStack.Redis.RedisException: [14:23:47.626] Unable to Connect: sPort: 0, Error: One or more errors occurred.
(...)
---> System.AggregateException: One or more errors occurred. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
Kann ich auf der Redis- und/oder Sentinel-Konfigurationsseite noch etwas tun, um sicherzustellen, dass ServiceStack die tatsächlichen Hostnamen der Redis-Knoten erhält, damit wir die verwendeten Zertifikate korrekt validieren können?
Antwort1
Das ServiceStack-Protokoll enthält den notwendigen Hinweis darauf, was schiefgelaufen ist: Sentinel hat genau das getan, was es sollte, aber auf die Redis-Backup-Knoten wurde per IP-Adresse verwiesen.
Ähnlich wie Sentinel eine Zeichenfolge mit dem FQDN in der sentinel announce-ipKonfigurationsanweisung zurückgeben kann, kann Redis dasselbe mit der replica-announce-ipKonfigurationsanweisung tun.
Die Lösung bestand darin, der Redis-Konfigurationsdatei auf allen Backup-Hosts die folgende Zeile hinzuzufügen:
replica-announce-ip servername.mydomain.com
Der Servername ist in diesem Fall natürlich der Hostname der Maschine, auf der dieser spezielle Sicherungsknoten ausgeführt wird.