Passthrough und Offloading: HTTPS Load Balancing mit HA-Proxy 1.5

tiero, 123RF

Verschlüsselte Last

HA-Proxy verteilt die Besucherströme vielgenutzter Webseiten auf verschiedene Server; die nächste Version optimiert auch verschlüsselte Verbindungen. Zu den Nutzern des Loadbalancer zählen unter anderem die extrem häufig frequentierten Seiten Twitter, Stack Overflow, Reddit und Tumblr.
ADMIN 03/14 stellt Erste-Hilfe-Tipps zu Windows-Rettung, Backup und Recovery bei Datenbanken vor und verrät wie man Linux-Systeme vollständig sichert und ... (mehr)

Bei womöglich zehntausend gleichzeitigen Zugriffen auf eine Webseite muss sich die Last möglichst geschickt auf mehrere Server verteilen. Für die optimale Nutzung der vorhandenen Hardware sorgt HA-Proxy [1]. HTTP-Server stoßen allerdings beim Einsatz von SSL-verschlüsselten Verbindungen schneller an ihre Grenzen, denn jede Ent- und Verschlüsselung erfordert zusätzliche Rechenleistung. An dieser Stelle legt die in Entwicklung befindliche HA-Proxy-Version 1.5 mit neuen Features nach.

Bisher unterscheiden Loadbalancer wie HA-Proxy nicht wesentlich zwischen HTTPS- und unverschlüsselten HTTP-Verbindungen. Sie leiten die geschützten Anfragen per SSL-Passthrough ungerührt an die passenden Webserver weiter. Für HA-Proxy genügt dafür die recht übersichtliche Konfiguration in Listing 1.

Listing 1

HA-Proxy mit SSL-Passthrough

01 global
02   log /dev/log  local0
03   log /dev/log  local1 notice
04
05   maxconn 1000
06   daemon
07   user haproxy
08   group haproxy
09
10 defaults
11   log     global
12   mode    tcp
13   option  httplog
14   option  dontlognull
15   timeout server 5s
16   timeout connect 5s
17   timeout client 5s
18   errorfile 400 /etc/haproxy/errors/400.http
19   errorfile 403 /etc/haproxy/errors/403.http
20   errorfile 408 /etc/haproxy/errors/408.http
21   errorfile 500 /etc/haproxy/errors/500.http
22   errorfile 502 /etc/haproxy/errors/502.http
23   errorfile 503 /etc/haproxy/errors/503.http
24   errorfile 504 /etc/haproxy/errors/504.http
25
26 frontend https_frontend
27   bind *:443
28   mode tcp
29   option httpclose
30   option forwardfor
31   reqadd X-Forwarded-Proto:\ https
32   default_backend httpserver
33
34   listen stats :2000
35   mode http
36   stats enable
37   stats hide-version
38   stats realm Haproxy\ Statistics
39   stats uri /
40   stats auth admin:secret
41
42 backend httpserver
43   mode tcp
44   balance roundrobin
45   stick-table type ip size 200k expire 60m
46   stick on src
47   server web1 10.0.0.1:443
48   server web2 10.0.0.2:443

HTTP mit oder ohne S?

Der größte Unterschied zwischen HTTP- und HTTPS-Balancing besteht in der Zeile »mode tcp« (unter »https_frontend« ), während bei der unverschlüsselten Variante »mode http« zum Einsatz kommt. Im letzteren Modus nutzt HA-Proxy die HTTP-Header-Daten, um Balancing-Entscheidungen zu treffen.

Die beiden mit »stick« beginnenden Zeilen im Abschnitt »backend« sorgen dafür, dass ein Client immer auf demselben Webserver landet. Diese Zuordnungen merkt sich HA-Proxy in einer eigenen Tabelle, der sogenannten Stick-Table.

Das Schlüsselwort »check« in der Server-Definition bewirkt, dass HA-Proxy die Backend-Server zyklisch auf Lebenszeichen prüft. Zusätzlich steht hierfür die »httpchk« -Option zur Verfügung. Sie bleibt in der noch aktuellen Version 1.4 von HA-Proxy dem unverschlüsselten HTTP-Verkehr vorbehalten, die finale Version 1.5 wird sie auch in Verbindung mit SSL erlauben.

Eingeschaltet wird die erweiterte Prüfung im einfachsten Fall mit »option httpchk« . HA-Proxy sendet dann einen vollständigen HTTP-Request an den Backend-Server (»OPTIONS /« ) und betrachtet ihn als gesund, wenn er eine Antwort mit den Statuscodes »2xx« oder »3xx« zurückbekommt. Sowohl die Request-Methode als auch die URL lassen sich anpassen:

