Herzlich willkommen auf dem Blog der exensio GmbH

exensio ist ein unabhängiges Software-Unternehmen von erfahrenen IT Beratern und Architekten. Zu unseren Kunden zählen namhafte deutsche Großunternehmen.

exensio verbessert das Kommunikations- und Informationsmanagement von Unternehmen. Auf Basis sinnvoller und zweckmäßiger Technologien erarbeiten wir flexible und übergreifende Lösungen für webbasierte Informationssysteme. Abhängig von den Kundenanforderungen realisieren wir Web Applikationen sowie Lösungen auf Basis von Web Content Management- und Portalsystemen. Integrativ, wirtschaftlich und anwenderfreundlich!

Hier gelangen Sie zur exensio GmbH.

Sonntag, 4. März 2012

Teil 2 - Grails in Produktion – mit Apache, Tomcat und MySQL

Im zweiten Teil meiner Blog-Serie (hier geht es zu Teil 1 bzw. Teil 3) möchte ich auf die Konfiguration des Apache Moduls mod_jk innerhalb des Apache Web-Servers eingehen. Hierzu muss die Datei httpd.conf angepasst und eine Datei worker.properties erstellt (die Konfiguration der Ports beschreibe ich dann im Tomcat-Teil meiner Blog-Serie) werden. Des Weiteren werden ich noch kurz die JKStatus Konsole vorstellen.

Einstellungen in der Datei httpd.conf:
Im Listing unten sieht man die Standard-Einstellungen, diese können und sollten dann in jedem Projekt modifiziert bzw. erweitert werden. Folgendes ist anzumerken :
  • Bis Zeile 9 - stehen die globalen Einstellungen, wie Lokation des Logfiles, der worker.properties, etc.
  • Ab Zeile 43 - stehen dann die Einstellungen innerhalb des Virtual-Host Abschnitts. In einer Produktions-Umgebung sollte man dann noch entscheiden, ob die JKStatus-Konsole benutzt werden soll (Zeile 50). 
Einstellungen in der Datei worker.properties (/etc/apache2):
Diese finden sich im Listing unten. Diese worker.properties führt ein Load-Balancing der Http-Requests auf 4 Tomcat-Server durch (mit einem Apache-WS davor). Sollen die 4 Tomcats die Requests von 2 Apache-WS-Servern erhalten, so bräuchte man 2 worker.properties. Ich würde dann jedoch weiterhin die Namen der Server global durchnummerieren, sprich svr1..svr4 und nicht svr1/svr2 für den ersten Apache-WS und erneut svr1/svr2 für den zweiten Apache-WS, da der Servername an die JSESSIONID angehängt wird und man somit einfacher herausfinden kann, an welchen Server der HttpRequest ging, um dann beispielsweise schneller das zugehörige Logfile zu finden. Zeile 29 ist noch erwähnenswert: Das Modul mod_jk geht standardmäßig von max. 3 Servern aus, auf die die Last verteilt werden soll. Aus diesem Grund ist hier der Wert auf 4 angepasst worden.

JKStatus-Konsole:
Diese ist im Bild rechts zu sehen. Meines Erachtens ist diese Konsole während der Lasttests ein sehr
nützliches Hilfsmittel. In Produktion sollte dann jedoch eher Nagios benutzt werden. Man sieht in der Konsole beispielsweise sehr schön, ob sich die Last gleichmäßig auf alle Tomcat-Server verteilt. Auch bekommt man sehr schnell mit, wenn ein Tomcat Probleme hat. Hierbei sind folgende Angaben (rote Umrandung im Bild rechts) von besonderem Interesse:
  • Busy (Current number of busy connections)
  • Max (Maximum number of busy connections). 
Bei hohen Werten hat der Tomcat Probleme, meistens hängen dann Tomcat-Threads, beispielsweise verursacht durch eine überlastete Datenbank.

Keine Kommentare:

Kommentar veröffentlichen