Load-Balancing mit dem Apache HTTP Server

Ein Indianer kommt selten allein

Bei den heutigen Anforderungen an die Leistungsfähigkeit und Ausfallsicherheit von Web-Anwendungen sind Methoden zur Lastverteilung unverzichtbar. Dieser Artikel beschreibt, wie man mit wenig Aufwand einen effektiver Load-Balancer mit dem Apache-Webervers einrichtet.

Die zunehmende Komplexität moderner Web-Anwendungen erfordert in den meisten Fällen den Betrieb von mehreren Applikationsservern. Die Gründe hierfür sind vielfältig und reichen von steigenden Besucherzahlen, über die Sicherstellung der Verfügbarkeit bis hin zu den stetig wachsenden Anforderungen der Web-Anwendungen selbst. So wird es häufig sogar notwendig selbst statische Web-Seiten über mehrere Server zu verteilen um somit deren zeitige Auslieferung sicherzustellen.

Betrachtet man die unterschiedlichen Technologien und Situationen so wird schnell klar warum zahlreiche, völlig unterschiedliche Lösungen angeboten werden. Beginnend bei einfachen DNS-basierten Verteilungssystemen, reicht die Palette über andwendungsspezifische Load-Balancer bis hin zu hochspezialisierten, auf der Ebene des Netzwerks operierenden Geräten.

Die schematische Darstellung in Abbildung 1 verdeutlicht die dem Artikel zugrundliegende Struktur eines software-basierten und auf der HTTP-Schicht [1] arbeitenden Balancing-Systems.

Abbildung 1: Schematische Darstellung eines typischen, HTTP-basierten Balancing-Systems.

Den Kern bilden in diesem Aufbau mehrere Load-Balancer, sogenannte Frontend-Server oder Gateways, die die eingehenden Anfragen der Besucher nach einem vorgegebenen Muster auf eine Sammlung ("Pool") von Applikationsservern, auch Backend-Server genannt, verteilen.

Weitere dieser Einzelsysteme können im Hinblick auf eine gesteigerte Ausfallsicherheit auch nebeneinander betrieben werden (in Abbildung 1 im Hintergrund dargestellt). In diesem Fall ist jedoch für die Verteilung unterhalb der Einzelsysteme separat Rechnung zu tragen.

Vorbereitungen

Bevor der Indianer als Load-Balancer beziehungsweise Gateway zum Einsatz kommen kann ist es von Nöten die gewünschten Funktionalitäten mittels der gewohnten Modul-Methode zu laden:

LoadModule <emphasize class="replaceable">xyz</emphasize>_module↩
  modules/mod_<emphasize class="replaceable">xyz</emphasize>.so

Wir beschränken uns in diesem Artikel auf die grundlegenden Fähigkeiten eines HTTP-basierten Load-Balancers in Kombination mit Caching, Kompression, dem URL-Rewriting sowie auch der Verarbeitung von Headern. Tabelle 1 enthält daher eine Liste der nur für diesen Artikel speziell benötigten Module; die in der Regel standardmäßig aktiven Module werden vorausgesetzt.

Tabelle 1

Benötigte Module

Modul

Funktion

mod_proxy

Allgemeines Proxy-Modul

mod_proxy_balancer

Balancer-Funktionen zum Proxy-Modul

mod_proxy_http

HTTP-Unterstützung zum Proxy-Modul

mod_cache

Allgemeines Caching-Modul

mod_disk_cache

Datei-basierte Zwischenspeicher zum Caching-Modul

mod_deflate

Modul zur Kompression von Inhalten

mod_rewrite

Modul zum Verwerten und Bearbeiten von URLs

mod_headers

Modul zum Verwerten und Bearbeiten von HTTP-Headern

AJP, oder gar FTP?

Kommen als Backends JServ-fähige Applikationsserver zum Einsatz, wie zum Beispiel Apache Tomcat oder Jetty, so ist es möglich den Gateway ebenfalls mittels des Apache JServ Protokolls (AJP) zu betreiben. Hierzu wird lediglich das Modul »mod_proxy_ajp« anstelle von »mod_proxy_http« geladen sowie die relevanten URLs von http:// auf ajp:// abgeändert.

Die Verwendung dieses, auf einem Binärformat basierenden Protokolls verspricht neben einigen Vorteilen in Bezug auf die Performance der Backend-Verbindungen auch einen insgesamt niedrigeren Resourcenverbrauch. Um dies zu erreichen ist allerdings auch eine erhöhte Anzahl an ständigen Verbindungen zu den Backends in Kauf zu nehmen.

Ein drittes Modul namens »mod_proxy_ftp« sei hier nur der Vollständigkeit halber noch kurz als ein weiteres, unterstütztes Protokoll erwähnt. Weitere Details hierzu können der Dokumentation des Apache HTTP Servers [2] entnommen werden.

Übrigens können natürlich AJP-Backends auch neben HTTP-Backends verwendet werden, selbst innerhalb eines einzelnen Pools.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
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

Google+

Ausgabe /2019