Was ist ein Load Balancer?

Nehmen wir an, Sie hätten eine Java Webapplikation in Spring programmiert. Eine hochexklusive Homepage, welche dem Besucher die Frisuren aller Formel 1 Rennfahrer zeigt. Nun möchten Sie ihr Glanzstück dem Internet zeigen.

Im einfachsten Fall erstellen Sie ein aus ihrem Java Projekt eine WAR Datei (Web Archive). Dann brauchen Sie noch einen Server, der zum Beispiel eine Linux Distribution am laufen hat. Dort installieren sie einen Tomcat (siehe Tomcat oder Websphere?) und kopieren ihre WAR Datei in den Webapps Ordner. Beim Starten von Tomcat wird ihre Webapplikation automatisch entpackt und gestartet.

Unerhoffter Erfolg

Nach einigen Wochen schauen Sie sich die Benutzerstatistiken an und sehen, wie die Zugriffe auf ihre Seite explodiert sind! Alle wollen Formel 1 Rennfahrerfrisuren bestaunen! Ihr Server kommt mit den Anfragen nicht mehr nach. Was tun?

Mehr Server müssen her

Sie brauchen mehr Server und Sie brauchen ein Load Balancing!

Sobald Sie mehrere Server am Laufen haben spricht man von einem Server Cluster (oder auch Server Farm oder Server Pool). Ein Cluster ist eine Gruppe von Servern, die gleichzeitig eine Webapplikationen laufen haben und für die Aussenwelt so erscheinen, als ob es ein einziger Server wäre.

Zwischen der Aussenwelt und den Servern liegt dann der Load Balancer. Dies kann eine Software- oder Hardwarelösung sein.

Das Ziel ist es, die Hochverfügbarkeit zu gewährleisten. Wenn ein Server ausfallen würde, können die verbleibenden Server die Anfragen übernehmen. Ein weiteres Ziel ist die Skalierbarkeit. Wenn ihre Benutzerzahlen in den Himmel schiessen, werden Sie noch mehr Server benötigen, um den Ansturm an Besuchern auszuhalten. Das System muss also skalierbar und erweiterbar sein.

Wie funktioniert jetzt ein Load Balancer?

Wenn ein Besucher auf ihre Webseite geht, tippt er eine URL wie „www.suesseformel1frisuren.ch“ in den Browser. Der Domain Name Server (DNS) schaut dann in seinem Verzeichnis und findet die IP Adresse des Servers, etwa „200.0.0.121“, welche er dem Besucher zurückgibt. Das nennt man DNS Lookup.

Der DNS Server kann nun mehrere Adressen für eine URL speichern. Jede Adresse steht dann für einen Server im Cluster. Kommt nun eine Anfrage rein, schickt der DNS Server die Adresse des ersten Servers zurück. Bei der nächsten Anfrage die des zweiten Servers, dann des dritten, dann wieder der erste und so weiter. Das ist die Round Robin-Methode.

200.0.0.121
200.0.0.122
200.0.0.123

Was ist der Vorteil dieser Methode?

Der Vorteil davon ist, dass neue Server ganz einfach der Konfiguration hinzugefügt werden können.

Was ist der Nachteil bei der Server Affinität?

Server Affinität ist die Fähigkeit, die Benutzeranfragen an einen bestimmten Server zu senden. Ein Nachteil dieser Methode ist es nämlich, dass mehrere Anfrage des gleichen Benutzers an verschiedene Server geschickt werden können. Das HTTP Protokoll ist stateless, zwei aufeinanderfolgende Anfragen wissen nichts voneinander. Um die Kontrolle über die Session eines Benutzers zu behalten, kann der Server eine der folgenden Methoden verwenden:

1. Cookies
2. Versteckte Felder
3. URL Rewriting

Das Prinzip ist dabei jeweils dasselbe: Wenn ein Benutzer eine erste Anfrage macht, erstellt der Server ein Token, welches diesen Benutzer identifiziert. Dieses Token wird dann an den Benutzer geliefert, und dieser schickt immer das gleiche Token bei folgenden Anfragen. Somit kann der Load Balancer die Anfragen des gleichen Tokens immer an den gleichen Server schicken.

Ein Problem hierbei ist allerdings, dass der Browser die IP Adresse des Servers cached. Wenn dieser Cache abläuft, macht der Browser eine neue Anfrage und erhält gegebenfalls eine andere IP als vorher.

Was ist der Nachteil bei der hohen Verfügbarkeit?

Hat man einen Cluster mit 5 Servern und einer dieser Server geht offline, kann es dennoch vorkommen, dass Anfragen an diesen Server geschickt werden. Um dies zu verhindern prüfen moderne Router regelmässig, ob die Server noch angesprochen werden können.

Gibt es noch andere Load Balancing Algorithmen?

