☰

HAProxy, aber immer noch ein einzelner Ausfallpunkt

tag-icon • tag-icon haproxy mariadb
HAProxy, aber immer noch ein einzelner Ausfallpunkt

Ich richte einen Testcluster ein – Maria Galera Cluster auf 3 physischen Knoten mit HAProxy. Es funktioniert, aber ich habe einen Anfängerfehler gemacht, den ich nicht beheben kann – also kann mir hoffentlich jemand mit seinem Expertenblick weiterhelfen?!

Ich habe 3 physische Knoten Knoten1: 10.1.1.120

Knoten2: 10.1.1.121

Knoten3: 10.1.1.124

Mit HAProxy eine virtuelle IP von 10.1.1.113

Wenn ich eine Abfrage über die virtuelle IP mache, erhalte ich Folgendes:

$ mysql -uroot -pPassword -P 3306 -h 10.1.1.113 -e "select @@hostname; show processlist;"
+------------+
| @@hostname |
+------------+
| node2      |
+------------+
+----+-------------+-------------+------+---------+------+--------------------+------------------+----------+
| Id | User        | Host        | db   | Command | Time | State              | Info                 | Progress |
+----+-------------+-------------+------+---------+------+--------------------+------------------+----------+
|  1 | system user |             | NULL | Sleep   |   37 | NULL               | NULL                 |    0.000 |
|  2 | system user |             | NULL | Sleep   |   37 | wsrep aborter idle | NULL             |    0.000 |
| 45 | root        | node1:55877 | NULL | Query   |    0 | init               | show processlist |    0.000 |
+----+-------------+-------------+------+---------+------+--------------------+-

Und wenn ich das tueIP-AdresseAnKnoten1- dort befindet sich tatsächlich meine virtuelle IP-Adresse, ABER der Hostname wird zurückgegeben alsKnoten2.

Wenn ich Knoten1 herunterfahre (oder einfach eth0 deaktiviere), verschiebt sich die virtuelle IP-Adresse woanders hin, aber der @@Hostname wird immer noch als Knoten2 zurückgegeben.

Das Problem tritt auf, wenn ich Knoten2 herunterfahre. Wenn ich dann versuche, mit der virtuellen IP auf MySQL zuzugreifen, erhalte ich Folgendes:

**ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0 "Internal error/check (Not system error)"**

(Wenn ich mich jetzt bei einem der lokalen Computer anmelde, ohne die virtuelle IP zu verwenden, funktioniert es).

Es scheint also, als ob der HAProxy-Teil funktioniert (da dieser entsprechend verschoben wird), aber MariaDB versucht, sein eigenes Ding durchzuziehen und hat entschieden, dass alles über Node2 geroutet werden muss.

Ich habe keine Bind-Adresse in meinen .cnf-Dateien. Ich verwende Port 1306 für meinen SQL-Dienst, um Konflikte mit 3306 zu vermeiden, wenn ich den Dienst auf einem Computer neu starte, der zufällig die virtuelle IP hat und gleichzeitig 3306 postet.

Meine Keepalived-Datei ist ... (nicht sicher, ob das richtig ist, aber alle Knoten sind auf Master eingestellt und die Prioritäten sind 100, 101 bzw. 102 – scheint keinen Unterschied zu machen)

global_defs {
  router_id geordi
}
vrrp_script haproxy {
  script "killall -0 haproxy"
  interval 1
  weight 1
}

vrrp_instance 51 {
  virtual_router_id 51
  priority 101
  state MASTER
  interface eth0
  virtual_ipaddress {
    10.1.1.113 dev eth0
  }
  track_script {
    haproxy
  }
}

und meine haproxy.cfg ist:

global
    log /dev/log    local0
    log /dev/log    local1 notice
    chroot /var/lib/haproxy
    user haproxy
    group haproxy
    daemon

defaults
    log global
    mode    http
    option  dontlognull
    contimeout 5000
    clitimeout 50000
    srvtimeout 50000
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http

listen mysql_proxy 10.1.1.113:3306
        mode tcp 
        balance roundrobin
        option tcpka 
        option httpchk
        option mysql-check user haproxy
        server node1 10.1.1.120:1306 check 
        server node2 10.1.1.121:1306 check 
        server node3 10.1.1.124:1306 check

Ich freue mich über alle Vorschläge – ich bin frustrierend nah dran, alles zum Laufen zu bringen, aber ich habe es noch nicht ganz geschafft!

Antwort1

Explizit festgelegt bind-address=0.0.0.0in my.cnf.

Zusätzlich (wenn Sie schon so weit sind, haben Sie das wahrscheinlich schon getan):

  1. Stellen Sie sicher, dass jeder Host die IP-Adresse hat 10.1.1.113(bei Verwendung von Keepalived, dann über eine Dummy-Schnittstelle als /32).
  2. einsetzennet.ipv4.conf.default.rp_filter = 2​/etc/sysctl.conf
  3. einsetzennet.ipv4.conf.default.accept_source_route = 0​/etc/sysctl.conf

Dadurch kann MySQL auf allen Schnittstellen LISTEN und auf einer Schnittstelle ANTWORTEN, für die das Paket nicht bestimmt war.

Die Netzwerkschnittstelle auf Knoten1 (10.1.1.120) erhält das Paket als „10.1.1.13“ auf der Schnittstelle, die 10.1.1.120 entspricht. Normalerweise würde dies mit der Bemerkung „Das ist nichts für mich“ verworfen. Dies geschieht auf der „Internet“-Ebene des TCP/IP-Modells.

In den obigen Bestimmungen 2 und 3 heißt es jedoch: „Akzeptieren Sie es einfach, es könnte für uns sein“, was dann an MySQL weitergeleitet wird (Schicht „Anwendung“ des TCP/IP-Modells). MySQL erkennt, dass wir an alle Adressen gebunden sind, eine davon ist 10.1.1.113 (Bestimmung 1) und verarbeitet sie.

verwandte Informationen