option httpchk HEAD /
option httpchk OPTIONS /documents/all/

Die erste Zeile ersetzt die Default-Methode »OPTIONS« durch »HEAD« . Die zweite verwandelt die Standard-URL »/« in »/documents/all« .

Im Normalfall laufen die Lebenszeichen über HTTP 1.0 ab, aber HTTP 1.1 ist auch erlaubt. Dazu ist das »Host« -Feld erforderlich, das man beginnend mit der Zeichenfolge »\r\n« an die Protokollversion anhängt:

option httpchk HEAD HTTP/1.1\r\nHost:\ www

SSL-Offloading

Das grundlegende Problem beim HTTPS-Balancing besteht in der zusätzlichen Last auf den Backend-Servern, denn SSL ist rechenintensiv  – die Server können nicht so viele Clients bedienen wie ohne SSL. Für dieses Problem hat die in Entwicklung befindliche Version 1.5 von HA-Proxy eine Lösung an Bord: SSL-Offloading oder SSL-Termination. Die neue HA-Proxy-Version bringt unter anderem die Möglichkeit mit, die Verschlüsselung von SSL-Verbindungen schon am Loadbalancer zu terminieren, sodass dieser mit den Backend-Webservern nur noch HTTP spricht. Das entlastet die Webserver vom Zeit- und Ressourcen-intensiven Ver- und Entschlüsseln. Sofern die Hardware des Balancers mitspielt, erzielt diese Methode deutliche Geschwindigkeitsvorteile.

SSL-Offloading ermöglicht beim Kompilieren des Quellcodes die Option »USE_OPENSSL=1« . Fertig geschnürte Pakete stehen für einige populäre Linux-Distributionen ebenfalls bereit, darunter Debian [2], Ubuntu [3] sowie OpenSuse und Suse Linux Enterprise Server (SLES) [4]. Listing 2 zeigt die für SSL-Offloading abgewandelte Konfiguration.

Listing 2

HA-Proxy mit SSL-Offloading

01 global
02   log /dev/log  local0
03   log /dev/log  local1 notice
04
05   maxconn 1000
06   daemon
07   user haproxy
08   group haproxy
09
10 defaults
11   log     global
12   mode    http
13   option  httplog
14   option  dontlognull
15   timeout server 5s
16   timeout connect 5s
17   timeout client 5s
18   errorfile 400 /etc/haproxy/errors/400.http
19   errorfile 403 /etc/haproxy/errors/403.http
20   errorfile 408 /etc/haproxy/errors/408.http
21   errorfile 500 /etc/haproxy/errors/500.http
22   errorfile 502 /etc/haproxy/errors/502.http
23   errorfile 503 /etc/haproxy/errors/503.http
24   errorfile 504 /etc/haproxy/errors/504.http
25
26 frontend https_frontend
27   bind *:443 ssl crt /etc/haproxy/snakeoil.pem
28   mode http
29   option httpclose
30   option forwardfor
31   reqadd X-Forwarded-Proto:\ https
32   default_backend httpserver
33
34   listen stats :2000
35   mode http
36   stats enable
37   stats hide-version
38   stats realm Haproxy\ Statistics
39   stats uri /
40   stats auth admin:secret
41
42 backend httpserver
43   mode http
44   balance roundrobin
45   cookie SERVERID insert indirect nocache
46   server web1 10.0.0.1:80 check cookie web1
47   server web2 10.0.0.2:80 check cookie web2

Im Abschnitt »frontend« fällt auf, dass die »bind« -Zeile jetzt Informationen über das SSL-Zertifikat enthält. Für einen SSL-Offloading-Test genügt an dieser Stelle das von OpenSSL für Testzwecke mitgelieferte Snakeoil-Zertifikat. Wenn alles richig funktioniert, tauscht man es durch ein korrektes Zertifikat aus. In die unter »bind« angegebene PEM-Datei gehören sowohl das Serverzertifikat als auch der zugehörige private Schlüssel, sie werden darin aneinandergehängt:

#~ cat /etc/ssl/certs/ssl-cert-snakeoil.pem /etc/ssl/private/ssl-cert-snakeoil.key > /etc/haproxy/snakeoil.pem

Im Abschnitt »backend« sind die Server nun von ihrer SSL-Last befreit und lauschen auf Port 80.

