wake-up-neo.net

So konfigurieren Sie Apache Httpd ordnungsgemäß als Load Balancer, wenn einige Hosts möglicherweise nicht verfügbar sind

Ich verwende eine Apache Httpd-Instanz als Proxy vor mehreren Java Tomcat-Instanzen. Apache fungiert als Load Balancer für die Tomcat-Instanzen.

Die Apache-Konfiguration sieht im Grunde wie folgt aus

<Proxy balancer://mycluster>
    BalancerMember ajp://Host1:8280 route=jvmRoute-8280
    BalancerMember ajp://Host2:8280 route=jvmRoute-8280
    BalancerMember ajp://Host3:8280 route=jvmRoute-8280
</Proxy>
<VirtualHost *:80>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Dies funktioniert grundsätzlich, wenn die AJP-Ports in den Tomcat-Instanzen konfiguriert sind. Anforderungen werden an einen der Hosts gesendet und die Last wird auf die Tomcat-Instanzen verteilt.

Allerdings sehe ich sehr lange Verzögerungen, die in Httpd immer dann auftreten, wenn einer der Hosts nicht verfügbar ist. Es scheint also, dass Apache sich nicht daran erinnert, dass einer der Hosts nicht verfügbar ist, und wiederholt versucht, Anforderungen auch an die fehlenden Hosts zu senden Senden Sie es an einen der verfügbaren Hosts und versuchen Sie es später beim fehlerhaften Host.

Gibt es eine Möglichkeit, mod_proxy et.al. zu konfigurieren? von Apache Httpd, um ein solches Failover-Szenario zu unterstützen, d. h. mehrere Hosts zu haben und keine großen Verzögerungen zu verursachen, wenn ein Host ausfällt? Vorzugsweise sollte Apache regelmäßig im Hintergrund überprüfen, welche Hosts nicht mehr vorhanden sind, und nicht, wie sie es wünschen.

Ich habe HAProxy gefunden, das für diese Art von Dingen besser geeignet zu sein scheint, aber ich würde es vorziehen, aus einer Reihe von Gründen, die nichts miteinander zu tun haben, bei Apache zu bleiben.


Aktualisieren

In der Zwischenzeit stellte ich fest, dass ein Teil meines Problems von Clients verursacht wurde, die die Verbindung endlos offen hielten und daher keine Verbindungen/Threads mehr zur Verfügung standen.

Daher ändere ich die Frage in: Welche Konfigurationsoptionen würden Sie verwenden, um den Effekt von so etwas zu minimieren? Das heißt viele offene Verbindungen zulassen oder in diesem Fall schnell schließen? Ansonsten klingt das wie ein sehr einfacher DOS-Angriff mit meiner aktuellen Konfiguration?

11
centic

Clients werden die Verbindung nicht endlos offen halten. Überprüfen Sie Ihre Apache-server-tuning.conf und suchen Sie nach der KeepAliveTimeout-Einstellung. Senken Sie es auf etwas Vernünftiges.

Ihre Änderungen an der Verbindungsunterbrechung und dem erneuten Versuch sind in der Tat das, was Sie tun müssen. Ich würde allerdings die Verbindungszeit verkürzen. 10 Sekunden ist noch Alter. Wenn sich das Back-End am selben Ort befindet, warum nicht in Millisekunden? connectiontimeout = 200ms sollte genügend Zeit für den Verbindungsaufbau lassen.

6
Amblyopius

Ich glaube, ich habe zumindest eine Art Workaround oder eine einfache Lösung gefunden. mod_proxy scheint standardmäßig eine sehr lange Verbindungszeit zu haben (300 Sekunden). Wenn Sie es nicht anders einstellen, dauert es lange, bis Offline-Knoten als fehlerhaft erkannt werden.

Durch Festlegen eines kurzen Verbindungszeitlimits und Erhöhen des Wiederholungsversuchs könnte ich dafür sorgen, dass es für mich besser funktioniert:

BalancerMember ajp://Host1:8280 route=jvmRoute-8280 connectiontimeout=10 retry=600

Dies stellt sicher, dass fehlerhafte Verbindungen relativ schnell erkannt werden und Apache nicht zu oft versucht, fehlerhafte Server zu erreichen. Leider sieht es so aus, als ob Apache tatsächliche Anfragen zur Überprüfung der Kontostandmitglieder verwendet. Daher können einzelne Anfragen von Zeit zu Zeit langsam sein, wenn versucht wird, einen Server zu erreichen, der zuvor in den Fehlerzustand versetzt wurde. Es scheint, dass es keine Heartbeat- oder Watchdog-Funktion gibt. Für so etwas bieten andere Load-Balancing-Lösungen solche Funktionen, insbesondere HAProxy

Weitere Informationen finden Sie unter mod_proxy und mod_proxy_balancer .

Zusätzlich waren der Serverstatus über mod_status und der Balance Manager über eine von mod_balancer bereitgestellte Seite eine große Hilfe bei der Diagnose dieses Problems!

2
centic

Anscheinend haben Sie das ping tag vergessen (eigentlich heißt es CPING - 100-Continue)

Wie so:

<Proxy "balancer://www">
    BalancerMember "http://192.168.0.100:80" max=128 ttl=300 retry=60 connectiontimeout=5 timeout=300 ping=2
    BalancerMember "http://192.168.0.101:80" max=128 ttl=300 retry=60 connectiontimeout=5 timeout=300 ping=2
    BalancerMember "http://192.168.0.102:80" max=128 ttl=300 retry=60 connectiontimeout=5 timeout=300 ping=2
    BalancerMember "http://192.168.0.103:80" max=128 ttl=300 retry=60 connectiontimeout=5 timeout=300 ping=2
    BalancerMember "http://192.168.0.104:80" max=128 ttl=300 retry=60 connectiontimeout=5 timeout=300 ping=2
    BalancerMember "http://192.168.0.105:80" max=128 ttl=300 retry=60 connectiontimeout=5 timeout=300 ping=2
    BalancerMember "http://192.168.0.106:80" max=128 ttl=300 retry=60 connectiontimeout=5 timeout=300 ping=2
    SetEnv proxy-nokeepalive 1
</Proxy>
ProxyPass "/www/" "balancer://www/"
ProxyPassReverse "/www/" "balancer://www/"
1
mjoao