Ja, statt eines Round Robins könnte man etwa wählen, dass jeweils derjenige Server die nächste Anfrage erhält, welcher momentan am wenigsten offene Verbindungen zu Clients hat.

Oder man konfiguriert ein IP Hashing, bei dem man anhand der IP Adresse des Benutzers feststellt, an welchen Server er weitergeleitet wird.

Hardware und Software Load Balancers

Bei Load Balancers gibt es Lösungen als Hardware wie auch als Software.

Ein Hardware Load Balancer hat etwa den Vorteil, dass er selber eine virtuelle Ip Adresse besitzt, die er der Aussenwelt zeigen kann. Diese virtuelle Ip repräsentiert quasi den gesamten Cluster. Kommt nun eine neue Anfrage rein, überschreibt der Load Balancer den Request Header mit der effektiven Adresse eines Servers.

Der Vorteil ist hier, dass man Server einfach entfernen kann und nicht Gefahr läuft, dass dennoch ein Benutzer auf diesen Server connected – Schliesslich wird der gesamte Cluster durch die eine virtuelle IP repräsentiert. Das Problem ist, dass Hardware Load Balancer nicht in gesicherten HTTPS Verbindungen laufen, weil dort die Nachrichten SSL-verschlüselt sind und den Load Balancer daran hindern, auf die Informationen zuzugreifen. Die Server Affinität ist somit bei HTTPS nicht gegeben. Für die Entschlüsslung müsste ein Web Server Proxy vor den Cluster gehängt werden.

Software Load Balancer werden auch Application Delivery Controller (ADC) genannt, welche gut mit Virtual Appliances umgehen können – Also etwa ein Betriebssystem, Tomcat und Webapplikation als geschnürtes Paket.

Momentan mal! Virtual Applicances? Huh?

Genau. Am Anfang habe ich das einfachste Beispiel gemacht: Sie kaufen einen physischen Server, stellen ihn in einen Raum und installieren zum Beispiel eine Linux Distribution mit Tomcat auf dieser Maschine. Dort läuft dann ihre Webapplikation.

In den heutigen Firmen ist dieses einfache Beispiel aber mittlerweile ziemlich entfernt von der Realität. Stellen Sie sich vor, eine Firma müsste für jede Webapplikation eine bis mehrere physische Server unterhalten. Das wäre ein viel zu grosser Aufwand.

Stattdessen läuft heute mittlerweile so ziemlich alles virtualisiert – So virtualisiert, wie man sich das kaum vorstellen kann. Eine grosse Firma hat etwa eine gewisse Serverlandschaft zur Verfügung. Auf dieser Serverlandschaft laufen alle ihre Webapplikationen – Aber alle stets virtualisiert. Ihre Formel 1 Frisuren-Applikation ist dann etwa nur ein virtuelles Image, in dem schon alles enthalten ist: Applikation, Betriebssystem und Tomcat. So kann man die Applikation auf beliebig vielen Servern starten und wieder verschwinden lassen, ganz wie man es benötigt (Punkt Skalierbarkeit).

Liefert man eine neue Version seiner Applikation, macht das Entwicklungsteam oftmals gleich das Gesamtpaket (also das ganze Image) für den Betrieb bereit, welcher dieser nur noch deployen kann. Entgegen meinem Artikel Was ist DevOps? ist die Entwicklung und der Betrieb oftmals noch in verschiedenen Teams. Die Entwickler entwickeln, die Betriebsleute installieren.

Nun, es geht sogar noch weiter, aber ich muss wohl langsam zum Ende kommen. Weitere interessante Themen sind etwa Docker, bei dem man die Applikation auch noch vom Betriebssystem abkoppelt, oder serverless code, bei dem alles irgendwo in der Cloud läuft. Aber diese Geschichte erzähle ich ein anderes Mal.

Tomcat oder Websphere?

Wie viele andere Firmen mussten wir uns an einem Punkt entscheiden, ob wir unsere Infrastruktur von IBM Websphere Applikationsserver auf Apache Tomcat wechseln sollten.

Beide Produkte sind zum Ende des letzten Jahrhunderts entstanden, haben sich aber in verschiedene Richtungen entwickelt. Während Tomcat ein Leichtgewicht geblieben ist und als Open-Source Produkt verwendet werden kann, wurde aus Websphere ein grosses Produkt einer ganzen Gruppe von IBM Produkten, die miteinander zusammenarbeiten.

Websphere ist ein Applikationsserver

Was man oftmals als technischen Unterschied liest ist, dass Websphere ein Applikationserver ist, während Tomcat nur als Servlet Container fungiert.

Ein Java Applikationsserver unterstützt alle Java EE Funktionalitäten. Diese Funktionalitäten erweitern die Standard-Java-Plattform für die Durchführung von internetbasierten Businesstransaktionen. Dazu gehören etwa JTA, EBJs oder JMS.

