0
Haproxy Regel Missachtung bei neustart
Hallo,
ich weiß nicht genau ob das Unterforum richtig gewählt ist aber es geht um Server und Internet im weiteren Sinne.
Betroffen Versionen von HA-Proxy 1.5.8 (Debian 7) und 1.5.12 (Ubuntu 14.04).
Ziel ist es mittels HAproxy den aktuellen Redis-Master durch Abfrage der Redis-Sentinels zu ermitteln und so den Master immer für alle Anwendungen bereit stellen zu können (wenn diese nicht nativ mit sentinel zusammenarbeiten).
Die Webanwendungen verbinden sich mit dem HA-Proxy und diser gibt die Anfrage dan per Regelwerk weiter.
Hier der entsprechende Configeintrag.
Jetzt das Problem:
IMMER wenn der Haproxy neu gestartet oder neu geladen wird, sind die Regeln schnuppe!
Bis zum ersten Aplauf des Checkintervalls vermittelt der HAproxy einfach die erste Server IP, egal ob es der aktuelle Master ist oder nicht!
Und das ist ein Problem.
Die Regel funktoniert soweit, immer wenn der Master weg bricht und die Sentinels einen neuen wählen, leitet der HAproxy nirgendwo hin, ist der neue Master bestimmt gibt der HAproxy auch nur diesen weiter.
ABER wird der HAproxy neu gestartet nimmt er immer die erste IP im Beispiel 10.100.7.143, egal ob es der Slave ist oder nicht!
Kennt jemand das Problem und weiß wie man das umgehen kann?
Die Verwendung der Server use_backend und entsprechenden Backends habe ich auch schon getestet.
Gruß
Chonta
Nachtrag: Lösung gefunden.
Folgender Eintrag musste noch in der Konfiguration hinzugefügt werden. Konfig angepasst.
tcp-request connection reject if { nbsrv(check_master_redisA) ge 2 } { nbsrv(check_master_redisB) ge 2 }
ich weiß nicht genau ob das Unterforum richtig gewählt ist aber es geht um Server und Internet im weiteren Sinne.
Betroffen Versionen von HA-Proxy 1.5.8 (Debian 7) und 1.5.12 (Ubuntu 14.04).
Ziel ist es mittels HAproxy den aktuellen Redis-Master durch Abfrage der Redis-Sentinels zu ermitteln und so den Master immer für alle Anwendungen bereit stellen zu können (wenn diese nicht nativ mit sentinel zusammenarbeiten).
Die Webanwendungen verbinden sich mit dem HA-Proxy und diser gibt die Anfrage dan per Regelwerk weiter.
Hier der entsprechende Configeintrag.
## If at least 2 sentinels agree with the redis host that it is master, use it.
listen redis_master :6380
mode tcp
tcp-request connection reject if { nbsrv(check_master_redisA) ge 2 } { nbsrv(check_master_redisB) ge 2 }
use-server redisA if { nbsrv(check_master_redisA) ge 2 }
server redisA 10.100.7.143:6379 weight 0
use-server redisB if { nbsrv(check_master_redisB) ge 2 }
server redisB 10.100.7.134:6379 weight 0
## Check 3 sentinels to see if they think redisA is master
backend check_master_redisA
mode tcp
option tcp-check
tcp-check send PING\r\n
tcp-check expect string +PONG
tcp-check send sentinel\ get-master-addr-by-name\ mymaster\r\n
tcp-check expect string 10.100.7.143
tcp-check send QUIT\r\n
tcp-check expect string +OK
server sentinelA 10.100.7.143:26379 check inter 5s
server sentinelB 10.100.7.134:26379 check inter 5s
server sentinelC 10.100.7.172:26379 check inter 5s
## Check 3 sentinels to see if they think redisB is master
backend check_master_redisB
mode tcp
option tcp-check
tcp-check send PING\r\n
tcp-check expect string +PONG
tcp-check send sentinel\ get-master-addr-by-name\ mymaster\r\n
tcp-check expect string 10.100.7.134
tcp-check send QUIT\r\n
tcp-check expect string +OK
server sentinelA 10.100.7.143:26379 check inter 5s
server sentinelB 10.100.7.134:26379 check inter 5s
server sentinelC 10.100.7.172:26379 check inter 5sJetzt das Problem:
IMMER wenn der Haproxy neu gestartet oder neu geladen wird, sind die Regeln schnuppe!
Bis zum ersten Aplauf des Checkintervalls vermittelt der HAproxy einfach die erste Server IP, egal ob es der aktuelle Master ist oder nicht!
Und das ist ein Problem.
Die Regel funktoniert soweit, immer wenn der Master weg bricht und die Sentinels einen neuen wählen, leitet der HAproxy nirgendwo hin, ist der neue Master bestimmt gibt der HAproxy auch nur diesen weiter.
ABER wird der HAproxy neu gestartet nimmt er immer die erste IP im Beispiel 10.100.7.143, egal ob es der Slave ist oder nicht!
Kennt jemand das Problem und weiß wie man das umgehen kann?
Die Verwendung der Server use_backend und entsprechenden Backends habe ich auch schon getestet.
Gruß
Chonta
Nachtrag: Lösung gefunden.
Folgender Eintrag musste noch in der Konfiguration hinzugefügt werden. Konfig angepasst.
tcp-request connection reject if { nbsrv(check_master_redisA) ge 2 } { nbsrv(check_master_redisB) ge 2 }
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 273775
Url: https://administrator.de/contentid/273775
Printed on: April 26, 2024 at 04:04 o'clock
