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

 

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

 

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

 

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.
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023