Bis Java Version 6 musste dabei ein Java EE Applikationsserver all diese Aspekte berücksichtigen. Dies ist heute nicht mehr so, dank dem Konzept von „profiles“ in Java 6. Applikationen werden in Java Applikationsservern im EAR (Enterprise Archive) Fromat ausgeliefert, wobei ein EAR mehrere WAR Dateien beinhalten kann (Eine WAR Datei ist quasi eine Webapplikatikon).

Und Tomcat ist ein Servlet Container

Ein Servlet Container muss nur die Java Servlet und JSP Spezifikation implementieren, welche die Installation von Webapplikationen definiert. Ein Servlet Container kann also genauso eine WAR Datei laufen lassen.

Heutzutage ist es so, dass die Servlet Spezifikation soviele Aspekte von Webtechnologien abdeckt, dass viele kommerzielle Firmen Tomcat als Applikationsserver verwenden.

Enterprise Java Beans sind kein Grund mehr

Lange Zeit war einer der Vorteile von Websphere die volle Unterstützung von Enterprise Java Beans (EJB). Diese Beans stellen einen Weg zur Verfügung, wie Businesslogik in ein einzelnes Objekt gekapselt werden kann. Dies hat sich allerdings mit dem kostenlosen OpenEJB plugin geändert.

EJBs wurden etwa eingesetzt, wenn die Applikation verteilt war, also Zugriff auf Ressourcen auf anderen Maschinen benötigte. Dies ist aber in Zeiten von Webservices oder REST Services kein Pluspunkt für EBJ mehr.

Skalierbarkeit war ebenfalls ein Thema bei EJBs, inklusive Load Balancing oder fail-over Szenarien. Hierfür gibt es aber mittlerweile eine ganze Reihe von Open Source Programmen, die man einsetzen könnte.

Man sieht: Viele der genannten Vorteile wie JMS, JTA, JPA etc. sprechen heute nicht mehr für EJB, wenn man Tomcat und Websphere vergleicht.

Die Framework Landschaft ist gewachsen

Ein weiterer Unterschied ist das Auftauchen von Frameworks wie Spirng, Seam, Hibernate, Grails, Guice oder JRuby on Rails. Mit diesen Frameworks kann man heutzutage die gleichen Ergebnisse erzielen wie mit Java EE. Diese Frameworks wurden oftmals aus dem Grund entwickelt, weil Entwickler unzufrieden waren mit der EJB oder Java EE Implementation und die Weiterentwicklung zu langsam voranschritt.

Ein Anbieter, Performanz und Unterstützung

Der technische Unterschied zwischen Tomcat und Websphere ist mit voranschreitender Zeit geringer und geringer geworden. Mit den richtigen Erweiterungen und Tools steht Tomcat dem Websphere praktisch in nichts mehr nach.

Bei Websphere muss man sich im Klaren sein, dass man auf einen einzigen Anbieter setzt, und dessen Launen vollends ausgesetzt ist. Dadurch, dass Websphere Teil eines grossen Gesamtsystems ist, kann durchaus auch die Performanz darunter leiden. Auch in meiner Erfahrung war besonders die Entwicklungsarbeit mit Tomcat enorm schneller als mit Websphere.

Was man aber nicht übersehen darf: Setzt man auf Websphere, kann man mit der Unterstützung von IBM rechnen sowie auch deren administrative Tools für den Umgang des Servers verwenden. Bei Tomcat muss man sich eher auf die Internet Community verlassen. Zudem gelten vorallem die Websphere Server als sehr stabil – Wobei ich noch nie gehört habe, dass Tomcats instabil sind.

Tomcat mit vielen Vorteilen

Warum setzen bereits über sechzig Prozent der Webentwickler auf Tomcat? Meistens hört oder liest man die gleichen Gründe: Bei Tomcat kann man seine eigene IDE wählen, dass die prorietäre IDE von Websphere zu verwenden. Ein Tomcat Server startet unglaublich schnell, was natürlich der generellen Entwicklungszeit zugute kommt.

Ein Punkt, bei dem Websphere die Nase vorn hat, sind die Möglichkeiten der grafischen Analyse und Verwaltung des Servers. Die Popularität von Tomcat hat aber dazu geführt, dass etwa Produkte wie Tcat diese Lücke füllen.

Natürlich wichtig: Der Preis

Websphere verursacht astronomische Kosten während Tomcat kostenlos und Open Source ist. Das ist der Grund, den ich jeweils am häufigsten gehört habe, um eine Migration zu rechtfertigen. Wenn man zwei Produkte hat, die ähnliche Funktionen anbieten beziehungsweise ein Prjekt zum Ziel führen könnten, ist es schwer, sich für eine sehr teure Lösung zu entscheiden – teuer beim initialen Aufwand sowie jährlichen Lizenzkosten.

