Apache – Tomcat: jk-workers.properties

Hier werden wie weiter oben schon besprochen Worker und Balancer konfiguriert. Am Anfang der Datei gibt es eine sogenannte „worker.list“. Alles was hierin aufgelistet wird, ist dem Apache2 später auch bekannt. Darunter folgt dann meist die Konfiguration der einzelnen Worker und Balancer. Wobei ein Balancer auch nur eine Art Worker ist. Ein Worker ist einfach nur die Beschreibung eines Tomcats. Dabei lässt er sich mit 3 Zeilen abbilden. Man gibt mit „worker.Name.port“ den AJP-Connector Port an , mit „worker.Name.host“ den Hostnamen oder die IP und mit „worker.Name.type“ noch den Typ an. Beim Typ kann man entweder „ajp13“ oder „lb“ angeben. Wobei „lb“ dann für Load Balancer steht und „ajp13“ für einen normalen Worker. Der „Name“ im mittleren Teil der 3 Parameter sollte im dem der JVMRoute aus dem Engine-Tag der Server.xml des Tomcats entsprechen. Im Eigentlich ist dies aber nur wichtig, wenn man einen LB aufbauen möchte. Da so der Apache2 genau die Tomcats unterschieden kann. Hat man also diese 3 Parameter, hat man auch schon einen Worker, diesen fügt man dann noch der am Anfang erwähnten „worker.list“ hinzu. Einfach den Namen des Worker dort eintragen in einer Komma-separierten Liste. Anschließend dann noch „/etc/init.d/apache2 reload“. Damit ist ein Worker eingerichtet.

Einen LoadBalancer richtet man ebenso einfach ein. Zuerst braucht man aber mindestens einen Worker und damit es Sinn macht am besten gleich einen 2. dazu. Den Balancer kann man frei benennen. Mit „worker.TestBalancer.balance_workers“ legt man fest, welche Worker Teil des Balancer sind. Dort Komma- separiert die Liste an Tomats mit ihren Worker-Namen eintragen. „worker.TestBalancer.type“ setzt man dann auf „lb“. Wenn man in seiner Webapplikation mit Seesions arbeitet sollte man dann noch „worker.adminbalancer.sticky_session“ auf „1“ setzten. Damit man immer auf dem selben Worker bleibt und nicht mit jeden Request hin und her springt. Für die „method“ gibt es dann mehrere Optionen, hier ein Auszug aus der offiziellen Doku(1):

  • If method is set to R[equest] the balancer will use number of requests to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. This is the default value and should be working well for most applications.
  • If method is set to S[ession] the balancer will use number of sessions to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. Because the balancer does not keep any state, it actually does not know the number of sessions. Instead it counts each request without a session cookie or URL encoding as a new session. This method will neither know, when a session is being invalidated, nor will it correct its load numbers according to session timeouts or worker failover. This method should be used, if sessions are your limiting resource, e.g. when you only have limited memory and your sessions need a lot of memory.
  • If set to T[raffic] the balancer will use the network traffic between JK and Tomcat to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. This method should be used, if network to and from the backends is your limiting resource.
  • If set to B[usyness] the balancer will pick the worker with the lowest current load, based on how many requests the worker is currently serving. This number is divided by the workers lbfactor, and the lowest value (least busy) worker is picked. This method is especially interesting, if your request take a long time to process, like for a download application.

Request und Session haben sich bis jetzt bewährt. Der gesamte Parameter wird dann wieder mit „worker.TestBalancer.method“ gesetzt. Damit wäre dann auch ein Balancer konfiguriert. diesen dann nur noch in der „worker.list“ mit seinen Namen hinzufügen.

 

(1): http://tomcat.apache.org/connectors-doc/reference/workers.html