Außerdem kümmern sich nun Cookies um die sogenannte Stickiness, die Zuordnung eines Clients zu einem bestimmten Server. Kommt die Anfrage eines Clients ohne passenden Cookie am Balancer an, fügt HA-Proxy einen »SERVERID« -Cookie in die Antwort ein, der den Namen des Servers enthält, etwa »web1« . Bei der nächsten Verbindung vom gleichen Client – dieses Mal mit Cookie – weiß HA-Proxy, zu welchem Server es die Anfrage schicken soll. Dieser Trick erspart dem Loadbalancer die Pflege einer Stick-Table. Listing 3 zeigt einen Ausschnitt der HA-Proxy-Debugging-Ausgabe mit der Ausgabe des Cookies.

Listing 3

HA-Proxy-Output mit Cookie-Vergabe

01 0000000e:stats.clireq[0008:ffff]: GET / HTTP/1.1
02 0000000e:stats.clihdr[0008:ffff]: Host: 10.0.0.150:2000
03 0000000e:stats.clihdr[0008:ffff]: Connection: keep-alive
04 0000000e:stats.clihdr[0008:ffff]: Authorization: Basic YWRtaW46c2VjcmV0
05 0000000e:stats.clihdr[0008:ffff]: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
06 0000000e:stats.clihdr[0008:ffff]: User-Agent: Mozilla/5.0 (X11; Linux x86_64) Ubuntu Chromium/31.0.1650.63
07 0000000e:stats.clihdr[0008:ffff]: Accept-Encoding: gzip,deflate,sdch
08 0000000e:stats.clihdr[0008:ffff]: Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
09 0000000e:stats.clihdr[0008:ffff]: Cookie: SERVERID=web2

Vor dem Start steht schließlich eine Syntaxprüfung der Konfigurationsdatei an:

#~ haproxy -c -f /etc/haproxy.cfg

Antwortet HA-Proxy mit der Meldung »Configuration file is valid« , steht der ausgewogenen Lastverteilung kaum etwas im Wege. Beim Aufruf der HTTPS-Adresse beschwert sich der Browser zwar noch über das zum Testen verwendete, aber wertlose Snakeoil-Zertifikat, dem die vertrauenswürdige Signatur fehlt. Nach dem Abnicken dieser Warnung funktioniert aber alles wie gewünscht: Client und Loadbalancer unterhalten sich per HTTPS, Balancer und Webserver per HTTP. Die Statistik (siehe Abbildung 1) zeigt die Stickiness auf: Die eingehenden Verbindungen eines Clients landen alle auf Server »web2« , während der Server »web1« auf neue Clients wartet.

Abbildung 1: Die HA-Proxy-Statistik demonstriert die Stickiness: Alle Verbindungen des untersuchten Clients landen auf dem Server web2.

Der Autor

Charly Kühnast stieg in den frühen 90ern von IBM-Mainframes auf Linux um und ist Sysadmin in einem niederrheinischen Rechenzentrum. Seine Freizeit verbringt er als Aushilfslehrer in verschiedenen Hochschulen, als Autor für Medialinx und Galileo Press, im Dojo und – am liebsten – in der Küche.

Ähnliche Artikel

comments powered by Disqus
Mehr zum Thema

Workshop: Hochverfügbarer Load Balancer mit Heartbeat und HA-Proxy

Zwei identisch konfigurierte Server hinter einem Load Balancer sind ein häufig anzutreffendes Setup. Der Balancer sorgt nicht nur für eine Verteilung der Last, sondern prüft auch zyklisch, ob seine beiden Schutzbefohlenen im Backend noch erreichbar sind. Fällt einer aus, muss der zweite Server solange die gesamte Last stemmen, aber besser als ein kompletter Ausfall ist das allemal. Damit ist ein Single Point of Failure eliminiert, aber dafür gibt es einen neuen, nämlich den Load Balancer. Wer es mit der Verfügbarkeit ernst meint, muss auch diesen doppelt vorhalten. Die entsprechende Konfiguration zeigt dieser Workshop.

Artikel der Woche

Support-Ende von SMBv1

Mit dem aktuellen Update für Windows 10 und Windows Server 2016 steht eine Änderung ins Haus, die gerade für Benutzer älterer Linux-Distributionen große Auswirkungen hat. Nachdem Microsoft es über viele Jahre schon angekündigt hat, entfernt der Konzern mit dem aktuellen Update-Release den Support für das SMB-Protokoll 1. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Linux-Backup

Welche Backup-Lösung setzen Sie für Linux im professionellen Umfeld ein?

  • keine
  • eigene Scripts
  • rsnapshot
  • rdiff-backup
  • Bacula
  • Bareos
  • Borg
  • Duplicity
  • Amanda
  • Burp
  • Clonezilla
  • Acronis
  • Arkeia
  • SEP sesam
  • Veeam
  • Redo Backup
  • Relax-and-Recover
  • andere kommerzielle Software
  • andere Open-Source-Software

Google+

Ausgabe /2018

Microsite