Bei Tomcat benötigt es gerade mal die Hardware, auf der der ganze Spass laufen kann und die Kosten für das Einrichten und den Betrieb des Servers.

Der Apple Effekt

Was dazukommt ist ein ähnliche Effekt wie bei Apple: Hat man erst einmal ein Produkt von IBM gekauft, wird man an diesen Anbieter gebunden und kauft bei weiteren Anwendungsfällen höchst wahrscheinlich auch wieder Software von demselben Anbieter – Etwa weil die verschiedenen Programme von IBM gut miteinander harmonieren.

Bei Tomcat hat man schon eine höhere Flexibilität und die Freiheit, die Tools zu nehmen, die man selber für richtig hält. Dann wiederum kann man auch argumentieren, dass die Suche und Einarbeit in neue Tools ebenfalls Aufwand erzeugt, während man bei IBM auf eine eingelebte Produktgruppe zugreifen kann und von IBM sogar noch bei der Einrichtung unterstützt wird.

Mein Fazit: Tomcat = Flexibilität

Wie ich bereits geschrieben habe machte ich sehr gute Erfahrungen bei der Entwicklung mit Tomcat im Vergleich zu Websphere – Besonders beim Punkt Schnelligkeit. Bei einem Websphere Server musste ich jeweils 1-2 Minuten warten, bis er oben war, während es bei Tomcat vielleicht 10-20 Sekunden waren.

Was mich persönlich ebenfalls beeindruckt, ist der eingebettete Tomcat in Produkten, etwa in Spring Boot. Einer Spring Boot Webapplikation kann als einfache JAR Datei erstellt werden und Spring Boot kann diese JAR Datei automatisch auf einer (magischen?) Tomcat Instanz laufen lassen – Ohne dass ich irgendetwas konfigurieren muss (ich bin ein heimlicher Spring Fanboy).

Für Tomcat spricht sicherlich auch die Flexibilität, wenn jemals ein weiteres Produkt auf den Markt kommen würde. Die Hürde, auf das neue Produkt zu wechseln, wäre viel geringer als bei der eingefleischten IBM Familie.

Was ist GlusterFS?

GlusterFS ist eine geniale Erfindung, wenn man eine Applikation hat, die auf mehreren Servern läuft und dort Abfragen bearbeitet. GlusterFS ist ein verteiltes Dateisystem, das Speicherelemente von mehreren Servern als einheitliches Dateisystem präsentiert. Mehrere Rechner können dabei gleichzeitig auf ein gemeinsames Dateisystem zugreifen. GlusterFS ist OpenSource und erlaubt die Verschüsselung der Verbindung via Transport Layer Security via OpenSSL.

Stellen Sie sich vor, sie haben 6 Server, auf denen ihre Applikation läuft. Jede ihrer Server verarbeitet Requests und loggt dabei die Erfolgsmeldungen sowie eventuelle Fehler. Wenn Sie nun wissen wollen, ob Ihre Server einen bestimmten Kunden verarbeitet haben – Etwa den Kunden „Kung Fu Panda“ – ist das kein Problem, da sie den Namen der Kunden in den Logfiles speichern. Aber, oh weh, Sie müssen sich jedesmal auf 6 Servern einloggen, um die Logfiles nach dem Kunden zu durchforsten.

Bei diesem Problem kann Ihnen GlusterFS helfen. Die Logfiles können dazu einfach an einem Platz zusammengetragen werden. Dazu kommt, dass Sie sich auf einen beliebigen Server einloggen können, um die Files zu lesen. Bei diesem Beispiel fällt auch auf, dass 6 bereits eine relative hohe Zahl von Server ist und bei GlusterFS beliebig erweitert werden kann, wo bei Alternativen jeweils nur zwei Knoten zu einem Dateisystem verbunden werden konnten.

Dabei gibt es verschiedene Konfigurationsoptionen. Die Dateien können zum Beispiel verteilt gespeichert und dem Client als ein Dateisystem angezeigt werden. Dadurch kann der zur Verfügung stehende Speicher einfach erhöht werden, die Dateien sind dabei aber nicht redundant. Interessanter ist aber wohl in vielen Anwendungsfällen der „Replicated Storage“, bei der jede Datei auf mehreren Servern gespiegelt gespeichert wird. Falls ein Server ausfallen würde, oder eine Daten nicht korrekt abgelegt werden kann, wäre diese immer noch auf dem zweiten Server vorhanden. GlusterFS unterstützt den Administrator dabei, wenn ein sogenannter „Split Brain“ passieren würde: Wenn das Spiegeln (mirroring) einer Datei auseinanderläuft und das File nur noch auf einem der Server im Gluster verfügbar ist.

GlusterFS kann im Netz hier gefunden werden: https://www.gluster.org/

was ist glusterfs replicated.png