Version: GSB 7Grundlagen

• Apache-Tomcat-Kopplung
• Loadbalancer

In diesem Kapitel werden

• die für dieses Dokument wichtigen Teilkomponenten des Webservers Apache, des Applikationsservers Tomcat und der Suchmaschine Lucene vereinfacht vorgestellt
• sowie eine gängige Strategie zum Thema Ausfallsicherheit mittels Loadbalancer skizziert.

Die diskutierten Punkte stellen in ihrer derzeitigen Konfiguration bzw. Verfügbarkeit wichtige Aspekte für die in den folgenden Kapiteln durchgeführte Diskussion der Tomcat Cluster-Strategien vor.

Apache-Tomcat-Kopplung

Zur Auslieferung der Inhalte werden beim GSB die so genannten Delivery-Tomcatserver von Core Media eingesetzt. Abbildung 1 skizziert stark vereinfacht, den prinzipiellen Aufbau eines Delivery-Tomcatservers mit den in diesem Konzept betrachteten Komponenten. Gegenwärtig existiert im wesentlichen eine 1-1-Zuordnung der Apache-Webserver zu ihren nachgeschalteten Tomcats, die zum einen für den Aufbau und die Verwaltung des Cache als auch über das Search & Indexing Framework eine Schnittstelle zur Suchmaschine Lucene oder zum zugeordnetenSolr-Suchserver bereitstellt. Zur Vereinfachung wird diese Schnittstelle in eine Teilkomponente für die Bearbeitung von Suchanfragen (Index Reader) und eine Teilkomponente den Aufbau bzw. Aktualisierung des Suchindexes aufgeteilt (Index Writer).

Eine zentrale Aufgabe des Delivery-Tomcatservers ist die Bearbeitung von Request. In der Regel werden Requests derzeit vom Apache-Webserver entgegen genommen.

Im GSB-Kontext werden eingehende Requests mithilfe der verfügbaren CoreMedia-Mechanismen verarbeitet, d.h. Requests werden seitens des Apaches auf zwei verschiedene Arten beantwortet:

• Bei gecachten Inhalten erfolgt eine Auslieferung der angefragten Inhalte, indem die Inhalte direkte aus dem durch den Applikationsserver Tomcat aufgebauten internen Caches ausgelesen und ausgeliefert werden.
• Bei (noch) nicht-gecachten Inhalten wird der Request an den zugehörigen Tomcat weitergeleitet wird. Der Applikationsserver generiert die vom Webserver angefragten Inhalte, legt das Ergebnis (bzw. Teile davon) ggf. im internen Cache ab und liefert das Ergebnis dann vollständig an den Webserver aus.

Die Weiterleitung an den zugehörigen Tomcat geschieht über das Apache-Modul mod_proxy, das die Requests, abhängig vom angesprochenen Servernamen („Virtualhost“) an einen gegebenen Tomcat weiterleitet.

Loadbalancer

Loadbalancer werden zur Lastverteilung sowie zur Absicherung im Falle eines Server-Ausfalls eingesetzt. Um im Falle eines Serverausfalls oder bei Lastspitzen die eingehenden Anfragen weiterhin performant bearbeiten zu können, werden die Anfragen durch einen Loadbalancer auf weitere, so genannte Backup-Server verteilt.

Ausfallstrategie

Zur Verteilung der Anfragen muss für den Loadbalancer eine geeignete Ausfallstrategie definiert und umgesetzt werden. Da eine Ausfallstrategie sowohl von den Optionen des Loadbalancers als auch von den verfügbaren Hard- und Softwarekomponenten und deren Auslastung abhängt, kann eine solche Strategie natürlich nur im Rahmen einer konkreten GSB-Installation definiert werden. Die im folgenden skizzierte Strategie stellt daher nur eine mögliche Ausfallstrategie dar, die im Multi-Mandanten Betrieb eingesetzt werden könnte.

Als Ausgangspunkt wird davon ausgegangen, dass die installierte GSB-Instanz mehrere Mandanten hostet und über mehrere Delivery-Tomcatserver verfügt. Jeder Delivery-Server ist so installiert, dass er prinzipiell in der Lage wäre, alle Mandanten auszuliefern. Der Loadbalancer teilt die verfügbaren Delivery-Server in verschiedene Gruppen ein, wo bei die Einteilung wie folgt aussieht: Eine Mandanten-Gruppe wird im Normalfall von mehreren primären Delivery-Servern bedient. Im Notfall stehen weitere, so genannte Backup Delivery-Server zur Verfügung.

Das Aktivierungsszenario der Backup Delivery-Server sieht dabei wie folgt aus: Fällt ein primärer Delivery-Server aus, liefern zunächst die übrig gebliebenen primären Delivery-Server den Content der Mandanten-Gruppe weiter aus, d.h. es werden keine Backup Delivery-Server vom Loadbalancer angesteuert.

Erst, wenn kein Server der primären Delivery-Server-Gruppe mehr zur Verfügung steht, bearbeiten die Server der Backup Gruppe auch die Anfragen von Mandanten aus der ausgefallenen primären Delivery-Server. Die Entscheidung, welche Anfrage an welchen Delivery-Server der Backup Gruppe weitergeleitet wird, wird dabei weiterhin allein durch den Loadbalancer festgelegt.

Überprüfung der Verfügbarkeit der Delivery-Tomcatserver

Zur Bestimmung, ob ein Delivery-Tomcatserver zur Verfügung steht, wird der entsprechende Apache in in der Standardinstallation regelmäßigen Abständen unter einem bestimmten VirtualHost-Namen („SymbolicServerName“) angesprochen. Unter diesem Namen leitet der Apache Requests an die Tomcat-Webapplikation „healthCheck“ weiter. Sollte der Apache oder Webapplikation nicht erreichbar sein oder HTTP-Fehler-Codes, wie z.B. 500 (interner Serverfehler) oder 404 (Ressource nicht gefunden) etc. zurückliefern, so wird der entsprechende Delivery-Tomcatserver für die Dauer des Fehlerzustandes aus der Lastverteilung genommen.

Falls der Apache allerdings mehrer Tomcats anspricht und den Traffic mandantenspezifisch auf diese Tomcats verteilt, muss der LoadBalancer für jeden Mandanten einen spezifischen „healthCheck“-Request abschicken. Mit der im letzten Kapitel beschriebenen Konfiguration würde man das Muster www.mandant.de/healthCheck verwenden und der LoadBalancer würde je nach Mandant unterschiedliche Tomcatserver testen.

Behandlung von Sessions

Falls für die Abarbeitung einer Anfrage mehrere Tomcats einer Mandantengruppe zur Verfügung stehen, so sollte der Loadbalancer, falls der Request im Kontext einer http-Session abgesetzt wurde, diesen Request an denjenigen Tomcat weiterleiten, der die Session erzeugt hat („sticky session“). Anderenfalls würden die einzelnen Requests des Users zufällig zwischen allen verfügbaren Tomcats verteilt werden, was gegebenenfalls zu multiplen Login-Aufforderungen führen würde, da die aktuelle Session-ID des Users und damit der User selbst nur auf demjenigen Tomcat bekannt ist, auf dem die Session auch erzeugt wurde. Beim Zugriff auf einen der anderen Tomcats erhält der User eine neue Session und wird abermals zur Authentifizierung aufgefordert, sofern er einen durch den Tomcat geschützten Bereich betritt.