HA Loadbalancer mit keepalived und HAProxy

In einer high-availability Umgebung (HA) sind nicht nur die loadbalncer redundant, sondern auch die dahinter liegenden Backend-Server.

Das Szenario ist, dass es zwei Loadbalancer (lb01 und lb02) gibt. Diese haben je eine eigene IP-Adresse und „teilen“ sich eine dritte virtuelle IP-Adresse (VIP), welche in einem failover-Fall mittels keepalived von einem System auf das andere System transferiert wird.

Im backend gibt es zwei gleiche Webserver (web01 und web02). HAProxy verteilt die requests auf einen der beiden Webserver, sofern beide verfügbar sind.

Es kann also sowohl einer der Loadbalancer, wie auch einer der Webserver ausfallen.

Installation

Die IP Adressen sehen wie folgt aus:

Loadbalancer:

  • lb01: IP: 192.168.10.1
  • lb01: IP: 192.168.10.2
  • VIP: 192.168.10.3

Webserver:
(Auf den Webservern läuft eine Applikation, welche die Ports 8080 (HTTP) und 80443 (HTTPS) benutzen. Bei „normalen“ Webservern wäre es hier 80 (HTTP) und 443 (HTTPS)

  • web01: IP: 192.168.80.1 (HTTP-Port: 8080 )
  • web02: IP: 192.168.80.2 (HTTPS-Port: 80443)

Zunächst werden die benötigten Komponenten auf den beiden loadbalancern lb1 und lb2 installiert:

yum install keepalived haproxy
 
systemctl enable keepalived
systemctl enable haproxy

Nun müssen noch die Kernel-Parameter net.ipv4.ip_forward (IP-Forwarding einschalten) und net.ipv4.ip_nonlocal_bind gesetzt werden.
net.ipv4.ip_nonlocal_bind ermöglicht es, dass Programme sich an eine IP „binden“ können, welche es auf dem System (noch) gar nicht gibt.

sysctl -w net.ipv4.ip_forward="1"
sysctl -w net.ipv4.ip_nonlocal_bind="1"

Nun wird auf dem ersten loadbalancer (lb01) keepalived Konfiguriert:
/etc/keepalived/keepalived.conf

global_defs {
  router_id lb01
}
 
vrrp_script check_haproxy {
  script "/usr/bin/killall -0 haproxy"
  interval 2
  weight 2
}
 
vrrp_instance web-prod {
  state MASTER
  interface eth0
  virtual_router_id 1
  priority 100
  virtual_ipaddress {
    192.168.10.3
  }
  track_script {
    check_haproxy
  }
}

Und auf dem zweiten loadbalancer (lb02)
/etc/keepalived/keepalived.conf

global_defs {
  router_id lb02
}
 
vrrp_script check_haproxy {
  script "/usr/bin/killall -0 haproxy"
  interval 2
  weight 2
}
 
vrrp_instance web-prod {
  state BACKUP
  interface eth0
  virtual_router_id 1
  priority 99
  virtual_ipaddress {
    192.168.10.3
  }
  track_script {
    check_haproxy
  }
}

Der Unterschied ist im zweiten steht der STATE auf BACKUP und die priority auf 99; der Rest beleibt gleich.

Mittels den check_haproxy Script wird geprüft ob der HAProxy läuft und falls nicht ein failover initiert.

Nun wird die HAProxy Konfiguration gemacht, welche auf beiden loadbalancern (lb01 und lb02) gleich ist:

global
  log                                  127.0.0.1 local1
  maxconn                              4000
  user                                 haproxy
  group                                haproxy
  daemon
 
 
defaults
  mode                                 http
  log                                  global
  option                               httplog
  retries                              3
  timeout http-request                 10s
  timeout queue                        1m
  timeout connect                      10s
  timeout client                       1m
  timeout server                       1m
 
 
listen stats
  bind :9000
  mode http
  stats enable
  stats hide-version
  stats realm Haproxy\ Statistics
  stats uri /haproxy_stats
# stats auth Username:Password
 
 
frontend           web-prod-http
  bind             192.168.10.3:80
  default_backend  postch-exphub-prod-live-http
 
backend            web-prod-http
  balance          roundrobin
  server           web01 192.168.80.1:8080 check
  server           web02 192.168.80.2:8080 check
 
 
frontend           web-prod-https
  bind             192.168.10.3:443
  default_backend  postch-exphub-prod-live-http
 
backend            web-prod-https
  balance          roundrobin
  server           web01 192.168.80.1:80443 check
  server           web02 192.168.80.2:80443 check

Hier gehört immer eine Frontend-Definiton zur gleichnamigen Backend-Definition.
Das frontend bindet sich auf die VIP und das backend beinhaltet alle (gleichen) Server, welche im round-robin Verfahren loadbalnced werden.

Im obigen Szenario passiert folgendes:

  • Benutzer ruft die virtuelle IP auf: http://192.168.10.3/
  • ; diese befindet sich je nachdem auf lb01 oder lb02.

  • Der zuständige Loadbalancer transferieret den request abwechslungsweise (round-robin) auf: 192.168.80.1:8080 und 192.168.80.2:8080

Quellen

Published by

Steven Varco

Steven ist ein Redhat RHCE-Zertifizierter Linux-Crack und ist seit über 18 Jahren sowohl beruflich wie auch privat auf Linux spezialisiert. In seinem Keller steht ein Server Rack mit diversen ESX und Linux Servern.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.